第1回 問題集（全般）

正解: B. Just-In-Time (JIT) アクセスを構成する

正解の根拠・詳細解説

本番環境での一時的な特権アクセス（昇格アクセス）を管理する最適な方法は、Just-In-Time (JIT) アクセス または Privileged Access Management (PAM) を使用することです。これにより、ユーザーは必要な理由を記載してアクセスをリクエストし、承認後に一定期間のみ権限が付与されます。

正解: C. BigQuery 動的データマスキング (Dynamic Data Masking)

正解の根拠・詳細解説

BigQueryの動的データマスキングを使用すると、データ自体のストレージは変更せずに、クエリ実行ユーザーの権限（ロール）に応じて機密列を自動的にマスキングして返すことができます。

正解: B. ネットワークタグ（Network Tags）またはサービスアカウントを使用してVPCファイアウォールルールを適用する

正解の根拠・詳細解説

GCPのVPCファイアウォールルールでは、適用対象として「ネットワークタグ」または「サービスアカウント」を指定できます。Webサーバーインスタンスに特定のタグ（例: web-server）やサービスアカウントを割り当て、そのターゲットに対してのみHTTPS（TCP 443）のインバウンドを許可するルールを作成するのがベストプラクティスです。

正解: A. Cloud Audit Logs の管理アクティビティ監査ログ (Admin Activity Logs)

正解の根拠・詳細解説

「管理アクティビティ監査ログ」は、リソースの構成やメタデータを変更するAPI呼び出し（IAM変更、VM作成・削除など）を記録します。これはデフォルトで常に有効になっており、無効にすることはできず、無料で提供されます。

正解: B. Security Health Analytics

正解の根拠・詳細解説

Security Command Center の Security Health Analytics は、GCPリソースの設定ミスや脆弱性（公開バケット、開いているファイアウォールポート、MFA未設定のユーザーなど）を自動的にスキャンして検出する機能です。

正解: A. 組織 → フォルダ → プロジェクト → リソース

正解の根拠・詳細解説

Google Cloudのリソース階層は「組織（Organization）→ フォルダ（Folder）→ プロジェクト（Project）→ リソース」の順です。フォルダは部門や環境（本番／開発）ごとの区切りとして使い、複数階層にネストできます。IAMポリシーや組織のポリシーは上位から下位へ継承されるため、組織レベルで設定した制約は配下のすべてのプロジェクトに自動的に適用されます。プロジェクトがフォルダの親になることはありません。

正解: B. 組織のポリシーで constraints/iam.allowedPolicyMemberDomains を設定する

正解の根拠・詳細解説

組織のポリシー（Organization Policy Service）のリスト制約 constraints/iam.allowedPolicyMemberDomains は「ドメインで制限された共有」と呼ばれ、許可したCloud Identity／Google Workspaceの顧客IDに属するプリンシパルのみをIAMポリシーに追加できるようにします。組織レベルで設定すれば配下の全プロジェクトに継承されます。VPC Service Controlsはデータの持ち出し（API境界）を守るもので、IAMメンバーの追加自体は防げません。

正解: C. 組織のポリシーで constraints/iam.disableServiceAccountKeyCreation を適用する

正解の根拠・詳細解説

組織のポリシー制約 constraints/iam.disableServiceAccountKeyCreation を有効にすると、その組織・フォルダ・プロジェクト配下でユーザー管理のサービスアカウントキーを作成できなくなります。カスタムロールから権限を外す方法は、基本ロールや他のロールを持つユーザーには効果がなく抜け道が残ります。キーの代わりにサービスアカウントの権限借用（impersonation）やWorkload Identity 連携を使うのが推奨です。

正解: D. Workload Identity 連携（Workload Identity Federation）を構成する

正解の根拠・詳細解説

Workload Identity 連携は、AWS、Azure、オンプレミスのOIDC/SAMLプロバイダなど外部IDプロバイダの認証情報を、Google Cloudの短命なアクセストークンと交換する仕組みです。これによりサービスアカウントキーの配布・保管が不要になり、鍵の漏洩リスクを根本的に排除できます。APIキーは呼び出し元の識別のみで認可には使えず、OAuthクライアントIDの埋め込みも機密情報の配布という同じ問題を抱えます。

正解: B. GKE Workload Identity を有効にし、KSAとGoogleサービスアカウントを紐付ける

正解の根拠・詳細解説

GKEのWorkload Identityは、Kubernetesサービスアカウント（KSA）をGoogle Cloudのサービスアカウント（GSA）に紐付け、Podが短命な認証情報で直接GCP APIを呼び出せるようにする推奨方式です。Secretとしてキーをマウントする方法は漏洩リスクがあり、ノードのアクセススコープを広げるとノード上の全Podが同じ強い権限を持ってしまいます。IAM条件でPodのラベルを評価することはできません。

正解: D. roles/iam.serviceAccountTokenCreator

正解の根拠・詳細解説

サービスアカウントの権限借用（impersonation）で短命なアクセストークンやIDトークンを生成するには、対象のサービスアカウントに対して roles/iam.serviceAccountTokenCreator（サービスアカウントトークン作成者）が必要です。serviceAccountUserはVMやCloud Runなどのリソースにサービスアカウントを「アタッチ」する際に使うロールです。KeyAdminは鍵の作成・削除、AdminはSA自体の管理ロールで、いずれも今回の目的には過剰または不適切です。

正解: A. IAM 拒否ポリシー（Deny Policy）を作成する

正解の根拠・詳細解説

IAMの拒否ポリシー（Deny Policy）は、特定のプリンシパルに対して特定の権限の使用を明示的に拒否する仕組みで、許可ポリシーよりも常に優先して評価されます。上位階層から継承された強いロールがあっても拒否が勝つため、ガードレールとして有効です。ロールの剥奪は上位階層からの継承には対応できず、uniform bucket-level accessはACLの無効化であって削除操作の禁止ではありません。

正解: C. プロジェクトにリーエン（Lien）を設定する

正解の根拠・詳細解説

プロジェクトリーエン（Lien）は Resource Manager の機能で、リーエンが設定されているプロジェクトは削除APIを呼び出しても拒否されます。削除するにはまずリーエンを外す必要があり、意図しない削除に対する保護になります。ラベルやフォルダ移動は分類・整理のための機能で削除を防ぐ力はなく、課金の切り離しはむしろサービス停止を招きます。

正解: C. 必要な権限のみを含むカスタムロール（Custom Role）を作成して付与する

正解の根拠・詳細解説

事前定義ロールで最小権限を満たせない場合は、必要な権限（compute.instances.start、compute.instances.stop、compute.instances.get など）だけを集めたカスタムロールを作成するのがベストプラクティスです。compute.adminやeditorは作成・削除を含む過剰な権限であり、運用ルールや事後検知は技術的な予防にはなりません。viewerでは起動・停止ができません。

正解: A. 従来はプロジェクトに対する編集者（Editor）ロールが自動付与され、権限が過剰になりやすい

正解の根拠・詳細解説

Compute Engineのデフォルトサービスアカウントには、従来プロジェクトの編集者（Editor）ロールが自動的に付与されており、最小権限の原則から見ると過剰です。現在は組織のポリシー constraints/iam.automaticIamGrantsForDefaultServiceAccounts でこの自動付与を無効化でき、ワークロードごとに専用のサービスアカウントを作成して必要最小限のロールだけを与えるのが推奨されます。デフォルトSAの操作も通常どおり監査ログに記録されます。

正解: D. 組織のポリシーで constraints/gcp.resourceLocations を設定する

正解の根拠・詳細解説

組織のポリシーのリスト制約 constraints/gcp.resourceLocations（リソース ロケーションの制限）を使うと、リソースを作成できるリージョンやマルチリージョンをホワイトリスト方式で限定できます。組織やフォルダに設定すれば配下のプロジェクトに継承され、EU外でのリソース作成は作成時点で拒否されます。Cloud Armorはアプリケーションへのリクエスト元IPの制御であり、データの保存場所とは無関係です。

