AWSエンジニアのためのGoogle Cloudサービスまとめその5 セキュリティ・ID管理編

Last updated at 2026-09-16Posted at 2026-08-13

0. はじめに

前回はネットワーク系のサービスをまとめました。今回はその第5弾として、セキュリティ・ID管理系のサービスを見ていきます。ロードバランサやネットワーク経路は前回のネットワーク編で扱ったので、ここからはセキュリティ統合管理・IAM・監査ログなど、アクセス制御とガバナンスに関わるサービスを見ていきます。

このカテゴリは、名前は似ていても担当レイヤーが異なるサービス(SCCとCloud Armorなど)が多いため、対応関係に加えて各サービスの担当領域を整理します。

1. セキュリティ・ID管理

カテゴリ	AWS	Google Cloud
セキュリティ統合管理	Security Hub	Security Command Center (SCC)
機密データ保護	Macie	Sensitive Data Protection
生成AIのプロンプト/レスポンス保護	Bedrock Guardrails	Model Armor
WAF / DDoS対策	WAF / Shield	Cloud Armor
鍵管理	KMS	Cloud KMS
リソースの階層グループ化(共通IAMポリシー適用)	AWS Organizations OU	フォルダ (Folder)
アクセス権限管理	IAM	IAM
内部アプリへのアクセス制御(認証プロキシ)	Verified Access	Identity-Aware Proxy (IAP)
GKE PodのGoogle Cloud認証(キーレス)	IRSA	Workload Identity Federation for GKE
オンプレミス/他クラウドのワークロード認証(キーレス)	-	Workload Identity Federation (オンプレミス・他クラウド向け)
外部パートナー等の人間のユーザーのフェデレーション	-	Workforce Identity 連携 (Workforce Identity Federation)
ユーザーによるSAの一時的なりすまし	AssumeRole	サービスアカウントの権限借用 (Impersonation)
JIT特権昇格・エンタイトルメント管理	TEAM (aws-samplesのOSS参考実装)	Privileged Access Manager (PAM)
全プリンシパル対象の明示的な権限拒否	-	IAM拒否ポリシー (IAM Deny Policy)
ローカル開発時のデフォルト認証情報	AWS CLI の認証情報チェーン	Application Default Credentials (ADC)
シークレット管理	Secrets Manager	Secret Manager
監査ログ	CloudTrail	Cloud Audit Logs
プライベートPKI(マネージドCA)	AWS Private Certificate Authority	Certificate Authority Service (CA Service)
データ持ち出し防止(境界制御)	-	VPC Service Controls
リソース設定の制約(FWルール適用は不可)	AWS Organizations SCP	組織ポリシー (Organization Policy)
監査ログ等の他サービスへの転送設定	CloudTrail への配信設定	ログシンク (Log Sink)
ユーザー認証 (CIAM・一般消費者向け)	Cognito	Identity Platform
従業員ID管理 (IdP)	IAM Identity Center (旧 AWS SSO)	Cloud Identity
グループウェア	-	Google Workspace
Googleサポートによるデータアクセスの可視化・事前承認	-	Access Transparency / Access Approval
暗号鍵アクセス要求ごとの理由提示・承認	-	Key Access Justifications (KAJ)
規制プログラム対応の統制一括パッケージ(データ所在地・サポート地理等)	-	Assured Workloads
第三者認証・監査レポートのセルフサービス取得	AWS Artifact	Audit Manager

1-1. Security Command Center (SCC)

Security Hubに相当する、Google Cloud環境におけるセキュリティとリスクを統合管理するためのプラットフォームです。

組織全体の設定ミス検出(Security Health Analytics)、公開Webアプリの脆弱性スキャン(Web Security Scanner)、脅威検出(Event Threat Detection)を包括的に提供し、PCI DSSなどの規制コンプライアンス状況を監視・報告します。
脆弱なディスクイメージから起動されたVMの自動検出も可能です(稼働時間の長短では脆弱性の有無は判断できない点に注意)。
稼働中VMのクリプトマイニング(暗号通貨マイニングソフト)は、Virtual Machine Threat Detection(ハイパーバイザからエージェントレスでVMのメモリをスキャン)とEvent Threat Detection(ログ上の不正な通信シグナルから検出)の両方が検出対象に含みます。VMTDはメモリ上の実行痕跡、ETDはログ上の通信痕跡という検出面の違いがあります。
進行中インシデントの調査: 未知のIPアドレスから高権限サービスアカウントへの成りすましを狙った疑わしいログイン試行のように、進行中の脅威を調査したい場合は、Event Threat Detectionの関連findingsを確認し、Cloud Audit Logsと相互参照します。データアクセス監査ログを事後に有効化しても、それ以前の証跡までは記録されていません。
公開資産の検出から監査までをツールだけで完結: 公開ネットワーク資産を検出・監査したい場合は、まずCloud Asset Inventoryで組織全体のリソースを棚卸しして外部公開資産を特定し、そのうえでWeb Security Scannerで脆弱性を監査します。自社所有のGoogle Cloud資産のスキャンには、事前のGoogleへの通知や承認は不要です。
継続的コンプライアンス評価からの対象外コントロール除外: CIS Google Cloud Foundations Benchmark等に継続的に自動評価したいが、組織に関連しないコントロールは評価対象から外したい場合は、SCC Premiumのミュートルールを使います。該当する検出結果を自動的かつ恒久的にミュートでき(削除ではないため後から見直しも可能)、表示のたびに手動でミュートする運用を避けられます。
規制標準への構成偏差の継続検出: PCI DSS等の規制標準に対し、IaaSレベルの構成偏差を監査前に継続的に検出したい場合は、SCC PremiumのCompliance Monitoring機能(実体はSecurity Health Analyticsの検出結果を規制標準にマッピングしたもの)で対応標準にフィルタリングし、非準拠の検出結果を洗い出します。
悪性ドメインへの疑わしい通信の検知: 既知の疑わしいドメインへのアウトバウンド通信を検知・アラートしたい場合は、Cloud DNSのDNS Server Policyでクエリロギングを有効化し、インターネット接続を持つVPCネットワークへ適用します。クエリログがCloud Loggingへ記録されると、SCC PremiumのEvent Threat Detectionがそのログを解析し、悪意のあるドメイン解決を検知します。
暗号鍵の未ローテーション検出: ローテーションポリシーを設定し忘れているプロジェクトを組織横断で洗い出したい場合は、SCC PremiumのSecurity Health AnalyticsのKMSスキャナによる検出結果を確認します。自前でCloud KMS APIを定期ポーリングするスクリプトを書かずに済みます。
コンテナのランタイム脅威検出: 稼働中のGKEコンテナ内での不審なバイナリ実行やリバースシェルなどのランタイム脅威を検出したい場合は、SCC Premium/EnterpriseのContainer Threat Detectionを使います。VMTD/ETD(上述)とは検出対象のレイヤーが異なります。

1-2. Sensitive Data Protection (旧 Cloud Data Loss Prevention / Cloud DLP)

Amazon Macieに相当する、氏名・住所・電話番号・クレジットカード番号・マイナンバーなどの機密情報(PII)を自動検出・分類し、マスキング・トークン化・置換などで匿名化するデータ保護サービスです。

