セキュリティ設計 — 鍵・境界・ゼロトラスト

ここまでの章で、権限は 第 2 章の IAM、ネットワークは 第 3 章と 第 12 章で設計してきました。この章はそれらを「多層防御（defense in depth）」として束ねます。守る対象は 3 つに整理できます。鍵（保存データの暗号化とシークレット）、境界（組織ポリシーと VPC Service Controls によるガードレール）、そしてゼロトラスト（IAP・Cloud Armor によるアクセス経路の防御）です。PCA 試験のセクション 3.1 は配点約 18% のドメインの中核で、「この要件ならどの層のどの道具か」を選ばせる問題が繰り返し出ます。

鍵 — 保存データの暗号化と Cloud KMS・Secret Manager

既定の暗号化 — 何もしなくても全データは暗号化されている

Google Cloud では、保存されるすべての顧客データが既定で AES-256 により暗号化されます。追加設定も追加費用も不要です。仕組みを知っておくと CMEK の理解が速くなります。データはストレージ層でチャンクに分割され、チャンクごとに別のデータ暗号鍵（DEK）で暗号化されます。DEK 自体は鍵暗号鍵（KEK）でラップ（暗号化）されて保存されます。この 2 段構えをエンベロープ暗号化と呼びます。既定では KEK は Google 内部の鍵管理システム Keystore に保管され、定期的に自動ローテーションされます。暗号処理には FIPS 140-2 検証済みモジュール（BoringCrypto）が使われます。

つまりアーキテクトが選ぶのは「暗号化するかどうか」ではなく、KEK を誰が管理するかです。選択肢は 3 段階あります。

CMEK — 鍵のライフサイクルを自分の手に

CMEK（customer-managed encryption keys、顧客管理の暗号鍵）は、KEK を Cloud KMS 上の自分の鍵に置き換える方式です。鍵の作成・保存場所・保護レベル・ローテーション・アクセス制御・無効化・破棄をすべて顧客が制御でき、鍵の利用が監査ログに残ります。Cloud Storage・BigQuery・Compute Engine をはじめ多数のサービスが CMEK に対応しています（対応サービスは公式ドキュメントの CMEK integrations 一覧で確認できます）。

仕組みの要点はサービスエージェントです。Cloud Storage や BigQuery などの CMEK 対応サービスは、プロジェクトごとの特別なサービスアカウント（サービスエージェント）を介して Cloud KMS に暗号化・復号を依頼します。このため、鍵に対して roles/cloudkms.cryptoKeyEncrypterDecrypter を付与する相手はエンドユーザーではなくサービスエージェントです。逆に言えば、鍵を無効化・破棄すればサービスは復号できなくなり、データへのアクセスを鍵側から一括遮断できます（クリプトシュレッディング）。これが「退役するデータの確実な無効化」や「有事の緊急遮断」という設計要件への答えになります。

CSEK — 鍵を持ち込む最終手段

CSEK（customer-supplied encryption keys、顧客提供の暗号鍵）は、Base64 エンコードした生の AES-256 鍵をリクエストのたびに自分で送り込む方式です。Google は鍵を保存せず、検証用の暗号学的ハッシュだけを保持します。鍵が Google 側に残らない代わりに制約が多く、Cloud Storage ではコンソールから CSEK オブジェクトを操作できず、バケット既定鍵にも設定できません。鍵をなくせばデータは復元不能です。対応サービスもごく一部で、Compute Engine のディスク向け CSEK はすでに非推奨となり CMEK への移行が案内されています（2026-08 時点）。実務でも試験でも、まず CMEK（外部に鍵を置きたいなら後述の Cloud EKM）を検討するのが筋です。

Cloud KMS の構造とローテーション

Cloud KMS の資源はロケーション → キーリング → 鍵 → 鍵バージョンの階層です。キーリングと鍵はいったん作ると削除できません（破棄できるのは鍵バージョンだけで、名前は永久に残ります）。CMEK 用途では、鍵は保護対象リソースと同じロケーションに作るのが原則です。保護レベルは 3 系統あります（2026-08 時点）。

• ソフトウェア鍵 — FIPS 140-3 レベル 1。鍵バージョンあたり月 $0.06 と安価で、CMEK の既定解
• Cloud HSM — FIPS 140-2 レベル 3 のハードウェア保護。鍵バージョンあたり月 $1.00〜2.50
• Cloud EKM — 鍵を外部の鍵管理システムに置いたまま使う。鍵素材は Google に送られない。鍵バージョンあたり月 $3.00

