mcpField
A
assuredworkloads-environment-assessor

assuredworkloads-environment-assessor

github.com/googleセキュリティ21.6k652 回インストール今日更新
リポジトリ

assuredworkloads-environment-assessor について

Google Cloud のフォルダーやプロジェクトのコンプライアンス環境を評価するスキルです。読み取り専用の調査、テレメトリー分析、データ境界フレームワークの推奨を行い、変更操作を禁止して、ポリシー確認を確定的な違反ではなく事前準備の指標として扱います。

主な機能

  1. 01読み取り専用でリソースとポリシーを調査
  2. 02ロケーションとサービス利用を分析
  3. 03CMEK ポリシーの準備状況を評価
  4. 04データ境界フレームワークを推奨
  5. 05事前確認とサーバー評価を区別

活用シーン

  1. 01フォルダーやプロジェクトのリソース一覧化
  2. 02組織ポリシーの潜在的なずれの確認
  3. 03ワークロード向けコンプライアンス枠組みの選定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/google/skills --skill assuredworkloads-environment-assessor

インストール後、Claude Code で/assuredworkloads-environment-assessorを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
attribution.md
gcloud-commands.md
scripts/
evaluate_control_rules.py
validate_workload_payload.py

詳細

コンプライアンス環境評価スキル

このスキルは、Google Cloud のフォルダ(folders/{folder_id})とプロジェクト(projects/{project_id})を対象に、リスクゼロで変更を加えないコンプライアンス情報の検出、物理テレメトリのプロファイリング、データ境界フレームワークの推奨を行います。

使用状況の帰属

必ずお読みください:gcloud、REST API、または MCP コマンドを実行する前に、 使用状況の帰属の指示を必ず読み、 従ってください。

安全性と実行ティア(重要)

  • ティア R(厳密な読み取り専用): すべての検出操作では、読み取り専用クエリを実行します ( gcloud asset search-all-resources、 gcloud compliance-manager frameworks list、 gcloud compliance-manager cloud-controls describe、および gcloud org-policies describe --effective)。 変更を加えるコマンド(gcloud compliance-manager framework-deployments create、 gcloud org-policies set-policy、または gcloud resource-manager ...)を実行しては 絶対にいけません。

グラウンディングのガードレール:Google Cloud と Assured Workloads の優先(重要)