Cloud Storage、BigQuery、DatastoreなどのGCPサービスと連携して保存データをスキャンできるほか、API経由でアプリケーションに組み込み、データ入力時やデータ連携時にリアルタイムで機密情報を検査することも可能です。GDPR、PCI DSS、HIPAAなどのコンプライアンス対応でも広く利用されます。
Macieは主にS3内の機密データの自動検出・分類が中心ですが、Sensitive Data Protectionは保存データだけでなくAPIによるリアルタイム検査やデータの匿名化・変換機能まで備えている点で、データ保護・加工の範囲がより広いです。
自社データをAIトレーニングに活用する際の倫理的配慮: 自社の保有データでAIモデルを学習させたい場合、未加工データをそのまま使うとPIIが学習データに混入するリスクがあります。Sensitive Data Protectionによる匿名化・仮名化を実装すれば、プライバシーリスクを抑えながら自社データを活用できます(公開データセットのみに限定すると、自社データ活用という目的自体を達成できません)。
画像に含まれるPIIを保護したい場合は、画像検査・レダクション機能を使います。OCRでテキストを検出してinfoTypeに一致させるほか、顔や物体の検出・マスキングも行えます(テキスト向けのレダクション設定は画像には効きません)。
運用チームにはPIIを見せず、必要なチームだけが元の値へ戻せるようにしたい場合は、可逆なトークン化を使います。マスキングや編集(値の削除)は不可逆で、後から元の値を復元できません。
複数テーブル間の結合(参照整合性)を保ちつつ既存のスキーマ制約(桁数・文字種)に合わせてトークン化したい場合は、入力と同じ長さ・文字種のトークンを生成する形式保存暗号化(FPE)を使います。文字種を保つ必要がなければ決定論的暗号化(AES-SIV)の方が制約が少なく、暗号学的ハッシュは不可逆なため再識別が必要な用途には使えません。
検査コストを抑えたい場合は、BigQueryのrowsLimitやCloud StorageのbytesLimitPerFileで検査対象をサンプリングし、CloudStorageRegexFileSetでスキャン対象のファイルパスを絞り込みます。
アップロードされたファイルにPIIが含まれる場合だけ別バケットへ自動的に隔離したい場合は、Cloud Pub/SubとCloud Functionsを組み合わせ、アップロードをトリガーにDLPスキャンを実行してPII検出時のみファイルを移動する構成が定石です。
一定期間より前の既存ファイルからPIIを取り除きつつ、匿名化後のデータは保持目的で別途アーカイブしたい場合は、検査ジョブで対象ファイルのPIIを検出・脱識別化し、結果を別のCloud Storageバケットへ保存した上で元ファイルを削除します。オブジェクトライフサイクル管理(TTL)はストレージクラスの自動移行・コスト最適化の機能で、ファイル内容のPIIを検出・除去することはできません。
複数リージョンにまたがるバケットでの機密データ検出: 複数リージョンのCloud Storageバケットに特定の機密データ種別(例: ヘルスケアデータ)が紛れ込んでいないかを検出したい場合は、検出対象のinfoTypeを指定した検査ジョブを全対象バケットに対して実行します。データの所在地を制限する組織ポリシーやコンプライアンス監視の機能では、バケット内のデータの中身そのものは検査できません。
生成AIチャットボットの入出力からのPII排除: 内部向けチャットボットを通じてPIIが通信されないようにしたい場合は、DLP APIでユーザーの入力(発話)とモデルの出力(応答)の双方に対しPIIを検出・マスキングします。
Cloud Functionsの環境変数に残るシークレットの定期検出: サーバーレス関数の環境変数に紛れ込んだAPIキー等のシークレットを検出したい場合は、Sensitive Data Protectionで環境変数を定期スキャンし、検出時にSecurity Command Centerのfindingとして一元管理します。
BigQueryデータセットの仮名化による分析共有: 機密データセット(PII含む)を分析目的で別チームに共有しつつPIIを保護したい場合は、**仮名化(pseudonymization)**でPIIフィールドを識別不可能な代替値に置き換えたうえで、仮名化済みデータセットへのアクセスを付与します。分析に必要な結合キーの一貫性を保ちながら個人特定性を除去できます。

1-3. Cloud Armor

AWS WAF/Shieldに相当する、分散型サービス拒否(DDoS)攻撃からの保護とWebアプリケーションファイアウォール(WAF)機能を提供するサービスです。

外部からの悪意あるトラフィック(SQLインジェクション等)をエッジレベルでブロックしますが、環境全体のスキャンや不審なアウトバウンド通信の検出機能は持ちません。
外部アプリケーションロードバランサだけでなく、リージョン内部アプリケーションロードバランサや外部プロキシネットワークロードバランサ(TCP/SSL)にもアタッチできます。ただし「内部アプリケーションを特定のCIDRからのみ許可し、Google CloudネイティブのSYNフラッド保護で足りる」という要件では、VPCファイアウォールルールだけで完結するため、Cloud Armorの導入自体が過剰になります。
レート制限アクションの使い分け: 急増したトラフィックが悪意あるものか不明で、可用性を保ちながらクライアントごとのリクエスト数を一定間隔で制限したい場合はthrottleアクション(閾値までは許可・超過分のみ抑制)を使います。denyアクションは該当トラフィックを単純に全拒否するため、悪性か不明な相手も締め出してしまい可用性要件に反します。
Webアプリ保護の3層役割分担: インバウンドの到達性制限・一般的なWeb攻撃(SQLi/XSS等)防御・内部トラフィックの異常監視を同時に満たしたい場合は、各要件に適切なプロダクトを割り当てます。VPCファイアウォールで許可リスト化されたトラフィックのみを通し(L3/L4の到達性制御)、Cloud Armorの定義済みルールでL7のWeb攻撃をブロックし(WAF/DDoS防御)、Cloud IDSでパケット検査による内部トラフィックの異常検知を行います。

1-4. Cloud KMS

AWS KMSに相当する、暗号鍵の作成・管理・利用を行うマネージドサービスです。

ソフトウェア鍵に加えて、HSM(ハードウェアセキュリティモジュール)保護の鍵やCloud External Key Manager(EKM)を使った外部鍵管理にも対応します。
保存データの暗号化には3方式あります。追加設定不要のデフォルト暗号化(Google管理)、Cloud KMSで鍵を管理するCMEK(顧客管理の暗号鍵)、そしてCloud KMSを介さずリクエストごとに顧客が鍵そのものを提供するCSEK(顧客指定の暗号鍵、Cloud Storage等の一部サービスのみ対応)です。
HSM保護レベルでの鍵生成が必須の場合: 「検証済みHSM内でのみ鍵を生成・保存する」ことがコンプライアンス上義務付けられ、かつ完全マネージドな統合を求める場合は、保護レベルにHSMを指定して新規鍵を作成します(Cloud HSM)。FIPS 140-2レベル3検証済みのハードウェア内で鍵が生成・保管され、Cloud StorageやBigQuery等とCMEKとしてネイティブに統合されます。
Cloud EKMとの違い: サポート対象の外部鍵管理パートナー(SaaS型を含む)上に鍵を置く方式で、鍵の生成・保存自体がGoogle Cloudの外部となります。オンプレミスHSMの自社運用が必須というわけではありませんが、パートナー側のサービス調達・運用が別途必要になるため、上記のHSM要件(Cloud HSM)とは別物です。
Google CloudがFIPS 140-2準拠の暗号化に使う検証済みモジュールはBoringCryptoです。「FIPS 140-2に準拠したい」という要件では鍵の管理方式の選択自体が本質ではなく、保存データと転送データの両方をBoringCryptoで能動的に暗号化することが要点になります(内部IPアドレスを使うVM間通信はGoogle Cloud基盤側で自動的に暗号化されますが、外部IPアドレスを使う通信は対象外です)。
インシデント前の影響軽減: 鍵が侵害された場合の影響を事前に小さくするには、各キーバージョンの有効期間を区切る定期的な自動キーローテーションと、1キーバージョンあたりで暗号化するデータ量の制限を組み合わせます。侵害済み鍵の無効化・取り消しはインシデント発生「後」の対応であり、事前の影響軽減策とは区別します。
暗号シュレッディング: データ本体ではなく暗号鍵を破棄することで、暗号化済みデータを実質的に復元不能にしてPIIを「削除」する手法です。CMEKで鍵を顧客が完全に制御していれば、鍵を破棄するだけでその鍵によって暗号化された全データを復号不能にでき、Google Cloudサービス群とネイティブに統合されるため運用オーバーヘッドが小さく済みます。
制御レベルの最上位: クライアント側暗号化: デフォルト暗号化<CMEK<CSEK(上記3方式)よりもさらに強く鍵を統制したい場合は、Google Cloudへ送信する前にアプリケーション側でデータを暗号化するクライアント側暗号化を、鍵管理用のCloud KMSと暗号化操作用のCloud HSMの組み合わせと併用します。3つを組み合わせることで、鍵の生成から利用まで顧客側で最も強く統制できます。

