これは AWS CDK v2 デベロッパーガイドです。旧版の CDK v1 は 2022 年 6 月 1 日にメンテナンスを開始し、2023 年 6 月 1 日にサポートを終了しました。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS CDK セキュリティのベストプラクティス
AWS Cloud Development Kit (AWS CDK) は、開発者が AWS のサービスを設定し、AWS 上にインフラストラクチャをプロビジョニングするために使用できる強力なツールです。このような制御と機能を提供するツールを使用する場合、組織は、ツールが安全で安全な方法で使用されていることを確認するためのポリシーとプラクティスを確立する必要があります。たとえば、組織は、アカウントで設定されたコンプライアンスやコストコントロールの対策を改ざんできないように、特定のサービスへの開発者のアクセスを制限することが必要な場合があります。
多くの場合、セキュリティと生産性の間には緊張があり、各組織は適切なバランスを確立する必要があります。このトピックでは、独自のセキュリティポリシーを作成および実装する際に考慮できる、AWS CDK のセキュリティのベストプラクティスについて説明します。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションを説明するものではありません。これらのベストプラクティスはお客様の環境に適切ではないか、十分ではない場合があるため、これらは指示ではなく、有用な考慮事項と見なしてください。
## IAM セキュリティのベストプラクティス
AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスを安全に制御するためのウェブサービスです。組織、個人、AWS CDK は、AWS リソースに対し実行できるアクションを決定するアクセス許可を管理するために IAM を使用します。IAM を使用する場合は、IAM セキュリティのベストプラクティスに従ってください。詳細については、「*IAM ユーザーガイド*」の「[AWS Identity and Access Management のセキュリティのベストプラクティスとユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPracticesAndUseCases.html)」を参照してください。
## AWS CDK のアクセス許可を管理する
組織全体で AWS CDK を使用してインフラストラクチャを開発および管理する場合は、アクセス許可の管理が重要となるような、以下のシナリオを検討する必要があります。
+ **AWS CDK デプロイのアクセス許可** – これらのアクセス許可は、AWS リソースを変更できるユーザーと変更内容を決定します。
+ **リソース間のアクセス許可** - AWS CDK で作成および管理している AWS リソース間のインタラクションを許可するアクセス許可です。
### AWS CDK デプロイのアクセス許可を管理する
開発者は AWS CDK を使用して、開発マシン上のインフラストラクチャをローカルに定義します。このインフラストラクチャは、通常 AWS CDK コマンドラインインターフェイス (AWS CDK CLI) を使用するデプロイを通して AWS 環境に実装されます。デプロイでは、開発者が環境で実行できる変更を制御できます。たとえば、開発者に変更を加えさせたくない Amazon Virtual Private Cloud (Amazon VPC) リソースがあるとします。
デフォルトでは、CDK CLI はブートストラップ時に作成されたアクターのセキュリティ認証情報と IAM ロールを組み合わせて使用して、デプロイのアクセス許可を受け取ります。アクターのセキュリティ認証情報は、まず認証に使用され、その後 IAM ロールは、AWS CloudFormation サービスを使用してリソースを作成するなど、デプロイ中にさまざまなアクションを実行すると見なされます。使用されている IAM ロールなど、CDK デプロイの仕組みの詳細については、「[AWS CDK アプリケーションのデプロイ](deploy.md)」を参照してください。
デプロイを実行できるユーザーとデプロイ中に実行できるアクションを制限するには、次の点を考慮してください。
+ アクターのセキュリティ認証情報は、AWS への認証に使用される最初の認証情報セットです。ここから、デプロイ中にアクションを実行するために使用されるアクセス許可は、デプロイワークフロー中に引き受けられる IAM ロールに付与されます。これらのロールを引き受けることができるユーザーを制限することで、デプロイを実行できるユーザーを制限できます。これらの IAM ロールを独自のロールに置き換えることで、デプロイ中に実行できるアクションを制限することもできます。
+ デプロイを実行するアクセス許可は、`DeploymentActionRole` に付与されます。このロールを引き受けることができるユーザーを制限することで、デプロイを実行できるユーザーに対するアクセス許可を制御できます。ロールをデプロイに使用すると、ロールを別のアカウントの AWS ID に引き受けることができるため、クロスアカウントデプロイを実行できます。デフォルトでは、適切な `AssumeRole` ポリシーステートメントを持つ同じ AWS アカウント内のすべての ID が、このロールを引き受けることができます。
+ AWS CloudFormation を使用してリソースを作成および変更するためのアクセス許可は、`CloudFormationExecutionRole` に付与されます。このロールには、ブートストラップリソースから読み取るアクセス許可も必要です。CDK デプロイのアクセス許可を制御するには、`CloudFormationExecutionRole` にマネージドポリシーを使用し、必要に応じてアクセス許可の境界を設定します。デフォルトでは、このロールにはアクセス許可の境界がない `AdministratorAccess` アクセス許可があります。
+ ブートストラップリソースを操作するアクセス許可は、`FilePublishingRole` および `ImagePublishingRole` に付与されます。デプロイを実行するアクターには、これらのロールを引き受けるアクセス許可が必要です。デフォルトでは、適切な `AssumeRole` ポリシーステートメントを持つ同じ AWS アカウント内のすべての ID が、このロールを引き受けることができます。
+ 検索を実行するためにブートストラップリソースにアクセスするためのアクセス許可が `LookupRole` に付与されます。デプロイを実行するアクターには、このロールを引き受けるアクセス許可が必要です。デフォルトでは、このロールにはブートストラップリソースへの `readOnly` のアクセス許可があります。デフォルトでは、適切な `AssumeRole` ポリシーステートメントを持つ同じ AWS アカウント内のすべての ID が、このロールを引き受けることができます。
これらのロールを引き受けるアクセス許可を持つ AWS アカウントで IAM ID を設定するには、次のポリシーステートメントを持つポリシーを ID に追加します。
```
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "AssumeCDKRoles",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:ResourceTag/aws-cdk:bootstrap-role": [
"image-publishing",
"file-publishing",
"deploy",
"lookup"
]
}
}
}]
}
```
#### デプロイ中に引き受けるロールのアクセス許可を変更する
デプロイ中に引き受けるロールのアクセス許可を変更することで、デプロイ中に実行できるアクションを管理できます。アクセス許可を変更するには、独自の IAM ロールを作成し、環境をブートストラップするときに指定します。ブートストラップをカスタマイズするときは、合成をカスタマイズする必要があります。一般的な手順については、「[AWS CDK ブートストラップをカスタマイズする](bootstrapping-customizing.md)」を参照してください。
#### デプロイ中に使用されるセキュリティ認証情報とロールを変更する
デプロイ中に使用されるロールとブートストラップリソースは、使用する CDK スタックシンセサイザーによって決定されます。この動作を変更するには、合成をカスタマイズできます。詳細については、「[CDK スタック合成を設定して実行する](configure-synth.md)」を参照してください。
#### 最小特権アクセスを付与する際の考慮事項
最小特権アクセスを付与することは、セキュリティ戦略を開発する際に検討することをお勧めします。詳細については、「*AWS Well-Architected フレームワークガイド*」の「[SEC03-BP02 最小特権アクセスの付与](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_least_privileges.html)」を参照してください。
多くの場合、最小特権アクセスを付与する際は、特定のタスクの実行に必要な最小限のアクセスに IAM ポリシーを制限する必要があります。このアプローチを使用して CDK できめ細かなアクセス許可を介して最小特権アクセスを付与しようとすると、CDK のデプロイに影響が及び、意図するよりも広いスコープのアクセス許可を作成せざるを得なくなる可能性があります。このアプローチを使用する際に考慮すべき点を以下に示します。
+ 開発者が AWS CDK を使用して CloudFormation を介してインフラストラクチャをプロビジョニングできるようにする包括的なアクセス許可のリストを決定することは、困難で複雑です。
+ きめ細かな処理を行う場合、アクセス許可が長すぎて IAM ポリシードキュメントの最大長に収まらない場合があります。
+ アクセス許可のセットが不完全な場合、開発者の生産性とデプロイに重大な影響を与える可能性があります。
CDK では、デプロイは CloudFormation を使用して実行されます。CloudFormation は、提供されるアクセス許可を使用して、一連の AWS API コールを順番に開始します。任意の時点で必要なアクセス許可は、多くの要因によって異なります。
+ 変更対象となる AWS のサービス。具体的には、使用および変更されるリソースとプロパティ。
+ CloudFormation スタックの現在の状態。
+ デプロイ中やロールバックが必要な場合に発生する可能性のある問題。これには、`Create` に加えて `Delete` のアクセス許可が必要です。
提供されたアクセス許可が不完全である場合は、手動による介入が必要です。以下に、いくつかの例を示します。
+ ロールフォワード中に不完全なアクセス許可が見つかった場合は、デプロイを一時停止し、続行する前に新しいアクセス許可について話し合い、プロビジョニングする必要があります。
+ デプロイがロールバックされ、ロールバックを適用するアクセス許可がない場合、CloudFormation スタックは回復に多くの手動の作業が必要な状態になる可能性があります。
このアプローチは複雑化を引き起こし、開発者の生産性を大幅に制限するため、推奨しません。代わりに、ガードレールを実装し、バイパスを防ぐことをお勧めします。
#### ガードレールの実装とバイパスの防止
AWS Control Tower、AWS Config、AWS CloudTrail、AWS Security Hub などのサービスを使用して、ガードレール、コンプライアンスルール、監査、モニタリングを実装できます。このアプローチでは、既存の検証メカニズムの改ざんを除き、開発者にすべてを行うアクセス許可を付与します。開発者は、ポリシーの範囲内であれば、変更を迅速に実装できます。これは、AWS CDK を使用する際に推奨されるアプローチです。ガードレールの詳細については、「*Management and Governance Cloud Environment Guide*」の「[コントロール](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/controls.html)」を参照してください。
また、ガードレールを実装する方法として、*アクセス許可の境界*または*サービスコントロールポリシー (SCP)* を使用することをお勧めします。AWS CDK を使用してアクセス許可の境界を実装する方法の詳細については、「[AWS CDK のアクセス許可の境界を作成して適用する](customize-permissions-boundaries.md)」を参照してください。
コンプライアンス制御メカニズムを使用している場合は、ブートストラップフェーズ中にセットアップします。`CloudFormationExecutionRole` または開発者がアクセス可能な ID に、導入したメカニズムのバイパスを防ぐポリシーまたはアクセス許可の境界がアタッチされていることを確認します。適切なポリシーは、使用する特定のメカニズムによって異なります。
### AWS CDK によってプロビジョニングされたリソース間のアクセス許可を管理する
AWS CDK によってプロビジョニングされたリソース間のアクセス許可を管理する方法は、CDK がロールとポリシーを作成することを許可するかどうかによって異なります。
AWS コンストラクトライブラリの L2 コンストラクトを使用してインフラストラクチャを定義する場合、提供された `grant` メソッドを使用してリソース間のアクセス許可をプロビジョニングできます。`grant` メソッドでは、リソース間で必要なアクセスのタイプを指定すると、AWS CDK が目的を達成するために最小特権の IAM ロールをプロビジョニングします。このアプローチは、開発者にとって効率的であると同時に、ほとんどの組織のセキュリティ要件を満たします。詳細については、「[AWS CDK を使用して L2 コンストラクトのアクセス許可を定義する](define-iam-l2.md)」を参照してください。
自動生成されたロールを手動で作成されたロールに置き換えてこの機能を回避する場合は、次の点を考慮してください。
+ IAM ロールは手動で作成する必要があり、アプリケーション開発が遅くなります。
+ IAM ロールを手動で作成して管理する必要がある場合、多くの場合、管理しやすくするために複数の論理ロールが 1 つのロールに結合されます。これは最小特権の原則に反しています。
+ これらのロールはデプロイ前に作成する必要があるため、参照する必要があるリソースはまだ存在しません。したがって、ワイルドカードを使用する必要がありますが、これは最小特権の原則に反しています。
+ ワイルドカードの使用に対する一般的な回避策は、すべてのリソースに予測可能な名前を付けることを義務付けることです。ただし、これにより、CloudFormation が必要に応じてリソースを置き換える機能が妨げられ、開発が遅くなったり、ブロックされたりする可能性があります。このため、CloudFormation が一意のリソース名を作成することを許可することをお勧めします。
+ 手動アクションはすべてのデプロイの前に実行する必要があるため、継続的な配信を実行することはできません。
組織が CDK によるロールの作成を防止したい場合、通常それは開発者が IAM ロールを作成できないようにすることが目的です。懸念されるのは、AWS CDK を使用して IAM ロールを作成するアクセス許可を開発者に付与することで、自分の権限を昇格できる可能性があることです。これに対策するには、*アクセス許可の境界*または*サービスコントロールポリシー (SCP)* を使用することをおすすめします。アクセス許可の境界では、開発者と CDK が実行できる制限を設定できます。CDK を使用してアクセス許可の境界を使用する方法の詳細については、「[AWS CDK のアクセス許可の境界を作成して適用する](customize-permissions-boundaries.md)」を参照してください。