汎用 LLM の事前学習に由来するハルシネーション、不正確なコンプライアンス評価、誤ったブロッカーを防ぐため、エージェントには厳格なグラウンディングのガードレールが適用されます。

  1. 一般的な LLM の事前学習済み知識に基づく判断の厳格な禁止:
    • 一般的なウェブデータによる事前学習から、コンプライアンスルール、API の意味、デプロイの制約を導き出してはなりません(一般的な NIST/FedRAMP 認証監査チェックリスト、AWS/Azure アーキテクチャ、従来のオンプレミス IT 監査担当者の考え方など)。
    • 従来の IT 監査では、コンプライアンス違反はデプロイを阻止する二者択一のゲートです。Google Cloud Assured Workloads v2 では、Monitor Mode は既存の Organization Policies を変更せずに検知制御をデプロイするため、Day 0 のロールアウトを停止せず、継続的な可観測性を実現できます。これらの方式を混同してはなりません。
  2. Google Cloud API の正式な契約とスコープに基づく判断:
    • API に関するすべての前提は、公開されている Google Cloud API の契約に基づかなければなりません:
      • Assured Workloads v1 GA API(assuredworkloads.googleapis.com/v1):新規作成専用です。契約上、新しいフォルダー(resourceType: CONSUMER_FOLDER)のみ作成できます。既存のブラウンフィールドのフォルダー(folders/...)やプロジェクトを、その場で採用またはバインドすることはできません。
      • Assured Workloads v2 API(assuredworkloads.googleapis.com/v2):ブラウンフィールドにネイティブ対応しています。既存のリソース階層(existingFolder、existingProject)に直接バインドでき、リソースを変更しない Monitor Mode(enforcementMode: DETECTIVE)をサポートします。
  3. クライアント側の組織ポリシー準備状況とサーバー側 CES の境界:
    • クライアント側のスコープ:scripts/evaluate_control_rules.py による事前評価では、Framework.cloudControlDetails[].parameters にバインドされている、確度の高い次の 3 つの組織ポリシーパラメータセットのみを評価します:
      1. リソースロケーション(builtin-restrict-resource-locations / constraints/gcp.resourceLocations)
      2. Service Usage Restrictions / SUR (builtin-enforce-service-usage-restrictions / constraints/gcp.restrictServiceUsage)
      3. CMEK 暗号化要件(builtin-require-cmek / constraints/gcp.restrictNonCmekServices)
    • サーバー側の CES スコープ:複雑な Continuous Evaluation Service (ces_rule)と REST API ルール(rest_api_measurement)は、フレームワークのデプロイ後に Continuous Evaluation Service(CES)がサーバー側で評価します。
    • 用語に関する不変条件:クライアント側の調査結果は、事前フライトの組織ポリシー準備状況に関する推奨事項/潜在的なドリフト指標 (orgPolicyDriftIndicators)として表現しなければなりません。実際のデプロイ後の CES 実行結果と矛盾する可能性がある、コンプライアンス上の「違反」や「デプロイ阻止要因」として断定してはなりません。
  4. 静的な組み込みカタログ、セッションキャッシュ、サポートの案内、KAJ フロー:
    • gcloud compliance-manager frameworks list が返す組み込みフレームワーク(type: BUILT_IN)は、組織間で共通する静的な構成です。セッションごとに frameworks.json を一度取得し、すべての候補の評価とフォローアップクエリでキャッシュされたファイルを再利用してください。
    • 担当者サポートモデル:フレームワークの cloudControlDetails に builtin-restrict-technical-support-services が含まれる場合、そのフレームワークには有料のソブリン/規制対象サポートサブスクリプションが必要です(displayName と description に反映されています)。builtin-restrict-technical-support-services を含まないフレームワーク(例:builtin-us-data-boundary、builtin-eu-data-boundary)では、標準の商用サポート(サポート料金の上乗せなし)を利用します。
    • Key Access Justifications(KAJ)と EKM:-with-access-justifications のフレームワークバリアントを推奨するのは、お客様が KAJ/EKM を明示的にリクエストした場合、または frameworks.json 内の一致するリージョン別バリアントを特定する場合に限ります。
  5. 決定論的なツール実行ゲート:
    • 互換性スコア($$S_{\text{composite}}$$)やリソースインベントリを推測してはなりません。
    • --frameworks-file=frameworks.json を指定して scripts/evaluate_control_rules.py を実行し、--frameworks-file=frameworks.json を指定して scripts/validate_workload_payload.py を実行しなければなりません。

前提条件

環境アセスメントを実行する前に、ローカル環境または Cloud Shell 環境が以下の前提条件を満たしていることを確認してください。

  1. Google Cloud SDK:
  2. プロジェクトの設定と対象の選択:
    • アセスメントクエリを実行するための管理用プロジェクトを選択または設定します:
      gcloud config set project PROJECT_ID
      
  3. リージョンの設定と利用可能性:
    • 十分にサポートされているデフォルトのリージョン(例:us-central1)を設定します:
      gcloud config set compute/region us-central1
      
    • 公式のリージョン利用可能状況のドキュメントを参照してください:Google Cloud Locations。プレビュー版のモデルや API は、多くの場合 global または us-central1 に制限されます。
  4. 必要な API の有効化:
    • 管理用プロジェクトで必要な Google Cloud API を有効にします:
      gcloud services enable \
        cloudasset.googleapis.com \
        orgpolicy.googleapis.com \
        assuredworkloads.googleapis.com \
        cloudsecuritycompliance.googleapis.com
      
  5. 認証の設定:
    • ユーザーまたはサービスアカウントの ID で認証し、アプリケーションのデフォルト認証情報を設定します:
      gcloud auth login
      gcloud auth application-default login
      
  6. 課金と割り当てプロジェクトの設定(課金への影響なし):
    • アセスメントの費用ゼロ保証:このアセスメントを実行しても、Google Cloud のインフラストラクチャおよび API の課金は $0 です。すべての検出操作(gcloud asset search-all-resources、gcloud compliance-manager frameworks list、gcloud org-policies describe --effective)は、無料の読み取り専用メタデータクエリです。
    • 割り当てプロジェクトの要件:Google Cloud Service Infrastructure では、API のレート制限の割り当てとサービス使用量の計測(X-Goog-User-Project ヘッダーを介して送信)を行うため、無料 API の場合でも、有効な Cloud Billing アカウントが紐付けられた管理用プロジェクトが必要です。
    • 事前確認:
      # 1. 有効な Cloud Billing アカウントが管理用プロジェクトに紐付けられていることを確認します
      gcloud billing projects describe PROJECT_ID --format="value(billingEnabled)"
      
      # 2. 共有プロジェクトを使用する場合は、ユーザー ID にプロジェクトの割り当てを使用する権限があることを確認します
      gcloud projects add-iam-policy-binding PROJECT_ID \
        --member="user:USER_EMAIL" \
        --role="roles/serviceusage.serviceUsageConsumer"
      
      # 3. Application Default Credentials の割り当てプロジェクトを同期します
      gcloud auth application-default set-quota-project PROJECT_ID
      
  7. コマンドとペイロードのリファレンス:
    • サーバー側の完全な投影マスク、フィールドフィルター、API ペイロードの定義については、Google Cloud CLI Commands Reference を参照してください。