対称鍵には自動ローテーションを設定できます（--rotation-period）。ローテーションすると新しい鍵バージョンがプライマリになり、以後の暗号化に使われますが、既存データは再暗号化されません。古いバージョンは古いデータの復号のために有効なまま残ります。非対称鍵は公開鍵の配り直しが必要なため自動ローテーション非対応です。なお、CMEK 対応リソースの作成時に鍵・キーリング・権限付与まで自動生成する Cloud KMS Autokey も使えます。

Secret Manager — 「値そのもの」を守る

データベースのパスワードや API キーのようなシークレット（秘匿値）を環境変数やリポジトリにばらまかず一元管理するのが Secret Manager です。Cloud KMS との違いは明快で、KMS は鍵素材を決して外に出さず暗号処理だけを引き受けるのに対し、Secret Manager は値そのものを保存し、権限のある呼び出しに返すサービスです。

• シークレットとバージョン — シークレットはメタデータの器で、実データはバージョンとして積み重なる。バージョンには有効 / 無効 / 破棄の状態があり、ロールバックや段階的な切り替えに使える
• レプリケーション — 自動（Google が配置を選ぶ）とユーザー管理（リージョンを指定）。データレジデンシー要件にはリージョナルシークレットも選べる
• IAM 連携 — 読み出しに必要なのは roles/secretmanager.secretAccessor のみ。管理と参照のロールを分離できる
• 運用機能 — ローテーション通知・有効期限・監査ログ・CMEK 対応

本番コードでの参照は latest ではなくバージョン番号を固定するのが公式の推奨です。料金はアクティブなバージョン数とアクセス回数に応じた従量制で、月あたりバージョン 6 個・アクセス 10,000 回までの無料枠があります（2026-08 時点）。

境界 — 組織ポリシーと VPC Service Controls

組織ポリシー — 「できない」を作るガードレール

IAM は「誰に何を許可するか」を決めますが、許可を持つ人の操作ミスや悪意までは防げません。組織ポリシーは、組織 / フォルダ / プロジェクトに継承される制約（constraint）で「誰であってもこの構成は作れない」を強制します（第 2 章の入口の深掘りです）。制約にはブール型とリスト型があり、セキュリティ設計で頻出の代表例は次のとおりです。

• compute.vmExternalIpAccess — VM への外部 IP 付与を制限する（既定では全 VM に付与可能）。攻撃面を一気に減らす定番
• iam.disableServiceAccountKeyCreation — サービスアカウントキーの作成を禁止し、鍵漏えい事故の元栓を締める（マネージド版は iam.managed.disableServiceAccountKeyCreation）
• iam.allowedPolicyMemberDomains — ドメイン制限共有。許可した Google Workspace 顧客 ID に属するプリンシパルにしかロールを付与できなくする。allUsers / allAuthenticatedUsers の付与もブロックされる
• compute.skipDefaultNetworkCreation — 新規プロジェクトでの default ネットワーク自動作成を止める

このほか、指定サービスに CMEK の利用を強制したり、鍵を置くプロジェクトを限定したりする CMEK 関連の制約群もあります。組織ポリシーは組織リソースが前提のため、学習用の個人プロジェクトでは適用の練習はできませんが、試験では「全プロジェクトに強制したい」というフレーズが出たら組織ポリシーを疑ってください。

VPC Service Controls — データ持ち出しを境界で防ぐ

IAM が正しくても防げない攻撃があります。盗まれた認証情報による組織外からのアクセス、内部者による gcloud storage cp での組織外バケットへのコピー、そして IAM の設定ミスです。VPC Service Controls（VPC SC）は、プロジェクトと Google 管理サービス（BigQuery、Cloud Storage など）の集合をサービス境界（service perimeter）で囲み、境界内の通信は自由にしたまま、境界をまたぐサービスアクセスを既定でブロックします。公式ドキュメントの整理では、IAM は「ID ベースのきめ細かいアクセス制御」、VPC SC は「コンテキストベースの境界セキュリティ（egress 制御を含む）」と役割が異なります。