1-5. フォルダ (Folder)

AWS Organizations OUに相当する、Google Cloudのリソース階層(組織 → フォルダ → プロジェクト → 個々のリソース)における、プロジェクトをグループ化するための中間ノードです。

ラベルとの違い: ラベルはキーバリューのメタデータで主に請求の追跡・フィルタリング用途であり、IAMポリシーの継承には使えません。「共通のIAMポリシーを共有するリソースをグループ化したい」場合はフォルダを使い、配下のプロジェクト・リソースへ自動的に継承させます。
プロジェクトの役割: プロジェクトはリソース整理・IAMアクセス管理・請求の基本単位です。異なるチームのリソースを独立させたい場合は、既存プロジェクトに招待するのではなく専用の新しいプロジェクトを作成します。プロジェクトIDはGoogle Cloud全体で一意です。

1-6. IAM (Identity and Access Management)

AWS IAMに相当する、Google Cloudリソースへのアクセス権限をユーザー・グループ・サービスアカウント単位で制御する仕組みです。

「誰が」「どのリソースに」「どのロールでアクセスできるか」をポリシーとして定義します。事前定義ロール・カスタムロールのどちらも利用可能です。
ベストプラクティスは、個々のユーザーに直接ロールを付与するのではなく、Googleグループにユーザーを割り当て、そのグループにロールを付与する方法です。異動・退職時もグループのメンバーシップを変更するだけで済み、IAMポリシーを個別に更新する必要がありません。
権限の問題を調査したいときは、まずコンソールの「IAM」セクションで割り当てられているロールを確認します。IAMは階層的なので、プロジェクトだけでなくフォルダ・組織レベルで継承されたロールも確認が必要です。
「表示のみ」のロールの使い分け: リソース階層だけを表示させたい場合はroles/browser(ブラウザ)が最小権限で、プロジェクト全体を表示のみでレビューさせたい場合はroles/viewer(閲覧者)が一般的です。
名前の似たroles/iam.roleViewer(ロールビューア)はIAMロールの「定義」を表示するロール、roles/iam.securityReviewerはセキュリティ関連リソースの表示に限定されるロールで、いずれも上記2つとは対象範囲が異なります。
「誰が何にアクセスできるか」を横断的にクエリして監査証拠を作成したい場合はPolicy Analyzer、個別アクセスの可否を診断したい場合はPolicy Troubleshooter、過剰な権限の縮小を提案させたい場合はIAM Recommender、ポリシー変更の影響を事前に検証したい場合はPolicy Simulatorを使います。名前が似た4ツールなので目的で使い分けます。
過剰権限の洗い出し→安全な是正のワークフロー: 大規模環境で過剰な権限を是正したい場合は、まずIAM Recommenderで削減候補を特定し、実際にロールを外す前にPolicy Simulatorで変更後の影響を事前評価してから適用する、2段階のワークフローが定石です。
組織全体の権限管理・監査を引き継ぎたい場合はroles/resourcemanager.organizationAdmin(組織管理者)を使います。名前が似た組織ポリシー管理者(roles/orgpolicy.policyAdmin、組織ポリシー(制約)の設定に限定)とは権限範囲が異なるので注意してください。
フォルダ管理者ロールの使い分け: 特定フォルダの管理権限だけを委譲したい場合はroles/resourcemanager.folderAdmin(フォルダ管理者、リソースの作成・削除等)をフォルダスコープで付与します。名前が似たroles/resourcemanager.folderIamAdminはフォルダ自体のリソース管理を包括するロールではなくIAMポリシーの編集権限に偏ったロールで、付与すると自分自身への権限昇格が可能になってしまうため、同じ用途には使いません。
組織を作成するとroles/resourcemanager.projectCreator(プロジェクト作成者)が全メンバーへ自動付与されます。「特定チームだけがプロジェクトを作成できるようにしたい」場合は、全ユーザーからこのロールを削除したうえで、対象チームのGoogleグループにだけ再付与します。
カスタムロールの2つの成熟度表現: 個々の権限にはSUPPORTED(本番利用可)・TESTING(変更の可能性あり)というサポートレベルがあり、本番用ロールはSUPPORTED権限のみで構成します。ロール自体の成熟度は、これとは別軸のロールのステージ(ALPHA/BETA/GA)で表現します。
時間ベースのIAM条件による期間限定アクセス: 外部監査法人などに「特定の1か月間だけ」読み取り専用アクセスを与え、期間終了後は自動的に失効させたい場合は、Googleグループへのロールバインディングに時間ベースのIAM条件(開始日〜終了日の期間指定)を組み合わせます。期間経過後は自動的にアクセスが無効化され、Cloud Audit Logsでグループメンバー個人の操作も追跡できます。署名付きURL(詳細はストレージ編)は有効期限の上限が短く、1か月の要件には使えません。
タグ+IAM条件によるリソース単位のスコープ: カスタムロールは権限の集合を定義するだけで、対象リソースの絞り込みはできません。特定のタグが付いたリソースにだけロールを適用したい場合は、対象リソースへタグを付与し、ロールバインディングにresource.matchTagを使うIAM条件を組み合わせます。
CEL式による複合条件アクセス: 上記のタグ条件に加え、時間帯やアクセス元ネットワークなど複数の要因を組み合わせて判定したい場合は、IAM条件のCEL式でrequest.time(時間帯)・resource.matchTag(リソースタグ)・request.auth.access_levels(Access Context Managerのアクセスレベル)をAND条件として組み合わせます。コンピューティング編でも、この仕組みを使って本番VMへのSSHを複合条件で絞る例を扱っています。
大規模組織での過剰権限の防止と検出: 数千プロジェクト規模で過剰な権限付与を防ぎたい場合は、組織ポリシーと最小権限のIAM設計による予防と、SCC PremiumのSecurity Health Analyticsによる検出を両輪で運用します。

1-7. Identity-Aware Proxy (IAP)

AWS Verified Accessに相当する、ユーザーの認証・認可に基づいてアプリケーションへのアクセスを制御するサービスです。主に内部アプリケーションや特定のユーザーグループへのアクセス制御に使われます。

不特定多数向けの一般公開ウェブサイトのセキュリティ確保には、通常は外部HTTP(S)ロードバランサ+マネージドSSL証明書の組み合わせの方が適しています。
VPNなしでインターネット経由にアプリを公開しつつ、許可したGoogleグループのメンバーだけにアクセスを絞りたい場合にも使います。Googleアカウントの2段階認証プロセスをそのまま活用できます。
IAPは「HTTPSリソース向け」と「SSH/TCPリソース向け」で構成対象が異なります。SSHアクセスを保護したい場合は後者を構成します。
IAP for TCP forwardingを使うと、Compute Engineインスタンスへ公開IPアドレスなしでSSH接続できます(gcloud compute ssh --tunnel-through-iap)。VPCファイアウォールでIAPの外部IPアドレス範囲(35.235.240.0/20)からのポート22を許可する必要がありますが、踏み台ホストを自前運用するより外部IP課金やパッチ管理コストがかかりません。
バックエンドアプリケーションが「IAP経由のトラフィックのみ受け入れる」ことを保証したい場合は、IAPが付与する署名付きJWT(X-Goog-IAP-JWT-Assertionヘッダー)をアプリ側で検証します。Googleの公開鍵で署名・発行元・対象者を確認すれば、IAPを迂回した直接アクセスを排除できます(X-Goog-Authenticated-User-*のような署名なしヘッダーの検証だけでは保証できません)。
SIEM連携による侵入検知: IAPで保護したアプリへのアクセス試行(認可された到達・拒否された試行の双方)を監視して不審な兆候を検知したい場合は、データアクセス監査ログ(iap.googleapis.com、既定で無効)を分析対象にします。管理アクティビティログはIAP自体の構成変更が対象で、日常的なアクセス試行そのものは記録しません。
グループ+内部IPの複合条件でのアクセス制御: 特定のGoogleグループのメンバーであり、かつ社内IPレンジからのアクセスに限定したい場合は、Access Context ManagerでグループメンバーシップとIPレンジの両方を条件とするアクセスレベルを作成し、そのアクセスレベルをIAPポリシーへ適用します。

