# Amazon RDS でのセキュリティ
AWS ではクラウドのセキュリティが最優先事項です。AWS のお客様はセキュリティを最も重視する組織の要件を満たすように構築されたデータセンターとネットワークアーキテクチャから利点を得られます。
セキュリティは、AWS とお客様の間の共有責任です。[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)では、この責任がクラウド*の*セキュリティおよびクラウド*内*のセキュリティとして説明されています。
+ **クラウドのセキュリティ** - 「AWS」は、「AWS」クラウドで「AWS」のサービスを実行するインフラストラクチャを保護する責任を負います。また、「AWS」は、使用するサービスを安全に提供します。[「AWS」 コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)の一環として、サードパーティーの監査が定期的にセキュリティの有効性をテストおよび検証しています。Amazon RDS (Aurora) に適用するコンプライアンスプログラムの詳細については、「[コンプライアンスプログラムによる AWS 対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。
+ **クラウド内のセキュリティ** - お客様の責任は使用する AWS のサービスによって決まります。また、お客様は、お客様のデータの機密性、組織の要件、および適用可能な法律および規制などの他の要因についても責任を担います。
このドキュメントは、Amazon RDS を使用する際に共有責任モデルを適用する方法を理解するのに役立ちます。以下のトピックでは、セキュリティおよびコンプライアンスの目的を達成するために Amazon RDS を設定する方法を示します。また Amazon RDS リソースのモニタリングやセキュリティ確保に役立つ他の AWS サービスの使用方法についても確認頂けます。
DB インスタンス上の Amazon RDS リソースとデータベースへのアクセスを管理できます。アクセスの管理に使用する方法は、ユーザーが Amazon RDS で実行する必要のあるタスクのタイプによって異なります。
+ Amazon VPC サービスに基づき、仮想プライベートクラウド (VPC) 内で DB インスタンスを実行して、ネットワークアクセス制御を最大限に拡張します。VPC での DB インスタンスの作成の詳細については、「[Amazon VPC と Amazon RDS](USER_VPC.md)」を参照してください。
+ AWS Identity and Access Management (IAM) ポリシーを使用して、どのユーザーが Amazon RDS リソースの管理を許可されるかを決定するアクセス許可を割り当てます。例えば、IAM を使用して、いずれのユーザーが DB インスタンスの作成、情報入手、変更、削除、リソースのタグ付け、セキュリティグループの変更を許可されるかを決定します。
+ セキュリティグループを使用して、どの IP アドレスまたは Amazon EC2 インスタンスが DB インスタンス上のデータベースに接続できるかを制御します。DB インスタンスを初めて作成すると、そのインスタンスのファイアウォールにより、関連付けられるセキュリティグループによって指定されたルールに従ったアクセスを除き、データベースへのアクセスはすべて禁止されます。
+ Db2、MySQL、MariaDB、PostgreSQL、Oracle、または Microsoft SQL Server のデータベースエンジンを実行している DB インスタンスと Secure Socket Layer (SSL) または Transport Layer Security (TLS) の接続を使用します。DB インスタンスで SSL/TLS を使用する方法の詳細については、「[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md)」を参照してください。
+ Amazon RDS 暗号化を使用して、DB インスタンスおよび保管時のスナップショットのセキュリティを確保します。Amazon RDS 暗号化は、業界スタンダードの AES-256 暗号化アルゴリズムを使用して、DB インスタンスをホストしているサーバーでデータを暗号化します。詳細については、「[Amazon RDS リソースの暗号化](Overview.Encryption.md)」を参照してください。
+ Oracle DB インスタンスではネットワーク暗号化と Transparent Data Encryption を使用します。詳細については、「[Oracle ネイティブネットワーク暗号化](Appendix.Oracle.Options.NetworkEncryption.md)」と「[Oracle Transparent Data Encryption](Appendix.Oracle.Options.AdvSecurity.md)」を参照してください。
+ DB エンジンのセキュリティ機能を使用して、DB インスタンスのデータベースにログインできるユーザーを制御します。これらの機能は、データベースがローカルネットワーク上にあるかのように動作します。
**注記**
目的のユースケースに対してのみ、セキュリティを設定する必要があります。Amazon RDS で管理されるプロセス用にセキュリティアクセスを設定する必要はありません。このプロセスには、バックアップの作成、プライマリ DB インスタンスとリードレプリカの間のデータのレプリケートなどがあります。
Amazon RDS リソースや DB インスタンス上のデータベースに対するアクセスの管理の詳細については、以下のトピックを参照してください。
**Topics**
+ [
# Amazon RDS でのデータベース認証
](database-authentication.md)
+ [
# Amazon RDS および AWS Secrets Manager によるパスワード管理
](rds-secrets-manager.md)
+ [
# Amazon RDS でのデータ保護
](DataDurability.md)
+ [
# Amazon RDS での Identity and Access Management
](UsingWithRDS.IAM.md)
+ [
# Amazon RDS でのログ記録とモニタリング
](Overview.LoggingAndMonitoring.md)
+ [
# Amazon RDS のコンプライアンス検証
](RDS-compliance.md)
+ [
# Amazon RDS の耐障害性
](disaster-recovery-resiliency.md)
+ [
# Amazon RDS でのインフラストラクチャセキュリティ
](infrastructure-security.md)
+ [
# Amazon RDS API とインターフェイス VPC エンドポイント (AWS PrivateLink)
](vpc-interface-endpoints.md)
+ [
# Amazon RDS のセキュリティのベストプラクティス
](CHAP_BestPractices.Security.md)
+ [
# セキュリティグループによるアクセス制御
](Overview.RDSSecurityGroups.md)
+ [
# マスターユーザーアカウント権限
](UsingWithRDS.MasterAccounts.md)
+ [
# Amazon RDS のサービスにリンクされたロールの使用
](UsingWithRDS.IAM.ServiceLinkedRoles.md)
+ [
# Amazon VPC と Amazon RDS
](USER_VPC.md)
# Amazon RDS でのデータベース認証
Amazon RDS は、データベースユーザーを認証するいくつかの方法をサポートしています。
パスワード、Kerberos、および IAM データベース認証では、データベースに対する認証にはさまざまな方法が使用されます。したがって、特定のユーザーは、1 つの認証方法のみを使用してデータベースにログインできます。
PostgreSQL の場合は、特定のデータベースのユーザーに対して、次のロール設定の 1 つだけを使用します。
+ IAM データベース認証を使用するには、`rds_iam`ロールをユーザーに割り当てます。
+ Kerberos 認証を使用するには、`rds_ad`ロールをユーザーに割り当てます。
+ パスワード認証を使用するには、`rds_iam` または `rds_ad` ロールをユーザーに割り当てないでください。
ネストされた許可アクセスによって直接的または間接的に PostgreSQL データベースのユーザーに `rds_iam` ロールと `rds_ad` ロールを両方を割り当てないでください。`rds_iam`ロールがマスターユーザーに追加されると、IAM 認証はパスワード認証よりも優先されるため、マスターユーザーは IAM ユーザーとしてログインする必要があります。
**重要**
アプリケーションではマスターユーザーを直接使用しないことを強くお勧めします。代わりに、アプリケーションに必要な最小の特権で作成されたデータベースユーザーを使用するというベストプラクティスに従ってください。
**Topics**
+ [
## パスワード認証
](#password-authentication)
+ [
## IAM データベース認証
](#iam-database-authentication)
+ [
## Kerberos 認証
](#kerberos-authentication)
## パスワード認証
*パスワード認証*を使用すると、データベースがユーザーアカウントのすべての管理を行います。DB エンジンがパスワードを指定するのに必要な正しい句を使用して、`CREATE USER` などの SQL 文でユーザーを作成します。例えば、MySQL の文は `CREATE USER` *名前* `IDENTIFIED BY` *パスワード* となりますが、PostgreSQLでは `CREATE USER` *名前* `WITH PASSWORD` *パスワード* となります。
パスワード認証を使用すると、データベースがユーザーアカウントを制御および認証します。DB エンジンに強力なパスワード管理機能がある場合は、セキュリティを強化できます。ユーザーコミュニティが小規模である場合は、パスワード認証を使用すると、データベース認証が管理しやすくなります。この場合、クリアテキストパスワードが生成されるため、AWS Secrets Manager との統合によってセキュリティが強化されます。
Amazon RDS での Secrets Manager の使用の詳細については、「*AWS Secrets Manager ユーザーガイド*」の「[基本シークレットの作成](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html)」と「[サポートされている Amazon RDS データベースのシークレットのローテーション](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets-rds.html)」を参照してください。カスタムアプリケーションにおいてシークレットをプログラムで取得する方法については、*AWS Secrets Manager ユーザーガイド*の「[シークレット値の取得](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html)」を参照してください。
## IAM データベース認証
AWS Identity and Access Management (IAM) データベース認証を使用して、DB インスタンスを認証できます。この認証方法では、DB インスタンスに接続するときにパスワードを使用する必要はありません。代わりに、認証トークンを使用します。
特定の DB エンジンの可用性など、IAM データベース認証の詳細については、「[MariaDB、MySQL、および PostgreSQL の IAM データベース認証](UsingWithRDS.IAMDBAuth.md)」を参照してください。
## Kerberos 認証
Amazon RDS で、Kerberos と Microsoft Active Directory を使用した、データベースユーザーの外部認証がサポートされるようになりました。Kerberos は、ネットワーク経由でパスワードを送信する必要をなくすためにチケットと対称キー暗号化を使用するネットワーク認証プロトコルです。Kerberos は Active Directory に組み込まれており、データベースなどのネットワークリソースに対するユーザー認証を行えるように設計されています。
Amazon RDS での Kerberos と Active Directory のサポートにより、データベースユーザーのシングルサインオンおよび一元化認証という利点が得られます。ユーザー資格情報を Active Directory に保持できます。Active Directory には、複数の DB インスタンスの資格情報を保存し、管理する一元的な場所が用意されています。
セルフマネージド Active Directory の認証情報を使用するには、DB インスタンスが参加している Directory Service for Microsoft Active Directory との信頼関係を確立する必要があります。
RDS for PostgreSQL および RDS for MySQL は、フォレスト全体の認証または選択的認証による一方向および双方向のフォレスト信頼関係をサポートしています。
シナリオによっては、外部信頼関係に Kerberos 認証を設定できます。これには、セルフマネージド Active Directory に追加の設定が必要です。これには、[Kerberos フォレストの検索順序](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/kfso-not-work-in-external-trust-event-is-17)が含まれますが、これらに限定されません。
Microsoft SQL Server および PostgreSQL DB インスタンスは、一方向および双方向のフォレスト信頼関係をサポートしています。Oracle DB インスタンスは、一方向と双方向の外部およびフォレストの信頼関係をサポートしています。詳細については、*Directory Service 管理ガイド*の「[信頼関係を作成する場合](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/setup_trust.html)」を参照してください。
特定の DB エンジンを使用した Kerberos 認証については、以下を参照してください。
+ [RDS for SQL Server による AWS Managed Active Directory の操作](USER_SQLServerWinAuth.md)
+ [Amazon RDS for MySQL での Kerberos 認証の使用](mysql-kerberos.md)
+ [Amazon RDS for Oracle の Kerberos 認証の設定](oracle-kerberos.md)
+ [Amazon RDS for PostgreSQL で Kerberos 認証を使用する](postgresql-kerberos.md)
+ [Amazon RDS for Db2 での Kerberos 認証の使用](db2-kerberos.md) .
**注記**
現在、Kerberos 認証は MariaDB DB インスタンスではサポートされていません。
# Amazon RDS および AWS Secrets Manager によるパスワード管理
Amazon RDS は Secrets Manager と統合して、DB インスタンスとマルチ AZ DB クラスターのマスターユーザーパスワードを管理します。
**Topics**
+ [
## Secrets Manager と Amazon RDS の統合に関する制限事項
](#rds-secrets-manager-limitations)
+ [
## AWS Secrets Manager を使用したマスターユーザーパスワード管理の概要
](#rds-secrets-manager-overview)
+ [
## Secrets Manager でマスターユーザーパスワードを管理する利点
](#rds-secrets-manager-benefits)
+ [
## Secrets Manager の統合に必要なアクセス許可
](#rds-secrets-manager-permissions)
+ [
## RDS によるマスターユーザーパスワードの管理の強化AWS Secrets Manager
](#rds-secrets-manager-auth)
+ [
## Secrets Manager による DB インスタンスのマスターユーザーパスワードの管理
](#rds-secrets-manager-db-instance)
+ [
## Secrets Manager を使用した RDS for Oracle テナントデータベースのマスターユーザーパスワードの管理
](#rds-secrets-manager-tenant)
+ [
## Secrets Manager によるマルチ AZ DB クラスターのマスターユーザーパスワードの管理
](#rds-secrets-manager-db-cluster)
+ [
## DB インスタンスのマスターユーザーパスワードシークレットのローテーション
](#rds-secrets-manager-rotate-db-instance)
+ [
## マルチ AZ DB クラスターのマスターユーザーパスワードシークレットのローテーション
](#rds-secrets-manager-rotate-db-cluster)
+ [
## DB インスタンスのシークレットに関する詳細を表示する
](#rds-secrets-manager-view-db-instance)
+ [
## マルチ AZ DB クラスターのシークレットに関する詳細の表示
](#rds-secrets-manager-view-db-cluster)
+ [
## テナントデータベースのシークレットに関する詳細の表示
](#rds-secrets-manager-view-tenant)
+ [
## 利用可能なリージョンとバージョン
](#rds-secrets-manager-availability)
## Secrets Manager と Amazon RDS の統合に関する制限事項
Secrets Manager によるマスターユーザーパスワードの管理は、以下の機能ではサポートされていません。
+ ソース DB または DB クラスターが Secrets Manager で認証情報を管理する場合のリードレプリカの作成。これは、RDS for SQL Server を除くすべての DB エンジンに適用されます。
+ Amazon RDS ブルー/グリーンデプロイ
+ Amazon RDS Custom
+ Oracle Data Guard のスイッチオーバー
## AWS Secrets Manager を使用したマスターユーザーパスワード管理の概要
AWS Secrets Manager を使用すると、コード内のハードコードされた認証情報 (データベースパスワードを含む) を Secrets Manager への API コールで置き換えて、プログラムでシークレットを取得することができます。Secrets Manager の詳細については、[AWS Secrets Manager ユーザーガイド](https://docs.aws.amazon.com/secretsmanager/latest/userguide/)を参照してください。
データベースシークレットを Secrets Manager に保存すると、AWS アカウント に料金が発生します。料金については、「[AWS Secrets Manager 料金表](https://aws.amazon.com/secrets-manager/pricing)」を参照してください。
次のいずれかのオペレーションを実行するときに、RDS が Amazon RDS DB インスタンスまたはマルチ AZ DB クラスターのマスターユーザーパスワードを Secrets Manager で管理するように指定できます。
+ DB インスタンスを作成する
+ マルチ AZ DB クラスターを作成する
+ RDS for Oracle CDB でテナントデータベースを作成する
+ DB インスタンスの変更
+ マルチ AZ DB クラスターを変更する
+ テナントデータベースを変更する (RDS for Oracle のみ)
+ DB インスタンスを Amazon S3 から復元する
+ DB インスタンスをスナップショットまたはポイントインタイムに復元する (RDS for Oracle のみ)
RDS が Secrets Manager でマスターユーザーパスワードを管理するように指定すると、RDS はパスワードを生成して Secrets Manager に保存します。シークレットを直接操作して、マスターユーザーの認証情報を取得できます。また、カスタマーマネージドキーを指定してシークレットを暗号化したり、Secrets Manager が提供する KMS キーを使用したりすることもできます。
RDS はシークレットの設定を管理し、デフォルトで 7 日ごとにシークレットをローテーションします。ローテーションスケジュールなど、一部の設定を変更できます。Secrets Manager でシークレットを管理する DB インスタンスを削除すると、シークレットとそれに関連するメタデータも削除されます。
シークレット内の認証情報を使用して DB インスタンスまたはマルチ AZ DB クラスターに接続するには、Secrets Manager からシークレットを取得します。詳細については、*AWS Secrets Manager ユーザーガイド*の「[AWS Secrets Manager からのシークレットの取得](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)、[AWS Secrets Manager シークレットの認証情報を使用して SQL データベースに接続する](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_jdbc.html)」を参照してください。
## Secrets Manager でマスターユーザーパスワードを管理する利点
Secrets Manager で RDS マスターユーザーのパスワードを管理することには、次の利点があります。
+ RDS はデータベース認証情報を自動的に生成します。
+ RDS はデータベース認証情報を AWS Secrets Manager に自動的に保存および管理します。
+ RDS は、アプリケーションを変更することなく、データベースの認証情報を定期的にローテーションします。
+ Secrets Manager は、データベースの認証情報を人間のアクセスやプレーンテキスト表示から保護します。
+ Secrets Manager では、データベース接続用のシークレット内のデータベース認証情報を取得できます。
+ Secrets Manager では、IAM を使用してシークレット内のデータベース認証情報へのアクセスをきめ細かく制御できます。
+ 必要に応じて、さまざまな KMS キーを使用して、データベースの暗号化を資格情報の暗号化から分離できます。
+ データベース認証情報の手動管理やローテーションが不要になります。
+ AWS CloudTrail と Amazon CloudWatch を使用すると、データベースの認証情報を簡単にモニタリングできます。
Secrets Manager のメリットの詳細については、「[AWS Secrets Manager ユーザーガイド](https://docs.aws.amazon.com/secretsmanager/latest/userguide/)」を参照してください。
## Secrets Manager の統合に必要なアクセス許可
Secrets Manager の統合に関連するオペレーションを実行するには、ユーザーが必要なアクセス許可を持っている必要があります。必要な特定のリソースの API オペレーションを実行するためのアクセス許可を付与する IAM ポリシーを作成できます。その後、これらのポリシーを、それらのアクセス許可を必要とする IAM アクセス許可セットまたはロールにアタッチできます。詳細については、「[Amazon RDS での Identity and Access Management](UsingWithRDS.IAM.md)」を参照してください。
作成、変更、または復元オペレーションの場合、Amazon RDS が Secrets Manager でマスターユーザーパスワードを管理するように指定するユーザーには、次のオペレーションを実行するアクセス許可が必要です。
+ `kms:DescribeKey`
+ `secretsmanager:CreateSecret`
+ `secretsmanager:TagResource`
`kms:DescribeKey` アクセス許可は、`MasterUserSecretKmsKeyId` のカスタマーマネージドキーにアクセスし、`aws/secretsmanager` を記述するために必要です。
作成、変更、または復元オペレーションの場合、Secrets Manager でシークレットを暗号化するカスタマーマネージドキーを指定するユーザーには、次のオペレーションを実行するアクセス許可が必要です。
+ `kms:Decrypt`
+ `kms:GenerateDataKey`
+ `kms:CreateGrant`
変更オペレーションの場合、Secrets Manager でマスターユーザーパスワードをローテーションするユーザーには、次のオペレーションを実行するアクセス許可が必要です。
+ `secretsmanager:RotateSecret`
## RDS によるマスターユーザーパスワードの管理の強化AWS Secrets Manager
IAM 条件キーを使用して、AWS Secrets Manager のマスターユーザーパスワードの RDS 管理を実施できます。次のポリシーでは、マスターユーザーパスワードが Secrets Manager で RDS によって管理されていない限り、ユーザーが DB インスタンスまたは DB クラスターを作成または復元するまたはテナントデータベースを作成または変更することはできません。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": ["rds:CreateDBInstance", "rds:CreateDBCluster", "rds:RestoreDBInstanceFromS3", "rds:RestoreDBClusterFromS3",
"rds:RestoreDBInstanceFromDBSnapshot", "rds:RestoreDBInstanceToPointInTime", "rds:CreateTenantDatabase",
"rds:ModifyTenantDatabase"],
"Resource": "*",
"Condition": {
"Bool": {
"rds:ManageMasterUserPassword": false
}
}
}
]
}
```
------
**注記**
このポリシーは、作成時に AWS Secrets Manager でのパスワード管理を強制します。ただし、インスタンスを変更することで、Secrets Manager の統合を無効にして、マスターパスワードを手動で設定することができます。
これを防ぐには、ポリシーのアクションブロックに `rds:ModifyDBInstance`、`rds:ModifyDBCluster` を含めます。これにより、Secrets Manager 統合が有効になっていない既存のインスタンスには、以降の変更ができなくなることに注意してください。
IAM ポリシーでの条件キーの使用の詳細については、「[Amazon RDS のポリシー条件キー](security_iam_service-with-iam.md#UsingWithRDS.IAM.Conditions)」および「[ポリシー例: 条件キーの使用](UsingWithRDS.IAM.Conditions.Examples.md)」を参照してください。
## Secrets Manager による DB インスタンスのマスターユーザーパスワードの管理
以下のアクションを実行すると、Secrets Manager でマスターユーザーパスワードの RDS 管理を設定できます。
+ [Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)
+ [Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)
+ [Amazon RDS for MySQL DB インスタンスへのバックアップの復元](MySQL.Procedural.Importing.md)
+ [DB インスタンスへの復元](USER_RestoreFromSnapshot.md) (RDS for Oracle のみ)
+ [Amazon RDS の DB インスタンスを特定の時点に復元する](USER_PIT.md) (RDS for Oracle のみ)
上記のオペレーションは、RDS コンソール、AWS CLI、または RDS API を使用して実行できます。
### コンソール
RDS コンソールで DB インスタンスを作成または変更する手順に従います。
+ [DB インスタンスの作成](USER_CreateDBInstance.md#USER_CreateDBInstance.Creating)
+ [Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)
+ [Amazon S3 から新しい MySQL DB インスタンスにデータをインポートする](MySQL.Procedural.Importing.md#MySQL.Procedural.Importing.PerformingImport)
RDS コンソールを使用してこれらのオペレーションのいずれかを実行する場合、マスターユーザーパスワードを RDS が Secrets Manager で管理するように指定できます。DB インスタンスを作成または復元する場合、**[認証情報設定]** で **[AWS Secrets Manager でマスター認証情報を管理する]** を選択します。DB インスタンスを変更するときは、**[設定]** で **[AWS Secrets Manager でマスター認証情報を管理する]** を選択します。
以下の図は、DB インスタンスを作成または復元するときの **AWS Secrets Manager でマスター認証情報を管理する** 設定の例です。
![\[AWS Secrets Manager でマスター認証情報を管理する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/secrets-manager-credential-settings-db-instance.png)
このオプションを選択すると、RDS はマスターユーザーパスワードを生成し、そのライフサイクル全体を通じて Secrets Manager で管理します。
![\[選択した AWS Secrets Manager マスター認証情報を管理する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/secrets-manager-integration-create-db-instance.png)
シークレットは、Secrets Manager が提供する KMS キーを使用して暗号化するか、自分で作成したカスタマーマネージドキーを使用して暗号化するかを選択できます。RDS で DB インスタンスのデータベース認証情報を管理したら、シークレットの暗号化で使用されている KMS キーを変更することはできません。
要件に合わせて他の設定を選択できます。DB インスタンスの作成時に使用できる設定の詳細については、「[DB インスタンスの設定](USER_CreateDBInstance.Settings.md)」を参照してください。DB インスタンスを変更する際に使用できる設定の詳細については、「[DB インスタンスの設定](USER_ModifyInstance.Settings.md)」を参照してください。
### AWS CLI
Secrets Manager で RDS を使用してマスターユーザーパスワードを管理するには、以下のいずれかの AWS CLI コマンドで `--manage-master-user-password` オプションを指定します。
+ [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)
+ [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)
+ [restore-db-instance-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-s3.html)
+ [restore-db-instance-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html) (RDS for Oracle のみ)
+ [restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html) (RDS for Oracle のみ)
これらのコマンドで `--manage-master-user-password` オプションを指定すると、RDS はマスターユーザーパスワードを生成し、そのライフサイクル全体を通じて Secrets Manager で管理します。
シークレットを暗号化するには、カスタマーマネージドキーを指定するか、Secrets Manager によって提供されるデフォルトの KMS キーを使用できます。`--master-user-secret-kms-key-id` オプションを使用して、カスタマーマネージドキーを指定します。AWS KMS キー識別子は、KMS キーのキー ARN、キー ID、エイリアス ARN、またはエイリアス名です。別の AWS アカウント で KMS キーを使用するには、キー ARN またはエイリアス ARN を指定します。RDS で DB インスタンスのデータベース認証情報を管理したら、シークレットの暗号化で使用されている KMS キーを変更することはできません。
要件に合わせて他の設定を選択できます。DB インスタンスの作成時に使用できる設定の詳細については、「[DB インスタンスの設定](USER_CreateDBInstance.Settings.md)」を参照してください。DB インスタンスを変更するときに使用できる設定の詳細については、「[DB インスタンスの設定](USER_ModifyInstance.Settings.md)」を参照してください。
次の例では DB インスタンスを作成し、RDS が Secrets Manager でマスターユーザーパスワードを管理するように指定します。シークレットは、Secrets Manager によって提供される KMS キーを使用して暗号化されます。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds create-db-instance \
2. --db-instance-identifier mydbinstance \
3. --engine mysql \
4. --engine-version 8.0.39 \
5. --db-instance-class db.r5b.large \
6. --allocated-storage 200 \
7. --master-username testUser \
8. --manage-master-user-password
```
Windows の場合:
```
1. aws rds create-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --engine mysql ^
4. --engine-version 8.0.39 ^
5. --db-instance-class db.r5b.large ^
6. --allocated-storage 200 ^
7. --master-username testUser ^
8. --manage-master-user-password
```
### RDS API
RDS が Secrets Manager のマスターユーザーパスワードを管理するように指定するには、次の RDS API オペレーションのいずれかで `ManageMasterUserPassword` パラメータを `true` に設定します。
+ [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)
+ [ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html)
+ [RestoreDBInstanceFromS3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromS3.html)
+ [RestoreDBInstanceFromSnapshot](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromSnapshot.html) (RDS for Oracle のみ)
+ [RestoreDBInstanceToPointInTime](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html) (RDS for Oracle のみ)
これらのオペレーションのいずれかで `ManageMasterUserPassword` パラメータを `true` に設定すると、RDS はマスターユーザーパスワードを生成し、そのライフサイクル全体を通じて Secrets Manager で管理します。
シークレットを暗号化するには、カスタマーマネージドキーを指定するか、Secrets Manager によって提供されるデフォルトの KMS キーを使用できます。`MasterUserSecretKmsKeyId` パラメータを使用して、カスタマーマネージドキーを指定します。AWS KMS キー識別子は、KMS キーのキー ARN、キー ID、エイリアス ARN、またはエイリアス名です。別の AWS アカウント で KMS キーを使用するには、キー ARN またはエイリアス ARN を指定します。RDS で DB インスタンスのデータベース認証情報を管理したら、シークレットの暗号化で使用されている KMS キーを変更することはできません。
## Secrets Manager を使用した RDS for Oracle テナントデータベースのマスターユーザーパスワードの管理
以下のアクションを実行すると、Secrets Manager でマスターユーザーパスワードの RDS 管理を設定できます。
+ [RDS for Oracle テナントデータベースを CDB インスタンスに追加する](oracle-cdb-configuring.adding.pdb.md)
+ [RDS for Oracle テナントデータベースの変更](oracle-cdb-configuring.modifying.pdb.md)
前述のアクションを実行するために、RDS コンソール、AWS CLI、または RDS API を使用できます。
### コンソール
RDS コンソールで RDS for Oracle テナントデータベースを作成または変更する手順に従います。
+ [RDS for Oracle テナントデータベースを CDB インスタンスに追加する](oracle-cdb-configuring.adding.pdb.md)
+ [RDS for Oracle テナントデータベースの変更](oracle-cdb-configuring.modifying.pdb.md)
RDS コンソールを使用して前述のオペレーションのいずれかを実行する場合、RDS が Secrets Manager でマスターユーザーパスワードを管理するように指定できます。テナントデータベースを作成するときは、**[認証情報設定]** の **[AWS Secrets Manager でマスター認証情報を管理する]** を選択します。テナントデータベースを変更する場合は、**[設定]** で **[AWS Secrets Manager でマスター認証情報を管理する]** を選択します。
以下の図は、テナントデータベースを作成するときの **[AWS Secrets Manager でマスター認証情報を管理する]** 設定の例です。
![\[AWS Secrets Manager でマスター認証情報を管理する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/secrets-manager-credential-settings-db-instance.png)
このオプションを選択すると、RDS はマスターユーザーパスワードを生成し、そのライフサイクル全体を通じて Secrets Manager で管理します。
![\[選択した AWS Secrets Manager マスター認証情報を管理する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/secrets-manager-integration-create-db-instance.png)
シークレットは、Secrets Manager が提供する KMS キーを使用して暗号化するか、自分で作成したカスタマーマネージドキーを使用して暗号化するかを選択できます。RDS でテナントデータベースのデータベース認証情報を管理したら、シークレットの暗号化で使用されている KMS キーを変更することはできません。
要件に合わせて他の設定を選択できます。テナントデータベースの作成時に使用できる設定の詳細については、「[DB インスタンスの設定](USER_CreateDBInstance.Settings.md)」を参照してください。テナントデータベースの変更時に利用できる設定の詳細については、「[DB インスタンスの設定](USER_ModifyInstance.Settings.md)」を参照してください。
### AWS CLI
Secrets Manager で RDS を使用してマスターユーザーパスワードを管理するには、以下のいずれかの AWS CLI コマンドで `--manage-master-user-password` オプションを指定します。
+ [create-tenant-database](https://docs.aws.amazon.com/cli/latest/reference/rds/create-tenant-database.html)
+ [modify-tenant-database](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-tenant-database.html)
前述のコマンドで `--manage-master-user-password` オプションを指定すると、RDS はマスターユーザーパスワードを生成し、そのライフサイクル全体を通じて Secrets Manager で管理します。
シークレットを暗号化するには、カスタマーマネージドキーを指定するか、Secrets Manager によって提供されるデフォルトの KMS キーを使用できます。`--master-user-secret-kms-key-id` オプションを使用して、カスタマーマネージドキーを指定します。AWS KMS キー識別子は、KMS キーのキー ARN、キー ID、エイリアス ARN、またはエイリアス名です。別の AWS アカウント で KMS キーを使用するには、キー ARN またはエイリアス ARN を指定します。RDS でテナントデータベースのデータベース認証情報を管理したら、シークレットの暗号化で使用されている KMS キーを変更することはできません。
要件に合わせて他の設定を選択できます。テナントデータベースの作成時に使用可能な設定の詳細については、「[create-tenant-database](https://docs.aws.amazon.com/cli/latest/reference/rds/create-tenant-database.html)」を参照してください。テナントデータベースを変更するときに使用できる設定の詳細については、「[modify-tenant-database](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-tenant-database.html)」を参照してください。
次の例では、RDS for Oracle テナントデータベースを作成し、RDS が Secrets Manager でマスターユーザーパスワードを管理するように指定します。シークレットは、Secrets Manager によって提供される KMS キーを使用して暗号化されます。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds create-tenant-database --region us-east-1 \
2. --db-instance-identifier my-cdb-inst \
3. --tenant-db-name mypdb2 \
4. --master-username mypdb2-admin \
5. --character-set-name UTF-16 \
6. --manage-master-user-password
```
Windows の場合:
```
1. aws rds create-tenant-database --region us-east-1 ^
2. --db-instance-identifier my-cdb-inst ^
3. --tenant-db-name mypdb2 ^
4. --master-username mypdb2-admin ^
5. --character-set-name UTF-16 ^
6. --manage-master-user-password
```
### RDS API
RDS が Secrets Manager のマスターユーザーパスワードを管理するように指定するには、次の RDS API オペレーションのいずれかで `ManageMasterUserPassword` パラメータを `true` に設定します。
+ [CreateTenantDatabase](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateTenantDatabase.html)
+ [ModifyTenantDatabase](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyTenantDatabase.html)
これらのオペレーションのいずれかで `ManageMasterUserPassword` パラメータを `true` に設定すると、RDS はマスターユーザーパスワードを生成し、そのライフサイクル全体を通じて Secrets Manager で管理します。
シークレットを暗号化するには、カスタマーマネージドキーを指定するか、Secrets Manager によって提供されるデフォルトの KMS キーを使用できます。`MasterUserSecretKmsKeyId` パラメータを使用して、カスタマーマネージドキーを指定します。AWS KMS キー識別子は、KMS キーのキー ARN、キー ID、エイリアス ARN、またはエイリアス名です。別の AWS アカウント で KMS キーを使用するには、キー ARN またはエイリアス ARN を指定します。RDS でテナントデータベースのデータベース認証情報を管理したら、シークレットの暗号化で使用されている KMS キーを変更することはできません。
## Secrets Manager によるマルチ AZ DB クラスターのマスターユーザーパスワードの管理
以下のアクションを実行すると、Secrets Manager でマスターユーザーパスワードの RDS 管理を設定できます。
+ [Amazon RDS 用のマルチ AZ DB クラスターの作成](create-multi-az-db-cluster.md)
+ [Amazon RDS のマルチ AZ DB クラスターの変更](modify-multi-az-db-cluster.md)
これらのアクションを実行するには、RDS コンソール、AWS CLI、または RDS API を使用できます。
### コンソール
RDS コンソールを使用してマルチ AZ DB クラスターを作成または変更する手順に従います。
+ [DB クラスターの作成](create-multi-az-db-cluster.md#create-multi-az-db-cluster-creating)
+ [Amazon RDS のマルチ AZ DB クラスターの変更](modify-multi-az-db-cluster.md)
RDS コンソールを使用してこれらのオペレーションのいずれかを実行する場合、マスターユーザーパスワードが RDS で Secrets Manager で管理されるように指定できます。これを行うには、DB クラスターを作成ときに、**[Credential settings]** (認証情報設定) で **[Manage master credentials in AWS Secrets Manager]** ( でマスター認証情報を管理する) を選択します。DB クラスターを変更する場合は、**[Settings]** (設定) で **[Manage master credentials in AWS Secrets Manager]** ( でマスター認証情報を管理する) を選択します。
以下の図は、DB インスタンスを作成またはときの **AWS Secrets Managerでマスター認証情報を管理する**設定の例です。
![\[AWS Secrets Manager でマスター認証情報を管理する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/secrets-manager-credential-settings.png)
このオプションを選択すると、RDS はマスターユーザーパスワードを生成し、そのライフサイクル全体を通じて Secrets Manager で管理します。
![\[選択した AWS Secrets Manager マスター認証情報を管理する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/secrets-manager-integration-create.png)
シークレットは、Secrets Manager が提供する KMS キーを使用して暗号化するか、自分で作成したカスタマーマネージドキーを使用して暗号化するかを選択できます。RDS が DB クラスターのデータベース認証情報を管理した後は、シークレットの暗号化に使用される KMS キーを変更することはできません。
要件に合わせて他の設定を選択できます。
各 マルチ AZ DB クラスターの作成時に使用できる設定の詳細については、「[マルチ AZ DB クラスターを作成するための設定](create-multi-az-db-cluster.md#create-multi-az-db-cluster-settings)」を参照してください。マルチ AZ DB クラスターの変更時に利用できる設定の詳細については、「[マルチ AZ DB クラスターの変更の設定](modify-multi-az-db-cluster.md#modify-multi-az-db-cluster-settings)」を参照してください。
### AWS CLI
RDS が Secrets Manager のマスターユーザーパスワードを管理するように指定するには、以下のいずれかの `--manage-master-user-password` コマンドでオプションを指定します。
+ [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)
+ [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)
これらのコマンドで `--manage-master-user-password` オプションを指定すると、RDS はマスターユーザーパスワードを生成し、そのライフサイクル全体を通じて Secrets Manager で管理します。
シークレットを暗号化するには、カスタマーマネージドキーを指定するか、Secrets Manager によって提供されるデフォルトの KMS キーを使用できます。`--master-user-secret-kms-key-id` オプションを使用して、カスタマーマネージドキーを指定します。AWS KMS キー識別子は、KMS キーのキー ARN、キー ID、エイリアス ARN、またはエイリアス名です。別の AWS アカウント で KMS キーを使用するには、キー ARN またはエイリアス ARN を指定します。RDS が DB クラスターのデータベース認証情報を管理した後は、シークレットの暗号化に使用される KMS キーを変更することはできません。
要件に合わせて他の設定を選択できます。
各 マルチ AZ DB クラスターの作成時に使用できる設定の詳細については、「[マルチ AZ DB クラスターを作成するための設定](create-multi-az-db-cluster.md#create-multi-az-db-cluster-settings)」を参照してください。マルチ AZ DB クラスターの変更時に利用できる設定の詳細については、「[マルチ AZ DB クラスターの変更の設定](modify-multi-az-db-cluster.md#modify-multi-az-db-cluster-settings)」を参照してください。
この例では、マルチ AZ DB クラスターを作成し、RDS が Secrets Manager でパスワードを管理するように指定しています。シークレットは、Secrets Manager によって提供される KMS キーを使用して暗号化されます。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds create-db-cluster \
2. --db-cluster-identifier mysql-multi-az-db-cluster \
3. --engine mysql \
4. --engine-version 8.0.39 \
5. --backup-retention-period 1 \
6. --allocated-storage 4000 \
7. --storage-type io1 \
8. --iops 10000 \
9. --db-cluster-instance-class db.r6gd.xlarge \
10. --master-username testUser \
11. --manage-master-user-password
```
Windows の場合:
```
1. aws rds create-db-cluster ^
2. --db-cluster-identifier mysql-multi-az-db-cluster ^
3. --engine mysql ^
4. --engine-version 8.0.39 ^
5. --backup-retention-period 1 ^
6. --allocated-storage 4000 ^
7. --storage-type io1 ^
8. --iops 10000 ^
9. --db-cluster-instance-class db.r6gd.xlarge ^
10. --master-username testUser ^
11. --manage-master-user-password
```
### RDS API
RDS が Secrets Manager のマスターユーザーパスワードを管理するように指定するには、次のいずれかのオペレーションで `ManageMasterUserPassword` パラメータを `true` に設定します。
+ [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html)
+ [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
これらのオペレーションのいずれかで `ManageMasterUserPassword` パラメータを `true` に設定すると、RDS はマスターユーザーパスワードを生成し、そのライフサイクル全体を通じて Secrets Manager で管理します。
シークレットを暗号化するには、カスタマーマネージドキーを指定するか、Secrets Manager によって提供されるデフォルトの KMS キーを使用できます。`MasterUserSecretKmsKeyId` パラメータを使用して、カスタマーマネージドキーを指定します。AWS KMS キー識別子は、KMS キーのキー ARN、キー ID、エイリアス ARN、またはエイリアス名です。別の AWS アカウント で KMS キーを使用するには、キー ARN またはエイリアス ARN を指定します。RDS が DB クラスターのデータベース認証情報を管理した後は、シークレットの暗号化に使用される KMS キーを変更することはできません。
## DB インスタンスのマスターユーザーパスワードシークレットのローテーション
RDS がマスターユーザーパスワードシークレットをローテーションすると、Secrets Manager は既存のシークレットの新しいシークレットバージョンを生成します。新しいバージョンのシークレットには、新しいマスターユーザーパスワードが含まれています。Amazon RDS は DB インスタンスのマスターユーザーパスワードを、新しいシークレットバージョンのパスワードと一致するように変更します。
スケジュールされたローテーションを待つ代わりに、シークレットをすぐにローテーションできます。Secrets Manager でマスターユーザーのパスワードシークレットを更新するには、DB インスタンスを変更します。DB インスタンスの変更の詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
RDS コンソール、AWS CLI、または RDS API を使用して、マスターユーザーのパスワードシークレットをすぐに更新できます。新しいパスワードは常に 28 文字で、少なくとも 1 つの大文字と小文字、1 つの数字、1 つの句読点が含まれます。
### コンソール
RDS コンソールを使用してマスターユーザーのパスワードシークレットをローテーションするには、DB インスタンスを変更し、**[Settings]** (設定) で **[Rotate secret immediately]** (シークレットを直ちにローテーションする) を選択します。
![\[マスターユーザーパスワードシークレットをすぐにローテーションする\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/secrets-manager-integration-rotate.png)
[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md) の RDS コンソールで DB インスタンスを変更する手順に従います。確認ページで **[Apply immediately]** (すぐに適用) を選択する必要があります。
### AWS CLI
AWS CLI を使用してマスターユーザーパスワードシークレットをローテーションするには、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) コマンドを使用して `--rotate-master-user-password` オプションを指定します。マスターパスワードをローテーションするときは、`--apply-immediately` オプションを指定する必要があります。
この例では、マスターユーザーパスワードシークレットをローテーションします。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds modify-db-instance \
2. --db-instance-identifier mydbinstance \
3. --rotate-master-user-password \
4. --apply-immediately
```
Windows の場合:
```
1. aws rds modify-db-instance ^
2. --db-instance-identifier mydbinstance ^
3. --rotate-master-user-password ^
4. --apply-immediately
```
### RDS API
[ModifyDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) オペレーションを使用して `RotateMasterUserPassword` パラメータを `true` に設定すると、マスターユーザーパスワードシークレットをローテーションできます。マスターパスワードを変更するときは、`ApplyImmediately` パラメータを `true` に設定する必要があります。
## マルチ AZ DB クラスターのマスターユーザーパスワードシークレットのローテーション
RDS がマスターユーザーパスワードシークレットをローテーションすると、Secrets Manager は既存のシークレットの新しいシークレットバージョンを生成します。新しいバージョンのシークレットには、新しいマスターユーザーパスワードが含まれています。Amazon RDS は、マルチ AZ DB クラスターのマスターユーザーパスワードを、新しいシークレットバージョンのパスワードと一致するように変更します。
スケジュールされたローテーションを待つ代わりに、シークレットをすぐにローテーションできます。Secrets Manager でマスターユーザーパスワードシークレットをローテーションするには、マルチ AZ DB クラスターを変更します。マルチ AZ DB クラスターの変更については、「[Amazon RDS のマルチ AZ DB クラスターの変更](modify-multi-az-db-cluster.md)」を参照してください。
RDS コンソール、AWS CLI、または RDS API を使用して、マスターユーザーのパスワードシークレットをすぐに更新できます。新しいパスワードは常に 28 文字で、少なくとも 1 つの大文字と小文字、1 つの数字、1 つの句読点が含まれます。
### コンソール
RDS コンソールを使用してマスターユーザーパスワードシークレットをローテーションするには、マルチ AZ DB クラスターを変更し、**[Settings]** (設定) で **[Rotate secret immediately]** (シークレットを直ちにローテーションする) を選択します。
![\[マスターユーザーパスワードシークレットをすぐにローテーションする\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/secrets-manager-integration-rotate-taz-cluster.png)
RDS コンソールを使用して、[Amazon RDS のマルチ AZ DB クラスターの変更](modify-multi-az-db-cluster.md) および のマルチ AZ DB クラスターを変更する手順に従います。確認ページで **[Apply immediately]** (すぐに適用) を選択する必要があります。
### AWS CLI
AWS CLI を使用してマスターユーザーパスワードシークレットをローテーションするには、[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) コマンドを使用して `--rotate-master-user-password` オプションを指定します。マスターパスワードをローテーションするときは、`--apply-immediately` オプションを指定する必要があります。
この例では、マスターユーザーパスワードシークレットをローテーションします。
**Example**
Linux、macOS、Unix の場合:
```
1. aws rds modify-db-cluster \
2. --db-cluster-identifier mydbcluster \
3. --rotate-master-user-password \
4. --apply-immediately
```
Windows の場合:
```
1. aws rds modify-db-cluster ^
2. --db-cluster-identifier mydbcluster ^
3. --rotate-master-user-password ^
4. --apply-immediately
```
### RDS API
[ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) オペレーションを使用して `RotateMasterUserPassword` パラメータを `true` に設定すると、マスターユーザーパスワードシークレットをローテーションできます。マスターパスワードを変更するときは、`ApplyImmediately` パラメータを `true` に設定する必要があります。
## DB インスタンスのシークレットに関する詳細を表示する
コンソール ([https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)) または AWS CLI ([get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) Secrets Manager コマンド) を使用して自分のシークレットを取得できます。
RDS によって管理されているシークレットの Amazon リソースネーム (ARN) は、RDS コンソール、AWS CLI、または RDS API の Secrets Manager で確認できます。
### コンソール
**RDS で管理されているシークレットの詳細を Secrets Manager で表示するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**データベース** を選択します。
1. DB インスタンスの名前を選択して、その詳細を表示します。
1. **[設定]** タブを選択します。
**[Master Credentials ARN]** (マスター認証情報の ARN) では、シークレット ARN を表示できます。
![\[RDS が管理するシークレットの詳細を Secrets Manager で表示する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/secrets-manager-integration-view-instance.png)
**[Manage in Secrets Manager]** (Secrets Managerで管理) で管理リンクをクリックすると、Secrets Manager コンソールでシークレットを表示および管理できます。
### AWS CLI
[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) RDS CLI コマンドを使用すると、Secrets Manager で RDS によって管理されているシークレットに関する次の情報を検索できます。
+ `SecretArn` – シークレットの ARN
+ `SecretStatus` – シークレットのステータス
設定可能なステータス値は以下のとおりです。
+ `creating` – シークレットは作成中です。
+ `active` – シークレットは通常の使用とローテーションで利用可能です。
+ `rotating` – シークレットはローテーション中です。
+ `impaired` - シークレットはデータベースの認証情報へのアクセスに使用できますが、ローテーションはできません。例えば、アクセス許可が変更されて RDS がシークレットやシークレットの KMS キーにアクセスできなくなった場合、シークレットがこのステータスになる可能性があります。
シークレットのステータスがこの場合は、ステータスの原因となった状態を修正できます。ステータスの原因となった条件を修正すると、ステータスは次のローテーションまで `impaired` のままです。または、DB インスタンスを変更してデータベース認証情報の自動管理をオフにしてから、DB インスタンスを再度変更してデータベース認証情報の自動管理をオンにすることもできます。DB インスタンスを変更するには、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) コマンドの `--manage-master-user-password` オプションを使用します。
+ `KmsKeyId` – シークレットの暗号化に使用する KMS キーの ARN。
特定の DB インスタンスの出力を表示する `--db-instance-identifier` オプションを指定します。この例は、DB インスタンスが使用するシークレットの出力を示しています。
**Example**
```
1. aws rds describe-db-instances --db-instance-identifier mydbinstance
```
シークレットの出力例は次のとおりです。
```
"MasterUserSecret": {
"SecretArn": "arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!db-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx",
"SecretStatus": "active",
"KmsKeyId": "arn:aws:kms:eu-west-1:123456789012:key/0987dcba-09fe-87dc-65ba-ab0987654321"
}
```
シークレット ARN がある場合は、[get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) Secrets Manager CLI コマンドを使用してシークレットの詳細を表示できます。
この例は、前のサンプル出力のシークレットの詳細を示しています。
**Example**
Linux、macOS、Unix の場合:
```
aws secretsmanager get-secret-value \
--secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!db-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx'
```
Windows の場合:
```
aws secretsmanager get-secret-value ^
--secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!db-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx'
```
### RDS API
RDS で管理されているシークレットの ARN、ステータス、および KMS キーを Secrets Manager で表示するには、[DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) オペレーションを使用し、`DBInstanceIdentifier` パラメータを DB インスタンス識別子に設定します。シークレットの詳細は、出力に含まれています。
シークレット ARN がある場合は、[GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) Secrets Manager オペレーションを使用してシークレットの詳細を表示できます。
## マルチ AZ DB クラスターのシークレットに関する詳細の表示
コンソール ([https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)) または AWS CLI ([get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) Secrets Manager コマンド) を使用して自分のシークレットを取得できます。
RDS によって管理されているシークレットの Amazon リソースネーム (ARN) は、RDS コンソール、AWS CLI、または RDS API の Secrets Manager で確認できます。
### コンソール
**RDS が管理するシークレットの詳細を Secrets Manager で表示する**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**データベース** を選択します。
1. 詳細を表示する マルチ AZ DB クラスターの名前を選択します。
1. **[設定]** タブを選択します。
**[Master Credentials ARN]** (マスター認証情報の ARN) では、シークレット ARN を表示できます。
![\[RDS が管理するシークレットの詳細を Secrets Manager で表示する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/secrets-manager-integration-view-taz-cluster.png)
**[Manage in Secrets Manager]** (Secrets Managerで管理) で管理リンクをクリックすると、Secrets Manager コンソールでシークレットを表示および管理できます。
### AWS CLI
RDS AWS CLI [describe-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) コマンドを使用すると、Secrets Manager で RDS によって管理されているシークレットに関する次の情報を検索できます。
+ `SecretArn` – シークレットの ARN
+ `SecretStatus` – シークレットのステータス
設定可能なステータス値は以下のとおりです。
+ `creating` – シークレットは作成中です。
+ `active` – シークレットは通常の使用とローテーションで利用可能です。
+ `rotating` – シークレットはローテーション中です。
+ `impaired` - シークレットはデータベースの認証情報へのアクセスに使用できますが、ローテーションはできません。例えば、アクセス許可が変更されて RDS がシークレットやシークレットの KMS キーにアクセスできなくなった場合、シークレットがこのステータスになる可能性があります。
シークレットのステータスがこの場合は、ステータスの原因となった状態を修正できます。ステータスの原因となった条件を修正すると、ステータスは次のローテーションまで `impaired` のままです。または、DB クラスターを変更してデータベース認証情報の自動管理をオフにしてから、DB クラスターを再度変更してデータベース認証情報の自動管理をオンにすることもできます。DB クラスターを変更するには、[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) コマンドの `--manage-master-user-password` を使用します。
+ `KmsKeyId` – シークレットの暗号化に使用する KMS キーの ARN。
特定の DB クラスターの出力を表示する `--db-cluster-identifier` オプションを指定します。この例は、DB クラスターが使用するシークレットの出力を示しています。
**Example**
```
1. aws rds describe-db-clusters --db-cluster-identifier mydbcluster
```
以下は、シークレットの出力例を示しています。
```
"MasterUserSecret": {
"SecretArn": "arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx",
"SecretStatus": "active",
"KmsKeyId": "arn:aws:kms:eu-west-1:123456789012:key/0987dcba-09fe-87dc-65ba-ab0987654321"
}
```
シークレット ARN がある場合は、[get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) Secrets Manager CLI コマンドを使用してシークレットの詳細を表示できます。
この例は、前のサンプル出力のシークレットの詳細を示しています。
**Example**
Linux、macOS、Unix の場合:
```
aws secretsmanager get-secret-value \
--secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx'
```
Windows の場合:
```
aws secretsmanager get-secret-value ^
--secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx'
```
### RDS API
RDS によって管理されているシークレットの ARN、ステータス、および KMS キーは、[DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) RDS オペレーションを使用して Secrets Manager で表示し、`DBClusterIdentifier` パラメータを DB クラスター識別子に設定できます。シークレットの詳細は、出力に含まれています。
シークレット ARN がある場合は、[GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) Secrets Manager オペレーションを使用してシークレットの詳細を表示できます。
## テナントデータベースのシークレットに関する詳細の表示
コンソール ([https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)) または AWS CLI ([get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) Secrets Manager コマンド) を使用して自分のシークレットを取得できます。
AWS Secrets Manager の Amazon RDS によって管理されているシークレットの Amazon リソースネーム (ARN) は、Amazon RDS コンソール、AWS CLI、または Amazon RDS API にあります。
### コンソール
**テナントデータベースの AWS Secrets Manager で Amazon RDS によって管理されるシークレットの詳細を表示するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**データベース** を選択します。
1. テナントデータベースを含む DB インスタンスの名前を選択して、その詳細を表示します。
1. **[設定]** タブを選択します。
**テナントデータベース**セクションで、テナントデータベースを検索し、**マスター認証情報の ARN** を表示します。
**[Manage in Secrets Manager]** (Secrets Managerで管理) で管理リンクをクリックすると、Secrets Manager コンソールでシークレットを表示および管理できます。
### AWS CLI
[describe-tenant-databases](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-tenant-databases.html) Amazon RDS AWS CLI コマンドを使用して、テナントデータベースの AWS Secrets Manager で Amazon RDS によって管理されるシークレットに関する次の情報を検索できます。
+ `SecretArn` – シークレットの ARN
+ `SecretStatus` – シークレットのステータス
設定可能なステータス値は以下のとおりです。
+ `creating` – シークレットは作成中です。
+ `active` – シークレットは通常の使用とローテーションで利用可能です。
+ `rotating` – シークレットはローテーション中です。
+ `impaired` - シークレットはデータベースの認証情報へのアクセスに使用できますが、ローテーションはできません。例えば、アクセス許可が変更されて Amazon RDS がシークレットやシークレットの KMS キーにアクセスできなくなった場合、シークレットがこのステータスになる可能性があります。
シークレットのステータスがこの場合は、ステータスの原因となった状態を修正できます。ステータスの原因となった条件を修正すると、ステータスは次のローテーションまで `impaired` のままです。または、テナントデータベースを変更してデータベース認証情報の自動管理をオフにしてから、テナントデータベースを再度変更してデータベース認証情報の自動管理をオンにすることもできます。テナントデータベースを変更するには、[modify-tenant-database](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-tenant-database.html) コマンドで `--manage-master-user-password` オプションを使用します。
+ `KmsKeyId` – シークレットの暗号化に使用する KMS キーの ARN。
特定の DB インスタンスにあるテナントデータベースの出力を表示するには、`--db-instance-identifier` オプションを指定します。特定のテナントデータベースの出力を表示する `--tenant-db-name` オプションを指定することもできます。この例は、テナントデータベースが使用するシークレットの出力を示しています。
**Example**
```
1. aws rds describe-tenant-databases \
2. --db-instance-identifier database-3 \
3. --query "TenantDatabases[0].MasterUserSecret"
```
シークレットの出力例は次のとおりです。
```
{
"SecretArn": "arn:aws:secretsmanager:us-east-2:123456789012:secret:rds!db-ABC123",
"SecretStatus": "active",
"KmsKeyId": "arn:aws:kms:us-east-2:123456789012:key/aa11bb22-####-####-####-fedcba123456"
}
```
シークレット ARN がある場合は、[get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) Secrets Manager コマンドを使用してシークレットの詳細を表示できます。
この例は、前のサンプル出力のシークレットの詳細を示しています。
**Example**
Linux、macOS、Unix の場合:
```
aws secretsmanager get-secret-value \
--secret-id 'arn:aws:secretsmanager:us-east-2:123456789012:secret:rds!db-ABC123'
```
Windows の場合:
```
aws secretsmanager get-secret-value ^
--secret-id 'arn:aws:secretsmanager:us-east-2:123456789012:secret:rds!db-ABC123'
```
### Amazon RDS API
AWS Secrets Manager で Amazon RDS によって管理されているシークレットの ARN、ステータス、および KMS キーを表示するには、[DescribeTenantDatabases](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeTenantDatabases.html) オペレーションを使用し、`DBInstanceIdentifier` パラメータを DB インスタンス識別子に設定します。`TenantDBName` パラメータを特定のテナントデータベース名に設定することもできます。シークレットの詳細は、出力に含まれています。
シークレット ARN がある場合は、[GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) Secrets Manager オペレーションを使用してシークレットの詳細を表示できます。
## 利用可能なリージョンとバージョン
機能の可用性とサポートは、各データベースエンジンの特定のバージョンと AWS リージョン によって異なります。Secrets Manager を Amazon RDS と統合した場合のバージョンとリージョンの可用性の詳細については、「[Secrets Manager と Amazon RDS の統合でサポートされているリージョンと DB エンジン](Concepts.RDS_Fea_Regions_DB-eng.Feature.SecretsManager.md)」を参照してください。
# Amazon RDS でのデータ保護
AWS [責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)は、Amazon Relational Database Service のデータ保護に適用されます。このモデルで説明されているように、AWS は、AWS クラウド のすべてを実行するグローバルインフラストラクチャを保護する責任を担います。ユーザーは、このインフラストラクチャでホストされるコンテンツに対する管理を維持する責任があります。また、使用する「AWS のサービス」のセキュリティ設定と管理タスクもユーザーの責任となります。データプライバシーの詳細については、[データプライバシーに関するよくある質問](https://aws.amazon.com/compliance/data-privacy-faq/)を参照してください。欧州でのデータ保護の詳細については、*AWS セキュリティブログ*に投稿された [AWS 責任共有モデルおよび GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) のブログ記事を参照してください。
データを保護するため、「AWS アカウント」 認証情報を保護し、「AWS IAM アイデンティティセンター」 または 「AWS Identity and Access Management」 (IAM) を使用して個々のユーザーをセットアップすることをお勧めします。この方法により、それぞれのジョブを遂行するために必要な権限のみが各ユーザーに付与されます。また、次の方法でデータを保護することもお勧めします:
+ 各アカウントで多要素認証 (MFA) を使用します。
+ SSL/TLS を使用して 「AWS」 リソースと通信します。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ AWS CloudTrail で API とユーザーアクティビティロギングを設定します。CloudTrail 証跡を使用して AWS アクティビティをキャプチャする方法については、「*AWS CloudTrail ユーザーガイド*」の「[CloudTrail 証跡の使用](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)」を参照してください。
+ AWS のサービス 内のすべてのデフォルトセキュリティコントロールに加え、AWS 暗号化ソリューションを使用します。
+ Amazon Macie などの高度な管理されたセキュリティサービスを使用します。これらは、Amazon S3 に保存されている機密データの検出と保護を支援します。
+ コマンドラインインターフェイスまたは API を使用して 「AWS」 にアクセスする際に FIPS 140-3 検証済みの暗号化モジュールが必要な場合は、FIPS エンドポイントを使用します。利用可能な FIPS エンドポイントの詳細については、「[連邦情報処理規格 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)」を参照してください。
お客様の E メールアドレスなどの極秘または機密情報を、タグ、または **[名前]** フィールドなどの自由形式のテキストフィールドに含めないことを強くお勧めします。これには、コンソール、API、AWS CLI、または AWS SDK を使用して Amazon RDS またはその他の AWS のサービス で作業する場合が含まれます。タグ、または名前に使用される自由記述のテキストフィールドに入力したデータは、請求または診断ログに使用される場合があります。外部サーバーに URL を提供する場合、そのサーバーへのリクエストを検証できるように、認証情報を URL に含めないことを強くお勧めします。
**Topics**
+ [
# 暗号化を使用したデータの保護
](Encryption.md)
+ [
# ネットワーク間のトラフィックのプライバシー
](inter-network-traffic-privacy.md)
# 暗号化を使用したデータの保護
データベースリソースの暗号化を有効にすることができます。また、DB インスタンスへの接続を暗号化することもできます。
**Topics**
+ [
# Amazon RDS リソースの暗号化
](Overview.Encryption.md)
+ [
# AWS KMS key 管理
](Overview.Encryption.Keys.md)
+ [
# SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化
](UsingWithRDS.SSL.md)
+ [
# SSL/TLS 証明書のローテーション
](UsingWithRDS.SSL-certificate-rotation.md)
# Amazon RDS リソースの暗号化
Amazon RDS は、Amazon RDS DB インスタンスを暗号化することができます。保管中に暗号化されるデータには、DB インスタンス、ログ、自動バックアップ、リードレプリカ、スナップショットの基本的なストレージが含まれます。
Amazon RDS の暗号化された DB インスタンスでは、Amazon RDS DB インスタンスをホストしているサーバーでデータを暗号化するために、業界標準の AES-256 暗号化アルゴリズムを使用します。
データが暗号化されると、Amazon RDS はパフォーマンスの影響を最小限に抑えながら、データへのアクセスと復号の認証を透過的に処理します。暗号化を使用するために、データベースのクライアントアプリケーションを変更する必要はありません。
**注記**
暗号化された/されていない DB インスタンスのでは、AWS リージョン間でレプリケートする場合でも、ソースとリードレプリカ間で送信されるデータは暗号化されます。
**Topics**
+ [
## Amazon RDS リソースの暗号化の概要
](#Overview.Encryption.Overview)
+ [
## DB インスタンスの暗号化
](#Overview.Encryption.Enabling)
+ [
## DB インスタンスの暗号化が有効になっているかの判別
](#Overview.Encryption.Determining)
+ [
## Amazon RDS の暗号化の可用性
](#Overview.Encryption.Availability)
+ [
## 転送中の暗号化
](#Overview.Encryption.InTransit)
+ [
## Amazon RDS の暗号化された DB インスタンスの制限事項
](#Overview.Encryption.Limitations)
## Amazon RDS リソースの暗号化の概要
Amazon RDS の暗号化された DB インスタンスは、基になるストレージへの不正アクセスからデータを保護することによって、データ保護の追加レイヤーを提供します。Amazon RDS の暗号化を使用して、クラウドにデプロイされるアプリケーションのデータ保護を強化することや、保管時のデータ暗号化に関するコンプライアンスの要件を達成することができます。 Amazon RDS の暗号化された DB インスタンスでは、すべてのログ、バックアップ、スナップショットが暗号化されます。暗号化の可用性と制限の詳細については、「[Amazon RDS の暗号化の可用性](#Overview.Encryption.Availability)」および「[Amazon RDS の暗号化された DB インスタンスの制限事項](#Overview.Encryption.Limitations)」を参照してください。
Amazon RDS は、これらのリソースを暗号化するために AWS Key Management Service キーを使用します。AWS KMS は、安全で可用性の高いハードウェアとソフトウェアを組み合わせて、クラウド向けに拡張されたキー管理システムを提供します。AWS マネージドキー を使用することも、カスタマーマネージドキーを作成することもできます。
暗号化された DB インスタンスを作成するときは、カスタマーマネージドキーまたは Amazon RDS の AWS マネージドキー を選択して、DB インスタンスを暗号化できます。カスタマーマネージドキーのキー識別子を指定しない場合、Amazon RDS は新しい DB インスタンスに AWS マネージドキー を使用します。Amazon RDS は、Amazon RDS 用の AWS マネージドキー を AWS アカウントに作成します。AWS アカウントには、AWS リージョンごとに Amazon RDS の AWS マネージドキー が別々にあります。
Amazon RDS リソースの暗号化と復号に使用するカスタマーマネージドキーを管理するには、[AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/).を使用します。
AWS KMS を使用して、カスタマーマネージドキーを作成し、これらのカスタマーマネージドキーの使用を制御するポリシーを定義できます。AWS KMS は CloudTrail をサポートしているため、KMS キーの使用状況を監査して、カスタマーマネージドキーが適切に使用されていることを確認できます。カスタマーマネージドキーは、Amazon Aurora およびサポートされている AWS のサービス (Amazon S3、Amazon EBS、Amazon Redshift など) で使用できます。AWS KMS と統合しているサービスのリストについては、「[AWS サービス統合](https://aws.amazon.com/kms/features/#AWS_Service_Integration)」を参照ください。KMS キーの使用に関する考慮事項:
+ 暗号化された DB インスタンスを作成したら、その DB インスタンスで使用されている KMS キーを変更することはできません。したがって、暗号化された DB インスタンスを作成する前に、KMS キーの要件を必ず確認してください。
DB インスタンスの暗号化キーを変更する必要がある場合は、インスタンスの手動スナップショットを作成し、スナップショットのコピー中に暗号化を有効にします。詳細については、[re:Post 情報センターの記事](https://repost.aws/knowledge-center/update-encryption-key-rds)を参照してください。
+ 暗号化されたスナップショットをコピーする場合、ソーススナップショットの暗号化に使用した KMS キーとは異なる KMS キーを使用して、ターゲットスナップショットを暗号化できます。
+ また、Amazon RDS の暗号化されたインスタンスのリードレプリカとプライマリ DB インスタンスの両方が同じ AWS リージョンにある場合、リードレプリカはプライマリ DB インスタンスと同じ KMS キーを使用して暗号化する必要があります。
+ プライマリ DB インスタンスとリードレプリカが異なる AWS リージョンにある場合には、その AWS リージョンの KMS キー を使用してリードレプリカを暗号化します。
+ スナップショットを共有する AWS アカウントの AWS マネージドキー を使って暗号化されたスナップショットを共有することはできません。
+ Amazon RDS は、Transparent Data Encryption (TDE) による Oracle または SQL Server の DB インスタンスの暗号化もサポートします。TDE は、RDS 保管時の暗号化とともに使用できますが、TDE と RDS 保管時の暗号化を同時に使用すると、データベースのパフォーマンスに若干影響する可能性があります。個々の暗号化方式ごとに異なるキーを管理する必要があります。TDE の詳細については「[Oracle Transparent Data Encryption](Appendix.Oracle.Options.AdvSecurity.md)」または「[SQL サーバーの透過的なデータの暗号化サポート](Appendix.SQLServer.Options.TDE.md)」を参照してください。
**重要**
KMS キーを無効にすると、Amazon RDS は DB インスタンス用の KMS キーにアクセスできなくなります。KMS キーへのアクセスを失った場合、バックアップが有効になっているインスタンスでは、暗号化された DB インスタンスは検出から 2 時間後に `inaccessible-encryption-credentials-recoverable` 状態になります。DB インスタンスは 7 日間この状態のままであり、その間、インスタンスは停止します。この間に DB インスタンスに対して行われた API コールは成功しない場合があります。DB インスタンスを復旧するには、KMS キーを有効にして、この DB インスタンスを再起動します。AWS マネジメントコンソール、AWS CLI、または RDS API から KMS キーを有効にします。AWS CLI コマンド [start-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/start-db-instance.html) または AWS マネジメントコンソール を使用して DB インスタンスを再起動します。
`inaccessible-encryption-credentials-recoverable` 状態は、停止できる DB インスタンスにのみ適用されます。この回復可能な状態は、リードレプリカやリードレプリカを持つインスタンスなど、停止できないインスタンスには適用されません。詳細については、「[DB インスタンスの停止に関する制限事項](USER_StopInstance.md#USER_StopInstance.Limitations)」を参照してください。
DB インスタンスが 7 日以内に復旧されない場合、終了 `inaccessible-encryption-credentials` 状態になります。この状態では、DB インスタンスは使用できなくなり、バックアップからのみ DB インスタンスを復元できます。データベース内の暗号化されたデータの消失を防ぐために、暗号化された DB インスタンスのバックアップは常に有効にしておくことを強くお勧めします。
DB インスタンスの作成中に、Amazon RDS は呼び出し元のプリンシパルが KMS キーにアクセスできるかどうかを確認し、DB インスタンスの存続期間全体に使用する KMS キーから許可を生成します。呼び出し元のプリンシパルの KMS キーへのアクセス権を取り消しても、実行中のデータベースには影響しません。スナップショットを別のアカウントにコピーするなど、クロスアカウントシナリオで KMS キーを使用する場合は、KMS キーを他のアカウントと共有する必要があります。別の KMS キーを指定せずにスナップショットから DB インスタンスを作成すると、新しいインスタンスはソースアカウントの KMS キーを使用します。DB インスタンスの作成後にキーへのアクセス権を取り消しても、インスタンスには影響しません。ただし、キーを無効にすると、そのキーで暗号化されたすべての DB インスタンスに影響します。これを防ぐには、スナップショットのコピー操作時に別のキーを指定します。
バックアップが無効化されている DB インスタンスは、インスタンスの変更または復旧中にボリュームがホストからデタッチされるまで使用できます。RDS は、該当する場合、インスタンスを `inaccessible-encryption-credentials-recoverable` 状態または `inaccessible-encryption-credentials` 状態に移行します。
KMS キーの詳細については、「AWS Key Management Service デベロッパーガイド**」の「[AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys)」と「[AWS KMS key 管理](Overview.Encryption.Keys.md)」を参照してください。
## DB インスタンスの暗号化
新しい DB インスタンスを暗号化するには、Amazon RDS コンソールで **[Enable encryption]** (暗号を有効化) を選択します。DB インスタンスの作成については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
AWS CLI の [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) コマンドを使用して、暗号化された DB インスタンスを作成するには、`--storage-encrypted` パラメータを設定します。[CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) API オペレーションを使用する場合は、`StorageEncrypted` パラメータを true に設定します。
AWS CLI `create-db-instance` コマンドを使用して、カスタマーマネージドキーで暗号化された DB インスタンスを作成する場合は、`--kms-key-id` パラメータを KMS キーの任意のキー識別子に設定します。Amazon RDS API `CreateDBInstance` オペレーションを使用する場合は、`KmsKeyId` パラメータを KMS キーの任意のキー識別子に設定します。カスタマーマネージドキーを別の AWS アカウントで使用するには、キー ARN またはエイリアス ARN を指定します。
## DB インスタンスの暗号化が有効になっているかの判別
AWS マネジメントコンソール、AWS CLI、または RDS API を使用して、DB インスタンスの保存時の暗号化が有効になっているか判別できます。
### コンソール
**DB インスタンスに対して保存時の暗号化がオンになっているかどうかを判別します**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[データベース]** を選択します。
1. 詳細を表示するためにチェックする DB インスタンスの名前を選択します。
1. **設定**タブを選択し、**ストレージ**下にある**暗号化** 値 をチェックします。
**有効**または**無効**のいずれかが表示されています。
![\[DB インスタンスの保管時の暗号化のチェック\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/encryption-check-db-instance.png)
### AWS CLI
AWS CLI を使用して DB インスタンスの保存時の暗号化が有効になっているかを判断するには、以下のオプションで [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) コマンドを呼び起こします:
+ `--db-instance-identifier` - DB インスタンスの名前です。
次の例では、`mydb` DB インスタンスの保管時の暗号化に関して `TRUE` または `FALSE` の いずれかを返すクエリを使用しています。
**Example**
```
1. aws rds describe-db-instances --db-instance-identifier mydb --query "*[].{StorageEncrypted:StorageEncrypted}" --output text
```
### RDS API
Amazon RDS API を使用して DB インスタンスの保管時の暗号化が有効であるかを判断するには、以下のパラメータで [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) オペレーションを呼び起こします:
+ `DBInstanceIdentifier` - DB インスタンスの名前です。
## Amazon RDS の暗号化の可用性
Amazon RDS 暗号化は、現在すべてのデータベースエンジンおよびストレージタイプに使用できます。
Amazon RDS 暗号化は、ほとんどの DB インスタンスクラスで使用できます。次の表は、Amazon RDS 暗号化を*サポートしていない* DB インスタンスクラスの一覧です。
| インスタンスタイプ | インスタンスクラス |
| --- | --- |
| 汎用 (M1) | db.m1.small db.m1.medium db.m1.large db.m1.xlarge |
| メモリ最適化 (M2) | db.m2.xlarge db.m2.2xlarge db.m2.4xlarge |
| バースト可能 (T2) | db.t2.micro |
## 転送中の暗号化
**物理レイヤーでの暗号化**
AWS グローバルネットワーク上の AWS リージョンを流れるすべてのデータは、AWS の安全な施設を離れる前に、物理層で自動的に暗号化されます。AZ 間のトラフィックはすべて暗号化されます。追加的な暗号化レイヤーでは、このセクションに記載されているもの以外にも、保護が提供されている場合があります。
**Amazon VPC ピアリングおよび Transit Gateway のクロスリージョンピアリング接続によって得られる暗号化**
Amazon VPC およびTransit Gateway のピアリング接続を使用する、すべてのクロスリージョントラフィックは、リージョンからの送信時に自動的に一括で暗号化されます。すべてのトラフィックにおける物理レイヤーには、そのトラフィックが AWS の保護された設備を離れる前に、追加の暗号化レイヤーが自動的に提供されています。
**インスタンス間での暗号化**
AWS では、すべてのタイプの DB インスタンス間において安全でプライベートな接続を提供しています。さらに、一部のインスタンスタイプでは、基盤となる Nitro System ハードウェアのオフロード機能を使用して、インスタンス間の転送中のトラフィックを自動的に暗号化します。この暗号化では、256 ビットの暗号化による関連データによる認証暗号化 (AEAD) アルゴリズムを使用します。ネットワークのパフォーマンスには影響しません。インスタンス間でこの追加の転送中トラフィック暗号化をサポートするには、次の要件を満たす必要があります。
+ インスタンスは、次のインスタンスタイプを使用します。
+ **汎用**: M6i、M6id、M6in、M6idn、M7g
+ **メモリ最適化**: R6i、R6id、R6in、R6idn、R7g、X2idn、X2iedn、X2iezn
+ 各インスタンスは同じ AWS リージョンにあるものとします。
+ 各インスタンスは同じ VPC 内、あるいはピア接続された VPC 内にあり、トラフィックは仮想ネットワークのデバイスもしくはサービス (ロードバランサーや Transit Gateway など) を通過しないものとします。
## Amazon RDS の暗号化された DB インスタンスの制限事項
Amazon RDS の暗号化された DB インスタンスには、以下の制限事項があります。
+ Amazon RDS DB インスタンスは、DB インスタンスの作成時にのみ暗号化できます。作成後には暗号化できません。
ただし、暗号化されていないスナップショットのコピーは暗号化できるので、暗号化されていない DB インスタンスに効果的に暗号化を追加できます。つまり、DB インスタンスのスナップショットを作成し、そのスナップショットの暗号化済みコピーを作成します。この暗号化されたスナップショットから DB インスタンスを復元することで、元の DB インスタンスの暗号化されたコピーを作成できます。詳しくは、「[Amazon RDS の DB スナップショットのコピー](USER_CopySnapshot.md)」を参照してください。
+ 暗号化された DB インスタンスの暗号化をオフにすることはできません。
+ 暗号化されていない DB インスタンスの暗号化されたスナップショットを作成することはできません。
+ 暗号化された DB インスタンスのスナップショットは、DB インスタンスと同じ KMS キーを使用して暗号化する必要があります。
+ 暗号化されていない DB インスタンスのリードレプリカを暗号化することや、暗号化されている DB インスタンスのリードレプリカを暗号化しないようにすることはできません。
+ 暗号化されたリードレプリカとソース DB インスタンスの両方が同じ AWS リージョンにある場合、リードレプリカはソース DB インスタンスと同じ KMS キーで暗号化する必要があります。
+ 暗号化されていないバックアップやスナップショットを、暗号化された DB インスタンスに復元することはできません。
+ ある AWS リージョンから別のリージョンに暗号化されたスナップショットをコピーするには、送信先 AWS リージョンの KMS キーを指定する必要があります。これは、KMS キーが、作成される AWS リージョンに固有のものであるためです。
ソーススナップショットはコピープロセス全体で暗号化されたままになります。Amazon RDSは、コピー処理中にエンベロープ暗号化を使用してデータを保護します。エンベロープ暗号化の仕組みの詳細については、*AWS Key Management Service デベロッパーガイド*の「[エンベロープ暗号化](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)」を参照してください。
+ 暗号化された DB インスタンスの暗号化を解除することはできません。ただし、暗号化された DB インスタンスからデータをエクスポートし、暗号化されていない DB インスタンスにデータをインポートすることはできます。
# AWS KMS key 管理
Amazon RDS には、キー管理のために [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/) が自動的に統合されます。Amazon RDS では、エンベロープ暗号化が使用されます。エンベロープ暗号化の仕組みの詳細については、*AWS Key Management Service デベロッパーガイド*の「[エンベロープ暗号化](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping)」を参照してください。
2 種類の AWS KMS キーを使用して、DB インスタンスを暗号化できます。
+ KMS キーに対するフル制御の権限が必要な場合は、*カスタマーマネージドキー*を作成する必要があります。カスタマーマネージドキーの詳細については、*AWS Key Management Service デベロッパーガイド*の「[Customer managed keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk)」を参照してください。
+ *AWS マネージドキー* は、お客様のアカウントにある KMS キーであり、AWS KMS と統合されている AWS のサービスがお客様に代わって作成し、管理し、使用します。デフォルトでは、RDS AWS マネージドキー (`aws/rds`) が暗号化に使用されます。RDS AWS マネージドキー の管理、ローテーション、削除はできません。AWS マネージドキー の詳細については、「*AWS Key Management Service Developer Guide*」の「[AWS マネージドキー](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) 」を参照してください。
Amazon RDS の暗号化された DB インスタンスに使用される KMS キーを管理するには、[AWS KMS コンソール](https://console.aws.amazon.com/kms)の [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/)、AWS CLI、または AWS KMS API を使用します。AWS マネージドキーまたはカスタマーマネージドキーで実行された、すべてのアクションの監査ログを表示するには、[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/) を使用します。キーのローテーションの詳細については、「[AWS KMS キーのローテーション](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)」を参照してください。
## カスタマーマネージドキーの使用の承認
RDS が暗号化オペレーションでカスタマーマネージドキーを使用すると、RDS リソースを作成または変更するユーザーに代わって動作します。
カスタマーマネージドキーを使用して、RDS リソースを作成するには、カスタマーマネージドキーで次の操作を呼び出すためのアクセス許可がユーザーに必要になります。
+ `kms:CreateGrant`
+ `kms:DescribeKey`
これらの必要なアクセス許可は、キーポリシーか、キーポリシーで許可されている場合は IAM ポリシーで指定できます。
**重要**
Amazon RDS などのマネージドサービスを使用する AWS KMS キーポリシーですべてのリソース (\$1) に明示的な拒否ステートメントを使用する場合は、リソース所有アカウントを許可する条件を指定する必要があります。拒否ルールに IAM ユーザーの例外が含まれている場合でも、この条件なしで操作が失敗することがあります。
**ヒント**
最小権限のプリンシパルに従うには、`kms:CreateGrant` へのフルアクセスを許可しないでください。代わりに、ユーザーに代わって AWS サービスによって許可が作成された場合にのみ、[kms:ViaService 条件キー](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service)を使用して、ユーザーが KMS キーに許可を作成できるようにします。
さまざまな方法で、IAM ポリシー をより厳しくすることができます。例えば、RDS から発信されるリクエストにのみカスタマーマネージドキーの使用を許可する場合、`rds..amazonaws.com` 値を指定して [kms:ViaService 条件キー](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service)を使用します。また、暗号化にカスタマーマネージドキーを使用する条件として、[Amazon RDS 暗号化コンテキスト](#Overview.Encryption.Keys.encryptioncontext) でキーまたは値を使用することもできます。
詳細については、「*AWS Key Management Service デベロッパーガイド*」の「[他のアカウントのユーザーに KMS キーの使用を許可する](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html)」と「[AWS KMS のキーポリシー](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies)」を参照してください。
## Amazon RDS 暗号化コンテキスト
RDS が KMS キーを使用する場合、または Amazon EBS が RDS の代わりに KMS キーを使用する場合、サービスは[暗号化コンテキスト](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context)を指定します。暗号化コンテキストは、データの整合性を保証するために AWS KMS で使用される[追加の認証データ](https://docs.aws.amazon.com/crypto/latest/userguide/cryptography-concepts.html#term-aad) (AAD) です。暗号化オペレーションで暗号化コンテキストを指定すると、サービスは復号オペレーションでも同じ暗号化コンテキストを指定する必要があります。そうしないと、復号は失敗します。暗号化コンテキストは [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) ログにも書き込まれるため、特定の KMS キーが使用された理由を理解するのに役立ちます。CloudTrail ログには KMS キーの使用を説明する多くのエントリが含まれている場合があります。各ログエントリの暗号化コンテキストは、その特定の使用理由を判断するのに役立ちます。
少なくとも Amazon RDS は、次の JSON 形式の例のように、暗号化コンテキストに DB インスタンス ID を常に使用します。
```
{ "aws:rds:db-id": "db-CQYSMDPBRZ7BPMH7Y3RTDG5QY" }
```
この暗号化コンテキストにより、KMS キーが使用された DB インスタンスを識別することができます。
KMS キーが特定の DB インスタンスと特定の Amazon EBS ボリュームに使用されると、次の JSON 形式の例のように、DB インスタンス ID と Amazon EBS ボリューム ID の両方が暗号化コンテキストに使用されます。
```
{
"aws:rds:db-id": "db-BRG7VYS3SVIFQW7234EJQOM5RQ",
"aws:ebs:id": "vol-ad8c6542"
}
```
# SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化
アプリケーションで Secure Socket Layer (SSL) または Transport Layer Security (TLS) を使用することで、Db2、MariaDB、Microsoft SQL Server、MySQL、Oracle、または PostgreSQL を実行するデータベースへの接続を暗号化できます。
SSL/TLS 接続は、クライアントと DB インスタンスまたはクラスターの間を移動するデータを暗号化することによって、1 つのセキュリティ層を提供します。オプションで、データベースにインストールされたサーバー証明書を検証することで、SSL/TLS 接続でサーバー ID 検証を実行できます。サーバーの ID 検証を必須にするには、次の一般的な手順に従ってください。
1. データベースの **DB サーバー証明書**に署名する**認証局 (CA)** を選択します。認証局の詳細については、「[認証局](#UsingWithRDS.SSL.RegionCertificateAuthorities)」を参照してください。
1. データベースに接続するときに使用する証明書バンドルをダウンロードします。証明書バンドルをダウンロードするには、「[AWS リージョン による証明書バンドル](#UsingWithRDS.SSL.CertificatesAllRegions)」を参照してください。
**注記**
証明書はすべて、SSL/TLS 接続を使用したダウンロードでのみ使用可能です。
1. DB エンジンのプロセスで、SSL/TLS Connect を実装するプロセスで、データベースに接続します。各 DB エンジンには SSL/TLS を実装する独自のプロセスがあります。ご使用のデータベースの SSL/TLS の実装方法については、ご使用の DB エンジンに対応する以下のリンクを使用してください。
+ [Amazon RDS for Db2 DB インスタンスでの SSL/TLS の使用](Db2.Concepts.SSL.md)
+ [Amazon RDS 上の MariaDB DB インスタンスの SSL/TLS サポート](MariaDB.Concepts.SSLSupport.md)
+ [Microsoft SQL Server DB インスタンスでの SSL の使用](SQLServer.Concepts.General.SSL.Using.md)
+ [Amazon RDS 上の MySQL DB インスタンスの SSL/TLS サポート](MySQL.Concepts.SSLSupport.md)
+ [RDS for Oracle DB インスタンスでの SSL の使用](Oracle.Concepts.SSL.md)
+ [PostgreSQL DB インスタンスで SSL を使用する](PostgreSQL.Concepts.General.SSL.md)
## 認証局
**認証局 (CA)** は、証明書チェーンの最上位にあるルート CA を識別する証明書です。CA は、各 DB インスタンスにインストールされているサーバー証明書である、**DB インスタンス証明書**に署名します。DB サーバー証明書は DB インスタンスを信頼できるサーバーとして識別します。
![\[認証局の概要\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/certificate-authority-overview.png)
Amazon RDS にはデータベース用の DB サーバー証明書に署名するための、以下の CA が用意されています。
****
| 認証局 (CA) | 説明 | 共通名 (CN) |
| --- | --- | --- |
| rds-ca-rsa2048-g1 | 大半の AWS リージョン では、RSA 2048 プライベートキーアルゴリズムと SHA256 署名アルゴリズムを備えた認証局を使用します。 AWS GovCloud (US) Regions では、CA が RSA 2048 プライベートキーアルゴリズムと SHA384 署名アルゴリズムを備えた認証局を使用します。 この CA はサーバー証明書の自動ローテーションをサポートします。 | Amazon RDS region-identifier ルート CA RSA2048 G1 |
| rds-ca-rsa4096-g1 | RSA 4096 プライベートキーアルゴリズムと SHA384 署名アルゴリズムを備えた認証局を使用します。この CA はサーバー証明書の自動ローテーションをサポートします。 | Amazon RDS region-identifier ルート CA RSA4096 G1 |
| rds-ca-ecc384-g1 | ECC 384 プライベートキーアルゴリズムと SHA384 署名アルゴリズムを備えた認証局を使用します。この CA はサーバー証明書の自動ローテーションをサポートします。 | Amazon RDS region-identifier ルート CA ECC384 G1 |
**注記**
AWS CLI を使用している場合は、[describe-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html) を使用して、上記の認証局の有効性を確認できます。
これらの CA 証明書は、地域およびグローバル証明書バンドルに含まれています。rds-ca-rsa2048-g1、rds-ca-rsa4096-g1、または rds-ca-ecc384-g1 CA をデータベースで使用すると、RDS はデータベース上で DB サーバー証明書を管理します。RDS は、DB サーバーの証明書の有効期限が切れる前に証明書のローテーションを行います。
### データベースに CA を設定する
データベースの CA は、以下のタスクの実行時に設定できます。
+ DB インスタンスまたはマルチ AZ DB クラスターの作成 - DB インスタンスまたはクラスターを作成する際に CA を設定できます。手順については、「[Amazon RDS DB インスタンスの作成](USER_CreateDBInstance.md)」または「[Amazon RDS 用のマルチ AZ DB クラスターの作成](create-multi-az-db-cluster.md)」を参照してください。
+ DB インスタンスまたはマルチ AZ DB クラスターの変更 – DB インスタンスまたはクラスターを変更することで CA を設定できます。手順については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」または「[Amazon RDS のマルチ AZ DB クラスターの変更](modify-multi-az-db-cluster.md)」を参照してください。
**注記**
デフォルトの CA は rds-ca-rsa2048-g1 に設定されています。[modify-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html) コマンドを使用して、AWS アカウント のデフォルト CA をオーバーライドできます。
使用可能な CA は、DB エンジンと DB エンジンのバージョンによって異なります。AWS マネジメントコンソール を使用するとき、次の図に示すように、**認証局**の設定を使用して CA を選択できます。
![\[認証局のオプション\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/certificate-authority.png)
コンソールには、DB エンジンおよび DB エンジンのバージョンで利用可能な CA のみが表示されます。AWS CLI を使用しているとき、[create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) コマンドまたは [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) コマンドを使用して DB インスタンスの CA を設定できます。マルチ AZ DB クラスターの CA は、[create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) コマンドまたは [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) コマンドを使用して指定できます。
AWS CLI を使用しているとき、[describe-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html) コマンドを使用して、アカウントで使用可能な CA を確認できます。このコマンドでは、出力内の `ValidTill` に各 CA の有効期限も表示されます。[describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) コマンドを使用すると、特定の DB エンジンと DB エンジンのバージョンで使用できる CA を検索できます。
次の例は、PostgreSQL DB エンジンのバージョンのデフォルト RDS で使用できる CA を示しています。
```
aws rds describe-db-engine-versions --default-only --engine postgres
```
以下のような出力が生成されます。使用可能な CA は `SupportedCACertificateIdentifiers` に記載されます。出力には、DB エンジンのバージョンで、`SupportsCertificateRotationWithoutRestart` の再起動なしで証明書のローテーションがサポートされるかどうかも表示されます。
```
{
"DBEngineVersions": [
{
"Engine": "postgres",
"MajorEngineVersion": "13",
"EngineVersion": "13.4",
"DBParameterGroupFamily": "postgres13",
"DBEngineDescription": "PostgreSQL",
"DBEngineVersionDescription": "PostgreSQL 13.4-R1",
"ValidUpgradeTarget": [],
"SupportsLogExportsToCloudwatchLogs": false,
"SupportsReadReplica": true,
"SupportedFeatureNames": [
"Lambda"
],
"Status": "available",
"SupportsParallelQuery": false,
"SupportsGlobalDatabases": false,
"SupportsBabelfish": false,
"SupportsCertificateRotationWithoutRestart": true,
"SupportedCACertificateIdentifiers": [
"rds-ca-rsa2048-g1",
"rds-ca-ecc384-g1",
"rds-ca-rsa4096-g1"
]
}
]
}
```
### DB サーバーの証明書の有効性
DB サーバー証明書の有効性は、DB エンジンのバージョンと、DB エンジンのバージョンによって異なります。DB エンジンのバージョンで、DB エンジンのバージョンで、DB サーバーのローテーションがサポートされる場合、DB サーバーの証明書の有効期間は 1 年です。それ以外の場合、有効期間は 3 年間です。
DB サーバー証明書ローテーションの詳細については、「[サーバー証明書の自動ローテーション](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation)」を参照してください。
### DB インスタンスの CA の表示
データベースの CA に関する詳細を確認するには、次の画像のように、コンソール内の **[接続とセキュリティ]** タブを表示します。
![\[認証局の詳細\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/certificate-authority-details.png)
AWS CLI を使用している場合は、[describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) コマンドを使用して DB インスタンスの CA の詳細を表示できます。マルチ AZ DB クラスターの CA の詳細は、[describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) コマンドを使用して確認できます。
## Amazon RDS の証明書バンドルをダウンロードする
SSL または TLS を使用してデータベースに接続する場合、データベースインスタンスには Amazon RDS からの信頼証明書が必要です。次の表の適切なリンクを選択して、データベースをホストする AWS リージョン に対応するバンドルをダウンロードします。
### AWS リージョン による証明書バンドル
すべての AWS リージョンおよび GovCloud (米国) リージョンの証明書バンドルには、次のルート CA 証明書が含まれています。
+ `rds-ca-rsa2048-g1`
+ `rds-ca-rsa4096-g1`
+ `rds-ca-ecc384-g1`
`rds-ca-rsa4096-g1` および `rds-ca-ecc384-g1` 証明書は、以下のリージョンでは使用できません。
+ アジアパシフィック (ムンバイ)
+ アジアパシフィック (メルボルン)
+ カナダ西部 (カルガリー)
+ 欧州 (チューリッヒ)
+ 欧州 (スペイン)
+ イスラエル (テルアビブ)
アプリケーション信頼ストアでは、ルート CA 証明書の登録のみが必要です。RDS が DB サーバー証明書を自動的にローテーションするときに接続の問題が発生する可能性があるため、中間 CA 証明書を信頼ストアに登録しないでください。
**注記**
Amazon RDS Proxy は AWS Certificate Manager (ACM) の証明書を使用します。RDS Proxy を使用している場合は、Amazon RDS 証明書をダウンロードしたり、RDS Proxy 接続を使用するアプリケーションを更新したりする必要はありません。詳細については、「[RDS Proxy での TLS/SSL の使用](rds-proxy.howitworks.md#rds-proxy-security.tls)」を参照してください。
AWS リージョン の証明書バンドルをダウンロードするには、次の表で、データベースをホストする AWS リージョン のリンクを選択します。
| **AWS リージョン** | **証明書バンドル (PEM)** | **証明書バンドル (PKCS7)** |
| --- | --- | --- |
| 商用 AWS リージョン | [global-bundle.pem](https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem) | [global-bundle.p7b](https://truststore.pki.rds.amazonaws.com/global/global-bundle.p7b) |
| 米国東部 (バージニア北部) | [us-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.pem) | [us-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.p7b) |
| 米国東部 (オハイオ) | [us-east-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-east-2/us-east-2-bundle.pem) | [us-east-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-east-2/us-east-2-bundle.p7b) |
| 米国西部 (北カリフォルニア) | [us-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-west-1/us-west-1-bundle.pem) | [us-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-west-1/us-west-1-bundle.p7b) |
| 米国西部 (オレゴン) | [us-west-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-west-2/us-west-2-bundle.pem) | [us-west-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-west-2/us-west-2-bundle.p7b) |
| アフリカ (ケープタウン) | [af-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/af-south-1/af-south-1-bundle.pem) | [af-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/af-south-1/af-south-1-bundle.p7b) |
| アジアパシフィック (香港) | [ap-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-east-1/ap-east-1-bundle.pem) | [ap-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-east-1/ap-east-1-bundle.p7b) |
| アジアパシフィック (ハイデラバード) | [ap-south-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-south-2/ap-south-2-bundle.pem) | [ap-south-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-south-2/ap-south-2-bundle.p7b) |
| アジアパシフィック (ジャカルタ) | [ap-southeast-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-3/ap-southeast-3-bundle.pem) | [ap-southeast-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-3/ap-southeast-3-bundle.p7b) |
| アジアパシフィック (マレーシア) | [ap-southeast-5-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-5/ap-southeast-5-bundle.pem) | [ap-southeast-5-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-5/ap-southeast-5-bundle.p7b) |
| アジアパシフィック (メルボルン) | [ap-southeast-4-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-4/ap-southeast-4-bundle.pem) | [ap-southeast-4-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-4/ap-southeast-4-bundle.p7b) |
| アジアパシフィック (ムンバイ) | [ap-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-south-1/ap-south-1-bundle.pem) | [ap-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-south-1/ap-south-1-bundle.p7b) |
| アジアパシフィック (大阪) | [ap-northeast-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-3/ap-northeast-3-bundle.pem) | [ap-northeast-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-3/ap-northeast-3-bundle.p7b) |
| アジアパシフィック (タイ) | [ap-southeast-7-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-7/ap-southeast-7-bundle.pem) | [ap-southeast-7-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-7/ap-southeast-7-bundle.p7b) |
| アジアパシフィック (東京) | [ap-northeast-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.pem) | [ap-northeast-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.p7b) |
| アジアパシフィック (ソウル) | [ap-northeast-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-2/ap-northeast-2-bundle.pem) | [ap-northeast-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-2/ap-northeast-2-bundle.p7b) |
| アジアパシフィック (シンガポール) | [ap-southeast-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-1/ap-southeast-1-bundle.pem) | [ap-southeast-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-1/ap-southeast-1-bundle.p7b) |
| アジアパシフィック (シドニー) | [ap-southeast-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-2/ap-southeast-2-bundle.pem) | [ap-southeast-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-2/ap-southeast-2-bundle.p7b) |
| カナダ (中部) | [ca-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ca-central-1/ca-central-1-bundle.pem) | [ca-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ca-central-1/ca-central-1-bundle.p7b) |
| カナダ西部 (カルガリー) | [ca-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ca-west-1/ca-west-1-bundle.pem) | [ca-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ca-west-1/ca-west-1-bundle.p7b) |
| 欧州 (フランクフルト) | [eu-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-central-1/eu-central-1-bundle.pem) | [eu-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-central-1/eu-central-1-bundle.p7b) |
| 欧州 (アイルランド) | [eu-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-1/eu-west-1-bundle.pem) | [eu-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-1/eu-west-1-bundle.p7b) |
| 欧州 (ロンドン) | [eu-west-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-2/eu-west-2-bundle.pem) | [eu-west-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-2/eu-west-2-bundle.p7b) |
| ヨーロッパ (ミラノ) | [eu-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-south-1/eu-south-1-bundle.pem) | [eu-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-south-1/eu-south-1-bundle.p7b) |
| 欧州 (パリ) | [eu-west-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-3/eu-west-3-bundle.pem) | [eu-west-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-3/eu-west-3-bundle.p7b) |
| 欧州 (スペイン) | [eu-south-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-south-2/eu-south-2-bundle.pem) | [eu-south-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-south-2/eu-south-2-bundle.p7b) |
| 欧州 (ストックホルム) | [eu-north-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-north-1/eu-north-1-bundle.pem) | [eu-north-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-north-1/eu-north-1-bundle.p7b) |
| 欧州 (チューリッヒ) | [eu-central-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-central-2/eu-central-2-bundle.pem) | [eu-central-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-central-2/eu-central-2-bundle.p7b) |
| イスラエル (テルアビブ) | [il-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/il-central-1/il-central-1-bundle.pem) | [il-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/il-central-1/il-central-1-bundle.p7b) |
| メキシコ (中部) | [mx-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/mx-central-1/mx-central-1-bundle.pem) | [mx-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/mx-central-1/mx-central-1-bundle.p7b) |
| 中東 (バーレーン) | [me-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/me-south-1/me-south-1-bundle.pem) | [me-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/me-south-1/me-south-1-bundle.p7b) |
| 中東 (アラブ首長国連邦) | [me-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/me-central-1/me-central-1-bundle.pem) | [me-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/me-central-1/me-central-1-bundle.p7b) |
| 南米 (サンパウロ) | [sa-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/sa-east-1/sa-east-1-bundle.pem) | [sa-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/sa-east-1/sa-east-1-bundle.p7b) |
| 任意の AWS GovCloud (US) Region | [global-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/global/global-bundle.pem) | [global-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/global/global-bundle.p7b) |
| AWS GovCloud (米国東部) | [us-gov-east-1-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-east-1/us-gov-east-1-bundle.pem) | [us-gov-east-1-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-east-1/us-gov-east-1-bundle.p7b) |
| AWS GovCloud (米国西部) | [us-gov-west-1-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-west-1/us-gov-west-1-bundle.pem) | [us-gov-west-1-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-west-1/us-gov-west-1-bundle.p7b) |
### CA 証明書の内容の表示
CA 証明書バンドルの内容を確認するには、次のコマンドを使用します。
```
keytool -printcert -v -file global-bundle.pem
```
# SSL/TLS 証明書のローテーション
Amazon RDS 認証局証明書 rds-ca-2019 は、2024 年 8 月に期限切れになりました。RDS DB インスタンスまたはマルチ AZ DB クラスターへの接続に証明書検証付きの Secure Sockets Layer (SSL) または Transport Layer Security (TLS) を使用しているか、使用する予定がある場合は、新しい CA 証明書 rds-ca-rsa2048-g1、rds-ca-rsa4096-g1、または rds-ca-ecc384-g1 のいずれかの使用を検討してください。現在、証明書検証付きで SSL/TLS を使用していない場合でも、CA 証明書の有効期限が切れている可能性があり、証明書検証付きで SSL/TLS を使用して RDS データベースに接続する予定がある場合は、新しい CA 証明書に更新する必要があります。
Amazon RDS では、AWS セキュリティのベストプラクティスとして、新しい CA 証明書を提供しています。新しい証明書およびサポートしている AWS リージョンの詳細については、「[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md)」を参照してください。
データベースの CA 証明書を更新するには、次の方法を使用します。
+ [DB インスタンスまたはクラスターの変更による CA 証明書の更新](#UsingWithRDS.SSL-certificate-rotation-updating)
+ [メンテナンスの適用による CA 証明書の更新](#UsingWithRDS.SSL-certificate-rotation-maintenance-update)
新しい CA 証明書を使用するように DB インスタンスまたはマルチ AZ DB クラスターを更新する前に、RDS データベースに接続するクライアントまたはアプリケーションを必ず更新します。
## 証明書を更新する際の考慮事項
証明書を更新する前に、次の状況を考慮してください。
+ Amazon RDS Proxy は AWS Certificate Manager (ACM) の証明書を使用します。RDS Proxy を使用している場合は、SSL/TLS 証明書を更新するときに、RDS Proxy 接続を使用するアプリケーションを更新する必要はありません。詳細については、「[RDS Proxy での TLS/SSL の使用](rds-proxy.howitworks.md#rds-proxy-security.tls)」を参照してください。
+ 2020 年 7 月 28 日より前に作成された、または rds-ca-2019 証明書にアップデートされた DB インスタンスまたはマルチ AZ DB クラスターで Go バージョン 1.15 アプリケーションを使用している場合は、証明書を再度更新する必要があります。エンジンに応じて、証明書を rds-ca-rsa2048-g1、rds-ca-rsa4096-g1、または rds-ca-ecc384-g1 に更新してください。
新しい CA 証明書識別子を使用して、DB インスタンスの場合は `modify-db-instance` コマンド、またはマルチ AZ DB クラスターの場合は `modify-db-cluster` コマンドを使用します。`describe-db-engine-versions` コマンドを使用すると、特定の DB エンジンと DB エンジンのバージョンで使用できる CA を検索できます。
2020 年 7 月 28 日以降にデータベースを作成したか、その証明書を更新した場合、必要なアクションはありません。詳細については、[Go GitHub issue \$139568](https://github.com/golang/go/issues/39568) を参照してください。
## DB インスタンスまたはクラスターの変更による CA 証明書の更新
次の例では、CA 証明書を *rds-ca-2019* から *rds-ca-rsa2048-g1* に更新します。別の証明書を選択できます。詳細については、「[認証局](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities)」を参照してください。
アプリケーションの信頼ストアを更新して、CA 証明書の更新に関連するダウンタイムを短縮します。CA 証明書のローテーションに関連する再起動の詳細については、「[サーバー証明書の自動ローテーション](#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation)」を参照してください。
**DB インスタンスまたはクラスターを変更して CA 証明書を更新するには**
1. 「[SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md)」の説明に従って、新しい SSL/TLS 証明書をダウンロードします。
1. 新しい SSL/TLS 証明書を使用するようにアプリケーションを更新します。
新しい SSL/TLS 証明書のアプリケーションを更新する方法は、特定のアプリケーションにより異なります。アプリケーション開発者と協力して、アプリケーションの SSL/TLS 証明書を更新します。
SSL/TLS 接続の確認および各 DB エンジン用アプリケーションの更新については、以下のトピックを参照してください。
+ [新しい SSL/TLS 証明書を使用して MariaDB インスタンスに接続するようにアプリケーションを更新する](ssl-certificate-rotation-mariadb.md)
+ [新しい SSL/TLS 証明書を使用して Microsoft SQL Server DB インスタンスに接続するようにアプリケーションを更新する](ssl-certificate-rotation-sqlserver.md)
+ [新しい SSL/TLS 証明書を使用して MySQL DB インスタンスに接続するようにアプリケーションを更新する](ssl-certificate-rotation-mysql.md)
+ [新しい SSL/TLS 証明書を使用して Oracle DB インスタンスに接続するようにアプリケーションを更新する](ssl-certificate-rotation-oracle.md)
+ [新しい SSL/TLS 証明書を使用して PostgreSQL DB インスタンスに接続するようにアプリケーションを更新する](ssl-certificate-rotation-postgresql.md)
Linux オペレーティングシステムの信頼ストアを更新するサンプルスクリプトについては、「[証明書を信頼ストアにインポートするためのサンプルスクリプト](#UsingWithRDS.SSL-certificate-rotation-sample-script)」を参照してください。
**注記**
証明書バンドルには古い CA と新しい CA の両方の証明書が含まれます。そのため、アプリケーションを安全に更新し、移行期間に接続を維持することができます。AWS Database Migration Service を使用してデータベースを DB インスタンスまたはクラスターに移行する場合は、移行中の接続を確保するために証明書バンドルを使用することをお勧めします。
1. DB インスタンスまたはマルチ AZ DB クラスターを変更して、CA を **rds-ca-2019** から **rds-ca-rsa2048-g1** に変更します。CA 証明書を更新するためにデータベースの再起動が必要かどうかを確認するには、[describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) コマンドを使用して、`SupportsCertificateRotationWithoutRestart` フラグをチェックします。
**重要**
証明書の有効期限が切れた後に接続の問題が発生した場合は、コンソールで [**すぐに適用**] を指定するか、`--apply-immediately` を使用して AWS CLI オプションを指定します。デフォルトで、このオペレーションは次のメンテナンスウィンドウの間に実行するようスケジュールされています。
RDS for Oracle DB インスタンスでは、接続エラーを防ぐために Oracle DB を再起動することをお勧めします。
常時オプションやミラーリングオプションが有効になっている RDS for SQL Server のマルチ AZ インスタンスの場合、証明書ローテーション後にインスタンスを再起動すると、フェイルオーバーが予想されます。
デフォルト RDS CA と異なるインスタンス CA のオーバーライドを設定するには、[modify-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html) CLI コマンドを使用します。
AWS マネジメントコンソール または AWS CLI を使用して、DB インスタンスまたはマルチ AZ DB クラスターの CA 証明書を **rds-ca-2019** から **rds-ca-rsa2048-g1** に変更できます。
------
#### [ Console ]
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで、**[データベース]** を選択し、変更する DB インスタンスまたはマルチ AZ DB クラスターを選択します。
1. **[Modify]** (変更) を選択します。
![\[DB インスタンスまたはマルチ AZ DB クラスターを変更する\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/ssl-rotate-cert-modify.png)
1. **[接続]** セクションで、**[rds-ca-rsa2048-g1]** を選択します。
![\[CA 証明書の選択\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/ssl-rotate-cert-ca-rsa2048-g1.png)
1. [**Continue**] を選択して、変更の概要を確認します。
1. 変更をすぐに反映させるには、[**Apply immediately**] を選択します。
1. 確認ページで、変更内容を確認します。変更内容が正しい場合は、**[DB インスタンスを変更]** または **[クラスターを変更]** を選択して変更を保存します。
**重要**
このオペレーションをスケジュールする場合は、必ずクライアント側の信頼ストアを事前に更新します。
または、[**戻る**] を選択して変更を編集するか、[**キャンセル**] を選択して変更をキャンセルします。
------
#### [ AWS CLI ]
AWS CLI を使用して DB インスタンスまたはマルチ AZ DB クラスターの CA を **rds-ca-2019** から **rds-ca-rsa2048-g1** に変更するには、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) または [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) コマンドを呼び出します。DB インスタンスまたはクラスター識別子および `--ca-certificate-identifier` オプションを指定します。
`--apply-immediately` パラメータを使用して更新を直ちに適用します。デフォルトで、このオペレーションは次のメンテナンスウィンドウの間に実行するようスケジュールされています。
**重要**
このオペレーションをスケジュールする場合は、必ずクライアント側の信頼ストアを事前に更新します。
**Example**
**DB インスタンス**
次の例では、CA 証明書を `rds-ca-rsa2048-g1` に設定することにより、`mydbinstance` を変更しています。
Linux、macOS、Unix の場合:
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--ca-certificate-identifier rds-ca-rsa2048-g1
```
Windows の場合:
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--ca-certificate-identifier rds-ca-rsa2048-g1
```
インスタンスを再起動する必要がある場合、[modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) CLI コマンドを使用して、`--no-certificate-rotation-restart` オプションを指定できます。
**Example**
**マルチ AZ DB クラスター**
次の例では、CA 証明書を `rds-ca-rsa2048-g1` に設定することにより、`mydbcluster` を変更しています。
Linux、macOS、Unix の場合:
```
aws rds modify-db-cluster \
--db-cluster-identifier mydbcluster \
--ca-certificate-identifier rds-ca-rsa2048-g1
```
Windows の場合:
```
aws rds modify-db-cluster ^
--db-cluster-identifier mydbcluster ^
--ca-certificate-identifier rds-ca-rsa2048-g1
```
------
## メンテナンスの適用による CA 証明書の更新
メンテナンスを適用して CA 証明書を更新するには、次のステップを実行します。
------
#### [ Console ]
**メンテナンスを適用して CA 証明書を更新するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. ナビゲーションペインで **[証明書の更新]** を選択します。
![\[ナビゲーションペインの証明書の更新オプション\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/ssl-rotate-cert-certupdate.png)
**[証明書の更新が必要なデータベース]** ページが表示されます。
![\[データベースの CA 証明書の更新\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/ssl-rotate-cert-update-multiple.png)
**注記**
このページには、現在の AWS リージョン リージョンの DB インスタンスおよびクラスターのみが表示されます。複数の AWS リージョン にデータベースがある場合は、このページを AWS リージョン ごとにチェックし、古い SSL/TLS 証明書を使用しているすべての DB インスタンスを確認します。
1. 更新する DB インスタンスまたはマルチ AZ DB クラスターを選択します。
**[スケジュール]** を選択すると、次のメンテナンスウィンドウでの証明書の更新をスケジュールできます。**[今すぐ適用]** を選択して、直ちに更新を適用します。
**重要**
証明書の有効期限が切れた後に接続の問題が発生した場合は、**[今すぐ適用]** オプションを使用します。
1.
1. **[スケジュール]** を選択すると、CA 証明書のローテーションの確認を求められます。このプロンプトには、アップデートのスケジュール期間も記載されています。
![\[証明書の更新の確認\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/ssl-rotate-cert-confirm-schedule.png)
1. **[今すぐ適用]** を選択すると、CA 証明書のローテーションの確認を求められます。
![\[証明書の更新の確認\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/ssl-rotate-cert-confirm-now.png)
**重要**
データベースでの CA 証明書の更新をスケジュールする前に、SSL/TLS とサーバー証明書を接続に使用するクライアントアプリケーションを更新します。これらの更新は、DB エンジンに固有です。これらのクライアントアプリケーションを更新したら、CA 証明書の更新を確認できます。
続行するには、チェックボックスをオンにし、[**確認**] を選択します。
1. 更新する DB インスタンスおよびクラスターごとに、ステップ 3 と 4 を繰り返します。
------
## サーバー証明書の自動ローテーション
ルート CA がサーバー証明書の自動ローテーションをサポートしている場合、RDS は DB サーバー証明書のローテーションを自動的に処理します。RDS はこの自動ローテーションに同じルート CA を使用するため、新しい CA バンドルをダウンロードする必要はありません。「[認証局](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities)」を参照してください。
DB サーバー証明書のローテーションと有効期間は DB エンジンによって異なります。
+ DB エンジンが再起動なしのローテーションをサポートしている場合、ユーザーによるアクションがなくても、RDS は DB サーバー証明書を自動的にローテーションします。RDS は、DB サーバー証明書の半減期になった時点で、希望するメンテナンス期間に DB サーバー証明書のローテーションを試みます。新しい DB サーバー証明書は、12 か月間有効です。
+ DB エンジンが再起動せずにローテーションをサポートしていない場合、Amazon RDS は、証明書の半分、または有効期限の少なくとも 3 か月前に、Describe-pending-maintenance-actions API を介して `server-certificate-rotation` 保留中のメンテナンスアクションを表示します。apply-pending-maintenance-action API を使用してローテーションを適用できます。新しい DB サーバー証明書は、36 か月間有効です。
[ describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) コマンドを使用して、`SupportsCertificateRotationWithoutRestart` フラグを点検することで、再起動なしで DB エンジンバージョンが証明書のローテーションをサポートするかどうかを特定します。詳細については、「[データベースに CA を設定する](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities.Selection)」を参照してください。
## 証明書を信頼ストアにインポートするためのサンプルスクリプト
次のサンプルシェルスクリプトでは、証明書バンドルを信頼ストア内にインポートします。
各サンプルシェルスクリプトでは、Java 開発キット (JDK) の一部である keytool が使用されます。JDK のインストールの詳細については、「[JDK インストールガイド](https://docs.oracle.com/en/java/javase/17/install/overview-jdk-installation.html)」を参照してください。
------
#### [ Linux ]
Linux オペレーティングシステムで、証明書バンドルを信頼ストアにインポートするサンプルシェルスクリプトを次に示します。
```
mydir=tmp/certs
if [ ! -e "${mydir}" ]
then
mkdir -p "${mydir}"
fi truststore=${mydir}/rds-truststore.jks storepassword=changeit
curl -sS "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem"> ${mydir}/global-bundle.pem
awk 'split_after == 1 {n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1}{print > "rds-ca-" n+1 ".pem"}' < ${mydir}/global-bundle.pem
for CERT in rds-ca-*; do alias=$(openssl x509 -noout -text -in $CERT | perl -ne 'next unless /Subject:/; s/.*(CN=|CN = )//; print')
echo "Importing $alias"
keytool -import -file ${CERT} -alias "${alias}" -storepass ${storepassword} -keystore ${truststore} -noprompt
rm $CERT
done
rm ${mydir}/global-bundle.pem
echo "Trust store content is: "
keytool -list -v -keystore "$truststore" -storepass ${storepassword} | grep Alias | cut -d " " -f3- | while read alias
do expiry=`keytool -list -v -keystore "$truststore" -storepass ${storepassword} -alias "${alias}" | grep Valid | perl -ne 'if(/until: (.*?)\n/) { print "$1\n"; }'`
echo " Certificate ${alias} expires in '$expiry'"
done
```
------
#### [ macOS ]
macOS で証明書バンドルを信頼ストアにインポートするサンプルシェルスクリプトを次に示します。
```
mydir=tmp/certs
if [ ! -e "${mydir}" ]
then
mkdir -p "${mydir}"
fi truststore=${mydir}/rds-truststore.jks storepassword=changeit
curl -sS "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem"> ${mydir}/global-bundle.pem
split -p "-----BEGIN CERTIFICATE-----" ${mydir}/global-bundle.pem rds-ca-
for CERT in rds-ca-*; do alias=$(openssl x509 -noout -text -in $CERT | perl -ne 'next unless /Subject:/; s/.*(CN=|CN = )//; print')
echo "Importing $alias"
keytool -import -file ${CERT} -alias "${alias}" -storepass ${storepassword} -keystore ${truststore} -noprompt
rm $CERT
done
rm ${mydir}/global-bundle.pem
echo "Trust store content is: "
keytool -list -v -keystore "$truststore" -storepass ${storepassword} | grep Alias | cut -d " " -f3- | while read alias
do expiry=`keytool -list -v -keystore "$truststore" -storepass ${storepassword} -alias "${alias}" | grep Valid | perl -ne 'if(/until: (.*?)\n/) { print "$1\n"; }'`
echo " Certificate ${alias} expires in '$expiry'"
done
```
------
# ネットワーク間のトラフィックのプライバシー
Amazon RDS とオンプレミスのアプリケーション間、および同じ AWS リージョン内の Amazon RDS と他の AWS リソース間では、接続が保護されています。
## サービスとオンプレミスのクライアントおよびアプリケーションとの間のトラフィック
プライベートネットワークと AWS との間には 2 つの接続オプションがあります
+ AWS Site-to-Site VPN 接続。詳細については、「[AWS Site-to-Site VPN とは](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)」を参照してください。
+ Direct Connect 接続。詳細については、「[Direct Connect とは?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)」を参照してください。
AWS が公開した API オペレーションを使用することにより、ネットワークを通じて、Amazon RDS へのアクセスを取得できます。クライアントは以下をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
また、リクエストにはアクセスキー ID と、IAM プリンシパルに関連付けられているシークレットアクセスキーを使用して署名する必要があります。または、[AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) を使用して、一時的なセキュリティ認証情報を生成し、リクエストに署名することもできます。
# Amazon RDS での Identity and Access Management
AWS Identity and Access Management (IAM) は管理者が AWS リソースへのアクセスを安全に制御するために役立つ AWS のサービスです。IAM 管理者は、誰 (のサインイン) を*認証*して、Amazon RDS リソースの使用を*承認* (許可) するかを管理します。IAM は、追加費用なしで使用できる AWS のサービス です。
**Topics**
+ [
## 対象者
](#security_iam_audience)
+ [
## アイデンティティを使用した認証
](#security_iam_authentication)
+ [
## ポリシーを使用したアクセスの管理
](#security_iam_access-manage)
+ [
# Amazon RDS と IAM の連携
](security_iam_service-with-iam.md)
+ [
# Amazon RDS のアイデンティティベースのポリシーの例
](security_iam_id-based-policy-examples.md)
+ [
# AWSAmazon RDS の マネージドポリシー
](rds-security-iam-awsmanpol.md)
+ [
# Amazon RDS の AWS 管理ポリシーに関する更新
](rds-manpol-updates.md)
+ [
# サービス間での混乱した代理問題の防止
](cross-service-confused-deputy-prevention.md)
+ [
# MariaDB、MySQL、および PostgreSQL の IAM データベース認証
](UsingWithRDS.IAMDBAuth.md)
+ [
# Amazon RDS のアイデンティティおよびアクセスのトラブルシューティング
](security_iam_troubleshoot.md)
## 対象者
AWS Identity and Access Management (IAM) の使用方法は、Amazon RDS で行う作業によって異なります。
**サービスユーザー ** - ジョブを実行するために Amazon RDS サービスを使用する場合は、管理者が必要なアクセス許可と認証情報を用意します。作業を実行するためにさらに多くの Amazon RDS 機能を使用するとき、追加のアクセス許可が必要になる場合があります。アクセスの管理方法を理解すると、管理者から適切なアクセス許可をリクエストするのに役に立ちます。Amazon RDS の機能にアクセスできない場合は、「[Amazon RDS のアイデンティティおよびアクセスのトラブルシューティング](security_iam_troubleshoot.md)」を参照してください。
**サービス管理者** - 社内の Amazon RDS リソースを担当している場合は、おそらく Amazon RDS へのフルアクセスがあります。従業員がどの Amazon RDS 機能とリソースアクセスする必要があるかを決定するのは管理者の仕事です。その後で、サービスユーザーのアクセス許可を変更するために、 管理者にリクエストを送信する必要があります。このページの情報を点検して、IAM の基本概念を理解してください。お客様の会社で Amazon RDS で IAM を利用する方法の詳細については、「[Amazon RDS と IAM の連携](security_iam_service-with-iam.md)」を参照して ください。
**管理者** - 管理者は、Amazon RDS へのアクセスを管理するポリシーの作成方法の詳細について確認したい場合があります。IAM で使用できる Amazon RDS アイデンティティベースのポリシーの例を表示するには、「[Amazon RDS のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照して ください。
## アイデンティティを使用した認証
認証とは、アイデンティティ認証情報を使用して AWS にサインインする方法です。ユーザーは、AWS アカウントのルートユーザー、IAM ユーザーとして、または IAM ロールを引き受けることによって、認証される必要があります。
AWS IAM アイデンティティセンター (IAM Identity Center)、シングルサインオン認証、Google/Facebook 認証情報などの ID ソースからの認証情報を使用して、フェデレーテッドアイデンティティとしてサインインできます。サインインの詳細については、「*AWS サインイン ユーザーガイド*」の「[How to sign in to your AWS アカウント](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)」を参照してください。
プログラムによるアクセスの場合、AWS はリクエストに暗号で署名するための SDK と CLI を提供します。詳細については、「*IAM ユーザーガイド*」の「[API リクエストに対する AWS Signature Version 4](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)」を参照してください。
### AWS アカウントのルートユーザー
AWS アカウントを作成すると、すべての AWS のサービスとリソースに対する完全なアクセス権を持つ AWS アカウント*ルートユーザー*と呼ばれる 1 つのサインイン ID を使用して開始します。日常的なタスクには、ルートユーザーを使用しないことを強くお勧めします。ルートユーザー認証情報を必要とするタスクについては、「*IAM ユーザーガイド*」の「[ルートユーザー認証情報が必要なタスク](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)」を参照してください。
### フェデレーテッドアイデンティティ
ベストプラクティスでは、人間のユーザーが一時的な認証情報を使用して AWS のサービス にアクセスする際、アイデンティティプロバイダーとのフェデレーションを使用することが求められます。
*フェデレーテッドアイデンティティ*は、エンタープライズディレクトリ、ウェブ ID プロバイダー、Directory Service のユーザーであり、ID ソースからの認証情報を使用して AWS のサービスにアクセスするユーザーです。フェデレーティッドアイデンティティは、一時的な認証情報を提供するロールを引き受けます。
アクセスを一元管理する場合は、AWS IAM アイデンティティセンター をお勧めします。詳細については、「*AWS IAM アイデンティティセンター ユーザーガイド*」の「[What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)」を参照してください。
### IAM ユーザーとグループ
*[IAM ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)*は、1 人のユーザーまたは 1 つのアプリケーションに対して特定の許可を持つアイデンティティです。長期認証情報を持つ IAM ユーザーの代わりに一時的な認証情報を使用することをお勧めします。詳細は「*IAM ユーザーガイド*」の「[人間のユーザーが一時的な認証情報を使用して AWS にアクセスするには ID プロバイダーとのフェデレーションの使用が必要です](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp)」を参照してください。
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) IAM ユーザーのコレクションを指定し、大量のユーザーのアクセス許可の管理を容易にします。詳細については、「*IAM ユーザーガイド*」の「[IAM ユーザーに関するユースケース](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)」を参照してください。
IAM データベース認証を使用して、DB インスタンスを認証できます。
IAM データベース認証は、次の DB エンジンで使用できます。
+ RDS for MariaDB
+ RDS for MySQL
+ RDS for PostgreSQL
IAM を使用した DB インスタンスの認証の詳細については、「[MariaDB、MySQL、および PostgreSQL の IAM データベース認証](UsingWithRDS.IAMDBAuth.md)」を参照してください。
### IAM ロール
*[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)*は、特定の許可を持つ、AWS アカウント内のアイデンティティです。これはユーザーに似ていますが、特定のユーザーに関連付けられていません。[ロールを切り替える](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)ことによって、AWS マネジメントコンソールで IAM ロールを一時的に引き受けることができます。ロールを引き受けるには、AWS CLIまたは AWS API オペレーションを呼び出すか、カスタム URL を使用します。ロールを使用する方法の詳細については、「*IAM ユーザーガイド*」の「[IAM ロールの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html)」を参照してください。
IAM ロールと一時的な認証情報は、次の状況で役立ちます:
+ **一時的なユーザーアクセス許可** - ユーザーは、特定のタスクのための複数の異なるアクセス許可を一時的に受け取るために、IAM ロールを引き受けることができます。
+ **フェデレーションユーザーアクセス** – フェデレーテッド ID に許可を割り当てるには、ロールを作成してそのロールの許可を定義します。フェデレーテッド ID が認証されると、その ID はロールに関連付けられ、ロールで定義されている許可が付与されます。フェデレーションのロールについては、「*IAM ユーザーガイド*」の「[サードパーティー ID プロバイダー (フェデレーション) 用のロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html)」を参照してください。IAM Identity Center を使用する場合は、許可セットを設定します。アイデンティティが認証後にアクセスできるものを制御するため、IAM Identity Center は、権限セットを IAM のロールに関連付けます。アクセス許可セットの詳細については、「*AWS IAM アイデンティティセンター User Guide*」の「[Permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)」を参照してください。
+ **クロスアカウントアクセス** - IAM ロールを使用して、自分のアカウントのリソースにアクセスすることを、別のアカウントの人物 (信頼済みプリンシパル) に許可できます。クロスアカウントアクセス権を付与する主な方法は、ロールを使用することです。ただし、一部の AWS のサービスでは、(ロールをプロキシとして使用する代わりに) リソースにポリシーを直接アタッチできます。クロスアカウントアクセスでのロールとリソースベースのポリシーの違いの詳細については、「[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html)」の「*IAM ロールとリソースベースのポリシーとの相違点*」を参照してください。
+ **クロスサービスアクセス権** - 一部の AWS のサービスでは、他の AWS のサービスの機能を使用します。例えば、あるサービスで呼び出しを行うと、通常そのサービスによって Amazon EC2 でアプリケーションが実行されたり、Amazon S3 にオブジェクトが保存されたりします。サービスでは、呼び出し元プリンシパルの許可、サービスロール、またはサービスリンクロールを使用してこれを行う場合があります。
+ **転送アクセスセッション** – 転送アクセスセッション (FAS) は、AWS のサービスを呼び出すプリンシパルの権限を、AWS のサービスのリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
+ **サービスロール** - サービスがユーザーに代わってアクションを実行するために引き受ける [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)です。IAM 管理者は、IAM 内からサービスロールを作成、変更、削除できます。詳細については、「*IAM ユーザーガイド*」の「[AWS のサービス に許可を委任するロールを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)」を参照してください。
+ **サービスにリンクされたロール** - サービスにリンクされたロールは、AWS のサービス にリンクされたサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
+ **Amazon EC2 で実行されているアプリケーション** - EC2 インスタンスで実行され、AWS CLI または AWS API リクエストを行っているアプリケーションの一時的な認証情報を管理するには、IAM ロールを使用できます。これは、EC2 インスタンス内でのアクセスキーの保存に推奨されます。AWS ロールを EC2 インスタンスに割り当て、そのすべてのアプリケーションで使用できるようにするには、インスタンスに添付されたインスタンスプロファイルを作成します。インスタンスプロファイルにはロールが含まれ、EC2 インスタンスで実行されるプログラムは一時的な認証情報を取得できます。詳細については、「*IAM ユーザーガイド*」の「[Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用して許可を付与する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)」を参照してください。
IAM ロールを使用するべきかどうかについては、*IAM ユーザーガイド*の「[IAM ロールの作成が適している場合 (ユーザーではなく)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role)」を参照してください。
## ポリシーを使用したアクセスの管理
AWS でのアクセスは、ポリシーを作成し、それらを IAM アイデンティティまたは AWS リソースに添付することで制御できます。ポリシーは AWS のオブジェクトであり、ID やリソースに関連付けられて、これらのアクセス許可を定義します。AWS は、エンティティ (ルートユーザー、ユーザー、または IAM ロール) によってリクエストが行われると、それらのポリシーを評価します。ポリシーでの権限により、リクエストが許可されるか拒否されるかが決まります。大半のポリシーは JSON ドキュメントとして AWSに保存されます。JSON ポリシードキュメントの構造と内容の詳細については、「*IAM ユーザーガイド*」の「[JSON ポリシー概要](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)」を参照してください。
管理者は、ポリシーを使用して、AWS リソースへのアクセス権を持つユーザーと、これらのリソースに対して実行できるアクションを指定できます。すべての IAM エンティティ (アクセス許可セットまたはロール) は、アクセス許可のない状態からスタートします。言い換えると、デフォルト設定では、ユーザーは何もできず、自分のパスワードを変更することすらできません。何かを実行する許可をユーザーに付与するには、管理者がユーザーに許可ポリシーをアタッチする必要があります。また、管理者は、必要な許可があるグループにユーザーを追加できます。管理者がグループに許可を付与すると、そのグループ内のすべてのユーザーにこれらの許可が付与されます。
IAM ポリシーは、オペレーションの実行方法を問わず、アクションの許可を定義します。例えば、`iam:GetRole` アクションを許可するポリシーがあるとします。このポリシーがあるユーザーは、AWS マネジメントコンソール、AWS CLI、または AWS API からロール情報を取得できます。
### アイデンティティベースポリシー
ID ベースのポリシーは、 アクセス許可セットやロールなどの ID にアタッチできる JSON アクセス許可ポリシードキュメントです。これらのポリシーは、アイデンティティが実行できるアクション、リソース、および条件を制御します。アイデンティティベースのポリシーを作成する方法については、[IAM ユーザーガイド](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)の *IAM ポリシーの作成*を参照してください。
アイデンティティベースのポリシーは、さらに*インラインポリシー*または*マネージドポリシー*に分類できます。インラインポリシーは、単一のアクセス許可セットまたはロールに直接埋め込まれます。マネージドポリシーは、AWS アカウント内の複数のアクセス許可セットおよびロールにアタッチできるスタンドアロンポリシーです。マネージドポリシーには、AWS マネージドポリシーとカスタマー管理ポリシーがあります。マネージドポリシーまたはインラインポリシーのいずれかを選択する方法については、*IAM ユーザーガイド*の[マネージドポリシーとインラインポリシーの比較](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline)を参照してください。
Amazon RDSに固有の AWS マネージドポリシーの詳細については、「[AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md)」を参照してください。
### 他のポリシータイプ
AWS では、他の一般的ではないポリシータイプをサポートしています。これらのポリシータイプでは、より一般的なポリシータイプで付与された最大の権限を設定できます。
+ **アクセス許可の境界** - アクセス許可の境界は、ID ベースのポリシーによって IAM エンティティ (アクセス許可セットまたはロール) に付与できるアクセス許可の上限を設定する高度な機能です。エンティティに許可の境界を設定できます。結果として許可される範囲は、エンティティのアイデンティティベースポリシーとその許可の境界の共通部分になります。`Principal` フィールドでアクセス許可セットまたはロールを指定するリソースベースのポリシーは、アクセス許可の境界によって制限されません。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。許可の境界の詳細については、「*IAM ユーザーガイド*」の「[IAM エンティティの許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)」を参照してください。
+ **サービスコントロールポリシー (SCP)** – SCP は、AWS Organizations で組織や組織単位 (OU) に最大アクセス許可を指定する JSON ポリシーです。AWS Organizationsは、お客様のビジネスが所有する複数の AWS アカウントをグループ化し、一元的に管理するサービスです。組織内のすべての機能を有効にすると、サービスコントロールポリシー (SCP) を一部またはすべてのアカウントに適用できます。SCP はメンバーアカウントのエンティティに対する権限を制限します (各 AWS アカウントのルートユーザー など)。Organizations と SCP の詳細については、*AWS Organizationsユーザーガイド*の「[SCP の仕組み](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html)」を参照してください。
+ **セッションポリシー** - セッションポリシーは、ロールまたはフェデレーションユーザーの一時的なセッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。結果としてのセッションのアクセス許可は、アクセス許可セットまたはロールの ID ベースのポリシーとセッションポリシーの共通部分になります。また、リソースベースのポリシーから権限が派生する場合もあります。これらのポリシーのいずれかを明示的に拒否した場合、権限は無効になります。詳細については、「*IAM ユーザーガイド*」の「[セッションポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)」を参照してください。
### 複数のポリシータイプ
1 つのリクエストに複数のタイプのポリシーが適用されると、結果として作成される権限を理解するのがさらに難しくなります。複数のポリシータイプが関連するとき、リクエストを許可するかどうかを AWS が決定する方法の詳細については、*IAM ユーザーガイド*の[ポリシーの評価ロジック](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)を参照してください。
# Amazon RDS と IAM の連携
IAM を使用して、Amazon RDS へのアクセスを管理するには、Amazon RDS で使用できる IAM の機能を理解しておく必要があります。
次の表は、Amazon RDS で使用できる IAM 機能の一覧です。
| IAM 機能 | Amazon RDS のサポート |
| --- | --- |
| [アイデンティティベースのポリシー](#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 RDS や AWS の他のサービスと IAM との連携の概要については、*IAM ユーザーガイド*の「[IAM と連携する AWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」を参照してください。
**Topics**
+ [
## Amazon RDS アイデンティティベースのポリシー
](#security_iam_service-with-iam-id-based-policies)
+ [
## Amazon RDS 内のリソースベースのポリシー
](#security_iam_service-with-iam-resource-based-policies)
+ [
## Amazon RDS のポリシーアクション
](#security_iam_service-with-iam-id-based-policies-actions)
+ [
## Amazon RDS のポリシーリソース
](#security_iam_service-with-iam-id-based-policies-resources)
+ [
## Amazon RDS のポリシー条件キー
](#UsingWithRDS.IAM.Conditions)
+ [
## Amazon RDS のアクセスコントロールリスト (ACL)
](#security_iam_service-with-iam-acls)
+ [
## Amazon RDS タグを使ったポリシーにおける属性ベースのアクセスコントロール (ABAC)
](#security_iam_service-with-iam-tags)
+ [
## Amazon RDS での一時的な認証情報の使用
](#security_iam_service-with-iam-roles-tempcreds)
+ [
## Amazon RDS のフォワードアクセスセッション
](#security_iam_service-with-iam-principal-permissions)
+ [
## Amazon RDS のサービスロール
](#security_iam_service-with-iam-roles-service)
+ [
## Amazon RDS のサービスリンクロール
](#security_iam_service-with-iam-roles-service-linked)
## Amazon RDS アイデンティティベースのポリシー
**アイデンティティベースのポリシーのサポート:** あり。
アイデンティティベースのポリシーは、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)」を参照してください。
### Amazon RDS アイデンティティベースのポリシーの例
Amazon RDS アイデンティティベースのポリシーの例を表示するには、「[Amazon RDS のアイデンティティベースのポリシーの例](security_iam_id-based-policy-examples.md)」を参照してください。
## Amazon RDS 内のリソースベースのポリシー
**リソースベースのポリシーのサポート:** なし。
リソースベースのポリシーは、リソースに添付する 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)を参照してください。
## Amazon RDS のポリシーアクション
**ポリシーアクションのサポート:** あり。
管理者は AWS JSON ポリシーを使用して、だれが何にアクセスできるかを指定できます。つまり、どの**プリンシパル**がどのような**リソース**にどのような**条件**で**アクション**を実行できるかということです。
JSON ポリシーの `Action` 要素にはポリシー内のアクセスを許可または拒否するために使用できるアクションが記述されます。このアクションは関連付けられたオペレーションを実行するためのアクセス許可を付与するポリシーで使用されます。
Amazon RDS のポリシーアクションは、アクションの前にプレフィックス `rds:` を使用します。例えば、Amazon RDS `DescribeDBInstances` API オペレーションを使用して DB インスタンスを指定するアクセス許可を付与するには、ポリシーに `rds:DescribeDBInstances` アクションを含めます。ポリシーステートメントには、`Action` または `NotAction` エレメントを含める必要があります。Amazon RDS は、このサービスで実行できるタスクを記述する独自のアクションのセットを定義します。
単一のステートメントに複数のアクションを指定するには、次のようにコンマで区切ります。
```
"Action": [
"rds:action1",
"rds:action2"
```
ワイルドカード \$1を使用して複数のアクションを指定することができます。例えば、`Describe` という単語で始まるすべてのアクションを指定するには、次のアクションを含めます。
```
"Action": "rds:Describe*"
```
Amazon RDS アクションのリストを確認するには、「サービス認可リファレンス」の「[Amazon RDS によって定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions)」を参照してください。**
## Amazon RDS のポリシーリソース
**ポリシーリソースのサポート:** あり。
管理者は 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"
```
Amazon RDS のリソースタイプおよび 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)」を参照してください。
## Amazon RDS のポリシー条件キー
**サービス固有のポリシー条件キーのサポート:** あり。
管理者は 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)を参照してください。
Amazon RDS は独自の条件キーを定義し、一部のグローバル条件キーの使用をサポートしています。すべての AWS グローバル条件キーを確認するには、*IAM ユーザーガイド*の「[AWS グローバル条件コンテキストキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)」を参照してください。
すべての RDS API オペレーションは、`aws:RequestedRegion` 条件キーをサポートします。
Amazon RDS の条件キーのリストについては、「*サービス認可リファレンス*」の「[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)」を参照してください。
## Amazon RDS のアクセスコントロールリスト (ACL)
**アクセスコントロールリスト (ACL) をサポート:** なし。
アクセスコントロールリスト (ACL) は、どのプリンシパル (アカウントメンバー、ユーザー、またはロール) がリソースにアクセスするためのアクセス許可を持つかを制御します。ACL はリソースベースのポリシーに似ていますが、JSON ポリシードキュメント形式は使用しません。
## Amazon RDS タグを使ったポリシーにおける属性ベースのアクセスコントロール (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)」を参照してください。
Amazon RDS リソースのタグ付けの詳細については、「[条件の指定: カスタムタグの使用](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)」を参照してください。
## Amazon RDS での一時的な認証情報の使用
**一時的な認証情報のサポート:** あり。
一時的な認証情報は、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)」を参照してください。
## Amazon RDS のフォワードアクセスセッション
**転送アクセスセッションをサポート:** あり。
転送アクセスセッション (FAS) は、AWS のサービス を呼び出すプリンシパルのアクセス許可を AWS のサービス のリクエストと合わせて使用し、ダウンストリームのサービスに対してリクエストを行います。FAS リクエストを行う際のポリシーの詳細については、「[転送アクセスセッション](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)」を参照してください。
## Amazon RDS のサービスロール
**サービスロールのサポート:** あり。
サービスロールとは、サービスがユーザーに代わってアクションを実行するために引き受ける [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)を参照してください。
**警告**
サービスロールの許可を変更すると、Amazon RDS のサービスロール の機能が破損する可能性があります。Amazon RDS が指示する場合以外は、サービスロールを編集しないでください。
## Amazon RDS のサービスリンクロール
**サービスリンクロールのサポート:** あり。
サービスにリンクされたロールは、AWS のサービス にリンクされているサービスロールの一種です。サービスがロールを引き受け、ユーザーに代わってアクションを実行できるようになります。サービスにリンクされたロールは、AWS アカウント に表示され、サービスによって所有されます。IAM 管理者は、サービスリンクロールのアクセス許可を表示できますが、編集することはできません。
Amazon RDS サービスにリンクされたロールの使用の詳細については、「[Amazon RDS のサービスにリンクされたロールの使用](UsingWithRDS.IAM.ServiceLinkedRoles.md)」を参照してください。
# Amazon RDS のアイデンティティベースのポリシーの例
デフォルトでは、アクセス許可セットとロールには、Amazon RDS リソースを作成または変更するアクセス許可はありません。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)
+ [
## Amazon RDS コンソールの使用
](#security_iam_id-based-policy-examples-console)
+ [
## コンソールの使用に必要なアクセス許可
](#UsingWithRDS.IAM.RequiredPermissions.Console)
+ [
## 自分の権限の表示をユーザーに許可する
](#security_iam_id-based-policy-examples-view-own-permissions)
+ [
# Amazon RDS でリソースを作成、変更、削除するアクセス許可ポリシー
](security_iam_id-based-policy-examples-create-and-modify-examples.md)
+ [
# ポリシー例: 条件キーの使用
](UsingWithRDS.IAM.Conditions.Examples.md)
+ [
# 条件の指定: カスタムタグの使用
](UsingWithRDS.IAM.SpecifyingCustomTags.md)
+ [
# Amazon RDS リソースの作成時にタグ付けするアクセス許可の付与
](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) を参照してください。
## Amazon RDS コンソールの使用
Amazon RDS コンソールにアクセスするには、一連の最小限のアクセス許可が必要です。これらのアクセス許可により、AWS アカウント の Amazon RDS リソースの詳細をリストおよび表示できるようにする必要があります。最小限必要なアクセス許可よりも制限が厳しいアイデンティティベースのポリシーを作成すると、そのポリシーを持つエンティティ (ユーザーまたはロール) ではコンソールが意図したとおりに機能しません。
AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソール権限を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。
これらのエンティティが Amazon RDS コンソールを引き続き使用できるように、エンティティに次の AWS 管理ポリシーもアタッチします。
```
AmazonRDSReadOnlyAccess
```
詳細については、*IAM ユーザーガイド* の「[ユーザーへのアクセス許可の追加](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console)」を参照してください。
## コンソールの使用に必要なアクセス許可
コンソールを使用するユーザーには、最小限のアクセス許可のセットが必要です。これらのアクセス許可により、ユーザーは AWS アカウントの Amazon RDS リソースを記述し、Amazon EC2 セキュリティやネットワーク情報など、その他の関連情報を提供できます。
これらの最小限必要なアクセス権限よりも制限された IAM ポリシーを作成している場合、その IAM ポリシーを使用するユーザーに対してコンソールは意図したとおりには機能しません。「`AmazonRDSReadOnlyAccess`」で説明されているとおり、ユーザーがコンソールを使用できること、および [ポリシーを使用したアクセスの管理](UsingWithRDS.IAM.md#security_iam_access-manage) 管理ポリシーがユーザーにアタッチされていることを確認してください。
AWS CLI または Amazon RDS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。
以下のポリシーでは、ルート AWS アカウントの Amazon RDS リソースへのフルアクセスが付与されます。
```
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": "*"
}
]
}
```
# Amazon RDS でリソースを作成、変更、削除するアクセス許可ポリシー
以下のセクションでは、リソースへのアクセスを許可および制限するアクセス許可ポリシーの例を示します。
## 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` 要素を使用して、アクセス許可または制約を追加できます。条件を指定する方法については、「[Amazon RDS のポリシー条件キー](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.Support.md)」を参照してください。
アイデンティティベースのポリシーでアクセス権限を得るプリンシパルを指定していないため、ポリシーでは `Principal` 要素を指定していません。ユーザーにポリシーをアタッチすると、そのユーザーが暗黙のプリンシパルになります。IAM ロールにアクセス権限ポリシーをアタッチすると、ロールの信頼ポリシーで識別されたプリンシパルがアクセス権限を得ることになります。
Amazon RDS アクションのリストを確認するには、「サービス認可リファレンス」の「[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 RDS リソースに対してそれらのアクションが許可されることを示します。
------
#### [ 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 つの異なる値を持つタグが付いたリソースに対するアクションにアクセス許可を付与する
アイデンティティベースのポリシーの条件を使用して、タグに基づいて Amazon RDS リソースへのアクセスを制御できます。次のポリシーでは、`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 RDS 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 RDS では、カスタムタグを使用して 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/UserGuide/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 RDS リソースのタグ付け](USER_Tagging.md)」を参照してください。
**重要**
タグを使用して RDS リソースへのアクセスを管理する場合は、RDS リソースのタグへのアクセスを保護することをお勧めします。`AddTagsToResource` および `RemoveTagsFromResource` アクションのポリシーを作成することによって、タグへのアクセスを管理できます。例えば、次のポリシーは、ユーザーがすべてのリソースのタグを追加または削除することを拒否します。次に、特定のユーザーがタグを追加または削除することを許可するポリシーを作成できます。
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"DenyTagUpdates",
"Effect":"Deny",
"Action":[
"rds:AddTagsToResource",
"rds:RemoveTagsFromResource"
],
"Resource":"*"
}
]
}
```
Amazon RDS アクションのリストを確認するには、「サービス認可リファレンス」の「[Amazon RDS によって定義されるアクション](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions)」を参照してください。**
## ポリシー例: カスタムタグの使用
以下に示しているのは、Amazon RDS IAM アクセス許可ポリシーでのカスタムタグの使用例です。Amazon RDS リソースへのタグの追加の詳細については、「[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 RDS リソースの使用の詳細については、「[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"
}
}
}
]
}
```
------
# Amazon RDS リソースの作成時にタグ付けするアクセス許可の付与
一部の 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:CreateDBInstance` など) を使用するためのアクセス許可が必要です。作成アクションでタグが指定されている場合、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 マネージドポリシー: AmazonRDSCustomServiceRolePolicy
](#rds-security-iam-awsmanpol-AmazonRDSCustomServiceRolePolicy)
+ [
## AWS マネージドポリシー: AmazonRDSCustom Instance ProfileRolePolicy
](#rds-security-iam-awsmanpol-AmazonRDSCustomInstanceProfileRolePolicy)
+ [
## 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 RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions)」を参照してください。
## AWS マネージドポリシー: AmazonRDSCustomServiceRolePolicy
IAM エンティティに `AmazonRDSCustomServiceRolePolicy` をアタッチすることはできません。このポリシーは、Amazon RDS が RDS DB リソースに代わって AWS のサービスを呼び出すことを許可するサービスにリンクされたロールに関連付けられています。
このポリシーには、以下のアクセス許可が含まれています。
+ `ec2` - RDS Custom が、ポイントインタイム復元機能を提供する DB インスタンスでバックアップ操作を実行することを許可します。
+ `secretsmanager` ‐ RDS Custom が RDS Custom によって作成された DB インスタンス固有のシークレットを管理できるようにします。
+ `cloudwatch` - RDS Custom が CloudWatch エージェントを介して DB インスタンスメトリクスとログを CloudWatch にアップロードすることを許可します。
+ `events`、`sqs`‐ RDS Custom が DB インスタンスに関するステータス情報を送受信できるようにします。
+ `cloudtrail` ‐ RDS Custom が DB インスタンスに関する変更イベントを受信することを許可します。
+ `servicequotas` ‐ RDS Custom が DB インスタンスに関するサービスクォータを読み取ることを許可します
+ `ssm` - RDS Custom が DB インスタンスの基盤となる EC2 インスタンスを管理することを許可します。
+ `rds` - RDS Custom が DB インスタンスの RDS リソースを管理することを許可します。
+ `iam` - RDS Custom がインスタンスプロファイルを検証して DB インスタンスの基盤となる EC2 インスタンスにアタッチすることを許可します。
JSON ポリシードキュメントを含むこのポリシーの詳細については、*AWS マネージドポリシーリファレンスガイド*の「[AmazonRDSCustomServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSCustomServiceRolePolicy.html)」を参照してください。
## AWS マネージドポリシー: AmazonRDSCustom Instance ProfileRolePolicy
IAM エンティティに `AmazonRDSCustomInstanceProfileRolePolicy` をアタッチしないでください。このポリシーは、さまざまなオートメーションアクションとデータベース管理タスクを実行するためのアクセス許可を Amazon RDS Custom DB インスタンスに付与するために使用されるインスタンスプロファイルロールにのみアタッチする必要があります。RDS Custom インスタンスの作成時にインスタンスプロファイルを `custom-iam-instance-profile` パラメータとして渡すと、RDS Custom はこのインスタンスプロファイルを DB インスタンスに関連付けます。
**アクセス許可の詳細**
このポリシーには、以下のアクセス許可が含まれています。
+ `ssm`、`ssmmessages`、`ec2messages` ‐ RDS Custom が Systems Manager を介して DB インスタンスで通信、自動化の実行、エージェントの管理を実行できるようにします。
+ `ec2`、`s3` ‐ RDS Custom が、ポイントインタイム復元機能を提供する DB インスタンスでバックアップオペレーションを実行できるようにします。
+ `secretsmanager` ‐ RDS Custom が RDS Custom によって作成された DB インスタンス固有のシークレットを管理できるようにします。
+ `cloudwatch`、`logs`‐ RDS Custom が CloudWatch エージェントを介して DB インスタンスのメトリクスとログを CloudWatch にアップロードできるようにします。
+ `events`、`sqs`‐ RDS Custom が DB インスタンスに関するステータス情報を送受信できるようにします。
+ `kms` ‐ RDS Custom がインスタンス固有の KMS キーを使用して、RDS Custom が管理するシークレットと S3 オブジェクトの暗号化を実行できるようにします。
JSON ポリシードキュメントなど、このポリシーの詳細については、「**AWS マネージドポリシーリファレンスガイド」の「[AmazonRDSCustomInstanceProfileRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSCustomInstanceProfileRolePolicy.html)」を参照してください。
## 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 日 |
| [Amazon RDS Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom) – 既存のポリシーの更新 | Amazon RDS は、`AWSServiceRoleForRDSCustom` サービスにリンクされたロールの `AmazonRDSCustomServiceRolePolicy` に新しいアクセス許可を追加しました。アクセス許可により、RDS Custom は別の AWS リージョンの Amazon RDS サービスと通信し、EC2 イメージをコピーできます。詳細については、「[Amazon RDS Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom)」を参照してください。 | 2024 年 7 月 18 日 |
| [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 日 |
| [Amazon RDS Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom) – 既存のポリシーの更新 | Amazon RDS は、`AWSServiceRoleForRDSCustom` サービスにリンクされたロールの `AmazonRDSCustomServiceRolePolicy` に新しいアクセス許可を追加しました。この新しいアクセス許可により、RDS Custom はサービスロールをインスタンスプロファイルとして RDS Custom インスタンスに関連付けることができます。詳細については、「[Amazon RDS Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom)」を参照してください。 | 2024 年 4 月 19 日 |
| [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 RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`AWSServiceRoleForRDS` サービスリンクロールの `AmazonRDSServiceRolePolicy` に新しいステートメント ID を追加しました。 詳細については、「[Amazon RDS のサービスにリンクされたロールのアクセス許可](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 日 |
| [Amazon RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`AWSServiceRoleForRDSCustom` サービスにリンクされたロールの `AmazonRDSCustomServiceRolePolicy` に新しいアクセス許可を追加しました。これらの新しいアクセス許可により、RDS Custom for Oracle は EventBridge マネージドルールを作成、変更、削除できるようになります。 詳細については、「[Amazon RDS Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom)」を参照してください。 | 2023 年 9 月 20 日 |
| [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 日 |
| [Amazon RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`AWSServiceRoleForRDSCustom` サービスにリンクされたロールの `AmazonRDSCustomServiceRolePolicy` に新しいアクセス許可を追加しました。これらの新しいアクセス許可により、RDS Custom for Oracle は DB スナップショットを使用できるようになります。 詳細については、「[Amazon RDS Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom)」を参照してください。 | 2023 年 6 月 23 日 |
| [Amazon RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`AWSServiceRoleForRDSCustom` サービスにリンクされたロールの `AmazonRDSCustomServiceRolePolicy` に新しいアクセス許可を追加しました。これらの新しいアクセス許可により、RDS Custom for Oracle は DB スナップショットを使用できるようになります。 詳細については、「[Amazon RDS Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom)」を参照してください。 | 2023 年 6 月 23 日 |
| [Amazon RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`AWSServiceRoleForRDSCustom` サービスにリンクされたロールの `AmazonRDSCustomServiceRolePolicy` に新しいアクセス許可を追加しました。これらの新しいアクセス許可により、RDS Custom はネットワークインターフェイスを作成できるようになります。 詳細については、「[Amazon RDS Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom)」を参照してください。 | 2023 年 5 月 30 日 |
| [Amazon RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`AWSServiceRoleForRDSCustom` サービスにリンクされたロールの `AmazonRDSCustomServiceRolePolicy` に新しいアクセス許可を追加しました。これらの新しいアクセス許可により、RDS Custom は Amazon EBS を呼び出してストレージクォータを確認できます。 詳細については、「[Amazon RDS Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom)」を参照してください。 | 2023 年 4 月 18 日 |
| [Amazon RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS Custom は、Amazon SQS との統合のために `AWSServiceRoleForRDSCustom` サービスにリンクされたロールの `AmazonRDSCustomServiceRolePolicy` に新しいアクセス許可を追加しました。RDS Custom では、顧客アカウントで SQS キューを作成および管理するために Amazon SQS との統合が必要です。SQS キュー名は `do-not-delete-rds-custom-[identifier]` という形式に従い、`Amazon RDS Custom` のタグが付けられています。`ec2:CreateSnapshot` のアクセス許可も追加され、RDS Custom がインスタンスにアタッチされたボリュームのバックアップを作成できるようになりました。 詳細については、「[Amazon RDS Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom)」を参照してください。 | 2023 年 4 月 6 日 |
| [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 日 |
| [AWSAmazon RDS の マネージドポリシー](rds-security-iam-awsmanpol.md) – 既存ポリシーへの更新 | Amazon RDS は `AmazonRDSFullAccess` および `AmazonRDSReadOnlyAccess` マネージドポリシーに新しいアクセス許可を追加して、RDS コンソールで Amazon DevOps Guru の検出結果を表示できるようにしました。 このアクセス許可は、DevOps Guru の検出結果を表示できるようにするために必要です。 詳細については、「[Amazon RDS の AWS マネージドポリシーに関する更新](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-manpol-updates.html)」を参照してください。 | 2023 年 3 月 30 日 |
| [Amazon RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、AWS Secrets Manager との統合のために `AWSServiceRoleForRDS` サービスにリンクされたロールの `AmazonRDSServiceRolePolicy` に新しいアクセス許可を追加しました。RDS では、Secrets Manager でマスターユーザーのパスワードを管理するために、Secrets Manager との統合が必要です。シークレットでは予約された命名規則を使用しており、顧客からの更新を制限します。 詳細については、「[Amazon RDS および AWS Secrets Manager によるパスワード管理](rds-secrets-manager.md)」を参照してください。 | 2022 年 12 月 22 日 |
| [Amazon RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`AWSServiceRoleForRDSCustom` サービスにリンクされたロールの `AmazonRDSCustomServiceRolePolicy` に新しいアクセス許可を追加しました。RDS Custom は DB クラスターをサポートします。ポリシー内のこれらの新しいアクセス許可により、RDS Custom は DB クラスターに代わって AWS のサービス を呼び出すことができます。 詳細については、「[Amazon RDS Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom)」を参照してください。 | 2022 年 11 月 9 日 |
| [Amazon RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、`AWSServiceRoleForRDS` との統合のために AWS Secrets Manager サービスにリンクされたロールに新しいアクセス権限を追加しました。 SQL Server Reporting Services (SSRS) の E メールが RDS で機能するには Secrets Manager との統合が必要です。SSRS E メールは顧客に代わってシークレットを作成します。シークレットでは予約された命名規則を使用しており、顧客からの更新を制限します。 詳しくは、「[SSRS E メールを使用してレポートを送信する](SSRS.Email.md)」を参照してください。 | 2022 年 8 月 26 日 |
| [Amazon RDS のサービスにリンクされたロールのアクセス許可](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 RDS のサービスにリンクされたロールのアクセス許可](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 RDS のサービスにリンクされたロールのアクセス許可](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 日 |
| [Amazon RDS のサービスにリンクされたロールのアクセス許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – 既存ポリシーへの更新 | Amazon RDS は、お客様が所有する IP プールおよびローカルゲートウェイルートテーブル (LGW-RTB) の許可を管理するための新しい許可を `AWSServiceRoleForRDS` サービスリンクロールに追加しました。 これらの許可は、Outposts の RDS が Outposts のローカルネットワークでマルチ AZ レプリケーションを実行するために必要です。 詳細については、「[AWS Outposts 上での Amazon RDS のマルチ AZ 配置の使用](rds-on-outposts.maz.md)」を参照してください。 | 2022 年 4 月 19 日 |
| [アイデンティティベースポリシー](UsingWithRDS.IAM.md#security_iam_access-manage-id-based-policies) – 既存ポリシーへの更新 | Amazon RDS は、LGW-RTB に対する許可を記述するための新しい許可を `AmazonRDSFullAccess` マネージドポリシーに追加しました。 これらの許可は、Outposts の RDS が Outposts のローカルネットワークでマルチ AZ レプリケーションを実行するために必要です。 詳細については、「[AWS Outposts 上での Amazon RDS のマルチ AZ 配置の使用](rds-on-outposts.maz.md)」を参照してください。 | 2022 年 4 月 19 日 |
| [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 RDS のサービスにリンクされたロールのアクセス許可](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 Custom のサービスにリンクされたロール許可](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-custom) - 新しいポリシー | Amazon RDS は、`AWSServiceRoleForRDSCustom` という名前の新しいサービスにリンクされたロールを追加して、RDS カスタムが DB インスタンスの代わりに AWS のサービス を呼び出せるようにしました。 | 2021 年 10 月 26 日 |
| 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)
+ [ネイティブバックアップおよび復元用の IAM ロールの手動作成](SQLServer.Procedural.Importing.Native.Enabling.md#SQLServer.Procedural.Importing.Native.Enabling.IAM)
+ [SQL Server DB インスタンスの Windows 認証のセットアップ](USER_SQLServerWinAuth.SettingUp.md)
+ [RDS for SQL Server を S3 と統合するための前提条件](Appendix.SQLServer.Options.S3-integration.preparing.md)
+ [SQL Server Audit の IAM ロールを手動で作成する](Appendix.SQLServer.Options.Audit.IAM.md)
+ [Amazon S3 と RDS for Oracle を統合する IAM アクセス許可の設定](oracle-s3-integration.preparing.md)
+ [Amazon S3 バケットへのアクセスを設定する](USER_PostgreSQL.S3Import.AccessPermission.md) (PostgreSQL のインポート)
+ [Amazon S3 バケットへのアクセスを設定する](postgresql-s3-export-access-bucket.md) (PostgreSQL エクスポート)
# MariaDB、MySQL、および PostgreSQL の IAM データベース認証
AWS Identity and Access Management (IAM) データベース認証を使用して、DB インスタンスを認証できます。IAM データベース認証には、MariaDB、MySQL、および PostgreSQL を使用します。この認証方法では、DB インスタンスに接続するときにパスワードを使用する必要はありません。代わりに、認証トークンを使用します。
*認証トークン*は、Amazon RDS がリクエストに応じて生成する一意の文字列です。認証トークンは、AWS 署名バージョン 4 を使用して生成されます。各トークンには 15 分の有効期間があります。認証は IAM を使用して外部的に管理されるため、ユーザー認証情報をデータベースに保存する必要はありません。引き続きスタンダードのデータベース認証を使用することもできます。トークンは認証にのみ使用され、確立後のセッションには影響しません。
IAM データベース認証には次の利点があります。
+ データベースとの間で送受信されるネットワークトラフィックは、Secure Socket Layer (SSL) または Transport Layer Security (TLS) を使用して暗号化されます。Amazon RDS で 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)
## 利用可能なリージョンとバージョン
機能の可用性とサポートは、各データベースエンジンの特定のバージョンによって異なります。Amazon RDS と IAM データベース認証を使用したエンジン、バージョン、リージョンの可用性の詳細については、「[Amazon RDS での IAM データベース認証でサポートされているリージョンと DB エンジン](Concepts.RDS_Fea_Regions_DB-eng.Feature.IamDatabaseAuthentication.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 ユーザーとしてログインする必要があります。
+ PostgreSQL の場合、Amazon RDS は IAM 認証方法と Kerberos 認証方法両方の同時有効化をサポートしていません。
+ PostgreSQL では、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)」を参照してください。
バースト可能なクラスインスタンスを使用している場合は、バッファやキャッシュなどの他のパラメータで使用されるメモリを同じ量だけ減らして、メモリが不足しないようにします。
+ IAM DB 認証は、どのエンジンの RDS on Outposts でもサポートされていません。
## IAM データベース認証に関する推奨事項
IAM データベース認証を使用する場合には、以下のことをお勧めします。
+ アプリケーションが必要とする新しい IAM データベース認証接続が 1 秒あたり 200 未満の場合は、IAM データベース認証を使用します。
Amazon RDS を使用するデータベースエンジンでは、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 RDS DB インスタンスの作成](USER_CreateDBInstance.md)」を参照してください。
+ DB インスタンスを変更して IAM データベース認証を有効にするには、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
+ IAM データベース認証を有効にしてスナップショットから DB インスタンスを復元するには、「[DB インスタンスへの復元](USER_RestoreFromSnapshot.md)」を参照してください。
+ IAM データベース認証を有効化しながら DB インスタンスを特定の時点に復元するには、「[Amazon RDS の DB インスタンスを特定の時点に復元する](USER_PIT.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 インスタンスが 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. [**DB インスタンスを変更** ] を選択します。
## AWS CLI
AWS CLI を使用して、IAM 認証で新しい DB インスタンスを作成するには、[https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) コマンドを使用します。次の例のように、`--enable-iam-database-authentication` オプションを指定します。
```
aws rds create-db-instance \
--db-instance-identifier mydbinstance \
--db-instance-class db.m3.medium \
--engine MySQL \
--allocated-storage 20 \
--master-username masterawsuser \
--manage-master-user-password \
--enable-iam-database-authentication
```
既存の DB インスタンスを更新して、IAM 認証を使用するかどうかを指定するには、AWS CLI コマンド [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) を使用します。必要に応じて `--enable-iam-database-authentication` または `--no-enable-iam-database-authentication` オプションを指定します。
**注記**
DB インスタンスが IAM 認証と互換性があることを確認します。[利用可能なリージョンとバージョン](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability) の互換性要件を確認する。
デフォルトでは、Amazon RDS は次のメンテナンスウィンドウ中に変更を実行します。これを上書きし、IAM DB 認証をできるだけ早く有効にする場合は、`--apply-immediately` パラメータを使用します。
次の例は、既存の DB インスタンスの IAM 認証をすぐに有効にする方法を示しています。
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--apply-immediately \
--enable-iam-database-authentication
```
DB インスタンスを復元する場合は、次のいずれかの AWS CLI コマンドを使用します。
+ `[restore-db-instance-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-to-point-in-time.html)`
+ `[restore-db-instance-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_CreateDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) を使用します。`EnableIAMDatabaseAuthentication` パラメータを `true` に設定します。
既存の DB インスタンスを更新して、IAM 認証を持つ、または持たないようにするには、API オペレーション [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) を使用します。`EnableIAMDatabaseAuthentication` パラメータを `true` に設定して IAM 認証を有効にするか、`false` に設定して無効にします。
**注記**
DB インスタンスが IAM 認証と互換性があることを確認します。[利用可能なリージョンとバージョン](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability) の互換性要件を確認する。
DB インスタンスを復元する場合は、次のいずれかの API オペレーションを使用します。
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceFromDBSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBInstanceToPointInTime.html)
IAM データベース認証設定は、デフォルトで元のスナップショットの設定になります。この設定を変更するには、`EnableIAMDatabaseAuthentication` パラメータを `true` に設定して IAM 認証を有効にするか、`false` に設定して無効にします。
# IAM データベースアクセス用の IAM ポリシーの作成と使用
ユーザーまたはロールに DB インスタンスへの接続を許可するには、IAM ポリシーを作成する必要があります。その後、ポリシーをアクセス許可セットまたはロールにアタッチします。
**注記**
IAM キーポリシーの詳細については、「[Amazon RDS での 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:db-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:DbiResourceId/db-user-name
```
この形式では、以下のように置き換えます。
+ `region` は、DB インスタンスの AWS リージョンです。このポリシー例での AWS リージョンは `us-east-2` です。
+ `account-id` は DB インスタンスの AWS アカウント番号です。このポリシー例でのアカウント番号は `1234567890` です。ユーザーは DB インスタンスのアカウントと同じアカウントでなければなりません。
クロスアカウントアクセスを実行するには、DB インスタンスのアカウントに上記のポリシーで IAM ロールを作成し、他のアカウントがそのロールを引き継ぐことを許可します。
+ `DbiResourceId` は、DB インスタンスの識別子です。この識別子は AWS リージョンに固有であり、変更されることはありません。このポリシー例での識別子は `db-ABCDEFGHIJKL01234` です。
Amazon RDS 用の DB インスタンスのリソース ID を AWS マネジメントコンソール で検索するには、DB インスタンスを選択して、その詳細を表示します。そして、[**Configuration (設定)**] タブを選択します。[**設定**] セクションに [**リソース ID**] が表示されます。
または、次のように AWS CLI コマンドを使用して、以下に示されているように、現在の AWS リージョンのすべての DB インスタンスの識別子とリソース ID をリストできます。
```
aws rds describe-db-instances --query "DBInstances[*].[DBInstanceIdentifier,DbiResourceId]"
```
Amazon Aurora を使用している場合は、`DbiResourceId` の代わりに `DbClusterResourceId` を指定してください。詳細については、*Amazon Aurora ユーザーガイド*の「[IAM データベースアクセス用の IAM ポリシーの作成と使用](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html)」を参照してください。
**注記**
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:db-ABCDEFGHIJKL01234/jane_doe",
"arn:aws:rds-db:us-east-2:123456789012:dbuser:db-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 RDS のアイデンティティベースのポリシーの例](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:db-12ABC34DEFG5HIJ6KLMNOP78QR/jane_doe
```
ポリシーを *Jane*、*Bob*、*Diego* にアタッチした場合、これらの各ユーザーは、`jane_doe` データベースアカウントを使用して、指定された DB インスタンスに接続できます。
# IAM 認証を使用したデータベースアカウントの作成
IAM データベース認証では、作成するユーザーアカウントにデータベースのパスワードを割り当てる必要はありません。データベースアカウントにマッピングされているユーザーを削除した場合は、`DROP USER` ステートメントでデータベースアカウントも削除する必要があります。
**注記**
IAM 認証に使用されるユーザー名は、データベース内のユーザー名の大文字および小文字と一致する必要があります。
**Topics**
+ [
## MariaDB および MySQL での IAM 認証の使用
](#UsingWithRDS.IAMDBAuth.DBAccounts.MySQL)
+ [
## PostgreSQL での IAM 認証の使用
](#UsingWithRDS.IAMDBAuth.DBAccounts.PostgreSQL)
## MariaDB および MySQL での IAM 認証の使用
MariaDB および MySQL では、認証は、`AWSAuthenticationPlugin` (IAM とシームレスに連携してユーザーを認証する AWS 提供のプラグイン) によって処理されます。DB インスタンスに、マスターユーザーまたはユーザーを作成して権限を付与できる別のユーザーとして接続します。接続後、次の例に示すように、`CREATE USER` ステートメントを発行します。
```
CREATE USER 'jane_doe' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
```
`IDENTIFIED WITH` 句により、MariaDB および 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;
```
## PostgreSQL での IAM 認証の使用
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` ロールを付与する必要があります。ロールのネストされたメンバーシップまたは間接的な付与を使用することもできます。
# 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 RDS に接続するときに、認証トークンを使用できます。トークンを使用することで、コードにパスワードを含めないで済みます。あるいは、AWS SDK を使用して、認証トークンをプログラムで作成して、プログラムで署名することもできます。
IAM 認証トークンに署名した後、Amazon RDS 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 ドライバーの詳細については、使用している [RDS for MariaDB](MariaDB.Connecting.Drivers.md#MariaDB.Connecting.JDBCDriver)、[RDS for MySQL](MySQL.Connecting.Drivers.md#MySQL.Connecting.JDBCDriver)、または [RDS for PostgreSQL](PostgreSQL.Connecting.JDBCDriver.md) DB インスタンスに対応する言語ドライバーを参照してください。
**注記**
RDS for MariaDB でサポートされている機能は、AWS Secrets Manager、AWS Identity and Access Management (IAM)、およびフェデレーティッド ID による認証のみです。
# コマンドラインから IAM 認証を使用して、DB インスタンスに接続する: AWS CLI および mysql クライアント
以下に示すように、AWS CLI および `mysql` コマンドラインツールを使用して、コマンドラインから Amazon RDS 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 証明書ファイルへのフルパス
MariaDB での SSL/TLS サポートについては、「[Amazon RDS 上の MariaDB DB インスタンスの SSL/TLS サポート](MariaDB.Concepts.SSLSupport.md)」を参照してください。
MySQL での SSL/TLS サポートについては、「[Amazon RDS 上の MySQL DB インスタンスの SSL/TLS サポート](MySQL.Concepts.SSLSupport.md)」を参照してください。
SSL 証明書をダウンロードするには [SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照ください。
+ `--enable-cleartext-plugin` - この接続で `AWSAuthenticationPlugin` を使用する必要があることを示す値
MariaDB クライアントを使用している場合、`--enable-cleartext-plugin` オプションは必須ではありません。
+ `--user` - アクセス先のデータベースアカウント
+ `--password` - 署名済みの IAM 認証トークン
認証トークンは数百の文字で構成されます。これは、コマンドラインでは手に負えなくなる可能性があります。この問題を回避する 1 つの方法は、環境可変にトークンを保存し、接続時にその可変を使用することです。次の例は、この回避策を実行する 1 つの方法を示しています。この例では、*/sample\$1dir/* が公開キーを含む SSL 証明書ファイルへのフルパスです。
```
RDSHOST="mysqldb.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 コマンドラインツールを使用して、コマンドラインから Amazon RDS for 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)
+ [
## Amazon RDS PostgreSQL インスタンスへの接続
](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect.PostgreSQL)
## IAM 認証トークンの生成
認証トークンは数百の文字で構成されるため、コマンドラインでは手に負えなくなる可能性があります。この問題を回避する 1 つの方法は、環境可変にトークンを保存し、接続時にその可変を使用することです。次の例では、AWS CLI コマンドを使用して署名された認証トークンを取得するために `generate-db-auth-token` を使用し、`PGPASSWORD` 環境可変に格納する方法を示しています。
```
export RDSHOST="rdspostgres.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` - アクセス先のデータベースアカウント
生成されたトークンの初期の複数の文字は次のようになります。
```
rdspostgres.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 レコードを使用して認証トークンを生成することはできません。
## Amazon RDS 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 証明書ファイルへのフルパス
詳細については、「[PostgreSQL DB インスタンスで SSL を使用する](PostgreSQL.Concepts.General.SSL.md)」を参照してください。
SSL 証明書をダウンロードするには [SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照ください。
+ `dbname` - アクセス先のデータベース
+ `user` - アクセス先のデータベースアカウント
+ `password` - 署名済みの IAM 認証トークン
**注記**
DB インスタンス エンドポイントの代わりに、カスタム Route 53 DNS レコードを使用して認証トークンを生成することはできません。
次の例は、psql を使用して接続する方法を示しています。この例の psql では、環境変数 `RDSHOST` をホスト用に、また、環境変数 `PGPASSWORD` を生成されたトークン用に使用しています。また、*/sample\$1dir/* は公開キーを含む SSL 証明書ファイルへの完全なパスを示します。
```
export RDSHOST="rdspostgres.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 を使用して、RDS for MariaDB、MySQL、または 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 データベースコネクタを使用します。
このコードで MariaDB インスタンスまたは MySQL DB インスタンスに接続します。必要に応じて以下の可変の値を変更します。
+ `server` - アクセス先の DB インスタンスのエンドポイント
+ `user` - アクセス先のデータベースアカウント
+ `database` - アクセス先のデータベース
+ `port` - DB インスタンスへの接続に使用するポート番号
+ `SslMode` - 使用する SSL モード
`SslMode=Required` を使用すると、SSL 接続で DB インスタンスのエンドポイントを SSL 証明書のエンドポイントと照合します。
+ `SslCa` － Amazon RDS の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, "mysqldb.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=mysqldb.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();
}
}
}
```
このコードで PostgreSQL DB インスタンスに接続します。
必要に応じて以下の可変の値を変更します。
+ `Server` - アクセス先の DB インスタンスのエンドポイント
+ `User ID` - アクセス先のデータベースアカウント
+ `Database` - アクセス先のデータベース
+ `Port` - DB インスタンスへの接続に使用するポート番号
+ `SSL Mode` - 使用する SSL モード
`SSL Mode=Required` を使用すると、SSL 接続で DB インスタンスのエンドポイントを SSL 証明書のエンドポイントと照合します。
+ `Root Certificate` － Amazon RDS の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("postgresmydb.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=postgresmydb.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 を使用して、RDS for MariaDB、MySQL、または 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 インスタンスに接続する方法を示します。
このコードで MariaDB インスタンスまたは 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 = "mysqldb.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)
}
}
```
このコードで 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 = "postgresmydb.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 インスタンスに接続する方法を示します。
このコードで MariaDB インスタンスまたは 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 := "mysqldb.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)
}
}
```
このコードで 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 := "postgresmydb.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 を使用して、RDS for MariaDB、MySQL、または 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 インスタンスへの接続
次のコード例では、認証トークンを生成し、それを使用して MariaDB または 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 RDS の中間証明書。(詳細については、[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 RDS の 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) を使用して、RDS for MariaDB、MySQL、または 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 RDS の SSL 証明書へのフルパス
`ssl_ca` を使用する場合、SSL 証明書を指定します。SSL 証明書をダウンロードするには [SSL/TLS を使用した DB インスタンスまたはクラスターへの接続の暗号化](UsingWithRDS.SSL.md) を参照ください。
**注記**
DB インスタンス エンドポイントの代わりに、カスタム Route 53 DNS レコードを使用して認証トークンを生成することはできません。
このコードで MariaDB インスタンスまたは MySQL DB インスタンスに接続します。
このコードを実行する前に、[Python Package Index](https://pypi.org/project/PyMySQL/) の手順に従って PyMySQL ドライバーをインストールしてください。
```
import pymysql
import sys
import boto3
import os
ENDPOINT="mysqldb.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))
```
このコードで PostgreSQL DB インスタンスに接続します。
このコードを実行する前に、[Psycopg documentation](https://pypi.org/project/psycopg2/) の手順に従って `psycopg2` をインストールしてください。
```
import psycopg2
import sys
import boto3
import os
ENDPOINT="postgresmydb.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-instance --db-instance-identifier mydbinstance \
--region us-east-1 \
--db-instance-class db.t3.large \
--allocated-storage 50 \
--engine postgres \
--engine-version 16 \
--port 5432 \
--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-instance --db-instance-identifier mydbinstance \
--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-instances --region us-east-1 --db-instance-identifier mydbinstance
...
"EnabledCloudwatchLogsExports": [
"iam-db-auth-error"
],
...
```
## IAM DB 認証 CloudWatch メトリクス
Amazon RDS は、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/UserGuide/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 RDS のアイデンティティおよびアクセスのトラブルシューティング
次の情報は、Amazon RDS と IAM の使用に伴って発生する可能性がある一般的な問題の診断や修復に役立ちます。
**Topics**
+ [
## Amazon RDS でアクションを実行する権限がありません。
](#security_iam_troubleshoot-no-permissions)
+ [
## iam:PassRole を実行する権限がない
](#security_iam_troubleshoot-passrole)
+ [
## 自分の AWS アカウントの外部のユーザーに Amazon RDS リソースへのアクセスを許可したい
](#security_iam_troubleshoot-cross-account-access)
## Amazon RDS でアクションを実行する権限がありません。
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` アクションを実行する権限がないというエラーが表示された場合、管理者にお問い合わせ、サポートを依頼する必要があります。管理者は、サインイン認証情報を提供した担当者です。Amazon RDS にロールを渡すことができるようにポリシーを更新するよう、管理者に依頼します。
一部の AWS サービスでは、新しいサービスロールまたはサービスにリンクされたロールを作成せずに、既存のロールをサービスに渡すことができます。そのためには、サービスにロールを渡すアクセス許可が必要です。
以下の例のエラーは、`marymajor` という名前のユーザーがコンソールを使用して Amazon RDS でアクションを実行しようとした場合に発生します。ただし、アクションには、サービスロールによってサービスに許可が付与されている必要があります。Mary には、ロールをサービスに渡す許可がありません。
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
この場合、Mary は `iam:PassRole` アクションの実行が許可されるように、担当の管理者にポリシーの更新を依頼します。
## 自分の AWS アカウントの外部のユーザーに Amazon RDS リソースへのアクセスを許可したい
他のアカウントのユーザーや組織外の人が、リソースにアクセスするために使用できるロールを作成できます。ロールの引き受けを委託するユーザーを指定できます。リソースベースのポリシーまたはアクセスコントロールリスト (ACL) をサポートするサービスの場合、それらのポリシーを使用して、リソースへのアクセスを付与できます。
詳細については、以下を参照してください。
+ Amazon RDS でこれらの機能がサポートされるかどうかを確認するには、「[Amazon RDS と 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)を参照してください。
# Amazon RDS でのログ記録とモニタリング
モニタリングは、Amazon RDS と AWS ソリューションの信頼性、可用性、パフォーマンスを維持する上で重要な部分です。マルチポイント障害が発生した場合は、その障害をより簡単にデバッグできるように、AWS ソリューションのすべての部分からモニタリングデータを収集する必要があります。AWS には、Amazon RDS リソースをモニタリングし、潜在的なインシデントに対応するための複数のツールが用意されています。
**Amazon CloudWatch アラーム**
Amazon CloudWatch アラームを使用して、指定した期間中、1 つのメトリクスをモニタリングします。メトリクスが特定の閾値を超えると、Amazon SNS トピックまたは AWS Auto Scaling ポリシーに通知が送信されます。CloudWatch アラームは、特定の状態にあるという理由ではアクションを呼び出しません。状態が変わり、それが指定した期間だけ維持される必要があります。
**AWS CloudTrail ログ**
CloudTrail では、Amazon RDS のユーザー、ロール、または AWS のサービスによって実行されたアクションの記録を確認できます。CloudTrail は、コンソールからの呼び出しと Amazon RDS API オペレーションへのコード呼び出しを含む、Amazon RDS のすべての API コールをイベントとしてキャプチャします。CloudTrail によって収集された情報を使用して、リクエストの作成元の IP アドレス、リクエストの実行者、リクエストの実行日時などの詳細を調べて、Amazon RDS に対してどのようなリクエストが行われたかを判断できます。詳細については、「[AWS CloudTrail での Amazon RDS API コールのモニタリング](logging-using-cloudtrail.md)」を参照してください。
**拡張モニタリング**
Amazon RDS には、DB インスタンスが実行されているオペレーティングシステム (OS) のリアルタイムのメトリクスが用意されています。コンソールで DB インスタンスのメトリクスを表示したり、選択したモニタリングシステムで Amazon CloudWatch Logs からの拡張モニタリング JSON 出力を使用したりできます。詳細については、「[拡張モニタリングを使用した OS メトリクスのモニタリング](USER_Monitoring.OS.md)」を参照してください。
**Amazon RDS Performance Insights**
Performance Insights は、既存の Amazon RDS モニタリング機能を拡張して、データベースのパフォーマンスを明確にし、これに影響を与えるあらゆる問題を分析しやすくします。Performance Insights ダッシュボードを使用してデータベースロードを視覚化したり、ロードを待機、SQL ステートメント、ホスト、ユーザー別にフィルタリングしたりできます。詳細については、「[Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング](USER_PerfInsights.md)」を参照してください。
**データベースのログ**
データベースログを表示、ダウンロード、モニタリングするには、AWS マネジメントコンソール、AWS CLI、または RDS API を使用します。詳細については、「[Amazon RDS ログファイルのモニタリング](USER_LogAccess.md)」を参照してください。
** Amazon RDS の推奨事項**
Amazon RDS は、データベースリソースに対して自動化された推奨事項を示します。これらの推奨事項では、DB インスタンス設定、使用状況、パフォーマンスデータを分析して、ベストプラクティスガイダンスを提供します。詳細については、「[Amazon RDS の推奨事項](monitoring-recommendations.md)」を参照してください。
** Amazon RDS イベントの通知**
Amazon RDS では、Amazon RDS のイベントが発生したときに、Amazon Simple Notification Service (Amazon SNS) を使用して通知を送信します。これらの通知は、AWS リージョンの Amazon SNS でサポートされているすべての通知の形式を使うことができます (E メール、テキストメッセージ、HTTP エンドポイントの呼び出しなど)。詳細については、「[Amazon RDS イベント通知の操作](USER_Events.md)」を参照してください。
**AWS Trusted Advisor**
Trusted Advisor は、AWS の数十万のお客様にサービスを提供することにより得られた、運用実績から学んだベストプラクティスを活用しています。Trusted Advisor はお客様の AWS 環境を検査し、システムの可用性とパフォーマンスを向上させたりセキュリティギャップを埋めたりする機会がある場合には、推奨事項を作成します。すべての AWS のお客様は、Trusted Advisor の 5 つのチェックにアクセスできます。ビジネスまたはエンタープライズサポートプランをご利用のお客様は、すべての Trusted Advisor チェックを表示できます。
Trusted Advisor には、以下を対象とした Amazon RDS 関連のチェックがあります。
+ Amazon RDS アイドル DB インスタンス
+ Amazon RDS セキュリティグループのアクセスリスク
+ Amazon RDS バックアップ
+ Amazon RDS マルチ AZ
これらのチェックの詳細については、「[Trusted Advisor のベストプラクティス (チェック)](https://aws.amazon.com/premiumsupport/trustedadvisor/best-practices/)」を参照してください。
Amazon RDS のモニタリングの詳細については、「[Amazon RDS インスタンスでのメトリクスのモニタリング](CHAP_Monitoring.md)」を参照してください。
# Amazon RDS のコンプライアンス検証
サードパーティーの監査者は、複数の AWS コンプライアンスプログラムの一環として Amazon RDS のセキュリティとコンプライアンスを評価します。このプログラムには、SOC、PCI、FedRAMP、HIPAA などがあります。
特定のコンプライアンスプログラムの範囲内の AWS サービスのリストについては、「[コンプライアンスプログラムによる AWS 対象範囲内のサービス](https://aws.amazon.com/compliance/services-in-scope/)」を参照してください。一般的な情報については、「[AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/)」を参照してください。
AWS Artifact を使用して、サードパーティーの監査レポートをダウンロードできます。詳細については、「[AWS Artifact のレポートのダウンロード](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)」を参照してください。
Amazon RDS を使用する際のお客様のコンプライアンス責任は、データの機密性、組織のコンプライアンス目的、適用法規によって決まります。AWS は、コンプライアンスに役立つ以下のリソースを提供しています。
+ [セキュリティとコンプライアンスのクイックスタートガイド](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) — これらのデプロイガイドでは、アーキテクチャ上の考慮事項について説明し、セキュリティとコンプライアンスに焦点を当てたベースライン環境を AWS にデプロイするためのステップを示します。
+ 「[Architecting for HIPAA Security and Compliance on Amazon Web Services](https://docs.aws.amazon.com/pdfs/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.pdf)」(Amazon Web Services での HIPAA のセキュリティとコンプライアンスのためのアーキテクチャ) – このホワイトペーパーは、企業が AWS を使用して HIPAA 準拠のアプリケーションを作成する方法を説明しています。
+ [AWS コンプライアンスのリソース](https://aws.amazon.com/compliance/resources/) - お客様の業界や地域に当てはまる可能性のあるワークブックやガイドのコレクションです。
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) - この AWS サービスでは、自社プラクティス、業界ガイドライン、および規制に対するリソースの設定の準拠状態を評価します。
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – この AWS のサービス は、AWS 内のセキュリティ状態の包括的なビューを提供します。Security Hub CSPM では、セキュリティコントロールを使用して AWS リソースを評価し、セキュリティ業界標準とベストプラクティスに対するコンプライアンスをチェックします。サポートされているサービスとコントロールの一覧については、「[Security Hub CSPM のコントロールリファレンス](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html)」を参照してください。
# Amazon RDS の耐障害性
AWS のグローバルインフラストラクチャは、AWS リージョンとアベイラビリティーゾーンを中心として構築されています。AWSリージョンには、低レイテンシー、高いスループット、そして高度の冗長ネットワークで接続されている複数の物理的に独立し隔離されたアベイラビリティーゾーンがあります。アベイラビリティーゾーンでは、アベイラビリティーゾーン間で中断せずに、自動的にフェイルオーバーするアプリケーションとデータベースを設計および運用することができます。アベイラビリティーゾーンは、従来の単一または複数のデータセンターインフラストラクチャよりも可用性、耐障害性、およびスケーラビリティが優れています。
AWS リージョンとアベイラビリティーゾーンの詳細については、「[AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)」を参照してください。
Amazon RDS では、AWS グローバルインフラストラクチャに加えて、データの耐障害性とバックアップのニーズに対応するための機能を提供しています。
## バックアップと復元
Amazon RDS は、DB インスタンスの自動バックアップを作成および保存します。Amazon RDS は DB インスタンスのストレージボリュームのスナップショットを作成し、個々のデータベースだけではなく、その DB インスタンス全体をバックアップします。
Amazon RDS は、DB インスタンスのバックアップ期間中に DB インスタンスの自動バックアップを作成します。Amazon RDS は、指定したバックアップ保持期間に従って DB インスタンスの自動バックアップを保存します。必要に応じて、バックアップ保持期間内の任意の時点でデータベースを復旧できます。また、DB スナップショットを手動で作成して、DB インスタンスを手動でバックアップすることもできます。
DB インスタンスを作成するには、ソース DB インスタンスに障害が発生した場合に、災害対策ソリューションとして、この DB スナップショットから復元します。
詳細については、「[データのバックアップ、復元、エクスポート](CHAP_CommonTasks.BackupRestore.md)」を参照してください。
## レプリケーション
Amazon RDS では、MariaDB、MySQL、Oracle、PostgreSQL の DB エンジンの組み込みのレプリケーション機能を使用して、リードレプリカと呼ばれる特殊なタイプの DB インスタンスをソースの DB インスタンスから作成することができます。ソース DB インスタンスに加えられた更新は、リードレプリカに非同期的にコピーされます。読み取りクエリをアプリケーションからリードレプリカにルーティングすることにより、ソース DB インスタンスへの負荷を減らすことができます。リードレプリカを使うと、単一 DB インスタンスの容量制約にとらわれることなく伸縮自在にスケールアウトし、読み取り負荷の高いデータベースワークロードに対応できます。ソース DB インスタンスで障害が発生した場合は、災害対策ソリューションとして、リードレプリカをスタンドアロンインスタンスに昇格させることができます。DB エンジンによっては、Amazon RDS は他にもレプリケーションオプションをサポートしています。
詳細については、「[DB インスタンスのリードレプリカの操作](USER_ReadRepl.md)」を参照してください。
## フェイルオーバー
Amazon RDS は、マルチ AZ 配置を使用して DB インスタンスの高可用性およびフェイルオーバーサポートを提供します。Amazon RDS は複数の異なるテクノロジーを使用してフェイルオーバーサポートを提供します。Oracle、PostgreSQL、MySQL、MariaDB DB インスタンスのマルチ AZ 配置では、Amazon のフェイルオーバーテクノロジーが使用されます。SQL Server DB インスタンスでは SQL Server データベースのミラーリング (DBM) が使用されます。
詳細については、「[Amazon RDS でのマルチ AZ 配置の設定と管理](Concepts.MultiAZ.md)」を参照してください。
# Amazon RDS でのインフラストラクチャセキュリティ
マネージドサービスとして、Amazon Relational Database Service は AWS グローバルネットワークセキュリティによって保護されています。AWS セキュリティサービスと AWS がインフラストラクチャを保護する方法については「[AWS クラウドセキュリティ](https://aws.amazon.com/security/)」を参照してください。インフラストラクチャセキュリティのベストプラクティスを使用して AWS 環境を設計するには「*セキュリティの柱 - AWS 適切なアーキテクチャを備えたフレームワーク*」の「[インフラストラクチャの保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)」を参照してください。
ネットワーク経由で Amazon RDS にアクセスするには、AWS が発行した API コールを使用します。クライアントは以下をサポートする必要があります。
+ Transport Layer Security (TLS)。TLS 1.2 が必須で、TLS 1.3 をお勧めします。
+ DHE (楕円ディフィー・ヘルマン鍵共有) や ECDHE (楕円曲線ディフィー・ヘルマン鍵共有) などの完全前方秘匿性 (PFS) による暗号スイート。これらのモードは Java 7 以降など、ほとんどの最新システムでサポートされています。
また、Amazon RDS には、インフラストラクチャのセキュリティをサポートする機能もあります。
## セキュリティグループ
セキュリティグループにより DB インスタンスに対する送受信トラフィックへのアクセスを制御します。デフォルトでは、ネットワークアクセスは DB インスタンスに対してオフになっています。セキュリティグループで IP アドレス範囲、ポート、またはセキュリティグループからのアクセスを許可するルールを指定できます。Ingress ルールを設定したら、そのセキュリティグループに関連付けられているすべての DB インスタンスに、同じルールが適用されます。
詳しくは、「[セキュリティグループによるアクセス制御](Overview.RDSSecurityGroups.md)」を参照してください。
## パブリックアクセシビリティ
Amazon VPC サービスに基づき、仮想プライベートクラウド (VPC) 内で DB インスタンスを起動する場合は、そのインスタンスのパブリックアクセシビリティをオンまたはオフにすることができます。作成した DB インスタンスにパブリック IP アドレスに解決される DNS 名を含むかどうかを指定するには、*Public accessibility* パラメータを使用します。このパラメータを使用することで、DB インスタンスに対するパブリックアクセスがあるかどうかを指定することができます。*Public accessibility* パラメータを変更することによって、DB インスタンスのパブリックアクセス可能性をオンまたはオフにすることができます。
詳細については、「[VPC 内の DB インスタンスをインターネットから隠す](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding)」を参照してください。
**注記**
DB インスタンスが VPC 内にあるがパブリックアクセス可能でない場合は、AWS Site-to-Site VPN 接続や Direct Connect 接続を使用してプライベートネットワークからアクセスすることもできます。詳しくは、「[ネットワーク間のトラフィックのプライバシー](inter-network-traffic-privacy.md)」を参照してください。
# Amazon RDS API とインターフェイス VPC エンドポイント (AWS PrivateLink)
*インターフェイス VPC エンドポイント*を作成することで、VPC と Amazon RDS API エンドポイント間にプライベート接続を確立できます。インターフェイスエンドポイントは を使用します[AWS PrivateLink](https://aws.amazon.com/privatelink)
AWS PrivateLink を使用すると、インターネットゲートウェイ、NAT デバイス、VPN 接続、または Direct Connect 接続なしで、Amazon RDS API オペレーションにプライベートにアクセスできます。VPC 内の DB インスタンスは、DB インスタンス を起動、変更、または終了するための Amazon RDS API エンドポイントとの通信に、パブリック IP アドレスを必要としません。また、RDS API オペレーションの使用にも、パブリック IP アドレスを必要としません。VPC と Amazon RDS 間のトラフィックは、Amazon ネットワークを離れません。
各インターフェイスエンドポイントは、サブネット内の 1 つ以上の Elastic Network Interface によって表されます。Elastic Network Interface の詳細については、*Amazon EC2 ユーザーガイド*の「[Elastic Network Interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)」を参照してください。
VPC エンドポイントの詳細については、*Amazon VPC ユーザーガイド*の「[インターフェイス VPC エンドポイント (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html)」を参照してください。RDS API オペレーションの詳細については、[Amazon RDS API リファレンス](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/)を参照してください。
DB インスタンスへの接続には、インターフェイス VPC エンドポイントは必要ありません。詳細については、「[VPC の DB インスタンスにアクセスするシナリオ](USER_VPC.Scenarios.md)」を参照してください。
## VPC エンドポイントに関する考慮事項
Amazon RDS API エンドポイントのインターフェイス VPC エンドポイントを設定する前に、*Amazon VPC ユーザーガイド* の「[インターフェイスエンドポイントのプロパティと制限](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations)」を確認してください。
Amazon RDS リソースの管理に関連するすべての RDS API オペレーションは、AWS PrivateLink を使用して VPC から利用することができます。
VPC エンドポイントポリシーは RDS API エンドポイントでサポートされます。デフォルトでは、エンドポイント経由で RDS API オペレーションへのフルアクセスが許可されます。詳細については、*Amazon VPC ユーザーガイド*の「[VPC エンドポイントによるサービスのアクセス制御](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html)」を参照してください。
## 利用可能な状況
現在、Amazon RDS API は、次の AWS リージョンで VPC エンドポイントをサポートしています。
+ 米国東部 (オハイオ)
+ 米国東部 (バージニア北部)
+ 米国西部 (北カリフォルニア)
+ 米国西部 (オレゴン)
+ アフリカ (ケープタウン)
+ アジアパシフィック (香港)
+ アジアパシフィック (ムンバイ)
+ アジアパシフィック (ニュージーランド)
+ アジアパシフィック (大阪)
+ アジアパシフィック (ソウル)
+ アジアパシフィック (シンガポール)
+ アジアパシフィック (シドニー)
+ アジアパシフィック (台北)
+ アジアパシフィック (タイ)
+ アジアパシフィック (東京)
+ カナダ (中部)
+ カナダ西部 (カルガリー)
+ 中国 (北京)
+ 中国 (寧夏)
+ 欧州 (フランクフルト)
+ 欧州 (チューリッヒ)
+ 欧州 (アイルランド)
+ 欧州 (ロンドン)
+ 欧州 (パリ)
+ 欧州 (ストックホルム)
+ 欧州 (ミラノ)
+ イスラエル (テルアビブ)
+ メキシコ (中部)
+ 中東 (バーレーン)
+ 南米 (サンパウロ)
+ AWS GovCloud (米国東部)
+ AWS GovCloud (米国西部)
## Amazon RDS API 用のインターフェイス VPC エンドポイントの作成
Amazon RDS API 用の VPC エンドポイントは、Amazon VPC コンソールまたは AWS Command Line Interface (AWS CLI) で作成できます。詳細については、*Amazon VPC ユーザーガイド*の[インターフェイスエンドポイントの作成](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint)を参照してください。
サービス名 `com.amazonaws.region.rds` を使用して、Amazon RDS API の VPC エンドポイントを作成します。
中国の AWS リージョンを除き、エンドポイントでプライベート DNS を有効にすると、AWS リージョンのデフォルト DNS 名 (`rds.us-east-1.amazonaws.com` など) を使用して、VPC エンドポイントで Amazon RDS に API リクエストを行うことができます。中国 (北京) および 中国 (寧夏) AWS リージョンの場合、それぞれ `rds-api---cn-north-1.amazonaws.com.rproxy.goskope.com.cn` および `rds-api---cn-northwest-1.amazonaws.com.rproxy.goskope.com.cn` を使用して VPC エンドポイントで API リクエストを行うことができます。
詳細については、*Amazon VPC ユーザーガイド* の「[インターフェイスエンドポイントを介したサービスへのアクセス](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint)」を参照してください。
## Amazon RDS API 用の VPC エンドポイントポリシーの作成
VPC エンドポイントに Amazon RDS API へのアクセスを制御するエンドポイントポリシーをアタッチできます。このポリシーでは、以下の情報を指定します。
+ アクションを実行できるプリンシパル。
+ 実行可能なアクション。
+ このアクションを実行できるリソース。
詳細については、*Amazon VPC ユーザーガイド*の「[VPC エンドポイントによるサービスのアクセス制御](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html)」を参照してください。
**例: Amazon RDS API アクションの VPC エンドポイントポリシー**
Amazon RDS API のエンドポイントポリシーの例を次に示します。このポリシーは、エンドポイントにアタッチされると、すべてのリソースのすべてのプリンシパルに対して、登録されている Amazon RDS API アクションへのアクセスを許可します。
```
{
"Statement":[
{
"Principal":"*",
"Effect":"Allow",
"Action":[
"rds:CreateDBInstance",
"rds:ModifyDBInstance",
"rds:CreateDBSnapshot"
],
"Resource":"*"
}
]
}
```
**例: 指定した AWS アカウントからのすべてのアクセスを拒否する VPC エンドポイントポリシー**
以下の VPC エンドポイントポリシーは、AWS アカウント `123456789012` からリソースへのエンドポイントを使用したすべてのアクセスを拒否します。このポリシーは、他のアカウントからのすべてのアクションを許可します。
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": { "AWS": [ "123456789012" ] }
}
]
}
```
# Amazon RDS のセキュリティのベストプラクティス
AWS Identity and Access Management (IAM) アカウントを使用して、Amazon RDS API オペレーション、特に Amazon RDS リソースの作成、変更、削除を行うオペレーションへのアクセスを制御します。そのようなリソースには、DB インスタンス、セキュリティグループ、およびパラメータグループなどがあります。また、IAM を使用して、DB インスタンスのバックアップや復元など、一般的な管理アクションを実行するアクションも制御します。
+ Amazon RDS リソースを管理するユーザー (本人を含む) ごとに個別のユーザーを作成します。Amazon RDS リソースの管理には、AWS ルート認証情報を使用しないでください。
+ それぞれの職務の実行に最低限必要になる一連のアクセス許可を各ユーザーに付与します。
+ IAM グループを使用して、複数のユーザーのアクセス許可を効果的に管理します。
+ IAM 認証情報のローテーションを定期的に行います。
+ Amazon RDS のシークレットが自動的にローテーションされるように､AWS Secrets Manager を設定します。詳細については、*AWS Secrets Manager ユーザーガイド*の「[AWS Secrets Manager シークレットのローテーション](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)」を参照してください。認証情報は、AWS Secrets Manager プログラムから取得することもできます。詳細については、*AWS Secrets Manager ユーザーガイド*の「[シークレット値の取得](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html)」を参照してください。
Amazon RDS でのセキュリティの詳細については、「[Amazon RDS でのセキュリティ](UsingWithRDS.md)」を参照してください。IAM の詳細については、「[AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/Welcome.html)」を参照してください。IAM のベストプラクティスについては、「[IAM のベストプラクティス](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html)」を参照してください。
AWS Security Hub CSPM は、セキュリティコントロールを使用してリソース設定とセキュリティ標準を評価し、お客様がさまざまなコンプライアンスフレームワークに準拠できるようサポートします。Security Hub CSPM を使用して RDS リソースを評価する方法の詳細については、「AWS Security Hub ユーザーガイド」の「[Amazon リレーショナルデータベースサービスコントロール](https://docs.aws.amazon.com/securityhub/latest/userguide/rds-controls.html)」を参照してください。
Security Hub CSPM を使用して、セキュリティのベストプラクティスに関連する RDS の使用状況をモニタリングできます。詳細については、「[What is AWS Security Hub CSPM?](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)」を参照してください。
AWS マネジメントコンソール、AWS CLI、RDS API を使用して、マスターユーザーのパスワードを変更します。SQL クライアントなどの別のツールを使用する場合、マスターユーザーのパスワードを変更すると、ユーザーの権限が意図せずに取り消される可能性があります。
# セキュリティグループによるアクセス制御
VPC セキュリティグループにより DB インスタンスに対する送受信トラフィックへのアクセスを制御します。デフォルトでは、ネットワークアクセスは DB インスタンスに対してオフになっています。セキュリティグループで IP アドレス範囲、ポート、またはセキュリティグループからのアクセスを許可するルールを指定できます。Ingress ルールを設定したら、そのセキュリティグループに関連付けられているすべての DB インスタンスに、同じルールが適用されます。セキュリティグループでは最大 20 のルールを指定できます。
## VPC セキュリティグループの概要
VPC セキュリティグループの各ルールにより、特定のソースがその VPC セキュリティグループに関連付けられている VPC 内の DB インスタンスにアクセスできるようになります。ソースとしては、アドレスの範囲 (203.0.113.0/24 など) または別の VPC セキュリティグループを指定できます。VPC セキュリティグループをソースとして指定すると、ソース VPC セキュリティグループを使用するすべてのインスタンス (通常はアプリケーションサーバー) からの受信トラフィックを許可することになります。VPC セキュリティグループには、インバウンドトラフィックとアウトバウンドトラフィック両方を制御するルールを追加できます。ただし、アウトバウンドトラフィックのルールは通常、DB インスタンスには適用されません。送信トラフィックのルールは、DB インスタンスがクライアントである場合にのみ適用されます。例えば、送信トラフィックのルールは送信データベースリンクがある Oracle DB インスタンスに適用されます。VPC セキュリティグループを作成するには、「[Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Welcome.html)」を使用するか、VPC コンソールの **[Security Group]** (セキュリティグループ) オプションを使用する必要があります。
VPC 内のインスタンスへのアクセスを許可する VPC セキュリティグループのルールを作成するときは、そのルールがアクセスを許可するアドレスの範囲ごとにポートを指定する必要があります。例えば、VPC 内のインスタンスへの Secure Shell (SSH) アクセスをオンにするには、指定したアドレスの範囲の TCP ポート 22 に対するアクセスを許可するルールを作成します。
VPC 内の異なるインスタンスに対する異なるポートへのアクセスを許可する複数の VPC セキュリティグループを設定できます。例えば、VPC のウェブサーバーに TCP ポート 80 へのアクセスを許可する VPC セキュリティグループを作成できます。次に、VPC の RDS for MySQL DB インスタンスの TCP ポート 3306 へのアクセスを許可する別の VPC セキュリティグループを作成できます。
VPC セキュリティグループの詳細については、*Amazon Virtual Private Cloud ユーザーガイド*の「[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。
**注記**
DB インスタンスが VPC 内にあるが、パブリックアクセス可能でない場合は、AWS Site-to-Site VPN 接続または Direct Connect 接続を使用してプライベートネットワークからアクセスすることもできます。詳細については、「[ネットワーク間のトラフィックのプライバシー](inter-network-traffic-privacy.md)」を参照してください。
## セキュリティグループのシナリオ
VPC 内の DB インスタンスの一般的な用途は、同じ VPC 内の Amazon EC2 インスタンスで実行され、VPC の外にあるクライアントアプリケーションによってアクセスされるアプリケーションサーバーとデータを共有することです。このシナリオでは、AWS マネジメントコンソールの RDS および VPC ページ、または RDS および EC2 API オペレーションを使用して、必要なインスタンスおよびセキュリティグループを作成します。
1. VPC セキュリティグループ (「`sg-0123ec2example`」など) を作成し、ソースとしてクライアントアプリケーションの IP アドレスを使用するという受信ルールを定義します。このセキュリティグループにより、クライアントアプリケーションは、このセキュリティグループを使用する VPC 内の EC2 インスタンスに接続できるようになります。
1. アプリケーションの EC2 インスタンスを作成し、前のステップで作成した VPC セキュリティグループ (「`sg-0123ec2example`」) に EC2 インスタンスを追加します。
1. 2 つ目の VPC セキュリティグループ (「`sg-6789rdsexample`」など) を作成し、ステップ 1 で作成した VPC セキュリティグループ (「`sg-0123ec2example`」) をソースとして指定して新しいルールを作成します。
1. 新しい DB インスタンスを作成し、その DB インスタンスを前のステップで作成した VPC セキュリティグループ (`sg-6789rdsexample`) に追加します。DB インスタンスを作成するとき、ステップ 3 で作成した VPC セキュリティグループ (`sg-6789rdsexample`) のルールに指定した同じポート番号を使用します。
以下の図に、このシナリオを示しています。
![\[VPC 内の DB インスタンスと EC2 インスタンス\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/images/con-VPC-sec-grp.png)
このシナリオの VPC 設定の手順の詳細については、「[チュートリアル: DB インスタンスで使用する VPC を作成する (IPv4 専用)](CHAP_Tutorials.WebServerDB.CreateVPC.md)」を参照してください。VPC の使用に関する詳細については、「[Amazon VPC と Amazon RDS](USER_VPC.md)」を参照してください。
## VPC セキュリティグループを作成する
DB インスタンスの VPC セキュリティグループは、VPC コンソールを使って作成できます。セキュリティグループを作成する方法については、*Amazon Virtual Private Cloud ユーザーガイド*の「[セキュリティグループを作成して VPC 内の DB インスタンスへのアクセスを提供する](CHAP_SettingUp.md#CHAP_SettingUp.SecurityGroup)」および「[セキュリティグループ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)」を参照してください。
## セキュリティグループを DB インスタンスと関連付ける
RDS コンソールの [**変更**]、`ModifyDBInstance` Amazon RDS API、または `modify-db-instance` AWS CLI コマンドを使用して、セキュリティグループを DB インスタンスに関連付けることができます。
次の CLI の例では、特定の VPC セキュリティグループを関連付け、DB インスタンスから DB セキュリティグループを削除します。
```
aws rds modify-db-instance --db-instance-identifier dbName --vpc-security-group-ids sg-ID
```
DB インスタンスの変更の詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。DB スナップショットから DB インスタンスを復元するときのセキュリティグループの考慮事項については、「[セキュリティグループに関する考慮事項](USER_RestoreFromSnapshot.md#USER_RestoreFromSnapshot.Security)」を参照してください。
**注記**
ポート値がデフォルト以外の値に設定されている場合、RDS コンソールにはデータベースのさまざまなセキュリティグループルール名が表示されます。
RDS for Oracle DB インスタンスでは、Oracle Enterprise Manager Database Express (OEM)、Oracle Management Agent for Enterprise Manager Cloud Control (OEM Agent)、および Oracle Secure Sockets Layer オプションのセキュリティグループオプション設定を入力することで、追加のセキュリティグループを関連付けることができます。この場合、DB インスタンスに関連付けられているセキュリティグループとオプション設定の両方が DB インスタンスに適用されます。これらのオプショングループの詳細については、「[Oracle Enterprise Manager](Oracle.Options.OEM.md)」、「[Enterprise Manager Cloud Control 向け Oracle Management Agent](Oracle.Options.OEMAgent.md)」、「[Oracle Secure Sockets Layer](Appendix.Oracle.Options.SSL.md)」を参照してください。
# マスターユーザーアカウント権限
新しい DB インスタンスを作成すると、使用するデフォルトマスターユーザーがその DB インスタンスの特定の権限を取得します。DB インスタンスの作成後にマスターユーザー名を変更することはできません。
**重要**
アプリケーションではマスターユーザーを直接使用しないことを強くお勧めします。代わりに、アプリケーションに必要な最小の特権で作成されたデータベースユーザーを使用するというベストプラクティスに従ってください。
**注記**
マスターユーザーのアクセス許可を誤って削除した場合は、DB インスタンスを変更して新しいマスターユーザーパスワードを設定することで復元できます。DB インスタンスの変更の詳細については、「[Amazon RDS DB インスタンスを変更する](Overview.DBInstance.Modifying.md)」を参照してください。
次の表は、各データベースエンジンに対してマスターユーザーが取得する権限とデータベースロールを示しています。
| データベースエンジン | システム権限 | データベースロール |
| --- | --- | --- |
| RDS for Db2 | マスターユーザーは `masterdba` グループに割り当てられ、`master_user_role` が割り当てられます。 `SYSMON`、`DATAACCESS` 付き `DBADM`、および `ACCCESSCTRL`、`BINDADD`、`CONNECT`、`CREATETAB`、`CREATE_SECURE_OBJECT`、`EXPLAIN`、`IMPLICIT_SCHEMA`、`LOAD`、`SQLADM`、`WLMADM` | `DBA`,`DBA_RESTRICTED`, `DEVELOPER`,`ROLE_NULLID_PACKAGES`, `ROLE_PROCEDURES`,`ROLE_TABLESPACES` 詳細については、「[Amazon RDS for Db2 のデフォルトロール](db2-default-roles.md)」を参照してください。 |
| RDS for MariaDB | `SELECT`,`INSERT`,`UPDATE`,`DELETE`, `CREATE`,`DROP`,`RELOAD`, `PROCESS`,`REFERENCES`,`INDEX`, `ALTER`,`SHOW DATABASES`,`CREATE TEMPORARY TABLES`,`LOCK TABLES`, `EXECUTE`,`REPLICATION CLIENT`,`CREATE VIEW`,`SHOW VIEW`,`CREATE ROUTINE`, `ALTER ROUTINE`,`CREATE USER`, `EVENT`,`TRIGGER`,`REPLICATION SLAVE` RDS for MariaDB バージョン 11.4 以降、マスターユーザーには `SHOW CREATE ROUTINE` 権限も付与されます。 | — |
| RDS for MySQL バージョン 8.0.36 以上 | `SELECT`,`INSERT`,`UPDATE`, `DELETE`,`CREATE`,`DROP`, `RELOAD`,`PROCESS`, `REFERENCES`,`INDEX`,`ALTER`, `SHOW DATABASES`,`CREATE TEMPORARY TABLES`,`LOCK TABLES`,`EXECUTE`, `REPLICATION SLAVE`,`REPLICATION CLIENT`, `CREATE VIEW`,`SHOW VIEW`,`CREATE ROUTINE`,`ALTER ROUTINE`,`CREATE USER`,`EVENT`,`TRIGGER`, `CREATE ROLE`,`DROP ROLE`, `APPLICATION_PASSWORD_ADMIN`, `ROLE_ADMIN`,`SET_USER_ID`, `XA_RECOVER_ADMIN` | `rds_superuser_role` `rds_superuser_role` の詳細については、「[RDS for MySQL のロールベースの権限モデル](Appendix.MySQL.CommonDBATasks.privilege-model.md)」を参照してください。 |
| RDS for MySQL バージョン 8.0.36 未満 | `SELECT`,`INSERT`,`UPDATE`, `DELETE`,`CREATE`,`DROP`, `RELOAD`,`PROCESS`, `REFERENCES`,`INDEX`,`ALTER`, `SHOW DATABASES`,`CREATE TEMPORARY TABLES`,`LOCK TABLES`,`EXECUTE`, `REPLICATION CLIENT`,`CREATE VIEW`, `SHOW VIEW`,`CREATE ROUTINE`,`ALTER ROUTINE`,`CREATE USER`,`EVENT`, `TRIGGER`,`REPLICATION SLAVE` | — |
| RDS for PostgreSQL | `CREATE ROLE`,`CREATE DB`, `PASSWORD VALID UNTIL INFINITY`,`CREATE EXTENSION`,`ALTER EXTENSION`,`DROP EXTENSION`,`CREATE TABLESPACE`,`ALTER