Domain 4
アクセスとセキュリティの構成

【通常のロールバインディング】
  alice に roles/storage.objectAdmin を付与
  → いつでも、どこからでもアクセス可能

【条件付きロールバインディング】
  alice に roles/storage.objectAdmin を付与
  ただし、以下の条件を満たす場合のみ:
    ├── 特定の時間帯のみ（例: 平日 9:00-18:00）
    ├── 特定のリソースのみ（例: 本番バケット以外）
    └── 特定のリクエスト元のみ

【よく使う条件の種類】

① 時間ベースの条件
request.time.getHours('Asia/Tokyo') >= 9 &&
request.time.getHours('Asia/Tokyo') < 18

② 特定リソースへのアクセス制限
resource.name.startsWith("projects/my-project/datasets/staging")

③ リソースタイプによる制限
resource.type == "storage.googleapis.com/Object"

④ タグベースのアクセス制御
resource.matchTagId("tagValues/123456789")

# 例1: 業務時間内（JST 9:00-18:00）のみ権限を有効化
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:contractor@partner.com" \
  --role="roles/compute.instanceAdmin.v1" \
  --condition='
    title=BusinessHoursOnly,
    description=Only during business hours JST,
    expression=request.time.getHours("Asia/Tokyo") >= 9 && request.time.getHours("Asia/Tokyo") < 18'

# 例2: 有効期限付きの権限付与（一時的なアクセス）
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:temp-worker@example.com" \
  --role="roles/viewer" \
  --condition='
    title=TemporaryAccess,
    description=Valid until 2024-03-31,
    expression=request.time < timestamp("2024-03-31T23:59:59Z")'

# 例3: 特定の Cloud Storage パスのみアクセス許可
gcloud storage buckets add-iam-policy-binding gs://my-bucket \
  --member="serviceAccount:external-app@PROJECT.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer" \
  --condition='
    title=DevOnlyAccess,
    description=Access to dev prefix only,
    expression=resource.name.startsWith("projects/_/buckets/my-bucket/objects/dev/")'

【個人（ユーザー）に直接ロールを付与する問題】

社員 A、B、C が同じ権限を必要としている場合:
  ユーザーごとに add-iam-policy-binding を 3 回実行
    ↓
社員 D が追加されたら また 1 回実行
社員 A が退職したら remove-iam-policy-binding を実行
    ↓
管理が煩雑・設定漏れのリスク

【グループにロールを付与する利点（推奨）】

Google グループ: backend-team@example.com に権限付与
    ↓
グループにメンバーを追加するだけで権限が自動付与
グループからメンバーを削除するだけで権限が自動剥奪
IAM ポリシーを変更する必要なし！

設定例:
  gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="group:backend-team@example.com" \
    --role="roles/run.developer"

【人間のアカウント vs サービスアカウント】

人間のアカウント（User Account）:
  └── alice@example.com でログインするのは「人間」

サービスアカウント（Service Account）:
  └── my-app@project.iam.gserviceaccount.com
      これは「アプリケーション・プログラム」のアカウント

【サービスアカウントの二重の役割】

役割①: 主体（Principal）としてのサービスアカウント
  → 他のリソースにアクセスする「誰か」として機能
  例: VM 上のアプリが Cloud Storage を読み取る
      （VM に SA をアタッチ → SA の権限でアクセス）

役割②: リソース（Resource）としてのサービスアカウント
  → 「誰かが SA を使う権限を管理する対象」
  例: alice が特定の SA を使う権限を持つかどうか
      （SA へのアクセス自体を IAM で制御）

# サービスアカウントの作成
gcloud iam service-accounts create my-app-sa \
  --display-name="My Application Service Account" \
  --description="SA for the production web application"

# SA の一覧確認
gcloud iam service-accounts list

# SA の詳細確認
gcloud iam service-accounts describe \
  my-app-sa@PROJECT_ID.iam.gserviceaccount.com

# SA に IAM ロールを付与（SA が Cloud Storage を読み取る権限）
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:my-app-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

# SA を VM にアタッチ（VM 作成時）
gcloud compute instances create my-vm \
  --service-account=my-app-sa@PROJECT_ID.iam.gserviceaccount.com \
  --scopes=cloud-platform \
  --zone=asia-northeast1-a

# 既存 VM の SA を変更
gcloud compute instances set-service-account my-vm \
  --service-account=new-sa@PROJECT_ID.iam.gserviceaccount.com \
  --scopes=cloud-platform \
  --zone=asia-northeast1-a

# SA の無効化（削除せずに一時停止）
gcloud iam service-accounts disable \
  my-app-sa@PROJECT_ID.iam.gserviceaccount.com

# SA の削除
gcloud iam service-accounts delete \
  my-app-sa@PROJECT_ID.iam.gserviceaccount.com

【actAs 権限とは？】

