受験体験記（Google Cloud Professional Cloud Security Engineer）

誰かの参考になれば。

受験概要

• 受験日 2026/01/24
• オンライン受験（Kryterion）※複数回目
• 試験時間 2h ※見直し含めてきっちり2h掛かった
• 問題数 50問 ※合格したので正答率不明
• 今回は連続受験クーポンが利用できて$200/2*1.1=$110で受験

受験後の感想

• まず、これまでのGC試験で最も疲れた試験だった
• 各問題の文章量がかなり多かった印象で、全て文章で表現されるので問題によっては理解に集中を要する。疲れてる状態だとキツイかも
• 全体的に、セキュリティ要件に対して具体的な対策を確認されるもので、一問一答的なシンプルなものは少なかった
• かなり細かいところを問われる印象なので、模擬試験でそれなりの点数が取れていても油断は禁物
• 以下のUdemyの模擬試験のまんまの問題は少なかったが、カバー範囲としては問題なさそう。難易度は本番の方が少し高いかも
• 50問終了時の見直しマークは13問だったが、受験中は迷う問題が多く、体感ではもっと見直し対象にしていた印象だった
  • 一周目の解答終了時点で残り15分、13問の見直しもややこしいものが残っていたので、全問見直しできたがギリギリだった
• 今回は接続的な問題はなし

勉強法

• Udemy：【2026年最新】Google Professional Cloud Security Engineer 模擬試験
  • 割引なしで3000円
• 一旦真面目に4回分の模擬試験を受験し、まとめてテスト直ししつつ、理解が浅い部分をCopilotやGeminiで重点的に復習
  • 1つ目：96%、2つ目：76%、3回目：72%、4回目：84%
  • 模擬試験4回分で全体をカバーする感じなので全てやる必要あり
  • 復習時のまとめにて、CopiotもGeminiもたまに間違えるので、怪しいと感じたものはちゃんと確認する
• 勉強時間：電車で模擬試験4回分で5h、4hくらい集中して復習(合計10h弱)
  • かなり内容が細かくなってきたが、GCで提供されているセキュリティ対策を理解できるのでシンプルに楽しい
  • 一方で、より細かい設定等に関する知識やトラブルシューティングが多く、且つGCのサービスに依存するものが多いので本来は実際に触りながら学ぶのが望ましい
  • 新たな知識はあまりないが、以下のようなサービスの詳細を押さえておく必要あり
    • VPC Service Controlsとサービス境界
    • DNS連携、Proxy関連
    • SCCの各種機能
    • 認証連携(Workload Identity Federation, IAP, GCDS, SAML-based SSO)
    • 特殊なワークロード(Shielded VM, Confidential VM,Assured Workloads)
    • Authorized Dataset/View
    • 詳細は以下の「得られた用語など」を参照。流石にカテゴライズできなくなってきた

前提

• 一般的なwebシステム開発の経験あり
• Docker/Kubernetesの基礎知識あり
• CISSPと情報処理安全確保支援士を取得済みなのでセキュリティ方面の知識もそれなり
• いくつかのGoogleCloud資格取得済み(CDL,GAIL,ACE,ADP,AGWA,PCA)
• まだ実際のGoogle Cloud環境は一切触ってない(そろそろやばい)

得られた用語など

不正解からの学び

• Cloud EKM: Cloud External Key Manager。外部のKMSを利用してGCP上のデータを暗号化する仕組み
  • Cloud HSMと違い、鍵の管理を完全に外部に委託できるが、レイテンシが増加する可能性や、可用性の確保が必要
  • 可用性の確保には、複数のリージョンにまたがる外部KMSの利用や、フェイルオーバー戦略の策定が必要
• Cloud KMS: GCPのマネージド型鍵管理サービス
  • 鍵の生成、保存、管理、ローテーションを提供
  • ハードウェアセキュリティモジュール(HSM)を利用して鍵を保護
  • 主な機能：対称鍵と非対称鍵の管理、IAM統合、監査ログ、鍵のバージョニングとローテーション
  • 可用性確保には、ロケーションにマルチリージョンやグローバルを選択し、定期的なバックアップと監査ログの有効化が推奨される
  • キーを管理する外部システムとの接続が一時的に切断された場合は、可用性に影響を与える
• Cloud KMSのキーリングとキー
  • キーリング: 鍵を論理的にグループ化するコンテナ
  • キー: 実際の暗号化鍵。対称鍵と非対称鍵の両方をサポート
  • キーにはバージョンがあり、各バージョンは独立して管理可能
