監査ログをいかに取得し活用するか［4ページ目］

2. 保管期間

保管期間と分析頻度は反比例の関係です。分析頻度が多いログは、異常検知が発生時点から近いタイミングで可能ですので、保管期間はそれ程長期間でなくても良いと考えます。一方、不正会計処理（循環取引など）を防ぐべきリスクとする場合には、発見に時間がかかる事例が多いため、ログ保管期間を12カ月以上とする事を推奨します。不正会計処理の場合、そもそも日々の業務上でのチェック機能が脆弱であるために発生するわけですが、発見に時間がかかる理由の例として、前任者の退職を含む担当者交代後に発覚するパターンがあります。

NIST（National Institute of Standards and Technology）のSP800-92「Guide to Computer Security Log Management」では、影響レベルごとに推奨する保管期間、ローテーション頻度、分析頻度などを記載しています。日本語訳も出ていますので、表5にその内容を記載します。

表5：ログ管理にかかわる推奨管理策

分類	低位影響レベルのシステム	中位影響レベルのシステム	高位影響レベルのシステム
ログデータを保管する期間	1～2週間	1～3ヶ月間	3～12ヶ月間
ログをローテーションする頻度	任意（実行する場合は、少なくとも週に一度または25MBごと）	6～24時間ごと、または2～5MBごと	15～60分ごと、または0.5～1.0MBごと
ログ管理インフラストラクチャへのログ転送を組織として義務づける場合、転送を実行する頻度	3～24時間ごと	15～60分ごと	少なくとも5分ごと
ローカルでのログデータ分析を実行する頻度（自動または手動による）	1～7日ごと	12～24時間ごと	少なくとも1日につき6回
ローテーションしたログのファイル完全性チェックを実行する必要性	任意	要	要
ローテーションしたログを暗号化する必要性	任意	任意	要
ログ管理インフラストラクチャへのログ転送に暗号化通信またはログ専用ネットワークを使用する必要性	任意	可能な限り	要
引用元：「コンピュータセキュリティログ管理ガイド」（P49）情報処理推進機構(IPA)/NRIセキュアテクノロジーズ株式会社による翻訳

また、データベース内に格納といったオンライン状態での保管期間と、バックアップテープやDVD、外付けHDDなどのオフライン状態での保管期間を整理する事で、ストレージコストの無尽蔵な膨張を割ける事ができます。

3. 事件・事故発生を想定した訓練

繰り返しになりますが、デフォルト設定は監査ログを取得する設定になっていません。また、著者の経験では、（1）を基に必要なログを定義したつもりでも、取得対象から漏れていたり、設定が不十分であったりして、重ね合わせると数珠つなぎにならないケースも見受けられます。

そこで、情報漏えいが発生したと仮定し、ログから事実確認がどこまで行えるのか、ステークホルダーへの対応はどのようにすれば良いかについて、訓練を行う事を推奨します。訓練と言うとBCPのようですが、情報漏えいが発生した際の現場の状況は、事業まではいきませんが業務が一時的には中断すると言って差し支えありません。システム停止リスクについては、地震（機器故障）や新型インフルエンザ（運用者不在によるシステム運用の継続困難）という分かりやすいキーワードにより訓練を実施したという話は聞きますが、情報漏えいが発生した際に備えての訓練を実施しているという話は、（有価証券報告書の「事業等のリスク」にて情報漏えいについて言及している企業も含め）めったに聞きません。

訓練をする事のメリットを整理します。

• 取得していると思っていた監査ログの抜け・漏れを確認。取得設定のチューニング材料となる
• 情報漏えいであっても発生すれば業務を中断せざるを得ない状況に陥るというリスクを理解。経営層に情報セキュリティ対策の意義を認識してもらうきっかけとしても利用可能
• ステークホルダー対応の抜け・漏れを確認。望ましい対応をするためにどのような監査ログが必要になるかを特定するきっかけとなり、チューニング材料になる

なお、ステークホルダー対応は情報システム部門の業務分掌に収まらないと思いますので、訓練は他部門との合同で行う、外部からの通報を受けるケースとしては一般ユーザーを含めて行うという方法も有益だと考えます。

4. 統合ログツールについて

内部統制をきっかけに、ログイン・ログオフやシステム変更管理にかかわる作業のログを一元管理化するツールが多数出ています。統合ログツールの利点は、各システムから吸い上げられたログを一元化する事で、分析が容易になる事だと考えます。しかしながら、統合ログツールを導入した所で、集中管理できるログは、各機器・ソフトウエア自体で取得したデータが転送またはコピーされたものに過ぎません。

統合ログツールを導入する際の基本的な検討手順は次の通りになります。

• 事件・事故の発生を水際で防ぎたい、または発生した時の対応判断材料を得たいリスクの特定
• リスクを防ぐために、また、対応材料とするために必要な情報の特定
• 必要な情報を取得するための監査ログ出力パラメータの特定

この手順は統合ログツールの導入有無にかかわらず、必要な監査ログを特定し取得していくための正攻法になります。統合ログツールという物を導入しても、必要な情報が集まらなければただの箱になってしまいますので、そのような事にならないよう監査ログと付き合ってみてください。

今回は、ログ管理の重要性と活用について解説しました。本連載はこれで終わりとなりますが、これまでの連載記事を含め、皆さんのデータベースセキュリティに対する意識がたかまる一助になれば幸いです。

【参照リンク】

データベース・セキュリティ・コンソーシアム（DBSC）（アクセス：2010/11）

「データベースセキュリティ安全度セルフチェック統計データ Ver. 2.1」データベース・セキュリティ・コンソーシアム（DBSC）（アクセス：2010/11）

「Oracle Databaseセキュリティ・ガイド　11gリリース1（11.1）」日本オラクル株式会社（アクセス：2010/11）

• [編集部注] 一部に文章の抜け、誤りがありましたので修正しました（2010.12.15）