GCP を利用したセキュリティ要件対応 : VPC Service Controls を試してみた (その 3: アクセスレベルを構成する)
本記事は、 「GCP を利用したセキュリティ要件対応 : VPC Service Controls を試してみた」の記事 3/3 本目となります。第 1, 2 回目の記事は下記を御覧ください。
前回は GCP のマネージドサービスをさらに高度に保護する VPC Service Controls （以下、 VPC SC ）を構成し、高度にデータを保護するというのが具体的にどういう動作なのかということを紹介しました。今回はアクセスレベルを設定し、特定の条件 (ソースIP制限など) においてサービス境界線内部へのアクセスを許可してみたいと思います。
アクセスレベルの構成
Access Context Manager を利用して、アクセスレベルを構成します。今回は GCP のコンソールにアクセスをしているクライアントのソース IP を追加してみましょう。構成イメージは以下のとおりです。
Access Context Manager にアクセスします。再度組織を選択します。
「新規」を押して、条件より「IP サブネットワーク」を選択し、 クライアントのグローバル IP アドレスを追加します。
注 : 動的な IP アサインがされる環境の場合には変化しないか確認してください
注: IPv6 が使える環境では v6 を足しておきましょう
アクセスレベルの追加
サービス境界線にアクセスレベルを追加します。追加を行うと、サービス境界線内部ではなくとも、アクセスレベルに一致をすれば、境界線内部と同様にアクセスが可能になります。
今回は前回作成した sample_perimeter にアクセスレベルを追加しました。
それでは、サービス境界内にあるプロジェクトを開いて動作を確認してみましょう。先ほどと同様に BigQuery のデータセットが見えることがわかると思います。
許可したソース IP のクライアントより、 CLI / コンソールの両方で GCS や BigQuery を操作できることがわかりました。コンソール経由であっても、きちんとソース IP をみて判断してくれるのは嬉しいですね。
もしもアクセスが可能にならなかった場合には、 Stackdriver Logging より監査ログを確認することで、 VPC SC が有効になったリソースの callerIp などを見て確認することができます。
今回は紹介できませんでしたが、 VPC Service Control にはこの他にもオンプレミスから Interconnect 経由での Google のマネージド・サービスへの接続サポートなどのユースケースもカバーしています。
セキュリティということでとっつきづらい、設定しづらいイメージがあるかもしれませんが、単なるネットワーク・セキュリティだけではなく統合的にデータを守るための機能というのが理解できたと思います。また、使えないセキュリティはセキュリティでないという言葉もあるぐらいですが、できるだけガチガチに縛られている感を出さずに透過的に操作できるようになっているあたりも、 VPC SC の特徴かなというように感じています。
ぜひ皆さんも VPC SC をお試しいただいて、もっと多くの活用シーンで BigQuery などのサービスを使っていってくださいね！
Disclaimer: この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり､私の雇用者には関係はありません｡