• Cloud HSM: GCPのハードウェアセキュリティモジュールサービス
  • FIPS 140-2 Level 3に準拠した物理的なHSMデバイスを提供
  • 高いセキュリティ要件を持つアプリケーション向けに設計
  • Cloud KMSと統合して使用可能
• Security Health Analytics: GCPのセキュリティ診断サービス
  • セキュリティのベストプラクティスに基づいて、GCPリソースの設定をスキャンし、潜在的な脆弱性や誤設定を検出
  • 主な対象：パブリック公開、オープンポート、古いOSバージョン、不適切なIAM設定など
• Web Security Scanner: GCPのWebアプリケーション向け脆弱性スキャナー
  • クロールとテストを通じて、XSSやSQLインジェクションなどの一般的な脆弱性を検出
  • 主な対象サービス：GKE, App Engine, Cloud Run, Compute Engine上のWebアプリケーション
• Policy Troubleshooter: IAMポリシーのトラブルシューティングツール
  • 特定のユーザーやサービスアカウントが特定のリソースに対して持つ権限を確認
  • ポリシーの評価結果を提供し、アクセス拒否の原因を特定
• Policy Analyzer: IAMポリシーの分析ツール
  • 組織全体のIAMポリシーを分析し、過剰な権限や潜在的なセキュリティリスクを特定
  • ポリシーの変更履歴を追跡し、セキュリティコンプライアンスを維持
• IAM Recommender: IAMポリシーの最適化を支援するツール
  • ユーザーやサービスアカウントの権限使用状況を分析し、不要な権限を削減するための推奨事項を提供
  • 最小権限の原則に基づいて、セキュリティリスクを低減
• Secret Managerを利用したDB接続情報の管理
  • Secret ManagerにDB接続情報を保存し、アプリケーションからはSecret Manager APIを通じて取得
  • アクセス制御をIAMで管理し、監査ログを有効化してアクセス履歴を追跡
  • ローテーションの自動化は、ローテーションスケジュールトリガー -> Pub/Sub -> Cloud FunctionsやCloud Runで実装
• Storageの署名付きURLの権限は、作成したサービスアカウントの権限に依存
• VPC Service Controlsのブロック理由の確認は、Audit logsのpolicy-deniedエントリを確認
  • ブロックした境界、違反タイプ、影響を受けたリソースなどの詳細情報が含まれる
• Assured Workloads: 特定の規制要件に準拠したワークロードをGCP上で実行するためのサービス
  • 以下のような規制に対応するためのコンプライアンスコントロールを提供
    • GDPR: 欧州連合のデータ保護規則
    • FedRAMP: 米国連邦政府のクラウドサービスセキュリティ基準
    • HIPAA: 米国の医療情報保護規則
    • CJIS: 犯罪者情報の保護に関する基準
    • PCI DSS: クレジットカード情報の保護基準
    • SOC 2: サービス組織のセキュリティ、可用性、処理の完全性、機密性、プライバシーに関する基準
  • ワークロードやデータの分離、データの暗号化、監査ログの管理などのテンプレートを提供
    • データの地理的配置（データレジデンシ、ロケーション）: データが特定の地域内に保存されるように制御
    • データ主権管理、アクセス制御: 厳格なIAMポリシーと多要素認証の適用
    • 監査とログ管理: 監査ログの有効化と定期的なレビュー
    • データ暗号化: 保存データと転送データの暗号化
    • インシデント対応: セキュリティインシデントに対する対応計画の策定
• Assured Workloads for Government: 米国政府向けの特別なAssured Workloads
  • FedRAMP High、DoD SRG Levels 2-5、ITARなどの厳格な規制要件に対応
  • 政府機関や防衛関連企業がGCP上でワークロードを安全に実行できるように設計
• Shielded VM: 強化されたセキュリティ機能を備えたCompute Engineの仮想マシン
  • セキュアブート: OSの起動時に署名を検証し、改ざんを防止
  • 整合性モニタリング: VMのブートプロセスやOSの整合性を継続的に監視
  • 仮想TPM: 仮想化されたトラステッドプラットフォームモジュールを提供し、暗号化キーの安全な保管を実現
