アクセスと認証の概要 - AWS Global Accelerator
認証とはアクセス制御とはポリシーとはIAM の使用開始

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

アクセスと認証の概要

IAM を初めて使用する場合は、以下のトピックを読んで AWS の認証とアクセスを開始してください。

認証とは

認証は、認証情報を使用して AWS にサインインする方法です。

注記

すぐに開始するには、このセクションを無視できます。最初に、「」の基本情報に目を通してください。AWS Global Accelerator の ID とアクセス管理「」および「」を参照してください。IAM の使用開始。

プリンシパルとして、あなたは認証済み(AWS にサインイン)。エンティティー (ルートユーザー、IAM ユーザー、IAM ロール) を使用して AWS にリクエストを送信します。IAM ユーザーは、ユーザー名とパスワード、アクセスキーのセットなど、長期的な認証情報を持つことができます。IAM ロールを引き受けると、一時的なセキュリティ認証情報が付与されます。

AWS Management Console からユーザーとして認証するには、ユーザー名とパスワードを使用してサインインする必要があります。AWS CLI または AWS API から認証するには、アクセスキーとシークレットキー、または一時的な認証情報を指定する必要があります。AWS では、SDK と CLI ツールを提供して、お客様の認証情報を使用して、リクエストに暗号で署名できます。AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。使用する認証方法を問わず、追加のセキュリティ情報の提供を要求される場合もあります。たとえば、AWS では Multi-Factor Authentication (MFA) を使用してアカウントのセキュリティを高めることを推奨しています。

プリンシパルとして、以下のエンティティ (ユーザーまたはロール) を使用して AWS にサインインできます。

AWS アカウントのルートユーザー

AWS アカウントを初めて作成する場合は、すべての AWS のサービスとリソースに対して完全なアクセス権限を持つシングルサインイン ID で始めます。このアイデンティティは root ユーザーと呼ばれ、AWS アカウントの作成に使用したメールアドレスとパスワードでのサインインによりアクセスされます。強くお勧めしているのは、日常的なタスクには、それが管理者タスクであっても、root ユーザーを使用しないことです。代わりに、最初の IAM ユーザーを作成するためにのみ、ルートユーザーを使用するというベストプラクティスに従います。その後、ルートユーザーの認証情報を安全な場所に保管し、それらを使用して少数のアカウントおよびサービス管理タスクのみを実行します。

IAM ユーザー

あんIAM ユーザーは、特定のアクセス許可を持つ、AWS アカウント内のエンティティです。グローバルアクセラレーター署名バージョン 4では、インバウンド API リクエストを認証するためのプロトコルです。リクエストの認証については、「」を参照してください。署名バージョン 4 署名プロセス()AWS 全般のリファレンス。

IAM ロール

あんIAM ロールは、特定のアクセス権限を持ち、アカウントで作成できる IAM アイデンティティです。IAM ロールは、AWS でできることとできないことを決定するのが、アクセス許可ポリシーを伴う AWS アイデンティティであるという点で IAM ユーザーと似ています。ただし、ユーザーは 1 人の特定の人に一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。また、ロールには標準の長期認証情報 (パスワードやアクセスキーなど) も関連付けられません。代わりに、ロールを引き受けると、ロールセッション用の一時的なセキュリティ認証情報が提供されます。IAM ロールと一時的な認証情報は、次の状況で役立ちます。

フェデレーティッドユーザーアクセス

IAM ユーザーを作成するのではなく、AWS Directory Service、エンタープライズユーザーディレクトリ、またはウェブアイデンティティプロバイダーの既存のアイデンティティを使用することもできます。このようなユーザーはフェデレーティッドユーザーと呼ばれます。AWS では、ID プロバイダーを通じてアクセスがリクエストされたとき、フェデレーティッドユーザーにロールを割り当てます。フェデレーティッドユーザーの詳細については、」フェデレーティッドユーザーとロール()IAM ユーザーガイド。

一時的なユーザー権限

IAM ユーザーは、ロールを引き受けることで、一時的に特定のタスクに対して異なるアクセス許可を取得することができます。

クロスアカウントアクセス

IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを別のアカウントの信頼済みプリンシパルに許可できます。ロールは、クロスアカウントアクセスを許可する主な方法です。ただし、一部の AWS のサービスでは、(ロールをプロキシとして使用する代わりに) リソースにポリシーを直接アタッチできます。グローバルアクセラレータでは、これらのリソースベースのポリシーはサポートされていません。ロールとリソースベースのポリシーのいずれを使用してクロスアカウントアクセスを許可するかの詳細については、「別のアカウント内のプリンシパルに対するアクセスコントロール」を参照してください。

AWS サービスへのアクセス

サービスロールとはIAM ロールサービスがお客様に代わってアクションを実行すると引き受けること。サービスロールは、お客様のアカウント内のみでアクセスを提供します。他のアカウントのサービスへのアクセス権を付与するためにサービスロールを使用することはできません。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、「」を参照してください。AWS のサービスにアクセス許可を委任するロールの作成()IAM ユーザーガイド。

Amazon EC2 で実行中のアプリケーション

EC2 インスタンスで実行され、AWS CLI または AWS API リクエストを作成しているアプリケーションの一時的な認証情報を管理するには、IAM ロールを使用します。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。AWS ロールを EC2 インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスにアタッチされたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時認証情報を取得することができます。詳細については、「」を参照してください。IAM ロールを使用して、Amazon EC2 インスタンスで実行されるアプリケーションにアクセス許可を付与する()IAM ユーザーガイド。

アクセス制御とは

AWS にサインイン (認証) した後では、AWS リソースおよびオペレーションへのアクセスはポリシーによって管理されます。アクセスコントロールは承認とも呼ばれます。

注記

すぐに開始するには、このページを無視できます。最初に、「」の基本情報に目を通してください。AWS Global Accelerator の ID とアクセス管理「」および「」を参照してください。IAM の使用開始。

