Amazon Aurora アイデンティティベースのポリシーの例 - Amazon Aurora

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

デフォルトでは、IAM ユーザーおよびロールには、Aurora リソースを作成または変更するアクセス許可はありません。また、AWS Management Console や AWS CLI、AWS API を使用してタスクを実行することもできません。IAM 管理者は、ユーザーとロールに必要な、指定されたリソースで特定の API オペレーションを実行するアクセス許可をユーザーとロールに付与する IAM ポリシーを作成する必要があります。続いて、管理者はそれらのアクセス許可が必要な IAM ユーザーまたはグループにそのポリシーを添付します。

これらの JSON ポリシードキュメント例を使用して IAM のアイデンティティベースのポリシーを作成する方法については、IAM ユーザーガイドJSON タブでのポリシーの作成を参照してください。

ポリシーのベストプラクティス

ID ベースのポリシーは非常に強力です。アカウント内で、Aurora リソースを作成、アクセス、または削除できるかどうかを決定します。これらのアクションを実行すると、AWS アカウントに追加料金が発生する可能性があります。アイデンティティベースのポリシーを作成または編集するときは、以下のガイドラインと推奨事項に従います。

  • AWS 管理ポリシーを使用してスタートする - Aurora の使用をすばやくスタートするには、AWS 管理ポリシーを使用して、従業員に必要なアクセス許可を付与します。これらのポリシーはアカウントで既に有効になっており、AWS によって管理および更新されています。詳細については、「IAM ユーザーガイド」の「AWS マネージドポリシー」を使用した許可の使用スタート」を参照してください。

  • 最小特権を付与する - カスタムポリシーを作成するときは、タスクを実行するために必要なアクセス許可のみを付与します。最小限の許可からスタートし、必要に応じて追加の許可を付与します。この方法は、寛容過ぎる許可で始め、後でそれらを強化しようとするよりも安全です。詳細については、「IAM ユーザーガイド」の「最小特権を認める」を参照してください。

  • 機密性の高いオペレーションに MFA を有効にする - 追加セキュリティとして、機密性の高リソースまたは API オペレーションにアクセスするために IAM ユーザーに対して、多要素認証 (MFA) の使用を要求します。詳細については、「IAM ユーザーガイド」の「AWS での多要素認証 (MFA) の使用」を参照してください。

  • 追加セキュリティに対するポリシー条件を使用する - 実行可能な範囲内で、アイデンティティベースのポリシーがリソースにアクセスできる条件を定義します。例えば、リクエストが発生しなければならない許容 IP アドレスの範囲を指定するための条件を記述できます。指定された日付または時間範囲内でのみリクエストを許可する条件を書くことも、SSL や MFA の使用を要求することもできます。詳細については、「IAM ユーザーガイド」の「IAM JSON ポリシー要素: 条件」を参照してください。

Aurora コンソールの使用

Amazon Aurora コンソールにアクセスするには、一連の最小限のアクセス許可が必要です。これらのアクセス許可により、AWS アカウントの Aurora リソースの詳細をリストおよび表示できるようにする必要があります。最低限必要なアクセス許可よりも制限的なアイデンティティベースのポリシーを作成することができます。ただし、作成した場合、コンソールでは、そのポリシーがアタッチされたエンティティ (IAM ユーザーまたはロール) 用に意図したとおりに動作しません。

これらのエンティティが Aurora コンソールを引き続き使用できるように、エンティティに次の AWS 管理ポリシーもアタッチします。詳細については、IAM ユーザーガイド の「ユーザーへのアクセス許可の追加」を参照してください。

AmazonRDSReadOnlyAccess

AWS CLI または AWS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。代わりに、実行しようとしている API オペレーションに一致するアクションのみへのアクセスが許可されます。

ユーザーが自分の許可を表示できるようにする

この例では、ユーザー ID にアタッチされたインラインおよび管理ポリシーの表示を 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": "*" } ] }

AWS アカウントでの DB インスタンスの作成をユーザーに許可する

以下は、123456789012 アカウントで ID が AWS のユーザーが DB インスタンスを作成できるようにするポリシーの例です。ポリシーは、test で始める新しい DB インスタンスの名前である必要があります。また、新しい DB インスタンスは、MySQL データベースエンジンと DB インスタンスの db.t2.micro クラスを使用する必要があります。さらに、新しい DB インスタンスでは、オプショングループと default で始まる DB パラメータグループ、および default サブネットグループを使用する必要があります。