• Sheidled GKE Nodes: GKEクラスター内でShielded VMのセキュリティ機能を利用可能にするオプション
• Confidential VMs: GCPの仮想マシンで、メモリの暗号化を提供するサービス
  • メモリ内のデータが暗号化され、ホストOSや他のVMからのアクセスを防止
  • ハードウェアベースのセキュリティ機能を利用して、データの機密性を確保
  • Googleサポートからの管理アクセスも防止可能
  • Confidential VMsを使用するには、Compute Engineインスタンスを作成する際に「Confidential VM」オプションを有効化
• Confidential GKE Nodes: GKEクラスター内でConfidential VMsのメモリ暗号化機能を利用可能にするオプション
• vTPM: 仮想トラステッドプラットフォームモジュール。仮想化環境でTPMの機能を提供
  • 秘密情報（暗号化キー、証明書など）を安全に保管
  • Confidential VMsやShielded VMsで利用可能
• OS Login 認証: IAMを使用してCompute EngineインスタンスへのSSHアクセスを管理
  • ユーザーのIAMロールに基づいてアクセス権を付与または拒否
  • SSHキーの管理が不要になり、セキュリティが向上
  • 多要素認証（MFA）の有効化には、プロジェクトまたはインスタンスのメタデータにenable-oslogin-mfa=TRUEを設定
• Workload Identity Federation: 外部IDプロバイダー（例: AWS IAM、Azure AD、オンプレミスのIDシステム）を使用してGCPリソースにアクセスするための仕組み
  • サービスアカウントを介してGCPリソースへのアクセスを許可
  • 長期的なGCPサービスアカウントキーの管理が不要になり、セキュリティが向上
  • 具体的なサービスアカウントを使ったアクセス制限方法は以下の通り
    • 外部IDプロバイダーで認証されたエンティティに対して、特定のGCPサービスアカウントへのアクセスを許可するように設定
    • IAMポリシーで、Workload Identity Federationを使用してアクセスするエンティティに対して、必要なロールを付与
    • つまり、WIFで外部の特定のエンティティを認証し、そのエンティティに対して特定のサービスアカウントへのアクセス権をIAMで設定することで、細かいアクセス制御
• マルチクラウド環境でのキーレス認証
  • 例）AWS上のアプリケーションからGC上のBigQueryにアクセスする場合
    1. AWS IAMロールを作成し、必要なポリシーを付与
    2. GCPでWorkload Identity Poolを作成し、AWSを外部IDプロバイダーとして設定
    3. Workload Identity Pool内にAWS IAMロールと対応するGCPサービスアカウントをマッピング
    4. AWS上のアプリケーションがAWS IAMロールを使用して認証し、GCPサービスアカウントを介してBigQueryにアクセス
• Identity-Aware Proxy (IAP): GCPリソースへのアクセスをユーザーのIDとコンテキストに基づいて制御するサービス
  • コンテキスト：ユーザーの場所、デバイスの状態、IPアドレスなど
  • アプリケーションレベルでのアクセス制御を提供し、VPNやファイアウォールの設定を簡素化
  • IAPを有効にするには、対象のリソース（App Engine、Compute Engine、GKEなど）でIAPを有効化し、適切なIAMロール（IAP-Secured Web App Userなど）をユーザーに付与
• GCDS: Google Cloud Directory Sync。オンプレミスのActive DirectoryやLDAPディレクトリとGoogle Workspace/GCPのユーザーアカウントを同期するツール
  • ユーザー、グループ、連絡先情報を同期
  • セキュリティポリシーの一貫性を維持
• SAML-based SSO: SAMLを使用してGoogle Workspace/GCPへのシングルサインオンを実現
  • IdP（例: Okta、Azure AD、オンプレミスのAD FS）を使用して認証
• Secure Web Proxy: VPCからインターネットへのアウトバウンドトラフィックを制御するためのプロキシサーバー
  • 接続先URL, 接続元ホスト/IPアドレス, プロトコル, 時間帯などに基づいてトラフィックをフィルタリング
  • Cloud NATやCloud Routerと組み合わせて使用可能
    • Cloud NATは、NAT機能のみを提供し、トラフィックのルーティングやフィルタリングは行わない
    • Cloud Routerは、ルーティング情報の管理のみ
