サマリ(Github Copilot作成)
このブログでは、Google CloudのIAM設定ミスにより、意図せず本番環境にアクセスできる状態となり問題が発生した事例について解説しています。
主な内容
1.Google Cloudの組織機能とIAMの継承:
・Google Cloudでは、組織配下にフォルダやプロジェクトを階層構造で管理できる。
・IAMポリシーは上位レベルで設定すると下位レベルに自動的に継承される仕組み。
2.期待していたアクセス制御:
・開発者グループは「開発フォルダ」「検証フォルダ」のみにアクセス可能で、本番環境にはアクセスできないように設定することを目指していた。
3.問題の発生:
・実際には、IAM設定のミスにより、開発者グループが本番環境にもアクセスできる状態となってしまった。
4.原因:
・Cloud Identityを利用していたが、組織レベルで「ドメイン」というプリンシパルに「組織の管理者」ロールが付与されていたことが原因。
本編
1.組織の説明について
Google Cloudの組織 (Organization)機能を利用すると組織配下にフォルダを作成でき、フォルダの配下にプロジェクトを作成するという階層構造を作れる。これにより企業全体のリソースを一元的に管理し、セキュリティやコンプライアンスを組織全体で統制することが可能になる。
※組織の詳細はGGEN社ブログGoogle Cloudの組織(Organization)を徹底解説などが詳しいです。
2.組織を利用した際のIAMの継承と今回実現しようとしたアクセス制御について
上位レベル（組織またはフォルダ）で設定されたIAMポリシーは、その下位レベル（フォルダまたはプロジェクト）にも自動的に適用される。
今回私が担当したシステムでは以下のような環境ごとにフォルダを分けるというような構成としていた。
・組織の下に「Aシステム」フォルダを作る。
・「Aシステム」フォルダの下に「開発フォルダ」、「検証フォルダ」、「本番フォルダ」を作る。
・「開発フォルダ」、「検証フォルダ」、「本番フォルダ」の下に同等構成のプロジェクトをそれぞれ作る。
上記構成の元、「開発フォルダ」、「検証フォルダ」、「本番フォルダ」レベルでのみIAMロールを設定するようにしていた。
これにより、個々のプロジェクトでIAM設定をするのではなくIAMの継承によりフォルダ配下のプロジェクトに一気にIAM設定ができるため、設定と権限管理の負荷軽減が実現できていた。
また、IAM設定は「グループ」のみに対して行っていた。
例えば開発者グループは「開発フォルダ」、「検証フォルダ」にのみロールを付与することで、開発者が開発、検証環境にのみアクセスでき、本番環境(「本番フォルダ」配下のリソース)には申請をしないとアクセスできないというような形でアクセス制御を行おうとしていた。
しかし、残念ながら実現したいアクセス制御ができていなかった。
開発者グループは以下の図の緑色の範囲(開発、検証環境)にのみアクセスできることが期待値であったが、赤枠(本番環境)にもアクセスできる状態となってしまっていた。
この際、開発者グループには、「本番フォルダ」に一切のIAMロールをつけていなかった。
なぜであるのか、実はIAMに関する落とし穴にはまっていたのであった。
3.「ドメイン」というプリンシパルの存在について
原因は
「組織」レベルで開発者グループにロールを付与してしまっていた。
そのため、「本番フォルダ」へも開発者グループにロールが継承され、本番環境にアクセスできるようになってしまっていた。。。
というようなわかりやすい話であればどれほど楽であったか。
IAMの継承は組織を利用する際の基礎であるため、上位レベルで不要なロールがないかは穴が開くほど設計していた。そのため、「組織」、「Aシステム」フォルダという上位レベルで開発者グループにロールが付与されているというようなことはなかった。
本当の原因は、「ドメイン」というプリンシパルに組織レベルでロール(それも「組織の管理者」という結構何でもできてしまうロール)が付与されていたためであった。
公式ドキュメントIAMプリンシパルのページを見ると、プリンシパルには以下の種類がある。
- Google アカウント
- サービス アカウント
- Google グループ
- Google Workspace アカウント
- Cloud Identity ドメイン
- allAuthenticatedUsers
- allUsers
- Workforce Identity プール内の 1 つ以上のフェデレーション ID
- Workload Identity プール内の 1 つ以上のフェデレーション ID
- Google Kubernetes Engine Pod のセット
- Resource Manager プリンシパル セット（プリンシパル アクセス境界ポリシー バインディングのみ）
正直、1.2.3くらいしかプリンシパルとして利用できることを意識していなかった。
ただし、「5.Cloud Identity ドメイン」というものがあり
4.具体的な画面
(1)組織レベルでのIAMページの設定画面
・組織レベルのIAM設定は以下の画像 ※ドメイン名はマスキングしています
・赤枠部分が「ドメイン」プリンシパル
・デフォルトでは、組織レベルで「ドメイン」プリンシパルに「請求先アカウント作成者」と「プロジェクト作成者」ロールがついている
→公式ドキュメントデフォルトの組織ロールの管理参照
・「ドメイン」プリンシパルに、なぜか「組織の管理者」ロールがついてしまった。(理由は不明。おそらく設定誤り。)
(2)権限のないユーザで配下のフォルダ、プロジェクトのIAMを編集できてしまう
・以下の画像の通り「user02@ドメイン名」というユーザには一切のIAMロールがついていないため本来組織配下のフォルダ「folder01」にはアクセスできないが、「folder01」のIAMページにアクセスできてしまう。
・Cloud Identityで作成したユーザは「@」以降が「ドメイン名」となるため、明にユーザ(グループ)にロールをつけていなくても、「ドメイン」プリンシパルについているロールの権限がついている状態となる。
※前述の通り、サービスアカウントは「@」以降が異なるため関係ない。
・IAMロールを編集することも可能
・「オーナー」ロールをつけて何でもやることもできる
(3)「ドメイン」プリンシパルからロールを削除すると、期待した権限となる
・「ドメイン」プリンシパルから「組織の管理者」ロールを削除
※ドメインを探す際は、単にドメイン名で検索すると全ユーザ、グループも表示されるため「タイプ：ドメイン」で検索するとわかりやすい
・IAMのページのアクセス権がなくなる。
・組織配下のフォルダもプロジェクトも見れなくなる。
※本来はこれらのページも見れなくなるべきだが、組織レベルで「ドメイン」プリンシパルにデフォルトでついている「請求先アカウント作成者」と「プロジェクト作成者」ロールを残しているため、ページ自体までは到達する。必要であれば「ドメイン」プリンシパルにデフォルトでついている「請求先アカウント作成者」と「プロジェクト作成者」ロールも削除すべし。
最後に(所感)
・セキュリティ周りは思い込みで問題ないと思っても実際は思いもよらない設定となっていることがあるのでテストは大事。
・プリンシパルに関するいい勉強となった。ただし今回は本番データ投入前に私が何気なく本番のページを覗いたことで本事象を検知することができたが、本番データ投入後に顧客側で気付いた場合はベンダ側として大きな責任を取らされることになるため、できればこういった勉強方法は今後はとりたくはない。(気がついていないだけでこういったことはよくあるだろうが。)