【入門編】 GCP IAMにおけるサービスアカウントキーの管理とローテーション – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

こんにちは！クラウドインフラのセキュリティや認証基盤の仕組みに触れ始めたばかりのエンジニアの皆さん、日々の開発や運用お疲れ様です。

「GCP（Google Cloud）のサービスアカウントキーをどう管理すればいいのか分からない…」
「JSONファイルをダウンロードしてソースコードに直書きしちゃいけないって聞いたけど、じゃあどうすればいいの？」

そんな疑問や不安を抱えていませんか？セキュリティのルールは難しく聞こえるかもしれませんが、実は私たちの日常生活にある「鍵の管理」と同じです。一歩ずつ、分かりやすく紐解いていきましょう！

—

1. 家の鍵をずっと机の上に置きっぱなしにしていませんか？

まずは、GCPの「サービスアカウントキー」がどういうものか、身近な例で考えてみましょう。

サービスアカウントとは、人間ではなく「システムやプログラムがGCPの機能を使うための身分証明書」のようなものです。そして、その身分証明書を証明するためのパスワードやデジタル証明書が「サービスアカウントキー（JSONファイル）」になります。

ここで、よくある危険なシチュエーションを想像してみてください。

  • 開発用のパソコンのデスクトップに、サービスアカウントのキー（JSONファイル）がぽつんと置いてある。
  • あろうことか、そのファイルをうっかりパブリックなGitHubリポジトリにアップロードしてしまった。

これって、「自宅の合鍵を玄関のドアノブにぶら下げたまま、旅行に出かけるようなもの」なんです。泥棒（攻撃者）が通りかかったら、一瞬で家の中（クラウド環境）に入り放題になってしまいますよね。実際に、GitHub等に誤ってアップロードされたキーは、数分〜数時間以内にボットによって自動収集され、仮想通貨のマイニングなどに悪用されてしまう事件が後を絶ちません。

—

2. なぜ「キーのローテーション」だけでは不十分なのか？

「じゃあ、定期的に鍵を作り直せば（ローテーションすれば）安全なんでしょ？」と思った方、素晴らしい着眼点です！

もちろん、定期的なローテーション（古い鍵を無効化し、新しい鍵を発行すること）は非常に重要な防衛策です。しかし、人間が手動でキーを発行し、各サーバーや設定ファイルを書き換えて…というのは、手間がかかる上にミスも起きやすいもの。「あ、あの古いキーの削除を忘れていた！」というヒューマンエラーが、セキュリティ事故の温床になります。

そもそも、「静的なパスワード（鍵ファイル）をディスク上に保存する」というアプローチ自体が、現代のクラウドセキュリティにおいてはリスクの芽になりやすいのです。

そこで登場するのが、今回の主役である「キーレス認証（Workload Identity Federation）」という強力なアプローチです。

—

3. 鍵を持たない新しいセキュリティ：「Workload Identity Federation」とは？

「キーレス認証」と聞くと、「えっ、鍵なしでどうやって本人確認するの？」と驚かれるかもしれません。

現実の世界で例えてみましょう。
昔はホテルに泊まるとき、重くて大きな「物理のルームキー」をフロントから渡されて持ち歩いていましたよね。もしその鍵を落としたら、誰でも部屋に入れてしまいます。
しかし最近の高級ホテルやスマートロックはどうでしょう？ スマホの画面や一時的な暗証番号、あるいは「今ここに私がいる」という証明（生体認証など）を使って、「その都度、一時的な通行証を発行してもらう」仕組みになっていますよね。

GCPの Workload Identity Federation もこれと全く同じです。

外部の環境（GitHub Actions、AWS、オンプレミスのサーバーなど）で動くプログラムがGCPのリソースにアクセスしたいとき、あらかじめGCP側に「こういう条件を満たしていたら信用してね」という信頼関係（フェデレーション）を結んでおきます。

すると、プログラムは長持ちする「秘密のキーファイル」を持たなくても、その都度「私、こういう者ですが、一時的な通行証（アクセストークン）をください！」とGCPにお願いし、数分〜数時間だけ有効な使い捨ての通行証を受け取って作業ができるのです。

これなら、ファイルとして保存される「永遠の鍵」がそもそも存在しないため、万が一ソースコードが流出しても、攻撃者が悪用できる鍵はどこにもありません。

