Exemples de politiques basées sur l'identité pour Amazon RDS

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

Pour apprendre à créer une politique basée sur l’identité IAM à l’aide de ces exemples de documents de politique JSON, veuillez consulter Création de politiques dans l’onglet JSON dans le Guide de l’utilisateur IAM.

Bonnes pratiques en matière de politiques

Les stratégies basées sur l'identité 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 politiques basées sur l’identité, suivez ces instructions et recommandations :

• Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations à vos utilisateurs et à vos charges de travail, utilisez les politiques AWS gérées qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour de plus amples informations, consultez Politiques gérées AWS ou Politiques gérées AWS pour les activités professionnelles dans le Guide de l’utilisateur IAM.

• Accorder les autorisations de moindre privilège - Lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées autorisations de moindre privilège. Pour plus d’informations sur l’utilisation de IAM pour appliquer des autorisations, consultez Politiques et autorisations dans IAM dans le Guide de l’utilisateur IAM.

• Utiliser des conditions dans les politiques IAM pour restreindre davantage l’accès - Vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique Service AWS, tel que AWS CloudFormation. Pour plus d’informations, consultez Conditions pour éléments de politique JSON IAM dans le Guide de l’utilisateur IAM.

• Utilisez IAM Access Analyzer pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles - IAM Access Analyzer valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour de plus amples informations, consultez Validation de politique IAM Access Analyzer dans le Guide de l’utilisateur IAM.

• Exiger l'authentification multifactorielle (MFA) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger le MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour de plus amples informations, consultez Configuration de l’accès aux API protégé par MFA dans le Guide de l’utilisateur IAM.

Pour plus d’informations sur les bonnes pratiques dans IAM, consultez Bonnes pratiques de sécurité dans IAM dans le Guide de l’utilisateur IAM.

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 de consulter les informations relatives aux ressources Amazon RDS présentes dans votre Compte AWS. Si vous créez une stratégie basée sur l’identité qui est plus restrictive que l’ensemble minimum d’autorisations requis, la console ne fonctionnera pas comme prévu pour les entités (utilisateurs ou rôles) tributaires de cette stratégie.

Il n'est pas nécessaire d'accorder des autorisations de console minimales aux utilisateurs qui appellent uniquement l'API AWS CLI ou l' AWS API. Autorisez plutôt l’accès à uniquement aux actions qui correspondent à l’opération d’API que vous tentez d’effectuer.

Pour garantir que ces entités peuvent toujours utiliser la console Amazon RDS , associez également la politique AWS gérée suivante aux entités.

AmazonRDSReadOnlyAccess

Pour plus d’informations, consultez Ajout d’autorisations à un utilisateur dans le Guide de l’utilisateur IAM.

Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations

Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d'afficher les politiques en ligne et gérées attachées à leur identité d'utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or 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 AWS compte

Voici un exemple de politique qui permet à l'utilisateur possédant l'ID de 123456789012 créer des instances de base de données pour votre AWS compte. 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  :

• La politique permet à l'utilisateur de créer une instance de base de données à l'aide de l'opération d'API CreateDBInstance (cela s'applique également à create-db-instanceAWS CLI la commande et au). 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). Cet ARN inclut le nom du service auquel appartient la ressource (rds), la AWS région (*indique n'importe quelle région dans cet exemple), le numéro de AWS compte (123456789012il s'agit du numéro de compte dans cet exemple) et 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 de politique pour Amazon RDS. 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, veuillez consulter Moteurs de base de données pris en charge pour les classes d'instance de base de données .

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

Pour afficher la liste des actions Amazon RDS, consultez Actions définies par Amazon RDS dans Référence de l'autorisation de service.

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 associées à son AWS compte et de fournir d'autres informations connexes, notamment des informations relatives à la sécurité et au réseau Amazon EC2.

Si vous créez une politique IAM plus restrictive que les autorisations minimales requises, la console ne fonctionne pas comme prévu pour les utilisateurs dotés de cette politique 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 des accès à l’aide de politiques.

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

La politique suivante accorde un accès complet à toutes les ressources Amazon RDS pour le AWS compte racine :

AmazonRDSFullAccess             
         

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

La politique 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 le groupe de paramètres de base de données et le groupe de sous-réseau spécifiés

La politique 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 de base de données mydbpg et le groupe de sous-réseau de base de données mydbsubnetgroup.

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

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 politique suivante accorde l'autorisation d'exécuter l'opération d'API CreateDBSnapshot sur les instances de base de données avec la balise stage définie sur development ou test.

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

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

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

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

La politique 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"
      }
   ]
}

Refuser tout accès à une ressource

Vous pouvez refuser explicitement l'accès à une ressource. Les politiques de refus ont priorité sur les politiques d'autorisation. La politique suivante refuse explicitement à un utilisateur la possibilité de gérer une ressource :

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

Exemples de politiques : 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'est pas Multi-AZ

La politique 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 la configuration Multi-AZ. 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 politique 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 de base de données, y compris les réplicas en lecture
snapshot-tag	Instantanés de base de données
ri-tag	Instances de base de données réservées
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 de 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 politique suivante refuse aux utilisateurs la capacité à ajouter ou supprimer des balises pour toutes les ressources. Vous pouvez alors créer des politiques 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, consultez Actions définies par Amazon RDS dans Référence de l'autorisation de service.

Exemples de politiques : 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 politique suivante accorde l'autorisation d'exécuter l'opération d'API CreateDBSnapshot sur les instances de base de données avec la balise stage définie sur development ou test.

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

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

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

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 politique 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 politique 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":"arn:aws:rds:*:123456789012:pg:*",
         "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"
            }
         }
      }
   ]
}