正解: B. Cloud Asset Inventory

正解の根拠・詳細解説

Cloud Asset Inventoryは、組織・フォルダ・プロジェクト配下のアセット（リソースのメタデータとIAMポリシー）を一元的に検索・エクスポートできるサービスです。過去のスナップショットや変更履歴の取得、変更をリアルタイムに通知するフィード（Pub/Sub連携）にも対応します。Cloud Monitoringは指標の監視、Billingはコスト分析が目的で、資産の棚卸しには適していません。

正解: A. IAM Recommender（ロールの推奨）

正解の根拠・詳細解説

Policy Intelligenceの一部であるIAM Recommender（ロールの推奨）は、過去の実際のAPI使用状況を分析し、付与されているが使われていない権限を検出して、より限定的なロールへの変更を推奨します。Policy Troubleshooterは「なぜこのユーザーがアクセスできる／できないのか」を診断する機能、Access TransparencyはGoogleのサポート担当者によるアクセスの記録で、目的が異なります。

正解: B. Policy Troubleshooter

正解の根拠・詳細解説

Policy Troubleshooterは、プリンシパル・リソース・権限の3つを指定すると、階層のどのレベルのどのポリシーが結果に影響しているかを分析し、アクセスが許可／拒否される理由を提示します。継承されたポリシーや条件付きバインディングの評価結果まで確認できるため、権限トラブルの切り分けに最適です。VPCフローログはネットワーク通信、Cloud Traceはレイテンシ分析のための機能です。

正解: C. Google Cloud Directory Sync (GCDS)

正解の根拠・詳細解説

Google Cloud Directory Sync（GCDS）は、LDAPやActive Directoryを信頼できる情報源として、Cloud Identity／Google Workspaceのユーザー、グループ、組織部門を一方向に同期するツールです。同期はディレクトリ側からGoogle側への一方向で、Google側にだけ存在するアカウントは削除される場合があるため設定に注意が必要です。Managed Microsoft ADはGoogle Cloud上でADドメインコントローラを運用するサービスであり、Cloud Identityへの同期ツールではありません。

正解: D. Cloud IdentityでサードパーティIdPをSAML SSOプロファイルとして構成する

正解の根拠・詳細解説

Cloud Identity（またはGoogle Workspace）ではSAML 2.0のサードパーティIdPをSSOプロファイルとして設定でき、ユーザーのログイン時に認証をIdP側へリダイレクトします。これによりパスワードポリシーやMFAを自社IdPに集約できます。Identity Platformは自社アプリのエンドユーザー認証（CIAM）向けのサービスで、従業員のコンソールログインには使いません。IAPは自社アプリへのアクセス制御であり、Google Cloudコンソール自体を保護するものではありません。

正解: B. ホストプロジェクトでネットワークを一元管理し、各チームのプロジェクトをサービスプロジェクトとして接続する

正解の根拠・詳細解説

共有VPCでは、ホストプロジェクトがVPCネットワーク、サブネット、ファイアウォールルールなどを一元管理し、サービスプロジェクトのリソース（VMなど）がそのサブネットを利用します。ネットワーク管理の責務をネットワークチームに集約しつつ、各チームには自プロジェクト内のリソース管理権限だけを与えられるため、職務分掌（Separation of Duties）が実現できます。VPCピアリングは分散管理になり一元的なガバナンスが効きません。

正解: D. Essential Contacts（必須連絡先）

正解の根拠・詳細解説

Essential Contacts（必須連絡先）は、セキュリティ、技術、法務、停止（Suspension）などのカテゴリごとに通知先メールアドレスをリソース階層に登録できる機能です。組織レベルで設定すれば配下に継承され、担当者の異動などで通知が届かなくなる事態を防げます。Cloud Monitoringの通知チャンネルは自分で定義したアラート用で、Googleからのプラットフォーム通知は届きません。

正解: A. IAMポリシーは、プリンシパルの集合とロールを結びつけるバインディングの一覧である

正解の根拠・詳細解説

Google CloudのIAMでは、ロールは権限（例: compute.instances.start）の集まりであり、ポリシーの中の各バインディングが「どのプリンシパル（ユーザー、グループ、サービスアカウント、ドメイン）に、どのロールを付与するか」を定義します。個別の権限を直接プリンシパルに割り当てることはできません。バインディングにはIAM条件（Condition）を付けて、時間や対象リソースで絞り込むこともできます。

正解: C. 個々のユーザーではなくGoogleグループに対してロールを付与する

正解の根拠・詳細解説

IAMのベストプラクティスは、職務ごとのGoogleグループを作り、そのグループにロールを付与することです。人事異動時はグループのメンバーシップを変えるだけで権限が自動的に切り替わり、監査もグループ単位で行えます。全員にeditorを与えるのは最小権限違反であり、ユーザーごとにサービスアカウントやプロジェクトを作る運用はコストが跳ね上がります。

正解: C. 専用アカウントとして最小限の人数に限定し、ハードウェアセキュリティキーによる2段階認証を必須にする

正解の根拠・詳細解説

特権管理者はCloud Identity／Workspaceの最上位アカウントで、組織管理者ロールの付与など極めて強い操作が可能です。人数を最小限に絞り、日常業務用アカウントとは分離し、ハードウェアセキュリティキーによる2段階認証を必須化し、リカバリ情報を安全に保管するのが推奨です。自動化に使う、日常利用するといった運用は、侵害された際の影響が甚大になります。

正解: A. 組織のポリシーで constraints/compute.vmExternalIpAccess を設定する

正解の根拠・詳細解説

組織のポリシー制約 constraints/compute.vmExternalIpAccess は、外部IPを持てるVMインスタンスをホワイトリストで限定（または全面的に拒否）できます。作成時点でブロックされるため、事後検知ではなく予防になります。ファイアウォールは通信の制御であって外部IPの割り当て自体は防げず、Cloud NATは外向き通信の手段を提供するだけで外部IP付与を禁止する機能ではありません。

正解: D. 組織のポリシーは「リソースをどう構成できるか」の制約を定義し、IAMポリシーは「誰がどのリソースに何をできるか」を定義する

正解の根拠・詳細解説

組織のポリシー（Organization Policy Service）は「外部IPを許可するか」「どのリージョンを使えるか」といったリソース構成のガードレールを定義し、実行者が誰であっても一律に適用されます。一方IAMポリシーは、プリンシパルにロールを付与して「誰が何をできるか」を制御します。組織のポリシーは組織・フォルダ・プロジェクトのいずれにも設定でき、下位に継承されます。

正解: B. VPC Service Controls でサービス境界を作成する

正解の根拠・詳細解説

VPC Service Controlsは、Cloud StorageやBigQueryなどのマネージドサービスの周囲に「サービス境界」を作り、境界外のネットワークからのAPIアクセスを遮断してデータの持ち出し（exfiltration）を防ぎます。IAMが「誰が」を制御するのに対し、VPC SCは「どこから」を制御する第二の防御層で、認証情報が漏洩した場合でも境界外からのアクセスはブロックされます。Cloud ArmorはHTTP(S)ロードバランサ向けのWAFで、Storage APIの境界防御には使えません。

正解: A. 境界をドライラン モード（dry run）で構成する

正解の根拠・詳細解説

VPC Service Controlsのドライラン モードでは、境界のルールに違反するリクエストを実際にはブロックせず、監査ログに記録だけします。これにより本番影響なしに「もし適用したら何が遮断されるか」を検証でき、必要なイングレス／エグレスルールを整備してから強制モードに切り替えられます。VPCフローログはVPC内のIPレベルの通信記録で、サービス境界の違反判定は行いません。

正解: B. 境界にイングレスルール（Ingress Policy）を追加する

正解の根拠・詳細解説

