Exadata Cloud Infrastructureは、顧客とOracleによって共同で管理されます。

Exadata Cloud Infrastructureデプロイメントは、次の2つの責任範囲に分けられます:

顧客がアクセス可能なサービス: Exadata Cloud Infrastructureのサブスクリプションの一部として顧客がアクセスできるコンポーネント

• 顧客アクセス可能な仮想マシン(VM)
• 顧客アクセス可能なデータベース・サービス

Oracle管理インフラストラクチャ: 顧客がアクセス可能なサービスを実行するためにOracleによって所有および操作されるコンポーネント

• 電力配分装置(PDU)
• アウトオブバンド(OOB)管理スイッチ » InfiniBandスイッチ
• Exadata Storage Server
• 物理Exadataデータベース・サーバー
• 顧客情報を含むExadataサーバーをホストするデータセンター・セキュリティ

顧客は、(OCI仮想クラウド・ネットワークおよびOCIセキュリティ・リストを介した)VMへのネットワーク・アクセス、VMにアクセスするための認証、VMで実行されているデータベースにアクセスするための認証など、顧客サービスへのアクセスを制御およびモニターします。Oracleは、Oracle管理インフラストラクチャ・コンポーネントへのアクセスおよび物理サーバーのセキュリティを制御およびモニターします。Oracleのスタッフは、顧客が顧客VMにアクセスできない場合を除き、顧客VMやデータベースなど、顧客のサービスにアクセスすることを許可されていません。Exadata Cloud Serviceのセキュリティ制御ドキュメント(https://www.oracle.com/a/ocom/docs/engineered-systems/exadata/exadata-cloud-service-security.pdf)の例外ワークフローを参照してください。

顧客は、ポート1521のOracle Netなどの標準的なOracleデータベース接続方法を使用して、顧客VMで実行されているデータベースへのクライアントVCNおよびバックアップVCNを介してExadata Cloud Infrastructureで実行されているOracleデータベース(DB)にアクセスします。顧客は、ポート22のトークン・ベースSSHなど、標準のOracle Linuxの方法を使用して、Oracleデータベースが実行されているVMにアクセスします。

Exadata Cloud Infrastructureによって提供されるセキュリティ機能。

• Oracle Cloudの物理的なセキュリティ

  Oracle Cloudデータ・センターは、Uptime InstituteおよびTelecommunications Industry Association (TIA)のANSI/TIA-942-A Tier 3 (99.982%の可用性)またはTier 4 (99.995%の可用性)の標準に準拠し、重要機器の運用にはN2 (Nは必要性)の冗長化手法に従っています。Oracle Cloud Infrastructureサービスを収容するデータ・センターは、冗長電源を使用し、広域の停電に備えて発電機のバックアップを維持しています。サーバー・ルームは、温度や湿度が詳細にモニターされ、消火システムが配備されています。データ・センターのスタッフは、発生する可能性のあるセキュリティおよび可用性イベントに対処できるように、インシデントへの応答やエスカレーション手順についてトレーニングを受けています。詳細は、Oracle Cloud Infrastructureセキュリティ・ガイドを参照してください。Oracle Cloud Infrastructureデータ・センター・コンプライアンスの詳細は、Oracle Cloudコンプライアンスを参照してください。

• 顧客システムへのオペレータ・アクセス

  Oracleのアクセス・プロトコルは次のとおりです:

  • 施設への物理的なアクセスは、特定のOracle従業員、受託業者および許可された訪問者に制限されます。
  • Oracleの従業員、下請業者および許可された訪問者にはIDカードが発行され、Oracleの敷地内にいる間はこれを着用する必要があります。
  • 訪問者は、訪問者名簿に署名すること、Oracleの敷地内にいるときは付添いまたは監視(あるいはその両方)を受けること、またはOracleとの機密保持契約の内容を守ること(あるいはそのすべて)が求められます。
  • セキュリティは、キー/アクセス・カードの所有と施設へのアクセス能力をモニターします。Oracleを退職するスタッフは、キー/カードを返却する必要があり、退職時にキー/カードは非アクティブ化されます。
  • サービス拠点での物理的なセキュリティ・バリアまたは入退室管理に対するすべての修復および変更は、セキュリティが認可します。
  • Oracleでは、施設のリスク/保護レベルに応じて、24時間365日のオンサイトの警備要員またはパトロール要員を組み合せて使用します。いずれの場合も、要員はパトロール、警報応答、およびセキュリティ・インシデントの記録に責任を負います。
  • Oracleは、統合された侵入者警報機能を備えた一元管理型の電子アクセス制御システムを実装しています。アクセス・ログは、6か月以上保存されます。さらに、CCTVによるモニターおよび記録の保持期間は、施設の機能およびリスク・レベルに応じて、最低30日から90日間です。
• ハイパーバイザの顧客分離

  ハイパーバイザは、クラウド環境で仮想デバイスを管理し、サーバーおよびネットワークの仮想化を処理するソフトウェアです。従来の仮想化環境では、ハイパーバイザはネットワーク・トラフィックを管理し、VMインスタンス間、およびVMインスタンスと物理ホストの間のフローを可能にします。これにより、ハイパーバイザの複雑さと計算オーバーヘッドが大幅に増します。仮想マシン・エスケープ攻撃などの概念実証コンピュータ・セキュリティ攻撃により、この設計に伴う大きなリスクが浮き彫りになりました。これらの攻撃ではハイパーバイザの複雑さを悪用して、攻撃者がVMinstanceから抜け出し、基盤となるオペレーティング・システムにアクセスして、ハイパーバイザを制御できるようになります。攻撃者は他のホストにアクセスでき、時には検出されないこともあります。Oracle Cloud Infrastructureは、ネットワーク仮想化をハイパーバイザから切り離すことで、このリスクを軽減します。ネットワーク仮想化は高度にカスタマイズされたハードウェアおよびソフトウェア・レイヤーとして実装され、クラウド制御はハイパーバイザおよびホストから切り離されて独自のネットワークに配置されました。この強化およびモニターされた制御層が、分離されたネットワーク仮想化を可能にします。分離されたネットワーク仮想化では、攻撃対象領域を制限することでリスクを軽減します。悪意のある行為者が1つのホストでVMエスケープ攻撃に成功したとしても、クラウド・インフラストラクチャ内の他のホストに到達できないように設計されています。攻撃は事実上1つのホストに封じ込められます。分離されたネットワーク仮想化は、すべてのリージョン内のすべてのデータ・センターに実装されます。つまり、すべてのOracle Cloud Infrastructureテナントがこのリスク低減の恩恵を受けることになります。

  図6-1 Oracleの第2世代クラウドにおける分離されたネットワーク仮想化によるリスクの低減

  
  
• マルチテナントのセキュリティ

  マルチテナントは多層防御のセキュリティ理念に従い、包括的な分離アーキテクチャを備えています。

  これには4つの主要なカテゴリがあり、各カテゴリにいくつかの重要な機能があります。

  1. アクセス制御メカニズム
  2. 不正な管理者アクセスの防止
  3. データ・ファイルへの直接アクセスの防止
  4. リソースの分離

  図6-2 マルチテナントの包括的な分離アーキテクチャ

  
  

• 多層防御 Exadata Cloud Infrastructureは、サービス全体の機密性、整合性および可用性を確保するための多くの制御を提供します。

  まず、Exadata Cloud Infrastructureは、Exadata Database Machineによって提供される堅牢なオペレーティング・システム・イメージから構築されています(https://docs.oracle.com/en/engineered-systems/exadata-database-machine/dbmsq/exadata-security-overview.html)。これにより、インストール・イメージが必要なソフトウェア・パッケージのみに制限され、不要なサービスが無効になり、システム全体にセキュアな構成パラメータが実装されて、コア・オペレーティング環境が保護されます。

  Exadata Cloud Infrastructureは顧客のためにシステムをプロビジョニングするため、Exadata Database Machineの成熟したプラットフォームのすべての強みを継承することに加え、追加のセキュアなデフォルト構成選択がサービス・インスタンスに実装されています。たとえば、すべてのデータベース表領域には、透過的データ暗号化(TDE)、初期データベース・ユーザーとスーパーユーザー用の厳格なパスワード強制、および拡張監査とイベント・ルールが必要です。

  Exadata Cloud Infrastructureは、完全なデプロイメントとサービスも構成するため、PCI、HIPPA、ISO27001などの業界標準の外部監査の対象になります。これらの外部監査要件により、ウィルス対策スキャン、システムの予期しない変更に対する自動アラート、フリート内のすべてのOracle管理インフラストラクチャ・システムに対する日次脆弱性スキャンなど、付加価値サービス機能が追加されます。

• 最小権限

  Oracle Secure Coding Standardsでは、ソフトウェア・プロセスを、その機能を実装するために最小限の権限レベルで実行する必要があります。

  各プロセスおよびデーモンは、より高いレベルの権限の必要性を証明できる場合を除き、通常の権限のないユーザーとして実行される必要があります。これにより、予期しない問題や、権限のないユーザー領域に対する脆弱性が抑制され、システム全体が危険にさらされることがなくなります。

  メンテナンスまたはトラブルシューティングのためにExadata Cloud Infrastructureへのアクセスに個別の指定アカウントを使用するOracle operationsチーム・メンバーにもこの原則は適用されます。必要な場合にのみ、より高いレベルの権限への監査アクセスを使用して問題を解決します。ほとんどの問題は自動化によって解決されるため、自動化で問題を解決できない場合を除き、人間のオペレータにシステムへのアクセスを許可しないことで最小権限を採用しています。

• 監査とアカウンタビリティ

  必要に応じてシステムへのアクセスが許可されますが、すべてのアクセスおよびアクションは、アカウンタビリティのために記録およびトラッキングされます。

  Exadata Cloud Infrastructureの監査ログはOracleによって制御され、セキュリティのモニターおよびコンプライアンスの目的で使用されます。Oracleは、Oracle Incident Response PracticesおよびOracle Data Processing Agreementに従って、関連する監査ログを顧客と共有できます。

  すべてのアクションを取得できるように、すべてのインフラストラクチャ・コンポーネントで監査機能が提供されています。顧客は、データベースおよびゲストVM構成に監査を構成することもでき、それらを他のエンタープライズ監査システムと統合することもできます。

• クラウド操作の自動化

  システムのプロビジョニング、パッチ適用、メンテナンス、トラブルシューティングおよび構成に必要な手動操作をなくすことで、エラーの可能性が減少します。

• 強化されたOSイメージ

  • 最小限のパッケージ・インストール:

    効率的なシステムを実行するために必要なパッケージのみがインストールされます。インストールするパッケージ・セットを小さくすると、オペレーティング・システムの攻撃対象領域が減少し、システムの安全性が向上します。

  • セキュアな構成:

    システムおよびそのコンテンツのセキュリティ状態を強化するために、多くのデフォルト以外の構成パラメータがインストール時に設定されます。たとえば、SSHは特定のネットワーク・インタフェースでのみリスニングするように構成され、sendmailはlocalhost接続のみを受け入れるように構成されるなど、他にも同じような多くの制限がインストール時に実装されます。

  • 必要なサービスのみを実行:

    システムにインストールされているが、通常の操作に必要のないサービスは、デフォルトで無効になっています。たとえば、NFSはアプリケーションの様々な目的のために顧客が頻繁に構成するサービスですが、通常のデータベース操作には必要ないため、デフォルトでは無効になっています。顧客は、要件ごとにオプションでサービスを構成できます。

• 攻撃対象領域の最小化

  強化されたイメージの一部として、攻撃対象領域が削減され、サービスの提供に必要なソフトウェアのみがインストールおよび実行されます。

• 追加のセキュリティ機能の有効化(grubパスワード、セキュア・ブート)

  • ExaDB-Dは、Exadataイメージ機能を利用して、ベース・イメージに統合された機能(他の多くの機能に加えて、grubパスワードやセキュア・ブートなど)を使用します。
  • カスタマイズを通じて、顧客は追加の構成により、セキュリティ体制をさらに強化できます。
• セキュアなアクセス方法
  • 強力な暗号を使用したSSHを介したデータベース・サーバーへのアクセス。弱い暗号はデフォルトで無効になっています。
  • 暗号化されたOracle Net接続を介したデータベースへのアクセス。デフォルトでは、サービスは暗号化されたチャネルを通じて利用可能で、デフォルトで構成済のOracle Netクライアントは暗号化されたセッションを使用します。
  • Exadata MS Webインタフェース(https)を介した診断へのアクセス。
• 監査とロギング
  • デフォルトでは、監査が管理操作に対して有効になっており、それらの監査レコードは、必要に応じて自動レビューおよびアラートを行うためにOCI内部システムに通知されます。

Exadata Cloud Infrastructureのコンポーネントは、複数のユーザー・アカウントで定期的に管理されます。これらのユーザーは必須であり、変更できません。

すべてのExaDB-Dマシンで、OracleはトークンベースのSSHログインを使用および推奨します。

次の3つのユーザーのクラスがあります:

• デフォルト・ユーザー: ログオン権限なし
  
• シェル・アクセスが制限されたデフォルト・ユーザー
  これらのユーザーは、制限されたシェル・ログインを使用して定義済タスクを実行するために使用されます。これらのユーザーは削除すると定義済タスクが失敗するため、削除できません。
• ログイン権限を持つデフォルト・ユーザー
  これらの特権ユーザーは、システム内のほとんどのタスクを実行するために使用されます。これらのユーザーは、実行中のシステムに重大な影響を与える可能性があるため、絶対に変更または削除しないでください。

Oracle Exadata Database Machineのセキュリティ機能で説明されているすべてのExadata機能に加えて、次のセキュリティ設定もExadata Cloud Infrastructureインスタンスに適用されます。

• デフォルト以外のパラメータを使用したカスタム・データベース・デプロイメント。
  コマンドhost_access_controlでは、Exadataセキュリティ設定を構成します:

  • パスワードのエージングおよび複雑性ポリシーを実装します。
  • アカウントのロックアウトおよびセッション・タイムアウト・ポリシーを定義します。
  • リモートのrootアクセスを制限します。
  • 特定のアカウントへのネットワーク・アクセスを制限します。
  • ログイン警告バナーを実装します。
• account-disable: 特定の構成済条件が満たされた場合にユーザー・アカウントを無効にします。
• pam-auth: パスワード変更およびパスワード認証のための様々なPAM設定。
• rootssh: /etc/ssh/sshd_configのPermitRootLogin値を調整して、rootユーザーがSSHを介してログインすることを許可または拒否します。
  • デフォルトでは、PermitRootLoginはnoに設定されます。
  • クラウド自動化で一部のライフサイクル管理操作を実行するには、PermitRootLogin=without-passwordが必要です。rootログインを無効にすると、そのサービス機能が失敗します。
• session-limit: /etc/security/limits.confの* hard maxloginsパラメータ(すべてのユーザーの最大ログイン数)を設定します。この制限は、uid=0のユーザーには適用されません。

  デフォルトは* hard maxlogins 10で、これは推奨されるセキュアな値です。

• ssh-macs: 使用可能なメッセージ認証コード(MAC)アルゴリズムを指定します。
  • MACアルゴリズムは、プロトコル・バージョン2でデータ整合性保護のために使用されます。
  • サーバーとクライアントの両方で、デフォルトはhmac-sha1、hmac-sha2-256、hmac-sha2-512です。
  • 推奨されるセキュアな値: サーバーとクライアントの両方でhmac-sha2-256、hmac-sha2-512です。
• password-aging: 対話型ユーザー・アカウントの現在のパスワード・エージングを設定または表示します。
  • -M: パスワードを使用できる最大日数。
  • -m: パスワード変更の間隔として許容される最小日数。
  • -W: パスワードの期限が切れる前に警告が表示される日数。
  • デフォルトは-M 99999、-m 0、-W 7です
  • --strict_compliance_only-M 60、-m 1、-W 7
  • 推奨されるセキュアな値: -M 60、-m 1、-W 7

顧客VM(DOMU、ゲストVMおよびゲストOSとも呼ばれる)でデフォルトで実行されるプロセスのリスト

• Exadata Cloud Infrastructure VMエージェント:

  データベース・ライフサイクル操作を処理するためのクラウド・エージェント。

  • opcユーザーとして実行します
  • プロセス表は、jar名(dbcs-agent-VersionNumber-SNAPSHOT.jarおよびdbcs-admin-VersionNumver-SNAPSHOT.jar)を持つJavaプロセスとして実行されていることを示しています。
• Oracle Trace File Analyzerエージェント:

  Oracle Trace File Analyzer (TFA)では、単一のバンドルに多数の診断ツールが提供されるため、Oracleデータベースおよびクラスタウェアに関する診断情報を収集しやすくなり、Oracle Supportの処理時に問題の解決に役立ちます。

  • rootユーザーとして実行します
  • initdデモンとして実行されます(/etc/init.d/init.tfa)。
  • プロセス表にはJavaアプリケーション(oracle.rat.tfa.TFAMain)が表示されます
  • rootおよびexawatchユーザーとして実行します。
  • バックグラウンド・スクリプトExaWatcher.shとして実行します。そのすべての子プロセスはPerlプロセスとして実行されます。
  • プロセス表には、複数のPerlアプリケーションとして示されます。ExaWatcher:
• データベースおよびGI(クラスタウェア):
  • dbmsvcおよびgridユーザーとして実行します
  • プロセス表には、次のアプリケーションが示されます:
    • gridユーザーとしてoraagent.bin、apx_*およびams_*
    • dbrsMainおよびJavaアプリケーション- oracleユーザーとしてderbyclient.jar、weblogic.Server。
• 管理サーバー(MS):

  イメージ機能を管理および監視するためのExadataイメージ・ソフトウェアの一部。

  • dbmadminとして実行します。
  • プロセス表には、Javaプロセスとして実行されていることが示されます。

• ゲストVMのネットワーク・セキュリティ
  
• コンプライアンス要件
  

有効で、使用されているデフォルトのデータベース・セキュリティ機能:

• 透過的データベース暗号化(TDE)は、Oracle Database Cloudツールによって作成されたデータベース表領域に使用されます。
  • CDB$ROOT: ユーザー表領域が暗号化されます
  • PDB: すべての表領域が暗号化されます
  • ウォレット・パスワードは、初期DB作成時に指定されます。Walletパスワードは、dbaascliを使用して変更できます。顧客は、このパスワードを定期的に変更する必要があります。
• データベース内のユーザー
  • データベースに追加のユーザーは作成されません。
  • DBの作成後、SYS、SYSTEMおよびDBSNMPを除くすべてのDBユーザーがロックされます。
  • 監査は、次の操作に対して有効です:
    • DATABASE LINK
    • PUBLIC DATABASE LINK
    • PUBLIC SYNONYM
    • DROP ANY PROCEDURE
    • PROCEDURE
    • ALTER SYSTEM
    • TRIGGER
    • CREATE DATABASE LINK
    • ALTER DATABASE LINK
    • CREATE PROCEDURE
    • ALTER SYSTEM
    • CREATE TRIGGER
    • CREATE ANY TRIGGER
    • SELECT ANY DICTIONARY
    • DB VERSION_11_2: EXEMPT REDACTION POLICY
    • DB VERSION_12_1またはDB VERSION_12_2: BECOME USER
    • DB VERSION_12_1: SESSION
    • DBAASSECUREプロファイルが作成され、データベース・ユーザー・アカウントのデフォルト・プロファイルとして設定されます。

• すべてのネットワーク接続に対するネイティブSQL*Net暗号化- Exadata Cloud Infrastructureでデフォルトで設定される関連するsqlnet.oraパラメータは次のとおりです:

  • SQLNET.ENCRYPTION_TYPES_SERVER = (AES256, AES192, AES128)

  • SQLNET.ENCRYPTION_SERVER = requested

  • SQLNET.CRYPTO_CHECKSUM_SERVER = accepted

  • SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (SHA256, SHA384, SHA512)

• TCPSプロトコルは、ポート2484でのデータベースへのネットワーク接続用に提供されます(/var/opt/oracle/dbaas_acfs/grid/tcps_walletsで構成されたウォレット)。Exadata Cloud Infrastructureでデフォルトで設定される関連するsqlnet.oraパラメータは、次のとおりです:

  • SSL_CIPHER_SUITES = (SSL_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, 
    SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 
    SSL_ECDHE_RSA_WITH_AES_256_GCM_SHA384)

  • WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets)))

  • SQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPS = TRUE

  • SSL_VERSION = 1.2

