【Google Cloudでセキュリティの柱を築く】利用リージョンを制限する

1.組織ポリシー(gcp.resourceLocations)

組織ポリシーのリソースロケーションの制限を設定することで対象とするリージョンを絞ることが可能です。リソースのリージョン制限を行うことで特定のリージョンだけでなく、複数リージョンを束ねたマルチリージョンとリージョン内のゾーンを細かく設定することができます。

https://cloud.google.com/resource-manager/docs/organization-policy/defining-locations?hl=ja

例えば、日本国内に限定したい場合は以下のように値に”in:jp-locations”と指定することで東京/大阪リージョンに限定することができます。同じように個別にリージョン指定とゾーン指定も出来ます。

良い点: 全体統制がシンプル

組織ポリシーは組織、フォルダから設定が行えるので配下のプロジェクト全体に統制を効かせる事が可能です。そのため、組織管理者が各プロジェクトユーザーに利用リージョンを強制化する事が出来ます。

さらに個別のプロジェクトで除外設定を行う事も簡単に行えます。北米リージョンでしか提供されていないサービスの利用や韓国やシンガポールなどアジアリージョンでのDR、ローカライズ対応が行えます。多くのサービスで対応しているのもよい点です。

https://cloud.google.com/resource-manager/docs/organization-policy/defining-locations-supported-services?hl=ja

課題点: グローバルリージョンに対応しきれない

冒頭説明した通り、グローバルサービスが多く用意されています。グローバルサービスは明示的にリージョン指定を行うことができません。例えば、IAMのデータや認証認可機能を日本リージョンに限定するといった事ができません。そのため、完全に指定リージョンのみの構成ができません。

https://cloud.google.com/about/locations?hl=ja

以下のように特定サービスについてグローバルリージョン利用を禁じる組織ポリシーも用意されていますが、非常に少ないです。

• compute.disableGlobalLoadBalancing(Load Balancer)
• pubsub.enforceInTransitRegions(Pub/Sub)

また、すべてのサービスが対応しているわけではないので、グローバル以外のプロダクトでも対象となっていないものもあります。

2.Assured Workloads

特定の法規制を受ける業界(食品、医薬品、金融、政府機関など)やEUなど個人情報を厳格に扱う必要のある国への統制を強制化できるサービスです。Assured Workloadsによりデータの保管先リージョンの強制化することができます。

https://cloud.google.com/assured-workloads/docs/data-residency?hl=ja

良い点: グローバルサービスでも強制化が可能

組織ポリシーで対応できないグローバルサービスのデータ保管先を特定リージョンにすることができます。IAMやResource Managerであってもそのデータ保管先を絞ることができます。組織/フォルダ単位で設定できるため、組織ポリシーと同様に全体統制を行えたりフォルダ単位でAssured Workloadsを効かせるものとそうでないものを分けることも可能です。

• Cloud DNS
• Cloud Monitoring
• IAM
• Resource Manager

https://cloud.google.com/assured-workloads/docs/supported-products?hl=ja

課題点: 1リージョンに限定され柔軟な対応が難しい

例えば日本リージョンにデータ所在地を限定したいとなった場合に、東京/大阪でのDRあるいは東西日本の近隣リージョンで処理を行わせるようなケースがあるかと思います。しかし、Assured Workloadsは1リージョンのみでの構成となります。そのため、DRの構成をするためには別途プロジェクトを構成してデータ連携を図るなど構成が煩雑になります。(2025年7月現在)

また、1リージョンしか指定できないため、検証で北米の新サービスを利用するといったことが柔軟に行えません。組織ポリシーのようにオーバーライドを都度行うこともできないため、事前にフォルダをリージョンごとに厳格に設計したり、組織で割りきって1リージョンのみに強制化させるしかありません。

1. グローバルサービスの特定

実はドキュメントに記載のないグローバルサービスも多くあります。特にドキュメントに反映のない新しいサービスやGoogleサービスのAPIは暗黙的にグローバルだったりするためです。

ここでサービス特定を行えるのがAsset Inventoryによるリソースロケーションの特定です。Asset Inventoryのリソースタブ内のロケーションにて現在構成されているサービスのロケーションを確認することができます。ここで日本国外のリージョンやグローバルサービスの利用状況を確認します。これにより、ドキュメントにないグローバルサービスの検出や利用実態を把握することができます。

2. データ分類/取り扱いを確認する

日本国外にデータが保管されること自体が問題なのではなく、機密情報や個人情報が海外に送られてしまうこと、海外からアクセスできてしまうことが問題です。そのため、Resource Managerで扱われるGoogle Cloudの組織/フォルダ/プロジェクト情報やIAMのロールバインド情報は企業機密や個人情報そのものではなかったりします。

また、データが保管/取り扱いされるサービスは基本的にはストレージ、データベース、DWHとその周辺パイプラインを構成するツール群がメインです。それ以外で個人情報や機密データが取り扱われるのであれば、データの取り扱い(＝運用)に問題があるとも言えます。データの保管先はもちろん強制化すべきですが、VPC Service Controlsや他の組織ポリシー、Cloud DLPなど別のソリューションを用いてこれが解決できる問題だったりもします。リージョン指定だけにこだわる必要はありません。