1-8. Workload Identity Federation for GKE

AWSのIRSA(IAM Roles for Service Accounts)に相当する、GKE内のKubernetes ServiceAccountをGoogleサービスアカウントにマッピングすることで、PodがGoogle Cloudリソースへ安全にアクセスできるようにする機能です。

サービスアカウントキー(静的で長期的な認証情報)をPodにマウント・配布する必要がなくなるため、組織ポリシーでサービスアカウントキーの使用が禁止されている場合の推奨されるほぼ唯一の方法です。ノードのデフォルトサービスアカウントに権限を付与する方式は、同一ノード上の全Podが権限を持ってしまい最小権限の原則に反します。

1-9. Workload Identity Federation (オンプレミス・他クラウド向け)

GKE以外の、データセンターのベアメタルサーバーやAWS/AzureなどGoogle Cloudの外部で動くワークロードからGoogle Cloud APIを呼びたい場合の話です。

外部IdP(Active Directory、AWS/Azureのアイデンティティ、GitHub/GitLabのOIDCトークンなど)が発行する認証情報を、キーファイルを発行せずにGoogle Cloudの短期アクセストークンと交換できます。サービスアカウントのキーファイルでも認証自体は可能ですが、漏洩・長期有効性のリスクがあるため、公式ドキュメントはWorkload Identity Federationを優先し、キーファイルは使えない場合の代替とする優先順位を明示しています。
オンプレミスAD FS(OIDC)との連携: オンプレミスのActive Directory Federation Services (AD FS)をOIDCプロバイダとして構成している場合も、Workload Identity Federationのプールへ外部IdPとして登録できます。アプリはAD FSから取得したOIDCトークンをSTS(Security Token Service)API経由でGoogle Cloudの短命アクセストークンへ交換し、権限借用は特定のサブジェクトにのみ許可することできめ細かな制御を実現できます。

1-10. サービスアカウントの権限借用 (Service Account Impersonation)

AWSのAssumeRoleに相当する、ユーザーアカウントがサービスアカウントの権限を一時的に借りてAPI呼び出しを行う機能です。借用元のユーザーには対象サービスアカウントへのroles/iam.serviceAccountTokenCreatorロールが必要で、コマンドには--impersonate-service-accountフラグを付与します。

サービスアカウントキーをローカルにダウンロードせずに済むため、権限のテストにはGoogleが推奨する最もセキュアな方法です。
CI/CDでも、単一の広範な権限を持つサービスアカウントを使い回さず、パイプラインごとに専用のサービスアカウントを用意して最小限のロールだけを付与します。
なおCompute EngineインスタンスからAPIへ最小権限でアクセスする基本形は、権限借用ではなく、必要最小限のロールを持つサービスアカウントをVMにアタッチし、アプリケーションがインスタンスメタデータサーバーから短命の認証情報を自動取得する構成です(サービスアカウントキーをディスクに保存せずに済みます)。
最小権限+期間限定アクセス: 「常に最小権限」かつ「問題調査の期間中だけアクセスできる」ことを両立したい場合は、制限された閲覧権限のみを持つ専用サービスアカウントを作成し、対応チームにはそのサービスアカウントへのroles/iam.serviceAccountUserを付与します。チームは普段は強い権限を保持せず、調査が必要なときだけそのサービスアカウントを借用して限定的な作業を行えます。

1-11. Application Default Credentials (ADC)

ローカル開発環境でよく使われる認証の仕組みで、Google Cloudのクライアントライブラリが自動的に認証情報を見つけるための共通の置き場所・探索ロジックです。gcloud auth login(gcloud CLI自体のログイン)とは別物で、通常はgcloud auth application-default loginコマンドでローカルにADCファイルを作成します。

ユーザー自身の権限でAPIにアクセスするものであり、本番環境でアプリケーションが実際に使用するサービスアカウントの権限を代替してテストすることはできません(その用途は前述のサービスアカウントの権限借用)。

1-12. Secret Manager

AWS Secrets Managerに相当する、APIキー・パスワード・証明書・サービスアカウントキーなどの機密情報(シークレット)を安全に保存・管理するためのサービスです。

シークレットのバージョン管理、IAMによるきめ細かいアクセス制御、アクセス監査ログを提供します。アプリケーションやCI/CDパイプラインは実行時にAPI経由で必要なシークレットを取得でき、コードやマニフェストへの平文埋め込みを回避できます。
シークレットへのきめ細かいアクセス制御・環境分離・鍵ローテーションの制御を両立したい場合は、本番・非本番のシークレットを別々のGoogle Cloudプロジェクトに分けて保存し、プロジェクトレベルのIAMで制御したうえでCMEK(顧客管理の暗号鍵)で暗号化する構成が定石です。単一プロジェクトへまとめると環境分離を満たせず、Google管理の暗号鍵では鍵のローテーションスケジュールを顧客側で制御できません。

1-13. Cloud Audit Logs

AWS CloudTrailに相当する、管理アクティビティやデータアクセスなどのイベントを記録する監査ログです。

Cloud Loggingを通じて閲覧・エクスポートできる、種別ごとのログで構成されます。

種別	記録内容	デフォルト
管理アクティビティ	リソースのメタデータ・構成変更(VM作成、IAMポリシー変更など)	常に有効
データアクセス	BigQueryテーブルやCloud Storageオブジェクトの読み取りなど、ユーザーデータへのアクセス	サービスにより無効(要有効化)
システムイベント	VMの起動/停止などGoogle Cloud自身の自動処理	常に有効

「退職した従業員が機密データにアクセスしたか」のようにデータそのものへのアクセスを追跡したい場合は、データアクセス監査ログの明示的な有効化が必要です。外部監査人へのログレビュー権限にはroles/logging.privateLogViewer(プライベートログ閲覧者)を付与します。このロールはデータアクセス監査ログに加え、後述のAccess Transparencyログへのアクセスも制御できます(1-20)。

IAMロールの割り当て履歴を調べたい場合は、管理アクティビティログをLogs ExplorerでSetIamPolicyメソッドフィルタして確認します(各サービスのコンソールは現在の設定しか表示しません)。

「BigQueryへの書き込みがすべて特定のサービスアカウントによるものだったか」のように、ある主体以外による操作がなかったことを確認したい場合は、対象の操作にフィルタをかけたうえで検証対象の主体に一致するエントリを非表示(除外)にし、残ったリストが空であることを確認します。一致するエントリを表示して件数を見る手順は論理が逆になる点に注意してください。

ログのデータレジデンシー: Cloud Loggingのデータ所在地はログバケットのリージョンで決まり、既定の_Defaultバケットはグローバルに保存されます。「ログを特定地域(例: 欧州)内に保持したい」という規制要件がある場合は、対象リージョンを指定した新しいログバケットを作成し、_Defaultシンクの宛先をそのバケットへリダイレクトします。ログバケットのカスタム保持期間の上限は**3650日(10年)**で、これを超える長期保持が必要な場合はCloud Storageへの長期エクスポートを併用します。

1-14. VPC Service Controls

AWS側に直接の対応サービスがない、BigQueryやCloud Storageなど機密性の高いGoogle Cloud APIの周囲に仮想的なセキュリティ境界(サービスペリメタ)を設定し、データの持ち出し(exfiltration)を防止する機能です。