• リモート・リスナー登録 - リスナーはGIホームから実行されます。Exadata Cloud Infrastructureデプロイメントでは、Oracle Supportドキュメント2333222.1 (Exadata Cloud Serviceソフトウェア・バージョン)で指定されたGrid Infrastructureバージョンが使用されます。Exadata Cloud Infrastructureのデフォルト構成には、listener.oraパラメータVALID_NODE_CHECKING_REGISTRATION_LISTENER=SUBNETとREMOTE_REGISTRATION_ADDRESS_<SCANLISTENER>=<value>の組合せが含まれ、セキュリティ目的でリモート・リスナー登録を制限します。
• OCI Vault統合 - TDE暗号化キーはOCI Vault(キー管理システム)に格納できます。プリンシパル、ボールトなどを構成する詳細および手順は、Exadata Cloud Infrastructureの顧客管理キーを参照してください。Exadata Cloud Infrastructure OCI Vault統合では、プライベート・ボールト・タイプと共有ボールト・タイプの両方がサポートされています。DBユーザー認証はOCI Vaultと統合されていません。

OS/VMバックアップ:

Oracleは、ゲストVMのフル・バックアップを毎週実行し、1つ以上のバックアップ・コピーを保持します。これらのバックアップは、ゲストVM (Exadataストレージに存在するASMディスク・グループではなく、ローカルOSファイルシステム)の完全なディスク・スナップショットです。このバックアップは、毎週事前設定された時間にトリガーされます。バックアップはdom0にローカルに格納されます。顧客は、My Oracle Support (MOS)サービス・リクエスト(SR)を申請することで、最新のバックアップからゲストVMイメージをリストアするようにOracleにリクエストできます。Oracleは、イメージ・バックアップから特定のファイルをリストアできません。単一ファイル・リストアを実行する必要がある場合、顧客はゲストVMでファイル・レベルのバックアップを実行する必要があります。

