まえがき
データエンジニアリングにおけるデザインパターンを扱った書籍 "Data Engineering Design Patterns" の第 7 章 Data Security Design Patterns の感想を残していきます。
この章は、データエンジニアがビジネス資産であるデータセットを保護するために役立つ以下のような実現パターンを紹介しています。
- データの削除（GDPR や CCPA における「忘れられる権利」対応）
- データへのアクセス制御
- データの暗号化・匿名/仮名化
- データアクセス時の認証・認可
これらの感想として以下のことを述べています。
- 氏名・住所など個人識別情報のみ削除すれば大丈夫なのか（Vertical Partitioner パターン）
- 個人データ削除請求とタイムトラベルの両立（In-Place Overwriter パターン）
- レコード/カラム単位のアクセス制御に DBMS 機能/ビューのどちらを用いるか（Fine-Grained Accessor for Tables パターン）
- サーバーサイド暗号化は誰からのどういう脅威を守っているのか（Encryptor パターン）
- その「匿名化」が具体的に何をしているのか確認しよう（Anonymizer/Pseudo-Anonymizer パターン）
以前の 2～6章についての感想は以下です。この書籍を読む背景や感想を残していく方針について知りたい場合は、最初の記事を参照してください。
紹介されているデザインパターン
以下が本章で紹介されているデザインパターンです。（概要は私が自分の理解の元、言い直しています）
| セクション | デザインパターン | 概要 |
|---|---|---|
| Data Removal | Vertical Partitioner | 削除する必要があるデータとそれ以外の削除不要のデータを分割して保存する |
| In-Place Overwriter | 削除すべきデータを上書き削除する | |
| Access Control | Fine-Grained Accessor for Tables | カラム/レコード単位のアクセス制御 |
| Fine-Grained Accessor for Resources | リソースベース/アイデンティティーベースのアクセス制御 | |
| Data Protection | Encryptor | クライアント側/サーバー側でのデータ暗号化 |
| Anonymizer | データの削除、ノイズ混入、合成データへの置き換え | |
| Pseudo-Anonymizer | データのマスキング、ハッシュ化、トークン化 | |
| Connectivity | Secrets Pointer | パスワード/APIキーなどのシークレットを外部の鍵管理サービスに保存 |
| Secretless Connector | クラウドの IAM サービスでロールを割り当てることでシークレットキーなしでアクセスを許可 |
感想
事前のおごとわりですが、この記事の中で GDPR の条文やその遵守方法についていくつか触れています。ただし、私は法的な専門家ではありません（データマネジメントを担うものとしてある程度は押さえてはいますが）。実際の運用では専門家への相談が必要です。
氏名・住所など個人識別情報のみ削除すれば大丈夫なのか（Vertical Partitioner パターン）
Vertical Partitioner パターンは、本書籍では以下のような例で説明されています（データの中身は変えています）。
以下のようなユーザーの行動ログがあるとします。
| イベント ID | ユーザー ID | ユーザー住所 | 行動 | 対象 |
|---|---|---|---|---|
| 10001 | 201 | 東京都品川区… | click | index.html |
| 10002 | 202 | 神奈川県横浜市… | click | about.html |
これを、個人識別情報（PII：Personally Identifiable Information）とそれ以外に分割して保存します。
-
① PII
ユーザー ID ユーザー住所 201 東京都品川区… 202 神奈川県横浜市… -
② それ以外
イベント ID ユーザー ID 行動 対象 10001 201 click index.html 10002 202 click about.html
（② に含まれるユーザー ID は PII なのではという話もあるのですが、ユーザー ID を含めないと ① と組わせて分析できなくなるため、ひとまずこのままとします）
こうすることで、GDPR や CCPA（今だと CPRA）などに基づいてユーザーから個人データ削除の請求があった場合でも、① のテーブルの PII のデータのみ削除すればよいため、削除の処理コスト低減を図ることができるというのが、本書籍の主張になります。
ただ、ここで問題となるのは GDPR や CCPA における個人データの定義ですが、例えば GDPR では以下のような定義がされています。
personal data’ means any information relating to an identified or identifiable natural person (‘data subject’);
「個人データ」とは、識別されたまたは識別可能な自然人(「データ主体」)に関するあらゆる情報を意味する。
この定義に照らし合わせて、② のデータが個人データに当たらないかは注意が必要です。というか、多くの場合は当たると判断されます（日時や対象を元に他のデータと組み合わせることで個人を識別できる可能性があるため）。その場合、削除の義務が発生します。
一般に個人情報関連だと個人情報/データと個人識別情報の違いを認識していないケースが散見されますが、注意が必要ですね。
ちなみに、個人データ削除請求対応という文脈でなければ、データのライフサイクル（生成・更新・削除のタイミング）が異なるデータを分割して保存するというアプローチは、データ管理の観点からも有用な手段であることは確かです。
個人データ削除請求とタイムトラベルの両立（In-Place Overwriter パターン）
最近の DWH はタイムトラベルという機能があり、一定期間内の任意の過去断面のデータを参照する機能があります。この機能は以下のようなシチュエーションで非常に重宝します。
- バックフィル（過去の特定機関のデータ再処理）の前準備としてのデータ巻き戻し
- 上書き更新/削除してしまったデータの一時的な調査
- パイプライン処理のバグやオペミスに起因する誤ったデータ更新からの復旧
- これら機能的なメリットに加え、いざとなれば過去の断面に一瞬で戻せるという安心感
ただし、先に述べた個人データの削除請求を考えると悩ましいことになります。DELETE で該当する個人データのレコードを削除しても、タイムトラベル機能で参照できてしまうからです。
タイムトラベルを無効にすれば問題は回避できるのですが、先に挙げたメリットを放棄することになります。
ただし、現実的には必ずしも無効化する必要はないと思っています。GDPR の条文を以下に示します。
The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:
データ主体は、管理者から、本人に関する個人データの消去を不当に遅滞なく取得する権利を有し、以下のいずれかの理由が適用される場合、当該管理者は、個人情報を不当に遅滞なく消去する義務を負うものとする。
"without undue delay"（不当な遅延なく）削除する必要があると記載があり、即時削除しなければいけないというわけではありません。（そもそも申請を受けてからのリードタイムもあるはずなので即時削除自体は現実的には難しいのですが）
これを踏まえ、例えば削除請求から 30 日以内に削除するという対外的なポリシーとした場合、
- タイムトラベルは 7 日に設定する
- 削除請求のデータの実際の DELETE 実行は 20 日以内に行う
としておくと、タイムトラベルの恩恵を享受しながら、30 日以内という期限も守ることができるという考えもあると思います。
（「不当な遅延なく」がどれぐらいの期間を許容されるのかは意図をもって曖昧にされているので、結局は悩ましいですが）
レコード/カラム単位のアクセス制御に DBMS 機能/ビューのどちらを用いるか（Fine-Grained Accessor for Tables パターン）
Fine-Grained Accessor for Tables パターンの節では、テーブル単位のアクセス制御だけではなく、レコードやカラム単位でアクセス制御についても触れられています。
本書籍に記載がある通り、最近の多くの DBMS ではテーブル単位のアクセス制御よりさらに細かく、行や列ごとにアクセス制御を行うことが可能です。
- 列レベル
- BigQuery：データカタログにおけるポリシータグ
- Redshift や PostgreSQL：列単位の GRANT
- Snowflake：Masking Policy
- 行レベル
- Redshift：Row-Level Security
- Snowflake や BigQuery：Row Access Policy
ただし、これらの機能を使わずともビューを使うことで行・列へのアクセス制御は可能です。
DBMS の機能による実現とビューによる実現、どちらを採用するかというのは判断が分かれるところですが、私個人としてはビューで無理がないのであればビューにしたい派です。DBMS の機能による実現は以下のようなデメリットもあると考えているからです。
- 同じ名前のテーブルを見ているのに、ユーザーによって結果が異なるのは混乱を招きやすい
- 例外的なアクセス許可に対応しづらい
- 管理すべきオブジェクトが増える
- アクセス制御の設定が複数のオブジェクトに分散する
もちろん、以下のようなケースでは DBMS による機能の採用を検討すべきなので、結局は都度判断にはなりますが。
- マルチテナント環境など多数のグループ向けに異なるアクセス制御を行う場合（ビューで実現しようとすると、大量にビューが必要になるケース）
- 同一のアプリ・コードからユーザー属性によって動的にアクセス範囲を切り替えたい
- 一か所でアクセス制御のポリシーを確実に強制したい
サーバーサイド暗号化は誰からのどういう脅威を守っているのか（Encryptor パターン）
Encryptor パターンでは主にサーバー側のストレージ暗号化について説明されています。クライアント側は特に意識せずストレージにアクセスすると、サーバー側で自動的に暗号化/復号化を行う仕組みです。
AWS では以下のような機能に該当します。
- Amazon S3 の SSE-S3 や SSE-KMS
- Amazon EBS の EBS Encryption
今では採用が当たり前ですが、大昔にこの仕組みを学んだときは、この仕組みは誰からデータを守っているのか疑問に思っていました。
- 暗号化/復号化キーへのアクセスを持たないユーザーのアクセスから守る？
- サーバー側暗号化でよく誤解されやすいですが、ユーザーはストレージへのアクセス権に加え、暗号化/復号キーへのアクセス権を持たないとデータを読み取れない
- ただ、ストレージへのアクセス権制御のみで十分では？
- （クラウドはリソースを再利用するので、ユーザーが一度利用終了した後に他のユーザーに割り当てられた時には暗号化は有効？）
- クラウドプロバイダーが不正にデータを読むことから守る？
- そもそもクラウドプロバイダーの中の人であっても以下の仕組みがあり、データ読み取りは難しい
- データを読み取るには一時的な許可承認が都度必要
- 読み取り作業は監視される
- 物理区画は厳重に守られている など
- 以上の仕組みを信じないとした場合、そもそも暗号化/復号化の鍵をクラウドプロバイダーが持っているのだから、意味がないのでは？
- そもそもクラウドプロバイダーの中の人であっても以下の仕組みがあり、データ読み取りは難しい
- クラウドプロバイダーが利用終了して廃棄したディスクから第三者がデータを抜くことから守る？
- 第三者は暗号化/復号化キーを持っていないので、確かにこれは効果がある
- そもそもとして、クラウドプロバイダーがストレージを利用終了するときは物理破壊や NIST 方式/DoD 準拠方式などによる消去をすることになっているので、心配しすぎな気もする
これらの疑問が現時点でもきれいに解消しているわけではないのですが、サーバー側暗号化、特に顧客管理キーによるサーバー側暗号化を採用する大きな動機として、「暗号化消去」（Cryptographic Erase）があります。
以下のページで触れられているのですが、クラウドではストレージ上のデータを物理的に消去することは難しいため、データは暗号化してストレージに保存し、利用終了時に暗号化/復号化キーを廃棄しデータを二度と復号化できなくすることで、物理的消去の代替とするというアプローチになります。
「利用終了時にデータを物理削除したことを確認せよ」というオンプレ時のセキュリティーチェックルールに対応するためのアプローチである気もしなくはないのですが、実際にエンプラ領域だと顧客管理キーによるサーバー側暗号化は必須とされる印象を持っています。
（ちなみに、クラウドベンダー管理のキーによるサーバー側暗号化では復号不能性の証跡/担保が難しいので、注意が必要です。）
その「匿名化」が具体的に何をしているのか確認しよう（Anonymizer/Pseudo-Anonymizer パターン）
Anonymizer/Pseudo-Anonymizer パターンの節では以下の手法が紹介されています。
- Anonymizer パターン
- データの削除：保護したい情報を含むカラム・項目を削除する
- データの攪乱：保護したい情報のノイズを加える（例えば、文字列に対してランダムな文字を間に挟む）
- 合成データへの置換：データ型やデータの種別は同一のまま別の値に置き換える（「国名」カラムで「フランス」を「ドイツ」に置き換えるなど）
- Pseudo-Anonymizer パターン
- マスキング：保護したい情報の全部もしくは一部を無為な文字に置き換える（080-1234-5678 → 0X0-YYYY-ZZZ など）
- トークン化：保護したい情報を 1 対 1 でトークン（疑似識別子）に置き換える
- ハッシュ化/暗号化：保護したい情報をハッシュ関数/暗号化関数に掛ける
ただ、これらの内容は日本の個人情報保護法における「匿名化」とは異なりますし（「仮名化」に近い）、オライリーの別書籍「データ匿名化手法」で主題になっている「匿名化」 = 「非特定化」とも異なります。
それぞれにおける定義はここでは割愛しますが、DBMS の機能として「匿名化の機能があります」と宣伝されることがありますが、実際には何をしてくれるのかは仕様や実際の動作を確認する必要があるので注意が必要ですね。