ステップごとの運用ワークフロー

ステップ 1:スコープの取り込みと組織 ID の解決
  1. 対象スコープ(folders/{folder_id} または projects/{project_id})を受け取るか、ユーザーに入力を促します。ユーザーが規制体制を明示せず、範囲が広いスコープを指定した場合でも、広範な質問票への回答を求めて処理を止めてはなりません。直ちにテレメトリの取り込みを開始します。
  2. 下流のカタログクエリに使用するため、スコープから親の組織 ID を自動的に解決します:
    • フォルダーの場合:
      gcloud resource-manager folders describe FOLDER_ID --format="value(parent)"
      
      (親が別のフォルダーの場合は、organizations/{org_id} が見つかるまで祖先をたどります)
    • プロジェクトの場合:
      gcloud projects get-ancestors PROJECT_ID --format="value(id,type)"
      
ステップ 2:2 パスのテレスコーププロトコルでアセットのテレメトリーと有効な組織ポリシーを取り込む

スコープ階層全体を 100% 網羅しながらペイロードをコンパクトに保つため、テレメトリーの取り込みは 2 回のテレスコープパスで実行されます(Google Cloud CLI コマンドリファレンスを参照)。

  1. パス 1:マクロフットプリントと API の列挙(スコープを 100% 網羅):

    gcloud asset search-all-resources \
      --scope="folders/FOLDER_ID" \
      --page-size=500 \
      --format="json(name,assetType,location)" > macro_telemetry.json
    
    • ページネーションとスコープのセマンティクス:--page-size=500 は、Cloud Asset Inventory で許可される最大バッチサイズである 500 個のクラウドアセットを、HTTP API の 1 ページごとに取得します。folders/FOLDER_ID とその配下のプロジェクトに厳密に含まれるすべてのアセットを自動的にページネーションして取得します。
    • ロケーションと SUR の完全な網羅:macro_telemetry.json は、builtin-restrict-resource-locations(allowedLocations)と builtin-enforce-service-usage-restrictions(allowedServices / SUR)の両方を評価するために必要な、アクティブな location と assetType の値を 100% 記録します。
    • PERMISSION_DENIED が返された場合:
      • エラーに USER_PROJECT_DENIED と記載されているか、roles/serviceusage.serviceUsageConsumer に言及している場合、エラーは管理用の割り当てプロジェクトに関するものです(請求先アカウントが紐付けられていないか、呼び出し元に serviceUsageConsumer がありません)。割り当てプロジェクトの復旧手順に従い、それ以上のコマンドの実行を中止してください。
      • エラーが対象スコープ(folders/... または projects/...)に言及している場合は、直ちにすべてのツール呼び出しを中止し(ステップ 2.2、ステップ 3、またはそれ以降のコマンドを実行しないでください)、対象スコープで roles/cloudasset.viewer と roles/orgpolicy.policyViewer が必要であることをユーザーに伝えてください。
    • 返されたリソースが 0 個の場合は、対象スコープが空であることをユーザーに伝えてください。
  2. スコープ上の有効なユニバーサル組織ポリシーを確認する(38/38 フレームワーク):

    gcloud org-policies describe gcp.resourceLocations \
      --folder=FOLDER_ID \
      --effective \
      --format="json(name,spec.rules)" > effective_locations.json
    
    gcloud org-policies describe gcp.restrictServiceUsage \
      --folder=FOLDER_ID \
      --effective \
      --format="json(name,spec.rules)" > effective_services.json
    
    gcloud org-policies describe gcp.restrictTLSVersion \
      --folder=FOLDER_ID \
      --effective \
      --format="json(name,spec.rules)" > effective_tls.json
    
