【GCPでセキュリティの柱を築く】セキュアで統制の効いたGoogle Cloudを設計する(組織を構成する)
こんにちは、クラウドアーキテクトの山下です。
前回はGoogleCloudで設計を行う上での基礎となる概要について触れてきました。
今回は実際にセキュアな設計を行う上でガードレイル(Guardrail)となる組織の考え方と計画について触れたいと思います。
クラウドは様々なプロジェクトやシステムで利用されます。そのため、システム要件や使うサービスは一様ではありません。一方、それぞれの設計を統制を効かせてベストプラクティスを全てに当てはめる事は出来るでしょうか？プロジェクト数が少ない場合は出来るでしょうが、多数のプロジェクトや性質が違うプロジェクトが存在する場合はこれが厳しくなってきます。GoogleCloudの”組織”を用いる事でこの課題を一部解消する事ができます。
組織について紹介されている記事や書籍も多いので、今回は設計観点と他社クラウドとの比較に焦点を当てて触れていきます。
組織、フォルダ、プロジェクト
Google Cloudは組織、フォルダ、プロジェクトの階層構造から定義が行われており、組織(ドメインを持つCloud IdentityまたはGoogle Workspace)を親として部署やシステム、サービス群をまとめたフォルダと最終的にリソースが作成されるプロジェクトから構成されています。
組織やフォルダを構成せずともプロジェクトだけでGoogle Cloudを利用する事が出来ますが、個人や部署で個別契約されたプロジェクト、いわゆるRogue Cloud(野良クラウド)の発生やそれに対する是正と統制を行えません。
組織、フォルダを利用するメリットはリソースやシステムの整理もありますが、全体にセキュリティ統制を効かせられるのが最大のメリットです。
組織を利用する事により、配下のフォルダとプロジェクトに以下のサービスを適用しセキュリティの是正をする事が可能です。組織からユーザ向けのフォルダとプロジェクトを払い出すことで野良クラウド、ユーザ責でのセキュリティ設計の委任を抑制できます。
[適用できるサービス/機能]
- Cloud Identity, Google Workspaceに紐づくグループ/ユーザ連携
- Beyondcorp Enterprise(Chrome Enterprise)
- 組織のポリシー
- Security Command Center
- VPC Service Controls
- 組織内での共有VPC
- 組織全体の監査ログ
- 組織全体のAsset Inventory
- 組織全体のAccess Context Manager
- 組織全体の請求状況/アラート管理
- 組織全体でのサポート利用
- …などなど
組織を設計する
IDとアクセスを設計する
AWSとは異なり、GoogleCloudはAzureに近くドメイン(組織)配下にプロジェクトが存在します。さらに、GoogleCloudにはIAMユーザーやEntraIDユーザーに当たるものはなく、GoogleアカウントにIAM権限を付与する運用となります。
ここに制限を設けないとxxxxxx@gmail.comなどの個人アカウントをプロジェクトや組織に権限追加できてしまいます。組織とCloudIdentity及びWorkspaceを連携する事で、ドメインのGoogleアカウントおよびグループにアクセスを限定出来ます。
また、EntraIDのようなIDaaS側でユーザーディレクトリを作成し、CloudIdentityに連携させることも可能です。
ユーザーディレクトリをどこに置くか、どのドメインからのアクセスを許可するのかを設計していきます。
| Cloud Identity | GCP利用に必要最低限でよい場合に。無償で利用も可能。 |
|---|---|
| Google Workspaces | GCPだけでなくオフィス関連のサービスやDriveなどを利用したい場合に。 |
| 外部IDaaS(EntraID,LDAP,Okta) | すでにEntraIDなどで従業員名簿とSSOを構成している場合に。※上記いずれかと連携は必要です。 |
組織の役割と担当者を決める
GoogleCloudをはじめとしてパブリッククラウドでは一般的に最小権限の原則が定められています。
役割以上の過剰な権限の付与や付与対象者が無制限の場合に対象となります。最小権限の原則に従い、この割り当て先を絞る事で統制を効かす事が出来ます。
**設計のベストプラクティスとしてこの権限付与を2名以上にする事が推奨されています。**担当者の退職やGoogleアカウントにログイン出来ず復旧できないリスクがあるためです。
さらにMFA設定を行う事でこれをさらに制限できます。この辺りはパブリッククラウドでは一般的ではありますが、組織全体に及ぶものとシステム単位で役割を分けられます。
Google推奨の設定
GoogleCloudではサンプルの権限として以下を提案しています。
これに完全に従う必要はありませんが、設計の参考になります。必須のものはエンタープライズ企業、中小規模の組織でも有用です。加えて企業/組織に合わせて任意のグループを追加する事で役割に応じたグルーピングができます。
請求管理グループ: 必須
請求/支払いに関わる業務が行える権限です。購買部がクラウドのコスト管理をしている場合や決済権を持つメンバーとクラウド管理を行うメンバーを分けたい場合に有用です。
- 請求先アカウント管理者
- 請求先アカウント作成者
- 組織閲覧者
組織管理者グループ: 必須
GCP組織の運用に関わる全ての権限を有します。
支払いからPJ払い出し、セキュリティ運用に関わるまで様々です。
まずはこのグループをCloudIdentityかGWSに作成し必要なメンバーを入れ、フォルダやプロジェクトレベルの利用者は入れないようにします。
- 組織の管理者
- フォルダ管理者
- プロジェクト作成者
- 請求先アカウント ユーザー
- 組織のロールの管理者
- 組織ポリシー管理者
- セキュリティ センター管理者
- サポート アカウント管理者
- Pub/Sub 管理者
セキュリティ管理者グループ: 任意※セキュリティ専門部署がいれば
組織もその配下も全て含んだセキュリティに関わる業務が行える権限です。組織管理者グループからセキュリティ関連サービスやIaaSの監視部分だけ抽出したような権限です。SOC部署などを持つ大きな組織/企業にはおすすめのグループです。
- 組織ポリシー管理者
- セキュリティ管理者
- セキュリティ審査担当者
- サービス アカウントの作成
- 組織のロールの閲覧者
- セキュリティ センター管理者
- フォルダ IAM 管理者
- プライベート ログ閲覧者
- ログ構成書き込み
- Kubernetes Engine 閲覧者
- Compute 閲覧者
フォルダ/プロジェクト構成を考える
フォルダを活用する事を考えましょう。会社の組織構造と合わせて部署単位、システム単位でのフォルダを構成する事で管理をシンプルに出来ます。
組織管理者が配下のフォルダやプロジェクト全体を管理、またはその逆となると最小権限の原則を満たせなくなります。組織管理者は組織単位の管理にフォーカスし、フォルダやプロジェクトの払い出しは行うものの、配下の各部署やシステム担当者に管理を委ねていきます。
とはいえ、フォルダの策定が一番骨が折れるのが現実かと思います。毎年の組織改編や担当者の変更、どの管理部門が責任を持つか曖昧なのが現実だからです。
そのため、システム毎にフォルダを分けるのが現実的だと考えています。後からプロジェクトのフォルダ移行は可能ですが、毎年プロジェクトを移行するのは労力を要するでなく思わぬ事故を招きかねません。
一方、組織管理者グループとは異なる横串の組織(SOC部隊、DevOps部隊、BI/分析部隊、コーポレート部署…etc)については特定のシステムではなく複数のシステムにまたがる管理を行うと思います。
これを満たすために横串の部署についてはフォルダ/プロジェクトではなくGoogleグループ(CloudIdentity,GWS,グループ単体)でこれを束ねて、最小権限を組織レベルで割り当てる事が有用と考えています。
監査とオブザーバビリティを集約する
GoogleCloudではデフォルトで監査ログ(AuditLogs)が収集されています。プロジェクトについてはこのログがデフォルトで収集/保管されていますが、組織レベルでは監査ログに配下のプロジェクトの監査ログも含まれます。また、Cloud Identity/Workspaceについてもログを集約する事が可能です。
一方で監査ログの結果をBigQueryで分析したい、CloudStorageに入れてコスト削減をしたい、Pub/Subと連携して外部のSIEM基盤などに送りたい場合など一元化だけでは満たせない要件もあります。その場合は、組織管理プロジェクトを作成する事も考えてみましょう。
フォルダ/プロジェクト構成のところではシステム毎に分かれるのがおすすめと紹介しましたが、集約が必要かつ共有のリソースを利用している場合は専用のプロジェクトを払い出すはあると考えています。
まとめ
組織はGoogleCloud利用に統制を効かせるために非常に有用な機能です。つい優れたマネージドサービス群でシステム開発を行う事にフォーカスしがちですが、セキュリティや運用がバラバラではせっかく開発したサービスもリスクに晒されて台無しになってしまいます。
企業内で統制を効かせる事で管理工数が減るだけでなく、セキュリティも担保し、コスト管理による無駄の排除も実現できます。どんなに小規模なシステムであっても開発/本番などの環境が２つ以上あるのであれば組織を構成し始めましょう。後に拡大したとしても活きてくるようになります。
Discussion