こんにちは。フクヤマです。
いつも当ブログをご覧いただき、誠にありがとうございます。
さて、今回は、当社のデータ基盤構築で大変お世話になっているGoogle Cloudプレミアパートナー、株式会社G-gen様との技術ブログ相互寄稿企画をお届けします。
本企画では、G-gen様の技術ブログ「G-gen Tech Blog」と当社のブログで、両社の知見を交換する形で記事を掲載していきます。
記念すべきG-gen様の1つ目の記事のテーマは、「VPC Service Controlsの境界の分割設計に関する考察」です。
VPC Service Controlsは、Google Cloudのデータを外部の脅威から保護する上で極めて重要なサービスですが、そのセキュリティ境界（Perimeter）をどう設計するかは、多くの技術者が悩むポイントです。「境界は一つに集約すべきか、あるいは分割すべきか」――。この記事では、その設計思想を具体的なユースケースと共に深く考察されており、まさにプロフェッショナルの知見が光る内容となっています。
それでは、G-gen 杉村様による貴重な寄稿記事をご覧ください。
G-gen の杉村です。VPC Service Controls は、Google Cloud の API やデータの保護のためのサービスです。VPC Service Controls では境界（perimeter）という設定オブジェクトによりアクセスを制御しますが、複数の境界を設計する際の考え方について考察します。
1.前提知識
1-1.VPC Service Controls
VPC Service Controls は、Google Cloud の API やデータの保護のためのサービスです。このサービスにより、Google Cloud リソースへの操作（作成、読み取り、更新、削除等）を特定の IP アドレスからのリクエストに限定したり、データの移動を指定した領域の内部に留めたりすることができます。
VPC Service Controls の詳細は、以下の記事も参照してください。
1-2.境界と境界ブリッジ
VPC Service Controls において、保護の範囲や、データの相互移動が可能な範囲を定義する設定オブジェクトが境界（perimeter）です。原則的に、境界は Google Cloud 組織のレベルで作成します。しかし、アクセスポリシー（Access policies）の仕組みを使い、フォルダやプロジェクトのレベルに管理を委任することもできます。
- 参考 : サービス境界の詳細と構成
また、2つの境界を接続して、相互に API リクエストやデータ移動を可能にする設定を、境界ブリッジ（perimeter bridge）といいます。
- 参考 : ブリッジを使用して境界を越えて共有する
1-3.イメージ図
以下は、境界の概念を簡易的に表した図です。
1-4.境界と複数のリソース
境界には、保護対象リソースとして、Google Cloud プロジェクトまたは VPC ネットワークを収容できます。1つの境界に対して、複数のプロジェクトやネットワークを収容できるため、多くの場合で、組織に1つだけ境界を作成することになります。
2.複数の境界を作成するケース
1つの Google Cloud 組織において、複数の境界を作成するケースはどのようなものでしょうか。それは、異なるアクセスユースケースが複数ある場合です。以下は、その例です。
- Google Cloud への接続元 IP アドレスとして、 A 拠点（自社）と B 拠点（パートナー会社）がある
- A 拠点からは a というプロジェクト群に、B 拠点からは b というプロジェクト群にだけアクセスさせる
このようなケースでは、異なる2つのアクセス制御のユースケースが存在しているため、境界を2つ作成するのが望ましいでしょう。
3.境界が1つの方がよいケース
一方で以下のようなユースケースでは、境界を複数作成することが適切ではない可能性があります。
- Google Cloud への接続元拠点（接続元 IP アドレス）は、A 拠点（自社）のみ
- a というプロジェクト群と b というプロジェクト群があり、それぞれ目的が異なる
- a はセキュリティソリューションなどの共通基盤プロジェクト群。情シス部員が接続する
- b は仮想サーバーなどの IaaS プロジェクト群。事業部門の開発者が接続する
- b の仮想サーバーから a の Cloud Storage バケットにファイルをアップロードする要件がある
- 今後、社内での Google Cloud 利用拡大に伴い、プロジェクト群 c や d が登場する可能性がある。それぞれ、異なる事業部門の開発者が接続する想定
このような場合には、a と b の2つのプロジェクト群があるため、一見、境界を2つに分割するのがよいように思えるかもしれません。しかし要件を確認すると、a と b の間で API リクエストが発生するため、2つの境界を境界ブリッジで接続するか、a と b の間で外向きルール・内向きルールを細かく定義して許可を追加していく必要があります。このような相互の許可ルールは、プロジェクト群 c や d が追加されるたびに、1:n で増えることになります。
さらに「情シス部員は a だけに、事業部門員は b だけに」というアクセス制御は、Identity and Access Management（IAM）の責務と考えられます。VPC Service Controls には、接続元 IP アドレスなどのコンテキストに基づいたアクセス制御について責務を持たせ、あくまで IAM と組み合わせた多層防御を加えるものであると考えるのが望ましいといえます。
これらのことから、こういったケースでは境界を複数に分ける理由が特にありません。さらにもし境界を複数にした場合は、今後のプロジェクト群の追加に従って運用負荷が肥大化していくことになります。この場合、1つの大きな境界にプロジェクト群を収容し、所属部署によって異なるプロジェクトへのアクセス制御は、フォルダ分けに基づく Identity and Access Management（IAM）設計によって実現するのが望ましいと考えられます。
なお、境界の外向きルール・内向きルールの詳細については、以下の記事も参照してください。
4.複数の境界を作成して境界ブリッジで接続するケース
以下のようなケースでは、複数の境界を作成して、境界ブリッジで接続するか、外向きルール・内向きルールを細かく定義するのが望ましいといえます。
- Google Cloud への接続元 IP アドレスとして、 A 拠点（自社）と B 拠点（パートナー会社）がある
- A 拠点からは a というプロジェクト群に、B 拠点からは b というプロジェクト群にだけアクセスさせる
- A 拠点の BigQuery データセットから B 拠点の BigQuery データセットへデータの移動、もしくはテーブルの結合がある
- 将来的にプロジェクト群がc, d, e といったように増えたり、プロジェクト群間で多種多様なデータ移動・参照が発生したりはしない
5.設計の基本方針
「境界が1つの方がよいケース」で前述したように、基本的には VPC Service Controls で制御すべきアクセスユースケース（クライアントのコンテキストによるアクセス制御）が単一の場合は、できる限り境界を1つにしたほうがよいといえます。これにはできるだけ構成をシンプルにして運用負荷を下げる効果があります。
逆に、コンテキストが異なる複数のアクセスユースケースがある場合は境界を複数にしますが、その場合でも外向きルール・内向きルール設計が細かくなりすぎたりしないようシンプルにしたり、また運用上の負荷が肥大化しないよう、Terraform 等による構築の自動化をするなどの工夫が望ましいといえます。
G-gen 杉村様、非常に示唆に富んだ記事をありがとうございました。
VPC Service Controlsの境界を「アクセスユースケースの数」で判断するという明確な指針や、IAMとの責務分担を考慮する視点は、まさに「言うは易く行うは難し」な部分です。当社のセキュリティ基盤をより堅牢にしていく上で、大変参考になりました。
次回は「Security Command Center」をテーマにご寄稿いただく予定です。どうぞご期待ください。
ライオン株式会社のデジタル部門「LDX」が発信するテックブログ「LION Digital Inside」は、ハミガキ、ハブラシ、洗剤などを開発・製造する中で培った“製造業としての強み”と、Webサービス開発の最前線が交差する場所。LDXが最新技術と革新の舞台裏を余すところなくお届けします。
Discussion