GCP IAMとセキュリティ設計｜サービスアカウント・ロール管理のベストプラクティス

クラウド環境でのセキュリティインシデントの多くは、「過剰な権限の付与」「サービスアカウントキーの漏洩」「退職者のアカウント削除漏れ」といった、アクセス管理の不備が原因です。

GCPのIAM（Identity and Access Management）は、「誰が」「何に」「どんな操作を」できるかを一元管理する仕組みです。適切に設計・運用することで、セキュリティリスクを大幅に低減できます。

この記事では、IAMの基本概念から実務的なサービスアカウント管理、ロール設計、組織全体のセキュリティポリシーまで、エンジニアやIT担当者が実践すべきベストプラクティスを解説します。

GCP IAMの基本概念｜認証と認可の仕組み

IAMを正しく運用するために、まず基本的な概念を理解しましょう。

IAMの3つの構成要素

GCP IAMは、プリンシパル（誰が）、ロール（何ができるか）、リソース（何に対して）の3要素で構成されます。

プリンシパル（メンバー）
アクセスする主体を指します。以下の種類があります。

Googleアカウント：個人のGoogleアカウント（user@example.com）
サービスアカウント：アプリケーションやVMに割り当てる非人間のアカウント
Googleグループ：複数のユーザーをまとめたグループ（group@example.com）
Google Workspaceドメイン：組織全体のユーザー

ロール
パーミッション（権限）の集合です。「Compute Engineのインスタンスを起動する」「Cloud Storageのオブジェクトを読む」といった個別の権限が、ロールとしてまとめられています。

リソース
権限の対象となるGCPリソースです。プロジェクト、バケット、データベースインスタンスなどを指します。

IAMポリシーの仕組み

IAMポリシーは「プリンシパルにロールをバインドする」形で定義します。

# ポリシーの確認
gcloud projects get-iam-policy PROJECT_ID --format=json

# ロールの付与
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:developer@example.com" \
  --role="roles/viewer"

IAMポリシーはリソース階層に沿って継承されます。組織レベルで付与されたロールはすべてのプロジェクトに、プロジェクトレベルのロールはプロジェクト内のすべてのリソースに適用されます。

ロールの種類と適切な選び方

GCP IAMには3種類のロールがあり、それぞれ適した使い方があります。

基本ロール（Basic Roles）

プロジェクト全体に対する広範な権限を持つロールです。

roles/viewer：すべてのリソースの読み取り
roles/editor：すべてのリソースの読み取りと変更
roles/owner：すべての操作 + IAM管理

基本ロールは本番環境では使用を避けてください。権限が広すぎるため、最小権限の原則に反します。開発初期のプロトタイピングや個人プロジェクトに限定しましょう。

事前定義ロール（Predefined Roles）

特定のサービスに対する適切な権限が事前にまとめられたロールです。実務では事前定義ロールの使用を推奨します。

例：Cloud Storageに関する事前定義ロール
- roles/storage.objectViewer    → オブジェクトの読み取り
- roles/storage.objectCreator   → オブジェクトの作成
- roles/storage.objectUser      → オブジェクトの読み書き
- roles/storage.admin           → バケット管理を含むすべて

Cloud StorageやCloud SQLなど、各サービスの記事でも具体的なロールの使い方を解説しています。

カスタムロール

事前定義ロールでは権限が多すぎる・少なすぎる場合に、必要な権限だけを組み合わせたカスタムロールを作成できます。

# カスタムロールの作成
gcloud iam roles create customStorageReader \
  --project=PROJECT_ID \
  --title="Custom Storage Reader" \
  --description="Can only read objects in specific buckets" \
  --permissions=storage.objects.get,storage.objects.list \
  --stage=GA

# YAML定義ファイルを使う場合
# custom-role.yaml
title: "App Deployer"
description: "Cloud RunとArtifact Registryへのデプロイ権限"
stage: "GA"
includedPermissions:
  - run.services.create
  - run.services.update
  - run.services.get
  - run.services.list
  - artifactregistry.repositories.uploadArtifacts
  - artifactregistry.repositories.downloadArtifacts

