Google Cloud IAM一時付与システムを「作らなかった」話

この記事は10Xアドベントカレンダー2024の21日目の記事になります。 昨日はBizdevの勝谷さんが「 全国のスーパーマーケットを回る10XのBizdevが出張で出会った美味しかったもの3選 | Notion 」の記事を公開しています。

はじめに

こんにちは、10X在籍3年目のSREの栗原です。 今回は、以前に検討していたGoogle Cloud IAMの一時付与システムについて、その設計思想と最終的に「作らなかった」理由についてお話ししたいと思います。

作ろうとした理由と、作らなかった理由

弊社では、Google CloudのIAM管理をTerraformで一元管理しています。TerraformはIaCとして優秀なツールですが、開発者が一時的に権限を必要とする場合、TerraformのPR作成、レビュー、マージというプロセスを経る必要があり、その体験は必ずしも良いとは言えませんでした。また、作業後に権限を削除をしなければ、そのまま権限が残り続けてしまうというセキュリティリスクも孕んでいます。

これらの課題を解決するため、一時的なIAM付与を自動化するシステムを検討していました。しかし、Google Cloud PAM(Privileged Access Management)の登場により、これらの課題は全て解決できると判断し、自作のシステム開発は見送ることとなりました。今回は、その供養として検討していたシステムの設計思想について共有させてください。

システム構成

今回検討していたシステムは、以下の図のような構成を想定していました。

API Server

API Serverは、クライアント(Slack botなど)からのリクエストを受け付け、IAMの一時付与を処理する中心となるコンポーネントです。APIリクエストには、以下のパラメータが含まれます。

  • 依頼者のメールアドレス
  • 付与したいIAMロール
  • 付与期間

API Serverでは、以下の処理を行います。

  1. メールアドレスのドメイン確認: リクエストの送信元が、許可されたドメインからのものであるかを確認します。
  2. JWT (JSON Web Token) の生成: ペイロードに、メールアドレス、付与するロール、付与期間を含むJWTを生成します。
  3. JWS (JSON Web Signature) の生成: Cloud KMSでJWTに署名を行い、JWSを生成します。
  4. 承認用URLの生成: JWSを含む承認用URLをクライアントに返します。

承認フロー

  1. クライアントは、API Serverから受け取った承認用URLを承認者に伝えます。
  2. 承認者は、承認用URLにブラウザでアクセスします。
  3. Cloud IAPによって、承認者のGoogleアカウントでのログインが必須となります。
  4. API Serverは、JWSの署名検証を行い、 その後JWSの有効期限を確認します。Cloud IAPから提供されるリクエストヘッダーに含まれるメールアドレスが、承認者リストに含まれているかを確認します。
  5. 検証が成功した場合、IAMを一時的に付与します。

IAMの付与には、IAM conditionを用います。これにより、指定された期間のみ有効なIAMを付与することが可能になります。

こだわりポイント

このシステムを設計する上で、特に重視したこだわりポイントは以下の3点です。

データベースレス

このシステムには、データベースが存在しません。データベースのメンテナンスやアップデートによる苦労を避けたかったこと、システムをシンプルに保ちたかったことが理由です。データベースレスでも、JWSを活用することで、システムとして破綻することなく、要件を満たしています。

JWSの利用

このようなIAM一時付与システムは、攻撃者にとって格好の標的となりえます。そのため、セキュリティを確保することは非常に重要です。このシステムでは、改ざん検知のためにJWS (JSON Web Signature) を採用しました。JWSによる署名検証を行うことで、リクエストの改ざんを検知し、不正な権限付与を防ぐことが可能です。これにより、外部からの攻撃に対する堅牢性を高め、システム全体の安全性を担保します。

承認フローの導入

IAMの一時付与には、承認フローが不可欠です。このシステムでは、承認フローを実装するために、Cloud IAP (Identity-Aware Proxy) を活用しました。これにより、承認者は自身のGoogleアカウントで認証を行うことができ、API Server側で複雑な承認ロジックを実装する必要がなくなります。さらに、発行される承認用URLには、有効期限(exp claim)を5分に設定しています。そのため、承認者が意図的に承認を行わない場合は、5分経過するとURLが無効となり、IAM付与が行われない仕組みとなっています。これにより、承認フローをシンプルかつ安全に実現しています。

Google PAMの導入と現状

今回、IAM一時付与システムを自作する代わりにGoogle Cloud PAMを導入し、最近その利用を開始しました。Terraformで google_privileged_access_manager_entitlement を定義し、利用者は必要なEntitlementsを選択して申請する仕組みを構築しています。まだ使い始めたばかりで、Entitlementsの種類は少ないですが、利用者のニーズに合わせて順次拡充していく予定です。

まとめ

今回は、Google Cloud IAMの一時付与システムを開発しようとして、最終的に開発を見送った経緯についてお話ししました。Google Cloud PAMの登場は非常に大きかったですが、その過程で考えたシステムの設計思想は、今後のシステム開発にも活かしていけると考えています。