ステップ 3:組み込みフレームワークカタログを取得してキャッシュし、ロケーションと SUR に基づいてフィルタリングする
  1. 組み込みフレームワークカタログを取得してキャッシュする(バインドパラメータを使用):
    if [ ! -s frameworks.json ]; then
      gcloud compliance-manager frameworks list \
        --organization=ORGANIZATION_ID \
        --location=global \
        --filter="category:ASSURED_WORKLOADS" \
        --format="json(name,majorRevisionId,displayName,description,category,cloudControlDetails)" > frameworks.json
    fi
    
    • セッションキャッシュ:組み込みの ASSURED_WORKLOADS フレームワークは組織間で共通の静的定義であるため、出力を frameworks.json にキャッシュし、すべての候補評価、ペイロード検証、追加の質問で再利用します。
  2. ロケーションと SUR のフットプリントに基づいて候補を絞り込み、意図を確認する:
    • ロケーションを持たないコントロールプレーン管理メタデータ (cloudresourcemanager.googleapis.com/*、orgpolicy.googleapis.com/*、 cloudasset.googleapis.com/*、accesscontextmanager.googleapis.com/*、 および location: "global" の階層ノード)は、データプレーンのロケーション確認から除外します。
    • macro_telemetry.json のアクティブなデータプレーンリージョン(location)とアクティブなサービスプレフィックス(assetType)を、frameworks.json の各フレームワークの builtin-restrict-resource-locations(allowedLocations)および builtin-enforce-service-usage-restrictions(allowedServices / SUR)パラメータと照合します。
      • 米国限定リージョン(us-central1、us-east4):候補には、DoD IL5(builtin-il5、裁定済みサポート)、ITAR(builtin-itar、米国人によるサポート)、FedRAMP High/Moderate、または US Regional Data Boundary(builtin-us-data-boundary、標準的な商用サポート)が含まれます。
      • EU 限定リージョン(europe-west3、europe-west1):候補には、EU Data Boundary and Support(builtin-eu-data-boundary-and-support)と、標準の EU Regional Boundary(builtin-eu-data-boundary)が含まれます。
    • 対象を絞った確認:
      • 物理的なフットプリントに一致するフレームワークが複数あり、ユーザーの規制上の意図が明示されていない場合(例:規制体制を指定していない、範囲の広いリクエスト)、単一の第一候補をまだ確定してはいけません。一致する候補フレームワークを提示し、ユーザーに規制上の意図(例:EU Sovereignty、US FedRAMP/IL5)と担当者のサポートモデル(標準的な商用サポートか、有償のソブリン/規制対象サポートか)について、対象を絞った確認の質問をして停止します。
      • -with-access-justifications(KAJ/EKM)フレームワークのバリアントは、顧客が KAJ/EKM を明示的に求めた場合、または一致するリージョンバリアント間の確認に必要な場合にのみ推奨します。
      • 対象外/カタログにないコンプライアンス基準(例:CMMC、UK GDPR): ユーザーが frameworks.json に組み込みの ASSURED_WORKLOADS フレームワークとして存在しないコンプライアンス基準または法的認証(CMMC、UK GDPR、SOC 2、PCI-DSS など)の評価を求めた場合、存在しないフレームワーク ID(例:builtin-cmmc、builtin-uk-gdpr)を捏造して evaluate_control_rules.py または validate_workload_payload.py に渡してはいけません。要求された基準は単独の Assured Workloads Data Boundary フレームワークではないことを明確に伝え、カタログの対象範囲の境界を説明します(Data Boundary が適用するのは、地域ごとのデータレジデンシー、SUR、CMEK、ソブリン向けサポートのルーティングであり、法的なプライバシー要件や第三者認証監査ではありません)。また、アクティブなリージョンのフットプリントに一致する、frameworks.json にある最も近い関連 ASSURED_WORKLOADS フレームワークを提示します(例:米国の防衛/CUI ワークロードには builtin-il5 または builtin-fedramp-high、欧州/英国の地域データレジデンシーには builtin-eu-data-boundary-and-support/builtin-eu-data-boundary/builtin-uk-data-boundary)。
Step 4: 条件付き Pass 2 CMEK 取り込みと組織ポリシー評価
  1. Pass 2:CMEK リソースタイプの条件付きターゲット詳細取り込み: macro_telemetry.json 内のアクティブな CAI assetType と、 frameworks.json の builtin-require-cmek に含まれる CMEK 管理対象サービスの共通部分から TARGET_TYPES を導出します。38 個の Data Boundary フレームワークのうち、 builtin-require-cmek を含むのは 6 個だけです。TARGET_TYPES が空でない場合は、kmsKeys を取得します:
    TARGET_TYPES=$(python3 scripts/evaluate_control_rules.py \
      --get-target-asset-types \
      --framework=FRAMEWORK_ID \
      --telemetry-file=macro_telemetry.json \
      --frameworks-file=frameworks.json)
    
    if [ -n "${TARGET_TYPES}" ]; then
      gcloud asset search-all-resources \
        --scope="folders/FOLDER_ID" \
        --asset-types="${TARGET_TYPES}" \
        --page-size=500 \
        --format="json(name,assetType,location,kmsKeys)" > deep_telemetry.json
    fi
    
  2. 信頼性の高い組織ポリシー評価ツールを実行: scripts/evaluate_control_rules.py を frameworks.json とともに macro_telemetry.json(および任意の deep_telemetry.json)に対して実行し、 3 つの定量スコア(locationScore、serviceScore、cmekScore、 compositeScore)と orgPolicyDriftIndicators を算出します(cmekRequired が false の場合は、スコアカードの CMEK 準備状況列に常に N/A を表示します):
    python3 scripts/evaluate_control_rules.py \
      --telemetry-file=macro_telemetry.json \
      --deep-telemetry-file=deep_telemetry.json \
      --framework=FRAMEWORK_ID \
      --frameworks-file=frameworks.json
    
  3. 運用面およびガバナンス面への影響を評価:
    • frameworks.json 内の、パラメーター化された運用上のコントロール (builtin-restrict-kms-protection-levels、 builtin-enforce-allowed-cmek-crypto-key-projects、 builtin-restrict-cloud-function-generations、 builtin-restrict-cloudstorage-auth-types、 builtin-iam-disable-service-account-key-creation、 builtin-disable-ssh-in-browser、builtin-enable-axt、および builtin-cloud-logging-regulatory-settings のような *-regulatory-settings コントロール)の cloudControlDetails を確認し、 ワークフローへの影響を最終レポートにまとめます。
  4. Turnkey Assured Workloads ペイロードを検証:
    python3 scripts/validate_workload_payload.py \
      --payload-json='{"displayName":"Sovereign-Workload-Enclave","resourceConfig":{"existingFolder":"folders/FOLDER_ID"},"framework":{"framework":"organizations/ORGANIZATION_ID/locations/global/frameworks/FRAMEWORK_ID"}}' \
      --org-id=ORGANIZATION_ID \
      --frameworks-file=frameworks.json
    
Step 5: エグゼクティブ評価レポートの作成(ミント・ピラミッド構造)

ミント・ピラミッド原則 (結論を最初に提示 -> 中核となる価値の柱 -> 裏付けとなる証拠 -> アクションプラン)に沿って、 エグゼクティブレポートを提示します:

# Compliance Environment Assessment Report: [Scope URI]

## 1. Executive Conclusion & Recommendation (Bottom Line Up Front)
* **Primary Recommendation**: [Framework Name] (`organizations/{org_id}/locations/global/frameworks/{framework_id}`)
* **Org Policy Readiness Alignment**: [Composite Fit %]
* **Value & Safety Invariant**: In-place brownfield adoption via Assured Workloads v2 in **Monitor Mode** (`enforcementMode: DETECTIVE`).
  * **Zero Production Outage Risk**: Mutates zero Organization Policies on Day 0.
  * **Continuous Server-Side CES Observability**: Activates real-time Continuous Evaluation Service (CES) monitoring across all framework controls.
  * **No Migration Required**: Protects existing resources in-place without provisioning separate folders.

---

## 2. Core Value Drivers: Why Assured Workloads Fits This Scope
1. **Residency & Boundary Alignment (`gcp.resourceLocations`)**: Active regional workloads are evaluated against allowed regions ([e.g. 100% US-contained]).
2. **Service & API Compatibility (`gcp.restrictServiceUsage` / SUR)**: Active service APIs are evaluated against accredited service allowlists ([e.g. 100% approved services]).
3. **Non-Disruptive Posture Hardening**: Enrolling in Monitor Mode provides server-side CES posture evaluation while allowing your team to triage Org Policy readiness safely.

---

## 3. Objective Assessment Scorecard & Org Policy Readiness Triage

### Quantitative Org Policy Readiness Scorecard
| Candidate Framework | Location Residency (`locationScore`) | Service Usage / SUR (`serviceScore`) | CMEK Readiness (`cmekScore`) | Composite Alignment | Personnel Support Model |
| :--- | :--- | :--- | :--- | :--- | :--- |
| **[Framework 1]** | [XX%] | [XX%] | [XX% or N/A] | **[XX%]** | [Support Model] |
| **[Framework 2]** | [XX%] | [XX%] | [XX% or N/A] | **[XX%]** | [Support Model] |

### Active Resource & Effective Org Policy Baseline
* **Discovered Inventory**: [Total Assets count] across [Active resource types and regions].
* **Effective Org Policy Baseline**: [Effective `gcp.resourceLocations`, `gcp.restrictServiceUsage`, and `gcp.restrictTLSVersion` posture].

### Pre-Flight Org Policy Readiness Recommendations (Prior to Enforced Mode)
*Pre-flight drift indicators do NOT block Day 0 deployment in Monitor Mode. Address these prior to enabling preventive policy enforcement (authoritative CES and REST control evaluations run server-side after deployment):*
* **[Priority 1]**: [e.g. Configure CMEK keys on unencrypted resources before toggling `builtin-require-cmek` to `PREVENTIVE`].
* **[Priority 2]**: [e.g. Operational impact of bound controls such as `builtin-restrict-kms-protection-levels` or `builtin-cloud-logging-regulatory-settings`].

---

## 4. Deployment Action Plan & Commercial Advisory

### Deploy via Google Cloud Console (Recommended)
Review and deploy the recommended framework directly in the Google Cloud Console:
👉 **[Open Assured Workloads Console](https://console.cloud.google.com/compliance/assuredworkloads?organizationId=ORGANIZATION_ID)**
*(The Console deployment wizard binds composing controls in Monitor Mode with zero infrastructure mutations).*

### Commercial & Licensing Advisory
* Assured Workloads compliance regimes may carry support routing or licensing entitlements depending on whether `builtin-restrict-technical-support-services` is bound (standard commercial support vs. paid sovereign/regulated support).
* Review full pricing details and entitlement tiers at: https://cloud.google.com/assured-workloads/pricing
ステップ 6:特定のサービスに関する顧客からの追加質問への対応

顧客から、推奨または候補のフレームワークが特定の Google Cloud サービス(例:Cloud Run、 Cloud Storage、Spanner、GKE、Cloud SQL、Vertex AI、Cloud Logging)にどのような影響を与えるかについて具体的な質問があった場合:

  1. キャッシュ済みの frameworks.json をローカルで確認する(キャッシュされていない場合はステップ 3 の frameworks list で取得する):
    • 現在の作業ディレクトリに frameworks.json がまだ存在しない場合は、まずステップ 3 の gcloud compliance-manager frameworks list コマンドを実行して frameworks.json を取得します。
    • <service>.googleapis.com が builtin-enforce-service-usage-restrictions の allowedServices で許可されているか、および builtin-require-cmek の services で CMEK が必須になっているかを確認します。
    • そのフレームワークにバインドされているサービス固有の cloudControlDetails[].name エントリ(例: builtin-run-disable-ephemeral-disk、 builtin-restrict-cloudstorage-auth-types、 builtin-disable-spanner-multi-region、 builtin-cloud-logging-regulatory-settings)と、バインドされている parameters を特定します。
  2. 必要に応じて、信頼できる制御の詳細を取得する:
    • Framework.cloudControlDetails には制御の説明、適用モード、修正手順が含まれていないため、該当する制御 ID に対して cloud-controls describe を実行します:
      gcloud compliance-manager cloud-controls describe CONTROL_ID \
        --organization=ORGANIZATION_ID \
        --location=global \
        --format="json(name,displayName,description,supportedEnforcementModes,remediationSteps,parameterSpec)"
      
    • レスポンスから、基盤となる Organization Policy 制約の正確な値(例: run.managed.disableEphemeralDisk、storage.restrictAuthTypes)、 supportedEnforcementModes(PREVENTIVE と DETECTIVE のどちらか)、および remediationSteps を抽出します。
  3. 依頼された場合は、フォルダ/プロジェクトに有効なポリシーを確認する:
    • 顧客から、自身のフォルダですでにそのサービス固有の Org Policy 制約が適用されているかどうかを尋ねられた場合は、次を実行します:
      gcloud org-policies describe CONSTRAINT_NAME \
        --folder=FOLDER_ID \
        --effective \
        --format="json(name,spec.rules)"
      

障害モードとエラー復旧プレイブック

エラー条件直ちに行う対応ユーザー向け復旧ガイダンス
USER_PROJECT_DENIED または serviceusage.serviceUsageConsumer検出を中止します。対象スコープの権限と混同しないでください。管理用プロジェクトの課金ステータスと、呼び出し元の割り当て権限を確認します。「管理用プロジェクト PROJECT_ID は API 割り当てに使用できません。1)Cloud Billing アカウントが紐付けられていることを確認します(gcloud billing projects describe PROJECT_ID)。2)ご自身の ID に PROJECT_ID 上の roles/serviceusage.serviceUsageConsumer を付与します。または、3)所有するプロジェクトに切り替えます:gcloud config set project <PROJECT_ID>。」
CAIS での PERMISSION_DENIED直ちに検出を中止します。リソースについて推測したり、憶測に基づいて判断したりしないでください。「この環境を分析するには、有効な ID に folders/123 上の roles/cloudasset.viewer を付与してください。」
組織ポリシーでの PERMISSION_DENIEDポリシーの調査を中止します。有効な制約を推測しないでください。「有効な組織ポリシーを確認するには、folders/123 上の roles/orgpolicy.policyViewer を付与してください。」
空のスコープ(リソース 0 件)評価を中止します。スコープにアクティブなアセットが含まれていないことをユーザーに伝えます。「folders/123 にアクティブなリソースが見つかりません。リソースをプロビジョニングするか、アクティブなスコープを選択してください。」
規制上の要件の不一致要点を絞った確認を行い、ユーザーに詳細を尋ねます。異なる要件(例:DoD IL5 の審査済みサポートと ITAR の米国人要件)を提示し、業務上の要件を確認します。
カタログに一致するものがないマルチリージョンの乖離を示す指標を詳しく説明します。単一リージョンのソブリンデータ境界フレームワークが除外された理由(例:承認されていないリージョンにまたがる複数大陸のリソースフットプリント)を説明します。
スコープ外/カタログにない標準(例:CMMC、UK GDPR)フレームワーク ID(builtin-cmmc、builtin-uk-gdpr)を捏造しないでください。カタログの対象範囲を説明し、隣接する ASSURED_WORKLOADS の候補を提示します。「Assured Workloads には、frameworks.json に独立した [CMMC / UK GDPR] フレームワークは含まれていません。ただし、アクティブなリソースに基づき、隣接する Assured Workloads データ境界フレームワークとして、builtin-il5/builtin-fedramp-high(米国の防衛/連邦政府ワークロード向け)、または builtin-eu-data-boundary-and-support/builtin-uk-data-boundary(欧州/英国の地域内データ保管向け)を評価できます。」

コメント