「サービスアカウントキーが使い回されていた」
「BigQueryのデータが誰でも見れる設定になっていた」
「監査ログを有効にしていない」

1. GCPの「ここで漏れる」3大パターン

パターン①：サービスアカウントキーの管理不足

GCPのサービスアカウントは、アプリケーションがGCPリソースにアクセスするための"IDカード"です。

問題になるケース：

  • Project EditorやOwner相当の権限を持つSAキーが複数存在する
  • キーのローテーションが行われておらず、数年間同じキーを使っている
  • キーがGitリポジトリや共有ドライブに保存されている

対策：
可能な限り、SAキーを使わずにWorkload Identity（GCE/GKEからはキー不要でGoogle APIを呼べる）を使いましょう。

パターン②：IAM権限の肥大化

小規模チームで「全員にEditor権限」を付与し、そのままになっているケースが多い。

チェックポイント：

  • roles/ownerやroles/editorが個人アカウントに直接付与されていないか
  • 退職者・転職者のアカウントが残っていないか
  • グループメンバーシップの棚卸しができているか

パターン③：オブジェクトの誤公開（GCS等）

Cloud Storage（GCS）バケットのallUsersやallAuthenticatedUsersへの権限付与は、実質全世界公開を意味します。

 

2. IAM設計のポイント

最小権限の徹底

roles/editorは便利ですが危険です。
実際に必要な権限だけを付与するカスタムロールの使用を推奨します。

# 悪い例
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:dev@example.com" \
  --role="roles/editor"

# 良い例：必要なサービスだけ
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:dev@example.com" \
  --role="roles/cloudsql.client"

Condition（条件付きIAM）の活用

IAMのバインディングに時間やリソースパスの条件を付けられます。
本番環境へのアクセスは業務時間内のみ、特定のプロジェクトのみに制限するといった設計が可能です。

 

3. Cloud Audit Logsの押さえどころ

GCPのAudit Logsは3種類あります：

ログ種別記録内容デフォルト
Admin Activity設定変更・IAM変更自動有効（無効化不可）
Data Accessデータの読み取り・変更デフォルト無効
System EventGCP内部の自動操作自動有効

特に注意：Data Accessログはデフォルト無効です。
BigQuery、GCSへのアクセス履歴を取るには、明示的に有効化する必要があります。

 

4. 監視：Security Command Center（SCC）の活用

GCP標準のセキュリティダッシュボードです。

SCCが検出する主な問題：

  • 公開されているGCSバケット
  • SAキーの不審な使用
  • 過剰権限の検出
  • 外部への異常なデータ転送

SCCの**Premium Tier（旧Security Health Analytics + Event Threat Detection）**を使うと、脅威検知の精度が上がります。

 

5. Colorkrew Securityの考え方

Colorkrew Securityでは、GCP環境のセキュリティ設計・棚卸し・監査ログ設計を支援しています。
GCPは"デフォルト設定"が必ずしも安全ではありません。SAキー・IAM・監査ログの3点を押さえることが、GCPセキュリティの第一歩です。