サポート終了通知: 2024 年 10 月 22 日、 AWS は Amazon Nimble Studio のサポートを終了します。2024 年 10 月 22 日以降、Nimble Studio コンソールまたは Nimble Studio リソースにアクセスできなくなります。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon Nimble Studio 向けの Identity and Access Management
AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全に制御 AWS のサービス するのに役立つ です。管理者は、(サインインを) 認証された、および Amazon Nimble Studio リソースの使用を認可された (アクセス許可を持つ) ユーザーを制御します。IAM は、追加料金なしで AWS のサービス 使用できる です。
トピック
対象者
AWS Identity and Access Management (IAM) の使用方法は、Nimble Studio で行う作業によって異なります。
サービスユーザー — Nimble Studio サービスを使用してジョブを実行する場合は、サービスユーザーになります。この場合、割り当てられたリソースにアクセスするために必要な認証情報とアクセス許可を、管理者が用意します。作業を行うためにさらに多くの Nimble Studio の機能を使用する際は、追加の許可が必要になる場合があります。アクセスの管理方法を理解すると、管理者に適切なアクセス許可をリクエストするのに役に立ちます。Nimble Studio の機能にアクセスできない場合は、「Amazon Nimble Studio のアイデンティティとアクセスのトラブルシューティング」を参照してください。
サービス管理者 - 社内の Nimble Studio リソースを担当している場合は、通常、Nimble Studio へのフルアクセス許可が付与されます。従業員がアクセスする必要のある Nimble Studio の機能とリソースを決定することは、管理者のジョブです。その後、サービスユーザーのアクセス許可を変更するリクエストを管理者に送信します。このページの情報を確認して、IAM の基本概念を理解してください。企業における Nimble Studio での IAM の使用方法については、「Amazon Nimble Studio で IAM を使用する方法」を参照してください。
アイデンティティを使用した認証
認証とは、ID 認証情報 AWS を使用して にサインインする方法です。を使用したサインインの詳細については AWS マネジメントコンソール、IAM ユーザーガイドの「IAM ユーザーまたはルートユーザー AWS マネジメントコンソール として にサインインする」を参照してください。
AWS アカウント ルートユーザー、ユーザー、または IAM ロールを引き受けて認証 (サインイン AWS) される必要があります。会社のシングルサインオン認証を使用することも、Google や Facebook のサインインを使用することもできます。このような場合、管理者が事前に IAM ロールを使用して ID フェデレーションを設定している必要があります。別の会社の認証情報 AWS を使用して にアクセスすると、間接的にロールを引き受けることになります。
AWS マネジメントコンソール
AWS には、認証情報を使用してリクエストに暗号で署名するための SDK およびコマンドラインツールが用意されています。 AWS ツールを使用しない場合は、リクエストに自分で署名します。これには、インバウンド API リクエストを認証するためのプロトコルである署名バージョン 4 を使用します。リクエストの認証の詳細については、「 AWS 全般のリファレンス 」の「署名バージョン 4 の署名プロセス」を参照してください。
使用する認証方法を問わず、追加のセキュリティ情報の提供を要求される場合もあります。例えば、 AWS では、多要素認証 (MFA) を使用してアカウントのセキュリティを強化することをお勧めします。詳細については、「IAM ユーザーガイド」の「AWSでの多要素認証 (MFA) の使用」を参照してください。
AWS アカウント ルートユーザー
を初めて作成するときは AWS アカウント、アカウント内のすべての AWS のサービス およびリソースへの完全なアクセス権を持つシングルサインインアイデンティティから始めます。この ID は AWS アカウント ルートユーザーと呼ばれ、アカウントの作成に使用した E メールアドレスとパスワードでサインインすることでアクセスできます。ただし、日常的なタスクには、それが管理的なタスクであっても、ルートユーザーを使用しないことを強くお勧めします。代わりに、初期の IAM ユーザーを作成するためにのみ、ルートユーザーを使用するというベストプラクティスに従います。その後、ルートユーザーの認証情報を安全な場所に保管し、それらを使用して少数のアカウントおよびサービス管理タスクのみを実行します。
ユーザーとグループ
ユーザーは、単一のユーザーまたはアプリケーションに対して特定のアクセス許可 AWS アカウント を持つ 内のアイデンティティです。ユーザーは、長期的な認証情報またはアクセスキーのセットを持つことができます。アクセスキーの生成方法の詳細については、「IAM ユーザーガイド」の「IAM ユーザーのアクセスキーの管理」を参照してください。ユーザーにアクセスキーを生成する際は、キーペアを表示して安全に保存してください。後で、シークレットアクセスキーを復元することはできません。新しいアクセスキーペアを生成します。
[IAM グループ] は、ユーザーのコレクションを指定するアイデンティティです。グループとしてサインインすることはできません。グループを使用して、複数のユーザーに対して一度に権限を指定できます。多数のユーザーグループがある場合、グループを使用することで権限の管理が容易になります。例えば、IAMAdmins という名前のグループを設定して、そのグループに IAM リソースを管理する許可を与えることができます。
ユーザーは、ロールとは異なります。ユーザーは 1 人の人または 1 つのアプリケーションに一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。ユーザーには永続的な長期の認証情報がありますが、ロールでは一時認証情報が提供されます。詳細については、「IAM ユーザーガイド」の「ユーザー (ロールではなく) の作成が適している場合」を参照してください。
IAM ロール
IAM ロールは、特定のアクセス許可 AWS アカウント を持つ 内のアイデンティティです。これはユーザーに似ていますが、特定のユーザーには関連付けられていません。ロールを切り替える AWS マネジメントコンソール ことで、 で IAM ロールを一時的に引き受けることができます。ロールを引き受けるには、 AWS CLI または AWS API オペレーションを呼び出すか、カスタム URL を使用します。ロールの使用方法については、「IAM ユーザーガイド」の 「IAM ロールを使用する」を参照してください。
IAM ロールと一時的な認証情報は、次の状況で役立ちます:
-
一時的なユーザーアクセス許可 - ユーザーは、特定のタスクのための複数の異なるアクセス許可を一時的に受け取るために、IAM ロールを引き受けることができます。
-
フェデレーティッドユーザーアクセス – ユーザーを作成する代わりに、 Directory Service、エンタープライズユーザーディレクトリ、またはウェブ ID プロバイダーから既存の ID を使用できます。このようなユーザーはフェデレーションユーザーと呼ばれます。 AWS では、ID プロバイダーを通じてアクセスがリクエストされたとき、フェデレーションユーザーにロールを割り当てます。フェデレーションユーザーの詳細については、「IAM ユーザーガイド」の「フェデレーションユーザーとロール」を参照してください。
-
メンバーシップ – Nimble Studio は「メンバーシップ」と呼ばれる概念を使用して、特定の起動プロファイルへのユーザーアクセスを許可します。メンバーシップを使用すると、スタジオ管理者は IAM ポリシーを書き込んだり理解したりすることなく、リソースアクセスをユーザーに委任できます。Nimble Studio 管理者が起動プロファイルでユーザーのメンバーシップを作成すると、そのユーザーは、起動プロファイルを使用するために必要な IAM アクション (プロパティの表示、起動プロファイルを使用したストリーミングセッションの開始など) の実行を認可されます。
-
サービスロール - サービスがユーザーに代わってアクションを実行するために引き受ける IAM ロールです。サービスロールは、ご使用のアカウント内のみでアクセス権の付与を行います。他のアカウント内にあるサービスに、アクセス権を付与することはできません。管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、「IAM ユーザーガイド」の「AWS のサービスにアクセス許可を委任するロールの作成」を参照してください。
-
サービスにリンクされたロール – サービスにリンクされたロールは、 にリンクされたサービスロールの一種です AWS のサービス。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。Nimble Studio は、サービスにリンクされたロールをサポートしていません。
-
-
Amazon EC2 で実行されているアプリケーション – IAM ロールを使用して、EC2 インスタンスで実行され、 AWS CLI または AWS API リクエストを実行しているアプリケーションの一時的な認証情報を管理できます。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。 AWS ロールを EC2 インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスにアタッチされたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時的な認証情報を取得できます。詳細については、「IAM ユーザーガイド」の「Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する」を参照してください。
IAM ロールと IAM ユーザーのどちらを使用するかについては、「IAM ユーザーガイド」の「(IAM ユーザーではなく) IAM ロールをいつ作成したら良いのか?」を参照してください。
ポリシーを使用したアクセスの管理
でアクセスを制御する AWS には、ポリシーを作成し、IAM ID または AWS リソースにアタッチします。ポリシーは のオブジェクト AWS であり、ID またはリソースに関連付けられると、そのアクセス許可を定義します。ルートユーザーまたは単なるユーザーとしてサインインすることも、IAM ロールを引き受けることもできます。その後、リクエストを行うと、 は関連するアイデンティティベースまたはリソースベースのポリシー AWS を評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。ほとんどのポリシーは JSON ドキュメント AWS として に保存されます。JSON ポリシードキュメントの構造と内容の詳細については、「IAM ユーザーガイド」の「JSON ポリシー概要」を参照してください。
管理者は JSON AWS ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースに対してどのような条件下でアクションを実行できるかということです。
すべての IAM エンティティ (ユーザーまたはロール) は、許可のない状態からスタートします。言い換えると、デフォルト設定では、ユーザーは何もできず、自分のパスワードを変更することすらできません。何かを実行する許可をユーザーに付与するには、管理者がユーザーに許可ポリシーをアタッチする必要があります。また、管理者は、必要な許可があるグループにユーザーを追加できます。管理者がグループに許可を付与すると、そのグループ内のすべてのユーザーにこれらの許可が付与されます。
IAM ポリシーは、オペレーションの実行方法を問わず、アクションの許可を定義します。例えば、iam:GetRole アクションを許可するポリシーがあるとします。そのポリシーを持つユーザーは、 AWS マネジメントコンソール、、 AWS CLIまたは AWS API からロール情報を取得できます。
アイデンティティベースのポリシー
アイデンティティベースポリシーは、ユーザー、ユーザーのグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーを作成する方法については、「IAM ユーザーガイド」の「IAM ポリシーの作成」を参照してください。
アイデンティティベースのポリシーは、さらにインラインポリシーまたはマネージドポリシーに分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれています。管理ポリシーは、 内の複数のユーザー、グループ、ロールにアタッチできるスタンドアロンポリシーです AWS アカウント。管理ポリシーには、 AWS 管理ポリシーとカスタマー管理ポリシーが含まれます。マネージド型ポリシーとインラインポリシーの内、いずれかを選択する方法については、「IAM ユーザーガイド」の「管理ポリシーとインラインポリシーの比較」を参照してください。
リソースベースのポリシー
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM ロールの信頼ポリシーや Amazon S3 バケットポリシーがあげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、プリンシパルを指定します。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または を含めることができます AWS のサービス。
リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーでは、IAM の AWS マネージドポリシーを使用できません。
Nimble Studio のアクセスコントロールリスト (ACL)
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするための許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
Amazon S3、 AWS WAF、および Amazon VPC は、ACLs。ACL の詳細については、「Amazon Simple Storage Service デベロッパーガイド」の「アクセスコントロールリスト (ACL) の概要」を参照してください。
その他のポリシータイプ
AWS は、一般的ではない追加のポリシータイプをサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の権限を設定できます。
-
アクセス許可の境界 - アクセス許可の境界は、アイデンティティベースのポリシーによって IAM エンティティ (ユーザーまたはロール) に付与できる許可の上限を設定する高度な機能です。エンティティにアクセス許可の境界を設定できます。結果として得られる許可は、エンティティのアイデンティティベースポリシーとその許可の境界にある共通部分です。
Principalフィールドでユーザーまたはロールを指定するリソースベースのポリシーは、許可の境界では制限されません。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。アクセス許可の境界の詳細については、「IAM ユーザーガイド」の「IAM エンティティのアクセス許可の境界」を参照してください。 -
サービスコントロールポリシー (SCP) – SCP とは、Organizations 内の組織または組織単位 (OU) に対し、アクセス許可の上限を指定するための JSON ポリシーです。Organizations は、ビジネスが所有する複数の AWS アカウント を、グループ化および一元管理するためのサービスです。組織内のすべての機能を有効にすると、サービスコントロールポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP は、各 AWS アカウント ルートユーザーを含むメンバーアカウントのエンティティのアクセス許可を制限します。Organizations と SCPs「 AWS Organizations ユーザーガイド」のSCPs」を参照してください。
-
セッションポリシー - セッションポリシーは、ロールまたはフェデレーションユーザーの一時的なセッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果として得られるセッションの許可は、ユーザーまたはロールのアイデンティティベースポリシーとセッションポリシーの共通部分です。また、リソースベースのポリシーから権限が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。詳細については、「IAM ユーザーガイド」の「セッションポリシー」を参照してください。
複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成される権限を理解するのがさらに難しくなります。複数のポリシータイプが関係する場合に がリクエストを許可するかどうか AWS を決定する方法については、「IAM ユーザーガイド」の「ポリシー評価ロジック」を参照してください。
