データ保護とマルチテナント

データ保護設計は、扱うデータの性質を理解し適切な分類と保護措置を施すことから始まる。データ分類は一般に「パブリック」「内部」「機密（Confidential）」「極秘（Restricted）」の4段階で行い、分類ごとに暗号化・アクセス制御・監査ログの要件を定める。個人を特定できる情報（PII: Personally Identifiable Information）は特別な保護が必要であり、仮名化（Pseudonymization）や匿名化（Anonymization）を用いて分析用途には識別子を取り除いた形で扱う設計が求められる。

暗号化は保存時（Encryption at Rest）と通信時（Encryption in Transit）の両方で必要である。保存時暗号化では、クラウドプロバイダーのマネージドな鍵管理サービス（AWS KMS・GCP Cloud KMS等）を活用し、アプリケーションレベルでも機密性の高いフィールドを個別に暗号化する場合がある。通信時暗号化ではTLS 1.2以上を強制し、証明書の管理自動化（Let’s Encrypt等）を整備することが重要である。

マルチテナント設計では複数の顧客（テナント）のデータを安全に分離することが最重要課題となる。分離戦略には「テーブル共有（tenant_idカラムで絞り込み）」「スキーマ分離（テナントごとに別スキーマ）」「DB分離（テナントごとに別データベース）」の3つのアプローチがあり、コスト・分離強度・運用複雑さのバランスで選択する。テーブル共有方式は最もコスト効率が良いが、クエリへのtenant_idフィルタの適用漏れが致命的なデータ漏洩につながるリスクを持つ。

コードレビューで着目するポイント

マルチテナントのクエリ全てに tenant_id のフィルタが適用されているか（行レベルセキュリティ等で強制する仕組みがあるか）
PII データが本番と同じ形でログや分析システムに流れていないか
暗号化鍵の管理がアプリコードに直接埋め込まれず、KMSやVaultで外部管理されているか
アクセス制御がリソースレベルで実装されているか（「ログイン済みユーザーは全ユーザーのデータを取得できる」という設計になっていないか）
データの保持期間ポリシーが実装されており、不要になったデータが自動削除されるか
GDPR・個人情報保護法の要請（削除権・開示権）に対応できるアーキテクチャになっているか
バックアップデータも本番データと同等の暗号化・アクセス制御が適用されているか

典型的なアンチパターン

tenant_id フィルタの適用漏れ: テーブル共有方式のマルチテナントで特定のAPIエンドポイントにtenant_idの絞り込みを忘れると、あるテナントの管理者が他テナントのデータを閲覧できる致命的なバグになる。PostgreSQLの行レベルセキュリティ（Row Level Security）等で仕組みとして強制する設計が推奨される。

本番データをそのまま開発環境にコピー: 本番のPIIをマスキングせず開発・ステージング環境に展開すると、アクセス管理が緩い環境でのデータ漏洩リスクが生まれる。開発環境では必ずデータのマスキング・仮名化を行ったコピーを使用すべきである。

フィールドレベル暗号化の欠如: データベース全体の暗号化（透過的暗号化）だけでは、DBに正常アクセスできる攻撃者に対して機密フィールドが平文で見えてしまう。特に機密性の高いフィールド（金融情報・医療情報等）はアプリケーションレベルでのフィールド暗号化も組み合わせるべきである。

参考リソース

標準: GDPR（EU一般データ保護規則） - 個人データ保護の基本的な要件と権利の定義
標準: 個人情報保護法（日本） - 日本における個人情報の取り扱いに関する法的要件
ツール: AWS KMS / GCP Cloud KMS - マネージドな暗号化鍵管理サービス
ツール: HashiCorp Vault - シークレット管理と動的な認証情報生成のためのツール
書籍: 「Database Security」 - マルチテナントのデータ分離と行レベルセキュリティの設計パターン