Amazon Relational Database Service
Guide de l'utilisateur (Version de l'API 2014-10-31)

Exemples de stratégies basées sur l'identité Amazon RDS

Par défaut, les utilisateurs et les rôles IAM ne sont pas autorisés à créer ou modifier les ressources Amazon RDS. Ils ne peuvent pas non plus exécuter des tâches à l'aide de AWS Management Console, AWS CLI ou de l'API AWS. Un administrateur IAM doit créer des stratégies IAM autorisant les utilisateurs et les rôles à exécuter des opérations d'API spécifiques sur les ressources spécifiées dont ils ont besoin. Il doit ensuite attacher ces stratégies aux utilisateurs ou aux groupes IAM ayant besoin de ces autorisations.

Pour apprendre à créer une stratégie basée sur l’identité IAM à l'aide de ces exemples de document de stratégie JSON, consultez Création de stratégies dans l'onglet JSON dans le IAM Guide de l'utilisateur.

Bonnes pratiques en matière de stratégies

Les stratégies basées sur l'identité sont très puissantes. Elles déterminent si une personne peut créer, consulter ou supprimer des ressources Amazon RDS dans votre compte. Ces actions peuvent entraîner des frais pour votre compte AWS. Lorsque vous créez ou modifiez des stratégies basées sur l'identité, suivez ces instructions et recommandations :

  • Commencer à utiliser des stratégies gérées AWS – Pour commencer à utiliser Amazon RDS rapidement, utilisez les politiques gérées AWS pour accorder à vos employés les autorisations dont ils ont besoin. Ces stratégies sont déjà disponibles dans votre compte et sont gérées et mises à jour par AWS. Pour plus d'informations, consultez la section Mise en route avec les autorisations à l'aide des stratégies gérées AWS dans le IAM Guide de l'utilisateur.

  • Accorder le privilège le plus faible – Lorsque vous créez des stratégies personnalisées, accordez uniquement les autorisations requises pour exécuter une seule tâche. Commencez avec un minimum d'autorisations et accordez-en d'autres si nécessaire. Cette méthode est plus sûre que de commencer avec des autorisations trop permissives et d'essayer de les restreindre plus tard. Pour plus d'informations, consultez Accorder le privilège le plus faible dans le IAM Guide de l'utilisateur.

  • Activer MFA pour les opérations sensibles – Pour plus de sécurité, obligez les utilisateurs IAM à utiliser l'authentification multi-facteurs (MFA) pour accéder à des ressources ou à des opérations d'API sensibles. Pour plus d'informations, consultez Utilisation de Multi-Factor Authentication (MFA) dans AWS dans le IAM Guide de l'utilisateur.

  • Utiliser des conditions de stratégie pour une plus grande sécurité – Tant que cela reste pratique pour vous, définissez les conditions dans lesquelles vos stratégies basées sur l'identité autorisent l'accès à une ressource. Par exemple, vous pouvez rédiger les conditions pour spécifier une plage d'adresses IP autorisées d'où peut provenir une demande. Vous pouvez également écrire des conditions pour autoriser les requêtes uniquement à une date ou dans une plage de temps spécifiée, ou pour imposer l'utilisation de SSL ou de MFA. Pour plus d'informations, consultez Éléments de stratégie JSON IAM : condition dans le IAM Guide de l'utilisateur.

Utilisation de la console Amazon RDS

Pour accéder à la console Amazon RDS, vous devez disposer d'un ensemble minimal d'autorisations. Ces autorisations doivent vous permettre de répertorier et visualiser les informations relatives aux ressources Amazon RDS de votre compte AWS. Vous pouvez créer une stratégie basée sur une identité qui soit plus restrictive que les autorisations minimales requises. Cependant, dans ce cas, la console ne fonctionne pas comme prévu pour les entités (rôles ou utilisateurs IAM) avec cette stratégie.

Pour garantir que ces entités pourront continuer à utiliser la console Amazon RDS, attachez également la stratégie gérée AWS suivante aux entités. Pour plus d'informations, consultez Ajout d'autorisations à un utilisateur dans le IAM Guide de l'utilisateur.

AmazonRDSReadOnlyAccess

Vous n'avez pas besoin d'accorder les autorisations minimales de console aux utilisateurs qui effectuent des appels uniquement vers AWS CLI ou l'API AWS. Autorisez plutôt l'accès à uniquement aux actions qui correspondent à l'opération d'API que vous tentez d'effectuer.

Autoriser les utilisateurs à afficher leurs propres autorisations

