IAMのEditor権限を広げすぎて退職者がアクセスできた話

監査ログを初めてちゃんと見た日

セキュリティ担当から連絡が来たのは定期的なセキュリティ監査のタイミングだった。「Cloud Audit Logを確認したところ、先月退職されたAさんのGoogleアカウントでCloud Storageへのアクセスが記録されています。退職後3ヶ月経っていますが、IAMから削除されていないようです」。読んだ瞬間に頭が真っ白になった。

問題は2つ重なっていた。ひとつ目はIAM設計が雑だったこと。プロジェクト初期はメンバーの入れ替わりが多く、細かく権限を分けるのが面倒だという理由で、エンジニア全員をプロジェクト単位でEditorにしていた。Editorはほぼ全リソースへの読み書き権限を持つ強力な権限だ。

なぜ削除漏れが起きたか

ふたつ目は退職時の処理手順に漏れがあったことだ。Aさんは外部委託のエンジニアで、個人のGoogleアカウントでIAMに追加されていた。社内の正社員であれば退職時にGoogle Workspaceのアカウントを無効化すればGCPのアクセスも実質できなくなる。しかし組織外の個人アカウントの場合、Google Workspaceとは連動しない。GCPプロジェクトのIAMから手動で削除するしかないが、そのステップがオフボーディング手順書に明記されていなかった。

幸い退職後のアクセスログを詳細に確認したところ、Aさんのアカウントによるアクセスは退職前の最終稼働日のもので止まっており、退職後の実際のアクセスは確認されなかった。「アクセスできる状態だった」という事実があるだけで実際の不正アクセスは発生していなかった。だがそれは運が良かっただけだ。

IAM管理の仕組みを作り直した

この件を機にIAM管理を根本から見直した。外部委託エンジニアには個人アカウントではなくサービスアカウントを払い出し、必要最小限の権限のみを付与する運用に変えた。IAMの棚卸しを月次でスプレッドシートで管理し、退職・契約終了の際はIAMからの削除をチェックリストの必須項目にした。また、Organization Policy Serviceを使い、IAMに追加できるアカウントのドメインを自社ドメインのみに制限した。これで外部の個人アカウントを誤ってIAMに追加することが原理的にできなくなった。IAMは「設定したら終わり」ではなく、定期的なレビューが必要なものだということを、この経験を通じて痛感した。