管理されたDBバックアップ:

• 週次フル・バックアップ(レベル0)
• 7日サイクルでの日次ローリング増分バックアップ(レベル1)
• データベース・デプロイメントの作成プロセスで設定された特定の時間に毎日行われる自動バックアップ。

バックアップの保持期間は、30日(オブジェクト・ストレージの場合)から7日(ローカル・ストレージの場合)まで異なります

暗号化:

• オブジェクト・ストレージとローカル・ストレージの両方: クラウド・ストレージへのバックアップはすべて暗号化されます。
• オブジェクト・ストレージのみ: クラウド・ストレージへのバックアップはすべて暗号化されます。

すべてのバックアップは、CP UIまたはCP APIを介して構成できます。

すべてのバックアップは、Transparent Data Encryption (TDE)ウォレット暗号化に使用されたものと同じマスター・キーで暗号化されます。

ライフサイクルの自動化のために、自動化されたツールのみがゲストVMにアクセスすることが許可されています。

具体的な使用例としては、ゲストVMが起動できない場合があります。この場合、顧客はリカバリ目的でゲストVMにアクセスする権限を与える必要があります。このシナリオを処理するための詳細は、Exadata Cloud Serviceのセキュリティ制御の「例外ワークフロー」を参照してください。

顧客は、ゲストVMへのネットワーク・アクセス(ゲストVMに実装されているレイヤー2 VLANおよびファイアウォール経由)、ゲストVMにアクセスするための認証、ゲストVMで実行されているデータベースにアクセスするための認証など、顧客サービスへのアクセスを制御およびモニターします。Oracleは、Oracle管理インフラストラクチャ・コンポーネントへのアクセスを制御およびモニターします。Oracleスタッフは、ゲストVMやデータベースなどの顧客サービスへのアクセスを許可されていません。