承認中、AWS はリクエストのコンテキスト該当するポリシーを確認します。次に、ポリシーを使用してリクエストの許可または拒否を決定します。大半のポリシーは JSON ドキュメントとして AWS に保存され、プリンシパルに対して許可または拒否するアクセス許可を指定します。JSON ポリシードキュメントの構造と内容の詳細については、「ポリシーとは」を参照してください。

ポリシーにより、管理者は AWS リソースへのアクセスを許可するユーザーと、これらのリソースで実行できるアクションを指定できます。すべての IAM エンティティ (ユーザーまたはロール) は、アクセス許可のない状態からスタートします。言い換えると、デフォルト設定では、ユーザーは何もできず、そのユーザーのアクセスキーを参照することすらできません。何かを実行するアクセス許可をユーザーに付与するには、管理者がユーザーにアクセス許可ポリシーをアタッチする必要があります。または、必要なアクセス許可がアタッチ済みであるグループにユーザーを追加できます。次に、管理者がグループにアクセス許可を付与すると、そのアクセス許可はグループ内のすべてのユーザーに付与されます。

リクエストを認証できる有効な認証情報がある場合でも、管理者からアクセス許可が付与されない限り、AWS Global Accelerator リソースを作成したり、これらのリソースにアクセスしたりすることはできません。たとえば AWS Global Accelerator を作成するには、そのための明示的なアクセス許可が必要です。