「サービスアカウントを VM にアタッチする」操作は
roles/iam.serviceAccountUser（含む actAs 権限）が必要

なぜ重要か？
  privileged-sa には Cloud SQL Admin 権限がある
  → この SA を誰でも VM にアタッチできると
    誰でも privileged-sa の権限を利用できてしまう！

→ actAs 権限を持つ人だけが、その SA を使えるリソースを作成できる

gcloud iam service-accounts add-iam-policy-binding \
  privileged-sa@PROJECT.iam.gserviceaccount.com \
  --member="user:alice@example.com" \
  --role="roles/iam.serviceAccountUser"

【サービスアカウントキーの生成から漏洩まで】

Step 1: エンジニアが SA キーを生成
  gcloud iam service-accounts keys create key.json \
    --iam-account=my-sa@PROJECT.iam.gserviceaccount.com

Step 2: key.json を CI/CD に設定 or ローカルに保存

Step 3: 誤って GitHub にコミット or ラップトップを紛失

Step 4: 攻撃者がキーを発見

Step 5: 攻撃者が GCP API を呼び出す
  gcloud auth activate-service-account --key-file=stolen-key.json

Step 6: 莫大な被害が発生！

【SA キーの管理コスト】
  ├── 定期的なローテーションが必要（90日ごと推奨）
  ├── 有効期限の管理
  ├── 誰がどのキーを持っているかの追跡
  └── 組織全体で数百〜数千のキーを管理する地獄

【シナリオ別の推奨認証方法】

シナリオ A: GCE/GKE/Cloud Run 上のアプリ
  → VM または Pod に SA をアタッチ
  → メタデータサーバーから自動的にトークンを取得
  → キー不要！

シナリオ B: 開発者のローカル PC
  → gcloud auth application-default login
  → ADC（Application Default Credentials）を使用
  → キー不要！

シナリオ C: GitHub Actions / GitLab CI / Jenkins
  → Workload Identity Federation を設定
  → CI/CD が動的にトークンを交換
  → キー不要！

シナリオ D: AWS / Azure / オンプレミスのシステム
  → Workload Identity Federation を設定
  → 外部 IdP のトークンを GCP トークンに交換
  → キー不要！

シナリオ E: 権限が必要な一時的な管理作業
  → SA Impersonation（権限借用）を使用
  → 短期トークンのみを生成
  → キー不要！

⚠️ SA JSON キーを使うべきシナリオ: ほぼなし
   どうしても必要な場合は組織ポリシーで管理し、
   有効期限を設定して定期ローテーションする

【Workload Identity Federation の仕組み】

従来（SA キー使用）:
  GitHub Actions → key.json を秘密として保存 → GCP API 呼び出し

Workload Identity Federation（推奨）:
  GitHub Actions
      ↓ OIDC トークン（GitHub が発行）を提示
  Google Cloud Security Token Service (STS)
      ↓ OIDC トークンを検証
      ↓ 短期有効な Google Cloud アクセストークンを発行
  GCP API を呼び出す
      ↓ 完了後トークンは自動失効

【メリット】
  ✓ SA キーをどこにも保存しない
  ✓ トークンは短期間で自動失効
  ✓ 監査ログで誰が何時アクセスしたか追跡可能

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

# Step 2: GitHub の OIDC プロバイダーを登録
gcloud iam workload-identity-pools providers create-oidc github-provider \
  --location=global \
  --workload-identity-pool=github-pool \
  --display-name="GitHub OIDC Provider" \
  --issuer-uri="https://token.actions.githubusercontent.com" \
  --attribute-mapping="google.subject=assertion.sub,attribute.repository=assertion.repository,attribute.actor=assertion.actor,attribute.aud=assertion.aud" \
  --attribute-condition="assertion.repository_owner == 'my-org'"  # 組織を限定

# Step 3: SA を作成（CI/CD 用の最小権限 SA）
gcloud iam service-accounts create github-deploy-sa \
  --display-name="GitHub Actions Deploy SA"

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:github-deploy-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/run.developer"  # 必要な権限のみ

# Step 4: Workload Identity Pool に SA への権限借用を許可
WORKLOAD_IDENTITY_POOL_ID=$(gcloud iam workload-identity-pools describe github-pool \
  --location=global \
  --format="value(name)")

gcloud iam service-accounts add-iam-policy-binding \
  github-deploy-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role="roles/iam.workloadIdentityUser" \
  --member="principalSet://iam.googleapis.com/${WORKLOAD_IDENTITY_POOL_ID}/attribute.repository/my-org/my-repo"

# .github/workflows/deploy.yml
name: Deploy to Cloud Run

on:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write  # OIDC トークンの生成を許可

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Workload Identity Federation で認証（SA キー不要！）
      - id: auth
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: 'projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/github-pool/providers/github-provider'
          service_account: 'github-deploy-sa@PROJECT_ID.iam.gserviceaccount.com'

      # gcloud が自動的に上記で取得したトークンを使用
      - name: Deploy to Cloud Run
        run: |
          gcloud run deploy my-service \
            --image=gcr.io/PROJECT/my-app:${{ github.sha }} \
            --region=asia-northeast1

# Step 1: GKE クラスタで Workload Identity を有効化
gcloud container clusters update my-cluster \
  --workload-pool=PROJECT_ID.svc.id.goog \
  --region=asia-northeast1

# Step 2: Google Cloud SA を作成
gcloud iam service-accounts create gke-app-sa \
  --display-name="GKE Application SA"

# Step 3: SA に必要な権限を付与
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:gke-app-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"  # Secret Manager へのアクセス

# Step 4: Kubernetes SA と Google Cloud SA を紐付け
gcloud iam service-accounts add-iam-policy-binding \
  gke-app-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/iam.workloadIdentityUser \
  --member="serviceAccount:PROJECT_ID.svc.id.goog[my-namespace/my-ksa]"

【ADC の検索順序（コードが認証情報を探す順番）】

1. GOOGLE_APPLICATION_CREDENTIALS 環境変数
   └── 指定されたキーファイルを使用

2. gcloud auth application-default login で設定した認証情報
   └── ローカル開発環境での標準

3. GCE / GKE / Cloud Run などの実行環境
   └── メタデータサーバーからトークンを自動取得（キー不要）

4. Cloud Shell
   └── 自動的に認証済み

【コードは認証情報を意識しない】

# コードでは認証情報を指定しない
from google.cloud import storage
client = storage.Client()  # ADC が自動的に認証情報を解決

# 方法1: ユーザーアカウントで認証（最も一般的）
gcloud auth application-default login
# ブラウザが開いて Google アカウントでログイン
# 認証情報が ~/.config/gcloud/application_default_credentials.json に保存

# 方法2: SA を権限借用して ADC を設定
gcloud auth application-default login \
  --impersonate-service-account=my-sa@PROJECT.iam.gserviceaccount.com
# SA の権限でローカル開発が可能

# 方法3: 環境変数で SA キーを指定（非推奨）
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/key.json
# ※ 緊急時以外は使用しない

# ADC の設定を確認
gcloud auth application-default print-access-token

# ADC の設定を削除
gcloud auth application-default revoke

【権限借用の仕組み】

alice（通常の権限を持つエンジニア）
    ↓ roles/iam.serviceAccountTokenCreator を持つ
privileged-sa（管理者権限を持つ SA）
    ↓ 短期トークンを生成（1時間以内に自動失効）
管理タスクを実行
    ↓ 完了

【通常の権限付与との違い】

通常の権限付与:
  alice に直接 roles/storage.admin を付与
  → alice は永続的に全バケットを管理できる
  → alice のアカウントが侵害されると大問題

権限借用:
  alice は自分の権限ではなく SA を借用して作業
  → 短期トークンで操作（1時間で失効）
  → 「alice が privileged-sa を使って何時にどの操作をしたか」
    が監査ログに詳細記録される
  → alice 自身の権限は小さいまま

# Step 1: privileged-sa の作成
gcloud iam service-accounts create privileged-sa \
  --display-name="Privileged Operations SA"

# Step 2: privileged-sa に管理権限を付与
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:privileged-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/storage.admin"

# Step 3: alice に SA の TokenCreator 権限を付与
gcloud iam service-accounts add-iam-policy-binding \
  privileged-sa@PROJECT_ID.iam.gserviceaccount.com \
  --member="user:alice@example.com" \
  --role="roles/iam.serviceAccountTokenCreator"

# Step 4: alice が権限借用を使って操作
gcloud storage buckets list \
  --impersonate-service-account=privileged-sa@PROJECT_ID.iam.gserviceaccount.com

# または短期トークンを生成して使用
gcloud auth print-access-token \
  --impersonate-service-account=privileged-sa@PROJECT_ID.iam.gserviceaccount.com

【PAM のワークフロー】

Step 1: alice が特権アクセスをリクエスト
  「prod の Cloud SQL を修正するために DB Admin が必要（理由: インシデント対応）」

Step 2: 承認者（上長・セキュリティチーム）がリクエストを確認
  → Slack / Email で通知
  → 理由・期間を確認して承認 or 却下

Step 3: 承認されたら自動的にロールを付与
  → 指定期間（例: 2時間）だけ有効

Step 4: 期間終了後、自動的にロールを剥奪
  → 誰の操作も不要

Step 5: 全操作が監査ログに詳細記録

【なぜ Secret Manager が必要か？】

❌ 絶対にやってはいけないこと:
  ├── コードにパスワードをハードコード
  │   DB_PASSWORD = "my-secret-password"
  ├── 環境変数に平文でシークレットを設定
  │   ENV DB_PASSWORD="my-secret-password"
  └── 設定ファイルをそのまま Git にコミット
      database.conf に password=... が含まれている

