

これは AWS CDK v2 デベロッパーガイドです。旧版の CDK v1 は 2022 年 6 月 1 日にメンテナンスを開始し、2023 年 6 月 1 日にサポートを終了しました。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# AWS 合成時の CDK ポリシーの検証
<a name="policy-validation-synthesis"></a>

## 合成時のポリシー検証
<a name="policy-validation"></a>

[AWS CloudFormation Guard ](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html)や [OPA](https://www.openpolicyagent.org/) などのポリシー検証ツールを使用して AWS CloudFormation テンプレートの制約を定義する場合は、合成時に AWS CDK と統合できます。適切なポリシー検証プラグインを使用することで、 AWS CDK アプリケーションで、合成直後に生成された AWS CloudFormation テンプレートをポリシーと照合させることができます。違反がある場合、合成は失敗してレポートがコンソールに出力されます。

合成時に AWS CDK によって実行される検証は、デプロイライフサイクルのある時点でコントロールを検証しますが、合成以外で発生するアクションには影響しません。例には、コンソールで直接実行されるアクションや、サービス API を介したアクションが含まれます。合成後の AWS CloudFormation テンプレートの変更には耐性がありません。「[AWS CloudFormation フック](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks.html)」や「[AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)」など、同じルールセットをより権威的に検証する他のメカニズムを個別に設定する必要があります。ただし、 AWS CDK が開発中にルールセットを評価する能力は、検出速度と開発者の生産性を向上させるため、依然として役立ちます。

 AWS CDK ポリシー検証の目的は、開発中に必要なセットアップ量を最小限に抑え、可能な限り簡単にすることです。

**注記**  
以前の`Beta1`インターフェイス (`IPolicyValidationPluginBeta1`、、 の `PolicyValidationPluginReportBeta1``policyValidationBeta1`プロパティなど`Stage`) は、安定したサフィックスなしの同等のもの (、 など) `IPolicyValidationPlugin`に段階的に拡張されています`PolicyValidationPluginReport`。`Beta1` インターフェイスは廃止されましたが、引き続き機能します。検証プラグインを登録する推奨方法は、 `policyValidationBeta1`プロパティではなく `Validations` クラスを使用することです。

## アプリケーションデベロッパー向け
<a name="for-application-developers"></a>

### 検証プラグインの追加
<a name="adding-validation-plugins"></a>

アプリケーションで 1 つ以上の検証プラグインを使用するには、 `Validations` クラスを使用します。

```
import { Validations } from 'aws-cdk-lib';
import { CfnGuardValidator } from '@cdklabs/cdk-validator-cfnguard';

const app = new App();

// Add a validation plugin to the entire app
Validations.of(app).addPlugins(new CfnGuardValidator());

// Or add to a particular stage
const prodStage = new Stage(app, 'ProdStage');
Validations.of(prodStage).addPlugins(new CfnGuardValidator());
```

合成の直後、この方法で登録されたすべてのプラグインが呼び出され、定義したスコープで生成されたすべてのテンプレートが検証されます。特に、`App` オブジェクトにテンプレートを登録した場合、すべてのテンプレートが検証の対象となります。

**警告**  
クラウドアセンブリを変更する以外に、プラグインは AWS CDK アプリケーションができることは何でも実行できます。ファイルシステムからデータを読み取ったり、ネットワークにアクセスしたりすることなどができます。プラグインを安全に使用できることを確認することは、プラグインのコンシューマーとしてユーザーの責任です。

### 警告とエラーの追加
<a name="adding-warnings-and-errors"></a>

`Validations` クラスには、コンストラクトにカスタム警告とエラーを追加するメソッドも用意されています。

```
import { Validations } from 'aws-cdk-lib';

const bucket = new s3.Bucket(this, 'MyBucket');

// Add a warning
Validations.of(bucket).addWarning('MyWarningId', 'This bucket does not have versioning enabled');

// Add an error (will cause synthesis to fail)
Validations.of(bucket).addError('MyErrorId', 'This bucket must have encryption enabled');
```

### 警告の確認
<a name="acknowledging-warnings"></a>

特定の警告を抑制する場合は、 `acknowledge`メソッドを使用します。

```
import { Validations } from 'aws-cdk-lib';

Validations.of(myConstruct).acknowledge({ id: 'MyWarningId', reason: 'This is acceptable for our use case' });
```

`acknowledge` メソッドは、 `id`および を持つ`Acknowledgment`オブジェクトを受け入れます`reason`。は`::`区切り文字`id`を使用して、検証ソースプレフィックスをルール名 ( `annotation::MyWarning`や など`cdknag::AwsSolutions-S1`) から区切ります。なしでベア ID を指定すると`::`、`annotation::`プレフィックスが自動的に追加されます。

### AWS CloudFormation Guard プラグイン
<a name="cfnguard-plugin"></a>

[https://github.com/cdklabs/cdk-validator-cfnguard](https://github.com/cdklabs/cdk-validator-cfnguard) プラグインを使用すると、「[AWS CloudFormation Guard](https://github.com/aws-cloudformation/cloudformation-guard)」を使用してポリシーの検証を実行できます。`CfnGuardValidator` プラグインには、厳選された一連の「[AWS Control Tower プロアクティブコントロール](https://docs.aws.amazon.com/controltower/latest/userguide/proactive-controls.html)」が組み込まれています。現在のルールのセットは、「[プロジェクトドキュメント](https://github.com/cdklabs/cdk-validator-cfnguard/blob/main/README.md)」にあります。「[合成時のポリシー検証](#policy-validation)」で説明したように、組織は「[AWS CloudFormation フック](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks.html)」を使用してより権威的な検証方法を設定することをお勧めします。

「[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 」の顧客の場合、これらの同じプロアクティブコントロールは組織全体にデプロイできます。 AWS Control Tower 環境で AWS Control Tower プロアクティブコントロールを有効にすると、コントロールは AWS CloudFormation を介してデプロイされた非準拠リソースのデプロイを停止できます。マネージドプロアクティブコントロールとその仕組みの詳細については、「[AWS Control Tower キュメント](https://docs.aws.amazon.com/controltower/latest/userguide/proactive-controls.html)」を参照してください。

これらの AWS CDK バンドルコントロールとマネージド AWS Control Tower プロアクティブコントロールは、一緒に使用するのが最適です。このシナリオでは、 AWS Control Tower クラウド環境でアクティブなものと同じプロアクティブコントロールを使用して、この検証プラグインを設定できます。その後、`cdk synth`ローカルで実行することで、 AWS CDK アプリケーションが AWS Control Tower コントロールを渡すという信頼をすばやく得ることができます。

### 検証レポート
<a name="validation-report"></a>

 AWS CDK アプリを合成すると、検証プラグインが呼び出され、結果が出力されます。レポートの例が以下に示されています。

```
Validation Report (CfnGuardValidator)
-------------------------------------
(Summary)
╔═══════════╤════════════════════════╗
║ Status    │ failure                ║
╟───────────┼────────────────────────╢
║ Plugin    │ CfnGuardValidator      ║
╚═══════════╧════════════════════════╝
(Violations)
Ensure S3 Buckets are encrypted with a KMS CMK (1 occurrences)
Severity: medium
  Occurrences:

    - Construct Path: MyStack/MyCustomL3Construct/Bucket
    - Stack Template Path: ./cdk.out/MyStack.template.json
    - Creation Stack:
        └──  MyStack (MyStack)
             │ Library: aws-cdk-lib.Stack
             │ Library Version: 2.50.0
             │ Location: Object.<anonymous> (/home/johndoe/tmp/cdk-tmp-app/src/main.ts:25:20)
             └──  MyCustomL3Construct (MyStack/MyCustomL3Construct)
                  │ Library: N/A - (Local Construct)
                  │ Library Version: N/A
                  │ Location: new MyStack (/home/johndoe/tmp/cdk-tmp-app/src/main.ts:15:20)
                  └──  Bucket (MyStack/MyCustomL3Construct/Bucket)
                       │ Library: aws-cdk-lib/aws-s3.Bucket
                       │ Library Version: 2.50.0
                       │ Location: new MyCustomL3Construct (/home/johndoe/tmp/cdk-tmp-app/src/main.ts:9:20)
    - Resource Name: amzn-s3-demo-bucket
    - Locations:
      > BucketEncryption/ServerSideEncryptionConfiguration/0/ServerSideEncryptionByDefault/SSEAlgorithm
  Recommendation: Missing value for key `SSEAlgorithm` - must specify `aws:kms`
  How to fix:
    > Add to construct properties for `cdk-app/MyStack/Bucket`
      `encryption: BucketEncryption.KMS`

Validation failed. See above reports for details
```

デフォルトでは、レポートは人間が読み取れる形式で出力されます。JSON 形式のレポートが必要な場合、CLI を介して `@aws-cdk/core:validationReportJson` を使用して有効にするか、アプリケーションに直接渡します。

```
const app = new App({
  context: { '@aws-cdk/core:validationReportJson': true },
});
```

または、プロジェクトディレクトリ内の `cdk.json`または `cdk.context.json` ファイルを使用して、このコンテキストキーと値のペアを設定できます ([コンテキスト値と AWS CDK ](context.md)を参照）。

JSON 形式を選択すると、 AWS CDK はポリシー検証レポートをクラウドアセンブリディレクトリ`policy-validation-report.json`の というファイルに出力します。デフォルトの人間が読める形式の場合、レポートは標準出力で出力されます。

## プラグイン作成者向け
<a name="plugin-authors"></a>

### プラグイン
<a name="plugins"></a>

 AWS CDK コアフレームワークは、プラグインを登録して呼び出し、フォーマットされた検証レポートを表示する責任があります。プラグインの責任は、 AWS CDK フレームワークとポリシー検証ツール間の翻訳レイヤーとして機能することです。プラグインは、 AWS CDK でサポートされている任意の言語で作成できます。複数の言語で消費される可能性のあるプラグインを作成する場合は、JSII を使用して各 AWS CDK 言語にプラグインを発行`TypeScript`できるように、 でプラグインを作成することをお勧めします。

### プラグインの作成
<a name="creating-plugins"></a>

 AWS CDK コアモジュールとポリシーツール間の通信プロトコルは、 `IPolicyValidationPlugin`インターフェイスによって定義されます。新しいプラグインを作成するには、このインターフェイスを実装するクラスを記述する必要があります。実装する必要があるものは 2 つあり、プラグイン名 (`name` プロパティを上書きすることで実装) および `validate()` メソッドです。

フレームワークは `validate()` を呼び出し、`IPolicyValidationContext` オブジェクトを渡します。検証するテンプレートの場所は `templatePaths` によって指定されます。プラグインは `PolicyValidationPluginReport` のインスタンスを返します。このオブジェクトは、合成の最後にユーザーが受け取るレポートを表します。

```
validate(context: IPolicyValidationContext): PolicyValidationPluginReport {
  // First read the templates using context.templatePaths...
  // ...then perform the validation, and then compose and return the report.
  // Using hard-coded values here for better clarity:
  return {
    success: false,
    violations: [{
      ruleName: 'CKV_AWS_117',
      description: 'Ensure that AWS Lambda function is configured inside a VPC',
      fix: 'https://docs.bridgecrew.io/docs/ensure-that-aws-lambda-function-is-configured-inside-a-vpc-1',
      violatingResources: [{
        resourceName: 'MyFunction3BAA72D1',
        templatePath: '/home/johndoe/myapp/cdk.out/MyService.template.json',
        locations: 'Properties/VpcConfig',
      }],
    }],
  };
}
```

プラグインは、クラウドアセンブリのものを一切変更できないことに注意してください。変更しようとすると合成が失敗します。

プラグインが外部ツールに依存している場合、一部のデベロッパーがまだそのツールをワークステーションにインストールしていない場合があることに注意してください。わずらわしさを最小限に抑えるには、プロセス全体を自動化するため、プラグインパッケージと共にインストールスクリプトを提供することを強くお勧めします。さらに、パッケージのインストールの一環として、そのスクリプトを実行することをお勧めします。例えば、`npm` を使用すると、`package.json` ファイルの `postinstall`「[スクリプト](https://docs.npmjs.com/cli/v9/using-npm/scripts)」に追加できます。

### 適用除外の処理
<a name="handling-exemptions"></a>

組織に適用除外を処理するメカニズムがある場合、検証プラグインの一部として実装できます。

実現可能な適用除外メカニズムを説明するシナリオの例
+ 特定のシナリオ*を除き*、ある組織にはパブリック Amazon S3 バケットが許可されないというルールがあります。
+ デベロッパーはこれらのシナリオのいずれかに該当する Amazon S3 バケットを作成し、適用除外を要求します (チケットの作成など)。
+ セキュリティのツールは、適用除外を登録する内部システムから読み取る方法を知っています

このシナリオでは、デベロッパーは内部システムで例外を要求し、その例外を「登録」する方法が必要になります。ガードプラグインの例に追加すると、内部チケットシステムに一致する適用除外がある違反をフィルタリングすることにより、適用除外を処理するプラグインを作成できます。

実装例については、既存のプラグインを参照してください。
+  [@cdklabs/cdk-validator-cfnguard](https://github.com/cdklabs/cdk-validator-cfnguard) 