Cet exemple montre comment créer une stratégie qui permet aux utilisateurs IAM d'afficher les stratégies en ligne et gérées attachées à leur identité d'utilisateur. Cette stratégie inclut les autorisations nécessaires pour réaliser cette action sur la console ou par programmation à l'aide d'AWS CLI ou de l'API AWS.

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

Autoriser un utilisateur à créer des instances de base de données dans un compte AWS

Voici un exemple de stratégie autorisant un utilisateur portant l'ID 123456789012 à créer des instances de base de données pour votre compte AWS. La stratégie exige que le nom de la nouvelle instance de base de données commence par test. La nouvelle instance de base de données doit également utiliser le moteur de base de données MySQL et la classe d'instance de base de données db.t2.micro. En outre, la nouvelle instance de base de données doit utiliser un groupe d'options et un groupe de paramètres de base de données commençant par default, et elle doit utiliser le groupe de sous-réseaux 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" } } } ] }

La stratégie inclut une instruction unique spécifiant les autorisations suivantes pour l'utilisateur IAM :

  • La stratégie autorise l'utilisateur IAM à créer une instance de base de données à l'aide de l'opération d'API CreateDBInstance (cela s'applique également à la commande create-db-instance de l'AWS CLI et de la AWS Management Console).

  • L'élément Resource spécifie que l'utilisateur peut effectuer des actions sur et avec des ressources. Vous indiquez des ressources à l'aide d'un nom ARN (Amazon Resources Name). Ce nom ARN inclut le nom du service auquel appartient la ressource (rds), la région AWS (* indique une région dans cet exemple), le numéro de compte de l'utilisateur (123456789012 est l'ID utilisateur dans cet exemple) ainsi que le type de ressource. Pour plus d'informations sur la création de noms ARN, consultez Utilisation des Amazon Resource Names (ARN) dans Amazon RDS.

    L'élément Resource dans l'exemple spécifie les contraintes de stratégie suivantes sur les ressources de l'utilisateur :

    • L'identifiant d'instance de base de données de la nouvelle instance de base de données doit commencer par test (par exemple, testCustomerData1, test-region2-data).

    • Le groupe d'options de la nouvelle instance de base de données doit commencer par default.

    • Le groupe de paramètres de base de données de la nouvelle instance de base de données doit commencer par default.

    • Le groupe de sous-réseaux de la nouvelle instance de base de données doit être le groupe de sous-réseaux default.

  • L'élément Condition indique que le moteur de base de données doit être MySQL et la classe d'instance de base de données doit être db.t2.micro. L'élément Condition indique les conditions lorsqu'une stratégie doit entrer en vigueur. Vous pouvez ajouter des autorisations ou des restrictions supplémentaires à l'aide de l'élément Condition. Pour plus d'informations sur la spécification de conditions, consultez Clés de condition. Cet exemple spécifie les conditions rds:DatabaseEngine et rds:DatabaseClass. Pour plus d’informations sur les valeurs de conditions valides pour rds:DatabaseEngine, consultez la liste en dessous du paramètre Engine dans CreateDBInstance. Pour plus d’informations sur les valeurs de conditions valides pour rds:DatabaseClass, consultez Moteurs de base de données pris en charge pour toutes les classes d'instances de base de données disponibles .

La stratégie ne spécifie pas l'élément Principal car, dans une stratégie basée sur une identité, vous ne spécifiez pas le mandataire qui obtient l'autorisation. Quand vous attachez une stratégie à un utilisateur, l'utilisateur est le mandataire implicite. Lorsque vous attachez une stratégie d'autorisation à un rôle IAM, le mandataire identifié dans la stratégie d'approbation de ce rôle obtient les autorisations.

Pour afficher la liste des actions Amazon RDS, veuillez consulter Actions définies par Amazon RDS dans le IAM Guide de l'utilisateur.

Autorisations requises pour utiliser la console

Pour qu'un utilisateur puisse utiliser la console, il doit avoir un ensemble minimal d'autorisations. Ces autorisations permettent à l'utilisateur de décrire les ressources Amazon RDS de leur compte AWS et de fournir d'autres informations associées, dont les informations relatives à la sécurité Amazon EC2 et au réseau.

Si vous créez une stratégie IAM plus restrictive que les autorisations minimales requises, la console ne fonctionne pas comme prévu pour les utilisateurs dotés de cette stratégie IAM. Pour garantir que ces utilisateurs puissent continuer à utiliser la console, attachez également la stratégie gérée AmazonRDSReadOnlyAccess à l'utilisateur, comme décrit dans Gestion de l'accès à l'aide des stratégies.

