【GCPでセキュリティの柱を築く】Google Cloudで組織を構築する

こんにちは、クラウドアーキテクトの山下です。

前回はGoogleCloudで設計を行う上での基礎となる概要と設計について触れてきました。今回は実際に設計した内容を元に構成を行っていきます。

組織があるのは書籍や資格学習で分かりつつも、検証でGoogle Cloudを利用する場面や１システムの開発/構築担当の場合、”組織なし”のフォルダやプロジェクトを触る事が実際多いのではないでしょうか？

今回は数プロジェクトが稼働しており、GoogleCloudを利用し始めた想定で行っていきます。そのため、全ての機能については触れませんがスモールスタートだとしても何を行えばよいのかが分かる内容となっております。

また、この設定は後からやり直しや見直し可能です。準備や調整に追われて組織を作成する面倒さやハードルを感じる前に、まずは構成してみることをおすすめします。

組織を構成する

実際に組織を構成する事を本記事では行っていきたいと思います。

まずGoogleCloudのコンソールよりIAMと管理から”IDと組織”を選択します。

そのままチェックリストに移動します。このチェックリストを利用する事で組織全体の構成に必要な設定を簡潔に行う事ができます。

このチェックリストについて組織は必須ですが、階層構造やロギング、モニタリング、セキュリティなどは必須項目ではありません。予め設計や方針を決めて進めるのが望ましくはありますが、⑦VPCネットワーク⑧ハイブリッド接続⑨モニタリングなどは要件次第で使わない場合もあるため、チェックできていなくても問題ありません。また、後から再度チェックリストを見直す/やり直すこともできます。定期的に見直して最適化を図りましょう！

組織の作成

組織の構成にはドメインとそれに紐づくCloud IdenityかWorkspaceのアカウントが必要となります。チェックリスト内に詳細に組織とCloud Identity, Workspaceのいずれが推奨か説明がされていますので割愛しますが、Workspaceを使う予定がなければ原則Cloud Idenityを使います。

いずれの場合もドメインの取得が前提条件になります。Square Domains(Google Domains)やCloudDNSに限らず予めドメインを取得します。また、申込時にドメイン購入をその場で行う事もできます。

Cloud IdentityまたはWorkspaceの初期設定、ドメイン確認が完了すると組織が払い出されます。前回の設計で触れたIDの選択に合わせてこちらを選択します。

※Cloud IdentityもWorkspaceもGoogle Cloudの組織/フォルダ/プロジェクトのいずれにも当てはまらない独立したID基盤(i.e. EntraID,LDAP,Okta等に相当)です。IAMやEntraIDなどクラウド側のリソースではありません。

グループを構成し権限を付与する

ユーザとグループのタブに移ります。前回のIDとアクセスで触れた内容です。GoogleCloudでは事前定義のグループサンプルが用意されています。各業務毎にグループ名が定義されておりCloudIdentityの権限を持っていれば、この画面からグループの作成を簡単に行う事ができます。

また、ここに表示されるグループを全て作成する必要はありません。設計時点で必要と判断したグループ及び役割に相当するものだけを作成で問題ございません。今回は組織管理者グループと請求先アカウント管理グループの２つを作成します。

※個別で異なる命名を行いたい場合は独自に定義する事も可能です。特に理由がなければこちらで行うのが手軽ですが、この項目は必須ではないので先に飛ばすことも可能です。

次に管理者権限のメニューに移ります。前のメニューでグループを作成していた場合にこちらでグループが”構成していない既存のグループ”として自動検出されます。

“構成”を選択することでグループに付与する組織レベルのIAMポリシーバインディングを簡単に割り当てる事ができます。役割に応じたグループに必要な最小権限をIAMメニューではなくこちらでサクッと割り当てられます。内容に問題なければ、”保存してアクセスを許可”をクリックします。

※より細かい制御を行いたい、Googleのサンプルでは満たせない場合は前項同様にここをスキップして問題ございません。後からやり直しもできます。

課金を構成する

今回は組織に関わる内容のため、割愛いたしますが組織に関わる請求を請求先アカウントにここでは紐づけられます。請求先アカウントと組織、配下のプロジェクトを紐づける事で請求先アカウント(課金)メニューで各プロジェクトの利用状況を把握する事ができます。

はじめに

⑤階層とアクセスから⑨ハイブリッド接続までは自動で設定されるわけではなく、Terraformテンプレートが最終的に提供されます。CloudShellやGCEなどマシン、ラップトップ上でTerraform applyして初めて適用となります。そのためやり直しも出来ますし誤って設定しても問題ありません。

階層とアクセスを構成する

組織/フォルダ/プロジェクトの階層構造が見えているのであれば、この項目を進めますが利用して間もない、まだシステム数が少ない、各部署や担当と調整が済んでいない場合は飛ばしてもよい項目です。

一方、ある程度決まっている場合は、組織/フォルダ/プロジェクトの階層構造を一度に構成できる階層とアクセスのメニューに移ります。リソース階層の”開始”を選択します。

推奨される構成で４パターンのサンプルが提示されます。

こちらについてはどれを選んでも正しいですが、前回のブログ記事でも触れた通り、システム単位で階層を構成しその配下にプロジェクトを構成するのが良いのではないかと考えています。部署移動やシステムの統廃合対応に柔軟に対応できるためです。

そのため、私の場合はチーム指向の階層を選択して命名を変えて対応します。

しかし、フォルダ単位でセキュリティ統制を行いたい場合などは環境志向の階層を選ぶのも有用です。デプロイするメンバー、監視するメンバーだけProduction(本番)環境フォルダにアクセス権を与えて簡単に統制をかけることもできるからです。個々の状況に合わせて選択を行っていきましょう。

作成した構成に合わせてグループとフォルダ/プロジェクトを紐づける事がここでは可能です。さらに先ほど定義した階層構造用のGoogleグループの作成と権限割り当ても定義できます。

ロギングの一元化

この項目も飛ばす事ができ、Terraformで適用することで初めて構成されるものですが、個人的にはこちらの設定は飛ばさずに実施をおすすめします。

というのも、組織だけでなく配下のプロジェクト全体の監査ログを一元化できるためです。今後プロジェクトやフォルダが追加された後でも統合されたログが集められます。

推奨項目であるCloud Loggingのログバケットに集めるのが一番シンプルでクエリでの検索も行えるためおすすめです。

さらにLoggingから転送を後で設定もできます。コスト重視ならCloudStorage、より細かいクエリやダッシュボード、レポート作成をしたいならBigQuery、外部のSIEMなどに送りたい場合はPub/Subなど選択は他にもあります。いずれにせよ集めておくにこしたことはないでしょう。

コンプライアンス要件がなければGlobalバケット、海外へのデータ保存が許容されないなら特定のリージョンを選択、保管期間も要件に合わせて90日や2年なども設定できます。他に転送しないなら長期、CloudStorageで長期保管ならログバケットは数十日などもできます。

セキュリティを構成する

セキュリティの構成についてはここで行わない方がよいと考えています・・・。シンプルに設定を行えますが、より細かな要件を適用することはできないためです。SecurityCommandCenterは料金がある程度かかるのと設定項目も多数あります。組織ポリシーも同様に項目数が多いだけでなく除外設定など個別対応も考えると実際はもっと綿密に行いたいところです。個人的にはここは後回しにして個別に設定を行います。

VPCネットワーク/ハイブリッド接続を構成する

プロジェクト毎にVPCをそれぞれ構成する事が可能ですが、GoogleCloudでは組織内のプロジェクト間で共有できるVPCまたは専用線接続先を構成する事ができます。

多数の既存オンプレミスシステムがあり、リフト＆シフトしたい場合やDevOpsツール群を一元管理したい場合、専用線接続を各プロジェクトに行わせないなど費用面や運用面でのメリットを得るためにこちらをうまく構成するのは有用です。

しかし、そういった要件がない場合はこの項目については飛ばしてしまってもよいと考えています。VPCを共有する事が予め見えているのであれば活用しましょう。

モニタリングを統合する

組織全体のリソース使用状況やアラートの確認など運用者目線で必要な対応をここでは設定する事ができます。運用者が横串で存在しており、各システムの担当者が運用/監視していない場合に有用です。

こちらも必須ではないため割愛しても問題ないですが、会社のサービス稼働状況やインシデント検出を一元化できるので多数の商用システムが稼働しているような企業には大変嬉しい機能です。

この項目は前項までのグループ作成と階層とアクセス制御で監視者向けの内容を行った、または手動でこれらを設定した場合の前提とその後の設定方法が書かれており、自動で何か適用されるものではありません。

サポートを構成する

GoogleCloudの有償サポートを組織全体で受けたい場合に設定する事ができます。サポートの対応言語、対応スピード、技術レベルなどを選び適用できます。速報性や重要なインシデント対応が求められる場合は有効にしますが、スモールスタートや運用者にある程度ナレッジがある場合はここについて飛ばしても構いません。逆に有効にしてあとから変更することもできます。

まとめ

組織について構成を設計して適用するまで非常にハードルが高いように思えますが、この記事で見てきた通り非常に簡単に構成する事ができました。

もちろん考えないといけない項目や調整を要するものも多くありますが、まずは組織を作成してしまって最低限必要な設定を入れて後から機能を拡充することもできます。少し心配になるかもしれませんが、全てを満たさなくても良いのです。

できるところから、しかし、今後の運用とセキュリティ、コスト最適化を目指すために組織は可能な限り構成をしていきましょう。