• VPC Service Controls(VSC): GCPリソースへのデータの不正アクセスや漏洩を防ぐためのセキュリティ境界を作成するサービス
  • サービス境界(ペリメーター)を定義し、その境界内でのみデータの読み書きを許可
  • 境界外からのアクセスを制限し、データの保護を強化
  • サービス境界の設定には、サービスペリメーターを作成し、対象のGCPサービス（Cloud Storage, BigQuery, Cloud Pub/Subなど）を指定
  • サービス境界内でのアクセス制御は、IAMポリシーと組み合わせて使用可能
  • サービス境界の監査には、Cloud Audit Logsを使用して、境界内外でのアクセス試行を記録
    • ログを分析して、不正アクセスの兆候を検出
    • アラートを設定する場合は、Cloud MonitoringとCloud Loggingを組み合わせて、特定のログエントリに基づいて通知を受け取るように設定
• VSCとFWの違い
  • VPC Service Controlsは、GCPリソースへのデータアクセスを制御するためのセキュリティ境界を提供
  • ファイアウォールルールは、ネットワークレベルでのトラフィックの許可または拒否を制御
  • VSCはデータの保護に焦点を当て、FWはネットワークトラフィックの制御に焦点を当てる
• VSCの境界を跨ぐアクセス許可
  • VPC Service Controlsの境界を跨いだアクセスを許可するには、アクセスレベルを設定
    • アクセスレベルは、特定の条件（例: IPアドレス範囲、デバイスのセキュリティ状態など）に基づいてアクセスを許可
    • アクセスレベルを作成し、サービス境界に関連付けることで、境界を跨いだアクセスを制御
  • プライベートIPで境界内マネージドサービスに境界外プロジェクトからの安全な接続にはPrivate Service Connectを利用
    • Private Service Connect: 異なるVPC間でアドレス重複を避けつつ、VPCピアリングなしにプライベートIPアドレスを使用してサービスにアクセス可能にするサービス
    • サービス境界内でPSCサービスアタッチメントを作成し、境界外のプロジェクトからPSCエンドポイントを介して接続
• サービス境界の設定例
  • 1. Google StorageとBigQueryを同一のサービス境界に含めるケース
    • サービスペリメーターを作成し、Cloud StorageとBigQueryを指定
    • これにより、同一境界内でのデータの読み書きが許可され、境界外からのアクセスが制限される
    • デフォルトで境界内に含まれるサービス例
      • データ系：Cloud Storage, BigQuery, Cloud Pub/Sub, Cloud Bigtable, Cloud Spanner, Cloud Datastore, Cloud SQL
      • コンピューティング系：Compute Engine, GKE, App Engine, Cloud Functions, Cloud Run
      • その他：Secret Manager, AI Platform
    • これらのサービスからのアクセスを拒否する場合は、IAMポリシーで明示的に拒否ルールを設定
  • 1. 外部サービスからのアクセスを許可するケース
    • 例えば、オンプレミスのデータセンターからCloud Storageへのアクセスを許可する場合
    • サービスペリメーターを作成し、Cloud Storageを指定
    • アクセスレベルを設定し、オンプレミスのIPアドレス範囲を指定
    • これにより、オンプレミスからのアクセスが許可され、その他の境界外からのアクセスは制限される
• VMの無停止、メモリダンプ取得は、limeやavmlなどのツールを利用
  • LiME: Linux Memory Extractor。Linuxシステムのメモリダンプを取得するためのオープンソースツール
  • AVML: Acquire Volatile Memory for Linux。Linuxシステムのメモリダンプを取得するためのMicrosoft製ツール
• リソース作成時のコンプライアンス強制（ラベル付与）
  • 現時点では組織ポリシーでラベル付与を強制する方法は提供されていない（タグはある）
  • 予防的統制：IaC経由でのデプロイを強制し、パイプライン内でポリシーチェック(Open Policy Agentやgcloud beta terraform vetなど)によりブロック
  • 発見的統制：Cloud Asset InventoryやCloud Config Validatorを利用して、ラベル付与されていないリソースを定期的に検出し、アラートを発行
• Authorized Dataset: BigQueryの機能で、特定のデータセットに対するアクセスを他のプロジェクトから許可
  • データセットの所有者が、他のプロジェクトに対してデータセットへのアクセス権を付与（Dataset毎）
  • これにより、異なるプロジェクト間でデータ共有が可能
• Authorized View: BigQueryの機能で、特定のビューに対するアクセスを他のプロジェクトから許可
  • ビューの所有者が、他のプロジェクトに対してビューへのアクセス権を付与（View毎）
  • これにより、異なるプロジェクト間でビューを通じたデータ共有が可能