イングレスルールは、境界の外にあるプリンシパルやプロジェクトから境界内のリソースへのアクセスを、条件付き（送信元、ID、対象サービス、メソッド）で例外的に許可する仕組みです。エグレスルールは逆に境界内から境界外のリソースへのアクセスを許可するためのものです。BigQueryを境界から外したり相手を同じ境界に入れたりすると、保護範囲が広がりすぎてしまいます。

正解: C. Access Context Manager のアクセスレベル

正解の根拠・詳細解説

Access Context Managerでは、送信元IPレンジ、地域、デバイスポリシー（画面ロック、ストレージ暗号化、OSバージョン、企業所有かなど）、ユーザーIDといった属性から「アクセスレベル」を定義します。このアクセスレベルはIdentity-Aware Proxyの条件やVPC Service Controlsの境界条件で参照でき、コンテキストアウェア アクセスを実現します。VPCファイアウォールはIPとポートしか見ず、デバイスの状態は判定できません。

正解: D. サブネットで限定公開の Google アクセス（Private Google Access）を有効にする

正解の根拠・詳細解説

限定公開のGoogleアクセス（Private Google Access）をサブネット単位で有効にすると、外部IPを持たないVMでもGoogle APIとサービスの外部IPにGoogleの内部ネットワーク経由で到達できます。Cloud NATは任意のインターネット宛て送信を可能にする機能であり、Google APIだけに限定したい場合はPrivate Google Accessのほうが適切です。VPCピアリングは自分のVPC同士を接続する機能で、Google APIへのアクセス手段ではありません。

正解: B. restricted.googleapis.com

正解の根拠・詳細解説

restricted.googleapis.com（199.36.153.4/30）は、VPC Service Controlsをサポートするサービスのみに到達できる制限付き仮想IPで、境界外へのデータ持ち出し経路を減らせます。private.googleapis.com（199.36.153.8/32）はVPC SC非対応のサービスも含めてほとんどのGoogle APIに到達できるため、境界の強度は下がります。DNSで googleapis.com をこのVIPに解決させるプライベートDNSゾーンを構成して使います。

正解: D. Cloud NATを構成する

正解の根拠・詳細解説

Cloud NATはマネージドの送信専用NATで、外部IPを持たないVMがインターネットへ発信できるようにしつつ、外部から開始されるインバウンド接続は一切受け付けません。外部IPを割り当てる方法は攻撃面が広がり管理も煩雑です。限定公開のGoogleアクセスはGoogle APIにしか到達できず、外部のパッケージリポジトリには使えません。

正解: A. 階層型ファイアウォール ポリシー（Hierarchical Firewall Policy）

正解の根拠・詳細解説

階層型ファイアウォールポリシーは組織またはフォルダのレベルで作成し、配下のVPCネットワークに継承されるファイアウォールルールです。上位階層のルールはプロジェクト管理者が変更できないため、組織全体のガードレールとして機能します。各VPCに個別ルールを作る方法はプロジェクト管理者が削除できてしまいます。Cloud ArmorはL7ロードバランサ向けで、VMへのSSHは対象外です。

正解: C. 上り（ingress）はすべて拒否、下り（egress）はすべて許可

正解の根拠・詳細解説

VPCネットワークには変更・削除できない「暗黙のルール」が2つあり、暗黙の上り拒否（implied deny ingress、優先度65535）と暗黙の下り許可（implied allow egress）が適用されます。つまり外部からVMへの通信は明示的に許可しない限り届かず、VMからの外向き通信は既定で許可されます。なお default ネットワークを自動作成した場合は、SSHやICMPを許可する既定のルールが別途追加されます。

正解: C. 拒否される（数値が小さいほうが優先度が高いため）

正解の根拠・詳細解説

VPCファイアウォールルールの優先度は0〜65535の整数で、数値が小さいほど優先度が高くなります。この例では優先度500の拒否ルールが優先度1000の許可ルールより先に評価されるため、TCP 443は拒否されます。作成順は評価に影響しません。運用では優先度の設計を明確にし、ファイアウォールルールロギングで実際の適用状況を確認するのが有効です。

正解: A. ファイアウォール ルール ロギング（Firewall Rules Logging）

正解の根拠・詳細解説

ファイアウォールルールロギングをルール単位で有効にすると、そのルールに一致した接続の記録（送信元・宛先、許可か拒否か、適用ルール名）がCloud Loggingへ出力されます。トラブルシューティングやルールの使用状況の棚卸しに使えます。管理アクティビティログはルールの作成・変更といった設定操作を記録するもので、通信そのものは記録しません。

正解: D. Cloud Armor（事前構成WAFルール）

正解の根拠・詳細解説

Cloud Armorは外部HTTP(S)ロードバランサに適用するWAF／DDoS対策サービスで、OWASP Top 10に対応した事前構成のWAFルール（SQLi、XSS、LFI、RCEなど）を適用できます。VPCファイアウォールはL3/L4のIP・ポート制御しかできず、ペイロード内の攻撃パターンは検査できません。Cloud IDSは侵入検知であり、トラフィックを遮断する製品ではありません。

正解: B. Cloud Armorのレート制限（rate limiting）ポリシーを設定する

正解の根拠・詳細解説

Cloud Armorのレート制限ルールでは、クライアントIPやHTTPヘッダーなどのキーごとに一定時間あたりのリクエスト数のしきい値を設け、超過分をスロットリング（throttle）または一定時間の禁止（ban）にできます。正当なトラフィックは通しつつ乱用だけを抑えられます。Cloud CDNはキャッシュによる負荷軽減はできますが、動的APIへの乱用対策にはなりません。

正解: A. Cloud IDS

正解の根拠・詳細解説

Cloud IDSはPalo Alto Networksの脅威検知エンジンを利用したマネージド侵入検知サービスで、パケットミラーリングでコピーしたトラフィックを解析し、マルウェア、スパイウェア、C2通信などを検知します。あくまで検知（IDS）であり、遮断（IPS）は行いません。VPCフローログはメタデータのみでペイロード検査はできず、Security Health Analyticsは構成ミスの検出が目的です。

正解: B. パケット ミラーリング（Packet Mirroring）

正解の根拠・詳細解説

パケットミラーリングは、指定したVMインスタンスの送受信トラフィックをペイロードごと複製し、内部ロードバランサ配下の収集用インスタンス群へ転送する機能です。IDS/IPSやネットワークフォレンジックの用途に使われます。VPCフローログやファイアウォールログはサンプリングされたメタデータのみで、ペイロードは含まれません。

正解: C. 限定公開クラスタ（Private Cluster）を作成し、承認済みネットワークでコントロールプレーンへのアクセスを制限する

正解の根拠・詳細解説

限定公開クラスタ（Private Cluster）ではノードが内部IPのみを持ち、インターネットから直接到達できません。さらにコントロールプレーンの公開エンドポイントを無効化するか、承認済みネットワーク（control plane authorized networks）で接続元CIDRを限定することで、管理APIへのアクセスも絞り込めます。ノードから外部への通信が必要な場合はCloud NATを併用します。

正解: D. Kubernetes の NetworkPolicy を適用する

正解の根拠・詳細解説

KubernetesのNetworkPolicyは、Podのラベルやネームスペースを条件にPod間（東西）の通信を許可・拒否するリソースで、GKEではネットワークポリシー（CalicoやDataplane V2）を有効化すると利用できます。VPCファイアウォールはノードのIPレベルまでしか見えず、同一ノード上のPod間通信は制御できません。サービスアカウントはAPIの認可の話であり、ネットワーク通信の制御ではありません。

正解: B. Binary Authorization

正解の根拠・詳細解説

Binary Authorizationは、デプロイ時にコンテナイメージへの「証明（Attestation）」を検証し、ポリシーを満たさないイメージの起動をブロックするデプロイ時のセキュリティ制御です。CI/CDで検証を通ったイメージにだけ署名を付けることで、ソフトウェアサプライチェーンの完全性を担保できます。GKE Sandboxは実行時の分離、Shielded GKE Nodesはノードの起動時整合性検証が目的で、イメージの出所は検証しません。

