設計の判断

コンプライアンスとデータの所在

Google Cloud が認証を取っていても、設定とデータの扱いの責任は利用者に残ります。データの所在はロケーションの選択と組織ポリシーで、より厳しい要件は Assured Workloads で、監査は Cloud Audit Logs で満たします。

Google Cloud は SOC 2 や PCI DSS などの第三者認証を取得していますが、それで利用者のシステムが規制に適合するわけではありません。試験で問われるのは、規制が求める要件を、セキュリティの設計で扱った統制のどれで満たすかです。

Google の認証は、利用者の監査の材料になる

薄い色の上 2 層は利用者、濃い色の下 2 層は Google の担当。監査では、下の層を Google の認証レポートで説明し、自社の統制は上の層だけ整えれば足ります。

Google が取得した認証のレポートは Compliance Reports Manager から入手できます。マネージドサービスほど Google の担う範囲が広がり、Compute Engine の VM なら OS のパッチ適用は利用者の担当です。

規制ごとに、設計へ持ち込まれる要件が違う

規制や基準	対象	設計への要件
HIPAA (米国)	医療情報 (PHI)	Google と BAA を結び、BAA の対象サービスだけで PHI を扱う
児童のプライバシー (米国の COPPA など)	子どもの個人情報	保護者の同意、収集の最小化、削除の仕組み
GDPR (EU) などの個人情報保護法	個人データ	収集目的の限定、削除の要求への対応、国外への移転の管理
データ主権	国や地域の内側に置くべきデータ	ロケーションの制限、Google の担当者のアクセスの制御
PCI DSS	クレジットカードの会員データ	カード会員データ環境の分離と縮小、暗号化、アクセスの記録
SOC 2	サービス提供者の内部統制	変更管理、アクセス管理、監視の証跡

HIPAA では、BAA の対象外のサービスや一般提供前のサービスで PHI を扱ってはいけません。対象は公式ページに一覧があります。ラベルやリソース名のようなメタデータにも PHI を書かないよう、Google は求めています。

PCI DSS では、監査の対象になる範囲を小さくします。カード会員データを扱う部分を専用のプロジェクトと VPC に切り出し、VPC Service Controls の境界で囲みます。カード番号を持たず決済代行事業者のトークンだけを持てば、範囲はさらに縮みます。

個人情報は、Sensitive Data Protection の検出で BigQuery や Cloud Storage のどこにあるかを見つけ、マスキングやトークン化で減らします。期限が来たら消すデータは Cloud Storage のライフサイクルルールや BigQuery のテーブルの有効期限で、一定期間消してはいけないデータは保持ポリシー (Bucket Lock) で扱います。

データの所在は、ロケーションで決まる

日本国内に収まるのは、東京か大阪のリージョンと、その 2 つを組んだ asia1 です。asia マルチリージョンが約束する範囲はアジアまでです。

Cloud Storage のロケーションは 3 種類あります。リージョンは 1 リージョンの中の 2 ゾーン以上に複製し、デュアルリージョンとマルチリージョンは複数のリージョンに複製します。リージョン障害に耐えるには後の 2 つが要ります。デュアルリージョンには、既定の複製 (RPO 12 時間) のほかに、15 分で複製するターボレプリケーションがあります。

「国内に保存」と「国内のリージョン障害に耐える」が両方求められたら、答えは asia1 です。EU の場合も中身を見ます。デュアルリージョン eur5 はベルギーとロンドンの組で、ロンドンは EU の外です。

試すデータの置き場所を選ぶ

データの所在

耐える障害

RPO 15 分以内で別リージョンへ複製する

asia-northeast1リージョン / 東京満たす
asia-northeast2リージョン / 大阪満たす
asia1デュアルリージョン / 東京 + 大阪満たす
asiaマルチリージョン / アジア (香港とインドネシアを除く)満たす
europe-west1リージョン / ベルギー満たす
eur4デュアルリージョン / フィンランド + オランダ満たす
eur5デュアルリージョン / ベルギー + ロンドン満たす
euマルチリージョン / EU 加盟国満たす
usマルチリージョン / 米国満たす

どのロケーションも条件を満たします。

ロケーションを選んだら、組織ポリシーの constraints/gcp.resourceLocations で、許可したロケーション以外にリソースを作れないようにします。組織ポリシーは既存のリソースを動かさないので、環境を作る前に設定します。

組織ポリシーで縛れないのが、Google の担当者の所在地とアクセスです。この要件には Assured Workloads を使います。フォルダに日本、EU、米国などのデータ境界や、FedRAMP、HIPAA などのコントロールパッケージを適用し、ロケーションの制限、サポート担当者の所在地の制限、CMEK の必須化をまとめてかけます。Access Transparency は Google の担当者がデータにアクセスした記録を見せ、Access Approval はそのアクセスを事前に承認させます。鍵を Google の外に置く Cloud EKM と Key Access Justifications を組み合わせると、Google 側だけでは復号できません。

監査ログは、種類によって既定の動きが違う

種類	記録するもの	既定の状態
管理アクティビティ	リソースの作成、設定の変更	常に記録。無効にできない
システムイベント	Google のシステムによる変更	常に記録。無効にできない
データアクセス	データの読み取り、ユーザーによるデータの書き込み	BigQuery 以外は無効。有効にすると料金がかかる場合がある
ポリシー拒否	VPC Service Controls などで拒否されたアクセス	記録される。除外フィルタで取り込まないようにできる

試験で一番よく出るのは、データアクセスの監査ログが BigQuery 以外では既定で無効だという点です。「誰が患者のデータを読んだかを記録したい」なら、対象サービスのデータアクセスの監査ログを有効にします。

既定の保存期間は _Required が 400 日、_Default が 30 日です。数年の保存が要るなら、組織の集約シンクで長期保存用のバケットへ送ります。

ログを置くプロジェクトの閲覧権限は監査担当だけに付けます。監査される側の管理者がログを消せない形にすると、職務の分離にもなります。

試してみる

自分のプロジェクトの管理アクティビティの監査ログを読み、_Required バケットの保存期間を確かめます。読むだけなので料金はかかりません。セキュリティの設計の「試してみる」を実行したあとなら、サービスアカウントやシークレットを作った記録が見えます。

PROJECT_ID=$(gcloud config get-value project)

# 管理アクティビティの監査ログを、誰が何をしたかの形で 10 件表示する
gcloud logging read \
  "logName=\"projects/${PROJECT_ID}/logs/cloudaudit.googleapis.com%2Factivity\"" \
  --limit=10 \
  --format="table(timestamp, protoPayload.authenticationInfo.principalEmail, protoPayload.methodName)"

# _Required バケットの保存期間 (retentionDays) を確認する
gcloud logging buckets describe _Required --location=global

この手順はリソースを作らないので、後片付けは要りません。

試験で問われる判断

以下は、このカリキュラム用に作った例です。

「医療機関の予約システムを移す。患者の情報を扱う」。まず Google と BAA を結び、対象サービスだけで構成します。暗号化やログの設定はその後です。

「監査人から、過去 3 年分の設定変更の記録を求められている」。_Required の 400 日では足りないので、集約シンクで長期保存先へ送ります。

「EU の顧客データを EU の外に出さない。開発者には広い権限を渡したい」。IAM ロールを絞るのではなく、ロケーション制約で EU に限定します。Google の担当者のアクセスまで制限するなら、Assured Workloads の EU 向けパッケージを選びます。

次のページでは、可用性と災害復旧の要件を数字にし、構成を選ぶ方法を扱います。