権限と個人情報

データ基盤には、会社の大事なデータが集まります。必要な人に、必要な範囲だけ見せるのが基本（最小権限）です。テーブル単位の権限だけでは足りないことが多く、列や行の単位でも絞ります。

BigQuery のポリシータグ、Snowflake のマスキングポリシー・行アクセスポリシー、PostgreSQL の行レベルセキュリティ（RLS）などが使えます。権限は人ではなくグループ（役割）に付け、定期的に棚卸しします。

IAM の考え方は SRE の「IAM（権限管理）」へ

個人のアカウントで動いているパイプラインは、その人が退職すると止まります。パイプラインは必ずサービスアカウントで動かします。

IAM の考え方は SRE の「IAM（権限管理）」へ

個人情報の扱い：日本の個人情報保護法では、利用目的をできるだけ特定して本人に示し、その目的の範囲で使うのが原則です（目的外の利用には原則として本人の同意が要る）。他の情報と照らし合わせないと個人を特定できないように加工した仮名加工情報にすると、利用目的の変更の制限などが外れ、社内の分析で使いやすくなります（その代わり、第三者への提供は原則できず、本人を特定しようとすることも禁止です）。EU の人のデータを扱うなら GDPR も関わり、処理の法的な根拠や、本人からの削除・開示の請求への対応が求められます。GDPR では、追加の情報で個人に結びつけられる仮名化したデータも個人データのままで、完全に匿名にしたデータだけが対象の外になります。具体的な判断は法務と相談します。

メールアドレスを単純にハッシュ化しただけでは、ありそうな値を総当たりで戻される恐れがあります。秘密の鍵を使うハッシュ（HMAC など）にし、鍵は分析者が触れない所に置きます。また削除の請求に応えるには、どのテーブルにその人のデータがあるかを把握しておく必要があり、生データやバックアップにも残ることを考えておきます。

本人からの削除の請求に応えるには、その人のデータがどこにあるかを知っている必要があります。データ基盤は同じデータを何段にも複製するので、業務 DB から消しただけでは残ります。

いちばん効くのは、保存期間を決めて自動で消すことです。「念のため全部ずっと持つ」は、漏れたときの被害と削除の手間を大きくします。

「誰が、いつ、どのデータを読んだか」を記録しておくと、漏えいが疑われたときに範囲を確かめられます。クラウド DWH にはクエリの履歴と監査ログがあるので、保存期間を決めて残します。