PII(個人識別可能情報)この情報は、機密情報とみなされ、法的規制、金銭的責任および個人の評判の目的で個人情報が許可なく使用されないように保護する必要があります。

個人識別可能情報(PII)がデータに表示されないようにするために、明示的なルールのセットを構成する必要があります。

デフォルトのApplication Performance Monitoringルールでは、金額、銀行口座番号および日付が認識されて、URLのPIIが非表示になります。ただし、デフォルト・ルールで取得されるのは明らかなPIIのみで、すべてが網羅されるわけではありません。環境内で正しいレポートが確実に行われ、PIIがデータに表示されないようにするには、デフォルト・ルールを評価し、さらにルールを構成する必要があります。

詳細は、「個人を識別可能な情報の非表示」および「セキュリティおよび個人を識別可能な情報」を参照してください

バックアップの保存

自動バックアップ機能を有効にすると、データベースの増分バックアップがサービスによって毎日オブジェクト・ストレージに作成されます。作成される最初のバックアップは、レベル0のバックアップです。その後、レベル1のバックアップが、次の週末まで毎日作成されます。週末ごとに新しいレベル0のバックアップから始まるサイクルが繰り返されます。

自動バックアップの有効化を選択した場合は、事前設定された保持期間(7日、15日、30日、45日または60日)のいずれかを選択できます。増分バックアップは、選択した保持期間が終了すると自動的に削除されます。