• Authorized ViewとAuthorized Datasetの違い
  • View単位か、Dataset丸ごとかの違い
  • Dataset AをDataset Bに許可し、B側でAのViewにBの特定データを紐づけることで、Dataset Aの利用側に対する包括的なアクセス制御が可能
  • ユーザ -> Dataset A(View) with Authorized to B -> Dataset B(Data)のようなアクセスフローになる
• Cloud Run+Secret Managerでのシークレット管理
  • 起動時に取得: 起動時にシークレットをボリュームとしてマウントし、ファイルシステム経由でアプリケーションがアクセス
  • Cloud Runアプリから都度取得: Secret Manager APIを使用して、Cloud Runアプリケーションからシークレットを動的に取得
• 階層型ファイアウォールポリシー（Hierarchical Firewall Policies）
  • 上位で定義されたファイアウォールルールが下位に継承される仕組み
  • goto_nextアクションを設定し、下位で例外ルールを定義するには、上位ルールでgoto_nextを指定おく
    • 例: 組織レベルで特定ポートへのトラフィックを拒否し、プロジェクトレベルでのみアクセスを許可する場合
      • 組織レベルでの拒否ルールにgoto_nextを設定
      • プロジェクトレベルでの許可ルールを定義
      • これにより、組織レベルの拒否ルールが適用された後、プロジェクトレベルの許可ルールが評価される
  • 下位で上位のルールを完全に無効化することはできない
• Cloud DLP(現:Sensitive Data Protection): 機密データの検出、分類、保護を支援するサービス
  • 機密データの検出: 名前、住所、クレジットカード番号などのパターンに基づいてデータをスキャン
  • データの分類: 検出されたデータを機密度に基づいて分類
  • データの保護: マスキング、トークン化、暗号化などの方法で機密データを保護
  • 主な機能：テンプレートベースのスキャン、カスタムルールの作成、レポート生成、自動化ワークフローの構築
  • 対象リソース：Cloud Storage, BigQuery, Datastore, Cloud SQLなど
• Cloud Shell作業時の機密データに対するアラート
  • Cloud Shell内データのCloud DLPによる直接スキャンはサポートされていないため、以下の代替手段による対策を検討
    1. Cloud DLP APIを使用して、Cloud Shell内のファイルをスキャンするカスタムスクリプト
    2. Cloud Shell上のファイルをCloud Storageにアップロードや同期し、Cloud DLPでスキャン
• Cloud Loggingのシンクによるログ転送時のPII除去
  • Cloud Routerには特定フィールドの書き換えやマスキング機能はないため、以下のような代替手段を検討
    • Pub/Subを中継ポイントとして使用し、Cloud LoggingからPub/Subにログを送信し、Cloud FunctionsでPII除去処理を行い、その後Cloud StorageやBigQueryなどに保存
• 金融業界向けのオンプレ->Google CloudをCloud Interconnect接続時のレイヤ2トラフィック暗号化
  • MACsec (Media Access Control Security, IEEE 802.1AE)を使用して、レイヤ2トラフィックの暗号化を実現
    • パケットのカプセル化オーバーヘッドがなく、低レイテンシでの暗号化通信が可能(10Gbps/100Gbps対応)
    • HA VPN over Interconnectのようなレイヤ3 VPN(帯域幅制限：Max 3Gbps程度)よりもパフォーマンスが向上
• ハイブリッドクラウドにおける相互名前解決
  • オンプレ -> GCP
    • Cloud DNSでインバウンドサーバーポリシーを作成し、オンプレのDNSサーバーからの名前解決要求をCloud DNSに転送
  • GCP -> オンプレ
    • Cloud DNSでアウトバウンドゾーン転送を設定し、クエリをオンプレのDNSサーバーに転送
• 複数プロジェクトで共通利用するゴールデンイメージの一元管理
  • 共通イメージプロジェクトを作成し、ゴールデンイメージを格納
  • 他のプロジェクトからは、イメージの完全なリソース名（projects/[IMAGE_PROJECT]/global/images/[IMAGE_NAME]）を使用して参照
  • IAMポリシーで、共通イメージプロジェクトに対する読み取り権限(roles/compute.imageUser)を他のプロジェクトのサービスアカウントに付与
• Cloud KMSでの対称鍵(Symmetric Key)のローテーション
  • 自動ローテーションを有効化することで、指定した期間ごとに自動的に新しい鍵バージョンが生成される
  • 手動ローテーションも可能で、必要に応じて新しい鍵バージョンを作成し、アプリケーションやサービスで使用する鍵バージョンを更新
