はじめに

前回の記事では、「ビッグデータ、IoT、AIを取り入れたいならデータマネジメントについて知るべき」と題して、データマネジメントの必要性を事例ベースで紹介しました。

この記事では、データマネジメントの中のデータセキュリティについての勘所を紹介します。自社にあったデータセキュリティポリシー作成する助けになれば幸いです。

データセキュリティが取り扱う領域

DMBOK (Data Management Body Of Knowledge)に載っている内容と若干異なりますが、データセキュリティにおいて考えるべき項目は主に4つあります。

認証: ユーザを識別でき、他人へのなりすましができない
権限: 誰であれば、どのデータに、なにができるのかが決まっており、越権行為ができない
保護: 個人情報などの秘匿すべき情報がマスキングされている
監査: 誰がいつどのデータに対してなにをしたかを追跡できる

それでは、各項目について深掘りしていきましょう。

認証

認証は、ユーザの正当性を確認する行為です。リアルならば運転免許証やマイナンバーカードといった身分証明書を提示することが、ネットならばIDとパスワードでログインすることが一般的かと思います。

シンプルに見えますが、認証にはいくつもの落とし穴があり、ここを失敗すると権限や監査といった他の項目にも影響してしまいます。

【ケース1】 Aさん、Bさん、Cさんは全員DBの管理者で、adminユーザになることができます。あるとき、adminユーザがDBのデータを消去してしまいました。しかし、監査ログには「昨日、adminユーザがDBのデータを消した」としか残っておらず、Aさん、Bさん、Cさんの誰が消したかはわからずじまいでした。

このケースは、本来はAさん、Bさん、Cさんがadmin権限をもつという形であればよかった(もしくは、adminユーザへのログイン履歴も監査対象にすればよかった)のが、そうなっていなかったために起こっています。認証と権限をごっちゃにするのは運用が楽なところがある一方、このようなケースで問題になる恐れがあります。悪意のないなりすまし状態を作れます。

【ケース2】 システムDのデータが必要なシステムEがあり、Dの開発グループはsystem_eというユーザをEの開発グループに払い出していました。あるとき、system_eユーザ経由でDのデータが悪用されたことが発覚しました。Dの開発グループがEの開発グループに問い合わせると、Eの開発グループにいた異動者の権限棚卸しを忘れていたために今回の件が起こってしまったとわかりました。

このケースは、「1.誰がsystem_eユーザになれるか」と「2.誰がシステムDのデータを利用できるか」で、認証と権限のプロセスが階層化されてしまったため、システムDが直接データを守ることが困難になったために起こっています。システムDの開発グループが定期的に正しくユーザの棚卸しを行ったとしても、システムEの開発グループが手を抜いてしまうとセキュリティ上の問題になってしまいます。

社内のデータに関するシステムに関して、最低限どの程度の強度の認証を行うべきかを取り決め、それぞれが実際にどのような認証を行っているのかを管理するということが必要になります。

権限

権限は、ユーザの行動の正当性を確認する行為です。ファイルやDBででてくるRead(読み込み)権限/Write(書き出し)権限の権限です。権限は、なりすましがないという前提で話を進めるため、認証に穴がある場合は機能しなくなります。

権限も厳密に考えていくといくつもの落とし穴があります。

【ケース3】 Aさんは極秘の案件を回していました。案件に関するすべてのファイルの内容は、案件に関わる人しか見えないようにしていました。しかし、ある日、同僚Bから極秘案件について尋ねられました。Aさんが「どうして、その案件を知っているのか」と聞くと、Bさんは「見知らぬ名前の案件のファイルがあったから気になって聞いた」と答えました。

既存のしっかりとしたソフトウェアを使っていれば、ファイル名といったメタ情報などに関しても権限を持たないユーザには見えないはずなので、こういったことは起こりません。しかし、Excelなど自前で管理している場合、この限りではありません。中身が見えなくてもメタ情報が見えるだけで問題になることもあり得ます。普段、機械のほうでよしなにやってくれているからこそ、いざ、自分で考えるとなると抜け漏れが発生しやすいです。

【ケース4】 WebサービスDの行動ログは、Dの開発グループしか見られないようにしています。しかし、WebサービスDはリバースプロキシEを利用しているので、リバースプロキシEのログをあさるとDの行動ログが取得できることに気づきました。

このケースでは、サービスのアーキテクチャを把握していなかったため、リバースプロキシEがWebサービスDのログを内包しているとしらず、片手落ちの権限管理になってしまっています。人の場合も同様で、組織構造に合わせて部下の権限を機械的に上司にもエスカレーションするという運用にした場合、兼任者がでてきた時点で破綻する恐れがあります。権限は、あるデータとユーザの1対1の関係で見るだけでなく、各データや各ユーザの関連性を把握した上で考えなければなりません。