# YAMLファイルからカスタムロールを作成
gcloud iam roles create appDeployer \
  --project=PROJECT_ID \
  --file=custom-role.yaml

サービスアカウントの設計と管理

サービスアカウントは、アプリケーションやVM、CI/CDパイプラインなど、人間以外のエンティティがGCPリソースにアクセスするために使います。適切な管理がセキュリティの要です。

サービスアカウントの設計原則

1. アプリケーションごとに専用のサービスアカウントを作成する
1つのサービスアカウントを複数のアプリケーションで共有しないでください。問題発生時の影響範囲を限定するためです。

2. 最小権限の原則を厳守する
必要な権限だけを付与します。「とりあえずEditor」は絶対に避けましょう。

3. サービスアカウントキーの使用を最小限にする
キーファイルの漏洩はセキュリティインシデントに直結します。可能な限りWorkload Identity Federationを使いましょう。

# サービスアカウントの作成
gcloud iam service-accounts create cloud-run-app \
  --display-name="Cloud Run Application" \
  --description="Service account for the main web application"

# 必要な権限を個別に付与
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:cloud-run-app@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/cloudsql.client"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:cloud-run-app@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

サービスアカウントキーの管理

サービスアカウントキーの使用が避けられない場合（外部サービスとの連携など）は、以下のルールを徹底します。

キーの有効期限を設定する：90日以内のローテーションを推奨
キーをソースコードに含めない：Secret Managerまたは環境変数で管理
未使用のキーを定期的に削除する：定期的な棚卸しを行う
キーの使用状況を監視する：不審なアクセスを検知する仕組みを構築

# サービスアカウントキーの一覧確認
gcloud iam service-accounts keys list \
  --iam-account=cloud-run-app@PROJECT_ID.iam.gserviceaccount.com

# 古いキーの削除
gcloud iam service-accounts keys delete KEY_ID \
  --iam-account=cloud-run-app@PROJECT_ID.iam.gserviceaccount.com

Workload Identity Federation

GitHub ActionsやAWSなど、外部のIDプロバイダからGCPリソースにアクセスする場合、キーレスでの認証が可能です。

# Workload Identity Poolの作成
gcloud iam workload-identity-pools create github-pool \
  --location="global" \
  --display-name="GitHub Actions Pool"

# プロバイダの設定
gcloud iam workload-identity-pools providers create-oidc github-provider \
  --location="global" \
  --workload-identity-pool="github-pool" \
  --display-name="GitHub Provider" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository" \
  --issuer-uri="https://token.actions.githubusercontent.com"

これにより、GitHub Actionsからサービスアカウントキーなしでデプロイパイプラインを実行できます。

最小権限の原則を実践する方法

「最小権限の原則」は、各ユーザーやサービスアカウントに、業務に必要な最小限の権限だけを付与するというセキュリティの基本原則です。

IAM Recommenderの活用

GCPのIAM Recommenderは、実際の権限使用状況を分析し、不要な権限の削除を提案してくれます。

# IAMの推奨事項を確認
gcloud recommender recommendations list \
  --project=PROJECT_ID \
  --location=global \
  --recommender=google.iam.policy.Recommender

例えば「過去90日間、Editor権限のうちCompute Engineの操作しか使われていない」場合、「roles/editorをroles/compute.adminに縮小する」といった提案が得られます。

条件付きIAMバインディング

特定の条件を満たす場合のみ権限を有効にするIAM Conditionsを活用しましょう。

# 特定の時間帯のみ権限を有効にする
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:oncall@example.com" \
  --role="roles/editor" \
  --condition="expression=request.time.getHours('Asia/Tokyo') >= 9 && request.time.getHours('Asia/Tokyo') <= 18,title=business-hours-only"

# 特定のリソースに対してのみ権限を有効にする
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:backup-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.objectAdmin" \
  --condition="expression=resource.name.startsWith('projects/_/buckets/backup-'),title=backup-buckets-only"

権限のテストと検証

権限が正しく設定されているかをテストすることも重要です。