• Cloud KMSでの非対称署名鍵(Asymmetric Signing Key)のローテーション
  • まず自動ローテーションはサポートされていないため
  • 以下の手動でのローテーション手順を実施
    1. 新しい非対称署名鍵ペアをCloud KMSで作成
    2. 新しい公開鍵を使用して署名検証を行うようにアプリケーションやサービスを更新
    3. 古い鍵が不要になったら、Cloud KMSから削除
• 対象鍵と非対称鍵の違い
  • 対称鍵: 同じ鍵を使用してデータの暗号化と復号化を行う
    • 例: AES (Advanced Encryption Standard)
  • 非対称鍵: 公開鍵と秘密鍵のペアを使用し、公開鍵でデータを暗号化し、秘密鍵で復号する。または、秘密鍵で署名し、公開鍵で検証する
    • 例: RSA (Rivest-Shamir-Adleman), ECDSA (Elliptic Curve Digital Signature Algorithm)
• 監査専用GC組織へのログ転送
  • 監査専用のGCP組織を作成し、各組織レベルの集約シンク（Aggregated Sink）を作成し
  • 監査ログを監査組織のPub/SubやStorageバケットに転送する
  • 転送先の監査組織で適切なIAMポリシーを設定し、監査担当者がログにアクセスできるようにする
  • 転送元組織でCloud Loggingシンクを設定する際に、転送先の監査組織のプロジェクトIDとログバケットを指定
• 集約シンクとは
  • Cloud Loggingの機能で、複数のプロジェクトやフォルダからのログを一元的に収集し、特定の転送先に送信する仕組み
  • これにより、ログ管理と分析が容易になり、セキュリティ監査やコンプライアンス要件を満たすために役立つ
• 社内ドメインの名前解決をオンプレミスDNSサーバーにフォワードする方法
  • 限定公開ゾーンをCloud DNSで作成し、社内ドメインを定義
  • 転送ターゲットにオンプレのDNSサーバーのIPアドレスを指定し、転送ゾーンとして構成する
• 限定公開ゾーンと転送ゾーンの違い
  • 限定公開ゾーン: 特定のVPCネットワーク内でのみ名前解決が可能なDNSゾーン
    • 例: internal.example.comを限定公開ゾーンとして作成し、VPC内のリソースからのみアクセス可能にする
  • 転送ゾーン: DNSクエリを他のDNSサーバーに転送するためのゾーン
    • 例: corp.example.comのクエリをオンプレミスのDNSサーバーに転送するように設定
• スプリットホライズンDNS
  • 同じドメイン名に対して、異なるネットワークや場所から異なるDNS応答を提供する仕組み
  • 例: example.comに対して、社内ネットワークからのアクセスには内部IPアドレスを返し、外部ネットワークからのアクセスにはパブリックIPアドレスを返す
  • Cloud DNSでは、限定公開ゾーンとパブリックゾーンを組み合わせてスプリットホライズンDNSを実現可能（以下、設定例）
    1. 限定公開ゾーン example.com を作成し、VPC内のリソースに対して内部IPアドレスを返すように設定
    2. パブリックゾーン example.com を作成し、インターネットからのアクセスに対してパブリックIPアドレスを返すように設定
• データ分析にてPIIの確定的マスキング
  • Sensitive Data Protection(旧Cloud DLP) の暗号学的ハッシュを利用して、常に同じハッシュ値を生成
  • その他の機能
    • 秘匿化（Redaction）: PIIデータを完全に削除または置換
    • 確定的暗号化(Deterministic Encryption): 同じ入力データに対して常に同じ暗号化結果を生成　（こちらなら複号可能）
    • 日付シフト(Date Shifting): 日付データをランダムにシフトして、元の日付を特定できないようにする
• 開発者によるサービスアカウント(例sa-acc)としてのコマンド実行や権限の借用
  • 開発者ユーザーアカウントに対して、sa-accのroles/iam.serviceAccountTokenCreatorロールを付与
  • 開発者はgcloudコマンドで--impersonate-service-accountフラグを使用して、sa-accとしてコマンドを実行可能
  • 間違えやすいロール
    • roles/iam.serviceAccountUser: サービスアカウントを"使用して"リソースを作成・管理する権限を付与（トークンの生成は不可）
    • roles/iam.serviceAccountAdmin: サービスアカウントの作成・管理権限を付与（トークンの生成は不可）

正解からの学び

