Top Story 1 （5）
リスクをいかにマネジメントしていくか
安心安全な企業経営を支えるITガバナンス

情報セキュリティガバナンスを強力に推進する
セキュリティアーキテクチャーとセキュリティソリューション

内部統制の信頼性を支えるIT基盤の証跡管理

今日の企業活動においては、多くの場面で証跡が必要とされます。それぞれの証跡は、その目的によって性格が大きく異なります。ある証跡は大量に保存する必要がある一方で、別の証跡は、量は少ない代わりに直ちに管理者の元へ届くことが求められたりします。このような証跡の性格を整理することが、証跡を効率的に管理するための前提条件になります。

[図6]証跡の分類例

前述の「富士通ESA」では、証跡を以下の4分類に分けて定義しています。

マネジメント状況把握型（M型）

情報セキュリティマネジメントシステムやマネジメントプロセスが正しく機能していることを確認するための証跡です。文書や報告書等、自由形式で記録されることが多いため、システムで自動的に処理するのには向きません。版数管理や承認履歴等、文書としての正当性に対する要件が多いので、文書管理システム等で取り扱うことが有効です。証跡としてのデータ量は決して多くはありません。また、集中管理する必要性もそれほど高くありません。

コントロール状況把握型（C型）

個々の情報セキュリティ対策が正しく機能していることを確認するための証跡です。パッチ適用状況、セキュリティソフトの導入状況、ファイアーウォールの稼働状況等がこれに相当します。一般的に、日常的なセキュリティチェックリストに記載される項目がほぼこれにあたります。セキュリティ対策が機能しなくなった場合には速やかにその事実を検知する必要がありますから、この証跡には適度なリアルタイム性が求められます。証跡としてのデータ量は多くありません。状況を的確に把握するために、集中管理を行うインフラが求められることがあります。

セキュリティ不正検知型（D型）

不正な行為によって個々の情報セキュリティ対策が脅威に面していることを知らせるための証跡です。セキュリティの異常ログやファイアーウォールの遮断ログ等がこれにあたります。かなり緊急性が高い性質のものを含みますので、証跡の収集には一般に高いリアルタイム性が求められます。証跡としてのデータ量は比較的少量です。その特性上、このカテゴリーの証跡はよくセキュリティ監視の対象となります。

セキュリティ追跡性確保型（T型）

不正な行為があったときに、その行為の内容や影響範囲を事後的に確認するための証跡です。実際にどの情報にアクセスしたか、どのような操作をしたか等を事後に検証できるようにするために、正常な業務の結果を記録する必要があります。このため、データ量が大量になる傾向があります。収集のリアルタイム性は高くはありませんが、目的によっては例えば「72時間以内に事実を確認できること」といった時間制約が付くこともあります。集中管理できることが望ましいのですが、データ量が多いため、データ集約のコストが高くなりがちです。管理方法は、大容量データの保管に最も適した方法の選択が最優先される傾向があります。事件の証拠として証跡を用いる場合（いわゆるフォレンジックの用途）は、上書きできない記憶媒体を利用する等のデータの正当性の保証対策が求められますが、厳密にこの保証を担保しようとするとデータ量の多さから莫大な投資を必要とする場合もあり、費用対効果の考量が必要です。なお、証跡をフォレンジック用途に利用する場合は、証跡が通過する全てのプロセスにおいて情報の信頼性を保証するchain of custodyの概念等、フォレンジックに特有の概念を理解しておく必要があります。

証跡の収集と記録の方針決定のためのガイドライン

前項では証跡を4種の類型に分けましたが、現実にはこれらの証跡は複雑に絡み合っています。例えば同じ機器で発生するログでも、失敗ログはD型（セキュリティ不正検知型）、成功ログはT型（セキュリティ追跡性確保型）になるのが一般的です。どちらか一方だけを記録するのであればさほど問題はありませんが、両方を記録するならば、それぞれの証跡類型に求められる要件の双方を満たさなければなりません。
D型とT型の証跡は、論理的にはITシステム上の資産を利用する場面で常に取得することが可能です。この資産利用時のD型・T型の証跡が、一般的に言われる監査ログに相当します。
また、C型（コントロール状況把握型）とD型は、一般にモニタリングの対象となります。セキュリティ管理はPDCAが継続的に行われ改善されていくことが重要です。そのためには、システムの運用が監視（モニタリング）され、対処・見直しが必要な問題を早期・確実に発見できることが必要となります。セキュリティ管理上、モニタリングに求められるものは以下の通りです。

セキュリティに関する機能（製品の設定等）が計画通りに実施されている／されていないことが確認できること。また実施されていない場合、管理者に通知されること
対処・見直しが必要となる事象発生が通知・記録されること

一方で、セキュリティ問題の影響把握、業務継続性の観点から、システム全体の運用が正常に行われていることをモニタリングできている必要があります。つまり、システムの監視、運用管理とセキュリティ管理のモニタリングは切り離せない関係であるといえます。このことから、セキュリティ管理とシステム運用を統合管理でき、役割（セキュリティ管理者、運用管理者、業務担当者等）にあわせて管理できることが求められます。モニタリングの対象となるのは以下のような事象です。

システム異常（ハード、ソフト）
性能情報（CPU、メモリ、ディスクI/O、ネットワーク・トラフィック）
セキュリティ管理製品のアラート
ログの異常

性能情報のモニタリングは、システムのキャパシティ・プランニング以外にもDoS攻撃（Denial of Services Attack：サービス拒否攻撃）によるネットワーク・トラフィックの増加等を検出できる可能性があり、セキュリティ上も有効な監視項目です。
ログの異常とは、ログ（たとえばIDSのログ等）に直接的に異常を示す情報が出力されることや、特定パターンのログが出力された場合に警告をあげられるようなログのコリレーション監視のことを指します。モニタリングがログのコリレーション（Correlation：相関分析）機能を持つことは、ノウハウの蓄積により異常検出パターンを追加でき、監視精度を上げるのに非常に有効です。