アクセスログの監視は難しい
外部からのサイバー攻撃であっても、内部の不正行為であっても、アクセスログを活用して、事件・事故を速やかに検知するのは非常に困難だとされています。アクセスログには、サーバ側のログと端末側のログの2種類があり、それぞれを組み合わせることで有効なログ監視をおこなおうとします。
サーバ側で詳細なログを取得するのは、システム全体に影響を与える上、ログが膨大なため監視が難しいと言われています。そこで日本版SOX対応のあたりから、端末側の操作ログを監視するソリューションが主流となっていたように思います。確かに、オペレータレベルのユーザが、Windows端末からアプリケーション経由でデータベースの参照や抽出をおこなう、という場合には、端末側の操作ログの監視は非常に有効です。
経産省ガイドライン改正で流れが変わった
2014年夏、ベネッセの大規模漏えい事故はみなさんの記憶にも新しいかと思います。その事故を受けて2014年12月に経産省ガイドラインが改正されました。この中に明記されているのが特権ユーザの監視。Windowsからアプリ経由でデータベースを参照・抽出するという形ではなく、SSHやWRDで特権ユーザとしてサーバにアクセスした場合に、端末側の操作ログを監視しても具体的にどのような不正行為がおこなわれたのかは監視できません。また、セキュリティ対策が十分でない多くの企業は、エンジニアがrootで直接アクセスするため、だれがアクセスしたのかをなかなか特定できないという状況も多いと聞きます。
やはりお金も手間もかける必要がある
これをやれば大丈夫というものはなく、下記のような対策を組み合わせて実施するしかありません。言わずもがなですが、お金も手間もかかります。
- サーバ管理者、DB管理者を必要最小限に限定するとともに、ユーザを個別に識別できるようにする。
- データベースに対して、大量のデータを抽出するようなクエリが実行された際に、一定の条件でアラートが上がるように設定する。
- 上記の他、ネットワーク、サーバ、アプリケーションに対して重要な変更がおこなわれた場合に、一定の条件でアラートが上がるように設定する。
- リモートアクセスが実行された場合は、監査証跡としてスクリーンショットを保存する。
- 端末監視型のログ監視ツールを利用して、外部記憶媒体やインターネットへのデータの書き出しを監視する。
報道された情報漏えい事故の多くは、原因が究明されています。しかし、ログ監視の仕組みを通じて、能動的に検知できたケースは非常に少なく、情報漏えいが発覚してからバックログを調査してようやく原因を究明するというケースが多いです。また、漏えいした情報を入手して、そのデータの傾向から、漸くどのデータベースから情報が漏えいしたかが特定できるということも多いのではないでしょうか。
サイバー攻撃が多様化される中、日本国内の企業は各種サイバー攻撃対策も考える必要があります。内部不正行為の検知も非常に難しいのですが、サイバー攻撃への対策となるとさらに対応は複雑になります。スイスチーズモデルにイメージされる多層防御の仕組みと、発見的統制の考え方がポイントとなります。