{ "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" } } } ] }

ポリシーには、IAM ユーザー用の以下のアクセス許可を指定する単一のステートメントが含まれます。

  • ポリシーを使用すると、IAM ユーザーは CreateDBInstance API オペレーションを使用して DB インスタンスを作成できます (これは create-db-instance AWS CLI コマンドと AWS Management Console にも適用されます)。

  • Resource 要素では、ユーザーがリソースでアクションを実行できることを指定できます。Amazon Resources Name (ARN) を使用してリソースを指定します。この ARN には、リソースが属しているサービスの名前 (rds)、AWS リージョン (* はこの例のリージョンを示します)、ユーザーアカウント番号 (123456789012 はこの例のユーザー ID です)、およびリソースのタイプが含まれます。ARN の作成の詳細については、「Amazon RDS の Amazon リソースネーム (ARN) の使用」を参照してください。

    例の Resource 要素は、ユーザーのリソースで、以下のポリシーの制約を指定します。

    • 新しい DB インスタンスの DB インスタンス識別子は、test で始まる必要があります (例: testCustomerData1test-region2-data)。

    • 新しい DB インスタンスのオプショングループは、default で始まる必要があります。

    • 新しい DB インスタンスの DB パラメータグループは、default で始まる必要があります。

    • 新しい DB インスタンスのサブネットグループは、default サブネットグループである必要があります。

  • Condition 要素は、DB エンジンが MySQL で、DB インスタンスクラスが db.t2.micro である必要があることを指定します。Condition 要素は、ポリシーが有効になる条件を指定します。Condition 要素を使用して、アクセス許可または制約を追加できます。条件を指定する方法については、「条件キー」を参照してください。この例では、rds:DatabaseEngine および rds:DatabaseClass を条件として指定します。rds:DatabaseEngine の有効な条件値については、CreateDBInstanceEngine パラメータのリストを参照してください。rds:DatabaseClass の有効な条件値については、「DB インスタンスクラスでサポートされている DB エンジン」を参照してください。

アイデンティティベースのポリシーでアクセス権限を得るプリンシパルを指定していないため、ポリシーでは Principal 要素を指定していません。ユーザーにポリシーをアタッチすると、そのユーザーが暗黙のプリンシパルになります。IAM ロールにアクセス権限ポリシーをアタッチすると、ロールの信頼ポリシーで識別されたプリンシパルがアクセス権限を得ることになります。

Aurora アクションのリストを確認するには、サービス認証リファレンスの「Amazon RDS で定義されるアクション」を参照してください。

コンソールの使用に必要なアクセス許可

コンソールを使用するユーザーには、最小限のアクセス許可のセットが必要です。これらのアクセス許可により、ユーザーは AWS アカウントの Amazon Aurora リソースを記述し、Amazon EC2 セキュリティやネットワーク情報など、その他の関連情報を提供できます。

これらの最小限必要なアクセス権限よりも制限された IAM ポリシーを作成している場合、その IAM ポリシーを使用するユーザーに対してコンソールは意図したとおりには機能しません。「AmazonRDSReadOnlyAccess」で説明されているとおり、ユーザーがコンソールを使用できること、および ポリシーを使用したアクセスの管理 管理ポリシーがユーザーにアタッチされていることを確認してください。

AWS CLI または Amazon RDS API のみを呼び出すユーザーには、最小限のコンソールアクセス許可を付与する必要はありません。

以下のポリシーでは、ルート AWS アカウントの Amazon Aurora リソースへのフルアクセスが付与されます。

AmazonRDSFullAccess

RDS リソースに対する Describe アクションの実行をユーザーに許可する

以下のアクセス権限ポリシーは、Describe で始まるすべてのアクションを実行するためのアクセス権限をユーザーに付与します。これらのアクションは、DB インスタンスなど RDS リソースに関する情報を表示します。Resource 要素内のワイルドカード文字 (*) は、アカウントによって所有されるすべての Amazon Aurora リソースに対してそれらのアクションが許可されることを示します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowRDSDescribe", "Effect": "Allow", "Action": "rds:Describe*", "Resource": "*" } ] }