IAMによるアクセス制御とは独立したレイヤーであり、たとえ正当な認証情報が漏洩しても境界外へのデータ持ち出しを防ぐ「多層防御」として機能します。
アクセスレベル(Access Levels)によるネットワーク単位の制限: 保護対象プロジェクトを含むサービスペリメタを作成し、Access Context Managerでアクセスレベル(オフィスネットワークのCIDR範囲などの条件)を境界に適用すると、IAM権限を正しく持つユーザーであっても、許可されていないネットワークからのAPI呼び出しを遮断できます。VPCファイアウォールルールはVM宛ての通信制御であり、インターネット経由で直接呼び出されるAPIへのアクセス制限には効きません。
Gemini Enterprise Agent Platform/Workbenchの保護対象API: AIプラットフォームやノートブック環境からのデータ引き出しを防ぎたい場合、サービス境界の保護対象サービスに**aiplatform.googleapis.com(Gemini Enterprise Agent Platform)とnotebooks.googleapis.com**(Workbench)を含めます。ml.googleapis.comは旧AI Platformのエンドポイントで、現行サービスの保護対象としては使えないので混同しないよう注意してください。
サービス境界は境界内のプロジェクト間では自由な通信を許可しつつ、境界外への通信をデフォルトで遮断します。「データ流出は防ぎたいがプロジェクト間の通信は制限したくない」という要件には、対象プロジェクトすべてを単一の境界に含めます(複数の境界に分割すると境界をまたぐ通信もブロックされてしまいます)。
Shared VPC構成でのアクセス拒否トラブルシュート: Shared VPCのサービスプロジェクトにあるCompute Engineインスタンスから、VPC SCで保護された別プロジェクトのBigQuery等へのアクセスが拒否される場合、原因の多くは「呼び出し元のインスタンスが存在するサービスプロジェクトが境界に含まれていない」ことにあります。ネットワークを共有するホストプロジェクトだけを境界に追加しても、API呼び出しの主体であるサービスプロジェクトが境界外のままでは拒否が続くため、インスタンスが存在するサービスプロジェクト自体を同じ境界に追加する必要があります。
アクセスレベル(送信元IP)によるAPI単位のアクセス制限: IAM権限を持つユーザーであっても、特定の送信元IPアドレス範囲以外からのAPI呼び出し(例: BigQueryへの直接クエリ)を拒否したい場合は、Access Context Managerで承認済みIPレンジを条件とするアクセスレベルを作成し、保護対象のサービス境界に適用します。Cloud Armorはロードバランサ前段のL7防御であり、BigQuery等のAPIへの直接アクセスの制御には使えません。社内ネットワークと会社管理VPNの両方から許可したい場合は、社内IPレンジに加えVPNが動的に払い出すIPプールのレンジもアクセスレベルの条件へ含めます。
境界外IDへの最小権限アクセス(イングレスポリシー): 境界外のプロジェクト・IDから特定のAPIメソッドだけに限定してアクセスを許可したい場合は、イングレスポリシーを使います。送信元ID(境界外のプロジェクトやサービスアカウント)と許可するAPIメソッドを個別に絞り込めるため、境界間の通信を一律に許可するペリメータブリッジより広く開けすぎず最小権限を維持できます。
境界間の一方向データコピー: 2つの境界間でデータのコピーを一方向にだけ許可したい場合は、コピー元の境界にegress(送信)ルール、コピー先の境界に対応するingress(インポート)ルールを組み合わせます。双方向かつ粒度の粗いペリメータブリッジは、両境界間の通信を一律に許可してしまうため、一方向限定の要件には過剰です。
egressルールを構成しないこと自体を防御にする: 機密データを扱うAI環境で境界外へのコピーと外部からの取り込みの両方を同時に遮断したい場合は、対象サービスを同一のサービス境界に収容し、あえてegress(送信)ルールを一切構成しません。egressルールが存在しなければ境界外への通信経路自体が生まれないため、「許可ルールを作らない」ことがそのまま防御になります。前述の一方向コピー(egress+ingressの組み合わせ)とは異なり、こちらは「どこにもegressしない」こと自体が目的です。
範囲限定ポリシー(Scoped Policy)による管理の委任: 組織全体のアクセスポリシーを一元管理しつつ、特定フォルダ・プロジェクトの境界設定だけを担当チームへ委任したい場合は、組織レベルのポリシーとは別に範囲限定ポリシーを作成して対象フォルダ・プロジェクトを含め、roles/accesscontextmanager.policyEditorをそのポリシーへスコープして委任します。委任先チームの権限は組織全体ではなく、そのポリシーの範囲内に閉じます。個別に厳密保護したいプロジェクトでは、そのポリシー配下で制限されたサービス=すべてのサービス、VPCアクセス可能なサービス=選択したサービスと設定すれば、許可したAPI以外は境界内でも使えなくなります。
デバイスポリシーをペリメータへ適用: OSパッチの適用状況やアンチウイルスの実行状態など、デバイスの準拠状態も境界の許可条件に含めたい場合は、Context-Aware Accessのデバイスポリシー条件を含むアクセスレベルを作成し、サービスペリメタへ適用します。

1-15. 組織ポリシー (Organization Policy)

AWS Organizations SCPに相当する、組織・フォルダ・プロジェクト単位でリソースの設定に対する制約(Constraint)をかける仕組みです(例: 外部IPの割り当て禁止、特定リージョン外でのリソース作成禁止など)。

ファイアウォールルールの適用には使用できません(通信制御が目的なら階層型ファイアウォールポリシー)。「誰が何にアクセスできるか」を制御するIAMとも異なり、「(許可された人でも)何ができるか」というガードレールを設定するものという位置づけです。
具体例としてconstraints/iam.allowedPolicyMemberDomains制約を組織レベルで設定すると、許可した組織ドメイン以外のGoogleアカウント(個人の@gmail.comなど)がIAMポリシーに追加されるのを防げます。
ドメイン制限共有への例外追加: この制約を有効化したまま、外部パートナー企業のユーザーにだけアクセスを許可したい場合は、制約をオフにするのではなく、ポリシー値をカスタムに設定し、各パートナーのCloud IdentityまたはGoogle Workspaceの顧客IDを許可値として例外追加してから制約を再度オンにします。Googleグループを例外値として登録する方式はサポートされていません。
部門ごとに異なるポリシーを適用したい場合はフォルダレベルで設定します。フォルダレベルのポリシーは、配下のプロジェクトのオーナーが変更・削除できません。
制約は遡及適用されません。設定した時点より未来の変更にのみ適用されるため、既存の違反状態(ドメイン外ユーザーの既存IAMバインディング等)は自動的に削除されません。制約の設定に加えて、既存の違反を手動で事後的に削除する対応が必要です。
サービスアカウントキーの統制にも使えます。constraints/iam.serviceAccountKeyExpiryHoursでキーの最大有効期間を強制したり、constraints/iam.disableServiceAccountKeyCreationで特定プロジェクトを除きキー作成自体を禁止したりでき、いずれもコード不要の予防的統制です。
特定VMだけに外部IPを許可(compute.vmExternalIpAccess): 過去の構成ミスでインターネットに公開すべきでないVMに外部IPが割り当てられた、といった事故の再発を防ぎたい場合、この制約でフロントエンドVM等の許可リストのみ外部IPの構成を認めます。
特定リージョン以外でのリソース作成を禁止(constraints/gcp.resourceLocations): Interconnectを確立した特定リージョンにのみ全ワークロードのデプロイを限定したい場合など、組織レベルでこの制約を構成し許可リージョンのみを許可リストに載せると、リスト外のロケーションでのリソース作成リクエストが作成時点でシステム的に拒否されます。フォルダ・プロジェクトへ継承されるため将来作成されるプロジェクトにも自動適用されます。この制約はあくまで今後の新規作成を防ぐ予防策で、適用前から存在する対象リージョン外の既存リソースは自動的には是正されないため、移行・削除は別途手動で対応する必要があります。
- フォルダレベルでの適用(複数ロケーションの共存): 「同一組織内でもフォルダ構造ごとに異なるデータレジデンシーロケーションを許容したい」場合は、この制約をフォルダレベルで設定します(組織レベルでは全体に単一ロケーションが強制され複数ロケーションを共存できません)。
ドライランモード: 新しい制約を本番へ適用する前に、実際の拒否は発生させず「どのリクエストが拒否されるか」だけを事前に確認したい場合は、ポリシーのdryRunSpecに設定を記述します。実際に適用されるspecとは別にdryRunSpecをログのみで評価でき、影響範囲を安全に把握できます。
inheritFromParent: falseによるポリシー継承の遮断: 特定のフォルダ・プロジェクトだけ親の制約を無視して独自のポリシーを適用したい場合は、子のポリシーでinheritFromParent: falseを設定します。親のポリシーとマージされるのではなく、子のポリシーが親を完全に置き換えます。
共有VPCホストプロジェクトの許可範囲をフォルダ単位で限定(constraints/compute.restrictSharedVpcHostProjects): 「特定フォルダ配下のプロジェクトだけを、特定の共有VPCホストプロジェクトに接続可能にしたい」場合は、この制約をフォルダレベルで設定し、許可値にunder:folders/FOLDER_ID形式で、ホストプロジェクトが置かれたネットワークフォルダを指定します(ホストプロジェクト自体を直接指定するわけではありません)。組織レベルで設定すると影響範囲が組織全体に及んでしまいます。