• SCC Premium: Security Command Centerの上位版で、より高度なセキュリティ機能と統合を提供
  • VM Threat Detection: Compute Engine VMの脆弱性やマルウェアを検出
  • Event Threat Detection: GCPリソースのログをリアルタイムで分析し、脅威を検出
  • Container Threat Detection: GKEクラスター内のコンテナの脆弱性や異常を検出
  • 拡張ルールセット（Security Health Analytics, Web Security Scannerなど）の提供
• オブジェクトホールド
• private.googleapi.com: VPC Service Controls内からGoogle APIにアクセスするためのプライベートエンドポイント
  • VPC内のリソースがGoogle APIにアクセスする際に、インターネット経由ではなく、Googleの内部ネットワークを通じて通信
  • これにより、データのセキュリティとプライバシーが向上し、VPC Service Controlsの境界内でのアクセスが可能
  • Youtube等のコンシューマー向けサービスは対象外
• restricted.googleapis.com: VPC Service Controls内からGoogle APIにアクセスするための制限付きエンドポイント
  • VPC内のリソースがGoogle APIにアクセスする際に、特定のAPIエンドポイントのみを許可
  • これにより、不要なAPIへのアクセスを制限し、セキュリティを強化
• Cloud Run functions(第二世代) の認証
  • 第二世代のCloud Runでは、IAMベースの認証がデフォルトで有効化
  • サービスアカウントに対してroles/run.invokerロールを付与することで、Cloud Runサービスへのアクセスを制御
  • 認証が必要な場合、HTTPリクエストにIDトークンを含める必要がある
• Cloud Identity: GoogleのIDおよびアクセス管理サービス
  • ユーザーアカウント、グループ、デバイスの管理
  • シングルサインオン(SSO)、多要素認証(MFA)、セキュリティポリシーの適用
  • Google Workspaceと統合して、組織全体のID管理を一元化
• Kubernetes Network Policy: GKEクラスター内のPod間およびPodと外部サービス間のネットワークトラフィックを制御するためのルールセット
  • Podセレクター、名前空間セレクター、IPブロックに基づいてトラフィックの許可または拒否を定義
  • ネットワークポリシーを適用することで、マイクロサービスアーキテクチャにおけるセキュリティ境界を確立
  • GKEでネットワークポリシーを有効にするには、クラスター作成時に--enable-network-policyフラグを指定
• Cloud KMSの破棄スケジュール
  • 鍵バージョンを破棄する際に、即時破棄またはスケジュール破棄を選択可能（デフォルトは24時間後）
  • スケジュール破棄を選択すると、指定した日時に鍵バージョンが自動的に破棄される
  • 破棄スケジュールは、鍵バージョンの作成時または後から変更可能
• GKE Sandbox: GKEクラスター内でPodを分離するためのセキュリティ機能
  • gVisorを使用して、Podごとに独立したユーザー空間を提供
  • ホストOSからの分離を強化し、悪意のあるコードがホストに影響を与えるリスクを低減
  • GKEクラスター作成時にsandboxオプションを有効化することで利用可能
• IAM拒否ポリシー: IAMポリシーにおいて、特定の条件に基づいてアクセスを明示的に拒否するルールを定義する機能
  • 拒否ポリシーは、許可ポリシーよりも優先されるため、特定のユーザーやサービスアカウントに対してアクセスを制限可能
• ログルーターによる間引き(サンプリング)：sample(insertId, percentage)関数を使用して、特定の割合でログエントリを転送
• Backupのロック
• サーバレスNEG: Cloud RunやApp Engineなどのサーバーレスサービス用のネットワークエンドポイントグループ
  • サーバーレスアプリケーションへのトラフィックをGCLB経由でルーティング可能にする
  • 自動スケーリングと高可用性を提供
  • Cloud Armorと組み合わせて使用可能
• 作成可能なロードバランサを制限するポリシー
  • 組織ポリシーでconstraints/compute.loadBalancersAllowedTypesを設定し、許可するロードバランサのタイプを指定
  • 例: HTTP(S)ロードバランサのみを許可し、TCP/UDPロードバランサの作成を禁止
  • 用途：コスト管理、セキュリティポリシーの遵守、運用の一貫性確保
• BreakGlass フラグ: 監査ログには残る
• Sensitive Data ProtectionのカスタムInfoType
  • ユーザー定義のパターンや正規表現に基づいて機密データを検出するためのInfoTypeを作成可能
  • 例: 社内の顧客IDフォーマットや特定のプロジェクトコードなど
