データを持ち出させない、もしくは持ち出す行為を
可能な限り検知し事後対策を立てる

サイバー攻撃の被害の多くは、メールの開封（添付ファイルの開封やリンクのクリック等）やWebサイトの閲覧によるウイルス感染が原因といわれています。この場合、特定のセキュリティ対策製品を導入しただけでは被害を防ぐことができないことがあります。

個人情報や機密情報を扱う業務やその他重要な業務においては、ウイルス感染予防だけでなく、感染してしまうことを想定して感染後の被害の回避や被害を低減させるために、複数の対策を多層で行う必要があります。これを多層防御とよびます。ここで重要なのは、多層防御で侵入を100％阻止することは不可能であるとの前提を立てることから始まることです。

IPAのWebサイト^{【出典7】}には、ウイルス感染や内部不正が発生しても、被害を回避・低減できるシステム設計や運用ルールを作成しそれが徹底されているか、PDCAサイクルにそって対策を見直しているか、これらが多層防御対策において重要であるとしています。ポイントとしては（1）ウイルス感染リスクの低減（2）重要業務を行う端末やネットワークの分離（3）重要情報が保存されているサーバーでの制限（4）事後対応の準備、の4点があげられています。

では、多層の「層」は何を意味するのでしょうか。多層防御は軍事用語である「Defense in Depth（縦深防御）」から来ているといわれています。縦深防御は、攻撃側の前進を防ぐのではなく、前進を遅らそうとすることを目的とします。それにより、時間を稼ぎつつ、攻撃側の前進による占領地域の増加と引き換えに敵の犠牲者を増加させる戦略です。つまりサイバーセキュリティにおける多層防御は、複数の防壁をつくり、攻撃側が最終目的とするデータの搾取・破壊等をできる限り遅らせる、また最終目的に到達する前の検出を可能にし、防御を再構築する。さらに、万が一データに到達できたとしても、被害を最小限にできるよう、データを持ち出させないもしくはデータを持ち出す行為を可能な限り検知し事後対策を立てる、ということです図2。つまり、従来のセキュリティ対策の中核であった、入口対策だけでなく、入口・出口対策、データ（サーバー）保護対策等もバランスよく行うこと、これこそが多層防御なのです。層の概念の例として、図3の7つの層に分けて定義することが可能です^{【出典8】}。

今までの企業におけるセキュリティ対策は、多くの場合、「2物理」や「4ネットワーク」、ISMS等で管理を行っている企業では「1ポリシーと手順」に力を入れてきたと思われます。

さて、ここでもう一度考えてみましょう。企業にとって守るべき情報とは何でしょうか。顧客の情報や企業自身の機密情報等の重要情報ですね。ここで前述したサイバーセキュリティ経営ガイドラインの記述を思い出してください。「重要情報が保存されているサーバーの保護」がありました。多層防御で最終的に守るものは、「データ」です。データが置かれているファイルサーバーやデータベースサーバーを守る、つまりデータ防御を行うことが非常に重要です。

さらに考えてみてください。大規模な個人情報は、どのPCに置かれているでしょうか？ 効率的な作業を行うために、個人もしくは数人で利用するPCに一時的にデータを置く場合もあるでしょう（この行為はセキュリティ上、好ましくはありません）。しかし、年金事案においても、個人情報のデータはもともと、サーバー（ホストコンピューター）上にあったわけです。企業や機関においては多くの場合、重要なデータはファイルサーバーやデータベースサーバーに置き、一定の運用ルールの下で利用されているのではないでしょうか。ということは、多層防御の重要性から鑑みれば、ファイルサーバーやデータベースサーバーは、セキュリティ対策を十分に施す必要があることが理解できると思います。データを保持しているサーバーは最後のとりでです。データを守らなくして、セキュリティ対策ができているとはいえません。

不正アクセスの発見には、ログや監査証跡が必要で、
監査を可能にする仕掛けも重要

ファイルサーバーやデータベースサーバーにおけるセキュリティ対策として、まず暗号化をあげると思います。一つの対策であることは間違いありません。ただ、暗号化が有効なのはどういう場合かを考える必要があります。

