【GCPでセキュリティの柱を築く】VPC Service controlsでPaaSとAPIをセキュアに

こんにちは。クラウドアーキテクトの山下です。今日はVPC Service Controlsについて触れていきたいと思います。

このサービスは登場からそこまで日が経っておらず比較的新しいサービスになります。

かつてのGoogleCloudは便利なPaaS群や設定のシンプルさが強みですが、セキュリティよりも利便性に少し重きが置かれていたように感じます。

その最たる例として、PaaSやそれらの出入り口となるAPIへのアクセス制御は認証/認可のみでAWS/Azureのようにネットワーク的な分断を行う事が出来ませんでした。

VPC ServiceControlsとは？

AWSやAzureではリソースベースポリシーと呼ばれるリソース側でのアクセス制御があります。また、VPCエンドポイントやPrivateエンドポイントなどVPC側にゲートウェイを設置しVPCからPaaSへの経路をプライベートでの通信を強制化出来ます。

これにより、PaaSは自分にアクセス出来る対象と経路を絞る事ができ、VPCもPaaSにアクセス出来る経路を絞る双方向での制限をかける事が出来ます。

一方、GoogleCloudではPaaS側で出来るアクセス制御は基本的にIAMのみになります。一部インスタンスを伴うデータベース系のIaaS/PaaS混合のサービスはパブリックIPの付与有無を選択出来ますが、ほとんどネットワークはパブリックに晒されています。

通秘データを扱っていたり、ネットワーク上到達可能な状態を良しとしない企業からすると大きな懸念になってしまいます。

認証認可で担保も出来はしますが、そもそも通信できる状態は避けたい、個々のPaaSのアクセスを管理するのは煩雑なので簡略化したいといった要望もあると思います。これらを満たせるのがVPC ServiceControlsです。

VPC ServiceControlsはよくドキュメントや紹介でサービス境界を作るものと表現されます。AWS/Azureをベースに考えるとイメージが難しいと感じるはずです。実際私も触るまで理解が出来ませんでした…。ですが、想像以上にシンプルです。

境界を作るとはどういうことか？

全てのPaaSやAPIがVPCのプライベートネットワーク内で構成されるとイメージすると分かりやすいかもしれません。

他のクラウドベンダーと比べ画期的なのはPaaS毎にアクセス制御を行わずとも境界に全てのAPIを入れてしまえばアクセス制御が完了します。非常にシンプルで運用性が高いです。

逆に言うとAWSやAzureはPaaSごとにアクセス制御が出来る一方で、サービスAPIへのアクセス制御までは行っていません。例えば、EC2もAzureVMも権限さえあればCLIやマネジメントコンソールを通じて自由に操作できてしまいます。GoogleCloudではこれさえも境界に加えられます。

さらに境界は複数のプロジェクトを跨いで構成する事も出来ます。特定のプロジェクト同士の通信は許可しつつ、他のプロジェクトからは一切アクセスさせない構成も可能です。

境界だからこその意外なデメリット

VPC Service Controlsは言い換えると境界が全ての通信を制限してしまう全拒否のルールが境界外に対して行われてしまいます。つまり、ホワイトリスト型のL7ファイアーウォールを対象全体に効かせているのと同じになります。

端末からgcouldコマンドでリソースを操作したり、ブラウザでコンソールからGUIで操作をするのも、LookerからBigQueryを見るのも全て制限されてしまいます。それほどまでに強い制限がかかってしまいます。

そのため、境界にアクセス出来る経路と条件を指定した穴開けを行なっていく必要があります。この穴開けをするホワイトリストに許可してもよい通信を都度足す事が必要になります。IPアドレスを許可する場合や特定のサービスアカウントやGoogleアカウントを許可する場合もあります。

これはGoogleCloudだからVPC ServiceControlsだからという課題ではなく、セキュリティを求めれば求めるほど運用性が下がるトレードオフがどうしてもあるためです。

デメリットを解消するDryRunモード

VPC Service ControlsではDryRunモードという機能を利用する事が出来ます。

DryRunモードではVPC Service Controlsの境界を設定しつつも、実際の通信制御は行われない機能です。この説明だけだと意味不明ですが、アクセス制限は行われない一方で、疑似的に境界を定義し裏でアクセス拒否が行われたログを出力するのがこの機能のポイントです。

これによってアクセス制御が行われてプロジェクトにアクセスが出来ない、サービスアカウントが特定のリソースに対して操作する事を拒否されるなどの問題に頭を悩ませずに済みます。

また、アクセス拒否の結果はログに蓄積されるだけでなく、VPC Service Controlsのトラブルシューティングメニューで拒否された詳細内容を確認する事が出来ます。

IAMの最小権限の原則のように設計/構築後や実際の運用を疑似的に行って、必要最低限のアクセスを拒否された内容から許可対象に加えていきます。

これにより想定以外の通信は全て制限され、最小のアクセスに留める事が出来ます。

まとめ

GoogleCloudはPaaS保護がネットワーク観点、リソースベースポリシー観点では設定項目がないためセキュリティ面で不安になってしまいます。しかし、VPC Service Controlsを用いる事でこれを解消できるどころか、他クラウドよりもより厳しくもシンプルにアクセス制御できます。

さらにVPC Service ControlsのDryRunモードを活用する事で実際の設計や運用に沿った通信を特定し、制限と許可を適切に設定できます。

セキュアにそして効率よくGoogleCloudを活用するためにVPC Service Controlsを理解して積極的に使いこなしていきましょう！