✅ Secret Manager を使う理由:
  ├── シークレットを安全に暗号化して保存
  ├── アクセス制御（IAM で誰が読めるかを制御）
  ├── バージョン管理（前のバージョンにロールバック可能）
  ├── 自動ローテーション（パスワードを定期更新）
  └── 監査ログ（誰がいつシークレットを読んだか記録）

# ===== シークレットの作成 =====

# テキストでシークレットを作成
echo -n "my-database-password" | \
  gcloud secrets create db-password \
    --replication-policy=automatic \
    --data-file=-

# ファイルからシークレットを作成
gcloud secrets create api-key \
  --replication-policy=automatic \
  --data-file=./api-key.txt

# ===== シークレットのバージョン管理 =====

# 新しいバージョンを追加（ローテーション）
echo -n "new-password-v2" | \
  gcloud secrets versions add db-password \
    --data-file=-

# バージョン一覧の確認
gcloud secrets versions list db-password

# ===== シークレットへのアクセス =====

# 最新バージョンにアクセス
gcloud secrets versions access latest --secret=db-password

# 特定バージョンにアクセス
gcloud secrets versions access 2 --secret=db-password

# ===== シークレットの管理 =====

# シークレット一覧
gcloud secrets list

# シークレットの詳細
gcloud secrets describe db-password

# 古いバージョンを無効化
gcloud secrets versions disable 1 --secret=db-password

# バージョンを削除（永久削除・復元不可）
gcloud secrets versions destroy 1 --secret=db-password

# シークレット自体を削除
gcloud secrets delete db-password

from google.cloud import secretmanager

def access_secret(project_id: str, secret_id: str, version_id: str = "latest") -> str:
    """Secret Manager からシークレットを取得"""
    client = secretmanager.SecretManagerServiceClient()
    
    # シークレットのリソース名を構築
    name = f"projects/{project_id}/secrets/{secret_id}/versions/{version_id}"
    
    # シークレットにアクセス
    response = client.access_secret_version(request={"name": name})
    
    return response.payload.data.decode("UTF-8")

# 使用例
db_password = access_secret("my-project", "db-password")
# → "my-database-password"

# Cloud Run デプロイ時に Secret Manager のシークレットを環境変数として注入
gcloud run deploy my-service \
  --image=gcr.io/PROJECT/my-app:latest \
  --region=asia-northeast1 \
  --set-secrets="DB_PASSWORD=db-password:latest,API_KEY=api-key:latest"
  # 環境変数名=シークレット名:バージョン

# Secret Store CSI Driver を使用して Pod に直接マウント
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-app-secrets
spec:
  provider: gcp
  parameters:
    secrets: |
      - resourceName: "projects/PROJECT/secrets/db-password/versions/latest"
        fileName: "db-password"
---
apiVersion: v1
kind: Pod
spec:
  volumes:
  - name: secrets-vol
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: my-app-secrets
  containers:
  - name: app
    volumeMounts:
    - name: secrets-vol
      mountPath: /run/secrets
      readOnly: true

# SA にシークレットへのアクセス権を付与
gcloud secrets add-iam-policy-binding db-password \
  --member="serviceAccount:my-app-sa@PROJECT.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

# 開発チームにシークレットの管理権限を付与
gcloud secrets add-iam-policy-binding db-password \
  --member="group:backend-team@example.com" \
  --role="roles/secretmanager.secretVersionManager"

【Cloud KMS でできること】

暗号化キーの管理:
  ├── 暗号化キーを Cloud KMS で一元管理
  ├── キーのローテーション（定期的に新しいキーに切り替え）
  ├── キーへのアクセスを IAM で制御
  └── FIPS 140-2 準拠のハードウェアで保護

データの暗号化・復号化:
  └── Cloud KMS キーを使ってデータを暗号化・復号化
      （CMEK: Customer Managed Encryption Keys）

【デフォルト暗号化 vs CMEK】

デフォルト:
  Google が管理するキーでデータを暗号化
  → 自動・コストなし
  → キーの管理は Google が担当

CMEK（顧客管理暗号化キー）:
  自分で作成・管理するキーでデータを暗号化
  → コストあり
  → キーの削除でデータへのアクセスを完全遮断可能
  → コンプライアンス要件（自社でキーを管理する義務）に対応

# ===== キーリングとキーの作成 =====

# キーリングを作成（キーをグループ化するコンテナ）
gcloud kms keyrings create my-keyring \
  --location=asia-northeast1

# 対称暗号化キーを作成（データの暗号化・復号化）
gcloud kms keys create my-symmetric-key \
  --keyring=my-keyring \
  --location=asia-northeast1 \
  --purpose=encryption \
  --rotation-period=90d \
  --next-rotation-time=2024-04-01T00:00:00Z