正解: D. GKE Sandbox（gVisor）

正解の根拠・詳細解説

GKE SandboxはgVisorを利用して、コンテナとホストカーネルの間に追加の分離レイヤ（ユーザー空間で動作するカーネル）を挟む機能です。コンテナからのシステムコールはgVisorが仲介するため、カーネル脆弱性を悪用したノードへのエスケープのリスクを大幅に下げられます。Binary Authorizationはデプロイ時の検証、Workload Identityは認証情報の管理で、実行時のカーネル分離は行いません。

正解: A. Shielded VM（セキュアブート、vTPM、整合性モニタリング）

正解の根拠・詳細解説

Shielded VMは、UEFIセキュアブートで署名されたブートコンポーネントのみを起動させ、仮想TPM（vTPM）による測定ブートと整合性モニタリングにより、起動プロセスの改ざんを検知します。整合性の検証に失敗するとCloud Loggingに記録され、アラートを設定できます。Confidential VMは実行中のメモリの暗号化が目的で、ブート整合性の検証とは役割が異なります。

正解: C. Confidential VM（Confidential Computing）

正解の根拠・詳細解説

Confidential VMは、AMD SEVなどのハードウェア機能を用いて「使用中のデータ（data in use）」つまりメモリ上のデータを暗号化し、ハイパーバイザやホストOSからも内容を読み取れないようにします。保存時（at rest）や転送時（in transit）の暗号化はデフォルトで行われますが、メモリ上のデータを守るのはConfidential Computingの領域です。

正解: C. OS Login を有効にする

正解の根拠・詳細解説

OS Loginを有効にすると、LinuxのSSHアクセスがGoogleアカウントとIAMロール（roles/compute.osLogin、roles/compute.osAdminLogin）に紐付けられ、鍵の配布・管理が不要になります。ユーザーを無効化すればSSHアクセスも即座に失われ、2段階認証との連携やログイン監査も可能です。メタデータへの鍵登録は分散管理となり、退職者の鍵の削除漏れが発生しやすくなります。

正解: A. SSLポリシー（SSL Policy）をターゲットプロキシに適用する

正解の根拠・詳細解説

SSLポリシーでは最小TLSバージョンとプロファイル（COMPATIBLE、MODERN、RESTRICTED、CUSTOM）を指定し、ターゲットHTTPS/SSLプロキシに適用することで許可する暗号スイートを制御できます。RESTRICTEDプロファイルはコンプライアンス要件が厳しい環境向けです。証明書の再発行はTLSバージョンの制御とは関係がありません。

正解: D. Certificate Authority Service (CA Service)

正解の根拠・詳細解説

Certificate Authority Service（CA Service）は、プライベート認証局をマネージドで構築・運用できるサービスで、CA階層の作成、証明書テンプレート、発行ポリシー、失効に対応します。CAの秘密鍵はCloud KMSやCloud HSMで保護されます。GoogleマネージドSSL証明書はロードバランサ向けの公開証明書で、内部サービス用のプライベート証明書発行には使えません。

正解: B. DNSSEC

正解の根拠・詳細解説

DNSSECはDNS応答にデジタル署名を付与し、リゾルバが応答の真正性と完全性を検証できるようにする仕組みです。Cloud DNSの公開ゾーンでは設定一つで有効化でき、レジストラ側にDSレコードを登録することで信頼の連鎖が完成します。これによりキャッシュポイズニングや中間者による応答の改ざんを検知できます。

正解: A. Dedicated Interconnect を利用し、必要に応じて MACsec for Cloud Interconnect を有効にする

正解の根拠・詳細解説

Dedicated Interconnect（またはPartner Interconnect）は、オンプレミスとGoogleのネットワークを専用線で接続する方式で、インターネットを経由しません。物理回線上の通信をさらに暗号化したい場合は MACsec for Cloud Interconnect（レイヤ2の暗号化）や、HA VPN over Cloud Interconnect（IPsec）を組み合わせます。VPCピアリングはGoogle Cloud上のVPC同士を接続する機能で、オンプレミス接続には使えません。

正解: B. VPC フローログ（VPC Flow Logs）

正解の根拠・詳細解説

VPCフローログはサブネット単位で有効化し、VMが送受信したネットワークフローのサンプルをメタデータ（IP、ポート、プロトコル、バイト数、RTTなど）としてCloud Loggingに記録します。ネットワークフォレンジック、通信の可視化、コスト分析に利用でき、BigQueryへエクスポートして分析するのが一般的です。ペイロードは含まれません。

正解: C. Private Service Connect

正解の根拠・詳細解説

Private Service Connectは、コンシューマ側VPC内のプライベートIPアドレス（エンドポイント）を通じて、Google APIやサードパーティ／自社のマネージドサービスへ接続できる仕組みです。VPCピアリングと違ってIPレンジの重複や推移的ピアリングの制約を受けず、接続の方向性も明確に制御できます。共有VPCは組織内でネットワークを共有する仕組みであり、サービス接続の方式ではありません。

正解: D. 組織のポリシーで constraints/compute.restrictVpcPeering を設定する

正解の根拠・詳細解説

組織のポリシー制約 constraints/compute.restrictVpcPeering は、VPCピアリングを確立できる相手のネットワークを組織・フォルダ・プロジェクト単位で許可リスト方式に限定します。これにより、承認されていない外部組織のVPCとの接続を予防的にブロックできます。ファイアウォールポリシーはトラフィックの制御であり、ピアリング関係の確立自体は防げません。

正解: B. データはデータ暗号鍵（DEK）で暗号化され、そのDEKはさらに鍵暗号鍵（KEK）で暗号化されて保管される

正解の根拠・詳細解説

Google Cloudの保存時暗号化は、データをデータ暗号鍵（DEK）で暗号化し、そのDEK自体を鍵暗号鍵（KEK）で暗号化して保管する「エンベロープ暗号化」を採用しています。KEKはKMSの内部で管理され、鍵のローテーションはKEKを入れ替えるだけで済むため効率的です。既定ではGoogleが鍵を管理しますが、CMEKを使えばKEKを顧客側のCloud KMS鍵に置き換えられます。

正解: D. 顧客管理の暗号鍵（CMEK）を Cloud KMS で作成して使用する

正解の根拠・詳細解説

CMEK（顧客管理の暗号鍵）は、Cloud KMSで顧客が作成・管理する鍵をGoogle Cloudサービスの暗号化に使う方式です。鍵のローテーション、無効化、破棄を自分の裁量で行え、鍵の使用履歴も監査ログで追跡できます。鍵を無効にすると、その鍵で暗号化されたデータにアクセスできなくなります。CSEKはリクエストごとに鍵素材を渡す方式でBigQueryでは利用できず、対応サービスも限定的です。

正解: A. Cloud External Key Manager (Cloud EKM)

正解の根拠・詳細解説

Cloud External Key Manager（Cloud EKM）は、対応する外部の鍵管理パートナーに保管された鍵を、Cloud KMSの鍵として参照して利用する仕組みです。鍵素材はGoogleのインフラに保存されず、外部側で鍵の提供を止めればデータへのアクセスも遮断できます。Cloud HSMは鍵をGoogleのHSM内で管理する方式で、鍵素材はGoogle Cloud内に留まります。

正解: C. Cloud HSM の保護レベルで鍵を作成する

正解の根拠・詳細解説

Cloud KMSでは鍵の保護レベルとして SOFTWARE、HSM、EXTERNAL、EXTERNAL_VPC を選べます。保護レベルにHSM（Cloud HSM）を指定すると、鍵はFIPS 140-2 レベル3認証済みのHSMクラスタ内で生成・保管され、鍵素材がHSM外に出ることはありません。APIの使い方は通常のKMS鍵と同じで、既存のアプリケーションをほぼ変更せずに要件を満たせます。