1-16. ログシンク (Log Sink)

AWSのCloudTrailへの配信設定に相当する、Cloud Audit LogsやCloud Loggingのログを、Cloud Storage・BigQuery・Pub/Subなど指定した宛先へルーティングするための設定です。組織・フォルダ・プロジェクトいずれのレベルでも構成できます。

プロジェクトレベルで構成すると、そのプロジェクトのオーナーがログシンクを削除・無効化できてしまいます。「プロジェクトユーザーが削除できないようにしたい」場合はフォルダレベル(または組織レベル)で構成する必要があります(組織ポリシーと同様の階層構造上の性質です)。
宛先にPub/Subトピックを設定し、会社のSIEMシステムをそのトピックのサブスクライバーとして追加すれば、監査ログをリアルタイムでSIEMへ連携できます。カスタムのエクスポート処理を自前開発するより、開発・運用コストを抑えられます。
フォルダレベルの集約シンクで「配下だけ・将来分も自動」: 特定フォルダ配下の本番プロジェクトだけ(他プロジェクトのログは含めず)のログを、将来作成される本番プロジェクトも含めて自動的に1箇所へ集約したい場合は、その**フォルダに集約シンク(集約エクスポート)**を作成します。集約シンクの対象範囲は作成したリソース階層の配下すべてなので、フォルダに作れば配下の既存・将来のプロジェクトが自動的に対象となります。組織ルートに作ると対象外プロジェクトのログまで含まれてしまい、プロジェクトごとの個別シンクでは新規プロジェクトに自動追随できません。
組織レベル集約シンクでのincludeChildren: 数百プロジェクト規模で組織全体のログを1本のシンクに統一集約したい場合は、組織レベルでincludeChildrenパラメータを有効にした集約シンクを作成し、宛先をPub/SubにすればほぼリアルタイムでオンプレミスSIEM等へストリーミングできます。includeChildrenを指定しないと配下プロジェクトのログは集約されません。
コンソールへのログインイベントの取り込み: 監査対象を「コンソールへのログイン」まで広げたい場合、この種のイベントはGoogle Cloudの通常の監査ログではなくGoogle Workspace/Cloud Identity側のログイン監査に記録されます。Admin Consoleで「Google Workspace監査ログをGoogle Cloudと共有する」設定を有効化しないと、ログシンクの集約対象に含まれません。
プッシュベースかつ耐障害性の高いオンプレミスSIEM連携: 複数クラウドにまたがる組織で、オンプレミスSIEMへほぼリアルタイム・プッシュベースでログをエクスポートしつつフォールトトレランスも満たしたい場合の定番パターンは「組織レベルの集約シンク→Pub/Sub→Dataflow」です。集約シンクで全プロジェクトのログをPub/Subトピックへ送り、プライマリのDataflowパイプラインでSIEMへプッシュ配信し、失敗したメッセージはセカンダリのDataflowパイプラインで再処理します。
ログビュー(Log View)による露出最小限の共有: オンプレミスSIEMに一部のログだけを見せたいがデータ露出は最小限に抑えたい場合は、ログシンクでの外部エクスポート(データのコピーが増える)ではなく、ログバケット内の一部だけを限定閲覧させるログビューを定義し、そのビューにだけアクセスを付与します。SIEM担当者が人間のユーザーで社外のIdPを持つ場合は、Workforce Identity 連携(1-33)で鍵レスにアクセスを付与できます。

1-17. Identity Platform

Cognitoに相当する、一般消費者向けアプリケーションのユーザー認証とアクセス管理(CIAM)を提供するサービスです。

ユーザー名/パスワード管理、多要素認証、ソーシャルログインなどに対応しています。

1-18. Cloud Identity

IAM Identity Center(旧 AWS SSO)に相当する、組織の従業員(ワークフォース)のアカウントやデバイスを一元管理するためのIDプロバイダ(IdP)です。

外部の一般アプリユーザー管理には使用しません(その用途はIdentity Platform)。Identity Platformが顧客向け、Cloud Identityが社内従業員向けという役割分担です。
Google Workspaceを従業員アカウント管理に使っている場合、その従業員IDはすでにCloud Identity上に存在します。
オンプレミスのADを正として維持する場合: パスワードやID管理の正をオンプレミスのActive Directoryに残したい場合は、Google Cloud Directory Sync(GCDS)でADのユーザー・グループをCloud Identityへ一方向に同期します。GCDSが行うのはユーザー情報の同期のみでパスワード自体は複製されないため、認証(パスワード検証)は別途SAML SSOでAD側のIDプロバイダへ委任する必要があります(SAMLの役割分担は後述)。
Microsoft Entra ID(Azure AD)を正とする場合: オンプレミスADではなくMicrosoft Entra IDをID管理の正として使っている場合、GCDSはLDAPプロトコルを前提とするため、クラウド専用ディレクトリであるEntra IDを直接の同期元にはできません。Google公式が案内する構成は、Azure MarketplaceのMicrosoft製ギャラリーアプリ「Google Cloud/G Suite Connector by Microsoft」によるEntra ID側の自動プロビジョニング機能で、Cloud Identityへユーザー・グループを同期します(このコネクタはMicrosoft製でGoogleのサポート対象外です)。なおこの機能はアカウントの作成・停止・同期(プロビジョニング)を扱うもので、後述のWorkforce Identity 連携(1-33、認証フェデレーションのみでライフサイクル管理は行いません)とは役割が異なります。
G Suite/Workspaceユーザーはそのまま使える: 組織がすでにG Suite(現Workspace)を使っているなら、そのメールアドレスをそのままIAMポリシーのプリンシパルとして追加するだけでアクセス権を付与できます。
サードパーティSSOプロバイダとのSAML統合: 会社が独自のSAML IdPを持つ場合、「会社のSSOプロバイダ = IdP」「Cloud Identity = SP(サービスプロバイダ)」という役割になります。Cloud IdentityでサードパーティIdPとのSSOをセットアップするのが正しい構成です。
競合アカウント(Conflicting Accounts): 従業員が会社ドメインで個人のGoogleアカウントを先に作っていると、管理アカウントと競合します。対象ユーザーに既存アカウントの**移行(トランスファー)を依頼して解消します。ドメイン全体で未管理の個人アカウントを一括で洗い出し、転送をリクエストしたい場合は、Google推奨のTransfer Tool for Unmanaged Users(TTUU)**を使います。
サードパーティIdPとSAML SSOを構成している環境では、ユーザー認証はIdP側で行われるため、パスワードポリシーはCloud Identity側ではなくAD(IdP)側で強制します。
アカウント侵害リスクを最小化する2段階認証は、SMS・電話による確認コードよりも、フィッシング耐性の高い**セキュリティキー(FIDO/WebAuthn)**をSSO後の認証に使う方が堅牢です。
Google Workspace管理コンソールでのグループ外部メンバー制限: 各アプリチームがGoogle Cloudコンソール経由で自チームのGoogleグループを自主管理する環境で、外部ユーザーの追加を防ぎたい場合は、Google Workspace管理コンソールでグループの共有設定(メンバー制限)を変更します。グループメンバーシップはIAMとは別レイヤーでCloud Identity/Workspace側が管理するため、IAMポリシーでは制御できません。
既存ユーザーへのパスワードポリシー適用漏れ: パスワードの長さ要件を組織のパスワード管理設定で定義しても、既存ユーザーは要件未満のパスワードのままログインできてしまいます。Admin Consoleで「次のサインイン時にパスワードポリシーを強制する」を選択すると、次回ログイン時に基準を満たすパスワードへの変更を強制できます。
スーパー管理者アカウントの保護: スーパー管理者アカウントにはセキュリティキー(FIDO/WebAuthn)による2段階認証を必須化し、日常のIAM運用は個別の委任ロールを持つ別アカウントで行います。スーパー管理者自体は緊急時専用のブレークグラスアカウントとして温存し、通常業務では使用しません。

