Amazon Elastic コンテナサービスのアイデンティティ とアクセス管理 - Amazon Elastic Container Service

Amazon Elastic コンテナサービスのアイデンティティ とアクセス管理

AWS Identity and Access Management (IAM) は、管理者が AWS のサービス リソースへのアクセスを安全に制御するために役立つ AWS のリソースです。IAM 管理者は、誰を認証 (サインイン) し、誰に Amazon ECS リソースの使用を承認する (アクセス許可を付与する) かを制御します。IAM は、追加費用なしで使用できる AWS のサービス です。

対象者

AWS Identity and Access Management (IAM) の用途は、Amazon ECS で行う作業によって異なります。

サービスユーザー – ジョブを実行するために Amazon ECS サービスを使用する場合は、管理者から必要なアクセス許可と認証情報が与えられます。さらに多くの Amazon ECS 機能を使用して作業を行う場合は、追加のアクセス許可が必要になることがあります。アクセスの管理方法を理解すると、管理者に適切なアクセス許可をリクエストするのに役立ちます。Amazon ECS の機能にアクセスできない場合は、「Amazon Elastic Container Service のアイデンティティとアクセスのトラブルシューティング」を参照してください。

サービス管理者 – 社内の Amazon ECS リソースを担当している場合は、通常、Amazon ECS へのフルアクセスがあります。管理者は、従業員にアクセス許可を付与する、Amazon ECS の機能やリソースを決定します。その後、IAM 理者にリクエストを送信して、サービスのユーザーのアクセス許可を変更する必要があります。このページの情報を確認し、IAM の基本概念を理解してください。会社で Amazon ECS を使用して IAM を利用する方法の詳細については、「IAM を使用するAmazon Elastic Container Service」を参照してください。

IAM 管理者 – 管理者は、 Amazon ECS へのアクセスを管理するポリシーの作成方法の詳細について確認する場合があります。IAM で使用できる Amazon ECS アイデンティティベースのポリシーの例を表示するには、「Amazon Elastic Container Service のアイデンティティベースのポリシーの例」を参照してください。

アイデンティティを使用した認証

認証は、アイデンティティ認証情報を使用して AWS にサインインする方法です。AWS Management Console を使用したサインインの詳細については、IAM ユーザーガイドの「IAM ユーザーまたはルートユーザーとしての AWS Management Console へのサインイン」を参照してください。

AWS アカウント のルートユーザーもしくは IAM ユーザーとして、または IAM ロールを引き受けることによって、認証を受ける (AWS にサインインする) 必要があります。会社のシングルサインオン認証を使用することも、Google や Facebook を使用してサインインすることもできます。このような場合、管理者は以前に IAM ロールを使用して ID フェデレーションを設定しました。他の会社の認証情報を使用して AWS にアクセスした場合、ロールを間接的に割り当てられています。

AWS Management Console に直接サインインするには、パスワードとルートユーザーのEメールまたは IAM ユーザー名を使用します。ルートユーザーまたは IAM ユーザーのアクセスキーを使用して AWS にプログラム的にアクセスできます。AWS は、ユーザーの認証情報を使用してリクエストに暗号的で署名するための SDK とコマンドラインツールを提供します。AWS ツールを使用しない場合は、リクエストに自分で署名する必要があります。そのためには、インバウンド API リクエストを認証するためのプロトコル、署名バージョン 4 を使用します。リクエストの認証の詳細については、AWS の全般リファレンスの「署名バージョン 4 の署名プロセス」を参照してください。

使用する認証方法を問わず、追加のセキュリティ情報の提供を要求される場合もあります。例えば、AWS では多要素認証 (MFA) を使用してアカウントのセキュリティを高めることを推奨しています。詳細については、IAM ユーザーガイドの「AWS での多要素認証 (MFA) の使用」を参照してください。

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

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

IAM ユーザーとグループ

[IAM user] (IAM ユーザー) は、単一のユーザーまたはアプリケーションに対する特定の許可を持つ AWS アカウント 内のアイデンティティです。IAM ユーザーは、ユーザー名とパスワード、アクセスキーのセットなど、長期的な認証情報を持つことができます。アクセスキーの生成方法の詳細については、[IAM User Guide] (IAM ユーザーガイド) の「Managing access keys for IAM users」(IAM ユーザーのアクセスキーの管理) をご参照ください。IAM ユーザーにアクセスキーを生成するとき、必ずキーペアを表示して安全に保存してください。後で、シークレットアクセスキーを回復することはできません。新しいアクセスキーペアを生成する必要があります。

[IAM group] (IAM グループ) は、IAM ユーザーのコレクションを指定するアイデンティティです。グループとしてサインインすることはできません。グループを使用して、一度に複数のユーザーに対して許可を指定できます。多数のユーザーのセットがある場合、グループを使用すると管理が容易になります。例えば、「IAMAdmins」という名前のグループを設定して、そのグループに IAM リソースを管理するアクセス許可を与えることができます。