正解: C. 鍵に自動ローテーション期間を設定し、新しい鍵バージョンを自動生成させる

正解の根拠・詳細解説

Cloud KMSの対称鍵には自動ローテーション期間を設定でき、期間が来ると新しい鍵バージョンが生成されて「プライマリ」になります。以降の暗号化は新バージョンで行われ、既存データの復号には古いバージョンが引き続き使われるため、再暗号化なしで安全に運用できます。鍵バージョンの鍵素材を上書きすることはできず、鍵を削除すると既存データが復号できなくなります。

正解: A. 破棄はまず「破棄をスケジュール済み」状態になり、既定では24時間の猶予期間中に復元できる

正解の根拠・詳細解説

Cloud KMSで鍵バージョンの破棄をリクエストすると、まず「破棄をスケジュール済み（DESTROY_SCHEDULED）」状態になり、既定では24時間の猶予期間が設けられます（鍵の作成時に1日〜120日の範囲で設定可能）。この期間中であれば復元（restore）でき、誤操作からの回復が可能です。猶予期間が過ぎると鍵素材は完全に消去され、その鍵で暗号化されたデータは二度と復号できません。

正解: D. roles/cloudkms.cryptoKeyEncrypterDecrypter

正解の根拠・詳細解説

roles/cloudkms.cryptoKeyEncrypterDecrypter は暗号化と復号の操作のみを許可し、鍵の作成・破棄・IAM変更といった管理操作はできません。一方 roles/cloudkms.admin は鍵の管理はできますが暗号化・復号の権限は含まれておらず、この2つを別々のプリンシパルに与えることで職務分掌が成立します。ownerは全権限を持つため分離の意味がなくなります。

正解: B. Secret Manager

正解の根拠・詳細解説

Secret Managerは、パスワード、APIキー、証明書などの機密文字列を保存・バージョン管理するためのマネージドサービスです。保存時は自動的に暗号化され（CMEKにも対応）、IAMでシークレット単位のアクセス制御ができ、アクセスは監査ログに記録されます。Cloud KMSは鍵管理のサービスであり、シークレットそのものの保管とバージョニングにはSecret Managerが適切です。メタデータやバケットへの平文保存は権限管理と監査が不十分です。

正解: A. 新しいシークレット バージョンを追加し、アプリケーションの参照先を切り替えてから旧バージョンを無効化する

正解の根拠・詳細解説

Secret Managerのシークレット バージョンはイミュータブル（作成後に値を変更できない）で、更新は新しいバージョンの追加として行います。新バージョンを追加し、アプリケーションが新しい値を使えることを確認してから旧バージョンを無効化（disable）し、問題がなければ破棄するのが安全な手順です。無効化しておけば問題発生時にすぐ有効化して切り戻せます。

正解: B. Sensitive Data Protection（Cloud DLP）の検査ジョブ

正解の根拠・詳細解説

Sensitive Data Protection（旧称 Cloud DLP）は、150種類以上の組み込みinfoType検出器（CREDIT_CARD_NUMBER、EMAIL_ADDRESS、PERSON_NAMEなど）を使って、Cloud Storage、BigQuery、Datastoreの中の機密データを検査できます。検査ジョブをスケジュール実行し、結果をSecurity Command CenterやPub/Subへ送って対応を自動化することも可能です。ライフサイクル管理はオブジェクトの保存期間の制御であり、内容の検査は行いません。

正解: C. Sensitive Data Protection の決定論的暗号化（トークン化）による仮名化

正解の根拠・詳細解説

Sensitive Data Protectionの匿名化（de-identification）では、決定論的暗号化（CryptoDeterministicConfig）やフォーマット保持暗号化を使ったトークン化が利用できます。同じ入力値は常に同じトークンになるため、参照整合性を保ったまま分析でき、必要であれば鍵を使って元の値へ再識別（re-identify）することも可能です。固定文字列のマスキングや削除では、顧客ごとの紐付けができなくなります。

正解: D. ポリシータグによる列レベルのアクセス制御（Column-level security）

正解の根拠・詳細解説

BigQueryの列レベルのセキュリティでは、タクソノミーで定義したポリシータグを列に付与し、そのポリシータグに対して「きめ細かい読み取り」の権限を持つプリンシパルだけが列を参照できるようにします。権限のないユーザーがその列を含むクエリを実行するとエラーになります。テーブル単位のIAMでは列ごとの制御ができず、エクスポートによる手作業は運用として現実的ではありません。

正解: B. 均一なバケットレベルのアクセス（Uniform bucket-level access）を有効にする

正解の根拠・詳細解説

均一なバケットレベルのアクセスを有効にすると、オブジェクト単位のACLが無効化され、アクセス制御はバケットに設定したIAMポリシーだけで決まります。ACLの設定漏れによる意図しない公開を防ぎ、権限の把握も容易になります。きめ細かい管理は逆にACLを併用する設定で、公開範囲の管理が複雑になります。

正解: D. 組織のポリシーで constraints/storage.publicAccessPrevention を適用する

正解の根拠・詳細解説

公開アクセスの防止（Public Access Prevention）は、バケット単位でも設定できますが、組織のポリシー制約 constraints/storage.publicAccessPrevention として組織やフォルダに適用すると、配下のすべてのバケットで allUsers／allAuthenticatedUsers への公開が一律に禁止され、個々の管理者が解除できなくなります。ラベルは分類のためのメタデータで、アクセス制御の効果はありません。

正解: A. 有効期限付きの署名付きURL（Signed URL）を発行する

正解の根拠・詳細解説

署名付きURL（Signed URL）は、サービスアカウントの鍵で署名された有効期限付きのURLで、Googleアカウントを持たない相手でも指定した操作（GET/PUTなど）を期限内だけ実行できます。バケットの公開やサービスアカウントキーの送付は範囲が広すぎ、期限もないため不適切です。allAuthenticatedUsersは「Googleアカウントを持つ全員」を意味し、社外の任意のユーザーにも開いてしまいます。

正解: C. バケットに保持ポリシーを設定し、バケットロック（Bucket Lock）で保持ポリシーをロックする

正解の根拠・詳細解説

Cloud Storageの保持ポリシーは、オブジェクトが指定期間を経過するまで削除・上書きできないようにします。さらにバケットロックを適用すると保持ポリシー自体が恒久的にロックされ、期間の短縮や解除がプロジェクトオーナーであってもできなくなるため、WORM（Write Once Read Many）要件やコンプライアンス監査に対応できます。ストレージクラスの変更はコスト最適化の話で、改ざん防止にはなりません。

正解: C. オブジェクトのバージョニングを有効にする

正解の根拠・詳細解説

オブジェクトのバージョニングを有効にすると、オブジェクトの上書きや削除の際に以前の世代が「非現行バージョン」として保持され、必要に応じて復元できます。世代が増え続けるとコストがかかるため、ライフサイクルルールで一定期間後に非現行バージョンを削除する運用と組み合わせるのが一般的です。バケットロックは削除の禁止であり、既に削除されたデータの復元機能ではありません。

正解: A. Compute Engineのサービス エージェントに、その鍵に対する暗号化・復号の権限を付与する必要がある

正解の根拠・詳細解説

CMEKを使う場合、対象サービスのサービス エージェント（例: service-<project-number>@compute-system.iam.gserviceaccount.com）に roles/cloudkms.cryptoKeyEncrypterDecrypter を付与しないと、サービスがその鍵を使えず操作が失敗します。またKMS鍵はリソースと同じロケーション（またはそれを含むマルチリージョン）に置く必要があります。CMEKのディスクからスナップショットは作成でき、スナップショットも同じ鍵で保護されます。

正解: D. BigQuery の AEAD 暗号化関数（AEAD.ENCRYPT / AEAD.DECRYPT_STRING）

