# 「CloudFormation」 のセキュリティ
AWS でのクラウドセキュリティは最優先事項です。AWS のユーザーは、セキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャを利用できます。
セキュリティは、AWS とユーザーの間の責任共有です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、これをクラウド*の*セキュリティおよびクラウド*内*のセキュリティと説明しています。
+ **クラウドのセキュリティ** - AWS はAWS Cloud で AWS のサービスを実行するインフラストラクチャを保護する責任を負います。また、AWS は使用するサービスを安全に提供します。[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの監査が定期的にセキュリティの有効性をテストおよび検証しています。CloudFormation に適用するコンプライアンスプログラムの詳細については、「[コンプライアンスプログラムによる対象範囲内の AWS のサービス](https://aws.amazon.com/compliance/services-in-scope/)」「」を参照してください。
+ **クラウド内のセキュリティ** - ユーザーの責任は、使用する AWS のサービスに応じて異なります。また、お客様は、データの機密性、お客様の会社の要件、および適用される法律および規制など、その他の要因についても責任を負います。
このドキュメントは、CloudFormation を使用する際に責任共有モデルを適用する方法を理解するのに役立ちます。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成するために CloudFormation を設定する方法を示します。また、CloudFormation リソースのモニタリングや保護に役立つ、その他 AWS サービスの使用方法についても説明します。
**Topics**
+ [CloudFormation スタックの削除を防止する](using-cfn-protect-stacks.md)
+ [スタックのリソースが更新されないようにする](protect-stack-resources.md)
+ [CloudFormation でのデータ保護](security-data-protection.md)
+ [AWS Identity and Access Management で CloudFormation アクセスを制御する](control-access-with-iam.md)
+ [AWS CloudTrail による CloudFormation API コールのログ記録](cfn-api-logging-cloudtrail.md)
+ [CloudFormation 内のインフラストラクチャセキュリティ](infrastructure-security.md)
+ [CloudFormation での耐障害性](disaster-recovery-resiliency.md)
+ [のコンプライアンス検証CloudFormation](cloudformation-compliance.md)
+ [CloudFormation での構成と脆弱性の分析](vulnerability-analysis-and-management.md)
+ [CloudFormation のセキュリティのベストプラクティス](security-best-practices.md)
+ [インターフェイスエンドポイントを使用した CloudFormation へのアクセス (AWS PrivateLink)](vpc-interface-endpoints.md)
# CloudFormation スタックの削除を防止する
スタックの削除保護を有効にして、スタックが誤って削除されるのを防ぐことができます。削除保護を有効にした状態でスタックを削除しようとすると、削除は失敗し、ステータスを含め、スタックが変更されることはありません。終了保護は、スタック作成時に有効にすることができます。デフォルトでは、スタックの削除保護は無効です。スタックの削除保護は、任意のステータスで設定できます ([`DELETE_IN_PROGRESS`] または [`DELETE_COMPLETE`] を除く)。
スタックで削除保護を有効または無効にすると、そのスタックに属するネストされたスタックにも同じ選択が適用されます。ネストされたスタックの削除保護を直接有効または無効にすることはできません。削除保護が有効になっているスタックに属するネストされたスタックを直接削除しようとすると、そのオペレーションは失敗し、ネストされたスタックは変更されません。
ただし、ネストされたスタックが削除されるスタック更新を行うと、CloudFormation は状況に応じて、ネストされたスタックを削除します。
削除保護は、ロールバックの無効化とは異なります。削除保護がスタックの削除の試行に適用されるのに対し、ロールバックの無効化は、スタックの作成に失敗した際の自動ロールバックに適用されます。
**スタック作成時に削除保護を有効にするには**
**[Create stack]** (スタックの作成) ウィザードの **[Specify stack options]** (スタックオプションの指定) ページの **[Advanced options]** (詳細オプション) で、**[Termination Protection]** (削除保護) セクションを展開し、**[Enable]** (有効化) を選択します。詳細については、「[スタックオプションを設定する](cfn-console-create-stack.md#configure-stack-options)」を参照してください。
**既存のスタックの削除保護を有効または無効にするには**
1. AWS マネジメントコンソール にサインインし、CloudFormation コンソール ([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/)) を開きます。
1. 画面上部にあるナビゲーションバーで、AWS リージョン を選択します。
1. 変更するスタックを選択します。
**注記**
スタック名の横に [**ネスト**] と表示されている場合、そのスタックは、ネストされたスタックです。ネストされたスタックが属するルートスタックの削除保護のみ変更することができます。
1. スタックの詳細ペインで、[**Stack actions (スタックアクション)**]、[**Edit termination protection (削除保護の編集)**] の順に選択します。
CloudFormation によって、[**Edit termination protection**] (削除保護の編集) ダイアログボックスが表示されます。
1. [**有効化**] または [**無効化**] を選択し、[**保存**] を選択します。
**ネストされたスタックの削除保護を有効または無効にするには**
スタック名の横に [**ネスト**] と表示されている場合、そのスタックは、ネストされたスタックです。ネストされたスタックが属するルートスタックの削除保護のみ変更することができます。ルートスタックの削除保護を変更するには
1. AWS マネジメントコンソール にサインインし、CloudFormation コンソール ([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/)) を開きます。
1. 画面上部にあるナビゲーションバーで、AWS リージョン を選択します。
1. 変更するネストされたスタックを選択します。
1. [**Stack info (スタック情報)**] ペインの [**概要**] セクションで、[**ルートスタック**] としてリストされているスタック名を選択します。
CloudFormation により、ルートスタックのスタックの詳細が表示されます。
1. [**Stack actions (スタックアクション)**]を選択し、[**Edit Termination Protection (削除保護の編集)**] を選択します。
CloudFormation によって、[**Edit termination protection**] (削除保護の編集) ダイアログボックスが表示されます。
1. [**有効化**] または [**無効化**] を選択し、[**保存**] を選択します。
**コマンドラインを使用して終了保護を有効または無効にするには**
[https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-termination-protection.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-termination-protection.html) コマンドを使用します。
## スタックの削除保護を変更するユーザーの制御
スタックの削除保護を有効または無効にするには、`cloudformation:UpdateTerminationProtection` アクションの権限が必要です。たとえば、以下のポリシーでは、ユーザーは、スタックの削除保護を有効または無効にすることができます。
CloudFormation でアクセス許可を指定する方法については、「[AWS Identity and Access Management で CloudFormation アクセスを制御する](control-access-with-iam.md)」を参照してください。
**Example スタックの削除保護を変更するアクセス許可を付与するサンプルポリシー。**
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action":[
"cloudformation:UpdateTerminationProtection"
],
"Resource":"*"
}]
}
```
# スタックのリソースが更新されないようにする
スタックを作成するとき、すべてのリソースですべての更新アクションが許可されます。デフォルトでは、スタック更新アクセス権限を持つユーザーであれば誰でもスタック内のすべてのリソースを更新できます。更新処理中、リソースの中断や完全な置き換えが必要になった場合は、新しい物理 ID やまったく新しいストレージが使用される結果になります。スタックポリシーを使用すると、スタックの更新中にスタックのリソースが意図せずに更新または削除されるのを防止できます。スタックポリシーは、指定したリソースに対して実行できる更新アクションを定義する JSON ドキュメントです。
スタックポリシーを設定すると、デフォルトでスタック内のすべてのリソースが保護されます。特定のリソースでの更新を許可するには、スタックポリシーでこれらのリソースに対して `Allow` ステートメントを明示的に指定します。1 つのスタックに定義できるスタックポリシーは 1 つのみですが、1 つのポリシー内で複数のリソースを保護することができます。スタックポリシーは、スタックの更新を試みるすべての CloudFormation ユーザーに適用されます。異なるスタックポリシーを異なるユーザーに関連付けることはできません。
スタックポリシーは、スタックの更新時のみ適用されます。AWS Identity and Access Management (IAM) ポリシーのようなアクセスコントロールは提供しません。特定のスタックリソースを誤って更新しないように、スタックポリシーはフェイルセーフメカニズムとしてのみ使用してください。AWS リソースまたはアクションへのアクセスを制御するには、IAM を使用します。
**Topics**
+ [スタックポリシーの例](#stack-policy-intro-example)
+ [スタックポリシーの定義](#stack-policy-reference)
+ [スタックポリシーの設定](#protect-stack-resources-protecting)
+ [保護されたリソースの更新](#protect-stack-resources-updating)
+ [スタックポリシーの変更](#protect-stack-resources-modifying)
+ [スタックポリシーのその他の例](#stack-policy-samples)
## スタックポリシーの例
次のスタックポリシーの例は、`ProductionDatabase` リソースの更新が禁止されます。
```
{
"Statement" : [
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
},
{
"Effect" : "Deny",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "LogicalResourceId/ProductionDatabase"
}
]
}
```
スタックポリシーを設定すると、デフォルトですべてのリソースが保護されます。すべてのリソースの更新を許可するには、すべてのリソースですべてのアクションを許可する `Allow` ステートメントを追加します。`Allow` ステートメントではすべてのリソースが指定されますが、`ProductionDatabase` 論理 ID を持つリソースに関しては明示的な `Deny` ステートメントが優先されます。この `Deny` ステートメントにより、置き換えや削除など、すべての更新アクションが `ProductionDatabase` リソースで禁止されます。
`Principal` 要素が必要ですが、ワイルドカード (`*`) のみサポートされています。つまり、ステートメントはすべての[プリンシパル](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#principal)に適用されます。
**注記**
スタックの更新中、CloudFormation は、更新された他のリソースに依存するリソースを自動的に更新します。例えば、CloudFormation は、更新されたリソースを参照するリソースを更新します。CloudFormation は自動的に更新されたリソースに物理的な変更 (リソースの ID など) は行いませんが、これらのリソースにスタックポリシーが関連付けられている場合は、リソースを更新する許可が必要になります。
## スタックポリシーの定義
スタックを作成するとき、スタックポリシーは設定されないため、すべてのリソースですべての更新アクションが許可されます。スタックリソースを更新アクションから保護するには、スタックポリシーを定義し、そのポリシーをスタックに設定します。スタックポリシーは JSON ドキュメントで、CloudFormation ユーザーが実行できる CloudFormation スタック更新アクションと、そのアクションが適用されるリソースを定義します。スタックポリシーを含むテキストファイルを指定するか、入力することにより、スタックの作成時にスタックポリシーを設定します。スタックにスタックポリシーを設定した場合、明示的に許可されていないすべての更新がデフォルトで拒否されます。
スタックポリシーは、`Effect`、`Action`、`Principal`、`Resource`、`Condition` の 5 つの要素によって定義します。スタックポリシーの構文を次の擬似コードに示します。
```
{
"Statement" : [
{
"Effect" : "Deny_or_Allow",
"Action" : "update_actions",
"Principal" : "*",
"Resource" : "LogicalResourceId/resource_logical_ID",
"Condition" : {
"StringEquals_or_StringLike" : {
"ResourceType" : [resource_type, ...]
}
}
}
]
}
```
`Effect`
指定されたリソースでの指定されたアクションを拒否するかまたは許可するかを決定します。`Deny` または `Allow` のみ指定できます ( など)。
```
"Effect" : "Deny"
```
スタックポリシーに重複ステートメントが含まれる場合 (リソースでの更新を許可するステートメントと拒否するステートメントの両方)、常に `Deny` ステートメントが `Allow` ステートメントより優先されます。リソースが必ず保護されるようにするには、そのリソースに対して `Deny` ステートメントを使用します。
Action
拒否または許可する更新アクションを指定します。
Update:Modify
変更の適用中にリソースで中断が発生しない更新アクションまたはなんらかの中断が発生する更新アクションを指定します。すべてのリソースで物理 ID が保持されます。
Update:Replace
リソースが再作成される更新アクションを指定します。CloudFormation は、指定された更新を使用して新しいリソースを作成してから、古いリソースを削除します。リソースが再作成されるため、新しいリソースの物理 ID が変更される場合があります。
Update:Delete
リソースが削除される更新アクションを指定します。スタックテンプレートから完全にリソースを削除する更新の場合は、このアクションを使用する必要があります。
更新:\$1
すべての更新アクションを指定します。アスタリスクは、すべての更新アクションを表すワイルドカードです。
次の例では、replace アクションと delete アクションのみを指定しています。
```
"Action" : ["Update:Replace", "Update:Delete"]
```
1 つのアクションを除くすべての更新アクションを許可するには、`NotAction` を使用します。たとえば、`Update:Delete` を除くすべての更新アクションを許可するには、次の例に示すように `NotAction` を使用します。
```
{
"Statement" : [
{
"Effect" : "Allow",
"NotAction" : "Update:Delete",
"Principal": "*",
"Resource" : "*"
}
]
}
```
Principal
`Principal` 要素は、ポリシーを適用するエンティティを指定します。この要素は必須ですが、ワイルドカード (`*`) のみサポートされています。つまり、ポリシーはすべての[プリンシパル](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#principal)に適用されます。
リソース
ポリシーを適用するリソースの論理 ID を指定します。リソースのタイプを指定するには、`Condition` 要素を使用します。
1 つのリソースを指定するには、論理 ID を使用します。例:
```
"Resource" : ["LogicalResourceId/myEC2instance"]
```
論理 ID には、ワイルドカードを使用できます。たとえば、すべての関連リソースに共通の論理 ID プレフィックスを使用している場合、ワイルドカードを使用してすべてのリソースを指定できます。
```
"Resource" : ["LogicalResourceId/CriticalResource*"]
```
これらのリソースに対して `Not` 要素を使用することもできます。たとえば、1 つを除くすべてのリソースに対する更新を許可するには、`NotResource` 要素を使用してそのリソースを保護します。
```
{
"Statement" : [
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"NotResource" : "LogicalResourceId/ProductionDatabase"
}
]
}
```
スタックポリシーを設定した場合、明示的に許可されていないすべての更新が拒否されます。`ProductionDatabase` リソース以外のリソースに対する更新をすべて許可することで、`ProductionDatabase` リソースに対する更新を拒否します。
条件
ポリシーを適用するリソースタイプを指定します。論理 ID を指定するには、`Resource` 要素を使用します。
次の例に示すように、EC2 インスタンスや RDS DB インスタンスのようなリソースタイプを指定できます。
```
{
"Statement" : [
{
"Effect" : "Deny",
"Principal" : "*",
"Action" : "Update:*",
"Resource" : "*",
"Condition" : {
"StringEquals" : {
"ResourceType" : ["AWS::EC2::Instance", "AWS::RDS::DBInstance"]
}
}
},
{
"Effect" : "Allow",
"Principal" : "*",
"Action" : "Update:*",
"Resource" : "*"
}
]
}
```
`Allow` ステートメントはすべてのリソースに更新アクセス権限を付与し、`Deny` ステートメントは EC2 および RDS DB インスタンスに対する更新を拒否します。`Deny` ステートメントは、すべてのアクションを常にオーバーライドします。
リソースタイプでワイルドカードを使用できます。たとえば、次の例に示すように、ワイルドカードを使用して、すべての Amazon EC2 リソース (— インスタンス、セキュリティグループ、サブネット— など) に対する更新アクセス許可を拒否できます。
```
"Condition" : {
"StringLike" : {
"ResourceType" : ["AWS::EC2::*"]
}
}
```
ワイルドカードを使用する場合は、`StringLike` 条件を使用する必要があります。
## スタックポリシーの設定
スタックを作成する際にスタックのポリシーを適用するには、コンソールまたは AWS CLI を使用します。AWS CLI を使用して、既存のスタックにスタックポリシーを適用することもできます。スタックのポリシーを適用すると、スタックからそれを削除することはできません。ただし、AWS CLI を使用して変更することはできます。
スタックポリシーは、スタックの更新を試みるすべての CloudFormation ユーザーに適用されます。異なるスタックポリシーを異なるユーザーに関連付けることはできません。
ポリシーの記述方法については、「[スタックポリシーの定義](#stack-policy-reference)」を参照してください。
**スタックの作成時にスタックポリシーを設定するには (コンソール)**
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. 画面の上部のナビゲーションバーで、スタックを作成する AWS リージョンを選択します。
1. [**CloudFormation Stacks**] ページで、[**スタックの作成**] を選択します。
1. [スタックの作成] ウィザードの [**Configure stack options (スタックオプションの設定)**] ページで、[**詳細設定**] セクションを展開し、[**スタックのポリシー**] を選択します。
1. 次のようにスタックポリシーを指定します。
+ コンソールにポリシーを直接作成するには、[**Enter stack policy (スタックポリシーの入力)**] を選択し、テキストフィールドにスタックポリシーを直接入力します。
+ 別のファイルで定義されたポリシーを使用するには、[**ファイルのアップロード**] を選択し、[**ファイルの選択**] を選択して、スタックポリシーを含むファイルを選択します。
**スタックの作成時にスタックポリシーを設定するには (AWS CLI)**
+ [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack.html) コマンドを使用する際、`--stack-policy-body` オプションを使用して変更されたポリシーを入力するか、`--stack-policy-url` オプションを使用してポリシーを含むファイルを指定します。
**既存のスタックでスタックポリシーを設定するには (AWS CLI のみ)**
+ [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/set-stack-policy.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/set-stack-policy.html) コマンドを使用する際、`--stack-policy-body` オプションを使用して変更されたポリシーを入力するか、`--stack-policy-url` オプションを使用してポリシーを含むファイルを指定します。
**注記**
既存のスタックにポリシーを追加するには、CloudFormation の [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html) アクションに対する許可が必要です。
## 保護されたリソースの更新
保護されたリソースを更新するには、スタックポリシーをオーバーライドする一時ポリシーを作成し、それらのリソースでの更新を許可します。スタックを更新するときにオーバーライドポリシーを指定します。オーバーライドポリシーによって、スタックポリシーが永続的に変更されるわけではありません。
保護されたリソースを更新するには、CloudFormation の [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html) アクションを使用する許可が必要です。CloudFormation 許可の設定については、「[AWS Identity and Access Management で CloudFormation アクセスを制御する](control-access-with-iam.md)」を参照してください。
**注記**
スタックの更新中、CloudFormation は、更新された他のリソースに依存するリソースを自動的に更新します。例えば、CloudFormation は、更新されたリソースを参照するリソースを更新します。CloudFormation は自動的に更新されたリソースに物理的な変更 (リソースの ID など) は行いませんが、これらのリソースにスタックポリシーが関連付けられている場合は、リソースを更新する許可が必要になります。
**保護されたリソースを更新するには (コンソール)**
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. 更新するスタックを選択し、[**Stack actions (スタックアクション)**]、[**スタックの更新**] の順に選択します。
1. スタックテンプレートを*変更していない*場合は、[**現在のテンプレートの使用**] を選択し、[**次へ**] をクリックします。テンプレートを変更した場合は、[**Replace current template (現在のテンプレートを置換)**] を選択し、[**Specify template (テンプレートの指定)**] セクションで更新されたテンプレートの場所を指定します。
+ ローカルコンピュータに保存されているテンプレートの場合は、[**テンプレートファイルをアップロード**] を選択します。[**ファイルの選択**] を選択してファイルの場所に移動し、ファイルを選択して、[**次へ**] をクリックします。
+ Amazon S3 バケットに保存されているテンプレートの場合は、[**Amazon S3 URL**] を選択します。テンプレートの URL を入力するか貼り付けて、[**次へ**] をクリックします。
バージョニング対応バケットにテンプレートがある場合、URL に `?versionId=version-id` を付加することによってテンプレートの具体的なバージョンを指定できます。詳細については、「*Amazon Simple Storage Service ユーザーガイド*」の「[バージョニングが有効なバケット内のオブジェクトの使用](https://docs.aws.amazon.com/AmazonS3/latest/userguide/manage-objects-versioned-bucket.html)」を参照してください。
1. テンプレートにパラメータが含まれている場合、[**Specify stack details (スタックの詳細を指定)**] ページで、パラメータ値を入力または変更し、[**次へ**] を選択します。
CloudFormation は、スタックで現在設定されている値を各パラメータに入力します (`NoEcho` 属性で宣言されたパラメータを除く)。[**既存の値の使用**] を選択することで、それらのパラメータに現在の値を使用できます。
`NoEcho` を使用して機密情報をマスクする方法、また動的なパラメータを使用してシークレットを管理する方法の詳細については、「[テンプレートに認証情報を埋め込まない](security-best-practices.md#creds)」ベストプラクティスを参照してください。
1. オーバーライドスタックポリシーを指定します。
1. [**Configure stack options (スタックオプションの設定)**] ページの [**詳細オプション**] セクションで、[**スタックのポリシー**] を選択します。
1. [**ファイルのアップロード**] を選択します。
1. [**ファイルの選択**] をクリックし、オーバーライドする側のスタックポリシーを含むファイルに移動するか、ポリシーを入力します。
1. [**次へ**] を選択します。
オーバーライドポリシーでは、更新する保護されたリソースを対象として `Allow` ステートメントを指定する必要があります。たとえば、すべての保護されたリソースを更新するには、すべての更新を許可する一時オーバーライドポリシーを指定します。
```
{
"Statement" : [
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
**注記**
CloudFormation がオーバーライドポリシーを適用するのは、この更新の実行中のみです。オーバーライドポリシーによって、スタックポリシーが永続的に変更されるわけではありません。スタックのポリシーを変更するには、「[スタックポリシーの変更](#protect-stack-resources-modifying)」を参照してください。
1. 送信したスタック情報と変更を確認します。
パラメータ値やテンプレートの URL が適切かなど、正しい情報を送信したことを確認します。テンプレートに IAM リソースが含まれる場合は、[**I acknowledge that this template may create IAM resources (このテンプレートが IAM リソースを作成する可能性を認識しています)**] を選択して、テンプレート内の IAM リソースを使用することを指定します。詳細については、「[CloudFormation テンプレートでの IAM リソースの承認](control-access-with-iam.md#using-iam-capabilities)」を参照してください。
**[変更のプレビュー]** セクションで、期待される変更のすべてを CloudFormation が実行することを確認します。例えば、追加、削除、または変更する予定のリソースを、CloudFormation が追加、削除、および変更することを確認します。CloudFormation は、スタックの変更セットを作成することによって、このプレビューを生成します。詳細については、「[変更セットを使用して CloudFormation スタックを更新する](using-cfn-updating-stacks-changesets.md)」を参照してください。
1. 変更内容が適切であることを確認できたら、[**更新**] をクリックします。
**注記**
この時点で、変更セットを表示するオプションを使用すると、提案された更新をより徹底的に確認することもできます。これを行うには、**[Update]** (更新) の代わりに **[View change set]** (変更セットを表示) をクリックしてください。CloudFormation により、更新に基づいて生成された変更セットが表示されます。スタックの更新を実行する準備ができたら、[**実行**] をクリックします。
CloudFormation により、スタックの [**Stack details (スタックの詳細)**] ページが表示されます。これで、スタックのステータスは `UPDATE_IN_PROGRESS` になりました。CloudFormation によるスタックの更新が正常に完了したら、スタックの状況が `UPDATE_COMPLETE` に設定されます。
スタックの更新が失敗した場合、CloudFormation によって変更が自動的にロールバックされ、スタックの状況が `UPDATE_ROLLBACK_COMPLETE` に設定されます。
**保護されたリソースを更新するには (AWS CLI)**
+ [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-stack.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-stack.html) コマンドを使用する際、`--stack-policy-during-update-body` オプションを使用して変更されたポリシーを入力するか、`--stack-policy-during-update-url` オプションを使用してポリシーを含むファイルを指定します。
**注記**
CloudFormation がオーバーライドポリシーを適用するのは、この更新の実行中のみです。オーバーライドポリシーによって、スタックポリシーが永続的に変更されるわけではありません。スタックのポリシーを変更するには、「[スタックポリシーの変更](#protect-stack-resources-modifying)」を参照してください。
## スタックポリシーの変更
追加のリソースを保護するか、リソースから保護を削除するには、スタックポリシーを変更します。たとえば、保護するデータベースをスタックに追加するときは、そのデータベースの `Deny` ステートメントをスタックポリシーに追加します。ポリシーを変更するには、[https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_SetStackPolicy.html) アクションを使用するアクセス許可が必要です。
AWS CLI を使用して、スタックポリシーを変更します。
**スタックポリシーを変更するには (AWS CLI)**
+ [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/set-stack-policy.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/set-stack-policy.html) コマンドを使用する際、`--stack-policy-body` オプションを使用して変更されたポリシーを入力するか、`--stack-policy-url` オプションを使用してポリシーを含むファイルを指定します。
スタックポリシーは削除できません。すべてのリソースからすべて保護を削除するには、すべてのリソースに対するすべてのアクションを明示的に許可するようにポリシーを変更します。次のポリシーは、すべてのリソースですべての更新を許可します。
```
{
"Statement" : [
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
## スタックポリシーのその他の例
次のポリシー例では、すべてのスタックリソースの更新を禁止する方法、特定のリソースの更新を禁止する方法、特定のタイプの更新を禁止する方法を示します。
### すべてのスタックリソースの更新を禁止する
すべてのスタックリソースの更新を禁止するため、次のポリシーでは、すべてのリソースのすべての更新アクションに対して `Deny` ステートメントを指定しています。
```
{
"Statement" : [
{
"Effect" : "Deny",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
### 1 つのリソースの更新を禁止する
次のポリシーでは、`MyDatabase` という論理 ID を持つデータベースについて、すべての更新アクションを拒否します。また、`Allow` ステートメントにより、他のすべてのスタックリソースにおいてすべての更新アクションを許可します。`Deny` ステートメントは常に許可アクションをオーバーライドするため、`Allow` ステートメントは `MyDatabase` リソースには適用されません。
```
{
"Statement" : [
{
"Effect" : "Deny",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "LogicalResourceId/MyDatabase"
},
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
デフォルト拒否を使用することで、前の例と同じ結果が得られます。スタックポリシーを設定すると、CloudFormation は明示的に許可されていない更新をすべて拒否します。次のポリシーでは、デフォルトで拒否されている `ProductionDatabase` リソースを除くすべてのリソースの更新が許可されます。
```
{
"Statement" : [
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"NotResource" : "LogicalResourceId/ProductionDatabase"
}
]
}
```
**重要**
デフォルト拒否の使用にはリスクがあります。ポリシーの他の場所で `Allow` ステートメントを使用している場合 (ワイルドカードを使用する `Allow` ステートメントなど)、知らないうちに意図しないリソースに更新アクセス権限を付与する可能性があります。ただし、明示的な拒否はすべての許可アクションをオーバーライドするため、`Deny` ステートメントを使用することでリソースが保護されることを保証できます。
### 特定のリソースタイプについてすべてのインスタンスの更新を禁止する
次のポリシーは、RDS DB インスタンスリソースタイプについて、すべての更新アクションを拒否します。また、`Allow` ステートメントにより、他のすべてのスタックリソースにおいてすべての更新アクションを許可します。`Allow` ステートメントは常に許可アクションをオーバーライドするため、`Deny` ステートメントは RDS DB インスタンスリソースには適用されません。
```
{
"Statement" : [
{
"Effect" : "Deny",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*",
"Condition" : {
"StringEquals" : {
"ResourceType" : ["AWS::RDS::DBInstance"]
}
}
},
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
### 特定のインスタンスについて置き換え更新を防止する
次のポリシーは、`MyInstance` という論理 ID を持つインスタンスの置き換えが発生する更新を拒否します。また、`Allow` ステートメントにより、他のすべてのスタックリソースにおいてすべての更新アクションを許可します。`Deny` ステートメントは常に許可アクションをオーバーライドするため、`Allow` ステートメントは `MyInstance` リソースには適用されません。
```
{
"Statement" : [
{
"Effect" : "Deny",
"Action" : "Update:Replace",
"Principal": "*",
"Resource" : "LogicalResourceId/MyInstance"
},
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
### ネストされたスタックの更新を禁止する
以下のポリシーは、CloudFormation スタックリソースタイプ (ネストされたスタック) でのすべての更新アクションを拒否します。また、`Allow` ステートメントにより、他のすべてのスタックリソースにおいてすべての更新アクションを許可します。`Deny` ステートメントは常に許可アクションを上書きするため、CloudFormation リソースに `Allow` ステートメントは適用されません。
```
{
"Statement" : [
{
"Effect" : "Deny",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*",
"Condition" : {
"StringEquals" : {
"ResourceType" : ["AWS::CloudFormation::Stack"]
}
}
},
{
"Effect" : "Allow",
"Action" : "Update:*",
"Principal": "*",
"Resource" : "*"
}
]
}
```
# CloudFormation でのデータ保護
AWS[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/) は、AWS CloudFormation でのデータ保護に適用されます。このモデルで説明されているように、AWS は、AWS クラウド のすべてを実行するグローバルインフラストラクチャを保護するがあります。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「AWS のサービス」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された [AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) のブログ記事を参照してください。
データを保護するため、「AWS アカウント」 認証情報を保護し、「AWS IAM アイデンティティセンター」 または 「AWS Identity and Access Management」 (IAM) を使用して個々のユーザーをセットアップすることをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して 「AWS」 リソースと通信します。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ AWS CloudTrail で API とユーザーアクティビティロギングを設定します。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「*AWS CloudTrail ユーザーガイド*」の「[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+ AWS のサービス 内のすべてのデフォルトセキュリティコントロールに加え、AWS 暗号化ソリューションを使用します。
+ Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API を使用して 「AWS」 にアクセスする際に FIPS 140-3 検証済みの暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これは、コンソール、API、AWS CLI、または AWS SDK で CloudFormation または他の AWS のサービス を使用する場合も同様です。タグ、または名前に使用される自由形式のテキストフィールドに入力されるデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
## 保管中の暗号化
AWS の責任共有モデルに従って、CloudFormation は保存時に暗号化されたデータを保存します。アカウントに保存されているデータの暗号化ポリシーとストレージポリシーを設定するのは顧客の責任です。たとえば、S3 バケットまたは SNS トピックに保存されているテンプレートやその他のデータについては、保存時の暗号化を有効にすることをお勧めします。同様に、顧客は CloudFormation によってプロビジョニングされるデータストレージシステムの暗号化設定を定義します。
## 送信中の暗号化
CloudFormation は、責任共有モデルに基づくサービス通信に暗号化されたチャネルを使用します。
## インターネットトラフィックのプライバシー
CloudFormation サービス通信は、デフォルトでリージョンまたはアベイラビリティーゾーン間で安全に暗号化されます。
# AWS Identity and Access Management で CloudFormation アクセスを制御する
AWS Identity and Access Management (IAM) を使えば、IAM ユーザーを作成して、AWS アカウント の特定のリソースへの、各ユーザーのアクセスを制御することができます。IAM を使用すると、スタックテンプレートの表示、スタックの作成、スタックの削除など、ユーザーが CloudFormation で実行できるアクションを制御できます。
CloudFormation の特定のアクションに加えて、各ユーザーが利用できる AWS サービスおよびリソースを管理できます。この方法で、ユーザーが CloudFormation の使用時にアクセスできるリソースを管理できます。たとえば、Amazon EC2 インスタンスを作成できるユーザー、データベースインスタンスを終了できるユーザ、または VPC を更新できるユーザを指定できます。CloudFormation を使用してそれらのアクションを実行するときは、いつでも同じアクセス許可が適用されます。
CloudFormation にアクセスできるユーザーを制御するときは、次のセクションの情報を使用します。また、テンプレートでの IAM リソースの作成を承認する方法、EC2 インスタンスで実行中のアプリケーションに必要なアクセス許可を付与する方法、AWS 環境のセキュリティ強化のために一時的なセキュリティ認証情報を使用する方法についても説明します。
## CloudFormation の IAM アイデンティティベースのポリシーの定義
CloudFormation へのアクセスを許可するには、必要な API アクションを呼び出すためのアクセス許可を、IAM アイデンティティ (ユーザーやロールなど) に付与する IAM ポリシーを作成し、これを割り当てる必要があります。
IAM アイデンティティベースポリシーでは、許可または拒否するアクションとリソース、またアクションを許可または拒否する条件を指定できます。CloudFormation は、特定のアクション、リソース、条件キーをサポートしています。
IAM を初めて使用する場合は、まず IAM JSON ポリシーの要素を理解します。詳細については、「*IAM ユーザーガイド*」の「[IAM JSON ポリシー要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。IAM ポリシーの作成方法については、IAM ドキュメントの[「はじめてのカスタマー管理ポリシーの作成とアタッチ」](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html)のチュートリアルを参照してください。
**Topics**
+ [CloudFormation のポリシーアクション](#using-iam-actions)
+ [CloudFormation のコンソール固有のアクション](#console-specific-actions)
+ [CloudFormation のポリシーリソース](#resource-level-permissions)
+ [CloudFormation のポリシー条件キー](#using-iam-conditions)
### CloudFormation のポリシーアクション
IAM ポリシーステートメントの `Action` 要素では、CloudFormation で提供されている API アクションを指定できます。アクション名には、接頭辞として小文字の文字列 `cloudformation:` を含める必要があります。例えば、`cloudformation:CreateStack`、`cloudformation:CreateChangeSet`、および `cloudformation:UpdateStack` のようになります。
単一のステートメントで複数のアクションを指定するには、次のようにカンマで区切ります。
```
"Action": [ "cloudformation:action1", "cloudformation:action2" ]
```
ワイルドカードを使用して複数のアクションを指定することもできます。例えば、`Get` という単語で始まるアクション名すべてを次のように指定できます。
```
"Action": "cloudformation:Get*"
```
`cloudformation` サービスプレフィックスに関連付けられたアクションの一覧については、「*Service Authorization Reference*」の「[Actions, resources, and condition keys for CloudFormation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html)」および「[Actions, resources, and condition keys for AWS クラウドコントロール API](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudcontrolapi.html)」を参照してください。
#### 例
以下は、CloudFormation スタックを表示するためのアクセス許可を付与するアクセス許可ポリシーの例です。
**Example 1: スタックを表示するためのアクセス許可を付与するポリシーの例**
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action":[
"cloudformation:DescribeStacks",
"cloudformation:DescribeStackEvents",
"cloudformation:DescribeStackResource",
"cloudformation:DescribeStackResources"
],
"Resource":"*"
}]
}
```
スタックを作成または削除するユーザーには、スタックテンプレートに基づく追加のアクセス許可が必要です。例えば、テンプレートに Amazon SQS キューが記述されている場合、次のポリシー例に示すように、ユーザーは CloudFormation アクションと Amazon SQS アクションの両方に対するアクセス許可を持っている必要があります。
**Example 2: スタックアクションの作成と表示、およびすべての Amazon SQS アクションを付与するサンプルポリシー**
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Effect":"Allow",
"Action":[
"sqs:*",
"cloudformation:CreateStack",
"cloudformation:DescribeStacks",
"cloudformation:DescribeStackEvents",
"cloudformation:DescribeStackResources",
"cloudformation:GetTemplate",
"cloudformation:ValidateTemplate"
],
"Resource":"*"
}]
}
```
### CloudFormation のコンソール固有のアクション
CloudFormation のコンソールを使用するユーザーには、AWS Command Line Interface または CloudFormation API に必要なアクセス許可に加えて、追加の許可が必要です。これらの追加のアクセス許可は、Amazon S3 バケットへのテンプレートのアップロードや、AWS 固有のパラメータタイプのドロップダウンリストなど、コンソールに固有の機能をサポートしています。
次のすべてのアクションで、すべてのリソースに対するアクセス許可を付与します。その際、特定のスタックまたはバケットに制限しないようにしてください。
次のアクションは、CloudFormation コンソールでのみ使用されるため、API リファレンスには記載されていません。このアクションにより、ユーザーは Amazon S3 バケットにテンプレートをアップロードできるようになります。
+ `cloudformation:CreateUploadBucket`
ユーザーがテンプレートをアップロードするときは、次の Amazon S3 のアクセス許可も必要になります。
+ `s3:PutObject`
+ `s3:ListBucket`
+ `s3:GetObject`
+ `s3:CreateBucket`
AWS 固有のパラメータタイプを持つテンプレートで、パラメータ ドロップダウン リストの値を確認するには、ユーザーは、対応する記述 API コールを行うためのアクセス許可が必要です。例えば、これらのパラメータタイプをテンプレートで使用する場合は次のアクセス許可が必要です。
+ `ec2:DescribeKeyPairs` – `AWS::EC2::KeyPair::KeyName` パラメータタイプに必要。
+ `ec2:DescribeSecurityGroups` – `AWS::EC2::SecurityGroup::Id` パラメータタイプに必要。
+ `ec2:DescribeSubnets` – `AWS::EC2::Subnet::Id` パラメータタイプに必要。
+ `ec2:DescribeVpcs` – `AWS::EC2::VPC::Id` パラメータタイプに必要。
AWS 固有のパラメータタイプに関する詳細は、「[CloudFormation が提供するパラメータタイプを使用して、実行時に既存のリソースを指定する](cloudformation-supplied-parameter-types.md)」を参照してください。
### CloudFormation のポリシーリソース
IAM ポリシーステートメントで、`Resource` 要素は、ステートメントがカバーするオブジェクトを指定します。CloudFormation では、各 IAM ポリシーステートメントは、ユーザーがAmazon リソースネーム（ARN）を使用して指定したリソースに適用されます。具体的 ARN 形式はリソースによって異なります。
CloudFormation リソースのタイプとその ARN のリストの一覧は、「*Service Authorization Reference*」の「[Resource types defined by CloudFormation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html#awscloudformation-resources-for-iam-policies)」を参照してください。各リソースの ARN を使って指定できるアクションについては、「[Actions defined by CloudFormation](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awscloudformation.html#awscloudformation-actions-as-permissions)」を参照してください。
次のポリシー例に示すように、特定のスタックのアクションを指定できます。ARN を指定するには、`placeholder text` をリソース固有の情報に置き換えます。
**Example 1: 指定したスタックに対するスタックアクションの削除と更新を拒否するサンプルポリシー**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"cloudformation:DeleteStack",
"cloudformation:UpdateStack"
],
"Resource": "arn:aws:cloudformation:us-east-1:111122223333:stack/MyProductionStack/*"
}
]
}
```
上記のポリシーでは、スタック名の最後にワイルドカードを使用することで、フルスタック ID (`arn:aws:cloudformation:region:account-id:stack/MyProductionStack/abc9dbf0-43c2-11e3-a6e8-50fa526be49c` など) とスタック名 (`MyProductionStack` など) の両方に基づいて、スタックの削除と更新を拒否します。
変更セットの作成を `AWS::Serverless` トランスフォームに許可するには、次のポリシーに示すように、`arn:aws:cloudformation:region:aws:transform/Serverless-2016-10-31` リソースレベルのアクセス許可を含めます。
**Example 2: 指定した変換に対して変更セットの作成アクションを許可するポリシーの例**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:CreateChangeSet"
],
"Resource": "arn:aws:cloudformation:us-east-1:aws:transform/Serverless-2016-10-31"
}
]
}
```
### CloudFormation のポリシー条件キー
IAM ポリシーのステートメントでは、必要に応じて、ポリシーを有効にするタイミングを制御する条件を指定できます。たとえば、特定のテンプレート URL を指定したときにのみ がユーザーにスタックの作成を許可するように、ポリシーを定義できます。CloudFormation 固有の条件や AWS 全体に対する、ポリシーが有効でなくなるタイミングを指定する `DateLessThan` などの条件を定義できます。AWS 全体の条件のリストについては、「*IAM ユーザーガイド*」の「[IAM ポリシー要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)」を参照してください。
**注記**
`aws:SourceIp` AWS 全体の条件を使用しないでください。CloudFormation はリクエストの送信元 IP アドレスではなく、独自の IP アドレスを使用してリソースをプロビジョニングします。例えば、スタックを作成する際に、CloudFormation は、Amazon EC2 インスタンスを起動したり Amazon S3 バケットを作成したりするために、`CreateStack` コールや **create-stack** コマンドを実行した IP アドレスではなく、その IP アドレスからリクエストを行います。
次のリストは、CloudFormation 固有の条件要件について説明しています。これらの条件は、ユーザーがスタックを作成または更新する場合にのみ適用されます。
`cloudformation:ChangeSetName`
ポリシーに関連付ける CloudFormation 変更セットの名前。この条件を使用して、 ユーザーがどの変更セットを実行、または削除するかを制御します。
`cloudformation:ImportResourceTypes`
ポリシーに関連付ける、`AWS::EC2::Instance` などのテンプレートリソースタイプ。この条件を使用して、 ユーザーがスタックにリソースをインポートするときに、操作できるリソースタイプを指定します。この条件は、ユーザーが `ResourcesToImport` パラメータで宣言したリソースタイプに対して確認されます。このパラメータは、現在のところ AWS CLI および API リクエストでのみサポートされています。このパラメータを使用する場合は、インポートオペレーション中にユーザーが制御するリソースタイプをすべて指定する必要があります。`ResourcesToImport` パラメータの詳細については、「*AWS CloudFormation API リファレンス*」の「[https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateChangeSet.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateChangeSet.html) アクション」を参照してください。
可能な `ResourcesToImport` の一覧については、「[リソースタイプのサポート](resource-import-supported-resources.md)」を参照してください。
3 つの部分からなるリソース命名規則を使用して、組織全体のすべてのリソースから個々のリソースタイプまで、ユーザーが操作できるリソースタイプを指定します。
`organization::*`
所定の組織のすべてのリソースタイプを指定します。
`organization::service_name::*`
所定の組織内で指定されたサービスのすべてのリソースタイプを指定します。
`organization::service_name::resource_type`
特定のリソースタイプを指定します。
例:
`AWS::*`
サポートされているすべての AWS リソースを指定します。
`AWS::service_name::*`
固有の AWS サービスでサポートされているすべてのリソースを指定します。
`AWS::service_name::resource_type`
`AWS::EC2::Instance` (すべての EC2 インスタンス) などの特定の AWS リソースタイプを指定します。
`cloudformation:ResourceTypes`
ポリシーに関連付ける `AWS::EC2::Instance` などのテンプレートリソース。この条件を使用して、 ユーザーがスタックを作成または更新したときに、操作できるリソースタイプを指定します。この条件は、ユーザーが `ResourceTypes` パラメータで宣言したリソースタイプに対して確認されます。このパラメータは、現在のところ AWS CLI および API リクエストでのみサポートされています。このパラメーターを使用する場合、ユーザーはそのテンプレートにあるすべてのリソースタイプを指定する必要があります。`ResourceTypes` パラメータの詳細については、「*AWS CloudFormation API リファレンス*」の「[https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html) アクション」を参照してください。
リソースタイプのリストについては、「[CloudFormation テンプレートリファレンスガイド](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/introduction.html)」を参照してください。
3 つの部分からなるリソース命名規則を使用して、組織全体のすべてのリソースから個々のリソースタイプまで、ユーザーが操作できるリソースタイプを指定します。
`organization::*`
所定の組織のすべてのリソースタイプを指定します。
`organization::service_name::*`
所定の組織内で指定されたサービスのすべてのリソースタイプを指定します。
`organization::service_name::resource_type`
特定のリソースタイプを指定します。
例:
`AWS::*`
サポートされているすべての AWS リソースを指定します。
`AWS::service_name::*`
固有の AWS サービスでサポートされているすべてのリソースを指定します。
`AWS::service_name::resource_type`
`AWS::EC2::Instance` (すべての EC2 インスタンス) などの特定の AWS リソースタイプを指定します。
`Alexa::ASK::*`
Alexa スキルキットですべてのリソースタイプを指定します。
`Alexa::ASK::Skill`
個々の [Alexa::ASK::Skill](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/alexa-resource-ask-skill.html) リソースタイプを指定します。
`Custom::*`
すべてのカスタムリソースを指定します。
詳細については、「[カスタムリソースを使用してカスタムプロビジョニングロジックを作成する](template-custom-resources.md)」を参照してください。
`Custom::resource_type`
特定のカスタムリソースタイプを指定します。
詳細については、「[カスタムリソースを使用してカスタムプロビジョニングロジックを作成する](template-custom-resources.md)」を参照してください。
`cloudformation:RoleARN`
ポリシーに関連付ける IAM サービスロールの Amazon リソースネーム (ARN)。この条件を使用して、 ユーザーがスタックまたは変更セットを操作するとき、どのサービスロールを使用できるかを制御します。
`cloudformation:StackPolicyUrl`
ポリシーに関連付ける Amazon S3 スタックポリシーの URL。 ユーザーがスタックの作成または更新アクション時にスタックに関連付けることができるスタックポリシーを制御するには、この条件を使用します。スタックポリシーの詳細については、「[スタックのリソースが更新されないようにする](protect-stack-resources.md)」を参照してください。
アップロードしたスタックポリシーを使用した場合にのみユーザーがスタックを作成または更新できるようにするには、それらのユーザーのために S3 バケットを読み取り専用に設定します。
`cloudformation:TemplateUrl`
ポリシーに関連付ける Amazon S3 テンプレートの URL。この条件を使用して、スタックを作成または更新したときに ユーザーが使用できるテンプレートを指定します。
アップロードしたテンプレートを使用した場合にのみユーザーがスタックを作成または更新できるようにするには、それらのユーザーのために S3 バケットを読み取り専用に設定します。
同じ名前の API パラメータには、次の CloudFormation 固有の条件が適用されます。
+ `cloudformation:ChangeSetName`
+ `cloudformation:RoleARN`
+ `cloudformation:StackPolicyUrl`
+ `cloudformation:TemplateUrl`
例えば、`cloudformation:TemplateUrl` は、`CreateStack`、`UpdateStack`、および `CreateChangeSet` API の `TemplateUrl` パラメータにのみ適用されます。
アクセス制御に条件キーを使用する IAM ポリシーの例については、「[CloudFormation の IAM アイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## CloudFormation テンプレートでの IAM リソースの承認
スタックを作成する前に、CloudFormation によってテンプレートが検証されます。検証中、CloudFormation は作成する可能性のある IAM リソースについてテンプレートをチェックします。IAM リソース (フルアクセス権を持つユーザーなど) は、AWS アカウント の任意のリソースにアクセスして変更できます。したがって、拡大した権限で意図していないリソースを作成しないように、進める前に各 IAM に関連付けられた権限を確認することをお勧めします。実行されたことを確認するには、スタックを作成する前に、CloudFormation に指定された機能を付与して、テンプレートにそれらのリソースを含めることを承認する必要があります。
CloudFormation コンソール、AWS Command Line Interface (AWS CLI)、または API を使用して、CloudFormation テンプレートの機能を承認できます。
+ CloudFormation コンソールで、[スタックを作成] または [スタックを更新] ウィザードの [**スタックオプションの設定**] ページで [**I acknowledge that this template may create IAM resources (このテンプレートが IAM リソースを作成する可能性を認識しています)**] を選択します。
+ AWS CLI で、[https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/create-stack.html) および [https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-stack.html](https://docs.aws.amazon.com/cli/latest/reference/cloudformation/update-stack.html) コマンドを使用する場合は、`--capabilities` オプションに `CAPABILITY_IAM` または `CAPABILITY_NAMED_IAM` 値を指定します。テンプレートに IAM リソースがある場合、いずれかの機能を指定できます。テンプレートの IAM リソースにカスタム名がある場合、`CAPABILITY_NAMED_IAM` を指定する必要があります。
+ API で [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html) と [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_UpdateStack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_UpdateStack.html) アクションを使用する際には、`Capabilities.member.1=CAPABILITY_IAM` または `Capabilities.member.1=CAPABILITY_NAMED_IAM` を指定します。テンプレートに IAM リソースがある場合、いずれかの機能を指定できます。テンプレートの IAM リソースにカスタム名がある場合、`CAPABILITY_NAMED_IAM` を指定する必要があります。
**重要**
テンプレートにカスタム名の IAM リソースが含まれている場合、同じテンプレートを再利用する複数のスタックを作成しないでください。IAM リソースはアカウント内でグローバルに一意でなければなりません。同じテンプレートを使用して異なるリージョンで複数のスタックを作成する場合、それぞれのスタックは一意なリソースを持つのではなく、同じ IAM リソースを共有する可能性があります。スタック間でリソースを共有すると、回復不可能な意図しない結果をまねく可能性があります。たとえば、1 つのスタックの共有された IAM リソースを削除または更新すると、意図せずに他のスタックのリソースの変更することになります。
## Amazon EC2 インスタンスで実行されるアプリケーションの認証情報の管理
Amazon EC2 インスタンスで実行されるアプリケーションで、Amazon S3 バケットや DynamoDB テーブルなどの AWS リソースにリクエストを送信する必要がある場合、そのアプリケーションでは AWS セキュリティ認証情報が必要になります。ただし、起動するすべてのインスタンスにおける長期的なセキュリティ認証情報を配信して埋め込むことは非常に難しく、潜在的なセキュリティリスクを伴います。IAM ユーザー認証情報のような長期認証情報を使用する代わりに、インスタンスが起動される際に Amazon EC2 インスタンスに関連付けられる IAM ロールを作成することをお勧めします。アプリケーションは Amazon EC2 インスタンスから一時的な認証情報を得ることができます。インスタンスに長期認証情報を埋め込む必要はありません。また、認証情報を管理しやすくするために、複数の Amazon EC2 インスタンスに対して 1 つのロールのみを指定できます。インスタンスごとに個別の認証情報を作成する必要はありません。
ロールでのインスタンスの起動方法を示すテンプレートスニペットについては、「[IAM ロールのテンプレートの例](quickref-iam.md#scenarios-iamroles)」を参照してください。
**注記**
一時的なセキュリティ認証情報を使用するインスタンスにあるアプリケーションでは、CloudFormation アクションを呼び出すことができます。ただし、CloudFormation は他の多数の AWS サービスとやり取りするため、使用するすべてのサービスが一時的なセキュリティ認証情報をサポートすることを確認する必要があります。一時的なセキュリティ認証情報を受け入れるサービスのリストについては、*IAM ユーザーガイド*の「[IAM と連携する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## 一時的なアクセス権の付与 (フェデレーションアクセス)
場合によっては、AWS アカウント に対して AWS 認証情報のない一時的なアクセス権をユーザーに付与する必要があります。一時的なアクセス権を付与する場合は、長期認証情報を作成して削除するのではなく、AWS Security Token Service (AWS STS) を使用します。たとえば、IAM ロールを使用できます。1 つの IAM ロールから、多くの一時的なセキュリティ認証情報 (アクセスキー、シークレットアクセスキー、およびセキュリティトークンを含む) をプログラムで作成し、配信することができます。これらの認証情報の有効期限は限られているため、期限が切れた後は AWS アカウント へのアクセスに使用することはできません。また、個々のユーザーに異なるレベルのアクセス許可を付与するために、複数の IAM ロールを作成することもできます。IAM ロールは、連合 ID やシングルサインオンのようなシナリオに対して有用です。
フェデレーティッドアイデンティティは、複数のシステムで使用できる固有のアイデンティティです。確立されたオンプレミスアイデンティティシステム (LDAP または Active Directory など) を使用している企業ユーザーの場合、そのオンプレミスアイデンティティシステムを使用してすべての認証を処理できます。ユーザーが認証された後で、適切な IAM ユーザーまたは IAM ロールから一時的なセキュリティ認証情報を提供します。例えば、管理者が AWS アカウントへの完全アクセス権を持ち、デベロッパーが CloudFormation スタックでの作業のみのアクセス許可を持つ、管理者ロールおよび開発者ロールを作成できます。管理者は、認証された後で、管理者ロールから一時的なセキュリティ認証情報を取得することが認可されます。一方で、開発者は開発者ロールからのみ一時的なセキュリティ認証情報を取得できます。
また、AWS マネジメントコンソール にフェデレーションユーザーアクセスを付与できます。ユーザーがオンプレミスアイデンティティシステムで認証された後で、AWS マネジメントコンソール への直接アクセス権を付与する一時的な URL をプログラムによって作成できます。ユーザーは既に認証されているため (シングルサインオン)、その一時的な URL を使用するときには AWS にサインインする必要がありません。また、この URL はユーザーの一時的なセキュリティ認証情報から作成されるため、この認証情報で利用できるアクセス許可によって、AWS マネジメントコンソール でユーザーに付与されるアクセス許可が決まります。
一時的なセキュリティ認証情報を生成するために複数のさまざまな AWS STS API を使用できます。使用する API の詳細については、「*IAM ユーザーガイド*」の「[AWS STS 認証情報を比較する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_sts-comparison.html)」を参照してください。
**重要**
`GetFederationToken` API から生成された一時的なセキュリティ認証情報を使用する場合は、IAM で作業することはできません。IAM での作業が必要な場合、代わりにロールからの一時的なセキュリティ認証情報を使用します。
CloudFormation は他の多数の AWS サービスとインタラクションします。CloudFormation で一時的なセキュリティ認証情報を使用する場合は、使用するすべてのサービスが一時的なセキュリティ認証情報をサポートすることを確認してください。一時的なセキュリティ認証情報を受け入れるサービスのリストについては、*IAM ユーザーガイド*の「[IAM と連携する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
詳細については、「*IAM ユーザーガイド*」の次の関連リソースを参照してください。
+ [一時的な認証情報の一般的なシナリオ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html#sts-introduction)
+ [AWS コンソールへのカスタム ID ブローカーアクセスを有効にする](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-custom-url.html)
# CloudFormation の IAM アイデンティティベースのポリシーの例
デフォルトでは、ユーザーおよびロールには、CloudFormation リソースを作成または変更するアクセス許可がありません。また、AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または AWS API を使用してタスクを実行することもできません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。その後、管理者はロールに IAM ポリシーを追加し、ユーザーはロール引き継ぐことができます。詳細については、「[CloudFormation の IAM アイデンティティベースのポリシーの定義](control-access-with-iam.md#iam-id-based-policies)」を参照してください。
以下は、1 つ以上の CloudFormation アクションを使用するためのアクセス許可を、許可または拒否する際に使用できるポリシーステートメントの例です。
**Topics**
+ [特定のテンプレート URL を要求する](#w2aac43c23c17b9)
+ [すべての CloudFormation インポートオペレーションを拒否する](#w2aac43c23c17c11)
+ [特定のリソースタイプのインポートオペレーションを許可する](#w2aac43c23c17c13)
+ [スタックテンプレートで IAM リソースを拒否する](#w2aac43c23c17c15)
+ [特定のリソースタイプでスタックの作成を許可する](#w2aac43c23c17c17)
+ [リソース変更 API アクションに基づいてアクセスを制御する](#w2aac43c23c17c19)
+ [リージョンとリソースタイプに基づいてスタックセットのオペレーションを制限する](#resource-level-permissions-service-managed-stack-set)
+ [すべての IaC ジェネレーターオペレーションを許可する](#iam-policy-example-for-iac-generator)
## 特定のテンプレート URL を要求する
次のポリシーは、スタックを作成または更新するときに、`https://s3.amazonaws.com/amzn-s3-demo-bucket/test.template` テンプレート URL の使用のみを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:CreateStack",
"cloudformation:UpdateStack"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudformation:TemplateUrl": [
"https://s3.amazonaws.com/amzn-s3-demo-bucket/test.template"
]
}
}
}
]
}
```
------
## すべての CloudFormation インポートオペレーションを拒否する
次のポリシーは、インポートオペレーションを除く、すべての CloudFormation オペレーションの実行を許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowAllStackOperations",
"Effect": "Allow",
"Action": "cloudformation:*",
"Resource": "*"
},
{
"Sid": "DenyImport",
"Effect": "Deny",
"Action": "cloudformation:*",
"Resource": "*",
"Condition": {
"ForAnyValue:StringLike": {
"cloudformation:ImportResourceTypes": [
"*"
]
}
}
}
]
}
```
------
## 特定のリソースタイプのインポートオペレーションを許可する
次のポリシーは、指定したリソース (以下の例では `AWS::S3::Bucket`) に加えて、すべてのスタックオペレーションをインポートオペレーションを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowImport",
"Effect": "Allow",
"Action": "cloudformation:*",
"Resource": "*",
"Condition": {
"ForAllValues:StringEqualsIgnoreCase": {
"cloudformation:ImportResourceTypes": [
"AWS::S3::Bucket"
]
}
}
}
]
}
```
------
## スタックテンプレートで IAM リソースを拒否する
次のポリシーは、スタックの作成を許可しますが、スタックのテンプレートに IAM サービスのリソースが含まれている場合はリクエストを拒否します。このポリシーでは、ユーザーが `ResourceTypes` パラメータ (AWS CLI および API リクエストでのみ使用可能) を指定することも要求されます。このポリシーは、明示的な拒否ステートメントを使用することにより、他のポリシーが追加のアクセス権限を付与している場合、このポリシーが常に有効なままになるようにします (明示的な拒否ステートメントは常に明示的な許可ステートメントより優先されます)。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect" : "Allow",
"Action" : [ "cloudformation:CreateStack" ],
"Resource" : "*"
},
{
"Effect" : "Deny",
"Action" : [ "cloudformation:CreateStack" ],
"Resource" : "*",
"Condition" : {
"ForAnyValue:StringLikeIfExists" : {
"cloudformation:ResourceTypes" : [ "AWS::IAM::*" ]
}
}
},
{
"Effect": "Deny",
"Action" : [ "cloudformation:CreateStack" ],
"Resource": "*",
"Condition": {
"Null": {
"cloudformation:ResourceTypes": "true"
}
}
}
]
}
```
------
## 特定のリソースタイプでスタックの作成を許可する
次のポリシーは、1 つ前の例に似ています。このポリシーは、スタックのテンプレートに IAM サービスのリソースが含まれていない場合に、スタックの作成を許可します。さらに、ユーザーが `ResourceTypes` パラメータ (AWS CLI および API リクエストでのみ使用可能) を指定することも要求します。このポリシーはよりシンプルですが、明示的な拒否ステートメントを使用しません。追加のアクセス権限を付与する他のポリシーにより、このポリシーがオーバーライドされる可能性があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect" : "Allow",
"Action" : [ "cloudformation:CreateStack" ],
"Resource" : "*",
"Condition" : {
"ForAllValues:StringNotLikeIfExists" : {
"cloudformation:ResourceTypes" : [ "AWS::IAM::*" ]
},
"Null":{
"cloudformation:ResourceTypes": "false"
}
}
}
]
}
```
------
## リソース変更 API アクションに基づいてアクセスを制御する
次のポリシーは、リソース変異 API アクションの名前でアクセスをフィルターすることを許可します。これは、IAM ユーザーがスタックまたはスタックセットのタグを追加または削除するために使用できる API を制御するために使用されます。タグの追加または削除に使用されるオペレーションは、条件キーの値として追加する必要があります。次のポリシーは、変更オペレーション `CreateStack` に対する `TagResource` および `UntagResource` アクセス許可を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "CreateActionConditionPolicyForTagUntagResources",
"Effect": "Allow",
"Action": [
"cloudformation:TagResource",
"cloudformation:UntagResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudformation:CreateAction": [
"CreateStack"
]
}
}
}]
}
```
------
## リージョンとリソースタイプに基づいてスタックセットのオペレーションを制限する
次のポリシーは、サービスマネージド型のスタックセットのアクセス許可を付与します。このポリシーを持つユーザーは、Amazon S3 リソースタイプ (`AWS::S3::*`) または `AWS::SES::ConfigurationSet` リソースタイプを含むテンプレートを含むスタックセットに対してのみオペレーションを実行できます。ID が `123456789012` である組織管理アカウントにサインインした場合、ユーザーはまた、ID が`ou-1fsfsrsdsfrewr` である OU をターゲットとするスタックセットに対してのみオペレーションを実行でき、さらに、ID が `987654321012` である AWS アカウント をターゲットとする、ID が `stack-set-id` であるスタックセットに対してのみオペレーションを実行できます。
スタックセットテンプレートに、ポリシーで指定されているリソース以外のリソースタイプが含まれている場合、またはデプロイターゲットが、対応する管理アカウントとスタックセットのポリシーで指定されているもの以外の OU またはアカウント ID である場合、スタックセットオペレーションは失敗します。
これらのポリシー制限は、スタックセットオペレーションが `us-east-1`、`us-west-2`、または `eu-west-2` AWS リージョン をターゲットとする場合にのみ適用されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cloudformation:*"
],
"Resource": [
"arn:aws:cloudformation:*:*:stackset/*",
"arn:aws:cloudformation:*:*:type/resource/AWS-S3-*",
"arn:aws:cloudformation:us-west-2:111122223333:type/resource/AWS-SES-ConfigurationSet",
"arn:aws:cloudformation:*:111122223333:stackset-target/*/ou-1fsfsrsdsfrewr",
"arn:aws:cloudformation:*:111122223333:stackset-target/stack-set-id/444455556666"
],
"Condition": {
"ForAllValues:StringEqualsIgnoreCase": {
"cloudformation:TargetRegion": [
"us-east-1",
"us-west-2",
"eu-west-1"
]
}
}
}
]
}
```
------
## すべての IaC ジェネレーターオペレーションを許可する
次のポリシーは、IaC ジェネレーターリソースのスキャンとテンプレート管理に関連する CloudFormation アクションへのアクセスを許可します。最初のステートメントは、リソーススキャンの記述、一覧表示、開始を許可します。また、IaC ジェネレーターがリソースと使用可能なリソースタイプに関する情報を取得できるようにする、必要な追加のアクセス許可 (`cloudformation:GetResource`、`cloudformation:ListResources`、`cloudformation:ListTypes`) へのアクセスも許可します。2 番目のステートメントは、生成されたテンプレートを作成、削除、記述、一覧表示、更新するための完全なアクセス許可を付与します。
また、IaC ジェネレーターでリソースをスキャンするすべてのユーザーに、ターゲットの AWS サービスの読み取りアクセス許可も付与する必要があります。詳細については、「[リソースのスキャンに必要な IAM アクセス許可](generate-IaC.md#iac-generator-permissions)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"ResourceScanningOperations",
"Effect":"Allow",
"Action":[
"cloudformation:DescribeResourceScan",
"cloudformation:GetResource",
"cloudformation:ListResources",
"cloudformation:ListResourceScanRelatedResources",
"cloudformation:ListResourceScanResources",
"cloudformation:ListResourceScans",
"cloudformation:ListTypes",
"cloudformation:StartResourceScan"
],
"Resource":"*"
},
{
"Sid":"TemplateGeneration",
"Effect":"Allow",
"Action":[
"cloudformation:CreateGeneratedTemplate",
"cloudformation:DeleteGeneratedTemplate",
"cloudformation:DescribeGeneratedTemplate",
"cloudformation:GetResource",
"cloudformation:GetGeneratedTemplate",
"cloudformation:ListGeneratedTemplates",
"cloudformation:UpdateGeneratedTemplate"
],
"Resource":"*"
}
]
}
```
------
# AWS CloudFormation の AWS マネージドポリシー
AWS マネージドポリシーは、AWS が作成および管理するスタンドアロンポリシーです。AWS マネージドポリシーは、多くの一般的なユースケースに対してアクセス許可を提供するように設計されているため、ユーザー、グループ、ロールへのアクセス権の割り当てを開始できます。
AWS マネージドポリシーは、ご利用の特定のユースケースに対して最小特権のアクセス許可を付与しない場合があることにご注意ください。これは、すべての AWS ユーザーが使用できるようになるのを避けるためです。ユースケースに固有の[カスタマー管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)を定義して、アクセス許可を絞り込むことをお勧めします。
AWS マネージドポリシーで定義したアクセス権限は変更できません。AWS が AWS マネージドポリシーに定義されているアクセス許可を更新すると、更新はポリシーがアタッチされているすべてのプリンシパルアイデンティティ (ユーザー、グループ、役割) に影響します。新しい AWS サービスを起動するか、既存のサービスで新しい API オペレーションが使用可能になると、AWS が AWS マネージドポリシーを更新する可能性が最も高くなります。
詳細については「*IAM ユーザーガイド*」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
## AWS マネージドポリシー: AWSCloudFormationFullAccess
ユーザー、グループおよびロールに `AWSCloudFormationFullAccess` をアタッチできます。
このポリシーは、CloudFormation アクションとリソースへのフルアクセスを許可するアクセス許可を付与します。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `cloudformation` - プリンシパルが、すべてのリソースに対してすべての CloudFormation アクションを実行できるようにします。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンスガイド*」の「[AWSCloudFormationFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCloudFormationFullAccess.html)」を参照してください。
## AWS マネージドポリシー: AWSCloudFormationReadOnlyAccess
ユーザー、グループおよびロールに `AWSCloudFormationReadOnlyAccess` をアタッチできます。
このポリシーは、CloudFormation リソースとアクションへの読み取り専用アクセスを許可するアクセス許可を付与します。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `cloudformation` – プリンシパルがスタックの説明、リソースの一覧表示、テンプレートの表示などの読み取り専用の CloudFormation アクションを実行できるようにしますが、スタックの作成、更新、削除は許可しません。
このポリシーのアクセス許可を確認するには、「*AWS マネージドポリシーリファレンスガイド*」の「[AWSCloudFormationReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSCloudFormationReadOnlyAccess.html)」を参照してください。
## CloudFormation の AWS マネージドポリシーへの更新
CloudFormation の AWS マネージドポリシーへの更新に関する詳細を、このサービスがこれらの変更の追跡を開始した以降の分について表示します。このページの変更に関する自動通知については、CloudFormation ドキュメントの履歴ページの RSS フィードにサブスクライブしてください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWSCloudFormationReadOnlyAccess](#security-iam-awsmanpol-AWSCloudFormationReadOnlyAccess) – 既存のポリシーへの更新 | CloudFormation は、バッチ記述オペレーションの `cloudformation:BatchDescribe*` アクションを許可する新しいアクセス許可を追加しました。 | 2026 年 1 月 30 日 |
| [AWSCloudFormationReadOnlyAccess](#security-iam-awsmanpol-AWSCloudFormationReadOnlyAccess) – 既存のポリシーへの更新 | CloudFormation は、スタックドリフト検出機能の `cloudformation:Detect*` アクションを許可する新しいアクセス許可を追加しました。 | 2019 年 11 月 13 日 |
| [AWSCloudFormationReadOnlyAccess](#security-iam-awsmanpol-AWSCloudFormationReadOnlyAccess) – 既存のポリシーへの更新 | CloudFormation は、`cloudformation:EstimateTemplateCost`、`cloudformation:Get*`、および `cloudformation:ValidateTemplate` アクションを許可する新しいアクセス許可を追加しました。 | 2017 年 11 月 2 日 |
| [AWSCloudFormationFullAccess](#security-iam-awsmanpol-AWSCloudFormationFullAccess) – 新規ポリシー | CloudFormation は、CloudFormation のアクションとリソースへのフルアクセスを提供する新しい AWS マネージドポリシーを追加しました。 | 2019 年 7 月 26 日 |
| [AWSCloudFormationReadOnlyAccess](#security-iam-awsmanpol-AWSCloudFormationReadOnlyAccess) – 既存のポリシーへの更新 | CloudFormation は、スタックドリフト検出の `cloudformation:DetectStackDrift` および `cloudformation:DetectStackResourceDrift` アクションを許可する新しいアクセス許可を追加しました。 | 2019 年 2 月 6 日 |
| [AWSCloudFormationReadOnlyAccess](#security-iam-awsmanpol-AWSCloudFormationReadOnlyAccess) – 新規ポリシー | CloudFormation は、CloudFormation アクションとリソースへの読み取り専用アクセスを提供する新しい AWS マネージドポリシーを追加しました。 | 2015 年 2 月 6 日 |
| CloudFormation が変更の追跡を開始しました | CloudFormation が AWS マネージドポリシーの変更の追跡を開始しました。 | 2015 年 2 月 6 日 |
# CloudFormation サービスロール
サービスロールは、ユーザーに代わってスタック内のリソースを呼び出すことを CloudFormation に許可する AWS Identity and Access Management (IAM) ロールです。スタックリソースを作成、更新、または削除することを CloudFormation に許可する IAM ロールを指定できます。CloudFormation はデフォルトで、スタックオペレーションのためのユーザー認証情報から CloudFormation が生成する一時的なセッションを使用します。サービスロールを指定すると、CloudFormation はロールの認証情報を使用します。
サービスロールを使用して、CloudFormation が実行できるアクションを明示的に指定します。これらは、必ずしもユーザー自身または他のユーザーが実行できるアクションと同じであるとは限りません。例えば、管理者権限がある場合でも、CloudFormation アクセスを制限できるのは Amazon EC2 アクションへのアクセスのみです。
IAM サービスで、サービスロールと権限ポリシーを作成します。サービスロールの作成について詳しくは、「*IAM ユーザーガイド*」の「[AWS のサービスに権限を委任するロールの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。ロールを引き受けることのできるサービスとして CloudFormation (`cloudformation.amazonaws.com`) を指定します。
サービスロールをスタックと関連付けるには、スタックを作成するときにロールを指定します。詳細については、「[スタックオプションを設定する](cfn-console-create-stack.md#configure-stack-options)」を参照してください。サービスロールは、コンソールでスタックを更新するとき、または API を使用してスタックを [https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DeleteStack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_DeleteStack.html) するときにも変更できます。サービスロールを指定する前に、サービスロールを割り当てるアクセス権限 (`iam:PassRole`) があるかどうかを確認します。`iam:PassRole` アクセス権限は、どのロールを使用できるかを指定します。詳細については、「*IAM ユーザーガイド*」の「[AWS サービスにロールを渡すアクセス許可をユーザーに付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html)」を参照してください。
**重要**
サービスロールを指定すると、CloudFormation はスタックで実行されるすべてのオペレーションに対して、そのロールを常に使用します。スタックの作成後に、スタックにアタッチされたサービスロールを削除することはできません。このスタックで操作を実行する権限を持つ他のユーザーは、`iam:PassRole` 権限の有無にかかわらず、このロールを使用できます。ユーザーが持つべきではないアクセス権限がロールに含まれる場合、ユーザーのアクセス権限を非意図的にエスカレーションできてしまいます。ロールが最小特権を付与することを確認します。詳細については、「IAM ユーザーガイド」の「[最小特権アクセス許可を適用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege)」を参照してください。
# サービス間の混乱した代理の防止
混乱した代理問題は、アクションを実行する許可を持たないエンティティが、より特権のあるエンティティにアクションを実行するように強制できるセキュリティの問題です。AWS では、サービス間でのなりすましによって、混乱した代理問題が発生する場合があります。サービス間でのなりすましは、あるサービス (*呼び出し元サービス*) が、別のサービス (*呼び出し対象サービス*) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自身のアクセス許可を使用して、本来アクセス許可が付与されるべきではない方法で別の顧客のリソースに対して働きかけることがあります。これを防ぐため、AWS では、アカウント内のリソースへのアクセス許可が付与されたサービスプリンシパルですべてのサービスのデータを保護するために役立つツールを提供しています。
リソースポリシーで「[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn)」および「[https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount)」のグローバル条件コンテキストキーを使用し、CloudFormation が CloudFormation 拡張機能などの特定リソースに別のサービスを付与する許可を制限することをお勧めします。クロスサービスアクセスにリソースを 1 つだけ関連付けたい場合は、`aws:SourceArn` を使用します。そのアカウント内のリソースをクロスサービスの使用に関連付けることを許可する場合は、`aws:SourceAccount` を使用します。
`aws:SourceArn` の値は CloudFormation が保存するリソースの ARN であることを確認します。
混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して `aws:SourceArn` グローバル条件コンテキストキーを使用することです。リソースの完全な ARN が不明な場合や、複数のリソースを指定する場合は、`aws:SourceArn` グローバルコンテキスト条件キーを使用して、ARN の未知部分をワイルドカード (`*`) で表します。例えば、`arn:aws:cloudformation:*:123456789012:*` です。
`aws:SourceArn` の値にアカウント ID が含まれていない場合、両方のグローバル条件コンテキストキーを使用して許可を制限する必要があります。
次の例では、CloudFormation で `aws:SourceArn` および `aws:SourceAccount` グローバル条件コンテキストキーを使用して、混乱した代理問題を回避する方法を示します。
## `aws:SourceArn` および `aws:SourceAccount` 条件キーを使用する信頼ポリシーの例
レジストリサービスの場合、CloudFormation は AWS Security Token Service (AWS STS) を呼び出してアカウントでのサービスロールを引き受けます。このロールは、[https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_RegisterType.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_RegisterType.html) オペレーションで `ExecutionRoleArn` に対して構成され、[https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_LoggingConfig.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_LoggingConfig.html) オペレーションで設定された `LogRoleArn` に対して構成されます。詳細については、「[IAM アクセス許可とパブリック拡張アクセスの信頼ポリシーを使用して実行ロールを設定する](registry-public.md#registry-public-enable-execution-role)」を参照してください。
このロールの信頼ポリシーの例では、条件文を使用して、サービスロールの `AssumeRole` 機能を、指定されたアカウントの指定された CloudFormation 拡張機能に対するアクションのみに制限します。`aws:SourceArn` および `aws:SourceAccount` の条件は個別に評価されます。サービスロールを使用するリクエストでは、両方の条件が満たされている必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"resources.cloudformation.amazonaws.com"
]
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:SourceAccount": "123456789012"
},
"ArnLike": {
"aws:SourceArn": "arn:aws:cloudformation:us-east-1:123456789012:type/resource/Organization-Service-Resource"
}
}
}
]
}
```
------
## 追加情報
StackSets で使用されるサービスロールの `aws:SourceArn` および `aws:SourceAccount` のグローバル条件コンテキストキーを使用するポリシーの例については、「[混乱した代理問題を軽減するためにグローバルキーを設定する](stacksets-prereqs-self-managed.md#confused-deputy-mitigation)」を参照してください。
詳細については、「IAM ユーザーガイド」の「[ロールの信頼ポリシーの変更](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html)」を参照してください。
# 転送アクセスセッション (FAS) リクエストとアクセス許可の評価
CloudFormation スタックを作成、更新、削除する場合、ユーザーはオプションで IAM ロール ARN を指定できます。ロールが指定されていない場合、CloudFormation はデフォルトのサービスメカニズムを使用して他の AWS サービスとやり取りします。このシナリオでは、呼び出し元は管理対象のリソースに必要なアクセス許可を持っている必要があります。または、ユーザーが独自の IAM ロールを提供すると、CloudFormation はそのロールを引き受けて、ユーザーに代わってサービスのやり取りを実行します。
ユーザーが IAM ロールを提供するかどうかにかかわらず、CloudFormation はリソースオペレーションごとに新しいスコープが限定された FAS トークンを生成します。その結果、`aws:ViaAWSService` を含む [FAS 関連の条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html#access_fas_policy_conditions)は、両方のシナリオで入力されます。
FAS の使用は、CloudFormation オペレーション中の IAM ポリシーの評価方法に影響します。FAS 関連の条件キーの影響を受けるリソースを含むテンプレートを使用してスタックを作成すると、アクセス許可が拒否される場合があります。
**IAM ポリシーの例**
次の IAM ポリシーを検討してください。`Statement2` は CloudFormation での `AWS::KMS::Key`リソースの作成を一貫して禁止します。スタックオペレーション中に IAM ロールが指定されているかどうかにかかわらず、制限は一貫して適用されます。これは、FAS の使用により、`aws:ViaAWSService` 条件キーが常に `true` に設定されているためです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"kms:CreateKey"
],
"Resource": [
"*"
]
},
{
"Sid": "Statement2",
"Effect": "Deny",
"Action": [
"kms:CreateKey"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"aws:ViaAWSService": "true"
}
}
}
]
}
```
------
**スタックテンプレートの例**
例えば、ユーザーが次のサンプルテンプレートを使用してスタックを作成すると、 `aws:ViaAWSService` は `true` に設定され、ロールのアクセス許可は FAS ポリシーによって上書きされます。スタックの作成は、`CreateKey` アクションを拒否する IAM ポリシーの `Statement2` の影響を受けます。その結果、アクセス許可拒否エラーが発生します。
```
Resources:
myPrimaryKey:
Type: AWS::KMS::Key
Properties:
Description: An example multi-Region primary key
KeyPolicy:
Version: '2012-10-17'
Id: key-default-1
Statement:
- Sid: Enable IAM User Permissions
Effect: Allow
Principal:
AWS: !Join
- ''
- - 'arn:aws:iam::'
- !Ref AWS::AccountId
- ':root'
Action: kms:*
Resource: '*'
```
FAS の詳細については、「*IAM ユーザーガイド*」の「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
**注記**
ほとんどのリソースはこの動作に従います。ただし、リソースの作成、更新、削除時に予期しない成功または失敗が発生し、IAM ポリシーに FAS 関連の条件キーが含まれている場合、問題のリソースは、この標準的な動作に従わないリソースの小さなサブセットに属している可能性があります。
# AWS CloudTrail による CloudFormation API コールのログ記録
CloudFormation は AWS CloudTrail (ユーザー、ロール、CloudFormation の AWS サービスが行ったアクションの記録を提供するサービス) と統合されます。CloudTrail は、CloudFormation のすべての API コールをイベントとしてキャプチャし、これには CloudFormation コンソールからの呼び出しと CloudFormation API へのコード呼び出しが含まれます。証跡を作成する場合は、CloudFormation のイベントなど、Amazon S3 バケットへの CloudTrail イベントの継続的な配信を有効にすることができます。証跡を設定しない場合でも、CloudTrail コンソールの **[イベント履歴]** で最新のイベントを表示できます。CloudTrail によって収集された情報を使用して、CloudFormation に対するリクエスト、リクエスト元の IP アドレス、リクエストしたユーザー、リクエスト日時などの詳細を確認できます。
CloudTrail の詳細については、「[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/)」を参照してください。
**Topics**
+ [CloudTrail での CloudFormation 情報](#cloudformation_info_in_cloudtrail)
+ [CloudFormation ログファイルエントリについて](#understanding_cloudformation_entries)
## CloudTrail での CloudFormation 情報
AWS アカウントを作成すると、そのアカウントに対して CloudTrail が有効になります。CloudFormation でアクティビティが発生するとき、そのアクティビティは、**[Event history]** (イベント履歴) の他の AWS サービスイベントとともに、CloudTrail イベントに記録されます。最近のイベントは、AWS アカウントで表示、検索、ダウンロードできます。詳細については、「[CloudTrail Event 履歴でのイベントの表示](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)」を参照してください。
CloudFormation のイベントを含め、AWS アカウントのイベントの継続的な記録については、トレイルを作成します。[Trail] (追跡) により、CloudTrail はログファイルを Simple Storage Service (Amazon S3) バケットに配信できます。デフォルトでは、コンソールで証跡を作成すると、すべての リージョンに証跡が適用されます。証跡は、AWS パーティションのすべてのリージョンからのイベントをログに記録し、指定した Amazon S3 バケットにログファイルを配信します。さらに、CloudTrail ログで収集したイベントデータをより詳細に分析し、それに基づく対応するためにその他の AWS のサービスを設定できます。詳細については、次を参照してください。
+ [証跡を作成するための概要](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail がサポートされているサービスと統合](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ 「[CloudTrail の Amazon SNS 通知の設定](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/configure-sns-notifications-for-cloudtrail.html)」
+ [CloudTrail ログファイルを複数のリージョンから受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html)、[複数のアカウントから CloudTrail ログファイルを受け取る](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
すべての CloudFormation アクションは、CloudTrail によってログ記録され、[AWS CloudFormation API リファレンス](https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_Operations.html)にドキュメント化されます。たとえば、[`CreateStack`]、[`DeleteStack`]、[`ListStacks`] セクションの呼び出しは、CloudTrail ログファイルにエントリを生成します。
各イベントまたはログエントリには、リクエストの生成者に関する情報が含まれます。同一性情報は次の判断に役立ちます。
+ リクエストが、ルートと IAM ユーザー認証情報のどちらを使用して送信されたか。
+ リクエストがロールまたはフェデレーションユーザーの一時的なセキュリティ認証情報を使用して行われたかどうか。
+ リクエストが別の AWS サービスによって行われたかどうか。
詳細については、「[CloudTrail userIdentity エレメント](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)」を参照してください。
## CloudFormation ログファイルエントリについて
[トレイル] は、指定した Simple Storage Service (Amazon S3) バケットにイベントをログファイルとして配信するように構成できます。CloudTrail のログファイルには、単一または複数のログエントリがあります。各イベントは任意の送信元からの単一のリクエストを表し、リクエストされたオペレーション、オペレーションの日時、リクエストパラメータなどに関する情報を含みます。CloudTrail ログファイルは、パブリック API 呼び出しの順序付けられたスタックトレースではないため、特定の順序では表示されません。
`CreateStack` オペレーションを示す CloudTrail ログエントリの例は、次のとおりです。オペレーションは Alice という名前の IAM ユーザーによって行われました。
**注記**
入力パラメータのキー名のみがログ記録されます。パラメータ値は記録されません。
```
{
"eventVersion": "1.01",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAABCDEFGHIJKLNMOPQ",
"arn": "arn:aws:iam::012345678910:user/Alice",
"accountId": "012345678910",
"accessKeyId": "AKIDEXAMPLE",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:02:43Z",
"eventSource": "cloudformation.amazonaws.com",
"eventName": "CreateStack",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.2.11 Python/2.7.4 Linux/2.6.18-164.el5",
"requestParameters": {
"templateURL": "templateURL",
"tags": [
{
"key": "test",
"value": "tag"
}
],
"stackName": "my-test-stack",
"disableRollback": true,
"parameters": [
{
"parameterKey": "password"
},
{
"parameterKey": "securitygroup"
}
]
},
"responseElements": {
"stackId": "arn:aws:cloudformation:us-east-1:012345678910:stack/my-test-stack/a38e6a60-b397-11e3-b0fc-08002755629e"
},
"requestID": "9f960720-b397-11e3-bb75-a5b75389b02d",
"eventID": "9bf6cfb8-83e1-4589-9a70-b971e727099b"
}
```
次の例では、Alice が `my-test-stack` スタックの `UpdateStack` オペレーションを呼び出したことを示しています。
```
{
"eventVersion": "1.01",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAABCDEFGHIJKLNMOPQ",
"arn": "arn:aws:iam::012345678910:user/Alice",
"accountId": "012345678910",
"accessKeyId": "AKIDEXAMPLE",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:04:29Z",
"eventSource": "cloudformation.amazonaws.com",
"eventName": "UpdateStack",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.2.11 Python/2.7.4 Linux/2.6.18-164.el5",
"requestParameters": {
"templateURL": "templateURL",
"parameters": [
{
"parameterKey": "password"
},
{
"parameterKey": "securitygroup"
}
],
"stackName": "my-test-stack"
},
"responseElements": {
"stackId": "arn:aws:cloudformation:us-east-1:012345678910:stack/my-test-stack/a38e6a60-b397-11e3-b0fc-08002755629e"
},
"requestID": "def0bf5a-b397-11e3-bb75-a5b75389b02d",
"eventID": "637707ce-e4a3-4af1-8edc-16e37e851b17"
}
```
次の例では、Alice が `ListStacks` オペレーションを呼び出したことを示しています。
```
{
"eventVersion": "1.01",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAABCDEFGHIJKLNMOPQ",
"arn": "arn:aws:iam::012345678910:user/Alice",
"accountId": "012345678910",
"accessKeyId": "AKIDEXAMPLE",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:03:16Z",
"eventSource": "cloudformation.amazonaws.com",
"eventName": "ListStacks",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.2.11 Python/2.7.4 Linux/2.6.18-164.el5",
"requestParameters": null,
"responseElements": null,
"requestID": "b7d351d7-b397-11e3-bb75-a5b75389b02d",
"eventID": "918206d0-7281-4629-b778-b91eb0d83ce5"
}
```
次の例では、Alice が `my-test-stack` スタックの `DescribeStacks` オペレーションを呼び出したことを示しています。
```
{
"eventVersion": "1.01",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAABCDEFGHIJKLNMOPQ",
"arn": "arn:aws:iam::012345678910:user/Alice",
"accountId": "012345678910",
"accessKeyId": "AKIDEXAMPLE",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:06:15Z",
"eventSource": "cloudformation.amazonaws.com",
"eventName": "DescribeStacks",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.2.11 Python/2.7.4 Linux/2.6.18-164.el5",
"requestParameters": {
"stackName": "my-test-stack"
},
"responseElements": null,
"requestID": "224f2586-b398-11e3-bb75-a5b75389b02d",
"eventID": "9e5b2fc9-1ba8-409b-9c13-587c2ea940e2"
}
```
次の例では、Alice が `my-test-stack` スタックの `DeleteStack` オペレーションを呼び出したことを示しています。
```
{
"eventVersion": "1.01",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDAABCDEFGHIJKLNMOPQ",
"arn": "arn:aws:iam::012345678910:user/Alice",
"accountId": "012345678910",
"accessKeyId": "AKIDEXAMPLE",
"userName": "Alice"
},
"eventTime": "2014-03-24T21:07:15Z",
"eventSource": "cloudformation.amazonaws.com",
"eventName": "DeleteStack",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "aws-cli/1.2.11 Python/2.7.4 Linux/2.6.18-164.el5",
"requestParameters": {
"stackName": "my-test-stack"
},
"responseElements": null,
"requestID": "42dae739-b398-11e3-bb75-a5b75389b02d",
"eventID": "4965eb38-5705-4942-bb7f-20ebe79aa9aa"
}
```
# CloudFormation 内のインフラストラクチャセキュリティ
マネージドサービスである AWS CloudFormation は AWS グローバルネットワークセキュリティで保護されています。AWSセキュリティサービスと AWS がインフラストラクチャを保護する方法については、「[AWSクラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して AWS 環境を設計するには、*セキュリティの柱 - AWS Well-Architected Framework*の[インフラストラクチャ保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)を参照してください。
AWS の発行済み API コールを使用して、ネットワーク経由で CloudFormation にアクセスします。クライアントは以下をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
これらの API オペレーションは任意のネットワークの場所から呼び出すことができますが、CloudFormation ではリソースベースのアクセスポリシーがサポートされているため、ソース IP アドレスに基づく制限を含めることができます。また、CloudFormation ポリシーを使用して、特定の Amazon Virtual Private Cloud (Amazon VPC) エンドポイントあるいは特定の VPC からのアクセスを制御することもできます。これにより、実質的に CloudFormation ネットワーク内の特定の VPC からの特定の AWS リソースへのネットワークアクセスが分離されます。
# CloudFormation での耐障害性
AWS のグローバルインフラストラクチャは AWS リージョンとアベイラビリティーゾーンを中心に構築されます。AWSリージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立および隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、ゾーン間で中断することなく自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、および拡張性が優れています。
AWS リージョンとアベイラビリティーゾーンの詳細については、[AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)を参照してください。
# のコンプライアンス検証CloudFormation
AWS のサービス が特定のコンプライアンスプログラムの対象であるかどうかを確認するには、「[コンプライアンスプログラムによる対象範囲内の AWS のサービス](https://aws.amazon.com/compliance/services-in-scope/)」をご覧いただき、関心のあるコンプライアンスプログラムを選択してください。一般的な情報については、[AWSコンプライアンスプログラム](https://aws.amazon.com/compliance/programs/) を参照してください。
AWS Artifact を使用して、サードパーティーの監査レポートをダウンロードできます。詳細については、[AWS Artifact でレポートをダウンロードする](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) を参照してください。
AWS のサービスを使用する際のお客様のコンプライアンス責任は、お客様のデータの機密性や貴社のコンプライアンス目的、適用可能な法律および規制によって決定されます。AWS のサービスを使用する際のコンプライアンス責任の詳細については、「[AWS セキュリティドキュメント](https://docs.aws.amazon.com/security/)」を参照してください。
# CloudFormation での構成と脆弱性の分析
構成および IT 管理は、AWS とお客様の間で共有される責任です。詳細については、AWS [責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)を参照してください。
# CloudFormation のセキュリティのベストプラクティス
CloudFormation には、独自のセキュリティポリシーを開発および実装する際に考慮する必要のあるいくつかのセキュリティ機能が用意されています。以下のベストプラクティスは一般的なガイドラインであり、完全なセキュリティソリューションに相当するものではありません。これらのベストプラクティスはお客様の環境に必ずしも適切または十分でない可能性があるので、処方箋ではなく、あくまで有用な検討事項とお考えください。
**Topics**
+ [IAM を使用したアクセス制御](#use-iam-to-control-access)
+ [テンプレートに認証情報を埋め込まない](#creds)
+ [AWS CloudTrail を使用して CloudFormation 呼び出しをログに記録する](#cloudtrail)
## IAM を使用したアクセス制御
IAM は AWS のユーザーとそのアクセス許可を管理できる AWS サービスです。IAM と CloudFormation を使用して、スタックテンプレートの表示、スタックの作成、スタックの削除など、ユーザーが実行できる CloudFormation アクションを指定できます。さらに、CloudFormation スタックを管理するには、そのスタックのリソースに対するアクセス許可が必要です。例えば、ユーザーが CloudFormation を使用して Amazon EC2 インスタンスを、起動、更新、終了する場合、そのユーザーは関連する Amazon EC2 アクションを呼び出すアクセス許可を持っている必要があります。
ほとんどの場合、ユーザーはテンプレート内のすべてのリソースを管理するためにフルアクセスを必要とします。CloudFormation は、ユーザーに代わってこれらのリソースを作成、変更、削除するための呼び出しを行います。ユーザーと CloudFormation サービスの間でアクセス許可を分割するには、サービスロールを使用します。CloudFormation は、ユーザーのポリシーの代わりにサービスロールのポリシーを使用して呼び出しを行います。詳細については、「[CloudFormation サービスロール](using-iam-servicerole.md)」を参照してください。
## テンプレートに認証情報を埋め込まない
CloudFormation テンプレートに機密情報を埋め込むのではなく、スタックテンプレートで動的なリファレンスを使用することをお勧めします。**
動的なリファレンスにより、AWS Systems Manager パラメータストアや AWS Secrets Manager などの他のサービスで保存、管理されている外部値をスタックテンプレートに指定するためのシンプルで強力な方法が提供されます。動的なリファレンスを使用すると、CloudFormation は、スタックオペレーションおよび変更セットオペレーション中に指定されたリファレンスの値を取得して、その値を適切なリソースに渡します。ただし、CloudFormation が実際の参照値を保存することはありません。詳細については、「[動的参照を使用して他のサービスに格納されている値を取得する](dynamic-references.md)」を参照してください。
[AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) を使用して、データベースやその他のサービスの認証情報を安全に暗号化、保存、取得できます。[AWS Systems Manager パラメータストア](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) は、構成データ管理のための安全な階層型ストレージを提供します。
起動テンプレートのパラメータの詳細については、「[CloudFormation テンプレートの Parameters 構文](parameters-section-structure.md)」を参照してください。
## AWS CloudTrail を使用して CloudFormation 呼び出しをログに記録する
AWS CloudTrail は、AWS アカウントで CloudFormation API コールを実行するすべてのユーザーを追跡します。API 呼び出しは、CloudFormation API、CloudFormation コンソール、バックエンドコンソール、または CloudFormation AWS AWS CLI コマンドの使用時にログに記録されます。ログ記録を有効にして Amazon S3 バケットを指定し、ログを保存します。こうすることで、必要ならばアカウントで誰がどのような CloudFormation 呼び出しを行ったかを監査できます。詳細については、「[AWS CloudTrail による CloudFormation API コールのログ記録](cfn-api-logging-cloudtrail.md)」を参照してください。
# インターフェイスエンドポイントを使用した CloudFormation へのアクセス (AWS PrivateLink)
AWS PrivateLink を使用して、VPC と CloudFormation の間にプライベート接続を作成できます。インターネットゲートウェイ、NAT デバイス、VPN 接続、Direct Connect 接続のいずれかを使用せずに、VPC 内にあるかのように CloudFormation にアクセスできます。VPC 内のインスタンスは CloudFormation にアクセスするためにパブリック IP アドレスを必要としません。
このプライベート接続を確立するには、AWS PrivateLink を利用した*インターフェイスエンドポイント*を作成します。インターフェイスエンドポイントに対して有効にする各サブネットにエンドポイントネットワークインターフェイスを作成します。これらは、CloudFormation 宛てのトラフィックのエントリポイントとして機能するリクエスタ管理型ネットワークインターフェイスです。
CloudFormation は、インターフェイスエンドポイントを介してすべての API アクションの呼び出しをサポートしています。
## CloudFormation VPC エンドポイントに関する考慮事項
インターフェイスエンドポイントを設定する前に、まず、「 *AWS PrivateLinkガイド*」の「[インターフェイス VPC エンドポイントを使用した AWS サービスへのアクセス](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)」で説明されている前提条件を満たしていることを確認してください。
CloudFormation のインターフェイスエンドポイントを設定する場合、以下の追加の前提条件と考慮事項が適用されます。
+ VPC 内にカスタムリソースリクエストまたは待機条件に応答する必要があるリソースがある場合は、それらが必要な CloudFormation 固有の Amazon S3 バケットにアクセスできることを確認してください。CloudFormation では、[カスタムリソース](template-custom-resources.md)リクエストまたは[待機条件](using-cfn-waitcondition.md)への応答をモニタリングするための S3 バケットが各リージョンにあります。テンプレートに VPC 内のカスタムリソースや待機条件が含まれている場合、その VPC のエンドポイントポリシーにより、次のバケットへの応答の送信がユーザーに許可されている必要があります。
+ カスタムリソースの場合、`cloudformation-custom-resource-response-region` バケットへのトラフィックを許可します。カスタムリソースを使用する場合、AWS リージョン名にダッシュは含まれません。例えば、`uswest2`。
+ 待機条件の場合、`cloudformation-waitcondition-region` バケットへのトラフィックを許可します。待機条件を使用する場合、AWS リージョン名にはダッシュが含まれます。例えば、`us-west-2`。
エンドポイントポリシーでこれらのバケットへのトラフィックがブロックされている場合、CloudFormation は応答を受け取らず、スタックオペレーションは失敗します。たとえば、待機条件に応答する必要がある `us-west-2` リージョンの VPC にリソースがある場合、リソースは `cloudformation-waitcondition-us-west-2` バケットに応答を送信できる必要があります。
CloudFormation が現在利用可能な AWS リージョン の一覧については、「*Amazon Web Services 全般のリファレンス* の[CloudFormation エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/cfn.html)」のページを参照してください。
+ 現在、VPC エンドポイントはクロスリージョンの要求をサポートしていません。必ず CloudFormation への API 呼び出しを発行する予定のリージョンでエンドポイントを作成してください。
+ VPC エンドポイントは、Route 53 を介して Amazon が提供する DNS のみをサポートします。独自の DNS を使用したい場合は、条件付き DNS 転送を使用できます。詳細については、「Amazon VPC ユーザーガイド」の「[Amazon VPC の DHCP オプションセット](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)」を参照してください。
+ VPC エンドポイントにアタッチされたセキュリティグループでは、VPC のプライベートサブネットから、ポート 443 で着信接続を許可する必要があります。
## CloudFormation のインターフェイス VPC エンドポイントの作成
CloudFormation 用の VPC エンドポイントは、Amazon VPC コンソールまたは AWS Command Line Interface (AWS CLI) を使用して作成できます。詳細については、「*AWS PrivateLink ガイド*」の「[Create a VPC endpoint](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws)」を参照してください。
以下のサービス名を使用して、CloudFormation 用のインターフェース・エンドポイントを作成します。：
+ **com.amazonaws.*region*.cloudformation** – CloudFormation API オペレーションのエンドポイントを作成します。
インターフェイスエンドポイントのプライベート DNS を有効にすると、リージョンのデフォルト DNS 名を使用して、CloudFormation への API リクエストを実行できます。例えば、`cloudformation.us-east-1.amazonaws.com`。
FIPS 固有のエンドポイントがサポートされている AWS リージョン では、次のサービス名を使用して CloudFormation のインターフェイスエンドポイントを作成することも可能です。
+ **com.amazonaws.*region*.cloudformation-fips** – [Federal Information Processing Standard (FIPS) 140-2](https://aws.amazon.com/compliance/fips/) に準拠する CloudFormation API のエンドポイントを作成します。
CloudFormation エンドポイントの完全なリストについては、「*Amazon Web Services 全般のリファレンス*」の「[CloudFormation endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/cfn.html)」を参照してください。
## CloudFormation 用の VPC エンドポイントポリシーの作成
エンドポイントポリシーは、インターフェイスエンドポイントにアタッチできる IAM リソースです。デフォルトのエンドポイントポリシーでは、インターフェイスエンドポイントを介した CloudFormation へのフルアクセスが許可されています。VPC から CloudFormationに許可されるアクセスを制御するには、カスタム・エンドポイント・ポリシーをインターフェースのエンドポイントにアタッチします。
エンドポイントポリシーは以下の情報を指定します。
+ アクションを実行できるプリンシパル (AWS アカウント、IAM ユーザー、IAM ロール)。
+ 実行可能なアクション。
+ このアクションを実行できるリソース。
詳細については、『*AWS PrivateLink ガイド*』の「[Control access to VPC endpoints using endpoint policies (エンドポイントポリシーを使用して VPC エンドポイントへのアクセスをコントロールする)](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)」を参照してください。
**例: CloudFormation アクション用の VPC エンドポイントポリシー**
以下は、CloudFormation 用のエンドポイントポリシーの例です。エンドポイントにアタッチされると、このポリシーは、すべてのリソースですべてのプリンシパルに、リストされている CloudFormation アクションへのアクセス権を付与します。次の例では、VPC エンドポイントを経由してスタックを作成するアクセス許可をすべてのユーザーに拒否し、CloudFormation サービスの他のすべてのアクションへのフルアクセスを許可します。
```
{
"Statement": [
{
"Action": "cloudformation:*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*"
},
{
"Action": "cloudformation:CreateStack",
"Effect": "Deny",
"Principal": "*",
"Resource": "*"
}
]
}
```