管理者は、以下へのアクセスをコントロールするポリシーを作成できます。

  • プリンシパル— リクエストを行っているユーザーまたはアプリケーションを制御する (プリンシパル）が許可されています。

  • IAM ID— どの IAM アイデンティティ (グループ、ユーザー、ロール) にどのようにアクセスできるかをコントロールします。

  • IAM ポリシー：だれがカスタマー管理ポリシーを作成、編集、削除でき、だれがすべての管理ポリシーをアタッチおよびデタッチできるかをコントロールします。

  • AWS リソース— アイデンティティベースのポリシーまたはリソースベースのポリシーを使用してだれがリソースにアクセスできるかをコントロールできます。

  • AWS アカウント— リクエストを特定のアカウントのメンバーにのみ許可するかどうかをコントロールします。

プリンシパルへのアクセスの制御

アクセス許可ポリシーは、プリンシパルに実行することを許可する操作をコントロールします。管理者は、アクセス許可を付与するアイデンティティ (ユーザー、グループ、またはロール) に対して、アイデンティティベースのアクセス許可ポリシーをアタッチする必要があります。アクセス許可ポリシーでは、AWS へのアクセスを許可または拒否します。管理者は、IAM エンティティ (ユーザーまたはロール) のアクセス許可の境界を設定して、エンティティに許可されるアクセス許可の上限を定義することもできます。アクセス許可の境界は IAM のアドバンスド機能です。アクセス許可の境界の詳細については、」IAM ID のアクセス許可の境界()IAM ユーザーガイド。

プリンシパルの AWS アクセスを制御する方法の詳細と例については、プリンシパルへのアクセスの制御()IAM ユーザーガイド。

ID へのアクセスの制御

管理者は、IAM アイデンティティ（ユーザー、グループ、ロール）に対して実行できる操作や、アイデンティティにアクセスできるユーザーを制限するポリシーを作成して、IAM アイデンティティ（ユーザーまたはグループ）に対して実行できる操作を制御します。次に、このポリシーを、アクセス許可を付与するアイデンティティにアタッチします。

たとえば、管理者は、特定の 3 ユーザーのパスワードをリセットすることを許可できます。これを行うには、IAM ユーザーにポリシーをアタッチします。このポリシーにより、ユーザー自身と特定の 3 ユーザーの ARN を持つユーザーのパスワードに限り、リセットすることを許可します。これにより、チームメンバーのパスワードはリセットできますが、他の IAM ユーザーのパスワードはリセットできません。

ポリシーを使用して ID への AWS アクセスを制御する方法の詳細と例については、」ID へのアクセスの制御()IAM ユーザーガイド。

ポリシーへのアクセスの制御

管理者は、だれがカスタマー管理ポリシーを作成、編集、削除でき、だれがすべての管理ポリシーをアタッチおよびデタッチできるかをコントロールできます。ポリシーを確認する場合、そのポリシー内の各サービスのアクセスレベルの要約を含むポリシー概要を表示できます。AWS は、各サービスアクションを 4 つの 1 つに分類します。アクセスレベル各アクションが何をするかに基づいて：List,Read,Write, またはPermissions management。これらのアクセスレベルを使用して、ポリシーに含めるアクションを判断できます。詳細については、「」を参照してください。ポリシー概要内のアクセスレベルの概要について()IAM ユーザーガイド。

警告

制限する必要がありますPermissions Managementアカウントのアクセスレベルのアクセス権限。制限しないと、アカウントのメンバーは各自のポリシーを作成するときに必要以上のアクセス許可を使用できるようになります。または、AWS へのフルアクセスを使用して個別のユーザーを作成できます。

ポリシーへの AWS アクセスを制御する方法の詳細と例については、」ポリシーへのアクセスの制御()IAM ユーザーガイド。

のリソースへのアクセスの制御

管理者は、アイデンティティベースのポリシーまたはリソースベースのポリシーを使用してリソースへのアクセスをコントロールできます。アイデンティティベースのポリシーでは、ポリシーをアイデンティティにアタッチし、そのアイデンティティがアクセスできるリソースを指定します。リソースベースのポリシーでは、制御するリソースにポリシーをアタッチします。ポリシーでは、リソースにアクセスできるプリンシパルを指定します。

詳細については、「」を参照してください。リソースへのアクセスコントロール()IAM ユーザーガイド。

リソース作成者は自動的に権限を持たない

アカウントのすべてのリソースは、その作成者を問わず、アカウントが所有します。AWS アカウントのルートユーザーはアカウント所有者であるため、アカウント内のリソースに対して任意のアクションを実行するアクセス許可を持ちます。

重要

強くお勧めしているのは、日常的なタスクには、それが管理者タスクであっても、root ユーザーを使用しないことです。代わりに、最初の IAM ユーザーを作成するためにのみ、ルートユーザーを使用するというベストプラクティスです。。その後、ルートユーザーの認証情報を安全な場所に保管し、それらを使用して少数のアカウントおよびサービス管理タスクのみを実行します。ルートユーザーとしてサインインする必要があるタスクを確認するには、」root ユーザーを必要とする AWS タスク。

AWS アカウントのエンティティ (ユーザーまたはロール) には、リソースを作成するためのアクセス権を付与する必要があります。しかし、リソースを作成しても、そのリソースへのフルアクセスが自動的に許可されるわけではありません。管理者は、アクションごとに明示的にアクセス許可を付与する必要があります。さらに、管理者はユーザーやロールのアクセス許可を管理するアクセス許可を持っている限り、アクセス許可をいつでも取り消すことができます。

別のアカウント内のプリンシパルに対するアクセスコントロール

管理者は、AWS リソースベースのポリシー、IAM クロスアカウントロール、または AWS Organizations サービスを使用して、別のアカウントのプリンシパルがアカウントのリソースにアクセスすることを許可できます。

一部の AWS サービスでは、管理者は、リソースに対するクロスアカウントアクセス許可を付与できます。これを行うには、プロキシとしてロールを使用する代わりに、共有するリソースに直接ポリシーをアタッチします。このポリシータイプをサービスでサポートしている場合、管理者が共有するリソースもリソースベースのポリシーをサポートしている必要があります。ユーザーベースのポリシーとは異なり、リソースベースのポリシーでは、だれがリソースにアクセスできるかを AWS アカウント ID 番号のリストの形式で指定します。グローバルアクセラレータでは、リソースベースのポリシーはサポートされていません。

クロスアカウントアクセスには、ロールを使うよりも、リソースベースのポリシーを使うほうがいくつかの点で有利です。リソースベースのポリシーによってリソースにアクセスする場合、プリンシパル (人またはアプリケーション) は依然として信頼されたアカウントで作業を行います。ロールのアクセス許可を取得する代わりに自身のアクセス許可が無効になることはありません。つまり、プリンシパルは、信頼される側のアカウントおよび信頼する側のアカウントの両方で、同時にリソースへのアクセス権を保持します。これは、2 つのアカウント間で情報をコピーする場合などに便利です。クロスアカウントロールの使用の詳細については、「」を参照してください。所有している別の AWS アカウントへのアクセス権を IAM ユーザーに提供()IAM ユーザーガイド。

AWS Organizations では、ユーザーが所有している複数の AWS アカウントに対してポリシーベースの管理を提供します。Organizations では、アカウントのグループを作成し、アカウントの作成を自動化して、これらのグループにポリシーを適用して管理することができます。Organizations では、カスタムスクリプトや手動プロセスを必要とすることなく、複数のアカウントをまたいでポリシーを一元管理できます。AWS Organizations を使用して、AWS アカウントをまたいで AWS サービスの使用を一元管理するサービスコントロールポリシー (SCP) を作成できます。詳細については、「」を参照してください。AWS Organizations とは何ですか?()AWS Organizations ユーザーガイド。

ポリシーとは

AWS でアクセスを制御するには、ポリシーを作成して IAM のアイデンティティや AWS のリソースにアタッチします。

注記

すぐに開始するには、このページを無視できます。最初に、「」の基本情報に目を通してください。AWS Global Accelerator の ID とアクセス管理「」および「」を参照してください。IAM の使用開始。

ポリシーは AWS のオブジェクトであり、エンティティやリソースに関連付けて、これらのアクセス許可を定義します。AWS は、ユーザーなどのプリンシパルがリクエストを行ったときに、それらのポリシーを評価します。ポリシーでのアクセス許可により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWS に保存されます。

IAM ポリシーは、オペレーションの実行方法を問わず、アクションのアクセス許可を定義します。たとえば、ポリシーでGetUserアクションを適用している場合、そのポリシーをアタッチされたユーザーは AWS マネジメントコンソール、AWS CLI、または AWS API からユーザー情報を取得することができます。IAM ユーザーを作成したら、コンソールまたはプログラムによるアクセスを許可するようにユーザーを設定できます。IAM ユーザーは、ユーザー名とパスワードを使用してコンソールにサインインできます。または、アクセスキーを使用して CLI または API を操作できます。

以下のポリシータイプ (頻度順) は、リクエストが承認されるかどうかに影響する場合があります。詳細については、「」を参照してください。ポリシータイプ()IAM ユーザーガイド。

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

マネージドポリシーとインラインポリシーを IAM アイデンティティ (ユーザー、ユーザーの所属グループ、およびロール) にアタッチできます。

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

一部の AWS サービスのリソースにインラインポリシーをアタッチできます。リソースベースのポリシーとして最も一般的な例は、Amazon S3 バケットポリシーと IAM ロールの信頼ポリシーです。グローバルアクセラレータでは、リソースベースのポリシーはサポートされていません。

Organizations SCP

AWS Organizations サービスコントロールポリシー (SCP) を使用して、AWS 組織の組織または組織単位 (OU) に権限の境界を適用できます。これらのアクセス許可は、メンバーアカウント内のすべてのエンティティに適用されます。

アクセスコントロールリスト (ACL)

ACL を使用して、リソースにアクセスできるプリンシパルをコントロールできます。ACL は、リソースベースのポリシーと似ていますが、JSON ポリシードキュメント構造を使用しない唯一のポリシータイプです。グローバルアクセラレータは ACL をサポートしている OR をサポートしていません。

これらのポリシータイプは、アクセス許可ポリシーまたはアクセス許可の境界として分類できます。

アクセス許可ポリシー

アクセス許可ポリシーを AWS のリソースにアタッチして、そのオブジェクトのアクセス許可を定義できます。AWS では、1 つのアカウント内のすべてのアクセス許可ポリシーがまとめて評価されます。アクセス許可ポリシーは、最も一般的なポリシーです。アクセス許可ポリシーとして、以下のポリシータイプを使用できます。

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

管理ポリシーまたはインラインポリシーを IAM ユーザー、グループ、またはロールにアタッチすると、そのエンティティのアクセス許可がポリシーで定義されます。

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

JSON ポリシードキュメントをリソースにアタッチするときに、そのリソースのアクセス許可を定義します。サービスでリソースベースのポリシーをサポートしている必要があります。

アクセスコントロールリスト (ACL)

リソースに ACL をアタッチするときに、そのリソースにアクセスする権限を持つプリンシパルのリストを定義します。リソースで ACL をサポートしている必要があります。

アクセス許可の境界

ポリシーを使用して、エンティティ (ユーザーまたはロール) のアクセス許可の境界を定義できます。アクセス許可の境界では、エンティティに付与できるアクセス許可の上限をコントロールします。アクセス許可の境界は AWS のアドバンスド機能です。複数のアクセス許可の境界がリクエストに適用される場合、AWS は各アクセス許可の境界を個別に評価します。アクセス許可の境界は以下の状況で適用できます。

Organizations

AWS Organizations サービスコントロールポリシー (SCP) を使用して、AWS 組織の組織または組織単位 (OU) にアクセス許可の境界を適用できます。

IAM ユーザーまたはロール

ユーザーまたはロールのアクセス許可の境界として管理ポリシーを使用できます。詳細については、「」を参照してください。IAM エンティティのアクセス許可の境界()IAM ユーザーガイド。

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

ポリシーを IAM アイデンティティにアタッチできます。たとえば、次の操作を実行できます。

アカウントのユーザーまたはグループにアクセス権限ポリシーをアタッチする

AWS Global Accelerator リソースを作成するアクセス許可を付与するために、ユーザーまたはユーザーが所属するグループにアクセス許可ポリシーをアタッチできます。

ロールにアクセス権限ポリシーをアタッチする (クロスアカウントアクセス権限を付与する)

アイデンティティベースのアクセス権限ポリシーを IAM ロールにアタッチして、クロスアカウントアクセス権限を付与できます。たとえば、アカウント A の管理者は、次のように他のまたは AWS にクロスアカウントのアクセス権限を別の AWS アカウント (アカウント B) または AWS サービスに付与するロールを作成することができます。

  1. アカウント A の管理者は、IAM ロールを作成して、アカウント A のリソースに権限を付与するロールに権限ポリシーをアタッチします。

  2. アカウント A の管理者は、アカウント B をそのロールを引き受けるプリンシパルとして識別するロールに、信頼ポリシーをアタッチします。

  3. アカウント B の管理者は、アカウント B のユーザーにロールを引き受ける権限を委任できるようになります。これにより、アカウント B のユーザーにアカウント A のリソースの作成とアクセスが許可されます。AWS サービスのアクセス権限を付与してロールを引き受けさせたい場合は、信頼ポリシー内のプリンシパルも、AWS サービスのプリンシパルとなることができます。

IAM を使用したアクセス許可の委任の詳細については、「」を参照してください。アクセス管理()IAM ユーザーガイド。

ユーザー、グループ、ロール、アクセス許可の詳細については、IAM ユーザーガイドの「アイデンティティ (ユーザー、グループ、ロール)」を参照してください。

以下に、グローバルアクセラレータで使用できるポリシーの例を 2 つ示します。最初のサンプルポリシーでは、AWS アカウントのアクセラレータに対するすべての List アクションと Describe アクションへのプログラムによるアクセスをユーザーに付与します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "globalaccelerator:List*",
                "globalaccelerator:Describe*"
            ],
            "Resource": "*"
        }
    ]
}