# 非対称署名キーを作成（コード署名・JWT 署名など）
gcloud kms keys create my-asymmetric-key \
  --keyring=my-keyring \
  --location=asia-northeast1 \
  --purpose=asymmetric-signing \
  --default-algorithm=ec-sign-p256-sha256

# ===== 暗号化・復号化 =====

# ファイルを暗号化
gcloud kms encrypt \
  --keyring=my-keyring \
  --key=my-symmetric-key \
  --location=asia-northeast1 \
  --plaintext-file=sensitive-data.txt \
  --ciphertext-file=sensitive-data.enc

# ファイルを復号化
gcloud kms decrypt \
  --keyring=my-keyring \
  --key=my-symmetric-key \
  --location=asia-northeast1 \
  --ciphertext-file=sensitive-data.enc \
  --plaintext-file=decrypted-data.txt

# ===== キーバージョン管理 =====

# キーの全バージョン一覧
gcloud kms keys versions list \
  --key=my-symmetric-key \
  --keyring=my-keyring \
  --location=asia-northeast1

# 古いキーバージョンを無効化（既存データへのアクセスは可能）
gcloud kms keys versions disable 1 \
  --key=my-symmetric-key \
  --keyring=my-keyring \
  --location=asia-northeast1

# Cloud Storage バケットに CMEK を設定
gcloud storage buckets update gs://my-sensitive-bucket \
  --default-kms-key=projects/PROJECT/locations/asia-northeast1/keyRings/my-keyring/cryptoKeys/my-symmetric-key

# SA に Cloud Storage バケットがキーを使う権限を付与
gcloud kms keys add-iam-policy-binding my-symmetric-key \
  --keyring=my-keyring \
  --location=asia-northeast1 \
  --member="serviceAccount:service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com" \
  --role="roles/cloudkms.cryptoKeyEncrypterDecrypter"

【VPC Service Controls の目的】

通常の IAM:
  「誰が何のリソースにアクセスできるか」を制御

VPC Service Controls:
  「どこから」アクセスできるかを制御
  （IAM と組み合わせてより強固なセキュリティを実現）

【防御できる脅威】

脅威1: データの持ち出し（Data Exfiltration）
  攻撃者が会社の BigQuery データを
  自分の Google Cloud プロジェクトにコピーしようとする
  → VPC Service Controls でブロック！

脅威2: 認証情報の盗難後のアクセス
  盗まれた SA キーで外部から Cloud Storage にアクセスしようとする
  → VPC Service Controls で許可された場所からのみアクセス！

脅威3: フィッシング後の不正アクセス
  社員が騙されてフィッシングサイトで認証情報を入力
  → 特定の IP / VPC からのみアクセスを許可しているためブロック！

【サービス境界（Service Perimeter）の構造】

サービス境界（Service Perimeter）:
  ├── 保護対象プロジェクト: project-A, project-B
  ├── 保護対象 API: BigQuery, Cloud Storage, Cloud SQL
  │
  ├── アクセスポリシー（誰がアクセスできるか）:
  │   ├── VPC Network: my-corp-vpc（社内ネットワークから）
  │   ├── IP アドレス範囲: 203.0.113.0/24（会社の外部 IP）
  │   └── SA: trusted-sa@project.iam.gserviceaccount.com
  │
  └── アクセスレベル（Access Level）:
      └── 上記の組み合わせで定義

境界外からのアクセス → PERMISSION DENIED
境界内からのアクセス → IAM で判断

【IAP がない場合（従来の方法）】

ユーザー → インターネット → VPN → 社内システム
または
ユーザー → インターネット → Bastion Host → 社内システム

問題点:
  ├── VPN のセットアップが面倒
  ├── Bastion Host の管理コスト
  └── VPN が侵害されると内部に全アクセス

【IAP がある場合（ゼロトラストアクセス）】

ユーザー → インターネット → IAP → Google 内部ネットワーク → アプリ
              ↑
         認証・認可をここで実施
         ・Google アカウントで認証
         ・IAM で認可（どのユーザーがアクセス可能か）
         ・デバイスのセキュリティ状態を確認
         ・VPN 不要！

# Cloud Run サービスに IAP を有効化
# （先にロードバランサを設定し、IAP はバックエンドサービスに適用）

# バックエンドサービスに IAP を有効化
gcloud compute backend-services update my-backend-service \
  --iap=enabled \
  --oauth2-client-id=CLIENT_ID \
  --oauth2-client-secret=CLIENT_SECRET \
  --global

# ユーザーにアクセスを許可
gcloud iap web add-iam-policy-binding \
  --resource-type=backend-services \
  --service=my-backend-service \
  --member="user:alice@example.com" \
  --role="roles/iap.httpsResourceAccessor"