1-19. Google Workspace

AWS側に直接の対応サービスがない、組織の従業員向けグループウェア・コラボレーションツールです。

一般消費者向けアプリの認証基盤としては使用しません。

1-20. Access Transparency と Access Approval

AWS側に直接の対応サービスがない、Googleサポート担当者による顧客データへのアクセスを可視化・統制する2つのサービスです。

Access Transparencyは、Googleのサポート・エンジニアが顧客データやリソースにアクセスした操作を、ほぼリアルタイムのログとして可視化します。「Google社内の担当者がデータにアクセスできること自体への懸念」を統制したい場合、まずこのログで可視化します。
Access Approvalは、サポートケースの解決等でGoogle側がデータアクセスを必要とする際、そのアクセスを組織側が明示的に承認できるようにします。Access Transparencyの可視化に加えて事前承認を必須化したい場合はこちらを併用します。
承認操作を行うにはroles/accessapproval.approverロールが必要です。IAMの一般的なベストプラクティスと同じく、個々のユーザーへの直接付与ではなく、Googleグループへユーザーを追加してそのグループにロールを付与する方法が推奨されます。
カスタム署名キーを外部HSMに保持したい場合: コンプライアンス上、Access Approvalのカスタム署名キーをGoogle Cloud外部のHSMに保存することが義務付けられている場合は、外部HSMで署名キーを作成し、そのHSMをCloud EKMと統合してプロジェクト内で参照可能にしたうえで、そのキーをAccess Approvalの署名キーとして設定します。Cloud KMSで作成した鍵はインポート鍵も含め最終的にGoogle Cloud内に保持されるため、この要件は満たせません。
有効化は組織レベルのみ: Access Transparencyはプロジェクト単位では有効化できず、組織レベルでのみ有効化できます。データアクセス監査ログ(1-13)も含め、いずれもGoogleサポート担当者自身の操作は対象外です。

1-21. Audit Manager

AWS Artifactに相当する、自社のGoogle Cloud環境を各種コンプライアンスフレームワークに対して評価・監査するための製品です。

「Compliance Reports」機能を使うと、Google Cloud基盤自体がC5:2020・CSA STAR・FedRAMP CRM・IRAP・ISO/IEC 27001:2022・27018:2019などについて第三者監査を受けた認証レポートを、コンソールからセルフサービスで公式にダウンロードできます(ダウンロードにはroles/auditmanager.auditorロールが必要)。監査人への提出資料として利用できます。
名前が似ているCloud Audit Logs(1-13)は自社リソースに対する操作ログの記録機能で、Google基盤側の認証レポートを提供するAudit Managerとは役割が異なります。

1-22. 共有責任モデル(IaaS/PaaS/SaaS)

AWSと同様、クラウドのセキュリティ責任はサービス形態(IaaS/PaaS/SaaS)に応じてGoogleと顧客の間で分担されます。上位の形態(SaaS)になるほどGoogleが担う範囲が広がり、顧客の責任は上位層に集中します。

SaaS(Google Workspace等): ネットワークセキュリティを含む基盤の大部分をGoogleが組み込みで提供・運用します。顧客はVPCやファイアウォール、ロードバランサ前段のCloud Armorのようなネットワーク制御を構成する対象リソース自体を持ちません。
PaaS(App Engine等): Googleがインフラ・ホストOS・ランタイム・スケーリングを管理します。ゲストOSのパッチ適用やデフォルト暗号化としての保存データの暗号化はGoogle側が自動的に適用する範囲で、顧客が主責任として焦点を当てるべきはアプリケーションコードそのものの安全性(XSS・SQLインジェクション等の実装脆弱性への対策)とアプリが扱うデータの取り扱いです。
IaaS(Compute Engine等): ネットワーク構成(VPC・ファイアウォール)やゲストOSのパッチ適用まで顧客の責任範囲に含まれます。

1-23. HIPAA対応(事業提携契約とコンプライアンス対象製品)

医療データ(PHI)をGoogle Cloudで扱いHIPAA等のプライバシー監査に合格するための前提は2点です。

①事業提携契約(BAA)をGoogle Cloudと締結すること。②アーキテクチャで使用する各サービスが、Google Cloudコンプライアンスページのコンプライアンス対象製品リスト(BAA対象)に含まれるかを検証すること。
認証機能(Firebase Authentication等)やプライベートクラスタといった個別のセキュリティ機能は有効な技術的対策ではあっても、この2点の法的・手続き的な前提の代わりにはなりません。

1-24. PCI DSS(スコープ削減と責任分界)

クレジットカード情報を扱う環境に求められるPCI DSSでは、監査範囲の管理とGoogle・顧客の責任分界の把握が実務上のポイントになります。

PCI DSSの監査負荷を下げる王道は、カード会員データ環境(CDE)を無関係なシステムから明確に分離することです。同一プロジェクトにカード決済系・Webアプリ・データ処理系が混在している場合、CDEを専用のGoogle Cloudプロジェクトへ分離すれば監査対象をCDEプロジェクトに限定できます。多要素認証・VPN・PA-DSS認定アプリの利用はセキュリティの強化策であり、監査スコープ自体を縮小する効果はありません。
PCI DSSはCDE内のすべての発信(egress)トラフィックを認可済み接続のみに制限することを求めます。Compute EngineとGKEはVPCファイアウォールルール(GKEはNetworkPolicyも)で下りトラフィックを認可済みに制御でき、追加の補償的コントロールなしにこの要件を満たせます。App EngineやCloud Run(functions含む)も、Direct VPC egressまたはServerless VPC Accessコネクタ経由でegress設定を有効にしたうえで、ネットワークタグやサービスアカウントを条件にしたVPCファイアウォールルールを設定すれば、同様に追加の補償的コントロールなしにこの要件を満たせます。
Googleが担うPCI DSSコントロールを特定したい場合は、Google Cloudが公開する**顧客責任マトリックス(Shared Responsibility Matrix)**を参照します。PCI DSS要件文書自体やPCI SSCのクラウドコンピューティングガイドラインは基準・指針を定義する一般文書であり、Google固有の責任分担までは示しません。

1-25. Model Armor

Bedrock Guardrailsに相当する、生成AIアプリケーションのプロンプトとレスポンスの両方をスクリーニングするサービスです。

プロンプトインジェクション・ジェイルブレイクの検出、有害コンテンツフィルタ、機密データ検出、悪意あるURL検出をテンプレートとして定義でき、任意のモデル(Gemini以外も含む)へREST API経由で適用できます。モデルを切り替えてもポリシーを一元管理できます。
名前が紛らわしい**Cloud Armor(1-3)はSQLインジェクション等L7のネットワーク攻撃やDDoSからエッジで保護するWAFで、自然言語による意味的操作であるプロンプトインジェクションは検出できません。PIIなど機密データの検出・マスキングが主目的のSensitive Data Protection(1-2)**とも役割が異なります。

1-26. OAuth 2.0 による委任された認可(サードパーティ連携)

自社APIが持つデータへ、ユーザーの認証情報を渡すことなくサードパーティアプリからのアクセスを許可したい場合(委任された認可、delegated authorization)は、業界標準プロトコルのOAuth 2.0互換のアクセス制御を構築・活用します。

リソース所有者の同意に基づきスコープを限定したアクセストークンを第三者アプリへ発行でき、必要に応じて取り消せます。
認証(Authentication)はSAML/OpenID Connect、認可の委任(Authorization delegation)はOAuthという役割分担で判断します。**SAML SSO(1-18)**は「誰であるか」を確認するフェデレーション認証の仕組みであり、サードパーティへのきめ細かな権限委任(認可)は担いません。

