Assured Workloads

解決する課題

「規制やコンプライアンス要件に適合した環境を、人手の設定漏れなく確実に用意したい」というのが核心です。データをどこに保管できるか、誰がそのリソースを運用・サポートできるか、暗号鍵をどう管理するか、といった要件を個別の設定として積み上げると、抜けや解釈のブレが生じます。Assured Workloads は、そうした要件をひとまとまりのコンプライアンス管理境界として最初から技術的に強制します。

• データの**保管地域（データレジデンシー）**を特定リージョンに限定し、域外への流出を防ぎたい
• リソースを運用・サポートするGoogle 側担当者の所在や審査要件を統制したい
• 規制（公共部門・金融・医療など）で求められる統制を最初から組み込んだ環境を素早く用意したい
• 準拠状態が崩れていないかを継続的に監視し、逸脱を早期に検知したい

主要概念と用語

• コンプライアンス体制（Compliance Regime）: 満たすべき規制・基準の種類。選んだ体制に応じて、適用されるリージョン制限やアクセス制御などのポリシーが変わる
• 管理境界（Control Package / Folder）: Assured Workloads が作成する専用フォルダ。配下のプロジェクトやリソースに、選んだ体制のポリシーが自動適用される
• データレジデンシー: データの保管・処理を特定の地理的リージョンに限定する統制。保存データだけでなく処理の場所も対象になり得る
• 担当者アクセス制御: リソースを運用・サポートする Google 側の担当者について、所在地や審査などの条件を制限する仕組み
• モニタリング（準拠状態の可視化）: 境界内の設定が選んだ体制から逸脱していないかを継続的に検査し、違反を一覧化するダッシュボード
• 顧客管理鍵（CMEK）連携: 暗号鍵を顧客側で管理する要件に対応するため、Cloud KMS の鍵をリソースに紐づけて利用する

仕様・制限・クォータ

• フォルダ単位で機能する: Assured Workloads は専用のフォルダを作り、その配下に作成したプロジェクト・リソースへポリシーを適用する。境界の外には効力が及ばない
• 体制ごとに対応リージョン・サービスが異なる: 選んだコンプライアンス体制によって、利用できるリージョンや対応プロダクトの範囲が制限される。サポート対象のサービスのみが境界内で利用可能
• 後からの体制変更には制約がある: 一度作成した境界の体制を任意に切り替えることは想定されておらず、新しい要件には新しい境界を作るのが基本
• 組織レベルの設定が前提: 利用には Cloud 組織と、Assured Workloads の有効化、適切な IAM 権限が必要
• 対応する規制・地域は拡張され続ける: 利用可能なコンプライアンス体制と対応リージョンの一覧は変動するため、最新の対応状況は公式ドキュメントで確認する（ここでは定性的に述べるに留める）

内部の仕組み

Assured Workloads は、組織の下に規制要件を束ねた専用フォルダを用意し、そのフォルダに対して組織ポリシーやアクセス制御を束ねて適用することで動作します。流れはおおむね次の通りです。

• 利用者が満たすべきコンプライアンス体制と配置リージョンを選び、Assured Workloads が対応する**管理境界（フォルダ）**を作成する
• 境界には、選んだ体制に応じたリソースロケーション制限（組織ポリシー）や担当者アクセス制御などが束ねて自動適用される
• 配下に作るプロジェクトやリソースは、これらのポリシーによって域外リージョンへの配置が拒否され、未対応サービスの利用が抑止される
• モニタリングが境界内の設定を継続的に評価し、ポリシーからの逸脱を違反として記録・表示する

つまり「個別サービスを後から縛る」のではなく、境界に入れた時点で要件が掛かるという設計です。データレジデンシーや担当者制限といった横断的な要件を、各リソースの設定ではなくフォルダのポリシーとして一括で効かせる点が要になります。

設計パターン / ベストプラクティス

• 対象ワークロードは最初から境界内に作る。後から移すのではなく、要件のあるシステムは境界フォルダ配下で新規構築する
• 満たすべき規制から体制を選ぶ。要件を満たす最小の体制を選び、不要に厳しい制限で運用効率を落とさない
• データレジデンシー要件は配置だけでなく経路も確認する。ログ・バックアップ・派生データの保管先も域内に収まるよう設計する
• 暗号鍵が顧客管理要件なら Cloud KMS（CMEK）と組み合わせる。鍵の所在とローテーションも準拠の一部として扱う
• モニタリングを定常運用に組み込む。違反検知をアラート化し、設定逸脱を放置しない
• 境界をまたぐ運用設計を避ける。境界内外でデータをやり取りする構成は、所在地統制の前提を崩しやすい

運用・監視

• 準拠モニタリングのダッシュボードを定期的に確認し、ポリシー違反や設定逸脱を早期に把握する
• 境界内の操作は Cloud Audit Logs に記録される。誰がどのリソースを変更したかを追跡し、統制の有効性を検証する
• 新しいサービスを境界内で使う前に、そのサービスが選んだ体制でサポートされているかを確認し、未対応サービスの利用申請を制御する
• データレジデンシー違反（域外への保管・処理）が検知された場合は、対象リソースの配置リージョンとデータの流れを洗い出して是正する
• 担当者アクセスのログを確認し、運用・サポートが要件の範囲内で行われているかを点検する

コスト

Assured Workloads の境界を作ること自体よりも、境界内で稼働させる各サービスの利用料と、準拠運用に伴う費用が中心です。リージョンが限定されることで価格や選択肢が制約される点、暗号鍵管理（Cloud KMS）やログ保持（Cloud Logging）が付随する点を見込む必要があります。

セキュリティ

• データレジデンシーを技術的に強制し、人手の設定に頼らず域外への保管・処理を拒否する
• 運用・サポート担当者のアクセスを統制し、要件外の所在地・条件からのリソース操作を制限する
• 暗号鍵を**顧客側で管理（CMEK）**し、鍵の所在とローテーションも準拠範囲として扱う
• 境界やポリシーを変更できるIAM 権限を最小化し、統制そのものの無効化を防ぐ
• モニタリングで逸脱を継続検知し、準拠が一時的に崩れた状態を放置しない

関連サービス・比較

Assured Workloads は、組織ポリシーによるリソースロケーション制限や Cloud KMS と組み合わせて機能します。とくに**リソースロケーション制限（組織ポリシー）**は単体でも地域制限を実現できますが、Assured Workloads は規制体制として横断的な統制を束ねて適用し、準拠状態の監視まで含む点が異なります。

ハンズオン / CLI例

# Assured Workloads のワークロード（管理境界）を作成する
# --compliance-regime には満たすべき規制体制の識別子を指定する
gcloud assured workloads create \
  --organization=ORGANIZATION_ID \
  --location=us-central1 \
  --display-name="regulated-workload" \
  --compliance-regime=COMPLIANCE_REGIME \
  --billing-account=billing-account/BILLING_ACCOUNT_ID \
  --next-rotation-time=2026-12-31T00:00:00Z \
  --rotation-period=2592000s

# 組織配下のワークロード（境界）を一覧する
gcloud assured workloads list \
  --organization=ORGANIZATION_ID \
  --location=us-central1

# 特定のワークロードの詳細を確認する
gcloud assured workloads describe WORKLOAD_ID \
  --organization=ORGANIZATION_ID \
  --location=us-central1