ユーザーは、ロールとは異なります。ユーザーは 1 名の特定の人またはアプリケーションに一意に関連付けられますが、ロールはそれを必要とする任意の人が引き受けるようになっています。ユーザーには永続的な長期の認証情報がありますが、ロールではテンポラリ認証情報が利用できます。詳細については、IAM ユーザーガイドの「IAM ユーザーの作成が適している場合 (ロールではなく)」を参照してください。

IAM ロール

IAM ロールは、特定のアクセス許可を持つ、AWS アカウント 内のアイデンティティです。これは IAM ユーザーに似ていますが、特定のユーザーには関連付けられていません。ロールを切り替えることによって、AWS Management Console で IAM ロールを一時的に引き受けることができます。ロールを引き受けるには、AWS CLI または AWS API 操作を呼び出すか、カスタム URL を使用します。ロールを使用する方法の詳細については、IAM ユーザーガイドの 「IAM ロールの使用」を参照してください。

IAM ロールとテンポラリ認証情報は、次の状況で役立ちます。

  • [Temporary IAM user permissions](一時的な IAM ユーザーアクセス許可) – IAM ユーザーは、特定のタスクに対して複数の異なるアクセス許可を一時的に IAM ロールで引き受けることができます。

  • [Federated user access] (フェデレーティッドユーザーアクセス) – IAM ユーザーを作成する代わりに、AWS Directory Service、エンタープライズユーザーディレクトリー、またはウェブ ID プロバイダーからの既存のアイデンティティを使用することができます。このようなユーザーは [federated users] (フェデレーティッドユーザー) と呼ばれます。AWS では、[identity provider] (ID プロバイダー) を通じてアクセスがリクエストされたとき、フェデレーティッドユーザーにロールを割り当てます。フェデレーティッドユーザーの詳細については、IAM ユーザーガイドの「フェデレーティッドユーザーとロール」を参照してください。

  • [Cross-account access] (クロスアカウントアクセス) – IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを別のアカウントの人物 (信頼済みプリンシパル) に許可できます。ロールは、クロスアカウントアクセスを許可する主な方法です。ただし、一部の AWS のサービス では、(ロールをプロキシとして使用する代わりに) リソースにポリシーを直接アタッチできます。クロスアカウントアクセスでのロールとリソースベースのポリシーの違いの詳細については、「IAM ユーザーガイド」の「IAM ロールとリソースベースのポリシーとの相違点」を参照してください。

  • クロスサービスアクセス – 一部の AWS のサービス は、他の AWS のサービス の機能を使用します。例えば、サービスで呼び出しを行う場合、そのサービスでは Amazon EC2 でアプリケーションを実行したり、Amazon S3 にオブジェクトを保存したりするのが一般的です。サービスは、呼び出し元プリンシパルの許可、サービスロール、またはサービスにリンクされたロールを使用してこれを行う場合があります。

    • [Principal permissions] (プリンシパル許可) – IAM ユーザーまたはロールを使用して AWS でアクションを実行する場合、そのユーザーはプリンシパルとみなされます。ポリシーは、プリンシパルに許可を付与します。一部のサービスを使用する場合、別のサービスで別のアクションをトリガーするアクションを実行することがあります。この場合、両方のアクションを実行するための許可が必要です。アクションがポリシーで追加の依存アクションを必要とするかどうかを確認するには、サービス認証リファレンスの「Amazon Elastic Container Service のアクション、リソース、および条件キー」をご参照ください。

    • [Service role] (サービスロール) – サービスがユーザーに代わってアクションを実行するために引き受ける [IAM role] (IAM ロール) です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、「IAM ユーザーガイド」の「AWS のサービス に許可を委任するロールの作成」を参照してください。

    • [Service-linked role] (サービスにリンクされたロール) – サービスにリンクされたロールは、AWS のサービス にリンクされたサービスロールの一種です。サービスは、ユーザーに代わってアクションを実行するロールを引き受けることができます。サービスリンクロールは、IAM アカウント内に表示され、サービスによって所有されます。IAM 管理者は、サービスにリンクされたロールの許可を表示できますが、編集することはできません。

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

IAM ロールを使用するか IAM ユーザーを使用するかどうかについては、IAM ユーザーガイドの「(IAMユーザーではなく) IAM ロールを作成するとき」を参照してください。

ポリシーを使用したアクセスの管理

AWS でのアクセスは、ポリシーを作成し、それらを IAM アイデンティティまたは AWS リソースにアタッチすることで制御できます。ポリシーは AWS のオブジェクトであり、ID やリソースに関連付けて、これらの許可を定義します。root ユーザーまたは IAM ユーザーとしてサインインすることも、IAM ロールを引き受けることもできます。その後でリクエストを行うと、AWS が関連する ID ベースまたはリソースベースのポリシーを評価します。ポリシーでの許可により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWS に保存されます。JSON ポリシードキュメントの構造と内容の詳細については、IAM ユーザーガイドの 「JSON ポリシー概要」を参照してください。