暗号化は万が一、データが持ち出されても、データは解読可能ではない、という意味においてのみ有効な対策であることです。また技術が進歩しコンピューターが高速化するに従い、以前に比べ暗号化されたデータが解読されるまで時間がかからなくなっています。法制度においても「個人情報は暗号化されても個人情報として扱う」のが日本の国の考え方です。これらを考えてもデータ流出後の対策だけでは不十分であるということがおわかりいただけると思います。

それでは何が必要なのでしょうか。データに対するアイデンティティ・アクセス管理（IAM : Identity and Access Management）が必要だと思います。この考え方の一部分は、一般的にはID管理として知られています。ここで注意してもらいたいのは、ID管理のIDはIdentifier（識別子）ではないことです。Identity（アイデンティティ）です。アイデンティティは日本ではもともとは存在しなかった概念なので正確に訳すことが難しいです。アイデンティティは「属性情報の集合体」と表現するとIT関係者にはわかりやすいかもしれません。人間でいえば、性別・氏名・住所だけでなく、指紋・髪の色・血液型のような生体に関する情報、食べ物の好き嫌いや趣味等、後天的で年齢や時間とともに変化し得る情報等、こういった情報からあなたのようなヒトが形成されている、と考えていただければいいと思います。こういう解釈を持てば、ヒトだけでなく、モノにもID管理は存在し得ます。そのような考えの下で、整理された技術体系がIAMといえます。
IAMは（1）Authentication（認証）（2）Authorization（認可）（3）Audit（監査）の3Aの要素で構成されていると考えることができます。3Aの中では、認証と認可の違いがわかりにくいかもしれません。例えば、社員証で入館や入室管理がされているとしましょう。社員として認められれば、会社の正門から入れる。これはその人が社員として認められているからです。これが認証です。ところでその社員は事務作業のみを認められていて、サーバールームへの出入りが許されていないとします。これはその社員にサーバールームへの入室権限が認可されていないと定義することができます。この認可の考え方をヒト以外にも広げることができます。例えば、皆さんがネット上のあるWebサイトにおいて認証されログインできている状態でも、必ずしもすべてのアプリケーションやデータへアクセスができない場合があります。これはアプリケーションやデータへのアクセス権限が認可されていない、と定義することができます。

「誰がいつ、どのような方法で、どんなアプリを利用し、どのデータにアクセスしたか。」これを管理するのが、認証と認可の技術です。Webサービスでは、最近ではSAML、OAuth、OpenID ConnectのようなIDフェデレーション技術を組み合わせて認証認可を実現することが多いです。一方、アクセスをきちんと監視し、場合によっては不正アクセスを発見するためには、ログや監査証跡が必要です。すなわち3Aの3つ目のAである監査を可能にする仕掛けも非常に重要です。図4

厳格なアクセス管理は、
高度な権限管理機能と監査を可能にすることで実現可能

ベネッセにおける個人情報流出事件では、システム管理者が本来はアクセスする必要のない特定のデータにアクセスし、持ち出してしまったことが原因でした。もし、システム管理者の権限を最小にし、当該データにアクセスできなければ、事件は起こらなかった可能性も高いと思われます。もう少し話を一般的に広げてみます。人事に関する情報はどの会社でも厳格に管理されていると思います。そのようななか、システム管理者は人事データにアクセスしていいのでしょうか。本来は禁止するべきです。そのための方法は2つあると思います。一つは厳格なルールを作って監視をする方法。もう一つは権限を与えなければ、システム管理者でも人事データにアクセスできないようにアクセス権限を強制（この場合ははく奪）する方法です。これを人手でなく、システムの機能として実装することです。こうすることによって、サイバーセキュリティ経営ガイドラインに記載されている「重要データ（データベースおよびファイル）への高度な暗号化、アクセス制限、アクセスログ収集」のアクセス制限をより完全な形で実現することができます。また、マイナンバー制度では、「特定個人情報の適正な取扱いに関するガイドライン（行政機関等・地方公共団体等編）」^{【出典9】}の「（別添）特定個人情報に関する安全管理措置」における技術的安全管理措置・アクセス制御の手法の例示として、次の一文が記載されています。

このように、厳格なアクセス管理は強固な認証だけで成立するものではなく、高度な権限管理を行う認可の機能を実装すること、そして監査を可能にすることによって実現可能です。その際には、システムが正しく運営されていることを確認し、もし不正アクセスがあったらそれを確実に発見するためのログが非常に重要です。