サービス統合セキュリティー・インフラストラクチャーの監査

セキュリティー監査は、セキュリティー・インフラストラクチャーにおいて重要な役割を果たします。セキュリティー監査は、レコードの保全性を確保すると共に監査可能イベントを追跡してアーカイブするためのメカニズムを提供します。

始める前に

サービス統合のセキュリティー監査サブシステムを有効にする前に、使用している環境でグローバル・セキュリティーを有効にする必要があります。

このタスクについて

セキュリティー・インフラストラクチャーの主な役割は、リソースの不正使用を防ぐことです。セキュリティー監査には、以下のような 2 つの主な目的があります。
  • 既存のセキュリティー構成の有効性と保全性を確認する。
  • セキュリティー構成の改善が必要な領域を認識する。
セキュリティー監査では、サポートされている監査可能なセキュリティー・イベントを収集して保存するためにユーザーが独自のコードを実装できるようにするインフラストラクチャーを提供するという方法で、これらの目的を実現します。 Java™ エンタープライズ・アプリケーション・コード以外のすべてのコードは信頼できるコードであると見なされます。エンタープライズ・アプリケーションがリソースにアクセスする度に、コードに追加されている監査ポイントを持っている内部アプリケーション・サーバー・プロセスを、監査可能イベントとして記録することができます。セキュリティー監査サブシステムでは、以下のタイプの監査可能イベントが収集されます。
  • 認証
  • 許可
  • プリンシパルと証明書のマッピング
  • 鍵管理
  • システム管理
  • セキュリティー・ポリシー管理
  • 監査ポリシー管理
  • 管理構成管理
  • アドミニストレーション・ランタイムの管理
  • ユーザー・レジストリーおよび ID 管理
  • パスワード変更
  • 委任

これらのタイプのイベントを、監査ログ・ファイルに記録することができます。データの保全性を確保するため、監査ログ・ファイルについては、署名を付けたり、暗号化したりすることができます。これらの監査ログ・ファイルを分析することにより、既存のセキュリティー・メカニズムの欠陥を見つけたり、現在のセキュリティー・インフラストラクチャーの潜在的な弱点を発見したりすることができます。セキュリティー・イベント監査レコードは、証拠の提示、アカウンタビリティーの実現、およびぜい弱性分析にも役立ちます。セキュリティー監査構成には、デフォルト・フィルターが 4 つ、デフォルト監査サービス・プロバイダーが 1 つ、デフォルト・イベント・ファクトリーが 1 つ用意されています。セキュリティー監査サブシステムのカスタマイズ方法については、以下のステップで説明します。必要に応じて、メッセージング固有の追加情報がステップに含まれている場合もあります。

手順

  1. セキュリティー監査サブシステムの使用可能化

    セキュリティー監査は、セキュリティー監査サブシステムが有効になっていないと、実行されません。セキュリティー監査サブシステムを機能するようにするには、グローバル・セキュリティーを有効にする必要があります。なぜならば、グローバル・セキュリティーも有効になっていない場合、セキュリティー・イベントが発生しないからです。

    メッセージング・セキュリティー・イベントが監査されるようにするため、以下のようにして、監査セキュリティーを有効にします。

    1. バスごとに監査が実行されるようにする場合は、サービス統合 ->「バス」 ->「security_valueをクリックして、「このバスの監査サービスを有効にする (Enable the auditing service for this bus)」チェック・ボックスを選択します。
    2. パブリッシュ/サブスクライブ・メッセージングの場合も、バス上の監視対象のそれぞれのトピック・スペースについて、サービス統合 ->「バス」 -> 「bus_name -> [宛先リソース (Destination resources)]「宛先 (Destinations)」 ->「topic_space_nameをクリックして、「このトピック・スペースの監査サービスを有効にする (Enable the auditing service for this topic space)」チェック・ボックスを選択します。
  2. 監査員ロール

    監査者のロールを持っているユーザーが、セキュリティー監査サブシステムを有効にして構成する必要があります。セキュリティー・ポリシー管理のため、厳密なアクセス制御を課すことが重要です。監査者のロールを使用することによって、権限を細かく分けて、管理者の権限と監査ロールを切り離せるようになります。

  3. セキュリティー監査イベント・タイプのフィルターの作成

    イベント・タイプ・フィルターを構成して、特定の監査可能イベント・タイプのサブセットのみが監査ログに記録されるようにすることができます。記録されるイベント・タイプをフィルタリングすることで、自身の環境に関して重要であると選択したもののみがレコードに表示されるようになるので、監査レコードの分析が容易になります。

    メッセージングに関して構成できる監査イベントは、以下のとおりです。

    SECURITY_AUTHN
    このイベントは、メッセージング・バスに接続しようとしているメッセージング・クライアントまたはメッセージング・エンジンの ID が認証された場合に生成されます。
    SECURITY_AUTHZ
    このイベントは、メッセージが直接またはパブリケーションによって送信される時やメッセージが直接またはサブスクリプションによって受信される時に、バスまたはメッセージ・キューに対するアクセス権限を確認するためにメッセージ・クライアントの ID がチェックされた場合に発生します。
    SECURITY_AUTHN_TERMINATE
    このイベントは、メッセージング・クライアントまたはメッセージング・エンジンとメッセージング・バスの間の接続が強制終了された場合に生成されます。
    SECURITY_MGMT_CONFIG
    このイベントは、インポート操作時または除去操作時にサービス・データ・オブジェクト (SDO) リポジトリーの内容がメッセージング・クライアントによって変更された場合に生成されます。

    イベント・フィルターは、イベントとそれについて予想される結果 (SUCCESS、DENIED、または重大度別のエラー条件など) の順列ごとに作成することができます。

    どのようなメッセージング・セキュリティー監査イベントがどのような場合に生成されるかについて詳しくは、メッセージング・セキュリティー監査イベントを参照してください。

  4. セキュリティー監査用監査サービス・プロバイダーの構成

    監査サービス・プロバイダーは、渡された監査データ・オブジェクトをフォーマットしてから、そのデータをリポジトリーに出力します。

  5. セキュリティー監査用監査イベント・ファクトリーの構成

    監査イベント・ファクトリーは、監査可能イベントに関連付けられているデータを収集し、監査データ・オブジェクトを作成します。監査データ・オブジェクトは、監査サービス・プロバイダーに送られ、フォーマットされてから、リポジトリーに記録されます。

  6. セキュリティー監査データの保護 記録された監査データが保護され、なおかつ、それらのデータ保全性が確保されることが重要です。データへのアクセスが制限され、保護されるようにするため、監査データを暗号化し、それに署名を付けることができます。
  7. セキュリティー監査サブシステム障害通知の構成

    セキュリティー監査サブシステムが障害を検出した場合にアラートが発行されるようにするため、通知を有効にすることができます。通知は、アラートが監査ログに記録されるように構成することも、アラートが指定の受信者リストに電子メールで送信されるように構成することもできます。

タスクの結果

このタスクが完了すると、構成で選択した監査可能イベントに関する監査データが記録されるようになります。

次のタスク

セキュリティー監査の構成が完了したら、監査データを分析して、現行のセキュリティー・インフラストラクチャーの潜在的欠点や、既存のセキュリティー・メカニズムで発生した可能性があるセキュリティー違反を見つけることができるようになります。


トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tjrsec_sa_secauditing
ファイル名:tjrsec_sa_secauditing.html