社内のデータ活用促進のために、データ分析者が自由にデータを入手できるデータ基盤としてデータレイクを構築するのは良い考えです。しかし、単純に社内データを保存したデータの入れ物を作成して開放するだけで、利用者間でのデータ流通が実現できるわけではありません。その大きな理由は、データガバナンスが不十分なデータレイクでは、データ所有者は流出リスク恐れてデータ提供を躊躇することが想定されるためです(下図)。
このような無防備なデータ基盤では、社内データを安全に活用することができません。そのため、データガバナンスを向上させることが重要になります。データガバナンスについては、DMBOK(データ管理知識体系 | Data Management Book of Knowledge)の一領域になっていて、下記のような記事で議論されています。
- データマネジメントに関するフレームワーク：『ビジネス2.0』の視点：オルタナティブ・ブログ
- デジタル変革を支える、データガバナンスフレームワーク (1/4)：EnterpriseZine（エンタープライズジン）
ただし、この領域の議論は抽象的な内容が多いと思うため、本記事ではできるだけ技術的な観点から、データ基盤のデータガバナンスを機能させるためのセキュリティ要件について説明したいと思います。なお、この記事の内容は、いくつかのデータ基盤系ベンダの公開資料を基にした私の理解を書いたもので、情報の信頼性にはご注意ください。
セキュリティ4要件
最初に、データ基盤のデータガバナンスを機能させるためには、セキュリティ4要件を満たすように設計すると考えやすいと思っています。その4要件とは、**1.認証(Authentication)、2. 認可(Authorization)、3.監査(Audit)、4.保護(Protection)**のことです(下図)。
この4要件は、私がデータガバナンスの設計を検討する際に利用しているフレームワークです。これら4要件の活用の考え方について、以降から順番に解説していきます。
1. 認証 (Authentication)
認証とは、システム利用ユーザの正当性を検証する機能のことを言います。多くのアプリの認証機能としては、IDとパスワードを組み合わせたパスワード認証の形で実装されていると思います。認証方式にはパスワード認証の他にも、デバイス認証や生体認証、複数の認証方式を組み合わせた多要素認証(MFA | Multi-Factor Authentication)があります。認証によるユーザIDの正当性の保証は、他の認可や監査等のセキュリティ要件を実装する前提にもなります。
データレイクのデータガバナンスを機能させるには、データレイクにもユーザ認証の機能が必要と考えられます。データレイクを含むデータ基盤では、その周辺のアプリやシステム(データ分析ツールや業務DBなど)と連携させることが多いため、これらの連携先システム毎に認証を行うとすると、利用ユーザの認証情報の入力や登録情報の管理が煩雑になります。この煩雑さを防ぐために、特にデータレイクの認証では認証専用のシステムにユーザ認証の機能を集約して**シングルサインオン(SSO)**の構成をとることを基本的には推奨しています。
2. 認可 (Authorization)
認可とは、利用ユーザのシステム権限を管理する機能のことを言います。多くのアプリの認可機能としては、ユーザが利用できるシステム機能を、複数の権限やユーザをまとめたロールとグループの単位で制限する機能として実装されていると思います。認可は、認証機能と合わせてIAM(Identity and Access Management)とも呼ばれることもあります。
データレイクの認可では、システム権限だけでなくデータアクセスの権限管理も行うことが大切です。データアクセスを特定の利用ユーザやグループに許可するように制御することで、データレイク上での不適切なデータ利用を未然に防止することができます。注意点として、アクセス権限の設定はデータレイクに新規データを登録する度に必要になりますので、アクセス権限の承認者が不在の状況では正当なデータ利用も滞ってしまいます。そのため、権限を許可する際の承認フローを設定して、利用ユーザのアクセス要求に対応する管理体制を整備しておきます。
3. 監査 (Audit)
監査とは、利用ユーザの操作履歴を記録してその証跡を追跡可能にする機能のことを言います。監査機能を実装するには、対象システムの利用履歴を監査ログとして出力すれば最低限は良いですが、利用ユーザの不審を検知した時に、該当ログをすぐに確認できる機能も検討すると良いです。例えば、監査ログの統計情報を監査レポートとして可視化する機能や、不審な挙動を検知して管理者等に通知する機能などが考えられます。
データレイクの監査では、システムの操作履歴だけではなくデータ規制法令の準拠性の確認も重要になります。この種類の法令の有名な例としては、PCI-DSS(クレジットカード会員情報)、GDPR(EU市民の個人情報)、HIPPA(医療情報)などがあります。行政等からこれら法令への準拠性を問われた場合に、素早く証拠を提出できるように準備することが求められます。また、このような法令は、時代の流れによって都度改訂・新設されることがあるので、法令の内容の変更にも対応できるように監査の仕組みを検討しておくことが望まれます。
4. 保護 (Protection)
保護とは、機密情報を取り除くためにデータを加工する機能のことを言います。保護の例としては、暗号化や秘密分散などの暗号技術、データマスキング、仮名化、統計化、匿名化などのデータ加工手法があります。暗号化は復号鍵、秘密分散では分散片が無ければ解読できないようにデータを変換する方法です。データマスキングはデータを部分的に削除する方法、仮名化は識別情報を無意味なIDに変換する方法、統計化はデータを統計情報に変換する方法、匿名化はデータを統計的に分析しても個人を識別できないように加工する方法です。
データレイクでは、データ漏洩に備えてデータを暗号化するだけでなく、復号鍵の管理を一元化して、漏洩時にすぐに鍵を交換するための暗号鍵管理(KMS | Key Management System)について検討しておきます。また、データマスキングのルール管理について、**動的マスキング1と静的マスキング2**の採用方針を確認しておきます。動的マスキングの方がマスキングルールを柔軟に管理できますが、静的マスキングの方が社内セキュリティポリシーには準拠しやすい利点があります。
システム構成例
概念的な話はここまでにして、データガバナンスのシステム実装について考えてみます。下図は、これらのセキュリティ4要件(認証・認可・監査・保護)を考慮したデータレイクのシステム構成例です。データ取得フローを青字で、データ登録フローを赤字で記述しています。保護の要件については、図の都合からデータマスキングに絞って記載しています。
社内システム環境の事情や制約に応じて、実際にはこの図のシステム構成をアレンジして設計・開発することになります。
データ利用フロー
データの取得と登録のフローについて書きます。図の都合から、その他の利用フローについては省略しています。
データ取得フロー
データ利用者がデータを取得する際は、下記のような流れを想定します。この流れにより、アクセス権限を有する正当なユーザのみが保護されたデータを取得し、その記録を追跡可能な状態にします。
| 番号 | 分類 | 動作 | 説明 |
|---|---|---|---|
| G1 | - | アクセス要求 | データ利用者がデータアクセスを要求する |
| G2 | 認証 | ユーザ認証 | アクセス要求者が登録ユーザ本人であることを確認する |
| G3 | 認証 | 結果通知 | アクセス要求者の認証結果をデータレイクに通知する |
| G4 | 認可 | 権限照会 | アクセス要求者がアクセス権限を持つことを確認する |
| G5 | 認可 | 承認 | アクセス権限の承認を依頼し、承認後に権限を付与する |
| G6 | 保護 | マスキング(動的) | 利用ユーザのアクセス権限に応じてマスキングする |
| G7 | - | データ取得 | 利用者がデータレイクからデータを取得する |
| G8 | 監査 | ログ登録 | 利用者のデータ利用ログを記録する |
データ登録フロー
データ所有者がデータレイクにデータを登録する際は、下記のような流れを想定します。この流れにより、データレイク上には静的マスキング済のデータか、アクセス権限が適切に設定されたデータのみが登録されるようにします。
| 番号 | 分類 | 動作 | 説明 |
|---|---|---|---|
| P1 | - | データ登録 | データレイクに新規データを登録する |
| P2 | 保護 | データ検査 | 登録データに機微情報が含まれていないか検査する |
| P3 | 保護 | マスキング(静的) | 登録データに含まれる機微情報をマスキングする |
| P4 | 認可 | 権限登録 | データ利用に関する権限を登録する |
| P5 | 認可 | 承認 | 承認者がデータ利用に関する権限を承認する |
| P6 | 監査 | ログ登録 | データ取得ログを記録する |
管理担当者と管理システム
セキュリティ4要件(認証、認可、監査、保護)の運用に必要と考えられる、管理担当者と管理システムの役割と業務内容について記述します。
認証: ユーザ管理者とID管理システム
- ユーザ管理者
ユーザ管理者は、ID管理システムのUIを利用してデータ基盤の利用ユーザの管理を行います。管理業務の具体例として、利用ユーザの登録や削除、登録情報の更新、認証パスワード紛失時対応などを行います。
- ID管理システム
利用ユーザのアカウント情報は、ID管理システムに保存します。ID管理システムは、Active DirectoryやLDAP等のアカウント管理用のシステムを利用することを推奨します。シングルサインオン(SSO)構成では、SAML等の認証プロトコルを利用してログイン先システムとID管理システム間で認証情報を連携して、ID管理システム側に認証機能を一元化します。近年では、ID管理システムはIDaaS(ID as a Service)を利用し、オンプレのID管理システムを持たない選択肢もあります。
認可: 承認者と承認ワークフロー
- 承認者
承認者は、データ基盤のユーザ利用権限に関する判断を行います。例えば、データアクセス要求の承認や却下、データ参照・更新権限の付与や剥奪、その判断のための利用者やデータの調査を行います。承認者は、アクセス要求の正当性を適切かつ迅速に判断できる人が担当するのが良く、最終的な責任はCDO(Chief Data Officer)が持つことになります。
- 承認ワークフロー
利用ユーザのアクセス要求を承認する流れを円滑化するために、承認ワークフローのシステムを準備します。ワークフローを利用して、利用ユーザがデータアクセスを要求するとその要求が自動的に承認者に通知され、承認者がその要求内容を確認して承認するとアクセス権限が自動的に付与されるといった承認プロセスを作成します。
監査: 監査担当者とログ管理システム
- 監査担当者
監査担当者は、データ基盤の利用証跡を確認する役割を担います。例えば、データ不正利用の疑義が発生した場合に、監査ログからその証跡を確認して結果を報告します。もし監査ログが十分に管理されていず、複数システムにログ情報が散在していてデータ形式も揃っていない場合では、この監査業務の実行には大きな苦労が伴うことになります。
- ログ管理システム
監査担当者の業務効率化のために、監査ログを一元化して管理するためのログ設計を実施します。ログ設計では、監査対象のログ一覧を洗い出し、そのログ情報の集約先や確認方法について検討します。監査ログの蓄積先はRDBでも良いですが、RDBは事前のスキーマ定義が必要でデータの検索性や容量拡張性の制約がある3ため、Elasticsearch等のNoSQLやオブジェクトストレージを採用することも有力だと思います。
保護: マスキング担当者とマスキング実行管理
- マスキング担当者
マスキング担当者は、データマスキングの実行やその保護ルールの管理を担当します。静的マスキングでは、登録データの機微情報の有無を検査して、発見した機微情報を別の文字列等に変換します。動的マスキングでは、対象のデータと利用ユーザのマスキング実行ルールをシステムに登録し、そのユーザがデータを閲覧した際にマスキングされるようにします。
- マスキング実行管理
マスキング担当者の業務を支援するために、マスキング実行ルールを管理します。マスキング実行の流れとしては、データ提供者が登録するデータを検査して機微情報の有無を確認し、機微情報が含まれればマスキング実行ルールに従って自動的に実行するか、マスキング担当者に通知して判断を仰ぎます。動的マスキングの場合は、データの閲覧権限を認可情報と連携して管理します。
最後に
この記事では、セキュリティ4要件(認証、認可、監査、保護)の観点からデータガバナンスの考え方とそのシステム実装について書いてみました。データ提供者が安心してデータを共通的なデータ基盤に提供できることは、社内データ流通を実現するための必要条件の一つだと思います。
一方で、社内データ流通の実現させるためには、データ提供者以外の目線からのデータ管理の仕組みも必要だと考えています。具体例としては、データ発見・理解を促すためのメタデータ管理、データ品質劣化を防ぐためのデータ品質管理、複数DB間のデータ一貫性を維持するためのマスタデータ管理(MDM)、データパイプラインの変更管理を容易にするリネージ管理などがあります。これらのデータ管理の領域については、また機会があれば別の記事として書こうと思います。