社内のあらゆるデータに関して、誰がなにをできるかを取り決め、本当にその取り決めどおりに権限管理ができているかを管理・統制することが必要になります。

保護

保護は、秘匿すべき情報がマスキングする行為です。リアルならば文書の秘匿すべき箇所を黒塗りにすることに、ネットならば該当の値をハッシュ化(復号しなければならない場合は、暗号化)することに該当します。

個人情報などシビアに扱わなければならないものが不要に拡散しないようにするためにも、保護する対象と保護方法は丁寧に設定されるべきです。顧客の氏名、メールアドレス、電話番号、クレジットカード番号などがよく対象となります。

保護についても落とし穴になるケースを1つ紹介しましょう。

【ケース6】 SNSサービスDでは、分析用のDB上で顧客氏名をハッシュ化していました。しかし、ユーザの投稿内容は保護対象となっていなかったため、DBにある投稿内容をもとにSNSから該当の投稿を検索し、ハッシュ化されていない顧客の生の氏名を得ることができてしまいました。

SNSやCGMサービスのデータ分析では、分析用DBの保護対象カラムの値をハッシュ化したとしても、そのサービス上で検索すればハッシュ化前のデータが得られてしまうことがあり得ます。例えば、ユーザAがメールアドレスを見えるような投稿をしていた場合、この方法で、Aの生のメールアドレスとハッシュ化したメールアドレスの両方が得られます。保護に脆弱なハッシュ関数が使われ、さらに他のカラムも全く同じ方法で保護していた場合、悪意があれば保護対象の元のデータを大量に取得することができてしまいます。

社内で保護の対象対象のデータはなにか、どうやって保護するのかを取り決め、本当に保護されているかを監督する体制を整えることが必要になります。

監査

監査は。誰がどんな行動を取ったかを監督し検査するする行為です。会計監査という文脈で聞く言葉ですね。

監査は、どこまでやるかの決めが重要になります。「誰がなにをしたかの監査ログを、どの粒度で何日保管するか」という問いに対して、わかっていない人は「一番細かな粒度でずっと保管した方がいいじゃないか、大は小を兼ねる」と答えるかもしれません。こうなってしまうと、監査ログ自体がビッグデータになり、実施頻度の割にランニングコストの高い監査システムを開発するはめになります。ただ、【ケース1】で紹介したとおり、監査ログの粒度が必要よりも荒いとなにかあったときに追跡できなくなってしまいます。

また、不正行為があった際に、リアルタイムで自動的に検知したいのか、定期的に人力で確認するのか、嫌疑がかかったときにだけ人力で確認するのかで必要となるデータやシステムは大きく異なってくるでしょう。人力対応なら、それだけの人件費も投じなければなりません。

社内におけるデータセキュリティポリシーに則り、どれだけの保証をどれだけのコストをかけて行うかを取り決め、それを実施できる体制を整える必要があります。

データセキュリティの位置づけ

データセキュリティのポリシーを決める際には関連するポリシーやルールに気を配る必要があります。下図は、私がDMBOK (Data Management Body Of Knowledge)をもとにまとめた、データセキュリティポリシーの位置づけです。

まず、データセキュリティポリシーは法的要求事項を満たすように設定される必要があります。会社法や個人情報保護法を無視した緩いセキュリティポリシーを作成しても意味がありません。

次に、IT部門がある会社は、情報セキュリティに関するポリシーが既にあるかと思います。なので、その情報セキュリティポリシーで決められた内容も満たす必要があります。情報セキュリティポリシーの中で、業務に関するあらゆるデータの社外への持ち出しが制限されているのに、データセキュリティポリシーでは許可されているというのはおかしいです。今後の業務推進を、既存の情報セキュリティポリシーが阻害する場合は、情報セキュリティポリシーを先に修正し、拡大さた情報セキュリティポリシーの中でデータセキュリティポリシーを作成するのがよいかと思います。

そして、これらのポリシーやルールと矛盾がない形で、上述の「認証・権限・保護・監査」の各項目を定義したデータセキュリティポリシーを作成します。

このような階層構造であるため、データセキュリティポリシーを作成する際には、IT部門のセキュリティ担当者、法務部門の担当者、監査部門の担当者と協力した方が円滑に進むと思われます。この点に関しては、企業毎に事情が異なるでしょうが…。

おわりに

長くなりましたが、データセキュリティの勘所を、落とし穴とセットで紹介しました。

データセキュリティ管理は、リスクヘッジのためにするもので、それ単体では売上に寄与しません。このため、どれだけの費用をかけてなにをするかを考える必要がでてくるでしょう。会社のお財布事情と万が一の際のユーザへの信頼失墜を天秤にかけつつ、自社にあったデータセキュリティ管理を行ってみてください。