前回のGoogle Cloudのセキュアな設計に続き、今回は、具体的なリソース保護の方法について説明します。今回取り上げるサービスは、VPC Service Controlsです。
私はこれまでに、セキュリティ要件の高いGoogle Cloudの設計案件に何度か参画してきましたが、その中で必ず採用されているのがVPC Service Controlsです。VPC Service Controlsは、簡単に言うとリソースのファイアウォールのような仕組みのサービスです。しかし、これをネットワークのファイアウォールと混同してしまう方がいるので、その違いを踏まえて説明します。
セキュリティの高い設計を目指す方や、VPC Service Controlsについて詳しく知りたい方のお役に立てれば幸いです。
是非、最後までご覧いただけると嬉しいです。
VPC Service Controls の概要
VPC Service Controls は、Google Cloud のセキュリティ機能の一つで、組織のデータ漏洩リスクを軽減するために設計されています。このサービスは、境界と呼ばれる論理的な囲いを作り、その境界内にあるリソースへのアクセスを厳密に制御することで、データの安全性を確保します。
VPC Service Controls の特徴
VPC Service Controls の主な特徴は、以下4つです。
- 境界の設定：組織は、保護したいリソース (Cloud Storage, BigQuery など) を含む境界を定義できます。
- アクセス制御：境界内にアクセスを許可するクライアント (IPアドレス、サービスアカウントなど) を指定できます。これにより、未承認のクライアントによるデータへのアクセスを防止します。
- プライベート アクセス：境界内では、リソースへのプライベートアクセスが許可されます。つまり、パブリックインターネットを経由せずにリソースにアクセスできるため、セキュリティが向上します。
- 外向きの通信制限：境界内から外部への通信を制限することで、データの漏洩リスクを低減できます。
Access Context Managerの概要
VPC Service Controls は、Access Context Manager を基盤として構築されており、Access Context Manager の機能を拡張しています。
Access Context Managerはアクセスレベルとアクセスポリシーを定義することで、ユーザーやデバイスがGoogle Cloudのリソースにアクセスする際の条件を設定します。アクセスレベルは、特定の条件（例えば、IPアドレスの範囲、デバイスの属性、ユーザーの属性など）に基づいてアクセスを許可または拒否するルールを定義します。アクセスポリシーは、これらのアクセスレベルをプロジェクトやリソースに適用するための設定です。
VPC Service Controls は、Access Context Managerのアクセスレベルと一緒に使用することが一般的です。
ここで、私の実体験をお話しします。VPC Service Controlsの境界にユーザーIDやIPアドレス（範囲）のアクセスレベルを設定しないと、VPC Service Controlsを設定した後、ログにエラーが記録され続けます。私はこれを知らずに、ずっとエラーが出る理由を探していました。実際は、ユーザーIDとIPアドレスを設定するのが一般的で、それが設定されていないとエラーが記録されます。以下はGoogle Cloudドキュメントの記載です。
Google Cloud コンソールから境界で保護されたリソースへのアクセスを許可するには、保護された API で Google Cloud コンソールを使用するユーザーのマシンを含むパブリック IP 範囲のアクセスレベルを作成する必要があります。
参考：Google Cloud ドキュメント
ただ、必ずしも、VPC Service Controls でAccess Context Managerを設定する必要はありません。
Access Context Managerについは、以前、別のブログでも説明しているので、そちらをご参考ください。
VPC Service Controlsの実装方法
今回は、VPC Service Controlsに焦点を当てるため、Access Context Managerのアクセスレベルを使用しない方法を説明します。一般的には、Access Context Managerを使用しますが、まずはVPC Service Controlsについて理解を深めるために、今回はAccess Context Managerのアクセスレベルは使用しません。
必要なロール
VPC Service Controlsを作成するために必要なロールは、以下のいずれかです。
- Access Context Manager 編集者
- Access Context Manager 管理者
今回の実装で使用するユーザーアカウントには、「Access Context Manager 管理者」のロールを付与しています。
1.VPC Service Controlsを開く
まずは、VPC Service Controlsを開きます。
VPC Service Controlsは組織階層で設定するため、組織階層を開きます。
サイドバーのセキュリティから「VPC Service Controls」を開きます。
すると、VPC Service Controlsが開きます。
2.境界を作成
次は、境界を作成します。
新規境界を作成するので、「NEW PERIMETER」を選択します。
境界のタイトルを任意で入力し、境界のタイプは、「標準境界（デフォルト）」を選択します。
保護するリソースを選択します。ここでは、境界にいれる、プロジェクトを選択します。
「ADD RESOURCES」を選択します。
境界にいれるプロジェクトを選択し、「ADD SELECTED RESOURCES」を選択します。
プロジェクトが追加されていることを確認します。
制限付きサービスを選択します。特定のサービスのみを境界の中に入れたい場合、「サービスを追加」を選択します。
今回は、「すべてのサービスを追加」を選択します。
サービスが追加されていることを確認します。
VPCのアクセス可能なサービスでは、「限定公開のGoogle アクセス」でアクセスするサービスを選択します。限定公開のGoogleアクセスとは、通常、Google Cloudのサービスを使用する際にインターネット経由でサービスのAPIにアクセスしますが、限定公開のGoogleアクセスを使用すると内部のネットワーク（プライベートネットワーク）経由でGoogle CloudのサービスのAPIにアクセスします。VPC Service Controlsを採用する案件では、セキュリティ要件が高いことが一般的なので、「限定公開のGoogle アクセス」を組み合わせて使用することが一般的です。
今回は「すべてのサービス」を選択します。
今回、アクセスレベルは設定しません。ポリシー設定については後で説明するので、今回は、これで「境界を作成」を選択します。（スクリーンショットには「保存」と表示されていますが、新規境界作成の場合は「境界を作成」となっています。）
正常に境界が作成されると一覧に表示されます。
以上で、VPC Service Controlsの境界作成は終わりになります。
3.動作テスト①
ここで動作テストを行います。現在、「上り（内向き）ポリシー」には何も許可設定を行っていないため、私のアカウントでアクセスした場合でも、Google CloudコンソールでGoogle Cloudのサービスにアクセスすることはできません。
ここでは、「VPCネットワーク」にアクセスします。
すると、「申し訳ございません。サーバーはリクエストを実行できませんでした」というメッセージが表示されます。これは、VPC Service ControlsによってGoogle Cloudサービスへのアクセスがブロックされた際に表示されるメッセージの一つです。
今度は、「Compute Engine」にアクセスします。
「Compute Engine」にアクセスした際には、「VPC Service Controls によってアクセスが拒否されました。〜」というメッセージが表示されるため、VPC Service Controlsによってブロックされていることが分かります。
ちなみに、メッセージの後ろに表示されている識別子を使用すると、何が原因でブロックされているかを確認することができますが、これについては、また別のブログで紹介しようと思います。
私が経験した限り、VPC Service Controlsによってアクセスがブロックされた場合、上記の2つのメッセージが表示されます。また、これらのメッセージが表示されない場合でも、リソースを作成しようとした際に、必要なロール（権限）を持っていてもリソースが作成できない事象が発生することがあります。
このように、VPC Service Controlsを使用すると、Google Cloudのプロジェクト内にあるリソースを保護することができます。
4.上り（内向き）ポリシーの許可設定
それでは、「上り（内向き）ポリシー」を設定して、私のアカウントが境界内のGoogle Cloudサービスにアクセスできるように変更します。上り（内向き）ポリシーは、プロジェクト内のリソースに対する外部からのアクセスを許可します。ポリシーで設定できるのは許可設定だけであり、拒否設定はできません。理由は、VPC Service Controlsの境界内にある場合、基本的にすべてのアクセスが拒否されるからです。
上り（内向き）ポリシーでは、基本的に下記項目で許可ルールを作成します。
- FROM属性
- ID
- 任意のID
- 任意のユーザー アカウント
- 任意のサービス アカウント
- 選択したID
- ソース
- すべてのソース
- アクセスレベル
- プロジェクト
- VPC ネットワーク
- ID
- TO属性
- プロジェクト
- サービス
- メソッド
FROM属性のIDでは、境界内のプロジェクトのサービスまたはリソースにどのIDがアクセスできるかを指定します。IDを指定しない場合は「任意のID」を選択します。ユーザーアカウントまたはサービスアカウントのどちらかを許可する場合は、「任意のユーザーアカウント／サービスアカウント」を選択します。アクセスできるIDを限定する場合は、「選択したID」を選択し、ユーザーアカウントまたはサービスアカウントを指定します。なお、Googleグループは指定できないのでご注意ください。
次に、FROM属性のソースでは、どのソースからのアクセスを許可するかを指定できます。例えば、特定のプロジェクトからのアクセスのみを許可することができます。このプロジェクトには、組織外のプロジェクトを指定することも可能です。Google Cloudのすべてのプロジェクトには「プロジェクト番号」が付与されており、その番号を登録することで組織外のプロジェクトを指定できます。プロジェクト番号は、ダッシュボードから確認できます。
TO属性のプロジェクトでは、「Selected projects（選択したプロジェクト）」または「All projects（全てのプロジェクト）」を選択できます。今回は「Selected projects」（選択したプロジェクト）を使用します。
TO属性のサービスでは、「All services（全てのサービス）」または「Selected services（選択したサービス）」を指定できます。「Selected services」を選択した場合、メソッドも「All methods」または「Selected methods」を指定でき、厳密にメソッドを設定することが可能です。私は「All methods」を選択することが多いです。セキュリティを高める場合、「Selected methods」を設定することでセキュリティを担保できます。
それでは、実際に設定を行います。
VPC Service Controlsで、該当の境界を選択します。
上部の「境界を編集」を選択します。
サイドバーから「上り（内向き）ポリシー」を選択します。
「ADD RULE」を選択します。
今回は、私のユーザーアカウントだけがGoogle Cloudの各サービスにアクセスできるように設定するため、IDは「選択したID」を選択し、「ユーザーアカウント／サービスアカウントの追加」の下にある「選択」をクリックします。
IDを入力後、「SAVE」を選択します。
ソースは、「すべてのソース」を選択し、プロジェクトは、今回境界を作成したプロジェクトを選択するので、「Selected projects」を選択します。その後、「選択」を選択します。
アクセスするプロジェクトにチェックを入れ、「ADD PROJECTS」を選択します。
プロジェクトが追加されているメッセージを確認し「DONE」を選択します。
すべのてGoogle Cloud サービスにアクセスするので、サービスは、「All services」を選択します。
最後に「保存」を選択します。
4.動作テスト②
2回目の動作テストを行います。
先ほど、アクセスして表示できなかったVPC ネットワークにアクセスすると、今度は、正常にアクセスできリソースが表示されます。
次に、同様にして、先ほどブロックされたCompute Engineにアクセスします。今度は正常にコンソールが表示されます。
このように、VPC Service Controlsを使用すると、プロジェクトを境界内に入れてアクセスできるサービスを限定することができます。以上のことから、VPC Service Controlsを使用することで、よりセキュアなGoogle Cloudの設計が可能になります。
VPC Service Controlsの誤解
VPC Service Controlsを知った当初、1つ誤解していたことがあります。プロジェクトを境界内に入れることで、例えばWebサーバー等をCompute Engineにデプロイした際、それにもWebからアクセスできなくなるという誤解です。VPC Service ControlsはあくまでGoogle Cloudのサービスやリソースを保護するためのものであり、ネットワークの脅威からリソースを保護するものではありません。
実際に、Compute EngineでVMを構築し、パブリックIPを付与して、どのような挙動になるかをお見せしながら説明しようと思います。VPC Service Controlsの設定は、上記の手順で行った設定から変更していません。
1.Compute EngineでVMの構築
インスタンスを作成を選択します。
今回は解説用なので、料金がかからないように、マシンタイプを「e2-micro」に選択し、ブートディスクを「標準永続ディスク」に変更する以外の設定は行いません。
「外部 IPv4 アドレス」が「エフェメラル」になっていることを確認します。
最後に「作成」を選択します。
VM に外部 IPv4 アドレスが付与されています。
2.PCからVMへの通信確認
私のパソコン（Mac）から、作成したVMにアクセスできるかを確認します。ターミナルソフトを起動して「ping」コマンドを打ちます。
pingの返答があるので、問題なく通信できることが確認できます。
3.VMからインターネットへの通信確認
次は、作成したVMにSSHで接続して、インターネットにアクセスできるかを確認します。今回は、Googleが管理しているDNSサーバー「8.8.8.8」にアクセスできるかを、「ping」を打って確認します。
問題なく、DNSサーバーにアクセスできているので、外向き（下り）の通信も可能です。
結論
VPC Service Controlsはあくまでプロジェクト内のリソースを他のプロジェクトなどから保護するものであり、ネットワークに関する保護には別途ファイアウォールルールなどを設定する必要があります。ただし、VPCネットワークからの保護は可能なので、その点には十分注意してください。
まとめ
今回は、下記５点について説明しました。
- VPC Service Controls の概要
- VPC Service Controls の特徴
- Access Context Managerの概要
- VPC Service Controlsの実装方法
- VPC Service Controlsの誤解
今回は、Google Cloudでセキュアな設計を行う具体的な方法として、VPC Service Controlsについて説明しました。VPC Service Controlsを使用すると、Google Cloudのリソースを保護することができます。ただし、VPC Service Controlsはあくまでリソースを保護するものであり、ネットワークの脅威から保護するものではないので、その点には注意してください。
これからも、Macのシステムエンジニアとして、日々、習得した知識や経験を発信していきますので、是非、ブックマーク登録してくれると嬉しいです！
それでは、次回のブログで！
