GCPセキュリティ設計の全体像: 入口・権限・秘密情報・鍵・データ境界で考える

GCPのセキュリティサービスを学ぶとき、IAMIAPCloud ArmorSecret ManagerCloud KMSVPC Service ControlsSecurity Command Center などが一気に出てきます。

ネットワークや可用性のように、すべてを1枚の構成図に載せると理解できる領域ではありません。入口を守るもの、GCPリソースの操作権限を制御するもの、秘密値を保管するもの、暗号鍵を管理するもの、データ持ち出しを抑止するものが混ざっています。

本記事では、GCPセキュリティ設計をサービス名からではなく、何を守るかで整理します。

セキュリティは守る対象で分ける

まずは以下の問いに分けると考えやすくなります。

設計で見る問い守る対象代表サービス
Internetからの攻撃をどこで止めるか外部入口Cloud Armor
社内ユーザーだけWebアプリに通すにはアプリ入口IAP
誰がGCPリソースを操作できるかリソース権限IAM
アプリがどの権限で動くか実行主体Service Account
APIキーやDBパスワードをどこに置くか秘密情報Secret Manager
保存時暗号化の鍵を誰が管理するか暗号鍵Cloud KMS / CMEK
機密データを検出・マスクするにはデータ分類Sensitive Data Protection
GCSやBigQueryのデータ持ち出しをどう抑止するかデータ境界VPC Service Controls
外部IP禁止などを組織全体に強制するには組織制約Organization Policy
設定不備や脅威をどう見つけるか検知・可視化Security Command Center / Cloud Logging

この表が、GCPセキュリティを見直すときの地図です。

守る対象別に見る

上の表をもとに、代表的な対象ごとに役割を整理します。

入口を守る

入口にも種類があります。

  • InternetからのHTTP(S)リクエスト → Cloud Armor
  • 社員や特定ユーザーのWebアプリ入場 → IAP

Cloud Armorは、Load Balancerの前段でWAF、DDoS対策、rate limit、IP制限などを行うサービスです。

IAPは、WebアプリやVMへのアクセスをユーザーIDベースで制御する仕組みです。VPNなしで社内ユーザーだけ管理画面へ通したい、といった要件で出てきます。

両者はどちらも入口に関係しますが、Cloud Armorは攻撃や大量リクエストを止める入口防御IAPは人間ユーザーを通すかどうかの入口制御です。

ネットワーク境界に絡む構成は『GCPのネットワーク境界セキュリティ図解まとめ』で扱います。

権限を守る

GCPリソースの操作権限はIAMで制御します。たとえば、人間ユーザーがBigQueryを見られるか、Cloud RunがCloud Storageを読めるか、CI/CDがCloud Runへデプロイできるか、といった問いはIAMの領域です。

アプリがGCPリソースへアクセスする場合は、Service Accountが実行主体になります。

Cloud Runであれば、紐づけられたService Accountとして動き、IAMで許可された範囲だけGCSやSecret Managerを操作します。

人間ユーザーの入口制御であるIAPと、GCPリソース操作権限であるIAMは混同しやすいですが、見ている対象が違います。

秘密情報と暗号鍵を守る

秘密情報と暗号鍵も分けて考えます。

  • APIキー、DBパスワード、Webhook secret → Secret Manager
  • 保存時暗号化に使う鍵を管理したい → Cloud KMS / CMEK

Secret Managerは、アプリが読む秘密値を保管するサービスです。

Cloud KMSは、暗号鍵を管理し、鍵を使った暗号化・復号・署名などの処理を提供するサービスです。

CMEKは、Cloud SQL、Cloud Storage、BigQueryなどの保存時暗号化に、Cloud KMS上の顧客管理鍵を使う方式です。

この違いは『Secret Manager・Cloud KMS・CMEKの違い』で扱います。

データを守る

データ保護には、少なくとも2つの観点があります。

  • データの中に機密情報が含まれているかを調べる → Sensitive Data Protection
  • GCS / BigQuery などのGoogle API系サービスからデータを境界外に出しにくくする → VPC Service Controls

Sensitive Data Protectionは、個人情報や機密データの検出、分類、マスキングに関係します。

VPC Service Controlsは、サービス境界を作って、Google Cloudサービスからのデータ持ち出しリスクを下げるための仕組みです。Private Service Connectのようなprivate接続とは目的が違います。

組織全体を縛る

個別リソースの権限とは別に、組織として禁止したいことがあります。たとえば、外部IP付きVMを禁止したい、利用可能なリージョンを制限したい、許可したサービスだけ使わせたい、といった要件です。

このようなガードレールはOrganization Policyで制御します。

IAMが「誰が何をできるか」を決めるのに対して、Organization Policyは「組織として何を許可しないか」を決めるものです。

検知・可視化する

予防だけでなく、設定不備や脅威を見つける仕組みも必要です。設定不備を見つける、脆弱性や脅威を検知する、ログから不審な操作を追う、といった観点です。

この領域では、Security Command CenterCloud LoggingCloud Audit Logs などを見ます。

アプリやインフラの運用監視とは別に、セキュリティ観点で「危ない状態になっていないか」を見つけるための領域です。

逆引きで見る

実際の設計やPCAの問題では、サービス名から考えるより要件から考えることが多いです。社内ユーザーだけWebアプリに通したい、APIキーを安全に保管したい、保存時暗号化の鍵を顧客管理したい、GCSやBigQueryのデータ持ち出しを抑止したい、といった要件からサービスを選びます。

要件からサービスを選ぶ整理は『GCPセキュリティサービス逆引き』で扱います。

まとめ

  • GCPセキュリティは、サービス名ではなく守る対象で分けると整理しやすい
  • Cloud Armorは外部入口、IAPはアプリ入口、IAMはGCPリソース操作権限を見る
  • Secret Managerは秘密値、Cloud KMS / CMEKは暗号鍵と保存時暗号化を見る
  • VPC Service Controlsはデータ持ち出し境界、Organization Policyは組織制約を見る
  • Security Command CenterやLoggingは検知・可視化の領域を担う

参考

タグ: GCP, クラウド設計, セキュリティ