正解の根拠・詳細解説

BigQueryのAEAD関数を使うと、キーセット（KEYS.NEW_KEYSET など）で生成した鍵を用いて列の値をSQL内で暗号化・復号できます。鍵をCloud KMSで保護し、復号に必要な鍵へのアクセスをIAMで制限すれば、テーブルを読める人でも鍵がなければ値を復元できない、いわゆるアプリケーションレイヤの暗号化を実現できます。承認済みビューはアクセス制御の仕組みであり、値そのものは暗号化しません。

正解: B. Googleの物理的な境界を越えるトラフィックは既定で暗号化され、ユーザーとの通信もTLSで保護される

正解の根拠・詳細解説

Google Cloudでは、ユーザーとGoogleのフロントエンド間はTLSで保護され、Googleが物理的に制御する境界の外を通るサービス間トラフィックも既定で認証・暗号化されます（ALTSなどの仕組み）。CMEKの設定有無とは無関係です。さらに強い要件がある場合は、アプリケーション層でのmTLSやVPN/Interconnectの暗号化オプションを追加で検討します。

正解: A. 使用しているCloud KMSの鍵バージョンを無効化する

正解の根拠・詳細解説

CMEKで暗号化されたデータは、鍵バージョンを無効化（disable）するとその鍵で復号できなくなるため、データへの実質的なアクセスを即座に遮断できます。これはCMEKを使う大きな利点の一つで、後から鍵を再度有効化すればアクセスを復旧できます。IAMの削除も有効な手段ですが、対象が多い場合は漏れが生じやすく、鍵の無効化のほうが確実です。

正解: B. プロジェクト内にキーリング（Key Ring）を作成し、その中に鍵、さらに鍵の中に鍵バージョンが存在する

正解の根拠・詳細解説

Cloud KMSでは、プロジェクト配下の指定したロケーション（グローバル、リージョン、マルチリージョン）にキーリングを作成し、その中に暗号鍵（CryptoKey）、さらに各鍵の中に鍵バージョン（CryptoKeyVersion）が存在します。IAMポリシーはキーリングや鍵のレベルで設定でき、キーリングは作成後に削除やロケーション変更ができない点にも注意が必要です。

正解: C. 顧客提供の暗号鍵（CSEK）

正解の根拠・詳細解説

CSEK（Customer-Supplied Encryption Keys）は、APIリクエストのたびに顧客がAES-256の鍵素材を提供する方式で、Googleは鍵をメモリ上でのみ使用し永続保存しません。その代わり鍵を紛失するとデータを復元できず、対応サービスもCloud StorageやCompute Engineの一部に限られます。鍵の管理負担が大きいため、多くの要件はCMEKで満たすことが推奨されます。

正解: D. Identity-Aware Proxy (IAP)

正解の根拠・詳細解説

Identity-Aware Proxy（IAP）は、アプリケーションの手前でユーザーの認証と認可を行うレイヤで、roles/iap.httpsResourceAccessor を持つプリンシパルだけがバックエンドに到達できます。ネットワーク境界ではなくIDを信頼の基点とするBeyondCorpの考え方に基づくため、VPNなしで社内アプリを安全に公開できます。VPC Service Controlsはマネージドサービスのデータ境界を守る機能で、Webアプリのユーザー認証は行いません。

正解: B. IAP TCP転送（IAP for TCP forwarding）を使用する

正解の根拠・詳細解説

IAPのTCP転送を使うと、Googleのインフラを経由して外部IPを持たないVMへSSHやRDPで接続できます。接続には roles/iap.tunnelResourceAccessor が必要で、アクセスは監査ログに記録されます。ファイアウォールでは 35.235.240.0/20（IAPの転送元レンジ）からのTCP 22のみを許可すればよく、インターネットにSSHポートを公開せずに済みます。シリアルコンソールの有効化はむしろリスクを増やす操作です。

正解: D. IAM条件（Condition）で request.time による有効期限を設定してロールを付与する

正解の根拠・詳細解説

IAM条件を使うと、`request.time < timestamp("2025-12-31T23:59:59Z")` のような式を付けてロールを付与でき、期限を過ぎると自動的にそのバインディングは効力を失います。剥奪の手作業や忘れが発生しないため、期間限定アクセスの管理に最適です。手動削除やリマインダーは人的ミスに依存し、監査上も弱い運用になります。

正解: A. リソース名を条件にしたIAM条件付きバインディングを使う

正解の根拠・詳細解説

IAM条件では `resource.name.startsWith("projects/_/buckets/team-a-")` のようにリソース名の属性を条件式に使えるため、命名規則に沿った一群のリソースだけにロールを限定できます。バケットが増えても条件が自動的に適用されるため運用が破綻しません。プロジェクト全体への付与は最小権限違反であり、IAM条件でラベルを直接評価することはできません。

正解: C. 基本ロールは非常に広範な権限を持つため、本番環境では事前定義ロールやカスタムロールへの置き換えが推奨される

正解の根拠・詳細解説

基本ロール（オーナー、編集者、閲覧者）はGoogle CloudのIAM登場以前からある粗い粒度のロールで、プロジェクト内のほぼすべてのサービスに対する広範な権限を含みます。最小権限の原則に反するため、本番環境ではサービスごとの事前定義ロール、必要に応じてカスタムロールへの置き換えが推奨されます。編集者はデータの読み書きも可能で、影響範囲は非常に大きくなります。

正解: C. セキュリティ キー（FIDO/WebAuthn）を必須にする

正解の根拠・詳細解説

セキュリティキー（FIDO U2F/WebAuthn）は、認証時にアクセス先のドメインを暗号学的に検証するため、偽サイトへ認証情報を入力させるフィッシングに耐性があります。SMSや音声によるコードはSIMスワップや中間者フィッシングで盗まれる可能性があり、強度は劣ります。パスワードの強化だけでは、フィッシングで直接入力させられる攻撃を防げません。

正解: A. 管理コンソールで2段階認証プロセスの適用ポリシーを組織部門やグループ単位で有効にする

正解の根拠・詳細解説

2段階認証プロセスの強制は、Cloud Identity／Google Workspaceの管理コンソールで設定するセキュリティ設定であり、組織部門（OU）やグループ単位で適用できます。段階的な展開のために登録猶予期間を設けたり、対象の認証方式（セキュリティキーのみ等）を限定したりすることも可能です。Google CloudのIAMや組織のポリシーは、リソースへの認可を扱うレイヤであり、ログイン時の認証方式は制御しません。

正解: D. Cloud Identity の管理コンソールで Google Cloud セッション継続時間を設定する

正解の根拠・詳細解説

Cloud Identity／Google Workspaceの管理コンソールでは「Google Cloud のセッション継続時間」を設定でき、指定時間が経過するとGoogle CloudコンソールやgcloudコマンドなどのGoogle Cloudサービスへのアクセス時に再認証が求められます。IAM条件はロール付与の有効期限であり、ログインセッションの長さとは別の概念です。

正解: B. Access Context Manager のアクセスレベルを作成し、IAPのコンテキストアウェア アクセス条件として適用する

正解の根拠・詳細解説

コンテキストアウェア アクセスでは、Access Context Managerでデバイスポリシー（企業所有、画面ロック、ディスク暗号化、OSバージョンなど）やIPレンジ、地域を条件にしたアクセスレベルを作り、それをIAPのIAMバインディングの条件として適用します。これによりIDに加えてアクセス元のコンテキストを評価するゼロトラストなアクセス制御が実現します。SSLポリシーは暗号スイートの制御でありデバイスの状態は判定しません。

正解: A. Cloud Identity の管理コンソールのパスワード管理ポリシー

正解の根拠・詳細解説

