Google Cloudのセキュリティ設計とチェックポイント
GCPはプロジェクト単位でリソースが分離され、組織(Organization)配下のフォルダ・プロジェクト階層でIAMポリシーが継承される構造を持ちます。このページでは、Cloud IAM・VPC Firewall Rules・Cloud Storage・Cloud Audit Logs・Security Command Center・Cloud KMSという主要サービスと、確認すべきセキュリティコントロールを整理します。
GCPの責任共有モデル(要点)
Google CloudもShared Responsibility Modelに基づき、物理インフラとネットワーク基盤の保護はGoogleが担う一方、Cloud IAMのロール設計、VPC Firewall Rulesの許可範囲、Cloud Storageのバケットポリシー、鍵管理といった設定は利用者側の責任です。GCPはCompute Engine/GKE/Cloud Runなどサービス形態によって境界線が変わる点も他クラウドと共通です。モデル全体の詳しい説明はCloud Security Fundamentalsを参照してください。
主要サービスとセキュリティコントロール
| サービス | カテゴリ | 確認すべきセキュリティコントロール |
|---|---|---|
| Cloud IAM | Identity | 基本ロール(Owner/Editor)ではなく事前定義/カスタムロールで最小権限化されているか |
| VPC Firewall Rules | Network | SSH(22)/RDP(3389)などに0.0.0.0/0を許可するルールが存在しないか |
| Cloud Storage | Storage | バケットにパブリックアクセス防止(Public Access Prevention)が有効化されているか |
| Cloud Audit Logs | Logging | Admin Activity/Data Accessログがすべてのプロジェクトで有効かつシンクで集約されているか |
| Security Command Center | Detection | Organization全体でPremium/Enterprise階層が有効化され、全プロジェクトをカバーしているか |
| Cloud KMS | Encryption | 機密データに対してGoogle管理鍵ではなく顧客管理鍵(CMEK)を使用しているか |
よくある設定ミス
-
Cloud Storageバケットの公開設定 High Risk
バケットIAMポリシーで
allUsersにstorage.objectViewerなどが付与され、認証なしで外部から読み取り可能になる。 -
VPC Firewall Rulesの過剰開放 High Risk
SSH/RDPなど管理ポートへのIngressルールで送信元範囲が
0.0.0.0/0のまま本番運用される。 -
基本ロール(Owner/Editor)の乱用 Medium Risk
サービスアカウントやユーザーに事前定義ロールではなく広範なProject Editor/Ownerロールが付与され続ける。
-
Security Command Centerの一部プロジェクトのみ有効 Medium Risk
新規作成したプロジェクトがOrganizationレベルのSCC監視対象から漏れ、検知の空白が生まれる。
gsutil iam get gs://<bucket-name> | grep allUsersgcloud compute firewall-rules list --filter="sourceRanges:0.0.0.0/0 AND (allowed.ports:22 OR allowed.ports:3389)"gcloud projects get-iam-policy <project-id> --flatten="bindings[].members" --filter="bindings.role:roles/owner OR bindings.role:roles/editor"gcloud scc sources list --organization=<organization-id>