指定した DB パラメータグループとサブネットグループを使用する DB インスタンスの作成をユーザーに許可する

以下の許可ポリシーは、mydbpg DB パラメータグループと mydbsubnetgroup DB サブネットグループを使用する必要のある DB インスタンスを作成することのみをユーザーに許可するための許可を付与します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "rds:CreateDBInstance", "Resource": [ "arn:aws:rds:*:*:pg:mydbpg", "arn:aws:rds:*:*:subgrp:mydbsubnetgroup" ] } ] }

2 つの異なる値を持つタグが付いたリソースに対するアクションにアクセス許可を付与する

アイデンティティベースのポリシーの条件を使用して、タグに基づいて Aurora リソースへのアクセスを制御できます。以下のポリシーでは、stage タグが development または test に設定された DB インスタンスで ModifyDBInstance および CreateDBSnapshot API を実行するためのアクセス許可を付与しています。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowDevTestCreate", "Effect": "Allow", "Action": [ "rds:ModifyDBInstance", "rds:CreateDBSnapshot" ], "Resource": "*", "Condition": { "StringEquals": { "rds:db-tag/stage": [ "development", "test" ] } } } ] }

ユーザーによる DB インスタンスの削除を禁止する

以下のアクセス権限ポリシーは、特定の DB インスタンスを削除することをユーザーに禁止するためのアクセス権限を付与します。例えば、管理者以外のすべてのユーザーに対して、本稼働 DB インスタンスの削除を拒否することができます。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyDelete1", "Effect": "Deny", "Action": "rds:DeleteDBInstance", "Resource": "arn:aws:rds:us-west-2:123456789012:db:my-mysql-instance" } ] }

リソースへのすべてのアクセスを拒否する

リソースへのアクセスを明示的に拒否できます。拒否ポリシーは許可ポリシーよりも優先されます。以下のポリシーは、リソースを管理する機能をユーザーに明示的に拒否します。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "rds:*", "Resource": "arn:aws:rds:us-east-1:123456789012:db:mydb" } ] }

ポリシー例: 条件キーの使用

以下に示しているのは、Amazon Aurora IAM アクセス許可ポリシーでの条件キーの使用例です。

例 1: 特定の DB エンジンを使用し、マルチ AZ ではない DB インスタンスを作成するためのアクセス許可を付与する

以下のポリシーでは、RDS 条件キーを使用して、MySQL データベースエンジンを使用するがマルチ AZ でない DB インスタンスのみをユーザーが作成できるようにします。Condition 要素では、データベースエンジンが MySQL であることが要件になることを示しています。

{ "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.8xlargem4.10xlarge を使用する DB インスタンスの作成のためのアクセス許可を明示的に拒否しています。このポリシーでは、追加のコストが発生するプロビジョンド IOPS を使用する DB インスタンスの作成もユーザーに禁止しています。

明示的に拒否するアクセス権限は、付与する他のいずれのアクセス権限よりも優先されます。これにより、決して付与されることのないアクセス権限を ID が誤って取得することがなくなります。

{ "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 を持つタグの追加を値 testqa、および production を持つリソースに追加することができます。

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "rds:AddTagsToResource", "rds:RemoveTagsFromResource" ], "Resource": "*", "Condition": { "streq": { "rds:req-tag/stage": [ "test", "qa", "production" ] } } } ] }

条件の指定: カスタムタグの使用

Amazon Aurora では、カスタムタグを使用して IAM ポリシーで条件を指定することがサポートされています。

例えば、environment という名前のタグを、betastagingproduction などの値で DB インスタンスに追加するとします。追加する場合、特定のユーザーを environment タグ値に基づく DB インスタンスに制限するポリシーを作成することができます。

注記

カスタムタグ識別子は大文字と小文字が区別されます。

以下の表では、Condition 要素で使用できる RDS タグ識別子を示しています。

RDS タグ識別子 Applies to
db-tag リードレプリカを含む DB インスタンス
snapshot-tag DB スナップショット
ri-tag リザーブド DB インスタンス
secgrp-tag DB セキュリティグループ
og-tag DB オプショングループ
pg-tag DB パラメータグループ
subgrp-tag DB サブネットグループ
es-tag イベントサブスクリプション
cluster-tag DB クラスター
cluster-pg-tag DB クラスターのパラメータグループ
cluster-snapshot-tag DB クラスタースナップショット

