① できること

組織管理の Google アカウントを利用した一元管理にて、セキュリティを確保できます。
・ 利用できるメンバを管理
・ 退職／離任 時の制御

② 解説

まずは Google アカウントから説明します。
Google アカウントは、 Google Cloud のリソースを利用するために作成するアカウントで、管理主体によって大きく分けて2つの種類があります。

Gmail のアドレスは分かりやすいのですが、任意のメールアドレス、特に企業ドメインのメールアドレスには注意が必要です。
というのも、見た目では「個人管理」なのか「組織管理」なのかは判別できず、該当する Google アカウントが「Google 管理ツール(Google Admin)」に登録されているかどうかで判別する必要があります。

Google Cloud 利用時には、まず「個人管理の Google アカウント」にてご利用を開始されることが多いのかと思います。

「個人管理の Google アカウント」では、退職者や離任者からプロジェクトの権限を外したい場合、管理ツールによる一括削除ができません。
数名のプロジェクト数やプロジェクト管理者数が少ない場合は特に問題はないかと思いますが、管理対象数が増えるにつれて、手間もかかりますし、抜け漏れ発生しやすくなることが容易に想定できます。

そのため、「組織管理の Google アカウント」 の利用を推奨します。
また、後程の「ドメインの制限」と組み合わせることで、意図しないユーザへ共有させないプロジェクトが実現できるため、セキュリティ強度を上げるためには必須の対策とも言えます。

③ 導入にあたって

「組織管理の Google アカウント」を利用するため、以下のいずれかのサービス準備して、Google 側で組織を作成します。
組織作成時に、「利用するドメイン名の登録」と「DNS レコードの追加による認証」を行うため、必要な場合は社内の IT 組織と連携いただければと思います。

① できること

利用者に応じて権限を分離することで、予期しない動作を防ぐことができます。

② 解説

Google Cloud では、あらかじめ決められた権限の組み合わせ(＝事前定義ロール)が準備されているため、Google アカウント等に必要な権限を付与することで、利用できる操作を制限することができます。

例えばデータ分析でよく利用される BigQuery の場合は、用途に応じて以下のような権限が準備されています。

③ 導入にあたって

利用者に必要な権限を付与します。

ベストプラクティスとしては、権限の組み合わせを Google アカウント に直接割り当てるのは運用上の効率が悪くなるため、事前定義ロールを付与した 「Google グループ」を作成して、そのグループに Google アカウントを所属することで、権限付与を行うことが推奨されています。
※ 本ブログでは Google グループについての内容は割愛させていただきます。

① できること

意図しない利用者のプロジェクト参加を防止します。

② 解説

プロジェクトにて Google アカウントの追加／権限を付与する際に、事前指定したドメインの Google アカウントのみを許可します。

たとえば、管理している組織に所属する 「組織管理の Google アカウント」のみを許可することで、意図しない利用者(≒個人管理の Google アカウント)がプロジェクトへ参加できなくなります。
そのため、管理している「組織管理の Google アカウント」以外はアクセスできない、セキュアな環境が実現できます。

③ 導入にあたって

意図しない利用者の参加を制限するためには、まず組織を作成し、「組織ポリシー」という機能を利用します。
「組織ポリシー」とは、 Google Cloud 組織内のリソースについて、使用方法に関する制限を構成して集中管理するための機能(制約)です。

今回は「組織ポリシー」の中で、「ドメインで制限された共有(iam.allowedPolicyMemberDomains)」という制約を利用します。

「組織ポリシー」は、利用を制約したいリソース(組織、フォルダ、プロジェクト)に設定することでができます。

ここまではアクセスを制限する機能をメインに記載しましたが、このパートではアクセスされた後の証跡について記載します。

① できること

操作証跡を残す。

② 解説

結論からいうと、Google Cloud ではほぼ準備ができています。
Google Cloud では、マネージド ログ管理システムである「Cloud Logging」の機能として、下記のように監査ログ (Audit Logs)が自動で取得されています。

