今回は監査と監視をテーマに、主にログに関して考えるべきことを解説していく。
最近いろいろなお客さまから「ログを集約したい」という要望をいただいており、話をする機会も増えています。
実際にはログを集約する前に検討しなくてはいけないことや、ログを集約した後も検討すべきことがあり、こういった事前の検討が非常に重要です。今回は監査と監視をテーマに、主にログに関して考えるべきことを解説していきます。
まず、ログを集約する前に、その対象となる「ログ」とは何なのでしょうか? そして、何のためにログを取得するのでしょうか?
ログは、監査ログ(audit log)、監査証跡(audit trail)ともいわれますが、実際には「活動の記録」、つまりは「業務プロセスの実行の記録」です。このような「記録=ログ」の取得の目的は、以下のようなものになります。
本来は「業務がどのように行われているか?」についての説明責任への対応であり、「監査への対応」を目的とするのは正しくないのかもしれません。しかし、ログが取得されているかをチェックしているのは監査人以外にはほとんどいないため、現実的には「監査への対応」といってもよいでしょう。
一般的に、ログに最も多く触れる機会というのは、障害・事故対応時になります。何らかの障害や事故が発生したときに、その原因を追究するためです。また、同様の事故が起きていないかを確認するために、活動の記録であるログを精査・分析することは一般的に行われています。
ログがなかった場合の障害の原因究明がどのくらい大変になるかを想像すれば、いかにログの取得が重要かが分かると思います。
また、データベースの障害復旧などでは、ログに出力された内容を事故発生後の復旧作業に利用することもあり、こうした場合にはログの出力は非常に重要といえます。
日次・週次・月次などのレポーティングを行うためにログを集計したり、リアルタイムで事故や異常の発見を行うためにログを監視する、といったことはセキュリティに限らず運用においては広く行われています。
リアルタイム監視も周期的なレポーティングも、監視サイクルが違うだけでモニタリングには変わりませんが、リアルタイム監視は異常の検知が主目的といってもよいでしょう。また、周期的なレポーティングには業務の実施状況、例えばID作成が何件あったかなどを確認し、業務の有効性・効率性を確認していく目的でも使います。
これはSLA(Service Level Agreement:サービス品質保証契約)やCMMI(Capability Maturity Model Integration)の議論に近いのですが、内部統制システムはいったん構築したら終わりというものではなく、見つかった不備を改善していかなければなりません。そのためには、継続的に内部統制システムを評価し、不備を見つけていく必要があります。内部統制システムの評価は「統制活動が有効に機能しているか?」を業務プロセスや統制活動のログを利用して評価するのが一般的です。
これらの目的を実現するためにはログの取得が不可欠なのですが、「正しいログ」を取得しなくては目的を十分に果たせなくなる可能性があります。以下にログ取得に当たって注意すべきポイントをまとめました。
ログが「業務プロセスの実行の記録」であることは前述しました。従って、ログの取得対象は、業務プロセスで利用されているアプリケーションのログとなります。これらのログは業務アプリケーションから出力されるものであり、IT内部統制でいえばアプリケーション統制において取得されるログということになります。
それ以外に「誰がどのシステムにいつアクセスした」とか、「あるユーザーIDのアクセス権の変更をいつ行った」といったセキュリティ関連のログや、「この業務アプリケーションをいつバージョンアップした」などのシステム変更に関するログなどがあり、これらはIT全般統制で行われる統制活動において取得されるログになります。
このようなアプリケーション統制、IT全般統制についてのログが、IT内部統制において必要なログであり、特に日本版SOX法対応においては、「財務報告に深く関係する業務プロセスで利用されているアプリケーションのログ」と「日本版SOX対象アプリケーションに対するIT全般統制のログ」が重要になります。
ログにおいて取得すべき内容はログの利用目的によって変わります、つまり、利用目的を充足できる内容でなければなりませんが、アプリケーション統制のログにおいてもIT全般統制のログにおいても、共通して必要となるのは「4W1H」の情報です。
そして、これらの4W1Hの情報が一意に決まり、かつ、それらが信頼できる情報であることが必要になります。例えば、Who(誰が)の部分についていえば、ログに出力されたIDが特定の個人にひも付けられること(IDと個人が1対1の関係であること)、また、そのIDがひも付けられる個人以外に利用していないこと(IDの利用における有効な本人認証の実施)が保証されなければなりません。そういったことができていない場合、「Who」に記録されている情報が本当に利用した個人であることが保証できず、不要とはいわないまでも、結果として「正しいログ」ではなくなってしまいます。
従って、ログに出力される内容が必要な情報であることの保証が重要となります。
ログはテキストファイル(ログファイル)やDBへ出力されることが多いですが、そういったログファイルなどが改ざんされていないことも重要です。実際にログファイルを改ざんし、不正を行った証拠を消そうとした事件の例もあります。ログは参照されることはあっても、修正や変更される必要性は絶対にないので、ログの信頼性を確保するためには誰であってもログの改ざんができないようにしておく必要があります。
これらのログについてのポイントは、UNIX/Linux/Windowsなどのオープン系OSがデフォルトで持っているログの機能では満たすことが難しく、運用などを含めて、相当に考慮して行うか、OSのセキュリティ強化ツール(例えば、CAのeTurst Access Control)などを利用していくことが必要になります。
Copyright © ITmedia, Inc. All Rights Reserved.