# Amazon Aurora での 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 Aurora と IAM の連携](security_iam_service-with-iam.md)
+ [Amazon Aurora のアイデンティティベースのポリシーの例](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)
+ [の IAM データベース認証](UsingWithRDS.IAMDBAuth.md)
+ [Amazon Aurora のアイデンティティおよびアクセスのトラブルシューティング](security_iam_troubleshoot.md)
## 対象者
AWS Identity and Access Management (IAM) の使用方法は、Amazon Aurora で行う作業によって異なります。
**サービスユーザー ** - ジョブを実行するために Aurora サービスを使用する場合は、管理者が必要なアクセス許可と認証情報を用意します。作業を実行するためにさらに多くの Aurora 機能を使用するとき、追加のアクセス許可が必要になる場合があります。アクセスの管理方法を理解すると、管理者から適切なアクセス許可をリクエストするのに役に立ちます。Aurora の機能にアクセスできない場合は、「[Amazon Aurora のアイデンティティおよびアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照してください。
**サービス管理者** - 社内の Aurora リソースを担当している場合は、おそらく Aurora へのフルアクセスがあります。従業員がどの Aurora 機能とリソースアクセスする必要があるかを決定するのは管理者の仕事です。その後で、サービスユーザーのアクセス許可を変更するために、 管理者にリクエストを送信する必要があります。このページの情報を点検して、IAM の基本概念を理解してください。お客様の会社で Aurora で IAM を利用する方法の詳細については、「[Amazon Aurora と IAM の連携](security_iam_service-with-iam.md)」を参照して ください。
**管理者** - 管理者は、Aurora へのアクセスを管理するポリシーの作成方法の詳細について確認したい場合があります。IAM で使用できる Aurora アイデンティティベースのポリシーの例を表示するには、「[Amazon Aurora のアイデンティティベースのポリシーの例](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 データベース認証は、Aurora で使用できます。IAM を使用した DB クラスターの認証の詳細については、「[ の 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 Auroraに固有の 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)を参照してください。
# Amazon Aurora と IAM の連携
IAM を使用して、Amazon Aurora へのアクセスを管理するには、Aurora で使用できる IAM の機能を理解しておく必要があります。
次の表は、Amazon Aurora で使用できる IAM 機能の一覧です。
| IAM 機能 | Amazon Aurora のサポート |
| --- | --- |
| [アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies) | あり |
| [リソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies) | なし |
| [ポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions) | あり |
| [ポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources) | はい |
| [ポリシー条件キー (サービス固有)](#UsingWithRDS.IAM.Conditions) | はい |
| [ACL](#security_iam_service-with-iam-acls) | いいえ |
| [属性ベースのアクセスコントロール (ABAC) (ポリシーのタグ)](#security_iam_service-with-iam-tags) | はい |
| [一時的な認証情報](#security_iam_service-with-iam-roles-tempcreds) | はい |
| [転送アクセスセッション](#security_iam_service-with-iam-principal-permissions) | はい |
| [サービスロール](#security_iam_service-with-iam-roles-service) | あり |
| [サービスリンクロール](#security_iam_service-with-iam-roles-service-linked) | はい |
Amazon Aurora や AWS の他のサービスと IAM との連携の概要については、*IAM ユーザーガイド*の「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
**Topics**
+ [Aurora アイデンティティベースのポリシー](#security_iam_service-with-iam-id-based-policies)
+ [Aurora 内のリソースベースのポリシー](#security_iam_service-with-iam-resource-based-policies)
+ [Aurora のポリシーアクション](#security_iam_service-with-iam-id-based-policies-actions)
+ [Aurora のポリシーリソース](#security_iam_service-with-iam-id-based-policies-resources)
+ [Aurora のポリシー条件キー](#UsingWithRDS.IAM.Conditions)
+ [Aurora のアクセスコントロールリスト (ACL)](#security_iam_service-with-iam-acls)
+ [Aurora タグを使ったポリシーにおける属性ベースのアクセスコントロール (ABAC)](#security_iam_service-with-iam-tags)
+ [Aurora での一時的な認証情報の使用](#security_iam_service-with-iam-roles-tempcreds)
+ [Aurora のフォワードアクセスセッション](#security_iam_service-with-iam-principal-permissions)
+ [Aurora のサービスロール](#security_iam_service-with-iam-roles-service)
+ [Aurora のサービスリンクロール](#security_iam_service-with-iam-roles-service-linked)
## Aurora アイデンティティベースのポリシー
**アイデンティティベースのポリシーのサポート:** あり。
アイデンティティベースのポリシーは、IAM ユーザーグループ、ユーザーのグループ、ロールなど、アイデンティティにアタッチできる JSON 許可ポリシードキュメントです。これらのポリシーは、ユーザーとロールが実行できるアクション、リソース、および条件をコントロールします。アイデンティティベースポリシーの作成方法については、「*IAM ユーザーガイド*」の「[カスタマー管理ポリシーでカスタム IAM アクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)」を参照してください。
IAM アイデンティティベースのポリシーでは、許可または拒否するアクションとリソース、およびアクションを許可または拒否する条件を指定できます。JSON ポリシーで使用できるすべての要素について学ぶには、*IAM ユーザーガイド*の「[IAM JSON ポリシーの要素のリファレンス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)」を参照してください。
### Aurora アイデンティティベースのポリシーの例
Aurora アイデンティティベースのポリシーの例を表示するには、「[Amazon Aurora のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## Aurora 内のリソースベースのポリシー
**リソースベースのポリシーのサポート:** なし。
リソースベースのポリシーは、リソースに添付する JSON ポリシードキュメントです。リソースベースのポリシーには例として、IAM *ロールの信頼ポリシー*や Amazon S3 *バケットポリシー*があげられます。リソースベースのポリシーをサポートするサービスでは、サービス管理者はポリシーを使用して特定のリソースへのアクセスをコントロールできます。ポリシーがアタッチされているリソースの場合、指定されたプリンシパルがそのリソースに対して実行できるアクションと条件は、ポリシーによって定義されます。リソースベースのポリシーで、[プリンシパルを指定する](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)必要があります。プリンシパルには、アカウント、ユーザー、ロール、フェデレーションユーザー、または AWS のサービス を含めることができます。
クロスアカウントアクセスを有効にするには、全体のアカウント、または別のアカウントの IAM エンティティを、リソースベースのポリシーのプリンシパルとして指定します。詳細については、IAM ユーザーガイド**の[IAM でのクロスアカウントリソースアクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)を参照してください。
## Aurora のポリシーアクション
**ポリシーアクションのサポート:** あり。
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどのような**リソース**にどのような**条件**で**アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
Aurora のポリシーアクションは、アクションの前にプレフィックス `rds:` を使用します。例えば、Amazon RDS `DescribeDBInstances` API オペレーションを使用して DB インスタンスを指定するアクセス許可を付与するには、ポリシーに `rds:DescribeDBInstances` アクションを含めます。ポリシーステートメントには、`Action` または `NotAction` エレメントを含める必要があります。Aurora は、このサービスで実行できるタスクを記述する独自のアクションのセットを定義します。
単一のステートメントに複数のアクションを指定するには、次のようにコンマで区切ります。
```
"Action": [
"rds:action1",
"rds:action2"
```
ワイルドカード \$1を使用して複数のアクションを指定することができます。例えば、`Describe` という単語で始まるすべてのアクションを指定するには、次のアクションを含めます。
```
"Action": "rds:Describe*"
```
Aurora アクションのリストを確認するには、「サービス認可リファレンス」の「[Amazon RDS によって定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions)」を参照してください。**
## Aurora のポリシーリソース
**ポリシーリソースのサポート:** あり。
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどの**リソース**に対してどのような**条件下で****アクション**を実行できるかということです。
`Resource` JSON ポリシー要素はアクションが適用されるオブジェクトを指定します。ベストプラクティスとして、[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) を使用してリソースを指定します。リソースレベルのアクセス許可をサポートしないアクションの場合は、ステートメントがすべてのリソースに適用されることを示すために、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
DB インスタンスリソースには、次の Amazon リソースネーム (ARN) があります。
```
arn:${Partition}:rds:${Region}:${Account}:{ResourceType}/${Resource}
```
ARN の形式の詳細については、「[Amazon リソースネーム ARN と AWS のサービスの名前空間](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html)」を参照してください。
例えば、ステートメントで `dbtest` DB インスタンスを指定するには、次の ARN を使用します。
```
"Resource": "arn:aws:rds:us-west-2:123456789012:db:dbtest"
```
特定のアカウントに属するすべての DB インスタンスを指定するには、ワイルドカード (\$1) を使用します。
```
"Resource": "arn:aws:rds:us-east-1:123456789012:db:*"
```
リソースの作成など、一部の RDS API オペレーションは、特定のリソースで実行できません。このような場合は、ワイルドカード (\$1) を使用します。
```
"Resource": "*"
```
Amazon RDS API オペレーションの多くが複数のリソースと関連します。例えば、`CreateDBInstance` では、DB インスタンスが作成されます。DB インスタンス作成時に特定のセキュリティグループおよびパラメータグループを使用するように ユーザーに義務付けることができます。複数リソースを単一ステートメントで指定するには、ARN をカンマで区切ります。
```
"Resource": [
"resource1",
"resource2"
```
Aurora のリソースタイプおよび ARN のリストについては、「*サービス認可リファレンス*」の「[Amazon RDS で定義されるリソース](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-resources-for-iam-policies)」を参照してください。どのアクションで各リソースの ARN を指定できるかについては、「[Amazon RDS で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions)」を参照してください。
## Aurora のポリシー条件キー
**サービス固有のポリシー条件キーのサポート:** あり。
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどんな**リソース**にどんな**条件**で**アクション**を実行できるかということです。
`Condition` 要素は、定義された基準に基づいてステートメントが実行される時期を指定します。イコールや未満などの[条件演算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)を使用して条件式を作成して、ポリシーの条件とリクエスト内の値を一致させることができます。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)を参照してください。
Aurora は独自の条件キーを定義し、一部のグローバル条件キーの使用をサポートしています。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の「[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
すべての RDS API オペレーションは、`aws:RequestedRegion` 条件キーをサポートします。
Aurora の条件キーのリストについては、「*サービス認可リファレンス*」の「[Amazon RDS の条件キー](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-policy-keys)」を参照してください。どのアクションおよびリソースと条件キーを使用できるかについては、「[Amazon RDS で定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions)」を参照してください。
## Aurora のアクセスコントロールリスト (ACL)
**アクセスコントロールリスト (ACL) をサポート:** なし。
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
## Aurora タグを使ったポリシーにおける属性ベースのアクセスコントロール (ABAC)
**ポリシーにおける属性ベースのアクセスコントロール (ABAC) タグをサポート:** あり。
属性ベースのアクセス制御 (ABAC) は、タグと呼ばれる属性に基づいてアクセス許可を定義する認可戦略です。IAM エンティティと AWS リソースにタグを付けることで、プリンシパルのタグがリソースタグと一致するときに操作を許可する ABAC ポリシーを設計できます。
タグに基づいてアクセスを管理するには、`aws:ResourceTag/key-name`、`aws:RequestTag/key-name`、または `aws:TagKeys` の条件キーを使用して、ポリシーの[条件要素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)でタグ情報を提供します。
サービスがすべてのリソースタイプに対して 3 つの条件キーすべてをサポートする場合、そのサービスの値は**あり**です。サービスが一部のリソースタイプに対してのみ 3 つの条件キーのすべてをサポートする場合、値は「**部分的**」になります。
ABAC の詳細については、「*IAM ユーザーガイド*」の「[ABAC 認可でアクセス許可を定義する](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」を参照してください。ABAC をセットアップする手順を説明するチュートリアルについては、「*IAM ユーザーガイド*」の「[属性ベースのアクセスコントロール (ABAC) を使用する](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)」を参照してください。
Aurora リソースのタグ付けの詳細については、「[条件の指定: カスタムタグの使用](UsingWithRDS.IAM.SpecifyingCustomTags.md)」を参照してください。リソースのタグに基づいてリソースへのアクセスを制限するためのアイデンティティベースのポリシーの例を表示するには、「[2 つの異なる値を持つタグが付いたリソースに対するアクションにアクセス許可を付与する](security_iam_id-based-policy-examples-create-and-modify-examples.md#security_iam_id-based-policy-examples-grant-permissions-tags)」を参照してください。
## Aurora での一時的な認証情報の使用
**一時的な認証情報のサポート:** あり。
一時的な認証情報は、AWSリソースへの短期的なアクセスを提供し、フェデレーションの使用時またはロールの切り替え時に自動的に作成されます。AWS では、長期的なアクセスキーを使用する代わりに、一時的な認証情報を動的に生成することをお勧めします。詳細については、「*IAM ユーザーガイド*」の「[IAM の一時的な認証情報](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)」および「[AWS のサービス と IAM との連携](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
## Aurora のフォワードアクセスセッション
**転送アクセスセッションをサポート:** あり。
転送アクセスセッション (FAS) は、AWS のサービス を呼び出すプリンシパルのアクセス許可を AWS のサービス のリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
## Aurora のサービスロール
**サービスロールのサポート:** あり。
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [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)を参照してください。
**警告**
サービスロールの許可を変更すると、Aurora のサービスロール の機能が破損する可能性があります。Aurora が指示する場合以外は、サービスロールを編集しないでください。
## Aurora のサービスリンクロール
**サービスリンクロールのサポート:** あり。
サービスにリンクされたロールは、AWS のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
Aurora サービスにリンクされたロールの使用の詳細については、「[Amazon Aurora のサービスにリンクされたロールの使用](UsingWithRDS.IAM.ServiceLinkedRoles.md)」を参照してください。
# Amazon Aurora のアイデンティティベースのポリシーの例
デフォルトでは、アクセス許可セットとロールには、Aurora リソースを作成または変更するアクセス許可はありません。AWS マネジメントコンソール、AWS CLI、または AWS API を使用してタスクを実行することもできません。管理者は、指定されたリソースに対して特定の API オペレーションを実行するために必要なアクセス許可をアクセス許可セットとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者は、それらのアクセス許可を必要とするアクセス許可セットまたはロールに、そのポリシーをアタッチします。
これらの JSON ポリシードキュメント例を使用して IAM のアイデンティティベースのポリシーを作成する方法については、『*IAM ユーザーガイド*』の「[JSON タブでのポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor)」を参照してください。
**Topics**
+ [ポリシーのベストプラクティス](#security_iam_service-with-iam-policy-best-practices)
+ [Aurora コンソールの使用](#security_iam_id-based-policy-examples-console)
+ [コンソールの使用に必要なアクセス許可](#UsingWithRDS.IAM.RequiredPermissions.Console)
+ [自分の権限の表示をユーザーに許可する](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Aurora でリソースを作成、変更、削除するアクセス許可ポリシー](security_iam_id-based-policy-examples-create-and-modify-examples.md)
+ [ポリシー例: 条件キーの使用](UsingWithRDS.IAM.Conditions.Examples.md)
+ [条件の指定: カスタムタグの使用](UsingWithRDS.IAM.SpecifyingCustomTags.md)
+ [Aurora リソースの作成時にタグ付けするアクセス許可の付与](security_iam_id-based-policy-examples-grant-permissions-tags-on-create.md)
## ポリシーのベストプラクティス
ID ベースのポリシーは、ユーザーのアカウント内で誰かが Amazon RDS リソースを作成、アクセス、または削除できるどうかを決定します。これらのアクションでは、AWS アカウント に費用が発生する場合があります。アイデンティティベースポリシーを作成したり編集したりする際には、以下のガイドラインと推奨事項に従ってください:
+ **AWS マネージドポリシーの使用を開始し、最小特権のアクセス許可に移行する** – ユーザーとワークロードへのアクセス許可の付与を開始するには、多くの一般的なユースケースのためにアクセス許可を付与する *AWS マネージドポリシー*を使用します。これらは AWS アカウントで使用できます。ユースケースに固有の AWS カスタマー管理ポリシーを定義して、アクセス許可を絞り込むことをお勧めします。詳細については、*IAM ユーザーガイド* の [AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) または [ジョブ機能の AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) を参照してください。
+ **最小特権を適用する** – IAM ポリシーでアクセス許可を設定する場合は、タスクの実行に必要な許可のみを付与します。これを行うには、特定の条件下で特定のリソースに対して実行できるアクションを定義します。これは、*最小特権アクセス許可*とも呼ばれています。IAM を使用して許可を適用する方法の詳細については、*IAM ユーザーガイド* の [IAM でのポリシーとアクセス許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) を参照してください。
+ **IAM ポリシーで条件を使用してアクセスをさらに制限する** - ポリシーに条件を追加して、アクションやリソースへのアクセスを制限できます。たとえば、ポリシー条件を記述して、すべてのリクエストを SSL を使用して送信するように指定できます。また、CloudFormation などの特定の AWS のサービス を介して使用する場合、条件を使用してサービスアクションへのアクセスを許可することもできます。詳細については、*IAM ユーザーガイド* の [IAM JSON ポリシー要素:条件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) を参照してください。
+ **IAM アクセスアナライザー を使用して IAM ポリシーを検証し、安全で機能的な権限を確保する** - IAM アクセスアナライザー は、新規および既存のポリシーを検証して、ポリシーが IAM ポリシー言語 (JSON) および IAM のベストプラクティスに準拠するようにします。IAM アクセスアナライザーは 100 を超えるポリシーチェックと実用的な推奨事項を提供し、安全で機能的なポリシーの作成をサポートします。詳細については、*IAM ユーザーガイド* の [IAM Access Analyzer でポリシーを検証する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) を参照してください。
+ **多要素認証 (MFA) を要求する** – AWS アカウントで IAM ユーザーまたはルートユーザーを要求するシナリオがある場合は、セキュリティを強化するために MFA をオンにします。API オペレーションが呼び出されるときに MFA を必須にするには、ポリシーに MFA 条件を追加します。詳細については、*IAM ユーザーガイド* の [MFA を使用した安全な API アクセス](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) を参照してください。
IAM でのベストプラクティスの詳細については、*IAM ユーザーガイド* の [IAM でのセキュリティのベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) を参照してください。
## Aurora コンソールの使用
Amazon Aurora コンソールにアクセスするには、一連の最小限のアクセス許可が必要です。これらのアクセス許可により、AWS アカウント の Amazon Aurora リソースの詳細をリストおよび表示できるようにする必要があります。最小限必要なアクセス許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) ではコンソールが意図したとおりに機能しません。
AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソール権限を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。
これらのエンティティが Aurora コンソールを引き続き使用できるように、エンティティに次の AWS 管理ポリシーもアタッチします。
```
AmazonRDSReadOnlyAccess
```
詳細については、*IAM ユーザーガイド* の「[ユーザーへのアクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。
## コンソールの使用に必要なアクセス許可
コンソールを使用するユーザーには、最小限のアクセス許可のセットが必要です。これらのアクセス許可により、ユーザーは AWS アカウントの Amazon Aurora リソースを記述し、Amazon EC2 セキュリティやネットワーク情報など、その他の関連情報を提供できます。
これらの最小限必要なアクセス権限よりも制限された IAM ポリシーを作成している場合、その IAM ポリシーを使用するユーザーに対してコンソールは意図したとおりには機能しません。「`AmazonRDSReadOnlyAccess`」で説明されているとおり、ユーザーがコンソールを使用できること、および [ポリシーを使用したアクセスの管理](UsingWithRDS.IAM.md#security_iam_access-manage) 管理ポリシーがユーザーにアタッチされていることを確認してください。
AWS CLI または Amazon RDS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。
以下のポリシーでは、ルート AWS アカウントの Amazon Aurora リソースへのフルアクセスが付与されます。
```
AmazonRDSFullAccess
```
## 自分の権限の表示をユーザーに許可する
この例では、ユーザーアイデンティティにアタッチされたインラインおよびマネージドポリシーの表示を IAM ユーザーに許可するポリシーの作成方法を示します。このポリシーには、コンソールで、または AWS CLI か AWS API を使用してプログラム的に、このアクションを完了するアクセス許可が含まれています。
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Aurora でリソースを作成、変更、削除するアクセス許可ポリシー
以下のセクションでは、リソースへのアクセスを許可および制限するアクセス許可ポリシーの例を示します。
## AWS アカウントでの DB インスタンスの作成をユーザーに許可する
以下は、`123456789012` アカウントで ID が AWS のアカウントが DB インスタンスを作成できるようにするポリシーの例です。ポリシーは、`test` で始める新しい DB インスタンスの名前である必要があります。また、新しい DB インスタンスは、MySQL データベースエンジンと DB インスタンスの `db.t2.micro` クラスを使用する必要があります。さらに、新しい DB インスタンスでは、オプショングループと `default` で始まる DB パラメータグループ、および `default` サブネットグループを使用する必要があります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCreateDBInstanceOnly",
"Effect": "Allow",
"Action": [
"rds:CreateDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:db:test*",
"arn:aws:rds:*:123456789012:og:default*",
"arn:aws:rds:*:123456789012:pg:default*",
"arn:aws:rds:*:123456789012:subgrp:default"
],
"Condition": {
"StringEquals": {
"rds:DatabaseEngine": "mysql",
"rds:DatabaseClass": "db.t2.micro"
}
}
}
]
}
```
------
ポリシーには、 ユーザー用の以下のアクセス許可を指定する単一のステートメントが含まれます。
+ ポリシーを使用すると、アカウントは [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) API オペレーションを使用して DB インスタンスを作成できます (これは [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI コマンドと AWS マネジメントコンソール にも適用されます)。
+ `Resource` 要素では、ユーザーがリソースでアクションを実行できることを指定できます。Amazon Resources Name (ARN) を使用してリソースを指定します。この ARN には、リソースが属しているサービスの名前 (`rds`)、AWS リージョン (`*` はこの例のリージョンを示します)、AWS アカウント番号 (`123456789012` はこの例のアカウント番号です)、およびリソースのタイプが含まれます。ARN の作成の詳細については、「[Amazon RDS の Amazon リソースネーム (ARN)](USER_Tagging.ARN.md)」を参照してください。
例の `Resource` 要素は、ユーザーのリソースで、以下のポリシーの制約を指定します。
+ 新しい DB インスタンスの DB インスタンス識別子は、`test` で始まる必要があります (例: `testCustomerData1`、`test-region2-data`)。
+ 新しい DB インスタンスのオプショングループは、`default` で始まる必要があります。
+ 新しい DB インスタンスの DB パラメータグループは、`default` で始まる必要があります。
+ 新しい DB インスタンスのサブネットグループは、`default` サブネットグループである必要があります。
+ `Condition` 要素は、DB エンジンが MySQL で、DB インスタンスクラスが `db.t2.micro` である必要があることを指定します。`Condition` 要素は、ポリシーが有効になる条件を指定します。`Condition` 要素を使用して、アクセス許可または制約を追加できます。条件を指定する方法については、「[Aurora のポリシー条件キー](security_iam_service-with-iam.md#UsingWithRDS.IAM.Conditions)」を参照してください。この例では、`rds:DatabaseEngine` および `rds:DatabaseClass` を条件として指定します。`rds:DatabaseEngine` の有効な条件値については、[CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) の `Engine` パラメータのリストを参照してください。`rds:DatabaseClass` の有効な条件値については、「[DB インスタンスクラスでサポートされている DB エンジン](Concepts.DBInstanceClass.SupportAurora.md)」を参照してください。
アイデンティティベースのポリシーでアクセス権限を得るプリンシパルを指定していないため、ポリシーでは `Principal` 要素を指定していません。ユーザーにポリシーをアタッチすると、そのユーザーが暗黙のプリンシパルになります。IAM ロールにアクセス権限ポリシーをアタッチすると、ロールの信頼ポリシーで識別されたプリンシパルがアクセス権限を得ることになります。
Aurora アクションのリストを確認するには、「サービス認可リファレンス」の「[Amazon RDS によって定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions)」を参照してください。**
## RDS リソースに対する Describe アクションの実行をユーザーに許可する
以下のアクセス権限ポリシーは、`Describe` で始まるすべてのアクションを実行するためのアクセス権限をユーザーに付与します。これらのアクションは、DB インスタンスなど RDS リソースに関する情報を表示します。`Resource` 要素内のワイルドカード文字 (\$1) は、アカウントによって所有されるすべての Amazon Aurora リソースに対してそれらのアクションが許可されることを示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowRDSDescribe",
"Effect": "Allow",
"Action": "rds:Describe*",
"Resource": "*"
}
]
}
```
------
## 指定した DB パラメータグループとサブネットグループを使用する DB インスタンスの作成をユーザーに許可する
以下の許可ポリシーは、`mydbpg` DB パラメータグループと `mydbsubnetgroup` DB サブネットグループを使用する必要のある DB インスタンスを作成することのみをユーザーに許可するための許可を付与します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "rds:CreateDBInstance",
"Resource": [
"arn:aws:rds:*:*:pg:mydbpg",
"arn:aws:rds:*:*:subgrp:mydbsubnetgroup"
]
}
]
}
```
------
## 2 つの異なる値を持つタグが付いたリソースに対するアクションにアクセス許可を付与する
アイデンティティベースのポリシーの条件を使用して、タグに基づいて Aurora リソースへのアクセスを制御できます。次のポリシーでは、`stage` タグが `development` または `test` に設定された DB インスタンスに対して `CreateDBSnapshot` API オペレーションを実行するためのアクセス許可が付与されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowAnySnapshotName",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:snapshot:*"
},
{
"Sid":"AllowDevTestToCreateSnapshot",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
次のポリシーでは、`stage` タグが `development` または `test` に設定された DB インスタンスに対して `ModifyDBInstance` API オペレーションを実行するためのアクセス許可が付与されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowChangingParameterOptionSecurityGroups",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:pg:*",
"arn:aws:rds:*:123456789012:secgrp:*",
"arn:aws:rds:*:123456789012:og:*"
]
},
{
"Sid":"AllowDevTestToModifyInstance",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
## ユーザーによる DB インスタンスの削除を禁止する
以下のアクセス権限ポリシーは、特定の DB インスタンスを削除することをユーザーに禁止するためのアクセス権限を付与します。例えば、管理者以外のすべてのユーザーに対して、本稼働 DB インスタンスの削除を拒否することができます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyDelete1",
"Effect": "Deny",
"Action": "rds:DeleteDBInstance",
"Resource": "arn:aws:rds:us-west-2:123456789012:db:my-mysql-instance"
}
]
}
```
------
## リソースへのすべてのアクセスを拒否する
リソースへのアクセスを明示的に拒否できます。拒否ポリシーは許可ポリシーよりも優先されます。以下のポリシーは、リソースを管理する機能をユーザーに明示的に拒否します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "rds:*",
"Resource": "arn:aws:rds:us-east-1:123456789012:db:mydb"
}
]
}
```
------
# ポリシー例: 条件キーの使用
以下に示しているのは、Amazon Aurora IAM アクセス許可ポリシーでの条件キーの使用例です。
## 例 1: 特定の DB エンジンを使用し、マルチ AZ ではない DB インスタンスを作成するためのアクセス許可を付与する
以下のポリシーでは、RDS 条件キーを使用して、MySQL データベースエンジンを使用するがマルチ AZ でない DB インスタンスのみをユーザーが作成できるようにします。`Condition` 要素では、データベースエンジンが MySQL であることが要件になることを示しています。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowMySQLCreate",
"Effect": "Allow",
"Action": "rds:CreateDBInstance",
"Resource": "*",
"Condition": {
"StringEquals": {
"rds:DatabaseEngine": "mysql"
},
"Bool": {
"rds:MultiAz": false
}
}
}
]
}
```
------
## 例 2: 特定の DB インスタンスクラスの DB インスタンスを作成するためのアクセス許可と、プロビジョンド IOPS を使用する DB インスタンスを作成するためのアクセス許可を明示的に拒否する
以下のポリシーでは、最もサイズが大きくてコストの高いインスタンスである DB インスタンスクラス `r3.8xlarge` と `m4.10xlarge` を使用する DB インスタンスの作成のためのアクセス許可を明示的に拒否しています。このポリシーでは、追加のコストが発生するプロビジョンド IOPS を使用する DB インスタンスの作成もユーザーに禁止しています。
明示的に拒否するアクセス権限は、付与する他のいずれのアクセス権限よりも優先されます。これにより、決して付与されることのないアクセス権限を ID が誤って取得することがなくなります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyLargeCreate",
"Effect": "Deny",
"Action": "rds:CreateDBInstance",
"Resource": "*",
"Condition": {
"StringEquals": {
"rds:DatabaseClass": [
"db.r3.8xlarge",
"db.m4.10xlarge"
]
}
}
},
{
"Sid": "DenyPIOPSCreate",
"Effect": "Deny",
"Action": "rds:CreateDBInstance",
"Resource": "*",
"Condition": {
"NumericNotEquals": {
"rds:Piops": "0"
}
}
}
]
}
```
------
## 例 3: リソースにタグを付けるために使用できるタグキーと値のセットを制限する
次のポリシーは、RDS 条件キーを使用し、キー `stage` を持つタグの追加を値 `test`、`qa`、および `production` を持つリソースに追加することができます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowTagEdits",
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource": "arn:aws:rds:us-east-1:123456789012:db:db-123456",
"Condition": {
"StringEquals": {
"rds:req-tag/stage": [
"test",
"qa",
"production"
]
}
}
}
]
}
```
------
# 条件の指定: カスタムタグの使用
Amazon Aurora では、カスタムタグを使用して IAM ポリシーで条件を指定することがサポートされています。
例えば、`environment` という名前のタグを、`beta`、`staging`、`production` などの値で DB インスタンスに追加するとします。追加する場合、特定のユーザーを `environment` タグ値に基づく DB インスタンスに制限するポリシーを作成することができます。
**注記**
カスタムタグ識別子は大文字と小文字が区別されます。
以下の表では、`Condition` 要素で使用できる RDS タグ識別子を示しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAM.SpecifyingCustomTags.html)
カスタムタグの条件の構文は次のとおりです。
`"Condition":{"StringEquals":{"rds:rds-tag-identifier/tag-name": ["value"]} }`
例えば、次の `Condition` 要素は、`environment` という名前のタグを持ち、タグの値が `production` である DB インスタンスに適用されます。
` "Condition":{"StringEquals":{"rds:db-tag/environment": ["production"]} } `
タグの作成の詳細については、「[Amazon Aurora および Amazon RDS リソースのタグ付け](USER_Tagging.md)」を参照してください。
**重要**
タグを使用して RDS リソースへのアクセスを管理する場合は、RDS リソースのタグへのアクセスを保護することをお勧めします。`AddTagsToResource` および `RemoveTagsFromResource` アクションのポリシーを作成することによって、タグへのアクセスを管理できます。例えば、次のポリシーは、ユーザーがすべてのリソースのタグを追加または削除することを拒否します。次に、特定のユーザーがタグを追加または削除することを許可するポリシーを作成できます。
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyTagUpdates",
"Effect":"Deny",
"Action":[
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource":"*"
}
]
}
```
Aurora アクションのリストを確認するには、「サービス認可リファレンス」の「[Amazon RDS によって定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions)」を参照してください。**
## ポリシー例: カスタムタグの使用
以下に示しているのは、Amazon Aurora IAM アクセス許可ポリシーでのカスタムタグの使用例です。Amazon Aurora リソースへのタグの追加の詳細については、「[Amazon RDS の Amazon リソースネーム (ARN)](USER_Tagging.ARN.md)」を参照してください。
**注記**
すべての例で、us-west-2 リージョンを使用し、架空のアカウント ID を含めています。
### 例 1: 2 つの異なる値を持つタグが付いたリソースに対するアクションにアクセス許可を付与する
次のポリシーでは、`stage` タグが `development` または `test` に設定された DB インスタンスに対して `CreateDBSnapshot` API オペレーションを実行するためのアクセス許可が付与されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowAnySnapshotName",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:snapshot:*"
},
{
"Sid":"AllowDevTestToCreateSnapshot",
"Effect":"Allow",
"Action":[
"rds:CreateDBSnapshot"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
次のポリシーでは、`stage` タグが `development` または `test` に設定された DB インスタンスに対して `ModifyDBInstance` API オペレーションを実行するためのアクセス許可が付与されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowChangingParameterOptionSecurityGroups",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource": [
"arn:aws:rds:*:123456789012:pg:*",
"arn:aws:rds:*:123456789012:secgrp:*",
"arn:aws:rds:*:123456789012:og:*"
]
},
{
"Sid":"AllowDevTestToModifyInstance",
"Effect":"Allow",
"Action":[
"rds:ModifyDBInstance"
],
"Resource":"arn:aws:rds:*:123456789012:db:*",
"Condition":{
"StringEquals":{
"rds:db-tag/stage":[
"development",
"test"
]
}
}
}
]
}
```
------
### 例 2: 指定した DB パラメータグループを使用する DB インスタンスを作成するためのアクセス許可を明示的に拒否する
以下のポリシーでは、特定のタグ値が設定された DB パラメータグループを使用する DB インスタンスの作成のためのアクセス権限を明示的に拒否しています。DB インスタンスを作成するときに特定のユーザー定義の DB パラメータグループの使用を必須とする場合にも、このポリシーを適用できます。`Deny` を使用するポリシーは、ほとんどの場合、適用範囲のより広いポリシーによって付与されるアクセス許可を制限するために使用します。
明示的に拒否するアクセス権限は、付与する他のいずれのアクセス権限よりも優先されます。これにより、決して付与されることのないアクセス権限を ID が誤って取得することがなくなります。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyProductionCreate",
"Effect":"Deny",
"Action":"rds:CreateDBInstance",
"Resource":"arn:aws:rds:*:123456789012:pg:*",
"Condition":{
"StringEquals":{
"rds:pg-tag/usage":"prod"
}
}
}
]
}
```
------
### 例 3: インスタンス名にユーザー名がプレフィックスとして付加されている DB インスタンスに対するアクションにアクセス許可を付与する
以下のポリシーでは、DB インスタンス名の前にユーザー名が付いている DB インスタンスのうち、`AddTagsToResource` と同等の `RemoveTagsFromResource` というタグが付いているか、または `stage` というタグが付いていない DB インスタンスに対する、API (`devo` または `stage` を除く) の呼び出しのためのアクセス権限を付与しています。
ポリシーの `Resource` 行では、リソースをその Amazon Resource Name (ARN) により識別しています。ARN と Amazon Aurora リソースの使用の詳細については、「[Amazon RDS の Amazon リソースネーム (ARN)](USER_Tagging.ARN.md)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AllowFullDevAccessNoTags",
"Effect":"Allow",
"NotAction":[
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource":"arn:aws:rds:*:123456789012:db:${aws:username}*",
"Condition":{
"StringEqualsIfExists":{
"rds:db-tag/stage":"devo"
}
}
}
]
}
```
------
# Aurora リソースの作成時にタグ付けするアクセス許可の付与
一部の RDS API オペレーションでは、リソースの作成時にタグを指定できます。リソースタグを使用して、属性ベースの制御 (ABAC) を実装できます。詳細については、「[AWS のABAC とは](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」および「[タグを使用した AWS リソースへのアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)」を参照してください。
ユーザーがリソースの作成時にタグを付けるには、リソースを作成するアクション (`rds:CreateDBCluster` など) を使用するためのアクセス許可が必要です。作成アクションでタグが指定されている場合、RDS は `rds:AddTagsToResource` アクションに対して追加の認可を実行して、ユーザーがタグを作成する認可を持っているかどうかを確認します。そのため、ユーザーには`rds:AddTagsToResource` アクションを使用する明示的なアクセス権限が必要です。
`rds:AddTagsToResource` アクションの IAM ポリシー定義では、`aws:RequestTag` 条件キーを使用して、リソースにタグを付けるリクエストでタグを要求できます。
例えば、次のポリシーでは、特定のタグキー (`environment` または `project`) でのみ、ユーザーが DB インスタンスを作成し、DB インスタンスの作成中にタグを適用することが許可されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:CreateDBInstance"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:RequestTag/environment": ["production", "development"],
"aws:RequestTag/project": ["dataanalytics", "webapp"]
},
"ForAllValues:StringEquals": {
"aws:TagKeys": ["environment", "project"]
}
}
}
]
}
```
------
このポリシーは、`environment` または `project` タグ以外のタグを含む DB インスタンスの作成リクエスト、またはこれらのタグのいずれかを指定しない DB インスタンスの作成リクエストを拒否します。さらに、ユーザーはポリシーで許可されている値と一致するタグの値を指定する必要があります。
次のポリシーでは、ユーザーが DB クラスターを作成し、作成時に `environment=prod` タグ以外のタグを適用することを許可します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:CreateDBCluster"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"rds:AddTagsToResource"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestTag/environment": "prod"
}
}
}
]
}
```
------
## 作成時のタグ付けでサポートされている RDS API アクション
次の RDS API アクションでは、リソース作成時のタグの指定がサポートされます。これらのアクションでは、リソースの作成時にタグを指定できます。
+ `CreateBlueGreenDeployment`
+ `CreateCustomDBEngineVersion`
+ `CreateDBCluster`
+ `CreateDBClusterEndpoint`
+ `CreateDBClusterParameterGroup`
+ `CreateDBClusterSnapshot`
+ `CreateDBInstance`
+ `CreateDBInstanceReadReplica`
+ `CreateDBParameterGroup`
+ `CreateDBProxy`
+ `CreateDBProxyEndpoint`
+ `CreateDBSecurityGroup`
+ `CreateDBShardGroup`
+ `CreateDBSnapshot`
+ `CreateDBSubnetGroup`
+ `CreateEventSubscription`
+ `CreateGlobalCluster`
+ `CreateIntegration`
+ `CreateOptionGroup`
+ `CreateTenantDatabase`
+ `CopyDBClusterParameterGroup`
+ `CopyDBClusterSnapshot`
+ `CopyDBParameterGroup`
+ `CopyDBSnapshot`
+ `CopyOptionGroup`
+ `RestoreDBClusterFromS3`
+ `RestoreDBClusterFromSnapshot`
+ `RestoreDBClusterToPointInTime`
+ `RestoreDBInstanceFromDBSnapshot`
+ `RestoreDBInstanceFromS3`
+ `RestoreDBInstanceToPointInTime`
+ `PurchaseReservedDBInstancesOffering`
AWS CLI または API を使用してタグ付きのリソースを作成する場合、`Tags` パラメータを使用して作成時にリソースにタグを適用します。
これらの API アクションでは、タグ付けが失敗した場合、リソースは作成されず、リクエストはエラーで失敗します。これにより、リソースがタグ付きで作成されるか、まったく作成されないため、意図したタグのないリソースは作成されません。
# AWSAmazon RDS の マネージドポリシー
アクセス許可セットとロールにアクセス許可を追加するには、自分でポリシーを作成するよりも、AWS マネージドポリシーを使用する方が簡単です。チームに必要な権限のみを提供する [IAM カスタマーマネージドポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)には時間と専門知識が必要です。すぐに使用を開始するために、AWS マネージドポリシーを使用できます。これらのポリシーは、一般的なユースケースをターゲット範囲に含めており、AWS アカウント で利用できます。AWS マネージドポリシーの詳細については、「*IAM ユーザーガイド*」の「[AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)」を参照してください。
AWS のサービス は、AWS マネージドポリシーを維持し、更新します。AWS マネージドポリシーの権限を変更することはできません。サービスでは新しい機能を利用できるようにするために、AWS マネージドポリシーに権限が追加されることがあります。この種類の更新は、ポリシーがアタッチされている、すべてのアイデンティティ (アクセス許可セットとロール) に影響を与えます。新しい機能が立ち上げられた場合や、新しいオペレーションが使用可能になった場合に、各サービスが AWS マネージドポリシーを更新する可能性が最も高くなります。サービスは、AWS マネージドポリシーから許可を削除しないため、ポリシーの更新によって既存の許可が破棄されることはありません。
さらに、AWS は複数のサービスにまたがるジョブ機能の特徴に対するマネージドポリシーもサポートしています。例えば、`ReadOnlyAccess` AWS マネージドポリシーでは、すべての AWS のサービス およびリソースへの読み取り専用アクセスを許可します。あるサービスで新しい機能を立ち上げる場合は、AWS は、追加された演算とリソースに対し、読み込み専用の許可を追加します。職務機能ポリシーのリストと説明については、*IAM ユーザーガイド*の「[ジョブ機能の AWS マネージドポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)」を参照してください。
**Topics**
+ [AWS マネージドポリシー: AmazonRDSReadOnlyAccess](#rds-security-iam-awsmanpol-AmazonRDSReadOnlyAccess)
+ [AWS マネージドポリシー: AmazonRDSFullAccess](#rds-security-iam-awsmanpol-AmazonRDSFullAccess)
+ [AWS マネージドポリシー: AmazonRDSDataFullAccess](#rds-security-iam-awsmanpol-AmazonRDSDataFullAccess)
+ [AWS マネージドポリシー: AmazonRDSEnhancedMonitoringRole](#rds-security-iam-awsmanpol-AmazonRDSEnhancedMonitoringRole)
+ [AWS マネージドポリシー: AmazonRDSPerformanceInsightsReadOnly](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly)
+ [AWS 管理ポリシー: AmazonRDSPerformanceInsightsFullAccess](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess)
+ [AWS マネージドポリシー: AmazonRDSDirectoryServiceAccess](#rds-security-iam-awsmanpol-AmazonRDSDirectoryServiceAccess)
+ [AWS マネージドポリシー: AmazonRDSServiceRolePolicy](#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy)
+ [AWS マネージドポリシー: AmazonRDSPreviewServiceRolePolicy](#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy)
+ [AWS マネージドポリシー: AmazonRDSBetaServiceRolePolicy](#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy)
## AWS マネージドポリシー: AmazonRDSReadOnlyAccess
このポリシーは、AWS マネジメントコンソール を通じた Amazon RDS への読み取り専用アクセスを許可します。
**許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `rds` — プリンシパルが Amazon RDS リソースを記述し、Amazon RDS リソースのタグを一覧表示することを許可します。
+ `cloudwatch` — プリンシパルが Amazon CloudWatch メトリクスの統計情報を取得することを許可します。
+ `ec2` — プリンシパルがアベイラビリティーゾーンとネットワークリソースを記述することを許可します。
+ `logs` — プリンシパルがロググループの CloudWatch Logs ログストリームを記述し、CloudWatch Logs ログイベントを取得することを許可します。
+ `devops-guru` - プリンシパルが Amazon DevOps Guru の対象となるリソースを記述できるようにします。リソースは、CloudFormation スタック名またはリソースタグで指定されます。
JSON ポリシードキュメントを含むこのポリシーの詳細については、*AWS マネージドポリシーリファレンスガイド*の「[AmazonRDSReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSReadOnlyAccess.html)」を参照してください。
## AWS マネージドポリシー: AmazonRDSFullAccess
このポリシーは、AWS マネジメントコンソール を通じて Amazon RDS へのフルアクセスを提供します。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `rds` - プリンシパルに Amazon RDS へのフルアクセスを許可します。
+ `application-autoscaling` — プリンシパルがアプリケーションオートスケーリングのターゲットとポリシーを記述し、管理することを許可します。
+ `cloudwatch` — プリンシパルが CloudWatch メトリクスの統計を取得し、CloudWatch アラームを管理することを許可します。
+ `ec2` — プリンシパルがアベイラビリティーゾーンとネットワークリソースを記述することを許可します。
+ `logs` — プリンシパルがロググループの CloudWatch Logs ログストリームを記述し、CloudWatch Logs ログイベントを取得することを許可します。
+ `outposts` — プリンシパルが AWS Outposts インスタンスタイプを取得することを許可します。
+ `pi` — プリンシパルが Performance Insights メトリクスを取得することを許可します。
+ `sns` — プリンシパルが Amazon Simple Notification Service (Amazon SNS) のサブスクリプションとトピックにアクセスして、Amazon SNS メッセージを発行することを許可します。
+ `devops-guru` - プリンシパルが Amazon DevOps Guru の対象となるリソースを記述できるようにします。リソースは、CloudFormation スタック名またはリソースタグで指定されます。
JSON ポリシードキュメントを含むこのポリシーの詳細については、*AWS マネージドポリシーリファレンスガイド*の「[AmazonRDSFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSFullAccess.html)」を参照してください。
## AWS マネージドポリシー: AmazonRDSDataFullAccess
このポリシーは、特定の AWS アカウント 内の Aurora Serverless クラスターに対して Data API とクエリエディタを使用するためのフルアクセスを許可します。このポリシーは、AWS アカウント が AWS Secrets Manager からシークレットの値を取得することを許可します。
`AmazonRDSDataFullAccess` ポリシーを IAM IDにアタッチできます。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `dbqms` — プリンシパルにクエリへのアクセス、作成、削除、記述、および更新を許可します。データベースクエリメタデータサービス (`dbqms`) は、内部専用のサービスです。このサービスでは、Amazon RDS を含む複数の AWS のサービス について、最新および保存済みのクエリを、AWS マネジメントコンソール のクエリエディタ用に提供します。
+ `rds-data` — プリンシパルが Aurora Serverless データベースに対して SQL ステートメントを実行するのを許可します。
+ `secretsmanager` — プリンシパルが からシークレットの値を取得するのを許可します。AWS Secrets Manager
JSON ポリシードキュメントを含むこのポリシーの詳細については、*AWS マネージドポリシーリファレンスガイド*の「[AmazonRDSDataFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDataFullAccess.html)」を参照してください。
## AWS マネージドポリシー: AmazonRDSEnhancedMonitoringRole
このポリシーは、Amazon RDS 拡張モニタリング用の Amazon CloudWatch Logs へのアクセスを提供します。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `logs` — プリンシパルが CloudWatch Logs ロググループと保持ポリシーを作成し、ロググループの CloudWatch Logs ログストリームを作成および記述することを許可します。また、プリンシパルが CloudWatch Logs ログイベントを設定および取得することも許可します。
JSON ポリシードキュメントを含むこのポリシーの詳細については、*AWS マネージドポリシーリファレンスガイド*の「[AmazonRDSEnhancedMonitoringRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSEnhancedMonitoringRole.html)」を参照してください。
## AWS マネージドポリシー: AmazonRDSPerformanceInsightsReadOnly
このポリシーは、Amazon RDS DB インスタンスと Amazon Aurora DB クラスター用の Amazon RDS Performance Insights への読み取り専用アクセスを提供します。
このポリシーには、ポリシードキュメントの識別子として `Sid` (ステートメント ID) が含まれるようになりました。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `rds` — プリンシパルが Amazon RDS DB インスタンスと Amazon Aurora DB クラスターを記述することを許可します。
+ `pi` — プリンシパルが Amazon RDS Performance Insights API を呼び出し、Performance Insights メトリクスにアクセスすることを許可します。
JSON ポリシードキュメントを含むこのポリシーの詳細については、*AWS マネージドポリシーリファレンスガイド*の「[AmazonRDSPerformanceInsightsReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsReadOnly.html)」を参照してください。
## AWS 管理ポリシー: AmazonRDSPerformanceInsightsFullAccess
このポリシーは、Amazon RDS DB インスタンスと Amazon Aurora DB クラスター用の Amazon RDS Performance Insights へのフルアクセスを提供します。
このポリシーには、ポリシードキュメントの識別子として `Sid` (ステートメント ID) が含まれるようになりました。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `rds` — プリンシパルが Amazon RDS DB インスタンスと Amazon Aurora DB クラスターを記述することを許可します。
+ `pi` — プリンシパルが Amazon RDS Performance Insights API を呼び出したり、パフォーマンス分析レポートを作成、表示、削除したりすることを許可します。
+ `cloudwatch` — プリンシパルが Amazon CloudWatch メトリクスを一覧表示し、メトリクスデータと統計を取得するのを許可します。
JSON ポリシードキュメントを含め、このポリシーの詳細については、「*AWS マネージドポリシーリファレンスガイド*」の「[AmazonRDSPerformanceInsightsFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsFullAccess.html)」を参照してください。
## AWS マネージドポリシー: AmazonRDSDirectoryServiceAccess
このポリシーは、Amazon RDS が Directory Service を呼び出すことを許可します。
**アクセス許可の詳細**
このポリシーには、以下の許可が含まれています。
+ `ds` — プリンシパルが Directory Service ディレクトリを記述し、Directory Service ディレクトリへの認可を制御することを許可します。
JSON ポリシードキュメントを含むこのポリシーの詳細については、*AWS マネージドポリシーリファレンスガイド*の「[AmazonRDSDirectoryServiceAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDirectoryServiceAccess.html)」を参照してください。
## AWS マネージドポリシー: AmazonRDSServiceRolePolicy
IAM エンティティに `AmazonRDSServiceRolePolicy` をアタッチすることはできません。このポリシーは、Amazon RDS がユーザーに代わってアクションを実行することを許可するサービスリンクロールにアタッチされます。詳細については、「[Amazon Aurora のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions)」を参照してください。
## AWS マネージドポリシー: AmazonRDSPreviewServiceRolePolicy
IAM エンティティに `AmazonRDSPreviewServiceRolePolicy` をアタッチしないでください。このポリシーは、Amazon RDS が RDS DB リソースに代わって AWS のサービスを呼び出すことを許可するサービスにリンクされたロールに関連付けられています。詳細については、「[Amazon RDS Preview のサービスリンクロール](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdspreview)」を参照してください。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `ec2` – プリンシパルがアベイラビリティーゾーンとネットワークリソースを記述することを許可します。
+ `secretsmanager` — プリンシパルが からシークレットの値を取得するのを許可します。AWS Secrets Manager
+ `cloudwatch`、`logs` – Amazon RDS が CloudWatch エージェントを介して DB インスタンスのメトリクスとログを CloudWatch にアップロードできるようにします。
このポリシーの詳細 (JSON ポリシードキュメントを含む) については、「*AWS Managed Policy Reference Guide*」の「[AmazonRDSPreviewServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPreviewServiceRolePolicy.html)」を参照してください。
## AWS マネージドポリシー: AmazonRDSBetaServiceRolePolicy
IAM エンティティに `AmazonRDSBetaServiceRolePolicy` をアタッチしないでください。このポリシーは、Amazon RDS が RDS DB リソースに代わって AWS のサービスを呼び出すことを許可するサービスにリンクされたロールに関連付けられています。詳細については、「[Amazon RDS Beta のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdsbeta)」を参照してください。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `ec2` – Amazon RDS が、ポイントインタイム復元機能を提供する DB インスタンスでバックアップ操作を実行することを許可します。
+ `secretsmanager` – Amazon RDS が Amazon RDS によって作成された DB インスタンス固有のシークレットを管理できるようにします。
+ `cloudwatch`、`logs` – Amazon RDS が CloudWatch エージェントを介して DB インスタンスのメトリクスとログを CloudWatch にアップロードできるようにします。
JSON ポリシードキュメントを含むこのポリシーの詳細については、「AWS マネージドポリシーリファレンスガイド」の「[AmazonRDSBetaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSBetaServiceRolePolicy.html)」を参照してください。**
# Amazon RDS の AWS 管理ポリシーに関する更新
Amazon RDS の AWS マネージドポリシーに対する更新の詳細について、このサービスがこれらの変更の追跡を開始した以降のものを示します。このページへの変更に関する自動アラートを受け取るには、Amazon RDS の[ドキュメント履歴](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/WhatsNew.html)ページで RSS フィードにサブスクライブしてください。
| 変更 | 説明 | 日付 |
| --- | --- | --- |
| [AWS マネージドポリシー: AmazonRDSPreviewServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy) – 既存のポリシーの更新 | Amazon RDS は、`AWSServiceRoleForRDSPreview` サービスにリンクされたロールの `AmazonRDSPreviewServiceRolePolicy` から `sns:Publish` 許可を削除しました。詳細については、「[AWS マネージドポリシー: AmazonRDSPreviewServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy)」を参照してください。 | 2024 年 8 月 7 日 |
| [AWS マネージドポリシー: AmazonRDSBetaServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy) – 既存のポリシーの更新 | Amazon RDS は、`AWSServiceRoleForRDSBeta` サービスにリンクされたロールの `AmazonRDSBetaServiceRolePolicy` から `sns:Publish` 許可を削除しました。詳細については、「[AWS マネージドポリシー: AmazonRDSBetaServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy)」を参照してください。 | 2024 年 8 月 7 日 |
| [AWS マネージドポリシー: AmazonRDSServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy) – 既存のポリシーの更新 | Amazon RDS は、` AWSServiceRoleForRDS` サービスにリンクされたロールの `AmazonRDSServiceRolePolicy` から `sns:Publish` 許可を削除しました。詳細については、「[AWS マネージドポリシー: AmazonRDSServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy)」を参照してください。 | 2024 年 7 月 2 日 |
| [AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md) – 既存のポリシーの更新 | Amazon RDS は、`AWSServiceRoleForRDSCustom` サービスリンクロールの `AmazonRDSCustomServiceRolePolicy` に新しいアクセス許可を追加し、RDS Custom for SQL Server で基盤となるデータベースのホストインスタンスタイプを変更できるようにしました。また、RDS は、データベースホストに関するインスタンスタイプ情報を取得する `ec2:DescribeInstanceTypes` アクセス許可も追加しました。詳細については、「[AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md)」を参照してください。 | 2024 年 4 月 8 日 |
| [AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md) - 新しいポリシー | Amazon RDS は、RDS Custom が EC2 インスタンスプロファイルを介して自動化アクションとデータベース管理タスクを実行できるように AmazonRDSCustomInstanceProfileRolePolicy という名前の新しいマネージドポリシーを追加しました。詳細については、「[AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md)」を参照してください。 | 2024 年 2 月 27 日 |
| [Amazon Aurora のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`AWSServiceRoleForRDS` サービスリンクロールの `AmazonRDSServiceRolePolicy` に新しいステートメント ID を追加しました。 詳細については、「[Amazon Aurora のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions)」を参照してください。 | 2024 年 1 月 19 日 |
| [AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md) - 既存のポリシーの更新 | `AmazonRDSPerformanceInsightsReadOnly` および`AmazonRDSPerformanceInsightsFullAccess` マネージドポリシーには、`Sid` (ステートメント ID) がポリシーステートメントの識別子として含まれます。 詳細については、「[AWS マネージドポリシー: AmazonRDSPerformanceInsightsReadOnly](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly)」および「[AWS 管理ポリシー: AmazonRDSPerformanceInsightsFullAccess](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess)」を参照してください。 | 2023 年 10 月 23 日 |
| [AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md) – 既存のポリシーの更新 | Amazon ECR では、新しいアクセス許可が `AmazonRDSFullAccess` 管理ポリシーに追加されました。これらのアクセス許可により、一定期間のパフォーマンス分析レポートを生成、表示、削除できます。 Performance Insights のアクセスポリシーの設定の詳細については、「[Performance Insights 用のアクセスポリシーの設定](USER_PerfInsights.access-control.md)」を参照してください。 | 2023 年 8 月 17 日 |
| [AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md) - 新しいポリシーと、既存のポリシーの更新 | Amazon RDS では、`AmazonRDSPerformanceInsightsReadOnly` 管理ポリシーと `AmazonRDSPerformanceInsightsFullAccess` という名前の新しい管理ポリシーに新しいアクセス許可が追加されました。これらのアクセス許可により、一定期間の Performance Insights を分析したり、分析結果を推奨事項と共に表示したり、レポートを削除したりできます。 Performance Insights のアクセスポリシーの設定の詳細については、「[Performance Insights 用のアクセスポリシーの設定](USER_PerfInsights.access-control.md)」を参照してください。 | 2023 年 8 月 16 日 |
| [AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md) – 既存ポリシーへの更新 | Amazon RDS は、`AmazonRDSFullAccess` と `AmazonRDSReadOnlyAccess` に新しい Amazon CloudWatch 名前空間 `ListMetrics` を追加しました。 この名前空間は、Amazon RDS が特定のリソース使用メトリクスを一覧表示するために必要です。 詳細については、*Amazon CloudWatch ユーザーガイド*の「[CloudWatch リソースへの許可の管理の概要](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-access-control-overview-cw.html)」を参照してください。 | 2023 年 4 月 4 日 |
| [Amazon Aurora のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、AWS Secrets Manager との統合のために `AWSServiceRoleForRDS` サービスにリンクされたロールの `AmazonRDSServiceRolePolicy` に新しいアクセス許可を追加しました。RDS では、Secrets Manager でマスターユーザーのパスワードを管理するために、Secrets Manager との統合が必要です。シークレットでは予約された命名規則を使用しており、顧客からの更新を制限します。 詳細については、「[Amazon Aurora および AWS Secrets Manager によるパスワード管理](rds-secrets-manager.md)」を参照してください。 | 2022 年 12 月 22 日 |
| [AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md) - 既存のポリシーの更新 | Amazon RDS は `AmazonRDSFullAccess` および `AmazonRDSReadOnlyAccess` マネージドポリシーに新しいアクセス許可を追加して、RDS コンソールで Amazon DevOps Guru を有効にできるようにしました。このアクセス許可は、DevOps Guru が有効になっているかどうかを確認するために必要です。 詳細については、「[DevOps Guru for RDS の IAM アクセスポリシーの設定](devops-guru-for-rds.md#devops-guru-for-rds.configuring.access)」を参照してください。 | 2022 年 12 月 19 日 |
| [Amazon Aurora のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`PutMetricData` の `AmazonRDSPreviewServiceRolePolicy` に新しい Amazon CloudWatch 名前空間を追加しました。 この名前空間は、Amazon RDS がリソース使用メトリクスを公開するために必要です。 詳細については、*Amazon CloudWatch ユーザーガイド*の「[条件キーを使用した CloudWatch 名前空間へのアクセスの制限](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html)」を参照してください。 | 2022 年 6 月 7 日 |
| [Amazon Aurora のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`PutMetricData` の `AmazonRDSBetaServiceRolePolicy` に新しい Amazon CloudWatch 名前空間を追加しました。 この名前空間は、Amazon RDS がリソース使用メトリクスを公開するために必要です。 詳細については、*Amazon CloudWatch ユーザーガイド*の「[条件キーを使用した CloudWatch 名前空間へのアクセスの制限](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html)」を参照してください。 | 2022 年 6 月 7 日 |
| [Amazon Aurora のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`PutMetricData` の `AWSServiceRoleForRDS` に新しい Amazon CloudWatch 名前空間を追加しました。 この名前空間は、Amazon RDS がリソース使用メトリクスを公開するために必要です。 詳細については、*Amazon CloudWatch ユーザーガイド*の「[条件キーを使用した CloudWatch 名前空間へのアクセスの制限](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html)」を参照してください。 | 2022 年 4 月 22 日 |
| [AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md) - 新しいポリシー | Amazon RDS では、Amazon RDS が DB インスタンスに代わって `AmazonRDSPerformanceInsightsReadOnly` サービスを呼び出せるように、AWS という名前の新しい管理ポリシーが追加されました。 Performance Insights のアクセスポリシーの設定の詳細については、「[Performance Insights 用のアクセスポリシーの設定](USER_PerfInsights.access-control.md)」を参照してください。 | 2022 年 3 月 10 日 |
| [Amazon Aurora のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`PutMetricData` の `AWSServiceRoleForRDS` に新しい Amazon CloudWatch 名前空間を追加しました。 これらの名前空間は、Amazon DocumentDB (MongoDB と互換) と Amazon Neptune が CloudWatch メトリクスを公開するために必要です。 詳細については、*Amazon CloudWatch ユーザーガイド*の「[条件キーを使用した CloudWatch 名前空間へのアクセスの制限](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html)」を参照してください。 | 2022 年 3 月 4 日 |
| Amazon RDS が変更の追跡を開始しました。 | Amazon RDS が AWS マネージドポリシーの変更の追跡を開始しました。 | 2021 年 10 月 26 日 |
# サービス間での混乱した代理問題の防止
*「混乱した代理」問題*は、アクションを実行するためのアクセス許可を持たないエンティティが、より特権のあるエンティティにアクションの実行を強制できてしまう場合に生じる、セキュリティ上の問題です。AWS では、サービス間でのなりすましによって、混乱した代理問題が発生する場合があります。
サービス間でのなりすましは、1 つのサービス (*呼び出し元サービス*) が、別のサービス (*呼び出し対象サービス*) を呼び出すときに発生する可能性があります。呼び出し元サービスが操作され、それ自身のアクセス許可を使用して、本来アクセス許可が付与されるべきではない方法で別の顧客のリソースに対して働きかけることがあります。これを防ぐために AWS では、お客様のすべてのサービスのデータを保護するのに役立つツールを提供しています。これらのツールでは、アカウントのリソースへのアクセス権が付与されたサービスプリンシパルを使用します。詳細については、*IAM ユーザーガイド* の [混乱した代理問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) を参照してください。
特定のリソースへのアクセスについて、Amazon RDS が別のサービスに付与する許可を制限する場合は、リソースポリシー内で [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) および [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) のグローバル条件コンテキストキーを使用することをお勧めします。
例えば、Amazon S3 バケットの Amazon リソースネーム (ARN) を使用する場合など、`aws:SourceArn` 値にアカウント ID が含まれていないことがあります。このような場合は、前出のグローバル条件コンテキストキーの両方を使用して、パーミッションを制限する必要があります。場合によっては、両方のグローバル条件コンテキストキーと、アカウント ID を含む `aws:SourceArn` 値を併用します。これらを同じポリシーステートメントで使用する場合は、`aws:SourceAccount` の値には、`aws:SourceArn` 内のアカウントと同じアカウント ID を使用します。クロスサービスのアクセスにリソースを 1 つだけ関連付けたい場合は、`aws:SourceArn` を使用します。クロスサービスによる使用のために、AWS アカウント内の任意のリソースを関連づけたい場合は、`aws:SourceAccount` を使用します。
`aws:SourceArn` の値には、Amazon RDS リソースタイプの ARN を指定する必要があります。詳細については、「[Amazon RDS の Amazon リソースネーム (ARN)](USER_Tagging.ARN.md)」を参照してください。
混乱した代理問題から保護するための最も効果的な方法は、リソースの完全な ARN を指定して `aws:SourceArn` グローバル条件コンテキストキーを使用することです。この時、リソースの完全な ARN が分からない場合や、複数のリソースを指定しているという場合があり得ます。このような場合、ARN の未知の部分については、ワイルドカード (`*`) を指定しながら `aws:SourceArn` グローバルコンテキスト条件キーを使用します。例は `arn:aws:rds:*:123456789012:*` です。
次の例では、Amazon RDS で `aws:SourceArn` および `aws:SourceAccount` グローバル条件コンテキストキーを使用して、「混乱した代理」問題を回避する方法を示します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "ConfusedDeputyPreventionExamplePolicy",
"Effect": "Allow",
"Principal": {
"Service": "rds.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:rds:us-east-1:123456789012:db:mydbinstance"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
}
```
------
グローバル条件コンテキストキーの `aws:SourceArn` と `aws:SourceAccount` を使用する他のポリシー例については、以下の各セクションを参照してください。
+ [Amazon SNS トピックに通知を発行するアクセス許可を付与する](USER_Events.GrantingPermissions.md)
+ [Amazon S3 バケットへのアクセスを設定する](USER_PostgreSQL.S3Import.AccessPermission.md) (PostgreSQL のインポート)
+ [Amazon S3 バケットへのアクセスを設定する](postgresql-s3-export-access-bucket.md) (PostgreSQL エクスポート)
# の IAM データベース認証
AWS Identity and Access Management (IAM) データベース認証を使用して、DB クラスターを認証できます。IAM データベース認証には、Aurora MySQL、および Aurora PostgreSQL を使用します。この認証方法では、DB クラスターに接続するときにパスワードを使用する必要はありません。代わりに、認証トークンを使用します。
*認証トークン*は、 Amazon Aurora がリクエストに応じて生成する一意の文字列です。認証トークンは、AWS 署名バージョン 4 を使用して生成されます。各トークンには 15 分の有効期間があります。認証は IAM を使用して外部的に管理されるため、ユーザー認証情報をデータベースに保存する必要はありません。引き続きスタンダードのデータベース認証を使用することもできます。トークンは認証にのみ使用され、確立後のセッションには影響しません。
IAM データベース認証には次の利点があります。
+ データベースとの間で送受信されるネットワークトラフィックは、Secure Socket Layer (SSL) または Transport Layer Security (TLS) を使用して暗号化されます。Amazon Aurora で SSL/TLS を使用する方法については、「[SSL/TLS を使用した DB クラスターへの接続の暗号化](UsingWithRDS.SSL.md)」を参照してください。
+ IAM を使用して各 DB クラスターで個別に管理するのではなく、データベースリソースへのアクセスを一元的に管理できます。
+ Amazon EC2 で実行するアプリケーションの場合、セキュリティを高めるため、EC2 インスタンスに固有のプロファイル認証情報を使用して、パスワードの代わりにデータベースにアクセスできます。
一般に、アプリケーションが 1 秒あたり 200 未満の接続を作成し、アプリケーションコードでユーザー名とパスワードを直接管理したくない場合は、IAM データベース認証の使用を検討してください。
Amazon Web Services (AWS) JDBC ドライバーは IAM データベース認証をサポートしています。詳細については、「Amazon Web Services (AWS) JDBC ドライバー GitHub リポジトリ」の「[AWS IAM Authentication Plugin](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/using-the-jdbc-driver/using-plugins/UsingTheIamAuthenticationPlugin.md)」を参照してください。[https://github.com/aws/aws-advanced-jdbc-wrapper](https://github.com/aws/aws-advanced-jdbc-wrapper)
Amazon Web Services (AWS) Python ドライバーは IAM データベース認証をサポートしています。詳細については、「Amazon Web Services (AWS) Python ドライバー GitHub リポジトリ」の「[AWS IAM Authentication Plugin](https://github.com/aws/aws-advanced-python-wrapper/blob/main/docs/using-the-python-driver/using-plugins/UsingTheIamAuthenticationPlugin.md)」を参照してください。[https://github.com/aws/aws-advanced-python-wrapper](https://github.com/aws/aws-advanced-python-wrapper)
DB 認証に IAM を設定するプロセスについては、以下のトピックを参照してください。
+ [IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [IAM 認証を使用したデータベースアカウントの作成](UsingWithRDS.IAMDBAuth.DBAccounts.md)
+ [IAM 認証を使用した DB クラスターへの接続](UsingWithRDS.IAMDBAuth.Connecting.md)
## 利用可能なリージョンとバージョン
利用できる機能とそのサポートは、各 Aurora データベースエンジンの特定のバージョン、および AWS リージョン によって異なります。Aurora と IAM データベース認証を使用したバージョンとリージョンの可用性の詳細については、「[IAM データベース認証でサポートされているリージョンと Aurora DB エンジン](Concepts.Aurora_Fea_Regions_DB-eng.Feature.IAMdbauth.md)」を参照してください。
Aurora MySQL では、サポートされているすべての DB インスタンスクラスは、db.t2.small および db.t3.small を除き、IAM データベース認証をサポートします。サポートされている DB インスタンスクラスの詳細については、「[DB インスタンスクラスでサポートされている DB エンジン](Concepts.DBInstanceClass.SupportAurora.md)」を参照してください。
## CLI および SDK のサポート
IAM データベース認証は、[AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/generate-db-auth-token.html) と以下の各言語固有の AWS SDK について使用できます。
+ [AWS SDK for .NET](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/RDS/TRDSAuthTokenGenerator.html)
+ [AWS SDK for C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp/latest/api/class_aws_1_1_r_d_s_1_1_r_d_s_client.html#ae134ffffed5d7672f6156d324e7bd392)
+ [AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/api/service/rds/#pkg-overview)
+ [AWS SDK for Java](https://docs.aws.amazon.com/sdk-for-java/latest/reference/software/amazon/awssdk/services/rds/RdsUtilities.html)
+ [AWS SDK for JavaScript](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/modules/_aws_sdk_rds_signer.html)
+ [AWS SDK for PHP](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.Rds.AuthTokenGenerator.html)
+ [AWS SDK for Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/rds.html#RDS.Client.generate_db_auth_token)
+ [AWS SDK for Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/RDS/AuthTokenGenerator.html)
## IAM データベース認証の制限
IAM データベース認証を使用する場合、以下の制限が適用されます。
+ 現在、IAM データベース認証はすべてのグローバル条件コンテキストキーをサポートしていません。
グローバル条件コンテキストキーの詳細については、「*IAM ユーザーガイド*」の「[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
+ PostgreSQL の場合、IAM ロール (`rds_iam`) がマスターユーザーに追加される (マスターユーザーである RDS を含む) と、IAM 認証はパスワード認証よりも優先されるため、ユーザーは IAM ユーザーとしてログインする必要があります。
+ DB クラスター エンドポイントの代わりに、カスタム Route 53 DNS レコードを使用して認証トークンを生成することはできません。
+ CloudWatch と CloudTrail は IAM 認証のログ記録を行いません。これらのサービスは、IAM ロールにデータベース接続の有効化を許可する `generate-db-auth-token` API コールを追跡しません。
+ IAM DB 認証には、データベースクラスターのコンピューティングリソースが必要です。信頼性の高い接続を実現するには、データベースに 300～1,000 MiB 以上の追加メモリが必要です。ワークロードに必要なメモリを確認するには、IAM DB 認証を有効にする前と後に、拡張モニタリングプロセスリストの RDS プロセスの RES 列を比較します。「[RDS コンソールでの OS メトリクスの表示](USER_Monitoring.OS.Viewing.md)」を参照してください。
バースト可能なクラスインスタンスを使用している場合は、バッファやキャッシュなどの他のパラメータで使用されるメモリを同じ量だけ減らして、メモリが不足しないようにします。
+ Aurora MySQL では、IAM 認証で設定したデータベースユーザーにパスワードベースの認証を使用することはできません。
+ IAM DB 認証は、どのエンジンの RDS on Outposts でもサポートされていません。
## IAM データベース認証に関する推奨事項
IAM データベース認証を使用する場合には、以下のことをお勧めします。
+ アプリケーションが必要とする新しい IAM データベース認証接続が 1 秒あたり 200 未満の場合は、IAM データベース認証を使用します。
Amazon Aurora を使用するデータベースエンジンでは、1 秒あたりの認証試行回数に制限はありません。ただし、IAM データベース認証を使用するときは、アプリケーションは認証トークンを生成する必要があります。次に、アプリケーションはそのトークンを使用して DB クラスターに接続します。1 秒あたりの新しい接続数の上限を超えた場合、IAM データベース認証の追加オーバーヘッドによって接続のスロットリングが発生する場合があります。
接続が頻繁に作成されるのを軽減するために、アプリケーションで接続プールを使用することを検討してください。これにより、IAM DB 認証のオーバーヘッドが軽減され、アプリケーションで既存の接続を再利用できるようになります。または、これらのユースケースでは RDS Proxy の使用を検討してください。RDS Proxy には追加料金がかかります。「[RDS Proxy の料金表](https://aws.amazon.com/rds/proxy/pricing/)」をご覧ください。
+ IAM データベース認証トークンのサイズは、IAM タグの数、IAM サービスポリシー、ARN の長さ、その他の IAM やデータベースのプロパティなど、さまざまな要素によって異なります。このトークンの最小サイズは、通常、約 1 KB ですが、それ以上になることもあります。このトークンは IAM 認証を使用するデータベースへの接続文字列のパスワードとして使用されるため、データベースドライバー (ODBC など) やツールが、サイズを理由にこのトークンを制限したり、切り詰めたりしないようにする必要があります。トークンが切り詰められると、データベースと IAM による認証検証は失敗します。
+ IAM データベース認証トークンの作成時に一時的な認証情報を使用している場合でも、IAM データベース認証トークンを使用して接続リクエストを行うときには、その一時的な認証情報が引き続き有効なものである必要があります。
## サポートされていない AWS グローバル条件コンテキストキー
IAMデータベース認証は AWS グローバル条件コンテキストキーのうち次のサブセットをサポートしていません。
+ `aws:Referer`
+ `aws:SourceIp`
+ `aws:SourceVpc`
+ `aws:SourceVpce`
+ `aws:UserAgent`
+ `aws:VpcSourceIp`
条件キーの詳細については、[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) の「*AWS グローバル条件コンテキストキー」* を参照してください。
# IAM データベース認証の有効化と無効化
デフォルトでは、IAM データベース認証は DB クラスターで無効になります。AWS マネジメントコンソール、AWS CLI、API のいずれかを使用して、IAM データベース認証を有効または無効にすることができます。
次のいずれかのアクションを実行する際に、IAM データベース認証を有効にすることができます。
+ IAM データベース認証を有効にして新しい DB クラスターを作成するには、「[Amazon Aurora DB クラスターの作成](Aurora.CreateInstance.md)」を参照してください。
+ DB クラスターを変更して IAM データベース認証を有効にするには、「[Amazon Aurora DB クラスターの変更](Aurora.Modifying.md)」を参照してください。
+ IAM データベース認証を有効にしてスナップショットから DB クラスターを復元するには、「[DB クラスタースナップショットからの復元](aurora-restore-snapshot.md)」を参照してください。
+ IAM データベース認証を有効化しながら DB クラスター を特定の時点に復元するには、「[DB クラスターを指定の時点の状態に復元する](aurora-pitr.md)」を参照してください。
## コンソール
作成または変更の各ワークフローには、[**データベース認証**] セクションがあり、IAM データベース認証を有効または無効にすることができます。そのセクションで、[**パスワードと IAM データベース認証**] を選択して、IAM データベース認証を有効にします。
**既存の DB クラスターに対して IAM データベース認証を有効または無効にするには**
1. Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、[**データベース**] を選択します。
1. 変更する DB クラスターを選択します。
**注記**
DB クラスター内のすべての DB インスタンスが IAM と互換性がある場合にのみ、IAM 認証を有効にすることができます。[利用可能なリージョンとバージョン](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability) の互換性要件を確認する。
1. [**Modify**] を選択します。
1. **[データベース認証]** セクションで、 を選択して、**[IAM データベース認証]** を有効にします。IAM 認証を無効にするには、**[パスワード認証]** または **[パスワードと Kerberos 認証]** を選択します。
1. CloudWatch Logs への IAM DB 認証ログの発行を有効にすることもできます。**[ログのエクスポート]** で、**[iam-db-auth-error ログ]** オプションを選択します。ログを CloudWatch Logs に発行するとストレージが消費され、その分の料金が発生します。不要になった CloudWatch Logs は削除してください。
1. [**Continue**] を選択します。
1. 変更をすぐに適用するには、[**変更のスケジューリング**] セクションで [**今すぐ**] を選択します。
1. [ **クラスターを変更**] を選択します。
## AWS CLI
AWS CLI を使用して、IAM 認証により新しい DB インスタンスクラスターを作成するには、[https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) コマンドを使用します。`--enable-iam-database-authentication` オプションを指定します。
既存の DB クラスターを更新して、IAM 認証を持つ、または持たないようにするには、AWS CLI コマンド [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) を使用します。必要に応じて `--enable-iam-database-authentication` または `--no-enable-iam-database-authentication` オプションを指定します。
**注記**
DB クラスター内のすべての DB インスタンスが IAM と互換性がある場合にのみ、IAM 認証を有効にすることができます。[利用可能なリージョンとバージョン](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability) の互換性要件を確認する。
デフォルトでは、Aurora は次のメンテナンスウィンドウ中に変更を実行します。これを上書きし、IAM DB 認証をできるだけ早く有効にする場合は、`--apply-immediately` パラメータを使用します。
DB クラスターを復元する場合は、次のいずれかの AWS CLI コマンドを使用します。
+ `[restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)`
+ `[restore-db-cluster-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)`
IAM データベース認証設定は、デフォルトで元のスナップショットの設定になります。この設定を変更するには、必要に応じて `--enable-iam-database-authentication` または `--no-enable-iam-database-authentication` オプションを設定します。
## RDS API
API を使用して、IAM 認証で新しい DB インスタンスを作成するには、API オペレーション [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) を使用します。`EnableIAMDatabaseAuthentication` パラメータを `true` に設定します。
既存の DB クラスターを更新して、IAM 認証を持つ、または持たないようにするには、API オペレーション [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) を使用します。`EnableIAMDatabaseAuthentication` パラメータを `true` に設定して IAM 認証を有効にするか、`false` に設定して無効にします。
**注記**
DB クラスター内のすべての DB インスタンスが IAM と互換性がある場合にのみ、IAM 認証を有効にすることができます。[利用可能なリージョンとバージョン](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability) の互換性要件を確認する。
DB クラスターを復元する場合は、次のいずれかの API オペレーションを使用します。
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
IAM データベース認証設定は、デフォルトで元のスナップショットの設定になります。この設定を変更するには、`EnableIAMDatabaseAuthentication` パラメータを `true` に設定して IAM 認証を有効にするか、`false` に設定して無効にします。
# IAM データベースアクセス用の IAM ポリシーの作成と使用
ユーザーまたはロールに DB クラスターへの接続を許可するには、IAM ポリシーを作成する必要があります。その後、ポリシーをアクセス許可セットまたはロールにアタッチします。
**注記**
IAM キーポリシーの詳細については、「[Amazon Aurora での Identity and Access Management](UsingWithRDS.IAM.md)」を参照してください。
次のポリシー例では、ユーザーは IAM データベース認証を使用して、DB クラスターに接続できます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:111122223333:dbuser:cluster-ABCDEFGHIJKL01234/db_user"
]
}
]
}
```
------
**重要**
管理者権限を持つユーザーは、IAM ポリシーで明示的なアクセス許可が設定されていない場合でも、DB のクラスターにアクセスできます。管理者アクセスを DB のクラスターに制限するには、最低限のアクセス許可が適切に設定された IAM ロールを作成し、それを管理者に設定します。
**注記**
`rds-db:` プレフィックスと、`rds:` で始まる他の RDS API オペレーションのプレフィックスを混同しないでください。IAM データベース認証に対してのみ、`rds-db:` プレフィックスと `rds-db:connect` アクションを使用します。これらは、その他のコンテキストでは有効ではありません。
このポリシーには、次の要素を持つ 1 つのステートメントが含まれています。
+ `Effect` - DB クラスターへのアクセスを許可するには、`Allow` を指定します。アクセスを明示的に許可しない場合、デフォルトでアクセスは拒否されます。
+ `Action` - DB クラスターへの接続を許可するには、`rds-db:connect` を指定します。
+ `Resource` - 1 つの DB クラスターで 1 つのデータベースアカウントを示す Amazon リソースネーム (ARN) を指定します。ARN 形式は次のとおりです。
```
arn:aws:rds-db:region:account-id:dbuser:DbClusterResourceId/db-user-name
```
この形式では、以下のように置き換えます。
+ `region` は、DB クラスターの AWS リージョンです。このポリシー例での AWS リージョンは `us-east-2` です。
+ `account-id` は DB クラスターの AWS アカウント番号です。このポリシー例でのアカウント番号は `1234567890` です。ユーザーは DB クラスターのアカウントと同じアカウントでなければなりません。
クロスアカウントアクセスを実行するには、DB クラスターのアカウントに上記のポリシーで IAM ロールを作成し、他のアカウントがそのロールを引き継ぐことを許可します。
+ `DbClusterResourceId` は、DB クラスターの識別子です。この識別子は AWS リージョンに固有であり、変更されることはありません。このポリシー例での識別子は `cluster-ABCDEFGHIJKL01234` です。
Amazon Aurora 用の DB クラスターのリソース ID を AWS マネジメントコンソール で検索するには、DB クラスターを選択して、その詳細を表示します。そして、[**Configuration (設定)**] タブを選択します。[**設定**] セクションに [**リソース ID**] が表示されます。
または、次のように AWS CLI コマンドを使用して、以下に示されているように、現在の AWS リージョンのすべての DB クラスターの識別子とリソース ID をリストできます。
```
aws rds describe-db-clusters --query "DBClusters[*].[DBClusterIdentifier,DbClusterResourceId]"
```
**注記**
RDS Proxy 経由でデータベースに接続する場合は、`prx-ABCDEFGHIJKL01234` などのプロキシリソース ID を指定します。RDS Proxy で IAM データベース認証を使用する方法については、「[IAM 認証を使用したデータベースへの接続](rds-proxy-connecting.md#rds-proxy-connecting-iam)」を参照してください。
+ `db-user-name` は、IAM 認証に関連付けるデータベースアカウントの名前です。このポリシー例で、データベースアカウントは `db_user` です。
多様なアクセスパターンをサポートするため、他の ARN を構築できます。次のポリシーでは、DB クラスターで 2 つの異なるデータベースアカウントにアクセスできます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/jane_doe",
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/mary_roe"
]
}
]
}
```
------
次のポリシーでは、特定の AWS アカウントと AWS リージョンのすべての DB クラスターとデータベースアカウントに一致させるために「\$1」文字を使用します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:111122223333:dbuser:*/*"
]
}
]
}
```
------
次のポリシーは、特定の AWS アカウントと AWS リージョンの DB クラスターすべてに一致します。ただし、`jane_doe` データベースアカウントを持つ DB クラスターまたは DB クラスターにのみにアクセスが許可されます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:*/jane_doe"
]
}
]
}
```
------
ユーザーまたはロールは、データベースユーザーがアクセスするデータベースにのみアクセスできます。例えば、DB クラスターに *dev* という名前のデータベースと、*test* という名前の別のデータベースがあるとします。データベースユーザー `jane_doe` が *dev* のみにアクセスできる場合、`jane_doe` ユーザーでその DB クラスターにアクセスできるユーザーまたはロールも、*dev* にのみアクセスできます。このアクセス制限は、テーブル、ビューなどその他のデータベースオブジェクトにも当てはまります。
管理者は、エンティティに必要な、指定されたリソースに対して特定の API オペレーションを実行するアクセス許可を付与する IAM ポリシーを作成する必要があります。続いて、管理者は、それらのアクセス許可を必要とするアクセス許可セットまたはロールに、そのポリシーをアタッチします。ポリシーの例については、「[Amazon Aurora のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## IAM ポリシーをアクセス許可セットまたはロールにアタッチする
データベース認証を許可する IAM ポリシーを作成した後、そのポリシーをアクセス許可セットまたはロールにアタッチする必要があります。このトピックに関するチュートリアルについては、*IAM ユーザーガイド*の「[はじめてのカスタマー管理ポリシーの作成とアタッチ](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html)」を参照してください。
チュートリアルを進める際に、このセクションに記載されているいずれかのポリシー例をスタート点として使用し、ニーズに合わせて調整することができます。チュートリアルを完了すると、`rds-db:connect` アクションを利用できる、ポリシーがアタッチされたアクセス許可セットが作成されます。
**注記**
複数のアクセス許可セットまたはロールを同じデータベースユーザーアカウントにマップできます。例えば、IAM ポリシーで以下のリソース ARN を指定したとします。
```
arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-12ABC34DEFG5HIJ6KLMNOP78QR/jane_doe
```
ポリシーを *Jane*、*Bob*、*Diego* にアタッチした場合、これらの各ユーザーは、`jane_doe` データベースアカウントを使用して、指定された DB クラスターに接続できます。
# IAM 認証を使用したデータベースアカウントの作成
IAM データベース認証では、作成するユーザーアカウントにデータベースのパスワードを割り当てる必要はありません。データベースアカウントにマッピングされているユーザーを削除した場合は、`DROP USER` ステートメントでデータベースアカウントも削除する必要があります。
**注記**
IAM 認証に使用されるユーザー名は、データベース内のユーザー名の大文字および小文字と一致する必要があります。
**Topics**
+ [Aurora MySQL での IAM 認証の使用](#UsingWithRDS.IAMDBAuth.DBAccounts.MySQL)
+ [Aurora PostgreSQL での IAM 認証の使用](#UsingWithRDS.IAMDBAuth.DBAccounts.PostgreSQL)
## Aurora MySQL での IAM 認証の使用
Aurora MySQL では、認証は、`AWSAuthenticationPlugin` (IAM とシームレスに連携してユーザーを認証する AWS 提供のプラグイン) によって処理されます。DB クラスターに、マスターユーザーまたはユーザーを作成して権限を付与できる別のユーザーとして接続します。接続後、次の例に示すように、`CREATE USER` ステートメントを発行します。
```
CREATE USER 'jane_doe' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
```
`IDENTIFIED WITH` 句により、Aurora MySQL は `AWSAuthenticationPlugin` を使用して、データベースアカウント (`jane_doe`) を認証できます。`AS 'RDS'` 句は、認証方式を参照します。指定したデータベースユーザー名は、IAM データベースアクセスの IAM ポリシー内のリソースと同じであることを確認します。詳細については、「[IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)」を参照してください。
**注記**
次のメッセージが表示された場合、AWS が提供するプラグインが、現在の DB クラスターに使用できないことを意味します。
`ERROR 1524 (HY000): Plugin 'AWSAuthenticationPlugin' is not loaded`
このエラーをトラブルシューティングするには、サポートされている設定を使用していること、および DB クラスターで IAM データベース認証を有効にしていることを確認します。詳細については、「[利用可能なリージョンとバージョン](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability)」および「[IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)」を参照してください。
`AWSAuthenticationPlugin` を使用してアカウントを作成したら、他のデータベースのアカウントと同様に管理します。例えば、`GRANT` および `REVOKE` ステートメントでアカウント特権を変更したり、`ALTER USER` ステートメントでさまざまなアカウント属性を変更したりできます。
IAM を使用する場合、データベースネットワークトラフィックは SSL/TLS を使用して暗号化されます。SSL 接続を許可するには、以下のコマンドでユーザーアカウントを変更します。
```
ALTER USER 'jane_doe'@'%' REQUIRE SSL;
```
## Aurora PostgreSQL での IAM 認証の使用
Aurora PostgreSQL で IAM 認証を使用するには、マスターユーザーまたはユーザーを作成して権限を付与できる別のユーザーとして DB クラスターに接続します。接続後、データベースユーザーを作成して、次の例に示すように、ユーザーに `rds_iam` ロールを付与します。
```
CREATE USER db_userx;
GRANT rds_iam TO db_userx;
```
指定したデータベースユーザー名は、IAM データベースアクセスの IAM ポリシー内のリソースと同じであることを確認します。詳細については、「[IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)」を参照してください。IAM 認証を使用するには、`rds_iam` ロールを付与する必要があります。ロールのネストされたメンバーシップまたは間接的な付与を使用することもできます。
PostgreSQL データベースユーザーは IAM または Kerberos 認証のいずれかを使用できますが、両方を使用することはできないため、このユーザーも `rds_ad` ロールを持つことはできません。これは、ネストされたメンバーシップにも適用されます。詳細については、「[ステップ 7: Kerberos プリンシパル用の PostgreSQL ユーザーを作成する](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins)」を参照してください。
# IAM 認証を使用した DB クラスターへの接続
IAM データベース認証では、DB クラスターに接続するときに認証トークンを使用します。*認証トークン*は、パスワードの代わりに使用する文字列です。認証トークンを生成した後、期限切れになるまで 15 分間有効です。期限切れのトークンを使用して接続を試みると、接続リクエストは拒否されます。
すべての認証トークンは、AWS 署名バージョン 4 を使用した有効な署名が添付されている必要があります (詳細については、*AWS 全般のリファレンス*の「[Signature Version 4 の署名プロセス](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html)」を参照してください)。AWS CLI や AWS など、AWS SDK for Java とAWS SDK for Python (Boto3) SDK は、作成した各トークンに自動的に署名できます。
別の AWS のサービス (AWS Lambda など) から Amazon Aurora に接続するときに、認証トークンを使用できます。トークンを使用することで、コードにパスワードを含めないで済みます。あるいは、AWS SDK を使用して、認証トークンをプログラムで作成して、プログラムで署名することもできます。
IAM 認証トークンに署名した後、 Aurora DB クラスターに接続できます。以下では、コマンドラインツールまたは AWS や AWS SDK for Java などの AWS SDK for Python (Boto3) SDK を使用して、これを行う方法を示しています。
詳細については、以下のブログ投稿を参照してください。
+ [IAM 認証を使用して SQL Workbench/J により Aurora MySQL または Amazon RDS for MySQL に接続する](https://aws.amazon.com/blogs/database/use-iam-authentication-to-connect-with-sql-workbenchj-to-amazon-aurora-mysql-or-amazon-rds-for-mysql/)
+ [pgAdmin Amazon Aurora PostgreSQL または Amazon RDS for PostgreSQL と接続するための IAM 認証の使用](https://aws.amazon.com/blogs/database/using-iam-authentication-to-connect-with-pgadmin-amazon-aurora-postgresql-or-amazon-rds-for-postgresql/)
**前提条件**
IAM 認証を使用して DB クラスターに接続するための前提条件は以下のとおりです。
+ [IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [IAM 認証を使用したデータベースアカウントの作成](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Topics**
+ [IAM 認証と AWS ドライバーを使用した DB クラスターへの接続](IAMDBAuth.Connecting.Drivers.md)
+ [コマンドラインから IAM 認証を使用して、DB クラスターに接続する: AWS CLI および mysql クライアント](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.md)
+ [コマンドラインから IAM 認証を使用して DB クラスターに接続する: AWS CLI および psql クライアント](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.PostgreSQL.md)
+ [IAM 認証および AWS SDK for .NET を使用した DB クラスターへの接続](UsingWithRDS.IAMDBAuth.Connecting.NET.md)
+ [IAM 認証および AWS SDK for Go を使用した DB クラスターへの接続](UsingWithRDS.IAMDBAuth.Connecting.Go.md)
+ [IAM 認証および AWS SDK for Java を使用した DB クラスターへの接続](UsingWithRDS.IAMDBAuth.Connecting.Java.md)
+ [IAM 認証および AWS SDK for Python (Boto3) を使用した DB クラスターへの接続](UsingWithRDS.IAMDBAuth.Connecting.Python.md)
# IAM 認証と AWS ドライバーを使用した DB クラスターへの接続
AWS のドライバースイートは、スイッチオーバーとフェイルオーバーの時間の短縮、AWS Secrets Manager、AWS Identity and Access Management (IAM)、フェデレーティッド ID での認証をサポートするように設計されています。AWS ドライバーは、DB クラスターステータスをモニタリングし、クラスタートポロジを認識して新しいライターを決定することを前提としています。このアプローチにより、スイッチオーバーとフェイルオーバーの時間が 1 桁秒に短縮されます (オープンソースドライバーの場合は数十秒)。
AWS ドライバーの詳細については、お使いの [Aurora MySQL](Aurora.Connecting.md#Aurora.Connecting.JDBCDriverMySQL) または [Aurora PostgreSQL](Aurora.Connecting.md#Aurora.Connecting.AuroraPostgreSQL.Utilities) DB クラスターに対応する言語ドライバーを参照してください。
# コマンドラインから IAM 認証を使用して、DB クラスターに接続する: AWS CLI および mysql クライアント
以下に示すように、AWS CLI および `mysql` コマンドラインツールを使用して、コマンドラインから Aurora DB クラスターに接続できます。
**前提条件**
IAM 認証を使用して DB クラスターに接続するための前提条件は以下のとおりです。
+ [IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [IAM 認証を使用したデータベースアカウントの作成](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**注記**
IAM 認証を使用して SQLWorkbench/J を使用してデータベースに接続する方法については、ブログ記事「[IAM 認証を使用して SQL Workbench/J で Aurora MySQL または Amazon RDS for MySQL に接続する](https://aws.amazon.com/blogs/database/use-iam-authentication-to-connect-with-sql-workbenchj-to-amazon-aurora-mysql-or-amazon-rds-for-mysql/)」を参照してください。
**Topics**
+ [IAM 認証トークンの生成](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken)
+ [DB クラスターへの接続](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect)
## IAM 認証トークンの生成
次の例では、AWS CLI を使用して署名された認証トークンを取得する方法を示します。
```
aws rds generate-db-auth-token \
--hostname rdsmysql.123456789012.us-west-2.rds.amazonaws.com \
--port 3306 \
--region us-west-2 \
--username jane_doe
```
この例で、パラメータは次のとおりです。
+ `--hostname` - アクセス先の DB クラスターのホスト名。
+ `--port` - DB クラスターへの接続に使用するポート番号
+ `--region` - DB クラスターが実行中の AWS リージョン
+ `--username` - アクセス先のデータベースアカウント
トークンの初期の複数の文字は次のようになります。
```
rdsmysql.123456789012.us-west-2.rds.amazonaws.com:3306/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
```
**注記**
DB クラスター エンドポイントの代わりに、カスタム Route 53 DNS レコードを使用して認証トークンを生成することはできません。
## DB クラスターへの接続
接続の全般的な形式を次に示します。
```
mysql --host=hostName --port=portNumber --ssl-ca=full_path_to_ssl_certificate --enable-cleartext-plugin --user=userName --password=authToken
```
パラメータは次のとおりです。
+ `--host` - アクセス先の DB クラスターのホスト名。
+ `--port` - DB クラスターへの接続に使用するポート番号
+ `--ssl-ca` - 公開キーを含む SSL 証明書ファイルへのフルパス
詳細については、「[Aurora MySQL DB クラスターへの接続](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL)」を参照してください。
SSL 証明書をダウンロードするには [SSL/TLS を使用した DB クラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照ください。
+ `--enable-cleartext-plugin` - この接続で `AWSAuthenticationPlugin` を使用する必要があることを示す値
MariaDB クライアントを使用している場合、`--enable-cleartext-plugin` オプションは必須ではありません。
+ `--user` - アクセス先のデータベースアカウント
+ `--password` - 署名済みの IAM 認証トークン
認証トークンは数百の文字で構成されます。これは、コマンドラインでは手に負えなくなる可能性があります。この問題を回避する 1 つの方法は、環境可変にトークンを保存し、接続時にその可変を使用することです。次の例は、この回避策を実行する 1 つの方法を示しています。この例では、*/sample\$1dir/* が公開キーを含む SSL 証明書ファイルへのフルパスです。
```
RDSHOST="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
TOKEN="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 3306 --region us-west-2 --username jane_doe )"
mysql --host=$RDSHOST --port=3306 --ssl-ca=/sample_dir/global-bundle.pem --enable-cleartext-plugin --user=jane_doe --password=$TOKEN
```
`AWSAuthenticationPlugin` を使って接続した場合、接続は SSL を使用して保護されます。これを確認するには、`mysql>` コマンドプロンプトで以下を入力します。
```
show status like 'Ssl%';
```
出力の次の行に詳細情報が示されます。
```
+---------------+-------------+
| Variable_name | Value |
+---------------+-------------+
| ... | ...
| Ssl_cipher | AES256-SHA |
| ... | ...
| Ssl_version | TLSv1.1 |
| ... | ...
+-----------------------------+
```
プロキシ経由で DB クラスターに接続する場合は、「[IAM 認証を使用したデータベースへの接続](rds-proxy-connecting.md#rds-proxy-connecting-iam)」を参照してください。
# コマンドラインから IAM 認証を使用して DB クラスターに接続する: AWS CLI および psql クライアント
以下に示すように、AWS CLI および psql コマンドラインツールを使用して、コマンドラインから Aurora PostgreSQL DB クラスターに接続できます。
**前提条件**
IAM 認証を使用して DB クラスターに接続するための前提条件は以下のとおりです。
+ [IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [IAM 認証を使用したデータベースアカウントの作成](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**注記**
pgAdminを使用してIAM認証でデータベースに接続する方法については、ブログ記事[IAM認証を使用してpgAdmin Amazon Aurora PostgreSQLまたはAmazon RDS for PostgreSQLで接続する](https://aws.amazon.com/blogs/database/using-iam-authentication-to-connect-with-pgadmin-amazon-aurora-postgresql-or-amazon-rds-for-postgresql/)を参照してください。
**Topics**
+ [IAM 認証トークンの生成](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken.PostgreSQL)
+ [Aurora PostgreSQL クラスターへの接続](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect.PostgreSQL)
## IAM 認証トークンの生成
認証トークンは数百の文字で構成されるため、コマンドラインでは手に負えなくなる可能性があります。この問題を回避する 1 つの方法は、環境可変にトークンを保存し、接続時にその可変を使用することです。次の例では、AWS CLI コマンドを使用して署名された認証トークンを取得するために `generate-db-auth-token` を使用し、`PGPASSWORD` 環境可変に格納する方法を示しています。
```
export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )"
```
例では、`generate-db-auth-token` コマンドへのパラメータは次のとおりです。
+ `--hostname` - アクセス先の DB クラスター (クラスターエンドポイント) のホスト名
+ `--port` - DB クラスターへの接続に使用するポート番号
+ `--region` - DB クラスターが実行中の AWS リージョン
+ `--username` - アクセス先のデータベースアカウント
生成されたトークンの初期の複数の文字は次のようになります。
```
mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com:5432/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
```
**注記**
DB クラスター エンドポイントの代わりに、カスタム Route 53 DNS レコードを使用して認証トークンを生成することはできません。
## Aurora PostgreSQL クラスターへの接続
psql を使用して接続する全般的な形式を次に示します。
```
psql "host=hostName port=portNumber sslmode=verify-full sslrootcert=full_path_to_ssl_certificate dbname=DBName user=userName password=authToken"
```
パラメータは次のとおりです。
+ `host` - アクセス先の DB クラスター (クラスターエンドポイント) のホスト名
+ `port` - DB クラスターへの接続に使用するポート番号
+ `sslmode` - 使用する SSL モード
`sslmode=verify-full` を使用すると、SSL 接続で DB クラスターのエンドポイントを SSL 証明書のエンドポイントと照合します。
+ `sslrootcert` －公開キーを含む SSL 証明書ファイルへのフルパス
詳細については、「[SSL/TLS での Aurora PostgreSQL データの保護](AuroraPostgreSQL.Security.md#AuroraPostgreSQL.Security.SSL)」を参照してください。
SSL 証明書をダウンロードするには [SSL/TLS を使用した DB クラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照ください。
+ `dbname` - アクセス先のデータベース
+ `user` - アクセス先のデータベースアカウント
+ `password` - 署名済みの IAM 認証トークン
**注記**
DB クラスター エンドポイントの代わりに、カスタム Route 53 DNS レコードを使用して認証トークンを生成することはできません。
次の例は、psql を使用して接続する方法を示しています。この例の psql では、環境変数 `RDSHOST` をホスト用に、また、環境変数 `PGPASSWORD` を生成されたトークン用に使用しています。また、*/sample\$1dir/* は公開キーを含む SSL 証明書ファイルへの完全なパスを示します。
```
export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )"
psql "host=$RDSHOST port=5432 sslmode=verify-full sslrootcert=/sample_dir/global-bundle.pem dbname=DBName user=jane_doe password=$PGPASSWORD"
```
プロキシ経由で DB クラスターに接続する場合は、「[IAM 認証を使用したデータベースへの接続](rds-proxy-connecting.md#rds-proxy-connecting-iam)」を参照してください。
# IAM 認証および AWS SDK for .NET を使用した DB クラスターへの接続
次に説明するように、AWS SDK for .NET を使用して、Aurora MySQL もしくは Aurora PostgreSQL DB クラスターに接続できます。
**前提条件**
IAM 認証を使用して DB クラスターに接続するための前提条件は以下のとおりです。
+ [IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [IAM 認証を使用したデータベースアカウントの作成](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**例**
以下のコード例で、認証トークンを生成し、それを使用して DB クラスターに接続する方法を示します。
このコードサンプルを実行するには、AWS SDK for .NET サイトにある [AWS](https://aws.amazon.com/sdk-for-net/) が必要です。`AWSSDK.CORE` および `AWSSDK.RDS` パッケージが必要です。DB クラスターに接続するには、MariaDB または MySQL 用の MySqlConnector や PostgreSQL 用の Npgsql など、DB エンジン用の .NET データベースコネクタを使用します。
このコードで Aurora MySQL DB クラスターに接続します。必要に応じて以下の可変の値を変更します。
+ `server` - アクセス先の DB クラスターのエンドポイント
+ `user` - アクセス先のデータベースアカウント
+ `database` - アクセス先のデータベース
+ `port` - DB クラスターへの接続に使用するポート番号
+ `SslMode` - 使用する SSL モード
`SslMode=Required` を使用すると、SSL 接続で DB クラスターのエンドポイントを SSL 証明書のエンドポイントと照合します。
+ `SslCa` － Amazon Aurora のSSL 証明書へのフルパス
証明書をダウンロードするには、「[SSL/TLS を使用した DB クラスターへの接続の暗号化](UsingWithRDS.SSL.md)」を参照してください。
**注記**
DB クラスター エンドポイントの代わりに、カスタム Route 53 DNS レコードを使用して認証トークンを生成することはできません。
```
using System;
using System.Data;
using MySql.Data;
using MySql.Data.MySqlClient;
using Amazon;
namespace ubuntu
{
class Program
{
static void Main(string[] args)
{
var pwd = Amazon.RDS.Util.RDSAuthTokenGenerator.GenerateAuthToken(RegionEndpoint.USEast1, "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 3306, "jane_doe");
// for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated
MySqlConnection conn = new MySqlConnection($"server=mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com;user=jane_doe;database=mydB;port=3306;password={pwd};SslMode=Required;SslCa=full_path_to_ssl_certificate");
conn.Open();
// Define a query
MySqlCommand sampleCommand = new MySqlCommand("SHOW DATABASES;", conn);
// Execute a query
MySqlDataReader mysqlDataRdr = sampleCommand.ExecuteReader();
// Read all rows and output the first column in each row
while (mysqlDataRdr.Read())
Console.WriteLine(mysqlDataRdr[0]);
mysqlDataRdr.Close();
// Close connection
conn.Close();
}
}
}
```
このコードで Aurora PostgreSQL DB クラスターに接続します。
必要に応じて以下の可変の値を変更します。
+ `Server` - アクセス先の DB クラスターのエンドポイント
+ `User ID` - アクセス先のデータベースアカウント
+ `Database` - アクセス先のデータベース
+ `Port` - DB クラスターへの接続に使用するポート番号
+ `SSL Mode` - 使用する SSL モード
`SSL Mode=Required` を使用すると、SSL 接続で DB クラスターのエンドポイントを SSL 証明書のエンドポイントと照合します。
+ `Root Certificate` － Amazon Aurora のSSL 証明書へのフルパス
証明書をダウンロードするには、「[SSL/TLS を使用した DB クラスターへの接続の暗号化](UsingWithRDS.SSL.md)」を参照してください。
**注記**
DB クラスター エンドポイントの代わりに、カスタム Route 53 DNS レコードを使用して認証トークンを生成することはできません。
```
using System;
using Npgsql;
using Amazon.RDS.Util;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
var pwd = RDSAuthTokenGenerator.GenerateAuthToken("postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 5432, "jane_doe");
// for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated
NpgsqlConnection conn = new NpgsqlConnection($"Server=postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com;User Id=jane_doe;Password={pwd};Database=mydb;SSL Mode=Require;Root Certificate=full_path_to_ssl_certificate");
conn.Open();
// Define a query
NpgsqlCommand cmd = new NpgsqlCommand("select count(*) FROM pg_user", conn);
// Execute a query
NpgsqlDataReader dr = cmd.ExecuteReader();
// Read all rows and output the first column in each row
while (dr.Read())
Console.Write("{0}\n", dr[0]);
// Close connection
conn.Close();
}
}
}
```
プロキシ経由で DB クラスターに接続する場合は、「[IAM 認証を使用したデータベースへの接続](rds-proxy-connecting.md#rds-proxy-connecting-iam)」を参照してください。
# IAM 認証および AWS SDK for Go を使用した DB クラスターへの接続
次に説明するように、AWS SDK for Go を使用して、Aurora MySQL もしくは Aurora PostgreSQL DB クラスターに接続できます。
**前提条件**
IAM 認証を使用して DB クラスターに接続するための前提条件は以下のとおりです。
+ [IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [IAM 認証を使用したデータベースアカウントの作成](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**例**
これらのコードサンプルを実行するには、AWS SDK for Go サイトにある [AWS](https://aws.amazon.com/sdk-for-go/) が必要です。
必要に応じて以下の可変の値を変更します。
+ `dbName` - アクセス先のデータベース
+ `dbUser` - アクセス先のデータベースアカウント
+ `dbHost` - アクセス先の DB クラスターのエンドポイント
**注記**
DB クラスター エンドポイントの代わりに、カスタム Route 53 DNS レコードを使用して認証トークンを生成することはできません。
+ `dbPort` - DB クラスターへの接続に使用するポート番号
+ `region` - DB クラスターが実行中の AWS リージョン
さらに、サンプルコード内のインポートされるライブラリがシステムに存在することを確認してください。
**重要**
このセクションの例では、次のコードを使用して、ローカル環境からデータベースにアクセスする認証情報を提供します。
`creds := credentials.NewEnvCredentials()`
Amazon EC2 や Amazon ECS などの AWS のサービスからデータベースにアクセスする場合は、コードを次のコードに置き換えることができます。
`sess := session.Must(session.NewSession())`
`creds := sess.Config.Credentials`
この変更を行う場合は、次のインポートを追加してください。
`"github.com/aws/aws-sdk-go/aws/session"`
**Topics**
+ [IAM 認証と AWS SDK for Go V2 を使用した接続](#UsingWithRDS.IAMDBAuth.Connecting.GoV2)
+ [IAM 認証と AWS SDK for Go V1 を使用した接続。](#UsingWithRDS.IAMDBAuth.Connecting.GoV1)
## IAM 認証と AWS SDK for Go V2 を使用した接続
IAM 認証と AWS SDK for Go V2 を使用して DB クラスターに接続できます
以下のコード例で、認証トークンを生成し、それを使用して DB クラスターに接続する方法を示します。
このコードで Aurora MySQL DB クラスターに接続します。
```
package main
import (
"context"
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/go-sql-driver/mysql"
)
func main() {
var dbName string = "DatabaseName"
var dbUser string = "DatabaseUser"
var dbHost string = "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
var dbPort int = 3306
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = "us-east-1"
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authenticationToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
このコードで Aurora PostgreSQL DB クラスターに接続します。
```
package main
import (
"context"
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/lib/pq"
)
func main() {
var dbName string = "DatabaseName"
var dbUser string = "DatabaseUser"
var dbHost string = "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
var dbPort int = 5432
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = "us-east-1"
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s",
dbHost, dbPort, dbUser, authenticationToken, dbName,
)
db, err := sql.Open("postgres", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
プロキシ経由で DB クラスターに接続する場合は、「[IAM 認証を使用したデータベースへの接続](rds-proxy-connecting.md#rds-proxy-connecting-iam)」を参照してください。
## IAM 認証と AWS SDK for Go V1 を使用した接続。
IAM 認証と AWS SDK for Go V1 を使用して DB クラスターに接続できます
以下のコード例で、認証トークンを生成し、それを使用して DB クラスターに接続する方法を示します。
このコードで Aurora MySQL DB クラスターに接続します。
```
package main
import (
"database/sql"
"fmt"
"log"
"github.com/aws/aws-sdk-go/aws/credentials"
"github.com/aws/aws-sdk-go/service/rds/rdsutils"
_ "github.com/go-sql-driver/mysql"
)
func main() {
dbName := "app"
dbUser := "jane_doe"
dbHost := "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
dbPort := 3306
dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort)
region := "us-east-1"
creds := credentials.NewEnvCredentials()
authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds)
if err != nil {
panic(err)
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
このコードで Aurora PostgreSQL DB クラスターに接続します。
```
package main
import (
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go/aws/credentials"
"github.com/aws/aws-sdk-go/service/rds/rdsutils"
_ "github.com/lib/pq"
)
func main() {
dbName := "app"
dbUser := "jane_doe"
dbHost := "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
dbPort := 5432
dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort)
region := "us-east-1"
creds := credentials.NewEnvCredentials()
authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds)
if err != nil {
panic(err)
}
dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s",
dbHost, dbPort, dbUser, authToken, dbName,
)
db, err := sql.Open("postgres", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
プロキシ経由で DB クラスターに接続する場合は、「[IAM 認証を使用したデータベースへの接続](rds-proxy-connecting.md#rds-proxy-connecting-iam)」を参照してください。
# IAM 認証および AWS SDK for Java を使用した DB クラスターへの接続
次に説明するように、AWS SDK for Java を使用して、Aurora MySQL もしくは Aurora PostgreSQL DB クラスターに接続できます。
**前提条件**
IAM 認証を使用して DB クラスターに接続するための前提条件は以下のとおりです。
+ [IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [IAM 認証を使用したデータベースアカウントの作成](UsingWithRDS.IAMDBAuth.DBAccounts.md)
+ [AWS SDK for Java をセットアップする](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-install.html)
SDK for Java 2.x の使用方法の例については、「[SDK for Java 2.x を使用した Amazon RDS の例](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java_rds_code_examples.html)」を参照してください。AWS Advanced JDBC Wrapper を使用することもできます。「[AWS Advanced JDBC Wrapper ドキュメント](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/Documentation.md)」を参照してください。
**Topics**
+ [IAM 認証トークンの生成](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken)
+ [IAM 認証トークンを手動で構築する](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken2)
+ [DB クラスターへの接続](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken.Connect)
## IAM 認証トークンの生成
AWS SDK for Java を使用してプログラムを作成する場合、`RdsIamAuthTokenGenerator` クラスを使用して署名付き認証トークンを取得できます。このクラスを使用するには、AWS 認証情報を提供する必要があります。これを行うには、`DefaultAWSCredentialsProviderChain` クラスのインスタンスを作成します。`DefaultAWSCredentialsProviderChain` は、[デフォルトの認証情報プロバイダチェーン](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default)で見つける初期の AWS のアクセスキーとシークレットキーを使用します。AWS アクセスキーの詳細については、「[ユーザーのアクセスキーの管理](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)」を参照してください。
**注記**
DB クラスター エンドポイントの代わりに、カスタム Route 53 DNS レコードを使用して認証トークンを生成することはできません。
`RdsIamAuthTokenGenerator` のインスタンスを作成した後、`getAuthToken` メソッドを呼び出して、署名済みトークンを取得できます。AWS リージョン、ホスト名、ポート番号、およびユーザー名を指定します。次のコード例はこれを行う方法を示しています。
```
package com.amazonaws.codesamples;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
public class GenerateRDSAuthToken {
public static void main(String[] args) {
String region = "us-west-2";
String hostname = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
String port = "3306";
String username = "jane_doe";
System.out.println(generateAuthToken(region, hostname, port, username));
}
static String generateAuthToken(String region, String hostName, String port, String username) {
RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder()
.credentials(new DefaultAWSCredentialsProviderChain())
.region(region)
.build();
String authToken = generator.getAuthToken(
GetIamAuthTokenRequest.builder()
.hostname(hostName)
.port(Integer.parseInt(port))
.userName(username)
.build());
return authToken;
}
}
```
## IAM 認証トークンを手動で構築する
Java では、認証トークンを生成するための最も簡単な方法は、`RdsIamAuthTokenGenerator` を使用することです。このクラスは、認証トークンを作成した後、AWS 署名バージョン 4 を使用してサインインします。詳細については、*AWS 全般のリファレンス*の「[Signature Version 4 の署名プロセス](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html)」を参照してください。
ただし、次のコード例に示すように、認証トークンを手動で構築して署名できます。
```
package com.amazonaws.codesamples;
import com.amazonaws.SdkClientException;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.auth.SigningAlgorithm;
import com.amazonaws.util.BinaryUtils;
import org.apache.commons.lang3.StringUtils;
import javax.crypto.Mac;
import javax.crypto.spec.SecretKeySpec;
import java.nio.charset.Charset;
import java.security.MessageDigest;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.SortedMap;
import java.util.TreeMap;
import static com.amazonaws.auth.internal.SignerConstants.AWS4_TERMINATOR;
import static com.amazonaws.util.StringUtils.UTF8;
public class CreateRDSAuthTokenManually {
public static String httpMethod = "GET";
public static String action = "connect";
public static String canonicalURIParameter = "/";
public static SortedMap canonicalQueryParameters = new TreeMap();
public static String payload = StringUtils.EMPTY;
public static String signedHeader = "host";
public static String algorithm = "AWS4-HMAC-SHA256";
public static String serviceName = "rds-db";
public static String requestWithoutSignature;
public static void main(String[] args) throws Exception {
String region = "us-west-2";
String instanceName = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
String port = "3306";
String username = "jane_doe";
Date now = new Date();
String date = new SimpleDateFormat("yyyyMMdd").format(now);
String dateTimeStamp = new SimpleDateFormat("yyyyMMdd'T'HHmmss'Z'").format(now);
DefaultAWSCredentialsProviderChain creds = new DefaultAWSCredentialsProviderChain();
String awsAccessKey = creds.getCredentials().getAWSAccessKeyId();
String awsSecretKey = creds.getCredentials().getAWSSecretKey();
String expiryMinutes = "900";
System.out.println("Step 1: Create a canonical request:");
String canonicalString = createCanonicalString(username, awsAccessKey, date, dateTimeStamp, region, expiryMinutes, instanceName, port);
System.out.println(canonicalString);
System.out.println();
System.out.println("Step 2: Create a string to sign:");
String stringToSign = createStringToSign(dateTimeStamp, canonicalString, awsAccessKey, date, region);
System.out.println(stringToSign);
System.out.println();
System.out.println("Step 3: Calculate the signature:");
String signature = BinaryUtils.toHex(calculateSignature(stringToSign, newSigningKey(awsSecretKey, date, region, serviceName)));
System.out.println(signature);
System.out.println();
System.out.println("Step 4: Add the signing info to the request");
System.out.println(appendSignature(signature));
System.out.println();
}
//Step 1: Create a canonical request date should be in format YYYYMMDD and dateTime should be in format YYYYMMDDTHHMMSSZ
public static String createCanonicalString(String user, String accessKey, String date, String dateTime, String region, String expiryPeriod, String hostName, String port) throws Exception {
canonicalQueryParameters.put("Action", action);
canonicalQueryParameters.put("DBUser", user);
canonicalQueryParameters.put("X-Amz-Algorithm", "AWS4-HMAC-SHA256");
canonicalQueryParameters.put("X-Amz-Credential", accessKey + "%2F" + date + "%2F" + region + "%2F" + serviceName + "%2Faws4_request");
canonicalQueryParameters.put("X-Amz-Date", dateTime);
canonicalQueryParameters.put("X-Amz-Expires", expiryPeriod);
canonicalQueryParameters.put("X-Amz-SignedHeaders", signedHeader);
String canonicalQueryString = "";
while(!canonicalQueryParameters.isEmpty()) {
String currentQueryParameter = canonicalQueryParameters.firstKey();
String currentQueryParameterValue = canonicalQueryParameters.remove(currentQueryParameter);
canonicalQueryString = canonicalQueryString + currentQueryParameter + "=" + currentQueryParameterValue;
if (!currentQueryParameter.equals("X-Amz-SignedHeaders")) {
canonicalQueryString += "&";
}
}
String canonicalHeaders = "host:" + hostName + ":" + port + '\n';
requestWithoutSignature = hostName + ":" + port + "/?" + canonicalQueryString;
String hashedPayload = BinaryUtils.toHex(hash(payload));
return httpMethod + '\n' + canonicalURIParameter + '\n' + canonicalQueryString + '\n' + canonicalHeaders + '\n' + signedHeader + '\n' + hashedPayload;
}
//Step 2: Create a string to sign using sig v4
public static String createStringToSign(String dateTime, String canonicalRequest, String accessKey, String date, String region) throws Exception {
String credentialScope = date + "/" + region + "/" + serviceName + "/aws4_request";
return algorithm + '\n' + dateTime + '\n' + credentialScope + '\n' + BinaryUtils.toHex(hash(canonicalRequest));
}
//Step 3: Calculate signature
/**
* Step 3 of the &AWS; Signature version 4 calculation. It involves deriving
* the signing key and computing the signature. Refer to
* http://docs.aws.amazon
* .com/general/latest/gr/sigv4-calculate-signature.html
*/
public static byte[] calculateSignature(String stringToSign,
byte[] signingKey) {
return sign(stringToSign.getBytes(Charset.forName("UTF-8")), signingKey,
SigningAlgorithm.HmacSHA256);
}
public static byte[] sign(byte[] data, byte[] key,
SigningAlgorithm algorithm) throws SdkClientException {
try {
Mac mac = algorithm.getMac();
mac.init(new SecretKeySpec(key, algorithm.toString()));
return mac.doFinal(data);
} catch (Exception e) {
throw new SdkClientException(
"Unable to calculate a request signature: "
+ e.getMessage(), e);
}
}
public static byte[] newSigningKey(String secretKey,
String dateStamp, String regionName, String serviceName) {
byte[] kSecret = ("AWS4" + secretKey).getBytes(Charset.forName("UTF-8"));
byte[] kDate = sign(dateStamp, kSecret, SigningAlgorithm.HmacSHA256);
byte[] kRegion = sign(regionName, kDate, SigningAlgorithm.HmacSHA256);
byte[] kService = sign(serviceName, kRegion,
SigningAlgorithm.HmacSHA256);
return sign(AWS4_TERMINATOR, kService, SigningAlgorithm.HmacSHA256);
}
public static byte[] sign(String stringData, byte[] key,
SigningAlgorithm algorithm) throws SdkClientException {
try {
byte[] data = stringData.getBytes(UTF8);
return sign(data, key, algorithm);
} catch (Exception e) {
throw new SdkClientException(
"Unable to calculate a request signature: "
+ e.getMessage(), e);
}
}
//Step 4: append the signature
public static String appendSignature(String signature) {
return requestWithoutSignature + "&X-Amz-Signature=" + signature;
}
public static byte[] hash(String s) throws Exception {
try {
MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(s.getBytes(UTF8));
return md.digest();
} catch (Exception e) {
throw new SdkClientException(
"Unable to compute hash while signing request: "
+ e.getMessage(), e);
}
}
}
```
## DB クラスターへの接続
次のコード例では、認証トークンを生成し、それを使用して Aurora MySQL を実行しているクラスターに接続する方法を示しています。
このコードサンプルを実行するには、AWS SDK for Java サイトにある [AWS](https://aws.amazon.com/sdk-for-java/) が必要です。また、以下が必要になります。
+ MySQL Connector/J。 このコードの例は `mysql-connector-java-5.1.33-bin.jar` でテストされています。
+ AWS リージョンに固有の、Amazon Aurora の中間証明書。(詳細については、[SSL/TLS を使用した DB クラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照してください)。クラスローダーは、実行時にこの Java コード例と同じディレクトリで証明書を探し、クラスローダーがその証明書を見つけられるようにします。
+ 必要に応じて以下の可変の値を変更します。
+ `RDS_INSTANCE_HOSTNAME` - アクセス先の DB クラスターのホスト名。
+ `RDS_INSTANCE_PORT` - PostgreSQL DB クラスターへの接続に使用されるポート番号。
+ `REGION_NAME` - DB クラスターが実行中の AWS リージョン
+ `DB_USER` - アクセス先のデータベースアカウント。
+ `SSL_CERTIFICATE` - AWS リージョンに固有の、Amazon Aurora の SSL 証明書。
AWS リージョンの証明書をダウンロードするには、[SSL/TLS を使用した DB クラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照してください。この Java プログラムファイルと同じディレクトリに SSL 証明書を配置し、クラスローダーが実行時にその証明書を見つけられるようにします。
このコード例では、[デフォルトの認証情報プロバイダチェーン](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default)から AWS 認証情報を取得します。
**注記**
セキュリティ上のベストプラクティスとして、ここに示されているプロンプト以外の `DEFAULT_KEY_STORE_PASSWORD` のパスワードを指定してください。
```
package com.amazonaws.samples;
import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator;
import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.auth.DefaultAWSCredentialsProviderChain;
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import java.io.File;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.security.KeyStore;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.Properties;
import java.net.URL;
public class IAMDatabaseAuthenticationTester {
//&AWS; Credentials of the IAM user with policy enabling IAM Database Authenticated access to the db by the db user.
private static final DefaultAWSCredentialsProviderChain creds = new DefaultAWSCredentialsProviderChain();
private static final String AWS_ACCESS_KEY = creds.getCredentials().getAWSAccessKeyId();
private static final String AWS_SECRET_KEY = creds.getCredentials().getAWSSecretKey();
//Configuration parameters for the generation of the IAM Database Authentication token
private static final String RDS_INSTANCE_HOSTNAME = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com";
private static final int RDS_INSTANCE_PORT = 3306;
private static final String REGION_NAME = "us-west-2";
private static final String DB_USER = "jane_doe";
private static final String JDBC_URL = "jdbc:mysql://" + RDS_INSTANCE_HOSTNAME + ":" + RDS_INSTANCE_PORT;
private static final String SSL_CERTIFICATE = "rds-ca-2019-us-west-2.pem";
private static final String KEY_STORE_TYPE = "JKS";
private static final String KEY_STORE_PROVIDER = "SUN";
private static final String KEY_STORE_FILE_PREFIX = "sys-connect-via-ssl-test-cacerts";
private static final String KEY_STORE_FILE_SUFFIX = ".jks";
private static final String DEFAULT_KEY_STORE_PASSWORD = "changeit";
public static void main(String[] args) throws Exception {
//get the connection
Connection connection = getDBConnectionUsingIam();
//verify the connection is successful
Statement stmt= connection.createStatement();
ResultSet rs=stmt.executeQuery("SELECT 'Success!' FROM DUAL;");
while (rs.next()) {
String id = rs.getString(1);
System.out.println(id); //Should print "Success!"
}
//close the connection
stmt.close();
connection.close();
clearSslProperties();
}
/**
* This method returns a connection to the db instance authenticated using IAM Database Authentication
* @return
* @throws Exception
*/
private static Connection getDBConnectionUsingIam() throws Exception {
setSslProperties();
return DriverManager.getConnection(JDBC_URL, setMySqlConnectionProperties());
}
/**
* This method sets the mysql connection properties which includes the IAM Database Authentication token
* as the password. It also specifies that SSL verification is required.
* @return
*/
private static Properties setMySqlConnectionProperties() {
Properties mysqlConnectionProperties = new Properties();
mysqlConnectionProperties.setProperty("verifyServerCertificate","true");
mysqlConnectionProperties.setProperty("useSSL", "true");
mysqlConnectionProperties.setProperty("user",DB_USER);
mysqlConnectionProperties.setProperty("password",generateAuthToken());
return mysqlConnectionProperties;
}
/**
* This method generates the IAM Auth Token.
* An example IAM Auth Token would look like follows:
* btusi123---cmz7kenwo2ye---rds---cn-north-1.amazonaws.com.rproxy.goskope.com.cn:3306/?Action=connect&DBUser=iamtestuser&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20171003T010726Z&X-Amz-SignedHeaders=host&X-Amz-Expires=899&X-Amz-Credential=AKIAPFXHGVDI5RNFO4AQ%2F20171003%2Fcn-north-1%2Frds-db%2Faws4_request&X-Amz-Signature=f9f45ef96c1f770cdad11a53e33ffa4c3730bc03fdee820cfdf1322eed15483b
* @return
*/
private static String generateAuthToken() {
BasicAWSCredentials awsCredentials = new BasicAWSCredentials(AWS_ACCESS_KEY, AWS_SECRET_KEY);
RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder()
.credentials(new AWSStaticCredentialsProvider(awsCredentials)).region(REGION_NAME).build();
return generator.getAuthToken(GetIamAuthTokenRequest.builder()
.hostname(RDS_INSTANCE_HOSTNAME).port(RDS_INSTANCE_PORT).userName(DB_USER).build());
}
/**
* This method sets the SSL properties which specify the key store file, its type and password:
* @throws Exception
*/
private static void setSslProperties() throws Exception {
System.setProperty("javax.net.ssl.trustStore", createKeyStoreFile());
System.setProperty("javax.net.ssl.trustStoreType", KEY_STORE_TYPE);
System.setProperty("javax.net.ssl.trustStorePassword", DEFAULT_KEY_STORE_PASSWORD);
}
/**
* This method returns the path of the Key Store File needed for the SSL verification during the IAM Database Authentication to
* the db instance.
* @return
* @throws Exception
*/
private static String createKeyStoreFile() throws Exception {
return createKeyStoreFile(createCertificate()).getPath();
}
/**
* This method generates the SSL certificate
* @return
* @throws Exception
*/
private static X509Certificate createCertificate() throws Exception {
CertificateFactory certFactory = CertificateFactory.getInstance("X.509");
URL url = new File(SSL_CERTIFICATE).toURI().toURL();
if (url == null) {
throw new Exception();
}
try (InputStream certInputStream = url.openStream()) {
return (X509Certificate) certFactory.generateCertificate(certInputStream);
}
}
/**
* This method creates the Key Store File
* @param rootX509Certificate - the SSL certificate to be stored in the KeyStore
* @return
* @throws Exception
*/
private static File createKeyStoreFile(X509Certificate rootX509Certificate) throws Exception {
File keyStoreFile = File.createTempFile(KEY_STORE_FILE_PREFIX, KEY_STORE_FILE_SUFFIX);
try (FileOutputStream fos = new FileOutputStream(keyStoreFile.getPath())) {
KeyStore ks = KeyStore.getInstance(KEY_STORE_TYPE, KEY_STORE_PROVIDER);
ks.load(null);
ks.setCertificateEntry("rootCaCertificate", rootX509Certificate);
ks.store(fos, DEFAULT_KEY_STORE_PASSWORD.toCharArray());
}
return keyStoreFile;
}
/**
* This method clears the SSL properties.
* @throws Exception
*/
private static void clearSslProperties() throws Exception {
System.clearProperty("javax.net.ssl.trustStore");
System.clearProperty("javax.net.ssl.trustStoreType");
System.clearProperty("javax.net.ssl.trustStorePassword");
}
}
```
プロキシ経由で DB クラスターに接続する場合は、「[IAM 認証を使用したデータベースへの接続](rds-proxy-connecting.md#rds-proxy-connecting-iam)」を参照してください。
# IAM 認証および AWS SDK for Python (Boto3) を使用した DB クラスターへの接続
次に説明するように、AWS SDK for Python (Boto3) を使用して、Aurora MySQL もしくは Aurora PostgreSQL DB クラスターに接続できます。
**前提条件**
IAM 認証を使用して DB クラスターに接続するための前提条件は以下のとおりです。
+ [IAM データベース認証の有効化と無効化](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [IAM データベースアクセス用の IAM ポリシーの作成と使用](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [IAM 認証を使用したデータベースアカウントの作成](UsingWithRDS.IAMDBAuth.DBAccounts.md)
さらに、サンプルコード内のインポートされるライブラリがシステムに存在することを確認してください。
**例**
コード例では、共有認証情報のプロファイルを使用します。認証情報の指定については、AWS SDK for Python (Boto3) ドキュメントの「[認証情報](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html)」を参照してください。
以下のコード例で、認証トークンを生成し、それを使用して DB クラスターに接続する方法を示します。
このコードサンプルを実行するには、AWS SDK for Python (Boto3) サイトにある [AWS](https://aws.amazon.com/sdk-for-python/) が必要です。
必要に応じて以下の可変の値を変更します。
+ `ENDPOINT` - アクセス先の DB クラスターのエンドポイント
+ `PORT` - DB クラスターへの接続に使用するポート番号
+ `USER` - アクセス先のデータベースアカウント
+ `REGION` - DB クラスターが実行中の AWS リージョン
+ `DBNAME` - アクセス先のデータベース
+ `SSLCERTIFICATE` － Amazon Aurora の SSL 証明書へのフルパス
`ssl_ca` を使用する場合、SSL 証明書を指定します。SSL 証明書をダウンロードするには [SSL/TLS を使用した DB クラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照ください。
**注記**
DB クラスター エンドポイントの代わりに、カスタム Route 53 DNS レコードを使用して認証トークンを生成することはできません。
このコードで Aurora MySQL DB クラスターに接続します。
このコードを実行する前に、[Python Package Index](https://pypi.org/project/PyMySQL/) の手順に従って PyMySQL ドライバーをインストールしてください。
```
import pymysql
import sys
import boto3
import os
ENDPOINT="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
PORT="3306"
USER="jane_doe"
REGION="us-east-1"
DBNAME="mydb"
os.environ['LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN'] = '1'
#gets the credentials from .aws/credentials
session = boto3.Session(profile_name='default')
client = session.client('rds')
token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION)
try:
conn = pymysql.connect(auth_plugin_map={'mysql_clear_password':None},host=ENDPOINT, user=USER, password=token, port=PORT, database=DBNAME, ssl_ca='SSLCERTIFICATE', ssl_verify_identity=True, ssl_verify_cert=True)
cur = conn.cursor()
cur.execute("""SELECT now()""")
query_results = cur.fetchall()
print(query_results)
except Exception as e:
print("Database connection failed due to {}".format(e))
```
このコードで Aurora PostgreSQL DB クラスターに接続します。
このコードを実行する前に、[Psycopg documentation](https://pypi.org/project/psycopg2/) の手順に従って `psycopg2` をインストールしてください。
```
import psycopg2
import sys
import boto3
import os
ENDPOINT="postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
PORT="5432"
USER="jane_doe"
REGION="us-east-1"
DBNAME="mydb"
#gets the credentials from .aws/credentials
session = boto3.Session(profile_name='RDSCreds')
client = session.client('rds')
token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION)
try:
conn = psycopg2.connect(host=ENDPOINT, port=PORT, database=DBNAME, user=USER, password=token, sslrootcert="SSLCERTIFICATE")
cur = conn.cursor()
cur.execute("""SELECT now()""")
query_results = cur.fetchall()
print(query_results)
except Exception as e:
print("Database connection failed due to {}".format(e))
```
プロキシ経由で DB クラスターに接続する場合は、「[IAM 認証を使用したデータベースへの接続](rds-proxy-connecting.md#rds-proxy-connecting-iam)」を参照してください。
# IAM DB 認証のトラブルシューティング
以下に、いくつかの一般的な IAM DB 認証に関する問題のトラブルシューティングのヒントと、IAM DB 認証の CloudWatch ログおよびメトリクスに関する情報を示します。
## CloudWatch Logs への IAM DB 認証エラーログのエクスポート
IAM DB 認証エラーログはデータベースホストに保存され、CloudWatch Logs アカウントでこれらのログをエクスポートできます。このページのログと修復方法を使用して、IAM DB 認証の問題をトラブルシューティングします。
コンソール、AWS CLI、および RDS API から CloudWatch Logs へのログエクスポートを有効にできます。コンソールの手順については、「[Amazon CloudWatch Logs へのデータベースログの発行](USER_LogAccess.Procedural.UploadtoCloudWatch.md)」を参照してください。
AWS CLI から DB クラスターを作成するときに IAM DB 認証エラーログを CloudWatch Logs にエクスポートするには、次のコマンドを使用します。
```
aws rds create-db-cluster --db-cluster-identifier mydbinstance \
--region us-east-1 \
--engine postgres \
--engine-version 16 \
--master-username master \
--master-user-password password \
--publicly-accessible \
--enable-iam-database-authentication \
--enable-cloudwatch-logs-exports=iam-db-auth-error
```
AWS CLI から DB クラスターを変更するときに IAM DB 認証エラーログを CloudWatch Logs にエクスポートするには、次のコマンドを使用します。
```
aws rds modify-db-cluster --db-instance-identifier mydbcluster \
--region us-east-1 \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["iam-db-auth-error"]}'
```
DB クラスターが IAM DB 認証ログを CloudWatch Logs にエクスポートしているかどうかを確認するには、`describe-db-instances` コマンドの出力で `EnabledCloudwatchLogsExports` パラメータが `iam-db-auth-error` に設定されているかどうかを確認します。
```
aws rds describe-db-cluster --region us-east-1 --db-cluster-identifier mydbcluster
...
"EnabledCloudwatchLogsExports": [
"iam-db-auth-error"
],
...
```
## IAM DB 認証 CloudWatch メトリクス
Amazon Aurora は、IAM DB 認証に関するほぼリアルタイムのメトリクスを Amazon CloudWatch アカウントに配信します。次の表に、CloudWatch で使用可能な IAM DB 認証メトリクスを示します。
| メトリクス | 説明 |
| --- | --- |
| `IamDbAuthConnectionRequests` | IAM DB 認証で行われた接続リクエストの合計数。 |
| `IamDbAuthConnectionSuccess` | 成功した IAM DB 認証リクエストの合計数。 |
| `IamDbAuthConnectionFailure` | 失敗した IAM DB 認証リクエストの合計数。 |
| `IamDbAuthConnectionFailureInvalidToken` | トークンが無効であるために失敗した IAM DB 認証リクエストの合計数。 |
| `IamDbAuthConnectionFailureInsufficientPermissions` | ポリシーまたはアクセス許可が正しくないために失敗した IAM DB 認証リクエストの合計数。 |
| `IamDbAuthConnectionFailureThrottling` | IAM DB 認証スロットリングにより失敗した IAM DB 認証リクエストの合計数。 |
| `IamDbAuthConnectionFailureServerError` | IAM DB 認証機能の内部サーバーエラーにより失敗した IAM DB 認証リクエストの合計数。 |
## 一般的な の問題と解決策
IAM DB 認証の使用時に、次の問題が発生することがあります。問題を解決するには、表の修復ステップを使用します。
| エラー | メトリクス | 原因 | ソリューション |
| --- | --- | --- | --- |
| `[ERROR] Failed to authenticate the connection request for user db_user because the provided token is malformed or otherwise invalid. (Status Code: 400, Error Code: InvalidToken)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInvalidToken` | 接続リクエストの IAM DB 認証トークンが有効な SigV4a トークンではないか、正しくフォーマットされていません。 | アプリケーションでトークン生成戦略を確認します。場合によっては、トークンを有効なフォーマットで渡してください。トークンを切り捨てる (または文字列形式が正しくない) と、トークンが無効になります。 |
| `[ERROR] Failed to authenticate the connection request for user db_user because the token age is longer than 15 minutes. (Status Code: 400, Error Code:ExpiredToken)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInvalidToken` | IAM DB 認証トークンの有効期限が切れています。トークンは 15 分間のみ有効です。 | アプリケーションでトークンキャッシュやトークン再利用ロジックを確認します。15 分より古いトークンは再利用しないでください。 |
| `[ERROR] Failed to authorize the connection request for user db_user because the IAM policy assumed by the caller 'arn:aws:sts::123456789012:assumed-role/ / ' is not authorized to perform `rds-db:connect` on the DB instance. (Status Code: 403, Error Code:NotAuthorized)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInsufficientPermissions` | このエラーの原因としては、以下が考えられます。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Troubleshooting.html) | アプリケーションで引き受ける IAM ロールやポリシーを確認します。DB に接続する場合と同じポリシーを引き受けてトークンを生成します。 |
| `[ERROR] Failed to authorize the connection request for user db_user due to IAM DB authentication throttling. (Status Code: 429, Error Code: ThrottlingException)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureThrottling` | 短時間に DB への接続リクエストが多すぎます。IAM DB 認証のスロットリング制限は、1 秒あたり 200 接続です。 | IAM 認証を使用して新しい接続を確立する速度を下げます。確立された接続をアプリケーションで再利用するには、RDS Proxy を使用して接続プールを実装することを検討してください。 |
| `[ERROR] Failed to authorize the connection request for user db_user due to an internal IAM DB authentication error. (Status Code: 500, Error Code: InternalError)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureThrottling` | IAM DB 認証で DB 接続を許可中に内部エラーが発生しました。 | https://aws.amazon.com/premiumsupport/ に連絡して問題を調査してください。 |
# Amazon Aurora のアイデンティティおよびアクセスのトラブルシューティング
次の情報は、Aurora と IAM の使用に伴って発生する可能性がある一般的な問題の診断や修復に役立ちます。
**Topics**
+ [Aurora でアクションを実行する権限がありません。](#security_iam_troubleshoot-no-permissions)
+ [iam:PassRole を実行する権限がない](#security_iam_troubleshoot-passrole)
+ [自分の AWS アカウントの外部のユーザーに Aurora リソースへのアクセスを許可したい](#security_iam_troubleshoot-cross-account-access)
## Aurora でアクションを実行する権限がありません。
AWS マネジメントコンソール から、アクションを実行する権限がないと通知された場合は、管理者に問い合わせてサポートを依頼する必要があります。管理者は、サインイン認証情報を提供した担当者です。
以下の例のエラーは、`mateojackson` ユーザーがコンソールを使用して、*ウィジェット*の詳細を表示しようとしましたが、`rds:GetWidget` アクセス許可がない場合に発生します。
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: rds:GetWidget on resource: my-example-widget
```
この場合、Mateo は、`my-example-widget` アクションを使用して `rds:GetWidget` リソースにアクセスできるように、ポリシーの更新を管理者に依頼します。
## iam:PassRole を実行する権限がない
`iam:PassRole` アクションを実行する権限がないというエラーが表示された場合、管理者にお問い合わせ、サポートを依頼する必要があります。管理者は、サインイン認証情報を提供した担当者です。Aurora にロールを渡すことができるようにポリシーを更新するよう、管理者に依頼します。
一部の AWS サービスでは、新しいサービスロールまたはサービスにリンクされたロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
以下の例のエラーは、`marymajor` という名前のユーザーがコンソールを使用して Aurora でアクションを実行しようとした場合に発生します。ただし、アクションには、サービスロールによってサービスに許可が付与されている必要があります。Mary には、ロールをサービスに渡す許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary は `iam:PassRole` アクションの実行が許可されるように、担当の管理者にポリシーの更新を依頼します。
## 自分の AWS アカウントの外部のユーザーに Aurora リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください。
+ Aurora でこれらの機能がサポートされるかどうかを確認するには、「[Amazon Aurora と IAM の連携](security_iam_service-with-iam.md)」を参照してください。
+ 所有している AWS アカウント全体のリソースへのアクセス権を提供する方法については、*IAM ユーザーガイド*の「[所有している別の AWS アカウントへのアクセス権を IAM ユーザーに提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)」を参照してください。
+ リソースへのアクセスをサードパーティーの AWS アカウントに提供する方法については、 *IAM ユーザーガイド*の[サードパーティーが所有する AWS アカウントへのアクセスの提供](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)を参照してください。
+ ID フェデレーションを介してアクセスを提供する方法については、[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)の*外部で認証されたユーザー (ID フェデレーション) へのアクセスの許可*を参照してください。
+ クロスアカウントアクセスでのロールとリソースベースのポリシーの使用の違いの詳細については、*IAM ユーザーガイド*の[IAM ロールとリソースベースのポリシーとの相違点](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)を参照してください。