詳細は、Oracle Exadata Database Service on Dedicated Infrastructureでのデータベースのバックアップおよびリカバリの管理を参照してください

監査ログ保持期間

OCI監査サービスは、サポートされるサービスに対して実行されるAPI操作の記録をログ・イベントのリストとして提供します。デフォルトでは、監査サービスの記録は365日間保持されます。

詳細は、監査ログ保持期間を参照してください

サービス・ログの保持

APIゲートウェイ、イベント、ファンクション、ロード・バランシング、オブジェクト・ストレージ、VCNフロー・ログなどのOracle Cloud Infrastructureサービスは、サービス・ログを出力します。これらのサポートされる各サービスには、そのサービスのロギングを有効または無効にできるログ・リソースがあります。デフォルトでは、ログの保持は1か月ですが、6か月まで設定できます。

ログ・グループを使用すると、IAMポリシーを使用してサービスによって生成される機密ログへのアクセスを制限できます。ログを保護するために複雑なコンパートメント階層に依存する必要はありません。たとえば、1つのコンパートメントのデフォルト・ログ・グループが、テナンシ全体のログを格納する場所であるとします。通常の場合と同様に、IAMポリシーでログ管理者にコンパートメントへのアクセス権を付与します。ただし、一部のプロジェクトには個人を特定できる情報(PII)が含まれており、これらのログは選択したログ管理者グループのみが表示できるとします。ログ・グループを使用すると、PIIを含むログを個別のログ・グループに配置し、IAMポリシーを使用して、少数のログ管理者以外のすべてのユーザーに対してアクセスを制限できます。