# グループにアクセスを許可（推奨）
gcloud iap web add-iam-policy-binding \
  --resource-type=backend-services \
  --service=my-backend-service \
  --member="group:internal-users@example.com" \
  --role="roles/iap.httpsResourceAccessor"

# IAP トンネル経由で VM に SSH 接続
gcloud compute ssh VM_NAME \
  --zone=asia-northeast1-a \
  --tunnel-through-iap
# → 外部 IP なし・ファイアウォールで SSH を開放していない VM にも接続可能！

# IAP トンネル経由でローカルポートフォワーディング
# 例: Cloud SQL に直接接続（Auth Proxy の代替）
gcloud compute start-iap-tunnel VM_NAME 3306 \
  --local-host-port=localhost:3307 \
  --zone=asia-northeast1-a
# → localhost:3307 → IAP → VM の 3306 にトンネル

【Cloud Armor が保護するレイヤ】

インターネット → Cloud Armor → Cloud Load Balancer → バックエンド
     ↑
  DDoS 攻撃・悪意のあるリクエストをここでブロック

【Cloud Armor でできること】

① L3/L4 DDoS 防御（自動）
   → ネットワーク層の大規模 DDoS を自動的に軽減

② L7 WAF（Web Application Firewall）
   → SQL インジェクション、XSS などの攻撃を検出・ブロック

③ IP ベースのアクセス制御
   → 特定の IP アドレスをブロック or 許可リスト

④ 地理情報ベースのアクセス制御
   → 特定の国からのアクセスをブロック

⑤ レート制限
   → 1つの IP からの大量リクエストを制限

# セキュリティポリシーを作成
gcloud compute security-policies create my-waf-policy \
  --description="WAF and DDoS protection for production"

# ===== WAF ルール（OWASP ルールセット）=====

# SQL インジェクション対策ルールを追加
gcloud compute security-policies rules create 1000 \
  --security-policy=my-waf-policy \
  --expression="evaluatePreconfiguredExpr('sqli-v33-stable')" \
  --action=deny-403 \
  --description="Block SQL injection attempts"

# XSS（クロスサイトスクリプティング）対策
gcloud compute security-policies rules create 1001 \
  --security-policy=my-waf-policy \
  --expression="evaluatePreconfiguredExpr('xss-v33-stable')" \
  --action=deny-403 \
  --description="Block XSS attempts"

# ===== IP ベースのルール =====

# 特定 IP をブロック
gcloud compute security-policies rules create 2000 \
  --security-policy=my-waf-policy \
  --src-ip-ranges=203.0.113.100/32 \
  --action=deny-403 \
  --description="Block known malicious IP"

# 特定の国からのアクセスをブロック
gcloud compute security-policies rules create 3000 \
  --security-policy=my-waf-policy \
  --expression="origin.region_code == 'XX'" \
  --action=deny-403 \
  --description="Block traffic from country XX"

# ===== レート制限 =====

# 1 IP あたり 100 リクエスト/60 秒に制限
gcloud compute security-policies rules create 4000 \
  --security-policy=my-waf-policy \
  --expression="true" \
  --action=rate-based-ban \
  --rate-limit-threshold-count=100 \
  --rate-limit-threshold-interval-sec=60 \
  --ban-duration-sec=600 \
  --conform-action=allow \
  --exceed-action=deny-429 \
  --description="Rate limiting per IP"

# ===== ポリシーを LB バックエンドサービスに適用 =====
gcloud compute backend-services update my-backend-service \
  --security-policy=my-waf-policy \
  --global

【Adaptive Protection とは？】

Google の ML モデルがトラフィックを分析:
  ├── 通常のトラフィックパターンを学習
  ├── 異常なトラフィック（DDoS の可能性）を検出
  ├── ブロックルールを自動提案
  └── ワンクリックで適用可能

設定方法:
  gcloud compute security-policies update my-waf-policy \
    --enable-layer7-ddos-defense

→ 大規模 DDoS 攻撃時に自動的に保護ルールを適用

【SCC の目的と位置づけ】

Security Command Center = Google Cloud のセキュリティ管理センター

機能:
  ├── 脆弱性の自動検出（VM の設定ミス、公開バケットなど）
  ├── 脅威の検出（不審な操作、マルウェアなど）
  ├── コンプライアンス状況の可視化（CIS Benchmark など）
  └── セキュリティスコアの提供

【SCC のサービス階層】

Standard（無料）:
  ├── Security Health Analytics（設定ミスの検出）
  ├── Web Security Scanner（基本）
  └── Cloud Asset Inventory との統合

Premium（有料）:
  ├── Event Threat Detection（リアルタイム脅威検出）
  ├── Container Threat Detection（GKE の脅威）
  ├── Virtual Machine Threat Detection（VM のマルウェア）
  └── Web Security Scanner（高度）

