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

0. はじめに

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

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

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

カテゴリ	AWS	Google Cloud
セキュリティ統合管理	Security Hub	Security Command Center (SCC)
機密データ保護	Macie	Sensitive Data Protection
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
ユーザーによるSAの一時的なりすまし	AssumeRole	サービスアカウントの権限借用 (Impersonation)
ローカル開発時のデフォルト認証情報	AWS CLI の認証情報チェーン	Application Default Credentials (ADC)
シークレット管理	Secrets Manager	Secret Manager
監査ログ	CloudTrail	Cloud Audit Logs
データ持ち出し防止(境界制御)	-	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

1-1. Security Command Center (SCC)

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

• 組織全体の設定ミス検出(Security Health Analytics)、公開Webアプリの脆弱性スキャン(Web Security Scanner)、脅威検出(Event Threat Detection)を包括的に提供し、PCI DSSなどの規制コンプライアンス状況を監視・報告します。
• 脆弱なディスクイメージから起動されたVMの自動検出も可能です(稼働時間の長短では脆弱性の有無は判断できない点に注意)。

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によるリアルタイム検査やデータの匿名化・変換機能まで備えている点で、データ保護・加工の範囲がより広いです。

1-3. Cloud Armor

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

• 外部からの悪意あるトラフィック(SQLインジェクション等)をエッジレベルでブロックしますが、環境全体のスキャンや不審なアウトバウンド通信の検出機能は持ちません。

1-4. Cloud KMS

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

• ソフトウェア鍵に加えて、HSM(ハードウェアセキュリティモジュール)保護の鍵やCloud External Key Manager(EKM)を使った外部鍵管理にも対応します。

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(ブラウザ)が最小権限です。IAMロールの「定義」を表示するroles/iam.roleViewer(ロールビューア)とは別物なので混同しないよう注意してください。
• プロジェクト全体を「表示のみ」でレビューさせたい場合はroles/viewer(閲覧者)が一般的です。セキュリティ関連リソースの表示に限定されるroles/iam.securityReviewerとは対象範囲が異なります。
• カスタムロールの各権限にはSUPPORTED(本番利用可)・TESTING(変更の可能性あり)というサポートレベルがあり、本番用ロールはSUPPORTED権限のみで構成します。
• ロール自体の成熟度は権限のサポートレベルとは別軸の**ロールのステージ(ALPHA/BETA/GA)**で表現します。

1-7. Identity-Aware Proxy (IAP)

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

• 不特定多数向けの一般公開ウェブサイトのセキュリティ確保には、通常は外部HTTP(S)ロードバランサ+マネージドSSL証明書の組み合わせの方が適しています。
• 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課金やパッチ管理コストがかかりません。

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. サービスアカウントの権限借用 (Service Account Impersonation)

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

• サービスアカウントキーをローカルにダウンロードせずに済むため、権限のテストにはGoogleが推奨する最もセキュアな方法です。
• CI/CDでも、単一の広範な権限を持つサービスアカウントを使い回さず、パイプラインごとに専用のサービスアカウントを用意して最小限のロールだけを付与します。

1-10. Application Default Credentials (ADC)

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

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

1-11. Secret Manager

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

• シークレットのバージョン管理、IAMによるきめ細かいアクセス制御、アクセス監査ログを提供します。アプリケーションやCI/CDパイプラインは実行時にAPI経由で必要なシークレットを取得でき、コードやマニフェストへの平文埋め込みを回避できます。

1-12. Cloud Audit Logs

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

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

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

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

1-13. VPC Service Controls

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

• IAMによるアクセス制御とは独立したレイヤーであり、たとえ正当な認証情報が漏洩しても境界外へのデータ持ち出しを防ぐ「多層防御」として機能します。

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

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

• ファイアウォールルールの適用には使用できません(通信制御が目的なら階層型ファイアウォールポリシー)。「誰が何にアクセスできるか」を制御するIAMとも異なり、「(許可された人でも)何ができるか」というガードレールを設定するものという位置づけです。
• 具体例としてconstraints/iam.allowedPolicyMemberDomains制約を組織レベルで設定すると、許可した組織ドメイン以外のGoogleアカウント(個人の@gmail.comなど)がIAMポリシーに追加されるのを防げます。
• 部門ごとに異なるポリシーを適用したい場合はフォルダレベルで設定します。フォルダレベルのポリシーは、配下のプロジェクトのオーナーが変更・削除できません。
• 制約は遡及適用されません。設定した時点より未来の変更にのみ適用されるため、既存の違反状態(ドメイン外ユーザーの既存IAMバインディング等)は自動的に削除されません。制約の設定に加えて、既存の違反を手動で事後的に削除する対応が必要です。
• サービスアカウントキーの統制にも使えます。constraints/iam.serviceAccountKeyExpiryHoursでキーの最大有効期間を強制したり、constraints/iam.disableServiceAccountKeyCreationで特定プロジェクトを除きキー作成自体を禁止したりでき、いずれもコード不要の予防的統制です。

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

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

• プロジェクトレベルで構成すると、そのプロジェクトのオーナーがログシンクを削除・無効化できてしまいます。「プロジェクトユーザーが削除できないようにしたい」場合はフォルダレベル(または組織レベル)で構成する必要があります(組織ポリシーと同様の階層構造上の性質です)。
• 宛先にPub/Subトピックを設定し、会社のSIEMシステムをそのトピックのサブスクライバーとして追加すれば、監査ログをリアルタイムでSIEMへ連携できます。カスタムのエクスポート処理を自前開発するより、開発・運用コストを抑えられます。

1-16. Identity Platform

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

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

1-17. Cloud Identity

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

• 外部の一般アプリユーザー管理には使用しません(その用途はIdentity Platform)。Identity Platformが顧客向け、Cloud Identityが社内従業員向けという役割分担です。
• Google Workspaceを従業員アカウント管理に使っている場合、その従業員IDはすでにCloud Identity上に存在します。オンプレのADと同期する場合はGoogle Cloud Directory Sync(GCDS)を使用します。
• サードパーティSSOプロバイダとのSAML統合: 会社が独自のSAML IdPを持つ場合、「会社のSSOプロバイダ = IdP」「Cloud Identity = SP(サービスプロバイダ)」という役割になります。Cloud IdentityでサードパーティIdPとのSSOをセットアップするのが正しい構成です。
• 競合アカウント(Conflicting Accounts): 従業員が会社ドメインで個人のGoogleアカウントを先に作っていると、管理アカウントと競合します。対象ユーザーに既存アカウントの**移行(トランスファー)**を依頼して解消します。

1-18. Google Workspace

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

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

2. まとめ

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

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

参考