変更要約: Professional Data Engineer 第1章を新規作成（ドメイン1「設計」: セキュリティ/コンプラ＝IAM 最小権限/組織ポリシー/GMEK・CMEK・Cloud EKM/Sensitive Data Protection/データ所在地/プロジェクト・データセット・テーブル設計/マルチ環境、信頼性と移行＝Dataform/Dataflow/Cloud Data Fusion・Cloud Composer・DR/フォールトトレランス/ACID/データ検証・BigQuery DTS/Database Migration Service/Datastream/Transfer Appliance）。
1.1設計：セキュリティとコンプライアンス
データ基盤の IAM と組織ポリシー、保存時/転送時の暗号化と鍵管理、個人情報（PII）の扱い、データ所在地（データ主権）、プロジェクト/データセット/テーブルのアーキテクチャ設計によるデータガバナンス、そして開発/本番のマルチ環境設計を理解します。
Professional Data Engineer は、データの収集・変換・保存・提供を担う堅牢なデータ基盤を設計します。設計の出発点は、性能や機能の前にセキュリティとコンプライアンスです。
1.1.1アクセス制御と暗号化
データへのアクセスは IAM の 最小権限 で設計し（基本ロールを避け事前定義/カスタム）、組織ポリシー で全社一貫の制約（リージョン制限など）を強制します。データは保存時/転送時とも既定で暗号化され、鍵の管理主体に応じて GMEK（Google 管理）/CMEK（Cloud KMS で顧客管理）/Cloud EKM（外部鍵）を選びます。個人情報（PII）は Sensitive Data Protection（Cloud DLP） で発見・マスキング/トークン化します。「最小権限＝IAM」「鍵を自社管理＝CMEK」「PII の保護＝Sensitive Data Protection」と結びます。
1.1.2データガバナンスとマルチ環境
データガバナンスは、プロジェクト/データセット/テーブルのアーキテクチャ設計から始まります（誰がどの粒度にアクセスするかを境界で表現）。データ所在地（データレジデンシー） で保管地域を制御し、規制（データ主権）に対応します。開発と本番は マルチ環境 で分離し、本番データを開発で誤用しないようにします。「データの統制は階層と境界で設計」「保管地域の規制＝データ所在地」「本番/開発の分離＝マルチ環境」を押さえます。
「要件 → 手段」が頻出。例：「データに最小権限」＝IAM 事前定義/カスタム、「全社一貫の制約」＝組織ポリシー、「鍵を自社で管理」＝CMEK（Cloud KMS）、「外部の鍵管理基盤」＝Cloud EKM、「PII を検出してマスキング」＝Sensitive Data Protection、「データを特定国に保管」＝データ所在地、「本番と開発を分離」＝別プロジェクト/環境。
混同に注意：
①既定で暗号化されるので論点は鍵の管理主体（GMEK/CMEK/EKM）。
②IAM（許可）と組織ポリシー（制約の強制）は別レイヤー。
③本番データを開発環境にコピーして放置しない（PII 漏えいの温床）。
1.1.3この節のまとめ
- IAM 最小権限＋組織ポリシー、暗号化は GMEK/CMEK/Cloud EKM を鍵管理で選ぶ
- PII は Sensitive Data Protection で発見・マスキング、保管地域はデータ所在地
- ガバナンスはプロジェクト/データセット/テーブル設計と本番/開発のマルチ環境分離で
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. データへのアクセスを最小権限で設計したい。最も適切なのはどれですか？
Q2. 暗号鍵を自社で管理し、ローテーション/無効化を制御したい。最適なのはどれですか？
Q3. データから個人情報（PII）を検出してマスキング/トークン化したい。使うのはどれですか？
Q4. 規制対応のため、データを特定の国/地域に保管したい。使う概念はどれですか？
Q5. 全社で一貫した制約（特定リージョン以外の作成禁止など）を強制したい。使うのはどれですか？
Q6. 本番データの誤用を防ぐためのデータ基盤設計として適切なものはどれですか？