• VM Manager: Compute Engine VMの管理とセキュリティを強化するためのサービス
  • OSパッチ管理: VMに対して自動的にOSパッチを適用
  • インベントリ管理: VMのソフトウェアインベントリを収集・管理
  • ポリシー管理: セキュリティポリシーを定義し、VMに適用
  • セキュリティスキャン: VMの脆弱性をスキャンし、レポートを提供
  • SCCとの統合: VMのセキュリティ状態をSecurity Command Centerで監視
• Privileged Access Management (PAM) for Google Cloud: 特権アクセスを管理・監視するためのサービス
  • 一時的な特権アクセスの付与: 必要なときにのみ特権アクセスを許可し、期限切れ後に自動的にアクセスを取り消す
    • 資格(Entitlement)の付与: ユーザーやサービスアカウントに対して、一時的な特権アクセスを付与
    • アクセス期間の設定: 特権アクセスの有効期限を設定
  • アクセス承認ワークフロー: 特権アクセスのリクエストに対して承認プロセスを設定
  • 監査ログの記録: 特権アクセスの使用状況を詳細に記録し、監査可能にする
• 組織ポリシーのプロジェクトレベルでの上書き(ドメイン制限の例)
  • 上位レベルでドメイン制限を設定し、特定のプロジェクトでのみ異なるドメインを許可する場合
    1. 組織レベルでconstraints/iam.allowedPolicyMemberDomainsを設定し、許可するドメインを指定
    2. プロジェクトレベルで同じ制約を設定し、異なるドメインを指定
    3. プロジェクトレベルの設定が優先され、指定されたドメインが許可される
• 上位、下位での上書き可能な例、不可能な例
  • 可能な例
    • IAMポリシーのドメイン制限（constraints/iam.allowedPolicyMemberDomains）
    • VMインスタンスタイプの制限（constraints/compute.vmTypesAllowed）
  • 不可能な例
    • 組織全体の請求アカウントの設定（constraints/gcp.restrictBillingAccount）
    • プロジェクトの作成制限（constraints/resourcemanager.projects.create）
• Grafeas: ソフトウェアのセキュリティとコンプライアンス情報を管理するためのオープンソースのメタデータフレームワーク
  • ソフトウェアアーティファクト（コンテナイメージ、VMイメージなど）に関する脆弱性情報、ビルド情報、デプロイ情報などのメタデータを収集・管理
  • セキュリティスキャンツールやCI/CDパイプラインと統合して、ソフトウェアのセキュリティ状態を把握
  • GCPでは、Container Analysis APIを通じてGrafeasを利用可能
• 監査用ドキュメントはコンプライアンスレポートマネージャー
• Dataplexのポリシータグ
  • Dataplexでは、データカタログのポリシータグを使用して、データ資産に対するアクセス制御を細かく設定可能
  • ポリシータグを作成し、Dataplexのデータアセットに適用することで、特定のユーザーやグループに対するアクセス権を管理
  • これにより、データガバナンスとセキュリティが強化される
  • 注意点: ポリシータグはデータカタログで管理されるため、Dataplexのデータアセットに適用する前に、データカタログでポリシータグを作成・管理する必要がある
• GKE Autopilotのセキュリティ機能
  • 自動的なノード管理: ノードのパッチ適用、アップグレード、スケーリングを自動化し、セキュリティリスクを低減
  • セキュアなデフォルト設定: ネットワークポリシー、Podセキュリティポリシー、IAMロールなどのセキュリティ設定がデフォルトで有効化
  • Shielded GKE Nodesのサポート: Shielded VMのセキュリティ機能を利用可能
  • 自動監視とアラート: クラスターのセキュリティ状態を継続的に監視し、異常が検出された場合にアラートを発行
  • SCCとの統合: Security Command Centerと連携して、GKEクラスターのセキュリティ状態を一元的に管理
• VPC Service Controlsのドライランモード
• Ceertificate Authority Service: マネージドなプライベート証明書発行サービス
• Access Transparency: GoogleのスタッフがGCPリソースにアクセスした際の詳細なログを提供
  • ログには、アクセス日時、理由、対象リソースなどの情報が含まれる
  • これにより、Googleのスタッフによるアクセスを監査可能
• Access Approval: GoogleのスタッフがGCPリソースにアクセスする前に、ユーザーが明示的に承認する仕組み
  • 承認リクエストが発生すると、ユーザーに通知が送信され、承認または拒否の選択肢が提供される
  • これにより、Googleのスタッフによるアクセスを制御可能