情報漏えいの原因・対策に潜む課題

情報漏えい防止のため実施すべきセキュリティ対策とは

情報セキュリティは、機密性（Confidentiality）、完全性（Integrity）、可用性（Availability）という3つの要素に分解することができる。このうちの機密性が失われた時に、情報漏えいが発生する。言い換えると、情報漏えい対策とは、従来の情報セキュリティ対策に何かを新たに追加するということではなく、すでに一般的な情報セキュリティ対策の一部に含まれているはずのものである。

発生原因ごとに、どのような対策が効果的であるかを考えてみよう。

内部者による情報漏えい事故を防止するためには、情報に対するアクセス権限を厳密に（職務上の権限に基づき必要最小限で）管理することが特に重要である。具体的な管理策の例としては、情報システムの開発環境を本番環境から分離すること、職務やシステム上の権限を分割すること、ID／アクセス権限の発行を必要最小限にとどめて定期的にレビューすることなどが挙げられる。これらを実現する際には、システムの運用管理手続きの抜本的な見直しなど、地道な作業が必要になる。

外部者からのターゲット攻撃による情報漏えいを防止するためには、攻撃の手段に対する技術的対策を施すことが主となる。最近は、Webアプリケーションの脆弱（ぜいじゃく）性を利用した「SQLインジェクション」などの攻撃が広く行われている。攻撃手法そのものは技術的に高度だが、脆弱（ぜいじゃく）性の点検方法や対策の実施方法はほぼ確立されており、情報セキュリティ対策を実施するサービス会社などに依頼すれば、確実に解決できる。

これらの基本的な情報セキュリティ対策の指針としては、広く知られているISO 27001/27002や、PCI DSS（Payment Card Industry Data Security Standard）、あるいはCobiT（Control Objectives for Information and related Technology）といった、情報セキュリティ管理のためのフレームワークやベストプラクティス集が参考になる。また、自社内に専門的な経験が十分蓄積されていなければ、社外の専門家に支援を仰ぐことも効果的である。

情報漏えい事故の本当の原因

ここまで述べたように、情報漏えい事故の原因のほとんどは、すでによく知られた手段で解決できるはずである。しかし現実には情報漏えい事故は増加するばかりである。これはなぜか。それは、監査を通すことが目的となってしまい、運用のライフサイクルが回っていないからである。

現在、ほとんどの企業では、自社で行う情報セキュリティ対策をとりまとめた、情報セキュリティ・ポリシーを策定している。特に昨年、いわゆるJ-SOX法への対応として情報セキュリティ・ポリシーを整備し直した企業も多かったと思われる。

国内の企業が情報セキュリティ・ポリシーを作成する際には、親会社や情報セキュリティ・サービス会社などから提示される“ひな形”をベースにカスタマイズすることが多い。そのためか、たいていの企業の情報セキュリティ・ポリシーの内容は、非常によく整っている。

しかし、一時的な監査対応や認証取得だけを目的にして、ポリシー文書は作成するものの実施のための組織や体制をきちんと作らない、という場合も少なくないようである。ポリシーを運用していくための仕組みを構築しないと、監査や審査が済んだ後はそのまま放置され、空文化し、次の監査の時期まで情報セキュリティ対策はおざなりになり、情報漏えい事故がいつ発生しても不思議ではない状況になる。

情報セキュリティ・マネジメントにおいては、「PDCAサイクル」を推進することが何よりも重要である。ところが、どの企業でも、「P」（Plan：計画）と「D」（Do：実行）はよく行われているが、きちんと「C」（Check：点検）や「A」（Act：維持・改善）をきちんと行っている企業は、極めて少ない。

PDCAの「C・A」を適切に実施しなければ、仮にポリシー上で設計した情報セキュリティ対策が設計通りに機能していなかったとしても、それに気付くことができない。つまり、情報漏えいの原因となり得る問題が発生していても、それを発見できず、情報漏えいリスクがそのまま放置されることになってしまう。

次ページでは、正しい情報漏えい対策のための仕組み作りについて解説する。