次の例では、へのプログラムによるアクセスを許可します。ListAcceleratorsオペレーション:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "globalaccelerator:ListAccelerators",
            ],
            "Resource": "*"
        }
    ]
}

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

リソースベースのポリシーは、リソースにアタッチする JSON ポリシードキュメントです。これらのポリシーでは、指定されたプリンシパルがリソースに対して実行できるアクションと実行条件を指定できます。最も一般的なリソースベースのポリシーは、Amazon S3 バケットです。リソースベースのポリシーは、リソース固有のインラインポリシーです。マネージド型のリソースベースのポリシーはありません。

リソースベースのポリシーを使用して他の AWS アカウントのメンバーにアクセス許可を付与することは、IAM ロールに比べて、いくつかの利点があります。詳細については、「」を参照してください。IAM ロールとリソースベースのポリシーとの相違点()IAM ユーザーガイド。

ポリシーアクセスレベルの分類

IAM コンソールでは、アクションが以下のアクセスレベルの分類に従ってグループ分けされます。

リスト

サービス内のリソースを一覧表示し、オブジェクトの存否を判断するアクセス許可を提供します。このレベルのアクセス権を持つアクションはオブジェクトをリストできますが、リソースのコンテンツは表示されません。List アクセスレベルの大半のアクションは、特定のリソースに対しては実行できません。これらのアクションを使用してポリシーステートメントを作成する場合は、[All resources (すべてのリソース)] ("*") を指定する必要があります。

Read

サービス内のリソースのコンテンツと属性を読み取るアクセス許可を提供します。ただし、編集するアクセス許可はありません。たとえば、Amazon S3 オペレーションGetObjectおよびGetBucketLocation前提条件Readアクセスレベル.

書き込み

サービス内のリソースを作成、削除、または変更するためのアクセス許可を提供します。たとえば、Amazon S3 オペレーションCreateBucket,DeleteBucket, およびPutObject前提条件書き込みアクセスレベル.

