リソースおよびオペレーションリソース所有権についてリソースへのアクセスの管理ポリシー要素 (アクション、効果、プリンシパル) の指定ポリシーでの条件の指定

新規プロジェクトでは、Kinesis Data Analytics for SQL よりも新しい Managed Service for Apache Flink Studio を使用することをお勧めします。Managed Service for Apache Flink Studio は、使いやすさと高度な分析機能を兼ね備えているため、高度なストリーム処理アプリケーションを数分で構築できます。

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

リソースへのアクセス許可の管理の概要

警告

新しいプロジェクトでは、Kinesis Data Analytics for SQL Applications よりも新しい Managed Service for Apache Flink Studio を使用することをお勧めします。Managed Service for Apache Flink Studio は、使いやすさと高度な分析機能を兼ね備えているため、高度なストリーム処理アプリケーションを数分で構築できます。

アクセス権限を付与するには、ユーザー、グループ、またはロールにアクセス許可を追加します。

のユーザーとグループ AWS IAM Identity Center：

アクセス許可セットを作成します。「AWS IAM Identity Center ユーザーガイド」の「アクセス許可一式を作成」の手順を実行します。
IAM 内で、ID プロバイダーによって管理されているユーザー:

ID フェデレーションのロールを作成します。詳細については、「IAM ユーザーガイド」の「サードパーティー ID プロバイダー (フェデレーション) 用のロールの作成」を参照してください。
IAM ユーザー:
- ユーザーが継承できるロールを作成します。手順については、「IAM ユーザーガイド」の「IAM ユーザー用ロールの作成」を参照してください。
- (お奨めできない方法) ポリシーをユーザーに直接アタッチするか、ユーザーをユーザーグループに追加する。詳細については、「IAM ユーザーガイド」の「ユーザー (コンソール) へのアクセス権限の追加」を参照してください。

注記

アカウント管理者 (または管理者ユーザー) は、管理者権限を持つユーザーです。詳細については、「IAM ユーザーガイド」の「IAM のベストプラクティス」を参照してください。

リソースおよびオペレーション

では、プライマリリソースはアプリケーションです。ポリシーで Amazon リソースネーム (ARN) を使用して、ポリシーを適用するリソースを識別します。

これらのリソースには、次の表に示すとおり、一意の Amazon リソースネーム (ARN) が関連付けられています。

リソースタイプ	ARN 形式
アプリケーション	`arn:aws:kinesisanalytics:region:account-id:application/application-name`

では、リソースを操作する一連のオペレーションが用意されています。使用可能なオペレーションのリストについては、「アクション」を参照してください。

リソース所有権について

は、誰がリソースを作成したかにかかわらず、アカウントで作成されたリソース AWS アカウントを所有します。具体的には、リソース所有者は、リソース作成リクエスト AWS アカウントを認証するプリンシパルエンティティ (ルートアカウント、ユーザー、または IAM ロール) のです。次の例は、この仕組みを示しています。

のルートアカウントの認証情報を使用してアプリケーション AWS アカウントを作成する場合、 AWS アカウントはリソースの所有者です。( では、リソースはアプリケーションです。)
でユーザーを作成し AWS アカウント、そのユーザーにアプリケーションを作成するアクセス許可を付与すると、そのユーザーはアプリケーションを作成できます。ただし、ユーザーが属 AWS アカウントするはアプリケーションリソースを所有しています。ユーザーではなく、ロールに権限を付与するよう強くお勧めします。
アプリケーションを作成するためのアクセス許可 AWS アカウントを持つに IAM ロールを作成する場合、ロールを引き受けることのできるいずれのユーザーもアプリケーションを作成できます。ユーザーが属 AWS アカウントするがアプリケーションリソースを所有しています。

リソースへのアクセスの管理

アクセス権限ポリシー では、誰が何にアクセスできるかを記述します。次のセクションで、アクセス許可ポリシーを作成するために使用可能なオプションについて説明します。

注記

このセクションでは、のコンテキストでの IAM の使用について説明します。IAM サービスに関する詳しい説明はしません。完全な IAM ドキュメンテーションについては、[IAM ユーザーガイド] の [IAM とは] を参照してください。IAM ポリシー構文の詳細と説明については、IAM ユーザーガイドの「IAM JSON ポリシーのリファレンス」を参照してください。

IAM アイデンティティにアタッチされているポリシーは、アイデンティティベースのポリシー (IAM ポリシー) と呼ばれます。リソースにアタッチされたポリシーを、リソースベースのポリシーと呼びます。は、アイデンティティベースのポリシー (IAMポリシー) のみをサポートします。

トピック

アイデンティティベースのポリシー (IAM ポリシー)
リソースベースのポリシー

アイデンティティベースのポリシー (IAM ポリシー)

ポリシーを IAM アイデンティティにアタッチできます。例えば、次のオペレーションを実行できます。