Vous n'avez pas besoin d'accorder les autorisations minimales de console pour les utilisateurs qui effectuent des appels uniquement à l'interface AWS CLI ou API Amazon RDS.

La stratégie suivante accorde l'accès total à toutes les ressources Amazon RDS pour le compte AWS racine :

AmazonRDSFullAccess

Autoriser un utilisateur à effectuer une action Describe sur une ressource RDS

La stratégie d'autorisation suivante accorde des autorisations à un utilisateur lui permettant d'exécuter toutes les actions commençant par Describe. Ces actions affichent des informations sur une ressource RDS, telle qu'une instance de base de données. Le caractère générique (*) figurant dans l'élément Resource indique que les actions sont autorisées pour toutes les ressources Amazon RDS détenues par le compte.

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

Autoriser un utilisateur à créer une instance de base de données qui utilise les groupes de sécurité et de paramètres de base de données spécifiés

La stratégie d'autorisation suivante accorde des autorisations permettant à un utilisateur de créer uniquement une instance de base de données devant utiliser le groupe de paramètres DB mysql-production et le groupe de sécurité DB db-production.

{ "Version":"2012-10-17", "Statement":[ { "Sid":"AllowMySQLProductionCreate", "Effect":"Allow", "Action":"rds:CreateDBInstance", "Resource":[ "arn:aws:rds:us-west-2:123456789012:pg:mysql-production", "arn:aws:rds:us-west-2:123456789012:secgrp:db-production" ] } ] }

Accorder une autorisation pour des actions sur une ressource à l'aide d'une balise spécifique avec deux valeurs différentes

Vous pouvez utiliser des conditions dans votre stratégie basée sur l'identité pour contrôler l'accès aux ressources Amazon RDS en fonction des balises. La stratégie suivante accorde l'autorisation d'exécuter les API ModifyDBInstance et CreateDBSnapshot sur les instances de base de données avec la balise stage définie sur development ou sur test.

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

Empêcher un utilisateur de supprimer une instance de base de données

La stratégie d'autorisation suivante accorde des autorisations empêchant un utilisateur de supprimer une instance de base de données spécifique. Par exemple, il est possible de refuser la capacité à supprimer vos instances de base de données de production à un utilisateur quelconque qui n'est pas un administrateur.

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

Exemples de stratégies : Utilisation des clés de condition

Les exemples suivants montrent comment vous pouvez utiliser des clés de condition dans les stratégies d'autorisation IAM Amazon RDS.

Exemple 1 : Accorder l'autorisation de créer une instance de base de données qui utilise un moteur de base de données spécifique et n'utilise pas plusieurs zones de disponibilité

La stratégie suivante utilise une clé de condition RDS et autorise un utilisateur à créer seulement des instances de bases de données qui utilisent le moteur de base de données MySQL et n'utilisent pas plusieurs zones de disponibilité. L'élément Condition indique l'exigence que le moteur de base de données soit MySQL.

{ "Version":"2012-10-17", "Statement":[ { "Sid":"AllowMySQLCreate", "Effect":"Allow", "Action":"rds:CreateDBInstance", "Resource":"*", "Condition":{ "StringEquals":{ "rds:DatabaseEngine":"mysql" }, "Bool":{ "rds:MultiAz": false } } } ] }

Exemple 2 : Refuser explicitement l'autorisation de créer des instances de bases de données pour certaines classes d'instance de base de données et de créer des instances de bases de données qui utilisent les IOPS provisionnées

La stratégie suivante refuse explicitement l'autorisation de créer des instances de bases de données qui utilisent les classes d'instance de base de données r3.8xlarge et m4.10xlarge, lesquelles représentent les classes d'instances de base de données les plus grandes et les plus onéreuses. Cette stratégie empêche également les utilisateurs de créer des instances de bases de données qui utilisent les IOPS provisionnées, ce qui génère un coût additionnel.

Le refus explicite d'une autorisation a priorité sur toutes les autres autorisations accordées. Cela garantit que des identités n'obtiendront pas par erreur une autorisation que vous ne souhaitez pas accorder.

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

Exemple 3 : Limiter l'ensemble de clés et de valeurs de balise pouvant être utilisées pour baliser une ressource

La politique suivante utilise une clé de condition RDS et autorise l'ajout d'une balise avec la clé stage à une ressource avec les valeurs test, qa et production.

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

Spécification de conditions : Utilisation de balises personnalisées