設計時に知っておくべき部品は 4 つです。① 境界外から特定条件のアクセスを許す ingress ルールと、境界内から外への持ち出しを許す egress ルール（境界同士をつなぐペリメータブリッジもありますが、現在は ingress / egress ルールが推奨）。② 許可条件を IP 範囲やデバイス属性で表現する Access Context Manager のアクセスレベル。③ 本適用の前に「ブロックせず記録だけする」ドライラン モード。既存システムに境界を後付けするときの必須手順です。④ ネットワーク側の合わせ技として、第 3 章で触れた restricted.googleapis.com（199.36.153.4/30）に DNS を向け、保護対象 API への経路をインターネット非経由に限定する構成。なお VPC SC はメタデータの移動までは完全に守れないため、メタデータの保護は IAM で行う、と公式ドキュメントも明記しています。

ゼロトラスト — IAP・Cloud Armor・Security Command Center

IAP — ネットワークの内側ではなく、人を検証する

「社内ネットワークにいるなら信用する」という境界型モデルを捨て、すべてのアクセスをユーザーの ID とコンテキストで毎回検証するのがゼロトラスト（Google の実装思想としては BeyondCorp）です。その中心となるプロダクトが IAP（Identity-Aware Proxy）で、HTTPS アプリケーションの前段に集中認可レイヤーを挟み、ネットワークレベルのファイアウォールではなくアプリケーションレベルのアクセス制御を実現します。

HTTPS リソースの保護では、App Engine・Cloud Run のほか、第 5 章のアプリケーション ロードバランサと組み合わせて Compute Engine / GKE のバックエンドを守れます。ユーザーは Google アカウント等でサインインし、IAP が IAM ロール（IAP-secured Web App User）を確認してから初めてアプリに到達します。注意点として、VM の配信ポートに直接届く経路が残っていると IAP を素通りできてしまうため、バックエンドへの直接アクセスをファイアウォールで塞ぎ、アプリ側でも署名付きヘッダーを検証するのが公式の推奨です。

もうひとつの顔が TCP 転送です。SSH / RDP などの TCP トラフィックを暗号化された HTTPS トンネルでラップし、外部 IP を持たない VM へ踏み台（bastion）サーバーなしで届けます。必要なのは、IAP の送信元レンジ 35.235.240.0/20 からの内向き通信を許可するファイアウォールルールと、利用者への roles/iap.tunnelResourceAccessor の付与だけです。接続は VM の nic0 の内部 IP に転送され、アイドル 1 時間で自動切断されます（大容量データ転送用の経路ではありません）。

Cloud Armor — エッジで受け止める WAF と DDoS 防御

Google Cloud Armor は、DDoS 攻撃と、SQL インジェクション（SQLi）・クロスサイトスクリプティング（XSS）のようなアプリケーション攻撃から守るマネージドサービスです。L3 / L4 のボリューム型 DDoS 防御は、グローバル外部アプリケーション ロードバランサなどではティアに関係なく自動で常時有効になります。L7 ではセキュリティポリシーをバックエンドに適用し、OWASP Core Rule Set に基づく事前構成 WAF ルール（SQLi / XSS など）、IP やリクエスト属性によるカスタムルール、レート制限を組み合わせます。上位版の Cloud Armor Enterprise では、機械学習でトラフィックを分析して L7 DDoS を検出し防御ルールを提案する Adaptive Protection や、Google の脅威インテリジェンスに基づく制御が使えます。適用対象は外部アプリケーション LB のほか、リージョン内部アプリケーション LB、プロキシ / パススルー型のネットワーク LB にも広がっています（2026-08 時点）。

Security Command Center — 多層防御を監視する

ここまでの防御を「作って終わり」にしないためのリスク管理基盤が Security Command Center（SCC）です。公開バケットや過剰権限のような構成ミスを検出する Security Health Analytics、ログから不審な挙動（クリプトマイニング等）を見つける Event Threat Detection、Web アプリの脆弱性を診断する Web Security Scanner などの検出サービスが見つけた問題を、finding（検出結果）として一元的に集約します。Cloud Armor など他サービスからの findings も集まります。組織レベルとプロジェクトレベルの有効化があり、フル機能は組織レベルが前提です。ティアは Standard / Premium / Enterprise の 3 段階ですが、Enterprise ティアは 2027-05-21 に終了して Premium へ移行すると告知されています（2026-08 時点）。

