| Oracle® Enterprise Managerライフサイクル・マネージメント管理者ガイド 13c リリース2 E78870-07 |
|
 前 |
 次 |
コンプライアンス管理では、構成、セキュリティおよび記憶域に関する企業のベスト・プラクティスについて、ターゲットおよびシステムのコンプライアンスを評価できます。これは、コンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールを定義、カスタマイズおよび管理することで実現します。また、コンプライアンス管理によって、ターゲットおよびシステムがコンプライアンスに対応するよう構成を変更する方法に関する情報が提供されます。
この章では、エンタープライズ内のアプリケーションが事前に確立されている規格に準拠していることをコンプライアンス管理で検証する方法、およびコンプライアンス構造の管理方法について説明します。この章の内容は次のとおりです。
コンプライアンス管理ソリューションでは、構成、セキュリティ、記憶域などに関する企業のベスト・プラクティスについて、ターゲットおよびシステムのコンプライアンスを評価できます。さらに、コンプライアンス管理は、コンプライアンスの評価に使用するエンティティを定義、カスタマイズおよび管理する機能を提供します。
コンプライアンス・ソリューションは次のとおりです。
ターゲットとシステムは有効な構成設定がされているか、および構成関連の脆弱性にさらされていないかを自動的に判断します。
ベスト・プラクティスに関するコンプライアンスにターゲットおよびシステムを提示するために構成を変更する方法をアドバイスします。
Oracle Enterprise Manager Cloud Control (Cloud Control)ユーザーに構成の変更や非認証アクションが環境内のどこで行われているかを知らせるために、ターゲットのファイル、プロセスおよびユーザーをリアルタイムでモニタリングします。
コンプライアンス標準ルールにマップするために、Oracle提供のコンプライアンス・フレームワーク(Oracleの汎用コンプライアンス・フレームワークなど)およびコンプライアンス標準を提供します。このマッピングによって、コンプライアンスに従っていない設定およびアクションが組織で従うコンプライアンス・フレームワークにどのように影響を及ぼすかをビジュアル化できます。
部門オーナー、ITマネージャおよびコンプライアンス・マネージャが定期的に参照して組織のコンプライアンスの適用範囲を確認するのに適したIT構成および変更のビューをコンプライアンスに焦点を合せて提供します。
コンプライアンス機能の使用を開始する前に、理解しておく必要がある基本事項がいくつかあります。詳細は、次を参照してください。
次の用語は、コンプライアンス機能について説明する際に、この章全体で使用されます。
コンプライアンス・フレームワークは、会社が業界におけるコンプライアンスを維持するために遵守する必要がある制御領域が編成されたリストです。Enterprise Managerでは、コンプライアンス・フレームワークをフォルダリング構造として使用することにより、標準およびルールをこれらが影響する制御領域にマップします。コンプライアンス・フレームワークは、これらの業界フレームワークを直接的に表現できるよう、階層的になっています。
1つのフレームワーク制御領域が1つ以上のコンプライアンス標準にマップされます。これらのコンプライアンス標準評価の結果、特定のフレームワーク領域のスコアが生成されます。
コンプライアンス標準は、幅広く受け入れられたベスト・プラクティスに従うチェックまたはルールのコレクションです。それは、制御に従っているかどうかを判断するために、ITインフラストラクチャのセットに対してテストする必要があるコンプライアンス制御をCloud Controlによって表現したものです。これにより、ITインフラストラクチャ、アプリケーション、ビジネス・サービスおよびビジネス・プロセスが適切に編成、構成、管理およびモニターされていることを確認します。コンプライアンス標準の評価は、プラットフォーム互換性、類似の構成を持つ他のカスタマに影響する既知の問題、セキュリティ脆弱性、パッチ推奨などに関連する情報を提供します。また、コンプライアンス標準は、リアルタイム変更のモニタリングを実行する場所を定義するためにも使用されます。
コンプライアンス標準は、1つ以上のコンプライアンス標準ルールにマップされ、評価が必要な1つ以上のターゲットに関連付けられます。
コンプライアンス標準ルールは、構成データの変更がコンプライアンスに影響するかどうかを決定するための特別なテストです。コンプライアンス標準ルールは、1つ以上のコンプライアンス標準にマップされます。
Cloud Controlには、次のタイプのコンプライアンス標準ルールがあります。
管理リポジトリのメトリック収集データに対してチェックを実行するために使用されます。
WebLogic Server署名ルール
ベスト・プラクティスの構成をサポートするためにWebLogicターゲットのチェックに使用されます。
変更が発生した際にファイル、プロセスおよびデータベース・エンティティへのアクションをリアルタイムでモニターするために使用されます。ユーザーのログイン/ログアウトおよびSU/SUDOアクティビティの取得も行います。
エージェントで構成チェックを実行するために使用され、違反を管理リポジトリにアップロードします。
実行する必要があるが、自動化できないチェック。例: インストール、アップグレードおよびパッチをテストするための計画は、本番での実装前に記述し、遵守する必要があります。
コンプライアンス標準ルール・フォルダは、コンプライアンス標準ルールを含む階層構造です。
重要度は、コンプライアンス・フレームワーク、標準およびルールのマップ時に行うことができる設定です。重要度を使用して、そのフレームワーク制御領域またはコンプライアンス標準のコンプライアンス・スコアにコンプライアンス違反が及ぼす影響を計算します。
コンプライアンス・フレームワークの場合、コンプライアンス標準のマップ時におけるこのコンプライアンス標準の重要度は、このフレームワーク内の他のコンプライアンス標準に対する相対的な重要度を示します。
コンプライアンス標準の場合、コンプライアンス標準ルールのマップ時における重要度は、コンプライアンス標準内の他のすべてのコンプライアンス標準ルールに対するコンプライアンス標準ルールの相対的な重要度を示します。
ターゲットのコンプライアンス標準に対するコンプライアンス・スコアは、ターゲットがコンプライアンス標準にどの程度準拠しているかを表すために使用されます。コンプライアンス・スコアは0%から100%(100%を含む)の範囲の数値です。コンプライアンス・スコアが100%の場合、ターゲットはコンプライアンス標準に完全にコンプライアンスしています。
リアルタイム・モニタリング・ルール定義には、指定したターゲット・タイプ、ターゲット・プロパティおよびエンティティ・タイプに対するモニタリングで何が重要かを指定するファセットが含まれています。ファセットは、ターゲット・タイプの属性を構成するパターンの集合です。たとえば、オペレーティング・システムのネットワーク構成ファイルは、複数のファイル名またはファイル・パターンが含まれた1つのファセットによって定義できます。
監視は、ホストに表示されたアクションまたはリアルタイム・モニタリング・ルールでモニター対象として構成されたターゲットです。各ユーザー・アクションが1つの監視結果になります。
監視にはすべて、監視が認証済または非認証またはそのどちらでもない(非監査)かを決定する監査ステータスがあります。監査ステータスは、手動で設定することも、リアルタイム・モニタリング・コンプライアンス標準ルール構成を介して自動的に設定することもできます。
単一の監視が管理エージェントからサーバーにレポートされることはありません。かわりに、これらは、同じターゲット、ルール、およびアクションの実行ユーザーに対して他の監視とともにバンドルされます。バンドルを使用すると、類似する監視を簡単にまとめることができるため、Cloud Controlで監視を管理しやすくなります。
コンプライアンス機能にアクセスするには、「エンタープライズ」メニューにナビゲートし、「コンプライアンス」を選択し、次のうちの1つを選択します。
ダッシュボードには、ユーザーの組織または領域のコンプライアンスまたはリスクの度合いを示す結果が非常に詳しく表示されます。ダッシュボードには、選択したフレームワークのコンプライアンス・スコア、最も準拠していないシステムとターゲット、および検出された管理対象外ホストを表すダイアルがあります。
コンプライアンス結果には、コンプライアンス・フレームワーク、コンプライアンス標準およびターゲット・コンプライアンスの評価結果およびエラーが含まれます。
「コンプライアンス・ライブラリ」ページには、標準を定義するのに使用されるエンティティが含まれています。コンプライアンス・ライブラリ・ページでは、コンプライアンス・フレームワーク、コンプライアンス標準、コンプライアンス標準ルールおよびリアルタイム・モニタリング・ファセットを操作できます。
注意: リアルタイム・モニタリング・ファセットは、リアルタイム・モニタリング・ルール専用です。
監視は、ホストに表示されたアクションまたはリアルタイム・モニタリング・ルールでモニター対象として構成されたターゲットです。各ユーザー・アクションが1つの監視結果になります。同じリアルタイム・モニタリング・ルールに対して同じターゲットの同じユーザーが短い期間に複数の監視を実行する場合、監視が追加でバンドルされます。監視対象のアクションを分析するために複数のUIベース・レポートが用意されています。
コンプライアンス標準機能を使用するには、次のロールおよび権限へのアクセス権限を持っている必要があります。
| ロール | 説明 | 含まれる権限 |
|---|---|---|
コンプライアンス・フレームワーク、コンプライアンス標準、コンプライアンス標準ルールおよびリアルタイム・モニタリング・ファセットを作成、変更および削除できます。 |
ターゲット権限:
リソース権限:
|
|
コンプライアンス・フレームワーク定義および結果を表示できます。 |
ターゲット権限なし リソース権限
|
コンプライアンスで使用されるターゲット権限およびリソース権限には、次が含まれます。
| 権限 | 権限のタイプ | 含まれるロール | 説明 |
|---|---|---|---|
ターゲット |
EM_COMPLIANCE_DESIGNER |
コンプライアンス標準のターゲットへの関連付けを含めて、任意のターゲットのコンプライアンスを管理できます。 |
|
ターゲット |
EM_COMPLIANCE_DESIGNER |
任意のターゲットのメトリックを管理できます。 |
|
ターゲット |
EM_COMPLIANCE_DESIGNER |
Enterprise Managerでのすべての管理対象ターゲットを表示できます。 |
|
ターゲット |
EM_COMPLIANCE_OFFICER EM_COMPLIANCE_DESIGNER |
コンプライアンス・フレームワーク定義および結果を表示できます。 注意: この権限は、コンプライアンス・フレームワーク・リソース権限に含まれます。この権限はEM_COMPLIANCE_OFFICERロールに対してはデフォルトで付与されますが、EM_COMPLIANCE_DESIGNERロールに対してはデフォルトで付与されません。 |
|
リソース |
EM_COMPLIANCE_DESIGNER |
コンプライアンス・フレームワーク、コンプライアンス標準、コンプライアンス標準ルールおよびリアルタイム・モニタリング・ファセットを作成できます。 この権限は、コンプライアンス・フレームワーク・リソース権限に含まれます。 |
|
リソース |
EM_COMPLIANCE_DESIGNER |
コンプライアンス・フレームワーク、コンプライアンス標準、コンプライアンス標準ルールおよびリアルタイム・モニタリング・ファセットを編集および削除できます。 この権限は、コンプライアンス・フレームワーク・リソース権限に含まれます。 |
|
リソース |
EM_COMPLIANCE_DESIGNER EM_COMPLIANCE_OFFICER |
コンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールの定義、カスタマイズおよび管理を行うことができます。また、ターゲットおよびシステムが、構成、セキュリティおよび記憶域などの観点から企業のベスト・プラクティスに準拠しているかどうかを評価できます。 この権限には、次の権限があります。
|
|
リソース |
EM_COMPLIANCE_DESIGNER |
ターゲット構成収集を拡張できます。 この権限には、次の権限があります。
|
|
リソース |
EM_COMPLIANCE_DESIGNER |
ジョブは、通常実行されるタスクの自動化が管理者によって定義される、スケジュール可能な作業単位です。 この権限には、次の権限があります。
|
次の表には、コンプライアンス・タスクとそれに必要なロールおよび権限がリストされています。
| タスク | 必要なロールおよび権限 |
|---|---|
コンプライアンス・フレームワークの作成 |
コンプライアンス・エンティティの作成権限 任意のコンプライアンス・フレームワークの表示権限 |
コンプライアンス・フレームワークの編集および削除 |
完全な任意のコンプライアンス・エンティティ権限 任意のコンプライアンス・フレームワークの表示権限 |
コンプライアンス・フレームワークの作成、編集および削除 |
EM_COMPLIANCE_DESIGNERロール EM_COMPLIANCE_OFFICERロール |
コンプライアンス標準のターゲットへの関連付け |
任意のターゲット・コンプライアンスの管理権限 または ターゲットに対するMANAGE_TARGET_COMPLIANCE権限 |
コンプライアンス・フレームワークのインポートまたはエクスポート |
EM_COMPLIANCE_DESIGNERロール EM_COMPLIANCE_OFFICERロール |
リアルタイム・モニタリング・ルールの作成 |
EM_COMPLIANCE_DESIGNERロール |
リアルタイム・モニタリング・ファセットの作成 |
EM_COMPLIANCE_DESIGNERロール |
注意: コンプライアンス標準と関連付けるターゲットへのアクセス権限も持っていることを確認してください。特に、ターゲットに対する任意のターゲット・コンプライアンスの管理権限が必要です。
コンプライアンス評価とは、コンプライアンス標準にマップされたコンプライアンス標準ルールをターゲットに対してテストし、管理リポジトリに違反を記録するプロセスです。
コンプライアンス標準に対してターゲットを評価することによって、ターゲットが標準のチェックに準拠しているかどうかを判別します。ターゲットが所定の状態を満たしていない場合、そのターゲットを準拠させるのに必要な変更事項をテストで提案します。
コンプライアンス評価によって、ターゲットがどの程度標準に準拠しているかに基づいてターゲットのスコアが生成されます。100%のコンプライアンス・スコアとは、ターゲットがコンプライアンス標準のすべてのチェックに合格したことを意味します。リアルタイム・モニタリングの場合、手動または変更リクエスト管理統合を介して非認証とマークされた監視があると、コンプライアンス・スコアは下がります。これらの非認証監視がクリアされるか認証済に変更されると、スコアは向上します。
ターゲット・コンプライアンスを定期的にモニターする必要があるため、コンプライアンス標準をターゲットに関連付ける必要があります。ターゲットの状態がリフレッシュする、つまり、ターゲットから新規データが収集されると、関連するターゲットに対して評価が自動的に実行されます。リポジトリ・ルールの場合、ターゲットの新規データが管理リポジトリにロードされると、評価が再度行われます。リアルタイム・モニタリングの場合、ユーザー・アクションの監視が行われるたびに評価が行われます。
コンプライアンスを保証するために実行可能な操作
Cloud Controlを使用してコンプライアンスを評価する場合、次のアクションを定期的に実行する必要があります。
組織のコンプライアンス・スコアが低いか組織が危険な状態にあることを示す可能性がある領域を検出するためのコンプライアンス・ダッシュボードの定期的モニター
評価の結果の表示
評価結果を検討し、ターゲットに必要な変更を行います。
表示権限のあるターゲットの結果のみを表示できます。コンプライアンス標準ルールの評価結果は、コンプライアンス標準の評価状態とコンプライアンス・サマリーを生成するためにロールアップされます。
Oracle提供のレポートの確認
リアルタイム・モニタリングUIレポートを定期的にモニターし、検出した監視が正常か異常かを確認します。非認証の変更を元に戻せるようになるまで、または監査者が求めるレベルまでアクションを調査できるまでは、異常のある監視を非認証に設定します。
評価結果としての傾向の概要の検討
傾向の概要ページのグラフを使用して、ターゲットがコンプライアンス標準に準拠する傾向にあるのか、コンプライアンスのベスト・プラクティスから遠ざかる傾向にあるのかを視覚的に判断します。
コンプライアンス標準の「傾向の概要」ページにアクセスするには、次の手順を実行します。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
「コンプライアンス標準」タブから「評価結果」を選択します。
評価結果ページで、調査するコンプライアンス標準を選択し、「詳細を表示」をクリックします。
結果の詳細ページで、「傾向の概要」タブをクリックします。
注意: コンプライアンス・フレームワークの「傾向の概要」ページをレビューすることもできます。
構成比較機能の上位でルールを作成することで、環境がベースライン(または相互)に一致していることを確認してください。リアルタイム・モニタリングを使用して、構成の変動をモニタリングします。
構成設定の妥当性の評価
構成関連の脆弱性の存在、記憶域およびセキュリティの評価
準拠するターゲットおよびシステムの変更
構成変更またはユーザー・アクションの認証の検証
システム、サービスおよびターゲットを継続的にテストして、システムを最大限に保護し、最高のパフォーマンスを実現します。
Oracle提供のコンプライアンス標準およびコンプライアンス標準ルールを使用して、コンプライアンスを判断します。
使用環境内でコンプライアンスについてモニターされていないホストは、使用環境に多大なコンプライアンス・リスクをもたらすため、これらをモニターします。
次の各項では、その他の詳細について説明します。
コンプライアンス統計は、コンプライアンス・ダッシュボード、「エンタープライズ・サマリー」ページ、およびターゲットのホームページなどのページにある「コンプライアンス・サマリー」リージョンのインタフェース全体で使用できます。
これらのリージョンでは、特定のターゲットの違反およびコンプライアンス・スコアを報告します。ただし、リージョンでは違反があることのみ報告され、詳細は表示されません。たとえば、「ホストのセキュアな構成」コンプライアンス標準の一部である「セキュア・ポート」コンプライアンス標準ルールに対して違反があるとします。しかし、「コンプライアンス・サマリー」リージョンを参照しているだけでは、詳細はわかりません。
コンプライアンス・ダッシュボードはCloud Controlコンプライアンス機能の最上位レベルのビューです。ダッシュボードにはいくつかのリージョンがあり、これによりIT環境のコンプライアンスが定義済の標準に従っている状況を非常によく把握できます。
コンプライアンス・ダッシュボードへのアクセスの手順:
コンプライアンス・ダッシュボードは、ホームの選択ページから選択できるページの1つでもあり、Cloud Controlにログインするときにホームページとして設定することもできます。
コンプライアンス・ダッシュボードには、次のリージョンがあります。
コンプライアンス・フレームワーク・サマリー
このリージョンで、ユーザーは1つのコンプライアンス・フレームワークを選択し、そのコンプライアンス・フレームワークの下の第2レベルの各フォルダに対するコンプライアンス・スコアを表示します。ダイアル上の針は、指定されたフレームワーク要素に関する現在のコンプライアンスのスコアを示しています。このスコアは、Enterprise Managerのログイン・ユーザーが表示できるターゲットに基づいています。
このダイアルをクリックすると、指定した第2レベルのフレームワーク・フォルダの「コンプライアンス結果」ページに移動し、次のフレームワーク・フォルダまたはこのフォルダに属しているコンプライアンス標準(またはその両方)のより詳細な情報が提供されます。
コンプライアンス・サマリー
このリージョンにはフレームワークのビューと標準のビューがあります。「フレームワーク」ビューのこのリージョンには、すべての定義済のコンプライアンス・フレームワークとその全体のスコアおよび違反の詳細のリストが示されます。「標準」ビューのこのリージョンには、最も低いスコアのコンプライアンス標準がその違反の詳細とともにリストされます。フレームワークまたは標準の名前をクリックすると、そのフレームワークまたは標準のより詳細な情報を示す画面に移動します。
このリージョンから、「傾向の表示」リンクをクリックし、コンプライアンス・スコアの履歴の傾向のグラフを表示することもできます。
最少コンプライアンス汎用システム
このリージョンには、最小のコンプライアンス・スコアの汎用システムが示されます。指定したシステムのスコアは、そのシステムのすべての要素に関連付けられたすべてのルールを含むことで計算されます。汎用システムは、HRISやPayrollなどのITビジネス・アプリケーションを定義するために使用します。スコアが最低であるシステムをレポートすることにより、監査時間の原因となるコンプライアンス・リスクがあるビジネス単位を特定しやすくなります。
最新の検出済管理対象外ホスト
このリージョンには、Cloud Control自動ホスト検出機能を使用して最近検出された、管理対象ホストに昇格されなかったホストが示されます。T環境内の管理対象外ホストは多くのアクセス制御およびデータ・アクセスのリスクの原因となる可能性があるので、これらのホストは特定のコンプライアンス・リスクを表しています。このリージョンの目的は、最近検出され、コンプライアンス制御下にない可能性のあるホストを強調することです。
最少コンプライアンス・ターゲット
このリージョンは「最少コンプライアンス汎用システム」と類似していますが、すべてのターゲットを示す(汎用システムを再度含む)点が異なります。このリージョンは、どの個別のターゲットが使用されているかが明確でない場合があるので、IT管理または監査者の視点からは、あまり役に立ちません。しかし、ITコンプライアンス監査の増加につながる最もリスクの高い領域を探す別のデータ・ポイントとして使用できます。
コンプライアンス・サマリー情報は、Cloud Controlの「コンプライアンス結果」ページおよび個々のターゲット・ホームページから使用できます。
「Cloud Control」ホームページからコンプライアンス・サマリー情報を表示するには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
ターゲットのホームページからコンプライアンス・サマリー情報を表示するには、次の手順に従います。
ターゲット固有のコンプライアンス評価結果は、Cloud Controlホームページおよび個々のターゲット・ホームページによって使用できます。コンプライアンスのルールおよび標準を評価することによって得られる評価結果は、次のとおりです。
| 評価結果 | 説明 |
|---|---|
コンプライアンス |
ターゲットは目的の状態にあり、非認証のリアルタイム・モニタリングの監視はありません。 |
非コンプライアンス |
ターゲットが所定の状態にありません。コンプライアンス標準の少なくとも1回のテストによって目的の状態からの逸脱が検出されたか、非認証のリアルタイム・モニタリングの監視が少なくとも1つあります。 |
エラー |
エラーにより結果が返されませんでした。エラーは、予期しない内部エラーまたはテスト中のエラーです。テスト中にエラーが発生するのは、次のような処理を試行した場合です。
|
「Cloud Control」ホームページを使用して結果を表示するには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
「ターゲット・コンプライアンス」タブをクリックします。ページに、ターゲットとその平均コンプライアンス・スコアが表示されます。
ターゲットのホームページからコンプライアンス評価結果を表示するには、次の手順に従います。
ページまたはリージョンを使用して、一定期間におけるターゲットのコンプライアンスを概観します。表およびグラフを使用して、現在の傾向および変化を簡単にウォッチできます。
注意: コンプライアンス標準からターゲットへの初回アソシエーション後に傾向概要データが時系列グラフに表示されるまでに最大6時間かかる可能性があります。
コンプライアンス・フレームワークを効率的に使用するには、組織内で使用するコンプライアンス・フレームワークの制御領域を反映するように、フレームワークを編成します。フレームワークの階層構造は、使用するフレームワークの制御領域に直接マップする必要があります。
Oracleは、Oracleの汎用コンプライアンス・フレームワーク、Fusion Applicationsコンプライアンスおよびセキュリティ技術導入ガイド(STIG)など、多くのフレームワークを提供します。これらのフレームワークは、ニーズに応じて独自のフレームワークを作成する際の起点にしたり、内部標準やSOX、HIPAA、NIST-800または他の一般的なフレームワークに基づいて独自のフレームワークを最も効率的に編成する方法について理解するために使用できます。
コンプライアンス・フレームワーク評価の結果を表示するには、「コンプライアンス・フレームワーク」タブからアクセスする「評価結果」ページを使用します。
コンプライアンス・フレームワークは階層構造であるため、フレームワークの各フォルダまたはノードには独自のスコアがあります。階層の最下位の子のスコアは親フォルダなどにまとめられます。これらのレポートを参照するユーザーが、使用するフレームワークの1つの制御領域に主に興味がある場合、フレームワークの下で参照するフォルダによって表される特定の制御領域のスコアに焦点を当てることができます。
コンプライアンス結果機能を使用することにより、違反の抑止と抑止解除および手動違反のクリアを行うことができます。
違反を抑止すると、コンプライアンス・スコア計算から違反を削除するときに、既存の違反を確認できます。違反を抑止することにより、違反リストから違反を削除することなく、違反がコンプライアンス・スコアに悪影響を及ぼさないようにすることができます。抑止は、無期限に有効にすることも、特定期間だけ有効にすることもできます。
違反の抑止を解除すると、コンプライアンス・スコアが、抑止解除された違反を考慮して再計算されます。
手動ルール違反をクリアすると、違反がクリアされます。また、コンプライアンス・スコアが対応するコンプライアンス標準またはターゲットに対して上昇します。手動ルール違反のクリアは、無期限に有効にすることも、特定期間だけ有効にすることもできます。
違反管理機能へのアクセス
違反管理機能にアクセスするには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
コンプライアンス標準をハイライト表示し、「違反の管理」をクリックします。
以下のタブを使用することができます。
抑止解除された違反
抑止された違反
手動ルール違反
「抑止解除された違反」タブ
このタブを使用して、違反を抑止します。
1つ以上の違反を選択します。
「違反の抑止」をクリックします。
「違反の抑止の確認」ポップアップで、違反を無期限に抑止することを選択するか、または抑止の終了日を指定できます。オプションで、抑止の説明を入力できます。
「OK」をクリックします。
これで、抑止を非同期に行うジョブが発行され、結果ライブラリページが再表示されます。抑止を有効にすると、違反が抑止されたこととその理由(理由が入力されている場合)を示す注釈が、基礎となるイベントに追加されます。注意: ジョブの結果は、即座に表示されません。効果が現われるまでに数分かかることがあります。
「抑止された違反」タブ
このタブを使用して、違反の抑止を解除します。
1つ以上の違反を選択します。
「違反の抑止解除」をクリックします。
「違反の抑止解除の確認」ポップアップで、抑止を解除する理由を入力できます。
「OK」をクリックします。
これで、抑止の解除を非同期に行うジョブが発行され、結果ライブラリに戻ります。抑止を解除すると、違反の抑止が解除されたこととその理由(理由が入力されている場合)を示す注釈が、基礎となるイベントに追加されます。注意: ジョブの効果はすぐには現われません。効果が現われるまでに数分かかることがあります。
「手動ルール違反」タブ
手動ルール違反をクリアするには、次の手順に従います。
これで、手動ルール違反を非同期にクリアするジョブが発行され、結果ライブラリページが再表示されます。手動ルール違反をクリアすると、基礎となる違反イベントもクリアされます。注意: ジョブの効果はすぐには現われません。効果が現われるまでに数分かかることがあります。
ここでは、コンプライアンス違反の調査に関するいくつかの提案事項を示します。最もクリティカルな違反やITエンタープライズのコンプライアンス全体に対する影響が最も大きい違反に注意してください。
コンプライアンス・ダッシュボードでスコアの最も低いシステムおよびターゲットとともにコンプライアンス・フレームワークのスコアをモニターします。
最近検出されたホストがCloud Controlを使用してコンプライアンス・リスクについてモニターされているかITコンプライアンスに潜在的なリスクをもたらしていないかを確認します。
「エンタープライズ・サマリー」ホームページ上の統計を検討します。特に、「コンプライアンス・サマリー」リージョン内の統計を参照します。重大度が「クリティカル」であるコンプライアンス違反を最初に処理する必要があります。
コンプライアンス・スコアの最も低い汎用システム(ITビジネス・アプリケーション)およびターゲットに対処します。
特定のターゲットのコンプライアンス違反については、そのターゲットのホームページを調査してください。「コンプライアンス標準サマリー」リージョンには概要情報が示されていますが、そのターゲットの傾向にもアクセスできます。
Cloud Controlのインシデント管理領域でコンプライアンス違反関連のイベントを確認します。
特定のコンプライアンス標準の「結果」ページにナビゲートします。ナビゲーション・ツリーで、コンプライアンス標準の名前をクリックすると、サマリー・ページに、すべてのターゲットが違反の数とともにリストされます。
「傾向の概要」ページにナビゲートすると、評価されたターゲット数、ターゲットごとの平均違反数、コンプライアンス・スコア別のターゲット数、および平均コンプライアンス・スコアの各グラフが表示されます。
注意:
表示権限のあるターゲットの結果のみを表示できます。
「エンタープライズ・サマリー」ページを参照していて、「ホストのセキュアな構成」コンプライアンス標準に対するクリティカル違反があることに気づいた場合、違反の原因となるターゲットを特定する必要があります。次の手順を実行します。
コンプライアンス標準に準拠していないすべてのターゲットを参照したいとします。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
コンプライアンス標準およびコンプライアンス・フレームワークに関連する違反を表示するオプションがあります。
すべてのターゲットにわたるすべての違反、つまりコンプライアンスに従っていないすべてのターゲットのロールアップ・ビューの「ターゲット・コンプライアンス」タブをクリックします。
「コンプライアンス標準」タブをクリックして、違反があるコンプライアンス標準のリストを表示します。このタブから、「エラー」タブにアクセスして、コンプライアンス標準に対するエラーを表示することもできます。
特定のターゲットのホームページに移動します。「コンプライアンス標準サマリー」リージョンでは、重大度レベルに従ってコンプライアンス違反がリストされます。対象のコンプライアンス標準の名前をクリックして、違反の詳細を表示します。
前の項で説明したとおり、コンプライアンス機能では、コンプライアンスの問題を解決するのに役立つ違反の詳細が提供されます。違反の詳細にアクセスする方法は複数あります。
違反には次の場所からアクセスできます。
「エンタープライズ・サマリー」ページにある「コンプライアンス・サマリー」リージョン。
コンプライアンス標準およびコンプライアンス・フレームワークに対する違反を簡単に確認できます。
「コンプライアンス結果」ページ。「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
違反の詳細を確認する方法の例は、次のとおりです。
例1: コンプライアンス・フレームワークの違反の詳細へのアクセス
コンプライアンス・フレームワークの違反を参照するには、「コンプライアンス・フレームワーク」タブ、「評価結果」タブの順にクリックします。「違反」列に、各フレームワークに存在する違反の数がリストされます。「違反」列の数値をクリックすると、すべてのターゲットが、関連付けられたコンプライアンス標準とともにリストされます。
一方、「違反数」列の数値をクリックすると、表示される違反ページには、違反があるコンプライアンス標準ルールがリストされます。また、「違反数」列の数値をクリックすると、表示される違反の詳細ページには、違反の原因となる特定のコンプライアンス標準ルールのすべてのメトリックがリストされます。
例2: コンプライアンス標準の違反の詳細へのアクセス
「コンプライアンス標準」タブ、「評価結果」タブの順にクリックすると、「違反」列に、各コンプライアンス標準に存在する違反の数がレポートされます。
「違反」列の数値をクリックすると、標準に違反しているすべてのターゲットがリストされた「違反」ポップアップが表示されます。
また、「違反数」列の数値をクリックすると、「違反」ポップアップが表示されます。すべてのコンプライアンス標準ルール(セキュリティ推奨など)がリストされます。
「違反」ポップアップの「違反数」列の数値を再クリックして、処理を続行します。後続のポップアップに「違反の詳細」に表示されます。たとえば、「違反の詳細」ポップアップには、問題の原因であるパッチの名前が表示されます。
例3 - ターゲットの違反へのアクセス
「ターゲット・コンプライアンス」タブをクリックすると、「違反」列に、各ターゲットに存在する違反の数がレポートされます。
「違反」列の数値をクリックすると、標準に違反しているすべてのターゲットがリストされた「違反」ポップアップが表示されます。図48-2を参照してください。
また、「違反数」列の数値をクリックすると、「違反」ポップアップが表示されます。すべてのコンプライアンス標準ルール(セキュリティ・ポートなど)がリストされます。
「違反」ポップアップの「違反数」列の数値を再クリックして、処理を続行します。後続のポップアップに「違反の詳細」が表示されます。たとえば、「違反の詳細」ポップアップには、コンプライアンス標準に違反しているポートの数が表示されます。
例4 - 「コンプライアンス標準」ページの「詳細を表示」を使用した違反
「コンプライアンス結果」ページの「詳細を表示」オプションを使用して、違反にドリルダウンすることもできます。標準を強調表示し、「詳細を表示」をクリックします。図48-3を参照してください。
結果のページには、ターゲットまたはコンプライアンス標準ルール別に違反を表示するオプションがあります。
「違反」タブをクリックすると、「イベントの詳細」および「ガイドされた解決」を含むコンプライアンス標準に関する詳細がリストされます。図48-4を参照してください。
例5: 「エンタープライズ・サマリー」ページからの違反へのアクセス
「エンタープライズ・サマリー」ページの「コンプライアンス・サマリー」リージョンでコンプライアンス標準の名前をクリックすると、「コンプライアンス標準結果詳細」ページが表示されます。「違反」タブをクリックすると、特定のコンプライアンス標準に違反するすべてのターゲットを表示できます。図48-5を参照してください。
「コンプライアンス標準結果詳細」ページで、「サマリー」タブ、「ターゲット別の結果」タブの順にクリックすると、ターゲットに対する違反の数が表示されます。違反列の数値をクリックすると、違反の原因となるコンプライアンス標準ルールがリストされた「違反」ポップアップが表示されます。次に、「違反数」列の数値をクリックすると、原因となっているメトリックまたはパッチの名前が表示されます。
注意: 「ターゲット・コンプライアンス」タブから、同様のドリルダウンが使用できます。
ヒント: 違反の最終結果に到達するには、「違反数」列の数値をクリックし続けます。さらに詳細が示され、問題の原因が絞り込まれます。
注意: 違反はマルチレベルですが、ターゲット評価は単一レベルのみです。
「評価エラー」ページでは、評価中に発生した問題に関する統計が報告されます。まず、評価エラー・ページに、すべての評価エラーが表示されます。
評価エラー・ページには、メトリック収集の結果発生したエラー、および最後のポリシー評価中に発生したエラーが表示されます。
検索フィルタを使用して、指定する検索基準セットと一致する評価エラーのみを表示します。
「メッセージ」列のメッセージをクリックして、エラーを解決するための対策を決定します。
通常、評価の結果は、前回の評価結果を上書きします。ただし、評価が失敗またはデータ・プロバイダ収集が失敗した場合は、前回の結果は上書きされず、そのまま残ります。
根本の問題が解決されると、エラーは報告されなくなります。
標準エラーの検索フィルタ
デフォルトでは、エンタープライズ構成内のすべての評価エラーが結果表に表示されます。ただし、検索基準のセットを指定し、基準と一致する評価エラーのみが結果表に表示されるように検索を実行できます。
たとえば、「ターゲット・タイプ」リストで「ホスト」、「ターゲット名」リストで「次を含む」、その隣の「ターゲット名」テキスト・フィールドで「-sun」を選択し、「実行」をクリックすると、Cloud Controlは、名前に「-sun」を含むホストのコンプライアンス標準ルールの評価エラーのみを結果表に表示します。
Cloud Controlでは、コンプライアンス固有のレポートが提供されます。これらのレポートへのアクセスの手順:
コンプライアンス・レポートには、次が含まれます。
説明レポート
説明レポートには、コンプライアンス・ライブラリで使用可能なすべてのコンプライアンス標準、コンプライアンス・フレームワークおよびコンプライアンス標準ルールがリストされます。これらのレポートによって、エンタープライズが標準へのコンプライアンスを獲得および維持するために、コンプライアンス標準およびコンプライアンス・フレームワークを追加で定義する必要があるかどうかを判断できます。
結果レポート
結果レポートでは、コンプライアンス標準およびコンプライアンス・フレームワークに対する様々な評価の詳細が提供されます。結果レポートを使用すると、定義済の標準に対するエンタープライズのコンプライアンスに関するすべての統計を、1つの場所に表示できます。即時対応が必要な可能性が最も高いターゲットを表示するには、「最下位AVG COMPLIANCE SCOREのターゲット」レポートを表示します。次に、提供されているレポートの例を示します。
コンプライアンス標準結果詳細
ターゲットに対して評価されたすべてのコンプライアンス標準のコンプライアンス・サマリーを表示します。データには、コンプライアンス・スコア、コンプライアンス、コンプライアンス・ルールおよび非コンプライアンス・ルール、違反および最終評価日が含まれます。
コンプライアンス標準結果サマリー
特定のコンプライアンス標準のコンプライアンス・サマリーを表示します。たとえば、Oracle製品のコンプライアンスに関するセキュリティ推奨事項についてそれぞれがレポートするターゲットが3つある場合、結果サマリーでは、情報が1つのレポートにロールアップされます。データには、平均コンプライアンス・スコア、即時対応が必要なターゲットの数、および非コンプライアンス・ルールの数が含まれます。
Cloud ControlではBIパブリッシャ統合を使用して一連のレポートを提供することもできます。次のレポートを使用できます。
リアルタイム・モニタリング違反レポート
リアルタイム・モニタリング・ルール・タイプに基づいて現在の違反を示します。
コンプライアンス・サマリー・レポート
現在のコンプライアンス・スコア、コンプライアンス傾向、上位10の最小コンプライアンス・システム・ターゲット、特定のコンプライアンス・フレームワークに対するフレームワーク違反サマリー、および第2レベルのフレームワーク・フォルダを示します。
監視ジャーナル・レポート
一定期間に発生した監視を示す表形式のレポートです。ユーザーがレポートのターゲット、開始時間および終了時間を選択できます。
注意: コンプライアンス・フレームワークが含まれるBI Publisherレポートが機能するようにするには、レポートを実行するユーザーがEM_COMPLIANCE_OFFICERロールを持つ必要があります。
ターゲットのコンプライアンス標準に対するコンプライアンス・スコアは、ターゲットがそのコンプライアンス標準にどの程度準拠しているかを表すために使用されます。コンプライアンス・スコアは0%から100%(100%を含む)の範囲の数値です。コンプライアンス・スコアが100%の場合、ターゲットはコンプライアンス標準に完全にコンプライアンスしています。
評価時に、ターゲットがそのコンプライアンス標準に対してコンプライアンスであるか非コンプライアンスできるかが判断されます。
重要度のタイプ
重要度は、コンプライアンス・フレームワーク、標準およびルールのマップ時に行うことができる設定です。重要度を使用して、そのフレームワーク制御領域またはコンプライアンス標準のコンプライアンス・スコアにコンプライアンス違反が及ぼす影響を計算します。
コンプライアンス・フレームワークの場合、コンプライアンス標準のマップ時におけるこのコンプライアンス標準の重要度は、このフレームワーク内の他のコンプライアンス標準に対する相対的な重要度を示します。
コンプライアンス標準の場合、コンプライアンス標準ルールのマップ時における重要度は、コンプライアンス標準内の他のすべてのコンプライアンス標準ルールに対するコンプライアンス標準ルールの相対的な重要度を示します。
ただし、コンプライアンス標準ルールの重要度が「低」であるからといって、このルールを無視しても差し支えないわけではありません。修正または補正制御によってリスクが解消されたら、すべてのコンプライアンス違反の優先順位を決定してクリアする必要があります。
重要度は、コンプライアンス・スコアがコンプライアンス標準階層内でロールアップする際に重み付けするために使用されます。
次の各項では、コンプライアンス・スコアの計算方法の例について説明します。
注意: この計算は、WebLogic Server署名ルールおよびリポジトリ・ルールに使用されます。
コンプライアンス標準ルール・ターゲットのコンプライアンス・スコアは、コンプライアンス標準ルールの重大度および重要度を使用し、この結果に、このターゲットに対して評価された行の合計数で違反の合計数を割った値を掛けることによって計算されます。
式は次のとおりです。
hirange - (hirange - lorange) * (number of violations / number of rows evaluated)
次の表は、コンプライアンス・スコアの計算に使用される重大度と重要度の値の組合せを示します。
表48-1 重要度と重大度の範囲
| 重要度 | クリティカル重大度(1) | 警告重大度(1) | マイナー警告重大度(1) |
|---|---|---|---|
高 |
0-25 (2) |
66-75 |
95-96 |
標準 |
26-50 |
76-85 |
97-98 |
低 |
51-75 |
86-95 |
99-99 |
(1)重大度の低範囲および高範囲
(2)低範囲は0、高範囲は25
リアルタイム・モニタリング・ルールのコンプライアンス・スコアは、違反のある監視バンドルの数を、一定期間に発生した監視バンドルの数と比較した結果に基づいています。監視バンドルは、短い時間(数分)内に、同じターゲットに対する同じユーザーによって発生するすべての監視のコレクションです。たとえば、ユーザーAがホストにログインし、5分間に10ファイルの変更を行うとします。これらの10の監視はすべて同じバンドルに属することが可能です。バンドルはEnterprise Managerによって自動的に処理されます。
過去の監視バンドルの数を計算する際は、最新のバンドルの方が高く重み付けされ、古くなるにつれて重み付けが変化します。
スコアは、次の計算式を使用して計算されます。
1 - V/T
where T is the sum of all the weighted bundle counts
and V is the count of the current bundles in violation
1-V/Tの計算結果は、Vが0 (100%コンプライアンス)の場合は1に近い値となり、VがT (0%コンプライアンス)の値に近い場合は0に近い値となります。
各ターゲットのコンプライアンス標準のコンプライアンス・スコアは、各ルール・ターゲットの個別のコンプライアンス・スコアにその重要度を掛けることによって計算されます。この乗算がルールごとに繰り返された後、算出された各積が加算されます。次に、各積の合計が各ルールの重要度の合計で割られます。
コンプライアンス・フレームワーク・スコアは、コンプライアンス・フレームワーク階層内のすべてのコンプライアンス標準にわたるすべてのコンプライアンス標準・ターゲット・スコアについて重み付けされてロールアップされた平均です。この重み付けは、コンプライアンス標準の重要度に基づいています。次の図では、コンプライアンス・フレームワークCFにはCS1とCS2の2つの標準があります。CS1はターゲットt1およびt2に対して関連付けられて評価され、CS2はターゲットt3およびt4に対して関連付けられて評価されます。
前に説明したとおり、監視は、ホストに表示されたアクションまたはリアルタイム・モニタリング・ルールでモニター対象として構成されたターゲットです。各ユーザー・アクションが1つの監視結果になります。
監視は多くの監査ステータスの1つを持つことができます。基本監査ステータスである非監査は、監視が検出されたが、このアクションが良好であるか不良であるかは示されていないことを意味します。認証済ステータスは、監視に対してなんらかの確認が行われており、これは発生が予期される(良好な変更であった)ものとして処理する必要があることを意味します。非認証ステータスは、この監視が確認されており、ポリシーに違反することが判明したことを意味します。この結果、修正、ポリシーの変更、または補正制御が行われる場合があります。監視の監査ステータスをルールによって自動的に設定することにより、ルールによってトリガーされるすべての監視をデフォルトの監査ステータスにすることができます。また、後述するUIレポートを介してステータスを手動で設定することもできます。最も高度な機能には、アクションの実行が想定されていたかどうかを監視ごとに自動的に確認するためにCloud Controlコネクタを介して変更管理リクエスト・サーバーと統合する機能が含まれます。
次の各項で、リアルタイム・モニタリングの監視の詳細を示します。
使用環境内で発生したリアルタイム・モニタリングの監視を確認する方法は主に4通りあります。
最初の3つの監視画面は、「エンタープライズ」メニューから「コンプライアンス」、「リアルタイム監視」の順に選択することによってアクセスできます。このページでは、3つのレポートのうちどれを参照するかを選択でき、リアルタイム・モニタリング・ルール構成に関連する管理エージェントの警告も表示されます。これらの警告は、管理エージェントからレポートされ、Cloud Controlサーバーへの監視の配信に影響を及ぼす可能性があります。予期される監視が欠落している場合は、これらの警告を確認し、それらの原因である構成問題に対処します。
監視が発生したときに、その監視を自動的に認証済または非認証としてマークできます。これは、調査する必要のある重要な監視を見つける1つの方法を提供します。ただし、監視を変更管理サーバーと調整するようにルールが構成されていない場合、属性検索のみで重要な監視を見つけることは困難な可能性があります。ビジネス・アプリケーション(汎用システム)別に監視を表示し、監視の詳細にドリルダウンできる機能により、監視の監査ステータスとは関係なく、調査する必要のある問題が発生している可能性のある場所を特定できます。
通常、ITマネージャと部門所有者は、ビジネス・アプリケーションで好ましくない構成の変化が発生したかどうかを識別する必要があります。監視をシステム別に表示することにより、どの変更がビジネス・アプリケーションに影響を与えているかを容易に確認できます。監視は、認証済、非認証、未監査、または非認証と未監査の両方を基準にフィルタできます。また、時間別にフィルタすることもできます。
これは、1つ以上のビジネス・アプリケーションを選択し、監視の相対数を参照できることから始まります。ITマネージャおよびコンプライアンス監査者がターゲットの使用目的を把握していない可能性があるため、このレポートはビジネス・アプリケーション・レベル(汎用システム)で開始されます。ビジネス・アプリケーションはCloud Controlで汎用システムとしてモデル化されます。
より熟達したユーザーであれば、これが作業対象のビジネス・アプリケーションである場合、このビジネス・アプリケーション・レベルで開始してもかまいません。
システム別に監視を表示するには、次の手順に従います。
コンプライアンス標準の構造に関係する場合の監視を表示する機能は、ITマネージャ、部門オーナー、コンプライアンス・マネージャ、経営者など技術者以外が実行するのが一般的です。
組織が準拠しているITコンプライアンス・フレームワークが反映されている特定のコンプライアンス・フレームワーク・セットを識別できます。監視は、認証済、非認証、未監査、または非認証と未監査の両方を基準にフィルタできます。また、時間別にフィルタすることもできます。
コンプライアンス・フレームワーク別に監視を表示するには、次の手順に従います。
これらの画面で提供されるこのドリルダウン機能により、監視の発生箇所を容易に特定できます。数百のビジネス・アプリケーションにわたって数万のターゲットが存在する環境では、ユーザーが検索条件を正確に把握していないかぎり、表と検索を使用して単純に監視を表示することが重要です。このような大規模な環境では、たとえアクティビティが少ない場合でも、数時間のうちに数千の監視が発生する可能性があります。
2画面による参照でも、使用環境内でどのような監視が行われたかに関する最適なビューを得られない場合は、監視を検索するための検索機能を使用することもできます。
監視を検索するには、次の手順に従います。
監視は、コンプライアンス基準ルール、ターゲット、およびアクションを実行したユーザーに基づいて論理的にバンドルされます。このバンドルの詳細は、リアルタイム・モニタリング・ルールの作成に関する項を参照してください。
バンドルの1つ以上の監視が認証されない場合、そのバンドルは違反とみなされます。この違反の結果、Cloud Controlインシデント管理でイベントが作成されます。イベント名は、リアルタイム・モニタリング・ルールに定義されているメッセージ・フィールドに基づいて付けられます。インシデント管理UIでこのイベントを表示する場合、ターゲット・タイプ、エンティティ・タイプ、バンドル内の監視の数、監査ステータス別の監視などのバンドルの詳細が複数のフィールドに表示されます。「監査ステータスの更新」リンクをクリックすると、バンドル監視ページに移動できます。
この「監視」ページには、このイベントの監視バンドルに含まれている監視のリストが表示されます。各監視は、認証済/非認証ステータス、ユーザー、時間などの様々な属性でフィルタできます。
次の各項では、リアルタイム・モニタリングの監視の監査ステータスを調整する方法や、コンプライアンス結果を評価する上で通知がどのように役立つかについて説明します。
リアルタイム監視の詳細を表示している場合は常に、監視の監査ステータスを変更できます。ユーザー処理を調査して、アクティビティが異なる監査ステータスになる必要があると判断した場合、監視の監査ステータスを上書きできます。リアルタイム・モニタリング・ルールに基づいて、すべての監視は、事前設定された監査ステータスを持つか、変更リクエスト管理サーバーとの統合によって決定された監査ステータスを持ちます。使用可能な監査ステータスは、次のとおりです。
非監査: 監視が良好か不良かを確認する評価が行われていません。
認証済: 監視は良好で、実行することが望ましいアクションであったことが確認されました。
非認証: 監視は不良で、不要なアクションであったことが確認されました。
非認証-クリア済: 監視は不良で、不要なアクションであったことが前に確認されましたが、修正、ポリシー変更または補正制御によって処理されており、現在はクリアされています。
監視の監査ステータスを変更するには、UIページ、監視検索ページ、またはインシデント・マネージャUIを使用した参照によって監視を表示します。監視を選択し、「監査ステータスの更新」をクリックします。ポップアップが表示され、新規監査ステータス、およびステータスの変更理由を説明するコメントを選択できます。監視ごとに監査ステータスのすべての変更の履歴が保持されます。
Cloud Controlインスタンスによって統合用の変更リクエスト管理サーバー・コネクタが使用されている場合、特別な考慮事項があります。
非認証の監視を認証済の監視に変更する場合、変更を認証する変更リクエストIDを入力するオプションがあります。この変更リクエストIDは、変更リクエスト管理システムにすでに存在するリクエストと一致する必要があります。コメントも入力できます。変更リクエストIDが提供されると、システムが自動的に認証したかのように、変更リクエストに変更の注釈が付けられます。監視バンドルにインシデントが作成された場合、イベント/インシデントが新しい数の非認証の監視で更新されます。
認証済の監視を非認証または未監査の監視に変更する場合、変更リクエストに付加された注釈はロールバックされます。監視バンドルに対してすでにインシデントが発生している場合は、注釈が変更され、インシデント内の非認証の監視の数が更新されます。これがグループ内の最初の非認証の監視である場合は、イベントが作成され、インシデントが発生します。変更に関するコメントを入力できます。
監視を手動で認証済に設定して変更リクエストIDを入力し、ルールで変更管理との統合が有効化されている場合、変更リクエストの属性は監視と比較されません。その変更リクエストは、単に監視詳細によって更新されます。
変更管理サーバーで注釈をロールバックすると、監視の注釈は実際に削除されるのではなく、ロールバック済としてマークされます。これは、注釈が削除された理由がわからないことなどによってユーザーが混乱するのを防ぐためです。また、後で監視が再び認証済になった場合は、単にロールバック済のマーキングが削除され、注釈が戻されます。
コンプライアンス基準ルールが作成され、そのルールとの変更管理リコンシリエーションを使用しない場合、監視で認証/非認証の自動チェックは実行されません。このルールに、各監視バンドルに対して情報イベントが生成されるように指定できます。この構成方法の詳細は、リアルタイム・モニタリング・ルールの作成に関する項を参照してください。
イベントには注釈が付きます。ユーザーは、インシデント管理コンソールからイベントおよびインシデントを参照できます。単一イベントを参照する場合、その監視バンドルのイベントに関連付けられている監視を参照できるリンクがあります。各監視バンドルには、1つのイベントのみが作成されます。バンドル内の少なくとも1つの監視が認証されないと、そのバンドルは違反とみなされ、イベントが生成されます。
この通知はユーザーによる操作または後続処理を必要としないため、情報として扱われます。後から誰かがこれらの未監査の監視のいずれかを認証済または非認証の監視に変更した場合、未監査の監視に対する新規情報イベントは再配信されません。イベントは、監視バンドルに対して1回のみ配信されます。ただし、いずれかの監視が手動で非認証に設定された場合は、その監視バンドル全体に対して違反が発生します。
バンドル内の少なくとも1つの監視が非認証状態である場合、違反が作成されます。この違反は、インシデント・マネージャ・コンソールでイベントになります。「インシデント・マネージャ」機能を使用して通知を設定します。この詳細は、インシデント・マネージャ・ページで、オンライン・ヘルプの概要に関する章の通知の設定に関する項にある、ルールを使用した通知の設定に関する項のリンクをクリックしてください。
コンプライアンス機能を使用する前に、コンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールを、エンタープライズに対して定義する必要があります。
次の各項では、これらのコンプライアンス・エンティティを定義および維持する方法について説明します。
コンプライアンス・フレームワークは、1つ以上のコンプライアンス標準、コンプライアンス標準ルール・フォルダおよびコンプライアンス標準ルールに任意のノードをマップできる階層構造です。コンプライアンス・フレームワークは、会社で使用する規制または標準ベースのコンプライアンス構造と類似した構造に標準をマップする方法を提供します。
コンプライアンス・フレームワークの管理
コンプライアンス・フレームワークを管理するには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
「コンプライアンス・フレームワーク」タブをクリックします。
管理するコンプライアンス・フレームワークをハイライト表示し、実行するアクションを選択します。
Oracle提供のフレームワークおよびユーザー定義のコンプライアンス・フレームワーク
Oracle提供のコンプライアンス・フレームワークと、ユーザー定義のコンプライアンス・フレームワークがあります。
Oracle提供のコンプライアンス・フレームワークには、次が含まれます。
Oracleサポート・コンプライアンスは、Oracleサポータビリティに対して期待される環境コンプライアンスをチェックするコントロールのコレクションです。
Oracleの汎用コンプライアンス・フレームワークは、変更を追跡するためのコンプライアンス標準と関連付けられた制御、および組織がITポリシーにどの程度準拠しているかを判断するためにITインフラストラクチャ全体に実行されるイベントの標準的なセットです。
セキュリティ技術導入ガイド(STIG)は、セキュリティ技術導入ガイド(STIG)コンプライアンスを確認するための一連の標準です。
ユーザー定義のコンプライアンス・フレームワーク
組織のニーズを満たすコンプライアンス・フレームワークを定義できます。
Oracleの提供するコンプライアンス・フレームワークは、削除または編集できません。ただし、これらのフレームワークを拡張する場合、類似作成機能を使用して、Oracle提供のフレームワークに基づいて独自のユーザー定義フレームワークを作成してから、新規フレームワークを編集することができます。
推奨: STIGおよびOracleの汎用コンプライアンス用として提供されているコンプライアンス・フレームワークのような上位レベルのコンプライアンス・フレームワークを作成することを強くお薦めします。
コンプライアンス・フレームワークを作成する利点
コンプライアンス標準は、ターゲットに対するテストを実行するために定義します。これには、構成値が正しく設定されているかのテスト、リアルタイム・ファイルの変更が行われているかを確認するテストなどがあります。コンプライアンス・フレームワークによって、コンプライアンス構想のどの制御領域までこれらのテストの結果が影響するかをマップします。
ある組織で、Oracle提供のコンプライアンス・フレームワークを拡張するコンプライアンス・フレームワークを定義するとします。これを行うには、Oracle提供のコンプライアンス・フレームワークなどの新規コンプライアンス・フレームワークを作成し、新規または既存のコンプライアンス標準を組み込みます。これにより、各コンプライアンス標準は適切なフレームワーク階層フォルダにマップされ、標準に対する違反もこのフレームワーク・フォルダにマップされるようになります。フレームワーク内の各フォルダは1つの制御領域を表します。
コンプライアンス・フレームワークを使用する理由
コンプライアンス・フレームワークを作成するのは、次のようないくつかの理由があります。
企業で使用される規制および基準のコンプライアンス制御への基本的なIT違反のマッピングによる、違反の影響を受けるコンプライアンス制御領域の簡単な特定
コンプライアンス指定レベルでのコンプライアンス監査
監査、セキュリティ評価および傾向分析
コンプライアンス・フレームワークで実行可能な操作
コンプライアンス・フレームワークでは、次のことを実行できます。
業界標準のコンプライアンス制御領域を表し、使用している内部フレームワークに合せて作成します。
多くの会社が、業界標準のフレームワークを使用して開始しますが、独自のニーズや監査要件に応じて変更します。
危険な状態にあり、違反に基づく補正制御が必要な可能性があるコンプライアンス制御を特定することにより、IT監査をサポートします。影響を受ける制御領域にコンプライアンス・チェックをマップしない場合、コンプライアンス監査における実質的な影響を特定することが困難になります。
コンプライアンス・フレームワークには様々なタイプのコンプライアンス標準(リポジトリ、WebLogic Serverの署名、リアルタイム・モニタリング)を組み込むことができるため、レポートを目的として様々なタイプの類似チェックをグループ化する上で役立ちます。
使用上の注意
リポジトリ・ルールの評価結果は、コンプライアンス・フレームワーク内のコンプライアンス標準ルールが変更または削除された場合に無効化されることがあります。コンプライアンス標準の評価では、コンプライアンス標準内の各コンプライアンス標準ルールの現在のコンプライアンス標準ルールの定義を常に参照しています。
コンプライアンス・フレームワークで次の操作を実行できます。
次の各項では、これらの操作について説明します。
注意: コンプライアンス・フレームワークで操作を実行する前に、必要な権限があることを確認します。たとえば、コンプライアンス・フレームワークを作成する場合、フレームワークの定義時に含めるコンプライアンス標準へのアクセス権限を持っていることを確認します。(コンプライアンス機能の使用に必要なロールおよび権限を参照してください。)
コンプライアンス・フレームワークを作成しやすくするには、コンプライアンス・フレームワークによって参照されるコンプライアンス標準がCloud Controlですでに定義されていることを確認します。システムの即時利用可能なコンプライアンス標準およびユーザー定義のコンプライアンス標準をコンプライアンス・フレームワークの任意の要素に追加できます。コンプライアンス標準を事前に定義しない場合、これらを後で追加する必要があります。
コンプライアンス・フレームワークを作成するには、次の手順に従います。
使用上の注意
開発
コンプライアンス・フレームワークが開発中で、定義された作業はまだ進行中であることを示します。開発モードの間、コンプライアンス・フレームワークの編集およびコンプライアンス・フレームワークの削除など、コンプライアンス・フレームワークのすべての管理機能がサポートされます。開発のコンプライアンス標準の結果は、ターゲットとコンソールのホームページ、およびコンプライアンス・ダッシュボードには表示されません。
ライフサイクル・ステータスのデフォルトは開発です。これを「本番」に一度のみ更新できます。本番から開発には変更できません。
本番
コンプライアンス・フレームワークが承認され、本番の品質を持つことを示します。コンプライアンス・フレームワークが本番モードの場合、結果はコンプライアンス・ダッシュボード、ターゲットおよびコンソール・ホームページにロールアップされます。
本番のコンプライアンス・フレームワークは、本番のコンプライアンス標準のみを参照できます。本番のコンプライアンス・フレームワークを編集して、本番のコンプライアンス標準への参照のみを追加/削除できます。
ライフサイクル・ステータスは、本番から開発には変更できません。
「キーワード」列でソートすると、同じキーワードを持つすべてのコンプライアンス・フレームワークはグループ化されます。
コンプライアンス・フレームワークに追加されたリポジトリまたはWebLogic Serverの署名のコンプライアンス標準を変更する場合は、コンプライアンス標準を直接編集するか、「インポート」を使用してコンプライアンス標準を新規の設定で上書きし、既存の評価を無効にします。つまり、変更したコンプライアンス標準が評価済のコンプライアンス・フレームワークに含まれており、評価結果がある場合は、これらの結果は表示されなくなります。
コンプライアンス標準をコンプライアンス・フレームワークに追加
コンプライアンス標準のマップ先のフレームワーク・フォルダ要素をクリックします。右クリックして「基準の追加」を選択し、このフォルダにマップする標準を選択できるポップアップを表示します。
検索基準を使用して、選択リストに表示されるコンプライアンス標準の数を最小化します。
選択し終わったら、「OK」をクリックします。フレームワーク階層画面がリフレッシュされ、新しく組み込んだコンプライアンス標準がフレームワーク・フォルダ要素の下に表示されます。
重要度の編集
選択したコンプライアンス・フレームワーク・フォルダの一部に組み込むコンプライアンス標準をマップした後、指定したこのフォルダの各コンプライアンス標準の重要度を編集できます。
重要度は、このフレームワーク・フォルダ内のこのコンプライアンス標準に対してコンプライアンス・スコアを計算する方法に影響します。
このスコアの計算方法の詳細は、「コンプライアンス・スコアおよび重要度の概要」を参照してください。
コンプライアンス・フレームワークの編集機能を使用して、新規コンプライアンス標準ルールをコンプライアンス・フレームワークに追加するか、既存のコンプライアンス・フレームワークの詳細を編集するか、または、コンプライアンス・フレームワークからコンプライアンス標準を削除します。
コンプライアンス・フレームワークを編集するには、次の手順に従います。
使用上の注意
コンプライアンス・フレームワークの定義を変更すると、傾向分析に影響を与える場合があります。
コンプライアンス・フレームワークに追加するコンプライアンス標準は、「コンプライアンス標準ライブラリ」ページで表示されるように、システム定義およびユーザー定義のコンプライアンス標準になります。
コンプライアンス・フレームワークに追加されたリポジトリまたはWebLogic Serverの署名のコンプライアンス標準を変更する場合は、コンプライアンス標準を直接編集するか、「インポート」を使用してコンプライアンス標準を新規の設定で上書きし、既存の評価を無効にします。つまり、変更したコンプライアンス標準が評価済のコンプライアンス・フレームワークに含まれており、評価結果がある場合は、これらの結果は表示されなくなります。このコンプライアンス・フレームワークの評価結果は、次の評価を行った後に再度表示されるようになります。新しい評価には、コンプライアンス・フレームワーク内でのコンプライアンス標準の変更も対象になります。
重要度は、このフレームワーク・フォルダ内のこのコンプライアンス標準に対してコンプライアンス・スコアを計算する方法に影響します。
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」コンプライアンス標準の重要度は「標準」であり、このコンプライアンス・フレームワークでは、セキュリティ・チェックを実行するその他の追加コンプライアンス標準の方が重要度が高くなります。
コンプライアンス・フレームワークを削除するには、次の手順に従います。
使用上の注意
コンプライアンス・フレームワークは1つずつ、またはリストで削除できます。コンプライアンス・フレームワークを削除すると、関連するメタデータと評価結果も削除されます。
ORACLEによって定義されたコンプライアンス・フレームワークは削除できません。これらは、コンプライアンス・フレームワークのリスト・ページ上のコンプライアンス・フレームワーク名の前にあるロック・アイコンの存在によって示されます。
エクスポート機能は、管理リポジトリおよびCloud Controlインスタンス間でユーザー定義のコンプライアンス・フレームワーク定義をトランスポートするためのメカニズムです。エクスポートによって、オペレーティング・システム・ファイルに定義を格納します。エクスポートしたコンプライアンス・フレームワーク定義は、XMLフォーマットであるため、Oracleコンプライアンス標準定義(XSD)フォーマットに準拠しています。コンプライアンス・フレームワークの定義を変更でき、生成されたコンプライアンス・フレームワーク定義を別の管理リポジトリに再インポートできます。
コンプライアンス・フレームワークをエクスポートするには、次の手順に従います。
指定するディレクトリおよびファイルにコンプライアンス・フレームワークのXML表現が生成されます。
インポートにより、すでに所有しているコンプライアンス・フレームワークの再使用、Cloud Controlの複数のインスタンス間でのフレームワーク定義の共有、フレームワークのオフライン編集の有効化が可能になります。
コンプライアンス・フレームワークをインポートする前に、インポートするコンプライアンス・フレームワークがファイルに定義されていることを確認します。このファイルには、Cloud Controlにアクセスするために使用しているブラウザからローカルにアクセスできる必要があります。また、インポートするコンプライアンス・フレームワーク定義XMLファイルへのアクセス権限を持っていることも確認します。
注意:
ルールを含むコンプライアンス標準(または、標準を含むフレームワーク)をUIまたはコマンドライン・インタフェースからインポートする場合は、<ComplianceContent>を含むxmlファイルをルートとしてインポートします。このルート・ファイルには、ルール、標準、フレームワークおよび標準グループのリストが含まれています。
これにより、フレームワークおよび標準の定義が正常にインポートされていることがわかります。さらに、関連するターゲットはすべて、変更された定義に基づいて再評価されます。
コンプライアンス・フレームワークをインポートするには、次の手順に従います。
コンプライアンス・フレームワークを参照するには、次の手順に従います。
コンプライアンス・フレームワークを検索するには、次の手順に従います。
コンプライアンス・フレームワークの評価結果を参照するには、次の手順に従います。
結果には、次のものがあります。
コンプライアンス・フレームワークで参照されるコンプライアンス標準に対して評価される異なるターゲットの平均コンプライアンス・スコア
コンプライアンス・フレームワークで参照される異なるコンプライアンス標準のターゲット評価(クリティカル、警告、コンプライアンス)の数
コンプライアンス・フレームワークで参照されるコンプライアンス標準に関連する違反(クリティカル、警告、マイナー警告)の数
コンプライアンス・フレームワークの評価結果を検索するには、次の手順に従います。
コンプライアンス・フレームワークのエラーを参照するには、次の手順に従います。
使用上の注意
エラーは、予期しない内部エラーまたはテスト中のエラーです。
通常、評価エラーの原因となるのは構成およびインストールの問題です。次のマニュアルの情報を参照してください。
『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』
『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』
インストールおよび構成を正しく行ってもエラーが解消されない場合は、オラクル社にサポートを依頼してください。
コンプライアンス・フレームワークのエラーを検索するには、次の手順に従います。
使用上の注意
エラーは、予期しない内部エラーまたはテスト中のエラーです。
通常、評価エラーの原因となるのは構成およびインストールの問題です。次のマニュアルの情報を参照してください。
『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』
『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』
インストールおよび構成を正しく行ってもエラーが解消されない場合は、オラクル社にサポートを依頼してください。
コンプライアンス標準は、チェックまたはルールのコレクションです。それは、制御に従っているかどうかを判断するために、ITインフラストラクチャのセットに対してテストする必要があるコンプライアンス制御をCloud Controlによって表現したものです。
コンプライアンス標準は、階層構造内の次の各要素で構成されています(図48-9を参照)。
コンプライアンス標準ルール
ネストしたルール・フォルダおよび個別コンプライアンス標準ルールを含めることができるルール・フォルダ。
ルール・フォルダは、コンプライアンス標準ルールを含む階層構造です。ルール・フォルダには、同じレベルの兄弟に対するルール・フォルダの重要性を示す重要度属性があります。この重要度は、他の兄弟ルール・フォルダからロールアップされているコンプライアンス・スコアの算出時に考慮されます。特定のルール・フォルダでは発生するテストが複数になる可能性がありますが、この方法で、特定のテストを他のテストより大きく重み付けできます。
含まれているコンプライアンス標準。コンプライアンス標準には、他のコンプライアンス標準を含めることができます。
コンプライアンス標準で実行可能な操作
業界全般の標準を表すことが可能。コンプライアンス標準は、単一のターゲット・タイプに適用可能です。
参照構成または認定構成として使用可能
企業のベスト・プラクティスを記述したコンプライアンス標準のルールの集合とすることが可能
たとえば、ターゲットがコンプライアンス標準に準拠していない場合、そのターゲットにはコンプライアンス標準へのコンプライアンスがないということになります。
コンプライアンス標準へのアクセス
即時利用可能なコンプライアンス標準(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提供のコンプライアンス標準を使用することも、独自の基準を作成することもできます。
コンプライアンス標準を作成する前に、コンプライアンス標準およびコンプライアンス標準ルールは、コンプライアンス標準によって参照され、管理リポジトリで定義されていることを確認します。
コンプライアンス標準を作成するには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
「コンプライアンス標準」タブをクリックします。
「作成」ボタンをクリックします。名前、作成者、標準を適用可能なターゲット・タイプおよび標準タイプの入力を求められます。標準タイプは次のとおりです。
リポジトリ
WebLogic Serverの署名
リアルタイム・モニタリング
エージェント側
「続行」をクリックします。
結果の「プロパティ」タブで、プロパティ値を入力します。
「追加」をクリックして、この基準を識別するキーワードを追加することも、既存のキーワードを使用することもできます。
コンプライアンス標準をさらに定義するには、ページの左上にあるコンプライアンス標準の名前を右クリックします。このメニューから、ルール・フォルダを作成し、ルールおよび組み込まれているコンプライアンス標準を追加できます。
ルール・フォルダを使用して、選択したルール・フォルダに対して評価されたターゲットおよび選択したルール・フォルダに評価されたコンプライアンス標準ルールによって分類された、結果のサマリーを表示できます。
「保存」をクリックします。
コンプライアンス標準を定義したら、標準をターゲットに関連付け、ターゲットのタイプ固有の設定を定義します。
コンプライアンス標準ライブラリ・ページで、正しいコンプライアンス標準がハイライトされていることを確認します。
ターゲットの関連付けボタンをクリックします。
コンプライアンス標準に対するターゲットの関連付けページで、「追加」をクリックし、標準に対して評価するターゲットを選択します。
「検索と選択: ターゲット」ポップアップで、適切なターゲットを選択します。
「選択」をクリックします。
ターゲットをコンプライアンス標準に関連付けたら、ターゲットに関連付けられたパラメータを編集できます。
コンプライアンス標準に対するターゲットの関連付けページで、「編集」をクリックします。
コンプライアンス標準パラメータのカスタマイズ・ページで、必要に応じてパラメータを変更します。
注意:
ターゲットのホームページからコンプライアンス標準をターゲットに関連付けることもできます。ターゲットのホームページの左上で、ターゲットの名前を右クリックします。表示されたメニューで、「コンプライアンス」、「標準アソシエーション」の順に選択します。
別のコンプライアンス標準へのコンプライアンス標準の組込み
コンプライアンス標準を含めるページを使用して、1つ以上のコンプライアンス標準を選択し、コンプライアンス標準に組み込みます。このリストは、コンプライアンス標準のターゲット・タイプで事前にフィルタ処理されます。
別のコンプライアンス標準へのコンプライアンス標準の組込みの手順:
使用上の注意
コンプライアンス標準は階層的であるため、ツリー内の上位ノードはルート・ノードと呼ばれます。
コンプライアンス標準を作成すると、バージョンは1になります。
ライフサイクル・ステータスのデフォルトは開発です。これを「本番」に一度のみ更新できます。本番から開発には変更できません。
開発
コンプライアンス標準が開発中で、定義された作業はまだ進行中であることを示します。開発モードの間、コンプライアンス標準の完全な編集およびコンプライアンス標準の削除など、コンプライアンス標準のすべての管理機能がサポートされます。ただし、コンプライアンス標準が開発モードの間、その結果は、「コンプライアンス結果」内、およびターゲットや「Cloud Control」ホームページには表示されません。
本番
コンプライアンス標準が承認され、本番の品質を持つことを示します。コンプライアンス標準が本番モードの場合、本番ルールへの参照を追加でき、ルールへの参照のみをコンプライアンス標準から削除できるなど、編集機能が制限されます。コンプライアンス標準の表示およびコンプライアンス標準の削除など、他のすべての管理機能はサポートされます。本番のコンプライアンス標準の結果は、ターゲットとコンソールのホームページ、およびコンプライアンス・ダッシュボードに表示されます。本番のコンプライアンス標準は、本番のコンプライアンス標準および本番のコンプライアンス標準ルールのみを参照できます。
本番モードに変更すると、その結果はコンプライアンス・ダッシュボード、ターゲット・ホームページおよび「Cloud Control」ホームページにロールアップされます。本番のコンプライアンス標準は、他の本番のコンプライアンス標準および本番のコンプライアンス標準ルールのみを参照できます。本番のコンプライアンス標準を編集して、本番のコンプライアンス標準および本番のコンプライアンス標準ルールへの参照のみを追加および削除できます。
既存のコンプライアンス標準ルール設定を編集して、コンプライアンス標準をカスタマイズできます。コンプライアンス・スコア計算に追加されたルールの重要度の変更、テンプレートのオーバーライドの回避、デフォルトのパラメータ値のオーバーライド(可能な場合)、およびコンプライアンス標準ルールの評価からのオブジェクトの除外(可能な場合)が可能です。
注意: Oracle提供のコンプライアンス標準、つまり、Oracleが定義するコンプライアンス標準は編集できません。
コンプライアンス標準を編集するには、次の手順に従います。
コンプライアンス標準を削除する前に、コンプライアンス標準がコンプライアンス・フレームワークによって使用されていないことを確認します。すべてのコンプライアンス・フレームワーク内のコンプライアンス標準に対する任意の参照を削除する必要があります。
注意: Oracle提供のコンプライアンス標準、つまり、Oracleが提供するコンプライアンス標準は削除できません。
コンプライアンス標準を削除するには、次の手順に従います。
エクスポート機能は、管理リポジトリおよびCloud Controlインスタンス間でユーザー定義のコンプライアンス標準定義をトランスポートするためのメカニズムです。エクスポートによって、オペレーティング・システム・ファイルに定義を格納します。エクスポートしたコンプライアンス標準定義は、XMLフォーマットであるため、Oracleコンプライアンス標準定義(XSD)フォーマットに準拠しています。コンプライアンス標準の定義を変更でき、生成されたコンプライアンス標準定義を別の管理リポジトリに再インポートできます。
コンプライアンス標準をエクスポートする前に、エクスポートするコンプライアンス標準へのアクセス権限を持っていることを確認します。
コンプライアンス標準をエクスポートするには、次の手順に従います。
インポート機能では、単一のユーザー定義のコンプライアンス標準、またはユーザー定義のコンプライアンス標準のリストの定義が含まれている、XMLベースのコンプライアンス標準定義ファイルをアップロードします。このアップロードによって、ユーザー定義のコンプライアンス標準またはユーザー定義のコンプライアンス標準のリストが新規作成されます。このコンプライアンス標準は、以前にエクスポートされたものである必要があります。
コンプライアンス標準のXML定義は、「ユーザー定義のコンプライアンス標準のXMLスキーマ定義」に定義されているコンプライアンス標準のXMLスキーマ定義(XSD)に準拠している必要があります。
コンプライアンス標準をインポートする前に、インポートするコンプライアンス標準がファイルに定義されていることを確認します。このファイルには、Cloud Controlにアクセスするために使用しているブラウザからローカルにアクセスできる必要があります。また、インポートするコンプライアンス標準定義XMLファイルへのアクセス権限を持っていることも確認します。
コンプライアンス標準をインポートするには、次の手順に従います。
既存のコンプライアンス標準の上書きチェック・ボックスを選択して、既存のコンプライアンス標準をオーバーライドできます。結果は次のようになります。
コンプライアンス標準をオーバーライドする場合、オーバーライドによって、そのコンプライアンス標準の評価結果のみでなく、すべてのターゲットおよびテンプレートの関連付けも削除されます。
上書きされたコンプライアンス標準がコンプライアンス・フレームワークの一部である場合、コンプライアンス・フレームワーク内でコンプライアンス標準が更新されます。ただし、コンプライアンス・フレームワーク内のそのコンプライアンス標準の評価結果は無効化されます。
コンプライアンス標準を参照するには、次の手順に従います。
コンプライアンス標準を検索するには、次の手順に従います。
コンプライアンス標準の評価結果を検索するには、次の手順に従います。
コンプライアンス標準の評価エラーを参照するには、次の手順に従います。
コンプライアンス標準のエラーを検索するには、次の手順に従います。
使用上の注意
評価エラー・ページには、メトリック収集の結果発生したエラー、および最後のポリシー評価中に発生したエラーが表示されます。
検索フィルタを使用して、指定する検索基準セットと一致する評価エラーのみを表示します。
「メッセージ」列のメッセージをクリックして、エラーを解決するための対策を決定します。
まず、評価エラー・ページに、すべての評価エラーが表示されます。
通常、評価の結果は、前回の評価結果を上書きします。ただし、評価が失敗またはデータ・プロバイダ収集が失敗した場合は、前回の結果は上書きされず、そのまま残ります。
根本の問題が解決されると、エラーは報告されません。
検索フィルタの例
デフォルトでは、エンタープライズ構成内のすべての評価エラーが結果表に表示されます。ただし、検索基準のセットを指定し、基準と一致する評価エラーのみが結果表に表示されるように検索を実行できます。
たとえば、「ターゲット・タイプ」リストで「ホスト」、「ターゲット名」リストで「次を含む」、その隣の「ターゲット名」テキスト・フィールドで「-sun」を選択し、「実行」をクリックすると、Cloud Controlは、名前に「-sun」を含むホストのコンプライアンス標準ルールの評価エラーのみを結果表に表示します。
コンプライアンス標準を作成したら、標準を1つ以上のターゲットに関連付けることができます。関連付けの一部として、ターゲットに関連する基準の重要度、コンプライアンス標準の評価のステータス、評価ステータスの変更理由およびしきい値などのパラメータをカスタマイズできます。
コンプライアンス標準をターゲットに関連付ける前に、コンプライアンス標準を関連付けるターゲットへのアクセス権限を持っていることを確認します。
コンプライアンス標準をターゲットに関連付けるには、次の手順に従います。
ターゲットに対するコンプライアンス標準の評価をさらにカスタマイズするために、コンプライアンス標準パラメータ(重要度、クリティカルのしきい値および警告のしきい値)を変更できます。コンプライアンス標準内で使用されたコンプライアンス標準ルールで、カスタマイズを行うこともできます。たとえば、「セキュア・ポート」コンプライアンス標準ルールの場合、DFLT_PORTはオーバーライド・パラメータです。ポートのデフォルト値を変更できます。オブジェクトを評価から除外することもできます(たとえば、特定のポートを評価から除外するなど)。
注意: リアルタイム・モニタリングの場合、ファセット・パターンで使用されているパラメータを変更できます。自動変更管理のリコンシリエーション設定を変更することもできます。
クリティカルのしきい値と警告のしきい値を変更することにより、コンプライアンス標準スコア・イベントを生成する方法を指定します。たとえば、実際のスコアがクリティカルのしきい値より低い場合、クリティカル・スコア・イベントが呼び出されます。
ベスト・プラクティス
コンプライアンス・アソシエーションの実行方法には、テストと編集に対するものと、本番と一括アソシエーションに対するものの2つがあります。
標準/ターゲットと標準ルール、またはルール・フォルダ/ターゲット・アソシエーション設定のテストと編集目的の場合、この項での前述のようにターゲットとコンプライアンス標準を関連付けます。
コンプライアンスのUIを使用して次のことができます。
アソシエーションをテストし、テストが完了したら削除します。
重要度、評価ステータスおよびしきい値についてアソシエーションを編集します。
注意: アソシエーションは、「管理グループ」ページおよび「テンプレート・コレクション」ページを使用して編集できません。
本番および一括アソシエーションの場合、「管理グループ」ページおよび「テンプレート・コレクション」ページを使用してターゲットを関連付けます。
「設定」メニューから、「ターゲットの追加」、「管理グループ」の順に選択します。「アソシエーション」タブをクリックします。
階層内の各管理グループは、メンバーシップ基準によって定義されているため、ターゲットはグループのメンバーシップ基準を満たす場合にのみグループに追加されます。したがって、ターゲットがグループに正常に追加されると、そのグループの適切なコンプライアンス標準に自動的に関連付けられます。これによって、ターゲットの多数のコンプライアンス標準への関連付けが容易になります。
コンプライアンス標準を作成したら、基準をグループ・ターゲットに関連付けることができます。これにより、キー標準がグループの一部のときにターゲットへのアソシエーションを可能にします。
コンプライアンス標準をグループ・ターゲットに関連付ける前に、次の前提条件が満たされていることを確認してください。
リアルタイム・モニタリング・コンプライアンス標準をターゲットに関連付ける場合、ターゲットでリアルタイム・モニタリングを有効化するための設定手順が実行されていなかったり、構成に不整合がある場合があります。この場合、「ターゲットの関連付け」画面に警告が表示されます。この画面にアクセスするには、コンプライアンス標準を選択し、「ターゲットの関連付け」ボタンを選択します。警告が存在する場合、ターゲット・アソシエーションの上にあるリンクに警告アイコンが表示されます。このリンクをクリックすると、このコンプライアンス標準に関する現在の警告がすべてリストされた画面が表示されます。
モニタリング対象のホスト/ターゲット上の構成問題を解決したり、ルール/ファセットのコンテンツを修正することにより、警告はすべて修正できます。根本の問題が解決されると、これらの警告は自動的にクリアされます。
この警告のリストは、「リアルタイム監視」ページ(「Enterprise」メニューから「コンプライアンス」、「リアルタイム監視」の順に選択)から入手することもできます。ここでは、監視を参照するために3つのタイプのレポートの1つを選択できます。画面の下半分には、リアルタイム・モニタリングに関連するすべてのターゲットおよびコンプライアンス標準に対してアクティブな警告がすべて表示されます。
セキュリティ・コレクションはデフォルトでは無効であるため、セキュリティ・コンプライアンス標準およびレポートなどのセキュリティ機能を使用する前に有効にする必要があります。セキュリティ・メトリックを有効にするには、次の手順に従います。
「OK」をクリックすると、「モニタリング・テンプレート」ページに確認メッセージが表示されます。
コンプライアンス標準は、1つ以上のコンプライアンス標準ルールを参照します。コンプライアンス標準を作成する際には、標準は、1つ以上の関連するコンプライアンス・フレームワークに適切にマッピングできるほど十分に詳細である必要があります。たとえば、Oracleの汎用コンプライアンス・フレームワークに存在する、次のようなコンプライアンス・フレームワーク構造を考えてみます。
変更および構成管理(コンプライアンス・フレームワーク・サブグループ)
データベース変更(コンプライアンス・フレームワーク・サブグループ)
Oracle Databaseを構成するためのベスト・プラクティス(コンプライアンス標準)
Oracle RACデータベースを構成するためのベスト・プラクティス(コンプライアンス標準)
Oracleプラガブル・データベースを構成するためのベスト・プラクティス(コンプライアンス標準)
このコンプライアンス・フレームワーク構造の一部にマップされる必要がある多くのコンプライアンス標準が存在し、それぞれに、この特定の要件に対処するための独自のルールがあります。ある標準は、構成設定が正しく設定されていることをチェックします。別の標準は、構成設定が変更されたかどうかをリアルタイムでチェックするために使用されます。
この例では、データベース変更コンプライアンス・フレームワーク・サブグループは、多くの異なるタイプのターゲットに関連しています。すべてのOracle Database、Oracle RACデータベースおよびOracleプラガブル・データベースには、すべてが保護される必要がある独自のタイプの構成があります。これらのターゲット固有の構成をモニターするために作成されたすべての標準は、同じデータベース変更サブグループにマップされます。
コンプライアンス標準が、既存および将来のコンプライアンス・フレームワークにマップできるように詳細な方法で構造化される場合、ルール内の違反をロールアップし、コンプライアンス・フレームワークのスコアに正しく影響を与えることができます。
ルール・フォルダは、コンプライアンス標準内の類似したコンプライアンス標準ルールのグループ化に使用されるオプションの階層構造です。コンプライアンス標準に個別コンプライアンス標準ルールを追加したり、標準内に多数のルールが存在する場合はこれらをグループ化できます。コンプライアンス標準内の重要度設定がそれぞれ異なる複数のルール・フォルダに同じコンプライアンス標準ルールを追加できます。コンプライアンス標準内に、ルール・フォルダをネストできます。
ルール・フォルダには、同じレベルの兄弟に対するルール・フォルダの重要性を示す重要度属性があります。この重要度は、他の兄弟ルール・フォルダからロールアップされているコンプライアンス・スコアの算出時に考慮されます。特定のルール・フォルダでは発生するテストが複数になる可能性がありますが、この方法で、特定のテストを他のテストより大きく重み付けできます。
次の各トピックでは、コンプライアンス標準ルール・フォルダについて説明します。
ルール・フォルダを作成するには、次の手順に従います。
フォルダを作成し、フォルダにコンプライアンス標準ルールを移入したら、フォルダについて次のアクションを実行できます。
ツリー内のルール・フォルダ・ノード、ルール参照ノード、およびコンプライアンス標準参照ノードを並べ替えるか、これらのノードを削除して、ツリー構造を編集します。
任意のノード(最上位レベルのコンプライアンス標準ノードを除く)・オブジェクトを選択し、コンテキスト・メニューから「削除」メニュー・アイテムをクリックします。削除オプションは、ルート・ノードでは使用できません。複数のオブジェクトを選択し、「削除」をクリックして、複数のノードを削除します。
コンプライアンス標準ルールは、構成データの変更がコンプライアンスに影響するかどうかを決定するためのテストです。テストの結果に基づいて、コンプライアンス・スコアが計算されます。これらのルール・コンプライアンス・スコアがロールアップされてコンプライアンス標準スコアが計算されることにより、このスコアをコンプライアンス・フレームワーク・スコアとともにロールアップおよびレポートできるようになります。
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つ以上のターゲットに関連付けられます。この結果、このルールをこれらのターゲットに対して効率的に評価できるようになります。
WebLogic Server署名ルール
WebLogic Serverの構成の問題を割込みで特定します。WebLogic Serverの署名ルールの目的は、ある構成データが条件(またはチェック)を満たす場合にWebLogic Serverで評価を行うことで、評価結果は、違反情報として管理サービスに送信されます。
問題の特定方法に関する詳細情報は、WebLogic Serverの署名ルール定義で指定されます。WebLogic Serverの署名ルール定義には、指定したターゲット・タイプとターゲット・プロパティに対する収集および評価で何が重要かを判別するのに使用する、DataspecおよびXQueryのロジックが含まれています。DataspecはWebLogic Serverから収集するのに使用されるMBeanをグループ化したものです。XQueryロジックには、MBeanごとに収集されたデータのチェックが含まれています。WebLogic Serverの署名ルールは、1つ以上の特定のWebLogicターゲット(WebLogicドメイン、WebLogic Java EEサーバーおよびWebLogicクラスタ)に関連付けることができます。
バージョン固有の詳細は、次のとおりです。
v10.3.3より前のWeblogic ServerターゲットでWeblogicサーバー署名ベースのルールのデータ・コレクションを有効にするには、bea-guardian-agent.warのコピーが必要です。このwarファイルのコピーは、OMSインストールの作業ディレクトリ($T_WORK/middleware/wlserver_10.3/server/lib/bea-guardian-agent.war)にあります
WebLogic Server v9およびv10.0の場合
ドメイン内のすべてのサーバーにbea-guardian-agent.warをインストールおよびデプロイします。コンテキスト・ルートは変更しないでください。Webアプリケーションのインストールの詳細は、http://<host>:<port>/console-help/doc/en-us/com/bea/wlserver/core/index.htmlを参照してください。
v10.3.2以下のWebLogic Server v10.3の場合
warファイルをOMSインストールから各ターゲットの$WL_HOME/server/libディレクトリにコピーします。ターゲット・ドメイン内のすべてのサーバーを再起動します。
WebLogic Server v.10.3.3以上の場合
必要なアクションはありません。
次の各項では、コンプライアンス標準ルールで実行できる操作について説明します。
注意: コンプライアンス標準ルールに対する操作を実行する前に、必要な権限があることを確認します。(コンプライアンス機能の使用に必要なロールおよび権限を参照してください。)
収集された構成データに基づいてターゲットが必要な構成状態にあることを確認するためのリポジトリのコンプライアンス標準ルールを作成するには、次の手順に従います。
リポジトリ・ルールに関する追加の注意事項
ルールはすべてグローバル・ルール・ライブラリに表示され、すべてのユーザーが参照できます。
コンプライアンス基準ルールの作成後、そのルールは自動的に評価されません。ルールは、使用する前にコンプライアンス標準に関連付ける必要があります。コンプライアンス標準が1つ以上のターゲットに関連付けられている場合のみ、ルールの評価が行われます。ルールを直接評価することはできません。
1つのルールを複数のコンプライアンス標準に関連付けることができます。
このルールが関連付けられているコンプライアンス標準を介してルールの様々な属性をカスタマイズできます。これらのカスタマイズは「コンプライアンス標準」画面で行います。コンプライアンス標準ごとにカスタマイズできるこれらの属性の1つに、この標準に関連するルールの重要度があります。
ユーザー定義コンプライアンス基準ルールは特権ユーザーによって定義されるため、コンプライアンス基準ルールを変更できるのは特権ユーザーのみです。違反結果は、すべてのユーザーが表示できます。
このユーザー定義のコンプライアンス標準ルールを他の特権ユーザーと共有するには、これらのユーザーが管理リポジトリにコンプライアンス標準ルールをインポートできるように、(エクスポート機能を使用して)XMLスキーマ定義を指定します。
「説明」、「影響」および「推奨」情報の参照中のスクロールを最小限に抑えるには、1行当たりのテキストを50文字に制限します。50を超える文字数が必要な場合は、改行してテキストを続けます。
コンプライアンス標準ルール・ウィザード内の各ページに関する具体的な手順の詳細は、コンテキスト依存ヘルプを参照してください。
コンプライアンス標準ルールのXML定義でWHERE句を手動で入力する場合、有効なXMLドキュメントを作成するには、<(より小さい)記号を<と表現する必要があります。次に例を示します。
<WhereClause>:status < 100</WhereClause>
一般に知れわたった思いがけない危険やベスト・プラクティスに関する詳細な知識に主に基づいて、WebLogicのインストールにおいて発生すると確認されているコンプライアンス違反を発見するために、数百の即時利用可能なWebLogic Serverの署名ルールが設計されています。また、実行するチェックを拡張するために独自のルールを作成することもできます。
署名は、WebLogicのインストールにおける潜在的な問題を説明しています。カテゴリ化のメタデータ、ユーザー読取り可能な問題の記述、および問題がターゲットに存在するがとうかを評価するXQuery式で構成されます。
WLS署名ルールは管理エージェント側ルールの1つであり、関連付けられたターゲットに対して署名定義をチェックし、その署名で定義される問題が存在することを検証します。WebLogicサーバーのターゲットには、WLSドメイン、WLSクラスタ、WebLogic管理対象サーバーがあります。最初の2つはコンポジット・ターゲット・タイプであり、単純なWebLogicサーバー・ターゲットのインスタンスの論理グループです。有意な違反結果を得るには、ドメインまたはクラスタの全体に対してルールを評価する必要があります。
WLS署名ルールは、他のコンプライアンス・ルールと同様、コンプライアンス標準にグループ化されます。コンプライアンス標準は、重大度や処置など署名のメタデータに基づく論理グループです。
特定の構成設定が既知の良質な構成要件を満たしているかどうかを評価するためにWebLogic Serverの署名のコンプライアンス標準ルールを作成するには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
「コンプライアンス標準ルール」タブをクリックします。
「作成」ボタンをクリックします。
「ルールの作成」ポップアップで、「WebLogic Serverの署名」ルール・タイプを選択します。
「続行」をクリックします。
次の画面で、ルールの複数の主要属性を入力するよう求められます。
ルール名
一意のルール名を入力します。
コンプライアンス・ルールの状態
このルールの状態が開発と本番のどちらであるかを設定します。開発とは、ルールがまだ定義またはチューニング中であり、ターゲットで使用する準備がまだ整っていないことを意味します。ルールを本番に昇格した後、ルールを開発に戻すことはできません。
重大度
ルールには、重大度レベルがあり、クリティカル(ルールが違反している場合の深刻な問題)、警告(違反している場合の深刻ではない問題)、またはマイナー警告(違反している場合のマイナーな問題)のいずれかです。重大度は、このルールがコンプライアンス標準に追加されるときにこのルールに設定される可能性がある重要度とともにコンプライアンス・スコアに影響します。
適用可能対象
このルールが適用されるターゲット・タイプ。
ターゲット・プロパティ・フィルタ
このルールがコンプライアンス標準に関連付けられているときにこのルールを適用可能なターゲットを決定する特定のターゲット・プロパティを指定できます。このようなプロパティには、オペレーティング・システム、ターゲット・ライフサイクルの状態、バージョンおよびプラットフォームがあります。たとえば、Linux OSなど、このルールにターゲット・プロパティ・フィルタを指定すると、このルールはLinuxオペレーティング・システムに対してのみ適用可能になります。
説明
ルールの説明
論理
このルールの確認対象、およびこのルールの違反による影響を表すテキスト。
推奨
違反が発生した際の問題の修正方法を表す推奨テキスト。
参照URL
コンプライアンス制御を詳細に説明するドキュメントへのURL。多くの場合、これらのドキュメントはコンテンツ管理システムに格納できます。
キーワード
キーワードは、データを様々なレポートに編成する方法を制御できるようルールに割り当てることができます。
「次」をクリックします。
次の画面で、署名の定義ファイルを指定する方法を選択します。ファイルのアップロードによってロードすることも、UIにテキストを直接入力することもできます。
コンプライアンス・メッセージおよび非コンプライアンス・メッセージを入力します。これらは、評価に関して表示されるメッセージです。違反が発生すると、非コンプライアンス・メッセージが、インシデント管理機能下におけるイベントを説明する文字列になります。
違反とともに表示する列を選択します。これらの列は、署名定義で戻り列として定義する必要があります。
「次」をクリックします。
次の画面では、ルールをテストできます。使用環境内のターゲットを選択し、「テストの実行」ボタンをクリックできます。ルールに関する問題が表示され、ルールを保存する前にこれらを解決できます。
「次」をクリックします。
最終ページでは、このルールに対して構成したすべての内容を確認できます。内容がすべて正しいことを確認し、「終了」ボタンをクリックしてルールを保存します。
1つ以上のコンプライアンス標準に関連付けられ、これらのコンプライアンス標準がターゲットに関連付けられるまでは、新しく作成したこのルールは機能しません。この関連付けが行われると、このルールのワークフローは次のようになります。
標準とルールの組合せは転送され、コンプライアンスを判定するためにコンプライアンス標準およびターゲット・タイプごとに管理エージェント側で収集されたメトリックに対して評価されます。
評価から違反が生成されます(違反がある場合)。
違反はCloud Controlサーバーにアップロードされ、そこから管理リポジトリ表の違反に処理されます。
これで、違反がコンプライアンス結果のページとコンプライアンス・ダッシュボードで表示できるようになります。
WebLogic Serverの署名の例
ルール作成ウィザードを使用すると、新規ルールを追加しやすくなりますが、WebLogic Serverの署名ルールの重要な部分は署名定義です。署名定義は、Managed Bean(MBean)のリストおよびXQuery式で構成されます。Managed Beanは、収集する構成データを表します。これは、収集するタイプおよびタイプ内での属性を定義します。また、違反があるかどうかを判断する際に考慮する属性の宣言も行います。XQuery式は、コンプライアンスに対して収集されたデータを評価する際に使用するロジックを定義します。署名定義のXMLの例は次のとおりです。
<SignatureDefinition>
<MBeanList>
<MBean scoreBase="true" mBeanType="ServerRuntime">
<AttributeName>Name</AttributeName>
<AttributeName>WeblogicVersion</AttributeName>
</MBean>
</MBeanList>
<XQueryLogic>declare function local:getServerRuntimesEqualToVersionWithPatch($targetData, $major as xs:integer,
$minor as xs:integer, $servicePack as xs:integer, $crNumber as xs:string) {
for $ServerRuntime in $targetData/DataCollection/ServerRuntime
let $weblogicVersion := fn:replace($ServerRuntime/@WeblogicVersion, "WebLogic Server Temporary Patch", "")
let $majorVersion :=
let $spaceParts := fn:tokenize(fn:substring-after($weblogicVersion, "WebLogic Server "), " ")
let $majorVersionParts := fn:tokenize($spaceParts[1], "\.")
return
$majorVersionParts[1] cast as xs:integer
let $SP_MP :=
if ($majorVersion = 8) then
"SP"
else
if ($majorVersion >= 9) then
"MP"
else " "
let $minorVersion :=
let $spaceParts := fn:tokenize(fn:substring-after($weblogicVersion, "WebLogic Server "), " ")
let $minorVersionParts := fn:tokenize($spaceParts[1], "\.")
return
$minorVersionParts[2] cast as xs:integer
let $servicePackVersion :=
let $spaceParts := fn:tokenize(fn:substring-after($weblogicVersion, "WebLogic Server "), " ")
let $servicePackParts := fn:substring-after($spaceParts[2], $SP_MP)
return
if ($servicePackParts = "") then
0
else
$servicePackParts cast as xs:integer
where $majorVersion = $major and $minorVersion = $minor and $servicePackVersion = $servicePack and
fn:contains(fn:upper-case($ServerRuntime/@WeblogicVersion),fn:upper-case($crNumber))
return
$ServerRuntime
};
for $server in local:getServerRuntimesEqualToVersionWithPatch(/,10,0,1,"CR366527")
|
local:getServerRuntimesEqualToVersionWithPatch(/,10,0,0,"CR366527")
return <Server
Name="{fn:data($server/@Name)}"/></XQueryLogic>
</SignatureDefinition>
実質的に、この定義では、すべてのランタイム・サーバーのサーバー名およびWebLogicバージョンを収集します。定義の大部分では、バージョン(メジャー・パッチとマイナー・パッチ)、サービス・パック、CR番号などの詳細が繰り返されます。サーバーに指定されたパッチ(10.0.1 CR366527または10.0.0 CR 366527)のいずれかがある場合、違反が発生し、この場合、違反で報告するサーバーの名前が返されます。そのため、ルール定義には、サーバー名の表示を説明するための列が含まれる必要があります。バージョンは、表示のコンテキストでは無関係です。アラートの表示は、どのサーバーが違反しているかについてのみ関与しています。
WebLogic Server署名ルールを使用するための重要な前提条件ステップ
モニターしようとするWebLogicのバージョンに固有の必須ステップは、次のとおりです。
WebLogic Server署名ルールに関する追加の注意事項
ルールはすべてグローバル・ルール・ライブラリに表示され、すべてのユーザーが参照できます。
コンプライアンス標準ルールは、作成された後、自動的には評価されません。ルールは、使用する前にコンプライアンス標準に関連付ける必要があります。コンプライアンス標準が1つ以上のターゲットに関連付けられている場合のみ、ルールの評価が行われます。ルールを直接評価することはできません。
1つのルールを複数のコンプライアンス標準に関連付けることができます。
このルールが関連付けられているコンプライアンス標準を介してルールの様々な属性をカスタマイズできます。これらのカスタマイズは「コンプライアンス標準」画面で行います。コンプライアンス標準ごとにカスタマイズできるこれらの属性の1つに、この標準に関連するルールの重要度があります。
ユーザー定義コンプライアンス基準ルールは特権ユーザーによって定義されるため、コンプライアンス基準ルールを変更できるのは特権ユーザーのみです。違反結果は、すべてのユーザーが表示できます。
このユーザー定義のコンプライアンス標準ルールを他の特権ユーザーと共有するには、これらのユーザーが管理リポジトリにコンプライアンス標準ルールをインポートできるように、(エクスポート機能を使用して)XMLスキーマ定義を指定します。
「説明」、「影響」および「推奨」情報の参照中のスクロールを最小限に抑えるには、1行当たりのテキストを50文字に制限します。50を超える文字数が必要な場合は、改行してテキストを続けます。
コンプライアンス標準ルール・ウィザード内の各ページに関する具体的な手順の詳細は、コンテキスト依存ヘルプを参照してください。
コンプライアンス標準ルール・ウィザード内の各ページに関する具体的な手順の詳細は、コンテキスト依存ヘルプを参照してください。
ファイル変更、ユーザー・アクセスおよびプロセス・アクティビティなど、ターゲットで発生したユーザー・アクションをモニタリングするためのリアルタイム・モニタリングのコンプライアンス標準ルールを作成するには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
「コンプライアンス標準ルール」タブをクリックします。
「作成」ボタンをクリックします。
「ルールの作成」ポップアップで、「リアルタイム・モニタリング」タイプを選択します。
「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」をクリックします。
別のコンプライアンス標準ルールに類似したコンプライアンス標準ルールを作成するには、次の手順に従います。
コンプライアンス標準ルールを編集するには、次の手順に従います。
使用上の注意
リポジトリ・ルールの場合、ルール名、状態(すでに本番である場合)、および適用可能対象以外のすべてのルール・プロパティを変更できます。
リアルタイム・モニタリング・ルールの場合、ルール名、状態(すでに本番である場合)、適用可能対象、ターゲット・プロパティ・フィルタおよびエンティティ・タイプは変更できません。
ルール問合せ、違反条件、パラメータまたは重大度など、リポジトリ・ルールの重要なルール・プロパティを変更する場合、ルールの編集によって、ルールを参照するコンプライアンス標準の結果は無効になります。コンプライアンス標準のコンプライアンス・スコアは、次のルール評価で再評価されます。
本番モードのルールでは、ルールのドラフトを作成および保存するか、既存の本番ルールを上書きするかを選択できます。ドラフトを作成する場合、ドラフト・ルールを編集し、後でそれをテストし、ドラフトが作成された元の本番ルールに上書きおよびマージできます。注意: コンプライアンス標準にドラフト・ルールを含めることはできません。
WebLogic Server署名ルールまたはリアルタイム・モニタリング・ルールについては、編集中のルールが、ターゲットに関連付けられているコンプライアンス標準によって参照されている場合、ルール定義はターゲットをモニタリングする管理エージェントにデプロイされ、これによって管理エージェントは最新のルール定義を評価できるようになります。管理エージェントが停止しているか、アクセス不可能な場合は、管理エージェントが使用可能になった直後にルール定義の変更が管理エージェントに伝播されます。
ルールを削除する前に、コンプライアンス標準ルールを削除する前にコンプライアンス標準ルールの参照がコンプライアンス標準から削除されていることを確認する必要があります。コンプライアンス標準によって使用されているルールを削除することはできません。
コンプライアンス標準ルールを削除するには、次の手順に従います。
エクスポート機能は、管理リポジトリおよびCloud Controlインスタンス間でユーザー定義のコンプライアンス標準ルール定義をトランスポートするためのメカニズムです。エクスポートによって、オペレーティング・システム・ファイルに定義を格納します。エクスポートしたコンプライアンス標準ルール定義は、XMLフォーマットであるため、Oracleコンプライアンス標準定義(XSD)フォーマットに準拠しています。コンプライアンス標準ルールの定義を変更でき、生成されたコンプライアンス標準ルール定義を別の管理リポジトリに再インポートできます。
コンプライアンス標準ルールをエクスポートするには、次の手順に従います。
インポートにより、すでに所有しているコンプライアンス標準ルールの再使用、Cloud Controlの複数のインスタンス間でのルール定義の共有、ルールのオフライン編集の有効化が可能になります。
コンプライアンス標準ルールをインポートする前に、インポートするコンプライアンス標準ルールがファイルに定義されていることを確認します。このファイルには、Cloud Controlにアクセスするために使用しているブラウザからローカルにアクセスできる必要があります。また、インポートするコンプライアンス標準ルール定義XMLファイルへのアクセス権限を持っていることも確認します。
コンプライアンス標準ルールをインポートするには、次の手順に従います。
コンプライアンス標準ルールを参照するには、次の手順に従います。
修正処理は、コンプライアンス標準ルールに対する違反を引き起こす問題を修正するスクリプトです。
修正処理には2種類あります。
手動 - コンプライアンス標準ルールのコンテキストに作成されます。
自動 - インシデント・ルールのコンテキストに作成されます。
手動修正処理
手動で修正処理を作成するには、次の手順を実行します。
「エンタープライズ」メニューで「モニタリング」、「修正処理」の順に選択します。
ジョブ・ページで、次を実行します。
「ライブラリ修正処理の作成」フィールドで、「SQLスクリプト」を選択し、「実行」をクリックします。
「一般」タブで、修正処理の名前を入力し(例: CA1)、説明を入力して、「イベント・タイプ」に「コンプライアンス標準ルール違反」を選択します。「ターゲット・タイプ」に「データベース・インスタンス」を選択します。
「パラメータ」タブでデフォルトのWHENEVER SQLERROR EXIT FAILURE;を選択します。「ライブラリに保存」をクリックします。
注意: インテリジェントな修復を有効にするには、コンプライアンス違反から修正処理にパラメータを渡します。たとえば、よく知られているアカウントへの変更をロックするには、次のSQL文を追加します。
alter user %EVTCTX.dbuser% account lock; where dbuser is the event context parameter
任意のパラメータに同様の変更を行うことができます。SQL問合せの列名とパラメータ名が一致していることを確認してください。
作成した修正処理を選択し、「公開」をクリックします。
確認のページで、「はい」をクリックします。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。ルール・タイプがエージェント側またはリポジトリのデータベース・コンプライアンス標準ルールを選択します。「アクション」メニューから「修正処理の割当て」を選択します。修正処理を選択し、「OK」をクリックします。
コンプライアンス標準ルールの詳細の表示ページに修正処理が表示されます。
自動修正処理
違反が起きたときに自動的にトリガーされる修正処理を作成するには、次の手順を実行します。
「設定」メニューで「インシデント」、「インシデント・ルール」の順に選択します。
インシデント・ルール: すべてのエンタープライズ・ルール・ページで「ルール・セットの作成」をクリックします。ルールの名前を指定し、「ターゲット」リージョンの「すべてのターゲット」を選択し、「ルール」リージョンの「作成」をクリックします。
「作成するルールのタイプを選択」ダイアログ・ボックスで、受信イベントおよびイベントの更新を選択します。「続行」をクリックします。
タイプに「コンプライアンス標準ルール違反」を選択します。
コンプライアンス標準ルール違反タイプのすべてのイベントまたはコンプライアンス標準ルール違反タイプの特定のイベントのいずれかを選択します。
詳細な選択オプションで、「修正処理が完了しました」を選択します。「次へ」をクリックします。
新規ルールの作成: アクションの追加ページで、「追加」をクリックします。条件付きアクションの追加ページで、訂正処理の選択をクリックします。訂正処理を選択します。「続行」をクリックします。
新規ルールの作成: アクションの追加ページで、「次へ」をクリックします。新規ルールの作成: 指定および説明ページで「次へ」をクリックします。
情報を確認して、「続行」をクリックします。
「保存」をクリックします。新しく追加されたルールは「保存」ボタンがクリックされるまで保存されないことに注意してください。「保存」をクリックした後、詳細を確認することでルール・セット・エンティティが新しいインシデント・ルールに新しいインシデント・ルールを追加したことを確認します。
リアルタイム・モニタリング・ルール定義には、指定したターゲット・タイプ、ターゲット・プロパティおよびエンティティ・タイプに対するモニタリングで何が重要かを判別するのに使用するファセットが含まれています。ファセットは、ターゲット・タイプの属性を構成するパターンの集合です。
次の各項では、リアルタイム・モニタリング・ファセットについて詳しく説明します。
ターゲット・タイプには複数のファセットがあります。ターゲット・タイプには、重要な構成ファイルはどれか、ログ・ファイルはどれか、実行可能ファイルはどれか、機密構成データが保存されているデータベース表はどれかなどのファセットがあります。指定されたターゲット・タイプのこれらすべてのファセットの総合で、コンプライアンスという観点から、指定されたターゲット・タイプでモニターすることが重要なすべてのことが決定されます。
特定のターゲット・タイプに対して、任意の数のファセットを作成できます。ファセットは、特定のターゲット・タイプに対してのみでなく、特定のターゲット・タイプといくつかのターゲット・タイプ・プロパティの組合せに対しても作成できます。たとえば、Windows上のホスト・ターゲット・タイプに対するファセットの作成は、Linux上のホスト・ターゲット・タイプに対するファセットの作成とは異なります。1つのファセットに複数のターゲット・タイプ・プロパティを設定したり、プロパティを指定せずに任意のターゲットがファセットを使用できるようにすることができます。
ファセットは多くのルールで再使用できます。この利点は、すべてのルールを変更しなくてもファセットのエントリを追加または削除できる点です。たとえば、今日モニターしたいログ・ファイルが5つある場合、これら5つのファイルをリストするファセットをモニターするルールを設定できます。明日新規ログ・ファイルを追加する必要がある場合、各ルールではなく、ファセットを変更するのみですみます。
ファセットは独自に作成するか、リアルタイム・モニタリング・ルールの作成に従ってインラインで作成できます。作成方法に関係なく、後から任意の数のルールで再利用できます。
ターゲット・タイプに基づくリアルタイム・モニタリング・ファセットを使用して、リアルタイム・モニタリング・ルールでモニタリングするエンティティを指定します。たとえば、ファイルの変更のためにホストをモニタリングする場合、ファセットに個別の単一ファイルのリスト、多くのファイルを含むワイルドカードを使用したパターンまたは全体のディレクトリを指定できます。これらのパターンにデフォルトを使用するパラメータも含めることができますが、各ターゲットの必要に応じて上書きできます。ORACLE_HOMEなどの組込みパラメータは各ターゲットに動的に入力されます。データベース構成ファイルtnsnames.oraのモニタリングを指定した場合、パターンが{ORACLE_HOME}/network/admin/tnsnames.oraになります。
ファセットは、完全に異なる2つの方法で使用できます。第一に、ファセットはモニターの内容を表します。ルール作成ウィザードでは、これらのファセットはウィザードのステップ「モニターするエンティティ」で選択します。また、ファセットは、モニタリング結果をフィルタするために使用することもできます。これらのフィルタ・ファセットは、ルール作成ウィザードの「フィルタ」ステップで指定します。たとえば、OSファイル・エンティティ・タイプをモニタリングする場合、ファイルの変更を行ったユーザー、ファイルの変更が行われた時刻、またはファイルの変更を行うために使用されたプロセスに基づいて結果をフィルタできます。
継続的なリアルタイム・モニタリングを実行する場合、モニタリングの範囲を重要なエンティティのみに制限することが重要です。組織によって重要でない多数のアクティビティをモニタリングすると、管理エージェントのCPU負荷が高くなり、Oracle Enterprise Managerサーバーによって処理および格納されるデータの量が非常に多くなります。
各ファセットには、ファセットが示すエンティティの種類を定義するエンティティ・タイプがあります。たとえば、OSレベルのモニタリングでは、OSファイル、OSプロセス、OSユーザー、Windowsレジストリおよび複数のActive Directoryエンティティ・タイプがあります。データベースのモニタリングでは、エンティティ・タイプに表、ビュー、索引、プロシージャが特に含まれます。使用可能なエンティティ・タイプは、管理エージェントから使用可能な継続的なリアルタイム構成変更モニタリング機能によって固定されています。
ファセットは、「ファセット・ライブラリ」画面を使用して作成できます。この画面で、ファセットのパターンの追加および編集、およびルールによって消費されているファセットの確認を実行できます。
次に示すのは、Cloud Controlでリアルタイム・モニタリング用としてサポートされるエンティティ・タイプです。
OSファイル
OSプロセス
OSユーザー
Microsoft Windowsレジストリ
Microsoft Active Directoryユーザー
Microsoft Active Directoryコンピュータ
Microsoft Active Directoryグループ
Oracleデータベースのディメンション
Oracleデータベースのシノニム
Oracleデータベース・タイプ
Oracleデータベース表
Oracleデータベース・ビュー
Oracleデータベース・プロシージャ
Oracleデータベース・ユーザー
Oracleデータベース索引
Oracleデータベース順序
Oracleデータベース関数
Oracleデータベース・プロファイル
Oracleデータベースのパブリック・シノニム
Oracleデータベース・ロール
Oracleデータベース・パッケージ
Oracleデータベース・ライブラリ
Oracleデータベース・トリガー
Oracleデータベース表領域
Oracleデータベースのマテリアライズド・ビュー
Oracleデータベース・クラスタ
Oracleデータベース・リンク
Oracleデータベース・パブリックDBリンク
Oracleデータベース・セグメント
OracleデータベースのSQL問合せ文
ファセットには、1つ以上のパターンが含まれています。これらのパターンは、包含および除外フィルタを表すことができます。たとえば、次のような重要な構成ファイルのファセットを定義できます。
include c:\myapp1\config
exclude c:\myapp1\config\dummy.cfg
この場合、個別のファイルc:\myapp1\config\dummy.cfgを除き、c:\myapp1\configの下にあるすべてのものがこのファセットのメンバーであるとみなされます。通常、パターンがどのように機能するかを指定するいくつかのルールがあり、最も一般的なユースケースを次に示します。各エンティティ・タイプには、特別なケースまたは特別なパターンの形式がある場合があります。
包含と除外のパターンが同じ詳細レベルで指定された場合、包含が優先されます。
より具体的なパターンが優先されます(前述の例では、exclude dummy.cfgによって、最初のパターンから継承されたinclude c:\dummy.cfgが上書きされます)。
パターンが存在しない場合、exclude *が想定されます(たとえば、ファセットにエンティティがない場合など)。
ファセットに追加する各パターンには、そのパターンについて記述できるオプションの説明フィールドがあります。
次の各項では、ファセットで実行できる操作について説明します。
これらの構成がコンプライアンス・モニタリングに関連しているため、ファセットを作成、削除および変更する権限を持っていることを確認します。詳細は、コンプライアンス機能の使用に必要なロールおよび権限を参照してください。
監視データを表示できるユーザーは、ファセット・ライブラリを表示し、ファセットのファセット履歴を参照することもできます。
ファセット・ライブラリを表示する方法には、検索モードと参照モードの2つがあります。検索モードの場合、検索基準を満たすすべてのファセットがフラット・リストに表示されます。参照モードの場合、ファセットが属するフォルダ階層とともにファセットが表示されます。このフォルダ構造は、Cloud Control内で非常に多数のファセットを管理する上で役立ちます。
検索モードでファセット・ライブラリを表示するには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
リアルタイム・モニタリング・ファセット・ライブラリ・タブを選択します。
Cloud Controlで「ファセット・ライブラリ」ページが表示され、既存のすべてのファセットが、ターゲット・タイプ、エンティティ・タイプなど、ファセットに関する詳細とともにリストされます。監査作成者ロールを持っている場合、このページから、作成、類似作成、表示、削除、インポートおよびエクスポートなどの管理タスクを実行できます。
「ファセットの検索」タブをクリックします。
ファセット・ライブラリ・ページには、ファセット名、作成者、ターゲット・タイプ、エンティティ・タイプ、ファセットを使用するルール、説明、およびファセットの最終更新時間が表示されます。ファセットの詳細を参照するには、そのファセットを表から選択して「詳細を表示」をクリックします。
表に表示する列を選択するには、「表示」をクリックしてから「列」を選択します。「すべて表示」列を選択するか、表に表示する列を個別に選択できます。列を並べ替えるには、「表示」をクリックしてから「並替え」をクリックし、矢印キーを使用して列を上下に移動して列の表示順序を変更します。
「検索」というタイトルのページの領域を拡張すると、ファセットの表示に適用する検索基準を選択できます。
選択したファセットの履歴を参照するには、そのファセットを表から選択して「履歴」をクリックします。「履歴の表示」ページが表示されます。
参照モードでファセット・ライブラリを表示するには、次の手順に従います。
ファセットを作成し、リアルタイム・モニタリング・コンプライアンス基準ルールでファセットを使用する場合、コンプライアンス・ルールはファセットの参照のみを行います。コンテンツが変更されると、ルールでは自動的に新しいコンテンツが使用されます。
ファセットのコンテンツの使用が開始されるのは、1つ以上のターゲットに関連付けられたコンプライアンス標準の一部であるルールにファセットが追加された場合のみです。
各ファセットには、ユーザーがそのファセットを記述できる説明が割り当てられます。各パターンにもオプションの説明フィールドがあります。使用が開始されるのは、1つ以上のターゲットに関連付けられたコンプライアンス標準の一部であるルールにファセットが追加された場合のみです。
ファセットを作成または編集するには、次の手順に従います。
ファセットの参照モードでファセットを表示する場合、ページ上に2つのリージョンが表示されます。左側には、存在するファセット・フォルダが表示されます。右側には、現在選択されているフォルダ内に存在するファセットが表示されます。フォルダが表示されている左側には、フォルダに対して使用可能なアクションが3つあります。
作成: 新規フォルダを作成できます。作成するフォルダ名を尋ねるポップアップが表示されます。また、この新規フォルダを最上位フォルダにするか、現在選択されているフォルダの子として追加するかを選択することもできます。
名前の変更: 既存のユーザー定義フォルダの名前の変更できます。
削除: ユーザー定義フォルダを削除できます。ファセットまたは他のフォルダが含まれるフォルダを削除することはできません。
Oracleによって移入された即時利用可能なフォルダの削除、名前変更または移動を行うことはできません。
未整理と呼ばれるデフォルトのフォルダが存在します。フォルダを指定せずに作成またはインポートされたファセットは常にこの未整理フォルダに移動されます。
移動するファセットを右側で特定し、これを選択し、これを配置する左側のフォルダまでドラッグするのみで、ファセットをフォルダに移動できます。ファイルはそのフォルダに移動します。1つのファセットが一度に属することができるのは1つのフォルダのみであり、ファセットは常に(未整理フォルダであっても)フォルダに属する必要があります。また、ファセットをクリックし、「移動」ボタンをクリックすることもできます。ポップアップ・ウィンドウが表示され、ファセットの移動先のフォルダを選択できます。
フォルダは監視分析やコンプライアンス・スコアには影響しません。これらは、「リアルタイム・モニタリング・ファセット」ライブラリ画面で、存在する非常に多数のファセットを管理しやすくするためにのみ使用されます。
ファセットは、ルールのモニタリング・ファセットまたはルールのフィルタ・ファセットとして使用されている間は削除できません。ファセットがどのルールでも使用されていない場合、ファセットを削除できます。ファセットが使用されている場合、現在使用されていることを示すアラートがユーザーに表示され、そのファセットを使用しているルールが変更されてそのファセットが含まれなくなるまで、そのファセットの削除は許可されません。
ファセットを削除すると、ファセットで履歴監視データが参照されず、かわりに関連するファセットの名前として「(削除されたファセット)」が表示されます。「参照」ページではなく「監視の検索」ページでのみこの監視データを使用できます。
コンプライアンスに焦点を当てたユーザーの場合、顧客は通常、コンプライアンス・データが失われないように未使用のファセットを使用可能なまま保持することを求めます。また、収集された監視を保持するために実際のファセットを保持しているかぎり、パターンを削除することもできます。この場合、この古いファセットに関連するコンプライアンス・データが使用可能でなくなった後にのみ、データを損失せずにファセットを削除できます。
ファセットを削除するには、次の手順に従います。
製品またはプラグインとともに出荷されるファセットは、変更できません。Oracle提供のコンテンツを強化または変更する場合、類似作成機能を使用して、ファセットのコピーを作成し、それを後で編集する必要があります。
類似作成機能の重要な制限は、ターゲット・タイプまたはエンティティ・タイプを変更できないことです。ファセットに含まれるパターンは、ターゲット・タイプまたはエンティティ・タイプによって異なる場合があります。類似作成を使用してこれらの属性を変更する場合、「エクスポート」を使用して元のファセットをエクスポートし、XMLの名前、ターゲット・タイプおよびエンティティ・タイプを編集して、新しいファセットとしてインポートする必要があります。
類似作成機能を使用して新しいファセットを作成するには、次の手順を実行します。
ファセットを選択して、エクスポートまたはインポートできます。選択したすべてのファセットは、1つの出力ファイルにエクスポートされます。
インポートする際、同じ名前、ターゲット・タイプおよびエンティティ・タイプの組合せのファセットがすでに存在する場合は、インポートが失敗し、そのファセットがすでに存在することを示すエラーが表示されます。ユーザーはインポート・ファイルを変更して重複する名前を削除し、インポートを再試行する必要があります。
名前、ターゲット・タイプおよびエンティティ・タイプの組合せにより、一意のファセットが定義されます。異なるターゲット・タイプおよびエンティティ・タイプには、同じ名前のファセットを定義できます。
ファセットをエクスポートするには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
リアルタイム・モニタリング・ファセット・ライブラリ・タブを選択します。
Cloud Controlで「ファセット・ライブラリ」ページが表示され、既存のすべてのファセットが、ターゲット・タイプ、エンティティ・タイプなど、ファセットに関する詳細とともにリストされます。このページから、作成、類似作成、表示、削除、インポートおよびエクスポートなどの管理タスクを実行できます。
ファセット・ライブラリ・ページにあるファセットのリストから、エクスポートするファセットを1つ以上選択し、「エクスポート」をクリックします。
「オープン」ダイアログ・ボックスで、任意のXMLエディタを使用してファセットxmlファイルをオープンまたは保存することを選択し、ファイルを編集するか、別の場所に保存します。
ファセットをインポートするには、次の手順に従います。
ファセットが少なくとも1つのルールで(モニタリング・ファセットまたはフィルタ・ファセットとして)使用された後、作成されたルールはすでにファセットの属性にバインドされているため、ファセットのファセット名、ターゲット・タイプ、エンティティ・タイプまたはターゲット基準は変更できません。変更可能な属性は、ファセット・パターン、「パラメータ」および「説明」フィールドのみです。ルールはファセット名に依存しませんが、ユーザーはファセット名に基づいてファセットをルールで使用してきました。消費後のファセット名の変更を許可することは、ルールの作成者のコンプライアンス結果および監視の分析時にルール作成者に混乱をもたらすだけです。
現在使用していないファセットを過去に使用したことがある場合、履歴監視データがまだ過去のファセットに関連付けられるため、使用中のファセットと同一に扱われます。
Cloud Control製品に含まれているOracle提供のファセットを変更することはできません。Oracle提供のファセットを変更して使用するには、「類似作成」操作を実行し、新しく作成したファセットを必要に応じて変更します。
ベース・ファセット属性を変更するには、次の手順に従います。
この項では、コンプライアンスの使用例を示します。次の例があります。
この例では、ホスト・タイプのターゲットのサンプルの構成ファイル(この例では、/tmp/foo.xml)を収集するカスタム構成でコンプライアンス・ルールを作成および実行する方法について説明します。
この例では、次のコンテンツでサンプルの/tmp/foo.xmlファイルを作成します。
<some_config> <prop foo="1"/> <prop bar="2"/> </some_config>
この手順には、次の方法が含まれます。
カスタム構成の作成
カスタムベースのリポジトリ・ルールの作成
コンプライアンス標準の作成
ターゲットの関連付け
結果の表示
カスタム構成の作成の手順:
「エンタープライズ」メニューから、「構成」、「構成拡張」の順に選択します。
「構成拡張」ページから、「作成」をクリックします。「構成拡張の作成」ページが表示されます。
「名前」(compliance_ccsなど)、説明(オプション)を入力し、「ターゲット・タイプ」(この例の場合は「ホスト」)を選択します。
「ファイルとコマンド」セクションで、「デフォルト・ベース・ディレクトリ」を入力します(ディレクトリとして/tmpを使用します)。
これは例です。実際のターゲットの場合、ターゲットの構成ファイルが含まれるディレクトリにする必要があります。
注意: カスタム構成によって収集されるすべてのファイルは日次ベースで変更しないようにし、管理者の明示的なアクションによる非常にまれな変更のみにしてください。
「追加」をクリックします。
- 「タイプ」列で、「ファイル」を選択します。
- 「ファイル/コマンド」列で、foo.xmlを入力します。「別名」列にfoo.xmlが自動的に入力されます。
注意: xmlのみ、またはfoo.xml表現のみでなく、任意のファイルを使用できます。カスタム構成は、多くのファイルおよび対応するパーサーをサポートしています。
- 「パーサー」列で、「XMLパーサー(デフォルト)」を選択します。
ページの下部にある「保存」をクリックします。
「カスタム構成」ページで、compliance_cssを強調表示し、「デプロイ」をクリックします。デプロイページが表示されます。
「追加」をクリックし、CSSをデプロイする必要があるターゲットを選択します。
「検索と選択: ターゲット」ページで、ファイル/tmp/foo.xmlが作成されたホスト・ターゲットを強調表示し、「選択」をクリックします。
「デプロイ」ページで「適用」をクリックします。
「保留中のデプロイメント・アクションの発行」ポップアップで、「はい」を選択します。このアクションにより、デプロイメント・アクションが発行されます。
「デプロイ」ページで、「ステータス」列に「デプロイは成功しました」と表示されるまで「ステータスのリフレッシュ」をクリックしてデプロイのステータスをリフレッシュします。
これでデプロイが発行されたので、「取消」をクリックしてページを終了します。(注意: 前述の「適用」のかわりに「保存」をクリックしていたら、デプロイ・アクションの発行の直後にページが終了していました。)
カスタム構成収集に基づくカスタムベースのリポジトリ・ルールの作成の手順:
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
「コンプライアンス・ライブラリ」ページで、「コンプライアンス標準ルール」タブをクリックします。
「作成」をクリックします。
「ルールの作成」ポップアップで、「リポジトリ・ルール」を選択し、「続行」をクリックします。
「ルールの作成: リポジトリ・ルール: 詳細」ページで、「ルール名」に入力します(compliance_css_ruleなど)。
「コンプライアンス・ルールの状態」では「開発」を選択し、「重大度」では「マイナー警告」を選択します。「適用可能対象」では「ホスト」を選択します。ページの右上にある「次」をクリックします。
「ルールの作成: リポジトリ・ルール: チェック定義(問合せ)」ページで、「モデル問合せ」をクリックします。「新しい検索基準」ページが表示されます。
「よく使用される検索基準」の下の「構成アイテム」メニューから「compliance_css (解析済データ)」を選択します。
「ホスト」セクションおよび「解析済データ」サブセクションで、「データソース」の「次を含む」にfoo.xmlを入力します。「属性」では、「完全一致」比較演算子を選択し、fooを入力し、サンプル・ファイル内でfooを参照します。(注意: 「データソース」および「属性」のこれらの式にはワイルドカード文字として%を使用することもできます。)
「検索」をクリックし、このフィルタで返された行を表示します。このファイル内の属性fooに対して値1を持つデータが表に表示されます。
「OK」をクリックします。
「ルールの作成: リポジトリ・ルール: チェック定義(問合せ)」が再表示されますが、今回は「SQLソース」が表示されます。
「次」をクリックします。注意: 通常、必要に応じて、処理を続行する前に問合せを更新することもできます。
「ルールの作成: リポジトリ・ルール: チェック定義(違反条件)」ページが表示されます。
「情報」列を除くすべての列を「キー」列(「値」、「属性」、「コンテナ」および「データソース名」)として選択します。
ページの「条件タイプ」セクションで「単純条件」を選択し、「列名」で「値」を選択し、「比較演算子」を等号(=)に変更します。「デフォルト値」列に1を入力します。「次」をクリックします。
「ルールの作成: リポジトリ・ルール: テスト」ページで、「ターゲット名」フィールドの横にあるアイコンをクリックします。「検索と選択: ターゲット」ポップアップが表示されます。カスタム構成がデプロイされたホストを特定します。属性を選択して、「選択」をクリックします。
「ルールの作成: リポジトリ・ルール: テスト」ページで、「テストの実行」をクリックします。テストが正常に実行されたら、「テストの実行 - 正常に完了しました」という内容の確認が表示されます。
前述の手順5で違反条件として値1を指定したこと、およびサンプル・ファイルの属性fooの値が1であったことから、テストの実行後に1つの違反が表示されます。「閉じる」をクリックします。
「ルールの作成: リポジトリ・ルール: テスト」ページで、「次」をクリックします。
「ルールの作成: リポジトリ・ルール: 確認」ページで、追加した情報がすべて正しいことを確認します。「終了」をクリックします。
コンプライアンス標準の作成の手順:
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
「コンプライアンス標準」タブをクリックし、「作成」をクリックします。
「コンプライアンス標準の作成」ポップアップで、「名前」フィールドにcompliance_css_csを入力し、「適用可能対象」メニューから「ホスト」を選択し、「標準タイプ」として「リポジトリ」を選択します。「続行」をクリックします。
コンプライアンス標準ページに、compliance_css_csコンプライアンス標準に関する情報が表示されます。左側にあるcompliance_css_csを右クリックし、右クリック・メニューで「ルールの追加...」オプションを選択します。
「ルール参照を含める」ポップアップで、compliance_css_ruleを選択します。「OK」をクリックします。「保存」をクリックし、compliance_css_csを保存します。
「コンプライアンス・ライブラリ」ページに、コンプライアンス標準が作成されたことを示す確認メッセージが表示されます。「OK」をクリックします。
ターゲットの関連付けの手順:
作成したcompliance_css_csを選択します。「ターゲットの関連付け」をクリックします。
「コンプライアンス標準へのターゲット・アソシエーション: compliance_css_cs」ページで、「追加」をクリックし、ターゲットを追加します。
「検索と選択: ターゲット」ページで、/tmp/foo.xmlが存在するターゲットを選択し、「選択」をクリックします。「OK」をクリックします。
これにより、関連付けを保存するかどうかが尋ねられます。「はい」または「いいえ」をクリックします。これにより、コンプライアンス標準が処理のためにターゲットに対して発行されたことを示す情報メッセージが表示されます。
結果の表示の手順:
「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
「コンプライアンス結果」ページで、compliance_css_csコンプライアンス標準を選択し、「詳細を表示」をクリックして、作成したコンプライアンス標準の詳細を表示します。
compliance_css_ruleに関連付けられた「違反」タブをクリックします。ターゲットは1つ違反に関連付けられています。
ツリー内のルール・ノードをクリックして「違反イベント」タブを表示してから、このタブをクリックし、ルールの違反の詳細を表示します。違反表内の違反行をクリックし、違反の詳細を表示します。
この例の目的は、DBMSの権限アクションをテストするエージェント側のコンプライアンス標準ルールと手動ルールを作成することです。
エージェント側のコンプライアンス標準ルールを作成するには、次の手順を実行します。
構成拡張を作成します。
エージェント側のコンプライアンス・ルールを作成します。
手動ルールを作成します。
コンプライアンス標準の作成
ルールを構成標準に追加します。
コンプライアンス標準をターゲットに関連付けます。
構成拡張の作成
次の手順を実行して、構成拡張を作成します。
「エンタープライズ」メニューから「構成」を選択し、「構成拡張」を選択します。
構成拡張ページで、「作成」をクリックします。
拡張の名前(例: DG0142 DBMS Privileged action audit)を入力します。この名前は、チェック定義ページで使用します。
ターゲット・タイプに「データベース・インスタンス」を選択します。
「SQL」タブを選択します。
「加算」をクリックして、最初のSQL文を追加します。
「SQL」フィールドで、次のように入力します。
select distinct 'Unauthorized user '||owner||' owns application objects in the database.' value
from dba_objects where
owner not in ('ANONYMOUS','AURORA$JIS$UTILITY$', 'AURORA$ORB$UNAUTHENTICATED', 'CTXSYS','DBSNMP','DIP','DVF','DVSYS','EXFSYS','LBACSYS','MDDATA',
'MDSYS','MGMT_VIEW','ODM','ODM_MTR', 'OLAPSYS','ORDPLUGINS', 'ORDSYS',
'OSE$HTTP$ADMIN','OUTLN','PERFSTAT', 'PUBLIC','REPADMIN','RMAN','SI_INFORMTN_SCHEMA',
'SYS','SYSMAN','SYSTEM','TRACESVR', 'TSMSYSWK_TEST','WKPROXY','WKSYS',
'WKUSER','WMSYS','XDB', 'OWBSYS', 'SCOTT', 'ORACLE_OCM', 'ORDDATA', 'APEX_030200',
'OWBSYS_AUDIT', 'APPQOSSYS', 'FLOWS_FILES')
and owner not in (select grantee from dba_role_privs
where granted_role='DBA')
別名(たとえば、DBMS application object ownership)を入力します。この別名は、この構成拡張の最上部にルールを定義する際に役立ちます。
「パーサー」には、データベース問合せパーサーを使用します。
「加算」をクリックして、2つ目のSQL文を追加します。
SQL
select distinct 'Application object owner account '||owner||' is not disabled.' value
from dba_objects, dba_users where
owner not in ('ANONYMOUS','AURORA$JIS$UTILITY$',
'AURORA$ORB$UNAUTHENTICATED','CTXSYS','DBSNMP','DIP','DVF',
'DVSYS','EXFSYS','LBACSYS','MDDATA','MDSYS','MGMT_VIEW','ODM',
'ODM_MTR','OLAPSYS','ORDPLUGINS','ORDSYS','OSE$HTTP$ADMIN',
'OUTLN','PERFSTAT','PUBLIC','REPADMIN','RMAN',
'SI_INFORMTN_SCHEMA','SYS','SYSMAN','SYSTEM','TRACESVR', 'TSMSYS',
'WK_TEST','WKPROXY','WKSYS','WKUSER','WMSYS','XDB')
and owner in (select distinct owner from dba_objects where object_type <>
'SYNONYM')
and owner = username and upper(account_status) not like '%LOCKED%'
別名(たとえば、DBMS application object owner accounts)を入力します。
「パーサー」には、データベース問合せパーサーを使用します。
「保存」をクリックし、次に「構成」ボックスで「はい」をクリックします。
エージェント側のコンプライアンス標準ルールの作成
エージェント側のコンプライアンス・ルールを作成するには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
「コンプライアンス・ライブラリ」で、「コンプライアンス標準ルール」をクリックします。
「作成」をクリックします。「ルールの作成」ポップアップで、「エージェント側のルール」を選択します。
「続行」をクリックします。
「ルールの作成: エージェント側のルール: 詳細」ページで、次の情報を設定します(図48-11を参照)。
名前: DBMS application object ownership
コンプライアンス・ルールの状態: 開発
重大度: クリティカル
適用可能対象: データベース・インスタンス
説明: アプリケーション・オブジェクトは、所有権が承認されたアカウントにより所有される必要があります。
原理: データベース・オブジェクトの所有権は、所有するオブジェクトへのアクセス権を他のサブジェクトに割り当てる権限を含めて、所有するオブジェクトに対する完全な権限を意味します。オブジェクトの所有権が管理または制御されていないと、オブジェクトに対する承認されていないアクセスまたは変更が発生する可能性があります。
「次」をクリックします。
「ルールの作成: エージェント側のルール: チェック定義」ページで、以前に定義した構成拡張と別名を検索します。図48-12を参照してください。
注意: 構成拡張名と別名は、1つに結合されて「構成拡張」の名前と「名前」フィールドに表示されます。この例では、完全な名前は、DG0142 DBMS Privileged action audit-DBMS application object ownershipです。
「次」をクリックします。
「ルールの作成: エージェント側のルール: テスト」ページで、ターゲットを検索し、「テストの実行」をクリックします。テストが実行中であることを示すポップアップが表示されます。確認ポップアップの「閉じる」をクリックします。図48-13を参照してください。
注意: 違反のあるテスト結果を故意に生成することもできます。たとえば、target type equal to hostをテストして、ホスト・ターゲットを評価すると、違反結果が表示されます。
「次」をクリックします。
「ルールの作成: エージェント側のルール: 確認」ページで、情報が意図したものであることを確認します。意図したものとは異なる場合、「戻る」をクリックし、必要に応じて修正します。情報が正しい場合は、「終了」をクリックします。図48-14を参照してください。
注意: コンプライアンス標準ルールは、「終了」をクリックするまで定義されません。
ヒント
コンプライアンス標準ルールが作成されても、自動的には評価されません。コンプライアンス標準にコンプライアンス標準ルールを追加してください。
ルールが作成された後、ルールに修正処理を割り当てます。
「コンプライアンス標準ルール」タブで、作成したばかりのルールを強調表示します。
「アクション」メニューから修正処理の割当てを選択します。
修正処理の割当てポップアップで、既存の修正処理を選択して「OK」をクリックします。
これらの手順を2つ目のルールに対して繰り返します。
注意: コンプライアンス標準ルールは、「終了」をクリックするまで定義されません。
手動ルールの作成
この手動ルールを作成する目的は、自動化できないチェックを追跡し、テスト計画とプロシージャが遵守していることを本番での実装前に確認することです。
手動ルールを作成するには、次の手順に従います。
「コンプライアンス・ライブラリ」で、「コンプライアンス標準ルール」をクリックします。
「作成」をクリックします。「ルールの作成」ポップアップで、「手動ルール」を選択します。
「続行」をクリックします。
「手動ルールの作成」ページで、次の情報を設定します(図48-15を参照)。
名前: DBMS testing plans and procedures
コンプライアンス・ルールの状態: Production
重大度: 警告
適用可能対象: データベース・インスタンス
説明: DBMSのインストール、アップグレードおよびパッチをテストするための計画およびプロシージャは、本番での実装前に定義し、遵守する必要があります。
原理: 既存のソフトウェアに対する更新とパッチの適用には、セキュリティの強化、製品の機能の強化または製品への機能の追加の意図があります。ただし、残念なことに、更新またはパッチの適用が、本番システムを動作不能にしたり、重大な脆弱性をもたらすことがよくあります。また、一部の更新は、セキュリティ要件を満たさない許容不可能な設定にセキュリティ構成を戻します。これらの理由により、更新とパッチをオフラインでテストしてから本番環境に導入することがよい方法です。
推奨: DBMSのインストール、アップグレードおよびパッチをテストするためのプロシージャを開発、文書化および実装してから、本番システムにデプロイします。
コンプライアンス・メッセージ: DBMSのインストール、アップグレードおよびパッチをテストするための計画およびプロシージャは、本番での実装前に定義し、遵守します。
非コンプライアンス・メッセージ: DBMSのインストール、アップグレードおよびパッチをテストするための計画およびプロシージャは、本番での実装前に定義または遵守されません。
参照URL: http://iase.disa.mil/stigs/index.html
ルールのキーワード: セキュリティ
「終了」をクリックします。
標準コンプライアンスを作成するには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
「コンプライアンス・ライブラリ」ページで、「コンプライアンス標準」をクリックします。
「作成」をクリックします。「コンプライアンス標準の作成」ポップアップで、次を設定します(図48-16を参照)。
名前: CS1 - DB Check
適用可能対象: データベース・インスタンスの選択
作成者: SYSMAN
標準タイプ: エージェント側
「続行」をクリックします
「コンプライアンス標準: CS1 - DB Check」ページのナビゲーション・ツリーで、標準を右クリックします。「ルールの追加」を選択します。「ルール参照を含める」で、DBMS application object ownership、DBMS application owner accountsおよびDBMS testing plans and proceduresを選択します。図48-17を参照してください。「OK」をクリックします。
「保存」をクリックします。
コンプライアンス標準をターゲットに関連付けるには、次の手順に従います。
「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。
「コンプライアンス・ライブラリ」ページで、「コンプライアンス標準」をクリックします。
新たに作成した標準(CS1 - DB Check)をハイライト表示し、「ターゲットの関連付け」ボタンをクリックします。
「コンプライアンス標準へのターゲット・アソシエーション: CS1 - DB Check」ページで、「追加」をクリックします。
1つ以上のターゲット(Oemrep_Databaseなど)を選択します。図48-19を参照してください。
「選択」をクリックします。「OK」をクリックします。
「はい」をクリックして、アソシエーションを保存します。
この例の目的は、違反を抑止することです。「エージェント側のコンプライアンス標準ルールと手動ルールの作成」で定義した手動ルールにより発生する違反を抑止します。
次の手順を実行します。