アクセス権限の管理

サービス内のリソースに対するアクセス許可を付与または変更するためのアクセス許可を提供します。たとえば、ほとんどの IAM および AWS Organizations ポリシーアクションには、アクセス権限の管理アクセスレベル.

Tip

AWS アカウントのセキュリティを強化するには、ポリシーを制限したり定期的にモニタリングします。アクセス権限の管理アクセスレベルの分類

タグ付け

サービス内のリソースにアタッチされているタグを作成、削除、または変更するアクセス許可を提供します。たとえば、Amazon EC2CreateTagsおよびDeleteTagsオペレーションにはタグ付けアクセスレベル.

IAM の使用開始

AWS Identity and Access Management (IAM) は、サービスおよびリソースへのアクセスを安全に管理するための AWS のサービスです。IAM は追加料金なしで提供している AWS アカウントの機能です。

注記

IAM を開始する前に、「」で基本的な情報に目を通してください。AWS Global Accelerator の ID とアクセス管理。

AWS アカウントを初めて作成する場合は、すべての AWS のサービスとリソースに対して完全なアクセス権限を持つシングルサインイン ID で始めます。このアイデンティティは root ユーザーと呼ばれ、AWS アカウントの作成に使用したメールアドレスとパスワードでのサインインによりアクセスされます。強くお勧めしているのは、日常的なタスクには、それが管理者タスクであっても、root ユーザーを使用しないことです。代わりに、最初の IAM ユーザーを作成するためにのみ、ルートユーザーを使用するというベストプラクティスに従います。その後、ルートユーザーの認証情報を安全な場所に保管し、それらを使用して少数のアカウントおよびサービス管理タスクのみを実行します。

IAM 管理者ユーザーを作成します。

自分用の管理者ユーザーを作成し、そのユーザーを管理者グループに追加するには (コンソール)

  1. サインインします。IAM コンソールを選択して、アカウントの所有者としてルートユーザーをクリックし、AWS アカウントの E メールアドレスを入力します。次のページでパスワードを入力します。

    注記

    強くお勧めします、使用するためのベストプラクティスに従います。Administratorルートユーザー認証情報を追跡し、安全な場所に保管する IAM ユーザー。ルートユーザーとしてのサインインは、いくつかのアカウントとサービスの管理タスクの実行にのみ使用してください。

  2. ナビゲーションペインで [Users]、[Add user] の順に選択します。

  3. [ユーザー名] に「Administrator」と入力します。

  4. [AWS Management Console access (AWS マネジメントコンソールへのアクセス)] の横にあるチェックボックスをオンにします。[Custom password (カスタムパスワード)] を選択し、その後テキストボックスに新しいパスワードを入力します。

  5. (オプション) デフォルトでは、AWS は新しいユーザーの初回のサインイン時に新しいパスワードの作成を要求します。必要に応じて [User must create a new password at next sign-in (ユーザーは次回のサインイン時に新しいパスワードを作成する必要がある)] のチェックボックスをオフにして、新しいユーザーがサインインしてからパスワードをリセットできるようにできます。

  6. 選択次へ: アクセス許可。

  7. [Set permissions (アクセス許可の設定)] で、[Add user to group (ユーザーをグループに追加)] を選択します。

  8. [Create group] を選択します。

  9. [グループの作成] ダイアログボックスで、[グループ名] に「Administrators」と入力します。

  10. 選択フィルタポリシーの適用[]、[] の順に選択します。AWS マネージド-ジョブ機能をクリックして、テーブルの内容をフィルタリングします。

  11. ポリシーリストで、[AdministratorAccess] のチェックボックスをオンにします。次に、[Create group] を選択します。

    注記

    AdministratorAccess アクセス許可を使用して AWS の請求およびコスト管理コンソールにアクセスするには、IAM ユーザーと IAM ロールの請求情報へのアクセスを有効にする必要があります。これを行うには、請求コンソールへのアクセスの委任に関するチュートリアルのステップ 1 の手順に従ってください。

  12. グループのリストに戻り、新しいグループのチェックボックスをオンにします。必要に応じて [Refresh] を選択し、リスト内のグループを表示します。

  13. 選択次へ: タグ。

  14. (オプション) タグをキー - 値のペアとしてアタッチして、メタデータをユーザーに追加します。IAM におけるタグの使用の詳細については、「」を参照してください。IAM エンティティのタグ付け()IAM ユーザーガイド。

  15. 選択次へ: 確認をクリックして、新しいユーザーに追加するグループメンバーシップのリストを表示します。続行する準備ができたら、[Create user] を選択します。

このプロセスを繰り返して新しいグループとユーザーを作成して、AWS アカウントのリソースへのアクセス許可をユーザーに付与できます。ポリシーを使用して特定の AWS のリソースへのユーザーのアクセス許可を制限する方法については、「AWS リソースのアクセス管理」と「IAM アイデンティティベースのポリシーの例」を参照してください。

Global Accelerator の委任ユーザーの作成

AWS アカウントで複数のユーザーをサポートするには、許可するアクションのみ他のユーザーが実行できるようにアクセス許可を委任する必要があります。そのためには、それらのユーザーが必要なアクセス許可を持つ IAM グループを作成し、ユーザーの作成時に必要なグループに追加します。このプロセスを使用して、AWS アカウント全体のグループ、ユーザー、およびアクセス許可を設定できます。このソリューションは、AWS 管理者が手動でユーザーやグループを管理する中小企業で最もよく使用されます。大規模な組織では、カスタム IAM ロール,フェデレーション, またはシングルサインオン。

以下の手順では、という名前のユーザーを 3 つ作成します。arnav,carlos, およびmarthaという名前のアクセラレータを作成するアクセス許可を付与するポリシーをアタッチします。my-example-acceleratorしかし、次の30日以内のみ。以下に示す手順を使用して、さまざまなアクセス許可を持つユーザーを追加できます。

