コンプライアンス管理の構成
コンプライアンス機能を使用する前に、コンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールを、エンタープライズに対して定義する必要があります。
次の各項では、これらのコンプライアンス・エンティティを定義および維持する方法について説明します。
コンプライアンス・フレームワークについて
コンプライアンス・フレームワークは、1つ以上のコンプライアンス標準、コンプライアンス標準ルール・フォルダおよびコンプライアンス標準ルールに任意のノードをマップできる階層構造です。コンプライアンス・フレームワークは、会社で使用する規制または標準ベースのコンプライアンス構造と類似した構造に標準をマップする方法を提供します。
コンプライアンス・フレームワークの管理
コンプライアンス・フレームワークを管理するには、次のステップに従います。
-
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
-
「コンプライアンス・フレームワーク」タブをクリックします。
-
管理するコンプライアンス・フレームワークをハイライト表示し、実行するアクションを選択します。
Oracle提供のフレームワークおよびユーザー定義のコンプライアンス・フレームワーク
Oracle提供のコンプライアンス・フレームワークと、ユーザー定義のコンプライアンス・フレームワークがあります。
-
Oracle提供のコンプライアンス・フレームワークには、次が含まれます。
-
Oracleサポート・コンプライアンスは、Oracleサポータビリティに対して期待される環境コンプライアンスをチェックするコントロールのコレクションです。
-
Oracleの汎用コンプライアンス・フレームワークは、変更を追跡するためのコンプライアンス標準と関連付けられた制御、および組織がITポリシーにどの程度準拠しているかを判断するためにITインフラストラクチャ全体に実行されるイベントの標準的なセットです。
-
セキュリティ技術導入ガイド(STIG)は、セキュリティ技術導入ガイド(STIG)コンプライアンスを確認するための一連の標準です。
-
-
ユーザー定義のコンプライアンス・フレームワーク
組織のニーズを満たすコンプライアンス・フレームワークを定義できます。
Oracleの提供するコンプライアンス・フレームワークは、削除または編集できません。ただし、これらのフレームワークを拡張する場合、類似作成機能を使用して、Oracle提供のフレームワークに基づいて独自のユーザー定義フレームワークを作成してから、新規フレームワークを編集することができます。
推奨: STIGおよびOracleの汎用コンプライアンス用として提供されているコンプライアンス・フレームワークのような上位レベルのコンプライアンス・フレームワークを作成することを強くお薦めします。
コンプライアンス・フレームワークを作成する利点
コンプライアンス標準は、ターゲットに対するテストを実行するために定義します。これには、構成値が正しく設定されているかのテスト、リアルタイム・ファイルの変更が行われているかを確認するテストなどがあります。コンプライアンス・フレームワークによって、コンプライアンス構想のどの制御領域までこれらのテストの結果が影響するかをマップします。
ある組織で、Oracle提供のコンプライアンス・フレームワークを拡張するコンプライアンス・フレームワークを定義するとします。これを行うには、Oracle提供のコンプライアンス・フレームワークなどの新規コンプライアンス・フレームワークを作成し、新規または既存のコンプライアンス標準を組み込みます。これにより、各コンプライアンス標準は適切なフレームワーク階層フォルダにマップされ、標準に対する違反もこのフレームワーク・フォルダにマップされるようになります。フレームワーク内の各フォルダは1つの制御領域を表します。
コンプライアンス・フレームワークを使用する理由
コンプライアンス・フレームワークを作成するのは、次のようないくつかの理由があります。
-
企業で使用される規制および基準のコンプライアンス制御への基本的なIT違反のマッピングによる、違反の影響を受けるコンプライアンス制御領域の簡単な特定
-
コンプライアンス指定レベルでのコンプライアンス監査
-
監査、セキュリティ評価および傾向分析
コンプライアンス・フレームワークで実行可能な操作
コンプライアンス・フレームワークでは、次のことを実行できます。
-
業界標準のコンプライアンス制御領域を表し、使用している内部フレームワークに合せて作成します。
多くの会社が、業界標準のフレームワークを使用して開始しますが、独自のニーズや監査要件に応じて変更します。
-
危険な状態にあり、違反に基づく補正制御が必要な可能性があるコンプライアンス制御を特定することにより、IT監査をサポートします。影響を受ける制御領域にコンプライアンス・チェックをマップしない場合、コンプライアンス監査における実質的な影響を特定することが困難になります。
-
コンプライアンス・フレームワークには様々なタイプのコンプライアンス標準(リポジトリおよびリアルタイム・モニタリング)を組み込むことができるため、レポートを目的として様々なタイプの類似チェックをグループ化する上で役立ちます。
使用上のノート
リポジトリ・ルールの評価結果は、コンプライアンス・フレームワーク内のコンプライアンス標準ルールが変更または削除された場合に無効化されることがあります。コンプライアンス標準の評価では、コンプライアンス標準内の各コンプライアンス標準ルールの現在のコンプライアンス標準ルールの定義を常に参照しています。
コンプライアンス・フレームワークでの操作
コンプライアンス・フレームワークで次の操作を実行できます。
- コンプライアンス・フレームワークの作成
- コンプライアンス・フレームワークの類似作成
- コンプライアンス・フレームワークの編集
- コンプライアンス・フレームワークの削除
- コンプライアンス・フレームワークのエクスポート
- コンプライアンス・フレームワークのインポート
- コンプライアンス・フレームワークの参照
- コンプライアンス・フレームワークの検索
次の各項では、これらの操作について説明します。
ノート:
コンプライアンス・フレームワークで操作を実行する前に、必要な権限があることを確認します。たとえば、コンプライアンス・フレームワークを作成する場合、フレームワークの定義時に含めるコンプライアンス標準へのアクセス権限を持っていることを確認します。コンプライアンス機能に必要なロールおよび権限を参照してください。コンプライアンス・フレームワークの作成
コンプライアンス・フレームワークを作成しやすくするには、コンプライアンス・フレームワークによって参照されるコンプライアンス標準がCloud Controlですでに定義されていることを確認します。システムの即時利用可能なコンプライアンス標準およびユーザー定義のコンプライアンス標準をコンプライアンス・フレームワークの任意の要素に追加できます。コンプライアンス標準を事前に定義しない場合、これらを後で追加する必要があります。
コンプライアンス・フレームワークを作成するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス・フレームワーク」タブをクリックします。
- 「作成」ボタンをクリックします。
- 名前および作成者を指定し、「OK」をクリックします。
- 一度、定義ページで情報を指定すると、(ページの左上にある)コンプライアンス・フレームワークの名前を右クリックして、使用可能なオプションを参照できます。このリストから、コンプライアンス標準などのサブグループを作成できます。
- 「保存」をクリックします。
使用上のノート
-
-
開発
コンプライアンス・フレームワークが開発中で、定義された作業はまだ進行中であることを示します。開発モードの間、コンプライアンス・フレームワークの編集およびコンプライアンス・フレームワークの削除など、コンプライアンス・フレームワークのすべての管理機能がサポートされます。開発のコンプライアンス標準の結果は、ターゲットとコンソールのホームページ、およびコンプライアンス・ダッシュボードには表示されません。
ライフサイクル・ステータスのデフォルトは開発です。これを「本番」に一度のみ更新できます。本番から開発には変更できません。
-
本番
コンプライアンス・フレームワークが承認され、本番の品質を持つことを示します。コンプライアンス・フレームワークが本番モードの場合、結果はコンプライアンス・ダッシュボード、ターゲットおよびコンソール・ホームページにロールアップされます。
本番のコンプライアンス・フレームワークは、本番のコンプライアンス標準のみを参照できます。本番のコンプライアンス・フレームワークを編集して、本番のコンプライアンス標準への参照のみを追加/削除できます。
ライフサイクル・ステータスは、本番から開発には変更できません。
-
-
「キーワード」列でソートすると、同じキーワードを持つすべてのコンプライアンス・フレームワークはグループ化されます。
-
コンプライアンス・フレームワークに追加されたリポジトリを変更する場合は、コンプライアンス標準を直接編集するか、「インポート」を使用してコンプライアンス標準を新規の設定で上書きし、既存の評価を無効にします。つまり、変更したコンプライアンス標準が評価済のコンプライアンス・フレームワークに含まれており、評価結果がある場合は、これらの結果は表示されなくなります。
コンプライアンス標準をコンプライアンス・フレームワークに追加
コンプライアンス標準のマップ先のフレームワーク・フォルダ要素をクリックします。右クリックして「基準の追加」を選択し、このフォルダにマップする標準を選択できるポップアップを表示します。
検索基準を使用して、選択リストに表示されるコンプライアンス標準の数を最小化します。
選択し終わったら、「OK」をクリックします。フレームワーク階層画面がリフレッシュされ、新しく組み込んだコンプライアンス標準がフレームワーク・フォルダ要素の下に表示されます。
重要度の編集
選択したコンプライアンス・フレームワーク・フォルダの一部に組み込むコンプライアンス標準をマップした後、指定したこのフォルダの各コンプライアンス標準の重要度を編集できます。
重要度は、このフレームワーク・フォルダ内のこのコンプライアンス標準に対してコンプライアンス・スコアを計算する方法に影響します。
このスコアの計算方法の詳細は、「コンプライアンス・スコアおよび重要度の概要」を参照してください。
コンプライアンス・フレームワークの編集
コンプライアンス・フレームワークの編集機能を使用して、新規コンプライアンス標準ルールをコンプライアンス・フレームワークに追加するか、既存のコンプライアンス・フレームワークの詳細を編集するか、または、コンプライアンス・フレームワークからコンプライアンス標準を削除します。
コンプライアンス・フレームワークを編集するには、次のステップに従います。
使用上のノート
-
コンプライアンス・フレームワークの定義を変更すると、傾向分析に影響を与える場合があります。
-
コンプライアンス・フレームワークに追加するコンプライアンス標準は、「コンプライアンス標準ライブラリ」ページで表示されるように、システム定義およびユーザー定義のコンプライアンス標準になります。
-
コンプライアンス・フレームワークに追加されたリポジトリを変更する場合は、コンプライアンス標準を直接編集するか、「インポート」を使用してコンプライアンス標準を新規の設定で上書きし、既存の評価を無効にします。つまり、変更したコンプライアンス標準が評価済のコンプライアンス・フレームワークに含まれており、評価結果がある場合は、これらの結果は表示されなくなります。このコンプライアンス・フレームワークの評価結果は、次の評価を行った後に再度表示されるようになります。新しい評価には、コンプライアンス・フレームワーク内でのコンプライアンス標準の変更も対象になります。
-
重要度は、このフレームワーク・フォルダ内のこのコンプライアンス標準に対してコンプライアンス・スコアを計算する方法に影響します。
-
1つのコンプライアンス標準を複数のコンプライアンス・フレームワークに追加し、追加されたコンプライアンス・フレームワークごとに異なる重要度を持たせることができます。たとえば、ユーザー・アカウントにパスワードが期限切れになったというフラグを設定する「Check Password Expired」というコンプライアンス標準を設定できます。このコンプライアンス標準は、「All System Passwords Secure」と「30-day Password Validation」という2つのコンプライアンス・フレームワークのメンバーになる場合があります。「All System Passwords Secure」コンプライアンス・フレームワークでは、パスワードのセキュリティが検証され、「30-day Password Validation」コンプライアンス・フレームワークでは、前回このパスワードを設定した日付がチェックされます。
-
「30-day Password Validation 」コンプライアンス・フレームワークでは、「Check Password Expired」コンプライアンス標準の重要度は非常に高いになります。このチェックにより、パスワードが期限切れになることがユーザーに警告されるためです。
-
「All System Passwords Secure」コンプライアンス・フレームワークでは、「Check Password Expired」コンプライアンス標準の重要度は「標準」であり、このコンプライアンス・フレームワークでは、セキュリティ・チェックを実行するその他の追加コンプライアンス標準の方が重要度が高くなります。
-
コンプライアンス・フレームワークの削除
コンプライアンス・フレームワークを削除するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス・フレームワーク」タブをクリックします。
- 削除するコンプライアンス・フレームワークをハイライト表示し、「削除」ボタンをクリックします。
- 「OK」をクリックし、コンプライアンス・フレームワークを削除することを確認します。
使用上のノート
-
コンプライアンス・フレームワークは1つずつ、またはリストで削除できます。コンプライアンス・フレームワークを削除すると、関連するメタデータと評価結果も削除されます。
-
ORACLEによって定義されたコンプライアンス・フレームワークは削除できません。これらは、コンプライアンス・フレームワークのリスト・ページ上のコンプライアンス・フレームワーク名の前にあるロック・アイコンの存在によって示されます。
コンプライアンス・フレームワークのエクスポート
エクスポート機能は、管理リポジトリおよびCloud Controlインスタンス間でユーザー定義のコンプライアンス・フレームワーク定義をトランスポートするためのメカニズムです。エクスポートによって、オペレーティング・システム・ファイルに定義を格納します。エクスポートしたコンプライアンス・フレームワーク定義は、XMLフォーマットであるため、Oracleコンプライアンス標準定義(XSD)フォーマットに準拠しています。コンプライアンス・フレームワークの定義を変更でき、生成されたコンプライアンス・フレームワーク定義を別の管理リポジトリに再インポートできます。
コンプライアンス・フレームワークをエクスポートするには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス・フレームワーク」タブをクリックします。
- エクスポートするコンプライアンス・フレームワークをハイライトします。
- 「アクション」メニューから、「エクスポート」を選択します。
- コンプライアンス・フレームワーク定義をエクスポートするファイル名を指定します。リーフ・レベルのルールおよびコンプライアンス標準がエクスポートされます。
指定するディレクトリおよびファイルにコンプライアンス・フレームワークのXML表現が生成されます。
コンプライアンス・フレームワークのインポート
インポートにより、すでに所有しているコンプライアンス・フレームワークの再使用、Cloud Controlの複数のインスタンス間でのフレームワーク定義の共有、フレームワークのオフライン編集の有効化が可能になります。
コンプライアンス・フレームワークをインポートする前に、インポートするコンプライアンス・フレームワークがファイルに定義されていることを確認します。このファイルには、Cloud Controlにアクセスするために使用しているブラウザからローカルにアクセスできる必要があります。また、インポートするコンプライアンス・フレームワーク定義XMLファイルへのアクセス権限を持っていることも確認します。
ノート:
ルールを含むコンプライアンス標準(または、標準を含むフレームワーク)をUIまたはコマンドライン・インタフェースからインポートする場合は、<ComplianceContent>を含むxmlファイルをルートとしてインポートします。このルート・ファイルには、ルール、標準、フレームワークおよび標準グループのリストが含まれています。
これにより、フレームワークおよび標準の定義が正常にインポートされていることがわかります。さらに、関連するターゲットはすべて、変更された定義に基づいて再評価されます。
コンプライアンス・フレームワークをインポートするには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス・フレームワーク」タブをクリックします。
- 「アクション」メニューから、「インポート」を選択します。
- コンプライアンス・フレームワーク定義(コンプライアンス・フレームワークXSDに従う)をインポートするファイル名を指定します。コンプライアンス・フレームワーク定義がすでに存在する場合に既存の定義をオーバーライドするかどうかを指定します。参照コンテンツをインポートするかどうか、およびすべてのリーフ・レベルのルールおよびコンプライアンス標準がインポートされるかどうかを指定します。ルールのリアルタイム・モニタリング・タイプでは、リアルタイム・モニタリング・ファセットもインポートされます。
- 「OK」をクリックします。
コンプライアンス・フレームワークの参照
コンプライアンス・フレームワークを参照するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス・フレームワーク」タブをクリックします。
- 特定のコンプライアンス・フレームワークの詳細を表示するには、コンプライアンス・フレームワークをハイライトして「詳細を表示」をクリックします。
コンプライアンス・フレームワークの検索
コンプライアンス・フレームワークを検索するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス・フレームワーク」タブをクリックします。
- ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。
- 「検索」をクリックします。
コンプライアンス・フレームワークの評価結果の参照
コンプライアンス・フレームワークの評価結果を参照するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
- コンプライアンス・フレームワークタブをクリックし、「評価結果」タブをクリックします。
- コンプライアンス・フレームワークをハイライト表示し、「詳細を表示」をクリックして、特定のコンプライアンス・フレームワークの詳細を表示します。
結果には、次のものがあります。
-
コンプライアンス・フレームワークで参照されるコンプライアンス標準に対して評価される異なるターゲットの平均コンプライアンス・スコア
-
コンプライアンス・フレームワークで参照される異なるコンプライアンス標準のターゲット評価(クリティカル、警告、コンプライアンス)の数
-
コンプライアンス・フレームワークで参照されるコンプライアンス標準に関連する違反(クリティカル、警告、マイナー警告)の数
コンプライアンス・フレームワークの評価結果の検索
コンプライアンス・フレームワークの評価結果を検索するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
- コンプライアンス・フレームワークタブをクリックし、「評価結果」タブをクリックします。
- ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。
- 「検索」をクリックします。
コンプライアンス・フレームワークのエラーの参照
コンプライアンス・フレームワークのエラーを参照するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
- コンプライアンス・フレームワークタブをクリックし、「エラー」タブをクリックします。
使用上のノート
エラーは、予期しない内部エラーまたはテスト中のエラーです。
通常、評価エラーの原因となるのは構成およびインストールの問題です。次のマニュアルの情報を参照してください。
インストールおよび構成を正しく行ってもエラーが解消されない場合は、オラクル社にサポートを依頼してください。
コンプライアンス・フレームワークのエラーの検索
コンプライアンス・フレームワークのエラーを検索するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
- コンプライアンス・フレームワークタブをクリックし、「エラー」タブをクリックします。
- ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。
- 「検索」をクリックします。
使用上のノート
エラーは、予期しない内部エラーまたはテスト中のエラーです。
通常、評価エラーの原因となるのは構成およびインストールの問題です。次のマニュアルの情報を参照してください。
インストールおよび構成を正しく行ってもエラーが解消されない場合は、オラクル社にサポートを依頼してください。
コンプライアンス標準について
コンプライアンス標準は、チェックまたはルールのコレクションです。それは、制御に従っているかどうかを判断するために、ITインフラストラクチャのセットに対してテストする必要があるコンプライアンス制御をCloud Controlによって表現したものです。
コンプライアンス標準は、階層構造内の次の各要素で構成されています。
- コンプライアンス標準ルール
- ネストしたルール・フォルダおよび個別コンプライアンス標準ルールを含めることができるルール・フォルダ。
ルール・フォルダは、コンプライアンス標準ルールを含む階層構造です。ルール・フォルダには、同じレベルの兄弟に対するルール・フォルダの重要性を示す重要度属性があります。この重要度は、他の兄弟ルール・フォルダからロールアップされているコンプライアンス・スコアの算出時に考慮されます。特定のルール・フォルダでは発生するテストが複数になる可能性がありますが、この方法で、特定のテストを他のテストより大きく重み付けできます。
- 含まれているコンプライアンス標準。コンプライアンス標準には、他のコンプライアンス標準を含めることができます。
コンプライアンス標準で実行可能な操作
- 業界全般の標準を表すことが可能。コンプライアンス標準は、単一のターゲット・タイプに適用可能です。
- 参照構成または認定構成として使用可能
- 企業のベスト・プラクティスを記述したコンプライアンス標準のルールの集合とすることが可能
たとえば、ターゲットがコンプライアンス標準に準拠していない場合、そのターゲットにはコンプライアンス標準へのコンプライアンスがないということになります。
コンプライアンス標準へのアクセス
即時利用可能なコンプライアンス標準(Oracleが提供するものを含む)は、コンプライアンス標準ライブラリ・ページの「コンプライアンス標準」で使用できます。このページにアクセスするには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準」タブをクリックします。
コンプライアンス標準に関連するコンプライアンス標準ルールを表示するには、コンプライアンス標準の名前をクリックし、「詳細を表示」をクリックします。「コンプライアンス標準詳細」ページが表示されたら、ページの左上にある標準の名前を右クリックし、「縮小」、「下をすべて開く」または「下をすべて閉じる」のいずれかを選択します。
ノート: Oracleにより定義されたコンプライアンス標準は変更できません。ただし、類似作成機能を使用して、Oracle提供の標準に類似した標準を作成することはできます。
コンプライアンス標準の一般的な使用上のノート
既存のコンプライアンス標準の上書きチェック・ボックスを選択して、既存のコンプライアンス標準をオーバーライドできます。この結果、コンプライアンス標準の評価時に、コンプライアンス標準が1つ以上のターゲットに関連付けられていることが必要になります。
- リポジトリ・コンプライアンス標準の場合、評価は、管理リポジトリ内のターゲットから収集されたデータに基づいて標準がこのターゲットに関連付けられた後に開始されます。
- WebLogic Serverコンプライアンス標準の場合、評価は、管理エージェント側の標準メトリックがリフレッシュされた後に行われます。Oracle WebLogicドメイン、Oracle WebLogic Java EEサーバーおよびOracle WebLogicクラスタの各ターゲットの場合、リフレッシュは24時間ごとに1回行われます。
- リアルタイム・モニタリング・コンプライアンス標準の場合、管理エージェントでのモニタリングは、コンプライアンス標準がターゲットに関連付けられる際に行われます。監視バンドルに非認証の監視が少なくとも1つ含まれると、違反が発生します。
リポジトリ・ルール固有の使用上のノート
コンプライアンス標準ルールのXML定義でWHERE句を手動で入力する場合、有効なXMLドキュメントを作成するには、<(より小さい)記号を<と表現する必要があります。例: <WhereClause>:status < 100</WhereClause>
監査で使用するためのコンプライアンス標準の設定方法の例
監査者が、データベース・ターゲットがコンプライアンス・フレームワークに準拠していることを検証するには、Cloud Control構造が定義されている必要があります。この構造を指定するステップは次のとおりです。
- スーパー管理者が、コンプライアンス作成者、IT管理者、コンプライアンス監査者という3つのCloud Controlユーザーを作成します。
- スーパー管理者が、コンプライアンス作成者とIT管理者に適したロールおよび権限を割り当てます。
- スーパー管理者が、IT管理者とコンプライアンス監査者に同じターゲット権限を割り当てます。
- コンプライアンス作成者がCloud Controlにログインし、Oracle提供のコンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールを表示します。次に、作成者は適切なコンプライアンス標準ルールを有効化および無効化し、新規コンプライアンス標準ルールを作成します。
- IT管理者が、Cloud Controlにログインし、ターゲット権限のあるターゲットを適切なコンプライアンス標準に関連付けます。
- IT管理者が、特定のターゲットのコンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールの適切な構成パラメータおよび設定を設定します。次に、管理者はこのターゲットからモニタリング・テンプレートを作成し、コンプライアンス標準が必要な、権限のある他のターゲットにこれを適用します。
- コンプライアンス監査者が、Cloud Controlにログインし、コンプライアンス・ダッシュボード、および表示権限のあるエンタープライズ・レベルと各ターゲット・レベルの違反およびエラーを表示します。次に、作成者は違反およびエラーを修正するために必要なアクションを実行します。
コンプライアンス標準での操作
コンプライアンス標準で次の操作を実行できます。
次の各項では、これらの操作について説明します。
ノート: コンプライアンス標準に対する操作を実行する前に、必要な権限があることを確認します。たとえば、コンプライアンス標準を作成する場合、コンプライアンス標準の定義時に含めるコンプライアンス標準ルールへのアクセス権限を持っていることを確認します。コンプライアンス機能に必要なロールおよび権限を参照してください。
コンプライアンス標準の作成
Oracleデータベースのセキュリティ構成など、Oracle提供のコンプライアンス標準を使用することも、独自の基準を作成することもできます。
コンプライアンス標準を作成する前に、コンプライアンス標準およびコンプライアンス標準ルールは、コンプライアンス標準によって参照され、管理リポジトリで定義されていることを確認します。
コンプライアンス標準を作成するには、次のステップに従います。
-
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
-
「コンプライアンス標準」タブをクリックします。
-
「作成」ボタンをクリックします。名前、作成者、標準を適用可能なターゲット・タイプおよび標準タイプの入力を求められます。標準タイプは次のとおりです。
-
リポジトリ
-
リアルタイム・モニタリング
-
エージェント側
「続行」をクリックします。
-
-
結果の「プロパティ」タブで、プロパティ値を入力します。
「追加」をクリックして、この基準を識別するキーワードを追加することも、既存のキーワードを使用することもできます。
-
コンプライアンス標準をさらに定義するには、ページの左上にあるコンプライアンス標準の名前を右クリックします。このメニューから、ルール・フォルダを作成し、ルールおよび組み込まれているコンプライアンス標準を追加できます。
ルール・フォルダを使用して、選択したルール・フォルダに対して評価されたターゲットおよび選択したルール・フォルダに評価されたコンプライアンス標準ルールによって分類された、結果のサマリーを表示できます。
-
「保存」をクリックします。
コンプライアンス標準を定義したら、標準をターゲットに関連付け、ターゲットのタイプ固有の設定を定義します。
-
コンプライアンス標準ライブラリ・ページで、正しいコンプライアンス標準がハイライトされていることを確認します。
-
ターゲットの関連付けボタンをクリックします。
-
コンプライアンス標準に対するターゲットの関連付けページで、「追加」をクリックし、標準に対して評価するターゲットを選択します。
-
「検索と選択: ターゲット」ポップアップで、適切なターゲットを選択します。
-
「選択」をクリックします。
ターゲットをコンプライアンス標準に関連付けたら、ターゲットに関連付けられたパラメータを編集できます。
-
コンプライアンス標準に対するターゲットの関連付けページで、「編集」をクリックします。
-
コンプライアンス標準パラメータのカスタマイズ・ページで、必要に応じてパラメータを変更します。
ノート:
ターゲットのホームページからコンプライアンス標準をターゲットに関連付けることもできます。ターゲットのホームページの左上で、ターゲットの名前を右クリックします。表示されたメニューで、「コンプライアンス」、「標準アソシエーション」の順に選択します。
別のコンプライアンス標準へのコンプライアンス標準の組込み
コンプライアンス標準を含めるページを使用して、1つ以上のコンプライアンス標準を選択し、コンプライアンス標準に組み込みます。このリストは、コンプライアンス標準のターゲット・タイプで事前にフィルタ処理されます。
別のコンプライアンス標準へコンプライアンス標準を組込むには:
使用上のノート
-
コンプライアンス標準は階層的であるため、ツリー内の上位ノードはルート・ノードと呼ばれます。
-
コンプライアンス標準を作成すると、バージョンは1になります。
-
ライフサイクル・ステータスのデフォルトは開発です。これを「本番」に一度のみ更新できます。本番から開発には変更できません。
-
開発
コンプライアンス標準が開発中で、定義された作業はまだ進行中であることを示します。開発モードの間、コンプライアンス標準の完全な編集およびコンプライアンス標準の削除など、コンプライアンス標準のすべての管理機能がサポートされます。ただし、コンプライアンス標準が開発モードの間、その結果は、「コンプライアンス結果」内、およびターゲットや「Cloud Control」ホームページには表示されません。
-
本番
コンプライアンス標準が承認され、本番の品質を持つことを示します。コンプライアンス標準が本番モードの場合、本番ルールへの参照を追加でき、ルールへの参照のみをコンプライアンス標準から削除できるなど、編集機能が制限されます。コンプライアンス標準の表示およびコンプライアンス標準の削除など、他のすべての管理機能はサポートされます。本番のコンプライアンス標準の結果は、ターゲットとコンソールのホームページ、およびコンプライアンス・ダッシュボードに表示されます。本番のコンプライアンス標準は、本番のコンプライアンス標準および本番のコンプライアンス標準ルールのみを参照できます。
本番モードに変更すると、その結果はコンプライアンス・ダッシュボード、ターゲット・ホームページおよび「Cloud Control」ホームページにロールアップされます。本番のコンプライアンス標準は、他の本番のコンプライアンス標準および本番のコンプライアンス標準ルールのみを参照できます。本番のコンプライアンス標準を編集して、本番のコンプライアンス標準および本番のコンプライアンス標準ルールへの参照のみを追加および削除できます。
-
コンプライアンス標準の編集
既存のコンプライアンス標準ルール設定を編集して、コンプライアンス標準をカスタマイズできます。コンプライアンス・スコア計算に追加されたルールの重要度の変更、テンプレートのオーバーライドの回避、デフォルトのパラメータ値のオーバーライド(可能な場合)、およびコンプライアンス標準ルールの評価からのオブジェクトの除外(可能な場合)が可能です。
ノート: Oracle提供のコンプライアンス標準、つまり、Oracleが定義するコンプライアンス標準は編集できません。
コンプライアンス標準を編集するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準」タブをクリックします。
- 編集する基準をハイライト表示し、「編集」ボタンをクリックします。
- 必要に応じて、パラメータを更新します。
- 「保存」をクリックします。
コンプライアンス標準の削除
コンプライアンス標準を削除する前に、コンプライアンス標準がコンプライアンス・フレームワークによって使用されていないことを確認します。すべてのコンプライアンス・フレームワーク内のコンプライアンス標準に対する任意の参照を削除する必要があります。
ノート: Oracle提供のコンプライアンス標準、つまり、Oracleが提供するコンプライアンス標準は削除できません。
コンプライアンス標準を削除するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準」タブをクリックします。
- 削除するコンプライアンス標準をハイライト表示し、「削除」ボタンをクリックします。
- 「OK」をクリックして、基準を削除するかどうかを確認します。
コンプライアンス標準のエクスポート
エクスポート機能は、管理リポジトリおよびCloud Controlインスタンス間でユーザー定義のコンプライアンス標準定義をトランスポートするためのメカニズムです。エクスポートによって、オペレーティング・システム・ファイルに定義を格納します。エクスポートしたコンプライアンス標準定義は、XMLフォーマットであるため、Oracleコンプライアンス標準定義(XSD)フォーマットに準拠しています。コンプライアンス標準の定義を変更でき、生成されたコンプライアンス標準定義を別の管理リポジトリに再インポートできます。
コンプライアンス標準をエクスポートする前に、エクスポートするコンプライアンス標準へのアクセス権限を持っていることを確認します。
コンプライアンス標準をエクスポートするには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準」タブをクリックします。
- エクスポートする基準をハイライト表示します。
- 「アクション」メニューから、「エクスポート」を選択します。
- 基準定義をエクスポートするファイル名を指定します。リーフ・レベルのルールおよびコンプライアンス標準がエクスポートされます。
- コンプライアンス標準のXML表現が生成されます。このファイルは、指定したディレクトリ内にあります。
コンプライアンス標準のインポート
インポート機能では、単一のユーザー定義のコンプライアンス標準、またはユーザー定義のコンプライアンス標準のリストの定義が含まれている、XMLベースのコンプライアンス標準定義ファイルをアップロードします。このアップロードによって、ユーザー定義のコンプライアンス標準またはユーザー定義のコンプライアンス標準のリストが新規作成されます。このコンプライアンス標準は、以前にエクスポートされたものである必要があります。
コンプライアンス標準のXML定義は、「ユーザー定義のコンプライアンス標準のXMLスキーマ定義」に定義されているコンプライアンス標準のXMLスキーマ定義(XSD)に準拠している必要があります。
コンプライアンス標準をインポートする前に、インポートするコンプライアンス標準がファイルに定義されていることを確認します。このファイルには、Cloud Controlにアクセスするために使用しているブラウザからローカルにアクセスできる必要があります。また、インポートするコンプライアンス標準定義XMLファイルへのアクセス権限を持っていることも確認します。
コンプライアンス標準をインポートするには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準」タブをクリックします。
- 「アクション」メニューから、「インポート」を選択します。
- コンプライアンス・フレームワーク定義(コンプライアンス・フレームワークXSDに従う)をインポートするファイル名を指定します。コンプライアンス・フレームワーク定義がすでに存在する場合に既存の定義をオーバーライドするかどうかを指定します。参照コンテンツもインポートするかどうかを指定します。
- 「OK」をクリックします。
既存のコンプライアンス標準の上書きチェック・ボックスを選択して、既存のコンプライアンス標準をオーバーライドできます。結果は次のようになります。
-
コンプライアンス標準をオーバーライドする場合、オーバーライドによって、そのコンプライアンス標準の評価結果のみでなく、すべてのターゲットおよびテンプレートの関連付けも削除されます。
-
上書きされたコンプライアンス標準がコンプライアンス・フレームワークの一部である場合、コンプライアンス・フレームワーク内でコンプライアンス標準が更新されます。ただし、コンプライアンス・フレームワーク内のそのコンプライアンス標準の評価結果は無効化されます。
コンプライアンス標準の参照
コンプライアンス標準を参照するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準」タブをクリックします。
- 特定の基準の詳細を表示するには、基準をハイライト表示し、「詳細を表示」をクリックします。
コンプライアンス標準の検索
コンプライアンス標準を検索するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準」タブをクリックします。
- ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。
- 「検索」をクリックします。
コンプライアンス標準の評価結果の検索
コンプライアンス標準の評価結果を検索するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
- 「コンプライアンス標準」タブをクリックし、「評価結果」タブをクリックします。
- ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。
- 「検索」をクリックします。
コンプライアンス標準のエラーの参照
コンプライアンス標準の評価エラーを参照するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
- 「コンプライアンス標準」タブをクリックし、「エラー」タブをクリックします。
コンプライアンス標準のエラーの検索
コンプライアンス標準のエラーを検索するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
- 「コンプライアンス標準」タブをクリックし、「エラー」タブをクリックします。
- ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。
- 「検索」をクリックします。
使用上のノート
-
評価エラー・ページには、メトリック収集の結果発生したエラー、および最後のポリシー評価中に発生したエラーが表示されます。
-
検索フィルタを使用して、指定する検索基準セットと一致する評価エラーのみを表示します。
-
「メッセージ」列のメッセージをクリックして、エラーを解決するための対策を決定します。
-
まず、評価エラー・ページに、すべての評価エラーが表示されます。
-
通常、評価の結果は、前回の評価結果を上書きします。ただし、評価が失敗またはデータ・プロバイダ収集が失敗した場合は、前回の結果は上書きされず、そのまま残ります。
根本の問題が解決されると、エラーは報告されません。
検索フィルタの例
デフォルトでは、エンタープライズ構成内のすべての評価エラーが結果表に表示されます。ただし、検索基準のセットを指定し、基準と一致する評価エラーのみが結果表に表示されるように検索を実行できます。
たとえば、「ターゲット・タイプ」リストで「ホスト」、「ターゲット名」リストで「次を含む」、その隣の「ターゲット名」テキスト・フィールドで「-sun」を選択し、「実行」をクリックすると、Cloud Controlは、名前に「-sun」を含むホストのコンプライアンス標準ルールの評価エラーのみを結果表に表示します。
コンプライアンス標準のターゲットへの関連付け
コンプライアンス標準を作成したら、標準を1つ以上のターゲットに関連付けることができます。関連付けの一部として、ターゲットに関連する基準の重要度、コンプライアンス標準の評価のステータス、評価ステータスの変更理由およびしきい値などのパラメータをカスタマイズできます。
コンプライアンス標準をターゲットに関連付ける前に、コンプライアンス標準を関連付けるターゲットへのアクセス権限を持っていることを確認します。
コンプライアンス標準をターゲットに関連付けるには、次のステップに従います。
ターゲットに対するコンプライアンス標準の評価をさらにカスタマイズするために、コンプライアンス標準パラメータ(重要度、クリティカルのしきい値および警告のしきい値)を変更できます。コンプライアンス標準内で使用されたコンプライアンス標準ルールで、カスタマイズを行うこともできます。たとえば、「セキュア・ポート」コンプライアンス標準ルールの場合、DFLT_PORTはオーバーライド・パラメータです。ポートのデフォルト値を変更できます。オブジェクトを評価から除外することもできます(たとえば、特定のポートを評価から除外するなど)。
ノート: リアルタイム・モニタリングの場合、ファセット・パターンで使用されているパラメータを変更できます。自動変更管理のリコンシリエーション設定を変更することもできます。
クリティカルのしきい値と警告のしきい値を変更することにより、コンプライアンス標準スコア・イベントを生成する方法を指定します。たとえば、実際のスコアがクリティカルのしきい値より低い場合、クリティカル・スコア・イベントが呼び出されます。
ベスト・プラクティス
コンプライアンス・アソシエーションの実行方法には、テストと編集に対するものと、本番と一括アソシエーションに対するものの2つがあります。
-
標準/ターゲットと標準ルール、またはルール・フォルダ/ターゲット・アソシエーション設定のテストと編集目的の場合、この項での前述のようにターゲットとコンプライアンス標準を関連付けます。
コンプライアンスのUIを使用して次のことができます。
-
アソシエーションをテストし、テストが完了したら削除します。
-
重要度、評価ステータスおよびしきい値についてアソシエーションを編集します。
ノート: アソシエーションは、「管理グループ」ページおよび「テンプレート・コレクション」ページを使用して編集できません。
-
-
本番および一括アソシエーションの場合、「管理グループ」ページおよび「テンプレート・コレクション」ページを使用してターゲットを関連付けます。
「設定」メニューから、「ターゲットの追加」、「管理グループ」の順に選択します。「アソシエーション」タブをクリックします。
階層内の各管理グループは、メンバーシップ基準によって定義されているため、ターゲットはグループのメンバーシップ基準を満たす場合にのみグループに追加されます。したがって、ターゲットがグループに正常に追加されると、そのグループの適切なコンプライアンス標準に自動的に関連付けられます。これによって、ターゲットの多数のコンプライアンス標準への関連付けが容易になります。
グループ・ターゲットへのコンプライアンス標準の関連付け
コンプライアンス標準をグループ・ターゲットに関連付ける前に、コンプライアンス標準を関連付けるグループ・ターゲットへのアクセス権限を持っていることを確認します。詳細は、コンプライアンス機能に必要なロールおよび権限を参照してください。
次のステップを実行します。
リアルタイム・モニタリング・コンプライアンス標準の警告の表示
リアルタイム・モニタリング・コンプライアンス標準をターゲットに関連付ける場合、ターゲットでリアルタイム・モニタリングを有効化するための設定ステップが実行されていなかったり、構成に不整合がある場合があります。この場合、「ターゲットの関連付け」画面に警告が表示されます。この画面にアクセスするには、コンプライアンス標準を選択し、「ターゲットの関連付け」ボタンを選択します。警告が存在する場合、ターゲット・アソシエーションの上にあるリンクに警告アイコンが表示されます。このリンクをクリックすると、このコンプライアンス標準に関する現在の警告がすべてリストされた画面が表示されます。
モニタリング対象のホスト/ターゲット上の構成問題を解決したり、ルール/ファセットのコンテンツを修正することにより、警告はすべて修正できます。根本の問題が解決されると、これらの警告は自動的にクリアされます。
この警告のリストは、「リアルタイム監視」ページ(「Enterprise」メニューから「コンプライアンス」、「リアルタイム監視」の順に選択)から入手することもできます。ここでは、監視を参照するために3つのタイプのレポートの1つを選択できます。画面の下半分には、リアルタイム・モニタリングに関連するすべてのターゲットおよびコンプライアンス標準に対してアクティブな警告がすべて表示されます。
セキュリティ・メトリックの有効化
セキュリティ・コレクションはデフォルトでは無効であるため、セキュリティ・コンプライアンス標準およびレポートなどのセキュリティ機能を使用する前に有効にする必要があります。セキュリティ・メトリックを有効にするには、次のステップに従います。
- 「エンタープライズ」メニューから、「モニタリング」、「モニタリング・テンプレート」の順に選択します。
- 「検索」領域で「オラクル社提供のテンプレートとオラクル社認定のテンプレートを表示」を選択し、「実行」をクリックします。
- 「オラクル社認定-データベース・セキュリティ構成メトリックの有効化」を選択し、「適用」をクリックします。
- 「監視テンプレートオラクル社認定-データベース・セキュリティ構成メトリックの有効化の適用: 一般」ページで「追加」をクリックします。
- 「検索と選択: ターゲット」ページで目的のデータベース・インスタンスを選択し、「選択」をクリックします。
- 「監視テンプレートオラクル社認定-データベース・セキュリティ構成メトリックの有効化の適用: 一般」ページの「コピー先ターゲット」リージョンで、目的のデータベース・インスタンスを選択し、「OK」をクリックします。
「OK」をクリックすると、「モニタリング・テンプレート」ページに確認メッセージが表示されます。
コンプライアンス標準の作成時の考慮事項
コンプライアンス標準は、1つ以上のコンプライアンス標準ルールを参照します。コンプライアンス標準を作成する際には、標準は、1つ以上の関連するコンプライアンス・フレームワークに適切にマッピングできるほど十分に詳細である必要があります。たとえば、Oracleの汎用コンプライアンス・フレームワークに存在する、次のようなコンプライアンス・フレームワーク構造を考えてみます。
-
変更および構成管理(コンプライアンス・フレームワーク・サブグループ)
-
データベース変更(コンプライアンス・フレームワーク・サブグループ)
-
Oracle Databaseを構成するためのベスト・プラクティス(コンプライアンス標準)
-
Oracle RACデータベースを構成するためのベスト・プラクティス(コンプライアンス標準)
-
Oracleプラガブル・データベースを構成するためのベスト・プラクティス(コンプライアンス標準)
-
-
このコンプライアンス・フレームワーク構造の一部にマップされる必要がある多くのコンプライアンス標準が存在し、それぞれに、この特定の要件に対処するための独自のルールがあります。ある標準は、構成設定が正しく設定されていることをチェックします。別の標準は、構成設定が変更されたかどうかをリアルタイムでチェックするために使用されます。
この例では、データベース変更コンプライアンス・フレームワーク・サブグループは、多くの異なるタイプのターゲットに関連しています。すべてのOracle Database、Oracle RACデータベースおよびOracleプラガブル・データベースには、すべてが保護される必要がある独自のタイプの構成があります。これらのターゲット固有の構成をモニターするために作成されたすべての標準は、同じデータベース変更サブグループにマップされます。
コンプライアンス標準が、既存および将来のコンプライアンス・フレームワークにマップできるように詳細な方法で構造化される場合、ルール内の違反をロールアップし、コンプライアンス・フレームワークのスコアに正しく影響を与えることができます。
コンプライアンス標準ルール・フォルダについて
ルール・フォルダは、コンプライアンス標準内の類似したコンプライアンス標準ルールのグループ化に使用されるオプションの階層構造です。コンプライアンス標準に個別コンプライアンス標準ルールを追加したり、標準内に多数のルールが存在する場合はこれらをグループ化できます。コンプライアンス標準内の重要度設定がそれぞれ異なる複数のルール・フォルダに同じコンプライアンス標準ルールを追加できます。コンプライアンス標準内に、ルール・フォルダをネストできます。
ルール・フォルダには、同じレベルの兄弟に対するルール・フォルダの重要性を示す重要度属性があります。この重要度は、他の兄弟ルール・フォルダからロールアップされているコンプライアンス・スコアの算出時に考慮されます。特定のルール・フォルダでは発生するテストが複数になる可能性がありますが、この方法で、特定のテストを他のテストより大きく重み付けできます。
次の各トピックでは、コンプライアンス標準ルール・フォルダについて説明します。
ルール・フォルダの作成
ルール・フォルダを作成するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します
- 「コンプライアンス標準」タブをクリックします。
- コンプライアンス標準ライブラリ・ページで、コンプライアンス標準をハイライトし、「編集」をクリックします。
- プロパティページで、コンプライアンス標準の名前を右クリックします。標準の名前は、ページの左上隅にあります。
- 「ルール・フォルダの作成」を選択します。
- フォルダの名前を入力し、「OK」をクリックします。
- 「プロパティ」ページで、説明、参照URLおよび重要度を指定します。コンプライアンス・スコアおよび重要度の概要を参照してください。
コンプライアンス標準内のルール・フォルダの管理
フォルダを作成し、フォルダにコンプライアンス標準ルールを移入したら、フォルダについて次のアクションを実行できます。
-
ツリー内のルール・フォルダ・ノード、ルール参照ノード、およびコンプライアンス標準参照ノードを並べ替えるか、これらのノードを削除して、ツリー構造を編集します。
-
任意のノード(最上位レベルのコンプライアンス標準ノードを除く)・オブジェクトを選択し、コンテキスト・メニューから「削除」メニュー・アイテムをクリックします。削除オプションは、ルート・ノードでは使用できません。複数のオブジェクトを選択し、「削除」をクリックして、複数のノードを削除します。
コンプライアンス標準ルールについて
コンプライアンス標準ルールは、構成データの変更がコンプライアンスに影響するかどうかを決定するためのテストです。テストの結果に基づいて、コンプライアンス・スコアが計算されます。これらのルール・コンプライアンス・スコアがロールアップされてコンプライアンス標準スコアが計算されることにより、このスコアをコンプライアンス・フレームワーク・スコアとともにロールアップおよびレポートできるようになります。
3つのタイプのコンプライアンス標準ルールがあります。
-
エージェントの構成の問題の検出に使用します。これにより、Security Technical Implementation Guide (STIG)のセキュリティ仕様の実装が可能になります。エージェント側のルールでは、基礎となる構成拡張ターゲット用に収集された結果データに基づく、ターゲットの違反が生成されます。
-
構成の一貫性ルール
コンポジット・ターゲット内にある類似ターゲット・タイプのターゲットの一貫性を判定します。たとえば、あるユーザーが15個のデータベースで構成されるクラスタ・データベースを持っているとします。そのユーザーはクラスタ・データベース比較テンプレートを構成一貫性として使用して、クラスタ内で変更された可能性のあるデータベースをフラグ付けできます。
-
構成ドリフト・ルール
類似ターゲット・タイプのターゲットの偏差を判定します。たとえば、あるユーザーがモニタリング中のデータベースが10台あるとします。そのユーザーは「初期化パラメータ・ファイルの権限」コンプライアンス標準ルールがすべてのデータベースに渡って同じであることを確認する必要があります。この偏差は、データベース構成が更新されたときに発生する可能性があります。
-
手動ルール
自動的に実行できないチェックを説明できるため、これらのタイプのチェックをコンプライアンス・フレームワークで説明できます。
たとえば、一般的なセキュリティ・チェックは、データ・センターへのセキュアなアクセスを確保することです。標準がターゲットに関連付けられている場合、各手動ルールにはそれぞれ1つの違反があります。ユーザーは、ルールのポジティブ・ステータスに手動でアテストする必要があります。つまり、タスクを担当する個人は、タスクを実行している必要があります。コンプライアンス・フレームワークは、手動チェックの違反を報告できるように、違反がいつ、だれによってクリアされたかを記録します。
-
欠落したパッチ・ルール
適切なターゲットに適用されていないパッチの検出に使用されます。このルールは、コンプライアンス結果UIおよび後続のコンプライアンス・ダッシュボード・リージョンに表示される違反を生成します。ロールアップ違反カウントはダッシュボード・リージョンに表示されます。ドリルダウンして違反の詳細を調べて、適切なターゲットに不足しているパッチを適用することで問題を修正できます。
-
ルールがパッチのリストに基づいている場合、ルールはターゲットにそのパッチが適用されていないことを確認します。適用されているパッチがある場合、違反は生成されません。適用されているパッチがない場合、適用されていないパッチを表示する1つの違反が生成されます。
-
パッチ番号はOracle推奨パッチまたは手動で入力したパッチを指します。
-
パッチが適用された後、対応するORACLE_HOME構成がアップロードされます。ターゲットに対するすべての関連する欠落したパッチ・ルールが再評価されます。
-
「欠落したパッチ」ルールを作成した後、欠落したパッチ・ルールを「リポジトリ」タイプのコンプライアンス標準に追加できます。次に、標準を選択して「ターゲットの関連付け」ボタンをクリックすることで、標準をターゲットに関連付けることができます。アソシエーションにおいて、欠落したパッチ・ルールが適用されたターゲット上で評価されます。
-
欠落したパッチ・ルールを含む標準がグループに関連付けられている場合、グループに新しいターゲットを追加したとき、新しいターゲットでのパッチの欠落が自動的に評価されます。
-
-
リアルタイム・モニタリング・ルール
構成データが格納されるオペレーティング・システム・エンティティおよびデータベース・レベル・エンティティをモニターします。リアルタイム・モニタリング・ルールは、モニタリングするエンティティ、モニタリングするユーザー・アクション、モニタリングに適用する任意のタイプのフィルタを定義します。モニタリングは、変更がいつ行われたか、誰が変更を行ったか、およびどのようなプロセスによって変更が行われたかに基づいてフィルタ処理できます。
リアルタイム・モニタリング・ルール定義には、指定したターゲット・タイプ、ターゲット・プロパティおよびエンティティ・タイプに対するモニタリングで何が重要かを判別するのに使用するファセットが含まれています。ファセットは、ターゲット・タイプの属性を構成するパターンの集合です。たとえば、ホスト・ターゲット・タイプの重要な構成ファイルをすべてリストするファセットを定義するよう選択できます。これらの構成ファイルが変更されると、ホストが不安定になる可能性が非常に高くなります。また、DBAユーザーであるユーザーをすべてリストするファセットを作成することもできます。
リアルタイム・モニタリング・ルールは、1つ以上のターゲットに関連付けられたコンプライアンス標準の一部にすることができます。モニタリングは、ファイル、プロセス、ユーザー、レジストリなどの任意のオペレーティング・システム・レベル・エンティティで行うことができます。リアルタイム・モニタリング・ルールでは、ルールによって取得された監視を自動的に調整するかどうかを指定することもできます。この調整により、監視されたアクションが認可されていたかどうかを確認します。
変更リクエスト管理調整では、オープン変更リクエストを、ターゲットで実行されたアクションと比較します。予期したアクションが実際のアクションと一致する場合、これらのアクションが認可され、一致しない場合、これらは認可されません。認可は手動で行うこともできます。すべての監視は、ルール、ターゲットおよびユーザーによって取得およびバンドルされます。監視データ収集の頻度には属性を設定できます。
-
管理リポジトリのメトリック収集データに対してチェックを実行するために使用されます。
1つまたは複数のターゲットの構成状態をチェックするのに使用します。構成アイテムが実際に所定の状態を満たすと判断され、ルールのテストが違反を特定するのに失敗した場合、ルールはコンプライアンスと言います。それ以外の場合、ルールに1つ以上の違反がある場合、ルールは非コンプライアンスと言います。コンプライアンス標準ルールのテスト条件によって評価されるデータソースは、Cloud Control管理リポジトリに対する問合せに基づきます。コンプライアンス標準ルールのテスト条件は、基本的なメトリック/問合せの列の値またはSQL式またはPL/SQL関数に基づくしきい値の条件を使用して実装できます。ルールを使用するには、1つ以上のコンプライアンス標準にルールを関連付ける必要があります。これにより、コンプライアンス標準は1つ以上のターゲットに関連付けられます。この結果、このルールをこれらのターゲットに対して効率的に評価できるようになります。
コンプライアンス標準ルールでの操作
次の各項では、コンプライアンス標準ルールで実行できる操作について説明します。
- リポジトリのコンプライアンス標準ルールの作成
- リアルタイム監視のコンプライアンス標準ルールの作成
- エージェント側ルールの作成
- 手動ルールの作成
- コンプライアンス標準ルールの類似作成
- コンプライアンス標準ルールの編集
- コンプライアンス標準ルールの削除
- コンプライアンス標準ルールのエクスポート
- コンプライアンス標準ルールのインポート
- コンプライアンス標準ルールの参照
- コンプライアンス標準ルールの検索
ノート:
コンプライアンス標準ルールに対する操作を実行する前に、必要な権限があることを確認します。詳細は、コンプライアンス機能に必要なロールおよび権限を参照してください。リポジトリのコンプライアンス標準ルールの作成
収集された構成データに基づいてターゲットが必要な構成状態にあることを確認するためのリポジトリのコンプライアンス標準ルールを作成するには、次のステップに従います。
リポジトリ・ルールに関する追加のノート
-
ルールはすべてグローバル・ルール・ライブラリに表示され、すべてのユーザーが参照できます。
-
コンプライアンス基準ルールの作成後、そのルールは自動的に評価されません。ルールは、使用する前にコンプライアンス標準に関連付ける必要があります。コンプライアンス標準が1つ以上のターゲットに関連付けられている場合のみ、ルールの評価が行われます。ルールを直接評価することはできません。
-
1つのルールを複数のコンプライアンス標準に関連付けることができます。
-
このルールが関連付けられているコンプライアンス標準を介してルールの様々な属性をカスタマイズできます。これらのカスタマイズは「コンプライアンス標準」画面で行います。コンプライアンス標準ごとにカスタマイズできるこれらの属性の1つに、この標準に関連するルールの重要度があります。
-
ユーザー定義コンプライアンス基準ルールは特権ユーザーによって定義されるため、コンプライアンス基準ルールを変更できるのは特権ユーザーのみです。違反結果は、すべてのユーザーが表示できます。
-
このユーザー定義のコンプライアンス標準ルールを他の特権ユーザーと共有するには、これらのユーザーが管理リポジトリにコンプライアンス標準ルールをインポートできるように、(エクスポート機能を使用して)XMLスキーマ定義を指定します。
-
「説明」、「影響」および「推奨」情報の参照中のスクロールを最小限に抑えるには、1行当たりのテキストを50文字に制限します。50を超える文字数が必要な場合は、改行してテキストを続けます。
-
コンプライアンス標準ルール・ウィザード内の各ページに関する具体的な手順の詳細は、コンテキスト依存ヘルプを参照してください。
-
コンプライアンス標準ルールのXML定義でWHERE句を手動で入力する場合、有効なXMLドキュメントを作成するには、<(より小さい)記号を<と表現する必要があります。次に例を示します。
<WhereClause>:status < 100</WhereClause>
リアルタイム・モニタリング・コンプライアンス標準ルールの作成
ファイル変更、ユーザー・アクセスおよびプロセス・アクティビティなど、ターゲットで発生したユーザー・アクションをモニタリングするためのリアルタイム・モニタリングのコンプライアンス標準ルールを作成するには、次のステップに従います。
-
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
-
「コンプライアンス標準ルール」タブをクリックします。
-
「作成」ボタンをクリックします。
-
「ルールの作成」ポップアップで、「リアルタイム・モニタリング」タイプを選択します。
-
「OK」をクリックします。
-
次の画面で、ルールの複数の主要属性を入力するよう求められます。
-
ルール名
一意のルール名を入力します。
-
コンプライアンス・ルールの状態
このルールの状態が開発と本番のどちらであるかを設定します。開発とは、ルールがまだ定義またはチューニング中であり、ターゲットで使用する準備がまだ整っていないことを意味します。ルールを本番に昇格した後、ルールを開発に戻すことはできません。
-
重大度
ルールには、重大度レベルがあり、クリティカル(ルールが違反している場合の深刻な問題)、警告(違反している場合の深刻ではない問題)、またはマイナー警告(違反している場合のマイナーな問題)のいずれかです。重大度は、このルールがコンプライアンス標準に追加されるときにこのルールに設定される可能性がある重要度とともにコンプライアンス・スコアに影響します。
-
適用可能対象
このルールが適用されるターゲット・タイプ。
-
エンティティ・タイプ
モニター対象のターゲットの一部であるオブジェクトのタイプ。たとえば、オペレーティング・システム(OS)の場合、エンティティ・タイプにはOSファイル、OSプロセスまたはOSユーザーなどがあります。データベースの場合、エンティティ・タイプにはデータベース表、データベース機能、データベース・プロシージャまたはデータベース・ユーザーなどがあります。
-
ターゲット・プロパティ・フィルタ
このルールがコンプライアンス標準に関連付けられているときにこのルールを適用可能なターゲットを決定する特定のターゲット・プロパティを指定できます。このようなプロパティには、オペレーティング・システム、ターゲット・ライフサイクルの状態、バージョンおよびプラットフォームがあります。たとえば、Linux OSなど、このルールにターゲット・プロパティ・フィルタを指定すると、このルールはLinuxオペレーティング・システムに対してのみ適用可能になります。
-
説明
ルールの説明
-
論理
このルールの確認対象、およびこのルールの違反による影響を表すテキスト。
-
詳細URL
コンプライアンス制御を詳細に説明するドキュメントへのURL。多くの場合、これらのドキュメントはコンテンツ管理システムに格納できます。
-
メッセージ
監視が非認証であると確認されたときに違反に使用されるメッセージ。
-
メッセージのクリア
前の違反がクリアされた後にこの違反に使用されるメッセージ。
-
キーワード
キーワードは、データを様々なレポートに編成する方法を制御できるようルールに割り当てることができます。
詳細は、「リアルタイム・モニタリング・ルールのターゲット・プロパティ・フィルタの重要度」を参照してください。
-
-
「次」をクリックします。
-
次のページで、このルールに対してモニターするファセットを選択します。すでに定義されているファセットを組み込むことも、このルール作成に従ってインラインで新規ファセットを作成することもできます。ファセットは、モニターするパターンの単なるリストです。たとえば、ファイル、ユーザー名、プロセスなどのリストです。ファセットについてはこの後、後半のリアルタイム・モニタリング・ファセットに関する項で説明します。
-
既存のファセットを組み込むか新規ファセットを追加した後に「次」をクリックします。
-
次の画面で、モニターするアクションを選択します。選択するアクションは、ルールに対して選択するエンティティ・タイプによって異なります。たとえば、OSファイル・モニタリングの場合、ファイルの作成、変更、削除、名前変更などのアクションをモニタリングできます。OSユーザーモニタリングの場合、ログイン、ログアウト、SU、SSHなどのアクションをモニタリングできます。ルールに対してモニターするアクションを少なくとも1つ選択する必要があります。
詳細は、「モニターする処理タイプの選択」を参照してください。
-
「次」をクリックします。
-
次の画面で、必要に応じて、モニタリング用のフィルタを構成できます。フィルタは、アクションを監視するタイミングまたは条件を制限するために使用します。たとえば、ファイル・ファセットFILES1をモニタリングしているときに、特定のユーザーのリストによって行われたファイル変更のみが取得されるようにフィルタを追加したり、特定の時間ウィンドウに変更が行われた場合、またはファイルを変更するために特定のプロセスが使用された場合に設定することもできます。フィルタはまた、異なるエンティティ・タイプのファセットでもあります。OSファイル・エンティティ・タイプをモニタリングしている場合、OSユーザー、OSプロセスまたは時間ウィンドウのファセットをフィルタとして適用できます。既存のファセットを組み込むことも、ルール作成に従ってインラインで新規ファセットを作成することもできます。ルール・ウィザードを取り消しても、インラインで作成したファセットはファセット・ライブラリ内にそのまま存在します。
詳細は、「リアルタイム・モニタリング・ルールのフィルタとしてのファセットの使用」を参照してください。
-
「次」をクリックします。
-
次の画面で、監視が管理エージェントで検出されたときの処理方法に関連する複数の設定を構成できます。
-
監視を手動で認証
-
変更リクエスト管理システムを使用して監視を自動認証
-
収集の設定
詳細は、「監査ステータスの構成」および「監視バンドルの存続期間の制御」を参照してください。
-
-
「次」をクリックします。
-
この画面で、ルールの設定を確認できます。
-
「終了」をクリックし、ルールを保存し、ルール・リスト・ページに戻ります。
リアルタイム・モニタリング・ルールのターゲット・プロパティ・フィルタの重要度
ルールの作成時に、ルールのターゲット・タイプを選択する必要があります。管理エージェントのリアルタイム・モニタリング機能は、オペレーティング・システムおよびオペレーティング・システムのバージョンに一部依存しているため、ユーザーはルールの基準の設定が許可されている必要があります。ターゲットはターゲット・タイプごとに異なる可能性があるため、ファセットのパターンも異なる可能性があります。たとえば、Microsoft Windows上のOracleデータベースは、UNIXオペレーティング・システム上のそれと同じではありません。
ターゲット・プロパティ・フィルタが設定されていない場合、すべてのルールのオプションが使用可能になり、target-csのアソシエーション時にターゲットの設定が一致しないと、ルールおよびファセットは無視されます。たとえば、プラットフォーム名のみを設定し、バージョンを設定しない場合は、そのプラットフォームのすべてのバージョンに共通のオプションのみが使用可能になります。
ルールの作成時に選択可能なファセットのリストは、ファセットの作成時に設定されるターゲット・プロパティ別にフィルタされます。たとえば、LinuxまたはHPUX上で機能するファセットFACET1があり、Windowsに対するルールを作成する場合、FACET1はそのルールには選択できません。これは、モニタリング・ファセットを選択する場合と、ファセットをフィルタとして使用する場合の両方に当てはまります。ただし、LinuxまたはHPUXのいずれかでルールを作成する場合は、ルールの基準が少なくともファセットの基準と重複するため、FACET1は使用可能になります。
リアルタイム・モニタリング・ルールのフィルタとしてのファセットの使用
ルールを作成する際、ファセットの使用方法は2つあります。最初の方法は、ファセットを使用して、ルールでモニターされるエンティティを決定することです。2つ目の方法は、ファセットをフィルタとして使用して、管理エージェントによって検出されたアクティビティ全体に適用することです。
同じファセットをあるルールではモニタリング・ファセットとして使用し、別のルールではフィルタ・ファセットとして使用できます。この利点は、たとえば、管理ユーザーを定義するためにパターンの集合を定義した後、その集合を再定義することなく、様々な方法で使用できることです。
ルール内のフィルタは、取得され、Cloud Controlにレポートされる監視の数を減らすために設定されます。フィルタが定義されていない場合、ルールで選択されたモニタリング・ファセットに関連するすべての監視が取得されます。ファセットをフィルタとして選択した場合、デフォルトでは、一致する属性を持つ監視のみが含まれます。次のITコンプライアンス制御の例は、フィルタリングの例を示しています。
IT制御: 本番時間中に、管理者によるクリティカルOS構成ファイルへの変更をモニターします。
このIT制御を実装するには、次のようなコンプライアンス基準を作成します。
-
ルールを作成し、クリティカルOS構成ファイルをすべてカバーするパターンを含むモニタリング・ファセットとして、ファイル・ファセット「クリティカルOS構成ファイル」を選択します。
-
取得するアクション・タイプとして、「コンテンツ変更」を選択します。
-
ファセット「管理者」を選択して、OSユーザー・フィルタを追加します。このファセットは、管理者とみなされるすべてのOSユーザー・アカウントを記述するパターンをリストします。
-
ファセット「本番時間」を選択して、時間ウィンドウ・フィルタを追加します。これは、本番時間とみなされる週のうちの時間を記述するパターンをリストします。たとえば、毎日4am-2pm PSTなどです。
管理エージェントがクリティカルOS構成ファイル内のパターンにコンテンツ変更を確認すると、エージェントは、その変更が本番時間中に発生し、管理者のファセットに記述されているユーザーによって行われたものである場合にのみ、変更をCloud Controlにレポートします。また、フィルタを反転して、管理者グループ以外のユーザーまたは本番時間以外の変更のみがレポートされるようにすることもできます。
フィルタの使用方法の詳細は、前述のリアルタイム・モニタリング・ルールの作成に関する項を参照してください。
監査ステータスの構成
各監視には監査ステータスがあります。この監査ステータスは時間が経つにつれて変化する場合があり、手動で設定することもCloud Controlによって自動的に設定することもできます。監査ステータスの管理方法は、リアルタイム・モニタリング・ルールの作成または編集時に構成します。
ウィザードの設定ページでルールを作成する場合、このルールに対して検出されたすべての監視の監査ステータスは、ユーザーから手動で取得するか、変更リクエスト管理サーバーとのコネクタ統合を使用して自動的に取得するかを選択するオプションが用意されています。
監査ステータスをルールに手動で設定することを選択する場合、2つのオプションを使用できます。
-
このルールに対して検出されたすべての監視がデフォルトで非監査、認証済または非認証になるようにデフォルト監査ステータスを設定できます。非監査とは、これらが確認されておらず、監視が良好と不良のどちらであるか決定されていないということを意味します。
-
手動認証時に、情報イベントを選択できます。これを使用して、新規監視バンドルの発生時にインシデント・マネージャで情報クラスの新規イベントを作成します。このイベントに基づいてイベント・ルールを作成することにより、監視バンドルに基づいて通知を送信したり、インシデント・マネージャが実行できる他の任意のアクションを実行できます。
変更リクエスト管理サーバーを使用して自動リコンシリエーションを使用することを選択する場合、変更管理用のCloud Controlコネクタを設定するステップに従う必要があります。詳細は、「リアルタイム・モニタリングのための追加設定」を参照してください。
コネクタが構成されると、ルール作成ウィザードのこの設定ステップに、このルールに使用するコネクタを選択するためのドロップダウンが表示されます。監視の属性およびオープンな変更リクエストに定義されている監視に基づいて、一致するオープンな変更リクエストが存在する場合、監視は自動的に認証済だとみなされ、そうでない場合、非認証だとみなされます。
自動リコンシリエーションを使用する場合、監視の認証を許可した変更リクエスト管理サーバーの変更リクエストに認証済監視の詳細を注釈し戻すよう指定する追加オプションが用意されています。
同じ監視バンドルに複数の監視が属することが可能です。監視はグループの一部ですが、認証済または非認証の決定は、グループ・レベルではなく個別の監視に対して行われます。グループに非認証としてマークされた監視が少なくとも1つ含まれている場合、そのグループは違反とみなされ、このグループの違反に対してイベントまたはインシデントが発生する可能性があります。
監視バンドルの存続期間の制御
監視バンドルとは、比較的短い期間内に、同じターゲット上の同じルールに対して、同じユーザーによって発生する監視の論理グループです。3つの要素は、管理エージェントがCloud Controlサーバーへ返す前に監視をグループ化する方法を決定する要素であるため、ユーザーが構成することはできません。
ただし、ルールを作成するユーザーは、次の3つの変数を構成できる必要があります。
-
アイドル・タイムアウト: 特定のターゲットに関する特定のルールに対するユーザーの最後のアクティビティ以降にアクティビティが実行されなかった時間の長さ。このユースケースは、ユーザーがサーバーにログインし、いくつかのファイルの変更を開始して、その後15分間ファイルが変更されない状態です。この15分の待ち時間がアイドル・タイムアウトです。このアイドル・タイムアウト時間を過ぎると、現在の監視バンドルがクローズしてCloud Controlサーバーに送信されます。次回、新規監視が検出されると、新規グループが開始され、プロセスが再度開始されます。
-
グループの最大存続期間: ユーザーがアイドル・タイムアウトを15分間に設定し、ホスト上のユーザーが10分ごとに、無期限に(たとえばスクリプトを利用して、あるいは手動で)1つのファイルを変更したとすると、監視バンドルは終了しないままとなり、Cloud Controlサーバーに送信されてレポート/処理されることもありません。グループに最大存続期間を設定すれば、指定された最大時間までしかグループを累積で存続させないように管理エージェントに指示することができます。たとえば、最大存続期間を30分、または1時間に設定できます。
-
バンドル内の最大監視数: 1つのアクティビティによって多数の監視が検出され、そのアクティビティによってルールがトリガーされる場合、監視が多すぎるときはすべての監査をまとめてバンドル化しない方がよいことがあります。バンドルには管理ライフサイクルがあり、Cloud Controlサーバーに到達した後に、このライフサイクル内で監視を認証済または非認証などに設定できます。1つの監視バンドルに何万もの監視が含まれていると、管理が困難になります。
ルールを作成しているユーザーは、バンドル化を無効にするよう選択することはできませんが、Cloud Controlサーバーへのレポートの遅延を減らす必要がある場合は、アイドル・タイムアウトとバンドルの最大存続期間により低い値を設定できます。
イベント/インシデント・サブシステムでは、個別の監視ではなく監視バンドルのみが追跡されます。1つの監視が非認証とマークされている場合、バンドル全体が違反になります。このバンドルは、インシデント管理イベントによって追跡されるエンティティになります。
監視バンドルは管理エージェントで構築され、前述の基準に応じてバンドルが完了した場合のみCloud Controlサーバーに送信されます。ほとんどのコンプライアンスのユースケースでは、結果を即時に参照する必要がないため、これは許容範囲です。何が行われているかを理解したり監視を管理しやすくする上でより重要なのは、結果を取得してまとめてバンドル化することです。
複数のルールで同じファセットを使用しているために、または同じホスト上の複数のターゲットがエンティティを共有する同じファセットをモニターしているために、1つの監視が管理エージェントで複数のバンドルに属している場合、最初のバンドルがそのいずれかの終了条件(アイドル・タイムアウト、グループの最大存続期間、またはグループ・エントリの最大数)に達すると、共有の監視を含むバンドルはすべて同時に終了します。
監視バンドルの存続期間を制御するには、リアルタイム・モニタリング・ルールを作成してルール作成ウィザードの「設定」ページで適切な設定を行う方法に関する前述の項を参照してください。
モニターする処理タイプの選択
ルールを作成する際、モニターしてCloud Controlにレポートすることが重要な監視またはユーザー処理のタイプを決定できます。管理エージェントには、エンティティ・タイプごとに使用できる特定の監視セットが用意されています。一部のオプションは、オペレーティング・システムのプラットフォームまたはバージョンに固有です。これらのオプションを1つ以上選択できます。
選択可能な監視タイプは、ルールに対して選択されたターゲット・プロパティとターゲット基準によっても制限される場合があります。たとえば、いくつかのオペレーティング・システムには、すべてのファイル・モニタリング機能が備わっていない可能性があります。使用可能な監視タイプのリストを構築する際には、ターゲット・タイプ、エンティティ・タイプおよびターゲット・プロパティをすべて考慮して使用可能な監視タイプが決定されます。
ルールでモニターする監視タイプを選択するには、次のステップを実行します。
リアルタイム・モニタリング・ルールに関する追加のノート
-
ルールはすべてグローバル・ルール・ライブラリに表示され、すべてのユーザーが参照できます。
-
コンプライアンス基準ルールの作成後、そのルールは自動的に評価されません。ルールは、使用する前にコンプライアンス標準に関連付ける必要があります。コンプライアンス標準が1つ以上のターゲットに関連付けられている場合のみ、ルールの評価が行われます。ルールを直接評価することはできません。
-
1つのルールを複数のコンプライアンス標準に関連付けることができます。
-
このルールが関連付けられているコンプライアンス標準を介してルールの様々な属性をカスタマイズできます。これらのカスタマイズは「コンプライアンス標準」画面で行います。コンプライアンス標準ごとにカスタマイズできるこれらの属性の1つに、この標準に関連するルールの重要度があります。
-
ユーザー定義コンプライアンス基準ルールは特権ユーザーによって定義されるため、コンプライアンス基準ルールを変更できるのは特権ユーザーのみです。違反結果は、すべてのユーザーが表示できます。
-
このユーザー定義のコンプライアンス標準ルールを他の特権ユーザーと共有するには、これらのユーザーが管理リポジトリにコンプライアンス標準ルールをインポートできるように、(エクスポート機能を使用して)XMLスキーマ定義を指定します。
-
1行当たりのテキストを50文字に制限することにより、「説明」、「影響」および「推奨」情報の参照中のスクロールを最小限に抑えることができます。50を超える文字数が必要な場合は、改行してテキストを続けます。
-
コンプライアンス標準ルール・ウィザード内の各ページに関する具体的な手順の詳細は、コンテキスト依存ヘルプを参照してください。
-
OSファイル・エンティティ・タイプのモニターを選択する場合、アクション・タイプの1つとして「ファイル・コンテンツの変更(成功) - ファイルのコピーのアーカイブ[リソース消費型]」が表示されます。このオプションを選択すると、ファイルの変更アクションが検出されるたびに、ファイルのコピーが管理エージェントにローカルでアーカイブされます。これは後で、ファイルの2つのバージョン間で変更された内容を視覚的に比較するために使用できます。ルール作成ウィザードの「モニターするアクション」ページには、アーカイブしたコピーを格納する数を設定する追加設定があります。
-
ルール作成ウィザードに従ってインラインでファセットをモニタリング・ファセットまたはフィルタ・ファセットとして追加する場合、ルール・ウィザードを取り消しても、新しく作成したファセットはそのまま残り、将来のルールで使用できるようになります。これらのファセットは、ファセット・ライブラリにアクセスすることによって削除できます。リアルタイム・モニタリング・ファセットの詳細は、このドキュメントの後半にある個別の項を参照してください。
エージェント側ルールの作成
ノート: エージェント側のルールを作成する前に、構成拡張を作成する必要があります。
収集された構成データに基づいてターゲットが必要な構成状態にあることを確認するためのエージェント側のコンプライアンス標準ルールを作成するには、次のステップに従います。
欠落したパッチのコンプライアンス標準ルールの作成
適切なターゲットに適用されていないパッチを検出するために、欠落したパッチのコンプライアンス標準ルールを作成するには、次のステップに従います。
ヒント
-
コンプライアンス標準ルールが作成されても、自動的には評価されません。コンプライアンス標準にコンプライアンス標準ルールを追加してください。
-
ルールが作成された後、ルールに修正処理を割り当てます。
-
「コンプライアンス標準ルール」タブで、作成したばかりのルールを強調表示します。
-
「アクション」メニューから修正処理の割当てを選択します。
-
修正処理の割当てポップアップで、既存の修正処理を選択して「OK」をクリックします。
-
コンプライアンス標準ルールの類似作成
別のコンプライアンス標準ルールに類似したコンプライアンス標準ルールを作成するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準ルール」タブをクリックします。
- レプリケートするルールをハイライト表示します。
- 「類似作成」ボタンをクリックします。
- 必要に応じて、フィールドをカスタマイズします。
- 「保存」をクリックします。
コンプライアンス標準ルールの編集
コンプライアンス標準ルールを編集するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準ルール」タブをクリックします。
- 編集するルールをハイライト表示し、「編集」ボタンをクリックします。
- 以前のルールの作成時に説明したルール作成ウィンドウ属性の各画面の指示に順に従います。
- 「保存」をクリックします。
使用上のノート
-
リポジトリ・ルールの場合、ルール名、状態(すでに本番である場合)、および適用可能対象以外のすべてのルール・プロパティを変更できます。
リアルタイム・モニタリング・ルールの場合、ルール名、状態(すでに本番である場合)、適用可能対象、ターゲット・プロパティ・フィルタおよびエンティティ・タイプは変更できません。
-
ルール問合せ、違反条件、パラメータまたは重大度など、リポジトリ・ルールの重要なルール・プロパティを変更する場合、ルールの編集によって、ルールを参照するコンプライアンス標準の結果は無効になります。コンプライアンス標準のコンプライアンス・スコアは、次のルール評価で再評価されます。
-
本番モードのルールでは、ルールのドラフトを作成および保存するか、既存の本番ルールを上書きするかを選択できます。ドラフトを作成する場合、ドラフト・ルールを編集し、後でそれをテストし、ドラフトが作成された元の本番ルールに上書きおよびマージできます。ノート: コンプライアンス標準にドラフト・ルールを含めることはできません。
-
リアルタイム・モニタリング・ルールについては、編集中のルールが、ターゲットに関連付けられているコンプライアンス標準によって参照されている場合、ルール定義はターゲットをモニタリングする管理エージェントにデプロイされ、これによって管理エージェントは最新のルール定義を評価できるようになります。管理エージェントが停止しているか、アクセス不可能な場合は、管理エージェントが使用可能になった直後にルール定義の変更が管理エージェントに伝播されます。
コンプライアンス標準ルールの削除
ルールを削除する前に、コンプライアンス標準ルールを削除する前にコンプライアンス標準ルールの参照がコンプライアンス標準から削除されていることを確認する必要があります。コンプライアンス標準によって使用されているルールを削除することはできません。
コンプライアンス標準ルールを削除するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準ルール」タブをクリックします。
- 削除するルールをハイライト表示し、「削除」ボタンをクリックします。
- 「OK」をクリックして、ルールを削除するかどうかを確認します。
コンプライアンス標準ルールのエクスポート
エクスポート機能は、管理リポジトリおよびCloud Controlインスタンス間でユーザー定義のコンプライアンス標準ルール定義をトランスポートするためのメカニズムです。エクスポートによって、オペレーティング・システム・ファイルに定義を格納します。エクスポートしたコンプライアンス標準ルール定義は、XMLフォーマットであるため、Oracleコンプライアンス標準定義(XSD)フォーマットに準拠しています。コンプライアンス標準ルールの定義を変更でき、生成されたコンプライアンス標準ルール定義を別の管理リポジトリに再インポートできます。
コンプライアンス標準ルールをエクスポートするには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準ルール」タブをクリックします。
- エクスポートするルールをハイライト表示します。
- 「アクション」メニューから、「エクスポート」を選択します。
- 基準ルールをエクスポートするファイル名を指定します。
- コンプライアンス標準ルールのXML表現が生成され、指定したディレクトリおよびファイルに配置されます。
コンプライアンス標準ルールのインポート
インポートにより、すでに所有しているコンプライアンス標準ルールの再使用、Cloud Controlの複数のインスタンス間でのルール定義の共有、ルールのオフライン編集の有効化が可能になります。
コンプライアンス標準ルールをインポートする前に、インポートするコンプライアンス標準ルールがファイルに定義されていることを確認します。このファイルには、Cloud Controlにアクセスするために使用しているブラウザからローカルにアクセスできる必要があります。また、インポートするコンプライアンス標準ルール定義XMLファイルへのアクセス権限を持っていることも確認します。
コンプライアンス標準ルールをインポートするには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準ルール」タブをクリックします。
- 「アクション」メニューから、「インポート」を選択します。
- ルール定義(コンプライアンス標準ルールXSDに従う)をインポートするファイル名を指定します。コンプライアンス・フレームワーク定義がすでに存在する場合に既存の定義をオーバーライドするかどうかを指定します。オーバーライド・オプションはリアルタイム・モニタリング・ルールには使用できません。
- 「OK」をクリックします。
コンプライアンス標準ルールの参照
コンプライアンス標準ルールを参照するには、次のステップに従います。
- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
- 「コンプライアンス標準ルール」タブをクリックします。
- 特定の基準ルールの詳細を表示するには、ルールをハイライト表示し、「詳細を表示」をクリックします。
修正処理の使用
修正処理は、コンプライアンス標準ルールに対する違反を引き起こす問題を修正するスクリプトです。
修正処理には2種類あります。
-
手動 - コンプライアンス標準ルールのコンテキストに作成されます。
-
自動 - インシデント・ルールのコンテキストに作成されます。
手動修正処理
手動で修正処理を作成するには、次のステップを実行します。
-
「エンタープライズ」メニューで「モニタリング」、「修正処理」の順に選択します。
-
ジョブ・ページで、次を実行します。
-
「ライブラリ修正処理の作成」フィールドで、「SQLスクリプト」を選択し、「実行」をクリックします。
-
「一般」タブで、修正処理の名前を入力し(例: CA1)、説明を入力して、「イベント・タイプ」に「コンプライアンス標準ルール違反」を選択します。「ターゲット・タイプ」に「データベース・インスタンス」を選択します。
-
「パラメータ」タブでデフォルトのWHENEVER SQLERROR EXIT FAILURE;を選択します。「ライブラリに保存」をクリックします。
ノート: インテリジェントな修復を有効にするには、コンプライアンス違反から修正処理にパラメータを渡します。たとえば、よく知られているアカウントへの変更をロックするには、次のSQL文を追加します。
alter user %EVTCTX.dbuser% account lock; where dbuser is the event context parameter
任意のパラメータに同様の変更を行うことができます。SQL問合せの列名とパラメータ名が一致していることを確認してください。
-
作成した修正処理を選択し、「公開」をクリックします。
-
確認のページで、「はい」をクリックします。
-
-
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。ルール・タイプがエージェント側またはリポジトリのデータベース・コンプライアンス標準ルールを選択します。「アクション」メニューから「修正処理の割当て」を選択します。修正処理を選択し、「OK」をクリックします。
コンプライアンス標準ルールの詳細の表示ページに修正処理が表示されます。
自動修正処理
違反が起きたときに自動的にトリガーされる修正処理を作成するには、次のステップを実行します。
-
「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。
-
インシデント・ルール: すべてのエンタープライズ・ルール・ページで「ルール・セットの作成」をクリックします。ルールの名前を指定し、「ターゲット」リージョンの「すべてのターゲット」を選択し、「ルール」リージョンの「作成」をクリックします。
-
「作成するルールのタイプを選択」ダイアログ・ボックスで、受信イベントおよびイベントの更新を選択します。「続行」をクリックします。
-
タイプに「コンプライアンス標準ルール違反」を選択します。
-
コンプライアンス標準ルール違反タイプのすべてのイベントまたはコンプライアンス標準ルール違反タイプの特定のイベントのいずれかを選択します。
-
詳細な選択オプションで、「修正処理が完了しました」を選択します。「次」をクリックします。
-
新規ルールの作成: アクションの追加ページで、「追加」をクリックします。条件付きアクションの追加ページで、訂正処理の選択をクリックします。訂正処理を選択します。「続行」をクリックします。
-
新規ルールの作成: アクションの追加ページで、「次へ」をクリックします。新規ルールの作成: 指定および説明ページで「次へ」をクリックします。
-
情報を確認して、「続行」をクリックします。
-
「保存」をクリックします。新しく追加されたルールは「保存」ボタンがクリックされるまで保存されないことに注意してください。「保存」をクリックした後、詳細を確認することでルール・セット・エンティティが新しいインシデント・ルールに新しいインシデント・ルールを追加したことを確認します。