Amazon Relational Database Service
ユーザーガイド

Amazon RDS での Identity and Access Management

AWS Identity and Access Management (IAM) は、管理者が AWS リソースへのアクセスを安全にコントロールするために役立つ AWS のサービスです。IAM 管理者は、Amazon RDS リソースを使用するために認証 (サインイン) および承認 (アクセス許可を持つ) される者を制御します。IAM は、追加料金なしで使用できる AWS のサービスです。

対象者

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

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

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

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

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

認証は、アイデンティティ認証情報を使用して AWS にサインインする方法です。AWS マネジメントコンソール を使用するサインインの詳細については、IAM ユーザーガイド の「IAM コンソールとサインインページ」を参照してください。

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

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

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

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

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

IAM ユーザーとグループ

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

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

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

IAM データベース認証を使用して、DB インスタンスを認証できます。

IAM データベース認証は、次の DB エンジンで使用できます。

  • Amazon RDS for MySQL

  • Amazon RDS for PostgreSQL

IAM を使用した DB インスタンスの認証の詳細については、MySQL および PostgreSQL の IAM データベース認証 を参照してください。

IAM ロール

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

IAM ロールと一時的な認証情報は、次の状況で役立ちます。

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

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

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

  • AWS サービスアクセス – サービスロールは、サービスがお客様に代わってお客様のアカウントでアクションを実行するために引き受ける IAM ロールです。一部の AWS のサービス環境を設定するときに、サービスが引き受けるロールを定義する必要があります。このサービスロールには、サービスが必要とする AWS のリソースにサービスがアクセスするために必要なすべてのアクセス権限を含める必要があります。サービスロールはサービスによって異なりますが、多くのサービスロールでは、そのサービスの文書化された要件を満たしている限り、アクセス権限を選択することができます。サービスロールは、お客様のアカウント内のみでアクセスを提供します。他のアカウントのサービスへのアクセス権を付与するためにサービスロールを使用することはできません。IAM 内部からロールを作成、修正、削除できます。たとえば、Amazon Redshift がお客様に代わって Amazon S3 バケットにアクセスし、バケットからデータを Amazon Redshift クラスターにロードすることを許可するロールを作成できます。詳細については、IAM ユーザーガイドAWS サービスにアクセス権限を委任するロールの作成を参照してください。

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

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

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

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

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

IAM ポリシーは、オペレーションの実行方法を問わず、アクションのアクセス許可を定義します。たとえば、iam:GetRole アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からロールの情報を取得できます。

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

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

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

アカウントのユーザーにアタッチ可能な以下の AWS 管理ポリシーは、Amazon RDS に固有のものです。

  • AmazonRDSReadOnlyAccess – 指定された AWS アカウントのすべての Amazon RDS リソースへの読み取り専用アクセス権限を付与します。

  • AmazonRDSFullAccess – ルート AWS アカウントのすべての Amazon RDS リソースへの完全なアクセス許可を付与します。

その他のポリシータイプ

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

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

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

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

複数のポリシータイプ

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

Amazon RDS の Identity and Access Management に関する詳細については、以下のページに進んでください。