# SCC の所見一覧を確認
gcloud scc findings list ORGANIZATION_ID \
  --source=ALL \
  --filter="state=ACTIVE AND severity=HIGH" \
  --format="table(name,category,severity,state)"

# 特定のプロジェクトの所見
gcloud scc findings list ORGANIZATION_ID \
  --source=ALL \
  --filter="resourceName:projects/my-project AND state=ACTIVE"

# 所見を解消済みとしてマーク
gcloud scc findings update FINDING_NAME \
  --source=SOURCE_ID \
  --organization=ORG_ID \
  --state=INACTIVE

【Binary Authorization の目的】

問題:
  「誰でもどんなコンテナイメージでも GKE にデプロイできる」
  → サプライチェーン攻撃に弱い
  → テストしていないイメージが本番に入るリスク

解決策: Binary Authorization

CI/CD パイプライン:
  コードビルド → テスト合格 → 承認済み署名をイメージに付与

GKE デプロイ時:
  Binary Authorization がポリシーを確認
    ├── 有効な署名あり → デプロイ許可 ✅
    └── 署名なし / 無効な署名 → デプロイ拒否 ❌ + アラート

【防げる攻撃】
  ├── 承認されていないイメージの誤デプロイ
  ├── サプライチェーン攻撃（npm パッケージへの悪意のあるコード）
  └── 開発者による手動デプロイ（CI/CD をバイパス）

【デフォルト拒否（Default Deny）の原則】

ネットワークのデフォルト状態:
  すべてのトラフィックを拒否
    ↓ 明示的に許可したもののみ通過

GCP のデフォルトファイアウォール:
  ├── INGRESS: すべて拒否（デフォルト）
  └── EGRESS: すべて許可（デフォルト）
      ↑ 本番環境では Egress も制限することを検討

# ===== 推奨パターン: タグベースのルール =====

# Web サーバーへの HTTP/HTTPS のみ許可
gcloud compute firewall-rules create allow-http-https-to-web \
  --network=prod-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --target-tags=web-server \        # web-server タグを持つ VM のみ
  --source-ranges=0.0.0.0/0 \
  --description="Allow HTTP/HTTPS traffic to web servers"

# App サーバーへはロードバランサからのみ許可
gcloud compute firewall-rules create allow-app-from-lb \
  --network=prod-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:8080 \
  --target-tags=app-server \
  --source-tags=web-server          # web-server タグからのみ

# DB サーバーへはアプリサーバーからのみ許可
gcloud compute firewall-rules create allow-db-from-app \
  --network=prod-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:5432 \
  --target-tags=db-server \
  --source-tags=app-server          # app-server タグからのみ

# SSH は IAP からのみ許可（外部からの直接 SSH を完全ブロック）
gcloud compute firewall-rules create allow-ssh-iap \
  --network=prod-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:22 \
  --target-tags=ssh-allowed \
  --source-ranges=35.235.240.0/20   # IAP の IP レンジ

# ❌ 危険: SSH を全世界に公開
gcloud compute firewall-rules create bad-ssh-rule \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=0.0.0.0/0   # すべての IP から SSH 接続可能！

# ❌ 危険: タグなし（全 VM に適用）
gcloud compute firewall-rules create bad-rule \
  --action=ALLOW \
  --rules=tcp:3389 \           # RDP を全 VM に公開
  --source-ranges=0.0.0.0/0

# ✅ 修正: IAP からの SSH のみ許可、特定タグの VM のみ
gcloud compute firewall-rules create good-ssh-rule \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20 \  # IAP の IP レンジ
  --target-tags=bastion-only          # 限定された VM のみ

【OS Login の多層防御効果】

層1: IAM（誰が SSH できるか）
  roles/compute.osLogin        → SSH 接続（sudo なし）
  roles/compute.osAdminLogin   → SSH 接続（sudo あり）
  → IAM で制御されるため、退職者は即時アクセス不可

層2: OS Login 自体の設定
  enable-oslogin=TRUE          → OS Login 有効化
  enable-oslogin-2fa=TRUE      → 2 要素認証必須

層3: ファイアウォールルール
  SSH は IAP からのみ許可（35.235.240.0/20）
  → 外部 IP からの直接アクセスを完全ブロック

層4: 組織ポリシー（強制適用）
  constraints/compute.requireOsLogin
  → 全 VM で OS Login を強制（設定し忘れ防止）

→ この 4 層すべてを通過しないと VM にアクセスできない！

【パターン①: IAM ロールの選択問題】
「フロントエンドエンジニアは Cloud Run へのデプロイと
 Artifact Registry からのイメージプルができる必要がある。
 最小権限のロールはどれか？」

考え方:
  Step 1: 必要な操作を特定
    ├── Cloud Run のデプロイ → roles/run.developer
    └── Artifact Registry の読み取り → roles/artifactregistry.reader

  Step 2: 基本ロールは選ばない
    ❌ roles/editor（過剰権限）
    ✅ roles/run.developer + roles/artifactregistry.reader