委任ユーザーを作成するには (コンソール)

  1. AWS マネジメントコンソールにサインインして、IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. ナビゲーションペインで [ユーザー]、[ユーザーの追加] の順に選択します。

  3. [ユーザー名] に「arnav」と入力します。

  4. [別のユーザーの追加] を選択し、2 番目のユーザーの名前として「carlos」と入力します。さらに [別のユーザーの追加] を選択し、3 番目のユーザーの名前として「martha」と入力します。

  5. [] のチェックボックスをオンにします。AWS マネジメントコンソールへのアクセス[]、[] の順に選択します。自動生成されたパスワード。

  6. 新しいユーザーがサインインしてからパスワードをリセットできるようにするには、必要に応じて [User must create a new password at next sign-in (ユーザーは次回のサインイン時に新しいパスワードを作成する必要がある)] のチェックボックスをオフにします。

  7. 選択次へ: アクセス許可。

  8. [Attach existing policies directly] を選択します。ユーザーの新しい管理ポリシーを作成します。

  9. [Create policy] を選択します。

    [ポリシーの作成] ウィザードが新しいタブまたはブラウザウィンドウで開きます。

  10. [Visual editor (ビジュアルエディタ)] タブで、[Choose a service (サービスの選択)] を選択します。[Global Accelerator 上部の検索ボックスを使用して、サービスのリストの結果を制限することができます。

    -サービスセクションが閉じ、アクションセクションが自動的に開きます。

  11. 許可する [グローバルアクセラレータ] アクションを選択します。たとえば、アクセラレータを作成するアクセス許可を付与するには、globalaccelerator:CreateAccelerator()アクションをフィルタする[] テキストボックス。グローバルアクセラレータアクションのリストがフィルタ処理されたら、[globalaccelerator:CreateAccelerator。

    グローバルアクセラレータのアクションは、アクセスレベルの分類別にグループ化され、各アクションが提供するアクセスのレベルをすばやく簡単に判断できます。詳細については、「ポリシーアクセスレベルの分類」を参照してください。

  12. 前の手順で選択したアクションが特定のリソースの選択をサポートしていない場合は、すべてのリソースが選択されます。その場合、このセクションを編集することはできません。

    リソースレベルのアクセス許可をサポートするアクションを 1 つ以上選択すると、これらのリソースタイプがビジュアルエディタの [Resources (リソース)] セクションに一覧表示されます。選択必要なアクションを選択したアクセラレーターリソースタイプをクリックして、ポリシーに特定のアクセラレータを入力するかどうかを選択します。

  13. すべてのリソースに対する globalaccelerator:CreateAccelerator アクションを許可する場合は、[All resources (すべててのリソース)] を選択します。

    リソースを指定する場合は、[Add ARN (ARN の追加)] を選択します。リージョンとアカウント ID (またはアカウント ID) を指定します (または [すべて) と入力し、my-example-acceleratorリソースに関して以下の操作を行います。次に、[Add (追加)] を選択します。

  14. [Specify request conditions (optional) (リクエスト条件の指定 (省略可能))] を選択します。

  15. 選択条件の追加アクセラレーターを作成するアクセス許可を付与します。以後 7 日間以内にします。今日の日付が 2019 年 1 月 1 日であるとします。

  16. [Condition Key (条件キー)] で、[aws:CurrentTime] を選択します。この条件キーでは、ユーザーによるリクエストの日時をチェックします。日時が指定した範囲内にある場合に限り、true が返されます (したがって、globalaccelerator:CreateAccelerator アクションが許可されます)。

  17. を使用する場合Qualifierデフォルト値のままにします。

  18. 許可された日時範囲の開始を指定するには、[Operator (演算子)] の [DateGreaterThan] を選択します。次に、[Value (値)] に「2019-01-01T00:00:00Z」と入力します。

  19. [Add (追加)] を選択して条件を保存します。

  20. [Add another condition (別の条件の追加)] を選択して終了日を指定します。

  21. 同様のステップに従って、許可された日時範囲の終了を指定します。[Condition Key (条件キー)] で、[aws:CurrentTime] を選択します。[Operator (演算子)] で、[DateLessThan] を選択します。[Value (値)] に、最初の日から 7 日後の日付である「2019-01-06T23:59:59Z」を入力します。次に [Add (追加)] を選択して条件を保存します。

  22. (省略可能) 作成するポリシーの JSON ポリシードキュメントを表示するには、JSONタブ. いつでも [Visual editor (ビジュアルエディタ)] タブと [JSON] タブを切り替えることができます。ただし、変更を加えたり、ポリシーの確認()Visual editor (ビジュアルエディタ)タブで、IAM はポリシーを再構成してビジュアルエディタに合わせて最適化することがあります。詳細については、「」を参照してください。ポリシーの再構成()IAM ユーザーガイド。

  23. 完了したら、[ポリシーの確認] を選択します。

  24. リポジトリの []ポリシーの確認ページ、名前に、globalaccelerator:CreateAcceleratorPolicy。[説明] に「Policy to grants permission to create an accelerator」と入力します。ポリシー概要を確認して、目的のアクセス許可を付与していることを確認し、[ポリシーの作成] を選択して新しいポリシーを保存します。

  25. 元のタブまたはウィンドウに戻り、ポリシーのリストを更新します。

  26. 検索ボックスに「globalaccelerator:CreateAcceleratorPolicy」と入力します。新しいポリシーの横のチェックボックスをオンにします。その後、[Next Step] を選択します。

  27. 選択次へ: 確認で新しいユーザーをプレビューします。続行する準備ができたら、[ユーザーの作成] を選択します。

  28. 新しいユーザーのパスワードをダウンロードまたはコピーし、安全にユーザーに配布します。別に、ユーザーにIAM ユーザーコンソールページへのリンクと、作成したユーザー名を入力します。

ユーザーに資格情報の自己管理を許可する

MFA を設定するには、ユーザーの仮想 MFA デバイスをホストするハードウェアに物理的にアクセスできる必要があります。たとえば、スマートフォンで実行される仮想 MFA デバイスを使用するユーザー用に MFA を設定するとします。その場合、ウィザードを完了するには、そのスマートフォンを利用できる必要があります。このため、ユーザーが自分の仮想 MFA デバイスを構成して管理できるようにすることをお勧めします。その場合、必要な IAM アクションを実行するアクセス許可をユーザーに付与する必要があります。

認証情報の自己管理を許可するポリシーを作成するには (コンソール)

  1. AWS マネジメントコンソールにサインインして、IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. ナビゲーションペインで、[ポリシー]、 [ポリシーの作成] の順に選択します。

  3. [JSON] タブを選択し、以下の JSON ポリシードキュメントからテキストをコピーします。このテキストを [JSON] ボックスに貼り付けます。

    重要

    次のポリシー例では、サインイン時のパスワードのリセットをユーザーに許可しません。新しいユーザーおよびパスワードの期限が切れているユーザーは、これを行う場合があります。この操作を許可するには、iam:ChangePassword と iam:CreateLoginProfile をステートメント BlockMostAccessUnlessSignedInWithMFA に追加します。ただし、IAM ではこのようなアクセス許可をお勧めしません。

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAllUsersToListAccounts",
            "Effect": "Allow",
            "Action": [
                "iam:ListAccountAliases",
                "iam:ListUsers",
                "iam:ListVirtualMFADevices",
                "iam:GetAccountPasswordPolicy",
                "iam:GetAccountSummary"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowIndividualUserToSeeAndManageOnlyTheirOwnAccountInformation",
            "Effect": "Allow",
            "Action": [
                "iam:ChangePassword",
                "iam:CreateAccessKey",
                "iam:CreateLoginProfile",
                "iam:DeleteAccessKey",
                "iam:DeleteLoginProfile",
                "iam:GetLoginProfile",
                "iam:ListAccessKeys",
                "iam:UpdateAccessKey",
                "iam:UpdateLoginProfile",
                "iam:ListSigningCertificates",
                "iam:DeleteSigningCertificate",
                "iam:UpdateSigningCertificate",
                "iam:UploadSigningCertificate",
                "iam:ListSSHPublicKeys",
                "iam:GetSSHPublicKey",
                "iam:DeleteSSHPublicKey",
                "iam:UpdateSSHPublicKey",
                "iam:UploadSSHPublicKey"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowIndividualUserToViewAndManageTheirOwnMFA",
            "Effect": "Allow",
            "Action": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },
        {
            "Sid": "AllowIndividualUserToDeactivateOnlyTheirOwnMFAOnlyWhenUsingMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ],
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        },
        {
            "Sid": "BlockMostAccessUnlessSignedInWithMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice",
                "iam:ListVirtualMFADevices",
                "iam:EnableMFADevice",
                "iam:ResyncMFADevice",
                "iam:ListAccountAliases",
                "iam:ListUsers",
                "iam:ListSSHPublicKeys",
                "iam:ListAccessKeys",
                "iam:ListServiceSpecificCredentials",
                "iam:ListMFADevices",
                "iam:GetAccountSummary",
                "sts:GetSessionToken"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

    このポリシーで行うこと

    • -AllowAllUsersToListAccountsステートメントにより、ユーザーはアカウントとそのユーザーに関する基本情報を IAM コンソールで表示できます。この 3 つのアクセス許可は独自のステートメントにある必要があります。これは、アクセス許可が特定のリソース ARN の指定をサポートせず、また指定する必要もなく、その代わりに "Resource" : "*" を指定するためです。

    • -AllowIndividualUserToSeeAndManageOnlyTheirOwnAccountInformationステートメントにより、ユーザーは自分のユーザー、パスワード、アクセスキー、署名証明書、SSH パブリックキー、および MFA 情報を IAM コンソールで管理できます。また、これにより、ユーザーは管理者から初回パスワードの設定を求められたときに初めてサインインを許可されます。リソース ARN は、これらのアクセス許可の使用をユーザー独自の IAM ユーザーエンティティにのみ制限します。

    • AllowIndividualUserToViewAndManageTheirOwnMFA ステートメントでは、ユーザーが各自の MFA デバイスを表示または管理できます。このステートメントのリソース ARN は、現在サインインしているユーザーと名前が一致するユーザーや MFA デバイスにのみアクセスを許可することに注意してください。ユーザーは、各自の MFA デバイス以外の MFA デバイスを作成または変更することはできません。

    • AllowIndividualUserToDeactivateOnlyTheirOwnMFAOnlyWhenUsingMFA ステートメントでは、MFA を使用してユーザーがサインインした場合に限り、ユーザーが各自の MFA デバイスのみを無効化できます。これにより、他者がアクセスキー (MFA デバイスではなく) のみを使用して MFA デバイスを無効化したり、アカウントにアクセスしたりできなくなります。

    • -BlockMostAccessUnlessSignedInWithMFAステートメントは、"Deny"および"NotAction"を使用して、IAM およびその他の AWS サービスのいくつかのアクションを除くすべてのアクションへのアクセスを拒否します。ifユーザーは MFA でサインインしていません。このステートメントのロジックの詳細については、「」を参照してください。Deny での NotAction の使用()IAM ユーザーガイド。ユーザーが MFA でサインインしている場合、"Condition" テストは失敗し、最後の "deny" ステートメントは無効になります。ユーザーのアクセス許可は、ユーザー用の他のポリシーやステートメントで決定されます。このステートメントにより、ユーザーが MFA でサインインしていない場合、ユーザーが実行できるのは表示されたアクションのみで、これらのアクションへのアクセスが別のステートメントやポリシーで許可されている場合に限られます。

      ...IfExists バージョンの Bool 演算子により、aws:MultiFactorAuthPresent キーが見つからない場合、条件は必ず true を返します。つまり､アクセスキーなどの長期認証情報を使用して API にアクセスするユーザーは以外の IAM API オペレーションへのアクセスを拒否されます。

  4. 完了したら、[ポリシーの確認] を選択します。

  5. [確認] ページで、ポリシー名として「Force_MFA」と入力します。ポリシーの説明には、次のように入力します。This policy allows users to manage their own passwords and MFA devices but nothing else unless they authenticate with MFA.ポリシーの確認概要ポリシーによって付与されたアクセス許可を確認し、[ポリシーの作成[] をクリックして作業内容を保存します。

    新しいポリシーが管理ポリシーの一覧に表示され､アタッチの準備ができます。

ポリシーをユーザーにアタッチするには (コンソール)

  1. ナビゲーションペインで [Users] を選択します。

  2. 編集するユーザーの名前 (チェックボックスではなく) を選択します。

  3. [Permissions] タブで、[Add permissions] を選択します。

  4. [Attach existing policies directly] を選択します。

  5. 検索ボックスに「Force」と入力し、リストの [Force_MFA] の横にあるチェックボックスをオンにします。続いて、[次へ] を選択します。確認。

  6. 変更内容を確認し、[Add permissions (アクセス許可の追加)] を選択します。

IAM ユーザーに対して MFA を有効化する

セキュリティを強化するために、グローバルアクセラレーターのリソースを保護するために、すべての IAM ユーザーが多要素認証 (MFA) を設定することをお勧めします。MFA では、さらなるセキュリティが追加されます。ユーザーは、通常のサインイン認証情報に加えて、AWS でサポートされている MFA デバイスから一意の認証情報を提供することを求められるためです。最も安全な AWS MFA デバイスは U2F セキュリティキーです。貴社にすでに U2F デバイスがある場合は、これらのデバイスを AWS 用に有効にしてください。それ以外の場合は、ユーザーごとにデバイスを購入し、ハードウェアが到着するまで待つ必要があります。詳細については、「」を参照してください。U2F セキュリティキーのイネーブル化()IAM ユーザーガイド。

U2F デバイスがまだない場合は、仮想 MFA デバイスを有効にすることで迅速に低コストで開始できます。これには、ソフトウェアアプリケーションを既存の電話や他のモバイルデバイスにインストールする必要があります。このデバイスは、時間同期されるワンタイムパスワードアルゴリズムに基づいて 6 桁の数値コードを生成します。ユーザーが AWS にサインインすると、デバイスからコードを入力するよう求められます。ユーザーに割り当てられた各仮想 MFA デバイスは一意であることが必要です。ユーザーは、別のユーザーの仮想 MFA デバイスからコードを入力して認証することはできません。仮想 MFA デバイスとして使用できるサポートされるアプリケーションのリストについては、「多要素認証」を参照してください。

注記

IAM ユーザーの MFA を設定するには、ユーザーの仮想 MFA デバイスをホストするモバイルデバイスに物理的にアクセスできる必要があります。

IAM ユーザーの仮想 MFA デバイスを有効にするには (コンソール)

  1. AWS マネジメントコンソールにサインインして、IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. ナビゲーションペインで [Users] を選択します。

  3. [ユーザー名] リストから対象の MFA ユーザーの名前を選択します。

  4. [Security credentials] タブを選択します。[Assigned MFA device (割り当て済み MFA デバイス)] の横で、[管理] を選択します。

  5. [MFA デバイスの管理] ウィザードで、[仮想 MFA デバイス]、[Continue (続行)] の順に選択します。

    IAM は QR コードを含む仮想 MFA デバイスの設定情報を生成して表示します。図は、QR コードに対応していないデバイスでの手動入力に利用できる「シークレット設定キー」を示しています。

  6. 仮想 MFA アプリを開きます。

    仮想 MFA デバイスをホストするために使用できるアプリケーションのリストについては、「多要素認証」を参照してください。仮想 MFA アプリが複数のアカウント (複数の仮想 MFA デバイス) をサポートしている場合は、新しいアカウント (新しい仮想 MFA デバイス) を作成するオプションを選択します。

  7. MFA アプリが QR コードをサポートしているかどうかを確認してから、次のいずれかを実行します。

    • ウィザードから [Show QR code (QR コードの表示)] を選択し、アプリを使用して QR コードをスキャンします。たとえば、カメラアイコンまたは [Scan code (スキャンコード)] に似たオプションを選択し、デバイスのカメラを使用してコードをスキャンします。

    • [MFA デバイスの管理] ウィザードで [Show secret key (シークレットキーの表示)] を選択し、MFA アプリにシークレットキーを入力します。

    これで仮想 MFA デバイスはワンタイムパスワードの生成を開始します。

  8. [MFA デバイスの管理] ウィザードの [MFA Code 1 (MFA コード 1)] ボックスに、現在仮想 MFA デバイスに表示されているワンタイムパスワードを入力します。デバイスが新しいワンタイムパススワードを生成するまで待ちます (最長 30 秒)。生成されたら [MFA Code 2 (MFA コード 2)] ボックスに 2 つ目のワンタイムパススワードを入力します。[Assign MFA (MFA の割り当て)] を選択します。

    重要

    コードを生成したら、即時にリクエストを送信します。コードを生成した後にリクエストを送信するまで時間がかかりすぎる場合、MFA デバイスはユーザーとは正常に関連付けられますが、その MFA デバイスは同期されません。これは、時刻ベースのワンタイムパスワード (TOTP) の有効期間が短いために起こります。その場合は、デバイスの再同期ができます。詳細については、「」を参照してください。仮想デバイスとハードウェア MFA デバイスの再同期()IAM ユーザーガイド。

    これで仮想 MFA デバイスを AWS で使用できます。