ハンズオン

前提は第 1 章の学習用プロジェクトと Cloud Shell です（ローカルの gcloud でも実行できます）。PROJECT_ID は自分のプロジェクト ID に読み替えてください（gcloud config get-value project で確認できます）。

gcloud services enable cloudkms.googleapis.com

gcloud kms keyrings create handson-kr --location=asia-northeast1

gcloud kms keys create handson-key \
  --keyring=handson-kr --location=asia-northeast1 \
  --purpose=encryption \
  --rotation-period=90d --next-rotation-time=2026-11-15T00:00:00

gcloud storage service-agent --project=PROJECT_ID \
  --authorize-cmek=projects/PROJECT_ID/locations/asia-northeast1/keyRings/handson-kr/cryptoKeys/handson-key

gcloud storage buckets create gs://PROJECT_ID-cmek-handson \
  --location=asia-northeast1 \
  --default-encryption-key=projects/PROJECT_ID/locations/asia-northeast1/keyRings/handson-kr/cryptoKeys/handson-key

echo "sensitive data" > sample.txt
gcloud storage cp sample.txt gs://PROJECT_ID-cmek-handson/

gcloud storage buckets describe gs://PROJECT_ID-cmek-handson \
  --format="default(default_kms_key)"

gcloud storage rm --recursive gs://PROJECT_ID-cmek-handson

gcloud kms keys versions destroy 1 \
  --key=handson-key --keyring=handson-kr --location=asia-northeast1

gcloud services enable secretmanager.googleapis.com

echo -n "db-pass-v1" | gcloud secrets create db-password \
  --replication-policy=automatic --data-file=-

gcloud secrets versions access latest --secret=db-password

echo -n "db-pass-v2" | gcloud secrets versions add db-password --data-file=-

gcloud secrets versions access 2 --secret=db-password

gcloud secrets add-iam-policy-binding db-password \
  --member="serviceAccount:SA_EMAIL" \
  --role="roles/secretmanager.secretAccessor"

gcloud secrets delete db-password --quiet

gcloud compute instances create iap-vm \
  --zone=asia-northeast1-b --machine-type=e2-micro --no-address

gcloud compute firewall-rules create allow-ssh-ingress-from-iap \
  --direction=INGRESS --action=allow --rules=tcp:22 \
  --source-ranges=35.235.240.0/20 --network=default

gcloud compute ssh iap-vm --zone=asia-northeast1-b --tunnel-through-iap

gcloud compute instances delete iap-vm --zone=asia-northeast1-b --quiet

gcloud compute firewall-rules delete allow-ssh-ingress-from-iap --quiet

つまずきポイント

理解度チェック

まとめと次章へ

• 保存データは既定で AES-256 のエンベロープ暗号化。方式選択の本質は「KEK を誰が管理するか」で、鍵の統制が要件なら CMEK、鍵を Google に置けないなら Cloud EKM。CSEK は制約が多く Compute Engine では非推奨
• Cloud KMS はロケーション → キーリング → 鍵 → バージョンの階層。キーリングと鍵は削除不能で、ローテーションしても既存データは再暗号化されない
• シークレットは Secret Manager に一元化し、secretAccessor の最小付与とバージョン固定参照で使う
• IAM は「誰に許可するか」、組織ポリシーは「誰にも作らせない」、VPC Service Controls は「データを境界から出さない」。守る対象が違うので置き換え不能
• IAP はアプリと SSH/RDP をユーザー単位のゼロトラスト認可で守り、Cloud Armor はエッジで DDoS と WAF を受け持ち、SCC が構成ミスと脅威を findings として監視する

参考リンク（公式ドキュメント）:

• Cloud KMS のリソースと保護レベル / CMEK の仕組み / 保存時の既定の暗号化
• Secret Manager の概要
• VPC Service Controls の概要 / 組織ポリシーの制約一覧
• IAP の概要 / IAP TCP 転送
• Cloud Armor の概要 / Security Command Center の概要

次の第 14 章は、この章の道具を「規制要件への翻訳」に接続します。HIPAA・PCI DSS・GDPR といったコンプライアンス要件をアーキテクチャに落とし込み、Sensitive Data Protection による PII 検出や Cloud Audit Logs による証跡設計を扱います。本章の CMEK・VPC Service Controls はそこでも主役です。