詳細は、サービス・ログおよびログおよびログ・グループの管理を参照してください

一部の問題は、Oracleが顧客のゲストVMにログインすることによってのみ解決できる場合があります。

顧客のゲストVMにアクセスする必要がある状況と、ゲストVMにアクセスするための推奨手順を次に示します:

1. スタータ・データベースがまだ作成されておらず、顧客がゲストVMにSSHアクセスできない状況。例としては、スタータ・データベースを作成できない原因をトラブルシューティングするために顧客が開いたSRがあります。この場合、顧客はゲストVMにアクセスできず、まだデータベースが作成されていないため、ゲストVMに顧客データは存在しません。

   ExaDB-Dサービスに関連付けられたセキュリティ・ポリシーに従って、Oracleの担当者は、顧客の明示的な許可なしに顧客のゲストVMにアクセスすることを禁止されています。このポリシーに従うために、オラクルは次の質問をしてゲストVMにアクセスする許可を顧客から得る必要があります。

   「Oracle がこのSRに記載されている問題を解決するためには、顧客のゲストVMにログインすることを許可する顧客の明示的な許可が必要です。ゲストVMへのアクセスを明示的に許可することにより、顧客は、顧客のゲストVMまたは関連データベースに格納されている機密データがないことを確認し、顧客のセキュリティ・チームが、Oracleがこの問題の解決を支援するために顧客のゲストVMにアクセスすることを許可することになります。ゲストVMへのアクセスを明示的に許可しますか。」

   顧客から肯定的な回答が得られたら、Oracleサポート・スタッフは顧客のゲストVMにログインして問題を解決できます。

