Oracle Operator Access Controlの概要
Oracle Operator Access Controlを使用して、インフラストラクチャに対するOracleサービス・スタッフのアクセスの制御、監査および取消を行う方法について学習します。
- Oracle Operator Access Controlとは
Oracle Operator Access Controlを使用すると、Exadataインフラストラクチャ、Oracle Autonomous DatabaseをExadata Cloud@Customer上でホストするExadataインフラストラクチャ、およびOracleによって管理されるAutonomous Exadata VMクラスタ(Exadata Cloud@Customer上のOracle Autonomous Databaseにデプロイされたクライアント仮想マシン)に対する、Oracleのアクセス権の付与、監査および取消を行うことができます。また、ヒューマン・オペレータが行ったすべてのアクションの監査レポートをほぼリアルタイムで取得できるようになります。 - オペレータ・アクセス・コントロールに関連する用語
オペレータ・アクセス・コントロールでどのような用語が使用されるかを学習します。 - Oracle Operator Access Controlによって提供されるコントロール・オプション
オペレータがインフラストラクチャに対して実行できるアクションのセットを指定するポリシーを作成します。 - オペレータ・アクセス・コントロールでのアクションの適用
オペレータ・アクセス・コントロールが環境で実行できる操作に対する制御の適用について学習します。 - オペレータ・アクセス・コントロールの制限
オペレータ・アクセス・コントロールは、汎用のコンプライアンス・ソリューションではなく、Oracleアクセスの監査およびコンプライアンスのために設計されたソリューションです。 - オペレータ・アクセス・コントロールの顧客テナンシ・ジョブ・ロール
オペレータ・アクセス・コントロールを確立するには、アクセス・コントロール・ポリシーを設定し、インフラストラクチャに対するアクセスの管理とモニターを担当するユーザー・グループを確立します。 - オペレータ・アクセス・コントロール監査ログのSIEMシステムへの転送
オペレータ・アクセス・コントロール監査ログを、Exadata Cloud@Customerからデータ・センター内のセキュリティ情報イベント管理(SIEM)システムに直接転送するように選択できます。
Oracle Operator Access Controlとは
Oracle Operator Access Controlを使用すると、Exadataインフラストラクチャ、Oracle Autonomous DatabaseをExadata Cloud@Customer上でホストするExadataインフラストラクチャ、およびOracleによって管理されるAutonomous Exadata VMクラスタ(Exadata Cloud@Customer上のOracle Autonomous Databaseにデプロイされたクライアント仮想マシン)に対する、Oracleのアクセス権の付与、監査および取消を行うことができます。また、ヒューマン・オペレータが行ったすべてのアクションの監査レポートをほぼリアルタイムで取得できるようになります。
Exadata Cloud@Customer向けのOracle Operator Access Control
- お客様は、仮想マシンにおけるアクションと、仮想マシンで実行されるデータベースおよびアプリケーションの日常的な管理に責任を持ちます。
- Oracleは、インフラストラクチャ・コンポーネント(電源、ベアメタル・オペレーティング・システム、ハイパーバイザ、Exadataストレージ・サーバー、およびインフラストラクチャ環境のその他の側面)に責任を持ちます。
ただし、システム管理のすべての側面を監査および管理するという規制要件がある場合、共同責任モデルには問題があります。規制当局に対して、お客様がシステムを全面的に制御していること、それらのコンプライアンス規制に準拠してシステムを運用していることを証明する必要があります。
システムの任意のオペレータまたは任意のソフトウェアによって、インフラストラクチャ・コンポーネントに対して実行されるすべてのアクションを制御および監査するにはどうすればよいでしょうか。システムに対して同じレベルの監査およびアクセス制御を維持し、システム全体について内部または外部の規制監査に必要な監査レコードを用意するには、どうすればよいでしょうか。この問題を解決するために、Oracleオペレータによるシステムへの自由なアクセスを抑制するソリューションとしてOracle Operator Access Controlが提供されます。
Exadata Cloud@Customer上のOracle Autonomous Database向けのオペレータ・アクセス・コントロール
オペレータ・アクセス・コントロールが拡張され、Exadata Cloud@Customer上のOracle Autonomous Databaseにデプロイされたクライアント仮想マシンの制御が提供されるようになりました。Exadata Cloud@Customerインフラストラクチャのオペレータ・アクセス・コントロールと同様に、お客様が、Exadata Cloud@CustomerにデプロイされたAutonomous Virtual MachineクラスタにOracle Operator Access Controlを適用できるようになりました。
- Autonomous Databaseリソースのプロビジョニング
- データベースのバックアップ
- データベースのリカバリ
- パッチ適用およびアップグレード
- スケーリング
- サービス・ヘルスのモニター
- 監査
- アラートおよび通知
お客様には、クライアント・オペレーティング・システムへのアクセス権、コンテナ・データベースへのsys/systemアクセス権、またはシステム・ログへのアクセス権はありません。また、お客様によるモニターは、アプリケーションのヘルスとパフォーマンス、すべてのレベルでのアプリケーションのセキュリティに限定されています。一方、管理者であるOracleオペレータには、ハイパーバイザおよびクライアントVMへのrootアクセス権を含め、すべてのコンポーネントに対する完全な制限なしのアクセス権があります。
自律型データベースの責任共有モデルは、ベンダーやデプロイメント・モデル(オンプレミス、ホスト、クラウド)に関係なく、すべてのデータとインフラストラクチャの管理を維持する必要がある規制対象顧客に対して、いくつかの運用上の課題をもたらします。規制対象顧客は、自社のコンプライアンスを精査し、セキュリティ・ガイドラインを策定します。このガイドラインは、強化と実施に数年かかる場合があります。
これは、厳しい規制を受けて、最もクリティカルなシステムやセキュリティの重要性が最も高いアプリケーションをOracle上で実行している、オラクル社のエンタープライズ顧客にまさに該当します。この問題を解決するために、Oracleオペレータによるシステムへの自由なアクセスを抑制するソリューションとしてOracle Operator Access Controlが提供されます。
Oracle Cloud Infrastructure向けのOracle Operator Access Control
Oracle Operator Access Controlは、Oracleオペレータがインフラストラクチャ上で実行するすべてのアクションについて徹底的な管理と監査証跡を維持できるようにするコンプライアンス監査システムです。
- インフラストラクチャへのアクセス権を付与します(誰がインフラストラクチャにアクセスできるか、いつシステムにアクセスできるか、Oracle担当者がシステムにアクセスできる期間など)。
- Oracleオペレータがシステム上で実行するすべてのアクションのほぼリアルタイムのレポートを表示して保存します。
- アクセスを制限します(Oracleオペレータがシステム上で実行できるアクションの制限など)。
- アクセス権を取り消します(以前に付与したアクセス権など)。
Compute Cloud@Customer向けのオペレータ・アクセス制御
Compute Cloud@Customerインフラストラクチャは、お客様がインフラストラクチャ上で作成および実行するVMとサービスの「ユーザー」であり、Oracleがインフラストラクチャ自体の「マネージャ」であるという原則に基づいています。管理とは、インフラストラクチャ・コンポーネントのアップグレード、パッチ適用、監視などの一般的なタスクを意味します。
顧客は、インフラストラクチャ・コンポーネント上のインフラストラクチャ仮想またはベアメタルOSインスタンス、またはこれらのインスタンス上で実行される管理ソフトウェアにはアクセスできません。一方、Oracle Opsはマネージャであり、ハイパーバイザやコントロール・プレーン・サーバーへのルート・アクセスなど、すべてのコンポーネントへの完全で制約のないアクセスが可能です。
このモデルは、ベンダーやデプロイメント・モデル(オンプレミス、ホスト、クラウド)に関係なく、すべてのデータとインフラストラクチャの制御を維持する必要がある規制対象顧客に対して、いくつかの運用上の課題を提起します。規制対象顧客は、自社のコンプライアンスの精査を受け、強化と実施に何年もかかる可能性のある独自のセキュリティ・ガイドラインを策定します。これは、厳しい規制を受けて、最もクリティカルなシステムやセキュリティの重要性が最も高いアプリケーションをOracle上で実行している、オラクル社のエンタープライズ顧客にまさに該当します。
オペレータ・アクセス・コントロールは、これらの顧客コンプライアンス目標をサポートするように拡張されており、ミッションクリティカルなデータベースをOracle Cloudに持ち込み、最終的にはお客様が専用システムへのアクセスを制御できるようになっています。
オペレータ・アクセス・コントロールに関連する用語
オペレータ・アクセス・コントロールでどのような用語が使用されるかを学習します。
オペレータ: Oracle Cloud Infrastructure (OCI)のオペレータ・グループ(Ops)テナンシのメンバーであるOracle従業員。たとえば、Exadata Cloud@Customer_opsグループまたはExaCS_opsグループのOracle従業員がオペレータであることがあります。Opsグループ・テナンシは、操作制御の管理が許可されているOCI内のテナンシのセットです。Opsグループおよび、これらのグループのメンバーであるオペレータには、インフラストラクチャへのアクセスをリクエストできる以外にデフォルトの権限はありません。オペレータ・グループのグループとメンバーシップは、Oracleによって厳しく制御されます。
ユーザー: テナンシのOCIユーザー。このユーザーのExadata Cloud@Customerシステム上にコントロールが配置されます。
Exadataインフラストラクチャ・レイヤー: Exadataシステムの複数の物理レイヤーまたはオペレーティング・システム・レイヤー。現在、コントロール・プレーン・サーバー、ホスト、ゲストVM、セル・サーバー、スイッチおよびILOMとして定義されています。
アクション: 指定されたレイヤー上でアクセスできる、コマンド、ファイルまたはネットワークの名前付き定義済みセット。Oracleによってアクションが定義されます。
オペレータ・コントロール: 顧客定義のエンティティ。これには、事前承認済のアクションと、アクセスを許可するために承認グループからの明示的な承認を必要とするアクションのグループが含まれます。承認者グループは、アクセスの承認または取消の限を持つユーザーのセットがリストされている、標準のIAMユーザー・グループです。
オペレータの属性: 場合によっては、オペレータ・コントロールによって、インフラストラクチャへのアクセスが許可されるオペレータの基準を定義できます。
オペレータ・コントロールの割当て: これは、Exadata Cloud@Customerシステムが指定されたオペレータ・コントロールにアタッチされるプロセスです。任意の時点で、1つのオペレータ・コントロールのみExadata Cloud@Customerシステムに適用できます。割当ては、永続的にすることも特定の期間を対象とすることもできます。オペレータ・コントロールがExadata Cloud@Customerシステムに割り当てられない場合、Exadata Cloud@Customerシステムは、診断およびメンテナンスに必要なすべてのアクセスを許可するデフォルトのオペレータ・コントロールを使用して実行されます。
アクセス・リクエスト: アクセス・リクエストは、オペレータが、指定したExadataインフラストラクチャへのアクセス権限をリクエストするプロセスです。ExadataインフラストラクチャはOCIDによって指定されます。リクエストでは、オペレータが必要とするアクションが指定されます。
アクセス・リクエストの承認/却下: アクセスの承認/却下は、Exadataインフラストラクチャにデプロイされたオペレータ・コントロールによって適格と判別されたユーザーが、アクセス・リクエストを付与または拒否できるプロセスです。
アクセス・リクエストの取消: 適格なユーザーは、任意の時点でアクセス・リクエストを取り消すことができます。この場合、このアクセス・リクエストに基づいてExadataインフラストラクチャに接続されたオペレータのセッションがすぐに削除されます。
確認中のアクセス・リクエスト: 送信済のOracleオペレータ・アクセス・リクエストを認識し、アクセス・リクエストが確認中であることをリクエスト元に知らせます。
Oracle Operator Access Controlによって提供されるコントロール・オプション
オペレータがインフラストラクチャに対して実行できるアクションのセットを指定するポリシーを作成します。
アクションは、Oracleによって管理されるインフラストラクチャ上でOracleオペレータに許可される操作を制約するものです。このような制約には、オペレーティング・システム・シェル・コマンドの実行やOracleスクリプトの実行に対する制御が含まれます。また、アクションによって、アクションによって定義された機能の範囲を超えるバイナリ、シェル・スクリプト、PerlまたはPythonスクリプトをOracleオペレータが実行することも制約されます。アクションを介して権限を付与すると、Oracleオペレータが実行するすべてのアクションがログに記録されます。MAC制約要件ポリシーの一部として、ログを監査できます。
ポリシーは、システムでのOracleオペレータによるメンテナンスの実行に対して、MAC (mandatory access control)制約を実装するために指定するアクションのセットです。ポリシーを定義するために、アクションを介して適用できる特定のアクセス・コントロールのリストを次に示します:
- Oracleオペレータを管理するためのオペレータ・コントロールを構成します:
- テナンシ内の特定のリソース・タイプのアクセス・プロファイルを制限するオペレータ・コントロール。たとえば、仮想マシン(VM)、Oracle Infrastructureデータベース・サーバー、コントロール・プレーン・サーバー、InfiniBandネットワークなどのリソースに対して個別のポリシーを設定できます。また、テナンシ内のリソース・グループにアクセス・コントロールを関連付けるようにポリシーを構成できます。
- 各オペレータ・コントロールに関連付けられたユーザーの管理者グループを構成します。これらのグループのメンバーは、オペレータ・コントロールをデプロイしたリソースに対するアクセス・リクエストを承認、変更または却下できます。
- リソースにアクセスするためのアクションを事前承認済として定義して構成します。アクセスを制御する管理ユーザーのグループを構成する必要はありません。
- リソースへのアクセスを許可する前に、必須リクエスト認可を指定します。例:
- アクションのセットが事前承認済としてマークされると、そのようなアクションのサブセットのみを指定するアクセス・リクエストは自動的に承認され、Oracleスタッフはインフラストラクチャ・コンポーネントにアクセスできます。
- アクセス・ポリシーが事前承認済に設定されないと、アクセス・リクエストを明示的に付与するまで、Oracleスタッフはコンパートメントへのアクセスを拒否されます。
- 以前に付与したインフラストラクチャへのアクセスを取り消します。
- 自動時間制限によって、リソースに付与したアクセス権が取り消されます。アクセス・リクエストが許可されると、Oracleオペレータには、限られた時間のアクセス権を付与する一意のユーザーIDが与えられます。その期限に達すると、承認されたアクセス・リクエストに関連するシステムへのすべてのOracleアクセスは取り消されます。さらに時間が必要な場合は、Oracleオペレータが延長リクエストを発行できます。
- 以前に付与したアクセス権が期限切れになる前に、すでにリソースに付与されていたアクセス権を手動で取り消します。
- ヒューマン・オペレータがリソースに対して実行するすべてのアクションを監査します:
-
ヒューマン・オペレータによるすべてのキーボード入力とコマンド実行が監査されます。すべてのLinux監査ログに全面的にアクセスできます。
システムの特定のOracleヒューマン・オペレータの監査をリクエストできます。
ノート
ヒューマン・オペレータのアイデンティティはOracleのお客様には明らかになりません。ただし、Oracle Operator Access Controlシステムによってオペレータのサービス・レコードが保持されるため、Oracleでは、テナンシ上のサービスに対して付与した特定のアクセス・リクエストとヒューマン・オペレータを関連付けることができます。悪意のあるアクションが疑われ、監査が必要な場合は、Oracleはそのリクエストを使用して、アクセス・リクエストによって許可されるアクションを実行する特定のヒューマン・オペレータのすべてのアクションを確認できます。
-
オペレータ・アクセス・コントロールでのアクションの適用
Oracleオペレータが環境で実行できる操作に対する制御の適用について学習します。
- アクションの適用とは
オペレータ・アクセス・コントロールのアクションによって、コマンドの実行、リソースへのアクセス、システムの状態の変更に関してオペレータの権限が制限されます。 - オペレータ・アクセス制御アクション: Exadataインフラストラクチャ
アクションは、ホスト、セル・サーバーおよびコントロール・プレーン・サーバーに限定されたExadata Cloud@Customerインフラストラクチャでオペレータが実行できる操作を定義します。 - オペレータ・アクセス制御アクション: Autonomous VM Cluster
フル・システム・アクセス以外に、制限付きアクセス・ケージの診断および保守を使用して、ログを表示し、サービス関連のタスクを実行します。 - オペレータ・アクセス制御アクション: Compute Cloud@Customer
認可されたオペレータは、Compute Cloud@Customerのアップグレード、トラブルシューティングまたは問題の解決に役立つリソースにアクセスする必要がある場合があります。
アクションの適用とは
オペレータ・アクセス・コントロールのアクションによって、コマンドの実行、リソースへのアクセス、システムの状態の変更に関してオペレータの権限が制限されます。
アクションによって定義される権限、リソース、システム変更アクセスがOracleオペレータに付与されて、オペレータ・アクセス・コントロールを使用して管理されるExadataインフラストラクチャ上で、特定の管理機能に関する所定範囲のタスクを実行できるようになります。アクションによって許可されるコマンドは、Oracle Linuxコマンドまたはセル・サーバー・コマンドです。
アクションによってアクセス権が付与されるリソースは、ファイルおよびネットワークです。システム変更は、オペレーティング・システムの状態変更、またはそれらのシステムで実行されているソフトウェアの状態変更に対応します。状態変更とは、再起動または構成変更の結果です。
アクションの適用は、承認済のアクセス・リクエストに基づきます。これによって、Oracleオペレータに認められたアクションのセットで定義されているように、オペレータによって実装できるようにする変更の時間制限ポリシーが設定されます。すべてのアクセス・リクエストにより、Exadataインフラストラクチャの一時ユーザー資格証明が作成されます。定義するアクセスのポリシーは、アクセス・リクエストで承認するアクションに基づいており、作成された一時ユーザーにアタッチされます。
通常、アクションの適用はオペレーティング・システムの機能です。オペレーティング・システムのインスタンス(すべてのホスト、セル・サーバー、コントロール・プレーン・サーバーなど)に対して、アクション適用ポリシーが作成されます。ポリシー付きで付与されたアクションは、アクセス・リクエストがクローズしたため、または管理タスクが完了、取消または期限切れになったために、アクセス・リクエストが無効になると削除されます。
アクションは、異なるインフラストラクチャ(オペレーティング・システムなど)や他のソフトウェア(cellcliなど)に適用することができます。
親トピック: オペレータ・アクセス・コントロールでのアクションの適用
オペレータ・アクセス・コントロールのアクション: Exadataインフラストラクチャ
アクションによって、オペレータがExadata Cloud@Customerインフラストラクチャ(ホスト、セル・サーバー、コントロール・サーバーに限定)で実行できる操作が定義されます。
アクションは、Exadata Cloud@Customerインフラストラクチャ全体に適用されます。アクションによって、Exadata Cloud@Customerの複数のレイヤーでのOracleオペレータ・アクションが制御されます。現在のバージョンで制御されるレイヤーは、セル・サーバー、管理ドメイン(ホスト)およびコントロール・プレーン・サーバーです。アクションは要件によって編成されるため、アクションのリクエストと、これらのアクションが生成する可能性のある重大な影響が発生します。
アクションによって、ターゲットのExadata Cloud@Customerシステム上でOracle Linux権限が変換されます。権限は、ファイル・システム権限、コマンド実行権限、およびsuまたはsudo権限に分類されます。アクションは、オペレータがExadata Cloud@Customerシステム上で実現できる変更の性質によって分類されます。
- 処置: コントロール・プレーン・サーバー(CPS)のみ
INFRA_CPS_ONLYとして識別されるコントロール・プレーン・サーバー(CPS)のみ、CPSの問題の診断および解決にのみ使用されます。Oracleスタッフは、セル・サーバーやホスト・オペレーティング・システム(Dom0)など、CPS以外のコンポーネントにはアクセスできません。 - アクション: システム診断
INFRA_DIAGで指定されるシステム診断は、Exadata Cloud@Customerインフラストラクチャ・レイヤーの問題の診断での使用を目的としています。 - アクション: 再起動権限付きのシステム・メンテナンス
INFRA_UPDATE_RESTARTで指定される再起動権限付きのシステム・メンテナンスは、システム構成の変更すなわちシステムの再起動を必要とするオペレータ・アクセス・シナリオでの使用を目的としています。 - アクション: データ・アクセス/VM制御権限付きシステム・メンテナンス
INFRA_HYPERVISORで指定されるデータ・アクセス/VM制御権限付きシステム・メンテナンスは、ホスト上のVM管理が必要な診断およびメンテナンス・シナリオでの使用を意図しています。 - アクション: フル・システム・アクセス
INFRA_FULLとして指定されるフル・システム・アクセスでは、インフラストラクチャ・コンポーネントのルート・アカウントへのアクセスが許可されます。
親トピック: オペレータ・アクセス・コントロールでのアクションの適用
アクション: コントロール・プレーン・サーバー(CPS)のみ
INFRA_CPS_ONLYとして識別されるコントロール・プレーン・サーバー(CPS)のみは、CPSの問題の診断および解決にのみ使用されます。Oracleスタッフは、セル・サーバーやホスト・オペレーティング・システム(Dom0)など、CPS以外のコンポーネントにはアクセスできません。
表1-1 INFRA_CPS_ONLYで有効化されるアクション
| アクション名 |
コントロール・プレーン・サーバー(CPS)のみ |
| 処理識別子 |
|
| オペレータ権限 |
Linuxユーザー権限: 非root suで chroot jail: はい suによる切替え可能: なし sudo user + command list: 前述のリストに限定されます セル・サーバー権限: いいえ ホスト・オペレーティング・システム(Dom0): いいえ ネットワーク権限: いいえ 実行可能コマンドのリスト: これらのコマンドは、Bashプロンプトから直接実行できます。
読取りおよび書込みアクセスが明示されているディレクトリおよびファイル:
特殊なオペレータ・アクセス・コントロール・コマンド: 前述のファイルまたはディレクトリを表示または変更(読み取り、読み取り/書き込み)するCageコマンド:
|
アクション: システム診断
INFRA_DIAGで指定されるシステム診断は、Exadata Cloud@Customerインフラストラクチャ・レイヤーの問題の診断での使用を目的としています。
診断には、ログの読み取り、診断の実行、およびコマンドのモニターが含まれます。このアクションは、Exadata Cloud@Customerシステムで診断エージェントによって問題を修正することも目的としています。この修正には、パラメータが変更される可能性がある診断デーモンの再起動が含まれます。
システム診断アクションには、顧客データ漏洩リスクや可用性低下リスクはありません。
- オペレータによる、
catやgrepなどを使用した、オペレーティング・システム、インフラストラクチャ・ソフトウェア、およびクラウド・オーケストレーション・ソフトウェアのログ・ファイルの読取り。 - オペレータによる、Oracle Linux診断コマンド(
topやnetstatなど)の実行。 - セル・サーバーでは、オペレータが
cellcliコマンドを実行して診断情報を取得することも許可されます。 - オペレータは、コントロール・プレーン・サーバー上のクラウド・オーケストレーション・インフラストラクチャにアクセスし、コントロール・プレーン・サーバー上のすべてのデーモンを再起動できます。
表1-2 INFRA_DIAGで有効化されるアクション
| アクション名 |
システム診断 |
| 処理識別子 |
|
| オペレータ権限 |
Oracle Linuxユーザー権限: 非root。 suでrootに切替え可能: 非対応 chroot jail: はい suによる切替え可能:
rootとして実行:
セル・サーバー権限:セル・モニターとして動作します。 ネットワーク権限: すべてのホスト、セル・サーバーおよびコントロール・プレーン・サーバーにSSH接続できます。ユーザー名はこれら全体で同じです。 実行可能コマンドのリスト:
読取りおよび書込みアクセスが明示されているディレクトリおよびファイル:
|
アクション: 再起動権限付きのシステム・メンテナンス
INFRA_UPDATE_RESTARTで指定される再起動権限付きのシステム・メンテナンスは、システム構成の変更すなわちシステムの再起動を必要とするオペレータ・アクセス・シナリオでの使用を目的としています。
通常、INFRA_UPDATE_RESTARTシナリオはメンテナンス用です。ただし、診断シナリオでこのアクションが必要になることもあります。システム構成の変更には、ネットワーク構成の変更、ハードウェア構成の変更、オペレーティング・システム構成(mount、inode、ulimitなど)の変更、またはクラウド・オーケストレーション・ソフトウェアの構成の変更が含まれます。システムの再起動では、Oracleオペレータに、オペレーティング・システム(ホスト、セル・サーバー)を再起動する、特定のサブシステム(ネットワークなど)を再起動する、セル・ディスクを再起動する資格が付与されます。
注意:
再起動権限を持つシステム・メンテナンス・アクションでは、インフラストラクチャ・コンポーネント(データベース・サーバー、ストレージ・サーバーおよびコントロール・プレーン・サーバー)の再起動が許可され、お客様のVM、顧客データおよびインフラストラクチャ監査サービスへのアクセスが防止されることに注意してください。- Oracleオペレータが、
root権限を使用してシステム・メンテナンス・アクティビティを実行することを許可します。オペレータがrootになることはできませんが、メンテナンス・コマンドをrootとして実行できます。 - オペレータによる監査パラメータの変更や監査ログへのアクセスは許可されません。ただし、このアクションによって、オペレータがExadata Cloud@Customerシステム全体をオフラインにすることは許可されます。
- 永続的な変更によるオペレーティング・システムの構成の変更をオペレータに許可します。たとえば、Oracleオペレータは
/etc/ parametersの変更を許可されます。 - Oracleオペレータによる、デーモン・プロセスの開始と、セル・サーバー上での
cellcliセル管理権限を使用したセル・ディスクの管理が許可されます。 - Oracleオペレータによる、コントロール・プレーン・サーバー上のクラウド・オーケストレーション・インフラストラクチャへのアクセスおよびコントロール・プレーン・サーバー上のすべてのデーモンの再起動が許可されます。
継承: システム診断のすべての権限
表1-3 INFRA_UPDATE_RESTARTで有効化されるアクション
| アクション名 |
再起動権限付きのシステム・メンテナンス |
| 処理識別子 |
|
| オペレータ権限 |
システム診断の権限に加えて以下が含まれる: suでrootに切替え可能: 非対応 chroot jail: はい suによる切替え可能:
rootとして実行:
セル・サーバー権限: セル・サーバーの ネットワーク権限: すべてのホスト、セル・サーバーおよびコントロール・プレーン・サーバーにSSH接続できます。ユーザー名はこれらすべてのレイヤーで同じです。 実行可能コマンドのリスト:
読取りおよび書込みアクセスが明示されているディレクトリおよびファイル:
|
アクション: データ・アクセス/VM制御権限付きシステム・メンテナンス
INFRA_HYPERVISORで指定されるデータ・アクセス/VM制御権限付きシステム・メンテナンスは、ホスト上のVM管理が必要な診断およびメンテナンス・シナリオでの使用を意図しています。
データ・アクセス/VM制御権限付きシステム・メンテナンスは、ホスト上のVM管理が必要な診断およびメンテナンス・シナリオでの使用を意図しています。ゲストVM上のすべてのデータは、顧客データとして扱われます。VM管理ではVMデータにアクセスできるため、このアクションによってデータがリスクにさらされる可能性があります。ただし、このアクションでは、セル・サーバーに格納されたデータのTDEキーへのアクセスは付与されません。VM管理が必要になるのは、VMソフトウェアインフラストラクチャに問題がある場合や、VM構成を変更する必要がある場合です。構成には、VMの外部的な側面(アタッチされたネットワーク、アタッチされたディスク、または割り当てられたリソース(CPU、メモ)など)が含まれます。
データ・アクセス/VM制御権限を持つシステム・メンテナンスでは、インフラストラクチャ監査サブシステムへのアクセスが防止されます。
- オペレータによる
root権限でのXen/KVM管理コマンドの実行を許可します。オペレータがrootになることはできません。このアクションを適用できるのはホストのみです。 - 再起動権限付きのシステム・メンテナンス・アクションの権限を継承します。
- オペレータがホストまたはセル・サーバーのオペレーティング・システム・パラメータを変更することはできない。ただし、オペレータはゲスト VMをシャットダウンし、ゲスト VMの構成を大幅に変更できます。
継承: 再起動付きシステム・メンテナンスのすべての権限。
表1-4 INFRA_HYPERVISORで有効化されるアクション
| アクション名 |
データ・アクセス/VM制御権限付きシステム・メンテナンス |
| 処理識別子 |
|
| オペレータ権限 |
再起動付きシステム・メンテナンスの権限に加えて以下が含まれる: Oracle Linuxユーザー権限: 非root。 suでrootに切替え可能: 非対応 chroot jail: はい suによる切替え可能: セル・サーバーの rootとして実行:
セル・サーバー権限: ネットワーク権限: すべてのホスト、セル・サーバーおよびコントロール・プレーン・サーバーにSSH接続できます。ユーザー名はこれら全体で同じです。 実行可能コマンドのリスト:
読取りおよび書込みアクセスが明示されているディレクトリおよびファイル:
|
アクション: フル・システム・アクセス
フル・システム・アクセス(INFRA_FULLとして識別)では、インフラストラクチャ・コンポーネントのルート・アカウントへのアクセスが許可されます。
フル・システム・アクセス・アクションは、Exadata Cloud@Customerインフラストラクチャへのフル・アクセスが必要な場合は使用することを目的としています。アクセスは、常に非ゲスト VMレイヤーに制限されます。ここでは、フル・アクセスは、ゲストVMを除くExadata Cloud@Customerシステムのすべてのオペレーティング・システム・インスタンスのroot権限を意味します。
フル・システム・アクセス・アクションでは、オペレータはインフラストラクチャのrootユーザーになることができます。これにより、オペレータは、任意のメモリーレジスタ、任意のファイル、任意のデバイス、および監査サブシステムにアクセスして変更できます。
表1-5 INFRA_FULLで有効化されるアクション
| アクション名 |
フル・システム・アクセス |
| 処理識別子 |
|
| オペレータ権限 |
Linuxユーザー権限: 非root suで chroot jail: いいえ 読取り可能ディレクトリ: すべて 読取り可能ファイル: すべて 書込み可能ディレクトリ: すべて 書込み可能ファイル: すべて 実行可能コマンドのリスト: すべて suによる切替え可能: sudoユーザーおよびコマンド・リスト: 制限なし セル・サーバー権限: ネットワーク権限: すべてのホスト、セル・サーバーおよびコントロール・プレーン・サーバーにSSH接続できます。ユーザー名はこれら全体で同じです。また、ホスト上で直接 |
オペレータ・アクセス制御アクション: Autonomous VM Cluster
フル・システム・アクセスの他に、制限されたアクセス・ケージ「診断および保守」を使用して、ログを表示し、サービス関連のタスクを実行します。
- アクション: Autonomous Exadata VM Clusterフル・システム・アクセス
AVM_FULLとして識別されるAutonomous Exadata VM Clusterフル・システム・アクセスは、低いアクセス権限で問題を解決できない場合、ほとんど使用されません。 - アクション: Autonomous Exadata VM Cluster System Diagnostics
AVM_SYS_DIAGとして識別されるAutonomous Exadata VM Cluster System Diagnosticsは、ログの表示に使用されます。 - アクション: Autonomous Exadata VM Cluster System Maintenance
AVM_SYS_MAINTとして識別されるAutonomous Exadata VM Cluster System Maintenanceは、サービス関連の変更の実行に使用されます。
親トピック: オペレータ・アクセス・コントロールでのアクションの適用
アクション: Autonomous Exadata VM Clusterフル・システム・アクセス
AVM_FULLとして識別されるAutonomous Exadata VM Clusterのフル・システム・アクセスは、低いアクセス権限で問題が解決できない場合、ほとんど使用されません。
Autonomous Exadata VM Clusterフル・システム・アクセス・アクションは、ゲストVMへのフル・アクセスが必要な場合に使用することを目的としています。ここでのフル・アクセスは、ゲストVMへのroot権限を意味します。
フル・システム・アクセス・アクションには、極度の可用性リスクとデータ漏洩リスクがあり、持続する可能性があります。このアクションには、システムからの監査ログのエクスポートを防ぐ機能もあります。
表1-6 AVM_FULLで有効化されるアクション
| アクション名 |
フル・システム・アクセス |
| 処理識別子 |
|
| オペレータ権限 |
Linuxユーザー権限: 非root suで chrootケージ内: 非対応 読取り可能ディレクトリ: すべて 読取り可能ファイル: すべて 書込み可能ディレクトリ: すべて 書込み可能ファイル: すべて 実行可能コマンドのリスト: すべて suによる切替え可能: sudoユーザーおよびコマンド・リスト: 制限なし |
アクション: Autonomous Exadata VM Cluster System Diagnostics
AVM_SYS_DIAGとして識別されるAutonomous Exadata VM Cluster System Diagnosticsは、ログの表示に使用されます。
Autonomous Exadata VM Cluster System Diagnosticsアクションは、ログの表示に使用することを目的としています。読み取り専用プロファイル。システムへの非特権読み取り専用アクセスを許可します。このアクションは、オペレーティングシステムおよびそのシステム上で実行されているソフトウェアで発生する可能性のある問題を特定するために使用されます。ほとんどのroot以外のコマンドは、このモードで使用できます。このアクションで使用できる特権付きコマンドはありません。演算子はoracle、opcまたはgridとしてsudoすることは許可されませんが、その動的オペレータ・ユーザーとして実行できるコマンドのホワイトリスト・セットがあります。
表1-7 AVM_SYS_DIAGで有効化されたアクション
| アクション名 |
Autonomous Exadata VMクラスタ・システム診断 |
| 処理識別子 |
|
| スコープ |
ゲストVM |
| オペレータ権限 |
Linuxユーザー権限: 非root suでrootに、oracle、opc、gridにすることができます: いいえ chrootケージ内: 対応 読取り可能ディレクトリ:
書込み可能なディレクトリ: 制限付きアプリケーション・ログの読取り可能な場所:
読取り可能な構成ファイル:
エグレス・ネットワーク・アクセス: なし ブラックリストに登録されたオペレーティング・システムのコマンド:
実行可能なコマンドのリスト: |
オペレータのアクセスを特定の顧客承認済Autonomous Container Database (ACD)に制限
診断および保守ケージ内の自律型VMクラスタ内の特定のACDへのアクセスを制限します。
演算子では、次のものが必要かどうかを指定できます。
- ACDへのSQLアクセスなしで、自律VMクラスタへのSSHのみのアクセス。この場合、ACDへのすべてのSQLアクセスがブロックされます。
- 自律型VMクラスタへのSSHアクセス、およびACDへのSQLアクセス。両方を選択する場合は、1つ以上のACDを選択する必要があります。
顧客は、オペレータがアクセスをリクエストしている詳細を含む承認要求を受け取ります。これにより、オペレータが適切なACDにアクセスできることを保証できます。顧客がアクセス要求を承認すると、オペレータは承認済みのACDにのみSQLアクセスを取得します。
Request Reason属性は、オペレータがアクセスをリクエストしているACDを表示します。
アクション: Autonomous Exadata VM Cluster System Maintenance
AVM_SYS_MAINTとして識別されるAutonomous Exadata VM Cluster System Maintenanceは、サービス関連の変更の実行に使用されます。
Autonomous Exadata VM Cluster System Maintenanceアクションは、サービス関連の変更の実行に使用することを目的としています。このアクションは、サービスの開始と停止、およびサービス・ヘルス・チェックの実行に使用されます。ほとんどのサービス関連のコマンドは、このモードで使用できます。オペレータはログにアクセスできますが、oracle、opcまたはgridへのsuは許可されません。
表1-8 AVM_SYS_MAINTで有効化されるアクション
| アクション名 |
Autonomous Exadata VMクラスタ・システムのメンテナンス |
| 処理識別子 |
|
| スコープ |
ゲストVM |
| オペレータ権限 |
Linuxユーザー権限: 非root suでrootに、oracle、opc、gridにすることができます: いいえ chrootケージ内: 対応 読取り可能ディレクトリ:
書込み可能なディレクトリ: なし 制限付きアプリケーション・ログの読取り可能な場所:
読取り可能な構成ファイル:
エグレス・ネットワーク・アクセス: なし ブラックリストに登録されたオペレーティング・システムのコマンド:
コマンド別名: 実行可能コマンドのリスト: サービス関連コマンドの実行は、 次に示す例を参照してください。
次のように別名で実行するスクリプト。
|
オペレータのアクセスを特定の顧客承認済Autonomous Container Database (ACD)に制限
診断および保守ケージ内の自律型VMクラスタ内の特定のACDへのアクセスを制限します。
演算子では、次のものが必要かどうかを指定できます。
- ACDへのSQLアクセスなしで、自律VMクラスタへのSSHのみのアクセス。この場合、ACDへのすべてのSQLアクセスがブロックされます。
- 自律型VMクラスタへのSSHアクセス、およびACDへのSQLアクセス。両方を選択する場合は、1つ以上のACDを選択する必要があります。
顧客は、オペレータがアクセスをリクエストしている詳細を含む承認要求を受け取ります。これにより、オペレータが適切なACDにアクセスできることを保証できます。顧客がアクセス要求を承認すると、オペレータは承認済みのACDにのみSQLアクセスを取得します。
Request Reason属性は、オペレータがアクセスをリクエストしているACDを表示します。
オペレータ・アクセス制御のアクション: Compute Cloud@Customer
認可されたオペレータがCompute Cloud@Customerのアップグレード、問題のトラブルシューティングまたは解決に役立つリソースにアクセスする必要がある場合があります。
- アクション: Compute Cloud@Customerインフラストラクチャのフル・アクセス
Compute Cloud@Customerインフラストラクチャのフル・アクセスは、CCC_SYS_ADMIN_FULL_ACCESSとして識別されます。
親トピック: オペレータ・アクセス・コントロールでのアクションの適用
アクション: Compute Cloud@Customerインフラストラクチャのフル・アクセス
Compute Cloud@Customerインフラストラクチャのフル・アクセスは、CCC_SYS_ADMIN_FULL_ACCESSとして識別されます。
表1-9 CCC_SYS_ADMIN_FULL_ACCESSで有効化されるアクション
| アクション名 |
フル・システム・アクセス |
| 処理識別子 |
|
| オペレータ権限 |
Linuxユーザー権限: 非root suで chrootケージ内: 非対応 読取り可能ディレクトリ: すべて 読取り可能ファイル: すべて 書込み可能ディレクトリ: すべて 書込み可能ファイル: すべて 実行可能コマンドのリスト: すべて suによる切替え可能: |
オペレータ・アクセス・コントロールの制限
オペレータ・アクセス・コントロールは、汎用のコンプライアンス・ソリューションではなく、Oracleアクセスの監査およびコンプライアンスのために設計されたソリューションです。
オペレータ・アクセス・コントロールでは、Oracle Operator Access Controlに関連付けられたアクセス・リクエストのコンテキストで作成された認可ユーザーしか監査されません。次のリストに、オペレータ・アクセス・コントロールによって対処されないコンプライアンスの監査とコントロールのアクションの例を示します。
- オペレータ・アクセス・コントロールでは、Oracleが所有するレイヤーのみが制御されます。たとえば、オペレータ・アクセス・コントロールでは、物理Exadataデータベース・サーバーとExadataストレージ・サーバーへのアクセスが制御されます。
- オペレータ・アクセス・コントロールでは、自動化アクションは制御されません。これには、プロキシベースの自動化アクセスなど、
rootやその他の高特権自動化ユーザーとして実行されるアクションが含まれます。 - オペレータ・アクセス・コントロールでは、定義されたアクション・レベルのみでコントロールが提供されます。アクションそのものが、オペレーティング・システム・レベルでアプリケーションへのアクセスを制御します。
- オペレータ・アクセス・コントロールは一般的な監査サービスではありません。これは、オペレータ・コントロールに関連付けられたアクセス・リクエストのコンテキストで作成された認可ユーザーしか監査しません。
- オペレータ・アクセス・コントロールでは、Exadata Cloud@Customerシステムの様々なレイヤーしか制御されません。Oracle Cloud Infrastructureの外部エンティティ(スイッチなど)または他のコントロール・プレーン・ソフトウェアに対するコントロールは提供されません。
オペレータ・アクセス・コントロールの顧客テナンシ・ジョブ・ロール
オペレータ・アクセス・コントロールを確立するには、アクセス・コントロール・ポリシーを設定し、インフラストラクチャに対するアクセスの管理とモニターを担当するユーザー・グループを確立します。
- ポリシー管理者向けのオペレータ・コントロールの作成
ポリシー管理者は、オペレータ・コントロール・ポリシー(オペレータ・コントロールと呼ばれる)を設定する権限を持つユーザーです。 - オペレータ・アクセス・リクエストの承認方法
Oracle Operator Access Controlポリシーを使用してIdentity and Access Management (IAM)制度を設定することで、オペレータ・コントロールの承認を管理する方法を確認します。 - オペレータ・アクセスの監査方法
ログの取得方法およびオペレータ・アクティビティの監査方法を学習します。
ポリシー管理者向けのオペレータ・コントロールの作成
ポリシー管理者は、オペレータ・コントロール・ポリシー(オペレータ・コントロールと呼ばれる)を設定する権限を持つユーザーです。
インフラストラクチャに対するオペレータ・アクセス・コントロールを作成するには、最初のステップとして、テナンシ・フリート管理者のために使用する一連のオペレータ・コントロールを開発および作成するオペレータ・コントロール・ポリシー管理者を作成します。
通常、オペレータ・コントロールを作成するときは、Exadataインフラストラクチャを複数のディメンションに基づいたアクセス制御グループに分割します:
- ビジネス重要度: 重要なシステム、それほど重要でないシステム、開発システム
- セキュリティまたはコンプライアンス: 特定のコンプライアンス・ニーズがあるシステムおよびその他のシステム
- ユーザー・グループ: Exadataシステムのセットを担当させるユーザー・グループ(通常はフリート管理者ロール)
Exadataシステムのセットを担当するユーザー・グループの例:
- アプリケーションがExadataシステムのセットに依存している垂直部門。
- いくつかの部門で共有されるシステムの場合は、IT部門が管理を担当します。
一般的には、重要度、規制コンプライアンスおよびユーザー・グループ管理に基づいてインフラストラクチャにコンパートメントを作成します。コンパートメントによってOracle Cloud Infrastructure内の論理的な管理境界が形成されるためです。通常、各コンパートメントには、そのコンパートメントに対する管理権限が付与されるユーザー・グループがあります。このため、ポリシー管理者は、Exadataインフラストラクチャを保持するコンパートメントと同じ数のオペレータ・コントロールを作成する必要があります。
コンパートメントに対する特定のオペレータ・コントロールに加えて、DEFAULT_OPERATOR_CONTROLという追加のポリシーも作成する必要があります。これを使用すると、新しいコンパートメントに新しいExadataシステムのセットを作成したり、それに対して別の管理ユーザーのセットを作成したりすることができます。
関連トピック
オペレータ・アクセス・リクエストの承認方法
Oracle Operator Access Controlポリシーを使用してIdentity and Access Management (IAM)制度を設定することで、オペレータ・コントロールの承認を管理する方法を確認します。
Oracle Cloudシステムのオペレータ・コントロールのテナンシ管理者は、オペレータ・コントロールのオペレータ・コントロール管理者グループのメンバーです。Oracle Cloud Infrastructureにアクセスするためのオペレータ・コントロール・リクエストを受け取ります。規制コンプライアンス要件をサポートするために、インフラストラクチャに対するアクセスを制御できます。一部のアクションのステータスが常に自動承認済になるように指定することも、Oracleがテナンシでのシステム・メンテナンス操作を実行する前に他のアクションが承認を受ける必要があるように指定することもできます。システムへのアクセス権を付与するとき、そのアクセス権は標準の期間に自動的に制限されます。また、指定した特定の時間枠内で操作が実行されるように指定することもできます。
例1-1 Oracle Cloud Infrastructure IAMポリシーのオペレータ・コントロール
システム上で付与する権限にきめ細かい制御を設定できます。
たとえば、テナンシ管理者であるコンパートメントにExadata Cloudシステムの2つのグループがあるとします。IAMポリシーの一環として、2つの個別のExadataシステム・セットを作成しました。システムの1つ目のグループでは、すべてのオペレータ・ポリシー構成が事前承認済に設定されており、2つ目のグループでは事前承認済に構成されているオペレータ・ポリシーはありません。
また、PRE_APPROVED_POLICY_USERSおよびEXPLICIT_APPROVED_POLICY_USERSの2つのユーザー・グループを作成しました。オペレータ・コントロール・グループは、指定するタグ付けによって識別されます。ネームスペースoptctlには2つのオペレータ・コントロール・グループがあります。1つは、タグpre-approved-exaccによって識別されます。2つ目のグループは、タグexplicit-approved-exaccによって識別されます。つまり、大きく分けると、すべてのアクションが事前承認済の一連のサーバーと、事前承認済のアクションがない一連のサーバーがあることになります。
次に、コンパートメントで、Exadata Cloudリソースのセットを確立したとします。各リソースが、許可されるアクションのレベルを表します:
system_diagは、Exadata Cloud@Customerインフラストラクチャ・レイヤーのすべての問題を診断するアクション(ログの読取り、診断の実行、コマンドのモニターなど)の権限を指定します。このポリシーのメンバーにはINFRA_DIAGアクションを付与します。system_mainは、システムの診断とメンテナンスを実行するアクションの権限を指定し、システムを再起動するオプションも指定します。このポリシーのメンバーにはINFRA_UPDATE_RESTARTアクションを付与しますが、認可は「認可の指定」に設定されます。system_allは、sudoの無制限使用など、システム上のフル・システム管理権限を付与します。このポリシーのメンバーにはINFRA_FULLアクションを付与します。このアクションで作成されるポリシー・グループはありません。
system_diagポリシーを設定したリソースについて、そのアクションで許可されるすべての管理アクティビティを事前承認済としてマークしました。グループPRE_APPROVED_POLICY_USERSのメンバーには、テナンシ内で事前承認済ステータスのsystem_diagを使用するアクセス権が付与されるように指定しました。
次に、PRE_APPROVED_POLICY_USERSグループ・メンバーシップを持つOracleオペレータがサーバーへのアクセスをリクエストしますが、メンテナンス・アクションで再起動が必要であるため、アクションINFRA_UPDATE_RESTARTをリクエストしたとします。Oracleオペレータは、メンテナンス・アクションの一部としてシステムを再起動することをオペレータに許可するアクションのアクセス権を、引き続き要求する必要があります。system_mainポリシーにアクセスできますが、このポリシー・アクセスを必要とするすべてのアクションは承認が必要です。
管理者は、任意の時点で、既存のグループ・メンバーシップまたは承認に関係なく、オペレータのアクセス権を取り消すことができます。グループ・メンバーシップからOracleオペレータを削除すると、オペレータはシステムに対するアクセス権がなくなります。
オペレータ・アクセスの監査方法
ログの取得方法およびオペレータ・アクティビティの監査方法を学習します。
監査ログは、Linuxカーネルの
auditdサブシステムを使用して収集されます。ログを収集するためにオペレータ・アクセス・コントロール・ルールを追加するには、オペレータ・コントロールを初めて割り当てた後でExadataシステムをリブートする必要があります。その後の割当てではExadataシステムをリブートする必要はありません。
取得された監査ログのエクステント
- ライフサイクル・イベント・ログ
- コマンド・ログ
1つ目はライフサイクル・イベントであり、2つ目はターゲット・ホスト上でオペレータによって実行されるコマンドです。
ライフサイクル・イベント・ログ
オペレータ・アクセス・コントロール・サービスは、オペレータ・アクセス・コントロール・サービス認可ユーザーのログイン・イベントおよびログアウト・イベントのみを取得し、自動化ログイン・イベントは取得しません。
コマンド・ログ
オペレータ・アクセス・コントロール・サービスは、認可ユーザーがシェルで実行するすべてのコマンドを取得します。リダクションを行わずにコマンド入力が取得され、コマンド出力は取得されません。また、シェル・スクリプトを使用して実行されるすべてのシェル・コマンドも取得します。
netstat -an | grep 8080searchlog.shを使用して実行されるコマンドも取得します。./searchlog.sh –process "cellservice"suの実行後でもユーザーによって実行されるコマンドが含まれます。たとえば、ログイン後に、認可ユーザーauth_user_123が次のコマンドを実行した場合、オペレータ・アクセス・コントロール・サービスはこれらのコマンドをすべて取得します。su - celladmin
tail -n 10 /var/log/messagesキーボード・ロギング
また、コマンド・ログはキーボード・ログ形式で取得することもできます。キーボード・ロギングは、オペレータがコンピュータに入力するすべてのキーストロークを取得します。キーボード・ロギングの取得には実用的なメリットは多くありませんが、規制要件でキーストローク・ロギングを取得する必要があるケースがあります。
ロギングされない項目
オペレータ・アクセス・コントロール・サービスは、自動化コマンドまたはライフサイクル・イベントのログを記録しません。このサービスは、直接またはシェルスクリプトの起動によってシェルに対して発行されたすべてのコマンドをログに記録しますが、バイナリ実行可能ファイルによって実行されたアクションはログに記録しません。したがって、オペレータがセル・サーバーにログインしてからcellcliシェルに入ると、ログは、cellcliシェル・コマンドのみの取得に制限されます。オペレータ・アクセス・コントロール・サービスは、cellcli内で実行されるコマンドをログに記録しません。
監査ログの形式
監査ログの形式はJSONテキストです。監査ログは、RAWデータと解釈されたデータの2つの部分に分類されます。RAWデータは、ログが取得されたLinuxマシンのコンテキスト外では理解できません。たとえば、RAWデータはLinuxユーザー名を参照せず、かわりに内部識別子を参照します。ユーザーへの識別子のマッピングは、ログが取得されたLinuxマシンでしか実行できません。
解釈に加え、形式では、ログにアクセス・リクエストIDを指定することで、コンテキストも設定されます。
ライフサイクル・イベント・ログ
次の2つの例では、ライフサイクル・イベントの監査ログの形式を示します。例では、ログインおよびログアウト・イベントを示します。このログインに使用されるユーザー名はUSERNAMEです。
例1-2 ログイン・イベント・ログ
{
"layer": "CPS",
"req_auth_id": "1",
"srchost": "dhcp-10-191-235-63.vpn.example.com",
"res": "success'",
"desthost": "10.191.235.63",
"pid": "89736",
"tty": "/dev/pts/2",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:22 2020",
"raw_data": "type=USER_LOGIN msg=audit(10/29/2020 03:20:22.091:10777414) : pid=89736 uid=root auid=USERNAME ses=75141 msg='op=login id=USERNAME exe=/usr/sbin/sshd hostname=dhcp-10-191-235-63.vpn.example.com addr=10.191.235.63 terminal=/dev/pts/2 res=success' \n",
"event": "login",
"loginid": "USERNAME"
}例1-3 ログアウト・イベント・ログ
{
"layer": "CPS",
"req_auth_id": "1",
"srchost": "dhcp-10-191-235-63.vpn.example.com",
"res": "success'",
"desthost": "10.191.235.63",
"pid": "90456",
"tty": "ssh",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:35 2020",
"raw_data": "type=USER_LOGOUT msg=audit(10/29/2020 03:20:35.855:10777438) : pid=90456 uid=root auid=USERNAME ses=75142 msg='op=login id=USERNAME exe=/usr/sbin/sshd hostname=dhcp-10-191-235-63.vpn.example.com addr=10.191.235.63 terminal=ssh res=success' \n",
"event": "logout",
"loginid": "USERNAME"
}コマンド・ログ
コマンド・ログはさらに複雑です。コマンド、コマンドのパラメータ、コマンドを実行する有効なユーザーに関する情報が提供されます。コマンドには、シェル・スクリプトの実行で、最初にbash -cが記録されてからスクリプト・コマンドが記録されるという階層もあります。
例1-4 コマンドの実行
{
"layer": "CPS",
"req_auth_id": "1",
"title": "ls\u0000/",
"raw_data": "type=PROCTITLE msg=audit(10/29/2020 03:20:29.418:10777424) : proctitle=ls / \ntype=PATH msg=audit(10/29/2020 03:20:29.418:10777424) : item=1 name=/lib64/ld-linux-x86-64.so.2 inode=1182648 dev=f9:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL \ntype=PATH msg=audit(10/29/2020 03:20:29.418:10777424) : item=0 name=/usr/bin/ls inode=1189225 dev=f9:00 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL \ntype=CWD msg=audit(10/29/2020 03:20:29.418:10777424) : cwd=/ \ntype=EXECVE msg=audit(10/29/2020 03:20:29.418:10777424) : argc=2 a0=ls a1=/ \ntype=SYSCALL msg=audit(10/29/2020 03:20:29.418:10777424) : arch=x86_64 syscall=execve success=yes exit=0 a0=0xfff6d0 a1=0xff42d0 a2=0xfff960 a3=0x7ffc1dd337e0 items=2 ppid=90474 pid=90764 auid=USERNAME uid=USERNAME gid=USERNAMg euid=USERNAME suid=USERNAME fsuid=USERNAME egid=USERNAMg sgid=USERNAMg fsgid=USERNAMg tty=pts2 ses=75141 comm=ls exe=/usr/bin/ls key=(null) \n",
"args": [],
"rec_id": "10777424",
"tty": "pts2",
"host": "scaqae08dv0605m",
"time": "Thu Oct 29 03:20:29 2020",
"loginid": "USERNAME"
}フィールド・タイトルによって、実行されたコマンドが示されます。RAWデータでは、さらに多くの情報が提供されます。
収集の頻度
オペレータ・アクセス・コントロール・サービスは、イベントの発生中および発生時にログ、タイムスタンプを収集し、ログをロギング・サービスに定期的にプッシュします。30秒間隔でログをプッシュしようとします。
監査ログへのアクセス
監査ログには、ロギング・サービスを介してアクセスできます。詳細は、ロギングの概要を参照してください。
第2項で示すJSONは、ロギング・サービスで入手できます。テナンシを使用して、ロギング・サービスにアクセスします。ログは、オペレータ・コントロールが作成されたコンパートメントに送信されます。ログはオペレータコントロールにタグ付けされます。
監査ログの保持ポリシー
監査ログはユーザー・テナンシに保持されるため、オペレータ・アクセス・コントロール・サービスでは監査ログの存続期間は制御されません。ユーザーが保持期間を制御できます。ただし、このサービスがログをユーザー・テナンシにプッシュできなかった場合は、Exadata構成によって許可されたエクステントまでログを保持しようとします。保持期間は長めです。つまり数日以上です。
オペレータ・アクセス・コントロール監査ログのSIEMシステムへの転送
オペレータ・アクセス・コントロール監査ログを、Exadata Cloud@Customerからデータ・センター内のセキュリティ情報イベント管理(SIEM)システムに直接転送するように選択できます。
セキュリティ管理を改善するために、監査ログをOCIロギング・サービスおよびデータ・センターのSIEMシステムに転送できます。これらの監査ログをSIEMシステムに送信するには、TCP経由のsyslogが使用されます。
- データ・センターへのSyslogサーバーのデプロイ
Exadata Cloud@Customerから監査ログを受信するために、データ・センターにSyslogサーバーをデプロイします。Syslogサーバーは選択できます。ほとんどのLinuxシステムには、rsyslogが付属しています。 - Syslogサーバー構成の例
選択したSyslogサーバーの構成方法を確認するには、この例を使用します。 - CPSとSyslogサーバー間の接続のテスト
Syslogサーバーの有効なIPアドレスまたはホスト名を指定したことを確認します。 - 監査ログの例
管理者として、コントロール・プレーン・サーバーから安全に受信された監査ログの例を確認してください。
データ・センターへのSyslogサーバーのデプロイ
Exadata Cloud@Customerから監査ログを受信するために、データ・センターにSyslogサーバーをデプロイします。Syslogサーバーは選択できます。ほとんどのLinuxシステムには、rsyslogが付属しています。
監査ログを転送できるのは、ターゲットExadata Cloud@Customerシステムごとに1つのSyslogサーバーのみです。Oracleではセキュアな通信しかサポートされません。また、伝送セキュリティにTLSが使用されます。コントロール・プレーン・サーバーはSyslogサーバーと接続し、すべての監査ログをセキュアなTCP経由で送ります。コントロール・プレーン・サーバーとSyslogサーバー間の信頼を確立するには、PEM形式のSyslogサーバーCA証明書ファイルを使用します。ファイル拡張子は、.pem、.cerまたは.crtである必要があります。構成の詳細は、Syslogサーバー構成の例を参照してください。
ログには、オペレータ・アクセス・コントロールによるログの管理および検索の章で説明している要素がすでに含まれています。この形式はsyslogおよびaudit-dのログ・パーサーと互換性があることが保証されます。監査ログの例を参照してください。
SIEMシステムへの監査ログの送信はベスト・エフォートで行われます。コントロール・プレーン・サーバーがネットワーク障害時にログの送信を再試行する際に、しきい値によるパケットのドロップがサイレントに発生する可能性があります。そのようなケースでは、OCIロギング・サービスを通じて表示されるログは参照情報になります。
監査ログを転送するには、少なくとも1つのオペレータ・コントロールをExadata Cloud@Customerシステムに無期限(ALWAYS ASSIGNED)に割り当てる必要があります。
関連トピック
Syslogサーバー構成の例
選択したSyslogサーバーの構成方法を確認するには、この例を使用します。
- リモート・ログを受信するためのネットワーク・ポートを開きます。
ノート
Syslogサーバーのエグレス・ルールは、Syslogポート用にオープンしている必要があります。たとえば、Syslogに6514ポートを使用する場合、トラフィックがAutonomous VMクラスタからSyslogに到達できるように、エグレス・セキュリティ・ルールを設定する必要があります。 - リモート通信のためにSyslogサーバー上で暗号化を有効にします。
- (オプション)セキュアな通信のためのルート証明書を生成して転送します。
次の例は、Oracle Linux 7のマシンでの
rsyslogサーバー(v 8.24)の構成に対応しています。この構成は、通常は/etc/rsyslog.confにあります。この例では、関連するセクションのみを示しています。
この例では、リスニング・ポートは10514です。Syslogトラフィックの暗号化に役立つ複数の情報をインターネットから入手できます。リファレンスとして適切なのは、Encrypting Syslog Traffic with TLS (SSL) [short version] (rsyslog 8.18.0.master documentation)です。
# rsyslog configuration file (8.24.0 - /etc/rsyslog.conf - Oracle Linux 7)
# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
# If you experience problems, then see http://www.rsyslog.com/doc/troubleshoot.html
#### MODULES $ModLoad imuxsock # provides support for local system logging (e.g. via logger command)# Provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 10514
...# certificate files
$DefaultNetstreamDriverCAFile /var/gnutls1/ca.pem
$DefaultNetstreamDriverCertFile /var/gnutls1/cert.pem
$DefaultNetstreamDriverKeyFile /var/gnutls1/key.pem$ModLoad imtcp # load TCP listener$InputTCPServerStreamDriverMode 1 # run driver in TLS-only mode
$InputTCPServerStreamDriverAuthMode anon # client is NOT authenticated
#$InputTCPServerStreamDriverAuthMode x509/name # client is NOT authenticated
$InputTCPServerRun 10514 # start up listener at port 10514
...CPSとSyslogサーバー間の接続のテスト
Syslogサーバーの有効なIPアドレスまたはホスト名を指定したことを確認します。
- Syslogサーバーがログを受信できることを確認するには、Syslogサーバーへのアクセス権を持つネットワーク上の任意のホストから、SyslogサーバーおよびSyslogポートに向けて
ncコマンドを実行します。nc syslog server host syslog port - Exadata Cloud@CustomerとSyslogサーバー間のパスが有効であることを確認するには、Exadata Cloud@Customerコントロール・プレーン・サーバーのIPアドレスをpingします。コントロール・プレーン・サーバー(CPS)のIPアドレスを取得するには、ネットワーク管理者に連絡してください。
関連トピック
監査ログの例
管理者として、コントロール・プレーン・サーバーから安全に受信された監査ログの例を確認してください。
ログがSyslogサーバーに送信されるとき、多くのヘッダーとJSON書式設定が省略されます。次の例は、Syslogまで送られるデータの性質を示しています。
例1-5 1
Apr 12 07:38:22 scaqar05dv0511m opctl: type=USER_LOGIN msg=audit(04/12/2021 07:38:05.752:1742859) :
pid=65327
uid=root
auid=830916abb78e4157b9e45b641e34fcf6 ses=32770
msg='op=login id=830916abb78e4157b9e45b641e34fcf6
exe=/usr/sbin/sshd
hostname=localhost.localdomain
addr=127.0.0.1
terminal=/dev/pts/3 res=success'例1-6 2
Apr 12 07:38:22 scaqar05dv0511m opctl: type=USER_LOGOUT msg=audit(04/12/2021 07:38:08.802:1742867) :
pid=65327
uid=root
auid=830916abb78e4157b9e45b641e34fcf6
ses=32770
msg='op=login
id=830916abb78e4157b9e45b641e34fcf6 exe=/usr/sbin/sshd
hostname=?
addr=?
terminal=/dev/pts/3 res=success'