運用担当者がGCPのIAM棚卸しを自動化した話

GCP クラウド

こんにちは。インフラストラクチャーDivの千田です。 主にクラウド（GCPとAWS）やSaaSなどの運用業務を担当しています。

今回は、GCPのIAM権限棚卸しを自動化した取り組みについて、背景や設計の工夫、そして苦労した点・学んだことを紹介します。

背景：棚卸しを自動化する前に何が起きていたか

私自身は、アドウェイズに入るまでGCPを触ったことすらありませんでした。入社後も日々の運用作業はするものの、実際にサービスを使う機会はほとんどないという状態が続いていました。

弊社のGCP環境には、約60のフォルダ、約80のプロジェクトが存在しています。この規模になると、権限管理は次のような課題を抱えていました。

  • サービスアカウント（SA）の利用実績を正確に追えていなかった
    • 最終利用日を確認するにはCloud Loggingを都度手動で調べる必要があり、継続的な実態把握が難しかった。利用実績が分からないままだと、不要になったSAを安心して止めることができない。
  • 未使用SAや過剰な権限の放置に気づけなかった
    • 作ったら作ったままになりがちで、誰にも見つからずに残り続けるケースがあった。過剰な権限を持つSAが放置されると、万が一認証情報が漏えいした際の被害範囲が広がってしまう。

なお、人間のユーザーアカウントについてはMicrosoft Entra ID + SSO連携により、離職時に自動的にGCPアクセスが無効化されます。そのため、優先度が高かったのはSAとGoogle Groupの棚卸しでした。
SAはSSOの管理対象外のため、放置されると気づきにくいという問題がありました。
この状態を解消するため、「まず現状を機械的に可視化し、定期的に確認できる仕組みを作る」という方針で、IAM棚卸しの自動化に取り組みました。

作ったもの：IAM棚卸し自動収集システム

全体のデータフローはシンプルです。毎日決まった時刻に情報を収集し、最終的に棚卸し担当者がスプレッドシート上で確認できる形にしています。

Cloud Scheduler（毎日 9:00 JST）
  └─► Cloud Run Jobs（Pythonスクリプト）
        ├─► Resource Manager API  ── フォルダ/プロジェクトのIAMポリシー取得
        ├─► IAM Admin API         ── SAメタデータ・キー情報取得
        ├─► Cloud Logging API     ── SA認証ログの集計
        └─► IAM Recommender API   ── 過剰権限の推奨事項取得
              ↓
            BigQuery
              ↓ BigQueryコネクタ
      Googleスプレッドシート（棚卸し確認・レビュー）

収集したデータはBigQueryにテーブルとして格納しており、主なテーブルは次の通りです。

テーブル 内容
ユーザーIAMバインディング ユーザーに付与されているロールの一覧
SAバインディング + アクティビティ SAのロール・キー情報・最終利用日・直近90日の認証回数
IAM推奨事項 IAM Recommenderが提示する過剰権限の削除・縮小提案
SA日別認証回数 四半期棚卸しの実績確認に使う、日次蓄積のログ集計
棚卸し対応履歴 実施した対応（SA削除・ロール変更など）の記録

設計で工夫したポイント

「洗い替え」と「蓄積」を使い分ける

IAMポリシーやSAの情報は、実行するたびに最新のスナップショットで上書き（洗い替え）しています。
一方で、SAの日別認証回数だけは洗い替えずに蓄積する設計にしました。理由は、四半期の棚卸しで「直近90日間、そのSAは一度でも使われたか」を確認する必要があるためです。実行時点から過去に遡ってログを都度取得するのはコストも大きく、継続的な実態把握には向いていませんでした。日々の認証回数を蓄積しておき、集計クエリで90日分をSUMする方式にすることで、この課題を解決しました。初回だけは過去90日分をバックフィルするオプションを用意しています。

気づき： BigQueryのストリーミング挿入（insert_rows_json）はストリーミングバッファ中はDELETEができない制約があります。
洗い替え型のテーブルではこれが問題になるため、load_table_from_json（WRITE_APPEND）を使う方式に変更しました。実際に手を動かして初めて気づいた制約でした。