2. 顧客のシステムに多数のデータベースが存在し、顧客はゲストVMにアクセスできるが、サポートがゲストVMにログインして多くの状況を解決する必要がある状況

   発生しました(たとえば、ゲストVMが変更されたため、ノードが起動しません)。fstabに存在しないマウント、fsckを実行する必要がある、Hugepage / sysctl confの変更またはlvmバックアップが正常に完了しない、fstabに存在しないマウントの間違ったエントリがある、顧客が/etc/ssh/sshd_configファイルでsshd構成または権限を変更したなど。あるいは、単に顧客が直面している問題の解決をOracleが支援することを望む場合です。

   このケースは、顧客のゲストVMファイル・システムまたはデータベースに機密データが存在する可能性があるため、最初のケースよりも深刻です。この場合、Oracleのサポート・スタッフは、この許可を得るために、次のようなSRのタイトルと内容で、特別に新しい明示的なSRを開くように顧客に要求する必要があります。

   ExaDB-Dサービスに関連付けられたセキュリティ・ポリシーに従って、Oracleの担当者は、顧客の明示的な許可なしに顧客のゲストVMにアクセスすることを禁止されています。Oracleがこのポリシーに準拠するためには、OracleにゲストVMへのアクセスを明示的に許可する次に示す文言で新規SRを作成するよう顧客に依頼する必要があります。次の文言を変更した場合、SRの解決に時間がかかることがありますのでご注意ください。

   新規SRのタイトル: SR granting Oracle explicit permission to access DomU of ExaDB-C@C with AK serial number AK99999999

   新規SRの内容: We are opening this SR to grant explicit permission to Oracle to access our DomU in order for support to help resolve issue described in SR# 1-xxxxxxxx.

   We acknowledge that by providing this permission, we understand that Oracle will have access to ALL FILES in DomU and agree that there are no confidential

   files stored in any of the file systems in DomU.In addition, we also agree that customer security team has authorized Oracle to have access to customer DomU

   in order to resolve the issue described in the above SR.

   前述のSRで顧客から肯定的な回答が得られたら、Oracleサポート・スタッフは顧客のゲストVMにログインして問題を解決できます。

コンポーネント別の様々な操作に対するOracle Cloud Operationsの責任と顧客の責任のリスト

• KMS統合(HSMキー)
  
• TDE表領域暗号化に対するデフォルト以外の暗号化アルゴリズムの使用