データアクセス 監査ログについては、データ容量がとても大きくなってしまうため、初期状態では BigQuery を除いたデータアクセス監査ログは取得されていません。
また、ポリシー拒否 監査ログも初期状態では取得されていません。
両ログとも、保持期間も 30 日となっていますので、長期保存をする場合は保存要件に応じて変更することが可能です。

また、「アクセスの透明性ログ」は、Google の担当者が操作した際に記録されるログとなります。
費用はかからないため、万が一を考慮し取得しておいてもよいかと思います。

③ 導入にあたって

基本的な仕組みは準備されていますので、下記３点の検討を推奨します。

• データアクセス 監査ログ を取得するかしないか
• ログの保存期間／保存方法

ログ容量によっては「Cloud Logging」にそのまま保存するよりも「Cloud Storage」へエクスポートした方が若干安価になります。
また、いくつかの保存方法がありますが、監査ログの分析を想定している場合は「BigQuery」へ集約すると便利です。

• ログ集約

Google Cloud では 別のプロジェクトにログを集約して保存することができます。
さらに、組織を利用していて、かつ、全社の全プロジェクトのログを一括して管理したいという場合には、管理用に別プロジェクトを用意してログ集約を行うような構成が便利です。

最後に「持ち出させない」という防御について触れたいと思います。
本施策は導入や運用についても若干難易度が高くなるため、オプション的な意味合いで記載します。

① できること

簡単にいうと、Google Cloud 環境への持ち込み および 持ち出しについて、「特定の利用元、特定の操作」しか許可しない、といった防御が可能になります。

つまり、リソースへ必要以上の権限を付与してしまった場合のガードレール機能や、万が一マルウェア等に感染してしまった際の不正な持ち出しの防止など、より強固な防御が可能となります。

② 解説

Google マネージド サービス は API にて操作を行いますので、そのAPIの送信元、操作対象(サービス)、操作(メソッド)をきめ細かく設定することで、利用できる機能の制御を行います。

具体的には下記の流れで設定を行います。
・ 防御するリソースの選択 (リソース：組織・フォルダ・プロジェクト）
・ 利用できる機能の制御

機能名としては「VPC サービス コントロール(VPC Service Controls)」と呼ばれています。
リソースに対して「サービス 境界(Service perimeter)」を指定し、境界の 内／外 を分割することで、境界内のリソースを保護します。
リソースの分離ルールは 「アクセスポリシー(access policy)」という保護ルールで細かな制御を行います。

例えば、以下の要件があった場合、下図のような制御方式となります。
・ A プロジェクトを防御範囲
・ 社内(オンプレミス環境)からのデータアップロードを禁止
・ 社内からの Web アクセスを許可

セオリーとしては防御する範囲を特定し、必要な操作のみ許可する、というような流れをとります。

③ 導入にあたって

「VPC サービス コントロール」自体は無償の機能です。
導入にあたってはいくつか準備ポイントがありますので、こちらもご確認ください。

 
＜ 準備ポイント ＞
・ 「VPC サービス コントロール」には、「１．組織管理のアカウント利用」で準備したような組織が必要です。
・ 「VCP サービスコントロール」に対応していないサービスもあるため、利用するサービスを明確にする。

また、実際の適用前には、利用したいサービスがきちんと機能することを検証するため、ドライランモードの実施を推奨します。

今回は、データ分析基盤という観点でセキュリティ強化の施策をまとめてみました。
本当はまだまだ有益な対策手段はあるのですが、とっかかりとして必要な施策に絞りました。
お手元の環境にてセキュリティ面で不安を感じる際には、まずは実施しやすい範囲から手を付けていただければと思います。

• なにはともあれ「組織」を作って運用しましょう。50名迄は無料で利用できます。
• 誰でも利用できる／なんでも利用できる環境は避けましょう。
• 監査ログは取得済みなのでご安心ください。

 
最後まで読んでいただき、ありがとうございました！
 
 
当社システムサポートは、Google Cloud の導入・移行・運営支援を行っています。
クラウド移行含めた最適なシステム環境構築のご相談は、以下よりお願いいたします！