SA削除は段階的に

未使用と判定されたSAをすぐに削除すると影響範囲の見落としが怖いため、「無効化 → 2週間の経過観察 → 削除」という段階的なフローにしています。これは自動化ツールの範囲外ですが、棚卸し全体の安全性を担保するためにこの運用ルールを採用しました。

苦労したこと：運用中心のキャリアからのツール開発

ここまで技術的な話をしてきましたが、正直に言うと一番大変だったのは「このツールをゼロから作ること」自体でした。これまでは運用が中心で、こうしたバッチツールをコードから設計・実装する経験がほとんどなかったためです。具体的には次のようなことに苦労しました。

  • Pythonでのスクリプト設計・実装そのもの
    • モジュールをどう分割するか、config管理やCLI引数の設計など、実装の作法から手探りでした。
  • Cloud Run Jobs / Cloud Schedulerなどの実行基盤の構築
    • コンテナ化やジョブのデプロイ、スケジューリングの仕組みを自分で組むのは初めての経験でした。
  • BigQueryのテーブル設計・クエリ設計
    • 洗い替え型・蓄積型をどう分けるか、90日集計をどう書くかなど、データ設計に慣れていない中での試行錯誤が続きました。
  • GCP各APIの仕様調査・認証周りの設計
    • 複数のAPIを組み合わせる必要がありました。Resource Manager・IAM Admin・Cloud Logging・IAM Recommenderの4つのAPIを使い分けています。それぞれの権限設計やクォータを調べるのに時間がかかりました。

この開発ではClaude Codeを活用しながらコードを組み立てました。普段アプリケーションを書く機会が少ない自分にとって、実装の一つひとつを相談しながら進められたことは、開発未経験からでも「実際に手を動かして形にする」ハードルを大きく下げてくれたと感じています。

そして、それと同じくらい、あるいはそれ以上に支えになったのが、チームのマネージャーの存在でした。方向性に迷ったときや実装で行き詰まったときに都度相談に乗ってもらい、経験からくるアドバイスをもらえたことで、開発未経験の自分でも安心して手を動かし続けることができました。
特に、棚卸しの頻度や対応方針といった弊社独自のルールをどうツールに落とし込むかは、ツールやAIに聞いても答えが出るものではありませんでした。マネージャーに相談しながら整理していくことで、ようやく実装に反映できました。ツールだけでは埋められない部分を、身近に相談できる人がいることで補ってもらえたと感じています。

学び：運用の経験があったからこそ見えたこと

大変なことは多かった一方で、得られたものも多くありました。

運用側の知識があったからこそ見えた設計ポイントがあった

例えば「洗い替えだけでは90日間の利用実績を追えない」という点は、実際に運用作業の中でSAの利用状況を確認してきた経験がなければ気づけなかったと思います。仕組みを作る人と使う人が同じであることの強みを実感しました。

自分で手を動かしてサービスを触ったことが、その後の問い合わせ対応にも役立った

これまでは運用がメインでGCPのサービスの内部にあまり触れていませんでした。テーブル設計やAPIの挙動を自分で理解した状態で運用に入れたことで、後からの問い合わせや設定依頼などにスムーズに対応できるようになりました。

開発未経験でも、相談相手がいれば形にできる

Claude Codeのようなツールを使うことで、運用担当者でも実際に動くシステムを作り上げられることを実感できたのは、今後同じような課題に取り組む人にも伝えたいポイントです。
同時に、困ったときに相談できるマネージャーやチームの存在があったからこそ最後まで作り切れたということも、あわせて伝えたいと思います。

まとめ

今回は、GCPのIAM棚卸しを、Cloud Run Jobs・BigQuery・GCPの各APIを組み合わせて自動化した取り組みを紹介しました。仕組みを作ることで「SAの利用状況や権限の状態を把握しづらい」状態から「毎日データが自動で蓄積され、計画的に確認できる」状態に変わり、権限管理の見通しが大きく改善しました。

また、運用中心のキャリアからツール開発に挑戦したこと自体も、自分にとって大きな学びのある経験でした。同じように「運用は詳しいけれど開発は初めて」という方の参考になれば嬉しいです。