設計の判断
セキュリティの設計
IAM で「誰が何をできるか」を決めたあと、組織ポリシー、VPC Service Controls、鍵の管理、アクセス経路の制御を重ねて、権限を持つ人や盗まれた認証情報でもできることを狭めます。
IAM は「この人はこの操作をしてよいか」を決めますが、管理者がバケットを誤って公開する事故や、盗まれた認証情報が社外から使われる事故は止められません。このページの統制は、IAM の外側に壁を 1 枚ずつ足すものです。試験では、要件の一文がどの壁を求めているかを見分けます。認証、認可、暗号化の仕組みは認証、認可、暗号化で扱いました。
組織ポリシーで、許してはいけない設定を先に禁止する
組織ポリシーは「どんな設定を」許すかを制御し、プロジェクトのオーナーでも禁止された設定は作れません。組織、フォルダ、プロジェクトに付けると下の階層に継承されます。よく出る制約は次の 4 つです。
constraints/iam.disableServiceAccountKeyCreation: サービスアカウント鍵の作成を禁止する。constraints/gcp.resourceLocations: リソースを作れるリージョンを限定する。constraints/iam.allowedPolicyMemberDomains: 自社のドメイン以外へのロール付与を禁止する。constraints/compute.vmExternalIpAccess: VM に外部 IP アドレスを付けさせない。
権限を絞らずに設定だけを縛りたいなら組織ポリシーです。ネットワークでは、階層型ファイアウォールポリシーがプロジェクトの管理者に上書きできないルールを組織やフォルダに置きます (VPC の設計)。
VPC Service Controls で、データの持ち出しを止める
VPC Service Controls は、Cloud Storage や BigQuery などのサービスの周りにサービス境界 (perimeter) を引きます。内側どうしは通信でき、境界をまたぐ通信は既定で遮断されます。IAM が身元で判断するのに対し、こちらはリクエストがどこから来たかで判断します。権限を持つ内部の人による外へのコピーも、社外で使われる盗まれた認証情報も、IAM は許可してしまうので、この境界で止めます。
外から入る通信は上り (ingress) ルール、内から外のリソースへ出る通信は下り (egress) ルールで個別に許可します。社外からのアクセスを IP アドレスや端末の状態で許すなら、Access Context Manager のアクセスレベルを境界に付けます。既存の環境には、まずドライランモードで入れ、遮断されるはずの通信を記録だけして確かめます。
暗号鍵は、要件が求める管理の強さで選ぶ
Google Cloud は保存データを既定ですべて暗号化するので、「暗号化したい」だけなら追加の作業は要りません。鍵の管理方法を変えるのは、自分で管理する理由が要件にあるときです。
| 方式 | 鍵の置き場所 | 選ぶ要件 |
|---|---|---|
| デフォルトの暗号化 | Google が管理する | 鍵の管理の要件がない |
| CMEK (Cloud KMS、SOFTWARE) | Cloud KMS。ローテーションや無効化は利用者が操作 | 鍵の管理と利用ログを自社で持つ |
| CMEK (Cloud HSM) | FIPS 140-2 レベル 3 の検証を受けた HSM | ハードウェアでの鍵保護が求められる |
| CMEK (Cloud EKM) | Google Cloud の外の鍵管理システム | 鍵を Google の外に置く |
CMEK なら、鍵を無効にするとデータを誰も読めなくなり、鍵の使用が監査ログに残ります。鍵を誤って削除するとデータを戻せないので、鍵の管理者と利用者のロールを分けます。Cloud KMS Autokey を使うと、CMEK の鍵の作成と割り当てを自動化できます。
サービスアカウント鍵を作らずに認証する
パスワードや API キーは、コードに書かず Secret Manager に置き、読めるサービスアカウントをシークレットごとに IAM で決めます。サービスアカウント鍵 (JSON の鍵ファイル) は、漏れたら誰でもそのサービスアカウントになれる長期の認証情報なので、試験では鍵を作らずに済む方法が正解になります。
Workload Identity Federation は、外部の ID プロバイダのトークンを短時間だけ有効な Google のトークンに交換します。権限借用には対象のサービスアカウントへの roles/iam.serviceAccountTokenCreator が要ります。普段は閲覧だけのロールにして強い操作のときだけ借用させると、職務の分離になり、借用の記録が監査ログに残ります。
人のアクセスは、ネットワークの位置ではなく身元と端末で判断します (ゼロトラスト)。Identity-Aware Proxy (IAP) は、IAM で許可された人だけをアプリに通します。IAP の TCP 転送を使えば、外部 IP アドレスのない VM に SSH できます。Chrome Enterprise Premium は、利用者、端末の状態、場所によるコンテキストアウェアアクセスに、データ損失防止やフィッシング対策を加えます。
サプライチェーン、AI、全体の見張り
イメージは Cloud Build でビルドして来歴 (provenance) を残し、Artifact Registry に置いて Artifact Analysis で脆弱性をスキャンします。「承認されていないイメージを本番で動かさない」には、必要な署名 (attestation) を持つイメージだけを GKE や Cloud Run にデプロイさせる Binary Authorization を選びます。スキャンだけではデプロイは止まりません。
生成 AI では、Model Armor が LLM に入るプロンプトと出てくる応答を検査し、プロンプトインジェクション、ジェイルブレイク、悪意のある URL、機密データを検出します。学習や RAG の前にデータから個人情報を外すのは Sensitive Data Protection (旧 Cloud DLP) です。モデルを公開する側は、最小権限のサービスアカウント、VPC Service Controls の境界、CMEK を Gemini Enterprise Agent Platform に組み合わせます。
Security Command Center は、公開されたバケットのような設定の誤りを一覧にします。Standard ティアは追加料金なしで使え、Premium ティアは脅威の検出、攻撃経路の分析、コンプライアンス基準への適合の監視を加えます (ティアの最新の内容)。
試してみる
Secret Manager のシークレットを権限借用で読み、許可したシークレットしか読めないことを確かめます。Secret Manager の無料枠に収まる規模です。
PROJECT_ID=$(gcloud config get-value project)
ME=$(gcloud config get-value account)
gcloud services enable secretmanager.googleapis.com iamcredentials.googleapis.com
# 読み取り専用のサービスアカウントを作り、自分に借用の権限を付ける
gcloud iam service-accounts create secret-reader
SA=secret-reader@${PROJECT_ID}.iam.gserviceaccount.com
gcloud iam service-accounts add-iam-policy-binding $SA \
--member=user:$ME --role=roles/iam.serviceAccountTokenCreator
# シークレットを 2 つ作り、片方だけサービスアカウントに読ませる
printf 'db-password-demo' | gcloud secrets create allowed-secret --data-file=-
printf 'other-demo' | gcloud secrets create denied-secret --data-file=-
gcloud secrets add-iam-policy-binding allowed-secret \
--member=serviceAccount:$SA --role=roles/secretmanager.secretAccessor
# 権限借用で読む。ロールの反映に 1〜2 分かかることがある
gcloud secrets versions access latest --secret=allowed-secret \
--impersonate-service-account=$SA
# こちらは PERMISSION_DENIED になる
gcloud secrets versions access latest --secret=denied-secret \
--impersonate-service-account=$SA後片付けをします。
gcloud secrets delete allowed-secret --quiet
gcloud secrets delete denied-secret --quiet
gcloud iam service-accounts delete $SA --quiet試験で問われる判断
以下は、このカリキュラム用に作った例です。
「分析チームは BigQuery の全データを読める。個人のプロジェクトへのコピーは防ぎたい」。読む権限は要るので IAM では絞れず、VPC Service Controls の境界で止めます。
「GitHub Actions のデプロイにサービスアカウント鍵を使っている」。Workload Identity Federation で鍵をなくし、組織ポリシーで鍵の作成を禁止します。
「保存データの暗号鍵を自社で無効化できる必要がある。鍵を Google の外に置く要件はない」。Cloud KMS の CMEK を選びます。Cloud EKM は要件を超えています。
次のページでは、法律や業界の基準が求める要件と、ここで扱った統制の対応を扱います。