【よくある誤答パターン】
  ❌ roles/owner（問題外の過剰権限）
  ❌ roles/editor（多くの不要な権限が含まれる）
  ✅ 事前定義ロールの組み合わせ または カスタムロール

【パターン②: SA キーの代替手法の問題】
「GitHub Actions から GCP のリソースを操作したい。
 最もセキュアな方法はどれか？」

正解: Workload Identity Federation
  → GitHub OIDC トークンを GCP トークンに交換
  → SA キーを GitHub に保存しない

【パターン③: シークレット管理の問題】
「Cloud Run アプリがデータベースのパスワードを必要とする。
 最もセキュアな管理方法はどれか？」

正解:
  Secret Manager にパスワードを保存
  Cloud Run の --set-secrets フラグで環境変数として注入
  SA に roles/secretmanager.secretAccessor を付与

【パターン④: ネットワークセキュリティの問題】
「本番環境の VM への SSH アクセスをセキュアにしたい。
 外部 IP を持たない VM にも接続できるようにしたい。」

正解: IAP トンネル + OS Login

【攻撃経路別のセキュリティサービス】

① 認証・アクセス制御
   IAM: 誰が何をできるか
   OS Login: VM への SSH アクセス
   IAP: VPN 不要のゼロトラストアクセス
   Binary Authorization: 承認済みコンテナのみデプロイ

② シークレット・データ保護
   Secret Manager: パスワード・APIキーの安全な管理
   Cloud KMS: 暗号化キーの管理・CMEK

③ ネットワーク防御
   Cloud Armor: DDoS・WAF（外部からの攻撃）
   VPC Firewall: ネットワーク層のアクセス制御
   VPC Service Controls: データ持ち出し防止

④ 可視化・検出
   Security Command Center: 設定ミス・脅威の検出
   Cloud Audit Logs: 誰が何をしたかの記録
   Cloud Asset Inventory: リソース・IAM の全体把握

【ロールの種類と特徴】

基本ロール (Basic Roles):
  「オーナー」「編集者」「閲覧者」。広範なアクセス権を提供。
  本番環境での使用はセキュリティ上の観点から強く非推奨。

事前定義ロール (Predefined Roles):
  Googleが保守。特定のサービスやジョブ機能に特化した細粒度の権限を提供。
  本番環境における標準的かつ最も推奨される選択肢。

カスタムロール (Custom Roles):
  組織独自の要件に適合させるため、任意の権限を組み合わせて定義。
  編集権限を持つプリンシパルに対する厳格な制限が必要（特権昇格リスク）。

【Read-Modify-Write パターン】

大規模な変更をREST APIやクライアントライブラリを通じて実行する場合:
1. Read: getIamPolicy() で現在の許可ポリシーと ETag を取得
2. Modify: JSONオブジェクトに対してプリンシパルの追加・ロール変更を適用
3. Write: setIamPolicy() で送信し、サーバー側で ETag を比較

【Thundering Herd 問題の回避】
IAM APIリクエストが失敗した場合、「ジッター（揺らぎ）を伴う切り捨て指数バックオフ」を適用。
待機時間 = min((2^n + random-fraction), maximum-backoff)
※ 409 (Conflict) エラーの場合は、単なる再試行ではなく、getIamPolicy() からやり直す。

2024年のセキュリティ動向レポートによると、認証情報の脆弱性がクラウド侵害の約76%を占めます。
Google Cloudは2024年5月以降、デフォルトで iam.disableServiceAccountKeyCreation の強力な組織ポリシーを適用しています。

キーを使用せざるを得ない環境での運用ルール:
・一時ディレクトリや公開された共有フォルダに絶対に放置しない。
・ユーザー間で電子メールやチャットツールを通じて直接受け渡ししない。
・GitHubやGitLabなどのソースコードリポジトリにキーを含めてコミットしない。
・アプリケーションの実行バイナリの内部にキーをハードコードして埋め込まない。
・定期的なローテーションポリシーを確立し自動化する。

【監査ログの4つのカテゴリ】

管理アクティビティ監査ログ (Admin Activity):
  リソースの構成変更を記録。強制的に有効（無料）、400日間保存。

データアクセス監査ログ (Data Access):
  ユーザーデータに対する作成・変更・読み取りを記録。
  デフォルト無効。有効化時は膨大なボリュームに注意。
  「免除されたプリンシパル」を設定してノイズを削減することが重要。

システムイベント監査ログ (System Event):
  Google Cloudシステム側が自律的に実行したイベント。常に有効（無料）。

ポリシー拒否監査ログ (Policy Denied):
  セキュリティポリシー違反や拒否されたアクセス試行を記録。デフォルト有効。