パスワードの最小文字数、強度の要件、再利用の禁止、有効期限などは、Cloud Identity／Google Workspaceの管理コンソールにあるパスワード管理の設定で行い、組織部門単位で適用できます。Google CloudのIAMや組織のポリシーはリソースへの認可を扱うもので、アカウントのパスワード要件は管理しません。なおサードパーティIdPでSSOしている場合は、パスワードポリシーはIdP側の設定に従います。

正解: B. Identity Platform

正解の根拠・詳細解説

Identity PlatformはCIAM（顧客向けID管理）のためのサービスで、メール／パスワード、電話番号、Google・Facebook・Appleなどのソーシャルログイン、SAML/OIDCの企業IdP連携、多要素認証などを自社アプリに組み込めます。Cloud Identityは従業員のIDを管理するサービス、IAPは社内アプリへのアクセス制御、Workload Identity 連携はワークロードの認証で、いずれもエンドユーザー向けではありません。

正解: C. APIキーにアプリケーション制限（パッケージ名や署名、リファラー、IPなど）とAPI制限を設定する

正解の根拠・詳細解説

APIキーは呼び出し元プロジェクトの識別にすぎず、認可には使えないため、必ずアプリケーション制限（HTTPリファラー、IPアドレス、Androidのパッケージ名と署名、iOSのバンドルID）とAPI制限（使用できるAPIの限定）を設定して悪用時の被害を限定します。エンコードやコメントへの移動は難読化にすらならず、サービスアカウントキーの埋め込みははるかに深刻な情報漏洩になります。

正解: D. 呼び出し元のサービスアカウントに roles/run.invoker を付与し、IDトークンを付けて呼び出す

正解の根拠・詳細解説

Cloud Runでは、呼び出される側のサービスに対して呼び出し元のサービスアカウントに roles/run.invoker を付与し、呼び出し時にそのサービスアカウントのIDトークン（対象サービスのURLをaudienceに指定）をAuthorizationヘッダーに付けるのが標準的な構成です。Cloud Runがトークンを検証するため、アプリケーション側で認証ロジックを実装する必要がありません。allUsersへの公開＋共有シークレットは、シークレット漏洩時に無防備になります。

正解: B. 関数の上り（ingress）設定を「内部トラフィックのみ許可」に変更する

正解の根拠・詳細解説

Cloud Functions（およびCloud Run）には上り（ingress）設定があり、「内部トラフィックのみを許可」を選ぶとVPC内部や共有VPCからのリクエストのみが到達でき、インターネットからの直接呼び出しは拒否されます。IAM（roles/cloudfunctions.invoker）による認可と併用することで、ネットワークとIDの二重の防御になります。メモリやタイムアウトはアクセス制御とは無関係です。

正解: D. Google グループのメンバーシップに有効期限を設定する

正解の根拠・詳細解説

Google グループでは、メンバーシップに有効期限を設定でき、期限を過ぎるとユーザーは自動的にグループから外れます。グループにIAMロールが付与されている場合、メンバーシップの失効に伴って権限も自動的に失われるため、一時的なアクセスの棚卸し忘れを防げます。グループの削除・再作成は他の権限にも影響し、運用として現実的ではありません。

正解: A. Workforce Identity 連携（Workforce Identity Federation）

正解の根拠・詳細解説

Workforce Identity 連携は、外部のIdP（OIDCまたはSAML）で認証された「人間のユーザー」に対して、Cloud Identityアカウントを作らずにGoogle Cloudコンソールやgcloudへのアクセスを許可する仕組みです。IAMではプリンシパル セット（principalSet）として参照してロールを付与します。Workload Identity 連携はアプリケーションやワークロード向けの同種の仕組みで、人間のユーザーには使いません。

正解: C. 拒否ポリシーに一致すると、許可ポリシーの内容にかかわらずリクエストは拒否される

正解の根拠・詳細解説

IAMではまず拒否ポリシーが評価され、リクエストが拒否ルールに一致した場合は、どれだけ強い許可ロールを持っていてもリクエストは拒否されます。拒否ルールに一致しない場合に許可ポリシーが評価されます。さらに組織のポリシー制約は、IAMで許可されている操作であってもリソース構成の観点からブロックし得るため、両者は独立したガードレールとして機能します。

正解: C. データアクセス監査ログ（Data Access Logs）を明示的に有効化する

正解の根拠・詳細解説

データアクセス監査ログはリソースの読み取りやデータの参照を記録しますが、量が膨大になるためBigQueryなど一部を除いて既定では無効です。IAM監査構成（Audit Config）でサービスごとにDATA_READ／DATA_WRITEを有効化する必要があり、有効化すると保存コストが発生します。管理アクティビティログは構成変更の記録で、オブジェクトの読み取りは含まれません。

正解: A. 組織レベルで集約シンク（Aggregated Sink）を作成する

正解の根拠・詳細解説

集約シンク（Aggregated Sink）は組織またはフォルダのレベルで作成し、配下のすべてのプロジェクトのログを1つの宛先（Cloud Storage、BigQuery、Pub/Sub、ログバケット）へまとめてルーティングできます。新しいプロジェクトが追加されても自動的に対象となるため、設定漏れが起きません。各プロジェクトでの個別設定は、漏れや改変のリスクが残ります。

正解: D. ログバケットの保持期間を設定し、バケットをロック（locked）する

正解の根拠・詳細解説

Cloud Loggingのログバケットは保持期間を最大3650日まで設定でき、さらにバケットをロックすると保持期間の短縮やバケットの削除ができなくなります。これにより、特権を持つ管理者でもログを消せない改ざん耐性のある保管が実現します。保持期間の設定だけでは、後から短縮したり削除したりできてしまいます。

正解: B. 400日

正解の根拠・詳細解説

_Required ログバケットには管理アクティビティ監査ログ、システムイベント監査ログ、Access Transparency ログが保存され、保持期間は400日固定で変更も削除もできません。一方、_Default バケットのデフォルト保持期間は30日で、こちらは変更可能です。それ以上の長期保管が必要な場合は、シンクでCloud StorageやBigQuery、保持期間を延長したログバケットへエクスポートします。

正解: A. SetIamPolicy を検出するログベースの指標を作成し、Cloud Monitoringのアラートポリシーで通知する

正解の根拠・詳細解説

管理アクティビティ監査ログには SetIamPolicy などのメソッド名が記録されるため、`protoPayload.methodName="SetIamPolicy"` のようなフィルタでログベースの指標（カウンタ）を作成し、その指標に対するCloud Monitoringのアラートポリシーを設定すれば、変更発生時に通知チャンネル（メール、Slack、PagerDutyなど）へ即座に通知できます。ログをPub/Subへ流して自動対応と組み合わせることも可能です。

正解: B. Access Transparency ログ

正解の根拠・詳細解説

Access Transparency は、Googleの担当者が顧客のコンテンツにアクセスした際に、アクセス者の所在地、アクセス理由（サポートケース番号など）、対象リソース、時刻を記録するログです。通常の監査ログが「顧客側の操作」を記録するのに対し、Access Transparency は「Google側の操作」を可視化します。特定のサポートプラン以上で利用でき、Access Approvalと組み合わせると事前承認も可能になります。

正解: C. Access Approval

正解の根拠・詳細解説

Access Approvalを有効にすると、Googleの担当者が顧客コンテンツへアクセスする前に承認リクエストが顧客側へ送られ、明示的に承認するまでアクセスがブロックされます（緊急時の一部の例外を除く）。Access Transparencyは事後のログ記録であり、事前の承認は行いません。両者は組み合わせて使うことで、Google側アクセスの統制と可視化が実現します。

正解: D. Event Threat Detection

正解の根拠・詳細解説

Event Threat Detection は、Cloud Audit Logs、VPCフローログ、Cloud DNSログなどをリアルタイムに解析し、ブルートフォースSSH、マルウェアや暗号通貨マイニングに関連する通信、異常なIAM付与、データ持ち出しの兆候などの脅威を検知してSecurity Command Centerにfindingを生成します。Security Health Analyticsは構成ミスの検出、Web Security Scannerはアプリケーションの脆弱性スキャンで、目的が異なります。

