# データ転送ターミナルのアイデンティティとアクセス管理 AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御するのに役立つ AWS のサービスです。IAM 管理者は、誰が *認証* (サインイン) され、データ転送ターミナルリソースを使用する*権限* (許可) を受けるかを制御します。IAM は、AWS のサービスで追加料金は発生しません。 **Topics** + [ ## オーディエンス ](#security-iam-audience) + [ ## アイデンティティによる認証 ](#security-iam-authentication) + [ ## ポリシーを使用したアクセス権の管理 ](#security-iam-access-manage) + [ # データ転送ターミナルと IAM の連携方法 ](security-iam-service-with-iam.md) ## オーディエンス AWS Identity and Access Management (IAM) の使用方法は、データ転送ターミナルで行う作業に応じて異なります。 **サービスユーザー** – 業務を行うためにデータ転送ターミナルサービスを使用する場合は、管理者から必要な認証情報と許可が提供されます。さらに多くのデータ転送ターミナル機能を使用して作業を行う場合は、追加のアクセス許可が必要になることがあります。アクセスの管理方法を理解すると、管理者に適切なアクセス許可をリクエストするのに役に立ちます。データ転送ターミナルの機能にアクセスできない場合は、「[AWS データ転送ターミナルのアイデンティティとアクセスのトラブルシューティング](security-iam-troubleshoot.md)」を参照してください。 **サービス管理者** – 社内のデータ転送ターミナルリソースを担当している場合は、通常、データ転送ターミナルへのフルアクセスがあります。サービスユーザーがアクセスするデータ転送ターミナル機能やリソースを決めるのは管理者の仕事です。その後、IAM 管理者にリクエストを送信して、サービスユーザーの権限を変更する必要があります。このページの情報を点検して、IAM の基本概念を理解してください。会社でデータ転送ターミナルと IAM を併用する方法の詳細については、「[データ転送ターミナルと IAM の連携方法](security-iam-service-with-iam.md)」を参照してください。 **IAM 管理者** – 管理者は、データ転送ターミナルへのアクセスを管理するポリシーの作成方法の詳細について確認する場合があります。IAM で使用できるデータ転送ターミナルのアイデンティティベースポリシーの例については、「[AWS データ転送ターミナルのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。 ## アイデンティティによる認証 認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、AWS アカウントのルートユーザーもしくは IAM ユーザーとして、または IAM ロールを引き受けることによって、*認証を受ける* (AWS にサインインする) 必要があります。 ID ソースから提供された認証情報を使用して、フェデレーティッドアイデンティティとして AWS にサインインできます。AWSフェデレーティッドアイデンティティの例としては、IAM アイデンティティセンター (IAM アイデンティティセンター) ユーザー、貴社のシングルサインオン認証、Google または Facebook の認証情報などがあります。フェデレーティッド ID としてサインインする場合、IAM ロールを使用して、前もって管理者により ID フェデレーションが設定されています。フェデレーションを使用して AWSにアクセスする場合、間接的にロールを引き受けることになります。 ユーザーのタイプに応じて、AWS マネジメントコンソールまたは AWS アクセスポータルにサインインできます。AWS へのサインインの詳細については、「*AWS サインインユーザーガイド*」の「[AWS アカウントにサインインする方法](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。 プログラムを使用して AWS にアクセスする場合、AWSは Software Development Kit (SDK) とコマンドラインインターフェイス (CLI) を提供し、認証情報を使用してリクエストに暗号で署名します。AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。リクエストに自分で署名する推奨方法の使用については、「*IAM ユーザーガイド*」の「[API リクエストに対する AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。 使用する認証方法を問わず、追加セキュリティ情報の提供をリクエストされる場合もあります。例えば、AWS は、アカウントのセキュリティを強化するために多要素認証 (MFA) を使用することをお勧めします。詳細については、「**AWS IAM Identity Center ユーザーガイド」の「[多要素認証](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-mfa.html)」および「*IAM ユーザーガイド*」の「[IAM の AWS 多要素認証](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html)」を参照してください。 ### AWS アカウントのルートユーザー AWS アカウントを作成する場合は、このアカウントのすべての AWS サービスとリソースに対して完全なアクセス権を持つ 1 つのサインインアイデンティティから始めます。このアイデンティティは AWS アカウント*ルートユーザー*と呼ばれ、アカウントの作成に使用したメールアドレスとパスワードでのサインインによりアクセスされます。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー資格情報は保護し、ルートユーザーでしか実行できないタスクを実行するときに使用します。ルートユーザーとしてサインインする必要があるタスクの完全なリストについては、「*IAM ユーザーガイド*」の「[ルートユーザー資格情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。 ### フェデレーテッドアイデンティティ ベストプラクティスとして、管理者アクセスを必要とするユーザーを含む人間のユーザーに対し、ID プロバイダーとのフェデレーションを使用して、一時的な認証情報の使用により、AWS サービスにアクセスすることを要求します。 *フェデレーション ID* は、エンタープライズユーザーディレクトリ、ウェブ ID プロバイダー、AWS Directory Service、Identity Center ディレクトリのユーザー、または ID ソースから提供された認証情報を使用して AWS のサービスにアクセスするユーザーです。フェデレーティッド ID が AWS アカウントにアクセスすると、ロールを引き受け、そのロールによって一時的な認証情報が提供されます。 アクセスを一元管理する場合は、AWS IAM Identity Center を使用することをお勧めします。IAM Identity Center でユーザーとグループを作成するか、すべての AWS アカウントとアプリケーションで使用するために、独自の ID ソースで一連のユーザーとグループに接続して同期することもできます。IAM Identity Center の詳細については、「**AWS IAM Identity Center ユーザーガイド」の「[IAM Identity Center とは何ですか?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。 ### IAM ユーザーとグループ **[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)は、単一のユーザーまたはアプリケーションに対する特定の許可を持つ AWS アカウント内のアイデンティティです。可能であれば、パスワードやアクセスキーなどの長期的な認証情報を保有する IAM ユーザーを作成する代わりに、一時的な認証情報を使用することをお勧めします。ただし、IAM ユーザーでの長期的な認証情報が必要な特定のユースケースがある場合は、アクセスキーをローテーションすることをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[長期的な認証情報を必要とするユースケースのためにアクセスキーを定期的にローテーションする](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#rotate-credentials)」を参照してください。 [IAM グループ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)は、IAM ユーザーの集団を指定するアイデンティティです。グループとしてサインインすることはできません。グループを使用して、複数のユーザーに対して一度に権限を指定できます。多数のユーザーグループがある場合、グループを使用することで権限の管理が簡単になります。例えば、*IAMAdmins* という名前のグループを設定して、そのグループに IAM リソースを管理する許可を与えることができます。 ユーザーは、ロールとは異なります。ユーザーは 1 人の人または 1 つのアプリケーションに一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。ユーザーには永続的な長期の認証情報がありますが、ロールでは一時認証情報が提供されます。詳細については、「*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)は、特定のアクセス許可を持つ、AWS アカウント内のアイデンティティです。これは IAM ユーザーに似ていますが、特定のユーザーに関連付けられていません。AWS マネジメントコンソールで IAM ロールを一時的に引き受けるには、[ユーザーから IAM ロール に切り替える (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ことができます。ロールを引き受けるには、AWS CLI または AWS API オペレーションを呼び出すか、カスタム URL を使用します。ロールを使用する方法の詳細については、「*IAM ユーザーガイド*」の「[ロールを引き受けるための各種方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)」を参照してください。 IAM ロールと一時的な認証情報は、次の状況で役立ちます: + **フェデレーションユーザーアクセス** – フェデレーティッド ID に許可を割り当てるには、ロールを作成してそのロールの許可を定義します。フェデレーテッド ID が認証されると、その ID はロールに関連付けられ、ロールで定義されている許可が付与されます。フェデレーションのロールについては、*IAM ユーザーガイド* の [サードパーティー ID プロバイダー (フェデレーション) 用のロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) を参照してください。IAM Identity Center を使用する場合は、許可セットを設定します。アイデンティティが認証後にアクセスできるものを制御するため、IAM Identity Center は、権限セットを IAM のロールに関連付けます。アクセス許可セットの詳細については、「*AWS IAM Identity Center ユーザーガイド*」の「[アクセス許可セット](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)」を参照してください。 + **一時的な IAM ユーザー権限** - IAM ユーザーまたはロールは、特定のタスクに対して複数の異なる権限を一時的に IAM ロールで引き受けることができます。 + **クロスアカウントアクセス** - IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを、別のアカウントの人物 (信頼済みプリンシパル) に許可できます。ロールは、クロスアカウントアクセスを許可する主な方法です。ただし、一部の AWS のサービスでは、 (ロールをプロキシとして使用する代わりに) リソースにポリシーを直接アタッチできます。クロスアカウントアクセスにおけるロールとリソースベースのポリシーの違いについては、「*IAM ユーザーガイド*」の「[IAM でのクロスアカウントのリソースへのアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)」を参照してください。 + **クロスサービスアクセス** – 一部の AWS のサービスは、AWS の他のサービスの機能を使用します。例えば、サービスで呼び出しを行うと、通常そのサービスによって Amazon EC2 でアプリケーションが実行されたり、Amazon S3 にオブジェクトが保存されたりします。サービスは、呼び出し元のプリンシパルの許可、サービスロール、サービスリンクロールを使用してこれを行う場合があります。 + **転送アクセスセッション (FAS)** – IAM ユーザーまたはロールを使用して AWS でアクションを実行するユーザーは、プリンシパルと見なされます。一部のサービスを使用する際に、アクションを実行することで、別のサービスの別のアクションがトリガーされることがあります。FAS は、AWS サービスを呼び出すプリンシパルの権限を、AWS サービスのリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストは、サービスが、完了するために他の AWS サービスまたはリソースとのやりとりを必要とするリクエストを受け取ったときにのみ行われます。この場合、両方のアクションを実行するためのアクセス許可が必要です。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。 + **サービスロール** - サービスがユーザーに代わってアクションを実行するために引き受ける [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)」を参照してください。 + **サービスリンクロール** – サービスリンクロールは、AWS のサービスにリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。 + **Amazon EC2 で実行されているアプリケーション** – EC2 インスタンスで実行され、AWS CLI または AWS API リクエストを作成しているアプリケーションの一時的な認証情報を管理するには、IAM ロールを使用します。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。AWS ロールを EC2 インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスに添付されたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時的な認証情報を取得できます。詳細については、「*IAM ユーザーガイド*」の「[Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用して許可を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)」を参照してください。 ## ポリシーを使用したアクセス権の管理 AWS でアクセスを制御するには、ポリシーを作成して AWS ID またはリソースにアタッチします。ポリシーは AWS のオブジェクトであり、アイデンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、プリンシパル (ユーザー、ルートユーザー、またはロールセッション) がリクエストを行うと、これらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWSに保存されます。JSON ポリシードキュメントの構造と内容の詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。 管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。 デフォルトでは、ユーザーやロールに権限はありません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。その後、管理者はロールに IAM ポリシーを追加し、ユーザーはロール引き継ぐことができます。 IAM ポリシーは、オペレーションの実行方法を問わず、アクションの許可を定義します。例えば、`iam:GetRole` アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からロールの情報を取得できます。 ### アイデンティティベースポリシー アイデンティティベースのポリシーは、IAM ユーザーグループ、ユーザーのグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。 アイデンティティベースのポリシーは、さらに*インラインポリシー*または*マネージドポリシー*に分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれています。管理ポリシーは、AWS アカウント内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンポリシーです。マネージドポリシーには、AWS マネージドポリシーとカスタマーマネージドポリシーがあります。マネージドポリシーまたはインラインポリシーのいずれかを選択する方法については、「*IAM ユーザーガイド*」の「[管理ポリシーとインラインポリシーのいずれかを選択する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)」を参照してください。 ### リソースベースのポリシー リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[[specify a principal]](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) (プリンシパルを指定する) 必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または AWS のサービスを含めることができます。 リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM からの AWS マネージド型ポリシーを使用することはできません。 ### アクセスコントロールリスト (ACL) アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。 Amazon S3、AWS WAF、および Amazon VPC は、ACL をサポートするサービスの例です。ACL の詳細については、*Amazon Simple Storage Service デベロッパーガイド* の [アクセスコントロールリスト (ACL) の概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) を参照してください。 ### その他のポリシータイプ AWS では、他の一般的ではないポリシータイプをサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の権限を設定できます。 + **アクセス許可の境界** - アクセス許可の境界は、アイデンティティベースポリシーによって IAM エンティティ (IAM ユーザーまたはロール) に付与できる権限の上限を設定する高度な機能です。エンティティにアクセス許可の境界を設定できます。結果として得られるアクセス許可は、エンティティのアイデンティティベースポリシーとそのアクセス許可の境界の共通部分になります。`Principal` フィールドでユーザーまたはロールを指定するリソースベースのポリシーでは、アクセス許可の境界は制限されません。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。アクセス許可の境界の詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティのアクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。 + **サービスコントロールポリシー (SCP)** – SCP とは、AWS Organizations 内の組織または組織単位 (OU) に対し、アクセス許可の上限を指定するための JSON ポリシーです。AWSOrganizations は、ビジネスが所有する複数の AWS アカウントを、グループ化および一元管理するためのサービスです。組織内のすべての機能を有効にすると、サービスコントロールポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP はメンバーアカウントのエンティティに対するアクセス許可を制限します (各 AWS アカウントルートユーザーなど)。Organizations と SCP の詳細については、「*AWS Organizations ユーザーガイド*」の「[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)」を参照してください。 + **リソースコントロールポリシー (RCP)** – RCP は、所有する各リソースにアタッチされた IAM ポリシーを更新することなく、アカウント内のリソースに利用可能な最大数のアクセス許可を設定するために使用できる JSON ポリシーです。RCP は、メンバーアカウントのリソースの許可を制限し、組織に属するかどうかにかかわらず、AWS アカウントルートユーザーを含む ID のための有効な許可に影響を及ぼす可能性があります。RCP をサポートする AWS のリストを含む Organizations と RCP の詳細については、「**AWS ユーザーガイド」の「[リソースコントロールポリシー (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) を参照してください。 # データ転送ターミナルと IAM の連携方法 IAM を使用して データ転送ターミナルへのアクセスを管理する前に、データ転送ターミナル で使用できる IAM 機能について理解しておく必要があります。 | IAM の特徴量 | データ転送ターミナルのサポート | | --- | --- | | [アイデンティティベースのポリシー](#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) | 不可 | データ転送ターミナルおよびその他の AWS サービスと大部分の IAM 機能の連携についての概要は、「*IAM ユーザーガイド*」の「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。 ## データ転送ターミナルのアイデンティティベースのポリシー **ID ベースのポリシーのサポート:** あり アイデンティティベースポリシーは、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)」を参照してください。 ### データ転送ターミナルのアイデンティティベースのポリシーの例 データ転送ターミナルのアイデンティティベースポリシーの例を確認するには、「[AWS データ転送ターミナルのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。 ## データ転送ターミナル内のリソースベースのポリシー **リソースベースのポリシーのサポート:** なし リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[[specify a principal]](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) (プリンシパルを指定する) 必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または AWS のサービスを含めることができます。 クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。リソースベースのポリシーにクロスアカウントのプリンシパルを追加しても、信頼関係は半分しか確立されない点に注意してください。プリンシパルとリソースが異なる AWS アカウントにある場合、信頼されたアカウントの IAM 管理者は、リソースにアクセスするための許可をプリンシパルエンティティ (ユーザーまたはロール) に付与する必要もあります。IAM 管理者は、ID ベースのポリシーをエンティティにアタッチすることで許可を付与します。ただし、リソースベースのポリシーで、同じアカウントのプリンシパルへのアクセス権が付与されている場合は、アイデンティティベースのポリシーをさらに付与する必要はありません。詳細については、「*IAM ユーザーガイド*」の「[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)」を参照してください。 ## データ転送ターミナルのポリシーアクション **ポリシーアクションのサポート:** あり 管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。 JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。ポリシーアクションの名前は通常、関連する AWS API オペレーションと同じです。一致する API オペレーションのない*アクセス許可のみのアクション*など、いくつかの例外があります。また、ポリシーに複数のアクションが必要なオペレーションもあります。これらの追加アクションは*依存アクション*と呼ばれます。 このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。 データ転送ターミナルアクションのリストを確認するには、「*サービス認可リファレンス*」の「[AWS データ転送ターミナルで定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-actions-as-permissions)」を参照してください。 データ転送ターミナルのポリシーアクションは、アクションの前に次のプレフィックスを使用します。 ``` datatransferterminal ``` 単一のステートメントで複数のアクションを指定するには、アクションをカンマで区切ります。 ``` "Action": [ "datatransferterminal:action1", "datatransferterminal:action2" ] ``` データ転送ターミナルのアイデンティティベースポリシーの例を確認するには、「[AWS データ転送ターミナルのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。 ## データ転送ターミナルのポリシーリソース **ポリシーリソースのサポート:** あり 管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件**下で**アクション**を実行できるかということです。 `Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ステートメントには`Resource` または `NotResource` 要素を含める必要があります。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。これは*リソースレベルの許可*と呼ばれる特定のリソースタイプをサポートするアクションに対して実行できます。 オペレーションのリスト化など、リソースレベルの許可をサポートしないアクションの場合はステートメントがすべてのリソースに適用されることを表示するワイルドカード (\$1) を使用します。 ``` "Resource": "*" ``` データ転送ターミナルリソースのタイプとその ARN のリストを確認するには、「*サービス認可リファレンス*」の「[AWS データ転送ターミナルで定義されるリソース](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-resources-for-iam-policies)」を参照してください。どのアクションで各リソースの ARN を指定できるかについては、「[AWS データ転送ターミナルで定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-actions-as-permissions)」を参照してください。 データ転送ターミナルのアイデンティティベースポリシーの例を確認するには、「[AWS データ転送ターミナルのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。 ## データ転送ターミナルのポリシー条件キー **サービス固有のポリシー条件キーのサポート:** あり 管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。 `Condition` 要素（または `Condition`block) lets you specify conditions in which a statement is in effect. The `Condition` 要素はオプションです。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。 1 つのステートメントに複数の `Condition` 要素を指定する場合、または 1 つの `Condition` 要素に複数のキーを指定する場合、AWS では `AND` 論理演算子を使用してそれらを評価します。単一の条件キーに複数の値を指定する場合、AWS では `OR` 論理演算子を使用して条件を評価します。ステートメントのアクセス許可が付与される前に、すべての条件が満たされる必要があります。 条件を指定する際にプレースホルダー変数も使用できます。例えば IAM ユーザーに、IAM ユーザー名がタグ付けされている場合のみリソースにアクセスできる権限を付与することができます。詳細については、「*IAM ユーザーガイド*」の「[‬IAM ポリシーの要素: 変数およびタグ‭](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html)」‬を参照してください。 AWS はグローバル条件キーとサービス固有の条件キーをサポートしています。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を参照してください。 データ転送ターミナルの条件キーのリストを確認するには、「*サービス認可リファレンス*」の「[AWS データ転送ターミナルの条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-policy-keys)」を参照してください。条件キーを使用できるアクションとリソースについては、「[AWS データ転送ターミナルで定義されるアクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-actions-as-permissions)」を参照してください。 データ転送ターミナルのアイデンティティベースポリシーの例を確認するには、「[AWS データ転送ターミナルのアイデンティティベースのポリシーの例](security-iam-id-based-policy-examples.md)」を参照してください。 ## データ転送ターミナルの ACL **ACL のサポート:** なし アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。 ## データ転送ターミナルでの ABAC **ABAC (ポリシー内のタグ) のサポート:** なし 属性ベースのアクセス制御 (ABAC) は、属性に基づいてアクセス許可を定義する認可戦略です。AWS では、属性は*タグ*と呼ばれます。タグは、IAM エンティティ (ユーザーまたはロール)、および多数の AWS リソースにアタッチできます。エンティティとリソースのタグ付けは、ABAC の最初の手順です。次に、プリンシパルのタグが、アクセスを試行するリソースのタグと一致したときにオペレーションを許可するよう、ABAC ポリシーを設計します。 ABAC は、急成長する環境や、ポリシー管理が煩雑になる状況で役に立ちます。 タグに基づいてアクセスを制御するには、`aws:ResourceTag/[replaceable]`key-name` `, , or aws:TagKeys condition keys.` を使用するポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)のタグ情報を指定します。サービスがすべてのリソースタイプで 3 つの条件キーすべてをサポートしている場合、値はサービスに対して **Yes** です。サービスが一部のリソースタイプに対してのみ 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)」を参照してください。 ### データ転送ターミナルでの一時的な認証情報の使用 **一時的な認証情報のサポート:** あり AWS サービスには、一時的な認証情報を使用してサインインしても機能しないものがあります。一時的な認証情報を利用できる AWS のサービスを含めた詳細情報については、「*IAM ユーザーガイド*」の「[IAM と連携する AWS サービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。 ユーザー名とパスワード以外の方法で AWS マネジメントコンソールにサインインする場合は、一時認証情報を使用していることになります。例えば、会社の Single Sign-On (SSO) リンクを使用して AWS にアクセスすると、そのプロセスは自動的に一時的な認証情報を作成します。また、ユーザーとしてコンソールにサインインしてからロールを切り替える場合も、一時的な認証情報が自動的に作成されます。ロールの切り替えに関する詳細については、「*IAM ユーザーガイド*」の「[ユーザーから IAM ロールに切り替える (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)」を参照してください。 一時的な認証情報は、AWS CLI または AWS API を使用して手動で作成できます。作成後、一時認証情報を使用して AWS にアクセスできるようになります。AWSは、長期的なアクセスキーを使用する代わりに、一時認証情報を動的に生成することをお勧めします。詳細については、「[IAM の一時的セキュリティ認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」を参照してください。 ### データ転送ターミナルのクロスサービスプリンシパルアクセス許可 **転送アクセスセッション (FAS) のサポート:** なし IAM ユーザーまたはロールを使用して AWS でアクションを実行するユーザーは、プリンシパルとみなされます。一部のサービスを使用する際に、アクションを実行することで、別のサービスの別のアクションがトリガーされることがあります。FAS は、AWS サービスを呼び出すプリンシパルの権限を、AWS サービスのリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストは、サービスが、完了するために他の AWS サービスまたはリソースとのやりとりを必要とするリクエストを受け取ったときにのみ行われます。この場合、両方のアクションを実行するためのアクセス許可が必要です。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。 ### データ転送ターミナルのサービスロール **サービスロールのサポート:** なし サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [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)」を参照してください。 **警告** サービスロールの権限を変更すると、データ転送ターミナルの機能が停止する可能性があります。データ転送ターミナルが指示する場合以外は、サービスロールを編集しないでください。 ### データ転送ターミナルのサービスにリンクされたロール **サービスにリンクされたロールのサポート:** なし サービスにリンクされたロールは、AWS のサービスにリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。 サービスにリンクされたロールの作成または管理の詳細については、「[IAM と提携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。表の「**サービスリンクロール**」列に `Yes` と記載されたサービスを見つけます。サービスにリンクされたロールに関するドキュメントをサービスで表示するには、**[はい]** リンクを選択します。 # AWS データ転送ターミナルのアイデンティティベースのポリシーの例 デフォルトでは、ユーザーおよびロールにはデータ転送ターミナルリソースを作成または変更するアクセス許可がありません。また、AWS マネジメントコンソール、AWS コマンドラインインターフェイス (AWS CLI)、または AWS API を使用してタスクを実行することもできません。IAM 管理者は、リソースで必要なアクションを実行するための権限をユーザーに付与する IAM ポリシーを作成できます。その後、管理者はロールに IAM ポリシーを追加し、ユーザーはロールを引き継ぐことができます。 これらサンプルの JSON ポリシードキュメントを使用して、IAM アイデンティティベースのポリシーを作成する方法については、「*IAM ユーザーガイド*」の「[IAM ポリシーを作成する (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)」を参照してください。 定義されるアクションとリソースタイプ (リソースタイプごとの ARN の形式など) の詳細については、「**サービス認可リファレンス」の「[アクション](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html)」を参照してください。 **Topics** + [ ## ポリシーに関するベストプラクティス ](#security-iam-service-with-iam-policy-best-practices) + [ ## データ転送ターミナルコンソールの使用 ](#security-iam-id-based-policy-examples-console) + [ ## 自分の権限の表示をユーザーに許可する ](#security-iam-id-based-policy-examples-view-own-permissions) ## ポリシーに関するベストプラクティス アイデンティティベースのポリシーは、ユーザーのアカウント内で誰かがデータ転送ターミナルリソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションを実行すると、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 などの特定の AWS サービスを介して使用する場合、条件を使用してサービスアクションへのアクセスを許可することもできます。詳細については、*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) を要求する** – AWS アカウントで IAM ユーザーまたはルートユーザーを要求するシナリオがある場合は、セキュリティを強化するために 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) を参照してください。 ## データ転送ターミナルコンソールの使用 AWS データ転送ターミナルコンソールにアクセスするには、許可の最小限のセットが必要です。これらの許可では、AWS アカウントでのデータ転送ターミナルリソースに関する詳細のリスト化と表示が許可されている必要があります。最小限必要な許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) に対してコンソールが意図したとおりに機能しません。 AWS CLI または AWS API のみを呼び出すユーザーには、コンソールの最小アクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスを許可します。 ユーザーとロールが引き続きデータ転送ターミナルコンソールを使用できるようにするには、エンティティにデータ転送ターミナル ` 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 データ転送ターミナルのアイデンティティとアクセスのトラブルシューティング 次の情報は、データ転送ターミナルと IAM の使用に伴って発生する可能性がある一般的な問題の診断や修復に役立ちます。 **Topics** + [ ## データ転送ターミナルでアクションを実行する権限がありません ](#security-iam-troubleshoot-no-permissions) + [ ## AWS アカウントの外部のユーザーにデータ転送ターミナルリソースへのアクセスを許可したい ](#security-iam-troubleshoot-cross-account-access) ## データ転送ターミナルでアクションを実行する権限がありません AWS データ転送ターミナルコンソールで予約を表示またはスケジュールできない場合は、必要なアクセス許可がない可能性があります。アカウント管理者に連絡して、アクセスと適切なアクセス許可を付与する IAM ID ポリシーを設定してください。 ## AWS アカウントの外部のユーザーにデータ転送ターミナルリソースへのアクセスを許可したい 他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。 詳細については、以下を参照してください。 + データ転送ターミナルがこれらの機能をサポートしているかどうかについては、「[データ転送ターミナルと IAM の連携方法](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) を参照してください。 # データ転送ターミナル API リファレンス: アクションとリソース AWS Identity and Access Management (IAM) ポリシーを作成する際、このページは、AWS データ転送ターミナル API オペレーション、実行するアクセス許可を付与する対象アクション、およびアクセス許可を付与できる AWS リソースの関係を理解するのに役立ちます。 一般的に、データ転送ターミナルのアクセス許可をポリシーに追加する方法は次のとおりです。 + `Action` エレメントにアクションを指定します。`datatransferterminal:` 値にはプレフィックスと API オペレーション名が含まれます。例えば、`datatransferterminal:CreateTask`。 + `Resource` エレメントのアクションに関連する AWS リソースを指定します。 データ転送ターミナルポリシーで AWS 条件キーを使用することもできます。すべての AWS キーのリストについては、「IAM ユーザーガイド」の「[利用可能なキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys)」を参照してください。 **データ転送ターミナル API オペレーションと対応するアクション** CreateTransferTeam + **アクション:**`datatransferterminal:CreateTransferTeam` **リソース:** `None` GetTransferTeam + **アクション:**`datatransferterminal:GetTransferTeam` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` UpdateTransferTeam + **アクション:**`datatransferterminal:UpdateTransferTeam` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` DeleteTransferTeam + **アクション:**`datatransferterminal:DeleteTransferTeam` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` ListTransferTeams + **アクション:**`datatransferterminal:ListTransferTeams` **リソース:** `None` RegisterPerson + **アクション:**`datatransferterminal:RegisterPerson` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` GetPerson + **アクション:**`datatransferterminal:GetPerson` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId`/person/$[replaceable]`PersonId```` **依存アクション:** `datatransferterminal:GetTransferTeam` **依存リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` DeregisterPerson + **アクション:**`datatransferterminal:DeregisterPerson` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId`/person/$[replaceable]`PersonId```` **依存アクション:** `datatransferterminal:GetTransferTeam` **依存リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` ListPersons + **アクション:**`datatransferterminal:ListPersons` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` CreateReservation + **アクション:**`datatransferterminal:CreateReservation` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` **依存アクション:** `datatransferterminal:GetTransferTeam` **依存リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` **依存アクション:** `datatransferterminal:GetPerson` **依存リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId`/person/$[replaceable]`PersonId```` **依存アクション:** `datatransferterminal:GetFacility` **依存リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:::facility/$[replaceable]`FacilityId```` GetReservation + **アクション:**`datatransferterminal:GetReservation` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId`/reservation/$[replaceable]`ReservationId```` **依存アクション:** `datatransferterminal:GetTransferTeam` **依存リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` UpdateReservation + **アクション:**`datatransferterminal:UpdateReservation` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId`/reservation/$[replaceable]`ReservationId```` **依存アクション:** `datatransferterminal:GetTransferTeam` **依存リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` **依存アクション:** `datatransferterminal:GetPerson` **依存リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId`/person/$[replaceable]`PersonId```` DeleteReservation + **アクション:**`datatransferterminal:DeleteReservation` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId`/person/$[replaceable]`PersonId```` **依存アクション:** `datatransferterminal:GetTransferTeam` **依存リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` ListReservations + **アクション:**`datatransferterminal:ListReservations` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:$[replaceable]`Region`:$[replaceable]`Account`:transfer-team/$[replaceable]`TransferTeamId```` ListFacilities + **アクション:**`datatransferterminal:ListFacilities` **リソース:** `None` GetFacility + **アクション:**`datatransferterminal:GetFacility` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:::facility/$[replaceable]`FacilityId```` GetFacilityAvailability + **アクション:**`datatransferterminal:GetFacilityAvailability` **リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:::facility/$[replaceable]`FacilityId`/availability` **依存アクション:** `datatransferterminal:GetFacility` **依存リソース:** `arn:aws::$[replaceable]`Partition`:datatransferterminal:::facility/$[replaceable]`FacilityId`/availability`