# Amazon RDS での Identity and Access Management
AWS Identity and Access Management (IAM) は管理者が AWS リソースへのアクセスを安全に制御するために役立つ AWS のサービスです。IAM 管理者は、誰 (のサインイン) を*認証*して、Amazon RDS リソースの使用を*承認* (許可) するかを管理します。IAM は、追加費用なしで使用できる AWS のサービス です。
**Topics**
+ [対象者](#security_iam_audience)
+ [アイデンティティを使用した認証](#security_iam_authentication)
+ [ポリシーを使用したアクセスの管理](#security_iam_access-manage)
+ [Amazon RDS と IAM の連携](security_iam_service-with-iam.md)
+ [Amazon RDS のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)
+ [AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md)
+ [Amazon RDS の AWS 管理ポリシーに関する更新](rds-manpol-updates.md)
+ [サービス間での混乱した代理問題の防止](cross-service-confused-deputy-prevention.md)
+ [MariaDB、MySQL、および PostgreSQL の IAM データベース認証](UsingWithRDS.IAMDBAuth.md)
+ [Amazon RDS のアイデンティティおよびアクセスのトラブルシューティング](security_iam_troubleshoot.md)
## 対象者
AWS Identity and Access Management (IAM) の使用方法は、Amazon RDS で行う作業によって異なります。
**サービスユーザー ** - ジョブを実行するために Amazon RDS サービスを使用する場合は、管理者が必要なアクセス許可と認証情報を用意します。作業を実行するためにさらに多くの Amazon RDS 機能を使用するとき、追加のアクセス許可が必要になる場合があります。アクセスの管理方法を理解すると、管理者から適切なアクセス許可をリクエストするのに役に立ちます。Amazon RDS の機能にアクセスできない場合は、「[Amazon RDS のアイデンティティおよびアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照してください。
**サービス管理者** - 社内の Amazon RDS リソースを担当している場合は、おそらく Amazon RDS へのフルアクセスがあります。従業員がどの Amazon RDS 機能とリソースアクセスする必要があるかを決定するのは管理者の仕事です。その後で、サービスユーザーのアクセス許可を変更するために、 管理者にリクエストを送信する必要があります。このページの情報を点検して、IAM の基本概念を理解してください。お客様の会社で Amazon RDS で IAM を利用する方法の詳細については、「[Amazon RDS と IAM の連携](security_iam_service-with-iam.md)」を参照して ください。
**管理者** - 管理者は、Amazon RDS へのアクセスを管理するポリシーの作成方法の詳細について確認したい場合があります。IAM で使用できる Amazon RDS アイデンティティベースのポリシーの例を表示するには、「[Amazon RDS のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照して ください。
## アイデンティティを使用した認証
認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、AWS アカウントのルートユーザー、IAM ユーザーとして、または IAM ロールを引き受けることによって、認証される必要があります。
AWS IAM アイデンティティセンター (IAM Identity Center)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーテッドアイデンティティとしてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[How to sign in to your AWS アカウント](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、AWS はリクエストに暗号で署名するための SDK と CLI を提供します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対する AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウントのルートユーザー
AWS アカウントを作成すると、すべての AWS のサービスとリソースに対する完全なアクセス権を持つ AWS アカウント*ルートユーザー*と呼ばれる 1 つのサインイン ID を使用して開始します。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスでは、人間のユーザーが一時的な認証情報を使用して AWS のサービス にアクセスする際、アイデンティティプロバイダーとのフェデレーションを使用することが求められます。
*フェデレーテッドアイデンティティ*は、エンタープライズディレクトリ、ウェブ ID プロバイダー、Directory Service のユーザーであり、ID ソースからの認証情報を使用して AWS のサービスにアクセスするユーザーです。フェデレーティッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、AWS IAM アイデンティティセンター をお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、1 人のユーザーまたは 1 つのアプリケーションに対して特定の許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには ID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) IAM ユーザーのコレクションを指定し、大量のユーザーのアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
IAM データベース認証を使用して、DB インスタンスを認証できます。
IAM データベース認証は、次の DB エンジンで使用できます。
+ RDS for MariaDB
+ RDS for MySQL
+ RDS for PostgreSQL
IAM を使用した DB インスタンスの認証の詳細については、「[MariaDB、MySQL、および PostgreSQL の IAM データベース認証](UsingWithRDS.IAMDBAuth.md)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定の許可を持つ、AWS アカウント内のアイデンティティです。これはユーザーに似ていますが、特定のユーザーに関連付けられていません。[ロールを切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)ことによって、AWS マネジメントコンソールで IAM ロールを一時的に引き受けることができます。ロールを引き受けるには、AWS CLIまたは AWS API オペレーションを呼び出すか、カスタム URL を使用します。ロールを使用する方法の詳細については、「*IAM ユーザーガイド*」の「[IAM ロールの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html)」を参照してください。
IAM ロールと一時的な認証情報は、次の状況で役立ちます:
+ **一時的なユーザーアクセス許可** - ユーザーは、特定のタスクのための複数の異なるアクセス許可を一時的に受け取るために、IAM ロールを引き受けることができます。
+ **フェデレーションユーザーアクセス** – フェデレーテッド ID に許可を割り当てるには、ロールを作成してそのロールの許可を定義します。フェデレーテッド ID が認証されると、その ID はロールに関連付けられ、ロールで定義されている許可が付与されます。フェデレーションのロールについては、「*IAM ユーザーガイド*」の「[サードパーティー ID プロバイダー (フェデレーション) 用のロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html)」を参照してください。IAM Identity Center を使用する場合は、許可セットを設定します。アイデンティティが認証後にアクセスできるものを制御するため、IAM Identity Center は、権限セットを IAM のロールに関連付けます。アクセス許可セットの詳細については、「*AWS IAM アイデンティティセンター User Guide*」の「[Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)」を参照してください。
+ **クロスアカウントアクセス** - IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを、別のアカウントの人物 (信頼済みプリンシパル) に許可できます。クロスアカウントアクセス権を付与する主な方法は、ロールを使用することです。ただし、一部の AWS のサービスでは、(ロールをプロキシとして使用する代わりに) リソースにポリシーを直接アタッチできます。クロスアカウントアクセスでのロールとリソースベースのポリシーの違いの詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)」の「*IAM ロールとリソースベースのポリシーとの相違点*」を参照してください。
+ **クロスサービスアクセス権** - 一部の AWS のサービスでは、他の AWS のサービスの機能を使用します。例えば、あるサービスで呼び出しを行うと、通常そのサービスによって Amazon EC2 でアプリケーションが実行されたり、Amazon S3 にオブジェクトが保存されたりします。サービスでは、呼び出し元プリンシパルの許可、サービスロール、またはサービスリンクロールを使用してこれを行う場合があります。
+ **転送アクセスセッション** – 転送アクセスセッション (FAS) は、AWS のサービスを呼び出すプリンシパルの権限を、AWS のサービスのリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
+ **サービスロール** - サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、「*IAM ユーザーガイド*」の「[AWS のサービス に許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。
+ **サービスにリンクされたロール** - サービスにリンクされたロールは、AWS のサービス にリンクされたサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
+ **Amazon EC2 で実行されているアプリケーション** - EC2 インスタンスで実行され、AWS CLI または AWS API リクエストを行っているアプリケーションの一時的な認証情報を管理するには、IAM ロールを使用できます。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。AWS ロールを EC2 インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスに添付されたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時的な認証情報を取得できます。詳細については、「*IAM ユーザーガイド*」の「[Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用して許可を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)」を参照してください。
IAM ロールを使用するべきかどうかについては、*IAM ユーザーガイド*の「[IAM ロールの作成が適している場合 (ユーザーではなく)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role)」を参照してください。
## ポリシーを使用したアクセスの管理
AWS でのアクセスは、ポリシーを作成し、それらを IAM アイデンティティまたは AWS リソースに添付することで制御できます。ポリシーは AWS のオブジェクトであり、ID やリソースに関連付けられて、これらのアクセス許可を定義します。AWS は、エンティティ (ルートユーザー、ユーザー、または IAM ロール) によってリクエストが行われると、それらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWSに保存されます。JSON ポリシードキュメントの構造と内容の詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、AWS リソースへのアクセス権を持つユーザーと、これらのリソースに対して実行できるアクションを指定できます。すべての IAM エンティティ (アクセス許可セットまたはロール) は、アクセス許可のない状態からスタートします。言い換えると、デフォルト設定では、ユーザーは何もできず、自分のパスワードを変更することすらできません。何かを実行する許可をユーザーに付与するには、管理者がユーザーに許可ポリシーをアタッチする必要があります。また、管理者は、必要な許可があるグループにユーザーを追加できます。管理者がグループに許可を付与すると、そのグループ内のすべてのユーザーにこれらの許可が付与されます。
IAM ポリシーは、オペレーションの実行方法を問わず、アクションの許可を定義します。例えば、`iam:GetRole` アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からロール情報を取得できます。
### アイデンティティベースポリシー
ID ベースのポリシーは、 アクセス許可セットやロールなどの ID にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティが実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーを作成する方法については、[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)の *IAM ポリシーの作成*を参照してください。
アイデンティティベースのポリシーは、さらに*インラインポリシー*または*マネージドポリシー*に分類できます。インラインポリシーは、単一のアクセス許可セットまたはロールに直接埋め込まれます。マネージドポリシーは、AWS アカウント内の複数のアクセス許可セットおよびロールにアタッチできるスタンドアロンポリシーです。マネージドポリシーには、AWS マネージドポリシーとカスタマー管理ポリシーがあります。マネージドポリシーまたはインラインポリシーのいずれかを選択する方法については、*IAM ユーザーガイド*の[マネージドポリシーとインラインポリシーの比較](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline)を参照してください。
Amazon RDSに固有の AWS マネージドポリシーの詳細については、「[AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md)」を参照してください。
### 他のポリシータイプ
AWS では、他の一般的ではないポリシータイプをサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の権限を設定できます。
+ **アクセス許可の境界** - アクセス許可の境界は、ID ベースのポリシーによって IAM エンティティ (アクセス許可セットまたはロール) に付与できるアクセス許可の上限を設定する高度な機能です。エンティティに許可の境界を設定できます。結果として許可される範囲は、エンティティのアイデンティティベースポリシーとその許可の境界の共通部分になります。`Principal` フィールドでアクセス許可セットまたはロールを指定するリソースベースのポリシーは、アクセス許可の境界によって制限されません。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。許可の境界の詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティの許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** – SCP は、AWS Organizations で組織や組織単位 (OU) に最大アクセス許可を指定する JSON ポリシーです。AWS Organizationsは、お客様のビジネスが所有する複数の AWS アカウントをグループ化し、一元的に管理するサービスです。組織内のすべての機能を有効にすると、サービスコントロールポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP はメンバーアカウントのエンティティに対する権限を制限します (各 AWS アカウントのルートユーザー など)。Organizations と SCP の詳細については、*AWS Organizationsユーザーガイド*の「[SCP の仕組み](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html)」を参照してください。
+ **セッションポリシー** - セッションポリシーは、ロールまたはフェデレーションユーザーの一時的なセッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果としてのセッションのアクセス許可は、アクセス許可セットまたはロールの ID ベースのポリシーとセッションポリシーの共通部分になります。また、リソースベースのポリシーから権限が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成される権限を理解するのがさらに難しくなります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、*IAM ユーザーガイド*の[ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)を参照してください。