—

4. 実践！GitHub ActionsからキーレスでGCPにアクセスする設定

それでは、一歩進んで具体的な設定の流れを見ていきましょう。今回は、開発現場で最もよく使われる「GitHub Actions」から、GCPのサービスアカウントにキーレス（Workload Identity Federation）でアクセスする例を解説します。

複雑な手順に見えますが、やることは「GCPとGitHubの間に信頼の橋を架ける」だけです。

ステップ1: GCP側でWorkload Identity プールとプロバイダを作成する

まずは、GCPのコンソールまたはGoogle Cloud CLI（gcloud）を使って、外部からの身元確認を受け入れる窓口を作ります。

# 1. プール（窓口の箱）の作成
gcloud iam workload-identity-pools create "my-github-pool" \
    --project="your-gcp-project-id" \
    --location="global" \
    --display-name="GitHub Actions Pool"

# 2. プロバイダ（GitHubを信頼する設定）の作成
gcloud iam workload-identity-pools providers create-oidc "github-provider" \
    --project="your-gcp-project-id" \
    --location="global" \
    --workload-identity-pool="my-github-pool" \
    --issuer-uri="https://token.actions.githubusercontent.com" \
    --attribute-mapping="google.subject=assertion.sub,attribute.actor=assertion.actor,attribute.repository=assertion.repository"

ここでは、「GitHub（token.actions.githubusercontent.com）が発行する身分証明書を信用しますよ」という設定をGCPに行っています。

ステップ2: サービスアカウントとGitHubリポジトリを紐付ける

次に、「この窓口を通ってきたGitHubのリポジトリなら、どのサービスアカウントの権限を使っていいか」という許可を与えます。

# 指定したGitHubリポジトリからのみ、特定のサービスアカウントになりすます（IMPERSONATEする）ことを許可
gcloud iam service-accounts add-iam-policy-binding "your-service-account@your-gcp-project-id.iam.gserviceaccount.com" \
    --role="roles/iam.workloadIdentityUser" \
    --member="principalSet://iam.googleapis.com/projects/YOUR_PROJECT_NUMBER/locations/global/workloadIdentityPools/my-github-pool/attribute.repository/your-org/your-repo"

これで、GCP側の準備は完了です！JSONキーファイルを1つも作っていないことに注目してくださいね。

ステップ3: GitHub Actionsのワークフローを書く

最後に、GitHub側（.github/workflows/deploy.yml など）の設定です。公式の認証アクションを使うことで、驚くほど簡単にキーレス認証が実現できます。

name: GCP Keyless Deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    # GCPへのアクセスに必要な権限（IDトークンを発行するため）を付与
    permissions:
      contents: 'read'
      id-token: 'write'

    steps:
    - name: リポジトリのチェックアウト
      uses: actions/checkout@v4

    # Google Cloud公式のアクションを使って一時的な認証情報を取得
    - name: Authenticate to Google Cloud
      uses: google-github-actions/auth@v2
      with:
        workload_identity_provider: 'projects/YOUR_PROJECT_NUMBER/locations/global/workloadIdentityPools/my-github-pool/providers/github-provider'
        service_account: 'your-service-account@your-gcp-project-id.iam.gserviceaccount.com'

    # 認証完了！あとは通常のgcloudコマンド等がそのまま使えます
    - name: Cloud Storageのバケット一覧を表示してみる
      run: |
        gcloud storage ls

このワークフローを実行すると、GitHubが自動的に一時的な証明書を発行し、GCP側がそれを検証して数分間だけのアクセストークンを渡してくれます。開発者はキーの管理や漏洩のリスクから完全に解放されるのです。

—

まとめ

今回は、GCPのサービスアカウントキーの危険性と、キーレス認証（Workload Identity Federation）への移行戦略についてお話ししました。

  • 従来のJSONキー管理：玄関のドアノブに合鍵をぶら下げているようなもの。漏洩のリスクが常につきまとう。
  • キーレス認証（Workload Identity Federation）：必要なときにだけ一時的な通行証を発行してもらう、ホテルのスマートロックのような安全な仕組み。

「これまで何となくJSONキーを発行していた…」という方も、これを機にぜひキーレスな認証基盤への移行を検討してみてください。一歩ずつ安全な仕組みを取り入れて、安心して開発に集中できる環境を作っていきましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました