G-gen の杉村です。Google Cloud (旧称 GCP) には組織 (Organization) という概念があります。ガバナンスとセキュリティのために重要なこの機能を解説します。
組織の基本
組織 (Organization) とは
Google Cloud の 組織 (Organization) とは、Google Cloud リソースの集中管理と整理のための仕組みです。Google Cloud プロジェクトを始めとする Google Cloud リソースは組織に所属して、管理下に入ることができます。
一つの組織は Google Workspace (Cloud Identity) のテナントと必ず 1:1 で紐付きます。
- 参考 : 組織リソース
リソースの階層構造
まず Google Cloud において、Compute Engine の VM (仮想サーバ) や BigQuery のテーブルなど、一つ一つのオブジェクトは リソース と呼ばれます。
そして、全てのリソースは階層構造をしています。つまり、リソースには 親子関係 があり、関係を図にするとツリー構造で表現されます。
このツリーにリソースが所属している状態を「このプロジェクトは組織 my-domain.com に所属している」のように表現します。
- 参考 : リソース階層
組織リソース
実は 「組織」自体も一つのリソース です。ツリーのトップレベルノード (最上位の節) が組織リソースであり、前掲の図で言うと、最上位にある my-domain.com が組織リソースです。
組織はドメイン名の他に10桁〜13桁程度の数字の 組織 ID を持ちます。また Google Workspace (Cloud Identity) テナントと共通の 顧客 ID (お客様 ID) も存在します。
組織自体がリソースであるため、組織は IAM ポリシー (当社記事参照) を持っていますし、組織に対して CRUD (Create/Read/Update/Delete) 操作をする API が存在します。
なお、組織リソースを操作する Google Cloud API は Resource Manager API (cloudresourcemanager.googleapis.com)です。
フォルダ・プロジェクト
階層を構成する要素として フォルダ と プロジェクト があります。
フォルダはパソコンのフォルダと似ていて、下位のフォルダやプロジェクトをグルーピングするためのリソースです。
プロジェクトはほとんどの Google Cloud リソースが所属する最も基本的な管理単位で、Amazon Web Services (AWS) でいうところの「AWS アカウント」や Microsoft Azure でいうところの「サブスクリプション」と似ています。BigQuery テーブルや Compute Engine の VM など、ほとんどの Google Cloud リソースは一つのプロジェクトの配下に所属します。
フォルダやプロジェクトも IAM ポリシーを持っているので権限管理の単位として使うことができます。また請求先アカウントのレポートでは、組織単位 / フォルダ単位 / プロジェクト単位で請求を分類することができるので請求の管理単位としても利用できます。
フォルダやプロジェクトも Resource Manager API によって CRUD されます。
組織のメリット・ユースケース
組織を使う理由
Google Cloud は組織なしでも利用することが可能です。
無料の Google アカウント (Gmail アカウント) で Google Cloud プロジェクトを作成すると、そのプロジェクトは組織に所属せず「組織なし」となります。この状態でも Compute Engine や BigQuery といった Google Cloud サービスは利用できます。
ただし、ほとんどの企業 (官公庁) では組織機能を使うべきと言えます。以下にそのいくつかの理由と、逆に組織を使わない場合のリスクを解説します。
複数プロジェクト管理
組織を使うメリットは、複数プロジェクトを利用するときに出てきます。
企業や官公庁において、複数のシステムを Google Cloud で開発・運用する際、それぞれのシステムを異なる部署やチームで管理し、またチームごとに異なる権限を付与したい場合があるはずです。
組織機能を使って複数プロジェクトを 組織下に束ねる ことにより、組織のポリシー 機能や IAM、VPC Service Controls などで 継承 の性質を利用したセキュリティ・統制上の集中管理ができるようになります。
継承 (inheritance) は、ここではリソースツリーの親から子の方向へ、IAM 権限や組織ポリシーの設定が引き継がれることを指します。これによって、組織の管理者は、多数存在するプロジェクトなどの Google Cloud リソースに一つ一つ設定を施していく運用オーバヘッドを節約することができます。工数を削減することで効果的に、また現実的な工数で ”ガバナンスを効かせる” ことができるようになります。
利用可能なサービス・機能
後述の組織のポリシー機能をはじめ、重要なセキュリティ機能の多くが組織を有効化していないと使えません。以下は、その例です。
- グループでの IAM 管理
- フォルダ (リソースツリー)
- 組織のポリシー
- VPC Service Controls
- Security Command Center (SCC)
- ログの集約 (ログルーティング、ログシンク)
組織を使わないリスク
逆に組織を利用しない場合、個別のプロジェクトに対して権限管理や統制を行う必要があるため、運用工数が膨れ上がります。
また企業 (官公庁) 内でいわゆる “野良プロジェクト” を許すことになり、意図しないセキュリティ事故のリスクが高まると言えるでしょう。
企業で Google Cloud を利用する場合は、たとえ最初は Google Cloud プロジェクトを一つしか使わない場合でも将来の拡張性も見込んで最初から組織を作成しておき、組織下でプロジェクトを管理することが望ましいと言えます。
組織の作成
Google Workspace (Cloud Identity) と Google Cloud
Google Cloud 組織は Google Workspace または Cloud Identity の組織と必ず1:1になります。そのため Google Cloud 組織を作成するには Google Workspace (Cloud Identity) テナントを作成します。
Google Workspace とは、Google 製のグループウェアツールです。旧称である G Suite の名に聞き覚えのある方も多いでしょう。
Cloud Identity は Google Workspace から Gmail などのグループウェア機能を抜いた代わりに無償または安価に利用できるサービスです。
Google Workspace や Cloud Identity では Google アカウント と呼ばれるユーザーアカウントを作成、管理することができます。
多くの人に親しみのある Amazon Web Services (AWS) ではクラウドリソースとして IAM User を作成しますが、Google Cloud には IAM User は存在しません。Google Workspace で管理される Google アカウントが、そのまま Google Cloud 管理・利用のためのアカウントとなります。
Google Cloud を利用したいが Google Workspace は不要だ、という企業は Cloud Identity でアカウントを管理することになります。Cloud Identity には Free と Premium の2 エディションがあり、50 アカウントまでは無料版である Free を利用できます。
組織の作成方法
Google Cloud 組織を作成するには、まず Google Workspace (もしくは Cloud Identity) のテナントを作成します (正確には Google Workspace アカウント、Cloud Identity アカウントと呼ばれますが、アカウントという名称は Google アカウントと紛らわしいため、当記事ではテナントと表現します) 。
Web の利用申込み画面から組織の情報やドメイン名などを記入し、発行された TXT もしくは CNAME レコードをそのドメインを管理する DNS に追加してドメインを認証することで、利用開始できます。
そのテナントの Google アカウントで初めて Google Cloud コンソールにログインした際に、表示される利用規約に同意すると、そのタイミングで Google Cloud 組織が自動的に作成されます。
テナント (組織) 作成の方法は以下の記事をご参照ください。
組織作成直後の特権
Google Workspace / Cloud Identity の管理者ロールと Google Cloud の IAM 権限は本来は 全くの別管理 です。
Google Workspace / Cloud Identity には「特権管理者」「グループ管理者」「ユーザー管理者」などの管理者ロールがあり、Google アカウントにロールをアサインできます。
一方で Google Cloud では Cloud IAM の仕組みで、リソースベースで IAM 権限を管理します。
Google Workspace の権限管理と Google Cloud の権限管理 (IAM) は本来は完全に別ものであり別管理なのですが、特権管理者だけは例外です。Google Workspace / Cloud Identity の「特権管理者」ロールを持つアカウントは Google Cloud 組織に対しても 組織の管理者 ロール (roles/resourcemanager.organizationAdmin) を持ちます。これは暗黙的な権限であり Google Cloud 組織の IAM 一覧画面には表示されません。
Google Workspace (Cloud Identity) の管理者と Google Cloud の管理者とは体制が別であることも往々にしてあります。その場合は Google Cloud 組織を作成した直後に、Google Workspace (Cloud Identity) の特権管理者アカウントを使い、Google Cloud を管理する担当者の Google アカウント/グループに対して Google Cloud 組織レベルの 組織の管理者 ロール等を付与することで、Google Cloud 環境の管理を委任することが推奨されています。
- 参考 : 組織の作成と管理
- 参考 : 特権管理者アカウントのベスト プラクティス
組織の表示
階層構造 (ツリー) の表示
Google Cloud コンソールで リソースの管理 という画面に遷移すると、組織階層がツリー形式で表示されます。
IAM と管理 の画面の左部メニューから リソースの管理 をクリックするか、Google Cloud コンソール上部の検索ボックスに Manage Resources と入力することで遷移できます。もちろん、gcloud コマンド等で情報を取得することも可能です。
表示に必要な権限
組織とその配下のフォルダやプロジェクトを全て表示するには、組織・フォルダ・プロジェクトに対する get list 権限が必要です。
Google アカウントが組織のトップノードに対して 参照者 (roles/browser) ロールや 組織の管理者 (roles/resourcemanager.organizationAdmin) ロールを持っていれば、組織とその配下の全てのフォルダ・プロジェクトを閲覧することができます。
ただし 参照者 や 組織の管理者 のよくできているところは、組織・フォルダ・プロジェクトのツリー構造を見られる権限はあっても、プロジェクトの中のリソース (Compute Engine VM や BigQuery テーブル等) まで見る権限は持っていないところです。これにより、クラウド環境の全体管理をするチームと、実際の開発・構築を行うチームの権限を分けることができます。
一方でよく用いられる 閲覧者 (roles/viewer) や オーナー (roles/owner) には逆に、組織自体やフォルダに対する get/list 権限がありません。組織トップノードにこれらのロールを付与しても「組織なし (No organization)」として平坦にプロジェクトが一覧表示されます。これらのロールにはプロジェクトに対する get/list 権限はあるためプロジェクトの情報は得られるのですが、組織やフォルダの情報は得られないためです。
あくまで 閲覧者 (roles/viewer) や オーナー (roles/owner) はプロジェクトの 中 を管理するロールであり、前述で言えば「実際の開発・構築を行うチーム」に与えられるロールなのです。
組織の管理
組織の管理者ロール
組織の管理に必要な IAM 権限の考え方についても解説します。
管理担当者の Google アカウントに対して、組織のトップノードレベルで 組織の管理者 (roles/resourcemanager.organizationAdmin) ロールを付与することで、以下のような管理タスクを実行することができます。
- 組織ツリー全体の表示
- 組織トップノードの IAM ポリシーの編集
- 組織配下の全フォルダの IAM ポリシーの編集
- 組織配下の全プロジェクトの IAM ポリシーの編集
組織の管理者 ロールは「何でもできる権限」を持っているわけではありませんが、組織と配下の全フォルダ・全プロジェクトの IAM を編集できることから、自分に対して「どんな権限でも付与できる」ことになります。事実上、最強の権限を持っていると言えます。
強力な管理権限
ただし 組織の管理者 ロールだけでは、フォルダの作成・削除などは行えません。それが行えるのは フォルダ管理者 (roles/resourcemanager.folderAdmin) 等です。 またプロジェクトの作成には プロジェクト作成者 (roles/resourcemanager.projectCreator) が必要ですし、組織のポリシーの管理には 組織ポリシー管理者 (roles/orgpolicy.policyAdmin) が必要です。
以下のロールを組織トップノードレベルで持っていれば、その Google アカウントは組織全体でほとんどの管理・構築タスクを行うことができます。とはいえ、実際には最小権限の原則に従い最小限のロールのみを付与することが望ましいでしょう。
- フォルダ管理者 (roles/resourcemanager.folderAdmin)
- プロジェクト作成者 (roles/resourcemanager.projectCreator)
- 組織の管理者 (roles/resourcemanager.organizationAdmin)
- 組織ポリシー管理者 (roles/orgpolicy.policyAdmin)
また、上記ロールにはプロジェクトの中のリソース (VM や BigQuery データセット等) を操作する権限は入っていません。組織レベル、フォルダレベル、またはプロジェクトレベルで オーナー (roles/owner) ロール等が必要です。
管理の委任
システム単位の管理者や部署のクラウド管理者に対して、フォルダレベルで IAM ロールを付与することで、管理を委任することができます。
例えばフォルダ system-a 以下は john@my-domain.com に管理を委任し、フォルダ system-b 以下は mary@my-domain.com に管理を委任する、という場合は、それぞれのフォルダレベルでそれぞれの担当者に対して フォルダ管理者 ロールを付与することで管理を委任できます。
フォルダ管理者 ロールは、フォルダレベルの IAM ポリシーの編集に加え、そのフォルダ配下のプロジェクトの IAM 権限を編集することができます。
また、プロジェクト単位で管理を委任することも可能です。その場合はプロジェクトレベルで オーナー ロールを付与することなどで実現できます。
どのロールにどのような権限があるかは、以下のドキュメントで確かめることができます。
- 参考 : IAM を使用した組織リソースのアクセス制御
- 参考 : IAM を使用したフォルダのアクセス制御
- 参考 : IAM を使用したプロジェクトのアクセス制御
監査
組織と Cloud Audit Logs
Google Cloud の API 実行履歴は Cloud Audit Logs で収集されます。Cloud Audit Logs の詳細は以下の記事をご参照ください。
Cloud Audit Logs はデフォルトで有効であり「管理アクティビティ監査ログ (Admin Activity audit logs)」と呼ばれる、変更系オペレーションは必ず記録されるようになっています。
しかし「データアクセス監査ログ (Data Access audit logs)」と呼ばれる参照系オペレーションを含む API 履歴を残すためには、明示的に設定する必要があります。
この明示的な設定も、組織内で親リソースから子リソースに継承されます。そのため組織トップノードでデータアクセス監査ログを有効化することで、組織内の全てのプロジェクトで有効化できます。なお 除外されるプリンシパル 設定も継承されます。
- 参考 : デフォルト構成を設定する
監査ログの収集
ログの生成自体は前述の “デフォルト構成の設定” で実施できます。ただしこの場合、ログの保管先はそれぞれのプロジェクト、フォルダ、組織レベルのログバケット (_Default や _Required) にそれぞれ保存されます。
ログルーティング (シンク) の仕組みを利用してログをログ集約用のプロジェクトに集約し、長期保存することで、ログの正しい保持や監査対応などに対応することができます。
- 参考 : ログルーティングとログの保存
- 参考 : プロジェクトをまたいだログの集約
組織 (Resource Manager) 自体の監査ログ
Resource Manager API 自体のログも、当然ながら Cloud Audit Logs に保存されます。
フォルダやプロジェクト、組織ポリシーなどの作成、削除、変更が記録されます。
- 参考 : Resource Manager の監査ロギングの情報
- 参考 : 組織のポリシーの監査ロギング情報
組織のポリシー
組織のポリシー (Organization Policy) 機能では、組織で管理されたプロジェクトに対し一定のルールを課し、統制を効かせることができます。
例として以下のようなポリシーがあります。
- Cloud Storage で公開アクセスを禁止
- 利用可能な Google Cloud サービスを制限
- リソースを作成できるリージョンを制限
組織のポリシーはリソース階層の上から下へ継承されていくため、フォルダ分けによって適用するポリシーを変えることができます。
組織のポリシーについては以下の記事で詳細に解説しています。組織を使うにあたり、最も基本的なセキュリティ機能ですので、ぜひご確認ください。
詳細な管理
タグ (tags)
Google Cloud には タグ (tags) という仕組みがあります。
タグは Key-Value の文字列であり、それ自体が Google Cloud リソースです。IAM の条件 (Condition) として利用可能であり、親リソースから子リソースへ継承されます。
タグをうまく使うことで、権限が及ぶ範囲をコントロールすることができます。
よく似た概念で「ラベル」という概念もありますが、タグとラベルは全くの別ものです。
タグの詳細は、以下の記事もご参照ください。
プロジェクトの移動
Google Cloud プロジェクトは、組織直下からフォルダ内へ、あるいはあるフォルダから別のフォルダへ移動することができます。ただしその際は、IAM を始めとする継承の性質を持つ設定には要注意です。設定の継承元が変わるため、予期せぬ結果を生まないよう確認しましょう。
それに加えてプロジェクトは「組織なし」から組織に所属させたり、ある組織から違う組織に移動することもできます。
ただし、組織間でプロジェクトを移行する場合、さまざまな考慮事項があります。以下に代表的なもののみを記載します。
- 上位リソースから継承される IAM 権限は移行されない
- プロジェクトに紐づくサポートケースが閲覧できなくなる (Google サポートに連絡してメタデータ移行を依頼する必要がある)
- VPC Service Controls 境界にプロジェクトが入っている場合、移行ができない
より詳細なリストは、以下をご参照ください。
- 参考 : 特殊なケースを処理する
プロジェクトの組織間移動の手順等は、以下のドキュメントをご参照ください。
- 参考 : 組織リソース間のプロジェクトの移行
通知の連絡先
連絡先の設定
Google Cloud から「料金改定」「サービス仕様」「法令に関連する通達」「セキュリティ関連通知」など重要なお知らせが通知される場合があります。
こういったお知らせは エッセンシャルコンタクト という仕組みで通知先メールアドレスを指定することができます。
なお、エッセンシャルコンタクトで明示的に通知先を指定しない場合、お知らせはカテゴリごとに所定の IAM ロールを付与されている Google アカウントのメールアドレスに通知されます。
例えば課金に関するお知らせや法令遵守に関するお知らせは 請求先アカウント管理者 (roles/billing.admin) ロールを持つ Google アカウントに通知され、Google プロダクトの変更点に関するお知らせは オーナー (roles/owner) のアカウントに届きます。
通知カテゴリとロールのデフォルトの対応表は、以下のドキュメントをご参照ください。
- 参考 : 通知のカテゴリ
連絡先の継承
連絡先設定にも継承の概念があります。組織レベルで連絡先を設定すると、その設定が下位のフォルダ・プロジェクトにまで継承されます。下位プロジェクトで発生したお知らせは組織レベルで設定した連絡先へ通知されます。
「課金」「法務」「セキュリティ」カテゴリの通知は組織レベルで設定することが推奨されています。
Resource Settings (リソースの設定)
組織に関連する機能として Resource Settings (リソースの設定) があります。一般的な名詞句に見えますが、機能の名称です。日本語だと少し紛らわしいため、当記事では Resource Settings と英名で呼称します。
Resource Settings を使用すると、組織・フォルダ・プロジェクトの設定値を一括管理することができます。
例えば、以下のような設定値を一元管理できます。
- 新しい Cloud Storage バケットのデフォルトのロケーション (リージョン)
- 新しい VM のデフォルトの DNS サーバ設定
- 新しい VM のデフォルトのマシンイメージ
Resource Settings は親リソースから子リソースに継承されます。組織トップノードやフォルダで設定値を作成すれば、その配下の全てのプロジェクトでそのデフォルト設定が使用されます。
なお Resource Settings の設定がない場合は、Google の定めるデフォルト値が使用されます。
- 参考 : リソースの設定の概要
組織内アクセス制限
組織内アクセス制限 (organization restrictions) は、企業の従業員 (官公庁の職員) が指定した Google Cloud 組織以外の組織にアクセスするのを制限するための機能です。
当機能は、企業 (官公庁) のネットワークで HTTP プロキシサーバを利用しており、そのプロキシサーバ以外にはインターネットに出る手段がないことが前提になります。
プロキシサーバにおいて、Google Cloud に向けた HTTP リクエストの HTTP ヘッダに特定の Key-Value を強制的に追加することで、そこで指定された組織 ID 以外の組織にアクセスできなくさせる仕組みです。
詳細は以下の公式ドキュメントをご参照ください。
- 参考 : 組織内アクセス制限の概要
また実際の利用方法については、以下の当社記事もご参照ください。
組織と関連する Google Cloud サービス
Identity and Access Management (IAM)
組織と最も関連が強い Google Cloud サービスは Identity and Access Management (IAM) であると言えます。
IAM は Google Cloud の認証・認可を担う仕組みであり、Google Cloud におけるセキュリティの最も基本的な要素です。
IAM 権限はリソースに対して設定されます。上位リソースに対して設定された権限は、下位リソースに継承されます。組織トップノードに設定された権限は最下位レベルのリソースである VM や BigQuery テーブル等にまで継承されます。
この仕組みを使って、プロジェクトをフォルダ分けしたうえで、フォルダ単位で権限を付与するなどして、権限管理の運用を効率化し、よりセキュアに運用できるようになります。
IAM の仕組みについては、以下の記事を参照してください。
階層型ファイアウォールポリシー
Google Cloud の VPC にはファイアウォールの仕組みがあります。ファイアウォールは通常はプロジェクトの VPC レベルで管理しますが 階層型ファイアウォールポリシー という仕組みを使うと、組織の上位から下位に向けてファイアウォールのルールを継承させることができます。
例えば、組織ルートもしくは上位フォルダで「TCP ポート 22 番は Deny」というポリシーを作れば、下位のプロジェクトの VPC ファイアウォールルールで許可しても、パケットは Deny されます。
ファイアウォールポリシーの詳細については以下の記事を参照してください。
VPC Service Controls
VPC Service Controls は Google Cloud サービスの API を保護する仕組みです。
接続元 IP アドレスやデバイス情報等のコンテキストベースでアクセス制御ができます。
VPC Service Controls の設定の管理権限は、アクセスポリシーというリソースを作ることで、フォルダもしくはプロジェクトの範囲に限定できます。これによりフォルダ / プロジェクト別の管理者に、VPC Service Controls の設定権限を委任することができるようになります。
VPC Service Controls の詳細については以下の記事を参照してください。
ベストプラクティス
フォルダ構造の決め方
組織配下ではフォルダを使って Google Cloud プロジェクトを整理することができますが、どのようなフォルダ構成とすべきかは悩みの種です。しかしながら、どのような環境でも通用するような 絶対の答えはありません。
「IAM」「組織のポリシー」「階層型ファイアウォール」など継承によって影響範囲が決まる機能を考慮に入れ、どの単位でまとめて管理したいか、という観点でフォルダ構成を決めます。
一例として、以下の図は 組織 ＞ 環境別フォルダ ＞ システム別フォルダ ＞ 機能別プロジェクト という構成になっています。
この会社 (官公庁) ではクラウドを横串管理する CCoE チームが存在し、本番環境には本番環境のための統制を、開発環境には開発環境のための統制を、というように環境別に異なったセキュリティポリシーを強制的に割り当てるために、このような構成になっています。
別のパターンでは、以下のような構成も取れるでしょう。以下の例は 組織 ＞ システム別フォルダ ＞ 環境別フォルダ ＞ 機能別プロジェクト という構成になっています。
この環境ではそれぞれのシステムはそれぞれの部門が管理していて、あるシステムでは「本番環境」「開発環境」の2面しか用意されていないが、別の部門の別のシステムでは「本番」「UAT」「テスト」「開発」の4面構成であり、セキュリティポリシーも異なる...というように、システムごとに統制の設計が大きく異なります。ですのでシステム別フォルダ以下は、そのシステムを管理する部署に IAM 権限を与え、裁量を持たせています。
上記の2例でも分かるように、クラウド環境がどのような運用体制でどのように統制されるか、という観点を持ちつつ、運用を意識して組織の構成を設計する必要があります。
組織作成直後にやるべきこと
組織作成直後には、組織トップノードの IAM Policy において、以下の権限が付与されています。
| プリンシパル | ロール |
|---|---|
| (ドメイン名) | プロジェクト作成者 (roles/resourcemanager.projectCreator) |
| (ドメイン名) | 請求先アカウント作成者 (roles/billing.creator) |
プリンシパルの (ドメイン名) とは、その 組織のドメインの Google アカウント全員に 権限が与えられている、という意味です。組織レベルの IAM 画面では以下のように表示されます。
この状態だと、組織のアカウント全員がプロジェクトを作成したり、請求先アカウントを作成できる状態です。この状態はクラウド管理者が気づかないうちに「野良アカウント」が作成できてしまいます。クラウド環境を集中管理するのであれば、この IAM ロール割り当ては削除するべきでしょう。
以下のように My First Project というプロジェクトが乱立している状態を見たことがあるでしょうか。
前掲のように組織のアカウントの全員がプロジェクト作成権限を持っている場合、Google Cloud 画面に初めてアクセスした際にチュートリアルが始まり、My First Project という名称のプロジェクトが自動的に作成されてしまうことで起こる現象です。前述の プロジェクト作成者 ロールの割り当てが削除してあれば、この状況は起こりません。
以下の記事もご参照ください。
その他のベストプラクティス
以下の公式ドキュメントで、企業 (官公庁) 向けの Google Cloud で行うべきベストプラクティスが紹介されています。
組織の構成、アカウント管理、ネットワークセキュリティ、ロギング、請求などに関して重要な観点が示唆されていますので、ぜひご確認ください。
また上記ベストプラクティスで言及されている Google Cloud の機能の多くが、当社記事によって解説されています。記事を見つけるために、以下のリンク集もご活用ください。
セキュリティスイート for Google Cloud
組織リソース構成や組織のポリシーを含む、Google Cloud の推奨セキュリティ設定を提供する G-gen のサービスである「セキュリティスイート for Google Cloud」について、以下の記事をぜひご参照ください。
杉村 勇馬 (記事一覧)
執行役員 CTO / クラウドソリューション部 部長
元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。
Follow @y_sugi_it