正解: B. Container Threat Detection

正解の根拠・詳細解説

Container Threat Detection は、GKEノード上のカーネルレベルの計測により、実行中のコンテナで発生した不審なバイナリやライブラリの実行、リバースシェル、権限昇格などの実行時（ランタイム）の脅威を検知します。Binary Authorizationはデプロイ前の検証、脆弱性スキャンはイメージ内の既知の脆弱性の検出であり、いずれも実行中の挙動は監視しません。

正解: D. Web Security Scanner

正解の根拠・詳細解説

Web Security Scanner は、App Engine、Compute Engine、GKEでホストしているWebアプリケーションをクロールしてリンクやフォームを操作し、XSS、混在コンテンツ、脆弱性のあるライブラリ、平文で送信されるパスワードなどを検出します。テスト環境で実行するのが推奨され、結果はSecurity Command Centerのfindingとして表示されます。Cloud IDSはネットワークトラフィックの検査で、アプリの脆弱性診断は行いません。

正解: A. VM Threat Detection

正解の根拠・詳細解説

VM Threat Detection は、ハイパーバイザのレベルで実行中VMのメモリをスキャンし、暗号通貨マイニングソフトウェアやカーネルモードのルートキットなどを検知します。ゲストOS内にエージェントを導入する必要がないため、性能への影響が小さく、攻撃者に検知機構を無効化されにくいという利点があります。Container Threat DetectionはGKEのコンテナが対象です。

正解: C. Standardでも一部のSecurity Health Analyticsの検出項目やアセット表示は利用できるが、Event Threat Detection などの高度な脅威検知はPremium以上で提供される

正解の根拠・詳細解説

Security Command Center の Standard ティアでは、アセットの表示や Security Health Analytics の一部の検出項目、Web Security Scanner のカスタムスキャンなどが無料で利用できます。Event Threat Detection、Container Threat Detection、VM Threat Detection、コンプライアンスレポート、攻撃経路の分析といった高度な機能は Premium 以上のティアで提供されます。

正解: C. SCCの通知設定でfindingをPub/Subへ送り、Cloud FunctionsやワークフローでSIEM連携と自動修復を実行する

正解の根拠・詳細解説

Security Command Centerでは、フィルタ条件を指定した通知構成を作成して、findingの発生・更新をPub/Subトピックへリアルタイムに配信できます。そこからCloud Functions、Cloud Run、Workflowsなどを起動して、SIEMへの転送、チケット起票、公開バケットの非公開化といった自動修復を実装するのが一般的なパターンです。手動確認やCSVエクスポートは対応が遅れ、運用も属人的になります。

正解: A. ミュート ルール（Mute Rule）を作成して該当するfindingを自動的にミュートする

正解の根拠・詳細解説

ミュート ルールを使うと、フィルタ条件に一致するfindingを自動的にミュート状態にでき、デフォルトのビューから除外しつつ記録自体は保持されます。誤検知や許容済みリスクを整理しても監査証跡が残る点が重要です。検出項目自体を無効化すると、他の本当に問題のあるリソースの検知も失われてしまいます。

正解: D. Google Security Operations（Chronicle）

正解の根拠・詳細解説

Google Security Operations（旧Chronicle）は、大量のセキュリティログを正規化して長期間（既定で1年程度）保持し、脅威インテリジェンスと突き合わせた検知ルール（YARA-L）や高速な検索による脅威ハンティング、SOAR機能によるインシデント対応の自動化を提供するクラウドネイティブなSIEM/SOARです。Cloud Monitoringは可用性・性能監視のためのサービスで、脅威分析基盤ではありません。

正解: B. 永続ディスクのスナップショットを取得し、ファイアウォールやネットワークタグで通信を遮断してからメモリと状態を保全する

正解の根拠・詳細解説

初動対応では、証拠の保全と封じ込めを両立させることが重要です。永続ディスクのスナップショットを取得して調査用のコピーを確保し、ファイアウォールルールやネットワークタグの変更で通信を遮断して被害の拡大を止めます。再起動やインスタンスの削除は、メモリ上の証拠や攻撃の痕跡を失わせてしまうため、フォレンジックの観点では避けるべきです。

正解: A. 該当するキーを直ちに削除し、そのサービスアカウントの監査ログで不正利用の有無を調査する

正解の根拠・詳細解説

流出したサービスアカウントキーは即座に削除（無効化）し、そのキーが有効だった期間の監査ログを調査して不正なAPI呼び出しやデータアクセスがなかったかを確認します。リポジトリを非公開にしてもすでに取得された可能性は消えず、キーは有効なままです。恒久対策としては、Workload Identity 連携や権限借用へ移行し、組織のポリシーでキー作成自体を禁止することが有効です。

正解: B. Assured Workloads

正解の根拠・詳細解説

Assured Workloads は、FedRAMP、CJIS、IL4、EU/日本などのリージョン別要件といったコンプライアンス体制ごとに、データの保存場所の制限、サポート担当者の所在地・審査要件、暗号化要件などを自動的に適用するフォルダを作成できるサービスです。要件から逸脱した構成はモニタリングされ違反として通知されます。VPC Service Controlsはデータ境界の制御であり、人員要件までは扱いません。

正解: C. Compliance Reports Manager から該当する監査レポートをダウンロードする

正解の根拠・詳細解説

Google CloudのISO/IEC認証、SOC 1/2/3レポート、PCI DSS証明書などの第三者監査文書は、Compliance Reports Manager（コンプライアンス レポート マネージャー）から利用者が直接ダウンロードできます。これらはGoogleが責任を負う範囲についての証明であり、利用者自身の設定・運用の適合性は別途、自社で監査対応する必要がある点に注意します。

正解: D. IAMポリシーの設計、ゲストOSのパッチ適用、アプリケーションのセキュアな実装

正解の根拠・詳細解説

責任共有モデルでは、Googleが物理施設、ハードウェア、ネットワークインフラ、ハイパーバイザなど「クラウドのセキュリティ」を担い、顧客はIAMの設計、データの分類と保護、ゲストOSやアプリケーションのパッチとセキュアな実装など「クラウドにおけるセキュリティ」を担います。マネージドサービスを使うほど顧客の責任範囲は小さくなり、IaaSでは大きくなります。

正解: B. 除外フィルタで低優先度のアプリケーションログのみを除外し、監査ログは除外しない

正解の根拠・詳細解説

Cloud Loggingではシンクに除外フィルタを設定して、特定のログエントリの取り込み（保存）を除外できます。ただし監査ログ、特に管理アクティビティ監査ログは無効化できず、コンプライアンスや調査に不可欠なため除外すべきではありません。_Required バケットの保持期間は400日で固定されており変更できません。

正解: D. 専用のログ用プロジェクトを作り、集約シンクでログを集約し、閲覧権限をセキュリティチームに限定する

正解の根拠・詳細解説

監査ログは、運用担当者が権限を持つプロジェクトとは分離した専用のログプロジェクトへ集約シンクで集め、そのプロジェクトのIAMをセキュリティチームに限定するのがベストプラクティスです。これにより、侵害されたアカウントや内部不正によるログの削除・改ざんを防ぎます。データアクセスログの閲覧には roles/logging.privateLogViewer が必要である点も、権限設計で考慮します。

正解: A. ログバケットでログ分析（Log Analytics）を有効にし、SQLでクエリする

正解の根拠・詳細解説

ログ分析（Log Analytics）を有効にしたログバケットでは、BigQueryのエンジンを利用してSQLでログを直接クエリでき、リンクされたデータセットを通じて他のBigQueryテーブルと結合した分析も可能です。ログエクスプローラのフィルタは条件による絞り込みには適していますが、集計や結合を伴う分析には向いていません。