1-27. Chrome Enterprise Premium (ゼロトラストアクセス)

AWSに単一の対応サービスはなく、AWS Verified Access(1-7のIAPに相当)に近い機能を、複数のGoogle Cloudサービスを組み合わせて実現する製品です。VPNなしで社内アプリケーションへのゼロトラストアクセスを実現します。

IAP(1-7)(HTTPS/SSHリソースへの認証プロキシ)・IAM・Access Context Manager(デバイスの状態・場所などのアクセスレベル定義)・Endpoint Verification(Chrome拡張によるデバイス情報収集)の4つのGoogle Cloudサービスを組み合わせ、ネットワーク境界ではなく個々のデバイス・ユーザーに対してアクセス制御を課します。
VPNはネットワークへの接続を許可する境界型モデルであるのに対し、Chrome Enterprise Premiumはアクセスのたびにユーザーの身元とデバイスコンテキストを検証します。VPNゲートウェイの運用負荷やレイテンシを避けつつ境界型からゼロトラストへ移行したい場合の選択肢になります。IPアドレス範囲によるファイアウォール制御は接続元の多様なリモートワーカーに対応できず、ゼロトラストへの移行にはなりません。
企業発行デバイス・証明書による制御: 「企業発行の管理対象デバイスで、有効なエンタープライズ証明書を保持している場合のみアクセスを許可したい」という要件には、**証明書ベースのアクセス(CBA)**のアクセスレベルを作成し、アクセスバインディングで適用します。Endpoint Verificationはデバイスの属性(OSバージョン・ディスク暗号化等)を収集する仕組みであり、証明書そのものを条件とするのはCBAの役割です。

1-28. Key Access Justifications (KAJ)

AWS側に直接の対応サービスがない、暗号鍵への各アクセス要求(復号リクエスト等)ごとに、Google側のシステムやサポート担当者がアクセスを必要とした理由(justification)を提示させ、その可否を顧客側で承認・拒否できる機能です。

デジタル主権(Digital Sovereignty)の文脈で語られることが多く、「すべての暗号化キーリクエストの可視性」が求められる要件に対応します。
CMEK(1-4)は鍵のライフサイクル管理、Cloud EKMは鍵を外部に保持する仕組みで、KAJはそれらとは役割が異なり鍵アクセス要求そのものの可視化・正当化を担います。「完全なライフサイクル管理+すべてのリクエストの可視性」という2軸の要件は、CMEKとKAJの組み合わせで満たします。
**Access Transparency/Access Approval(1-20)**は「Google担当者による顧客データへのアクセス」全般の可視化・事前承認が対象で、暗号鍵リクエスト自体の可視化に特化したKAJとは対象範囲が異なります。

1-29. Assured Workloads

AWS側に直接の対応サービスがない、規制プログラム(FedRAMP、各国の主権要件等)に応じて、データ所在地・データアクセス制御・Googleサポート/運用要員の地理的制限・暗号化要件などの統制を管理境界としてパッケージで一括適用できる機能です。

「データレジデンシー」「データアクセス制御」「データが存在する地理と同じ場所からのサポート提供」のように複数の規制要件を同時に満たす必要がある場合の定石です。リージョン限定デプロイ単独ではデータ所在地の一部しか満たせず、サポート要員の地理制限やアクセス制御は別途手当てが必要になります。
医療データ等の規制三点セット: 「データ所在地」「機微な管理アクションへの明示承認」「アクセスの監査可能性」を同時に満たしたい場合は、Assured Workloads(承認リージョンへのデプロイで所在地を強制)+Access Approval(1-20)(機微操作への事前承認)+Cloud Audit LogsとAccess Transparency(監査・Google担当者アクセスの可視化)を組み合わせます。HIPAA対応で必要な**事業提携契約(BAA)とコンプライアンス対象製品の確認(1-23)**とは別の統制レイヤーで、両方をあわせて満たす必要があります。

1-30. Privileged Access Manager (PAM)

AWS純正のマネージド機能はなく、AWS側はSecurity Competencyパートナー製品や、aws-samplesが公開するOSS参考実装「TEAM(Temporary Elevated Access Management)」を自前でデプロイして近い機能を実現します。PAMはこれをGoogle Cloudのマネージドサービスとして提供し、特権ロールをJust-In-Time(JIT)で一時的に昇格させる仕組みです。

常時高権限を持たせるのではなく、対象ロール・最大付与期間・承認者・正当化理由の入力必須化をエンタイトルメントとして定義しておき、利用者が申請して承認されると一時的にロールが付与されます。
付与期間は30分〜7日の範囲で設定でき、期間経過後は自動的に失効します。取り消し忘れによる権限の残存を防げます。
昇格の申請・承認・失効はすべてCloud Audit Logsに記録されるため、「誰が・いつ・なぜ」昇格したかを事後に追跡できます。

1-31. IAM拒否ポリシー (IAM Deny Policy)

AWS側に直接の対応サービスがない、特定の権限を全プリンシパルに対して一律禁止しつつ、必要な例外だけを個別に許可できる仕組みです。

通常のIAM許可ポリシーとは独立したレイヤーで、拒否(deny)は許可(allow)より常に優先されます。強い権限を持つプリンシパルであっても、拒否ポリシーの対象になれば操作できません。
対象権限はlogging.googleapis.com/sinks.deleteのようなIAM v2形式(サービスのFQDN/リソース.アクション)で指定します。
exceptionPrincipalsで特定のプリンシパルだけを拒否の対象外にできるため、「原則禁止だがセキュリティチームだけは例外的に許可」のような構成が可能です。
AWS OrganizationsのSCPは「リソース構成の制約」と「権限の明示的拒否」の両方を1つのポリシータイプで担いますが、Google Cloudではこれを組織ポリシー(1-15、リソース構成)とIAM拒否ポリシー(権限の拒否)に分けて提供しています。

1-32. Certificate Authority Service (CA Service)

AWS Private Certificate Authority(旧 ACM Private CA)に相当する、プライベートなPKI階層をフルマネージドで運用できるサービスです。

ルート鍵の保護にCloud HSM(FIPS 140-2レベル3検証済み)を使え、鍵の生成・保管をハードウェア内で完結できます。
ティアは用途で使い分けます。Enterpriseティアは長命・厳格な管理が必要な本番向けで、顧客管理の暗号鍵(CMEK)による証明書の追加保護にも対応します。DevOpsティアは高ボリューム・短命の証明書向けで低コストですが、CMEKには対応しません(いずれのティアもHSM保護自体は利用可能です)。
GKEワークロードとも統合でき、証明書テンプレートで指定した有効期間(例: 24時間)ごとに、期限前に自動ローテーションされる短命な証明書をPodへ発行できます。

1-33. Workforce Identity 連携 (Workforce Identity Federation)

AWS側に単一の対応サービスはなく、社外のベンダーやパートナーなど人間のユーザーを外部IdP経由でGoogle Cloudへフェデレーションする仕組みです。GKE/CI等のワークロード向けのWorkload Identity Federation(1-8・1-9)とは対象が異なります。

パートナー企業のトラストアンカー(SAML/OIDC IdP)を登録し、そのIdPで認証したユーザーへ短命トークンを発行して、IAMロールバインディングでアクセスを絞ります。
Workforce Identity 連携が担うのは認証フェデレーションのみで、アカウントの作成・停止・同期といったライフサイクル管理は行いません。パートナー企業の従業員が離職してパートナー側のIdPでアカウントが無効化されれば、認証のたびにIdPへ問い合わせる仕組み上、その時点で認証自体が成立しなくなりアクセスできなくなりますが、これはGoogle Cloud側がアカウントの停止処理を行っているわけではない点に注意してください。

2. まとめ

今回はセキュリティ・ID管理系のサービスをまとめました。SCC・Cloud Armorのように守るレイヤーが異なるサービスや、IAM周りの権限管理は、対応関係だけでなく各サービスの担当領域を合わせて把握しておく必要があります。

次回はデータ分析系のサービスをまとめる予定です。

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

AWSエンジニアのためのGoogle Cloudサービスまとめ その5 セキュリティ・ID管理編