カスタムタグの条件の構文は次のとおりです。

"Condition":{"StringEquals":{"rds:rds-tag-identifier/tag-name": ["value"]} }

例えば、次の Condition 要素は、environment という名前のタグを持ち、タグの値が production である DB インスタンスに適用されます。

"Condition":{"StringEquals":{"rds:db-tag/environment": ["production"]} }

タグの作成の詳細については、「Amazon RDS リソースのタグ付け」を参照してください。

重要

タグを使用して RDS リソースへのアクセスを管理する場合は、RDS リソースのタグへのアクセスを保護することをお勧めします。AddTagsToResource および RemoveTagsFromResource アクションのポリシーを作成することによって、タグへのアクセスを管理できます。例えば、次のポリシーは、ユーザーがすべてのリソースのタグを追加または削除することを拒否します。次に、特定のユーザーがタグを追加または削除することを許可するポリシーを作成できます。

{ "Version":"2012-10-17", "Statement":[ { "Sid":"DenyTagUpdates", "Effect":"Deny", "Action":[ "rds:AddTagsToResource", "rds:RemoveTagsFromResource" ], "Resource":"*" } ] }

Aurora アクションのリストを確認するには、サービス認証リファレンスの「Amazon RDS で定義されるアクション」を参照してください。

ポリシー例: カスタムタグの使用

以下に示しているのは、Amazon Aurora IAM アクセス許可ポリシーでのカスタムタグの使用例です。Amazon Aurora リソースへのタグの追加の詳細については、「Amazon RDS の Amazon リソースネーム (ARN) の使用」を参照してください。

注記

すべての例で、us-west-2 リージョンを使用し、架空のアカウント ID を含めています。

例 1: 2 つの異なる値を持つタグが付いたリソースに対するアクションにアクセス許可を付与する

以下のポリシーでは、stage タグが development または test に設定された DB インスタンスで ModifyDBInstance および CreateDBSnapshot API を実行するためのアクセス許可を付与しています。

{ "Version":"2012-10-17", "Statement":[ { "Sid":"AllowDevTestCreate", "Effect":"Allow", "Action":[ "rds:ModifyDBInstance", "rds:CreateDBSnapshot" ], "Resource":"*", "Condition":{ "StringEquals":{ "rds:db-tag/stage":[ "development", "test" ] } } } ] }

例 2: 指定した DB パラメータグループを使用する DB インスタンスを作成するためのアクセス許可を明示的に拒否する

以下のポリシーでは、特定のタグ値が設定された DB パラメータグループを使用する DB インスタンスの作成のためのアクセス権限を明示的に拒否しています。DB インスタンスを作成するときに特定のユーザー定義の DB パラメータグループの使用を必須とする場合にも、このポリシーを適用できます。Deny を使用するポリシーは、ほとんどの場合、適用範囲のより広いポリシーによって付与されるアクセス許可を制限するために使用します。

明示的に拒否するアクセス権限は、付与する他のいずれのアクセス権限よりも優先されます。これにより、決して付与されることのないアクセス権限を ID が誤って取得することがなくなります。

{ "Version":"2012-10-17", "Statement":[ { "Sid":"DenyProductionCreate", "Effect":"Deny", "Action":"rds:CreateDBInstance", "Resource":"*", "Condition":{ "StringEquals":{ "rds:pg-tag/usage":"prod" } } } ] }

例 3: インスタンス名にユーザー名がプレフィックスとして付加されている DB インスタンスに対するアクションにアクセス許可を付与する

以下のポリシーでは、DB インスタンス名の前にユーザー名が付いている DB インスタンスのうち、AddTagsToResource と同等の RemoveTagsFromResource というタグが付いているか、または stage というタグが付いていない DB インスタンスに対する、API (devo または stage を除く) の呼び出しのためのアクセス権限を付与しています。

ポリシーの Resource 行では、リソースをその Amazon Resource Name (ARN) により識別しています。ARN と Amazon Aurora リソースの使用の詳細については、「Amazon RDS の Amazon リソースネーム (ARN) の使用」を参照してください。

{ "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" } } } ] }