アカウントのユーザーまたはグループにアクセス権限ポリシーをアタッチする – アプリケーションなどのリソースを作成するアクセス権限を付与するには、ユーザーまたはユーザーが所属するグループにアクセス許可のポリシーをアタッチできます。
アクセス権限ポリシーをロールにアタッチする (クロスアカウントの許可を付与) - ID ベースのアクセス権限ポリシーを IAM ロールにアタッチして、クロスアカウントの権限を付与することができます。例えば、アカウント A の管理者は、次のように別の AWS アカウント（アカウント B など) または Amazon サービスにクロスアカウントアクセス許可を付与するロールを作成できます。
1. アカウント A の管理者は、IAM ロールを作成して、アカウント A のリソースに許可を付与するロールに許可ポリシーをアタッチします。
2. アカウント A の管理者は、アカウント B をそのロールを引き受けるプリンシパルとして識別するロールに、信頼ポリシーをアタッチします。
3. アカウント B の管理者は、アカウント B のユーザーにロールを引き受ける権限を委任できるようになります。これにより、アカウント B のユーザーはアカウント A のリソースの作成とアクセスができます。ロールを引き受ける権限を Amazon のサービスに付与すると、信頼ポリシー内のプリンシパルも Amazon サービスのプリンシパルとなることができます。
IAM を使用した許可の委任の詳細については、「IAM ユーザーガイド」の「アクセス管理」を参照してください。

以下に、アプリケーションの作成に必要な kinesisanalytics:CreateApplication アクションのアクセス権限を付与するポリシーの例を示します。

注記

これは簡単なポリシー例です。ポリシーをユーザーにアタッチすると、ユーザーは AWS CLI または AWS SDK を使用してアプリケーションを作成できます。しかし、入出力を設定するにはより多くのアクセス権限が必要です。また、このユーザーがコンソールを使用する場合もより多くのアクセス権限が必要です。後のセクションで、詳細な情報を説明します。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1473028104000",
            "Effect": "Allow",
            "Action": [
                "kinesisanalytics:CreateApplication"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

でアイデンティティベースのポリシーを使用する場合の詳細については、「でアイデンティティベースのポリシー (IAM ポリシー) を使用する」を参照してください。ユーザー、グループ、ロール、許可の詳細については、「IAM ユーザーガイド」の「アイデンティティ (ユーザー、グループ、ロール)」を参照してください。

リソースベースのポリシー

Amazon S3 などの他のサービスでは、リソースベースの許可ポリシーもサポートされています。例えば、ポリシーを S3 バケットにアタッチして、そのバケットに対する許可を管理できます。はリソースベースのポリシーをサポートしていません。

ポリシー要素 (アクション、効果、プリンシパル) の指定

サービスは、リソースごとに一連の API オペレーションを定義します。こうした API オペレーションへの許可を付与するために、はポリシーに定義できる一連のアクションを定義します。一部の API オペレーションは、API オペレーションを実行するために複数のアクションに対するアクセス許可を要求できます。リソースおよび API オペレーションに関する詳細については、「リソースおよびオペレーション」および「アクション」を参照してください。

最も基本的なポリシーの要素を次に示します。

リソース - Amazon リソースネーム (ARN) を使用して、ポリシーを適用するリソースを識別します。詳細については、「リソースおよびオペレーション」を参照してください。
アクション - アクションのキーワードを使用して、許可または拒否するリソースオペレーションを識別します。たとえば、create を使用して、アプリケーションの作成をユーザーに許可することができます。
効果 – ユーザーが特定のアクションをリクエストする際の効果 (許可または拒否) を指定します。リソースへのアクセスを明示的に許可していない場合、アクセスは暗黙的に拒否されます。また、明示的にリソースへのアクセスを拒否すると、別のポリシーによってアクセスが許可されている場合でも、ユーザーはそのリソースにアクセスできなくなります。
プリンシパル – ID ベースのポリシー (IAM ポリシー) で、ポリシーがアタッチされているユーザーが黙示的なプリンシパルとなります。リソースベースのポリシーでは、アクセス許可を受け取りたいユーザー、アカウント、サービス、またはその他のエンティティを指定します (リソースベースのポリシーにのみ適用)。では、リソースベースのポリシーはサポートされていません。

IAM ポリシーの構文と記述の詳細については、IAM ユーザーガイドの「IAM JSON ポリシーのリファレンス」を参照してください。

適用する API オペレーションやリソースがすべて表示されているテーブルのについては、「 API アクセス許可: アクション、アクセス許可、リソースの参照」を参照してください。

ポリシーでの条件の指定

アクセス許可を付与するとき、アクセスポリシー言語を使用して、ポリシーが有効になる条件を指定できます。例えば、特定の日付の後にのみ適用されるポリシーが必要になる場合があります。ポリシー言語での条件の指定の詳細については、「IAM ユーザーガイド」の「条件」を参照してください。

条件を表すには、あらかじめ定義された条件キーを使用します。に固有の条件キーはありません。ただし、必要に応じて使用できる AWS全体の条件キーがあります。 AWS全体のキーの完全なリストについては、「IAM ユーザーガイド」の「条件に使用可能なキー」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

認証とアクセスコントロール

アイデンティティベースのポリシー (IAM ポリシー) を使用する