翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Step Functions での ID とアクセスの管理
次のセクションでは、[AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) と Step Functions を使用してリソースにアクセスできるユーザーを制御することにより、リソースをセキュリティで保護する方法について詳しく説明します。たとえば、他の AWS リソースからイベントデータを取得するなど、 AWS リソースにアクセスするためのアクセス許可を持つ認証情報 AWS Step Functions を に提供する方法について説明します。
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。IAM 管理者は、誰を認証するか (サインインさせるか) と、誰に Step Functions リソースの使用を許可するか (アクセス許可を付与するか) を制御します。****IAM は、追加料金なしで AWS のサービス 使用できる です。
## オーディエンス
AWS Identity and Access Management (IAM) の使用方法は、ロールによって異なります。
+ **サービスユーザー** - 機能にアクセスできない場合は、管理者にアクセス許可をリクエストします (「[Step Functions でのアイデンティティとアクセスの問題のトラブルシューティング](security_iam_troubleshoot.md)」を参照)。
+ **サービス管理者** - ユーザーアクセスを決定し、アクセス許可リクエストを送信します (「[が IAM と AWS Step Functions 連携する方法](security_iam_service-with-iam.md)」を参照)
+ **IAM 管理者** - アクセスを管理するためのポリシーを作成します (「[のアイデンティティベースのポリシーの例 AWS Step Functions](security_iam_id-based-policy-examples.md)」を参照)
## アイデンティティを使用した認証
認証とは、ID 認証情報 AWS を使用して にサインインする方法です。、IAM ユーザー AWS アカウントのルートユーザー、または IAM ロールを引き受けることで認証される必要があります。
( AWS IAM アイデンティティセンター IAM Identity Center)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーティッド ID としてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、 は SDK と CLI AWS を提供してリクエストを暗号化して署名します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対するAWS 署名バージョン 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウント ルートユーザー
を作成するときは AWS アカウント、すべての AWS のサービス および リソースへの完全なアクセス権を持つ AWS アカウント *root ユーザー*と呼ばれる 1 つのサインインアイデンティティから始めます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスとして、人間のユーザーが一時的な認証情報 AWS のサービス を使用して にアクセスするには、ID プロバイダーとのフェデレーションを使用する必要があります。
フェ*デレーティッド ID* は、エンタープライズディレクトリ、ウェブ ID プロバイダー、または ID Directory Service ソースの認証情報 AWS のサービス を使用して にアクセスするユーザーです。フェデレーテッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、 AWS IAM アイデンティティセンターをお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[IAM アイデンティティセンターとは](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、特定の個人やアプリケーションに対する特定のアクセス許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細については、*IAM ユーザーガイド*の[「ID プロバイダーとのフェデレーションを使用して にアクセスすることを人間のユーザーに要求する AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集合を指定し、大量のユーザーに対するアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定のアクセス許可を持つアイデンティであり、一時的な認証情報を提供します。ユーザー[から IAM ロール (コンソール) に切り替えるか、 または API オペレーションを呼び出すことで、ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)を引き受けることができます。 AWS CLI AWS 詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。
IAM ロールは、フェデレーションユーザーアクセス、一時的な IAM ユーザーのアクセス許可、クロスアカウントアクセス、クロスサービスアクセス、および Amazon EC2 で実行するアプリケーションに役立ちます。詳細については、*IAM ユーザーガイド* の [IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) を参照してください。
## ポリシーを使用したアクセスの管理
でアクセスを制御する AWS には、ポリシーを作成し、ID AWS またはリソースにアタッチします。ポリシーは、アイデンティティまたはリソースに関連付けられたときにアクセス許可を定義します。 は、プリンシパルがリクエストを行うときにこれらのポリシー AWS を評価します。ほとんどのポリシーは JSON ドキュメント AWS として に保存されます。JSON ポリシードキュメントの詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、どの**プリンシパル**がどの**リソース**に対して、どのような**条件**で**アクション**を実行できるかを定義することで、誰が何にアクセスできるかを指定します。
デフォルトでは、ユーザーやロールにアクセス許可はありません。IAM 管理者は IAM ポリシーを作成してロールに追加し、このロールをユーザーが引き受けられるようにします。IAM ポリシーは、オペレーションの実行方法を問わず、アクセス許可を定義します。
### アイデンティティベースのポリシー
アイデンティティベースのポリシーは、アイデンティティ (ユーザー、グループ、またはロール) にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティがどのリソースに対してどのような条件下でどのようなアクションを実行できるかを制御します。アイデンティティベースポリシーの作成方法については、*IAM ユーザーガイド* の [カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) を参照してください。
アイデンティティベースのポリシーは、*インラインポリシー* (単一の ID に直接埋め込む) または*管理ポリシー* (複数の ID にアタッチされたスタンドアロンポリシー) にすることができます。管理ポリシーとインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。
### リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。例としては、IAM *ロール信頼ポリシー*や Amazon S3 *バケットポリシー*などがあります。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。リソースベースのポリシーでは、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM の AWS マネージドポリシーを使用できません。
### その他のポリシータイプ
AWS は、より一般的なポリシータイプによって付与されるアクセス許可の最大数を設定できる追加のポリシータイプをサポートしています。
+ **アクセス許可の境界** – アイデンティティベースのポリシーで IAM エンティティに付与することのできるアクセス許可の数の上限を設定します。詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** - AWS Organizations内の組織または組織単位の最大のアクセス許可を指定します。詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。
+ **リソースコントロールポリシー (RCP)** – は、アカウント内のリソースで利用できる最大数のアクセス許可を定義します。詳細については、「*AWS Organizations ユーザーガイド*」の「[リソースコントロールポリシー (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)」を参照してください。
+ **セッションポリシー** – ロールまたはフェデレーションユーザーの一時セッションを作成する際にパラメータとして渡される高度なポリシーです。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成されるアクセス許可を理解するのがさらに難しくなります。が複数のポリシータイプが関与する場合にリクエストを許可するかどうか AWS を決定する方法については、*「IAM ユーザーガイド*」の[「ポリシー評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)」を参照してください。
## アクセスコントロール
有効な認証情報があればリクエストを認証できますが、アクセス許可が付与されている場合を除き、Step Functions リソースの作成やアクセスはできません。たとえば、Step Functions ルールに関連付けられた、、Amazon Simple Notification Service (Amazon SNS) AWS Lambda、および Amazon Simple Queue Service (Amazon SQS) ターゲットを呼び出すためのアクセス許可が必要です。
以下のセクションでは、Step Functions の許可の管理方法について説明します。
+ [Step Functions でステートマシンの IAM ロールを作成する](procedure-create-iam-role.md)
+ [Step Functions の管理者以外のユーザー用の詳細なアクセス許可の作成](concept-create-iam-advanced.md)
+ [Step Functions の Amazon VPC エンドポイントの作成](vpc-endpoints.md)
+ [Step Functions が統合サービスの IAM ポリシーを生成する方法](service-integration-iam-templates.md)
+ [分散マップ状態を使用するための IAM ポリシー](iam-policies-eg-dist-map.md)
# が IAM と AWS Step Functions 連携する方法
IAM を使用して Shield へのアクセスを管理する前に、Shield で利用できる IAM の機能について説明します。
次の表に、 で使用できる IAM 機能を示します AWS Step Functions。
| IAM 機能 | Step Functions のサポート |
| --- | --- |
| [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies) | あり |
| [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies) | なし |
| [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions) | あり |
| [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources) | はい |
| [ポリシー条件キー (サービス固有)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | はい |
| [ACL](#security_iam_service-with-iam-acls) | なし |
| [ABAC (ポリシー内のタグ)](#security_iam_service-with-iam-tags) | 部分的 |
| [一時認証情報](#security_iam_service-with-iam-roles-tempcreds) | あり |
| [プリンシパルアクセス権限](#security_iam_service-with-iam-principal-permissions) | あり |
| [サービスロール](#security_iam_service-with-iam-roles-service) | あり |
| [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked) | いいえ |
Step Functions およびその他の AWS のサービスがほとんどの IAM 機能と連携する方法の概要については、IAM *ユーザーガイド*の[AWS 「IAM と連携する のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## Step Functions のアイデンティティベースのポリシー
**アイデンティティベースのポリシーのサポート:** あり
アイデンティティベースポリシーは、IAM ユーザー、ユーザーグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。JSON ポリシーで使用できるすべての要素について知るには、「*IAM ユーザーガイド*」の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### Step Functions のアイデンティティベースのポリシーの例
Step Functions でのアイデンティティベースのポリシーの例については、「[のアイデンティティベースのポリシーの例 AWS Step Functions](security_iam_id-based-policy-examples.md)」を参照してください。
## Step Functions 内のリソースベースのポリシー
**リソースベースのポリシーのサポート:** なし
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS のサービス。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。
## Step Functions のポリシーアクション
**ポリシーアクションのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは、関連するオペレーションを実行するための許可を付与するポリシーで使用されます。
Step Functions アクションのリストを確認するには、「*サービス認可リファレンス*」の「[AWS Step Functionsで定義されるリソース](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsstepfunctions.html)」を参照してください。
Step Functions のポリシーアクションは、アクションの前に以下のプレフィックスを使用します。
```
states
```
単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。
```
"Action": [
"states:action1",
"states:action2"
]
```
Step Functions でのアイデンティティベースのポリシーの例については、「[のアイデンティティベースのポリシーの例 AWS Step Functions](security_iam_id-based-policy-examples.md)」を参照してください。
## Step Functions のポリシーリソース
**ポリシーリソースのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
ACM リソースのタイプとその ARN のリストを確認するには、「*サービス認可リファレンス*」の「[AWS Step Functionsで定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsstepfunctions.html)」を参照してください。どのアクションで各リソースの ARN を指定できるかについては、「[AWS Step Functionsで定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsstepfunctions.html)」を参照してください。
Step Functions でのアイデンティティベースのポリシーの例については、「[のアイデンティティベースのポリシーの例 AWS Step Functions](security_iam_id-based-policy-examples.md)」を参照してください。
## Step Functions の条件キー
**サービス固有のポリシー条件キーのサポート:** あり
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*「IAM ユーザーガイド*」の[AWS 「グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
Step Functions の条件キーのリストを確認するには、「*サービス認可リファレンス*」の「[AWS Step Functionsの条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsstepfunctions.html)」を参照してください。条件キーを使用できるアクションとリソースについては、[「 で定義されるリソース AWS Step Functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsstepfunctions.html)」を参照してください。
ポリシーが Step Functions のサービスプリンシパル名に依存する場合は、`aws:PrincipalServiceName` 条件キーではなく `aws:PrincipalServiceNamesList` [複数値コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-single-vs-multi-valued-context-keys.html#reference_policies_condition-multi-valued-context-keys)に、`states.amazonaws.com` が含まれているかどうかを確認することをお勧めします。`aws:PrincipalServiceName` 条件キーには、サービスプリンシパル名のリストから 1 つのエントリしか含まれず、それが常に `states.amazonaws.com` であるとは限りません。次の条件ブロックでは、`states.amazonaws.com` の有無を確認する例を示しています。
```
{
"Condition": {
"ForAnyValue:StringEquals": {
"aws:PrincipalServiceNamesList": "states.amazonaws.com"
}
}
}
```
Step Functions でのアイデンティティベースのポリシーの例については、「[のアイデンティティベースのポリシーの例 AWS Step Functions](security_iam_id-based-policy-examples.md)」を参照してください。
## Step Functions の ACL
**ACL のサポート:** なし
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
## Step Functions と共に ABAC を使用
**ABAC (ポリシー内のタグ) のサポート:** 一部
属性ベースのアクセスコントロール (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグをアタッチし、プリンシパルのタグがリソースのタグと一致するときにオペレーションを許可するように ABAC ポリシーを設計できます。
タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。
ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。
## Step Functions での一時的な認証情報の使用
**一時的な認証情報のサポート:** あり
一時的な認証情報は AWS 、リソースへの短期的なアクセスを提供し、フェデレーションまたはスイッチロールの使用時に自動的に作成されます。長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成 AWS することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## Step Functions のクロスサービスプリンシパル許可
**転送アクセスセッション (FAS) のサポート:** あり
転送アクセスセッション (FAS) は、 を呼び出すプリンシパルのアクセス許可と AWS のサービス、ダウンストリームサービス AWS のサービス へのリクエストをリクエストする を使用します。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
## Step Functions のサービスロール
**サービスロールのサポート:** あり
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、IAM ユーザーガイド**の [AWS のサービスに許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)を参照してください。
**警告**
サービスロールの許可を変更すると、Step Functions の機能が阻害される可能性があります。Step Functions が指示する場合以外は、サービスロールを編集しないでください。
## Step Functions のサービスにリンクされたロール
**サービスにリンクされたロールのサポート:** なし
サービスにリンクされたロールは、 にリンクされたサービスロールの一種です AWS のサービス。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスにリンクされたロールは に表示され AWS アカウント 、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。
サービスにリンクされたロールの作成または管理の詳細については、「[IAM と提携するAWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。表の「**サービスリンクロール**」列に `Yes` と記載されたサービスを見つけます。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、**[はい]** リンクを選択します。
# のアイデンティティベースのポリシーの例 AWS Step Functions
デフォルトでは、ユーザーおよびロールには、Step Functions リソースを作成または変更するアクセス許可がありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。
これらのサンプルの JSON ポリシードキュメントを使用して IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。
Step Functions が定義するアクションとリソースタイプ (リソースタイプごとの ARN の形式を含む) の詳細については、「*サービス認可リファレンス*」の「[AWS Step Functionsのアクション、リソース、および条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsstepfunctions.html)」を参照してください。
**Topics**
+ [ポリシーに関するベストプラクティス](#security_iam_service-with-iam-policy-best-practices)
+ [Step Functions コンソールを使用する。](#security_iam_id-based-policy-examples-console)
+ [自分の権限の表示をユーザーに許可する](#security_iam_id-based-policy-examples-view-own-permissions)
## ポリシーに関するベストプラクティス
アイデンティティベースのポリシーは、ユーザーのアカウントで誰かが Step Functions リソースを作成、アクセス、または削除できるかを決定します。これらのアクションでは、 AWS アカウントに費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ ** AWS 管理ポリシーを開始し、最小特権のアクセス許可に移行** – ユーザーとワークロードにアクセス許可の付与を開始するには、多くの一般的なユースケースにアクセス許可を付与する*AWS 管理ポリシー*を使用します。これらは で使用できます AWS アカウント。ユースケースに固有の AWS カスタマー管理ポリシーを定義することで、アクセス許可をさらに減らすことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能のAWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、最小特権アクセス許可とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。条件を使用して、サービスアクションが などの特定の を通じて使用されている場合に AWS のサービス、サービスアクションへのアクセスを許可することもできます CloudFormation。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – で IAM ユーザーまたはルートユーザーを必要とするシナリオがある場合は AWS アカウント、MFA をオンにしてセキュリティを強化します。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## Step Functions コンソールを使用する。
AWS Step Functions コンソールにアクセスするには、最小限のアクセス許可のセットが必要です。これらのアクセス許可により、 の Step Functions リソースの詳細を一覧表示および表示できます AWS アカウント。最小限必要な許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) に対してコンソールが意図したとおりに機能しません。
AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。
ユーザーとロールが引き続き Step Functions コンソールを使用できるようにするには、エンティティに Step Functions `ConsoleAccess`または `ReadOnly` AWS 管理ポリシーもアタッチします。詳細については、「*IAM ユーザーガイド*」の「[ユーザーへの許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。
## 自分の権限の表示をユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI または AWS API を使用してプログラムでこのアクションを実行するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# AWS の 管理ポリシー AWS Step Functions
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 を更新すると、ポリシーがアタッチされているすべてのプリンシパル ID (ユーザー、グループ、ロール) に影響します。 AWS は、新しい が起動されるか、新しい API オペレーション AWS のサービス が既存のサービスで使用できるようになったときに、 AWS 管理ポリシーを更新する可能性が最も高くなります。
詳細については、「**IAM ユーザーガイド」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
## AWS マネージドポリシー: AWSStepFunctionsConsoleFullAccess
[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSStepFunctionsConsoleFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSStepFunctionsConsoleFullAccess.html) ポリシーを IAM アイデンティティにアタッチできます。
このポリシーは、ユーザーが Step Functions コンソールを使用してアクセスするための*管理者*アクセス許可を付与します。コンソールをフルに活用するには、ユーザーはサービスが引き受けることが可能な他の IAM ロールに iam:PassRole 許可が必要な場合があります。
## AWS マネージドポリシー: AWSStepFunctionsReadOnlyAccess
[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSStepFunctionsReadOnlyAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSStepFunctionsReadOnlyAccess.html) ポリシーを IAM アイデンティティにアタッチできます。
このポリシーは、ユーザーまたはロールがステートマシン、アクティビティ、実行、タグ、MapRuns、ステートマシンのエイリアスとバージョンを一覧表示および記述できるようにする*読み取り専用*アクセス許可を付与します。このポリシーは、指定したステートマシン定義の構文を確認するアクセス許可も付与します。
## AWS マネージドポリシー: AWSStepFunctionsFullAccess
[https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSStepFunctionsFullAccess.html](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSStepFunctionsFullAccess.html) ポリシーを IAM アイデンティティにアタッチできます。
このポリシーは、Step Functions API を使用するための*完全な*アクセス許可をユーザーまたはロールに付与します。フルアクセスを得るには、ユーザーはサービスが引き受けることが可能な IAM ロールに対して、最低 1 つの *iam:PassRole* 許可が付与される必要があります。
## AWS 管理ポリシーに対する Step Functions の更新
このサービスがこれらの変更の追跡を開始してからの Step Functions の AWS マネージドポリシーの更新に関する詳細を表示します。このページへの変更に関する自動アラートについては、Step Functions [ドキュメント履歴](document-history.md) ページの RSS フィードを購読してください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWSStepFunctionsReadOnlyAccess](#security-iam-awsmanpol-AWSStepFunctionsReadOnlyAccess) - 既存のポリシーの更新 | Step Functions は、`states:ValidateStateMachineDefinition` API アクションを呼び出して、指定したステートマシン定義の構文をチェックできるようにする新しいアクセス許可を追加しました。 | 2024 年 4 月 25 日 |
| [AWSStepFunctionsReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSStepFunctionsReadOnlyAccess.html) - 既存のポリシーの更新 | Step Functions は、タグ (ListTagsForResource)、分散マップ (ListMapRuns 、DescribeMapRun)、Versions and Aliases (DescribeStateMachineAlias、ListStateMachineAliases、ListStateMachineVersions) に関連するデータの一覧表示と読み取りを許可する新しいアクセス許可を追加しました。 | 2024 年 4 月 2 日 |
| Step Functions が変更の追跡を開始 | Step Functions は AWS 、管理ポリシーの変更の追跡を開始しました。 | 2024 年 4 月 2 日 |
# Step Functions でステートマシンの IAM ロールを作成する
AWS Step Functions はコードを実行し、 AWS リソース ( 関数の AWS Lambda 呼び出しなど) にアクセスできます。セキュリティを維持するために、IAM ロールを使用してこれらのリソースへの Step Functions アクセスを許可する必要があります。
[Step Functions を学習するためのチュートリアル](learning-resources.md#tutorials) このガイドの を使用すると、ステートマシンを作成する AWS リージョンで有効な自動生成された IAM ロールを利用できます。ただし、ステートマシンの IAM ロールを独自に作成することもできます。
ステートマシンの IAM ポリシーを作成する場合、そのポリシーにはステートマシンに付与する許可を含める必要があります。既存の AWS 管理ポリシーを例として使用することも、特定のニーズを満たすカスタムポリシーを最初から作成することもできます。詳細については、「*IAM ユーザーガイド*」 の「[IAM ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
ステートマシンの IAM ロールを独自に作成するには、このセクションの手順に従います。
この例では、Lambda 関数を呼び出す許可を持つIAM ロールを作成します。
## Step Functions のロールの作成
1. [IAM コンソール](https://console.aws.amazon.com/iam/home)にサインインし、**[ロール]**、**[ロールの作成]** の順に選択します。
1. **[信頼できるエンティティ]** ページの **[AWS サービス]** で、リストから **[Step Functions]** を選択し、**[次へ：許可]** を選択します。
1. **[アタッチされた許可ポリシー]** ページで、**[次へ：確認]** を選択します。
1. **[確認]** ページで、`StepFunctionsLambdaRole` を **[ロール名]** に入力し、**[ロールの作成]** を選択します。
ロールのリストで、IAM ロールが表示されます。
IAM 許可とポリシーの詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html)」の「*アクセス管理*」を参照してください。
## サービス間の混乱した代理の防止
混乱した代理問題は、アクションを実行する許可を持たないエンティティが、より権限のあるエンティティにアクションの実行を強制できるセキュリティ上の問題です。では AWS、サービス間のなりすましにより、混乱した代理問題が発生する可能性があります。サービス間でのなりすましは、1 つのサービス (*呼び出し元サービス*) が、別のサービス (*呼び出し対象サービス*) を呼び出すときに発生する場合もあります。この種のなりすましは、クロスアカウントおよびクロスサービスで発生するおそれがあります。呼び出し元サービスが操作され、それ自身のアクセス許可が利用されて、本来アクセス許可が付与されない形で、別のユーザーのリソースに働きかけることがあります。
混乱した代理を防ぐために、 は、アカウント内のリソースへのアクセス権が付与されたサービスプリンシパルを持つすべてのサービスのデータを保護するのに役立つツール AWS を提供します。このセクションでは、 固有のサービス間の混乱した代理の防止に焦点を当てています AWS Step Functionsが、このトピックの詳細については、*IAM ユーザーガイド*の[混乱した代理の問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)セクションを参照してください。
リソースポリシーで [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) のグローバル条件コンテキストキーを使用して、Step Functions が他のサービスに付与する、そのリソースに対するアクセス許可を制限することをお勧めします。クロスサービスアクセスにリソースを 1 つだけ関連付けたい場合は、`aws:SourceArn` を使用します。そのアカウント内のリソースをクロスサービスの使用に関連付けることを許可する場合は、`aws:SourceAccount` を使用します。
混乱した代理問題から保護するために最も効果的なのは、リソースの完全な ARN で `aws:SourceArn` グローバル条件コンテキストキーを使用する方法です。リソースの完全な ARN が不明な場合や、複数のリソースを指定する場合には、ARN の未知部分を表すワイルドカード文字 (`*`) を使って、グローバルコンテキスト条件キー `aws:SourceArn` を使用します。例えば、`arn:aws:states:*:111122223333:*`。
混乱した代理問題を防止するために、*信頼できるポリシー*の中で Step Functions と `aws:SourceArn` および `aws:SourceAccount` を使用する例を、以下に示します。
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"Service":[
"states.amazonaws.com"
]
},
"Action":"sts:AssumeRole",
"Condition":{
"ArnLike":{
"aws:SourceArn":"arn:aws:states:us-east-1:111122223333:stateMachine:*"
},
"StringEquals":{
"aws:SourceAccount":"111122223333"
}
}
}
]
}
```
## インラインポリシーをアタッチする
`Task` 状態の他のサービスを Step Functions で直接制御できます。制御する必要があるサービスの API アクションに Step Functions がアクセスできるように、インラインポリシーをアタッチします。
1. [IAM コンソール](https://console.aws.amazon.com/iam/home) を開いて **[ロール]** を選択し、Step Functions ロールを検索したら、そのロールを選択します。
1. **[インラインポリシーの追加]** を選択します。
1. ロールのポリシーを作成するには、**[ビジュアルエディタ]** か **[JSON]** タブを使用します。
AWS Step Functions が他の AWS サービスをコントロールする方法の詳細については、「」を参照してください[サービスと Step Functions の統合](integrate-services.md)。
**注記**
Step Functions コンソールで作成した IAM ポリシーの例については、[Step Functions が統合サービスの IAM ポリシーを生成する方法](service-integration-iam-templates.md) を参照してください。
# Step Functions の管理者以外のユーザー用の詳細なアクセス許可の作成
などの IAM のデフォルトの管理ポリシーは`ReadOnly`、すべてのタイプの AWS Step Functions アクセス許可を完全にカバーするわけではありません。このセクションでは、これらさまざまなタイプのアクセス許可について説明し、設定例を示します。
Step Functions には、4 つのカテゴリの許可があります。ユーザーに許可するアクセスに応じたカテゴリのアクセス許可の使用によって、アクセスを制御できます。
[サービスレベルのアクセス許可](#concept-create-iam-advanced-service)
特定のリソースで動作**しない** API コンポーネントに適用されます。
[ステートマシンレベルのアクセス許可](#concept-create-iam-advanced-state)
特定のステートマシンで動作するすべての API コンポーネントに適用されます。
[実行レベルのアクセス許可](#concept-create-iam-advanced-execution)
特定の実行で動作するすべての API コンポーネントに適用されます。
[アクティビティレベルのアクセス許可](#concept-create-iam-advanced-activity)
特定のアクティビティまたはその特定のインスタンスで動作するすべての API コンポーネントに適用されます。
## サービスレベルのアクセス許可
このアクセス権限レベルは、特定のリソースで動作**しない**すべての API アクションに適用されます。例えば、`[CreateStateMachine](https://docs.aws.amazon.com/step-functions/latest/apireference/API_CreateStateMachine.html)`、`[CreateActivity](https://docs.aws.amazon.com/step-functions/latest/apireference/API_CreateActivity.html)`、`[ListStateMachines](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListStateMachines.html)`、`[ListActivities](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListActivities.html)`、`[ValidateStateMachineDefinition](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ValidateStateMachineDefinition.html)` などです。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"states:ListStateMachines",
"states:ListActivities",
"states:CreateStateMachine",
"states:CreateActivity",
"states:ValidateStateMachineDefinition"
],
"Resource": [
"arn:aws:states:*:*:*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/my-execution-role"
]
}
]
}
```
## ステートマシンレベルのアクセス許可
このアクセス許可レベルは、特定のステートマシンで動作するすべての API アクションに適用されます。`[DeleteStateMachine](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DeleteStateMachine.html)`、`[DescribeStateMachine](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DescribeStateMachine.html)`、`[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)`、`[ListExecutions](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListExecutions.html)` などのリクエストの一部として、これらの API オペレーションにはステートマシンの Amazon リソースネーム (ARN) が必要です。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"states:DescribeStateMachine",
"states:StartExecution",
"states:DeleteStateMachine",
"states:ListExecutions",
"states:UpdateStateMachine",
"states:TestState",
"states:RevealSecrets"
],
"Resource": [
"arn:aws:states:*:*:stateMachine:StateMachinePrefix*"
]
}
]
}
```
## 実行レベルのアクセス許可
このアクセス許可レベルは、特定の実行で動作するすべての API アクションに適用されます。`[DescribeExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DescribeExecution.html)`、`[GetExecutionHistory](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetExecutionHistory.html)`、`[StopExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StopExecution.html)` などのリクエストの一部として、これらの API オペレーションには実行の ARN が必要です。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"states:DescribeExecution",
"states:DescribeStateMachineForExecution",
"states:GetExecutionHistory",
"states:StopExecution"
],
"Resource": [
"arn:aws:states:*:*:execution:*:ExecutionPrefix*"
]
}
]
}
```
## アクティビティレベルのアクセス許可
このアクセス許可レベルは、特定のアクティビティまたはその特定のインスタンスで動作するすべての API アクションに適用されます。`[DeleteActivity](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DeleteActivity.html)`、`[DescribeActivity](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DescribeActivity.html)`、`[GetActivityTask](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html)`、`[SendTaskHeartbeat](https://docs.aws.amazon.com/step-functions/latest/apireference/API_SendTaskHeartbeat.html)` などのリクエストの一部として、これらの API オペレーションにはアクティビティの ARN かインスタンスのトークンが必要です。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"states:DescribeActivity",
"states:DeleteActivity",
"states:GetActivityTask",
"states:SendTaskHeartbeat"
],
"Resource": [
"arn:aws:states:*:*:activity:ActivityPrefix*"
]
}
]
}
```
# Step Functions の他の AWS アカウント のリソースへのアクセス
Step Functions は、ワークフロー AWS アカウント のさまざまな で設定されたリソースへのクロスアカウントアクセスを提供します。Step Functions サービス統合を使用すると、 が AWS リソースベースのポリシーまたはクロスアカウント呼び出しをサポート AWS のサービス していない場合でも、任意のクロスアカウントリソースを呼び出すことができます。
たとえば、開発とテストという AWS アカウント 2 つの を同じ に所有しているとします AWS リージョン。クロスアカウントアクセスを使用すると、「Development」アカウントのワークフローは、「Testing」アカウントで使用可能な Amazon S3 バケット、Amazon DynamoDB テーブル、Lambda 関数などのリソースにアクセスできます。
**重要**
IAM ロールとリソースベースのポリシーは、単一のパーティション内のアカウント間でのみアクセスを委任します。例えば、標準 `aws` パーティションの米国西部 (北カリフォルニア)と、`aws-cn` パーティションの中国 (北京) にアカウントがあるとします。中国 (北京) アカウントの Amazon S3 リソースベースのポリシーを使用して、標準 `aws` アカウントのユーザーにアクセスを許可することはできません。
クロスアカウントアクセスの詳細については、「*IAM ユーザーガイド*」の「[クロスアカウントポリシーの評価論理](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html)」を参照してください。
各 AWS アカウント は独自のリソースを完全に制御しますが、Step Functions を使用すると、コードをカスタマイズすることなくワークフロー内のステップを再編成、スワップ、追加、または削除できます。これは、プロセスが変わったりアプリケーションが進化したりしても可能です。
また、ネストしたステートマシンの実行を呼び出して、さまざまなアカウントで利用可能にすることもできます。これにより、ワークフローを効率的に分離して切り離すことができます。異なるアカウントの別の Step Functions ワークフローにアクセスするワークフローの中で、[`.sync`](connect-to-resource.md#connect-sync) サービス統合パターンを使用する場合、Step Functions のポーリングは自身の割り当てクオータを消費します。詳細については、「[ジョブの実行 (.sync)](connect-to-resource.md#connect-sync)」を参照してください。
**注記**
クロスリージョン AWS SDK 統合とクロスリージョン AWS リソースアクセスは、Step Functions では使用できません。
## クロスアカウントの主なリソースの概念
**[実行ロール](procedure-create-iam-role.md)**
Step Functions がコードを実行し、 AWS Lambda 関数の呼び出しアクションなどの AWS リソースにアクセスするために使用する IAM ロール。
**[サービス統合](integrate-services.md)**
ワークフロー`Task`の状態内から呼び出すことができる AWS SDK 統合 API アクション。
**ソースアカウント**
ステートマシン AWS アカウント を所有し、実行を開始した 。
**ターゲットアカウント**
クロスアカウント呼び出しを行う AWS アカウント 。
**ターゲットロール**
ターゲットアカウントが所有するリソースへの呼び出しを行う際に、ステートマシンが引き受けるターゲットアカウントの IAM ロール
**[ジョブの実行 (.sync)](connect-to-resource.md#connect-sync)**
などの サービスを呼び出すために使用されるサービス統合パターン AWS Batch。またこれにより、 Step Functions のステートマシンはジョブの完了まで待機してから次の状態に進みます。Step Functions の待機を指示するには、`Task` 状態の `Resource` フィールドに `.sync` サフィックスを追加します。
## クロスアカウントリソースの呼び出し
ワークフローで、クロスアカウントリソースを呼び出すには次の操作を行います。
1. リソースを含むターゲットアカウントに IAM ロールを作成します。このロールは、ステートマシンを含むソースアカウントに、ターゲットアカウントのリソースにアクセスするアクセス許可を付与します。
1. `Task` ステートの定義で、クロスアカウントリソースを呼び出す前にステートマシンが引き受けるターゲット IAM ロールを指定します。
1. ターゲット IAM ロールの信頼ポリシーを変更して、ソースアカウントがこのロールを一時的に引き受けることができるようにします。信頼ポリシーには、ソースアカウントで定義したステートマシンの Amazon リソースネーム (ARN) を含める必要があります。また、 AWS リソースを呼び出すための適切なアクセス許可をターゲット IAM ロールに定義します。
1. ソースアカウントの実行ロールを更新して、ターゲット IAM ロールを引き受けるのに必要なアクセス許可を含めます。
例として、チュートリアルの「[Step Functions でのクロスアカウント AWS リソースへのアクセス](tutorial-access-cross-acct-resources.md)」を参照してください。
**注記**
複数の AWS アカウントからリソースにアクセスするための IAM ロールを引き受けるようにステートマシンを設定できます。ただし、ステートマシンが一度に引き受けられる IAM ロールは、1 つだけです。
![\[クロスアカウントリソースへのアクセス概念図\]](http://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/images/cross-account-support-concept.png)
## .sync 統合パターンへのクロスアカウントアクセス
ワークフローで `.sync` サービス統合パターンを使用すると、Step Functions は呼び出されたクロスアカウントリソースをポーリングして、タスクの完了を確認します。これにより、実際のタスク完了時間と Step Functions がタスク完了を認識する時間との間に若干の遅延が生じます。このポーリングループを完了させるには、ターゲットの IAM ロールが `.sync` の呼び出しに必要な許可を持つ必要があります。これを行うには、ターゲットの IAM ロールの信頼ポリシーで、ソースアカウントによる引き受けを許可する必要があります。さらに、ターゲットの IAM ロールにはポーリングループを完了させるための許可が必要です。
**注記**
現在、`arn:aws:states:::states:startExecution.sync` はネストされた Express ワークフローをサポートしていません。代わりに `arn:aws:states:::aws-sdk:sfn:startSyncExecution` を使用します。
### .sync 呼び出しのための信頼ポリシーの更新
次の例に示すように、ターゲットの IAM ロールの信頼ポリシーを更新します。`sts:ExternalId` フィールドでは、ロールを引き受けられるユーザーをさらに制御できます。ステートマシンの名前には、API が AWS Security Token Service `AssumeRole`サポートする文字のみを含める必要があります。詳細については、「*AWS Security Token Service API リファレンス*」の「[AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)」を参照してください。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Principal": {
"AWS": "arn:aws:iam::sourceAccountID:role/InvokeRole",
},
"Condition": {
"StringEquals": {
"sts:ExternalId": "arn:aws:states:us-east-2:sourceAccountID:stateMachine:stateMachineName"
}
}
}
]
}
```
### .sync 呼び出しに必要な許可
ステートマシンに必要な許可を付与するには、ターゲット IAM ロールの必要な許可を更新します。詳細については、「[Step Functions が統合サービスの IAM ポリシーを生成する方法](service-integration-iam-templates.md)」を参照してください。例えばステートマシンを起動するには、以下の許可を追加します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"states:StartExecution"
],
"Resource": [
"arn:aws:states:us-east-1:123456789012:stateMachine:myStateMachineName"
]
},
{
"Effect": "Allow",
"Action": [
"states:DescribeExecution",
"states:StopExecution"
],
"Resource": [
"arn:aws:states:us-east-1:123456789012:execution:myStateMachineName:*"
]
}
]
}
```
# Step Functions の Amazon VPC エンドポイントの作成
Amazon Virtual Private Cloud (Amazon VPC) を使用して AWS リソースをホストする場合は、Amazon VPC と AWS Step Functions ワークフロー間の接続を確立できます。公開インターネットと交差せずに、この Step Functions ワークフローとの接続を使用できます。Amazon VPC エンドポイントは、Standard ワークフロー、Express ワークフロー、同期 Express ワークフローでサポートされています。
Amazon VPC では、カスタム仮想ネットワークで AWS リソースを起動できます。VPC を使用して、IP アドレス範囲、サブネット、ルートテーブル、ネットワークゲートウェイなどのネットワーク設定を制御できます。Amazon VPC の詳細については、「[Amazon VPC ユーザーガイド](https://docs.aws.amazon.com/vpc/latest/userguide/)」を参照してください。
Amazon VPC を Step Functions に接続するには、まず*インターフェイス VPC エンドポイント*を定義する必要があります。これにより、VPC を他の AWS サービスに接続できます。このエンドポイントを使用すると、インターネットゲートウェイやネットワークアドレス変換 (NAT) インスタンス、または VPN 接続などを必要とせずに、信頼性の高いスケーラブルな方法で接続できるようになります。詳細については、「*Amazon VPC ユーザーガイド*」の「[インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html)」を参照してください。
## エンドポイントを作成する
VPC で AWS Step Functions エンドポイントを作成するには AWS マネジメントコンソール、 AWS Command Line Interface 、 (AWS CLI)、 AWS SDK、 AWS Step Functions API、または を使用します CloudFormation。
Amazon VPC コンソールまたは AWS CLIを使用して、エンドポイントを作成および設定する方法については、「*Amazon VPC ユーザーガイド*」の「[インターフェイスエンドポイントの作成](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint)」を参照してください。
**注記**
エンドポイントを作成するとき、VPC の接続先のサービスとして Step Functions を指定します。Amazon VPC コンソールでは、サービス名は AWS リージョンによって異なります。例えば、米国東部 (バージニア北部) を選択した場合、Standard ワークフロー と Express ワークフロー のサービス名は **com.amazonaws.us-east-1.states** であり、同期 Express ワークフロー のサービス名は **com.amazonaws.us-east-1.sync-states** です。
**注記**
[プライベート DNS](https://docs.aws.amazon.com/vpc/latest/privatelink/verify-domains.html) を通じて、SDK のエンドポイントをオーバーライドせずに VPC エンドポイントを使用できます。ただし、同期 Express ワークフロー用の SDK のエンドポイントをオーバーライドする場合は、`DisableHostPrefixInjection` 構成を `true` に設定する必要があります。例 (Java SDK V2):
```
SfnClient.builder()
.endpointOverride(URI.create("https://vpce-{vpceId}.sync-states.us-east-1.vpce.amazonaws.com"))
.overrideConfiguration(ClientOverrideConfiguration.builder()
.advancedOptions(ImmutableMap.of(SdkAdvancedClientOption.DISABLE_HOST_PREFIX_INJECTION, true))
.build())
.build();
```
を使用してエンドポイントを作成および設定する方法については CloudFormation、「 *CloudFormation ユーザーガイド*」の[AWS::EC2::VPCEndpoint](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpcendpoint.html) リソース」を参照してください。
## Amazon VPC エンドポイントポリシー
Step Functions への接続アクセスを制御するには、Amazon VPC エンドポイントの作成中に AWS Identity and Access Management (IAM) エンドポイントポリシーをアタッチします。複数のエンドポイントポリシーをアタッチすることで、複雑な IAM ルールを作成できます。詳細については、以下を参照してください。
+ [Step Functions 用 Amazon Virtual Private Cloud エンドポイントのポリシー](#vpc-iam)
+ [Step Functions の管理者以外のユーザー用の詳細なアクセス許可の作成](concept-create-iam-advanced.md)
+ [VPC エンドポイントによるサービスのアクセス制御](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html)
## Step Functions 用 Amazon Virtual Private Cloud エンドポイントのポリシー
Step Functions 用 Amazon VPC エンドポイントのポリシーを作成できます。このポリシーでは以下を指定します。
+ アクションを実行できるプリンシパル。
+ 実行可能なアクション。
+ このアクションを実行できるリソース。
以下は、1 人の IAM ユーザーにステートマシンの作成を許可し、他のすべての IAM ユーザーからのステートマシン削除権限を拒否できる Amazon VPC エンドポイントのポリシーの例です。またこのサンプルポリシーでは、すべてのユーザーに対して実行許可を付与します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"states:ListExecutions", "states:StartExecution", "states:StopExecution", "states:DescribeExecution"
],
"Resource": "*",
"Effect": "Allow",
"Principal": "*"
},
{
"Action": "states:CreateStateMachine",
"Resource": "*",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/MyUser"
}
},
{
"Action": "states:DeleteStateMachine",
"Resource": "*",
"Effect": "Deny",
"Principal": "*"
}
]
}
```
エンドポイントポリシーの作成の詳細については、以下を参照してください。
+ [Step Functions の管理者以外のユーザー用の詳細なアクセス許可の作成](concept-create-iam-advanced.md)
+ [VPC エンドポイントによるサービスのアクセス制御](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html)
# Step Functions が統合サービスの IAM ポリシーを生成する方法
AWS Step Functions コンソールでステートマシンを作成すると、Step Functions は AWS Identity and Access Management ステートマシン定義で使用されるリソースに基づいて、次のように (IAM) ポリシーを生成します。
+ **最適化統合**では、Step Functions はステートマシンに必要なすべてのアクセス許可とロールを含むポリシーを作成します。
ヒント: 「[最適化サービスの統合](integrate-optimized.md)」の各サービスページでポリシーの例を見ることができます。
+ **標準統合**では、Step Functions は一部のアクセス許可のみを含む IAM ロールを作成します。
ステートマシンにサービスとのやり取りに必要なロールポリシーが不足している場合は、自分で追加する必要があります。
## 動的リソースと静的リソース
*静的リソース*は、ステートマシンのタスクステートで**直接**定義します。タスクステートで直接呼び出すリソースに関する情報を含めると、Step Functions はそのリソースのみの IAM ロールを作成できます。
*動的リソース*は、ステートマシンの開始時、または個々のステートへの入力として**渡され**、JSONata または JSONPath を使用してアクセスされます。タスクに動的リソースを渡す場合、Step Functions はアクセス許可を自動的に絞り込むことができないため、`"Resource": "*"` を指定する、より寛容なポリシーを作成します。
## .sync を使用するタスクに必要な追加のアクセス許可
[ジョブを実行 (.sync)](connect-to-resource.md#connect-sync) パターンを使用するタスクは、接続されたサービスの API からのレスポンスをモニタリングおよび受信するために、追加のアクセス許可が必要です。
Step Functions は、接続されたサービスでジョブが実行されると、**ポーリング**と**イベント**の 2 つの方法でジョブのステータスをモニタリングします。
ポーリングには `Describe` または `Get` API アクションに対するアクセス許可が必要です。例えば、Amazon ECS の場合、ステートマシンには の許可アクセス許可が必要です。 AWS Glue ステートマシン`ecs:DescribeTasks`には の許可アクセス許可が必要です`glue:GetJobRun`。必要なアクセス許可がロールにない場合、Step Functions はジョブのステータスを判断できないことがあります。ポーリングメソッドを使用する理由の 1 つは、一部のサービス統合は EventBridge イベントをサポートしておらず、一部のサービスはベストエフォートでのみイベントを送信するためです。
または、 AWS サービスから Amazon EventBridge に送信されたイベントを使用することもできます。イベントはマネージドルールを使用して EventBridge から Step Functions にルーティングされるため、ロールには `events:PutTargets`、`events:PutRule`、`events:DescribeRule` のアクセス許可が必要です。これらのアクセス許可がロールにない場合、Step Functions がジョブの完了を認識するまでに遅延が発生する可能性があります。EventBridge イベントの詳細については、「 [AWS サービスのイベント](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-service-event.html)」を参照してください。
## スタックした .sync ワークフローのトラブルシューティング
ポーリングとイベントの**両方**をサポートする [ジョブを実行] (.sync) タスクでは、ロールにポーリングのアクセス許可がなくても、イベントを使用してタスクが正常に完了する場合があります。
このような場合、ポーリングのアクセス許可が不足していることや正しくないことに気付かない可能性があります。イベントが Step Functions に届かないまたは処理されないまれなケースでは、実行がスタックする可能性があります。
ポーリングのアクセス許可が正しく設定されていることを確認するには、次の方法で EventBridge イベントのない環境で実行を試してみてください。
+ Step Functions にイベントを転送している EventBridge のマネージドルールを削除します。
**注記**
このマネージドルールはアカウント内のすべてのステートマシンで共有されるため、他のステートマシンへの意図しない影響を避けるために、テストアカウントまたは開発アカウントを使用する必要があります。
+ 削除する特定のマネージドルールは、ターゲットサービスのポリシーテンプレートで `events:PutRule` に使用する `Resource` フィールドを検査して特定できます。マネージドルールは、そのサービス統合を使用するステートマシンを次回作成または更新するときに再度作成されます。
+ EventBridge ルールの削除に関する詳細については、「[ルールの無効化と削除](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-delete-rule.html)」を参照してください。
## ワークフローをキャンセルするためのアクセス許可
[ジョブを実行] (.sync) パターンを使用するタスクが停止すると、Step Functions はベストエフォートでタスクをキャンセルしようとします。
タスクのキャンセルには、`Cancel`、`Stop`、`Terminate`、または `Delete` の API アクション (`batch:TerminateJob` や `eks:DeleteCluster` など) に対するアクセス許可が必要です。ロールにこれらの許可がない場合、Step Functions はタスクをキャンセルできず、タスクの実行中に追加料金が発生する可能性があります。タスク停止の詳細については、[ジョブ実行](connect-to-resource.md#connect-sync)を参照してください。
**統合パターンの詳細**
同期タスクについては、「[Step Functions でサービス統合パターンを検出する](connect-to-resource.md)」を参照してください。
## アクティビティのみの Step Functions ステートマシンの IAM ポリシー
`Activity` タスクのみを持つステートマシン、またはタスクをまったく持たないステートマシンでは、すべてのアクションとリソースへのアクセスを拒否する IAM ポリシーを使用します。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*"
}
]
}
```
` Activity ` タスクの使用の詳細については、[Step Functions のアクティビティについて](concepts-activities.md) を参照してください。
# 分散マップ状態を使用するための IAM ポリシー
Step Functions コンソールでワークフローを作成すると、Step Functions はワークフロー定義内のリソースに基づいて IAM ポリシーを自動的に生成できます。生成されたポリシーには、ステートマシンロールが*分散マップ状態の* `[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)` API アクションを呼び出し、Amazon S3 バケットやオブジェクト、Lambda 関数などの AWS リソースにアクセスするために必要な最小限の権限が含まれます。
IAM ポリシーには必要最小限のアクセス許可のみを含めることをお勧めします。例えば、ワークフローに分散モードの `Map` ステートが含まれている場合、ポリシーの範囲を対象データが含まれる特定の Amazon S3 バケットおよびフォルダに絞り込みます。
**重要**
*分散マップ状態*の入力で、既存のキーと値のペアへの[参照パス](amazon-states-language-paths.md#amazon-states-language-reference-paths)とともに、Amazon S3 バケットやオブジェクト、またはプレフィックスを指定する場合は、ワークフローの IAM ポリシーを必ず更新してください。ポリシーの範囲は、ランタイムでパスから解釈されるバケット名とオブジェクト名に限定します。
## 分散マップ状態を実行するための IAM ポリシーの例
ワークフローに*分散マップ状態*を含める場合、Step Functions には、ステートマシンのロールで*分散マップ状態*の `[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)` API アクションを呼び出すための適切な許可が必要です。
次の IAM ポリシー例では、ステートマシンのロールで*分散マップ状態*を実行するために必要な最小特権を付与しています。
**注記**
必ず `stateMachineName` を、*分散マップ状態*を使用しているステートマシン名に置き換えてください。例えば、`arn:aws:states:region:account-id:stateMachine:mystateMachine`。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"states:StartExecution"
],
"Resource": [
"arn:aws:states:us-east-1:123456789012:stateMachine:myStateMachineName"
]
},
{
"Effect": "Allow",
"Action": [
"states:DescribeExecution"
],
"Resource": "arn:aws:states:us-east-1:123456789012:execution:myStateMachineName:*"
}
]
}
```
## 分散マップの IAM redriving ポリシーの例
失敗した子ワークフローは、[親ワークフロー](state-map-distributed.md#dist-map-orchestrate-parallel-workloads-key-terms)のマップ実行で [redriving](redrive-executions.md) できます。redriven された親ワークフローは、分散マップを含むすべての失敗状態を redrives します。実行ロールには、親ワークフローで `[RedriveExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_RedriveExecution.html)` API アクションを呼び出すために必要な最小特権があることを確認してください。
次の IAM ポリシー例では、ステートマシンのロールで*分散マップ状態*を redriving (再処理) するために必要な最小特権を付与しています。
**注記**
必ず `stateMachineName` を、*分散マップ状態*を使用しているステートマシン名に置き換えてください。例えば、`arn:aws:states:region:account-id:stateMachine:mystateMachine`。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"states:RedriveExecution"
],
"Resource": "arn:aws:states:us-east-2:123456789012:execution:myStateMachineName/myMapRunLabel:*"
}
]
}
```
## Amazon S3 データセットからデータを読み取る IAM ポリシーの例
次の例では、[ListObjectsV2](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html) および [GetObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html) API アクションを使用して Amazon S3 データセットにアクセスするための最小特権を付与する方法を示しています。
**Example Amazon S3 オブジェクトをデータセットとして使用する条件**
次の条件は、Amazon S3 バケットの `processImages` フォルダ内のオブジェクトにアクセスするための最小特権を付与します。
```
"Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ],
"Condition": {
"StringLike": {
"s3:prefix": [ "processImages" ]
}
}
```
**Example CSV ファイルをデータセットとして使用する**
次の例では、`ratings.csv` という名前の CSV ファイルにアクセスするために必要なアクションを示しています。
```
"Action": [ "s3:GetObject" ],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket/csvDataset/ratings.csv"
]
```
**Example Amazon S3 インベントリをデータセットとして使用する**
次に示しているのは、Amazon S3 インベントリマニフェストとデータファイルのリソースの例です。
```
"Resource": [
"arn:aws:s3:::myPrefix/amzn-s3-demo-bucket/myConfig-id/YYYY-MM-DDTHH-MMZ/manifest.json",
"arn:aws:s3:::myPrefix/amzn-s3-demo-bucket/myConfig-id/data/*"
]
```
**Example ListObjectsV2 を使用してフォルダプレフィックスに制限する**
[ListObjectsV2](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObjectsV2.html) を使用する場合、2 つのポリシーが生成されます。1 つはバケット (`ListBucket`) の内容を**一覧表示**するための、もう 1 つはバケット (`GetObject`) 内の**オブジェクトを取得**するためのポリシーです。
次に示しているのは、アクション、リソース、条件の例です。
```
"Action": [ "s3:ListBucket" ],
"Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ],
"Condition": {
"StringLike": {
"s3:prefix": [ "/path/to/your/json/" ]
}
}
```
```
"Action": [ "s3:GetObject" ],
"Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket/path/to/your/json/*" ]
```
`GetObject` ではスコープを設定せず、オブジェクトにワイルドカード (`*`) を使用することに注意してください。
## Amazon S3 バケットにデータを書き込むための IAM ポリシーの例
次の IAM ポリシーの例では `[PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html)` API アクションを使用して、Amazon S3 バケット内にある *csvJobs* という名前のフォルダに、子ワークフローの実行結果を書き込むために必要な最小特権を付与しています。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListMultipartUploadParts",
"s3:AbortMultipartUpload"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-destination-bucket/csvJobs/*"
]
}
]
}
```
### AWS KMS key 暗号化された Amazon S3 バケットの IAM アクセス許可
*分散マップ状態*では、マルチパートアップロードを使用して Amazon S3 バケットに子ワークフローの実行結果を書き込みます。バケットが AWS Key Management Service (AWS KMS) キーを使用して暗号化されている場合は、キーに対して `kms:Decrypt`、`kms:Encrypt`、`kms:GenerateDataKey` アクションを実行する許可も、IAM ポリシーに含める必要があります。マルチパートアップロードを完了する前に、暗号化されたファイル部分からデータを復号して読み取る必要があるため、Amazon S3 にはこれらの許可が必要です。
次の IAM ポリシーの例では、Amazon S3 バケットの暗号化に使用されるキーに対する `kms:Decrypt`、`kms:Encrypt`、および `kms:GenerateDataKey` アクションに許可を付与します。
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:GenerateDataKey"
],
"Resource": [
"arn:aws:kms:us-east-1:123456789012:key/111aa2bb-333c-4d44-5555-a111bb2c33dd"
]
}
}
```
詳細については、*AWS ナレッジセンター*の「[AWS KMS keyで暗号化した大容量ファイルを Amazon S3 にアップロードする](https://aws.amazon.com/premiumsupport/knowledge-center/s3-large-file-encryption-kms-key/)」を参照してください。
IAM ユーザーまたはロールが AWS アカウント と同じ にある場合はKMS key、キーポリシーに対するこれらのアクセス許可が必要です。IAM ユーザーまたはロールが KMS key とは異なるアカウントに属している場合、キーポリシーへのアクセス許可と、 IAM ユーザーまたはロールへのアクセス許可が両方とも必要です。
# Step Functions でのタグベースの IAM ポリシーの作成
Step Functions は、タグベースのポリシーをサポートしています。例えば、キー `environment` および値 `production` のタグを含むすべての Step Functions リソースへのアクセスを制限できます。
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"states:TagResource",
"states:UntagResource",
"states:DeleteActivity",
"states:DeleteStateMachine",
"states:StopExecution"
],
"Resource": "*",
"Condition": {
"StringEquals": {"aws:ResourceTag/environment": "production"}
}
}
]
}
```
このポリシーでは、ステートマシンまたはアクティビティを削除する機能、実行を停止する機能、および `environment/production` としてタグ付けされているすべてのリソースに対してタグを追加または削除する機能を `Deny` (拒否) します。
次の例のように、タグベースの認可の場合、ステートマシンの実行リソースはステートマシンに関連付けられたタグを継承します。
```
arn:partition:states:region:account-id:execution::
```
実行リソース ARN を指定する [DescribeExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DescribeExecution.html) またはその他の API を呼び出すとき、Step Functions はタグベースの認可を実行しながら、ステートマシンに関連付けられたタグを使用してリクエストを許可または拒否します。これにより、ステートマシンレベルの実行へのアクセスを許可または拒否できます。
タグ付けの詳細については、以下を参照してください。
+ [Step Functions でのステートマシンとアクティビティのタグ付け](sfn-best-practices.md#concepts-tagging)
+ [IAM タグを使用したアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_iam-tags.html)
# Step Functions でのアイデンティティとアクセスの問題のトラブルシューティング
次の情報は、Step Functions と IAM の使用時に発生する可能性のある、一般的な問題の診断や修復に役立ちます。
**Topics**
+ [Step Functions でアクションを実行する権限がない](#security_iam_troubleshoot-no-permissions)
+ [iam:PassRole を実行する権限がありません](#security_iam_troubleshoot-passrole)
+ [自分の 以外のユーザーに Step Functions リソース AWS アカウント へのアクセスを許可したい](#security_iam_troubleshoot-cross-account-access)
## Step Functions でアクションを実行する権限がない
アクションを実行する権限がないというエラーが表示された場合は、そのアクションを実行できるようにポリシーを更新する必要があります。
以下のエラー例は、`mateojackson` ユーザーがコンソールを使用して架空の `my-example-widget` リソースに関する詳細情報を表示しようとしているが、架空の `states:GetWidget` 許可がないという場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: states:GetWidget on resource: my-example-widget
```
この場合、Mateo のポリシーでは、`my-example-widget` アクションを使用して `states:GetWidget` リソースへのアクセスを許可するように更新する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン認証情報を提供した担当者が管理者です。
## iam:PassRole を実行する権限がありません
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合は、ポリシーを更新して Step Functions にロールを渡せるようにする必要があります。
一部の AWS のサービス では、新しいサービスロールまたはサービスにリンクされたロールを作成する代わりに、そのサービスに既存のロールを渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
以下のエラー例は、`marymajor` という名前の IAM ユーザーがコンソールを使用して、Step Functions でアクションを実行した場合に発生します。ただし、このアクションをサービスが実行するには、サービスロールから付与された許可が必要です。Mary には、ロールをサービスに渡すアクセス許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary のポリシーを更新してメアリーに `iam:PassRole` アクションの実行を許可する必要があります。
サポートが必要な場合は、 AWS 管理者にお問い合わせください。サインイン資格情報を提供した担当者が管理者です。
## 自分の 以外のユーザーに Step Functions リソース AWS アカウント へのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください:
+ Step Functions がこれらの機能をサポートしているかどうかを確認するには、「[が IAM と AWS Step Functions 連携する方法](security_iam_service-with-iam.md)」を参照してください。
+ 所有 AWS アカウント している のリソースへのアクセスを提供する方法については、[「IAM ユーザーガイド」の「所有 AWS アカウント している別の の IAM ユーザーへのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。 **
+ リソースへのアクセスをサードパーティーに提供する方法については AWS アカウント、*IAM ユーザーガイド*の[「サードパーティー AWS アカウント が所有する へのアクセスを提供する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)」を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、*IAM ユーザーガイド* の [外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) を参照してください。
+ クロスアカウントアクセスにおけるロールとリソースベースのポリシーの使用方法の違いについては、「*IAM ユーザーガイド*」の「[IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)」を参照してください。