Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Sécurité dans )
La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez d'un centre de données et d'une architecture réseau conçus pour répondre aux exigences des entreprises les plus sensibles en matière de sécurité.
La sécurité est une responsabilité partagée entre vous AWS et vous. Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) décrit cette notion par les termes sécurité *du* cloud et sécurité *dans* le cloud :
+ **Sécurité du cloud** : AWS est chargée de protéger l'infrastructure qui exécute les AWS services dans le AWS cloud. AWS vous fournit également des services que vous pouvez utiliser en toute sécurité. Des auditeurs tiers testent et vérifient régulièrement l’efficacité de notre sécurité dans le cadre des [programmes de conformitéAWS](https://aws.amazon.com/compliance/programs/). Pour découvrir les programmes de conformité qui s’appliquent à Amazon Aurora (Aurora), consultez [Services AWS concernés par le programme de conformité](https://aws.amazon.com/compliance/services-in-scope/).
+ **Sécurité dans le cloud** — Votre responsabilité est déterminée par le AWS service que vous utilisez. Vous êtes également responsable d’autres facteurs, y compris la sensibilité de vos données, les exigences de votre organisation, et la législation et la réglementation applicables.
Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de l’utilisation de Amazon Aurora. Les rubriques suivantes vous montrent comment configurer Amazon Aurora pour répondre à vos objectifs de sécurité et de conformité. Vous apprendrez également à utiliser d'autres AWS services qui vous aident à surveiller et à sécuriser vos ressources Amazon Aurora.
Vous pouvez gérer l’accès à vos ressources Amazon Aurora et à vos bases de données sur un cluster de bases de données. La méthode que vous utilisez pour gérer l’accès dépend du type de tâche que l’utilisateur doit effectuer avec Amazon Aurora :
+ Exécutez votre cluster de bases de données dans un cloud privé virtuel (VPC) basé sur le service Amazon VPC pour disposer du meilleur contrôle d’accès réseau possible. Pour plus d’informations sur la création d’un cluster de bases de données dans un VPC, consultez [Amazon VPC et Amazon Aurora](USER_VPC.md).
+ Utilisez des politiques Gestion des identités et des accès AWS (IAM) pour attribuer des autorisations qui déterminent qui est autorisé à gérer les ressources Amazon Aurora. Par exemple, vous pouvez utiliser IAM pour déterminer qui est autorisé à créer, décrire, modifier et supprimer des clusters de bases de données, attribuer des balises à des ressources ou modifier des groupes de sécurité.
Pour passer en revue des exemples de politiques IAM, consultez [Exemples de politiques basées sur l’identité pour Amazon Aurora](security_iam_id-based-policy-examples.md).
+ Utilisez les groupes de sécurité pour contrôler quelles adresses IP ou instances Amazon EC2 peuvent se connecter à vos bases de données sur un cluster de bases de données. Quand vous créez un cluster de bases de données pour la première fois, son pare-feu empêche tout accès aux bases de données sauf via les règles spécifiées par un groupe de sécurité associé.
+ Utilisez les connexions Secure Socket Layer (SSL) ou du protocole TLS (Transport Layer Security) avec des clusters de bases de données exécutant Aurora MySQL ou Aurora PostgreSQL. Pour plus d'informations sur l'utilisation SSL/TLS avec un cluster de base de données, consultez[Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md).
+ Utilisez le chiffrement Amazon Aurora pour sécuriser vos clusters de bases de données et instantanés au repos. Le chiffrement Amazon Aurora utilise l’algorithme de chiffrement AES-256 standard pour chiffrer vos données sur le serveur qui héberge votre cluster de bases de données. Pour plus d’informations, consultez [Chiffrement des ressources Amazon Aurora](Overview.Encryption.md).
+ Utilisez les fonctionnalités de sécurité de votre moteur de base de données pour contrôler qui peut se connecter aux bases de données sur un cluster de bases de données. Ces fonctions agissent comme si la base de données se trouvait sur votre réseau local.
Pour en savoir plus sur la sécurité avec Aurora MySQL, consultez [Sécurité avec Amazon Aurora MySQL](AuroraMySQL.Security.md). Pour en savoir plus sur la sécurité avec Aurora PostgreSQL, consultez [Sécurité avec Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md).
Aurora fait partie du service de base de données géré Amazon Relational Database Service (Amazon RDS). Amazon RDS est un service web qui facilite la configuration, l’exploitation et la mise à l’échelle d’une base de données relationnelle dans le cloud. Si vous connaissez déjà Amazon RDS, consultez le [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html).
Aurora comprend un sous-système de stockage très performant. Ses moteurs de bases de données compatibles avec MySQL et PostgreSQL sont personnalisés afin de tirer parti de ce stockage distribué et rapide. Aurora automatise et standardise également le clustering et la réplication des bases de données. Ces aspects figurent généralement parmi ceux qui représentent un défi dans le cadre de la configuration et de l’administration des bases de données.
Pour Amazon RDS et Aurora, vous pouvez accéder à l'API RDS par programmation, et vous pouvez l'utiliser AWS CLI pour accéder à l'API RDS de manière interactive. Certaines opérations d’API RDS et commandes d’ AWS CLI s’appliquent à Amazon RDS et à Aurora, alors que d’autres s’appliquent soit à Amazon RDS, soit à Aurora. Pour obtenir des informations sur les opérations d’API RDS, consultez [Référence d’API Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/Welcome.html). Pour plus d'informations à ce sujet AWS CLI, consultez la [AWS Command Line Interface référence relative à Amazon RDS.](https://docs.aws.amazon.com/cli/latest/reference/rds/index.html)
**Note**
Vous devez uniquement configurer la sécurité de vos cas d’utilisation. Vous n’avez pas à configurer l’accès de sécurité pour les processus gérés par Amazon Aurora. Il s’agit notamment de la création de sauvegardes, du basculement automatique et d’autres processus.
Pour plus d’informations sur la gestion de l’accès aux ressources Amazon Aurora et à vos bases de données sur une un cluster de bases de données, consultez les rubriques suivantes.
**Topics**
+ [Authentification de base de données avec (Amazon Aurora)](database-authentication.md)
+ [Gestion des mots de passe avec Amazon Aurora et AWS Secrets Manager](rds-secrets-manager.md)
+ [Protection des données dans Amazon RDS](DataDurability.md)
+ [Identity and Access Management pour Amazon Aurora](UsingWithRDS.IAM.md)
+ [Journalisation et surveillance dans )](Overview.LoggingAndMonitoring.md)
+ [Validation de la conformité pour Amazon Aurora](RDS-compliance.md)
+ [Résilience dans Amazon Aurora](disaster-recovery-resiliency.md)
+ [Sécurité de l'infrastructure dans Amazon Aurora](infrastructure-security.md)
+ [API Amazon RDS et points de terminaison d'un VPC d'interface (AWS PrivateLink)](vpc-interface-endpoints.md)
+ [Bonnes pratiques de sécurité pour )](CHAP_BestPractices.Security.md)
+ [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md)
+ [Privilèges du compte utilisateur principal](UsingWithRDS.MasterAccounts.md)
+ [Utilisation des rôles liés à un service pour Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md)
+ [Amazon VPC et Amazon Aurora](USER_VPC.md)
# Authentification de base de données avec (Amazon Aurora)
Amazon Aurora prend en charge plusieurs façons d’authentifier les utilisateurs de base de données.
L’authentification par mot de passe est disponible par défaut pour tous les clusters de bases de données. Pour Aurora MySQL et Aurora PostgreSQL, vous pouvez également ajouter l’authentification de base de données IAM ou Kerberos ou les deux pour le même cluster de bases de données.
L’authentification par mot de passe, Kerberos et IAM utilisent différentes méthodes d’authentification auprès de la base de données. Par conséquent, un utilisateur spécifique peut se connecter à une base de données en utilisant une seule méthode d’authentification.
Pour PostgreSQL, utilisez un seul des paramètres de rôle suivants pour un utilisateur d’une base de données spécifique :
+ Pour utiliser l’authentification de base de données IAM, affectez le rôle `rds_iam` à l’utilisateur.
+ Pour utiliser l’authentification Kerberos, affectez le rôle `rds_ad` à l’utilisateur.
+ Pour utiliser l’authentification par mot de passe, n’affectez pas les rôles `rds_iam` ou `rds_ad` à l’utilisateur.
N’affectez pas à la fois les rôles `rds_iam` et `rds_ad` à un utilisateur d’une base de données PostgreSQL, directement ou indirectement par l’intermédiaire d’un accès accordé imbriqué. Si le rôle `rds_iam` est ajouté à l’utilisateur principal, l’authentification IAM a priorité sur l’authentification par mot de passe, de sorte que l’utilisateur principal doit se connecter en tant qu’utilisateur IAM.
**Important**
Nous vous recommandons vivement de ne pas avoir recours au rôle d’utilisateur principal directement dans vos applications. Au lieu de cela, respectez la bonne pratique qui consiste à avoir recours à un utilisateur de base de données doté des privilèges minimum requis pour votre application.
**Topics**
+ [Authentification par mot de passe](#password-authentication)
+ [Authentification de base de données IAM](#iam-database-authentication)
+ [Authentification Kerberos](#kerberos-authentication)
## Authentification par mot de passe
Avec *l’authentification par mot de passe*, votre base de données se charge de toute l’administration des comptes utilisateurs. Vous créez des utilisateurs avec des instructions SQL telles que `CREATE USER`, avec la clause appropriée requise par le moteur de base de données pour spécifier des mots de passe. Par exemple, dans MySQL, l'instruction est `CREATE USER` *name* `IDENTIFIED BY`*password*, tandis que dans PostgreSQL, l'instruction est. `CREATE USER` *name* `WITH PASSWORD` *password*
Avec l’authentification par mot de passe, votre base de données contrôle et authentifie les comptes d’utilisateurs. Si un moteur de base de données dispose de fonctionnalités de gestion de mot de passe solides, il peut améliorer la sécurité. L’authentification de base de données peut être plus facile à administrer en utilisant l’authentification par mot de passe lorsque vous avez de petites communautés d’utilisateurs. Étant donné que des mots de passe en texte clair sont générés dans ce cas, leur intégration AWS Secrets Manager peut améliorer la sécurité.
Pour plus d’informations sur l’utilisation de Secrets Manager avec Amazon Aurora, consultez [Création d’un secret de base](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) et [Rotation de secrets pour les bases de données Amazon RDS prises en charge](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets-rds.html) dans le *Guide de l’utilisateur AWS Secrets Manager *. Pour plus d’informations sur la récupération par programme de vos secrets dans vos applications personnalisées, consultez [Récupération de la valeur de secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html) dans le *Guide de l’utilisateur AWS Secrets Manager *.
## Authentification de base de données IAM
Vous pouvez vous authentifier auprès de votre cluster de bases de données à l’aide de l’authentification de base de données Gestion des identités et des accès AWS (IAM). Grâce à cette méthode d’authentification, vous n’avez plus besoin de mot de passe pour vous connecter à un cluster de bases de données. En revanche, un jeton d’authentification est nécessaire.
Pour plus d’informations sur l’authentification de base de données IAM, y compris sur la disponibilité de moteurs de base de données spécifiques, consultez [Authentification de base de données IAM](UsingWithRDS.IAMDBAuth.md).
## Authentification Kerberos
Amazon Aurora prend en charge l’authentification externe des utilisateurs de bases de données avec Kerberos et Microsoft Active Directory. Kerberos est un protocole d’authentification réseau qui utilise les tickets et la cryptographie de clé symétrique pour vous éviter d’acheminer vos mots de passe via le réseau. Intégré dans Active Directory, Kerberos est conçu pour authentifier les utilisateurs sur les ressources réseau, par exemple les bases de données.
La prise en charge de Kerberos et Active Directory par Amazon Aurora procure les avantages d’une authentification unique et centralisée des utilisateurs de bases de données. Vous pouvez conserver vos informations d’identification utilisateur dans Active Directory. Active Directory vous offre un endroit centralisé de stockage et de gestion des informations d’identification pour plusieurs d’instances de base de données.
Pour utiliser les informations d'identification de votre Active Directory autogéré, vous devez configurer une relation de confiance avec Microsoft Active Directory Directory Service auquel le cluster de base de données d' de base de données est joint.
Aurora PostgreSQL et Aurora MySQL prennent en charge les relations de confiance unidirectionnelles et bidirectionnelles avec une authentification à l’échelle de la forêt ou une authentification sélective.
Dans certains scénarios, vous pouvez configurer l’authentification Kerberos via une relation de confiance externe. Cela nécessite que votre Active Directory autogéré dispose de paramètres supplémentaires. Cela inclut, mais sans s’y limiter, [ l’ordre de recherche Kerberos Forest](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/kfso-not-work-in-external-trust-event-is-17).
Aurora prend en charge l’authentification Kerberos pour les clusters de bases de données Aurora MySQL et Aurora PostgreSQL. Pour plus d’informations, consultez [Utilisation de l'authentification Kerberos pour Aurora MySQL](aurora-mysql-kerberos.md) et [Utilisation de l’authentification Kerberos avec Aurora PostgreSQL](postgresql-kerberos.md).
# Gestion des mots de passe avec Amazon Aurora et AWS Secrets Manager
Amazon Aurora s’intègre à Secrets Manager pour gérer les mots de passe d’utilisateur principal de vos clusters de bases de données.
**Topics**
+ [Disponibilité des régions et des versions](#rds-secrets-manager-availability)
+ [Limites de l’intégration de Secrets Manager avec Amazon Aurora](#rds-secrets-manager-limitations)
+ [Présentation de la gestion des mots de passe des utilisateurs principaux avec AWS Secrets Manager](#rds-secrets-manager-overview)
+ [Avantages de la gestion des mots de passe d’utilisateur principal avec Secrets Manager](#rds-secrets-manager-benefits)
+ [Autorisations requises pour l’intégration de Secrets Manager](#rds-secrets-manager-permissions)
+ [Appliquer la gestion du mot de passe de l'utilisateur principal par dans AWS Secrets Manager](#rds-secrets-manager-auth)
+ [Gestion du mot de passe utilisateur principal pour un cluster de base de données avec Secrets Manager](#rds-secrets-manager-db-cluster)
+ [Rotation du secret du mot de passe utilisateur principal pour un cluster de base de données](#rds-secrets-manager-rotate-db-cluster)
+ [Afficher les détails d'un secret pour un cluster de base de données](#rds-secrets-manager-view-db-cluster)
## Disponibilité des régions et des versions
La disponibilité et la prise en charge des fonctionnalités varient selon les versions spécifiques de chaque moteur de base de données, et selon les Régions AWS. Pour plus d’informations sur la disponibilité des versions et des régions avec l’intégration de Secrets Manager avec Amazon Aurora, consultez [Régions et moteurs de base de données Aurora pris en charge pour l’intégration de Secrets Manager](Concepts.Aurora_Fea_Regions_DB-eng.Feature.SecretsManager.md).
## Limites de l’intégration de Secrets Manager avec Amazon Aurora
La gestion des mots de passe d’utilisateur principal à l’aide de Secrets Manager n’est pas prise en charge pour les fonctionnalités suivantes :
+ Déploiements Amazon RDS Blue/Green
+ Clusters de bases de données qui font partie d’une base de données globale Aurora
+ Clusters DB Aurora Serverless v1
+ Réplicas en lecture entre Régions
+ Réplication externe du journal binaire
## Présentation de la gestion des mots de passe des utilisateurs principaux avec AWS Secrets Manager
Vous pouvez AWS Secrets Manager ainsi remplacer les informations d'identification codées en dur dans votre code, y compris les mots de passe de base de données, par un appel d'API à Secrets Manager pour récupérer le secret par programmation. Pour plus d’informations sur Secrets Manager, consultez le [Guide de l’utilisateur AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/).
Lorsque vous stockez des secrets de base de données dans Secrets Manager, des frais Compte AWS vous sont facturés. Pour plus d’informations sur la tarification, consultez la section [AWS Secrets Manager Tarification](https://aws.amazon.com/secrets-manager/pricing).
Vous pouvez spécifier qu’Aurora doit gérer le mot de passe d’utilisateur principal dans Secrets Manager pour un cluster de bases de données Amazon Aurora quand vous effectuez l’une des opérations suivantes :
+ Création d’un cluster de bases de données
+ Modification d’un cluster de bases de données
+ Restauration d’un cluster de bases de données à partir d’Amazon S3 (Aurora MySQL uniquement)
Quand vous spécifiez qu’Aurora doit gérer le mot de passe d’utilisateur principal dans Secrets Manager, Aurora génère le mot de passe et le stocke dans Secrets Manager. Vous pouvez interagir directement avec le secret pour récupérer les informations d’identification de l’utilisateur principal. Vous pouvez également spécifier une clé gérée par le client pour chiffrer le secret, ou utiliser la clé KMS fournie par Secrets Manager.
Aurora gère les paramètres du secret et effectue la rotation du secret tous les sept jours, par défaut. Vous pouvez modifier certains paramètres, tels que la planification de la rotation. Si vous supprimez un cluster de bases de données qui gère un secret dans Secrets Manager, le secret et les métadonnées associées sont également supprimés.
Pour vous connecter à un cluster de base de données avec les informations d’identification contenues dans un secret, vous pouvez récupérer le secret à partir de Secrets Manager. Pour plus d'informations, voir [Extraire des secrets depuis](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) une base de données SQL AWS Secrets Manager et [Se connecter à une base de données SQL avec des informations d'identification inscrites dans un AWS Secrets Manager secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_jdbc.html) dans le *Guide de AWS Secrets Manager l'utilisateur*.
## Avantages de la gestion des mots de passe d’utilisateur principal avec Secrets Manager
La gestion des mots de passe d’utilisateur principal Aurora avec Secrets Manager présente les avantages suivants :
+ Aurora génère automatiquement des informations d’identification de base de données.
+ Aurora stocke et gère automatiquement les informations d'identification de la base de données dans AWS Secrets Manager.
+ Aurora effectue une rotation régulière des informations d’identification de base de données, sans exiger de modifications d’application.
+ Secrets Manager sécurise les informations d’identification de base de données contre tout accès humain et tout affichage en texte brut.
+ Secrets Manager permet de récupérer les informations d’identification de base de données dans des secrets pour les connexions à une base de données.
+ Secrets Manager permet un contrôle précis de l’accès aux informations d’identification de base de données dans des secrets à l’aide d’IAM.
+ Vous pouvez éventuellement séparer le chiffrement d’une base de données du chiffrement des informations d’identification à l’aide de clés KMS différentes.
+ Vous pouvez éliminer la gestion et la rotation manuelles des informations d’identification de base de données.
+ Vous pouvez facilement surveiller les informations d'identification de la base AWS CloudTrail de données avec Amazon CloudWatch.
Pour en savoir plus sur les avantages de Secrets Manager, consultez le [Guide de l’utilisateur AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/).
## Autorisations requises pour l’intégration de Secrets Manager
Les utilisateurs doivent disposer des autorisations requises pour effectuer des opérations liées à l’intégration de Secrets Manager. Vous pouvez créer des politiques IAM qui accordent des autorisations pour effectuer des opérations API spécifiques sur les ressources spécifiées dont ils ont besoin. Vous pouvez ensuite attacher ces politiques aux jeux d’autorisations ou rôles IAM qui requièrent ces autorisations. Pour plus d’informations, consultez [Identity and Access Management pour Amazon Aurora](UsingWithRDS.IAM.md).
Pour les opérations de création, de modification ou de restauration, l’utilisateur qui spécifie qu’Aurora doit gérer le mot de passe d’utilisateur principal dans Secrets Manager doit avoir les autorisations nécessaires pour effectuer les opérations suivantes :
+ `kms:DescribeKey`
+ `secretsmanager:CreateSecret`
+ `secretsmanager:TagResource`
L’autorisation `kms:DescribeKey` est requise pour accéder à votre clé gérée par le client pour `MasterUserSecretKmsKeyId` et pour décrire `aws/secretsmanager`.
Pour les opérations de création, de modification ou de restauration, l’utilisateur qui spécifie la clé gérée par le client pour chiffrer le secret dans Secrets Manager doit avoir les autorisations nécessaires pour effectuer les opérations suivantes :
+ `kms:Decrypt`
+ `kms:GenerateDataKey`
+ `kms:CreateGrant`
Pour les opérations de modification, l’utilisateur qui effectue la rotation du mot de passe d’utilisateur principal dans Secrets Manager doit être autorisé à effectuer l’opération suivante :
+ `secretsmanager:RotateSecret`
## Appliquer la gestion du mot de passe de l'utilisateur principal par dans AWS Secrets Manager
Vous pouvez utiliser des clés de condition IAM pour mettre en œuvre la gestion par Aurora du mot de passe d’utilisateur principal dans AWS Secrets Manager. La politique suivante n’autorise pas les utilisateurs à créer ni à restaurer des instances de base de données ou des clusters de bases de données , à moins que le mot de passe d’utilisateur principal soit géré par Aurora dans Secrets Manager.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": ["rds:CreateDBInstance", "rds:CreateDBCluster", "rds:RestoreDBInstanceFromS3", "rds:RestoreDBClusterFromS3"],
"Resource": "*",
"Condition": {
"Bool": {
"rds:ManageMasterUserPassword": false
}
}
}
]
}
```
------
**Note**
Cette politique impose la gestion des mots de passe dès AWS Secrets Manager leur création. Toutefois, vous pouvez toujours désactiver l’intégration de Secrets Manager et définir manuellement un mot de passe principal en modifiant le cluster.
Pour éviter cela, incluez `rds:ModifyDBInstance`, `rds:ModifyDBCluster` dans le bloc action de la politique. Sachez que cela empêche l’utilisateur d’appliquer d’autres modifications aux clusters existant(e)s n’ayant pas l’intégration de Secrets Manager activée.
Pour plus d’informations sur l’utilisation de clés de condition dans les politiques IAM, consultez [Clés de condition de politique pour Aurora](security_iam_service-with-iam.md#UsingWithRDS.IAM.Conditions) et [Exemples de politiques : Utilisation des clés de condition](UsingWithRDS.IAM.Conditions.Examples.md).
## Gestion du mot de passe utilisateur principal pour un cluster de base de données avec Secrets Manager
Vous pouvez configurer la gestion Aurora du mot de passe d’utilisateur principal dans Secrets Manager lorsque vous effectuez les actions suivantes :
+ [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md)
+ [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md)
+ [Migration des données d'une base de données MySQL externe vers un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Migrating.ExtMySQL.md)
Vous pouvez utiliser la console RDS AWS CLI, ou l'API RDS pour effectuer ces actions.
### Console
Suivez les instructions pour créer ou modifier un cluster de bases de données à l’aide de la console RDS :
+ [Création d’un cluster de bases de données](Aurora.CreateInstance.md#Aurora.CreateInstance.Creating)
+ [Modification d’une instance de base de données dans un cluster de bases de données](Aurora.Modifying.md#Aurora.Modifying.Instance)
Dans la console RDS, vous pouvez modifier n’importe quelle instance de base de données pour spécifier les paramètres de gestion des mots de passe d’utilisateur principal pour l’ensemble du cluster de bases de données.
+ [Restauration d’un cluster de bases de données Amazon Aurora MySQL à partir d’un compartiment Amazon S3](AuroraMySQL.Migrating.ExtMySQL.S3.md#AuroraMySQL.Migrating.ExtMySQL.S3.Restore)
Lorsque vous utilisez la console RDS pour effectuer l’une de ces opérations, vous pouvez spécifier que le mot de passe d’utilisateur principal est géré par Aurora dans Secrets Manager. Pour ce faire, lorsque vous créez ou restaurez un cluster de bases de données, sélectionnez **Manage master credentials in AWS Secrets Manager** (Gérer les informations d’identification principales dans ) dans **Credential settings** (Paramètres des informations d’identification). Lorsque vous modifiez un cluster de bases de données, sélectionnez **Manage master credentials in AWS Secrets Manager** (Gérer les informations d’identification principales dans ) dans **Settings** (Paramètres).
L’image suivante est un exemple du paramètre **Manage master credentials in AWS Secrets Manager** (Gérer les informations d’identification principales dans ) lors de la création ou de la restauration d’un cluster de bases de données.
![\[Gérez les informations d'identification principales dans AWS Secrets Manager\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-credential-settings.png)
Lorsque vous sélectionnez cette option, Aurora génère le mot de passe d’utilisateur principal et le gère tout au long de son cycle de vie dans Secrets Manager.
![\[Gérer les informations d'identification principales dans les options AWS Secrets Manager sélectionnées\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-create.png)
Vous pouvez choisir de chiffrer le secret à l’aide d’une clé KMS fournie par Secrets Manager ou d’une clé gérée par le client que vous créez. Quand Aurora gère les informations d’identification de base de données pour un cluster de bases de données, vous ne pouvez pas modifier la clé KMS utilisée pour chiffrer le secret.
Vous pouvez choisir d’autres paramètres en fonction de vos besoins.
Pour plus d’informations sur les paramètres disponibles quand vous créez un cluster de bases de données, consultez [Paramètres pour les clusters de bases de données Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings). Pour plus d’informations sur les paramètres disponibles quand vous modifiez un cluster de bases de données, consultez [Paramètres pour Amazon Aurora](Aurora.Modifying.md#Aurora.Modifying.Settings).
### AWS CLI
Pour spécifier qu’Aurora doit gérer le mot de passe d’utilisateur principal dans Secrets Manager, spécifiez l’option `--manage-master-user-password` dans l’une des commandes suivantes :
+ [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)
+ [restore-db-cluster-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html)
Lorsque vous spécifiez l’option `--manage-master-user-password` dans ces commandes, Aurora génère le mot de passe d’utilisateur principal et le gère tout au long de son cycle de vie dans Secrets Manager.
Pour chiffrer le secret, vous pouvez spécifier une clé gérée par le client ou utiliser la clé KMS par défaut, fournie par Secrets Manager. Utilisez l’option `--master-user-secret-kms-key-id` pour spécifier une clé gérée par le client. L'identifiant de clé AWS KMS est l'ARN de la clé, l'ID de clé, l'alias ARN ou le nom d'alias de la clé KMS. Pour utiliser une clé KMS dans une autre Compte AWS, spécifiez l'ARN de la clé ou l'alias ARN. Quand Aurora gère les informations d’identification de base de données pour un cluster de bases de données, vous ne pouvez pas modifier la clé KMS utilisée pour chiffrer le secret.
Vous pouvez choisir d’autres paramètres en fonction de vos besoins.
Pour plus d’informations sur les paramètres disponibles quand vous créez un cluster de bases de données, consultez [Paramètres pour les clusters de bases de données Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings). Pour plus d’informations sur les paramètres disponibles quand vous modifiez un cluster de bases de données, consultez [Paramètres pour Amazon Aurora](Aurora.Modifying.md#Aurora.Modifying.Settings).
Cet exemple crée un cluster de bases de données et spécifie qu’Aurora doit gérer le mot de passe dans Secrets Manager. Ce secret est chiffré à l’aide de la clé KMS fournie par Secrets Manager.
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds create-db-cluster \
2. --db-cluster-identifier sample-cluster \
3. --engine aurora-mysql \
4. --engine-version 8.0 \
5. --master-username admin \
6. --manage-master-user-password
```
Pour Windows :
```
1. aws rds create-db-cluster ^
2. --db-cluster-identifier sample-cluster ^
3. --engine aurora-mysql ^
4. --engine-version 8.0 ^
5. --master-username admin ^
6. --manage-master-user-password
```
### API RDS
Pour spécifier que Aurora doit gérer le mot de passe d’utilisateur principal dans Secrets Manager, affectez au paramètre `ManageMasterUserPassword` la valeur `true` dans l’une des opérations suivantes :
+ [CréerDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html)
+ [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)
+ [Restaurer DBCluster depuis S3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromS3.html)
Lorsque vous affectez au paramètre `ManageMasterUserPassword` la valeur `true` dans l’une de ces opérations, Aurora génère le mot de passe d’utilisateur principal et le gère tout au long de son cycle de vie dans Secrets Manager.
Pour chiffrer le secret, vous pouvez spécifier une clé gérée par le client ou utiliser la clé KMS par défaut, fournie par Secrets Manager. Utilisez le paramètre `MasterUserSecretKmsKeyId` pour spécifier une clé gérée par le client. L'identifiant de clé AWS KMS est l'ARN de la clé, l'ID de clé, l'alias ARN ou le nom d'alias de la clé KMS. Pour utiliser une clé KMS dans un autre Compte AWS, spécifiez l’ARN de la clé ou l’ARN de l’alias. Quand Aurora gère les informations d’identification de base de données pour un cluster de bases de données, vous ne pouvez pas modifier la clé KMS utilisée pour chiffrer le secret.
## Rotation du secret du mot de passe utilisateur principal pour un cluster de base de données
Quand Aurora effectue la rotation d’un secret de mot de passe d’utilisateur principal, Secrets Manager génère une nouvelle version de secret pour le secret existant. La nouvelle version du secret contient le nouveau mot de passe d’utilisateur principal. Aurora modifie le mot de passe d’utilisateur principal du cluster de bases de données pour qu’il corresponde au mot de passe de la nouvelle version de secret.
Vous pouvez effectuer immédiatement la rotation d’un secret au lieu d’attendre une rotation planifiée. Pour effectuer la rotation d’un secret de mot de passe d’utilisateur principal dans Secrets Manager, modifiez le cluster de bases de données . Pour plus d’informations sur la modification d’un cluster de bases de données, consultez [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md).
Vous pouvez modifier immédiatement le secret d'un mot de passe utilisateur principal à l'aide de la console RDS, de l' AWS CLI API RDS ou de l'API RDS. Le nouveau mot de passe comporte toujours 28 caractères et contient au moins un caractère majuscule et minuscule, un chiffre et un caractère de ponctuation.
### Console
Pour effectuer la rotation d’un secret de mot de passe d’utilisateur principal à l’aide de la console RDS, modifiez le cluster de bases de données et sélectionnez **Rotate secret immediately** (Effectuer immédiatement une rotation du secret) dans **Settings** (Paramètres).
![\[Effectuer immédiatement une rotation du secret de mot de passe d’utilisateur principal\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-rotate-aurora.png)
Suivez les instructions pour modifier un cluster de bases de données avec la console RDS dans [Modification du cluster de bases de données à partir de la console, de l’CLI (CLI) et de l’API](Aurora.Modifying.md#Aurora.Modifying.Cluster). Vous devez choisir **Apply immediately** (Appliquer immédiatement) sur la page de confirmation.
### AWS CLI
Pour faire pivoter le code secret d'un utilisateur principal à l'aide de AWS CLI, utilisez la [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)commande et spécifiez l'`--rotate-master-user-password`option. Vous devez spécifier l’option `--apply-immediately` lorsque vous effectuez la rotation du mot de passe principal.
Cet exemple effectue la rotation d’un secret de mot de passe d’utilisateur principal.
**Example**
Pour Linux, macOS ou Unix :
```
1. aws rds modify-db-cluster \
2. --db-cluster-identifier mydbcluster \
3. --rotate-master-user-password \
4. --apply-immediately
```
Pour Windows :
```
1. aws rds modify-db-cluster ^
2. --db-cluster-identifier mydbcluster ^
3. --rotate-master-user-password ^
4. --apply-immediately
```
### API RDS
Vous pouvez faire pivoter le secret du mot de passe d'un utilisateur principal à l'aide de DBCluster l'opération [Modifier](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) et en définissant le `RotateMasterUserPassword` paramètre sur`true`. Vous devez affecter au paramètre `ApplyImmediately` la valeur `true` lorsque vous effectuez la rotation du mot de passe principal.
## Afficher les détails d'un secret pour un cluster de base de données
Vous pouvez récupérer vos secrets à l'aide de la console ([https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)) ou de la commande AWS CLI ([get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html)Secrets Manager).
Vous pouvez trouver le Amazon Resource Name (ARN) d'un secret géré par Aurora dans Secrets Manager avec la console RDS AWS CLI, ou l'API RDS.
### Console
**Pour afficher les détails d'un secret géré par Aurora dans Secrets Manager**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**.
1. Choisissez le nom du cluster de bases de données pour afficher ses détails.
1. Cliquez sur l’onglet **Configuration**.
Dans **Master Credentials ARN** (ARN des informations d’identification principales), vous pouvez consulter l’ARN du secret.
![\[Affichage des détails d’un secret géré par Aurora dans Secrets Manager\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-view-cluster.png)
Vous pouvez suivre le lien **Manage in Secrets Manager** (Gérer dans Secrets Manager) pour consulter et gérer le secret dans la console Secrets Manager.
### AWS CLI
Vous pouvez utiliser la AWS CLI [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)commande RDS pour trouver les informations suivantes sur un secret géré par dans Secrets Manager :
+ `SecretArn` : l’ARN du secret
+ `SecretStatus` : le statut du secret
Les valeurs de statut possibles incluent les suivantes :
+ `creating` : le secret est en cours de création.
+ `active` : le secret est disponible pour une utilisation et une rotation normales.
+ `rotating` : la rotation du secret est en cours.
+ `impaired` : le secret peut être utilisé pour accéder aux informations d’identification de base de données, mais il est impossible d’effectuer sa rotation. Un secret peut avoir ce statut si, par exemple, les autorisations sont modifiées de telle sorte que RDS ne puisse plus accéder au secret ou à la clé KMS associée à ce secret.
Lorsqu’un secret possède ce statut, vous pouvez corriger la condition à l’origine de ce statut. Si vous corrigez la condition à l’origine du statut, celui-ci reste `impaired` jusqu’à la rotation suivante. Vous pouvez également modifier le cluster de bases de données pour désactiver la gestion automatique des informations d’identification de base de données, puis modifier à nouveau le cluster de bases de données pour activer la gestion automatique des informations d’identification de base de données. Pour modifier le cluster de base de données, utilisez l'`--manage-master-user-password`option de la [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)commande.
+ `KmsKeyId` : l’ARN de la clé KMS utilisée pour chiffrer le secret
Spécifiez l’option `--db-cluster-identifier` permettant d’afficher la sortie pour un cluster de bases de données spécifique. Cet exemple montre la sortie d’un secret utilisé par un cluster de bases de données.
**Example**
```
1. aws rds describe-db-clusters --db-cluster-identifier mydbcluster
```
L’exemple suivant montre la sortie pour un secret :
```
"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"
}
```
Lorsque vous disposez de l'ARN secret, vous pouvez consulter les détails du secret à l'aide de la commande [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html)Secrets Manager CLI.
Cet exemple montre les détails du secret dans l’exemple de sortie précédent.
**Example**
Pour Linux, macOS ou Unix :
```
aws secretsmanager get-secret-value \
--secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx'
```
Pour Windows :
```
aws secretsmanager get-secret-value ^
--secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx'
```
### API RDS
Vous pouvez consulter l'ARN, le statut et la clé KMS d'un secret géré par Aurora dans Secrets Manager à l'aide de l'opération [Describe DBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) RDS et en définissant le `DBClusterIdentifier` paramètre sur un identifiant de cluster de base de données. Les détails sur le secret sont inclus dans la sortie.
Lorsque vous disposez de l'ARN secret, vous pouvez consulter les détails du secret à l'aide de l'opération [GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html)Secrets Manager.
# Protection des données dans Amazon RDS
Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) AWS s'applique à Amazon Relational Database Service. Comme décrit dans ce modèle, AWS est responsable de la protection de l’infrastructure globale sur laquelle l’ensemble du AWS Cloud s’exécute. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog Modèle de responsabilité partagée [AWS et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécurité AWS*.
À des fins de protection des données, nous vous recommandons de protéger les informations d’identification Compte AWS et de configurer les comptes utilisateur individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :
+ Utilisez l’authentification multifactorielle (MFA) avec chaque compte.
+ Utilisez les certificats SSL/TLS pour communiquer avec les ressources AWS. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez une API (Interface de programmation) et la journalisation des activités des utilisateurs avec AWS CloudTrail. Pour plus d’informations sur l’utilisation des sentiers CloudTrail pour capturer des activités AWS, consultez la section [Utilisation des sentiers CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *Guide de l’utilisateur AWS CloudTrail*.
+ Utilisez des solutions de chiffrement AWS, ainsi que tous les contrôles de sécurité par défaut au sein des Services AWS.
+ Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.
+ Si vous avez besoin de modules de chiffrement validés FIPS (Federal Information Processing Standard) 140-3 lorsque vous accédez à AWS via une interface de ligne de commande ou une API (interface de programmation), utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez [Norme FIPS (Federal Information Processing Standard) 140-3](https://aws.amazon.com/compliance/fips/).
Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela s'applique aussi lorsque vous utilisez Amazon RDS ou d'autres Services AWS à l'aide de la console, de l'API, de l'AWS CLI ou des kits SDK AWS. Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.
**Topics**
+ [Protection des données à l’aide du chiffrement](Encryption.md)
+ [Confidentialité du trafic inter-réseau](inter-network-traffic-privacy.md)
# Protection des données à l’aide du chiffrement
Amazon Aurora chiffre les ressources de base de données au niveau de la couche de stockage. Vous pouvez également chiffrer les connexions aux clusters de base de données.
**Topics**
+ [Chiffrement des ressources Amazon Aurora](Overview.Encryption.md)
+ [AWS KMS key gestion](Overview.Encryption.Keys.md)
+ [Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md)
+ [Rotation de votre SSL/TLS certificat](UsingWithRDS.SSL-certificate-rotation.md)
# Chiffrement des ressources Amazon Aurora
Amazon Aurora protège vos données à la fois au repos et en transit, qu'elles soient transférées entre des clients sur site et Amazon Aurora, ou entre Amazon Aurora et d'autres ressources. AWS Amazon Aurora chiffre toutes les données utilisateur de vos clusters de base de données Amazon Aurora, y compris les journaux, les sauvegardes automatisées et les instantanés.
Une fois vos données chiffrées, Amazon Aurora gère l'authentification de l'accès et le déchiffrement de vos données de manière transparente avec un impact minimal sur les performances. Vous n’avez pas besoin de modifier vos applications clientes de base de données pour utiliser le chiffrement.
**Note**
Pour les clusters d' de base de données chiffrés et non chiffrés, les données en transit entre la source et les répliques lues sont chiffrées, même lors de la réplication entre régions. AWS
**Topics**
+ [Présentation du chiffrement dans les ressources Amazon Aurora](#Overview.Encryption.Overview)
+ [Chiffrement d’un cluster de bases de données Amazon Aurora](#Overview.Encryption.Enabling)
+ [Détermination si le chiffrement est activé pour un cluster de bases de données](#Overview.Encryption.Determining)
+ [Disponibilité du chiffrement Amazon Aurora](#Overview.Encryption.Availability)
+ [Chiffrement en transit](#Overview.Encryption.InTransit)
+ [Limitations des clusters de bases de données chiffrées Amazon Aurora](#Overview.Encryption.Limitations)
## Présentation du chiffrement dans les ressources Amazon Aurora
Les clusters de base de données chiffrée Amazon Aurora fournissent une couche supplémentaire de protection des données en sécurisant vos données contre tout accès non autorisé au stockage sous-jacent. Tous les nouveaux clusters de bases de données créés le 18 février 2026 ou après 2026 dans Amazon Aurora sont chiffrés au repos à l'aide du chiffrement AES-256 conforme aux normes du secteur. Ce chiffrement s'effectue automatiquement en arrière-plan, sécurisant ainsi vos données sans aucune action de votre part. Cela permet également de réduire la charge opérationnelle et la complexité liées à la protection des données sensibles. Avec le chiffrement au repos, vous pouvez protéger les applications sensibles en termes de conformité et de sécurité contre les menaces accidentelles et malveillantes, tout en respectant les exigences réglementaires.
Amazon Aurora utilise une AWS Key Management Service clé pour chiffrer ces ressources. AWS KMS combine du matériel et des logiciels sécurisés et hautement disponibles pour fournir un système de gestion des clés adapté au cloud. Lors de la création d'un nouveau cluster de bases de données, Amazon Aurora utilise le chiffrement côté serveur (SSE) avec une [cléAWS détenue par défaut](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-key). Toutefois, vous pouvez choisir entre trois types de chiffrement en fonction de vos besoins en matière de sécurité et de conformité :
+ **AWS clé possédée (SSE-RDS)** : clé de chiffrement entièrement AWS contrôlée que vous ne pouvez ni visualiser ni gérer, utilisée automatiquement par Aurora pour le chiffrement par défaut.
+ **AWS clé gérée (AMK)** — Cette clé est créée et gérée par AWS et est visible dans votre compte, mais elle n'est pas personnalisable. Il n'y a pas de frais mensuels, mais des frais AWS KMS d'API s'appliqueront.
+ **Clé gérée par le client (CMK)** — La clé est stockée dans votre compte et vous la créez, la détenez et la gérez. Vous avez le contrôle total de la clé KMS (AWS KMS des frais s'appliquent).
AWS les clés gérées constituent une ancienne option de chiffrement qui reste disponible à des fins de rétrocompatibilité. Amazon Aurora utilise des clés AWS détenues par défaut pour chiffrer vos données, offrant ainsi une protection de sécurité renforcée sans frais supplémentaires ni frais de gestion. Dans la plupart des cas d'utilisation, nous recommandons d'utiliser soit la clé AWS détenue par défaut pour des raisons de simplicité et de rentabilité, soit une clé gérée par le client (CMK) si vous avez besoin d'un contrôle total sur vos clés de chiffrement. Pour plus d'informations sur les types de clés, consultez les [sections clés gérées par le client et clés AWS gérées](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt).
**Note**
**Important :** pour les instances de base de données source ou les clusters créés avant le 18 février 2026, pour lesquels vous n'avez pas opté pour le chiffrement, les instantanés, les clones et les répliques Amazon Aurora (instance de lecture) créés à partir de ces sources ne seront pas chiffrés. Cependant, les opérations de restauration et de réplication logique en dehors du cluster Amazon Aurora produiront des instances chiffrées.
Pour un cluster de bases de données chiffrée Amazon Aurora, les instances de bases de données, journaux, sauvegardes et instantanés sont tous chiffrés. Pour plus d’informations sur la disponibilité et les limites du chiffrement, consultez [Disponibilité du chiffrement Amazon Aurora](#Overview.Encryption.Availability) et [Limitations des clusters de bases de données chiffrées Amazon Aurora](#Overview.Encryption.Limitations).
Lorsque vous créez un cluster de bases de données chiffré, vous pouvez choisir une clé gérée par le client ou une clé Clé gérée par AWS pour Amazon Aurora pour chiffrer votre cluster de bases de données. Si vous ne spécifiez pas l'identifiant de clé pour une clé gérée par le client, Amazon Aurora l'utilise Clé gérée par AWS pour votre nouveau cluster de bases de données. Amazon Aurora crée un Clé gérée par AWS pour Amazon Aurora pour votre AWS compte. Votre AWS compte est associé à un compte Amazon Aurora différent Clé gérée par AWS pour chaque AWS région.
Pour gérer les clés gérées par le client qui sont utilisées pour le chiffrement et le déchiffrement de vos ressources Amazon Aurora, vous utilisez [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/).
À l'aide de AWS KMS, vous pouvez créer des clés gérées par le client et définir les politiques permettant de contrôler l'utilisation de ces clés gérées par le client. AWS KMS prend en charge CloudTrail, afin que vous puissiez auditer l'utilisation des clés KMS afin de vérifier que les clés gérées par le client sont utilisées de manière appropriée. Vous pouvez utiliser vos clés gérées par le client avec Amazon Aurora et les AWS services pris en charge tels qu'Amazon S3, Amazon EBS et Amazon Redshift. Pour obtenir la liste des services intégrés AWS KMS, consultez la section [Intégration des AWS services](https://aws.amazon.com/kms/features/#AWS_Service_Integration). Quelques considérations relatives à l’utilisation des clés KMS :
+ Une fois que vous avez créé une instance de base de données chiffrée, vous ne pouvez pas modifier la clé KMS utilisée par cette instance. Assurez-vous de déterminer vos exigences en matière de clé KMS avant de créer votre instance de base de données chiffrée. Si vous devez modifier la clé de chiffrement de votre cluster de base de données, procédez comme suit :
+ Créez un instantané manuel de votre cluster.
+ Restaurez le snapshot et activez le chiffrement avec la clé KMS de votre choix pendant l'opération de restauration.
+ Si vous restaurez un instantané non chiffré et que vous choisissez de ne pas chiffrer, le cluster de base de données créé sera chiffré à l'aide du chiffrement par défaut au repos (cléAWS détenue par -owned).
+ Vous ne pouvez pas partager un instantané chiffré à l'aide Clé gérée par AWS du AWS compte qui l'a partagé.
+ Chaque instance de base de données du cluster de base de données partage le même stockage chiffré avec la même clé KMS.
**Important**
Dans certains cas, Amazon Aurora peut perdre l’accès à la clé KMS pour un cluster de bases de données lorsque vous désactivez la clé KMS. Dans ce cas, le cluster de bases de données chiffré entre dans l’état `inaccessible-encryption-credentials-recoverable`. Le cluster de bases de données reste dans cet état pendant sept jours, pendant lesquels l’instance est arrêtée. Les appels d’API effectués vers le cluster de bases de données pendant cette période risquent d’échouer. Pour restaurer le cluster de bases de données, activez la clé KMS, puis redémarrez le cluster. Vous pouvez activer la clé KMS depuis l'API AWS Management Console AWS CLI, ou RDS. Redémarrez le cluster de base de données à l'aide de la AWS CLI commande [start-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/start-db-cluster.html)ou AWS Management Console.
L’état `inaccessible-encryption-credentials-recoverable` s’applique uniquement aux clusters de bases de données qui peuvent être interrompus. Cet état récupérable ne s’applique pas aux instances qui ne peuvent pas s’arrêter, telles que les clusters contenant des réplicas en lecture inter-régions. Pour plus d’informations, consultez [Limites liées à l’arrêt et au démarrage des clusters de bases de données Aurora](aurora-cluster-stop-start.md#aurora-cluster-stop-limitations).
Si le cluster de bases de données n’est pas récupéré dans un délai de sept jours, il passe à l’état `inaccessible-encryption-credentials` terminal. Dans cet état, le cluster de bases de données n’est plus utilisable et vous ne pouvez le restaurer qu’à partir d’une sauvegarde. Nous vous recommandons vivement de toujours activer les sauvegardes pour éviter la perte de données dans vos bases de données.
Lors de la création d’un cluster de bases de données, Aurora vérifie si le principal appelant dispose a accès à la clé KMS, puis génère une autorisation à partir de cette clé KMS, qu’il utilisera pendant toute la durée de vie du cluster de bases de données. La révocation de l’accès du principal appelant à la clé KMS n’affecte pas la base de données en cours d’exécution. Lorsque vous utilisez des clés KMS dans des scénarios entre comptes, tels que la copie d’un instantané sur un autre compte, la clé KMS doit être partagée avec l’autre compte. Si vous créez un cluster de bases de données à partir de l’instantané sans spécifier de clé KMS différente, le nouveau cluster utilise la clé KMS du compte source. Le fait de révoquer l’accès à la clé après la création du cluster de bases de données n’a aucun impact sur ce cluster. Toutefois, la désactivation de la clé affecte tous les clusters de bases de données chiffrés avec cette clé. Afin d’éviter cette situation, indiquez une clé différente au moment de la copie de l’instantané.
Pour plus d’informations sur les clés KMS, consultez [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) dans le *Guide du développeur AWS Key Management Service * et [AWS KMS key gestion](Overview.Encryption.Keys.md).
## Chiffrement d’un cluster de bases de données Amazon Aurora
Tous les nouveaux clusters de bases de données créés le 18 février 2026 ou après cette date sont chiffrés par défaut à l'aide d'une clé AWS détenue.
Pour chiffrer un nouveau cluster de base de données à l'aide d'une clé gérée par le client Clé gérée par AWS ou d'une clé gérée par le client, choisissez l'option sur la console. Pour plus d’informations sur la création d’un cluster de bases de données, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md).
Si vous utilisez la [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) AWS CLI commande pour créer un cluster de base de données chiffré, définissez le `--storage-encrypted` paramètre. Si vous utilisez l'opération [Create DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) API, définissez le `StorageEncrypted` paramètre sur true.
Une fois que vous avez créé un cluster de bases de données chiffrées, vous ne pouvez pas modifier la clé KMS pour ce cluster de bases de données. Vous devez donc prendre soin de déterminer vos besoins en termes de clés KMS avant de créer votre cluster de base de données chiffrées.
Si vous utilisez la AWS CLI `create-db-cluster` commande pour créer un cluster de base de données chiffré avec une clé gérée par le client, définissez le `--kms-key-id` paramètre sur n'importe quel identifiant de clé pour la clé KMS. Si vous utilisez l’opération Amazon RDS de l’API `CreateDBInstance`, définissez le paramètre `KmsKeyId` sur n’importe quel identifiant de clé pour la clé KMS. Pour utiliser une clé gérée par le client dans un autre AWS compte, spécifiez l'ARN de la clé ou l'alias ARN.
## Détermination si le chiffrement est activé pour un cluster de bases de données
Vous pouvez utiliser l'API AWS Management Console AWS CLI, ou RDS pour déterminer si le chiffrement au repos est activé pour un cluster de bases de données.
### Console
**Pour déterminer si le chiffrement au repos est activé pour un cluster de bases de données**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Databases (Bases de données)**.
1. Sélectionnez le nom du cluster de base de données que vous souhaitez vérifier pour en voir les détails.
1. Cliquez sur l’onglet **Configuration** et cochez la case **Encryption** (Chiffrement).
![\[Vérification du chiffrement au repos pour un cluster de base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/encryption-aurora-instance.png)
### AWS CLI
Pour déterminer si le chiffrement au repos est activé pour un cluster de base de données à l'aide de AWS CLI, appelez la [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)commande avec l'option suivante :
+ `--db-cluster-identifier` : nom du cluster de bases de données.
L’exemple suivant utilise une requête pour renvoyer `TRUE` ou `FALSE` concernant le chiffrement au repos pour le cluster de bases de données `mydb`.
**Example**
```
1. aws rds describe-db-clusters --db-cluster-identifier mydb --query "*[].{StorageEncrypted:StorageEncrypted}" --output text
```
### API RDS
Pour déterminer si le chiffrement au repos est activé pour un cluster de bases de données à l'aide de l'API Amazon RDS, appelez l'DBClustersopération [Describe](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) avec le paramètre suivant :
+ `DBClusterIdentifier` : nom du cluster de bases de données.
## Disponibilité du chiffrement Amazon Aurora
Le chiffrement Amazon Aurora est actuellement disponible pour tous les moteurs de base de données et types de stockage.
**Note**
Le chiffrement Amazon Aurora n’est pas disponible pour la classe d’instance de base de données db.t2.micro.
## Chiffrement en transit
**Chiffrement au niveau de la couche physique**
Toutes les données circulant Régions AWS sur le réseau AWS mondial sont automatiquement cryptées au niveau de la couche physique avant de quitter les installations AWS sécurisées. Tout le trafic entre les deux AZs est crypté. Des couches supplémentaires de chiffrement, y compris celles présentées dans cette section, peuvent fournir des protections supplémentaires.
**Chiffrement fourni par le peering Amazon VPC et le peering interrégional Transit Gateway**
Tout le trafic entre régions qui utilise un appairage VPC Amazon et Transit Gateway est automatiquement chiffré en bloc quand il quitte une région. Une couche de cryptage supplémentaire est automatiquement fournie au niveau de la couche physique pour tout le trafic avant qu'il ne quitte les installations AWS sécurisées.
**Chiffrement entre les instances**
AWS fournit une connectivité sécurisée et privée entre les instances de base de données de tous types. En outre, certains types d’instances utilisent les capacités de déchargement du matériel du système Nitro sous-jacent pour chiffrer automatiquement le trafic en transit entre instances. Ce chiffrement utilise des algorithmes de chiffrement authentifié avec données associées (AEAD), avec un chiffrement 256 bits. Il n’y a aucun impact sur les performances du réseau. Pour prendre en charge ce chiffrement supplémentaire du trafic en transit entre les instances, les exigences suivantes doivent être satisfaites :
+ Les instances utilisent les types d’instance suivants :
+ **Usage général :** M6i, M6id, M6in, M6idn, M7g
+ **Optimisé pour la mémoire** : R6i, R6id, R6in, R6idn, R7g, X2idn, X2iedn, X2iezn
+ Les instances se trouvent dans la même Région AWS.
+ Les instances se trouvent dans le même VPC ou peered VPCs, et le trafic ne passe pas par un périphérique ou un service réseau virtuel, tel qu'un équilibreur de charge ou une passerelle de transit.
## Limitations des clusters de bases de données chiffrées Amazon Aurora
Les limitations suivantes existent pour les clusters de bases de données chiffrés Amazon Aurora :
+ Vous ne pouvez pas désactiver le chiffrement d’un cluster de bases de données chiffré.
+ Si vous disposez d'un cluster non chiffré existant, tous les instantanés créés à partir de ce cluster seront également déchiffrés. Pour créer un instantané chiffré à partir d'un cluster non chiffré, vous devez le copier et spécifier une clé gérée par le client lors de l'opération de copie. Vous ne pouvez pas créer un instantané chiffré à partir d'un instantané non chiffré sans spécifier une clé gérée par le client.
+ Vous ne pouvez pas créer un instantané chiffré d'une de base de données non chiffrée.
+ Un instantané de cluster de bases de données chiffrées doit être chiffré à l’aide de la même clé KMS que le cluster de bases de données.
+ Vous ne pouvez pas convertir un cluster de base de données non chiffrée vers un cluster chiffré. Toutefois, vous pouvez restaurer un instantané non chiffré dans un cluster de bases de données Aurora chiffré. Pour ce faire, spécifiez une clé KMS lorsque vous procédez à la restauration à partir de l’instantané non chiffré.
+ Si vous disposez d'un cluster non chiffré existant, toute réplique Amazon Aurora (instance de lecture) créée à partir de ce cluster sera également déchiffrée. Pour créer un cluster chiffré à partir d'un cluster non chiffré, vous devez restaurer le cluster de base de données. Le cluster restauré sera chiffré par défaut après l'opération de restauration.
+ Pour copier un instantané chiffré d'une AWS région à une autre, vous devez spécifier la clé KMS dans la AWS région de destination. Cela est dû au fait que les clés KMS sont spécifiques à la AWS région dans laquelle elles sont créées.
L'instantané source reste chiffré pendant tout le processus de copie. Amazon Aurora utilise un chiffrement d’enveloppe pour protéger les données pendant le processus de copie. Pour plus d’informations sur le chiffrement d’enveloppe, consultez [Chiffrement d’enveloppe](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) dans le *Guide du développeur AWS Key Management Service *.
+ Vous ne pouvez pas déchiffrer un d’instances de base de données chiffrées. Vous pouvez cependant exporter des données à partir d’un d’instances de base de données et importer les données dans un d’instances de base de données non chiffrées.
# AWS KMS key gestion
Amazon Aurora s’intègre automatiquement avec [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/) pour la gestion des clés. Amazon Aurora utilise le chiffrement d’enveloppe. Pour plus d’informations sur le chiffrement d’enveloppe, consultez [Chiffrement d’enveloppe](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) dans le *Guide du développeur AWS Key Management Service *.
Vous pouvez utiliser deux types de AWS KMS clés pour chiffrer vos clusters d' de base de données.
+ Si vous souhaitez un contrôle total sur une clé KMS, vous devez créer une *clé gérée par le client*. Pour plus d’informations sur les clés gérées par le client, consultez [Clés gérées par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) dans le *Guide du développeur AWS Key Management Service *.
+ *Clés gérées par AWS*sont des clés KMS de votre compte créées, gérées et utilisées en votre nom par un AWS service intégré à AWS KMS. Par défaut, la Clé gérée par AWS RDS (`aws/rds`) est utilisée pour le chiffrement. Vous ne pouvez pas gérer, faire pivoter ou supprimer le RDS. Clé gérée par AWS Pour plus d'informations à ce sujet Clés gérées par AWS, consultez [Clés gérées par AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)le *guide du AWS Key Management Service développeur*.
Pour gérer les clés KMS utilisées pour les clusters d' de base de données chiffrées Amazon Aurora, utilisez le [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/) dans la [AWS KMS console](https://console.aws.amazon.com/kms) AWS CLI, le ou l' AWS KMS API. Pour consulter les journaux d’audit de chaque action effectuée à l’aide d’une clé gérée par le client ou par AWS , utilisez [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/). Pour plus d’informations sur la rotation des clés, consultez [Rotation des clés AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html).
## Autoriser l’utilisation d’une clé gérée par le client
Quand Aurora utilise une clé gérée par le client dans le cadre d’opérations de chiffrement, il agit au nom de l’utilisateur qui crée ou modifie la ressource Aurora.
Pour créer une ressource Aurora à l’aide d’une clé gérée par un client, un utilisateur doit avoir les autorisations nécessaires pour appeler les opérations suivantes sur la clé gérée par le client :
+ `kms:CreateGrant`
+ `kms:DescribeKey`
Vous pouvez spécifier les autorisations requises dans une politique de clé ou dans une IAM politique si la politique de clé le permet.
**Important**
Lorsque vous utilisez des déclarations de refus explicites pour toutes les ressources (\$1) dans les politiques AWS KMS clés des services gérés tels qu'Amazon RDS, vous devez spécifier une condition pour autoriser le compte propriétaire de la ressource. Les opérations peuvent échouer sans cette condition, même si la règle de refus inclut des exceptions pour votre utilisateur IAM.
**Astuce**
Pour suivre le principe du moindre privilège, n’autorisez pas l’accès complet à `kms:CreateGrant`. Utilisez plutôt la [clé de ViaService condition kms :](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) pour permettre à l'utilisateur de créer des autorisations sur la clé KMS uniquement lorsque l'autorisation est créée en son nom par un AWS service.
Vous pouvez renforcer la politique IAM de différentes manières. Par exemple, si vous souhaitez autoriser l'utilisation de la clé gérée par le client uniquement pour les demandes provenant de Aurora, utilisez la [clé de kms: ViaService condition](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) avec la `rds..amazonaws.com` valeur. Vous pouvez également utiliser les clés ou les valeurs du contexte [Contexte de chiffrement Amazon RDS](#Overview.Encryption.Keys.encryptioncontext) comme condition d’utilisation de la clé gérée par le client pour le chiffrement.
Pour plus d’informations, consultez [Autoriser des utilisateurs d’autres comptes à utiliser une clé KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) dans le *Guide du développeur AWS Key Management Service *.
## Contexte de chiffrement Amazon RDS
Quand Aurora utilise votre clé KMS ou quand Amazon EBS utilise la clé KMS pour le compte d’Aurora, le service spécifie un [contexte de chiffrement](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context). Le contexte de chiffrement est constitué de [données authentifiées supplémentaires](https://docs.aws.amazon.com/crypto/latest/userguide/cryptography-concepts.html#term-aad) (AAD) AWS KMS utilisées pour garantir l'intégrité des données. Autrement dit, quand un contexte de chiffrement est spécifié pour une opération de chiffrement, le service doit spécifier le même contexte de chiffrement pour l’opération de déchiffrement. Dans le cas contraire, le déchiffrement échoue. Le contexte de chiffrement est également écrit dans vos journaux [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) pour vous aider à comprendre pourquoi une clé KMS donnée a été utilisée. Vos CloudTrail journaux peuvent contenir de nombreuses entrées décrivant l'utilisation d'une clé KMS, mais le contexte de chiffrement de chaque entrée de journal peut vous aider à déterminer la raison de cette utilisation particulière.
Au minimum, Aurora utilise toujours l’ID de cluster de bases de données pour le contexte de chiffrement, comme dans l’exemple au format JSON suivant :
```
{ "aws:rds:dbc-id": "cluster-CQYSMDPBRZ7BPMH7Y3RTDG5QY" }
```
Ce contexte de chiffrement peut vous aider à identifier le cluster de bases de données pour lequel votre clé KMS a été utilisée.
Quand votre clé KMS est utilisée pour un cluster de bases de données spécifique et un volume Amazon EBS spécifique, l’ID du cluster de bases de données et l’ID de volume Amazon EBS sont utilisés pour le contexte de chiffrement, comme dans l’exemple au format JSON suivant :
```
{
"aws:rds:dbc-id": "cluster-BRG7VYS3SVIFQW7234EJQOM5RQ",
"aws:ebs:id": "vol-ad8c6542"
}
```
# Utilisation SSL/TLS pour chiffrer une connexion à une de clusters
Vous pouvez utiliser le protocole SSL (Secure Socket Layer) ou le protocole TLS (Transport Layer Security) à partir de votre application pour chiffrer une connexion à un cluster de bases de données exécutant Aurora MySQL ou Aurora PostgreSQL.
Les connexions SSL/TLS fournissent une couche de sécurité en chiffrant les données en transit entre votre client et le cluster de bases de données. En option, votre SSL/TLS connexion peut effectuer une vérification de l'identité du serveur en validant le certificat de serveur installé sur votre base de données. Pour exiger la vérification de l’identité du serveur, suivez ce processus général :
1. Choisissez l’**autorité de certification (CA)** qui signe le **certificat de serveur de base de données** pour votre base de données. Pour plus d’informations sur les autorités de certification, consultez [Autorités de certification](#UsingWithRDS.SSL.RegionCertificateAuthorities) .
1. Téléchargez une offre groupée de certificats à utiliser lorsque vous vous connectez à la base de données. Pour télécharger une offre groupée de certificats, consultez [Forfaits de certificats par Région AWS](#UsingWithRDS.SSL.CertificatesAllRegions) .
**Note**
Tous les certificats sont disponibles uniquement pour le téléchargement sur des connexions SSL/TLS.
1. Connectez-vous à la base de données en utilisant le processus de votre moteur de base de données pour implémenter SSL/TLS les connexions. Chaque moteur de base de données possède son propre processus d'implémentation SSL/TLS. To learn how to implement SSL/TLS pour votre base de données. Suivez le lien correspondant à votre moteur de base de données :
+ [Sécurité avec Amazon Aurora MySQL](AuroraMySQL.Security.md)
+ [Sécurité avec Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md)
## Autorités de certification
L’**autorité de certification (CA)** est le certificat qui identifie l’autorité de certification racine en haut de la chaîne de certificats. L’autorité de certification signe le **certificat de serveur de base de données**, qui est installé sur chaque instance de base de données. Le certificat de serveur de base de données identifie l’instance de base de données en tant que serveur approuvé.
![\[Présentation des autorités de certification\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority-overview.png)
Amazon RDS fournit les éléments suivants CAs pour signer le certificat du serveur de base de données d'une base de données.
****
| Autorité de certification (CA) | Description | Nom commun |
| --- | --- | --- |
| rds-ca-rsa2048-g1 | Utilise une autorité de certification avec l'algorithme de clé privée RSA 2048 et l'algorithme de SHA256 signature dans la plupart des cas. Régions AWS Dans le AWS GovCloud (US) Regions, cette autorité de certification utilise une autorité de certification avec un algorithme de clé privée et un algorithme de SHA384 signature RSA 2048. Cette autorité de certification prend en charge la rotation automatique des certificats de serveur. | Amazon RDS region-identifier Root CA G1 RSA2048 |
| rds-ca-rsa4096-g1 | Utilise une autorité de certification avec l'algorithme de clé privée et l'algorithme de SHA384 signature RSA 4096. Cette autorité de certification prend en charge la rotation automatique des certificats de serveur. | Amazon RDS region-identifier Root CA G1 RSA4096 |
| rds-ca-ecc384-g1 | Utilise une autorité de certification avec un algorithme de clé privée et un algorithme de SHA384 signature ECC 384. Cette autorité de certification prend en charge la rotation automatique des certificats de serveur. | Amazon RDS region-identifier Root CA G1 ECC384 |
**Note**
[Si vous utilisez le AWS CLI, vous pouvez vérifier la validité des autorités de certification répertoriées ci-dessus en utilisant describe-certificates.](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html)
Ces certificats de CA sont inclus dans la solution groupée de certificats régionaux et mondiaux. Lorsque vous utilisez l'autorité de certification rds-ca-rsa 2048-g1, rds-ca-rsa 4096-g1 ou rds-ca-ecc 384-g1 avec une base de données, RDS gère le certificat du serveur de base de données sur la base de données. RDS effectue automatiquement la rotation du certificat de serveur de base de données avant son expiration.
### Configuration de l’autorité de certification pour votre base de données
Vous pouvez définir l’autorité de certification pour une base de données lorsque vous effectuez les tâches suivantes :
+ Créer un cluster de base de données Aurora — Vous pouvez définir l'autorité de certification pour une instance de base de données dans un cluster Aurora lorsque vous créez la première instance de base de données dans le cluster de base de données à l'aide de l'API AWS CLI ou RDS. Actuellement, vous ne pouvez pas configurer l’autorité de certification des instances de base de données dans un cluster de bases de données lorsque vous créez le cluster de bases de données à l’aide de la console RDS. Pour obtenir des instructions, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md).
+ Modification d’une instance de base de données : vous pouvez définir l’autorité de certification d’une instance de base de données dans un cluster de bases de données en la modifiant. Pour obtenir des instructions, consultez [Modification d’une instance de base de données dans un cluster de bases de données](Aurora.Modifying.md#Aurora.Modifying.Instance) .
**Note**
L'autorité de certification par défaut est définie sur rds-ca-rsa 2048-g1. Vous pouvez remplacer l'autorité de certification par défaut pour votre Compte AWS compte à l'aide de la commande [modify-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html).
La disponibilité CAs dépend du moteur de base de données et de la version du moteur de base de données. Lorsque vous utilisez le AWS Management Console, vous pouvez choisir l'autorité de **certification à l'aide du paramètre Autorité** de certification, comme indiqué dans l'image suivante.
![\[Option d’autorité de certification\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority.png)
La console affiche uniquement ceux CAs qui sont disponibles pour le moteur de base de données et la version du moteur de base de données. Si vous utilisez le AWS CLI, vous pouvez définir l'autorité de certification pour une instance de base de données à l'aide de la [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)commande [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)or.
Si vous utilisez le AWS CLI, vous pouvez voir ce qui est disponible CAs pour votre compte en utilisant la commande [describe-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html). Cette commande indique également la date d’expiration de chaque autorité de certification dans `ValidTill`, dans la sortie. Vous pouvez trouver ceux CAs qui sont disponibles pour un moteur de base de données et une version de moteur de base de données spécifiques à l'aide de la [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)commande.
L'exemple suivant montre la version CAs disponible pour la version par défaut du moteur de base de données RDS pour PostgreSQL.
```
aws rds describe-db-engine-versions --default-only --engine postgres
```
Votre sortie est similaire à ce qui suit. Les options disponibles CAs sont répertoriées dans`SupportedCACertificateIdentifiers`. La sortie indique également si la version du moteur de base de données prend en charge la rotation du certificat sans redémarrage dans `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"
]
}
]
}
```
### Validité des certificats de serveur de base de données
La validité du certificat de serveur de base de données dépend du moteur de base de données et de la version du moteur de base de données. Si la version du moteur de base de données prend en charge la rotation du certificat sans redémarrage, la validité du certificat de serveur de base de données est de 1 an. Dans le cas contraire, la validité est de 3 ans.
Pour plus d’informations sur la rotation des certificats de serveur de base de données, consultez [Rotation automatique du certificat de serveur](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation).
### Visualisation de la CA pour votre instance de base de données
Vous pouvez consulter les détails concernant la CA d’une instance de base de données en affichant l’onglet **Connectivité et sécurité** de la console, comme illustré dans l’image suivante.
![\[Détails de l’autorité de certification\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority-details.png)
Si vous utilisez le AWS CLI, vous pouvez afficher les détails de l'autorité de certification pour une instance de base de données à l'aide de la [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)commande.
## Téléchargez des ensembles de certificats pour
Lorsque vous vous connectez à votre base de données via SSL ou TLS, l’instance de base de données nécessite un certificat de confiance d’Amazon RDS. Sélectionnez le lien approprié dans le tableau suivant pour télécharger l’offre correspondant à la Région AWS où vous hébergez votre base de données.
### Forfaits de certificats par Région AWS
Les ensembles de certificats pour toutes les régions Régions AWS et GovCloud (États-Unis) contiennent les certificats CA racine suivants :
+ `rds-ca-rsa2048-g1`
+ `rds-ca-rsa4096-g1`
+ `rds-ca-ecc384-g1`
Les certificats `rds-ca-ecc384-g1` et `rds-ca-rsa4096-g1` ne sont pas disponibles dans les régions suivantes :
+ Asie-Pacifique (Mumbai)
+ Asie-Pacifique (Melbourne)
+ Canada-Ouest (Calgary)
+ Europe (Zurich)
+ Europe (Espagne)
+ Israël (Tel Aviv)
Le magasin de confiance de votre application doit uniquement enregistrer le certificat CA racine. N'enregistrez pas les certificats CA intermédiaires dans votre magasin de confiance car cela pourrait entraîner des problèmes de connexion lorsque RDS fait automatiquement pivoter votre certificat de serveur de base de données.
**Note**
Le proxy et l'utilisation d'Amazon RDS Aurora Serverless v1 les certificats du AWS Certificate Manager (ACM). Si vous utilisez le proxy RDS, vous n’avez pas besoin de télécharger des certificats Amazon RDS ou de mettre à jour des applications utilisant des connexions de proxy RDS. Pour plus d’informations, consultez [Utilisation TLS/SSL avec RDS Proxy](rds-proxy.howitworks.md#rds-proxy-security.tls).
Si vous utilisez Aurora Serverless v1, le téléchargement des certificats Amazon RDS n’est pas nécessaire. Pour plus d’informations, consultez [Utilisation TLS/SSL avec Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls).
Pour télécharger un bundle de certificats pour un Région AWS, sélectionnez le lien correspondant à celui Région AWS qui héberge votre base de données dans le tableau suivant.
| **AWS Région** | **Solution groupée de certificats (PEM)** | **Ensemble de certificats (PKCS7)** |
| --- | --- | --- |
| N'importe quelle publicité Région 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) |
| USA Est (Virginie du Nord) | [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 (Ohio) | [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 (N. California) | [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 (Oregon) | [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) |
| Africa (Cape Town) | [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) |
| Asia Pacific (Hong Kong) | [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) |
| Asie-Pacifique (Hyderabad) | [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) |
| Asie-Pacifique (Jakarta) | [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) |
| Asie-Pacifique (Malaisie) | [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) |
| Asie-Pacifique (Melbourne) | [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) |
| Asia Pacific (Mumbai) | [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) |
| Asia Pacific (Osaka) | [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) |
| Asie-Pacifique (Thaïlande) | [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) |
| Asie-Pacifique (Tokyo) | [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) |
| Asia Pacific (Seoul) | [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) |
| Asia Pacific (Singapore) | [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) |
| Asia Pacific (Sydney) | [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) |
| Canada (Centre) | [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) |
| Canada-Ouest (Calgary) | [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) |
| Europe (Frankfurt) | [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) |
| Europe (Ireland) | [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) |
| Europe (London) | [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) |
| Europe (Milan) | [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) |
| Europe (Paris) | [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) |
| Europe (Espagne) | [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) |
| Europe (Stockholm) | [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) |
| Europe (Zurich) | [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) |
| Israël (Tel Aviv) | [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) |
| Mexique (Centre) | [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) |
| Middle East (Bahrain) | [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) |
| Moyen-Orient (EAU) | [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) |
| Amérique du Sud (São Paulo) | [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) |
| N'importe quel AWS GovCloud (US) Region s | [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 (USA Est) | [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-Ouest) | [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) |
### Affichage du contenu de votre certificat CA
Pour vérifier le contenu de votre offre groupée de certificats d’autorité de certification, utilisez la commande suivante :
```
keytool -printcert -v -file global-bundle.pem
```
# Rotation de votre SSL/TLS certificat
Les certificats de l’autorité de certification Amazon RDS rds-ca-2019 sont configurés pour expirer en août 2024. Si vous utilisez ou prévoyez d'utiliser le protocole SSL (Secure Sockets Layer) ou le protocole Transport Layer Security (TLS) avec vérification des certificats pour vous connecter à vos instances de base de données RDS , pensez à utiliser l'un des nouveaux certificats CA rds-ca-rsa 2048-g1, 4096-g1 ou 384-g1. rds-ca-rsa rds-ca-ecc Si vous ne l'utilisez pas actuellement SSL/TLS avec la vérification des certificats, vous avez peut-être encore un certificat CA expiré et vous devez le mettre à jour SSL/TLS avec un nouveau certificat CA si vous prévoyez d'utiliser la vérification des certificats pour vous connecter à vos bases de données RDS.
Amazon RDS fournit de nouveaux certificats CA dans le cadre des meilleures pratiques AWS de sécurité. Pour plus d'informations sur les nouveaux certificats et les AWS régions prises en charge, consultez[Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md).
Pour mettre à jour le certificat CA de votre base de données, appliquez les méthodes suivantes :
+ [Mise à jour de votre certificat CA en modifiant votre instance de base de données ](#UsingWithRDS.SSL-certificate-rotation-updating)
+ [Mise à jour de votre certificat CA en appliquant la maintenance](#UsingWithRDS.SSL-certificate-rotation-maintenance-update)
Avant de mettre à jour vos instances de base de données pour utiliser le nouveau certificat CA, veillez à mettre à jour vos clients ou applications connectés à vos bases de données RDS.
## Considérations relatives à la rotation des certificats
Tenez compte des situations suivantes avant de procéder à la rotation de votre certificat :
+ Le proxy et l'utilisation d'Amazon RDS Aurora Serverless v1 les certificats du AWS Certificate Manager (ACM). Si vous utilisez un proxy RDS, lorsque vous faites pivoter votre SSL/TLS certificat, vous n'avez pas besoin de mettre à jour les applications qui utilisent des connexions au proxy RDS. Pour plus d’informations, consultez [Utilisation TLS/SSL avec RDS Proxy](rds-proxy.howitworks.md#rds-proxy-security.tls).
+ Si vous utilisez Aurora Serverless v1, le téléchargement des certificats Amazon RDS n’est pas nécessaire. Pour plus d’informations, consultez [Utilisation TLS/SSL avec Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls).
+ Si vous utilisez une application Go version 1.15 avec une instance de base de données créé(e) ou mis(e) à jour vers le certificat rds-ca-2019 avant le 28 juillet 2020, vous devez mettre à jour à nouveau le certificat.
Utilisez la commande `modify-db-instance` , en utilisant le nouvel identifiant de certificat CA. Vous pouvez trouver ceux CAs qui sont disponibles pour un moteur de base de données et une version de moteur de base de données spécifiques à l'aide de la `describe-db-engine-versions` commande.
Si vous avez créé votre base de données ou mis à jour son certificat après le 28 juillet 2020, aucune action n’est requise. Pour plus d'informations, consultez [Go GitHub issue \$139568](https://github.com/golang/go/issues/39568).
## Mise à jour de votre certificat CA en modifiant votre instance de base de données
*L'exemple suivant met à jour votre certificat CA de *rds-ca-2019* à 2048-g1. rds-ca-rsa* Vous pouvez choisir un autre certificat. Pour plus d'informations, consultez[Autorités de certification](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities).
Mettez à jour le magasin de confiance de votre application afin de réduire la durée d’indisponibilité associés à la mise à jour de votre certificat CA. Pour plus d’informations sur la rotation des certificats CA, consultez [Rotation automatique du certificat de serveur](#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation).
**Pour mettre à jour votre certificat CA en modifiant votre instance de base de données**
1. Téléchargez le nouveau SSL/TLS certificat comme décrit dans[Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md).
1. Mettez à jour vos applications de sorte à utiliser le nouveau certificat SSL/TLS.
Les méthodes de mise à jour des applications pour SSL/TLS les nouveaux certificats dépendent de vos applications spécifiques. Collaborez avec les développeurs de vos applications pour mettre à jour les SSL/TLS certificats de vos applications.
Pour plus d'informations sur la vérification des SSL/TLS connexions et la mise à jour des applications pour chaque moteur de base de données, consultez les rubriques suivantes :
+ [Mise à jour des applications pour se connecter aux clusters de bases de données Aurora MySQL à l'aide des nouveaux certificats TLS](ssl-certificate-rotation-aurora-mysql.md)
+ [Mise à jour des applications pour se connecter aux clusters de bases de données Aurora PostgreSQL à l’aide des nouveaux certificats SSL/TLS](ssl-certificate-rotation-aurora-postgresql.md)
Pour obtenir un exemple de script qui met à jour le magasin d’approbations d’un système d’exploitation Linux, consultez [Exemple de script pour importer les certificats dans votre magasin d’approbations](#UsingWithRDS.SSL-certificate-rotation-sample-script).
**Note**
L’ensemble de certificats contient des certificats pour le nouveau et l’ancien CA, ce qui signifie que vous pouvez mettre à niveau votre application en toute sécurité et conserver la connectivité pendant la période de transition. Si vous utilisez le AWS Database Migration Service pour migrer une base de données vers une de clusters, nous vous recommandons d'utiliser le bundle de certificats pour garantir la connectivité pendant la migration.
1. **Modifiez l'instance de base de données l'autorité de certification de **rds-ca-2019** à 2048-g1. rds-ca-rsa** Pour vérifier si votre base de données doit être redémarrée pour mettre à jour les certificats CA, utilisez la [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)commande et cochez l'`SupportsCertificateRotationWithoutRestart`indicateur.
**Note**
Redémarrez votre cluster Babelfish après l’avoir modifié pour mettre à jour le certificat CA.
**Important**
Si vous rencontrez des problèmes de connectivité après l’expiration du certificat, utilisez l’option **Appliquer immédiatement** en la spécifiant dans la console ou en spécifiant l’option `--apply-immediately` à l’aide d’ AWS CLI. Par défaut, il est prévu que cette opération soit exécutée pendant votre prochaine fenêtre de maintenance.
Pour définir un remplacement pour votre CA de cluster différent de la CA RDS par défaut, utilisez la commande d’interface de ligne de commande [modify-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html).
------
#### [ Console ]
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Bases de données**, puis l’instance de base de données que vous souhaitez modifier.
1. Sélectionnez **Modifier**.
![\[Modification d’une instance de base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-modify-aurora.png)
1. Dans la section **Connectivité**, choisissez **rds-ca-rsa2048-g1**.
![\[Choisissez un certificat CA\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-ca-rsa2048-g1.png)
1. Choisissez **Continuer** et vérifiez le récapitulatif des modifications.
1. Pour appliquer les modifications immédiatement, choisissez **Appliquer immédiatement**.
1. Sur la page de confirmation, examinez vos modifications. Si elles sont correctes, choisissez **Modifier l’instance de base de données** pour enregistrer vos modifications.
**Important**
Lorsque vous planifiez cette opération, assurez-vous d’avoir mis à jour votre magasin d’approbation côté client au préalable.
Ou choisissez **Retour** pour revoir vos modifications, ou choisissez **Annuler** pour les annuler.
------
#### [ AWS CLI ]
Pour utiliser le pour AWS CLI faire passer l'autorité de certification de **rds-ca-2019** à **rds-ca-rsa2048-g1** pour une instance de base de données ou un cluster de base de données . [modify-db-instance[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) Spécifiez l’identifiant de l’instance de base de données et l’option `--ca-certificate-identifier`.
Pour appliquer la mise à jour immédiatement, utilisez le paramètre `--apply-immediately`. Par défaut, il est prévu que cette opération soit exécutée pendant votre prochaine fenêtre de maintenance.
**Important**
Lorsque vous planifiez cette opération, assurez-vous d’avoir mis à jour votre magasin d’approbation côté client au préalable.
**Example**
L’exemple suivant modifie `mydbinstance` en définissant le certificat CA sur `rds-ca-rsa2048-g1`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-instance \
--db-instance-identifier mydbinstance \
--ca-certificate-identifier rds-ca-rsa2048-g1
```
Pour Windows :
```
aws rds modify-db-instance ^
--db-instance-identifier mydbinstance ^
--ca-certificate-identifier rds-ca-rsa2048-g1
```
Si votre instance nécessite un redémarrage, vous pouvez utiliser la commande [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI et spécifier l'`--no-certificate-rotation-restart`option.
------
## Mise à jour de votre certificat CA en appliquant la maintenance
Procédez comme suit pour mettre à jour votre certificat CA en appliquant la maintenance d’instance de base de données.
------
#### [ Console ]
**Pour mettre à jour de votre certificat CA en appliquant la maintenance**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le panneau de navigation, choisissez **Mise à jour du certificat**.
![\[Option du panneau de navigation de rotation des certificats\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-certupdate.png)
La page **Bases de données nécessitant une mise à jour de certificat** apparaît.
![\[Mise à jour du certificat CA pour base de données\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-update-multiple.png)
**Note**
Cette page affiche uniquement les instances de base de données actuels Région AWS. Si vous avez des bases de données dans plusieurs d'entre elles Région AWS, consultez cette page Région AWS pour voir toutes les instances de base de données dotées d'anciens SSL/TLS certificats.
1. Choisissez l’instance de base de données que vous voulez mettre à jour.
Vous pouvez planifier la rotation du certificat pour votre prochaine fenêtre de maintenance en choisissant **Planification**. Appliquez la rotation immédiatement en choisissant **Appliquer maintenant**.
**Important**
Si vous rencontrez des problèmes de connectivité après l’expiration du certificat, utilisez l’option **Appliquer maintenant**.
1.
1. Si vous choisissez **Planification**, vous êtes invité à confirmer la rotation du certificat CA. Cette invite indique également la fenêtre planifiée pour votre mise à jour.
![\[Confirmation de la rotation du certificat\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-confirm-schedule.png)
1. Si vous choisissez **Appliquer maintenant**, vous êtes invité à confirmer la rotation du certificat CA.
![\[Confirmation de la rotation du certificat\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-confirm-now.png)
**Important**
Avant de planifier la rotation des certificats CA dans votre base de données, mettez à jour toutes les applications clientes qui les utilisent SSL/TLS et le certificat du serveur pour se connecter. Ces mises à jour sont spécifiques à votre moteur de base de données. Après avoir mis à jour ces applications clientes, vous pouvez confirmer la rotation du certificat CA.
Pour continuer, cochez la case, puis cliquez sur **Confirmation**.
1. Répétez les étapes 3 et 4 pour chaque instance de base de données que vous souhaitez mettre à jour.
------
## Rotation automatique du certificat de serveur
Si votre CA racine prend en charge la rotation automatique du certificat de serveur, RDS gère automatiquement la rotation du certificat de serveur de base de données. RDS utilise la même autorité de certification racine pour cette rotation automatique. Vous n’avez donc pas besoin de télécharger une nouvelle offre groupée d’autorités de certification. Consultez [Autorités de certification](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities).
La rotation et la validité de votre certificat de serveur de base de données dépendent de votre moteur de base de données :
+ Si votre moteur de base de données prend en charge la rotation sans redémarrage, RDS effectue automatiquement la rotation du certificat de serveur de base de données sans que vous ayez à intervenir. RDS tente d’effectuer la rotation de votre certificat de serveur de base de données pendant la fenêtre de maintenance de votre choix, à la moitié de la durée de vie du certificat de serveur de base de données. Le nouveau certificat de serveur de base de données est valide pendant 12 mois.
+ Si votre moteur de base de données ne prend pas en charge la rotation sans redémarrage, Amazon RDS `server-certificate-rotation` affiche une action de maintenance en attente via l' Describe-pending-maintenance-actionsAPI, à la demi-vie du certificat ou au moins 3 mois avant son expiration. Vous pouvez appliquer la rotation à l'aide de l' apply-pending-maintenance-actionAPI. Le nouveau certificat de serveur de base de données est valide pendant 36 mois.
Utilisez la [ describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html)commande et inspectez l'`SupportsCertificateRotationWithoutRestart`indicateur pour déterminer si la version du moteur de base de données prend en charge la rotation du certificat sans redémarrage. Pour plus d’informations, consultez [Configuration de l’autorité de certification pour votre base de données](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities.Selection).
## Exemple de script pour importer les certificats dans votre magasin d’approbations
Voici des exemples de scripts shell qui importent le lot de certificats dans un magasin d’approbations.
Chaque exemple de script shell utilise keytool, qui fait partie du kit de développement Java (JDK). Pour plus d’informations sur l’installation du JDK, consultez le [Guide d’installation du JDK](https://docs.oracle.com/en/java/javase/17/install/overview-jdk-installation.html).
------
#### [ Linux ]
Voici un exemple de scripting shell qui importe le lot de certificats vers un magasin d’approbations sur un système d’exploitation 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 ]
Voici un exemple de scripting shell qui importe le lot de certificats vers un magasin d’approbations sur 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
```
------
Pour en savoir plus sur les bonnes pratiques relatives à l’utilisation du protocole SSL avec Amazon RDS, consultez [Bonnes pratiques pour des connexions SSL réussies à Amazon RDS for Oracle](https://aws.amazon.com/blogs/database/best-practices-for-successful-ssl-connections-to-amazon-rds-for-oracle/).
# Confidentialité du trafic inter-réseau
Les connexions sont protégées à la fois entre , Amazon Aurora et les applications sur site, et entre Amazon et d'autres AWS ressources au sein de la même région. AWS
## Trafic entre les clients de service et sur site et les applications
Vous avez deux options de connectivité entre votre réseau privé et AWS :
+ Une connexion AWS Site-to-Site VPN. Pour plus d’informations, consultez [Qu’est-ce qu’ AWS Site-to-Site VPN ?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ Une Direct Connect connexion. Pour plus d'informations, voir [Qu'est-ce que c'est Direct Connect ?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
Vous accédez à Amazon Aurora via le réseau en utilisant des opérations d’API publiées par AWS. Les clients doivent prendre en charge les éléments suivants :
+ Protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Ses suites de chiffrement PFS (Perfect Forward Secrecy) comme DHE (Ephemeral Diffie-Hellman) ou ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.
En outre, les demandes doivent être signées à l’aide d’un ID de clé d’accès et d’une clé d’accès secrète associée à un principal IAM. Vous pouvez également utiliser [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) pour générer des informations d’identification de sécurité temporaires et signer les demandes.
# Identity and Access Management pour Amazon Aurora
Gestion des identités et des accès AWS (IAM) est un outil Service AWS qui permet à un administrateur de contrôler en toute sécurité l'accès aux AWS ressources. Des administrateurs IAM contrôlent les personnes qui peuvent être *authentifiées* (connectées) et *autorisées* (disposant d’autorisations) à utiliser des ressources Amazon RDS. IAM est un Service AWS outil que vous pouvez utiliser sans frais supplémentaires.
**Topics**
+ [Public ciblé](#security_iam_audience)
+ [Authentification par des identités](#security_iam_authentication)
+ [Gestion de l’accès à l’aide de politiques](#security_iam_access-manage)
+ [Comment Amazon Aurora fonctionne avec IAM](security_iam_service-with-iam.md)
+ [Exemples de politiques basées sur l’identité pour Amazon Aurora](security_iam_id-based-policy-examples.md)
+ [AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md)
+ [Mises à jour Amazon RDS des politiques gérées par AWS](rds-manpol-updates.md)
+ [Prévention des problèmes d'adjoint confus entre services](cross-service-confused-deputy-prevention.md)
+ [Authentification de base de données IAM](UsingWithRDS.IAMDBAuth.md)
+ [Résolution des problèmes liés à Identity and Access Amazon Aurora](security_iam_troubleshoot.md)
## Public ciblé
La façon dont vous utilisez Gestion des identités et des accès AWS (IAM) varie en fonction du travail que vous effectuez dans ).
**Utilisateur du service** – Si vous utilisez le service Aurora pour effectuer votre tâche, votre administrateur vous fournit les informations d’identification et les autorisations dont vous avez besoin. Plus vous utiliserez de fonctionnalités Aurora pour effectuer votre travail, plus vous pourrez avoir besoin d’autorisations supplémentaires. Comprendre la gestion des accès peut vous aider à demander à votre administrateur les autorisations appropriées. Si vous ne pouvez pas accéder à une fonctionnalité dans Aurora, consultez [Résolution des problèmes liés à Identity and Access Amazon Aurora](security_iam_troubleshoot.md).
**Administrateur du service** – Si vous êtes le responsable des ressources Aurora de votre entreprise, vous bénéficiez probablement d’un accès total à Aurora. C’est à vous de déterminer les fonctionnalités et les ressources Aurora auxquelles vos employés pourront accéder. Vous devez ensuite soumettre les demandes à votre administrateur pour modifier les autorisations des utilisateurs de votre service. Consultez les informations sur cette page pour comprendre les concepts de base d’IAM. Pour en savoir plus sur la façon dont votre entreprise peut utiliser IAM avec Aurora, consultez [Comment Amazon Aurora fonctionne avec IAM](security_iam_service-with-iam.md).
**Administrateur** : si vous êtes un administrateur, vous souhaiterez peut-être obtenir des détails sur la façon dont vous pouvez écrire des politiques pour gérer l’accès à Aurora. Pour obtenir des exemples de stratégies Aurora basées sur l’identité que vous pouvez utiliser dans IAM, consultez [Exemples de politiques basées sur l’identité pour Amazon Aurora](security_iam_id-based-policy-examples.md).
## Authentification par des identités
L'authentification est la façon dont vous vous connectez à AWS l'aide de vos informations d'identification. Vous devez être authentifié en tant qu'utilisateur IAM ou en assumant un rôle IAM. Utilisateur racine d'un compte AWS
Vous pouvez vous connecter en tant qu'identité fédérée à l'aide d'informations d'identification provenant d'une source d'identité telle que AWS IAM Identity Center (IAM Identity Center), d'une authentification unique ou d'informations d'identification. Google/Facebook Pour plus d’informations sur la connexion, consultez [Connexion à votre Compte AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) dans le *Guide de l’utilisateur Connexion à AWS *.
Pour l'accès par programmation, AWS fournit un SDK et une CLI pour signer les demandes de manière cryptographique. Pour plus d’informations, consultez [Signature AWS Version 4 pour les demandes d’API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) dans le *Guide de l’utilisateur IAM*.
### AWS utilisateur root du compte
Lorsque vous créez un Compte AWS, vous commencez par une seule identité de connexion appelée *utilisateur Compte AWS root* qui dispose d'un accès complet à toutes Services AWS les ressources. Il est vivement déconseillé d’utiliser l’utilisateur racine pour vos tâches quotidiennes. Pour les tâches qui requièrent des informations d’identification de l’utilisateur racine, consultez [Tâches qui requièrent les informations d’identification de l’utilisateur racine](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) dans le *Guide de l’utilisateur IAM*.
### Identité fédérée
Il est recommandé d'obliger les utilisateurs humains à utiliser la fédération avec un fournisseur d'identité pour accéder à Services AWS l'aide d'informations d'identification temporaires.
Une *identité fédérée* est un utilisateur provenant de l'annuaire de votre entreprise, de votre fournisseur d'identité Web ou Directory Service qui y accède à Services AWS l'aide d'informations d'identification provenant d'une source d'identité. Les identités fédérées assument des rôles qui fournissent des informations d’identification temporaires.
Pour une gestion des accès centralisée, nous vous recommandons d’utiliser AWS IAM Identity Center. Pour plus d’informations, consultez [Qu’est-ce que IAM Identity Center ?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
### Utilisateurs et groupes IAM
Un *[utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* est une identité qui dispose d’autorisations spécifiques pour une seule personne ou application. Nous vous recommandons d’utiliser ces informations d’identification temporaires au lieu des utilisateurs IAM avec des informations d’identification à long terme. Pour plus d'informations, voir [Exiger des utilisateurs humains qu'ils utilisent la fédération avec un fournisseur d'identité pour accéder à AWS l'aide d'informations d'identification temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) dans le *guide de l'utilisateur IAM*.
[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) spécifient une collection d’utilisateurs IAM et permettent de gérer plus facilement les autorisations pour de grands ensembles d’utilisateurs. Pour plus d’informations, consultez la section [Cas d’utilisation pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) dans le *Guide de l’utilisateur IAM*.
Vous pouvez vous authentifier auprès de votre cluster de bases de données à l’aide de l’authentification de base de données IAM.
L’authentification de base de données IAM fonctionne avec Aurora.Pour plus d’informations sur l’authentification auprès de votre cluster de bases de données avec IAM, consultez [Authentification de base de données IAM](UsingWithRDS.IAMDBAuth.md).
### Rôles IAM
Un *[rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité au sein de vous Compte AWS dotée d'autorisations spécifiques. Le concept ressemble à celui d’un utilisateur, mais un rôle n’est pas associé à une personne en particulier. Vous pouvez assumer temporairement un rôle IAM dans le en AWS Management Console [changeant de rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). Vous pouvez assumer un rôle en appelant une opération d' AWS API AWS CLI ou en utilisant une URL personnalisée. Pour plus d’informations sur les méthodes d’utilisation des rôles, consultez [Utilisation de rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) dans le *Guide de l’utilisateur IAM*.
Les rôles IAM avec des informations d’identification temporaires sont utiles dans les cas suivants :
+ **Autorisations utilisateur temporaires** : un utilisateur peut endosser un rôle IAM pour accepter différentes autorisations temporaires concernant une tâche spécifique.
+ **Accès utilisateur fédéré** : pour attribuer des autorisations à une identité fédérée, vous créez un rôle et définissez des autorisations pour le rôle. Quand une identité externe s’authentifie, l’identité est associée au rôle et reçoit les autorisations qui sont définies par celui-ci. Pour obtenir des informations sur les rôles pour la fédération, consultez [ Création d’un rôle pour un fournisseur d’identité tiers (fédération)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) dans le *Guide de l’utilisateur IAM*. Si vous utilisez IAM Identity Center, vous configurez un jeu d’autorisations. IAM Identity Center met en corrélation le jeu d’autorisations avec un rôle dans IAM afin de contrôler à quoi vos identités peuvent accéder après leur authentification. Pour plus d’informations sur les jeux d’autorisations, consultez [Jeux d’autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *.
+ **Accès intercompte** : vous pouvez utiliser un rôle IAM pour permettre à un utilisateur (principal de confiance) d’un compte différent d’accéder aux ressources de votre compte. Les rôles constituent le principal moyen d’accorder l’accès intercompte. Toutefois, dans certains Services AWS cas, vous pouvez associer une politique directement à une ressource (au lieu d'utiliser un rôle comme proxy). Pour en savoir plus sur la différence entre les rôles et les politiques basées sur les ressources pour l’accès intercompte, consultez [Différence entre les rôles IAM et les politiques basées sur les ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Accès multiservices** — Certains Services AWS utilisent des fonctionnalités dans d'autres Services AWS. Par exemple, lorsque vous effectuez un appel dans un service, il est courant que ce service exécute des applications dans Amazon EC2 ou stocke des objets dans Amazon S3. Un service peut le faire en utilisant les autorisations d’appel du principal, un rôle de service ou un rôle lié au service.
+ **Sessions d'accès** par transfert : les sessions d'accès par transfert (FAS) utilisent les autorisations du principal appelant et Service AWS, associées à la demande, Service AWS pour adresser des demandes aux services en aval. Pour plus de détails sur une politique lors de la formulation de demandes FAS, consultez [Transmission des sessions d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
+ **Rôle de service** : il s’agit d’un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) attribué à un service afin de réaliser des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*.
+ **Rôle lié à un service — Un rôle** lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés à un service apparaissent dans votre Compte AWS fichier et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
+ **Applications exécutées sur Amazon EC2** : vous pouvez utiliser un rôle IAM pour gérer les informations d'identification temporaires pour les applications qui s'exécutent sur une EC2 instance et qui envoient des demandes AWS CLI d' AWS API. Cela est préférable au stockage des clés d'accès dans l' EC2 instance. Pour attribuer un AWS rôle à une EC2 instance et le rendre disponible pour toutes ses applications, vous devez créer un profil d'instance attaché à l'instance. Un profil d'instance contient le rôle et permet aux programmes exécutés sur l' EC2 instance d'obtenir des informations d'identification temporaires. Pour plus d'informations, consultez [Utiliser un rôle IAM pour accorder des autorisations aux applications exécutées sur des EC2 instances Amazon](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) dans le guide de l'*utilisateur IAM*.
Pour savoir si vous devez utiliser ces rôles IAM ou non, consultez [Quand créer un rôle IAM (au lieu d’un utilisateur)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) dans le *Guide de l’utilisateur IAM*.
## Gestion de l’accès à l’aide de politiques
Vous contrôlez l'accès en AWS créant des politiques et en les associant aux identités ou aux AWS ressources IAM. Une politique est un objet AWS qui, lorsqu'il est associé à une identité ou à une ressource, définit leurs autorisations. AWS évalue ces politiques lorsqu'une entité (utilisateur root, utilisateur ou rôle IAM) fait une demande. Les autorisations dans les politiques déterminent si la demande est autorisée ou refusée. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations sur la structure et le contenu des documents de politique JSON, consultez [Vue d’ensemble des politiques JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) dans le *Guide de l’utilisateur IAM*.
Un administrateur peut utiliser des politiques pour spécifier qui a accès aux AWS ressources et quelles actions il peut effectuer sur ces ressources. Chaque entité IAM (jeu d’autorisations ou rôle) démarre sans autorisation. En d’autres termes, par défaut, les utilisateurs ne peuvent rien faire, pas même changer leurs propres mots de passe. Pour autoriser un utilisateur à effectuer une opération, un administrateur doit associer une politique d’autorisations à ce dernier. Il peut également ajouter l’utilisateur à un groupe disposant des autorisations prévues. Lorsqu’un administrateur accorde des autorisations à un groupe, tous les utilisateurs de ce groupe se voient octroyer ces autorisations.
Les politiques IAM définissent les autorisations d’une action, quelle que soit la méthode que vous utilisez pour exécuter l’opération. Par exemple, supposons que vous disposiez d’une politique qui autorise l’action `iam:GetRole`. Un utilisateur appliquant cette politique peut obtenir des informations sur le rôle à partir de AWS Management Console AWS CLI, de ou de l' AWS API.
### Politiques basées sur l’identité
Les politiques basées sur l’identité sont des documents de politiques d’autorisations JSON que vous pouvez attacher à une identité telle qu’un jeu d’autorisations ou un rôle. Ces politiques contrôlent les actions que peut exécuter cette identité, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Création de politiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Les politiques basées sur l’identité peuvent être classées comme des *politiques en ligne* ou des *politiques gérées*. Les politiques en ligne sont intégrées directement à un seul jeu d’autorisations ou rôle. Les politiques gérées sont des politiques autonomes que vous pouvez associer à plusieurs ensembles d'autorisations et rôles dans votre AWS compte. Les politiques gérées incluent les politiques AWS gérées et les politiques gérées par le client. Pour découvrir comment choisir entre une politique gérée et une politique en ligne, consultez [Choix entre les politiques gérées et les politiques en ligne](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) dans le *Guide de l’utilisateur IAM*.
Pour plus d'informations sur les politiques AWS gérées spécifiques à (Amazon Aurora), consultez[AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md).
### Autres types de politique
AWS prend en charge d'autres types de politiques moins courants. Ces types de politiques peuvent définir le nombre maximum d’autorisations qui vous sont accordées par des types de politiques plus courants.
+ **Limites des autorisations** : une limite des autorisations est une fonction avancée dans laquelle vous définissez le nombre maximal d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM (jeu d’autorisations ou rôle). Vous pouvez définir une limite d’autorisations pour une entité. Les autorisations obtenues représentent la combinaison des politiques basées sur l’identité de l’entité et de ses limites d’autorisations. Les politiques basées sur les ressources qui spécifient le jeu d’autorisations ou le rôle dans le champ `Principal` ne sont pas limitées par les limites des autorisations. Un refus explicite dans l’une de ces politiques annule l’autorisation. Pour plus d’informations sur les limites d’autorisations, consultez [Limites d’autorisations pour des entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) dans le *Guide de l’utilisateur IAM*.
+ **Politiques de contrôle des services (SCPs)** : SCPs politiques JSON qui spécifient les autorisations maximales pour une organisation ou une unité organisationnelle (UO) dans AWS Organizations. AWS Organizations est un service permettant de regrouper et de gérer de manière centralisée plusieurs AWS comptes détenus par votre entreprise. Si vous activez toutes les fonctionnalités d'une organisation, vous pouvez appliquer des politiques de contrôle des services (SCPs) à l'un ou à l'ensemble de vos comptes. Le SCP limite les autorisations pour les entités figurant dans les comptes des membres, y compris chacune Utilisateur racine d'un compte AWS d'entre elles. Pour plus d'informations sur les Organizations SCPs, voir [Comment SCPs travailler](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html) dans le *Guide de AWS Organizations l'utilisateur*.
+ **Politiques de session** : les politiques de session sont des politiques avancées que vous utilisez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Les autorisations de la session obtenues sont une combinaison des politiques basées sur l’identité du rôle ou des jeux d’autorisations et des politiques de session. Les autorisations peuvent également provenir d’une politique basée sur les ressources. Un refus explicite dans l’une de ces politiques annule l’autorisation. Pour plus d’informations, consultez [Politiques de session](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) dans le *Guide de l’utilisateur IAM*.
### Plusieurs types de politique
Lorsque plusieurs types de politiques s’appliquent à la requête, les autorisations en résultant sont plus compliquées à comprendre. Pour savoir comment AWS déterminer s'il faut autoriser une demande lorsque plusieurs types de politiques sont impliqués, consultez la section [Logique d'évaluation des politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) dans le *guide de l'utilisateur IAM*.
# Comment Amazon Aurora fonctionne avec IAM
Avant d’utiliser IAM pour gérer l’accès à Amazon Aurora, vous devez comprendre quelles sont les fonctions IAM disponibles à utiliser avec Aurora.
Le tableau suivant répertorie les fonctionnalités IAM que vous pouvez utiliser avec Amazon Aurora :
| Fonctionnalité IAM | Prise en charge d’Amazon Aurora |
| --- | --- |
| [Politiques basées sur l’identité](#security_iam_service-with-iam-id-based-policies) | Oui |
| [Politiques basées sur les ressources](#security_iam_service-with-iam-resource-based-policies) | Non |
| [Actions de politique](#security_iam_service-with-iam-id-based-policies-actions) | Oui |
| [Ressources de politique](#security_iam_service-with-iam-id-based-policies-resources) | Oui |
| [Clés de condition de politique (spécifiques au service)](#UsingWithRDS.IAM.Conditions) | Oui |
| [ACLs](#security_iam_service-with-iam-acls) | Non |
| [Contrôle d’accès par attributs (ABAC) (balises dans les politiques)](#security_iam_service-with-iam-tags) | Oui |
| [Informations d’identification temporaires](#security_iam_service-with-iam-roles-tempcreds) | Oui |
| [Transfert des sessions d’accès](#security_iam_service-with-iam-principal-permissions) | Oui |
| [Rôles de service](#security_iam_service-with-iam-roles-service) | Oui |
| [Rôles liés à un service](#security_iam_service-with-iam-roles-service-linked) | Oui |
Pour obtenir une vue d'ensemble de la manière dont , Amazon Aurora et d'autres AWS services fonctionnent avec IAM, consultez la section sur les [AWS services compatibles avec IAM dans le guide de l'utilisateur d'*IAM*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).
**Topics**
+ [Stratégies basées sur l’identité Aurora](#security_iam_service-with-iam-id-based-policies)
+ [Politiques basées sur les ressources au sein d’Aurora](#security_iam_service-with-iam-resource-based-policies)
+ [Actions de politique pour Aurora](#security_iam_service-with-iam-id-based-policies-actions)
+ [Ressources de politique pour Aurora](#security_iam_service-with-iam-id-based-policies-resources)
+ [Clés de condition de politique pour Aurora](#UsingWithRDS.IAM.Conditions)
+ [Listes de contrôle d'accès (ACLs) dans](#security_iam_service-with-iam-acls)
+ [Contrôle d’accès par attributs (ABAC) dans les politiques avec des balises Aurora](#security_iam_service-with-iam-tags)
+ [Utilisation des informations d’identification temporaires avec Aurora](#security_iam_service-with-iam-roles-tempcreds)
+ [Transfert des sessions d’accès pour Aurora](#security_iam_service-with-iam-principal-permissions)
+ [Rôles de service pour Aurora](#security_iam_service-with-iam-roles-service)
+ [Rôles liés à un service pour Aurora](#security_iam_service-with-iam-roles-service-linked)
## Stratégies basées sur l’identité Aurora
**Prend en charge les politiques basées sur l’identité :** oui.
Les politiques basées sur l’identité sont des documents de politique d’autorisations JSON que vous pouvez attacher à une identité telle qu’un utilisateur, un groupe d’utilisateurs ou un rôle IAM. Ces politiques contrôlent quel type d’actions des utilisateurs et des rôles peuvent exécuter, sur quelles ressources et dans quelles conditions. Pour découvrir comment créer une politique basée sur l’identité, consultez [Définition d’autorisations IAM personnalisées avec des politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) dans le *Guide de l’utilisateur IAM*.
Avec les politiques IAM basées sur l’identité, vous pouvez spécifier des actions et ressources autorisées ou refusées, ainsi que les conditions dans lesquelles les actions sont autorisées ou refusées. Pour découvrir tous les éléments que vous utilisez dans une politique JSON, consultez [Références des éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dans le *Guide de l’utilisateur IAM*.
### Exemples de politiques basées sur l’identité pour Aurora
Pour voir des exemples de stratégies Aurora basées sur l’identité, consultez [Exemples de politiques basées sur l’identité pour Amazon Aurora](security_iam_id-based-policy-examples.md).
## Politiques basées sur les ressources au sein d’Aurora
**Prend en charge les politiques basées sur les ressources :** non.
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Par exemple, les *politiques de confiance de rôle* IAM et les *politiques de compartiment* Amazon S3 sont des politiques basées sur les ressources. Dans les services qui sont compatibles avec les politiques basées sur les ressources, les administrateurs de service peuvent les utiliser pour contrôler l’accès à une ressource spécifique. Pour la ressource dans laquelle se trouve la politique, cette dernière définit quel type d’actions un principal spécifié peut effectuer sur cette ressource et dans quelles conditions. Vous devez [spécifier un principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) dans une politique basée sur les ressources. Les principaux peuvent inclure des comptes, des utilisateurs, des rôles, des utilisateurs fédérés ou. Services AWS
Pour permettre un accès intercompte, vous pouvez spécifier un compte entier ou des entités IAM dans un autre compte en tant que principal dans une politique basée sur les ressources. Pour plus d’informations, consultez [Accès intercompte aux ressources dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) dans le *Guide de l’utilisateur IAM*.
## Actions de politique pour Aurora
**Prend en charge les actions de politique :** oui.
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Action` d’une politique JSON décrit les actions que vous pouvez utiliser pour autoriser ou refuser l’accès à une politique. Intégration d’actions dans une politique afin d’accorder l’autorisation d’exécuter les opérations associées.
Les actions de stratégie dans Aurora utilisent le préfixe suivant avant l’action : `rds:`. Par exemple, pour accorder à une personne l’autorisation de décrire les instances de base de données à l’aide de l’opération d’API Amazon RDS`DescribeDBInstances` , vous incluez l’action `rds:DescribeDBInstances` dans sa stratégie. Les déclarations de politique doivent inclure un élément `Action` ou `NotAction`. Aurora définit son propre ensemble d’actions qui décrivent les tâches que vous pouvez effectuer avec ce service.
Pour spécifier plusieurs actions dans une seule instruction, séparez-les par des virgules, comme suit :
```
"Action": [
"rds:action1",
"rds:action2"
```
Vous pouvez aussi préciser plusieurs actions à l’aide de caractères génériques (\$1). Par exemple, pour spécifier toutes les actions qui commencent par le mot `Describe`, incluez l’action suivante.
```
"Action": "rds:Describe*"
```
Pour afficher la liste des actions Aurora, consultez [Actions définies par Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) dans *Référence de l’autorisation de service*.
## Ressources de politique pour Aurora
**Prend en charge les ressources de politique :** oui.
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément de politique JSON `Resource` indique le ou les objets auxquels l’action s’applique. Il est recommandé de définir une ressource à l’aide de son [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Pour les actions qui ne sont pas compatibles avec les autorisations de niveau ressource, utilisez un caractère générique (\$1) afin d’indiquer que l’instruction s’applique à toutes les ressources.
```
"Resource": "*"
```
La ressource d’instance de base de données possède l’ARN (Amazon Resource Name) suivant.
```
arn:${Partition}:rds:${Region}:${Account}:{ResourceType}/${Resource}
```
Pour plus d'informations sur le format de ARNs, consultez [Amazon Resource Names (ARNs) et espaces de noms AWS de services](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Par exemple, pour spécifier l’instance de base de données `dbtest` dans votre instruction, utilisez l’ARN suivant.
```
"Resource": "arn:aws:rds:us-west-2:123456789012:db:dbtest"
```
Pour spécifier toutes les instances de base de données qui appartiennent à un compte spécifique, utilisez le caractère générique (\$1).
```
"Resource": "arn:aws:rds:us-east-1:123456789012:db:*"
```
Certaines opérations d’API RDS, telles que la création de ressources, ne peuvent pas être exécutées sur une ressource spécifique. Dans ces cas-là, utilisez le caractère générique (\$1).
```
"Resource": "*"
```
De nombreuses opérations d’API Amazon RDS nécessitent plusieurs ressources. Par exemple, `CreateDBInstance` crée une instance de base de données. Vous pouvez spécifier qu’un utilisateur doit utiliser un groupe de sécurité spécifique et un groupe de paramètres lors de la création d’une instance de base de données. Pour spécifier plusieurs ressources dans une seule instruction, séparez-les ARNs par des virgules.
```
"Resource": [
"resource1",
"resource2"
```
Pour consulter la liste des types de ressources Aurora et leurs caractéristiques ARNs, consultez la section [Ressources définies par Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-resources-for-iam-policies) dans le *Service Authorization Reference*. Pour savoir les actions avec lesquelles vous pouvez spécifier l’ARN de chaque ressource, consultez [Actions définies par Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions).
## Clés de condition de politique pour Aurora
**Prend en charge les clés de condition de politique spécifiques au service :** oui.
Les administrateurs peuvent utiliser les politiques AWS JSON pour spécifier qui a accès à quoi. C’est-à-dire, quel **principal** peut effectuer **des actions** sur quelles **ressources** et dans quelles **conditions**.
L’élément `Condition` indique à quel moment les instructions s’exécutent en fonction de critères définis. Vous pouvez créer des expressions conditionnelles qui utilisent des [opérateurs de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tels que les signes égal ou inférieur à, pour faire correspondre la condition de la politique aux valeurs de la demande. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Aurora définit son propre ensemble de clés de condition et prend également en charge l’utilisation des clés de condition globales. Pour voir toutes les clés de condition AWS globales, voir les clés de [contexte de condition AWS globales](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *guide de l'utilisateur IAM*.
Toutes les opérations d’API RDS prennent en charge la clé de condition `aws:RequestedRegion`.
Pour afficher la liste des clés de condition Aurora, consultez [Clés de condition pour Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-policy-keys) dans la *Référence de l’autorisation de service*. Pour savoir avec quelles actions et ressources vous pouvez utiliser une clé de condition, consultez [Actions définies par Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions).
## Listes de contrôle d'accès (ACLs) dans
**Supporte les listes de contrôle d'accès (ACLs) :** Non
Les listes de contrôle d'accès (ACLs) contrôlent les principaux (membres du compte, utilisateurs ou rôles) autorisés à accéder à une ressource. ACLs sont similaires aux politiques basées sur les ressources, bien qu'elles n'utilisent pas le format de document de politique JSON.
## Contrôle d’accès par attributs (ABAC) dans les politiques avec des balises Aurora
**Prend en charge les balises dans les politiques pour le contrôle d’accès par attributs (ABAC) :** oui
Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit les autorisations en fonction des attributs appelés balises. Vous pouvez associer des balises aux entités et aux AWS ressources IAM, puis concevoir des politiques ABAC pour autoriser les opérations lorsque la balise du principal correspond à la balise de la ressource.
Pour contrôler l’accès basé sur des étiquettes, vous devez fournir les informations d’étiquette dans l’[élément de condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) d’une politique utilisant les clés de condition `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou `aws:TagKeys`.
Si un service prend en charge les trois clés de condition pour tous les types de ressources, alors la valeur pour ce service est **Oui**. Si un service prend en charge les trois clés de condition pour certains types de ressources uniquement, la valeur est **Partielle**.
Pour plus d’informations sur ABAC, consultez [Définition d’autorisations avec l’autorisation ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*. Pour accéder à un didacticiel décrivant les étapes de configuration de l’ABAC, consultez [Utilisation du contrôle d’accès par attributs (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) dans le *Guide de l’utilisateur IAM*.
Pour plus d’informations sur le balisage des ressources Aurora, consultez [Spécification de conditions : Utilisation de balises personnalisées](UsingWithRDS.IAM.SpecifyingCustomTags.md). Pour visualiser un exemple de politique basée sur l’identité permettant de limiter l’accès à une ressource en fonction des balises de cette ressource, consultez [Accorder une autorisation pour des actions sur une ressource à l’aide d’une balise spécifique avec deux valeurs différentes](security_iam_id-based-policy-examples-create-and-modify-examples.md#security_iam_id-based-policy-examples-grant-permissions-tags).
## Utilisation des informations d’identification temporaires avec Aurora
**Prend en charge les informations d’identification temporaires :** oui.
Les informations d'identification temporaires fournissent un accès à court terme aux AWS ressources et sont automatiquement créées lorsque vous utilisez la fédération ou que vous changez de rôle. AWS recommande de générer dynamiquement des informations d'identification temporaires au lieu d'utiliser des clés d'accès à long terme. Pour plus d’informations, consultez [Informations d’identification de sécurité temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) et [Services AWS compatibles avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) dans le *Guide de l’utilisateur IAM*.
## Transfert des sessions d’accès pour Aurora
**Prend en charge le transfert des sessions d’accès :** oui.
Les sessions d'accès direct (FAS) utilisent les autorisations du principal appelant et Service AWS, combinées Service AWS à la demande d'envoi de demandes aux services en aval. Pour plus de détails sur une politique lors de la formulation de demandes FAS, consultez [Transfert des sessions d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Rôles de service pour Aurora
**Prend en charge les rôles de service :** oui.
Un rôle de service est un [rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) qu’un service endosse pour accomplir des actions en votre nom. Un administrateur IAM peut créer, modifier et supprimer un rôle de service à partir d’IAM. Pour plus d’informations, consultez [Création d’un rôle pour la délégation d’autorisations à un Service AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) dans le *Guide de l’utilisateur IAM*.
**Avertissement**
La modification des autorisations d’un rôle de service peut altérer la fonctionnalité d’Aurora. Ne modifiez des rôles de service que quand Aurora vous le conseille.
## Rôles liés à un service pour Aurora
**Prend en charge les rôles liés à un service :** oui.
Un rôle lié à un service est un type de rôle de service lié à un. Service AWS Le service peut endosser le rôle afin d’effectuer une action en votre nom. Les rôles liés au service apparaissent dans votre Compte AWS fichier et appartiennent au service. Un administrateur IAM peut consulter, mais ne peut pas modifier, les autorisations concernant les rôles liés à un service.
Pour plus d’informations l’utilisation des rôles liés à un service Aurora, consultez [Utilisation des rôles liés à un service pour Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md).
# Exemples de politiques basées sur l’identité pour Amazon Aurora
Par défaut, les jeux d’autorisations et les rôles ne sont pas autorisés à créer ou modifier des ressources Aurora. 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, consultez [Création de politiques dans l’onglet JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) dans le *Guide de l’utilisateur IAM*.
**Topics**
+ [Bonnes pratiques en matière de politiques](#security_iam_service-with-iam-policy-best-practices)
+ [Utilisation de la console Aurora](#security_iam_id-based-policy-examples-console)
+ [Autorisations requises pour utiliser la console](#UsingWithRDS.IAM.RequiredPermissions.Console)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Politiques d’autorisation pour créer, modifier et supprimer des ressources dans Aurora](security_iam_id-based-policy-examples-create-and-modify-examples.md)
+ [Exemples de politiques : Utilisation des clés de condition](UsingWithRDS.IAM.Conditions.Examples.md)
+ [Spécification de conditions : Utilisation de balises personnalisées](UsingWithRDS.IAM.SpecifyingCustomTags.md)
+ [Octroi d’autorisation de baliser les ressources Aurora lors de la création](security_iam_id-based-policy-examples-grant-permissions-tags-on-create.md)
## 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 plus d’informations, consultez [politiques gérées par AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [politiques gérées par AWS pour les activités professionnelles](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
+ **Accordez 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 d’IAM pour appliquer des autorisations, consultez [politiques et autorisations dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez 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 CloudFormation. Pour plus d’informations, consultez [Conditions pour éléments de politique JSON IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dans le *Guide de l’utilisateur IAM*.
+ **Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles** : l’Analyseur d’accès IAM 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 plus d’informations, consultez [Validation de politiques avec IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) 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 la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez [Sécurisation de l’accès aux API avec MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dans le *Guide de l’utilisateur IAM*.
## Utilisation de la console Aurora
Pour accéder à la console Amazon Aurora, 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 Aurora présentes dans votre Compte AWS. Si vous créez une politique 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 politique.
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 Aurora, associez également la politique AWS gérée suivante aux entités.
```
AmazonRDSReadOnlyAccess
```
Pour plus d’informations, consultez [Ajout d’autorisations à un utilisateur](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) dans le *Guide de l’utilisateur IAM*.
## 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 Aurora 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 de l’accès à l’aide de politiques](UsingWithRDS.IAM.md#security_iam_access-manage).
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 Aurora pour le AWS compte racine :
```
AmazonRDSFullAccess
```
## 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": "*"
}
]
}
```
# Politiques d’autorisation pour créer, modifier et supprimer des ressources dans Aurora
Les sections suivantes présentent des exemples de politiques d’autorisation qui accordent et restreignent l’accès aux ressources :
## Autoriser un utilisateur à créer des instances de base de données dans un AWS compte
Voici un exemple de politique qui permet au compte doté de 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`.
------
#### [ 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"
}
}
}
]
}
```
------
La stratégie inclut une instruction unique spécifiant les autorisations suivantes pour l’utilisateur :
+ La politique permet au compte de créer une instance de base de données à l'aide de l'opération [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) API (cela s'applique également à la [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) AWS CLI 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 (`123456789012`il s'agit du numéro de compte dans cet exemple) et le type de ressource. Pour plus d'informations sur la création ARNs, consultez[Amazon Resource Names (ARN) dans Amazon RDS](USER_Tagging.ARN.md).
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 Aurora](security_iam_service-with-iam.md#UsingWithRDS.IAM.Conditions). Cet exemple spécifie les conditions `rds:DatabaseEngine` et `rds:DatabaseClass`. Pour plus d'informations sur les valeurs de condition valides pour`rds:DatabaseEngine`, consultez la liste sous le `Engine` paramètre dans [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). Pour plus d’informations sur les valeurs de conditions valides pour `rds:DatabaseClass`, consultez [Moteurs de base de données pris en charge pour les classes d’instance de base de données](Concepts.DBInstanceClass.SupportAurora.md).
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 Aurora, consultez [Actions définies par Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) dans *Référence de l’autorisation de service*.
## 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 (\$1) figurant dans l’élément `Resource` indique que les actions sont autorisées pour toutes les ressources Amazon Aurora détenues par le compte.
------
#### [ JSON ]
****
```
{
"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`.
------
#### [ JSON ]
****
```
{
"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 Aurora 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`.
------
#### [ 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"
]
}
}
}
]
}
```
------
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`.
------
#### [ 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"
]
}
}
}
]
}
```
------
## 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.
------
#### [ 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"
}
]
}
```
------
## 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 :
------
#### [ JSON ]
****
```
{
"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 Aurora.
## 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.
------
#### [ JSON ]
****
```
{
"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.
------
#### [ 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"
}
}
}
]
}
```
------
## 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`.
------
#### [ 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"
]
}
}
}
]
}
```
------
# Spécification de conditions : Utilisation de balises personnalisées
Amazon Aurora 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`.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAM.SpecifyingCustomTags.html)
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 [Marquage des ressources Amazon Aurora et Amazon RDS](USER_Tagging.md).
**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 Aurora, consultez [Actions définies par Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) 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 Aurora. Pour plus d'informations sur l'ajout de balises à une ressource Amazon Aurora, consultez [Amazon Resource Names (ARN) dans Amazon RDS](USER_Tagging.ARN.md).
**Note**
Tous les exemples utilisent la région us-west-2 et contiennent un compte fictif. IDs
### 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`.
------
#### [ 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"
]
}
}
}
]
}
```
------
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`.
------
#### [ 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"
]
}
}
}
]
}
```
------
### 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.
------
#### [ 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"
}
}
}
]
}
```
------
### 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 ARNs des ressources , consultez[Amazon Resource Names (ARN) dans Amazon RDS](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"
}
}
}
]
}
```
------
# Octroi d’autorisation de baliser les ressources Aurora lors de la création
Certaines actions RDS API vous permettent de spécifier des balises lorsque vous créez la ressource. Vous pouvez utiliser des balises de ressource pour implémenter le contrôle basé sur les attributs (ABAC). Pour plus d'informations, voir [À quoi sert ABAC ? AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) et [Contrôle de l'accès aux AWS ressources à l'aide de balises](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html).
Pour permettre aux utilisateurs d’attribuer des balises aux ressources au moment de la création, ils doivent avoir les autorisations d’utiliser l’action qui crée la ressource (par exemple, `rds:CreateDBCluster`). Si les balises sont spécifiées dans l’action de création, RDS effectue des autorisations supplémentaires sur l’action `rds:AddTagsToResource` afin de vérifier si les utilisateurs disposent des autorisations nécessaires pour créer des balises. Par conséquent, les utilisateurs doivent également avoir des autorisations explicites d’utiliser l’action `rds:AddTagsToResource`.
Dans la définition de politique IAM de l’action `rds:AddTagsToResource`, vous pouvez utiliser la clé de condition `aws:RequestTag` pour exiger des balises dans une demande de balisage d’une ressource.
Par exemple, la politique suivante permet aux utilisateurs de créer des instances de base de données et d’appliquer des balises lors de la création d’une instances de base de données, mais uniquement avec des clés de balise spécifiques (`environment` ou `project`) :
------
#### [ 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"]
}
}
}
]
}
```
------
Cette politique refuse toute demande de création d’instance de base de données qui inclut les balises `environment` ou `project`, ou qui ne spécifie aucune de ces balises. En outre, les utilisateurs doivent spécifier des valeurs pour les balises qui correspondent aux valeurs autorisées dans la politique.
La politique suivante permet aux utilisateurs de créer des clusters de bases de données et d’appliquer des balises pendant la création, à l’exception de la balise `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"
}
}
}
]
}
```
------
## Actions d’API RDS prises en charge pour le balisage lors de la création
Les actions d’API RDS suivantes prennent en charge le balisage lors de la création d’une ressource. Pour ces actions, vous pouvez spécifier des balises lorsque vous créez la ressource :
+ `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`
Si vous utilisez l'API AWS CLI or pour créer une ressource avec des balises, le `Tags` paramètre est utilisé pour appliquer des balises aux ressources lors de la création.
Pour ces actions d’API, si le balisage échoue, la ressource n’est pas créée et la demande échoue avec une erreur. Ainsi, les ressources sont créées avec des balises ou elles ne sont pas créées du tout, ce qui empêche la création de ressources sans les balises prévues.
# AWS politiques gérées pour Amazon RDS
Pour ajouter des autorisations aux ensembles d'autorisations et aux rôles, il est plus facile d'utiliser des politiques AWS gérées que de les rédiger vous-même. Il faut du temps et de l’expertise pour [créer des politiques gérées par le client IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) qui ne fournissent à votre équipe que les autorisations dont elle a besoin. Pour démarrer rapidement, vous pouvez utiliser nos politiques AWS gérées. Ces politiques couvrent des cas d’utilisation courants et sont disponibles dans votre Compte AWS. Pour plus d'informations sur les politiques AWS gérées, voir les [politiques AWS gérées](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dans le *guide de l'utilisateur IAM*.
Services AWS maintenir et mettre à jour les politiques AWS gérées. Vous ne pouvez pas modifier les autorisations dans les politiques AWS gérées. Les services ajoutent parfois des autorisations supplémentaires à une politique AWS gérée pour prendre en charge de nouvelles fonctionnalités. Ce type de mise à jour affecte toutes les identités (jeux d’autorisations et rôles) auxquelles la politique est attachée. Les services sont plus susceptibles de mettre à jour une politique AWS gérée lorsqu'une nouvelle fonctionnalité est lancée ou lorsque de nouvelles opérations sont disponibles. Les services ne suppriment pas les autorisations d'une politique AWS gérée. Les mises à jour des politiques ne portent donc pas atteinte à vos autorisations existantes.
En outre, AWS prend en charge les politiques gérées pour les fonctions professionnelles qui couvrent plusieurs services. Par exemple, la politique `ReadOnlyAccess` AWS gérée fournit un accès en lecture seule à toutes Services AWS les ressources. Lorsqu'un service lance une nouvelle fonctionnalité, il AWS ajoute des autorisations en lecture seule pour les nouvelles opérations et ressources. Pour obtenir la liste des politiques de fonctions professionnelles et leurs descriptions, consultez la page [politiques gérées par AWS pour les fonctions de tâche](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dans le *Guide de l’utilisateur IAM*.
**Topics**
+ [AWS politique gérée : Amazon RDSRead OnlyAccess](#rds-security-iam-awsmanpol-AmazonRDSReadOnlyAccess)
+ [AWS politique gérée : Amazon RDSFull Access](#rds-security-iam-awsmanpol-AmazonRDSFullAccess)
+ [AWS politique gérée : Amazon RDSData FullAccess](#rds-security-iam-awsmanpol-AmazonRDSDataFullAccess)
+ [AWS politique gérée : Amazon RDSEnhanced MonitoringRole](#rds-security-iam-awsmanpol-AmazonRDSEnhancedMonitoringRole)
+ [AWS politique gérée : Amazon RDSPerformance InsightsReadOnly](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly)
+ [AWS politique gérée : Amazon RDSPerformance InsightsFullAccess](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess)
+ [AWS politique gérée : Amazon RDSDirectory ServiceAccess](#rds-security-iam-awsmanpol-AmazonRDSDirectoryServiceAccess)
+ [AWS politique gérée : Amazon RDSService RolePolicy](#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy)
+ [AWS politique gérée : Amazon RDSPreview ServiceRolePolicy](#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy)
+ [AWS politique gérée : Amazon RDSBeta ServiceRolePolicy](#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy)
## AWS politique gérée : Amazon RDSRead OnlyAccess
Cette politique autorise l'accès en lecture seule à Amazon RDS via le. AWS Management Console
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `rds` : permet aux principaux de décrire les ressources Amazon RDS et de dresser la liste des balises pour les ressources Amazon RDS.
+ `cloudwatch`— Permet aux principaux d'obtenir les statistiques CloudWatch métriques d'Amazon.
+ `ec2` : permet aux principaux de décrire les zones de disponibilité et les ressources de réseaux.
+ `logs`— Permet aux directeurs de décrire les flux de CloudWatch journaux des groupes de journaux et d'obtenir les événements du journal CloudWatch des journaux.
+ `devops-guru`— Permet aux responsables de décrire les ressources couvertes par Amazon DevOps Guru, qui sont spécifiées soit par des noms de CloudFormation pile, soit par des balises de ressources.
Pour plus d'informations sur cette politique, y compris le document de politique JSON, consultez [Amazon RDSRead OnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSReadOnlyAccess.html) dans le *AWS Managed Policy Reference Guide*.
## AWS politique gérée : Amazon RDSFull Access
Cette politique fournit un accès complet à Amazon RDS via le AWS Management Console.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `rds` : donne aux principaux un accès complet à Amazon RDS.
+ `application-autoscaling` : permet aux principaux de décrire et de gérer les cibles et les politiques de scalabilité automatique des applications.
+ `cloudwatch`— Permet aux directeurs d'obtenir des statistiques CloudWatch métriques et de gérer les CloudWatch alarmes.
+ `ec2` : permet aux principaux de décrire les zones de disponibilité et les ressources de réseaux.
+ `logs`— Permet aux directeurs de décrire les flux de CloudWatch journaux des groupes de journaux et d'obtenir les événements du journal CloudWatch des journaux.
+ `outposts`— Permet aux principaux d'obtenir des types d' AWS Outposts instances.
+ `pi` : permet aux principaux d’obtenir les métriques de Performance Insights.
+ `sns` : permet aux principaux de s’abonner à Amazon Simple Notification Service (Amazon SNS) et à ses rubriques, et de publier des messages Amazon SNS.
+ `devops-guru`— Permet aux responsables de décrire les ressources couvertes par Amazon DevOps Guru, qui sont spécifiées soit par des noms de CloudFormation pile, soit par des balises de ressources.
Pour plus d'informations sur cette politique, y compris le document de politique JSON, consultez [Amazon RDSFull Access](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSFullAccess.html) dans le *AWS Managed Policy Reference Guide*.
## AWS politique gérée : Amazon RDSData FullAccess
Cette politique permet un accès complet à l'utilisation de l'API de données et de l'éditeur de requêtes sur des Aurora Serverless clusters spécifiques Compte AWS. Cette politique permet d' Compte AWS obtenir la valeur d'un secret auprès de AWS Secrets Manager.
Vous pouvez associer la politique `AmazonRDSDataFullAccess` à vos identités IAM.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `dbqms` : permet aux principaux d’accéder, de créer, de supprimer, de décrire et de mettre à jour des requêtes. Le service `dbqms` (Database Query Metadata Service, service de métadonnées de requête de base de données) est un service interne uniquement. Il fournit vos requêtes récentes et enregistrées pour l'éditeur de requêtes sur le AWS Management Console for multiple Services AWS, y compris Amazon RDS.
+ `rds-data` : permet aux principaux d’exécuter des instructions SQL sur les bases de données Aurora Serverless.
+ `secretsmanager`— Permet aux principaux d'obtenir la valeur d'un secret auprès de AWS Secrets Manager.
Pour plus d'informations sur cette politique, y compris le document de politique JSON, consultez [Amazon RDSData FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDataFullAccess.html) dans le *AWS Managed Policy Reference Guide*.
## AWS politique gérée : Amazon RDSEnhanced MonitoringRole
Cette politique donne accès à Amazon CloudWatch Logs pour Amazon RDS Enhanced Monitoring.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `logs`— Permet aux responsables de créer des groupes de CloudWatch journaux et des politiques de conservation, ainsi que de créer et de décrire CloudWatch les flux de journaux des groupes de journaux. Il permet également aux directeurs de mettre et d'obtenir les événements du journal CloudWatch Logs.
Pour plus d'informations sur cette politique, y compris le document de politique JSON, consultez [Amazon RDSEnhanced MonitoringRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSEnhancedMonitoringRole.html) dans le *AWS Managed Policy Reference Guide*.
## AWS politique gérée : Amazon RDSPerformance InsightsReadOnly
Cette politique fournit un accès en lecture seule à l’analyse des performances d’Amazon RDS pour les instances Amazon de base de données RDS et les clusters de bases de données Amazon Aurora.
Cette politique inclut désormais `Sid` (ID d’instruction) comme identifiant pour l’instruction de la politique.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `rds` : permet aux principaux de décrire des instances de base de données Amazon RDS et des clusters de base de données Amazon Aurora.
+ `pi` : permet aux principaux de faire des appels à l’API Analyse des performances d’Amazon RDS et d’accéder aux métriques de Performance Insights.
Pour plus d'informations sur cette politique, y compris le document de politique JSON, consultez [Amazon RDSPerformance InsightsReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsReadOnly.html) dans le *AWS Managed Policy Reference Guide*.
## AWS politique gérée : Amazon RDSPerformance InsightsFullAccess
Cette politique fournit un accès complet à l’analyse des performances d’Amazon RDS pour les instances de base de données Amazon RDS et les clusters de bases de données Amazon Aurora.
Cette politique inclut désormais `Sid` (ID d’instruction) comme identifiant pour l’instruction de la politique.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `rds` : permet aux principaux de décrire des instances de base de données Amazon RDS et des clusters de bases de données Amazon Aurora.
+ `pi` : permet aux principaux d’appeler l’API Analyse des performances d’Amazon RDS et de créer, d’afficher et de supprimer des rapports d’analyse des performances.
+ `cloudwatch`— Permet aux principaux de répertorier toutes les CloudWatch métriques Amazon et d'obtenir des données et des statistiques sur les métriques.
Pour plus d'informations sur cette politique, y compris le document de politique JSON, consultez [Amazon RDSPerformance InsightsFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsFullAccess.html) dans le *AWS Managed Policy Reference Guide*.
## AWS politique gérée : Amazon RDSDirectory ServiceAccess
Cette politique permet à Amazon RDS d’effectuer des appels vers Directory Service.
**Détails de l’autorisation**
Cette politique inclut l’autorisation suivante :
+ `ds`— Permet aux principaux de décrire les Directory Service répertoires et de contrôler les autorisations accordées aux Directory Service annuaires.
Pour plus d'informations sur cette politique, y compris le document de politique JSON, consultez [Amazon RDSDirectory ServiceAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDirectoryServiceAccess.html) dans le *AWS Managed Policy Reference Guide*.
## AWS politique gérée : Amazon RDSService RolePolicy
Vous ne pouvez pas attacher `AmazonRDSServiceRolePolicy` à vos entités IAM. Cette politique est attachée à un rôle lié à un service qui permet à Amazon RDS d’effectuer des actions en votre nom. Pour de plus amples informations, veuillez consulter [Autorisations des rôles liés à un service pour Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions).
## AWS politique gérée : Amazon RDSPreview ServiceRolePolicy
Ne joignez pas `AmazonRDSPreviewServiceRolePolicy` à vos entités IAM. Cette politique est associée à un rôle lié à un service qui permet à Amazon RDS d'appeler des AWS services au nom de vos ressources de base de données RDS. Pour de plus amples informations, veuillez consulter [Rôles liés à un service pour Amazon RDS Preview](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdspreview).
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `ec2` : permet aux principaux de décrire les zones de disponibilité et les ressources de réseaux.
+ `secretsmanager`— Permet aux principaux d'obtenir la valeur d'un secret auprès de AWS Secrets Manager.
+ `cloudwatch`, `logs` ‐ Permet à Amazon RDS de télécharger les métriques et les journaux de l'instance de base de données CloudWatch via CloudWatch un agent.
Pour plus d'informations sur cette politique, y compris le document de politique JSON, consultez [Amazon RDSPreview ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPreviewServiceRolePolicy.html) dans le *AWS Managed Policy Reference Guide*.
## AWS politique gérée : Amazon RDSBeta ServiceRolePolicy
Ne joignez pas `AmazonRDSBetaServiceRolePolicy` à vos entités IAM. Cette politique est associée à un rôle lié à un service qui permet à Amazon RDS d'appeler des AWS services au nom de vos ressources de base de données RDS. Pour de plus amples informations, veuillez consulter [Autorisations du rôle lié à un service pour Amazon RDS bêta](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdsbeta).
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes :
+ `ec2`‐ Permet à Amazon RDS d'effectuer des opérations de sauvegarde sur l'instance de base de données qui fournit des fonctionnalités de point-in-time restauration.
+ `secretsmanager` ‐ Permet à Amazon RDS de gérer des secrets spécifique à une instance de base de données créés par Amazon RDS.
+ `cloudwatch`, `logs` ‐ Permet à Amazon RDS de télécharger les métriques et les journaux de l'instance de base de données CloudWatch via CloudWatch un agent.
Pour plus d'informations sur cette politique, y compris le document de politique JSON, consultez [Amazon RDSBeta ServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSBetaServiceRolePolicy.html) dans le *AWS Managed Policy Reference Guide*.
# Mises à jour Amazon RDS des politiques gérées par AWS
Affichez les détails des mises à jour des politiques gérées par AWS pour Amazon RDS depuis que ce service a commencé à assurer le suivi des modifications. Pour recevoir des alertes automatiques sur les modifications apportées à cette page, abonnez-vous au flux RSS de la page [Document history](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/WhatsNew.html) (Historique des documents) d’Amazon RDS.
| Modification | Description | Date |
| --- | --- | --- |
| [AWS politique gérée : Amazon RDSPreview ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy) – Mise à jour de la politique existante | Amazon RDS a supprimé l’autorisation `sns:Publish` de `AmazonRDSPreviewServiceRolePolicy` du rôle lié au service `AWSServiceRoleForRDSPreview`. Pour plus d’informations, consultez [AWS politique gérée : Amazon RDSPreview ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy). | 7 août 2024 |
| [AWS politique gérée : Amazon RDSBeta ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy) – Mise à jour de la politique existante | Amazon RDS a supprimé l’autorisation `sns:Publish` de `AmazonRDSBetaServiceRolePolicy` du rôle lié au service `AWSServiceRoleForRDSBeta`. Pour plus d’informations, consultez [AWS politique gérée : Amazon RDSBeta ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy). | 7 août 2024 |
| [AWS politique gérée : Amazon RDSService RolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy) – Mise à jour de la politique existante | Amazon RDS a supprimé l’autorisation `sns:Publish` de `AmazonRDSServiceRolePolicy` du rôle lié au service ` AWSServiceRoleForRDS`. Pour plus d’informations, consultez [AWS politique gérée : Amazon RDSService RolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy). | 2 juillet 2024 |
| [AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md) – Mise à jour de la politique existante | Amazon RDS a ajouté une nouvelle autorisation à `AmazonRDSCustomServiceRolePolicy` du rôle `AWSServiceRoleForRDSCustom` liés au service afin de permettre à RDS Custom for SQL Server de modifier le type d’instance de l’hôte de base de données sous-jacent. RDS a également ajouté l’autorisation `ec2:DescribeInstanceTypes` pour obtenir des informations sur le type d’instance pour l’hôte de base de données. Pour plus d’informations, consultez [AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md). | 8 avril 2024 |
| [AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md) – Nouvelle politique | Amazon RDS a ajouté une nouvelle politique gérée nommée AmazonRDSCustomInstanceProfileRolePolicy pour permettre à RDS Custom d’effectuer des actions d’automatisation et des tâches de gestion de base de données via un profil d’instance EC2. Pour plus d’informations, consultez [AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md). | 27 février 2024 |
| [Autorisations des rôles liés à un service pour Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Mise à jour d’une politique existante | Amazon RDS a ajouté de nouvelles ID d’instruction à la politique `AmazonRDSServiceRolePolicy` du rôle `AWSServiceRoleForRDS` lié au service. Pour plus d’informations, consultez [Autorisations des rôles liés à un service pour Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions). | 19 janvier 2024 |
| [AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md) – Mise à jour des politiques existantes | Les politiques gérées par `AmazonRDSPerformanceInsightsReadOnly` et `AmazonRDSPerformanceInsightsFullAccess` incluent désormais `Sid` (ID d’instruction) comme identifiant dans l’instruction de la politique. Pour plus d’informations, consultez [AWS politique gérée : Amazon RDSPerformance InsightsReadOnly](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly) et [AWS politique gérée : Amazon RDSPerformance InsightsFullAccess](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess). | 23 octobre 2023 |
| [AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md) – Mise à jour de la politique existante | Amazon RDS a ajouté de nouvelles autorisations à la politique gérée `AmazonRDSFullAccess`. Les autorisations vous permettent de générer, d’afficher et de supprimer le rapport d’analyse des performances pendant une période donnée. Pour plus d’informations sur la configuration de stratégies d’accès pour l’analyse des performances, consultez [Configuration des politiques d’accès pour Performance Insights](USER_PerfInsights.access-control.md) | 17 août 2023 |
| [AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md) – Nouvelle politique et mise à jour de la politique existante | Amazon RDS a ajouté de nouvelles autorisations à la politique gérée `AmazonRDSPerformanceInsightsReadOnly` et une nouvelle politique gérée nommée `AmazonRDSPerformanceInsightsFullAccess`. Ces autorisations vous permettent d’analyser les informations de performances pour une période donnée, de consulter les résultats d’analyse ainsi que les recommandations, et de supprimer les rapports. Pour plus d’informations sur la configuration de stratégies d’accès pour l’analyse des performances, consultez [Configuration des politiques d’accès pour Performance Insights](USER_PerfInsights.access-control.md) | 16 août 2023 |
| [AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md) – Mise à jour d’une politique existante | Amazon RDS a ajouté un nouvel espace de noms Amazon CloudWatch `ListMetrics` pour `AmazonRDSFullAccess` et `AmazonRDSReadOnlyAccess`. Cet espace de nom est nécessaire à Amazon RDS pour répertorier des métriques spécifiques sur l’utilisation des ressources. Pour plus d’informations, consultez [Présentation de la gestion des autorisations d’accès à vos ressources CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-access-control-overview-cw.html) dans le *Guide de l’utilisateur Amazon CloudWatch*. | 4 avril 2023 |
| [Autorisations des rôles liés à un service pour Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Mise à jour d’une politique existante | Amazon RDS a ajouté de nouvelles autorisations à la politique `AmazonRDSServiceRolePolicy` du rôle `AWSServiceRoleForRDS` lié au service pour l’intégration avec AWS Secrets Manager. RDS nécessite une intégration à Secrets Manager pour gérer les mots de passe des utilisateurs principaux dans Secrets Manager. Le secret utilise une convention de dénomination réservée et restreint les mises à jour des clients. Pour plus d’informations, consultez [Gestion des mots de passe avec Amazon Aurora et AWS Secrets Manager](rds-secrets-manager.md). | 22 décembre 2022 |
| [AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md) – Mise à jour des politiques existantes | Amazon RDS a ajouté une nouvelle autorisation aux politiques gérées `AmazonRDSFullAccess` et `AmazonRDSReadOnlyAccess` pour vous permettre d’activer Amazon DevOps Guru dans la console RDS. Cette autorisation est requise pour vérifier si DevOps Guru est activé. Pour plus d’informations, consultez [Configuration des politiques d'accès IAM pour DevOps Guru for RDS](devops-guru-for-rds.md#devops-guru-for-rds.configuring.access). | 19 décembre 2022 |
| [Autorisations des rôles liés à un service pour Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Mise à jour d’une politique existante | Amazon RDS a ajouté un nouvel espace de noms Amazon CloudWatch à `AmazonRDSPreviewServiceRolePolicy` pour `PutMetricData`. Cet espace de nom est nécessaire à Amazon RDS pour publier des métriques sur l’utilisation des ressources. Pour plus d’informations, consultez [Using condition keys to limit access to CloudWatch namespaces](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) (Utilisation des clés de condition pour limiter l’accès aux espaces de noms CloudWatch) dans le *Guide de l’utilisateur Amazon CloudWatch*. | 7 juin 2022 |
| [Autorisations des rôles liés à un service pour Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Mise à jour d’une politique existante | Amazon RDS a ajouté un nouvel espace de noms Amazon CloudWatch à `AmazonRDSBetaServiceRolePolicy` pour `PutMetricData`. Cet espace de nom est nécessaire à Amazon RDS pour publier des métriques sur l’utilisation des ressources. Pour plus d’informations, consultez [Using condition keys to limit access to CloudWatch namespaces](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) (Utilisation des clés de condition pour limiter l’accès aux espaces de noms CloudWatch) dans le *Guide de l’utilisateur Amazon CloudWatch*. | 7 juin 2022 |
| [Autorisations des rôles liés à un service pour Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Mise à jour d’une politique existante | Amazon RDS a ajouté un nouvel espace de noms Amazon CloudWatch à `AWSServiceRoleForRDS` pour `PutMetricData`. Cet espace de nom est nécessaire à Amazon RDS pour publier des métriques sur l’utilisation des ressources. Pour plus d’informations, consultez [Using condition keys to limit access to CloudWatch namespaces](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) (Utilisation des clés de condition pour limiter l’accès aux espaces de noms CloudWatch) dans le *Guide de l’utilisateur Amazon CloudWatch*. | 22 avril 2022 |
| [AWS politiques gérées pour Amazon RDS](rds-security-iam-awsmanpol.md) – Nouvelle politique | Amazon RDS a ajouté une nouvelle politique gérée nommée `AmazonRDSPerformanceInsightsReadOnly` pour permettre à Amazon RDS d’appeler des services AWS au nom de vos instances de base de données. Pour plus d’informations sur la configuration de stratégies d’accès pour l’analyse des performances, consultez [Configuration des politiques d’accès pour Performance Insights](USER_PerfInsights.access-control.md) | 10 mars 2022 |
| [Autorisations des rôles liés à un service pour Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions) – Mise à jour d’une politique existante | Amazon RDS a ajouté de nouveaux espaces de noms Amazon CloudWatch à `AWSServiceRoleForRDS` pour `PutMetricData`. Ces espaces de noms sont nécessaires pour qu’Amazon DocumentDB (compatible avec MongoDB) et Amazon Neptune puissent publier des métriques CloudWatch. Pour plus d’informations, consultez [Using condition keys to limit access to CloudWatch namespaces](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) (Utilisation des clés de condition pour limiter l’accès aux espaces de noms CloudWatch) dans le *Guide de l’utilisateur Amazon CloudWatch*. | 4 mars 2022 |
| Amazon RDS a commencé à assurer le suivi des modifications | Amazon RDS a commencé à assurer le suivi des modifications pour ses politiques gérées par AWS. | 26 octobre 2021 |
# Prévention des problèmes d'adjoint confus entre services
Le *problème de l’adjoint confus* est un problème de sécurité dans lequel une entité qui n’a pas l’autorisation d’effectuer une action peut contraindre une entité plus privilégiée à effectuer cette action. EnAWS, l'usurpation d'identité interservices peut entraîner un problème de confusion chez les adjoints.
L’usurpation d’identité entre services peut se produire lorsqu’un service (le *service appelant*) appelle un autre service (le *service appelé*). Le service appelant peut être manipulé pour utiliser ses autorisations et agir sur les ressources d'un autre client, d'une manière dont il ne devrait pas avoir accès. Pour éviter cela, AWS fournit des outils qui peuvent vous aider à protéger vos données pour tous les services dont les responsables ont obtenu l'accès aux ressources de votre compte. Pour de plus amples informations, veuillez consulter [Le problème du député confus](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) dans le *Guide de l’utilisateur IAM*.
Afin de limiter les autorisations octroyées par Amazon RDS à un autre service pour une ressource spécifique, nous vous recommandons d'utiliser les clés de contexte de condition globale [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) et [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) dans les politiques de ressources.
Dans certains cas, la valeur `aws:SourceArn` ne contient pas l'ID du compte, par exemple lorsque vous utilisez l'Amazon Resource Name (ARN) pour un compartiment Amazon S3. Dans ces cas, veillez à utiliser les deux clés de contexte de condition globale pour limiter les autorisations. Dans certains cas, vous utilisez les deux clés de contexte de condition globale et la valeur `aws:SourceArn` contient l'ID du compte. Dans ces cas, assurez-vous que la valeur `aws:SourceAccount` et le compte dans le `aws:SourceArn` utilisent le même ID de compte lorsqu'ils sont utilisés dans la même instruction de politique. Utilisez `aws:SourceArn` si vous souhaitez qu'une seule ressource soit associée à l'accès entre services. Si vous souhaitez autoriser l'association d'une ressource du AWS compte spécifié à l'utilisation interservices, utilisez`aws:SourceAccount`.
Assurez-vous que la valeur de `aws:SourceArn` est un ARN d'un type de ressource Amazon RDS. Pour de plus amples informations, veuillez consulter [Amazon Resource Names (ARN) dans Amazon RDS](USER_Tagging.ARN.md).
Le moyen le plus efficace de se protéger contre le problème de député confus consiste à utiliser la clé de contexte de condition globale `aws:SourceArn` avec l’ARN complet de la ressource. Dans certains cas, vous ne connaissez pas l'ARN complet de la ressource ou vous spécifiez plusieurs ressources. Dans ces cas, utilisez la clé de contexte de condition globale `aws:SourceArn` avec des caractères génériques (`*`) pour les parties inconnues de l'ARN. Par exemple : `arn:aws:rds:*:123456789012:*`.
L'exemple suivant montre comment utiliser les clés de contexte de condition globale `aws:SourceArn` et `aws:SourceAccount` pour dans Amazon RDS afin d'éviter le problème de l'adjoint confus.
------
#### [ 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"
}
}
}
}
```
------
Pour obtenir d'autres exemples de politiques qui utilisent les clés de contexte de condition globale `aws:SourceArn` et `aws:SourceAccount`, veuillez consulter les sections suivantes :
+ [Octroi d’autorisations de publication de notifications dans une rubrique Amazon SNS](USER_Events.GrantingPermissions.md)
+ [Configuration de l’accès à un compartiment Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md) (importation PostgreSQL)
+ [Configuration de l’accès à un compartiment Amazon S3](postgresql-s3-export-access-bucket.md) (exportation PostgreSQL)
# Authentification de base de données IAM
Vous pouvez vous authentifier auprès de votre cluster d' de base de données à l'aide de l'authentification de base de données Gestion des identités et des accès AWS (IAM). L’authentification de base de données IAM fonctionne avec Aurora MySQL et Aurora PostgreSQL. Grâce à cette méthode d’authentification, vous n’avez plus besoin de mot de passe pour vous connecter à un cluster de bases de données. En revanche, un jeton d’authentification est nécessaire.
Un *jeton d’authentification* est une chaîne de caractères unique générée par Amazon Aurora sur demande. Les jetons d'authentification sont générés à l'aide de AWS la version 4 de Signature. Chaque jeton a une durée de vie de 15 minutes. Il n’est pas nécessaire de stocker les informations d’identification des utilisateurs dans la base de données, car l’authentification est gérée de manière externe avec IAM. Vous pouvez aussi toujours utiliser l’authentification de base de données standard. Le jeton est uniquement utilisé pour l’authentification et n’affecte pas la session une fois qu’il est établi.
L’authentification de base de données IAM offre les avantages suivants :
+ Le trafic réseau à destination et en provenance de la base de données est chiffré à l’aide de Secure Socket Layer (SSL) ou de Transport Layer Security (TLS). Pour plus d'informations sur l'utilisation SSL/TLS d', consultez[Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md).
+ Vous pouvez utiliser IAM pour gérer de façon centralisée l’accès à vos ressources de base de données, au lieu de gérer l’accès de manière individuelle sur chaque cluster de bases de données.
+ Pour les applications exécutées sur Amazon EC2, vous pouvez utiliser des informations d’identification spécifiques à votre instance EC2 pou accéder à la base de données, ce qui garantit une meilleure sécurité qu’un mot de passe.
En règle générale, envisagez d’utiliser l’authentification de base de données IAM lorsque vos applications créent moins de 200 connexions par seconde, et que vous ne souhaitez pas gérer les noms d’utilisateur et les mots de passe directement dans le code de votre application.
Le pilote JDBC Amazon Web Services (AWS) prend en charge l’authentification de la base de données IAM. Pour plus d'informations, consultez la section [Plug-in d'authentification AWS IAM](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/using-the-jdbc-driver/using-plugins/UsingTheIamAuthenticationPlugin.md) dans le [référentiel de pilotes JDBC Amazon Web Services (AWS)](https://github.com/aws/aws-advanced-jdbc-wrapper). GitHub
Le pilote Python Amazon Web Services (AWS) prend en charge l’authentification de la base de données IAM. Pour plus d'informations, consultez la section [Plug-in d'authentification AWS IAM](https://github.com/aws/aws-advanced-python-wrapper/blob/main/docs/using-the-python-driver/using-plugins/UsingTheIamAuthenticationPlugin.md) dans le [ GitHubréférentiel de pilotes Python Amazon Web Services (AWS)](https://github.com/aws/aws-advanced-python-wrapper).
Consultez les rubriques suivantes pour apprendre à configurer IAM pour l’authentification de la base de données :
+ [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Création d’un compte de base de données à l’aide de l’authentification IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
+ [Connexion à votre cluster de base de données à l'aide de l'authentification IAM.](UsingWithRDS.IAMDBAuth.Connecting.md)
## Disponibilité des régions et des versions
La disponibilité et la prise en charge des fonctions varient selon les versions spécifiques de chaque moteur de base de données Aurora, et selon les Régions AWS. Pour obtenir plus d’informations sur la disponibilité des versions et des régions avec Aurora et l’authentification de la base de données IAM, consultez [Régions et moteurs de base de données Aurora pris en charge pour l’authentification de base de données IAM](Concepts.Aurora_Fea_Regions_DB-eng.Feature.IAMdbauth.md).
Pour Aurora MySQL, toutes les classes d’instance de base de données prises en charge prennent en charge l’authentification de base de données IAM, à l’exception de db.t2.small et db.t3.small. Pour plus d’informations sur les classes d’instance de base de données prises en charge, consultez [Moteurs de base de données pris en charge pour les classes d’instance de base de données](Concepts.DBInstanceClass.SupportAurora.md).
## Support CLI et kit SDK
L'authentification de base de données IAM est disponible pour [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/generate-db-auth-token.html)et pour les langues AWS SDKs spécifiques suivantes :
+ [AWS SDK pour .NET](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/RDS/TRDSAuthTokenGenerator.html)
+ [AWS SDK pour 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 pour Go](https://docs.aws.amazon.com/sdk-for-go/api/service/rds/#pkg-overview)
+ [AWS SDK pour Java](https://docs.aws.amazon.com/sdk-for-java/latest/reference/software/amazon/awssdk/services/rds/RdsUtilities.html)
+ [AWS SDK pour JavaScript](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/modules/_aws_sdk_rds_signer.html)
+ [AWS SDK pour PHP](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.Rds.AuthTokenGenerator.html)
+ [AWS SDK pour Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/rds.html#RDS.Client.generate_db_auth_token)
+ [AWS SDK pour Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/RDS/AuthTokenGenerator.html)
## Limites de l’authentification de base de données IAM
Les limitations suivantes s’appliquent lors de l’utilisation de l’authentification de base de données IAM :
+ Actuellement, l’authentification de base de données IAM ne prend pas en charge toutes les clés de contexte de condition globale.
Pour plus d’informations sur les clés de contexte de condition globale, consultez [Clés de contexte de condition globales AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *Guide de l’utilisateur IAM*.
+ Pour PostgreSQL, si le rôle IAM (`rds_iam`) est ajouté à un utilisateur (y compris à l’utilisateur principal RDS), l’authentification IAM a priorité sur l’authentification par mot de passe, de sorte que l’utilisateur doit se connecter en tant qu’utilisateur IAM.
+ Vous ne pouvez pas utiliser un enregistrement DNS Route 53 personnalisé à la place du point de terminaison du cluster de bases de données pour générer le jeton d’authentification.
+ CloudWatch et CloudTrail n'enregistrez pas l'authentification IAM. Ces services ne suivent pas les appels d’API `generate-db-auth-token` qui autorisent le rôle IAM à activer la connexion à la base de données.
+ L’authentification de base de données IAM nécessite des ressources de calcul sur le cluster de bases de données. Pour garantir une connectivité fiable, votre base de données doit disposer de 300 à 1 000 Mio de mémoire supplémentaire. Pour connaître la mémoire nécessaire à votre charge de travail, comparez la colonne RES pour les processus RDS dans la liste des processus de surveillance améliorée avant et après l’activation de l’authentification de base de données IAM. Consultez [Affichage des métriques du système d’exploitation dans la console RDS](USER_Monitoring.OS.Viewing.md).
Si vous utilisez une instance de classe à performances extensibles, évitez de manquer de mémoire en réduisant d’autant la mémoire utilisée par d’autres paramètres tels que les tampons et le cache.
+ Pour Aurora MySQL, vous ne pouvez pas utiliser l'authentification par mot de passe pour un utilisateur de base de données que vous configurez avec l'authentification IAM.
+ L’authentification de base de données IAM n’est prise en charge pour RDS on Outposts, quel que soit le moteur.
## Recommandations pour l’authentification de base de données IAM
Nous recommandons les pratiques suivantes lors de l’utilisation de l’authentification de base de données IAM :
+ Utilisez l’authentification de base de données IAM si votre application exige moins de 200 nouvelles connexions d’authentification de base de données IAM par seconde.
Les moteurs de base de données qui fonctionnent avec Amazon Aurora n’imposent pas de limites de tentatives d’authentification par seconde. Néanmoins, lorsque vous utilisez l’authentification de base de données IAM, votre application doit générer un jeton d’authentification. Votre application emploie ensuite ce jeton pour la connexion au cluster de bases de données. Si vous dépassez la limite maximale de nouvelles connexions par seconde, le traitement supplémentaire d’authentification de base de données IAM peut entraîner une limitation de la connexion.
Envisagez d’utiliser le regroupement de connexions dans vos applications pour limiter la création constante de connexions. Cela peut réduire les frais généraux liés à l’authentification de base de données IAM et permettre à vos applications de réutiliser les connexions existantes. Vous pouvez également envisager d’utiliser le proxy RDS pour ces cas d’utilisation. Le proxy RDS entraîne des coûts supplémentaires. Consultez [Tarification de Proxy Amazon RDS](https://aws.amazon.com/rds/proxy/pricing/).
+ La taille d’un jeton d’authentification de base de données IAM dépend de nombreux facteurs, notamment du nombre de balises IAM, des politiques de service IAM, de la longueur des ARN, ainsi que d’autres propriétés IAM et de base de données. La taille minimale de ce jeton est généralement d’environ 1 Ko, mais elle peut être plus grande. Étant donné que ce jeton est utilisé comme mot de passe dans la chaîne de connexion à la base de données à l'aide de l'authentification IAM, vous devez vous assurer que les outils de votre pilote de base de données (par exemple, ODBC) and/or ne limitent ni ne tronquent ce jeton en raison de sa taille. Un jeton tronqué provoquera l’échec de la validation d’authentification effectuée par la base de données et IAM.
+ Si vous utilisez des informations d’identification temporaires lors de la création d’un jeton d’authentification d’une base de données IAM, les informations d’identification temporaires doivent toujours être valides lorsque vous utilisez le jeton d’authentification d’une base de données IAM pour effectuer une demande de connexion.
## Clés contextuelles de condition AWS globale non prises en charge
L'authentification de base de données IAM ne prend pas en charge le sous-ensemble suivant de clés AWS contextuelles de conditions globales.
+ `aws:Referer`
+ `aws:SourceIp`
+ `aws:SourceVpc`
+ `aws:SourceVpce`
+ `aws:UserAgent`
+ `aws:VpcSourceIp`
Pour plus d’informations, consultez [Clés de contexte de condition globales AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) dans le *Guide de l’utilisateur IAM*.
# Activation et désactivation de l’authentification de base de données IAM
Par défaut, l’authentification de base de données IAM est désactivée sur les et clusters de bases de données. Vous pouvez activer ou désactiver l'authentification de base de données IAM à l'aide de AWS Management Console AWS CLI, ou de l'API.
Vous pouvez activer l’authentification de base de données IAM lorsque vous effectuez une des actions suivantes :
+ Pour créer un nouveau cluster de bases de données avec l’authentification de base de données IAM activée, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md).
+ Pour modifier un cluster de bases de données afin d’activer l’authentification de base de données IAM, consultez [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md).
+ Pour restaurer un cluster de bases de données à partir d’un instantané avec l’authentification de base de données IAM activée, consultez [Restauration à partir d’un instantané de cluster de bases de données](aurora-restore-snapshot.md).
+ Pour restaurer un cluster de bases de données à un instant dans le passé avec l’authentification de base de données IAM activée, consultez [Restauration d’un cluster de bases de données à une date définie](aurora-pitr.md).
## Console
Chaque flux de travail de création ou de modification comporte une section **Authentification de base de données** dans laquelle vous pouvez activer ou désactiver l’authentification de base de données IAM. Dans cette section, choisissez **Authentification de base de données par mot de passe et IAM** pour activer l’authentification de base de données IAM.
**Pour activer ou désactiver l’authentification de base de données IAM pour un cluster de bases de données**
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans la panneau de navigation, choisissez **Databases (Bases de données)**.
1. Choisissez cluster de bases de données que vous souhaitez modifier.
**Note**
Vous ne pouvez activer l’authentification IAM que si toutes les instances de base de données du cluster sont compatibles avec IAM. Consultez les exigences de compatibilité présentées dans [Disponibilité des régions et des versions](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
1. Sélectionnez **Modify**.
1. Dans la section **Authentification de base de données, sélectionnez Mot de passe et authentification** de **données IAM pour activer l'authentification** de base de données IAM. Choisissez **Authentification par mot de passe** ou **Authentification par mot de passe et Kerberos** pour désactiver l’authentification IAM.
1. Vous pouvez également choisir d'activer la publication des journaux d'authentification IAM DB dans CloudWatch Logs. Sous **Exportations de journaux**, choisissez l'option de **iam-db-auth-error journal**. La publication de vos CloudWatch journaux dans Logs consomme de l'espace de stockage et vous devez payer des frais pour ce stockage. Assurez-vous de supprimer tous les CloudWatch journaux dont vous n'avez plus besoin.
1. Choisissez **Continuer**.
1. Pour appliquer immédiatement les modifications, choisissez **Immédiatement** dans la section **Planification des modifications**.
1. Choisissez ou **Modifier le cluster**.
## AWS CLI
Pour créer un nouveau cluster de base de données avec authentification IAM à l'aide de AWS CLI, utilisez la [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html)commande. Spécifiez l’option `--enable-iam-database-authentication`.
Pour mettre à jour un cluster de bases de données existant de manière à activer ou non l’authentification IAM, utilisez la commande de l’ AWS CLI [https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). Spécifiez l’option `--enable-iam-database-authentication` ou `--no-enable-iam-database-authentication`, selon le cas.
**Note**
Vous ne pouvez activer l’authentification IAM que si toutes les instances de base de données du cluster sont compatibles avec IAM. Consultez les exigences de compatibilité présentées dans [Disponibilité des régions et des versions](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
Par défaut, Aurora procède à la modification pendant la fenêtre de maintenance suivante. Si vous souhaitez ignorer ceci et activer l’authentification de bases de données IAM dès que possible, utilisez le paramètre `--apply-immediately`.
Si vous restaurez un cluster d' de base de données, utilisez l'une des AWS CLI commandes suivantes :
+ `[restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)`
+ `[restore-db-cluster-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)`
Le paramètre d’authentification de base de données IAM par défaut est celui de l’instantané source. Pour le modifier, spécifiez l’option `--enable-iam-database-authentication` ou `--no-enable-iam-database-authentication`, selon le cas.
## API RDS
Pour créer une nouvelle instance de base de données avec authentification IAM par l’intermédiaire de l’API, utilisez l’opération d’API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html). Définissez le paramètre `EnableIAMDatabaseAuthentication` sur `true`.
Pour mettre à jour un cluster de bases de données existant de manière à activer l’authentification IAM, utilisez l’opération d’API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Définissez le paramètre `EnableIAMDatabaseAuthentication` sur `true` pour activer l’authentification IAM ou sur `false` pour la désactiver.
**Note**
Vous ne pouvez activer l’authentification IAM que si toutes les instances de base de données du cluster sont compatibles avec IAM. Consultez les exigences de compatibilité présentées dans [Disponibilité des régions et des versions](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability).
Si vous restaurez un cluster ou une de base de données, utilisez l’une des opérations d’API suivantes :
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html)
+ [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html)
Le paramètre d’authentification de base de données IAM par défaut est celui de l’instantané source. Pour modifier ce paramètre, définissez le paramètre `EnableIAMDatabaseAuthentication` sur `true` pour activer l’authentification IAM ou sur `false` pour la désactiver.
# Création et utilisation d'une politique IAM pour l'accès à une base de données IAM
Pour autoriser un utilisateur ou un rôle à se connecter à votre cluster de bases de données, vous devez créer une politique IAM. Vous attachez ensuite la politique à un jeu d'autorisations ou à un rôle.
**Note**
Pour en savoir plus sur les stratégies IAM, consultez [Identity and Access Management pour Amazon Aurora](UsingWithRDS.IAM.md).
L'exemple de politique suivant autorise un utilisateur à se connecter à un cluster de bases de données en utilisant l'authentification de base de données IAM.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:111122223333:dbuser:cluster-ABCDEFGHIJKL01234/db_user"
]
}
]
}
```
------
**Important**
Un utilisateur doté d'autorisations d'administrateur peut accéder aux clusters de bases de données sans autorisations explicites dans une politique IAM. Si vous souhaitez restreindre l'accès de l'administrateur aux et aux clusters de base de données, vous pouvez créer un rôle IAM avec les autorisations appropriées accordant moins de privilèges, puis les assigner à l'administrateur.
**Note**
Ne confondez pas le préfixe `rds-db:` avec d'autres préfixes d'opération d'API RDS; qui commencent par `rds:`. Vous utilisez le préfixe `rds-db:` et l'action `rds-db:connect` uniquement pour l'authentification de base de données IAM. Ils ne sont valides que dans ce contexte.
L'exemple de politique inclut une instruction unique avec les éléments suivants :
+ `Effect` – Spécifiez `Allow` pour octroyer l'accès au cluster de base de données. Si vous n'autorisez pas explicitement l'accès, celui-ci est refusé par défaut.
+ `Action` – Spécifiez `rds-db:connect` pour autoriser les connexions au cluster de base de données.
+ `Resource` – Spécifiez un ARN (Amazon Resource Name) qui décrit un compte de base de données dans un cluster de base de données. Le format de l'ARN est le suivant.
```
arn:aws:rds-db:region:account-id:dbuser:DbClusterResourceId/db-user-name
```
Dans ce format, remplacez les variables suivantes :
+ `region`est la AWS région du cluster d' de base de données. Dans l'exemple de politique, la AWS région est`us-east-2`.
+ `account-id`est le numéro de AWS compte du cluster d' de base de données. Dans l'exemple de stratégie, le numéro de compte est `1234567890`. L'utilisateur doit figurer dans le même compte que le compte du cluster de base de données.
Pour bénéficier d'un accès intercompte, créez un rôle IAM avec la politique décrite ci-dessus dans le compte du cluster de base de données et autorisez votre autre compte à endosser ce rôle.
+ `DbClusterResourceId` correspond à l'identifiant du cluster de base de données. Cet identifiant est propre à une AWS région et ne change jamais. Dans cet exemple de stratégie, l'identifiant est `cluster-ABCDEFGHIJKL01234`.
Pour trouver un ID de ressource de cluster d' de base de AWS Management Console données dans Amazon Aurora, choisissez le cluster d' de base de données pour en voir les détails. Choisissez ensuite l'onglet **Configuration**. L'**ID de ressource** est indiqué dans la section **Configuration**.
Vous pouvez également utiliser la AWS CLI commande pour répertorier les identifiants et les ressources IDs de l'ensemble de votre cluster d' de base de données dans la AWS région actuelle, comme indiqué ci-dessous.
```
aws rds describe-db-clusters --query "DBClusters[*].[DBClusterIdentifier,DbClusterResourceId]"
```
**Note**
Si vous vous connectez à une base de données via le proxy RDS, spécifiez l'ID de ressource de proxy, par exemple `prx-ABCDEFGHIJKL01234`. Pour plus d'informations sur l'utilisation de l'authentification de base de données IAM avec le proxy RDS, consultez [Connexion à une base de données à l'aide de l'authentification IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
+ `db-user-name` correspond au nom du compte de base de données à associer à l'authentification IAM. Dans cet exemple de stratégie, le compte de la base de données est `db_user`.
Vous pouvez en créer d'autres ARNs pour prendre en charge différents modèles d'accès. La stratégie suivante permet d'accéder à deux comptes de base de données différents dans un cluster de base de données.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/jane_doe",
"arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/mary_roe"
]
}
]
}
```
------
La politique suivante utilise le caractère « \$1 » pour faire correspondre tous les clusters d' de base de données et les comptes de base de données pour un AWS compte et une AWS région spécifiques.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:111122223333:dbuser:*/*"
]
}
]
}
```
------
La politique suivante correspond à tous les clusters d' de base de données pour un AWS compte et une AWS région particuliers. Néanmoins, cette stratégie n'octroie l'accès qu'aux et clusters de bases de données qui ont un compte de base de données `jane_doe`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds-db:connect"
],
"Resource": [
"arn:aws:rds-db:us-east-2:123456789012:dbuser:*/jane_doe"
]
}
]
}
```
------
L'utilisateur ou le rôle a uniquement accès aux bases de données auxquelles l'utilisateur de base de données a accès. Supposons par exemple que votre cluster de base de donnés possède une base de données nommée *dev* et une autre base de données nommée *test*. Si l'utilisateur de base de données `jane_doe` a uniquement accès à *dev*, tous les rôles ou utilisateurs qui accèdent à ce cluster de bases de données avec l'utilisateur `jane_doe` ont aussi uniquement accès à *dev*. Cette restriction d'accès s'applique également aux autres objets de bases de données, tels que les tables, les vues, etc.
Un administrateur doit créer des politiques IAM autorisant les entités à 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 ou aux rôles qui ont besoin de ces autorisations. Pour obtenir des exemples de stratégies, consultez la section [Exemples de politiques basées sur l’identité pour Amazon Aurora](security_iam_id-based-policy-examples.md).
## Attacher une politique IAM à un jeu d'autorisations ou à un rôle
Après avoir créé une politique IAM pour permettre l'authentification d'une base de données, il convient d'attacher la politique à un jeu d'autorisations ou à un rôle. Pour accéder à un didacticiel sur ce sujet, veuillez consulter [Créer et attacher votre première politique gérée par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) dans le *Guide de l'utilisateur IAM*.
Tandis que vous parcourez ce didacticiel, vous pouvez utiliser un exemple de politique illustré dans cette section comme point de départ afin de le personnaliser en fonction de vos besoins. À la fin de ce didacticiel, vous obtenez un jeu d'autorisations avec une politique attachée qui peut utiliser l'action `rds-db:connect`.
**Note**
Vous pouvez mapper plusieurs jeux d'autorisations ou rôles au même compte d'utilisateur de base de données. Supposons par exemple que votre politique IAM a spécifié l'ARN de ressource suivant.
```
arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-12ABC34DEFG5HIJ6KLMNOP78QR/jane_doe
```
Si vous attachez la politique à *Jane*, *Bob* et *Diego*, chacun de ces utilisateurs peut se connecter au cluster de bases de données en utilisant le compte de base de données `jane_doe`.
# Création d’un compte de base de données à l’aide de l’authentification IAM
Avec l’authentification de base de données IAM, vous n’avez pas besoin d’associer de mots de passe de base de données aux comptes d’utilisateurs que vous créez. Si vous supprimez un utilisateur qui est mappé à un compte de base de données, vous devez également supprimer le compte de base de données avec l’instruction `DROP USER`.
**Note**
Le nom d’utilisateur utilisé pour l’authentification IAM doit correspondre à la casse du nom d’utilisateur dans la base de données.
**Topics**
+ [Utilisation de l’authentification IAM avec Aurora MySQL](#UsingWithRDS.IAMDBAuth.DBAccounts.MySQL)
+ [Utilisation de l'authentification IAM avec Aurora PostgreSQL](#UsingWithRDS.IAMDBAuth.DBAccounts.PostgreSQL)
## Utilisation de l’authentification IAM avec Aurora MySQL
Avec et Aurora MySQL, l'authentification est `AWSAuthenticationPlugin` gérée AWS par un plugin fourni qui fonctionne parfaitement avec IAM pour authentifier vos utilisateurs. Connectez-vous au cluster de bases de données en tant qu’utilisateur principal ou autre utilisateur qui peut créer des utilisateurs et accorder des privilèges. Après vous être connecté, exécutez l’instruction `CREATE USER`, comme indiqué dans l’exemple suivant.
```
CREATE USER 'jane_doe' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
```
La clause `IDENTIFIED WITH` permet à Aurora MySQL d’utiliser `AWSAuthenticationPlugin` pour authentifier le compte de base de données (`jane_doe`). La clause `AS 'RDS'` fait référence à la méthode d’authentification. Assurez-vous que le nom d’utilisateur de base de données spécifié est identique à une ressource dans la politique IAM pour l’accès à la base de données IAM. Pour de plus amples informations, veuillez consulter [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md).
**Note**
Si le message suivant s'affiche, cela signifie que le plug-in AWS fourni n'est pas disponible pour le cluster d' de base de données actuel.
`ERROR 1524 (HY000): Plugin 'AWSAuthenticationPlugin' is not loaded`
Pour remédier à cette erreur, vérifiez si vous utilisez une configuration prise en charge et si vous avez activé l’authentification de base de données IAM sur votre cluster de bases de données. Pour plus d’informations, consultez [Disponibilité des régions et des versions](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability) et [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md).
Après avoir créé un compte à l’aide de `AWSAuthenticationPlugin`, vous pouvez le gérer de la même manière que les autres comptes de base de données. Vous pouvez par exemple modifier les privilèges de compte avec `GRANT` et `REVOKE`, ou changer divers attributs de compte avec l’instruction `ALTER USER`.
Le trafic réseau de base de données est crypté SSL/TLS lors de l'utilisation d'IAM. Pour autoriser les connexions SSL, modifiez le compte d’utilisateur à l’aide de la commande suivante.
```
ALTER USER 'jane_doe'@'%' REQUIRE SSL;
```
## Utilisation de l'authentification IAM avec Aurora PostgreSQL
Pour utiliser l’authentification IAM avec Aurora PostgreSQL, connectez-vous au cluster de bases de données en tant qu’utilisateur principal ou autre utilisateur qui peut créer des utilisateurs et accorder des privilèges. Après vous être connecté, créez des utilisateurs de base de données, puis accordez-leur le rôle `rds_iam`, comme indiqué dans l’exemple suivant.
```
CREATE USER db_userx;
GRANT rds_iam TO db_userx;
```
Assurez-vous que le nom d’utilisateur de base de données spécifié est identique à une ressource dans la politique IAM pour l’accès à la base de données IAM. Pour plus d’informations, consultez [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Vous devez accorder le rôle `rds_iam` pour utiliser l’authentification IAM. Vous pouvez également utiliser des appartenances imbriquées ou des octrois indirects du rôle.
Notez qu’un utilisateur de base de données PostgreSQL peut utiliser l’authentification IAM ou Kerberos, mais pas les deux, si bien que cet utilisateur ne peut pas avoir le rôle `rds_ad`. Cela s’applique également aux adhésions imbriquées. Pour plus d’informations, consultez [Étape 7 : Créer des utilisateurs PostgreSQL pour vos principaux Kerberos](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins).
# Connexion à votre cluster de base de données à l'aide de l'authentification IAM.
Avec l'authentification de base de données IAM, vous utilisez un jeton d'identification lors de la connexion à votre cluster de base de données. Un *jeton d'authentification* constitue une chaîne de caractères unique qui remplace un mot de passe. Après avoir été créé, un jeton d'authentification est valable pendant 15 minutes avant d'expirer. Si vous tentez de vous connecter alors que le jeton expiré, la demande de connexion est rejetée.
Chaque jeton d'authentification doit être accompagné d'une signature valide, en utilisant AWS Signature Version 4. (Pour plus d'informations, consultez [Processus de signature Signature version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) dans la *Références générales AWS*.) L'AWS CLI et un kit SDK AWS tel que AWS SDK pour Java ou AWS SDK pour Python (Boto3) peuvent signer automatiquement chaque jeton que vous créez.
Vous pouvez utiliser un jeton d'authentification lorsque vous vous connectez à Amazon Aurora à partir d'un autre service AWS tel que AWS Lambda. L'utilisation d'un jeton vous évite d'avoir à placer un mot de passe dans votre code. Vous pouvez aussi utiliser un kit SDK AWS pour créer et signer un jeton d'authentification par programmation.
Après avoir obtenu un jeton d'authentification IAM signé, vous pouvez vous connecter à un cluster de bases de données Aurora. Utilisez les liens ci-dessous pour savoir comment procéder avec un outil de ligne de commande ou un kit SDK AWS, comme le AWS SDK pour Java ou AWS SDK pour Python (Boto3).
Pour plus d'informations, consultez les billets de blog suivants :
+ [Utilisation de l'authentification IAM pour se connecter avec SQL Workbench/J à Aurora MySQL ou 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/)
+ [Utilisation de l'authentification IAM pour se connecter à PgAdmin Amazon Aurora PostgreSQL ou 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/)
**Prérequis**
Les conditions préalables à la connexion à votre cluster de base de données à l'aide de l'authentification IAM sont les suivantes :
+ [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Création d’un compte de base de données à l’aide de l’authentification IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Topics**
+ [Connexion à votre cluster de bases de données à l’aide de l’authentification IAM avec les pilotes AWS](IAMDBAuth.Connecting.Drivers.md)
+ [Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM à partir de la ligne de commande : AWS CLI et du client MySQL](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.md)
+ [Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM à partir de la ligne de commande : AWS CLI et du client psql](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.PostgreSQL.md)
+ [Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM et du AWS SDK pour .NET](UsingWithRDS.IAMDBAuth.Connecting.NET.md)
+ [Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM et du AWS SDK pour Go](UsingWithRDS.IAMDBAuth.Connecting.Go.md)
+ [Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM et du AWS SDK pour Java](UsingWithRDS.IAMDBAuth.Connecting.Java.md)
+ [Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM et du AWS SDK pour Python (Boto3)](UsingWithRDS.IAMDBAuth.Connecting.Python.md)
# Connexion à votre cluster de bases de données à l’aide de l’authentification IAM avec les pilotes AWS
La suite de pilotes AWS a été conçue pour accélérer les temps de bascule et de basculement, ainsi que pour l’authentification avec AWS Secrets Manager, Gestion des identités et des accès AWS (IAM) et l’identité fédérée. Les pilotes AWS s’appuient sur la surveillance de l’état du cluster de bases de données et sur la connaissance de la topologie du cluster pour déterminer le nouvel enregistreur. Cette approche réduit les temps de bascule et de basculement à moins de 10 secondes, contre des dizaines de secondes pour les pilotes open source.
Pour plus d’informations sur les pilotes AWS, consultez le pilote correspondant au langage utilisé pour votre cluster de bases de données [Aurora MySQL](Aurora.Connecting.md#Aurora.Connecting.JDBCDriverMySQL) ou [Aurora PostgreSQL](Aurora.Connecting.md#Aurora.Connecting.AuroraPostgreSQL.Utilities).
# Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM à partir de la ligne de commande : AWS CLI et du client MySQL
Vous pouvez vous connecter depuis la ligne de commande à un cluster de base de données Aurora d'instance de base de données à l'aide de l'outil de ligne de `mysql` commande AWS CLI et comme décrit ci-dessous.
**Conditions préalables**
Les conditions préalables à la connexion à votre cluster de base de données à l’aide de l’authentification IAM sont les suivantes :
+ [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Création d’un compte de base de données à l’aide de l’authentification IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Note**
Pour plus d'informations sur la connexion à votre base de données à l'aide de SQL Workbench/J avec authentification IAM, consultez le billet de blog [Utiliser l'authentification IAM pour vous connecter avec SQL à Workbench/J Aurora MySQL ou Amazon RDS](https://aws.amazon.com/blogs/database/use-iam-authentication-to-connect-with-sql-workbenchj-to-amazon-aurora-mysql-or-amazon-rds-for-mysql/) for MySQL.
**Topics**
+ [Création d'un jeton d'authentification IAM](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken)
+ [Connexion à votre cluster de bases de données](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect)
## Création d'un jeton d'authentification IAM
L'exemple suivant illustre comment obtenir un jeton d'identification signé à l'aide d 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
```
Dans cet exemple, les paramètres sont les suivants :
+ `--hostname` – Le nom d'hôte du cluster de base de données auquel vous souhaitez accéder.
+ `--port` – Le numéro du port utilisé lors de la connexion au cluster d' de base de données.
+ `--region`— La AWS région dans laquelle le cluster d' de base de données est exécuté
+ `--username` – Le compte de base de données auquel vous souhaitez accéder.
Les premiers caractères du jeton ressemblent à l'exemple suivant.
```
rdsmysql.123456789012.us-west-2.rds.amazonaws.com:3306/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
```
**Note**
Vous ne pouvez pas utiliser un enregistrement DNS Route 53 personnalisé à la place du point de terminaison du cluster de bases de données pour générer le jeton d’authentification.
## Connexion à votre cluster de bases de données
Le format général de connexion est illustré ci-dessous.
```
mysql --host=hostName --port=portNumber --ssl-ca=full_path_to_ssl_certificate --enable-cleartext-plugin --user=userName --password=authToken
```
Les paramètres sont les suivants :
+ `--host` – Le nom d'hôte du cluster de base de données auquel vous souhaitez accéder.
+ `--port` – Le numéro du port utilisé lors de la connexion au cluster d' de base de données.
+ `--ssl-ca` – Le chemin d'accès complet vers le fichier de certificat SSL contenant la clé publique.
Pour de plus amples informations, veuillez consulter [Connexions TLS aux clusters de bases de données Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL).
Pour télécharger un certificat SSL, consultez [Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md).
+ `--enable-cleartext-plugin` – Une valeur qui spécifie que `AWSAuthenticationPlugin` doit être utilisé pour cette connexion.
Si vous utilisez un client MariaDB, l'option `--enable-cleartext-plugin` n'est pas requise.
+ `--user` – Le compte de base de données auquel vous souhaitez accéder.
+ `--password` – Un jeton d'authentification IAM signé.
Le jeton d'authentification est composé de plusieurs centaines de caractères. Il peut être encombrant sur la ligne de commande. Pour contourner ce problème, vous pouvez enregistrer le jeton dans une variable d'environnement, puis utiliser cette variable pour la connexion. L'exemple suivant illustre une manière de contourner ce problème. Dans l'exemple, */sample\$1dir/* il s'agit du chemin complet du fichier de certificat SSL contenant la clé publique.
```
RDSHOST="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
TOKEN="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 3306 --region us-west-2 --username jane_doe )"
mysql --host=$RDSHOST --port=3306 --ssl-ca=/sample_dir/global-bundle.pem --enable-cleartext-plugin --user=jane_doe --password=$TOKEN
```
Lorsque vous vous connectez avec `AWSAuthenticationPlugin`, la connexion est sécurisée par SSL. Pour le vérifier, tapez la commande suivante à l'invite de commande `mysql>`.
```
show status like 'Ssl%';
```
Les lignes suivantes de l'affichage obtenu fournissent plus de détails.
```
+---------------+-------------+
| Variable_name | Value |
+---------------+-------------+
| ... | ...
| Ssl_cipher | AES256-SHA |
| ... | ...
| Ssl_version | TLSv1.1 |
| ... | ...
+-----------------------------+
```
Si vous souhaitez vous connecter à un cluster de bases de données via un proxy, consultez [Connexion à une base de données à l'aide de l'authentification IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM à partir de la ligne de commande : AWS CLI et du client psql
À partir de la ligne de commande, vous pouvez vous connecter à une cluster de base de données Aurora PostgreSQL avec AWS CLI l'outil de ligne de commande psql comme décrit ci-après.
**Conditions préalables**
Les conditions préalables à la connexion à votre cluster de base de données à l’aide de l’authentification IAM sont les suivantes :
+ [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Création d’un compte de base de données à l’aide de l’authentification IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Note**
Pour plus d'informations sur la connexion à votre base de données à l'aide de pgAdmin avec authentification IAM, consultez le billet de blog [Utilisation de l'authentification IAM pour se connecter à PgAdmin Amazon Aurora PostgreSQL ou 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**
+ [Création d'un jeton d'authentification IAM](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken.PostgreSQL)
+ [Connexion à une un cluster Aurora PostgreSQL](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect.PostgreSQL)
## Création d'un jeton d'authentification IAM
Le jeton d'authentification se compose de plusieurs centaines de caractères ; il peut donc être complexe à manipuler sur la ligne de commande. Pour contourner ce problème, vous pouvez enregistrer le jeton dans une variable d'environnement, puis utiliser cette variable pour la connexion. L'exemple suivant montre comment utiliser le pour AWS CLI obtenir un jeton d'authentification signé à l'aide de la `generate-db-auth-token` commande et le stocker dans une variable d'`PGPASSWORD`environnement.
```
export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )"
```
Dans cet exemple, les paramètres de la commande `generate-db-auth-token` sont les suivants :
+ `--hostname` – Nom d'hôte de l'du cluster (point de terminaison du cluster) de base de données auquel vous souhaitez accéder.
+ `--port` – Le numéro du port utilisé lors de la connexion au cluster d' de base de données.
+ `--region`— La AWS région dans laquelle le cluster d' de base de données est exécuté
+ `--username` – Le compte de base de données auquel vous souhaitez accéder.
Les premiers caractères du jeton généré ressemblent à l'exemple suivant.
```
mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com:5432/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900...
```
**Note**
Vous ne pouvez pas utiliser un enregistrement DNS Route 53 personnalisé à la place du point de terminaison du cluster de bases de données pour générer le jeton d’authentification.
## Connexion à une un cluster Aurora PostgreSQL
Le format général pour utiliser psql pour la connexion est illustré ci-dessous.
```
psql "host=hostName port=portNumber sslmode=verify-full sslrootcert=full_path_to_ssl_certificate dbname=DBName user=userName password=authToken"
```
Les paramètres sont les suivants :
+ `host` – Nom d'hôte de l'du cluster (point de terminaison du cluster) de base de données auquel vous souhaitez accéder.
+ `port` – Le numéro du port utilisé lors de la connexion au cluster d' de base de données.
+ `sslmode` – Le mode SSL à utiliser.
Lorsque vous utilisez `sslmode=verify-full`, la connexion SSL vérifie le point de terminaison de l'cluster de base de données par rapport au point de terminaison dans le certificat SSL.
+ `sslrootcert` – Le chemin d'accès complet vers le fichier de certificat SSL contenant la clé publique.
Pour de plus amples informations, veuillez consulter [Sécurisation des données Aurora PostgreSQL avec SSL/TLS](AuroraPostgreSQL.Security.md#AuroraPostgreSQL.Security.SSL).
Pour télécharger un certificat SSL, consultez [Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md).
+ `dbname` – La base de données à laquelle vous souhaitez accéder.
+ `user` – Le compte de base de données auquel vous souhaitez accéder.
+ `password` – Un jeton d'authentification IAM signé.
**Note**
Vous ne pouvez pas utiliser un enregistrement DNS Route 53 personnalisé à la place du point de terminaison du cluster de bases de données pour générer le jeton d’authentification.
L'exemple suivant montre l'utilisation de psql pour se connecter. Dans cet exemple, psql utilise la variable d'environnement `RDSHOST` pour l'hôte et la variable d'environnement `PGPASSWORD` pour le jeton généré. Il s'*/sample\$1dir/*agit également du chemin complet vers le fichier de certificat SSL contenant la clé publique.
```
export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com"
export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )"
psql "host=$RDSHOST port=5432 sslmode=verify-full sslrootcert=/sample_dir/global-bundle.pem dbname=DBName user=jane_doe password=$PGPASSWORD"
```
Si vous souhaitez vous connecter à un cluster de bases de données via un proxy, consultez [Connexion à une base de données à l'aide de l'authentification IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM et du AWS SDK pour .NET
Vous pouvez vous connecter à une instance de base de données en procédant comme décrit ci-dessous. AWS SDK pour .NET
**Conditions préalables**
Les conditions préalables à la connexion à votre cluster de base de données à l’aide de l’authentification IAM sont les suivantes :
+ [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Création d’un compte de base de données à l’aide de l’authentification IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Exemples**
Les exemples de code suivants montre comment générer un jeton d'authentification, puis comment l'utiliser pour se connecter à un cluster de base de données.
Pour exécuter cet exemple de code, vous avez besoin du [AWS SDK pour .NET](https://aws.amazon.com/sdk-for-net/), qui se trouve sur le AWS site. Les paquets `AWSSDK.CORE` et `AWSSDK.RDS` sont requis. Pour vous connecter à un cluster d' de base de données, utilisez le connecteur de base de données .NET pour le moteur de base de données, par exemple MySqlConnector pour MariaDB ou MySQL, ou Npgsql pour PostgreSQL.
Ce code se connecte à un cluster de base de données Aurora MySQL. Modifiez la valeur des variables suivantes selon les besoins :
+ `server` – Le point de terminaison de cluster de base de données à laquelle vous souhaitez accéder.
+ `user` – Le compte de base de données auquel vous souhaitez accéder.
+ `database` – La base de données à laquelle vous souhaitez accéder.
+ `port` – Le numéro du port utilisé lors de la connexion au cluster d' de base de données.
+ `SslMode` – Le mode SSL à utiliser.
Lorsque vous utilisez `SslMode=Required`, la connexion SSL vérifie le point de terminaison de l'cluster de base de données par rapport au point de terminaison dans le certificat SSL.
+ `SslCa` – Le chemin d'accès complet au certificat SSL pour Amazon Aurora
Pour télécharger un certificat, consultez [Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md).
**Note**
Vous ne pouvez pas utiliser un enregistrement DNS Route 53 personnalisé à la place du point de terminaison du cluster de bases de données pour générer le jeton d’authentification.
```
using System;
using System.Data;
using MySql.Data;
using MySql.Data.MySqlClient;
using Amazon;
namespace ubuntu
{
class Program
{
static void Main(string[] args)
{
var pwd = Amazon.RDS.Util.RDSAuthTokenGenerator.GenerateAuthToken(RegionEndpoint.USEast1, "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 3306, "jane_doe");
// for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated
MySqlConnection conn = new MySqlConnection($"server=mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com;user=jane_doe;database=mydB;port=3306;password={pwd};SslMode=Required;SslCa=full_path_to_ssl_certificate");
conn.Open();
// Define a query
MySqlCommand sampleCommand = new MySqlCommand("SHOW DATABASES;", conn);
// Execute a query
MySqlDataReader mysqlDataRdr = sampleCommand.ExecuteReader();
// Read all rows and output the first column in each row
while (mysqlDataRdr.Read())
Console.WriteLine(mysqlDataRdr[0]);
mysqlDataRdr.Close();
// Close connection
conn.Close();
}
}
}
```
Ce code se connecte à un cluster de base de données Aurora PostgreSQL.
Modifiez la valeur des variables suivantes selon les besoins :
+ `Server` – Le point de terminaison de cluster de base de données à laquelle vous souhaitez accéder.
+ `User ID` – Le compte de base de données auquel vous souhaitez accéder.
+ `Database` – La base de données à laquelle vous souhaitez accéder.
+ `Port` – Le numéro du port utilisé lors de la connexion au cluster d' de base de données.
+ `SSL Mode` – Le mode SSL à utiliser.
Lorsque vous utilisez `SSL Mode=Required`, la connexion SSL vérifie le point de terminaison de l'cluster de base de données par rapport au point de terminaison dans le certificat SSL.
+ `Root Certificate` – Le chemin d'accès complet au certificat SSL pour Amazon Aurora
Pour télécharger un certificat, consultez [Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md).
**Note**
Vous ne pouvez pas utiliser un enregistrement DNS Route 53 personnalisé à la place du point de terminaison du cluster de bases de données pour générer le jeton d’authentification.
```
using System;
using Npgsql;
using Amazon.RDS.Util;
namespace ConsoleApp1
{
class Program
{
static void Main(string[] args)
{
var pwd = RDSAuthTokenGenerator.GenerateAuthToken("postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 5432, "jane_doe");
// for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated
NpgsqlConnection conn = new NpgsqlConnection($"Server=postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com;User Id=jane_doe;Password={pwd};Database=mydb;SSL Mode=Require;Root Certificate=full_path_to_ssl_certificate");
conn.Open();
// Define a query
NpgsqlCommand cmd = new NpgsqlCommand("select count(*) FROM pg_user", conn);
// Execute a query
NpgsqlDataReader dr = cmd.ExecuteReader();
// Read all rows and output the first column in each row
while (dr.Read())
Console.Write("{0}\n", dr[0]);
// Close connection
conn.Close();
}
}
}
```
Si vous souhaitez vous connecter à un cluster de bases de données via un proxy, consultez [Connexion à une base de données à l'aide de l'authentification IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM et du AWS SDK pour Go
Vous pouvez vous connecter à une instance de base de données en procédant comme décrit ci-dessous. AWS SDK pour Go
**Conditions préalables**
Les conditions préalables à la connexion à votre cluster de base de données à l’aide de l’authentification IAM sont les suivantes :
+ [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Création d’un compte de base de données à l’aide de l’authentification IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
**Exemples**
Pour exécuter ces exemples de code, vous avez besoin du [AWS SDK pour Go](https://aws.amazon.com/sdk-for-go/), disponible sur le AWS site.
Modifiez la valeur des variables suivantes selon les besoins :
+ `dbName` – La base de données à laquelle vous souhaitez accéder.
+ `dbUser` – Le compte de base de données auquel vous souhaitez accéder.
+ `dbHost` – Le point de terminaison de cluster de base de données à laquelle vous souhaitez accéder.
**Note**
Vous ne pouvez pas utiliser un enregistrement DNS Route 53 personnalisé à la place du point de terminaison du cluster de bases de données pour générer le jeton d’authentification.
+ `dbPort` – Le numéro du port utilisé lors de la connexion au cluster d' de base de données.
+ `region`— La AWS région dans laquelle le cluster d' de base de données est exécuté
En outre, assurez-vous que les bibliothèques importées dans l'exemple de code existent sur votre système.
**Important**
Les exemples de cette section utilisent le code suivant pour fournir des informations d'identification qui accèdent à une base de données à partir d'un environnement local :
`creds := credentials.NewEnvCredentials()`
Si vous accédez à une base de données depuis un AWS service, tel qu'Amazon EC2 ou Amazon ECS, vous pouvez remplacer le code par le code suivant :
`sess := session.Must(session.NewSession())`
`creds := sess.Config.Credentials`
Si vous effectuez cette modification, assurez-vous d'ajouter l'importation suivante :
`"github.com/aws/aws-sdk-go/aws/session"`
**Topics**
+ [Connexion à l'aide de l'authentification IAM et de la V2 AWS SDK pour Go](#UsingWithRDS.IAMDBAuth.Connecting.GoV2)
+ [Connexion à l'aide de l'authentification IAM et de la AWS SDK pour Go V1.](#UsingWithRDS.IAMDBAuth.Connecting.GoV1)
## Connexion à l'aide de l'authentification IAM et de la V2 AWS SDK pour Go
Vous pouvez vous connecter à un cluster d' de base de données à l'aide de l'authentification IAM et de la AWS SDK pour Go V2.
Les exemples de code suivants montre comment générer un jeton d'authentification, puis comment l'utiliser pour se connecter à un cluster de base de données.
Ce code se connecte à un cluster de base de données Aurora MySQL.
```
package main
import (
"context"
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/go-sql-driver/mysql"
)
func main() {
var dbName string = "DatabaseName"
var dbUser string = "DatabaseUser"
var dbHost string = "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
var dbPort int = 3306
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = "us-east-1"
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authenticationToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Ce code se connecte à un cluster de base de données Aurora PostgreSQL.
```
package main
import (
"context"
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/feature/rds/auth"
_ "github.com/lib/pq"
)
func main() {
var dbName string = "DatabaseName"
var dbUser string = "DatabaseUser"
var dbHost string = "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
var dbPort int = 5432
var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort)
var region string = "us-east-1"
cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
panic("configuration error: " + err.Error())
}
authenticationToken, err := auth.BuildAuthToken(
context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials)
if err != nil {
panic("failed to create authentication token: " + err.Error())
}
dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s",
dbHost, dbPort, dbUser, authenticationToken, dbName,
)
db, err := sql.Open("postgres", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Si vous souhaitez vous connecter à un cluster de bases de données via un proxy, consultez [Connexion à une base de données à l'aide de l'authentification IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
## Connexion à l'aide de l'authentification IAM et de la AWS SDK pour Go V1.
Vous pouvez vous connecter à un cluster d' de base de données à l'aide de l'authentification IAM et du V1 AWS SDK pour Go
Les exemples de code suivants montre comment générer un jeton d'authentification, puis comment l'utiliser pour se connecter à un cluster de base de données.
Ce code se connecte à un cluster de base de données Aurora MySQL.
```
package main
import (
"database/sql"
"fmt"
"log"
"github.com/aws/aws-sdk-go/aws/credentials"
"github.com/aws/aws-sdk-go/service/rds/rdsutils"
_ "github.com/go-sql-driver/mysql"
)
func main() {
dbName := "app"
dbUser := "jane_doe"
dbHost := "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
dbPort := 3306
dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort)
region := "us-east-1"
creds := credentials.NewEnvCredentials()
authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds)
if err != nil {
panic(err)
}
dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true",
dbUser, authToken, dbEndpoint, dbName,
)
db, err := sql.Open("mysql", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Ce code se connecte à un cluster de base de données Aurora PostgreSQL.
```
package main
import (
"database/sql"
"fmt"
"github.com/aws/aws-sdk-go/aws/credentials"
"github.com/aws/aws-sdk-go/service/rds/rdsutils"
_ "github.com/lib/pq"
)
func main() {
dbName := "app"
dbUser := "jane_doe"
dbHost := "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
dbPort := 5432
dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort)
region := "us-east-1"
creds := credentials.NewEnvCredentials()
authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds)
if err != nil {
panic(err)
}
dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s",
dbHost, dbPort, dbUser, authToken, dbName,
)
db, err := sql.Open("postgres", dsn)
if err != nil {
panic(err)
}
err = db.Ping()
if err != nil {
panic(err)
}
}
```
Si vous souhaitez vous connecter à un cluster de bases de données via un proxy, consultez [Connexion à une base de données à l'aide de l'authentification IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM et du AWS SDK pour Java
Vous pouvez vous connecter à une instance de base de données en procédant comme décrit ci-dessous. AWS SDK pour Java
**Conditions préalables**
Les conditions préalables à la connexion à votre cluster de base de données à l’aide de l’authentification IAM sont les suivantes :
+ [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Création d’un compte de base de données à l’aide de l’authentification IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
+ [Configuration du AWS SDK pour Java](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-install.html)
Pour des exemples d’utilisation du kit SDK pour Java 2.x, consultez [Exemples Amazon RDS utilisant le kit SDK pour Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java_rds_code_examples.html). Vous pouvez également utiliser l' AWS Advanced JDBC Wrapper, voir la documentation [AWS Advanced JDBC](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/Documentation.md) Wrapper.
**Topics**
+ [Création d’un jeton d’authentification IAM](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken)
+ [Construction manuelle d’un jeton d’authentification IAM](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken2)
+ [Connexion à votre cluster de bases de données](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken.Connect)
## Création d’un jeton d’authentification IAM
Si vous écrivez des programmes à l'aide de AWS SDK pour Java, vous pouvez obtenir un jeton d'authentification signé à l'aide de la `RdsIamAuthTokenGenerator` classe. L'utilisation de cette classe nécessite que vous fournissiez des AWS informations d'identification. Pour ce faire, vous devez créer une instance de la `DefaultAWSCredentialsProviderChain` classe. `DefaultAWSCredentialsProviderChain`utilise la première clé AWS d'accès et la première clé secrète qu'il trouve dans la [chaîne de fournisseurs d'informations d'identification par défaut](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default). Pour plus d’informations sur les clés d’accès AWS , consultez [Gestion des clés d’accès pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html).
**Note**
Vous ne pouvez pas utiliser un enregistrement DNS Route 53 personnalisé à la place du point de terminaison du cluster de bases de données pour générer le jeton d’authentification.
Après avoir créé une instance de `RdsIamAuthTokenGenerator`, vous pouvez appeler la méthode `getAuthToken` pour obtenir un jeton signé. Fournissez la région AWS , le nom d’hôte, le numéro de port et le nom d’utilisateur. L’exemple de code suivant montre comment procéder.
```
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;
}
}
```
## Construction manuelle d’un jeton d’authentification IAM
Dans Java, la manière la plus facile de créer un jeton d’authentification est d’utiliser `RdsIamAuthTokenGenerator`. Cette classe crée un jeton d'authentification pour vous, puis le signe à l'aide de AWS la version de signature 4. Pour plus d’informations, consultez [Processus de signature Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) dans le *Références générales AWS*.
Vous pouvez néanmoins aussi construire et signer un jeton d’authentification manuellement, comme indiqué dans l’exemple de code suivant.
```
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);
}
}
}
```
## Connexion à votre cluster de bases de données
L’exemple de code suivant montre comment créer un jeton d’authentification, puis comment l’utiliser pour se connecter à un cluster exécutant Aurora MySQL.
Pour exécuter cet exemple de code, vous avez besoin du [AWS SDK pour Java](https://aws.amazon.com/sdk-for-java/), qui se trouve sur le AWS site. En outre, vous avez besoin des éléments suivants :
+ MySQL Connector/J. Cet exemple de code a été testé avec `mysql-connector-java-5.1.33-bin.jar`.
+ Certificat intermédiaire pour (Amazon Aurora) spécifique à une AWS région. (Pour plus d’informations, consultez [Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md).) À l’exécution, le chargeur de classe recherche le certificat dans le même annuaire que celui de cet exemple de code Java, afin de pouvoir le trouver.
+ Modifiez la valeur des variables suivantes selon les besoins :
+ `RDS_INSTANCE_HOSTNAME` : le nom d’hôte du cluster de bases de données auquel vous souhaitez accéder.
+ `RDS_INSTANCE_PORT` : le numéro du port utilisé pour la connexion à votre cluster de bases de données PostgreSQL.
+ `REGION_NAME`— La AWS région dans laquelle le cluster d' de base de données est exécuté.
+ `DB_USER` – Le compte de base de données auquel vous souhaitez accéder.
+ `SSL_CERTIFICATE`— Un certificat SSL pour Amazon Aurora spécifique à une AWS région.
Pour télécharger un certificat pour votre région AWS , consultez [Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md). Placez le certificat SSL dans le même annuaire que ce fichier de programme Java, afin que le chargeur de classe puisse le trouver à l’exécution.
Cet exemple de code permet d'obtenir des AWS informations d'identification à partir de la chaîne de [fournisseurs d'informations d'identification par défaut](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default).
**Note**
Spécifiez un mot de passe pour `DEFAULT_KEY_STORE_PASSWORD` différent de celui indiqué ici, en tant que bonne pratique de sécurité.
```
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");
}
}
```
Si vous souhaitez vous connecter à un cluster de bases de données via un proxy, consultez [Connexion à une base de données à l'aide de l'authentification IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Connexion à votre cluster d' de base de données à l'aide de l'authentification IAM et du AWS SDK pour Python (Boto3)
Vous pouvez vous connecter à une instance de base de données en procédant comme décrit ci-dessous. AWS SDK pour Python (Boto3)
**Conditions préalables**
Les conditions préalables à la connexion à votre cluster de base de données à l’aide de l’authentification IAM sont les suivantes :
+ [Activation et désactivation de l’authentification de base de données IAM](UsingWithRDS.IAMDBAuth.Enabling.md)
+ [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md)
+ [Création d’un compte de base de données à l’aide de l’authentification IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md)
En outre, assurez-vous que les bibliothèques importées dans l'exemple de code existent sur votre système.
**Exemples**
Les exemples de code utilisent des profils pour les informations d'identification partagées. Pour plus d'informations sur la spécification des informations d'identification, consultez la section [Informations d'identification](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html) dans la AWS SDK pour Python (Boto3) documentation.
Les exemples de code suivants montre comment générer un jeton d'authentification, puis comment l'utiliser pour se connecter à un cluster de base de données.
Pour exécuter cet exemple de code, vous avez besoin du [AWS SDK pour Python (Boto3)](https://aws.amazon.com/sdk-for-python/), qui se trouve sur le AWS site.
Modifiez la valeur des variables suivantes selon les besoins :
+ `ENDPOINT` – Le point de terminaison de cluster de base de données à laquelle vous souhaitez accéder.
+ `PORT` – Le numéro du port utilisé lors de la connexion au cluster d' de base de données.
+ `USER` – Le compte de base de données auquel vous souhaitez accéder.
+ `REGION`— La AWS région dans laquelle le cluster d' de base de données est exécuté
+ `DBNAME` – La base de données à laquelle vous souhaitez accéder.
+ `SSLCERTIFICATE` – Le chemin d'accès complet au certificat SSL pour Amazon Aurora
Pour `ssl_ca`, spécifiez un certificat SSL. Pour télécharger un certificat SSL, consultez [Utilisation SSL/TLS pour chiffrer une connexion à une de clusters](UsingWithRDS.SSL.md).
**Note**
Vous ne pouvez pas utiliser un enregistrement DNS Route 53 personnalisé à la place du point de terminaison du cluster de bases de données pour générer le jeton d’authentification.
Ce code se connecte à un cluster de base de données Aurora MySQL.
Avant d'exécuter ce code, installez le pilote PyMy SQL en suivant les instructions du [Python Package Index](https://pypi.org/project/PyMySQL/).
```
import pymysql
import sys
import boto3
import os
ENDPOINT="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
PORT="3306"
USER="jane_doe"
REGION="us-east-1"
DBNAME="mydb"
os.environ['LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN'] = '1'
#gets the credentials from .aws/credentials
session = boto3.Session(profile_name='default')
client = session.client('rds')
token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION)
try:
conn = pymysql.connect(auth_plugin_map={'mysql_clear_password':None},host=ENDPOINT, user=USER, password=token, port=PORT, database=DBNAME, ssl_ca='SSLCERTIFICATE', ssl_verify_identity=True, ssl_verify_cert=True)
cur = conn.cursor()
cur.execute("""SELECT now()""")
query_results = cur.fetchall()
print(query_results)
except Exception as e:
print("Database connection failed due to {}".format(e))
```
Ce code se connecte à un cluster de base de données Aurora PostgreSQL.
Avant d'exécuter ce code, installez `psycopg2` en suivant les instructions de la documentation de [Psycopg](https://pypi.org/project/psycopg2/).
```
import psycopg2
import sys
import boto3
import os
ENDPOINT="postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com"
PORT="5432"
USER="jane_doe"
REGION="us-east-1"
DBNAME="mydb"
#gets the credentials from .aws/credentials
session = boto3.Session(profile_name='RDSCreds')
client = session.client('rds')
token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION)
try:
conn = psycopg2.connect(host=ENDPOINT, port=PORT, database=DBNAME, user=USER, password=token, sslrootcert="SSLCERTIFICATE")
cur = conn.cursor()
cur.execute("""SELECT now()""")
query_results = cur.fetchall()
print(query_results)
except Exception as e:
print("Database connection failed due to {}".format(e))
```
Si vous souhaitez vous connecter à un cluster de bases de données via un proxy, consultez [Connexion à une base de données à l'aide de l'authentification IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam).
# Résolution des problèmes liés à l’authentification de base de données IAM
Vous trouverez ci-dessous des idées de dépannage pour certains problèmes courants liés à l’authentification de base de données IAM, ainsi que des informations sur les journaux CloudWatch pour l’authentification de base de données IAM.
## Exportation des journaux d’erreurs d’authentification de base de données IAM vers CloudWatch Logs
Les journaux des erreurs d’authentification de base de données IAM sont stockés sur l’hôte de la base de données, et vous pouvez les exporter vers votre compte CloudWatch Logs. Utilisez les journaux et les méthodes de correction de cette page pour résoudre les problèmes liés à l’authentification de base de données IAM.
Vous pouvez activer les exportations de journaux vers CloudWatch Logs à partir de la console AWS CLI et de l’API RDS. Pour des instructions sur l’utilisation de la console, consultez [Publication des journaux de base de données dans Amazon CloudWatch Logs](USER_LogAccess.Procedural.UploadtoCloudWatch.md).
Pour exporter vos journaux d’erreurs d’authentification de base de données IAM vers CloudWatch Logs lors de la création d’un cluster de bases de données à partir du AWS CLI, utilisez la commande suivante :
```
aws rds create-db-cluster --db-cluster-identifier mydbinstance \
--region us-east-1 \
--engine postgres \
--engine-version 16 \
--master-username master \
--master-user-password password \
--publicly-accessible \
--enable-iam-database-authentication \
--enable-cloudwatch-logs-exports=iam-db-auth-error
```
Pour exporter vos journaux d’erreurs d’authentification de base de données IAM vers CloudWatch Logs lors de la modification d’un cluster de bases de données à partir du AWS CLI, utilisez la commande suivante :
```
aws rds modify-db-cluster --db-cluster-identifier mydbcluster \
--region us-east-1 \
--cloudwatch-logs-export-configuration '{"EnableLogTypes":["iam-db-auth-error"]}'
```
Pour vérifier si votre cluster de bases de données exporte les journaux d’authentification de base de données IAM vers CloudWatch Logs, vérifiez si le paramètre `EnabledCloudwatchLogsExports` est défini sur `iam-db-auth-error` dans la sortie de la commande `describe-db-instances`.
```
aws rds describe-db-cluster --region us-east-1 --db-cluster-identifier mydbcluster
...
"EnabledCloudwatchLogsExports": [
"iam-db-auth-error"
],
...
```
## Métriques CloudWatch pour l’authentification de base de données IAM
Amazon Aurora fournit des statistiques en temps quasi réel concernant l’authentification de base de données IAM sur votre compte Amazon CloudWatch. Le tableau suivant répertorie les métriques d’authentification de base de données IAM disponibles avec CloudWatch :
| Métrique | Description |
| --- | --- |
| `IamDbAuthConnectionRequests` | Nombre total de demandes de connexion effectuées avec l’authentification de base de données IAM. |
| `IamDbAuthConnectionSuccess` | Nombre total de demandes d’authentification de base de données IAM réussies. |
| `IamDbAuthConnectionFailure` | Nombre total de demandes d’authentification de base de données IAM ayant échoué. |
| `IamDbAuthConnectionFailureInvalidToken` | Nombre total de demandes d’authentification de base de données IAM ayant échoué à cause d’un jeton non valide. |
| `IamDbAuthConnectionFailureInsufficientPermissions` | Nombre total de demandes d’authentification de base de données IAM ayant échoué en raison de politiques ou d’autorisations incorrectes. |
| `IamDbAuthConnectionFailureThrottling` | Nombre total de demandes d’authentification de base de données IAM ayant échoué en raison de la limitation de l’authentification de base de données IAM. |
| `IamDbAuthConnectionFailureServerError` | Nombre total de demandes d’authentification de base de données IAM ayant échoué en raison d’une erreur interne du serveur dans la fonctionnalité d’authentification de base de données IAM. |
## Problèmes courants et solutions correspondantes
Vous pouvez rencontrer les problèmes suivants lors de l’utilisation de l’authentification de base de données IAM. Suivez les étapes de correction indiquées dans le tableau pour résoudre les problèmes :
| Erreur | Métrique(s) | Cause | Solution |
| --- | --- | --- | --- |
| `[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` | Le jeton d’authentification de base de données IAM figurant dans la demande de connexion n’est pas un jeton SigV4a valide ou il n’est pas formaté correctement. | Vérifiez votre stratégie de génération de jetons dans votre application. Dans certains cas, assurez-vous de transmettre le jeton avec un formatage valide. Le fait de tronquer le jeton (ou un formatage de chaîne incorrect) le rend non valide. |
| `[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` | Le jeton d’authentification de base de données IAM a expiré. Les jetons ne sont valides que pendant 15 minutes. | Vérifiez votre logique de mise en cache et/ou de réutilisation des jetons dans votre application. Vous ne devez pas réutiliser des jetons datant de plus de 15 minutes. |
| `[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` | Cette erreur peut être due aux raisons suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Troubleshooting.html) | Vérifiez que vous assumez le rôle et/ou la politique IAM dans votre application. Assurez-vous de suivre la même politique pour générer le jeton que pour vous connecter à la base de données. |
| `[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` | Vous envoyez trop de demandes de connexion à votre base de données en peu de temps. La limite de limitation de l’authentification IAM DB est de 200 connexions par seconde. | Réduisez le taux d’établissement de nouvelles connexions grâce à l’authentification IAM. Envisagez d’implémenter le regroupement de connexions à l’aide du proxy RDS afin de réutiliser les connexions établies dans votre application. |
| `[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` | Une erreur interne s’est produite lors de l’autorisation de la connexion à la base de données avec l’authentification de base de données IAM. | Contactez https://aws.amazon.com/premiumsupport/ pour enquêter sur le problème. |
# Résolution des problèmes liés à Identity and Access Amazon Aurora
Utilisez les informations suivantes pour identifier et résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec Aurora et IAM.
**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans Aurora](#security_iam_troubleshoot-no-permissions)
+ [Je ne suis pas autorisé à effectuer iam : PassRole](#security_iam_troubleshoot-passrole)
+ [Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder à mes ressources Aurora](#security_iam_troubleshoot-cross-account-access)
## Je ne suis pas autorisé à effectuer une action dans Aurora
S'il vous AWS Management Console indique que vous n'êtes pas autorisé à effectuer une action, vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui vous a fourni vos informations de connexion.
L'exemple d'erreur suivant se produit lorsque l'`mateojackson`utilisateur essaie d'utiliser la console pour afficher les détails d'un *widget* mais ne dispose pas des `rds:GetWidget` autorisations nécessaires.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: rds:GetWidget on resource: my-example-widget
```
Dans ce cas, Mateo demande à son administrateur de mettre à jour ses politiques pour lui permettre d’accéder à la ressource `my-example-widget` à l’aide de l’action `rds:GetWidget`.
## Je ne suis pas autorisé à effectuer iam : PassRole
Si vous recevez un message d'erreur selon lequel vous n'êtes pas autorisé à exécuter l'action `iam:PassRole`, vous devez contacter votre administrateur pour obtenir de l'aide. Votre administrateur est la personne qui vous a fourni vos informations de connexion. Demandez à cette personne de mettre à jour vos stratégies pour vous permettre de transmettre un rôle à Aurora.
Certains AWS services vous permettent de transmettre un rôle existant à ce service, au lieu de créer un nouveau rôle de service ou un rôle lié à un service. Pour ce faire, vous devez disposer des autorisations nécessaires pour transmettre le rôle au service.
L'exemple d'erreur suivant se produit lorsqu'un utilisateur nommé `marymajor` essaie d'utiliser la console pour exécuter une action dans Aurora. Toutefois, l'action nécessite que le service ait des autorisations accordées par une fonction du service. Mary ne dispose pas des autorisations nécessaires pour transférer le rôle au service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Dans ce cas, Mary demande à son administrateur de mettre à jour ses politiques pour lui permettre d'exécuter l'action `iam:PassRole`.
## Je souhaite autoriser des personnes extérieures à mon AWS compte à accéder à mes ressources Aurora
Vous pouvez créer un rôle que les utilisateurs provenant d’autres comptes ou les personnes extérieures à votre organisation pourront utiliser pour accéder à vos ressources. Vous pouvez spécifier qui est autorisé à assumer le rôle. Pour les services qui prennent en charge les politiques basées sur les ressources ou les listes de contrôle d'accès (ACLs), vous pouvez utiliser ces politiques pour autoriser les utilisateurs à accéder à vos ressources.
Pour plus d’informations, consultez les éléments suivants :
+ Pour savoir si Aurora prend en charge ces fonctionnalités, consultez [Comment Amazon Aurora fonctionne avec IAM](security_iam_service-with-iam.md).
+ Pour savoir comment fournir un accès à vos ressources sur les AWS comptes que vous possédez, consultez la section [Fournir un accès à un utilisateur IAM sur un autre AWS compte que vous possédez](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) dans le Guide de l'*utilisateur IAM*.
+ Pour savoir comment fournir l'accès à vos ressources à des AWS comptes tiers, consultez la section [Fournir un accès aux AWS comptes détenus par des tiers](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) dans le *guide de l'utilisateur IAM*.
+ Pour savoir comment fournir un accès par le biais de la fédération d’identité, consultez [Fournir un accès à des utilisateurs authentifiés en externe (fédération d’identité)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) dans le *Guide de l’utilisateur IAM*.
+ Pour découvrir quelle est la différence entre l’utilisation des rôles et l’utilisation des politiques basées sur les ressources pour l’accès entre comptes, consultez [Différence entre les rôles IAM et les politiques basées sur les ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) dans le *Guide de l’utilisateur IAM*.
# Journalisation et surveillance dans )
La surveillance joue un rôle important dans le maintien de la fiabilité, de la disponibilité et des performances d', d'Amazon Aurora et de vos AWS solutions. Vous devez collecter des données de surveillance provenant de toutes les parties de votre AWS solution afin de pouvoir corriger plus facilement une défaillance multipoint, le cas échéant. AWS fournit plusieurs outils pour surveiller vos ressources Amazon Aurora et répondre aux incidents potentiels :
** CloudWatch Alarmes Amazon**
À l'aide des CloudWatch alarmes Amazon, vous observez une seule métrique sur une période que vous spécifiez. Si la métrique dépasse un seuil donné, une notification est envoyée à une rubrique ou AWS Auto Scaling à une politique Amazon SNS. CloudWatch les alarmes n'appellent pas d'actions car elles se trouvent dans un état particulier. L’état doit avoir changé et avoir été conservé pendant un nombre de périodes spécifié.
**AWS CloudTrail Journaux**
CloudTrail fournit un enregistrement des actions entreprises par un utilisateur, un rôle ou un AWS service dans Amazon Aurora. CloudTrail capture tous les appels d'API pour Amazon Aurora sous forme d'événements, y compris les appels depuis la console et les appels de code vers les opérations d'API Amazon RDS. À l'aide des informations collectées par CloudTrail, vous pouvez déterminer la demande envoyée à Aurora, l'adresse IP à partir de laquelle la demande a été faite, l'auteur de la demande, la date à laquelle elle a été faite, ainsi que des informations supplémentaires. Pour plus d’informations, consultez [Surveillance des appels d'API Amazon Aurora dansAWS CloudTrail](logging-using-cloudtrail.md).
**Surveillance améliorée**
Amazon Aurora fournit des métriques en temps réel pour le système d’exploitation sur lequel votre cluster de bases de données s’exécute. Vous pouvez consulter les métriques de votre cluster d' de base de données à l'aide de la console ou utiliser la sortie JSON Enhanced Monitoring d'Amazon CloudWatch Logs dans le système de surveillance de votre choix. Pour plus d’informations, consultez [Surveillance des métriques du système d’exploitation à l’aide de la Surveillance améliorée](USER_Monitoring.OS.md).
**Analyse des performances d’Amazon RDS**
Performance Insights complète les fonctions de surveillance existantes sur Amazon Aurora. Ce service illustre les performances de votre base de données et facilite votre analyse des problèmes qui les impactent. Grâce au tableau de bord de Performance Insights, vous pouvez visualiser la charge de la base de données et la filtrer par attentes, instructions SQL, hôtes ou utilisateurs. Pour plus d’informations, consultez [Surveillance de la charge de la base de données avec Performance Insights sur ](USER_PerfInsights.md).
**Journaux de base de données**
Vous pouvez consulter, télécharger et consulter les journaux de base de données à l'aide de l'API AWS Management Console AWS CLI, ou RDS. Pour plus d’informations, consultez [Surveillance des fichiers journaux Amazon Aurora](USER_LogAccess.md).
** Recommandations Amazon Aurora**
Amazon Aurora fournit des recommandations automatisées pour les ressources de base de données. Ces recommandations offrent des conseils quand aux bonnes pratiques en analysant la configuration du cluster de bases de données, son utilisation et les données relatives à ses performances. Pour plus d’informations, consultez [Recommandations d’Amazon Aurora](monitoring-recommendations.md).
** Notification d’événement Amazon Aurora**
Amazon Aurora utilise Amazon Simple Notification Service (Amazon SNS) pour fournir une notification lorsqu’un événement Amazon Aurora se produit. Ces notifications peuvent se présenter sous n'importe quel format de notification pris en charge par Amazon SNS pour une AWS région, tel qu'un e-mail, un SMS ou un appel vers un point de terminaison HTTP. Pour plus d’informations, consultez [Utiliser la notification d’événements d’Amazon RDS](USER_Events.md).
**AWS Trusted Advisor**
Trusted Advisor s'appuie sur les meilleures pratiques apprises en servant des centaines de milliers de AWS clients. Trusted Advisor inspecte votre AWS environnement, puis émet des recommandations lorsque des opportunités se présentent pour économiser de l'argent, améliorer la disponibilité et les performances du système ou contribuer à combler les failles de sécurité. Tous les AWS clients ont accès à cinq Trusted Advisor chèques. Les clients disposant d'un plan de support Business ou Enterprise peuvent consulter tous les Trusted Advisor chèques.
Trusted Advisor possède les vérifications suivantes relatives à et Amazon Aurora :
+ Instances de base de données Amazon Aurora inactives
+ Risque lié à l’accès aux groupes de sécurité Amazon Aurora
+ Sauvegardes Amazon Aurora
+ Multi-AZ Amazon Aurora
+ Aurora Accessibilité d’instance de base de données
Pour plus d’informations sur ces vérifications, consultez [Bonnes pratiques Trusted Advisor (Checks)](https://aws.amazon.com/premiumsupport/trustedadvisor/best-practices/).
**Flux d’activité de base de données.**
Pour les flux d’activité de base de données protègent vos bases de données contre les menaces internes en contrôlant l’accès des DBA aux flux d’activité de base de données. Ainsi, la collecte, la transmission, le stockage et le traitement ultérieur du flux d'activité de la base de données ne sont pas accessibles aux personnes DBAs qui gèrent la base de données. Les flux d’activité de base de données peuvent vous permettre de fournir des protections à votre bases de données et de satisfaire les exigences en matière de conformité et de règlementation. Pour plus d’informations, consultez [Surveillance d’Amazon Aurora à l’aide des flux d’activité de base de données](DBActivityStreams.md).
Pour plus d’informations concernant la surveillance Aurora, consultez [Surveillance des métriques d’un cluster de bases de données Amazon Aurora](MonitoringAurora.md).
# Validation de la conformité pour Amazon Aurora
Des auditeurs tiers évaluent la sécurité et la conformité d'Amazon Aurora dans le cadre de plusieurs programmes de conformité AWS. Il s’agit notamment des certifications SOC, PCI, FedRAMP, HIPAA et d’autres.
Pour une liste des AWS services concernés par des programmes de conformité spécifiques, voir [AWSServices concernés par programme de conformité](https://aws.amazon.com/compliance/services-in-scope/). Pour obtenir des informations générales, veuillez consulter [Programmes de conformité d’AWS](https://aws.amazon.com/compliance/programs/).
Vous pouvez télécharger des rapports d'audit tiers à l'aide deAWS Artifact. Pour plus d'informations, consultez la section [Téléchargement de rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Lorsque vous utilisez Aurora, votre responsabilité en matière de conformité est déterminée par la sensibilité de vos données, les objectifs de conformité de votre organisation et les lois et réglementations applicables. AWSfournit les ressources suivantes pour faciliter la mise en conformité :
+ [Guides de démarrage rapide sur la sécurité et la conformité](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) : ces guides de déploiement abordent les considérations architecturales et indiquent les étapes à suivre pour déployer des environnements de base axés sur la sécurité et la conformité sur. AWS
+ [Architecture axée sur la sécurité et la conformité HIPAA sur 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) : ce livre blanc décrit comment les entreprises peuvent créer des applications AWS conformes à la loi HIPAA.
+ [AWSressources de conformité](https://aws.amazon.com/compliance/resources/) : collection de classeurs et de guides susceptibles de s'appliquer à votre secteur d'activité et à votre région.
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)— Ce AWS service évalue dans quelle mesure les configurations de vos ressources sont conformes aux pratiques internes, aux directives du secteur et aux réglementations.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Cela Service AWS fournit une vue complète de votre état de sécurité interneAWS. Security Hub CSPM utilise des contrôles de sécurité pour évaluer vos AWS ressources et vérifier votre conformité aux normes et aux meilleures pratiques du secteur de la sécurité. Pour obtenir la liste des services et des contrôles pris en charge, consultez [la référence des contrôles Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html).
# Résilience dans Amazon Aurora
L'infrastructure mondiale d'AWS s'articule autours de régions et de zones de disponibilité AWS.AWS Les régions fournissent plusieurs zones de disponibilité physiquement séparées et isolées, reliées par un réseau à latence faible, à haut débit et hautement redondant. Avec les zones de disponibilité, vous pouvez concevoir et exploiter des applications et des bases de données qui basculent automatiquement d’une zone de disponibilité à l’autre sans interruption. Les zones de disponibilité sont plus hautement disponibles, tolérantes aux pannes et évolutives que les infrastructures traditionnelles à un ou plusieurs centres de données.
Pour plus d'informations sur les régions et les zones de disponibilité AWS, veuillez consulter [Infrastructure mondiale AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
Outre l'infrastructure globale d'AWS, Aurora offrent différentes fonctions qui contribuent à satisfaire vos besoins en matière de résilience et de sauvegarde de données.
## Sauvegarde et restauration
Aurora sauvegarde automatiquement votre volume de cluster et conserve les données de restauration pendant la totalité de la *période de rétention des sauvegardes*. Les sauvegardes Aurora étant continues et incrémentielles, vous pouvez rapidement opérer une restauration à un point quelconque de la période de rétention des sauvegardes. Aucun impact sur les performances ou interruption du service de base de données ne se produit lors de l'écriture des données de sauvegarde. Vous pouvez spécifier une période de rétention des sauvegardes, comprise entre 1 et 35 jours, lorsque vous créez ou modifiez un cluster de base de données.
Si vous souhaitez conserver une sauvegarde au-delà de la période de rétention, vous pouvez aussi prendre un instantané des données dans votre volume de cluster. Aurora conserve les données des restaurations incrémentielles pendant la totalité de la période de rétention des sauvegardes. Par conséquent, vous avez uniquement besoin de créer un instantané pour les données que vous souhaitez garder au-delà de la période de rétention des sauvegardes. Vous pouvez créer un nouveau cluster de base de données à partir de l'instantané.
Vous pouvez récupérer vos données en créant un cluster de bases de données Aurora à partir des données de sauvegarde qu'Aurora conserve ou d'un instantané de cluster de bases de données que vous avez enregistré. Vous pouvez créer rapidement une nouvelle copie d'un cluster de bases de données à partir des données de sauvegarde à un point quelconque de la période de rétention des sauvegardes. La nature continue et incrémentielle des sauvegardes Aurora pendant la période de rétention signifie que vous n'avez pas besoin de prendre fréquemment des instantanés de vos données pour pouvoir améliorer les temps de restauration.
Pour plus d'informations, consultez [Sauvegarde et restauration d’un cluster de bases de données Amazon Aurora](BackupRestoreAurora.md).
## Réplication
Les réplicas Aurora sont les points de terminaison indépendants d'un cluster de bases de données Aurora, utilisés de préférence pour le dimensionnement des opérations de lecture et l'augmentation de la disponibilité. Le nombre de réplicas Aurora pouvant être distribués entre les zones de disponibilité que couvre un cluster de bases de données au sein d'une région AWS est limité à 15. Le volume de cluster de bases de données est composé de plusieurs copies des données du cluster de bases de données. Cependant, les données du volume de cluster sont représentées comme un seul volume logique à l'instance principale en écriture et aux réplicas Aurora du cluster de bases de données. En d'autres termes, si l'instance principale est défaillante, un réplica Aurora peut être promu comme l'instance de base de données principale.
Aurora prend aussi en charge les options de réplication qui sont spécifiques à Aurora MySQL et Aurora PostgreSQL.
Pour plus d'informations, consultez [Réplication avec Amazon Aurora](Aurora.Replication.md).
## Basculement
Aurora stocke les copies des données d'un cluster de base de données dans plusieurs zones de disponibilité d'une même région AWS. Le stockage se produit indépendamment du fait que les instances de base de données du cluster de base de données recouvrent ou pas plusieurs zones de disponibilité. Lorsque vous créez des réplicas Aurora sur plusieurs zones de disponibilité, Aurora les alloue et les gère automatiquement de manière synchrone. L'instance de base de données principale est répliquée de manière synchrone entre les zones de disponibilité sur des réplicas Aurora de façon à assurer une redondance des données, à éliminer les blocages d'I/O et à réduire les pics de latence pendant les sauvegardes du système. L'exécution d'un cluster de base de données avec la haute disponibilité peut améliorer la disponibilité pendant la maintenance planifiée du système et contribuer à protéger vos bases de données contre toute défaillance ou perturbation d'une zone de disponibilité.
Pour de plus amples informations, consultez [Haute disponibilité pour Amazon Aurora](Concepts.AuroraHighAvailability.md).
# Sécurité de l'infrastructure dans Amazon Aurora
En tant que service géré, Amazon Relational Database Service est protégé AWS par la sécurité du réseau mondial. Pour plus d'informations sur les services AWS de sécurité et sur la manière dont AWS l'infrastructure est protégée, consultez la section [Sécurité du AWS cloud](https://aws.amazon.com/security/). Pour concevoir votre AWS environnement en utilisant les meilleures pratiques en matière de sécurité de l'infrastructure, consultez la section [Protection de l'infrastructure](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) dans le cadre * AWS bien architecturé du pilier de sécurité*.
Vous utilisez des appels d'API AWS publiés pour accéder à Amazon RDS via le réseau. Les clients doivent prendre en charge les éléments suivants :
+ Protocole TLS (Transport Layer Security). Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Ses suites de chiffrement PFS (Perfect Forward Secrecy) comme DHE (Ephemeral Diffie-Hellman) ou ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La plupart des systèmes modernes tels que Java 7 et les versions ultérieures prennent en charge ces modes.
En outre, Aurora offre des fonctions pour contribuer à prendre en charge la sécurité de l'infrastructure.
## Groupes de sécurité
Les groupes de sécurité contrôlent l'accès dont dispose le trafic entrant et sortant d'un cluster de base de données. Par défaut, l'accès au réseau est désactivé sur un cluster de base de données. Vous pouvez spécifier des règles dans un groupe de sécurité qui autorisent l’accès depuis une plage d’adresses IP, un port ou un groupe de sécurité. Une fois les règles de trafic entrant configurées, les mêmes règles s'appliquent à tou(te)s les clusters de base de données qui sont associé(e)s à ce groupe de sécurité.
Pour de plus amples informations, veuillez consulter [Contrôle d’accès par groupe de sécurité](Overview.RDSSecurityGroups.md).
## Accessible publiquement
Lorsque vous lancez une instance de base de données à l'intérieur d'un VPC basé sur le service Amazon VPC, vous pouvez activer ou désactiver l'accessibilité publique pour cette instance de base de données. Pour définir si l'instance de base de données que vous créez comporte un nom DNS qui se résout en une adresse IP publique, vous utilisez le paramètre *Public accessibility* (Accessibilité publique). Ce paramètre vous permet de définir s'il existe un accès publique à l'instance de base de données. Vous pouvez modifier une instance de base de données pour activer ou désactiver l'accessibilité publique en modifiant le paramètre *Public accessibility* (Accessibilité publique).
Pour de plus amples informations, veuillez consulter [Masquer un cluster de bases de données dans un VPC depuis Internet](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding).
**Note**
Si votre instance de base de données se trouve dans un VPC mais n'est pas accessible au public, vous pouvez également utiliser une connexion AWS Site-to-Site VPN ou une Direct Connect connexion pour y accéder depuis un réseau privé. Pour de plus amples informations, veuillez consulter [Confidentialité du trafic inter-réseau](inter-network-traffic-privacy.md).
# API Amazon RDS et points de terminaison d'un VPC d'interface (AWS PrivateLink)
Vous pouvez établir une connexion privée entre votre VPC et vos points de terminaison d'API Amazon RDS en créant un *point de terminaison de VPC d'interface*. Les points de terminaison d'interface sont alimentés par [AWS PrivateLink](https://aws.amazon.com/privatelink).
AWS PrivateLink vous permet d'accéder en privé aux opérations de l'API Amazon RDS sans passerelle Internet, appareil NAT, connexion VPN ou Direct Connect connexion. Les instances de base de données de votre VPC n'ont pas besoin d'adresses IP publiques pour communiquer avec les points de terminaison d'API Amazon RDS for lancer, modifier ou mettre fin à des instances et des clusters de base de données. Vos instances de base de données n'ont pas non plus besoin d'adresses IP publiques pour utiliser une des opérations d'API RDS disponibles. Le trafic entre votre VPC et Amazon RDS ne quitte pas le réseau Amazon.
Chaque point de terminaison d'interface est représenté par une ou plusieurs interfaces réseau Elastic dans vos sous-réseaux. Pour plus d'informations sur les interfaces réseau Elastic, veuillez consulter [Interfaces réseau Elastic](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) dans le *Guide de l'utilisateur Amazon EC2.*
Pour plus d'informations sur les points de terminaison d'un VPC, consultez [Points de terminaison de VPC d'interface (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) dans le *Guide de l'utilisateur Amazon VPC*. Pour plus d'informations sur les opérations d'API RDS, consultez [Référence d'API Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/).
Vous n'avez pas besoin d'un point de terminaison VPC d'interface pour vous connecter à un(e) cluster de base de données. Pour de plus amples informations, veuillez consulter [Scénarios d’accès à un cluster de bases de données d’un VPC](USER_VPC.Scenarios.md).
## Considérations relatives aux points de terminaison d'un VPC
Avant de configurer un point de terminaison d'un VPC d'interface pour les points de terminaison d'API Amazon RDS, assurez-vous de vérifier les [propriétés et limitations du point de terminaison d'interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations) dans le *Amazon VPC Guide de l'utilisateur*.
Toutes les opérations d'API RDS pertinentes pour gestion de ressources Amazon Aurora sont disponibles à partir de votre VPC à l'aide d' AWS PrivateLink.
Les politiques de point de terminaison d'un VPC sont prises en charge pour les points de terminaison de l'API RDS. Par défaut, l'accès complet aux opérations de l'API RDS est autorisé via le point de terminaison. Pour plus d'informations, veuillez consulter [Contrôle de l'accès aux services avec points de terminaison d'un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) dans le *Amazon VPC Guide de l'utilisateur*.
## Disponibilité
L'API Amazon RDS prend actuellement en charge les points de terminaison VPC dans les régions suivantes : AWS
+ USA Est (Ohio)
+ USA Est (Virginie du Nord)
+ USA Ouest (Californie du Nord)
+ USA Ouest (Oregon)
+ Afrique (Le Cap)
+ Asie-Pacifique (Hong Kong)
+ Asie-Pacifique (Mumbai)
+ Asie-Pacifique (Nouvelle Zélande)
+ Asie-Pacifique (Osaka)
+ Asia Pacific (Seoul)
+ Asie-Pacifique (Singapour)
+ Asie-Pacifique (Sydney)
+ Asie-Pacifique (Taipei)
+ Asie-Pacifique (Thaïlande)
+ Asie-Pacifique (Tokyo)
+ Canada (Centre)
+ Canada Ouest (Calgary)
+ Chine (Pékin)
+ China (Ningxia)
+ Europe (Francfort)
+ Europe (Zurich)
+ Europe (Irlande)
+ Europe (Londres)
+ Europe (Paris)
+ Europe (Stockholm)
+ Europe (Milan)
+ Israël (Tel Aviv)
+ Mexique (Centre)
+ Middle East (Bahrain)
+ Amérique du Sud (São Paulo)
+ AWS GovCloud (USA Est)
+ AWS GovCloud (US-Ouest)
## Création d'un point de terminaison de VPC d'interface pour l'API Amazon RDS
Vous pouvez créer un point de terminaison VPC pour l'API Amazon RDS à l'aide de la console Amazon VPC ou du (). AWS Command Line Interface AWS CLI Pour plus d’informations, consultez [Création d’un point de terminaison d’interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint) dans le *Guide de l’utilisateur Amazon VPC*.
Créez un point de terminaison de VPC pour l'API Amazon RDS à l'aide du nom de service `com.amazonaws.region.rds`.
À l'exception des AWS régions de Chine, si vous activez le DNS privé pour le point de terminaison, vous pouvez envoyer des demandes d'API à Amazon RDS avec le point de terminaison VPC en utilisant son nom DNS par défaut pour AWS la région, par exemple. `rds.us-east-1.amazonaws.com` Pour les AWS régions de Chine (Pékin) et de Chine (Ningxia), vous pouvez effectuer des demandes d'API avec le point de terminaison VPC `rds-api---cn-north-1.amazonaws.com.rproxy.goskope.com.cn` en utilisant `rds-api---cn-northwest-1.amazonaws.com.rproxy.goskope.com.cn` et, respectivement.
Pour plus d’informations, consultez [Accès à un service via un point de terminaison d’interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) dans le *Guide de l’utilisateur Amazon VPC*.
## Création d'une politique de point de terminaison de VPC pour l'API Amazon RDS
Vous pouvez attacher une politique de point de terminaison à votre point de terminaison de VPC qui contrôle l'accès à l'API Amazon RDS. La politique spécifie les informations suivantes :
+ Le principal qui peut exécuter des actions.
+ Les actions qui peuvent être effectuées.
+ Les ressources sur lesquelles les actions peuvent être exécutées.
Pour plus d'informations, veuillez consulter [Contrôle de l'accès aux services avec points de terminaison d'un VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) dans le *Amazon VPC Guide de l'utilisateur*.
**Exemple : politique de point de terminaison de VPC pour les actions de l'API Amazon RDS**
Voici un exemple de politique de point de terminaison pour l'API Amazon RDS. Lorsqu'elle est attachée à un point de terminaison, cette politique accorde l'accès aux actions de l'API Amazon RDS répertoriées pour tous les principaux sur toutes les ressources.
```
{
"Statement":[
{
"Principal":"*",
"Effect":"Allow",
"Action":[
"rds:CreateDBInstance",
"rds:ModifyDBInstance",
"rds:CreateDBSnapshot"
],
"Resource":"*"
}
]
}
```
**Exemple : politique de point de terminaison VPC qui refuse tout accès depuis un compte spécifié AWS**
La politique de point de terminaison VPC suivante refuse au AWS compte `123456789012` tout accès aux ressources utilisant le point de terminaison. La politique autorise toutes les actions provenant d’autres comptes.
```
{
"Statement": [
{
"Action": "*",
"Effect": "Allow",
"Resource": "*",
"Principal": "*"
},
{
"Action": "*",
"Effect": "Deny",
"Resource": "*",
"Principal": { "AWS": [ "123456789012" ] }
}
]
}
```
# Bonnes pratiques de sécurité pour )
Utilisez des comptes Gestion des identités et des accès AWS (IAM) pour contrôler l'accès aux opérations de l'API Amazon RDS, en particulier aux opérations qui créent, modifient ou suppriment des ressources . Les ressources de ce type incluent les clusters de bases de données, les groupes de sécurité et les groupes de paramètres. Utilisez également IAM pour contrôler les actions qui effectuent des tâches administratives courantes telles que la sauvegarde et la restauration de clusters de bases de données.
+ Créez un utilisateur pour chaque personne qui gère les ressources Amazon Aurora, y compris vous-même. N'utilisez pas les informations d'identification AWS root pour gérer les ressources Amazon Aurora.
+ Accordez à chaque utilisateur un ensemble minimum d’autorisations requises pour exécuter ses tâches.
+ Utilisez des groupes IAM pour gérer efficacement des autorisations pour plusieurs utilisateurs.
+ Effectuer une rotation régulière des informations d’identification IAM.
+ Configurez AWS Secrets Manager pour alterner automatiquement les secrets pour Amazon Aurora. Pour plus d’informations, consultez [Rotation de vos secrets AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) dans le *Guide de l’utilisateur AWS Secrets Manager *. Vous pouvez également récupérer les informations d'identification par AWS Secrets Manager programmation. Pour plus d’informations, consultez [Récupération de la valeur du secret](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html) dans le *Guide de l’utilisateur AWS Secrets Manager *.
Pour plus d’informations sur la sécurité dans Amazon Aurora, consultez [Sécurité dans )](UsingWithRDS.md). Pour plus d’informations sur IAM, consultez [Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/Welcome.html). Pour plus d’informations sur les bonnes pratiques IAM, consultez [Bonnes pratiques IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html).
AWS Security Hub CSPM utilise des contrôles de sécurité pour évaluer les configurations des ressources et les normes de sécurité afin de vous aider à vous conformer aux différents cadres de conformité. Pour plus d'informations sur l'utilisation de Security Hub CSPM pour évaluer les ressources RDS, consultez les contrôles [Amazon Relational Database Service](https://docs.aws.amazon.com/securityhub/latest/userguide/rds-controls.html) dans le guide de l'utilisateur. AWS Security Hub
Vous pouvez surveiller votre utilisation de RDS en ce qui concerne les meilleures pratiques de sécurité à l'aide de Security Hub CSPM. Pour plus d'informations, voir [Qu'est-ce que c'est AWS Security Hub CSPM ?](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) .
Utilisez l'API AWS Management Console AWS CLI, la ou l'API RDS pour modifier le mot de passe de votre utilisateur principal. Si vous utilisez un autre outil, comme SQL client, pour modifier le mot de passe de l’utilisateur principal, cela pourrait finir par la révocation involontaire des privilèges de l’utilisateur.
Amazon GuardDuty est un service de surveillance continue de la sécurité qui analyse et traite diverses sources de données, y compris l'activité de connexion à Amazon RDS. Il utilise les flux de renseignements sur les menaces et le machine learning pour identifier les activités inattendues, potentiellement non autorisées, de comportement de connexion suspect et malveillantes dans votre environnement AWS .
Lorsqu'Amazon GuardDuty RDS Protection détecte une tentative de connexion potentiellement suspecte ou anormale indiquant une menace pour votre base de données, GuardDuty génère un nouveau résultat contenant des informations sur la base de données potentiellement compromise. Pour plus d’informations, consultez [Surveillance des menaces avec Amazon GuardDuty RDS Protection pour Amazon Aurora](guard-duty-rds-protection.md).
# Contrôle d’accès par groupe de sécurité
Les groupes de sécurité du VPC contrôlent l’accès dont dispose le trafic entrant et sortant d’ un cluster.de bases de données. Par défaut, l’accès au réseau est désactivé pour un cluster de bases de données. Vous pouvez spécifier des règles dans un groupe de sécurité qui autorisent l’accès depuis une plage d’adresses IP, un port ou un groupe de sécurité. Une fois les règles de trafic entrant configurées, les mêmes règles s’appliquent à tous les clusters de bases de données qui sont associés à ce groupe de sécurité. Vous pouvez spécifier jusqu’à 20 règles dans un groupe de sécurité.
## Présentation des groupes de sécurité VPC
Chaque règle de groupe de sécurité VPC permet à une source spécifique d’accéder à un cluster de bases de données dans un VPC associé à ce groupe de sécurité VPC. Cette source peut être une plage d’adresses (par exemple, 203.0.113.0/24) ou un autre groupe de sécurité VPC. En spécifiant un groupe de sécurité VPC en tant que source, vous autorisez le trafic entrant provenant de toutes les instances (généralement les serveurs d’application) qui utilisent le groupe de sécurité VPC source. Les groupes de sécurité du VPC peuvent avoir des règles qui régissent à la fois le trafic entrant et sortant. Cependant, les règles de trafic sortant ne s’appliquent généralement pas aux clusters de bases de données. Les règles de trafic sortant ne s’appliquent que si le cluster de bases de données fait office de client. Vous devez utiliser l’[API Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Welcome.html) ou l’option **Security Group** (Groupe de sécurité) de la console VPC pour créer des groupes de sécurité VPC.
Lorsque vous créez des règles pour votre groupe de sécurité VPC pour permettre d’accéder aux clusters dans votre VPC, vous devez spécifier un port pour chaque plage d’adresses à laquelle la règle autorise l’accès. Par exemple, si vous souhaitez activer l’accès Secure Shell (SSH) pour les instances du VPC, créez une règle autorisant l’accès au port TCP 22 pour la plage d’adresses spécifiée.
Vous pouvez configurer plusieurs groupes de sécurité VPC qui permettent d’accéder à des ports différents pour différentes instances dans votre VPC. Par exemple, vous pouvez créer un groupe de sécurité VPC qui autorise l’accès au port TCP 80 pour les serveurs Web de votre VPC. Vous pouvez ensuite créer un autre groupe de sécurité VPC qui autorise l’accès au port TCP 3306 pour les instances de base de données Aurora MySQL de votre VPC.
**Note**
Dans un cluster de bases de données Aurora, le groupe de sécurité VPC associé au cluster de bases de données est également associé à toutes les instances de base de données du cluster de bases de données. Si vous modifiez le groupe de sécurité VPC associé au cluster de base de données ou à une instance de base de données, la modification est automatiquement appliquée à toutes les instances de base de données du cluster de base de données.
Pour plus d’informations sur les groupes de sécurité VPC, consultez [Groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
**Note**
Si votre cluster d' de base de données se trouve dans un VPC mais n'est pas accessible au public, vous pouvez également utiliser une connexion AWS Site-to-Site VPN ou une Direct Connect connexion pour y accéder depuis un réseau privé. Pour plus d’informations, consultez [Confidentialité du trafic inter-réseau](inter-network-traffic-privacy.md).
## Scénario de groupes de sécurité
Une utilisation courante d’un cluster de bases de données dans un VPC consiste à partager les données avec un serveur d’application qui s’exécute dans une instance Amazon EC2 dans le même VPC et auquel accède une application cliente située hors du VPC. Dans ce scénario, vous devez utiliser les pages RDS et VPC ou AWS Management Console les opérations d'API RDS et EC2 pour créer les instances et les groupes de sécurité nécessaires :
1. Créez un groupe de sécurité VPC (par exemple, `sg-0123ec2example`) et définissez des règles entrantes qui utilisent les adresses IP de l’application cliente comme source. Ce groupe de sécurité autorise votre application cliente à se connecter aux instances EC2 dans un VPC qui utilise ce groupe de sécurité.
1. Créez une instance EC2 pour l’application et ajoutez l’instance EC2 au groupe de sécurité VPC (`sg-0123ec2example`) que vous avez créé à l’étape précédente.
1. Créez un second groupe de sécurité VPC (par exemple, `sg-6789rdsexample`) et créez une nouvelle règle en spécifiant le groupe de sécurité VPC que vous avez créé à l’étape 1 (`sg-0123ec2example`) en tant que source.
1. Créez un cluster de bases de données et ajoutez le cluster de bases de données au groupe de sécurité VPC (`sg-6789rdsexample`) que vous avez créé à l’étape précédente. Lorsque vous créez le cluster de bases de données, utilisez le même numéro de port que celui spécifié pour la règle du groupe de sécurité VPC (`sg-6789rdsexample`) que vous avez créée à l’étape 3.
Le schéma suivant illustre ce scénario.
![\[Cluster de bases de données et instance EC2 dans un VPC\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png)
Pour des instructions détaillées sur la configuration d’un VPC pour ce scénario, consultez [Tutoriel : Création d'un VPC à utiliser avec un cluster d' de base de données (uniquement) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md). Pour plus d’informations sur l’utilisation d’un VPC, consultez [Amazon VPC et Amazon Aurora](USER_VPC.md).
## Création d’un groupe de sécurité VPC
Vous pouvez créer un groupe de sécurité VPC pour une instance de base de données à l’aide de la console VPC. Pour plus d’informations sur la création d’un groupe de sécurité, consultez [Créer un groupe de sécurité qui autorise l’accès au cluster de bases de données dans le VPC](CHAP_SettingUp_Aurora.md#CHAP_SettingUp_Aurora.SecurityGroup) et [Groupes de sécurité](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
## Association d’un groupe de sécurité à un cluster de bases de données
Vous pouvez associer un groupe de sécurité à un cluster de base de données en utilisant **Modify cluster** sur la console RDS, l'API `ModifyDBCluster` Amazon RDS ou la `modify-db-cluster` AWS CLI commande.
L’exemple de commande CLI suivant associe un groupe VPC spécifique et supprime les groupes de sécurité de base de données d’un cluster de bases de données
```
aws rds modify-db-cluster --db-cluster-identifier dbName --vpc-security-group-ids sg-ID
```
Pour plus d’informations sur la modification d’un cluster de bases de données, consultez [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md).
# Privilèges du compte utilisateur principal
Lorsque vous créez un nouveau cluster de bases de données, l’utilisateur principal par défaut que vous utilisez obtient certains privilèges pour ce cluster de bases de données. Vous ne pouvez pas changer le nom de l’utilisateur principal après la création du cluster de bases de données.
**Important**
Nous vous recommandons vivement de ne pas avoir recours au rôle d’utilisateur principal directement dans vos applications. Au lieu de cela, respectez la bonne pratique qui consiste à avoir recours à un utilisateur de base de données doté des privilèges minimum requis pour votre application.
**Note**
Si vous supprimez par mégarde les autorisations de l’utilisateur principal, vous pouvez les restaurer en modifiant le cluster de bases de données et en définissant un nouveau mot de passe d’utilisateur principal. Pour plus d’informations sur la modification d’un cluster de bases de données, consultez [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md).
Le tableau suivant montre les privilèges et les rôles de base de données que l’utilisateur principal obtient pour chacun des moteurs de base de données.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html)
# Utilisation des rôles liés à un service pour Amazon Aurora
Amazon Aurora utilise des rôles liés à un [service Gestion des identités et des accès AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Un rôle lié à un service est un type unique de rôle IAM lié directement à Amazon Aurora. Les rôles liés à un service sont prédéfinis par (Amazon Aurora) et incluent toutes les autorisations requises par le service pour appeler d'autres AWS services en votre nom.
Un rôle lié à un service simplifie l’utilisation d’Amazon Aurora, car vous n’avez pas besoin d’ajouter manuellement les autorisations requises. Amazon Aurora définit les autorisations de ses rôles liés à un service et, sauf définition contraire, seul Amazon Aurora peut endosser ses rôles. Les autorisations définies comprennent la politique d’approbation et la politique d’autorisation. De plus, cette politique d’autorisation ne peut pas être attachée à une autre entité IAM.
Vous pouvez supprimer les rôles uniquement après la suppression préalable de leurs ressources connexes. Vos ressources Amazon Aurora sont ainsi protégées, car vous ne pouvez pas involontairement supprimer l’autorisation d’accéder aux ressources.
Pour plus d'informations sur les autres services qui prennent en charge les rôles liés à un service, veuillez consulter [Services AWS qui fonctionnent IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services avec un **Yes** (Oui) dans la colonne **Service-Linked Role** (Rôle lié à un service). Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.
## Autorisations des rôles liés à un service pour Amazon Aurora
Le rôle lié à un service AWSService RoleFor RDS fait confiance aux services suivants pour assumer le rôle :
+ `rds.amazonaws.com`
Ce rôle lié à un service est associé à une politique appelée `AmazonRDSServiceRolePolicy` qui lui accorde l’autorisation d’opérer dans votre compte.
Pour plus d'informations sur cette politique, y compris le document de politique JSON, consultez [Amazon RDSService RolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSServiceRolePolicy.html) dans le *AWS Managed Policy Reference Guide*.
**Note**
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, groupe ou rôle) de créer, modifier ou supprimer un rôle lié à un service. Si vous rencontrez le message d’erreur suivant :
**Impossible de créer la ressource. Vérifiez que vous détenez l’autorisation de créer un rôle lié au service. Dans le cas contraire, attendez et réessayez ultérieurement.**
Vérifiez que les autorisations suivantes sont activées :
```
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"rds.amazonaws.com"
}
}
}
```
Pour plus d’informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.
### Création d’un rôle lié à un service pour Amazon Aurora
Vous n’avez pas besoin de créer manuellement un rôle lié à un service. Lorsque vous créez un cluster de bases de données, Amazon Aurora crée le rôle lié à un service pour vous.
**Important**
Si vous utilisiez le service Amazon Aurora avant le 1er décembre 2017, date à laquelle il a commencé à prendre en charge les rôles liés au service, Amazon RDS Aurora a créé AWSService RoleFor le rôle RDS dans votre compte. Pour en savoir plus, consultez l'[article Un nouveau rôle est apparu dans mon AWS compte](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared).
Si vous supprimez ce rôle lié à un service et que vous avez ensuite besoin de le recréer, vous pouvez utiliser la même procédure pour recréer le rôle dans votre compte. Lorsque vous créez une un cluster de bases de données, Amazon Aurora crée de nouveau le rôle lié à un service pour vous.
### Modification d’un rôle lié à un service pour Amazon Aurora
Amazon Aurora ne vous permet pas de modifier le rôle lié au service AWSService RoleFor RDS. Après avoir créé un rôle lié à un service, vous ne pouvez pas changer le nom du rôle, car plusieurs entités peuvent faire référence à ce rôle. Néanmoins, vous pouvez modifier la description du rôle à l’aide d’IAM. Pour plus d’informations, consultez [Modification d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dans le *Guide de l’utilisateur IAM*.
### Suppression d’un rôle lié à un service pour Amazon Aurora
Si vous n’avez plus besoin d’utiliser une fonction ou un service qui nécessite un rôle lié à un service, nous vous recommandons de supprimer ce rôle. De cette façon, vous n’avez aucune entité inutilisée qui n’est pas surveillée ou gérée activement. Cependant, vous devez supprimer toutes vos et clusters de bases de données avant de pouvoir supprimer le rôle lié à un service.
#### Nettoyage d’un rôle lié à un service
Avant de pouvoir utiliser IAM pour supprimer un rôle lié à un service, vous devez d’abord vérifier qu’aucune session n’est active pour le rôle et supprimer toutes les ressources utilisées par le rôle.
**Pour vérifier si une session est active pour le rôle lié à un service dans la console IAM**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)l'adresse.
1. Dans le panneau de navigation de la console IAM, choisissez **Rôles**. Choisissez ensuite le nom (et non la case à cocher) du rôle AWSService RoleFor RDS.
1. Sur la page **Récapitulatif** du rôle sélectionné, choisissez l’onglet **Dernier accès**.
1. Dans l’onglet **Dernier accès**, consultez l’activité récente pour le rôle lié à un service.
**Note**
Si vous ne savez pas si Amazon Aurora utilise le rôle AWSService RoleFor RDS, vous pouvez essayer de le supprimer. Si le service utilise le rôle, la suppression échoue et vous avez accès aux régions AWS dans lesquelles le rôle est utilisé. Si le rôle est utilisé, vous devez attendre que la session se termine avant de pouvoir le supprimer. Vous ne pouvez pas révoquer la session d’un rôle lié à un service.
Si vous souhaitez supprimer le rôle AWSService RoleFor RDS, vous devez d'abord supprimer *tous* vos clusters d' de base de données.
##### Suppression de tous vos clusters
Utilisez l’une des procédures suivantes pour supprimer un seul cluster. Répétez la procédure pour chacun de vos clusters.
**Pour supprimer un cluster (console)**
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans la liste **Bases de données**, choisissez le cluster que vous souhaitez supprimer.
1. Pour **Cluster Actions (Actions de cluster)**, choisissez **Delete (Supprimer)**.
1. Sélectionnez **Delete**.
**Pour supprimer un cluster (CLI)**
Consultez `[delete-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster.html)` dans la *Référence de commande AWS CLI *.
**Pour supprimer un cluster (API)**
Consultez `[DeleteDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html)` dans le *Amazon RDS API Reference*.
Vous pouvez utiliser la console IAM, la CLI IAM ou l'API IAM pour supprimer le rôle lié au service AWSService RoleFor RDS. Pour plus d’informations, consultez [Suppression d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) dans le *Guide de l’utilisateur IAM*.
## Autorisations du rôle lié à un service pour Amazon RDS bêta
Amazon Aurora utilise le rôle lié au service nommé pour `AWSServiceRoleForRDSBeta` permettre à Amazon RDS Aurora d' AWS appeler des services au nom de vos ressources de base de données RDS.
Le rôle AWSService RoleFor RDSBeta lié à un service fait confiance aux services suivants pour assumer le rôle :
+ `rds.amazonaws.com`
Ce rôle lié à un service est associé à une politique appelée `AmazonRDSBetaServiceRolePolicy` qui lui accorde l’autorisation d’opérer dans votre compte. Pour plus d’informations, consultez [AWS politique gérée : Amazon RDSBeta ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy).
**Note**
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Si vous rencontrez le message d’erreur suivant :
**Impossible de créer la ressource. Vérifiez que vous détenez l’autorisation de créer un rôle lié au service. Dans le cas contraire, attendez et réessayez ultérieurement.**
Vérifiez que les autorisations suivantes sont activées :
```
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/custom.rds.amazonaws.com/AmazonRDSBetaServiceRolePolicy",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"custom.rds.amazonaws.com"
}
}
}
```
Pour plus d’informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.
## Rôles liés à un service pour Amazon RDS Preview
Amazon Aurora utilise le rôle lié au service nommé pour `AWSServiceRoleForRDSPreview` permettre à Amazon RDS Aurora d' AWS appeler des services au nom de vos ressources de base de données RDS.
Le rôle AWSService RoleFor RDSPreview lié à un service fait confiance aux services suivants pour assumer le rôle :
+ `rds.amazonaws.com`
Ce rôle lié à un service est associé à une politique appelée `AmazonRDSPreviewServiceRolePolicy` qui lui accorde l’autorisation d’opérer dans votre compte. Pour plus d’informations, consultez [AWS politique gérée : Amazon RDSPreview ServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy).
**Note**
Vous devez configurer les autorisations de manière à permettre à une entité IAM (comme un utilisateur, un groupe ou un rôle) de créer, modifier ou supprimer un rôle lié à un service. Si vous rencontrez le message d’erreur suivant :
**Impossible de créer la ressource. Vérifiez que vous détenez l’autorisation de créer un rôle lié au service. Dans le cas contraire, attendez et réessayez ultérieurement.**
Vérifiez que les autorisations suivantes sont activées :
```
{
"Action": "iam:CreateServiceLinkedRole",
"Effect": "Allow",
"Resource": "arn:aws:iam::*:role/aws-service-role/custom.rds.amazonaws.com/AmazonRDSPreviewServiceRolePolicy",
"Condition": {
"StringLike": {
"iam:AWSServiceName":"custom.rds.amazonaws.com"
}
}
}
```
Pour plus d’informations, consultez [Autorisations de rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) dans le *Guide de l’utilisateur IAM*.
# Amazon VPC et Amazon Aurora
Amazon Virtual Private Cloud (Amazon VPC) vous permet de lancer des ressources AWS, telles que des clusters de base de données Aurora, dans un cloud privé virtuel (VPC).
Lorsque vous utilisez un VPC, vous disposez d’un contrôle total sur l’environnement de réseau virtuel. Vous pouvez choisir votre propre plage d’adresses IP, créer des sous-réseaux et configurer le routage et les listes de contrôle d’accès. Il n’y a pas de frais supplémentaires pour exécuter votre cluster de bases de données dans un VPC.
Les comptes disposent d’un VPC par défaut. Tou(te)s les nouveaux clusters de base de données sont créées dans le VPC par défaut, à moins que vous ne spécifiez une autre option.
**Topics**
+ [Utilisation d’un cluster de bases de données dans un VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md)
+ [Scénarios d’accès à un cluster de bases de données d’un VPC](USER_VPC.Scenarios.md)
+ [Tutoriel : Création d'un VPC à utiliser avec un cluster d' de base de données (uniquement) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md)
+ [Tutoriel : Créer un VPC à utiliser avec un cluster de bases de données (mode double-pile)](CHAP_Tutorials.CreateVPCDualStack.md)
Vous trouverez ci-dessous une discussion sur la fonctionnalité VPC pertinente pour les clusters de base de données Amazon Aurora. Pour plus d’informations sur Amazon VPC, consultez le [Guide de mise en route Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/) et le [Guide de l’utilisateur Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
# Utilisation d’un cluster de bases de données dans un VPC
Votre cluster de bases de données se trouve dans un cloud privé virtuel (VPC). Un VPC est un réseau virtuel isolé logiquement des autres réseaux virtuels du cloud. AWS Amazon VPC vous permet de lancer des AWS ressources, telles qu'un cluster d'instances de base de données Amazon Aurora ou une Amazon EC2, dans un VPC. Le VPC peut être un VPC par défaut fourni avec votre compte ou un VPC que vous créez. Ils VPCs sont tous associés à votre AWS compte.
Votre VPC par défaut a trois sous-réseaux que vous pouvez utiliser pour isoler les ressources à l’intérieur du VPC. Le VPC par défaut possède aussi une passerelle Internet qui peut être utilisée pour fournir l’accès aux ressources à l’intérieur du VPC depuis l’extérieur du VPC.
Pour obtenir une liste des scénarios impliquant des clusters de bases de données Amazon Aurora dans un VPC et , consultez [Scénarios d’accès à un cluster de bases de données d’un VPC](USER_VPC.Scenarios.md).
**Topics**
+ [Utilisation d’un cluster de bases de données dans un VPC](#Overview.RDSVPC.Create)
+ [Contrôle du chiffrement VPC](#USER_VPC.EncryptionControl)
+ [Utilisation de groupes de sous-réseaux DB](#USER_VPC.Subnets)
+ [Sous-réseaux partagés](#USER_VPC.Shared_subnets)
+ [Adressage IP Amazon Aurora](#USER_VPC.IP_addressing)
+ [Masquer un cluster de bases de données dans un VPC depuis Internet](#USER_VPC.Hiding)
+ [Création d’un cluster de bases de données dans un VPC](#USER_VPC.InstanceInVPC)
Dans les tutoriels suivants, vous apprendrez à créer un VPC que vous pouvez utiliser pour un scénario commun Amazon Aurora :
+ [Tutoriel : Création d'un VPC à utiliser avec un cluster d' de base de données (uniquement) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md)
+ [Tutoriel : Créer un VPC à utiliser avec un cluster de bases de données (mode double-pile)](CHAP_Tutorials.CreateVPCDualStack.md)
## Utilisation d’un cluster de bases de données dans un VPC
Voici quelques conseils d’utilisation d’un cluster de bases de données dans un VPC :
+ Votre VPC doit avoir au moins deux sous-réseaux. Ces sous-réseaux doivent se trouver dans deux zones de disponibilité différentes dans l' Région AWS endroit où vous souhaitez déployer votre cluster d' de base de données. Un *sous-réseau* est un segment de la plage d’adresses IP d’un VPC que vous pouvez spécifier et que vous pouvez utiliser pour regrouper des clusters de bases de données en fonction de vos besoins en matière de sécurité et de fonctionnement.
+ Si vous voulez que votre cluster de bases de données dans le VPC soit publiquement accessible, assurez-vous d’activer les attributs VPC *DNS hostnames* (Noms d’hôtes DNS) et *DNS resolution* (Résolution DNS).
+ Votre VPC doit disposer d’un groupe de sous-réseau de base de données que vous créez. Vous créez un groupe de sous-réseaux de base de données en spécifiant les sous-réseaux que vous avez créés. Amazon Aurora choisit un sous-réseau et une adresse IP dans ce sous-réseau pour les associer avec l’instance de base de données principale dans votre cluster de bases de données. L’instance de base de données principale utilise la zone de disponibilité contenant le sous-réseau.
+ Votre VPC doit avoir un groupe de sécurité VPC qui autorise l’accès au cluster de bases de données.
Pour plus d’informations, consultez [Scénarios d’accès à un cluster de bases de données d’un VPC](USER_VPC.Scenarios.md).
+ Les blocs CIDR de chacun de vos sous-réseaux doivent être assez grands pour accueillir les adresses IP de rechange utilisées par Amazon Aurora pendant les activités de maintenance, y compris le basculement et le dimensionnement du calcul. Par exemple, une plage telle que 10.0.0.0/24 et 10.0.1.0/24 est généralement suffisante.
+ Un VPC peut avoir un attribut *instance tenancy (location d’instance)* ayant la valeur *par défaut* ou *dédiée*. Tous les paramètres par défaut VPCs ont l'attribut de location d'instance défini sur défaut, et un VPC par défaut peut prendre en charge n'importe quelle classe d'instance de base de données.
Si vous choisissez d’installer votre cluster de bases de données dans un VPC dédié où l’attribut de location de l’instance est défini comme étant dédié, la classe d’instance de base de données de votre cluster de bases de données doit être l’un des types d’instance dédiée Amazon EC2 approuvés. Par exemple, l’instance dédiée EC2 r5.large correspond à la classe d’instance db.r5.large DB. Pour plus d’informations sur la location d’instance dans un VPC, consultez [Instances dédiées](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) dans le *Guide de l’utilisateur Amazon Elastic Compute Cloud*.
Pour plus d’informations sur les types d’instance qui peuvent se trouver dans une instance dédiée, consultez [Instances dédiées Amazon EC2](https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/) sur la page de tarification Amazon EC2.
**Note**
Lorsque vous définissez l’attribut de location d’instance sur dédié pour un cluster de bases de données, cela ne garantit pas que le cluster de bases de données fonctionnera sur un hôte dédié.
## Contrôle du chiffrement VPC
Les contrôles de chiffrement VPC vous permettent de les appliquer encryption-in-transit à l'ensemble du trafic réseau au sein de votre. VPCs Utilisez le contrôle du chiffrement pour répondre aux exigences de conformité réglementaire en vous assurant que seul le matériel Nitro compatible avec le chiffrement peut être fourni dans un environnement désigné. VPCs Le contrôle du chiffrement permet également de détecter les problèmes de compatibilité au moment de la demande d'API plutôt que lors du provisionnement. Vos charges de travail existantes continuent de fonctionner et seules les nouvelles demandes incompatibles sont bloquées.
Définissez vos contrôles de chiffrement VPC en configurant le mode de contrôle VPC de manière à :
+ *désactivé* (par défaut)
+ *moniteur*
+ *appliqué*
Pour vérifier le mode de contrôle actuel de votre VPC, utilisez la AWS Management Console commande ou la commande API ou [DescribeVpcs](https://docs.aws.amazon.com//AWSEC2/latest/APIReference/API_DescribeVpcs.html)CLI.
Si votre VPC applique le chiffrement, vous ne pouvez fournir que des de base de données de clusters de base de données basées sur Nitro qui prennent en charge le chiffrement en transit dans ce VPC. Pour plus d'informations, voir,[Types de classes d’instance de base de données](Concepts.DBInstanceClass.Types.md). Pour plus d'informations sur les instances Nitro, consultez la section [Instances créées sur le système AWS Nitro](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) dans le guide de l'utilisateur *Amazon EC2*.
**Note**
Si vous essayez de provisionner des de données incompatibles dans un VPC basé sur le chiffrement, Aurora RDS renvoie une exception. `VpcEncryptionControlViolationException`
Aurora ServerlessPour MySQL et PostreSQL, le contrôle du chiffrement nécessite la version 3 ou une version ultérieure de la plate-forme.
## Utilisation de groupes de sous-réseaux DB
Les *sous-réseaux* sont des segments d’une plage d’adresses IP d’un VPC que vous définissez pour regrouper vos ressources en fonction de vos besoins de sécurité et de fonctionnement. Un *groupe de sous-réseaux de base de données* est une collection de sous-réseaux (généralement privés) que vous créez dans un VPC et que vous spécifiez alors pour vos clusters de base de données. En utilisant un groupe de sous-réseaux de base de données, vous pouvez spécifier un VPC particulier lors de la création de clusters d' de base de données à l'aide de l'API ou AWS CLI RDS. Si vous utilisez la console, vous pouvez choisir le VPC et les groupes de sous-réseaux que vous voulez utiliser.
Chaque groupe de sous-réseaux de base de données doit avoir des sous-réseaux dans au moins deux zones de disponibilité d’une Région AWS donnée. Lorsque vous créez un cluster de bases de données dans un VPC, vous choisissez un groupe de sous-réseau de base de données pour celui-ci. Dans le groupe de sous-réseaux de base de données, Amazon Aurora choisit un sous-réseau et une adresse IP dans ce sous-réseau pour les employer avec l’instance de base de données principale dans votre cluster de bases de données. La base de données utilise la zone de disponibilité contenant le sous-réseau. Aurora attribue toujours une adresse IP à partir d’un sous-réseau disposant d’un espace d’adresse IP libre.
Les sous-réseaux d’un groupe de sous-réseaux de base de données sont publics ou privés. Les sous-réseaux sont publics ou privés, selon la configuration que vous définissez pour leurs listes de contrôle d'accès réseau (réseau ACLs) et leurs tables de routage. Pour qu’un cluster de bases de données soit accessible au public, tous les sous-réseaux de son groupe de sous-réseaux de base de données doivent être publics. Si un sous-réseau associé à un cluster de bases de données accessible au public passe de public à privé, cela peut affecter la disponibilité du cluster de bases de données.
Pour créer un groupe de sous-réseaux de base de données prenant en charge le mode double pile, assurez-vous qu'un bloc CIDR du protocole Internet version 6 (IPv6) est associé à chaque sous-réseau que vous ajoutez au groupe de sous-réseaux de base de données. Pour plus d'informations, consultez [Adressage IP Amazon Aurora](#USER_VPC.IP_addressing) la section « [Migration vers](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) » IPv6 dans le guide de l'*utilisateur Amazon VPC.*
Lorsque Amazon Aurora crée un cluster de bases de données dans un VPC, il attribue une interface réseau à votre cluster de bases de données en utilisant une adresse IP de votre groupe de sous-réseau de base de données. Toutefois, nous vous recommandons vivement d’utiliser le nom du système de nom de domaine (DNS) pour vous connecter à votre cluster de bases de données. Nous le recommandons, car l’adresse IP sous-jacente change pendant le basculement.
**Note**
Pour chaque cluster de bases de données que vous exécutez dans un VPC, assurez-vous de réserver au moins une adresse dans chaque sous-réseau du groupe de sous-réseaux de base de données qui sera utilisée par Amazon Aurora pour les actions de récupération.
## Sous-réseaux partagés
Vous pouvez créer une instance de base de données dans un VPC partagé.
Voici quelques points à prendre en compte lors de l'utilisation du partage VPCs :
+ Vous pouvez déplacer un cluster de bases de données d’un sous-réseau VPC partagé vers un sous-réseau VPC non partagé et vice-versa.
+ Les participants à un VPC partagé doivent créer un groupe de sécurité dans le VPC pour pouvoir créer un cluster de bases de données.
+ Les propriétaires et les participants d’un VPC partagé peuvent accéder à la base de données à l’aide de requêtes SQL. Toutefois, seul le créateur d’une ressource peut effectuer des appels d’API sur cette ressource.
## Adressage IP Amazon Aurora
Les adresses IP permettent aux ressources de votre VPC de communiquer entre elles et avec les ressources sur Internet. Amazon Aurora prend en charge les deux protocoles ainsi que les protocoles IPv4 d' IPv6 adressage. Par défaut, , Amazon Aurora et Amazon VPC utilisent IPv4 le protocole d'adressage. Vous ne pouvez pas désactiver ce comportement. Lorsque vous créez un VPC, assurez-vous de spécifier un bloc IPv4 CIDR (une plage d'adresses privées IPv4 ). Vous pouvez éventuellement attribuer un bloc IPv6 CIDR à votre VPC et à vos sous-réseaux, et IPv6 attribuer les adresses de ce bloc aux clusters d' de base de données de votre sous-réseau.
Support du IPv6 protocole augmente le nombre d'adresses IP prises en charge. En utilisant le IPv6 protocole, vous vous assurez de disposer de suffisamment d'adresses disponibles pour la future croissance d'Internet. Les ressources et IPv6 adresses RDS nouvelles et existantes peuvent être utilisées IPv4 au sein de votre VPC. La configuration, la sécurisation et la traduction du trafic réseau entre les deux protocoles utilisés dans les différentes parties d’une application peuvent entraîner une surcharge opérationnelle. Vous pouvez standardiser le IPv6 protocole des ressources Amazon RDS afin de simplifier la configuration de votre réseau.
**Topics**
+ [IPv4 adresses](#USER_VPC.IP_addressing.IPv4)
+ [IPv6 adresses](#USER_VPC.IP_addressing.IPv6)
+ [Mode double pile](#USER_VPC.IP_addressing.dual-stack-mode)
### IPv4 adresses
Lorsque vous créez un VPC, vous devez spécifier une plage d' IPv4 adresses pour le VPC sous la forme d'un bloc CIDR, tel que. `10.0.0.0/16` Un *groupe de sous-réseau de base de données* définit la plage d’adresses IP de ce bloc CIDR qu’un cluster de bases de données peut utiliser. Ces adresses IP peuvent être privées ou publiques.
Une IPv4 adresse privée est une adresse IP qui n'est pas accessible via Internet. Vous pouvez utiliser IPv4 des adresses privées pour la communication entre votre cluster d' de base de données et d'autres ressources, telles que les instances Amazon EC2, dans le même VPC. Chaque cluster de bases de données dispose d’une adresse IP privée pour la communication dans le VPC.
Une adresse IP publique est une IPv4 adresse accessible depuis Internet. Vous pouvez utiliser des adresses publiques pour la communication entre votre cluster de bases de données et des ressources sur Internet, comme un client SQL. Vous contrôlez si votre cluster de bases de données reçoit une adresse IP publique.
Amazon RDS utilise les adresses IPv4 Elastic publiques issues du pool d' IPv4 adresses publiques d'EC2 pour les instances de base de données accessibles au public. Ces adresses IP sont visibles dans votre AWS compte lorsque vous utilisez la `describe-addresses` CLI, l'API ou que vous consultez la section Elastic IPs (EIP) du AWS Management Console. Chaque adresse IP gérée par RDS est marquée par un `service_managed` attribut défini sur. `"rds"`
Bien qu'ils IPs soient visibles dans votre compte, ils restent entièrement gérés par Amazon RDS et ne peuvent être ni modifiés ni publiés. Amazon RDS est IPs réintégré dans le pool d' IPv4 adresses public lorsqu'il n'est plus utilisé.
CloudTrail enregistre les appels d'API liés à l'EIP de RDS, tels que le. `AllocateAddress` Ces appels d'API sont invoqués par le principal du service`rds.amazonaws.com`.
**Note**
IPs alloués par Amazon RDS ne sont pas pris en compte dans les limites EIP de votre compte.
Pour un didacticiel expliquant comment créer un VPC avec uniquement des IPv4 adresses privées que vous pouvez utiliser pour un scénario Amazon , consultez. [Tutoriel : Création d'un VPC à utiliser avec un cluster d' de base de données (uniquement) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md)
### IPv6 adresses
Vous pouvez éventuellement associer un bloc IPv6 CIDR à votre VPC et à vos sous-réseaux, et IPv6 attribuer des adresses de ce bloc aux ressources de votre VPC. Chaque IPv6 adresse est unique au monde.
Le bloc IPv6 CIDR pour votre VPC est automatiquement attribué à partir du pool IPv6 d'adresses d'Amazon. Vous ne pouvez pas choisir la plage vous-même.
Lorsque vous vous connectez à une IPv6 adresse, assurez-vous que les conditions suivantes sont remplies :
+ Le client est configuré de telle sorte que le trafic entre le client et la base de données IPv6 soit autorisé.
+ Les groupes de sécurité RDS utilisés par l'instance de base de données sont correctement configurés afin que le trafic client-base de données IPv6 soit autorisé.
+ La pile du système d'exploitation client autorise le trafic sur l' IPv6 adresse, et les pilotes et bibliothèques du système d'exploitation sont configurés pour choisir le point de terminaison d'instance de base de données par défaut correct ( IPv4 ou non IPv6).
Pour plus d'informations IPv6, consultez la section [Adressage IP](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) dans le guide de l'*utilisateur Amazon VPC*.
### Mode double pile
Un cluster d' de base de données s'exécute en mode double pile lorsqu'il peut communiquer à la fois via des protocoles IPv4 et des protocoles d' IPv6 adressage. Les ressources peuvent ensuite communiquer avec le cluster d' de base de données en utilisant l'un des protocoles ou les deux. IPv4 IPv6 Les instances de base de données privées en mode double pile ont des IPv6 points de terminaison que RDS limite à l'accès VPC uniquement, ce qui garantit que vos points de terminaison restent privés. IPv6 Les instances de base de données publiques en mode double pile fournissent à la fois IPv4 des IPv6 points de terminaison auxquels vous pouvez accéder depuis Internet.
**Topics**
+ [Mode double pile et groupes de sous-réseaux de base de données](#USER_VPC.IP_addressing.dual-stack-db-subnet-groups)
+ [Utilisation d’instances de base de données en mode double pile](#USER_VPC.IP_addressing.dual-stack-working-with)
+ [Modification de IPv4 clusters d' de base de données réservés uniquement pour utiliser le mode double pile](#USER_VPC.IP_addressing.dual-stack-modifying-ipv4)
+ [Disponibilité de clusters de bases de données en réseau à double pile](#USER_VPC.IP_addressing.dual-stack-availability)
+ [Limitations pour les clusters de base de données en réseau à double pile](#USER_VPC.IP_addressing.dual-stack-limitations)
Pour un didacticiel expliquant comment créer un VPC à la fois avec IPv4 des IPv6 adresses que vous pouvez utiliser pour un scénario Amazon , consultez. [Tutoriel : Créer un VPC à utiliser avec un cluster de bases de données (mode double-pile)](CHAP_Tutorials.CreateVPCDualStack.md)
#### Mode double pile et groupes de sous-réseaux de base de données
Pour utiliser le mode double pile, assurez-vous qu'un bloc IPv6 CIDR est associé à chaque sous-réseau du groupe de sous-réseaux de base de données que vous associez au cluster d' de base de données. Vous pouvez créer un nouveau groupe de sous-réseau de base de données ou modifier un groupe de sous-réseau de base de données existant pour répondre à cette exigence. Une fois qu’un cluster de bases de données est en mode double pile, les clients peuvent s’y connecter normalement. Assurez-vous que les pare-feux de sécurité du client et les groupes de sécurité des instances de base de données RDS sont correctement configurés pour autoriser le transfert du trafic. IPv6 Pour se connecter, les clients utilisent le point de terminaison de l’instance principale du cluster de bases de données. Les applications client peuvent spécifier quel protocole est préféré lors de la connexion à une base de données. En mode double pile, le cluster d' de base de données détecte le protocole réseau préféré du client, soit IPv6, IPv4 soit, et utilise ce protocole pour la connexion.
Si un groupe de sous-réseaux de base de données cesse de prendre en charge le mode double pile en raison de la suppression d’un sous-réseau ou d’une dissociation CIDR, il existe un risque d’incompatibilité de l’état du réseau pour les instances de base de données associées au groupe de sous-réseaux de base de données. De même, vous ne pouvez pas utiliser le groupe de sous-réseau de base de données lorsque vous créez un cluster de bases de données en mode double pile.
Pour déterminer si un groupe de sous-réseaux de base de données prend en charge le mode double pile à l'aide du AWS Management Console, consultez le **type de réseau** sur la page de détails du groupe de sous-réseaux de base de données. Pour déterminer si un groupe de sous-réseaux de base de données prend en charge le mode double pile à l'aide de AWS CLI, exécutez la [describe-db-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-subnet-groups.html)commande et visualisez `SupportedNetworkTypes` la sortie.
Les réplicas en lecture sont traités comme des instances de base de données indépendantes et peuvent avoir un type de réseau différent de celui de l’instance de base de données principale. Si vous modifiez le type de réseau de l’instance de base de données principale d’un réplica en lecture, le réplica en lecture n’est pas affecté. Lorsque vous restaurez une instance de base de données, vous pouvez la restaurer sur tout type de réseau pris en charge.
#### Utilisation d’instances de base de données en mode double pile
Lorsque vous créez ou modifiez un cluster d' de base de données, vous pouvez spécifier le mode double pile pour permettre à vos ressources de communiquer avec votre cluster d' de base de données IPv4 via ou IPv6 les deux.
Lorsque vous utilisez le AWS Management Console pour créer ou modifier une instance de base de données, vous pouvez spécifier le mode double pile dans la section **Type de réseau**. L’image suivante présente la section **Network type** (Type de réseau) dans la console.
![\[Section Type de réseau dans la console avec Mode Double pile sélectionné.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png)
Lorsque vous utilisez le AWS CLI pour créer ou modifier un cluster d' de base de données, définissez l'`--network-type`option `DUAL` pour utiliser le mode double pile. Lorsque vous utilisez l’API RDS pour créer ou modifier un cluster de bases de données, définissez le paramètre `NetworkType` sur `DUAL` pour utiliser le mode double pile. Lorsque vous modifiez le type de réseau d’une instance de base de données, une durée d’indisponibilité est possible. Si le mode double pile n’est pas pris en charge par la version du moteur de base de données ou le groupe de sous-réseau de base de données spécifié, l’erreur `NetworkTypeNotSupported` est renvoyée.
Pour plus d’informations sur la création d’un cluster de bases de données, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md). Pour plus d’informations sur la modification d’un cluster, consultez [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md).
Pour déterminer si un cluster de bases de données est en mode double pile en utilisant la console, affichez **Type de réseau** dans l’onglet **Connectivité et sécurité** pour le cluster de bases de données.
#### Modification de IPv4 clusters d' de base de données réservés uniquement pour utiliser le mode double pile
Vous pouvez modifier un cluster d' de base de données réservé IPv4 uniquement pour utiliser le mode double pile. Pour ce faire, modifiez le type de réseau du cluster de bases de données. La modification peut entraîner une durée d’indisponibilité.
Nous vous recommandons de modifier le type de réseau de vos clusters de bases de données Amazon Aurora au cours d’une fenêtre de maintenance. Pour l’heure, il n’est pas possible de définir le type de réseau des nouvelles instances sur le mode double pile. Vous pouvez définir le type de réseau manuellement à l’aide de la commande `modify-db-cluster`.
Avant de modifier un cluster de bases de données pour utiliser le mode double pile, assurez-vous que son groupe de sous-réseau de base de données prend en charge le mode double pile. Si le groupe de sous-réseau de base de données associé au cluster de bases de données ne prend pas en charge le mode double pile, spécifiez un autre groupe de sous-réseau de base de données qui le prend en charge lorsque vous modifiez le cluster de bases de données. La modification du groupe de sous-réseaux de base de données d’ un cluster de bases de données peut entraîner une interruption de service.
Si vous modifiez le groupe de sous-réseau de base de données d’ un cluster de bases de données avant de modifier le cluster de bases de données pour utiliser le mode double pile, assurez-vous que le groupe de sous-réseau de base de données est valide pour le cluster de bases de données avant et après la modification.
Nous vous recommandons d'exécuter l'[modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html)API uniquement avec le `--network-type` paramètre ayant une valeur `DUAL` pour faire passer le réseau d'un cluster Amazon Aurora en mode double pile. L’ajout d’autres paramètres en même temps que le paramètre `--network-type` dans le même appel d’API peut entraîner une durée d’indisponibilité.
Si vous ne parvenez pas à vous connecter au cluster d' de base de données après la modification, assurez-vous que les pare-feux de sécurité et les tables de routage du client et de la base de données sont correctement configurés pour autoriser le trafic vers la base de données sur le réseau sélectionné ( IPv4 ou non IPv6). Vous devrez peut-être également modifier les paramètres du système d'exploitation, les bibliothèques ou les pilotes pour vous connecter à l'aide d'une IPv6 adresse.
**Pour modifier un cluster d' de base de données réservé IPv4 uniquement afin d'utiliser le mode double pile**
1. Modifiez un groupe de sous-réseaux de base de données pour prendre en charge le mode double pile ou créez un groupe de sous-réseaux de base de données qui prend en charge le mode double pile :
1. Associez un bloc IPv6 CIDR à votre VPC.
Pour obtenir des instructions, consultez la section [Ajouter un bloc IPv6 CIDR à votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#vpc-associate-ipv6-cidr) dans le guide de l'utilisateur *Amazon VPC.*
1. Attachez le bloc IPv6 CIDR à tous les sous-réseaux de votre groupe de sous-réseaux de base de données.
Pour obtenir des instructions, consultez la section [Ajouter un bloc IPv6 CIDR à votre sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html#subnet-associate-ipv6-cidr) dans le guide de l'utilisateur Amazon *VPC*.
1. Confirmez que le groupe de sous-réseaux de base de données prend en charge le mode double pile.
Si vous utilisez le AWS Management Console, sélectionnez le groupe de sous-réseaux de base de données et assurez-vous que la valeur des **types de réseau pris en charge** est **Dual, IPv4**.
Si vous utilisez le AWS CLI, exécutez la [describe-db-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-subnet-groups.html)commande et assurez-vous que la `SupportedNetworkType` valeur de l'instance de base de données est`Dual, IPv4`.
1. Modifiez le groupe de sécurité associé au cluster d' de base de données pour autoriser IPv6 les connexions à la base de données, ou créez un nouveau groupe de sécurité qui autorise IPv6 les connexions.
Pour obtenir des instructions, consultez [Security group rules](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) (Règles des groupes de sécurité) dans le *Guide de l’utilisateur Amazon VPC*.
1. Modifiez le cluster de la base de données pour qu’il prenne en charge le mode double pile. Pour ce faire, réglez le **Network type** (Type de réseau) sur **Dual-stack mode** (Mode double pile).
Si vous utilisez la console, assurez-vous que les paramètres suivants sont corrects :
+ **Type de réseau** : **mode double pile**
![\[Section Type de réseau dans la console avec Mode Double pile sélectionné.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png)
+ **DB subnet group** (Groupe de sous-réseau de base de données) : le groupe de sous-réseau de base de données que vous avez configuré à l’étape précédente.
+ **Groupe de sécurité** : la sécurité que vous avez configurée dans une étape précédente.
Si vous utilisez le AWS CLI, assurez-vous que les paramètres suivants sont corrects :
+ `--network-type` – `dual`
+ `--db-subnet-group-name` — le groupe de sous-réseau de base de données que vous avez configuré à l’étape précédente.
+ `--vpc-security-group-ids` : le groupe de sécurité du VPC que vous avez configuré à l’étape précédente.
Par exemple :
```
aws rds modify-db-cluster --db-cluster-identifier my-cluster --network-type "DUAL"
```
1. Confirmez que le cluster de bases de données prend en charge le mode double pile.
Si vous utilisez la console, choisissez l’onglet (Connectivité et sécurité)**Configuration** pour le cluster de la base de données. Dans cet onglet, assurez-vous que la valeur de **Network type** (Type de réseau) est **Dual-stack mode** (Mode double pile).
Si vous utilisez le AWS CLI, exécutez la [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html)commande et assurez-vous que la `NetworkType` valeur du cluster de base de données est`dual`.
Exécutez la `dig` commande sur le point de terminaison de l'instance de base de données du rédacteur pour identifier l' IPv6adresse qui lui est associée.
```
dig db-instance-endpoint AAAA
```
Utilisez le point de terminaison de l'instance de base de données du rédacteur, et non l' IPv6 adresse, pour vous connecter au cluster d' de base de données.
#### Disponibilité de clusters de bases de données en réseau à double pile
Les clusters de base de données réseau à double pile sont disponibles dans tous les domaines Régions AWS , à l'exception des suivants :
+ Asie-Pacifique (Hyderabad)
+ Asie-Pacifique (Malaisie)
+ Asie-Pacifique (Melbourne)
+ Asie-Pacifique (Thaïlande)
+ Canada-Ouest (Calgary)
+ Europe (Espagne)
+ Europe (Zurich)
+ Israël (Tel Aviv)
+ Mexique (Centre)
+ Moyen-Orient (EAU)
Les versions suivantes du moteur de base de données prennent en charge les clusters de bases de données en réseau à double pile :
+ Aurora MySQL versions :
+ 3.02 et versions 3 ultérieures
+ 2.09.1 et versions 2 ultérieures
Pour plus d’informations sur les versions d’Aurora MySQL, consultez [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html).
+ Versions d’Aurora PostgreSQL :
+ 15.2 et toutes les versions ultérieures
+ 14.3 et versions 14 ultérieures
+ 13.7 et versions 13 ultérieures
Pour plus d’informations sur les versions d’Aurora PostgreSQL, consultez [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html).
#### Limitations pour les clusters de base de données en réseau à double pile
Les limitations suivantes s’appliquent aux clusters de bases de données en réseau à double pile :
+ de base de données ne peuvent pas utiliser le IPv6 protocole exclusivement. Ils peuvent utiliser IPv4 exclusivement, ou ils peuvent utiliser le IPv6 protocole IPv4 and (mode double pile).
+ Amazon RDS ne prend pas en charge les IPv6 sous-réseaux natifs.
+ Vous ne pouvez pas utiliser le proxy RDS avec des clusters de bases de données en mode double pile.
## Masquer un cluster de bases de données dans un VPC depuis Internet
Un scénario Amazon Aurora courant consiste à avoir un VPC dans lequel vous avez une instance Amazon EC2 avec une application web publique et un cluster de bases de données avec une base de données qui n’est pas accessible publiquement. Par exemple, vous pouvez créer un VPC contenant un sous-réseau public et un sous-réseau privé. Les instances EC2 qui fonctionnent comme serveurs web peuvent être déployés dans le sous-réseau public. Les clusters de bases de données sont déployés dans le sous-réseau privé. Dans un tel déploiement, seuls les serveurs web ont accès aux clusters de base de données. Pour obtenir une illustration de ce scénario, consultez [Un cluster de bases de données dans un VPC auquel accède une instance EC2 dans le même VPC](USER_VPC.Scenarios.md#USER_VPC.Scenario1).
Lorsque vous lancez un cluster de bases de données dans un VPC, le cluster de bases de données possède une adresse IP privée pour le trafic à l’intérieur du VPC. Cette adresse IP privée n’est pas accessible au public. Vous pouvez utiliser l’option **Public access** (Accès public) pour indiquer si le cluster de bases de données possède également une adresse IP publique en plus de l’adresse IP privée. Si le cluster de la base de données est désigné comme publiquement accessible, son point de terminaison DNS se résout à l’adresse IP privée à partir du VPC. Il renvoit à l’adresse IP publique depuis l’extérieur du VPC. L’accès au cluster de la base de données est contrôlé en dernier ressort par le groupe de sécurité qu’il utilise. Cet accès public n’est pas autorisé si le groupe de sécurité attribué au cluster de la base de données ne comprend pas de règles d’entrée qui l’autorisent. En outre, pour qu’un cluster de bases de données soit publiquement accessible, les sous-réseaux de son groupe de sous-réseaux de base de données doivent avoir une passerelle Internet. Pour plus d’informations, consultez [Impossible de se connecter à l’instance de base de données Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting).
Vous pouvez modifier un cluster de bases de données pour activer ou désactiver l’accessibilité publique en modifiant l’option **Accès public**. L’illustration suivante présente l’option **Public Access (Accès public)** dans la section **Additional connectivity configuration (Configuration de connectivité supplémentaire)**. Pour définir cette option, ouvrez la section **Additional connectivity configuration (Configuration de connectivité supplémentaire)** dans la section **Connectivity (Connectivité)**.
![\[Définissez l’option Accès public pour votre base de données dans la section Configuration de connectivité supplémentaire sur Non.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/VPC-example4.png)
Pour plus d’informations sur la modification d’une instance de base de données afin de définir l’option **Public access (Accès public)**, consultez [Modification d’une instance de base de données dans un cluster de bases de données](Aurora.Modifying.md#Aurora.Modifying.Instance).
## Création d’un cluster de bases de données dans un VPC
Les procédure suivantes vous aident à créer un cluster de bases de données dans un VPC. Pour utiliser le VPC par défaut, vous pouvez commencer par l’étape 2, et utiliser le groupe VPC et sous-réseau de base de données qui ont déjà été créés pour vous. Si vous souhaitez créer un VPC supplémentaire, vous pouvez créer un nouveau VPC.
**Note**
Si vous voulez que votre cluster de bases de données du VPC soit publiquement accessible, vous devez mettre à jour les informations DNS pour le VPC en activant les attributs VPC *DNS hostnames* (noms d’hôtes DNS) et *DNS resolution* (Résolution DNS). Pour plus d’informations sur la mise à jour des informations DNS pour une instance VPC, consultez [Mise à jour de la prise en charge DNS pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html).
Suivez les étapes ci-après pour créer une instance de base de données dans un VPC:
+ [Étape 1 : Création d’un VPC](#USER_VPC.CreatingVPC)
+ [Étape 2 : créer un groupe de sous-réseaux de base de données](#USER_VPC.CreateDBSubnetGroup)
+ [Étape 3 : créer un groupe de sécurité VPC](#USER_VPC.CreateVPCSecurityGroup)
+ [Étape 4 : créer une instance de base de données dans le VPC](#USER_VPC.CreateDBInstanceInVPC)
### Étape 1 : Création d’un VPC
Créez un VPC avec des sous-réseaux dans au moins deux zones de disponibilité. Vous utilisez ces sous-réseaux lorsque vous créerez un groupe de sous-réseaux de base de données. Si vous avez un VPC par défaut, un sous-réseau est automatiquement créé pour vous dans chaque zone de disponibilité de la Région AWS.
Pour obtenir plus d’informations, consultez [Créer un VPC avec des sous-réseaux publics et privés](CHAP_Tutorials.WebServerDB.CreateVPC.md#CHAP_Tutorials.WebServerDB.CreateVPC.VPCAndSubnets), ou [Create a VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC) (Créer un VPC) dans le *Guide de l’utilisateur Amazon VPC*.
### Étape 2 : créer un groupe de sous-réseaux de base de données
Un groupe de sous-réseaux DB est une collection de sous-réseaux (généralement privés) que vous créez pour un VPC et que vous spécifiez alors pour vos clusters de base de données. Un groupe de sous-réseaux de base de données vous permet de spécifier un VPC particulier lorsque vous créez des clusters d' de base de données à l'aide de l'API ou AWS CLI RDS. Si vous utilisez la console, vous pouvez simplement choisir le VPC et les sous-réseaux que vous voulez utiliser. Chaque groupe de sous-réseaux DB doit avoir au moins un sous-réseau dans au moins deux zones de disponibilité de la Région AWS. La bonne pratique est la suivante : chaque groupe de sous-réseaux de base de données doit être constitué d’au moins un sous-réseau pour chaque zone de disponibilité dans la Région AWS.
Pour qu’un cluster de bases de données soit publiquement accessible, les sous-réseaux du groupe de sous-réseaux de base de données doivent avoir une passerelle Internet. Pour plus d’informations sur les passerelles Internet pour les sous-réseaux, consultez [Connect to the internet using an internet gateway](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) (Se connecter à Internet à l’aide d’une passerelle Internet) dans le *Guide de l’utilisateur Amazon VPC*.
Lorsque vous créez un cluster de bases de données dans un VPC, vous pouvez choisir un groupe de sous-réseau de base de données. Amazon Aurora choisit dans ce sous-réseau un sous-réseau et une adresse IP à associer à votre cluster de bases de données. Si aucun groupe de sous-réseau de base de données n’existe, Amazon Aurora crée un groupe de sous-réseau par défaut lorsque vous créez un cluster de bases de données. Amazon Aurora crée une interface réseau Elastic pour votre cluster de bases de données, et l’associe à cette adresse IP. Le cluster de bases de données utilise la zone de disponibilité contenant le sous-réseau.
Dans cette étape, vous créez un groupe de sous-réseaux de base de données et ajoutez les sous-réseaux que vous avez créés pour votre VPC.
**Pour créer un groupe de sous-réseaux de base de données**
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Subnet groups (Groupes de sous-réseaux)**.
1. Choisissez **Create DB Subnet Group (Créer groupe de sous-réseaux de base de données)**.
1. Dans **Nom**, saisissez le nom de votre nouveau groupe de sous-réseaux de base de données.
1. Dans le champ **Description**, saisissez une description de votre groupe de sous-réseaux de base de données.
1. Pour le champ **VPC**, choisissez le VPC par défaut ou le VPC que vous avez créé.
1. Dans la section **Ajouter des sous-réseaux**, choisissez les zones de disponibilité qui incluent les sous-réseaux à partir de **Zones de disponibilité**, puis choisissez les sous-réseaux à partir de **Sous-réseaux**.
![\[Créez un groupe de sous-réseaux de base de données.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/RDSVPC101.png)
1. Sélectionnez **Créer**.
Votre nouveau groupe de sous-réseaux DB apparaît dans la liste des groupes de sous-réseaux sur la console RDS. Vous pouvez choisir le groupe de sous-réseaux DB pour afficher les détails, y compris l’ensemble des sous-réseaux associés au groupe, dans le volet des détails en bas de la fenêtre.
### Étape 3 : créer un groupe de sécurité VPC
Avant de créer votre cluster de bases de données, vous pouvez créer un groupe de sécurité VPC à associer à votre cluster de bases de données. Si vous ne créez pas de groupe de sécurité VPC, vous pouvez utiliser le groupe de sécurité par défaut lorsque vous créez un cluster de bases de données. Pour obtenir des instructions sur la création d’un groupe de sécurité pour votre cluster de bases de données, consultez [Créer un groupe de sécurité VPC pour un cluster de bases de données privé(e)](CHAP_Tutorials.WebServerDB.CreateVPC.md#CHAP_Tutorials.WebServerDB.CreateVPC.SecurityGroupDB), ou [Control traffic to resources using security groups](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) (Contrôler le trafic vers les ressources à l’aide de groupes de sécurité) dans le *Guide de l’utilisateur Amazon VPC*.
### Étape 4 : créer une instance de base de données dans le VPC
Dans cette étape, vous créez un cluster de bases de données et utilisez le nom du VPC, le groupe de sous-réseaux de base de données et le groupe de sécurité VPC que vous avez créés dans les étapes précédentes.
**Note**
Si vous voulez que votre cluster de bases de données du VPC soit publiquement accessible, vous devez activer les attributs du VPC *DNS hostnames* (Noms d’hôte DNS) et *DNS resolution* (Résolution DNS). Pour plus d’informations, consultez [DNS attributes for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) (Attributs DNS pour votre VPC) dans le *Guide de l’utilisateur d’Amazon VPC*.
Pour plus d’informations sur la création d’un cluster de bases de données, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md).
Lorsque vous y êtes invité dans la section **Connectivity** (Connectivité), saisissez le nom du VPC, le groupe de sous-réseaux de base de données et le groupe de sécurité VPC.
**Note**
La mise à jour VPCs n'est actuellement pas prise en charge pour les clusters de base de données Aurora.
# Scénarios d’accès à un cluster de bases de données d’un VPC
Amazon Aurora prend en charge les scénarios suivants pour accéder à un cluster de bases de données dans un VPC :
+ [Une instance Amazon EC2 dans le même VPC](#USER_VPC.Scenario1)
+ [Une instance EC2 d’un autre VPC](#USER_VPC.Scenario3)
+ [Une application cliente via Internet](#USER_VPC.Scenario4)
+ [Un réseau privé](#USER_VPC.NotPublic)
## Un cluster de bases de données dans un VPC auquel accède une instance EC2 dans le même VPC
Une utilisation courante d’un cluster de bases de données d’un VPC consiste à partager les données avec un serveur d’application qui s’exécute dans une instance Amazon EC2 du même VPC.
Le schéma suivant illustre ce scénario.
![\[Scénario VPC avec un serveur web public et une base de données privée.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png)
La solution la plus simple pour gérer l’accès entre les instances EC2 et les clusters de bases de données du même VPC consiste à agir ainsi :
+ Créez un groupe de sécurité VPC dans lequel seront placées vos clusters de base de données. Ce groupe de sécurité peut être utilisé pour restreindre l’accès aux clusters de bases de données. Par exemple, vous pouvez créer une règle personnalisée pour ce groupe de sécurité. Cela peut permettre un accès TCP en utilisant le port que vous avez attribué au cluster de la base de données lorsque vous l’avez créé et une adresse IP que vous utilisez pour accéder au cluster de la base de données à des fins de développement ou autres.
+ Créez un groupe de sécurité VPC dans lequel seront placées vos instances EC2 (serveurs web et clients). Ce groupe de sécurité peut, si nécessaire, autoriser l’accès à l’instance EC2 à partir d’Internet à l’aide de la table de routage du VPC. Par exemple, vous pouvez définir des règles sur ce groupe de sécurité pour autoriser l’accès TCP à l’instance EC2 sur le port 22.
+ Créez des règles personnalisées dans le groupe de sécurité pour vos clusters de base de données qui autorisent les connexions depuis le groupe de sécurité que vous avez créé pour vos instances EC2. Ces règles peuvent permettre à tout membre du groupe de sécurité d’accéder aux clusters de la base de données.
Il existe un sous-réseau public et privé supplémentaire dans une zone de disponibilité distincte. Un groupe de sous-réseaux de base de données RDS nécessite un sous-réseau dans au moins deux zones de disponibilité. Le sous-réseau supplémentaire permet de passer facilement à un déploiement d’instance de base de données Multi-AZ à l’avenir.
Pour obtenir un didacticiel qui explique comment créer un VPC avec des sous-réseaux publics et privés pour ce scénario, consultez [Tutoriel : Création d'un VPC à utiliser avec un cluster d' de base de données (uniquement) IPv4](CHAP_Tutorials.WebServerDB.CreateVPC.md).
**Astuce**
Vous pouvez configurer la connectivité réseau entre une instance Amazon EC2 et un cluster de base de données automatiquement lorsque vous créez le cluster de base de données. Pour plus d'informations, consultez [Configurer la connectivité réseau automatique avec une instance EC2](Aurora.CreateInstance.md#Aurora.CreateInstance.Prerequisites.VPC.Automatic) .
**Pour créer une règle dans un groupe de sécurité VPC qui autorise les connexions à partir d’un autre groupe de sécurité, procédez comme suit :**
1. [Connectez-vous à la console Amazon VPC AWS Management Console et ouvrez-la à https://console.aws.amazon.com l'adresse /vpc.](https://console.aws.amazon.com/vpc)
1. Dans le panneau de navigation, choisissez **Groupes de sécurité**.
1. Choisissez ou créez un groupe de sécurité auquel vous voulez autoriser les membres d’un autre groupe de sécurité à accéder. Dans le scénario précédent, il s’agit du groupe de sécurité que vous utilisez pour vos clusters de bases de données. Sélectionnez l’onglet **Inbound Rules (Règles entrantes)**, puis **Edit inbound rules (Modifier les règles entrantes)**.
1. Sur la page **Edit inbound rules (Modifier les règles entrantes)**, cliquez sur **Add Rule (Ajouter une règle)**.
1. Pour **Type**, choisissez l’entrée qui correspond au port que vous avez utilisé lorsque vous avez créé votre cluster de bases de données, par exemple **MYSQL/Aurora**.
1. Dans la zone **Source**, commencez à taper l’ID du groupe de sécurité, qui répertorie les groupes de sécurité correspondants. Choisissez le groupe de sécurité dont vous voulez autoriser les membres à accéder aux ressources protégées par ce groupe de sécurité. Dans le scénario précédent, il s’agit du groupe de sécurité que vous utilisez pour votre instance EC2.
1. Si nécessaire, répétez les étapes pour le protocole TCP en créant une règle avec **Tous TCP** comme **Type** et votre groupe de sécurité dans la zone **Source**. Si vous prévoyez d’utiliser le protocole UDP, créez une règle avec **All UDP** (Tous UDP) comme **Type** et votre groupe de sécurité dans **Source**.
1. Sélectionnez **Enregistrer les règles**.
L’écran suivant affiche une règle entrante, ainsi qu’un groupe de sécurité pour sa source.
![\[Ajout d’un groupe de sécurité aux règles d’un autre groupe de sécurité\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/con-vpc-add-sg-rule.png)
Pour plus d’informations sur la connexion à votre cluster de bases de données depuis votre instance EC2, consultez [Connexion à un cluster de bases de données Amazon Aurora](Aurora.Connecting.md).
## Un cluster de bases de données d’un VPC accessible par une instance EC2 d’un autre VPC
Quand vos clusters de bases de données se trouvent dans un VPC différent de l’instance EC2 que vous utilisez pour y accéder, vous pouvez utiliser l’appairage de VPC pour accéder au cluster de bases de données.
Le schéma suivant illustre ce scénario.
![\[Une instance de base de données d’un VPC accessible par une instance Amazon EC2 d’un autre VPC.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/RDSVPC2EC2VPC-aurora.png)
Une connexion d'appairage VPC est une connexion réseau entre deux personnes VPCs qui vous permet d'acheminer le trafic entre elles à l'aide d'adresses IP privées. Les ressources des deux VPC peuvent communiquer entre elles comme si elles se trouvaient dans le même réseau. Vous pouvez créer une connexion d'appairage VPC entre votre propre compte VPCs, avec un VPC d'un autre AWS compte ou avec un VPC d'un autre compte. Région AWS Pour plus d’informations sur l’appairage de VPC, consultez [Appairage de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*.
## Un cluster de bases de données d’un VPC accessible par une application cliente via Internet
Pour accéder à des clusters de bases de données d’un VPC à partir d’une application cliente via Internet, vous configurez un VPC avec un seul sous-réseau public et une passerelle Internet pour activer la communication sur Internet.
Le schéma suivant illustre ce scénario.
![\[Un cluster de bases de données d’un VPC accessible par une application cliente via Internet.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/GS-VPC-network-aurora.png)
Nous recommandons la configuration suivante :
+ Un VPC de taille /16 (par exemple, CIDR : 10.0.0.0/16). Cette taille fournit 65 536 adresses IP privées.
+ Un sous-réseau de taille /24 (par exemple, CIDR : 10.0.0.0/24). Cette taille fournit 256 adresses IP privées.
+ Un(e) cluster de bases de données Amazon Aurora qui est associé(e) au VPC et au sous-réseau. Amazon RDS affecte à votre cluster de bases de données une adresse IP au sein du sous-réseau.
+ Une passerelle Internet qui connecte le VPC à Internet et à d’autres produits AWS .
+ Groupe de sécurité associé au cluster de bases de données. Les règles de trafic entrant de votre groupe de sécurité permettent à votre application client d’accéder à votre cluster de bases de données.
Pour plus d’informations sur la création de clusters de bases de données dans un VPC, consultez [Création d’un cluster de bases de données dans un VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.InstanceInVPC).
## Un cluster de bases de données d’un VPC accessible par un réseau privé
Si votre cluster de bases de données n’est pas accessible publiquement, les options suivantes vous permettent d’y accéder à partir d’un réseau privé :
+ Une connexion AWS Site-to-Site VPN. Pour plus d’informations, consultez [Qu’est-ce qu’ AWS Site-to-Site VPN ?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ Une Direct Connect connexion. Pour plus d'informations, voir [Qu'est-ce que c'est Direct Connect ?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
+ Une AWS Client VPN connexion. Pour plus d’informations, consultez [Qu’est-ce qu’ AWS Client VPN ?](https://docs.aws.amazon.com//vpn/latest/clientvpn-admin/what-is.html)
Le schéma suivant illustre un scénario avec une connexion AWS Site-to-Site VPN.
![\[Clusters de bases de données dans un VPC accessibles par un réseau privé.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/site-to-site-vpn-connection-aurora.png)
Pour plus d’informations, consultez [Confidentialité du trafic inter-réseau](inter-network-traffic-privacy.md).
# Tutoriel : Création d'un VPC à utiliser avec un cluster d' de base de données (uniquement) IPv4
Un scénario courant comprend un cluster de bases de données dans un cloud privé virtuel (VPC) basé sur le service Amazon VPC. Ce VPC partage des données avec un serveur web qui fonctionne dans le même VPC. Dans ce didacticiel, vous créez le VPC pour ce scénario.
Le schéma suivant illustre ce scénario. Pour plus d’informations sur d’autres scénarios, consultez [Scénarios d’accès à un cluster de bases de données d’un VPC](USER_VPC.Scenarios.md).
![\[Scénario à VPC unique\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png)
Votre cluster de bases de données doit être disponible uniquement pour votre serveur Web, et non pour l’Internet public. Vous créez ainsi un VPC avec des sous-réseaux publics et privés. Le serveur web étant hébergé dans le sous-réseau public, il peut atteindre Internet. Le cluster de bases de données est hébergé(e) dans un sous-réseau privé. Le serveur web peut se connecter au cluster de bases de données, car il est hébergé dans le même VPC. Mais le cluster de bases de données n’est pas accessible à l’Internet public, ce qui assure une plus grande sécurité.
Ce tutoriel configure un sous-réseau public et privé supplémentaire dans une zone de disponibilité séparée. Ces sous-réseaux ne sont pas utilisés par le tutoriel. Un groupe de sous-réseaux de base de données RDS nécessite un sous-réseau dans au moins deux zones de disponibilité. Le sous-réseau supplémentaire facilite la configuration de plus d’une instance de base de données Aurora
Ce didacticiel décrit la configuration d’un VPC pour les clusters de bases de données Amazon Aurora. Pour obtenir un didacticiel qui vous montre comment créer un serveur Web pour ce scénario VPC, consultez [Didacticiel : Créer un serveur web et une cluster de base de données Amazon Aurora](TUT_WebAppWithRDS.md). Pour plus d’informations sur Amazon VPC, consultez le [Guide de mise en route Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/) et le [Guide de l’utilisateur Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
**Astuce**
Vous pouvez configurer la connectivité réseau entre une instance Amazon EC2 et un cluster de base de données automatiquement lorsque vous créez le cluster de base de données. La configuration du réseau est similaire à celle décrite dans ce tutoriel. Pour plus d’informations, consultez [Configurer la connectivité réseau automatique avec une instance EC2](Aurora.CreateInstance.md#Aurora.CreateInstance.Prerequisites.VPC.Automatic).
## Créer un VPC avec des sous-réseaux publics et privés
Utilisez la procédure suivante pour créer un VPC avec des sous-réseaux publics et privés.
**Pour créer un VPC et des sous-réseaux**
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le coin supérieur droit du AWS Management Console, choisissez la région dans laquelle créer votre VPC. Cet exemple utilise la région USA Ouest (Oregon).
1. Dans le coin supérieur gauche, choisissez **VPC Dashboard (Tableau de bord VPC)**. Pour commencer à créer un VPC, sélectionnez **Create VPC** (Créer un VPC).
1. Pour **Resources to create** (Ressources à créer) sous **VPC settings** (Paramètres VPC), choisissez **VPC and more** (VPC et plus).
1. Pour **VPC settings** (Paramètres de VPC), définissez les valeurs suivantes :
+ **Name tag auto-generation** (Génération automatique de balise de nom) : **tutorial**
+ **IPv4 Bloc CIDR —** **10.0.0.0/16**
+ IPv6 Bloc **CIDR — Aucun bloc IPv6 ** **CIDR**
+ **Tenancy** (Location) : **Default** (Par défaut)
+ **Nombre de zones de disponibilité (AZs)** — **2**
+ **Personnaliser AZs** : conservez les valeurs par défaut.
+ **Number of public subnet** (Nombre de sous-réseaux publics) : **2**
+ **Number of private subnets** (Nombre de sous-réseaux privés) : **2**
+ **Customize subnets CIDR blocks** (Personnaliser les blocs CIDR des sous-réseaux) : conserver les valeurs par défaut.
+ **NAT gateways (\$1)** [Passerelles NAT (\$1)] : **None** (Aucune)
+ **VPC endpoints** (Points de terminaison VPC) : **None** (Aucun)
+ **DNS options** (Options DNS) : conservez les valeurs par défaut.
1. Sélectionnez **Create VPC** (Créer un VPC).
## Créer un groupe de sécurité VPC pour un serveur web public
Ensuite, vous créez un groupe de sécurité pour l’accès public. Pour vous connecter aux instances EC2 publiques dans votre VPC, ajoutez des règles entrantes au groupe de sécurité de votre VPC. Elles permettent au trafic de se connecter depuis Internet.
**Pour créer un groupe de sécurité VPC**
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez successivement **VPC Dashboard (Tableau de bord VPC)**, **Security Groups (Groupes de sécurité)** et **Create Security Group (Créer un groupe de sécurité)**.
1. Sur la page **Create Security Group (Créer un groupe de sécurité)**, définissez les valeurs suivantes :
+ **Nom du groupe de sécurité :** **tutorial-securitygroup**
+ **Description :** **Tutorial Security Group**
+ **VPC :** Choisissez le VPC que vous avez créé précédemment, par exemple : vpc- (**tutorial-vpc**) *identifier*
1. Ajoutez des règles entrantes au groupe de sécurité.
1. Déterminez l’adresse IP à utiliser pour vous connecter aux instances EC2 de votre VPC à l’aide de Secure Shell (SSH). Pour déterminer votre adresse IP publique, dans une autre fenêtre ou un autre onglet du navigateur, vous pouvez utiliser le service à l'adresse [https://checkip.amazonaws.com](https://checkip.amazonaws.com). Exemple d’adresse IP : `203.0.113.25/32`.
Dans de nombreux cas, votre connexion s’effectue via un fournisseur de services Internet (FSI) ou derrière votre pare-feu sans adresse IP statique. Dans ce cas, trouvez la plage d’adresses IP utilisées par les ordinateurs clients.
**Avertissement**
Si vous utilisez `0.0.0.0/0` pour l’accès SSH, vous permettez à toutes les adresses IP d’accéder à vos instances publiques par SSH. Cette approche est acceptable pour une brève durée dans un environnement de test, mais n’est pas sécurisée pour les environnements de production. Dans un environnement de production, autorisez uniquement l’accès à vos instances à l’aide de SSH pour une adresse IP ou une plage d’adresses spécifique.
1. Dans la section **Règles entrantes**, choisissez **Ajouter une règle**.
1. Définissez les valeurs suivantes pour que votre nouvelle règle entrante autorise l’accès SSH à votre instance Amazon EC2. Pour ce faire, vous pouvez vous connecter à votre instance Amazon EC2 pour installer le serveur web et d’autres utilitaires. Vous allez également vous connecter à votre instance EC2 afin de charger le contenu de votre serveur Web.
+ **Type:** **SSH**
+ **Source :** l’adresse IP ou la plage d’adresses IP de l’étape a ; par exemple : **203.0.113.25/32**.
1. Choisissez **Ajouter une règle**.
1. Définissez les valeurs suivantes pour que votre nouvelle règle entrante autorise HTTP à accéder à votre serveur Web :
+ **Type :** **HTTP**
+ **Source :** **0.0.0.0/0**
1. Choisissez **Create security group** (Créer un groupe de sécurité) pour créer le groupe de sécurité.
Notez l’ID du groupe de sécurité, car vous en aurez besoin ultérieurement dans ce didacticiel.
## Créer un groupe de sécurité VPC pour un cluster de bases de données privé(e)
Pour que votre cluster de bases de données demeure privé(e), créez un deuxième groupe de sécurité pour l’accès privé. Pour vous connecter aux clusters de bases de données privés de votre VPC, vous devez ajouter des règles entrantes à votre groupe de sécurité VPC qui autorisent le trafic à partir de votre serveur web uniquement.
**Pour créer un groupe de sécurité VPC**
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez successivement **VPC Dashboard (Tableau de bord VPC)**, **Security Groups (Groupes de sécurité)** et **Create Security Group (Créer un groupe de sécurité)**.
1. Sur la page **Create Security Group (Créer un groupe de sécurité)**, définissez les valeurs suivantes :
+ **Nom du groupe de sécurité :** **tutorial-db-securitygroup**
+ **Description :** **Tutorial DB Instance Security Group**
+ **VPC :** Choisissez le VPC que vous avez créé précédemment, par exemple : vpc- (**tutorial-vpc**) *identifier*
1. Ajoutez des règles entrantes au groupe de sécurité.
1. Dans la section **Règles entrantes**, choisissez **Ajouter une règle**.
1. Définissez les valeurs suivantes pour que votre nouvelle règle entrante autorise le trafic MySQL sur le port 3306 à partir de votre instance Amazon EC2. Dans ce cas, vous pouvez vous connecter du serveur Web à votre cluster de bases de données. Pour ce faire, vous pouvez stocker et extraire les données entre votre application web et votre base de données.
+ **Type :** **MySQL/Aurora**
+ **Source :** identifiant du groupe de sécurité **tutorial-securitygroup** que vous avez créé précédemment dans ce tutoriel, par exemple : **sg-9edd5cfb**.
1. Choisissez **Create security group** (Créer un groupe de sécurité) pour créer le groupe de sécurité.
## Création d’un groupe de sous-réseaux de base de données
Un *groupe de sous-réseaux de base de données* désigne une collection de sous-réseaux que vous créez dans un VPC et que vous spécifiez alors pour vos clusters de bases de données. Un groupe de sous-réseaux de base de données vous permet de spécifier un VPC particulier lors de la création de clusters de bases de données.
**Pour créer un groupe de sous-réseaux de base de données**
1. Identifiez les sous-réseaux privés pour votre base de données dans le VPC.
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez **VPC Dashboard** (Tableau de bord du VPC), puis **Subnets** (Sous-réseaux).
1. **Notez le sous-réseau IDs des sous-réseaux nommés **tutorial-subnet-private1-us-west-2a et 2-us-west-2b**. tutorial-subnet-private**
Vous avez besoin du sous-réseau IDs lorsque vous créez votre groupe de sous-réseaux de base de données.
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
Assurez-vous de vous connecter à la console Amazon RDS et non à la console Amazon VPC.
1. Dans le panneau de navigation, choisissez **Subnet groups (Groupes de sous-réseaux)**.
1. Choisissez **Create DB Subnet Group (Créer groupe de sous-réseaux de base de données)**.
1. Sur la page **Create DB subnet group (Créer groupe de sous-réseaux de base de données)**, définissez ces valeurs dans **Subnet group details (Détails de groupe de sous-réseaux)** :
+ **Nom:** **tutorial-db-subnet-group**
+ **Description:** **Tutorial DB Subnet Group**
+ **VPC : didacticiel-vpc** **(vpc** -) *identifier*
1. Dans la section **Ajouter des sous-réseaux**, choisissez les **zones de disponibilité** et les **sous-réseaux**.
Pour ce tutoriel, choisissez **us-west-2a** et **us-west-2b** pour les **Availability Zones** (Zones de disponibilité). Pour **Subnets** (Sous-réseaux), choisissez les sous-réseaux privés que vous avez identifiés à l’étape précédente.
1. Choisissez **Créer**.
Votre nouveau groupe de sous-réseaux DB apparaît dans la liste des groupes de sous-réseaux sur la console RDS. Vous pouvez choisir le groupe de sous-réseaux DB pour afficher les détails dans le volet des détails en bas de la fenêtre. Ces détails comprennent tous les sous-réseaux employés par le groupe.
**Note**
Si vous avez créé ce VPC pour effectuer [Didacticiel : Créer un serveur web et une cluster de base de données Amazon Aurora](TUT_WebAppWithRDS.md), créez le cluster de bases de données en suivant les instructions fournies dans [Créer un cluster de bases de données Amazon Aurora](CHAP_Tutorials.WebServerDB.CreateDBCluster.md).
## Suppression du VPC
Après avoir créé le VPC et d’autres ressources pour ce didacticiel, vous pouvez les supprimer si elles ne sont plus nécessaires.
**Note**
Si vous avez ajouté des ressources dans le VPC que vous avez créé pour ce tutoriel, vous devrez peut-être les supprimer avant de pouvoir supprimer le VPC. Par exemple, ces ressources peuvent comprendre des instances Amazon EC2 ou des clusters de bases de données Amazon RDS. Pour plus d’informations, consultez [Supprimer votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting) dans le *Guide de l’utilisateur Amazon VPC*.
**Pour supprimer un VPC et les ressources associées**
1. Supprimez le groupe de sous-réseaux de base de données.
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Subnet groups (Groupes de sous-réseaux)**.
1. Sélectionnez le groupe de sous-réseaux de base de données que vous souhaitez supprimer, par exemple **tutorial-db-subnet-group**.
1. Choisissez **Supprimer**, puis **Supprimer** dans la fenêtre de confirmation.
1. Notez l’ID du VPC.
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez **VPC Dashboard**, puis choisissez. **VPCs**
1. Dans la liste, identifiez le VPC que vous avez créé, tel que **tutorial-vpc**.
1. Notez le **VPC ID** (ID de VPC) du VPC que vous avez créé. Vous aurez besoin de l’ID de VPC dans les étapes suivantes.
1. Suppression du groupe de sécurité
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez **Tableau de bord du VPC**, puis **Groupes de sécurité**.
1. Sélectionnez le groupe de sécurité pour l'instance de base de données Amazon RDS, tel que **tutorial-db-securitygroup**.
1. Pour **Actions**, choisissez **Delete security groups** (Supprimer des groupes de sécurité), puis **Delete** (Supprimer) sur la page de confirmation.
1. Sur la page **Groupes de sécurité**, sélectionnez le groupe de sécurité pour l’instance Amazon EC2, par exemple **tutorial-securitygroup**.
1. Pour **Actions**, choisissez **Delete security groups** (Supprimer des groupes de sécurité), puis **Delete** (Supprimer) sur la page de confirmation.
1. Supprimer le VPC.
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez **VPC Dashboard**, puis choisissez. **VPCs**
1. Sélectionnez le VPC que vous voulez supprimer, tel que **tutorial-vpc**.
1. Pour **Actions**, choisissez **Supprimer le VPC**.
La page de confirmation affiche les autres ressources associées au VPC qui seront également supprimées, y compris les sous-réseaux qui lui sont associés.
1. Sur la page de confirmation, entrez **delete** et choisissez **Supprimer**.
# Tutoriel : Créer un VPC à utiliser avec un cluster de bases de données (mode double-pile)
Un scénario courant comprend un cluster de bases de données dans un cloud privé virtuel (VPC) basé sur le service Amazon VPC. Ce VPC partage des données avec une instance publique Amazon EC2 qui fonctionne dans le même VPC.
Dans ce tutoriel, vous créez le VPC pour ce scénario qui fonctionne avec une base de données en mode double pile. Mode double pile pour permettre la connexion via le protocole d' IPv6 adressage. Pour plus d’informations sur les adresses IP, consultez [Adressage IP Amazon Aurora](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing).
Les clusters de réseau à double pile sont pris en charge dans la plupart des régions. Pour de plus amples informations, veuillez consulter [Disponibilité de clusters de bases de données en réseau à double pile](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing.dual-stack-availability). Pour connaître les limites du mode à double pile, consultez [Limitations pour les clusters de base de données en réseau à double pile](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing.dual-stack-limitations).
Le schéma suivant illustre ce scénario.
![\[Scénario VPC pour le mode double pile\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-dual-stack-aurora.png)
Pour plus d’informations sur d’autres scénarios, consultez [Scénarios d’accès à un cluster de bases de données d’un VPC](USER_VPC.Scenarios.md).
Votre cluster de bases de données doit être disponible uniquement pour votre instance Amazon EC2, et non pour l’Internet public. Vous créez ainsi un VPC avec des sous-réseaux publics et privés. L’instance Amazon EC2 est hébergée dans le sous-réseau public, de sorte qu’elle peut accéder à l’Internet public. Le cluster de bases de données est hébergé(e) dans un sous-réseau privé. L’instance Amazon EC2 peut se connecter au cluster de bases de données, car elle est hébergée dans le même VPC. Cependant, le cluster de bases de données n’est pas accessible à l’Internet public, ce qui assure une plus grande sécurité.
Ce tutoriel configure un sous-réseau public et privé supplémentaire dans une zone de disponibilité séparée. Ces sous-réseaux ne sont pas utilisés par le tutoriel. Un groupe de sous-réseaux de base de données RDS nécessite un sous-réseau dans au moins deux zones de disponibilité. Le sous-réseau supplémentaire permet de configurer facilement plus d’une instance de base de données Aurora.
Pour créer un cluster de bases de données qui utilise le mode double pile, spécifiez **Dual-stack mode** (mode double pile) pour le paramètre **Network type** (Type de réseau). Vous pouvez également modifier un cluster de bases de données avec le même paramètre. Pour plus d’informations sur la création d’un cluster de bases de données, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md). Pour plus d’informations sur la modification d’un cluster, consultez [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md).
Ce didacticiel décrit la configuration d’un VPC pour les clusters de bases de données Amazon Aurora. Pour en savoir plus sur Amazon VPC, consultez le [Guide de l’utilisateur Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/).
## Créer un VPC avec des sous-réseaux publics et privés
Utilisez la procédure suivante pour créer un VPC avec des sous-réseaux publics et privés.
**Pour créer un VPC et des sous-réseaux**
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Dans le coin supérieur droit du AWS Management Console, choisissez la région dans laquelle créer votre VPC. L'exemple utilise la région USA Est (Ohio).
1. Dans le coin supérieur gauche, choisissez **VPC Dashboard (Tableau de bord VPC)**. Pour commencer à créer un VPC, sélectionnez **Create VPC** (Créer un VPC).
1. Pour **Resources to create** (Ressources à créer) sous **VPC settings** (Paramètres VPC), choisissez **VPC and more** (VPC et plus).
1. Pour les valeurs **VPC settings** (Paramètres VPC) restantes, définissez ce qui suit :
+ **Name tag auto-generation** (Génération automatique de balise de nom) : **tutorial-dual-stack**
+ **IPv4 Bloc CIDR —** **10.0.0.0/16**
+ IPv6 Bloc **CIDR : bloc** CIDR **fourni par Amazon IPv6 **
+ **Tenancy** (Location) : **Default** (Par défaut)
+ **Nombre de zones de disponibilité (AZs)** — **2**
+ **Personnaliser AZs** : conservez les valeurs par défaut.
+ **Number of public subnet** (Nombre de sous-réseaux publics) : **2**
+ **Number of private subnets** (Nombre de sous-réseaux privés) : **2**
+ **Customize subnets CIDR blocks** (Personnaliser les blocs CIDR des sous-réseaux) : conserver les valeurs par défaut.
+ **NAT gateways (\$1)** [Passerelles NAT (\$1)] : **None** (Aucune)
+ **Egress only internet gateway** (Passerelle Internet de sortie uniquement) : **No** (Non)
+ **VPC endpoints** (Points de terminaison VPC) : **None** (Aucun)
+ **DNS options** (Options DNS) : conservez les valeurs par défaut.
**Note**
Amazon RDS nécessite au moins deux sous-réseaux dans deux zones de disponibilité différentes pour prendre en charge les déploiements d’instances de base de données Multi-AZ. Ce tutoriel crée un déploiement Mono-AZ, mais l’exigence permet de le convertir facilement en un déploiement d’instance de base de données Multi-AZ à l’avenir.
1. Sélectionnez **Create VPC** (Créer un VPC).
## Créer un groupe de sécurité VPC pour une instance publique Amazon EC2
Ensuite, vous créez un groupe de sécurité pour l’accès public. Pour vous connecter aux instance EC2 publiques de votre VPC, ajoutez des règles entrantes à votre groupe de sécurité VPC qui autorisent le trafic à se connecter depuis Internet.
**Pour créer un groupe de sécurité VPC**
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez successivement **VPC Dashboard (Tableau de bord VPC)**, **Security Groups (Groupes de sécurité)** et **Create Security Group (Créer un groupe de sécurité)**.
1. Sur la page **Create Security Group (Créer un groupe de sécurité)**, définissez les valeurs suivantes :
+ **Nom du groupe de sécurité :** **tutorial-dual-stack-securitygroup**
+ **Description :** **Tutorial Dual-Stack Security Group**
+ **VPC :** **Choisissez le VPC que vous avez créé précédemment, par exemple : vpc- () *identifier* tutorial-dual-stack-vpc**
1. Ajoutez des règles entrantes au groupe de sécurité.
1. Déterminez l’adresse IP à utiliser pour vous connecter aux instances EC2 de votre VPC à l’aide de Secure Shell (SSH).
Voici un exemple d'adresse du protocole Internet version 4 (IPv4)`203.0.113.25/32`. Voici un exemple de plage d'adresses du protocole Internet version 6 (IPv6)`2001:db8:1234:1a00::/64`.
Dans de nombreux cas, votre connexion s'effectue via un fournisseur de services Internet (FSI) ou derrière votre pare-feu sans adresse IP statique. Dans ce cas, trouvez la plage d’adresses IP utilisées par les ordinateurs clients.
**Avertissement**
Si vous utilisez `0.0.0.0/0` for IPv4 ou `::0` for IPv6, vous permettez à toutes les adresses IP d'accéder à vos instances publiques via SSH. Cette approche est acceptable pour une brève durée dans un environnement de test, mais n’est pas sécurisée pour les environnements de production. Dans un environnement de production, autorisez uniquement une adresse IP ou une plage d’adresses IP spécifiques à accéder à vos instances.
1. Dans la section **Règles entrantes**, choisissez **Ajouter une règle**.
1. Définissez les valeurs suivantes pour que votre nouvelle règle entrante autorise l’accès Secure Shell (SSH) à votre instance Amazon EC2. Si vous faites cela, vous pouvez vous connecter à votre instance EC2 pour installer des clients SQL et d’autres applications. Indiquez une adresse IP pour accéder à votre instance EC2 :
+ **Type :** **SSH**
+ **Source :** l’adresse IP ou la plage de l’étape a. Voici un exemple d'adresse IPv4 IP**203.0.113.25/32**. Voici un exemple d'adresse IPv6 IP**2001:DB8::/32**.
1. Choisissez **Create security group** (Créer un groupe de sécurité) pour créer le groupe de sécurité.
Notez l’ID du groupe de sécurité, car vous en aurez besoin ultérieurement dans ce didacticiel.
## Créer un groupe de sécurité VPC pour un cluster de bases de données privé(e)
Pour que votre cluster de bases de données demeure privé(e), créez un deuxième groupe de sécurité pour l’accès privé. Pour vous connecter aux clusters de bases de données privé(e)s de votre VPC, ajoutez des règles entrantes à votre groupe de sécurité VPC. Elles autorisent le trafic provenant de votre instance Amazon EC2 uniquement.
**Pour créer un groupe de sécurité VPC**
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez successivement **VPC Dashboard (Tableau de bord VPC)**, **Security Groups (Groupes de sécurité)** et **Create Security Group (Créer un groupe de sécurité)**.
1. Sur la page **Create Security Group (Créer un groupe de sécurité)**, définissez les valeurs suivantes :
+ **Nom du groupe de sécurité :** **tutorial-dual-stack-db-securitygroup**
+ **Description :** **Tutorial Dual-Stack DB Instance Security Group**
+ **VPC :** **Choisissez le VPC que vous avez créé précédemment, par exemple : vpc- () *identifier* tutorial-dual-stack-vpc**
1. Ajoutez des règles entrantes au groupe de sécurité :
1. Dans la section **Règles entrantes**, choisissez **Ajouter une règle**.
1. Définissez les valeurs suivantes pour que votre nouvelle règle entrante autorise le trafic MySQL sur le port 3306 à partir de votre instance Amazon EC2. Dans ce cas, vous pouvez vous connecter de votre instance EC2 à votre cluster de bases de données. Cela signifie que vous pouvez envoyer des données de votre instance EC2 vers votre base de données.
+ **Type :** **MySQL/Aurora**
+ **Source :** identifiant du groupe de sécurité **tutorial-dual-stack-securitygroup** que vous avez créé précédemment dans ce tutoriel, par exemple : **sg-9edd5cfb**.
1. Pour créer le groupe de sécurité, choisissez **Créer un groupe de sécurité**.
## Création d’un groupe de sous-réseaux de base de données
Un *groupe de sous-réseaux de base de données* désigne une collection de sous-réseaux que vous créez dans un VPC et que vous spécifiez alors pour vos clusters de bases de données. En utilisant un groupe de sous-réseau de base de données, vous pouvez spécifier un VPC particulier lors de la création de clusters de bases de données. Pour créer un groupe de sous-réseaux de la base de données qui soit compatible `DUAL`, tous les sous-réseaux doivent être compatibles `DUAL`. Pour être `DUAL` compatible, un sous-réseau doit être associé à un IPv6 CIDR.
**Pour créer un groupe de sous-réseaux de base de données**
1. Identifiez les sous-réseaux privés pour votre base de données dans le VPC.
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez **VPC Dashboard** (Tableau de bord du VPC), puis **Subnets** (Sous-réseaux).
1. **Notez le sous-réseau des sous-réseaux nommés IDs **tutorial-dual-stack-subnet-private1-us-west-2a et -private2-us-west-2b**. tutorial-dual-stack-subnet**
Vous aurez besoin du sous-réseau IDs lorsque vous créerez votre groupe de sous-réseaux de base de données.
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
Assurez-vous de vous connecter à la console Amazon RDS et non à la console Amazon VPC.
1. Dans le panneau de navigation, choisissez **Subnet groups (Groupes de sous-réseaux)**.
1. Choisissez **Create DB Subnet Group (Créer groupe de sous-réseaux de base de données)**.
1. Sur la page **Create DB subnet group (Créer groupe de sous-réseaux de base de données)**, définissez ces valeurs dans **Subnet group details (Détails de groupe de sous-réseaux)** :
+ **Nom:** **tutorial-dual-stack-db-subnet-group**
+ **Description:** **Tutorial Dual-Stack DB Subnet Group**
+ **VPC : **tutorial-dual-stack-vpc (vpc**** -) *identifier*
1. Dans la section **Add subnets** (Ajouter des sous-réseaux), choisissez des valeurs pour les options **Availability Zones** (Zones de disponibilité) et **Subnets** (Sous-réseaux).
Pour ce tutoriel, choisissez **us-east-2a** et **us-east-2b** pour les **Availability Zones** (Zones de disponibilité). Pour **Subnets** (Sous-réseaux), choisissez les sous-réseaux privés que vous avez identifiés à l’étape précédente.
1. Choisissez **Créer**.
Votre nouveau groupe de sous-réseaux DB apparaît dans la liste des groupes de sous-réseaux sur la console RDS. Vous pouvez choisir le groupe de sous-réseau de base de données pour afficher ses détails. Il s’agit notamment des protocoles d’adressage pris en charge, de tous les sous-réseaux associés au groupe et du type de réseau pris en charge par le groupe de sous-réseaux de base de données.
## Créer une instance Amazon EC2 en mode double pile
Pour créer une instance Amazon EC2, suivez les instructions de la section [Lancer une instance à l’aide du nouvel assistant de lancement d’instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) du *Guide de l’utilisateur Amazon EC2*.
Sur la page **Configure Instance Details** (Configurer les détails d’instance), spécifiez les valeurs suivantes et conservez les valeurs par défaut des autres paramètres :
+ **Réseau** — Choisissez un VPC existant avec des sous-réseaux publics et privés, tels que **tutorial-dual-stack-vpc**(vpc-*identifier*) créé dans. [Créer un VPC avec des sous-réseaux publics et privés](#CHAP_Tutorials.CreateVPCDualStack.VPCAndSubnets)
+ **Sous-réseau** — Choisissez un sous-réseau public existant, tel que **subnet- *identifier* \$1 tutorial-dual-stack-subnet -public1-us-east-2a \$1 us-east-2a créé** en. [Créer un groupe de sécurité VPC pour une instance publique Amazon EC2](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupEC2)
+ **Auto-assign Public IP** (Attribuer automatiquement l’adresse IP publique) : choisissez **Enable** (Activer).
+ **Attribuer automatiquement une IPv6 adresse IP** — Choisissez **Activer**.
+ **Firewall (security groups)** [Pare-feu (groupes de sécurité)] : choisissez **Select an existing security group** (Sélectionnez un groupe de sécurité existant).
+ **Common security groups** (Groupes de sécurité communs) : choisissez un groupe de sécurité existant, tel que le `tutorial-securitygroup` créé dans [Créer un groupe de sécurité VPC pour une instance publique Amazon EC2](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupEC2). Assurez-vous que le groupe de sécurité que vous choisissez inclut des règles entrantes pour l’accès SSH (Secure Shell) et HTTP.
## Création d’un cluster de bases de données en mode double pile
Dans cette étape, vous créez un cluster de bases de données qui fonctionne en mode double pile.
**Pour créer une instance de base de données**
1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)l'adresse.
1. Dans le coin supérieur droit de la console, choisissez l' Région AWS endroit où vous souhaitez créer le cluster d' de base de données. L’exemple utilise la région USA Est (Ohio).
1. Dans le panneau de navigation, choisissez **Databases** (Bases de données).
1. Choisissez **Create database** (Créer une base de données).
1. Sur la page **Create database** (Créer une base de données), vérifiez que l’option **Standard create** (Création standard) est activée, puis choisissez le type de moteur de base de données Aurora MySQL.
1. Dans la section **Connectivity (Connectivité)**, définissez les valeurs suivantes :
+ **Network type** (Type de réseau) – choisissez **Dual-stack mode** (Mode double pile)
![\[Section Type de réseau dans la console avec Mode Double pile sélectionné\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png)
+ **Cloud privé virtuel (VPC)** : choisissez un VPC existant avec des sous-réseaux publics et privés, tels que **tutorial-dual-stack-vpc**(vpc-) créé dans. *identifier* [Créer un VPC avec des sous-réseaux publics et privés](#CHAP_Tutorials.CreateVPCDualStack.VPCAndSubnets)
Le VPC doit avoir des sous-réseaux dans des zones de disponibilité différentes.
+ **Groupe **de sous-réseaux de base de données — Choisissez un groupe** de sous-réseaux de base de données pour le VPC, tel que tutorial-dual-stack-db -subnet-group créé dans.** [Création d’un groupe de sous-réseaux de base de données](#CHAP_Tutorials.CreateVPCDualStack.DBSubnetGroup)
+ **Public access** (Accès public) : choisissez **No** (Non).
+ **VPC security group (firewall)** [Groupe de sécurité VPC (pare-feu)] : sélectionnez **Choose existing** (Choisir l’existant).
+ **Groupes de sécurité VPC existants** **: choisissez un groupe de sécurité VPC existant configuré pour un accès privé, tel tutorial-dual-stack-db que -securitygroup créé dans.** [Créer un groupe de sécurité VPC pour un cluster de bases de données privé(e)](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupDB)
Supprimez les autres groupes de sécurité, tels que le groupe de sécurité par défaut, en cliquant sur le signe **X** qui lui est associé.
+ **Availability Zone** (Zone de disponibilité) : choisissez **us-west-2a**.
Pour éviter le trafic inter-zones, assurez-vous que l’instance de base de données et l’instance EC2 se trouvent dans la même zone de disponibilité.
1. Pour les sections restantes, spécifiez vos paramètres de cluster de bases de données. Pour plus d’informations sur chaque paramètre, consultez [Paramètres pour les clusters de bases de données Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings).
## Se connecter à votre instance Amazon EC2 et à votre cluster de bases de données
Une fois votre instance Amazon EC2 et votre cluster de bases de données créées en mode double pile, vous pouvez vous connecter à chacune d’elles à l’aide du protocole IPv6. Pour vous connecter à une instance Amazon EC2 à l'aide du IPv6 protocole, suivez les instructions de la section [Connexion à votre instance Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) dans le guide de l'utilisateur *Amazon EC2*.
Pour vous connecter à votre cluster de bases de données Aurora MySQL depuis l’instance Amazon EC2, suivez les instructions dans [Se connecter à un cluster de bases de données Aurora MySQL](CHAP_GettingStartedAurora.CreatingConnecting.Aurora.md#CHAP_GettingStartedAurora.Aurora.Connect).
## Suppression du VPC
Après avoir créé le VPC et d’autres ressources pour ce didacticiel, vous pouvez les supprimer si elles ne sont plus nécessaires.
Si vous avez ajouté des ressources dans le VPC que vous avez créé pour ce tutoriel, vous devrez peut-être les supprimer avant de pouvoir supprimer le VPC. Les instances Amazon EC2 ou les clusters de bases de données sont des exemples de ressources. Pour plus d’informations, consultez [Supprimer votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting) dans le *Guide de l’utilisateur Amazon VPC*.
**Pour supprimer un VPC et les ressources associées**
1. Supprimez le groupe de sous-réseaux de base de données :
1. Ouvrez la console Amazon RDS à l'adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Dans le panneau de navigation, choisissez **Subnet groups (Groupes de sous-réseaux)**.
1. Sélectionnez le groupe de sous-réseaux de base de données à supprimer, par exemple **tutorial-db-subnet-group**.
1. Choisissez **Supprimer**, puis **Supprimer** dans la fenêtre de confirmation.
1. Notez l’ID du VPC :
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez **VPC Dashboard**, puis choisissez. **VPCs**
1. Dans la liste, identifiez le VPC que vous avez créé, par exemple. **tutorial-dual-stack-vpc**
1. Notez la valeur **VPC ID** (ID de VPC) du VPC que vous avez créé. Il vous servira dans les étapes suivantes.
1. Supprimez les groupes de sécurité :
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez **Tableau de bord du VPC**, puis **Groupes de sécurité**.
1. Sélectionnez le groupe de sécurité pour l'instance de base de données Amazon RDS, tel que **tutorial-dual-stack-db-securitygroup**.
1. Pour **Actions**, choisissez **Delete security groups** (Supprimer des groupes de sécurité), puis **Delete** (Supprimer) sur la page de confirmation.
1. Sur la page **Groupes de sécurité**, sélectionnez le groupe de sécurité pour l'instance Amazon EC2, tel que. **tutorial-dual-stack-securitygroup**
1. Pour **Actions**, choisissez **Delete security groups** (Supprimer des groupes de sécurité), puis **Delete** (Supprimer) sur la page de confirmation.
1. Supprimez la passerelle NAT :
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez **Tableau de bord du VPC**, puis **Passerelles NAT**.
1. Sélectionnez la passerelle NAT du VPC que vous avez créé. Utilisez l’ID de VPC pour identifier la passerelle NAT correcte.
1. Pour **Actions**, choisissez **Delete NAT gateway** (Supprimer la Passerelle NAT).
1. Sur la page de confirmation, entrez **delete** et choisissez **Supprimer**.
1. Supprimer le VPC
1. Ouvrez la console Amazon VPC à l’adresse [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Choisissez **VPC Dashboard**, puis choisissez. **VPCs**
1. Sélectionnez le VPC que vous souhaitez supprimer, par exemple. **tutorial-dual-stack-vpc**
1. Pour **Actions**, choisissez **Supprimer le VPC**.
La page de confirmation affiche les autres ressources associées au VPC qui seront également supprimées, y compris les sous-réseaux qui lui sont associés.
1. Sur la page de confirmation, entrez **delete** et choisissez **Supprimer**.
1. Libérez les adresses IP élastiques :
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Choisissez **EC2 Dashboard**, puis **Elastic IPs**.
1. Sélectionnez l’adresse IP élastique à libérer.
1. Pour **Actions**, choisissez **Release Elastic IP addresses** (Libérer les adresses IP élastiques).
1. Sur la page de confirmation, sélectionnez **Libérer**.