管理者は AWS JSON ポリシーを使用して、誰が何にアクセスできるかを指定できます。つまり、どのプリンシパルがどのリソースに対してどのような条件下でアクションを実行できるかということです。

すべての IAM エンティティ (ユーザーまたはロール) は、アクセス許可のない状態からスタートします。言い換えると、デフォルトでは、ユーザーは何もできず、自分のパスワードを変更することすらできません。何かを実行するアクセス許可をユーザーに付与するには、管理者がユーザーにアクセス許可ポリシーを添付する必要があります。また、管理者は、必要な許可があるグループにユーザーを追加できます。管理者がグループに許可を付与すると、そのグループ内のすべてのユーザーにこれらの許可が付与されます。

IAM ポリシーは、演算の実行方法を問わず、アクションの許可を定義します。例えば、iam:GetRole アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、 AWS Management Console 、 AWS CLI 、または AWS API からロールの情報を取得できます。

ID ベースのポリシー

ID ベースのポリシーは、IAM ユーザー、ユーザーのグループ、ロールなど、アイデンティティにアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーを作成する方法については、「IAM User Guide」 (IAM ユーザーガイド) の「Creating IAM policies」(IAM User GuideIAM ポリシーの作成) をご参照ください。

ID ベースのポリシーは、さらにインラインポリシーまたはマネージドポリシーに分類できます。インラインポリシーは、単一のユーザー、グループ、またはロールに直接埋め込まれています。マネージドポリシーは、AWS アカウント 内の複数のユーザー、グループ、およびロールにアタッチできるスタンドアロンポリシーです。マネージドポリシーには、 AWS マネージドポリシーとカスタマーマネージドポリシーが含まれます。マネージドポリシーまたはインラインポリシーのいずれかを選択する方法については、IAM ユーザーガイドの「マネージドポリシーとインラインポリシーの比較」を参照してください。

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

リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーの例は、IAM role trust policies (ロールの信頼ポリシー) および Amazon S3 bucket policies (バケットポリシー) です。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスを制御できます。ポリシーが添付されているリソースの場合、ポリシーは、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件を定義します。リソースベースのポリシーで、プリンシパルを指定する必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーティッドユーザー、または AWS のサービス を含めることができます。

リソースベースのポリシーは、そのサービス内にあるインラインポリシーです。リソースベースのポリシーで IAM の AWS マネージドポリシーを使用することはできません。

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

アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするための許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。

Amazon S3、AWS WAF、および Amazon VPC は、ACL をサポートするサービスの例です。ACL の詳細については、「Amazon Simple Storage Service Developer Guide」(Amazon Simple Storage Service デベロッパーガイド) の「Access control list (ACL) overview」(アクセスコントロールリスト (ACL) の概要) をご参照ください。

その他のポリシータイプ

AWS では、別のあまり一般的ではないポリシータイプもサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の許可を設定できます。

  • アクセス許可の境界 – 許可の境界は、ID ベースのポリシーが IAM エンティティ (IAM ユーザーまたはロール) に付与できる許可の上限を設定する高度な機能です。エンティティの許可の境界を設定できます。結果として得られるアクセス許可は、エンティティの ID ベースのポリシーとその許可の境界の共通部分です。Principal フィールドでユーザーまたはロールを指定するリソースベースのポリシーは、許可の境界では制限されません。これらのポリシーのいずれかを明示的拒否した場合、許可がオーバーライドされます。許可の境界の詳細については、「IAM User Guide」(IAM ユーザーガイド) の「Permissions boundaries for IAM entities」(IAM エンティティの許可の境界) を参照してください。

  • [Service control policies (SCPs)] (サービスコントロールポリシー (SCP)) – SCP は、AWS Organizations で組織や組織単位 (OU) に最大アクセス許可を指定する JSON ポリシーです。AWS Organizations は、お客様のビジネスが所有する複数の AWS アカウント をグループ化し、一元的に管理するサービスです。組織内のすべての機能を有効にすると、サービス制御ポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP はメンバーアカウントのエンティティ (各 AWS アカウント ルートユーザーなど) に対するアクセス許可を制限します。組織および SCP の詳細については、AWS Organizations ユーザーガイドの「SCP の仕組み」を参照してください。

  • [Session policies] (セッションポリシー) – セッションポリシーは、ロールまたはフェデレーティッドユーザーの一時セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果として得られるセッションの許可は、ユーザーまたはロールのID ベースのポリシーとセッションポリシーの共通部分です。また、リソースベースのポリシーから許可が派生する場合もあります。これらのポリシーのいずれかを明示的拒否した場合、許可がオーバーライドされます。詳細については、IAM ユーザーガイドセッションポリシーを参照してください。

複数のポリシータイプ

1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成される許可を理解するのがさらに複雑になります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、IAM ユーザーガイド の「ポリシーの評価ロジック」を参照してください。