# 特定のメンバーが特定の権限を持っているかテスト
gcloud asset analyze-iam-policy \
  --organization=ORG_ID \
  --identity="user:developer@example.com" \
  --full-resource-name="//storage.googleapis.com/projects/_/buckets/my-bucket"

組織ポリシーによるガードレール

組織ポリシー（Organization Policy）は、プロジェクト横断的にセキュリティルールを強制する仕組みです。個々のプロジェクトでの設定ミスを防ぎます。

推奨する組織ポリシー

1. サービスアカウントキー作成の制限

# サービスアカウントキーの作成を制限
gcloud resource-manager org-policies set-policy \
  --organization=ORG_ID \
  policy.yaml

# policy.yaml
constraint: constraints/iam.disableServiceAccountKeyCreation
booleanPolicy:
  enforced: true

2. 外部IPアドレスの制限

constraint: constraints/compute.vmExternalIpAccess
listPolicy:
  deniedValues:
    - all

3. リソースロケーションの制限

constraint: constraints/gcp.resourceLocations
listPolicy:
  allowedValues:
    - asia-northeast1
    - asia-northeast2

これにより、日本国内のリージョンのみにリソースが作成されるよう制限できます。コンプライアンスやデータ主権の要件を満たすのに有効です。

VPC Service Controlsの活用

VPC Service Controlsを使うと、GCPリソースの周囲にセキュリティ境界（ペリメータ）を設定し、データの流出を防止できます。

# アクセスポリシーの作成
gcloud access-context-manager policies create \
  --organization=ORG_ID \
  --title="My Access Policy"

# サービス境界の作成
gcloud access-context-manager perimeters create my-perimeter \
  --title="Production Perimeter" \
  --resources="projects/PROJECT_NUMBER" \
  --restricted-services="storage.googleapis.com,bigquery.googleapis.com" \
  --policy=POLICY_ID

監査ログとセキュリティモニタリング

セキュリティ対策は「設定して終わり」ではなく、継続的な監視が不可欠です。

Cloud Audit Logsの活用

GCPのCloud Audit Logsは、以下の4種類のログを記録します。

管理アクティビティログ：リソースの作成・削除・設定変更（常時有効・無料）
データアクセスログ：リソースのデータの読み取り・書き込み（要設定・有料）
システムイベントログ：GCPが自動実行するアクション（常時有効・無料）
ポリシー拒否ログ：アクセスが拒否された記録（常時有効・無料）

# データアクセスログの有効化
gcloud projects get-iam-policy PROJECT_ID --format=json > policy.json
# auditConfigsセクションにデータアクセスログの設定を追加
gcloud projects set-iam-policy PROJECT_ID policy.json

Security Command Centerの導入

Security Command Center（SCC）は、GCPのセキュリティ統合ダッシュボードです。以下の脆弱性を自動的に検出します。

公開されているCloud Storageバケット
ファイアウォールの過剰な許可ルール
MFAが無効なアカウント
使われていないサービスアカウントキー
暗号化されていないディスク

アラートの設定

重要なセキュリティイベントに対してアラートを設定しましょう。

# IAMポリシーの変更を検知するログベースのアラート
gcloud logging metrics create iam-policy-change \
  --description="IAM policy changes" \
  --log-filter='protoPayload.methodName="SetIamPolicy"'

実務で使えるIAM設計テンプレート

最後に、実務でそのまま使えるIAM設計のテンプレートを紹介します。

チーム別のロール設計例

■ 開発チーム
  - 開発環境: roles/editor
  - ステージング環境: roles/viewer + 必要なサービスの事前定義ロール
  - 本番環境: roles/viewer のみ

■ SREチーム
  - 全環境: 各サービスの admin ロール
  - 本番環境: roles/owner（条件付き：営業時間内のみ）

■ データ分析チーム
  - BigQuery: roles/bigquery.dataViewer + roles/bigquery.jobUser
  - Cloud Storage: roles/storage.objectViewer（分析用バケットのみ）

■ CI/CDパイプライン
  - サービスアカウント: カスタムロール（デプロイに必要な最小権限）
  - Workload Identity Federationで認証