Amazon RDS prend en charge la spécification de conditions dans une stratégie IAM à l'aide de balises personnalisées.

Par exemple, supposons que vous ajoutiez une balise nommée environment à vos instances de base de données avec des valeurs telles que beta, staging, production, etc. Dans ce cas, vous pouvez créer une stratégie qui limite certains utilisateurs aux instances de base de données fondées sur la valeur de balise environment.

Note

Les identifiants des balises personnalisées sont sensibles à la casse.

Le tableau suivant répertorie les identifiants des balises RDS que vous pouvez utiliser dans un élément Condition.

Identifiant de balise RDS S'applique à
db-tag Instances DB, y compris les réplicas en lecture
snapshot-tag Snapshots DB
ri-tag Instances DB réservées
secgrp-tag Groupes de sécurité DB
og-tag Groupes d'options DB
pg-tag Groupes de paramètres DB
subgrp-tag Groupes de sous-réseaux DB
es-tag Abonnements aux événements
cluster-tag Clusters DB
cluster-pg-tag Groupes de paramètres de cluster DB
cluster-snapshot-tag Instantanés de cluster DB

La syntaxe d'une condition de balise personnalisée est la suivante :

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

Par exemple, l'élément Condition suivant s'applique aux instances de bases de données avec une balise nommée environment et la valeur de balise production.

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

Pour plus d'informations sur la création de balises, consultez Balisage des ressources Amazon RDS.

Important

Si vous gérez l'accès à vos ressources RDS à l'aide du balisage, nous vous recommandons de sécuriser l'accès aux balises pour vos ressources RDS. Vous pouvez gérer l'accès aux balises en créant des stratégies pour les actions AddTagsToResource et RemoveTagsFromResource. Par exemple, la stratégie suivante refuse aux utilisateurs la capacité à ajouter ou supprimer des balises pour toutes les ressources. Vous pouvez alors créer des stratégies pour autoriser des utilisateurs spécifiques à ajouter ou supprimer des balises.

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

Pour afficher la liste des actions Amazon RDS, veuillez consulter Actions définies par Amazon RDS dans le IAM Guide de l'utilisateur.

Exemples de stratégies : Utilisation de balises personnalisées

Les exemples suivants montrent comment vous pouvez utiliser des balises personnalisées dans les stratégies d'autorisation IAM Amazon RDS. Pour plus d'informations sur l'ajout de balises à une ressource Amazon RDS, consultez Utilisation des Amazon Resource Names (ARN) dans Amazon RDS.

Note

Tous les exemples utilisent la région us-west-2 et contiennent des ID de compte fictifs.

Exemple 1 : Accorder une autorisation pour des actions sur une ressource à l'aide d'une balise spécifique avec deux valeurs différentes

La stratégie suivante accorde l'autorisation d'exécuter les API ModifyDBInstance et CreateDBSnapshot sur les instances de base de données avec la balise stage définie sur development ou sur test.

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

Exemple 2 : Refuser explicitement l'autorisation de créer une instance de base de données qui utilise les groupes de paramètres DB spécifiés

La stratégie suivante refuse explicitement l'autorisation de créer une instance de base de données qui utilise les groupes de paramètres DB avec des valeurs de balise spécifiques. Vous pouvez appliquer cette stratégie si vous avez besoin qu'un groupe de paramètres DB créé par le client soit toujours utilisé lors de la création des instances de bases de données. Notez que les stratégies qui utilisent Deny sont le plus souvent utilisées pour limiter un accès accordé par une stratégie plus large.

Le refus explicite d'une autorisation a priorité sur toutes les autres autorisations accordées. Cela garantit que des identités n'obtiendront pas par erreur une autorisation que vous ne souhaitez pas accorder.

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

Exemple 3 : Accorder une autorisation pour des actions sur une instance de base de données dont le nom d'instance a un nom d'utilisateur comme préfixe

La stratégie suivante accorde l'autorisation d'appeler une API quelconque (à l'exception de AddTagsToResource et de RemoveTagsFromResource) sur une instance de base de données dont le nom d'instance de base de données a comme préfixe le nom de l'utilisateur et a une balise nommée stage égale à devo ou qui n'a pas de balise nommée stage.

La ligne Resource dans la stratégie identifie une ressource par son Amazon Resource Name (ARN). Pour plus d'informations sur l'utilisation des noms ARN avec les ressources Amazon RDS, consultez Utilisation des Amazon Resource Names (ARN) dans Amazon RDS.

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