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 Amazon Aurora DSQL
La sécurité du cloud AWS est la priorité absolue. En tant que AWS client, vous bénéficiez de centres de données et d'architectures 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 ceci comme la sécurité *du* cloud et la 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 [AWS conformité Programmes](https://aws.amazon.com/compliance/programs/) de de conformité. Pour en savoir plus sur les programmes de conformité qui s'appliquent à Amazon Aurora DSQL, consultez la section [AWS Services concernés par programme de conformitéAWS](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 de la sensibilité de vos données, des exigences de votre entreprise, ainsi que de la législation et de la réglementation applicables.
Cette documentation vous aide à comprendre comment appliquer le modèle de responsabilité partagée lors de l’utilisation d’Aurora DSQL. Les rubriques suivantes expliquent comment configurer Aurora DSQL 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 Aurora DSQL.
**Topics**
+ [AWS politiques gérées pour Amazon Aurora DSQL](security-iam-awsmanpol.md)
+ [Protection des données dans Amazon Aurora DSQL](data-protection.md)
+ [Chiffrement des données pour Amazon Aurora DSQL](data-encryption.md)
+ [Gestion des identités et des accès pour Aurora DSQL](security-iam.md)
+ [Politiques basées sur les ressources pour Aurora DSQL](resource-based-policies.md)
+ [Utilisation de rôles liés à un service pour Aurora DSQL](working-with-service-linked-roles.md)
+ [Utilisation des clés de condition IAM avec Amazon Aurora DSQL](using-iam-condition-keys.md)
+ [Réponse aux incidents dans Amazon Aurora DSQL](incident-response.md)
+ [Validation de la conformité pour Amazon Aurora DSQL](compliance-validation.md)
+ [Résilience dans Amazon Aurora DSQL](disaster-recovery-resiliency.md)
+ [Sécurité de l’infrastructure dans Amazon Aurora DSQL](infrastructure-security.md)
+ [Configuration et analyse des vulnérabilités dans Amazon Aurora DSQL](configuration-vulnerability.md)
+ [Prévention du cas de figure de l’adjoint désorienté entre services](cross-service-confused-deputy-prevention.md)
+ [Bonnes pratiques de sécurité pour Aurora DSQL](best-practices-security.md)
# AWS politiques gérées pour Amazon Aurora DSQL
Une politique AWS gérée est une politique autonome créée et administrée par AWS. AWS les politiques gérées sont conçues pour fournir des autorisations pour de nombreux cas d'utilisation courants afin que vous puissiez commencer à attribuer des autorisations aux utilisateurs, aux groupes et aux rôles.
N'oubliez pas que les politiques AWS gérées peuvent ne pas accorder d'autorisations de moindre privilège pour vos cas d'utilisation spécifiques, car elles sont accessibles à tous les AWS clients. Nous vous recommandons de réduire encore les autorisations en définissant des [politiques gérées par le client](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) qui sont propres à vos cas d’utilisation.
Vous ne pouvez pas modifier les autorisations définies dans les politiques AWS gérées. Si les autorisations définies dans une politique AWS gérée sont AWS mises à jour, la mise à jour affecte toutes les identités principales (utilisateurs, groupes et rôles) auxquelles la politique est attachée. AWS est le plus susceptible de mettre à jour une politique AWS gérée lorsqu'une nouvelle politique Service AWS est lancée ou lorsque de nouvelles opérations d'API sont disponibles pour les services existants.
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) dans le *Guide de l’utilisateur IAM*.
## AWS politique gérée : AmazonAurora DSQLFull Accès
Vous pouvez associer `AmazonAuroraDSQLFullAccess` à vos utilisateurs, groupes et rôles.
Cette politique accorde des autorisations offrant un accès administrateur complet à Aurora DSQL. Les principaux disposant de ces autorisations peuvent :
+ Créer, supprimer et mettre à jour des clusters Aurora DSQL, y compris des clusters multi-régions
+ Gérer les politiques intégrées du cluster (créer, afficher, mettre à jour et supprimer des politiques)
+ Ajouter et supprimer des balises des clusters
+ Répertorier les clusters et afficher les informations sur les clusters individuels
+ Voir les balises associées aux clusters Aurora DSQL
+ Se connecter à la base de données en tant qu’utilisateur, y compris en tant qu’administrateur
+ Effectuer des opérations de sauvegarde et de restauration pour les clusters Aurora DSQL, y compris le démarrage, l’arrêt et la surveillance des tâches de sauvegarde et de restauration.
+ Utiliser des AWS KMS clés gérées par le client pour le chiffrement des clusters
+ Afficher toutes les statistiques CloudWatch de leur compte
+ Utiliser AWS Fault Injection Service (AWS FIS) pour injecter des défaillances dans les clusters SQL Aurora à des fins de test de tolérance aux pannes
+ Créer des rôles liés au service pour le service `dsql.amazonaws.com`, ce qui est nécessaire pour créer des clusters
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes.
+ `dsql` : accorde aux principaux un accès complet à Aurora DSQL.
+ `cloudwatch`—accorde l'autorisation de publier des points de données métriques sur Amazon CloudWatch.
+ `iam` : accorde des autorisations pour créer un rôle lié à un service.
+ `backup and restore` : accorde des autorisations pour démarrer, arrêter et surveiller les tâches de sauvegarde et de restauration pour les clusters Aurora DSQL.
+ `kms` : accorde les autorisations requises pour valider l’accès aux clés gérées par le client utilisées pour le chiffrement des clusters Aurora DSQL lors de la création, de la mise à jour ou de la connexion à des clusters.
+ `fis`—accorde des autorisations d'utilisation AWS Fault Injection Service (AWS FIS) pour injecter des défaillances dans des clusters Aurora DSQL à des fins de tests de tolérance aux pannes.
Vous trouverez la politique `AmazonAuroraDSQLFullAccess` dans la console IAM et dans le [Guide de référence de la politique gérée par AWS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLFullAccess.html).
## AWS politique gérée : AmazonAurora DSQLRead OnlyAccess
Vous pouvez associer `AmazonAuroraDSQLReadOnlyAccess` à vos utilisateurs, groupes et rôles.
Permet l’accès en lecture à Aurora DSQL. Les principaux disposant de ces autorisations peuvent répertorier les clusters et consulter les informations relatives à des clusters individuels. Ils peuvent voir les balises associées aux clusters Aurora DSQL et consulter les politiques intégrées des clusters. Ils peuvent récupérer et consulter toutes les statistiques CloudWatch de votre compte.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes.
+ `dsql` : accorde des autorisations en lecture seule à toutes les ressources d’Aurora DSQL.
+ `cloudwatch`— autorise la récupération de quantités par lots de données CloudWatch métriques et l'exécution de calculs métriques sur les données récupérées
Vous trouverez la politique `AmazonAuroraDSQLReadOnlyAccess` dans la console IAM et dans le [Guide de référence de la politique gérée par AWS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLReadOnlyAccess.html).
## AWS politique gérée : AmazonAurora DSQLConsole FullAccess
Vous pouvez associer `AmazonAuroraDSQLConsoleFullAccess` à vos utilisateurs, groupes et rôles.
Permet un accès administratif complet à Amazon Aurora DSQL via la AWS Management Console. Les principaux disposant de ces autorisations peuvent :
+ Créer, supprimer et mettre à jour des clusters Aurora DSQL, y compris des clusters multi-régions, avec la console
+ Gérez les politiques intégrées du cluster via la console (création, affichage, mise à jour et suppression de politiques)
+ Répertorier les clusters et afficher les informations sur les clusters individuels
+ Afficher les balises de n’importe quelle ressource de votre compte
+ Se connecter à la base de données en tant qu’utilisateur, y compris en tant qu’administrateur
+ Effectuer des opérations de sauvegarde et de restauration pour les clusters Aurora DSQL, y compris le démarrage, l’arrêt et la surveillance des tâches de sauvegarde et de restauration.
+ Utiliser des AWS KMS clés gérées par le client pour le chiffrement des clusters
+ Lancement AWS CloudShell depuis le AWS Management Console
+ Consultez tous les indicateurs CloudWatch de votre compte
+ Utiliser AWS Fault Injection Service (AWS FIS) pour injecter des défaillances dans les clusters SQL Aurora à des fins de test de tolérance aux pannes
+ Créer des rôles liés au service pour le service `dsql.amazonaws.com`, ce qui est nécessaire pour créer des clusters
Vous pouvez trouver la `AmazonAuroraDSQLConsoleFullAccess` politique sur la console IAM et [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLConsoleFullAccess.html)dans le AWS Managed Policy Reference Guide.
**Détails de l’autorisation**
Cette politique inclut les autorisations suivantes.
+ `dsql` : accorde des autorisations administratives complètes à toutes les ressources d’Aurora DSQL via la AWS Management Console.
+ `cloudwatch`: autorise la récupération de quantités par lots de données CloudWatch métriques et l'exécution de calculs métriques sur les données extraites.
+ `tag`—accorde l'autorisation de renvoyer les clés de balise et les valeurs actuellement utilisées dans le compte spécifié Région AWS pour le compte appelant.
+ `backup and restore` : accorde des autorisations pour démarrer, arrêter et surveiller les tâches de sauvegarde et de restauration pour les clusters Aurora DSQL.
+ `kms` : accorde les autorisations requises pour valider l’accès aux clés gérées par le client utilisées pour le chiffrement des clusters Aurora DSQL lors de la création, de la mise à jour ou de la connexion à des clusters.
+ `cloudshell`—accorde les autorisations de lancement AWS CloudShell pour interagir avec Aurora DSQL.
+ `ec2` : accorde l’autorisation de consulter les informations relatives aux points de terminaison Amazon VPC nécessaires aux connexions Aurora DSQL.
+ `fis`: accorde des autorisations à utiliser AWS FIS pour injecter des défaillances dans des clusters Aurora DSQL à des fins de tests de tolérance aux pannes.
+ `access-analyzer:ValidatePolicy`autorise le linter dans l'éditeur de politique, qui fournit des informations en temps réel sur les erreurs, les avertissements et les problèmes de sécurité liés à la politique actuelle.
+ `fis`—accorde des autorisations d'utilisation AWS Fault Injection Service (AWS FIS) pour injecter des défaillances dans des clusters Aurora DSQL à des fins de tests de tolérance aux pannes.
Vous trouverez la politique `AmazonAuroraDSQLConsoleFullAccess` dans la console IAM et dans le [Guide de référence de la politique gérée par AWS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLConsoleFullAccess.html).
## AWS politique gérée : Aurora DSQLService RolePolicy
Vous ne pouvez pas associer Aurora DSQLService RolePolicy à vos entités IAM. Cette politique est associée à un rôle lié au service qui permet à Aurora DSQL d’accéder aux ressources du compte.
Vous trouverez la `AuroraDSQLServiceRolePolicy` politique sur la console IAM et [Aurora DSQLService RolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDSQLServiceRolePolicy.html) dans le AWS Managed Policy Reference Guide.
## Mises à jour des politiques AWS gérées par Aurora DSQL
Consultez les détails des mises à jour des politiques AWS gérées pour Aurora DSQL depuis que ce service a commencé à suivre ces modifications. Pour recevoir des alertes automatiques concernant les modifications apportées à cette page, abonnez-vous au flux RSS sur la Page historique du document Aurora DSQL.
| Modifier | Description | Date |
| --- | --- | --- |
| AmazonAuroraDSQLFullAccès et AmazonAurora DSQLConsole FullAccess mise à jour | Ajout de la prise en charge de l'intégration AWS Fault Injection Service (AWS FIS) avec Aurora DSQL. Cela vous permet d’injecter des défaillances dans des clusters Aurora DSQL à une seule région ou multi-régions afin de tester la tolérance aux pannes de vos applications. Vous pouvez créer des modèles d'expérimentation dans la AWS FIS console pour définir des scénarios de défaillance et cibler des clusters Aurora DSQL spécifiques à des fins de test. Pour en savoir plus sur ces politiques, voir [AmazonAuroraDSQLFullAccès](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) et [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess). | 19 août 2025 |
| AmazonAuroraDSQLFullAccès et AmazonAurora DSQLRead OnlyAccess AmazonAurora DSQLConsole FullAccess mise à jour | Ajout de la prise en charge des politiques basées sur les ressources (RBP) avec de nouvelles autorisations :`PutClusterPolicy`, et`GetClusterPolicy`. `DeleteClusterPolicy` Ces autorisations permettent de gérer les politiques en ligne associées aux clusters Aurora DSQL pour un contrôle d'accès précis. Pour plus d'informations, consultez [AmazonAuroraDSQLFullAccess [AmazonAuroraDSQLReadOnlyAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLReadOnlyAccess)](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess), et [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess). | 15 octobre 2025 |
| AmazonAuroraDSQLFullMise à jour des accès | Permet d’effectuer des opérations de sauvegarde et de restauration pour les clusters Aurora DSQL, y compris le démarrage, l’arrêt et la surveillance des tâches. Permet également d’utiliser des clés KMS gérées par le client pour le chiffrement des clusters. Pour plus d'informations, voir [AmazonAuroraDSQLFullAccès](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) et [utilisation des rôles liés à un service dans Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 21 mai 2025 |
| AmazonAuroraDSQLConsoleFullAccess update | Permet d’effectuer des opérations de sauvegarde et de restauration pour les clusters Aurora DSQL via l’ AWS Console Home. Cela inclut le démarrage, l’arrêt et le suivi des tâches. Cela prend également en charge l’utilisation de clés KMS gérées par le client pour le chiffrement des clusters et le lancement d’ AWS CloudShell. Pour plus d'informations, reportez-vous à la section [Utilisation [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess)de rôles liés à un service dans Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 21 mai 2025 |
| AmazonAuroraDSQLFullMise à jour des accès | La politique ajoute quatre nouvelles autorisations pour créer et gérer des clusters de bases de données sur plusieurs Régions AWS : `PutMultiRegionProperties``PutWitnessRegion`,`AddPeerCluster`, et`RemovePeerCluster`. Ces autorisations incluent des contrôles au niveau des ressources et des clés de condition afin que vous puissiez contrôler les utilisateurs des clusters que vous pouvez modifier. La politique ajoute également l’autorisation `GetVpcEndpointServiceName` pour vous aider à vous connecter à vos clusters Aurora DSQL via AWS PrivateLink. Pour plus d'informations, voir Pour plus d'informations, voir [AmazonAuroraDSQLFullAccès](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) et [utilisation des rôles liés à un service dans Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 13 mai 2025 |
| AmazonAuroraDSQLReadOnlyAccess update | Inclut la possibilité de déterminer le nom de service de point de terminaison VPC correct lors de la connexion à vos clusters Aurora DSQL via AWS PrivateLink Aurora DSQL. Cela crée des points de terminaison uniques par cellule. Cette API vous permet donc d'identifier le point de terminaison approprié pour votre cluster et d'éviter les erreurs de connexion.Pour plus d'informations, reportez-vous à la section [Utilisation [AmazonAuroraDSQLReadOnlyAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLReadOnlyAccess)de rôles liés à un service dans Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 13 mai 2025 |
| AmazonAuroraDSQLConsoleFullAccess update | Ajout de nouvelles autorisations à Aurora DSQL pour prendre en charge la gestion de clusters multi-régions et la connexion des points de terminaison d’un VPC. Les nouvelles autorisations incluent : PutMultiRegionProperties PutWitnessRegion AddPeerCluster RemovePeerCluster GetVpcEndpointServiceName Pour plus d'informations, reportez-vous à la section [Utilisation [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess)de rôles liés à un service dans Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 13 mai 2025 |
| AuroraDsqlServiceLinkedRolePolicy update | Permet de publier des métriques sur les espaces de noms AWS/AuroraDSQL et AWS/Usage CloudWatch dans la politique. Cela permet au service ou au rôle associé de transmettre des données d'utilisation et de performance plus complètes à votre CloudWatch environnement. Pour plus d'informations, reportez-vous à la section [Utilisation [AuroraDsqlServiceLinkedRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDsqlServiceLinkedRolePolicy.html)de rôles liés à un service dans Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 8 mai 2025 |
| Page créée | A commencé à suivre les politiques AWS gérées liées à Amazon Aurora DSQL | 3 décembre 2024 |
# Protection des données dans Amazon Aurora DSQL
Le [modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) s’applique à la protection des données dans AWS. 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 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 d’ 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é *.
À des fins de protection des données, nous vous recommandons de protéger les informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS. 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.
+ SSL/TLS À utiliser pour communiquer avec les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3.
+ Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail. Pour plus d’informations sur l’utilisation des sentiers pour capturer des activités, consultez [Utilisation des sentiers](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *Guide de l’utilisateur*.
+ Utilisez des solutions de chiffrement, 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.
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 inclut lorsque vous travaillez avec ou d'autres utilisateurs de la console, de l'API ou AWS SDKs. AWS CLI 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.
## Chiffrement des données
Amazon Aurora DSQL offre une infrastructure de stockage hautement durable, pensée pour le stockage de données primaires et stratégiques. Les données sont stockées de façon redondante sur plusieurs appareils situés dans plusieurs installations au sein d’une même région Aurora DSQL.
### Chiffrement en transit
Par défaut, le chiffrement en transit est configuré pour vous. Aurora DSQL utilise le protocole TLS pour chiffrer tout le trafic entre votre client SQL et Aurora DSQL.
Chiffrement et signature des données en transit entre les AWS CLI clients du SDK ou de l'API et les points de terminaison SQL Aurora :
+ Aurora DSQL fournit des points de terminaison HTTPS pour le chiffrement des données en transit.
+ Pour protéger l’intégrité des demandes d’API adressées à Aurora DSQL, les appels d’API doivent être signés par l’appelant. Les appels sont signés par un certificat X.509 ou par la clé d'accès AWS secrète du client conformément au processus de signature Signature version 4 (Sigv4). 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*.
+ Utilisez le AWS CLI ou l'un des AWS SDKs pour envoyer des demandes à AWS. Ces outils signent automatiquement les demandes avec la clé d’accès que vous spécifiez lors de leur configuration.
#### Conformité FIPS
Les points de terminaison du plan de données Aurora DSQL (points de terminaison de cluster utilisés pour les connexions aux bases de données) utilisent par défaut des modules cryptographiques validés par la norme FIPS 140-2. Aucun point de terminaison FIPS distinct n'est requis pour les connexions au cluster.
Pour les opérations du plan de contrôle, Aurora DSQL fournit des points de terminaison FIPS dédiés dans les régions prises en charge. Pour plus d'informations sur les points de terminaison FIPS du plan de contrôle, consultez la section Points de [terminaison et quotas Aurora DSQL](https://docs.aws.amazon.com/general/latest/gr/dsql.html) dans le. *Références générales AWS*
Pour le chiffrement au repos, consultez [Chiffrement au repos dans Aurora DSQL](data-encryption.md#encryption-at-rest).
### Confidentialité du trafic inter-réseaux
Les connexions sont protégées à la fois entre Aurora DSQL et les applications sur site et entre Aurora DSQL et les autres AWS ressources de ces applications. Région AWS
Vous disposez de 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 à Aurora DSQL via le réseau en utilisant les 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.
## Protection des données dans les régions témoins
Lorsque vous créez un cluster multi-régions, une région témoin permet la reprise automatique en cas de défaillance en participant à la réplication synchrone des transactions chiffrées. Si un cluster associé devient indisponible, la région témoin reste disponible pour valider et traiter les écritures de base de données, sans perte de disponibilité.
Les régions témoins protègent et sécurisent vos données grâce à ces caractéristiques de conception :
+ La région témoin reçoit et stocke uniquement les journaux de transactions chiffrés. Elle n’héberge, ne stocke ni ne transmet jamais vos clés de chiffrement.
+ La région témoin se concentre uniquement sur les fonctions d’écriture, d’enregistrement des transactions et de quorum. Elle ne peut pas lire vos données de par sa conception.
+ La région témoin fonctionne sans points de terminaison de connexion au cluster ni processeurs de requêtes. Cela empêche l’accès à la base de données utilisateur.
Pour plus d’informations sur les régions témoins, consultez [Configuration de clusters multi-régions](configuring-multi-region-clusters.md).
# Configuration des SSL/TLS certificats pour les connexions Aurora DSQL
Aurora DSQL exige que toutes les connexions utilisent le chiffrement par protocole TLS (Transport Layer Security). Pour établir des connexions sécurisées, votre système client doit faire confiance à Amazon Root CA 1 (Root Certificate Authority). Ce certificat est préinstallé sur de nombreux systèmes d’exploitation. Cette section fournit des instructions pour vérifier le certificat Amazon Root CA 1 préinstallé sur différents systèmes d’exploitation et vous guide tout au long du processus d’installation manuelle du certificat s’il n’est pas déjà présent.
Nous vous recommandons d’utiliser la version 17 de PostgreSQL.
**Important**
Pour les environnements de production, nous recommandons d’utiliser le mode SSL `verify-full` pour garantir le plus haut niveau de sécurité de connexion. Ce mode vérifie que le certificat du serveur est signé par une autorité de certification fiable et que le nom d’hôte du serveur correspond au certificat.
## Vérification des certificats préinstallés
Dans la plupart des systèmes d’exploitation, **Amazon Root CA 1** est déjà préinstallé. Pour le valider, suivez les étapes indiquées ci-dessous.
### Linux (RedHat/CentOS/Fedora)
Exécutez la commande suivante dans votre terminal :
```
trust list | grep "Amazon Root CA 1"
```
Si le certificat est installé, vous obtenez la sortie suivante :
```
label: Amazon Root CA 1
```
### macOS
1. Ouvrez Spotlight Search (**Command** \$1 **Espace**)
1. Recherchez **Keychain Access**
1. Sélectionnez **System Roots** sous **System Keychains**
1. Recherchez **Amazon Root CA 1** dans la liste des certificats
### Windows
**Note**
En raison d’un problème connu avec le client Windows PSQL, l’utilisation de certificats racine du système (`sslrootcert=system`) peut renvoyer l’erreur suivante : `SSL error: unregistered scheme`. Vous pouvez suivre la méthode [Connexion depuis Windows](#connect-windows) comme méthode alternative pour vous connecter à votre cluster à l’aide du protocole SSL.
Si **Amazon Root CA 1** n’est pas installé sur votre système d’exploitation, suivez les étapes ci-dessous.
## Installation de certificats
Si le certificat `Amazon Root CA 1` n’est pas préinstallé sur votre système d’exploitation, vous devrez l’installer manuellement afin d’établir des connexions sécurisées avec votre cluster Aurora DSQL.
### Installation du certificat Linux
Suivez ces étapes pour installer le certificat Amazon Root CA sur les systèmes Linux.
1. Téléchargez le certificat racine :
```
wget https://www.amazontrust.com/repository/AmazonRootCA1.pem
```
1. Ajoutez le certificat au Trust Store :
```
sudo cp ./AmazonRootCA1.pem /etc/pki/ca-trust/source/anchors/
```
1. Mettez à jour le CA Trust Store :
```
sudo update-ca-trust
```
1. Vérifier l’installation :
```
trust list | grep "Amazon Root CA 1"
```
### Installation du certificat macOS
Ces étapes d’installation du certificat sont facultatives. L’[Installation du certificat Linux](#install-linux) fonctionne également pour un macOS.
1. Téléchargez le certificat racine :
```
wget https://www.amazontrust.com/repository/AmazonRootCA1.pem
```
1. Ajoutez le certificat au trousseau du système :
```
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain AmazonRootCA1.pem
```
1. Vérifier l’installation :
```
security find-certificate -a -c "Amazon Root CA 1" -p /Library/Keychains/System.keychain
```
## Connexion avec SSL/TLS vérification
Avant de configurer SSL/TLS des certificats pour des connexions sécurisées à votre cluster Aurora DSQL, assurez-vous de remplir les conditions préalables suivantes.
+ PostgreSQL version 17 installée
+ AWS CLI configuré avec les informations d'identification appropriées
+ Informations sur les points de terminaison du cluster Aurora DSQL
### Connexion depuis Linux
1. Générez et définissez le jeton d’authentification :
```
export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint)
```
1. Connectez-vous à l’aide de certificats système (s’ils sont préinstallés) :
```
PGSSLROOTCERT=system \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
1. Ou connectez-vous à l’aide d’un certificat téléchargé :
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
**Note**
Pour en savoir plus sur les paramètres PGSSLMODE, consultez [sslmode](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) dans la documentation [Fonctions de contrôle de connexion à la base de données](https://www.postgresql.org/docs/current/libpq-connect.html) PostgreSQL 17.
### Connexion depuis macOS
1. Générez et définissez le jeton d’authentification :
```
export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint)
```
1. Connectez-vous à l’aide de certificats système (s’ils sont préinstallés) :
```
PGSSLROOTCERT=system \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
1. Vous pouvez également télécharger le certificat racine et l’enregistrer sous `root.pem` (si le certificat n’est pas préinstallé)
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql —dbname postgres \
--username admin \
--host your_cluster_endpoint
```
1. Connexion à l’aide de psql :
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql —dbname postgres \
--username admin \
--host your_cluster_endpoint
```
### Connexion depuis Windows
#### Utilisation d’une invite de commande
1. Générez le jeton d’authentification :
```
aws dsql generate-db-connect-admin-auth-token ^
--region=your-cluster-region ^
--expires-in=3600 ^
--hostname=your-cluster-endpoint
```
1. Définissez la variable d’environnement mot de passe :
```
set "PGPASSWORD=token-from-above"
```
1. Définissez la configuration SSL :
```
set PGSSLROOTCERT=C:\full\path\to\root.pem
set PGSSLMODE=verify-full
```
1. Établissez une connexion à la base de données :
```
"C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres ^
--username admin ^
--host your-cluster-endpoint
```
#### En utilisant PowerShell
1. Générez et définissez le jeton d’authentification :
```
$env:PGPASSWORD = (aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --expires-in=3600 --hostname=your-cluster-endpoint)
```
1. Définissez la configuration SSL :
```
$env:PGSSLROOTCERT='C:\full\path\to\root.pem'
$env:PGSSLMODE='verify-full'
```
1. Établissez une connexion à la base de données :
```
"C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres `
--username admin `
--host your-cluster-endpoint
```
## Ressources supplémentaires
+ [Documentation PostgreSQL SSL](https://www.postgresql.org/docs/current/libpq-ssl.html)
+ [Amazon Trust Services](https://www.amazontrust.com/repository/)
# Chiffrement des données pour Amazon Aurora DSQL
Amazon Aurora DSQL chiffre toutes les données au repos. Pour améliorer la sécurité, ce chiffrement utilise AWS Key Management Service (AWS KMS). Cette fonctionnalité réduit la lourdeur opérationnelle et la complexité induites par la protection des données sensibles. Le chiffrement au repos vous aide à :
+ Réduire la charge opérationnelle liée à la protection des données sensibles
+ Créer des applications sécurisées qui répondent aux exigences réglementaires et de conformité strictes en matière de chiffrement
+ Ajouter une couche supplémentaire de protection des données en sécurisant toujours vos données dans un cluster chiffré
+ Respecter les politiques organisationnelles, les réglementations sectorielles ou gouvernementales et les exigences de conformité
Avec Aurora DSQL, vous pouvez créer des applications sensibles en matière de sécurité qui sont conformes aux exigences réglementaires et de chiffrement strictes. Les sections suivantes expliquent comment configurer le chiffrement pour les bases de données Aurora DSQL nouvelles et existantes et comment gérer vos clés de chiffrement.
**Topics**
+ [Types de clés KMS pour Aurora DSQL](#kms-key-types)
+ [Chiffrement au repos dans Aurora DSQL](#encryption-at-rest)
+ [Utilisation AWS KMS et clés de données avec Aurora DSQL](#using-kms-and-data-keys)
+ [Autoriser l'utilisation de votre SQL AWS KMS key pour Aurora](#authorizing-kms-key-use)
+ [Contexte de chiffrement Aurora DSQL](#dsql-encryption-context)
+ [Surveillance de l'interaction SQL d'Aurora avec AWS KMS](#monitoring-dsql-kms-interaction)
+ [Création d’un cluster Aurora DSQL chiffré](#creating-encrypted-cluster)
+ [Suppression ou mise à jour d’une clé pour votre cluster Aurora DSQL](#updating-encryption-key)
+ [Considérations relatives au chiffrement avec Aurora DSQL](#considerations-with-encryption)
## Types de clés KMS pour Aurora DSQL
Aurora DSQL s'intègre AWS KMS pour gérer les clés de chiffrement de vos clusters. Pour plus d’informations sur les types de clés et leurs états, consultez [Concepts AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts-intro.html) dans le *Guide du développeur AWS Key Management Service *. Lorsque vous créez un nouveau cluster, vous pouvez choisir parmi les types de clés KMS suivants pour chiffrer votre cluster :
**Clé détenue par AWS**
Type de chiffrement par défaut. Aurora DSQL détient la clé sans frais supplémentaires. Amazon Aurora DSQL déchiffre de manière transparente les données du cluster lorsque vous accédez à un cluster chiffré. Vous n’avez pas besoin de modifier votre code ni vos applications pour utiliser ou gérer des clusters chiffrés, et toutes les requêtes Aurora DSQL fonctionnent avec vos données chiffrées.
**Clé gérée par le client**
Vous créez, détenez et gérez la clé de votre Compte AWS. Vous avez le contrôle total de la clé KMS. AWS KMS des frais s'appliquent.
Le chiffrement au repos à l'aide du Clé détenue par AWS est disponible sans frais supplémentaires. Toutefois, des AWS KMS frais s'appliquent pour les clés gérées par le client. Pour plus d’informations, consultez la page [Tarification d’AWS KMS](https://aws.amazon.com/kms/pricing/).
Vous pouvez passer d’un type de clé à l’autre à tout moment. Pour plus d’informations sur les types de clés, consultez [Clés gérées par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) et [Clés détenues par AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) dans le *Guide du développeur AWS Key Management Service *.
**Note**
Le chiffrement au repos d'Aurora DSQL est disponible dans toutes les AWS régions où Aurora DSQL est disponible.
## Chiffrement au repos dans Aurora DSQL
Amazon Aurora DSQL utilise la norme Advanced Encryption Standard à 256 bits (AES-256), pour chiffrer vos données au repos. Ce chiffrement permet de protéger vos données contre tout accès non autorisé au stockage sous-jacent. AWS KMS gère les clés de chiffrement de vos clusters. Vous pouvez utiliser les [Clés détenues par AWS](#aws-owned-keys) par défaut ou choisir d’utiliser vos propres AWS KMS [Clés gérées par le client](#customer-managed-keys). Pour en savoir plus sur la spécification et la gestion des clés pour vos clusters Aurora DSQL, consultez [Création d’un cluster Aurora DSQL chiffré](#creating-encrypted-cluster) et [Suppression ou mise à jour d’une clé pour votre cluster Aurora DSQL](#updating-encryption-key).
**Topics**
+ [Clés détenues par AWS](#aws-owned-keys)
+ [Clés gérées par le client](#customer-managed-keys)
### Clés détenues par AWS
Aurora DSQL chiffre tous les clusters par défaut avec. Clés détenues par AWS Ces clés sont gratuites et peuvent être modifiées chaque année afin de protéger les ressources de votre compte. Vous n’avez pas besoin de consulter, de gérer, d’utiliser ni d’auditer ces clés. Aucune action n’est donc requise pour la protection des données. Pour plus d'informations à ce sujet Clés détenues par AWS, consultez [Clés détenues par AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)le *guide du AWS Key Management Service développeur*.
### Clés gérées par le client
Vous créez, possédez et gérez les clés gérées par le client dans votre Compte AWS. Vous avez le contrôle total de ces clés KMS, notamment de leurs politiques, de leur matériel de chiffrement, de leurs balises et de leurs alias. Pour plus d’informations sur la gestion des autorisations, 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 *.
Lorsque vous spécifiez une clé gérée par le client pour le chiffrement au niveau du cluster, Aurora DSQL chiffre le cluster et toutes ses données régionales avec cette clé. Pour éviter les pertes de données et maintenir l’accès au cluster, Aurora DSQL a besoin d’accéder à votre clé de chiffrement. Si vous désactivez votre clé gérée par le client, planifiez sa suppression ou si vous avez une politique qui restreint l’accès à votre service, l’état de chiffrement de votre cluster passe à `KMS_KEY_INACCESSIBLE`. Lorsqu’Aurora DSQL ne peut pas accéder à la clé, les utilisateurs ne peuvent pas se connecter au cluster, l’état de chiffrement du cluster passe à `KMS_KEY_INACCESSIBLE` et le service perd l’accès aux données du cluster.
Pour les clusters multirégionaux, les clients peuvent configurer la clé de AWS KMS chiffrement de chaque région séparément, et chaque cluster régional utilise sa propre clé de chiffrement au niveau du cluster. Si Aurora DSQL ne peut pas accéder à la clé de chiffrement d’un homologue dans un cluster multi-régions, le statut de cet homologue devient `KMS_KEY_INACCESSIBLE` et il indisponible pour les opérations de lecture et d’écriture. Les autres homologues poursuivent leurs activités normales.
**Note**
Si Aurora DSQL ne peut pas accéder à votre clé gérée par le client, l’état de chiffrement de votre cluster passe à `KMS_KEY_INACCESSIBLE`. Une fois que vous aurez rétabli l’accès aux clés, le service détectera automatiquement la restauration dans les 15 minutes. Pour plus d’informations, consultez Inactivité des clusters.
Pour les clusters multi-régions, si l’accès à la clé est perdu pendant une période prolongée, le temps de restauration du cluster dépend de la quantité de données écrites alors que la clé était inaccessible.
## Utilisation AWS KMS et clés de données avec Aurora DSQL
La fonctionnalité de chiffrement SQL au repos d'Aurora utilise une AWS KMS key et une hiérarchie de clés de données pour protéger les données de votre cluster.
Nous vous recommandons de planifier votre stratégie de chiffrement avant d’implémenter votre cluster dans Aurora DSQL. Si vous stockez des données sensibles ou confidentielles dans Aurora DSQL, pensez à inclure le chiffrement côté client dans votre stratégie. Vous pourrez ainsi chiffrer les données au plus près de leur origine et garantir leur protection tout au long de leur cycle de vie.
**Topics**
+ [Utilisation AWS KMS key de s avec Aurora SQL](#aws-kms-key)
+ [Utilisation des clés de cluster avec Aurora DSQL](#cluster-keys)
+ [Mise en cache des clés de cluster](#cluster-key-caching)
### Utilisation AWS KMS key de s avec Aurora SQL
Le chiffrement au repos protège votre cluster Aurora DSQL sous une AWS KMS key. Par défaut, Aurora DSQL utilise une Clé détenue par AWS clé de chiffrement mutualisée créée et gérée dans un compte de service Aurora DSQL. Mais vous pouvez chiffrer vos clusters Aurora DSQL sous une clé gérée par le client dans votre Compte AWS. Vous pouvez sélectionner une autre clé KMS pour chaque cluster, même s’il participe à une configuration KMS multi-régions.
Vous sélectionnez la clé KMS pour un cluster lorsque vous créez ou mettez à jour le cluster. Vous pouvez modifier la clé KMS d’un cluster à tout moment, soit dans la console Aurora DSQL, soit en exécutant l’opération `UpdateCluster`. Le processus de commutation des clés ne provoque pas de durée d’indisponibilité ni de dégradation du service.
**Important**
Aurora DSQL ne prend en charge que les clés KMS symétriques. Vous ne pouvez pas utiliser une clé KMS asymétrique pour chiffrer vos clusters Aurora DSQL.
Une clé gérée par le client fournit les avantages suivants :
+ Vous créez et gérez la clé KMS, y compris en définissant les stratégies de clé et les politiques IAM pour contrôler l’accès à la clé KMS. Vous pouvez activer et désactiver la clé KMS, activer et désactiver la rotation automatique des clés et supprimer la clé KMS lorsqu’elle n’est plus utilisée.
+ Vous pouvez utiliser une clé gérée par le client avec un élément de clé importé ou dans un magasin de clés personnalisé que vous possédez et gérez.
+ Vous pouvez auditer le chiffrement et le déchiffrement de votre cluster Aurora DSQL en examinant les appels d'API Aurora DSQL dans les AWS KMS journaux. AWS CloudTrail
Cependant, il Clé détenue par AWS est gratuit et son utilisation n'est pas prise en compte dans les quotas de AWS KMS ressources ou de demandes. Les clés gérées par le client sont facturées pour chaque appel d’API et des quotas AWS KMS s’appliquent à ces clés KMS.
### Utilisation des clés de cluster avec Aurora DSQL
Aurora DSQL utilise le code AWS KMS key pour générer et chiffrer une clé de données unique pour le cluster, connue sous le nom de clé de **cluster**.
La clé de cluster est utilisée en tant que clé de chiffrement de clé. Aurora DSQL utilise cette clé de cluster pour protéger les clés de chiffrement des données utilisées pour chiffrer les données du cluster. Aurora DSQL génère une clé de chiffrement des données unique pour chaque structure sous-jacente dans un cluster, mais plusieurs éléments de cluster peuvent être protégés par la même clé de chiffrement des données.
Pour déchiffrer la clé de cluster, Aurora DSQL envoie une demande AWS KMS lorsque vous accédez pour la première fois à un cluster chiffré. Pour que le cluster reste disponible, Aurora DSQL vérifie régulièrement l’accès déchiffré à la clé KMS, même lorsque vous n’accédez pas activement au cluster.
Aurora DSQL stocke et utilise la clé de cluster et les clés de chiffrement des données en dehors de AWS KMS. Il protège toutes les clés avec les clés de chiffrement Advanced Encryption Standard (AES) et 256 bits. Ensuite, il stocke les clés chiffrées avec les données chiffrées afin qu’elles soient disponibles pour déchiffrer les données de cluster à la demande.
Si vous modifiez la clé KMS de votre cluster, Aurora DSQL rechiffre la clé de cluster existante avec la nouvelle clé KMS.
### Mise en cache des clés de cluster
Pour éviter d'appeler AWS KMS chaque opération Aurora DSQL, Aurora DSQL met en cache les clés de cluster en texte clair pour chaque appelant en mémoire. Si Aurora DSQL reçoit une demande pour la clé de cluster mise en cache après 15 minutes d'inactivité, il envoie une nouvelle demande AWS KMS pour déchiffrer la clé de cluster. Cet appel capturera toutes les modifications apportées aux politiques d'accès du AWS KMS key in AWS KMS ou Gestion des identités et des accès AWS (IAM) après la dernière demande de déchiffrement de la clé de cluster.
## Autoriser l'utilisation de votre SQL AWS KMS key pour Aurora
Si vous utilisez une clé gérée par le client dans votre compte pour protéger votre cluster Aurora DSQL, les politiques associées à cette clé doivent accorder à Aurora DSQL l’autorisation de l’utiliser en votre nom.
Vous avez un contrôle total des politiques sur une clé gérée par le client. Aurora DSQL n'a pas besoin d'autorisation supplémentaire pour utiliser la valeur par défaut Clé détenue par AWS afin de protéger les clusters Aurora DSQL de votre. Compte AWS
### Politique de clé pour une clé gérée par le client
Lorsque vous sélectionnez une clé gérée par le client pour protéger un cluster Aurora DSQL, Aurora DSQL doit être autorisée à l'utiliser AWS KMS key au nom du principal qui effectue la sélection. Ce principal, qu'il s'agisse d'un utilisateur ou d'un rôle, doit disposer des AWS KMS key autorisations requises par Aurora DSQL. Vous pouvez fournir ces autorisations dans une stratégie de clé ou une politique IAM.
Aurora DSQL requiert au minimum les autorisations suivantes sur une clé gérée par le client :
+ `kms:Encrypt`
+ `kms:Decrypt`
+ `kms:ReEncrypt*`(pour kms: ReEncryptFrom et kms:ReEncryptTo)
+ `kms:GenerateDataKey`
+ `kms:DescribeKey`
Par exemple, l’exemple de stratégie de clé suivant fournit uniquement les autorisations requises. La politique a les effets suivants :
+ Autorise Aurora DSQL à utiliser le AWS KMS key dans des opérations cryptographiques, mais uniquement lorsqu'il agit pour le compte des principaux du compte autorisés à utiliser Aurora DSQL. Si les principaux spécifiés dans la déclaration de stratégie n’ont pas l’autorisation d’utiliser Aurora DSQL, l’appel échoue, même lorsqu’il provient du service Aurora DSQL.
+ La clé de condition `kms:ViaService` permet l’accord d’autorisations uniquement lorsque la demande provient d’Aurora DSQL au nom des principaux répertoriés dans la déclaration de stratégie. Ces principals ne peuvent pas appeler ces opérations directement.
Avant d'utiliser un exemple de politique clé, remplacez les exemples de principes par des principes réels provenant de votre. Compte AWS
```
{
"Sid": "Enable dsql IAM User Permissions",
"Effect": "Allow",
"Principal": {
"Service": "dsql.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey",
"kms:Encrypt",
"kms:ReEncryptFrom",
"kms:ReEncryptTo"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:EncryptionContext:aws:dsql:ClusterId": "w4abucpbwuxx",
"aws:SourceArn": "arn:aws:dsql:us-east-2:111122223333:cluster/w4abucpbwuxx"
}
}
},
{
"Sid": "Enable dsql IAM User Describe Permissions",
"Effect": "Allow",
"Principal": {
"Service": "dsql.amazonaws.com"
},
"Action": "kms:DescribeKey",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:dsql:us-east-2:111122223333:cluster/w4abucpbwuxx"
}
}
}
```
## Contexte de chiffrement Aurora DSQL
Un contexte de chiffrement est un ensemble de paires clé-valeur qui contiennent des données non secrètes arbitraires. Lorsque vous incluez un contexte de chiffrement dans une demande de chiffrement de données, lie AWS KMS cryptographiquement le contexte de chiffrement aux données chiffrées. Pour déchiffrer les données, vous devez transmettre le même contexte de chiffrement.
Aurora DSQL utilise le même contexte de chiffrement dans toutes les opérations AWS KMS cryptographiques. Si vous utilisez une clé gérée par le client pour protéger votre cluster Aurora DSQL, vous pouvez utiliser le contexte de chiffrement pour identifier l'utilisation de cette clé AWS KMS key dans les enregistrements et les journaux d'audit. Elle apparaît également texte brut dans les journaux tels que ceux d’ AWS CloudTrail.
Le contexte de chiffrement peut également être utilisé comme condition d’autorisation dans les politiques.
Dans ses demandes adressées à AWS KMS, Aurora DSQL utilise un contexte de chiffrement avec une paire clé-valeur :
```
"encryptionContext": {
"aws:dsql:ClusterId": "w4abucpbwuxx"
},
```
La paire clé-valeur identifie le cluster chiffrée par Aurora DSQL. La clé est `aws:dsql:ClusterId`. La valeur est l’identifiant du cluster.
## Surveillance de l'interaction SQL d'Aurora avec AWS KMS
Si vous utilisez une clé gérée par le client pour protéger vos clusters Aurora DSQL, vous pouvez utiliser AWS CloudTrail les journaux pour suivre les demandes qu'Aurora DSQL envoie en votre AWS KMS nom.
Développez les sections suivantes pour découvrir comment Aurora DSQL utilise les AWS KMS opérations `GenerateDataKey` et`Decrypt`.
### `GenerateDataKey`
Lorsque vous activez le chiffrement au repos sur un cluster, Aurora DSQL crée une clé de cluster unique. Il envoie une `GenerateDataKey` demande AWS KMS qui spécifie AWS KMS key le cluster.
L’événement qui enregistre l’opération `GenerateDataKey` est similaire à l’exemple d’événement suivant. L’utilisateur est le compte de service Aurora DSQL. Les paramètres incluent l'Amazon Resource Name (ARN) du AWS KMS key, un spécificateur de clé qui nécessite une clé de 256 bits, et le contexte de chiffrement qui identifie le cluster.
```
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AWSService",
"invokedBy": "dsql.amazonaws.com"
},
"eventTime": "2025-05-16T18:41:24Z",
"eventSource": "kms.amazonaws.com",
"eventName": "GenerateDataKey",
"awsRegion": "us-east-1",
"sourceIPAddress": "dsql.amazonaws.com",
"userAgent": "dsql.amazonaws.com",
"requestParameters": {
"encryptionContext": {
"aws:dsql:ClusterId": "w4abucpbwuxx"
},
"keySpec": "AES_256",
"keyId": "arn:aws:kms:us-east-1:982127530226:key/8b60dd9f-2ff8-4b1f-8a9c-bf570cbfdb5e"
},
"responseElements": null,
"requestID": "2da2dc32-d3f4-4d6c-8a41-aff27cd9a733",
"eventID": "426df0a6-ba56-3244-9337-438411f826f4",
"readOnly": true,
"resources": [
{
"accountId": "AWS Internal",
"type": "AWS::KMS::Key",
"ARN": "arn:aws:kms:us-east-1:982127530226:key/8b60dd9f-2ff8-4b1f-8a9c-bf570cbfdb5e"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"sharedEventID": "f88e0dd8-6057-4ce0-b77d-800448426d4e",
"vpcEndpointId": "AWS Internal",
"vpcEndpointAccountId": "vpce-1a2b3c4d5e6f1a2b3",
"eventCategory": "Management"
}
```
### Decrypt
Lorsque vous accédez à une cluster Aurora DSQL chiffré, Aurora DSQL a besoin de déchiffrer la clé de cluster pour pouvoir déchiffrer les clés situées au-dessous dans la hiérarchie. Il déchiffre ensuite les données du cluster. Pour déchiffrer la clé du cluster, Aurora DSQL envoie une `Decrypt` demande AWS KMS indiquant le nom du AWS KMS key cluster.
L’événement qui enregistre l’opération `Decrypt` est similaire à l’exemple d’événement suivant. L'utilisateur est le principal utilisateur Compte AWS qui accède au cluster. Les paramètres incluent la clé de cluster chiffrée (sous forme de blob de texte chiffré) et le contexte de chiffrement identifiant le cluster. AWS KMS dérive l'identifiant du AWS KMS key à partir du texte chiffré.
```
{
"eventVersion": "1.05",
"userIdentity": {
"type": "AWSService",
"invokedBy": "dsql.amazonaws.com"
},
"eventTime": "2018-02-14T16:42:39Z",
"eventSource": "kms.amazonaws.com",
"eventName": "Decrypt",
"awsRegion": "us-east-1",
"sourceIPAddress": "dsql.amazonaws.com",
"userAgent": "dsql.amazonaws.com",
"requestParameters": {
"keyId": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"encryptionContext": {
"aws:dsql:ClusterId": "w4abucpbwuxx"
},
"encryptionAlgorithm": "SYMMETRIC_DEFAULT"
},
"responseElements": null,
"requestID": "11cab293-11a6-11e8-8386-13160d3e5db5",
"eventID": "b7d16574-e887-4b5b-a064-bf92f8ec9ad3",
"readOnly": true,
"resources": [
{
"ARN": "arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab",
"accountId": "AWS Internal",
"type": "AWS::KMS::Key"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111122223333",
"sharedEventID": "d99f2dc5-b576-45b6-aa1d-3a3822edbeeb",
"vpcEndpointId": "AWS Internal",
"vpcEndpointAccountId": "vpce-1a2b3c4d5e6f1a2b3",
"eventCategory": "Management"
}
```
## Création d’un cluster Aurora DSQL chiffré
Tous les clusters Aurora DSQL sont chiffrés au repos. Par défaut, les clusters utilisent une Clé détenue par AWS clé gratuite, ou vous pouvez spécifier une AWS KMS clé personnalisée. Procédez comme suit pour créer votre cluster chiffré à partir du AWS Management Console ou du AWS CLI.
------
#### [ Console ]
**Pour créer un cluster chiffré dans AWS Management Console**
1. Connectez-vous à la console de AWS gestion et ouvrez la console Aurora DSQL à l'[https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql/)adresse.
1. Dans le volet de navigation sur le côté gauche de la console, choisissez **Clusters**.
1. Choisissez **Créer un cluster** en haut à droite, puis sélectionnez **Une seule région unique**.
1. Dans les **paramètres de chiffrement du cluster**, choisissez l’une des options suivantes.
+ Acceptez les paramètres par défaut pour chiffrer sans Clé détenue par AWS frais supplémentaires.
+ Sélectionnez **Personnaliser les paramètres de chiffrement (avancé)** pour indiquer une clé KMS personnalisée. Ensuite, recherchez ou entrez l’ID ou l’alias de votre clé KMS. Vous pouvez également choisir **Créer une AWS KMS clé** pour créer une nouvelle clé dans la AWS KMS console.
1. Choisissez **Créer un cluster**.
Pour confirmer le type de chiffrement de votre cluster, accédez à la page **Clusters** et sélectionnez l’ID du cluster pour afficher les détails du cluster. Consultez l'onglet **Paramètres du cluster**. Le paramètre de **clé KMS du cluster** indique la **clé par défaut Aurora DSQL** pour les clusters qui utilisent des clés AWS détenues ou l'ID de clé pour les autres types de chiffrement.
**Note**
Si vous choisissez de posséder et de gérer votre propre clé, assurez-vous que la stratégie de clé de KMS est correctement définie. Pour plus d’informations et d’exemples, consultez [Politique de clé pour une clé gérée par le client](#key-policy-customer-managed-key).
------
#### [ CLI ]
**Pour créer un cluster chiffré avec la valeur par défaut Clé détenue par AWS**
+ Utilisez la commande suivante pour créer un cluster Aurora DSQL :
```
aws dsql create-cluster
```
Comme indiqué dans les détails de chiffrement suivants, l’état de chiffrement du cluster est activé par défaut, et le type de chiffrement par défaut est la clé détenue par AWS. Le cluster est désormais chiffré avec la clé détenue par AWS par défaut dans le compte de service Aurora DSQL.
```
"encryptionDetails": {
"encryptionType" : "AWS_OWNED_KMS_KEY",
"encryptionStatus" : "ENABLED"
}
```
**Pour créer un cluster chiffré à l’aide de votre clé gérée par le client**
+ Utilisez la commande suivante pour créer un cluster Aurora DSQL, en remplaçant l’ID de clé en rouge par l’ID de votre clé gérée par le client.
```
aws dsql create-cluster \
--kms-encryption-key d41d8cd98f00b204e9800998ecf8427e
```
Comme indiqué dans les détails de chiffrement suivants, l’état de chiffrement du cluster est activé par défaut, et le type de chiffrement est la clé KMS gérée par le client. Le cluster est désormais chiffré avec votre clé.
```
"encryptionDetails": {
"encryptionType" : "CUSTOMER_MANAGED_KMS_KEY",
"kmsKeyArn" : "arn:aws:kms:us-east-1:111122223333:key/d41d8cd98f00b204e9800998ecf8427e",
"encryptionStatus" : "ENABLED"
}
```
------
## Suppression ou mise à jour d’une clé pour votre cluster Aurora DSQL
Vous pouvez utiliser le AWS Management Console ou AWS CLI pour mettre à jour ou supprimer les clés de chiffrement des clusters existants dans Amazon Aurora DSQL. Si vous supprimez une clé sans la remplacer, Aurora DSQL utilise la Clé détenue par AWS par défaut. Procédez comme suit pour mettre à jour les clés de chiffrement d’un cluster existant à partir de la console Aurora DSQL ou de l’ AWS CLI.
------
#### [ Console ]
**Pour mettre à jour ou supprimer une clé de chiffrement dans le AWS Management Console**
1. Connectez-vous à la console de AWS gestion et ouvrez la console Aurora DSQL à l'[https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql/)adresse.
1. Dans le volet de navigation sur le côté gauche de la console, choisissez **Clusters**.
1. Dans la vue en liste, recherchez et sélectionnez la ligne du cluster que vous souhaitez mettre à jour.
1. Sélectionnez le menu **Actions**, puis **Modifier**.
1. Dans les **paramètres de chiffrement du cluster**, choisissez l’une des options suivantes pour modifier les paramètres de chiffrement.
+ Si vous souhaitez passer d'une clé personnalisée à une Clé détenue par AWS, désélectionnez l'option **Personnaliser les paramètres de chiffrement (avancés)**. Les paramètres par défaut s'appliqueront et chiffreront votre cluster gratuitement. Clé détenue par AWS
+ Si vous souhaitez passer d’une clé KMS personnalisée à une autre ou d’une Clé détenue par AWS à une clé KMS, sélectionnez l’option **Personnaliser les paramètres de chiffrement (avancé)** si elle n’est pas déjà sélectionnée. Recherchez et sélectionnez ensuite l’ID ou l’alias de la clé que vous souhaitez utiliser. Vous pouvez également choisir **Créer une AWS KMS clé** pour créer une nouvelle clé dans la AWS KMS console.
1. Choisissez **Enregistrer**.
------
#### [ CLI ]
Les exemples suivants montrent comment utiliser le pour mettre AWS CLI à jour un cluster chiffré.
Pour mettre à jour un cluster chiffré avec la valeur par défaut Clé détenue par AWS
```
aws dsql update-cluster \
--identifier aiabtx6icfp6d53snkhseduiqq \
--kms-encryption-key "AWS_OWNED_KMS_KEY"
```
L’état `EncryptionStatus` de la description du cluster est défini sur `ENABLED` et le `EncryptionType` est `AWS_OWNED_KMS_KEY`.
```
"encryptionDetails": {
"encryptionType" : "AWS_OWNED_KMS_KEY",
"encryptionStatus" : "ENABLED"
}
```
Ce cluster est désormais chiffré à l'aide de la valeur par défaut Clé détenue par AWS du compte de service Aurora DSQL.
Mise à jour d’un cluster chiffré avec une clé gérée par le client pour Aurora DSQL
Mettez à jour le cluster chiffré, comme dans l’exemple suivant :
```
aws dsql update-cluster \
--identifier aiabtx6icfp6d53snkhseduiqq \
--kms-encryption-key arn:aws:kms:us-east-1:123456789012:key/abcd1234-abcd-1234-a123-ab1234a1b234
```
L’état `EncryptionStatus` de la description du cluster passe à `UPDATING` et le `EncryptionType` est `CUSTOMER_MANAGED_KMS_KEY`. Une fois qu’Aurora DSQL aura fini de propager la nouvelle clé sur la plate-forme, l’état du chiffrement passera à `ENABLED`
```
"encryptionDetails": {
"encryptionType" : "CUSTOMER_MANAGED_KMS_KEY",
"kmsKeyArn" : "arn:aws:us-east-1:kms:key/abcd1234-abcd-1234-a123-ab1234a1b234",
"encryptionStatus" : "ENABLED"
}
```
------
**Note**
Si vous choisissez de posséder et de gérer votre propre clé, assurez-vous que la stratégie de clé de KMS est correctement définie. Pour plus d’informations et d’exemples, consultez [Politique de clé pour une clé gérée par le client](#key-policy-customer-managed-key).
## Considérations relatives au chiffrement avec Aurora DSQL
+ Aurora DSQL chiffre toutes les données au repos du cluster. Vous ne pouvez pas désactiver ce chiffrement ni chiffrer uniquement certains éléments d’un cluster.
+ AWS Backup chiffre vos sauvegardes et tous les clusters restaurés à partir de ces sauvegardes. Vous pouvez chiffrer vos données de sauvegarde à AWS Backup l'aide de la clé AWS détenue ou d'une clé gérée par le client.
+ Les états de protection des données suivants sont activés pour Aurora DSQL :
+ **Données au repos** : Aurora DSQL chiffre toutes les données statiques sur les supports de stockage persistants
+ **Données en transit** : Aurora DSQL chiffre toutes les communications à l’aide du protocole TLS (Transport Layer Security) par défaut
+ Lorsque vous passez à une autre clé, nous vous recommandons de conserver la clé d'origine activée jusqu'à ce que la transition soit terminée. AWS a besoin de la clé d'origine pour déchiffrer les données avant de les chiffrer avec la nouvelle clé. Le processus est terminé lorsque l’état `encryptionStatus` du cluster est `ENABLED` et que vous voyez `kmsKeyArn` sur la nouvelle clé gérée par le client.
+ Lorsque vous désactivez votre clé gérée par le client ou que vous révoquez l’accès à Aurora DSQL pour utiliser votre clé, votre cluster passe à l’état `IDLE`.
+ L'API SQL AWS Management Console et Amazon Aurora utilisent des termes différents pour désigner les types de chiffrement :
+ AWS Console — Dans la console, vous verrez `KMS` quand vous utilisez une clé gérée par le client et `DEFAULT` quand vous utilisez un Clé détenue par AWS.
+ API : l’API Amazon Aurora DSQL utilise `CUSTOMER_MANAGED_KMS_KEY` pour les clés gérées par le client et `AWS_OWNED_KMS_KEY` pour les Clés détenues par AWS.
+ Si vous ne spécifiez pas de clé de chiffrement lors de la création du cluster, Aurora DSQL chiffre automatiquement vos données à l'aide du. Clé détenue par AWS
+ Vous pouvez à tout moment passer d'une Clé détenue par AWS clé gérée par le client à une clé gérée par le client. Effectuez cette modification à l'aide de AWS Management Console AWS CLI, ou de l'API SQL Amazon Aurora.
# Gestion des identités et des accès pour Aurora DSQL
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 *s’authentifient* (sont connectées) et *sont autorisées* (disposent d’autorisations) à utiliser des ressources Aurora DSQL. 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)
+ [Fonctionnement d’Amazon Aurora DSQL avec IAM](security_iam_service-with-iam.md)
+ [Exemples de politiques basées sur l’identité pour Amazon Aurora DSQL](security_iam_id-based-policy-examples.md)
+ [Résolution des problèmes liés à l’identité et à l’accès à Amazon Aurora DSQL](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 de votre rôle :
+ **Utilisateur du service** : demandez des autorisations à votre administrateur si vous ne pouvez pas accéder aux fonctionnalités (voir [Résolution des problèmes liés à l’identité et à l’accès à Amazon Aurora DSQL](security_iam_troubleshoot.md))
+ **Administrateur du service** : déterminez l’accès des utilisateurs et soumettez les demandes d’autorisation (voir [Fonctionnement d’Amazon Aurora DSQL avec IAM](security_iam_service-with-iam.md))
+ **Administrateur IAM** : rédigez des politiques pour gérer l’accès (voir [Exemples de politiques basées sur l’identité pour Amazon Aurora DSQL](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*.
### Compte AWS utilisateur root
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 [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*.
### Rôles IAM
Un *[rôle IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* est une identité dotée d’autorisations spécifiques qui fournit des informations d’identification temporaires. Vous pouvez assumer un rôle en [passant d'un rôle utilisateur à un rôle IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou en appelant une opération AWS CLI ou AWS API. Pour plus d’informations, consultez [Méthodes pour endosser un rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) dans le *Guide de l’utilisateur IAM*.
Les rôles IAM sont utiles pour l’accès des utilisateurs fédérés, les autorisations temporaires des utilisateurs IAM, les accès intercompte, les accès entre services et les applications exécutées sur Amazon EC2. 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*.
## 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 à AWS des identités ou à des ressources. Une politique définit les autorisations lorsqu'elles sont associées à une identité ou à une ressource. AWS évalue ces politiques lorsqu'un directeur fait une demande. La plupart des politiques sont stockées AWS sous forme de documents JSON. Pour plus d’informations les 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*.
À l’aide de politiques, les administrateurs précisent qui a accès à quoi en définissant quel **principal** peut effectuer des **actions** sur quelles **ressources** et dans quelles **conditions**.
Par défaut, les utilisateurs et les rôles ne disposent d’aucune autorisation. Un administrateur IAM crée des politiques IAM et les ajoute aux rôles, que les utilisateurs peuvent ensuite assumer. Les politiques IAM définissent les autorisations quelle que soit la méthode que vous utilisez pour exécuter l’opération.
### Politiques basées sur l’identité
Les stratégies basées sur l’identité sont des documents de stratégie d’autorisations JSON que vous attachez à une identité (utilisateur, groupe ou rôle). Ces politiques contrôlent les actions que peuvent exécuter ces identités, 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*.
Les politiques basées sur l’identité peuvent être des *politiques intégrées* (intégrées directement dans une seule identité) ou des *politiques gérées (politiques* autonomes associées à plusieurs identités). Pour découvrir comment choisir entre des politiques gérées et 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-choosing-managed-or-inline.html) dans le *Guide de l’utilisateur IAM*.
### Politiques basées sur les ressources
Les politiques basées sur les ressources sont des documents de politique JSON que vous attachez à une ressource. Les exemples incluent *les politiques de confiance de rôle* IAM et les *stratégies de compartiment* Amazon S3. 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. 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 politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser les politiques AWS gérées par IAM dans une stratégie basée sur les ressources.
### Autres types de politique
AWS prend en charge des types de politiques supplémentaires qui peuvent définir les autorisations maximales accordées par les types de politiques les plus courants :
+ **Limites d’autorisations** : une limite des autorisations définit le nombre maximum d’autorisations qu’une politique basée sur l’identité peut accorder à une entité IAM. Pour plus d’informations, 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)** — Spécifiez les autorisations maximales pour une organisation ou une unité organisationnelle dans AWS Organizations. Pour plus d’informations, consultez [Politiques de contrôle de service](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) dans le *Guide de l’utilisateur AWS Organizations *.
+ **Politiques de contrôle des ressources (RCPs)** : définissez le maximum d'autorisations disponibles pour les ressources de vos comptes. Pour plus d'informations, voir [Politiques de contrôle des ressources (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) dans le *guide de AWS Organizations l'utilisateur*.
+ **Politiques de session** : politiques avancées que vous passez en tant que paramètre lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. 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*.
# Fonctionnement d’Amazon Aurora DSQL avec IAM
Avant d’utiliser IAM pour gérer l’accès à Aurora DSQL, découvrez les fonctionnalités IAM que vous pouvez utiliser avec Aurora DSQL.
**Fonctionnalités IAM que vous pouvez utiliser avec Amazon Aurora DSQL**
| Fonctionnalité IAM | Prise en charge par Aurora DSQL |
| --- | --- |
| [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) | Oui |
| [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](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Oui |
| [ACLs](#security_iam_service-with-iam-acls) | Non |
| [ABAC (étiquettes dans les politiques)](#security_iam_service-with-iam-tags) | Oui |
| [Informations d’identification temporaires](#security_iam_service-with-iam-roles-tempcreds) | Oui |
| [Autorisations de principal](#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 façon dont Aurora DSQL et les autres AWS services fonctionnent avec la plupart des fonctionnalités IAM, consultez la section [AWS Services compatibles avec IAM dans le Guide de l'utilisateur *IAM*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).
## Politiques basées sur l’identité pour Aurora DSQL
**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 DSQL
Pour voir des exemples de politiques Aurora DSQL basées sur l’identité, consultez [Exemples de politiques basées sur l’identité pour Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## Politiques basées sur une ressource dans Aurora DSQL
**Prend en charge les politiques basées sur les ressources** : oui
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 mandataires peuvent inclure des comptes, des utilisateurs, des rôles, des utilisateurs fédérés ou des services AWS. Les politiques basées sur les ressources sont des politiques en ligne situées dans ce service. Vous ne pouvez pas utiliser les stratégies gérées par AWS depuis IAM dans une stratégie basée sur les ressources.
Pour savoir comment créer et gérer des politiques basées sur les ressources pour les clusters Aurora DSQL, consultez la section Stratégies [basées sur les ressources](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/resource-based-policies.html) pour Aurora DSQL.
## Actions de politique pour Aurora DSQL
**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.
Pour afficher la liste des actions Aurora DSQL, consultez [Actions définies par Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-actions-as-permissions) dans la *Référence de l’autorisation de service*.
Les actions de politique dans Aurora DSQL utilisent le préfixe suivant avant l’action :
```
dsql
```
Pour indiquer plusieurs actions dans une seule déclaration, séparez-les par des virgules.
```
"Action": [
"dsql:action1",
"dsql:action2"
]
```
Pour voir des exemples de politiques Aurora DSQL basées sur l’identité, consultez [Exemples de politiques basées sur l’identité pour Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## Ressources de politique pour Aurora DSQL
**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": "*"
```
Pour consulter la liste des types de ressources Aurora DSQL et leurs caractéristiques ARNs, consultez la section [Ressources définies par Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-resources-for-iam-policies) dans le *Service Authorization Reference*. Pour découvrir les actions avec lesquelles vous pouvez spécifier l’ARN de chaque ressource, consultez [Actions définies par Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-actions-as-permissions).
Pour voir des exemples de politiques Aurora DSQL basées sur l’identité, consultez [Exemples de politiques basées sur l’identité pour Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## Clés de condition d’une politique pour Aurora DSQL
**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*.
Pour afficher la liste des clés de condition Aurora DSQL, consultez [Clés de condition pour Amazon Aurora DSQL](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonauroradsql.html#amazonauroradsql-policy-keys) dans la *Référence de l’autorisation de service*. Pour découvrir les actions et les ressources avec lesquelles vous pouvez utiliser une clé de condition, consultez [Actions définies par Amazon Aurora DSQL](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonauroradsql.html#amazonauroradsql-actions-as-permissions).
Pour voir des exemples de politiques Aurora DSQL basées sur l’identité, consultez [Exemples de politiques basées sur l’identité pour Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## ACLs dans Aurora DSQL
**Supports 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.
## ABAC avec Aurora DSQL
**Prise en charge d’ABAC (balises dans les politiques) :** 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*.
## Utilisation des informations d’identification temporaires avec Aurora DSQL
**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*.
## Autorisations de principal entre services pour Aurora DSQL
**Prend en charge les sessions d’accès direct (FAS) :** 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 la politique relative à la transmission de demandes FAS, consultez la section [Sessions de transmission d’accès](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Rôles de service pour Aurora DSQL
**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 DSQL. Ne modifiez des rôles de service que quand Aurora DSQL vous le conseille.
## Rôles liés à un service pour Aurora DSQL
**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 à un service apparaissent dans votre Compte AWS répertoire 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 sur la création ou la gestion des rôles liés à un service pour Aurora DSQL, consultez [Utilisation de rôles liés à un service pour Aurora DSQL](working-with-service-linked-roles.md).
# Exemples de politiques basées sur l’identité pour Amazon Aurora DSQL
Par défaut, les utilisateurs et les rôles ne sont pas autorisés à créer ni à modifier les ressources Aurora DSQL. Pour octroyer aux utilisateurs des autorisations d’effectuer des actions sur les ressources dont ils ont besoin, un administrateur IAM peut créer des politiques IAM.
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 IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) dans le *Guide de l’utilisateur IAM*.
Pour plus de détails sur les actions et les types de ressources définis par Aurora DSQL, y compris le format de ARNs pour chacun des types de ressources, consultez la section [Actions, ressources et clés de condition pour Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html) dans le manuel *Service Authorization Reference*.
**Topics**
+ [Bonnes pratiques en matière de politiques](#security_iam_service-with-iam-policy-best-practices)
+ [Utilisation de la console Aurora DSQL](#security_iam_id-based-policy-examples-console)
+ [Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Autoriser la gestion du cluster et la connexion aux bases de données](#security_iam_id-based-policy-examples-cluster-management)
+ [Accès aux ressources SQL Aurora basé sur des balises](#security_iam_id-based-policy-examples-tag-based-access)
## Bonnes pratiques en matière de politiques
Les politiques basées sur l’identité déterminent si une personne peut créer, consulter ou supprimer des ressources Aurora DSQL 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 DSQL
Pour accéder à la console Amazon Aurora DSQL, vous devez disposer d’un ensemble minimum d’autorisations. Ces autorisations doivent vous permettre de répertorier et d'afficher des informations détaillées sur les ressources Aurora DSQL de 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 qu’ils tentent d’effectuer.
Pour garantir que les utilisateurs et les rôles peuvent toujours utiliser la console Aurora DSQL, associez également le DSQL Aurora `AmazonAuroraDSQLConsoleFullAccess` ou la politique `AmazonAuroraDSQLReadOnlyAccess` AWS gérée aux entités. 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*.
## Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations
Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
## Autoriser la gestion du cluster et la connexion aux bases de données
La politique suivante accorde à un utilisateur IAM l'autorisation de gérer et de se connecter à un cluster Aurora DSQL spécifique. La politique couvre la gestion du cluster et les actions de connexion à un seul cluster Amazon Resource Name (ARN), tout en autorisant `dsql:ListClusters` l'accès à toutes les ressources, car cette action ne prend pas en charge les autorisations au niveau des ressources.
Cet exemple permet `dsql:DbConnectAdmin` de se connecter au `admin` rôle. Pour vous connecter à un rôle de base de données personnalisé, remplacez `dsql:DbConnectAdmin` par`dsql:DbConnect`. Pour de plus amples informations, veuillez consulter [Authentification et autorisation pour Aurora DSQL](authentication-authorization.md).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowClusterManagement",
"Effect": "Allow",
"Action": [
"dsql:GetCluster",
"dsql:UpdateCluster",
"dsql:DeleteCluster",
"dsql:DbConnectAdmin",
"dsql:TagResource",
"dsql:ListTagsForResource",
"dsql:UntagResource"
],
"Resource": "arn:aws:dsql:*:123456789012:cluster/my-cluster-id"
},
{
"Sid": "AllowListClusters",
"Effect": "Allow",
"Action": "dsql:ListClusters",
"Resource": "*"
}
]
}
```
------
## Accès aux ressources SQL Aurora basé sur des balises
Vous pouvez utiliser des conditions dans votre politique basée sur l'identité pour contrôler l'accès aux ressources SQL Aurora en fonction de balises. L'exemple suivant montre comment créer une politique permettant de visualiser un cluster. Toutefois, la politique n'accorde l'autorisation que si la balise de cluster `Owner` a la valeur du nom d'utilisateur de cet utilisateur. Cette politique accorde également les autorisations nécessaires pour réaliser cette action sur la console.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListClustersInConsole",
"Effect": "Allow",
"Action": "dsql:ListClusters",
"Resource": "*"
},
{
"Sid": "ViewClusterIfOwner",
"Effect": "Allow",
"Action": "dsql:GetCluster",
"Resource": "arn:aws:dsql:*:*:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
}
]
}
```
------
Vous pouvez rattacher cette politique aux utilisateurs IAM de votre compte. Si un utilisateur nommé `richard-roe` tente d'afficher un cluster Aurora DSQL, le cluster doit être balisé `Owner=richard-roe` ou`owner=richard-roe`. Dans le cas contraire, IAM refuse l'accès. La clé de condition d'étiquette `Owner` correspond à la fois à `Owner` et à `owner`, car les noms de clé de condition ne sont pas sensibles à la casse. 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*.
La politique suivante permet à un utilisateur de créer des clusters uniquement s'il étiquette le cluster avec son propre nom d'utilisateur en tant que`Owner`. Il permet également de baliser uniquement les clusters que l'utilisateur possède déjà.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCreateTaggedCluster",
"Effect": "Allow",
"Action": "dsql:CreateCluster",
"Resource": "arn:aws:dsql:*:123456789012:cluster/*",
"Condition": {
"StringEquals": {
"aws:RequestTag/Owner": "${aws:username}"
}
}
},
{
"Sid": "AllowTagOwnedClusters",
"Effect": "Allow",
"Action": "dsql:TagResource",
"Resource": "arn:aws:dsql:*:123456789012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
}
]
}
```
------
# Résolution des problèmes liés à l’identité et à l’accès à Amazon Aurora DSQL
Utilisez les informations suivantes pour identifier et résoudre les problèmes courants que vous pouvez rencontrer lorsque vous travaillez avec Aurora DSQL et IAM.
**Topics**
+ [Je ne suis pas autorisé à effectuer une action dans Aurora DSQL](#security_iam_troubleshoot-no-permissions)
+ [Je ne suis pas autorisé à effectuer iam : PassRole](#security_iam_troubleshoot-passrole)
+ [Je souhaite autoriser des personnes extérieures à moi Compte AWS à accéder à mes ressources Aurora DSQL](#security_iam_troubleshoot-cross-account-access)
## Je ne suis pas autorisé à effectuer une action dans Aurora DSQL
Si vous recevez une erreur qui indique que vous n’êtes pas autorisé à effectuer une action, vos politiques doivent être mises à jour afin de vous permettre d’effectuer l’action.
L’exemple d’erreur suivant se produit lorsque le `mateojackson` tente d’utiliser la console pour afficher les détails d’une ressource `my-dsql-cluster`, mais ne dispose pas des autorisations `GetCluster` nécessaires.
```
User: iam:::user/mateojackson is not authorized to perform: GetCluster on resource: my-dsql-cluster
```
Dans ce cas, la politique qui s’applique à l’utilisateur `mateojackson` doit être mise à jour pour autoriser l’accès à la ressource `my-dsql-cluster` à l’aide de l’action `GetCluster`.
Si vous avez encore besoin d’aide, contactez votre administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je ne suis pas autorisé à effectuer iam : PassRole
Si vous recevez une erreur selon laquelle vous n’êtes pas autorisé à exécuter l’action `iam:PassRole`, vos politiques doivent être mises à jour afin de vous permettre de transmettre un rôle à Aurora DSQL.
Certains vous Services AWS 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 IAM nommé `marymajor` essaie d’utiliser la console pour exécuter une action dans Aurora DSQL. Toutefois, l’action nécessite que le service ait des autorisations accordées par un rôle de service. Mary n'est pas autorisée à transmettre le rôle au service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Dans ce cas, les politiques de Mary doivent être mises à jour pour lui permettre d’exécuter l’action `iam:PassRole`.
Si vous avez besoin d'aide, contactez votre AWS administrateur. Votre administrateur vous a fourni vos informations d’identification de connexion.
## Je souhaite autoriser des personnes extérieures à moi Compte AWS à accéder à mes ressources Aurora DSQL
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 DSQL prend en charge ces fonctionnalités, consultez [Fonctionnement d’Amazon Aurora DSQL avec IAM](security_iam_service-with-iam.md).
+ Pour savoir comment fournir l'accès à vos ressources sur celles Comptes AWS que vous possédez, consultez la section [Fournir l'accès à un utilisateur IAM dans un autre utilisateur Compte AWS 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 tiers Comptes AWS, consultez la section [Fournir un accès à des ressources Comptes AWS détenues 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 en savoir plus sur la différence entre l’utilisation des rôles et des politiques basées sur les ressources pour l’accès intercompte, 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*.
# Politiques basées sur les ressources pour Aurora DSQL
Utilisez des politiques basées sur les ressources pour Aurora DSQL afin de restreindre ou d'accorder l'accès à vos clusters par le biais de documents de politique JSON directement associés aux ressources de votre cluster. Ces politiques fournissent un contrôle précis sur les personnes autorisées à accéder à votre cluster et dans quelles conditions.
Les clusters Aurora DSQL sont accessibles depuis l'Internet public par défaut, l'authentification IAM étant le principal contrôle de sécurité. Les politiques basées sur les ressources vous permettent d'ajouter des restrictions d'accès, notamment pour bloquer l'accès depuis l'Internet public.
Les politiques basées sur les ressources fonctionnent parallèlement aux politiques basées sur l'identité IAM. AWS évalue les deux types de politiques afin de déterminer les autorisations finales pour toute demande d'accès à votre cluster. Par défaut, les clusters Aurora DSQL sont accessibles au sein d'un compte. Si un utilisateur ou un rôle IAM dispose d'autorisations Aurora DSQL, il peut accéder aux clusters sans qu'aucune politique basée sur les ressources ne soit attachée.
**Note**
Les modifications apportées aux politiques basées sur les ressources sont finalement cohérentes et prennent généralement effet en une minute.
*Pour plus d'informations sur les différences entre les politiques basées sur l'identité et les politiques basées sur les ressources, voir Politiques basées sur l'[identité et politiques basées sur les ressources](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) dans le guide de l'utilisateur IAM.*
## Quand utiliser des politiques basées sur les ressources
Les politiques basées sur les ressources sont particulièrement utiles dans les scénarios suivants :
+ *Contrôle d'accès basé sur le réseau* : limitez l'accès en fonction du VPC ou de l'adresse IP d'où proviennent les demandes, ou bloquez complètement l'accès public à Internet. Utilisez des clés de condition telles que `aws:SourceVpc` et `aws:SourceIp` pour contrôler l'accès au réseau.
+ *Plusieurs équipes ou applications* : accordez l'accès au même cluster à plusieurs équipes ou applications. Plutôt que de gérer des politiques IAM individuelles pour chaque principal, vous définissez les règles d'accès une fois sur le cluster.
+ *Accès conditionnel complexe* : contrôlez l'accès en fonction de plusieurs facteurs tels que les attributs réseau, le contexte de la demande et les attributs utilisateur. Vous pouvez combiner plusieurs conditions dans une seule politique.
+ *Gouvernance de sécurité centralisée* : permettez aux propriétaires de clusters de contrôler l'accès à l'aide d'une syntaxe de AWS politique familière qui s'intègre à vos pratiques de sécurité existantes.
**Note**
L'accès entre comptes n'est pas encore pris en charge pour les politiques basées sur les ressources Aurora DSQL, mais il sera disponible dans les futures versions.
Lorsque quelqu'un essaie de se connecter à votre cluster Aurora DSQL, il AWS évalue votre politique basée sur les ressources dans le cadre du contexte d'autorisation, ainsi que toutes les politiques IAM pertinentes, afin de déterminer si la demande doit être autorisée ou rejetée.
Les politiques basées sur les ressources peuvent accorder l'accès aux principaux au sein du même AWS compte que le cluster. Pour les clusters multirégionaux, chaque cluster régional possède sa propre politique basée sur les ressources, permettant des contrôles d'accès spécifiques à la région en cas de besoin.
**Note**
Les clés de contexte des conditions peuvent varier d'une région à l'autre (par exemple, VPC IDs).
**Topics**
+ [Utilisation](#rbp-when-to-use)
+ [Créez avec des politiques](rbp-create-cluster.md)
+ [Ajouter et modifier des politiques](rbp-attach-policy.md)
+ [Afficher la politique](rbp-view-policy.md)
+ [Supprimer la politique](rbp-remove-policy.md)
+ [Exemples de politiques](rbp-examples.md)
+ [Blocage de l'accès public](rbp-block-public-access.md)
+ [Opérations d’API](rbp-api-operations.md)
# Création de clusters avec des politiques basées sur les ressources
Vous pouvez associer des politiques basées sur les ressources lors de la création d'un nouveau cluster afin de garantir que les contrôles d'accès sont en place dès le départ. Chaque cluster peut avoir une seule politique intégrée directement attachée au cluster.
## AWS Console de gestion
**Pour ajouter une politique basée sur les ressources lors de la création du cluster**
1. Connectez-vous à la console de AWS gestion et ouvrez la console Aurora DSQL à l'[https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql)adresse.
1. Choisissez **Créer un cluster**.
1. Configurez le nom de votre cluster, les balises et les paramètres multirégionaux selon vos besoins.
1. Dans la section **Paramètres du cluster**, recherchez l'option de **stratégie basée sur les ressources**.
1. Activez l'option **Ajouter une politique basée sur les ressources**.
1. Entrez votre document de politique dans l'éditeur JSON. Par exemple, pour bloquer l'accès public à Internet :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect",
"dsql:DbConnectAdmin"
],
"Condition": {
"Null": {
"aws:SourceVpc": "true"
}
}
}
]
}
```
1. Vous pouvez utiliser **Modifier la déclaration** ou **Ajouter une nouvelle déclaration** pour élaborer votre politique.
1. Terminez la configuration de cluster restante et choisissez **Create cluster**.
## AWS CLI
Utilisez le `--policy` paramètre lors de la création d'un cluster pour associer une politique en ligne :
```
aws dsql create-cluster --policy '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Principal": {"AWS": "*"},
"Resource": "*",
"Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
"Condition": {
"StringNotEquals": { "aws:SourceVpc": "vpc-123456" }
}
}]
}'
```
## AWS SDKs
------
#### [ Python ]
```
import boto3
import json
client = boto3.client('dsql')
policy = {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Principal": {"AWS": "*"},
"Resource": "*",
"Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
"Condition": {
"StringNotEquals": { "aws:SourceVpc": "vpc-123456" }
}
}]
}
response = client.create_cluster(
policy=json.dumps(policy)
)
print(f"Cluster created: {response['identifier']}")
```
------
#### [ Java ]
```
import software.amazon.awssdk.services.dsql.DsqlClient;
import software.amazon.awssdk.services.dsql.model.CreateClusterRequest;
import software.amazon.awssdk.services.dsql.model.CreateClusterResponse;
DsqlClient client = DsqlClient.create();
String policy = """
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Principal": {"AWS": "*"},
"Resource": "*",
"Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
"Condition": {
"StringNotEquals": { "aws:SourceVpc": "vpc-123456" }
}
}]
}
""";
CreateClusterRequest request = CreateClusterRequest.builder()
.policy(policy)
.build();
CreateClusterResponse response = client.createCluster(request);
System.out.println("Cluster created: " + response.identifier());
```
------
# Ajouter et modifier des politiques basées sur les ressources pour les clusters
## AWS Console de gestion
**Pour ajouter une politique basée sur les ressources à un cluster existant**
1. Connectez-vous à la console de AWS gestion et ouvrez la console Aurora DSQL à l'[https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql)adresse.
1. Choisissez votre cluster dans la liste des clusters pour ouvrir la page des détails du cluster.
1. Sélectionnez l’onglet **Autorisations**.
1. Dans la section **Stratégie basée sur les ressources, choisissez **Ajouter** une politique**.
1. Entrez votre document de politique dans l'éditeur JSON. Vous pouvez utiliser **Modifier la déclaration** ou **Ajouter une nouvelle déclaration** pour élaborer votre politique.
1. Choisissez **Add policy (Ajouter la politique)**.
**Pour modifier une politique basée sur les ressources existante**
1. Connectez-vous à la console de AWS gestion et ouvrez la console Aurora DSQL à l'[https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql)adresse.
1. Choisissez votre cluster dans la liste des clusters pour ouvrir la page des détails du cluster.
1. Sélectionnez l’onglet **Autorisations**.
1. **Dans la section **Stratégie basée sur les ressources**, choisissez Modifier.**
1. Modifiez le document de politique dans l'éditeur JSON. Vous pouvez utiliser **Modifier la déclaration** ou **Ajouter une nouvelle déclaration** pour mettre à jour votre politique.
1. Sélectionnez **Enregistrer les modifications**.
## AWS CLI
Utilisez la `put-cluster-policy` commande pour associer une nouvelle politique ou mettre à jour une politique existante sur un cluster :
```
aws dsql put-cluster-policy --identifier your_cluster_id --policy '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Principal": {"AWS": "*"},
"Resource": "*",
"Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
"Condition": {
"Null": { "aws:SourceVpc": "true" }
}
}]
}'
```
## AWS SDKs
------
#### [ Python ]
```
import boto3
import json
client = boto3.client('dsql')
policy = {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Principal": {"AWS": "*"},
"Resource": "*",
"Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
"Condition": {
"Null": {"aws:SourceVpc": "true"}
}
}]
}
response = client.put_cluster_policy(
identifier='your_cluster_id',
policy=json.dumps(policy)
)
```
------
#### [ Java ]
```
import software.amazon.awssdk.services.dsql.DsqlClient;
import software.amazon.awssdk.services.dsql.model.PutClusterPolicyRequest;
DsqlClient client = DsqlClient.create();
String policy = """
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Principal": {"AWS": "*"},
"Resource": "*",
"Action": ["dsql:DbConnect", "dsql:DbConnectAdmin"],
"Condition": {
"Null": {"aws:SourceVpc": "true"}
}
}]
}
""";
PutClusterPolicyRequest request = PutClusterPolicyRequest.builder()
.identifier("your_cluster_id")
.policy(policy)
.build();
client.putClusterPolicy(request);
```
------
# Afficher les politiques basées sur les ressources
Vous pouvez consulter les politiques basées sur les ressources associées à vos clusters pour comprendre les contrôles d'accès actuellement en place.
## AWS Console de gestion
**Pour consulter les politiques basées sur les ressources**
1. Connectez-vous à la console de AWS gestion et ouvrez la console Aurora DSQL à l'[https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql)adresse.
1. Choisissez votre cluster dans la liste des clusters pour ouvrir la page des détails du cluster.
1. Sélectionnez l’onglet **Autorisations**.
1. Consultez la politique ci-jointe dans la section **Stratégie basée sur les ressources**.
## AWS CLI
Utilisez la `get-cluster-policy` commande pour afficher la politique basée sur les ressources d'un cluster :
```
aws dsql get-cluster-policy --identifier your_cluster_id
```
## AWS SDKs
------
#### [ Python ]
```
import boto3
import json
client = boto3.client('dsql')
response = client.get_cluster_policy(
identifier='your_cluster_id'
)
# Parse and pretty-print the policy
policy = json.loads(response['policy'])
print(json.dumps(policy, indent=2))
```
------
#### [ Java ]
```
import software.amazon.awssdk.services.dsql.DsqlClient;
import software.amazon.awssdk.services.dsql.model.GetClusterPolicyRequest;
import software.amazon.awssdk.services.dsql.model.GetClusterPolicyResponse;
DsqlClient client = DsqlClient.create();
GetClusterPolicyRequest request = GetClusterPolicyRequest.builder()
.identifier("your_cluster_id")
.build();
GetClusterPolicyResponse response = client.getClusterPolicy(request);
System.out.println("Policy: " + response.policy());
```
------
# Supprimer les politiques basées sur les ressources
Vous pouvez supprimer les politiques basées sur les ressources des clusters pour modifier les contrôles d'accès.
**Important**
Lorsque vous supprimez toutes les politiques basées sur les ressources d'un cluster, l'accès est entièrement contrôlé par les politiques basées sur l'identité IAM.
## AWS Console de gestion
**Pour supprimer une politique basée sur les ressources**
1. Connectez-vous à la console de AWS gestion et ouvrez la console Aurora DSQL à l'[https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql)adresse.
1. Choisissez votre cluster dans la liste des clusters pour ouvrir la page des détails du cluster.
1. Sélectionnez l’onglet **Autorisations**.
1. **Dans la section **Stratégie basée sur les ressources**, choisissez Supprimer.**
1. Dans la boîte de dialogue de confirmation, tapez **confirm** pour confirmer la suppression.
1. Sélectionnez **Delete (Supprimer)**.
## AWS CLI
Utilisez la `delete-cluster-policy` commande pour supprimer une politique d'un cluster :
```
aws dsql delete-cluster-policy --identifier your_cluster_id
```
## AWS SDKs
------
#### [ Python ]
```
import boto3
client = boto3.client('dsql')
response = client.delete_cluster_policy(
identifier='your_cluster_id'
)
print("Policy deleted successfully")
```
------
#### [ Java ]
```
import software.amazon.awssdk.services.dsql.DsqlClient;
import software.amazon.awssdk.services.dsql.model.DeleteClusterPolicyRequest;
DsqlClient client = DsqlClient.create();
DeleteClusterPolicyRequest request = DeleteClusterPolicyRequest.builder()
.identifier("your_cluster_id")
.build();
client.deleteClusterPolicy(request);
System.out.println("Policy deleted successfully");
```
------
# Exemples de politiques communes basées sur les ressources
Ces exemples présentent des modèles courants de contrôle de l'accès à vos clusters Aurora DSQL. Vous pouvez combiner et modifier ces modèles pour répondre à vos besoins d'accès spécifiques.
## Bloquer l'accès public à Internet
Cette politique bloque les connexions à vos clusters Aurora DSQL depuis l'Internet public (non VPC). La politique ne précise pas à partir de quel VPC les clients peuvent se connecter, mais seulement qu'ils doivent se connecter à partir d'un VPC. Pour limiter l'accès à un VPC spécifique, utilisez-le `aws:SourceVpc` avec l'opérateur de `StringEquals` condition.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect",
"dsql:DbConnectAdmin"
],
"Condition": {
"Null": {
"aws:SourceVpc": "true"
}
}
}
]
}
```
**Note**
Cet exemple est utilisé uniquement `aws:SourceVpc` pour vérifier les connexions VPC. Les touches de `aws:SourceVpce` condition `aws:VpcSourceIp` et fournissent une granularité supplémentaire mais ne sont pas requises pour le contrôle d'accès de base réservé aux VPC.
Pour fournir une exception pour des rôles spécifiques, utilisez plutôt cette politique :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAccessFromOutsideVPC",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect",
"dsql:DbConnectAdmin"
],
"Condition": {
"Null": {
"aws:SourceVpc": "true"
},
"StringNotEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::123456789012:role/ExceptionRole",
"arn:aws:iam::123456789012:role/AnotherExceptionRole"
]
}
}
}
]
}
```
## Restreindre l'accès à AWS l'organisation
Cette politique restreint l'accès aux principaux au sein d'une AWS organisation :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": [
"dsql:DbConnect",
"dsql:DbConnectAdmin"
],
"Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/mydsqlclusterid0123456789a",
"Condition": {
"StringNotEquals": {
"aws:PrincipalOrgID": "o-exampleorgid"
}
}
}
]
}
```
## Restreindre l'accès à une unité organisationnelle spécifique
Cette politique restreint l'accès aux principaux au sein d'une unité organisationnelle (UO) spécifique d'une AWS organisation, offrant ainsi un contrôle plus précis que l'accès à l'échelle de l'organisation :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": [
"dsql:DbConnect"
],
"Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/mydsqlclusterid0123456789a",
"Condition": {
"StringNotLike": {
"aws:PrincipalOrgPaths": "o-exampleorgid/r-examplerootid/ou-exampleouid/*"
}
}
}
]
}
```
## Politiques relatives aux clusters multirégionaux
Pour les clusters multirégionaux, chaque cluster régional maintient sa propre politique de ressources, ce qui permet des contrôles spécifiques à la région. Voici un exemple de politiques différentes par région :
*Politique us-east-1 :*
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect"
],
"Condition": {
"StringNotEquals": {
"aws:SourceVpc": "vpc-east1-id"
},
"Null": {
"aws:SourceVpc": "true"
}
}
}
]
}
```
*Politique us-east-2 :*
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect"
],
"Condition": {
"StringEquals": {
"aws:SourceVpc": "vpc-east2-id"
}
}
}
]
}
```
**Note**
Les clés de contexte des conditions peuvent varier entre Régions AWS elles (par exemple, VPC IDs).
# Blocage de l'accès public à l'aide de politiques basées sur les ressources dans Aurora DSQL
Le blocage de l'accès public (BPA) est une fonctionnalité qui identifie et empêche l'attachement de politiques basées sur les ressources qui accordent un accès public à vos clusters Aurora DSQL sur l'ensemble de vos comptes. AWS Avec le BPA, vous pouvez empêcher l'accès public à vos ressources SQL Aurora. Le BPA effectue des vérifications lors de la création ou de la modification d'une politique basée sur les ressources et contribue à améliorer votre niveau de sécurité avec Aurora DSQL.
BPA utilise un [raisonnement automatisé](https://aws.amazon.com/what-is/automated-reasoning/) pour analyser l’accès accordé par votre politique basée sur les ressources, et vous alerte si de telles autorisations sont détectées au moment de l’administration d’une politique basée sur les ressources. L’analyse vérifie l’accès à toutes les déclarations de politique basées sur les ressources, aux actions et à l’ensemble de clés de condition utilisées dans vos politiques.
**Important**
Le BPA contribue à protéger vos ressources en empêchant l'accès public par le biais de politiques basées sur les ressources directement associées à vos ressources Aurora DSQL, telles que les clusters. En plus d’utiliser BPA, examinez attentivement les politiques suivantes pour vous assurer qu’elles n’accordent pas d’accès public :
Politiques basées sur l'identité associées aux AWS principaux associés (par exemple, les rôles IAM)
Politiques basées sur les AWS ressources associées (par exemple, AWS clés du service de gestion des clés (KMS))
Vous devez vous assurer que le [principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) n’inclut aucune entrée `*` ou que l’une des clés de condition spécifiées limite l’accès des principaux à la ressource. Si la politique basée sur les ressources accorde un accès public à votre cluster sur plusieurs AWS comptes, Aurora DSQL vous empêchera de créer ou de modifier la politique jusqu'à ce que la spécification contenue dans la stratégie soit corrigée et considérée comme non publique.
Vous pouvez rendre une politique non publique en spécifiant un ou plusieurs principaux à l’intérieur du bloc `Principal`. L’exemple de politique basée sur les ressources suivant bloque l’accès public en spécifiant deux principaux.
```
{
"Effect": "Allow",
"Principal": {
"AWS": [
"123456789012",
"111122223333"
]
},
"Action": "dsql:*",
"Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/cluster-id"
}
```
Les politiques qui restreignent l’accès en spécifiant certaines clés de condition ne sont pas non plus considérées comme publiques. Parallèlement à l’évaluation du principal spécifié dans la politique basée sur les ressources, les [clés de condition fiables](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) suivantes sont utilisées pour terminer l’évaluation d’une politique basée sur les ressources pour un accès non public :
+ `aws:PrincipalAccount`
+ `aws:PrincipalArn`
+ `aws:PrincipalOrgID`
+ `aws:PrincipalOrgPaths`
+ `aws:SourceAccount`
+ `aws:SourceArn`
+ `aws:SourceVpc`
+ `aws:SourceVpce`
+ `aws:UserId`
+ `aws:PrincipalServiceName`
+ `aws:PrincipalServiceNamesList`
+ `aws:PrincipalIsAWSService`
+ `aws:Ec2InstanceSourceVpc`
+ `aws:SourceOrgID`
+ `aws:SourceOrgPaths`
En outre, pour qu’une politique basée sur les ressources ne soit pas publique, les valeurs d’Amazon Resource Name (ARN) et les clés de chaîne ne doivent pas contenir de caractères génériques ni de variables. Si votre politique basée sur les ressources utilise la clé `aws:PrincipalIsAWSService`, vous devez vous assurer que vous avez défini la valeur de la clé sur true.
La politique suivante limite l’accès à l’utilisateur `Ben` dans le compte spécifié. La condition impose une contrainte à `Principal` et ne doit pas être considérée comme publique.
```
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "dsql:*",
"Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/cluster-id",
"Condition": {
"StringEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:user/Ben"
}
}
}
```
L’exemple suivant d’une politique basée sur des ressources non publique limite l’utilisation de `sourceVPC` avec l’opérateur `StringEquals`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "dsql:*",
"Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/cluster-id",
"Condition": {
"StringEquals": {
"aws:SourceVpc": [
"vpc-91237329"
]
}
}
}
]
}
```
# Opérations d'API SQL Aurora et politiques basées sur les ressources
Les politiques basées sur les ressources dans Aurora DSQL contrôlent l'accès à des opérations d'API spécifiques. Les sections suivantes répertorient toutes les opérations de l'API Aurora DSQL organisées par catégorie, avec une indication de celles qui prennent en charge les politiques basées sur les ressources.
La colonne *Supports RBP* indique si le fonctionnement de l'API est soumis à une évaluation de politique basée sur les ressources lorsqu'une politique est attachée au cluster.
## Tag APIs
| Opération API | Description | Supporte le RBP |
| --- | --- | --- |
| [ListTagsForResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_ListTagsForResource.html) | Répertorie les balises d'une ressource Aurora DSQL | Oui |
| [TagResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_TagResource.html) | Ajoute des balises à une ressource SQL Aurora | Oui |
| [UntagResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_UntagResource.html) | Supprime les balises d'une ressource SQL Aurora | Oui |
## Gestion des clusters APIs
| Opération API | Description | Supporte le RBP |
| --- | --- | --- |
| [CreateCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_CreateCluster.html) | Crée un nouveau cluster. | Non |
| [DeleteCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_DeleteCluster.html) | Supprime un cluster | Oui |
| [GetCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetCluster.html) | Récupère des informations sur un cluster | Oui |
| [GetVpcEndpointServiceName](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetVpcEndpointServiceName.html) | Récupère le nom du service de point de terminaison VPC pour un cluster | Oui |
| [ListClusters](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_ListClusters.html) | Répertorie les clusters de votre compte | Non |
| [UpdateCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_UpdateCluster.html) | Met à jour la configuration d'un cluster | Oui |
## Propriété multirégionale APIs
| Opération API | Description | Supporte le RBP |
| --- | --- | --- |
| [AddPeerCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_AddPeerCluster.html) | Ajoute un cluster homologue à une configuration multirégionale | Oui |
| [PutMultiRegionProperties](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutMultiRegionProperties.html) | Définit les propriétés multirégionales d'un cluster | Oui |
| [PutWitnessRegion](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutWitnessRegion.html) | Définit la région témoin pour un cluster multirégional | Oui |
## Politique basée sur les ressources APIs
| Opération API | Description | Supporte le RBP |
| --- | --- | --- |
| [DeleteClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_DeleteClusterPolicy.html) | Supprime la politique basée sur les ressources d'un cluster | Oui |
| [GetClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetClusterPolicy.html) | Récupère la politique basée sur les ressources pour un cluster | Oui |
| [PutClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutClusterPolicy.html) | Crée ou met à jour la politique basée sur les ressources pour un cluster | Oui |
## AWS Fault Injection Service APIs
| Opération API | Description | Supporte le RBP |
| --- | --- | --- |
| [InjectError](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_InjectError.html) | Injecte des erreurs pour les tests d'injection de défauts | Non |
## Backup et restauration APIs
| Opération API | Description | Supporte le RBP |
| --- | --- | --- |
| [GetBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetBackupJob.html) | Récupère les informations relatives à une tâche de sauvegarde | Non |
| [GetRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetRestoreJob.html) | Récupère les informations relatives à une tâche de restauration | Non |
| [StartBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StartBackupJob.html) | Démarre une tâche de sauvegarde pour un cluster | Oui |
| [StartRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StartRestoreJob.html) | Démarre une tâche de restauration à partir d'une sauvegarde | Non |
| [StopBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StopBackupJob.html) | Arrête une tâche de sauvegarde en cours | Non |
| [StopRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StopRestoreJob.html) | Arrête une tâche de restauration en cours | Non |
# Utilisation de rôles liés à un service pour Aurora DSQL
Aurora DSQL 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.html#id_roles_terms-and-concepts) (IAM). Un rôle lié à un service est un type unique de rôle IAM lié directement à Aurora DSQL. Les rôles liés à un service sont prédéfinis par Aurora DSQL et incluent toutes les autorisations dont le service a besoin pour appeler au Services AWS nom de votre cluster Aurora DSQL.
Un rôle lié à un service simplifie la configuration des processus, car vous n’avez pas besoin d’ajouter manuellement les autorisations requises pour utiliser Aurora DSQL. Lorsque vous créez un cluster, Aurora DSQL crée automatiquement le rôle lié à un service pour vous. Vous pouvez supprimer le rôle lié à un service uniquement après avoir supprimé tous les clusters. Vos ressources Aurora DSQL sont ainsi protégées, car vous ne pouvez pas involontairement supprimer les autorisations nécessaires pour y accéder.
Pour plus d’informations sur les autres services qui prennent en charge les rôles liés à un service, reportez-vous aux [Services AWS qui fonctionnent avec IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) et recherchez les services comportant un **Oui** dans la colonne **Rôle lié à un service**. Choisissez un **Oui** ayant un lien permettant de consulter les détails du rôle pour ce service.
Les rôles liés à un service sont disponibles dans toutes les régions Aurora DSQL prises en charge.
## Autorisations des rôles liés à un service pour Aurora DSQL
Aurora DSQL utilise le rôle lié à un service nommé `AWSServiceRoleForAuroraDsql` — Permet à Amazon Aurora DSQL de créer et de gérer des AWS ressources en votre nom. Ce rôle lié à un service est attaché à la politique gérée suivante : [AuroraDsqlServiceLinkedRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDsqlServiceLinkedRolePolicy.html).
**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. Il se peut que vous rencontriez le message d’erreur suivant : `You don't have the permissions to create an Amazon Aurora DSQL service-linked role`. Si vous voyez ce message, vérifiez que vous avez activé les autorisations suivantes :
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateDsqlServiceLinkedRole",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:AWSServiceName": "dsql.amazonaws.com"
}
}
}
]
}
```
Pour plus d’informations, consultez [Autorisations des rôles liés à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions.html).
## Créer un rôle lié à un service
Il n'est pas nécessaire de créer manuellement un rôle DSQLService LinkedRolePolicy lié à un service Aurora. Aurora DSQL crée automatiquement le rôle lié au service pour vous. Si le rôle DSQLService LinkedRolePolicy lié au service Aurora a été supprimé de votre compte, Aurora DSQL crée le rôle lorsque vous créez un nouveau cluster Aurora DSQL.
## Modification d’un rôle lié à un service
Aurora DSQL ne vous permet pas de modifier le rôle lié au DSQLService LinkedRolePolicy service Aurora. Une fois que vous avez 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 au rôle. Vous pouvez toutefois modifier la description du rôle à l'aide de la console IAM, du AWS Command Line Interface (AWS CLI) ou de l'API IAM.
## Supprimer un rôle lié à un service
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.
Avant de pouvoir supprimer un rôle lié à un service pour un compte, vous devez supprimer tous les clusters du compte.
Vous pouvez utiliser la console IAM AWS CLI, ou l'API IAM pour supprimer un rôle lié à un service. Pour plus d’informations, consultez [Création d’un rôle lié à un service](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#delete-service-linked-role) dans le Guide de l’utilisateur IAM.
## Régions prises en charge pour les rôles liés à un service Aurora DSQL
Aurora DSQL prend en charge l’utilisation des rôles liés à un service dans toutes les régions où le service est disponible. Pour plus d’informations, consultez [Régions et points de terminaison AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# Utilisation des clés de condition IAM avec Amazon Aurora DSQL
Lorsque vous accordez des autorisations dans Aurora DSQL, vous pouvez spécifier des conditions pour déterminer comment une politique d’autorisation doit prendre effet. Les exemples suivants montrent comment vous pouvez utiliser des clés de condition dans les politiques d’autorisation Aurora DSQL.
## Exemple 1 : accorder l'autorisation de créer un cluster dans un environnement spécifique Région AWS
La politique suivante accorde l’autorisation de créer des clusters dans les régions USA Est (Virginie du Nord) et USA Est (Ohio). Cette politique utilise l’ARN de la ressource pour limiter les régions autorisées. Aurora DSQL ne peut donc créer des clusters que si cet ARN est spécifié dans la section `Resource` de la politique.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": ["dsql:CreateCluster"],
"Resource": [
"arn:aws:dsql:us-east-1:*:cluster/*",
"arn:aws:dsql:us-east-2:*:cluster/*"
],
"Effect": "Allow"
}
]
}
```
------
## Exemple 2 : Accorder l'autorisation de créer un cluster multirégional dans des domaines spécifiques Région AWS
La politique suivante accorde l’autorisation de créer des clusters multi-régions dans les régions USA Est (Virginie du Nord) et USA Est (Ohio). Cette politique utilise l’ARN de la ressource pour limiter les régions autorisées. Aurora DSQL ne peut donc créer des clusters multi-régions que si cet ARN est spécifié dans la section `Resource` de la politique. Notez que la création de clusters multi-régions nécessite également les autorisations `PutMultiRegionProperties`, `PutWitnessRegion` et `AddPeerCluster` dans chaque région spécifiée.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dsql:CreateCluster",
"dsql:PutMultiRegionProperties",
"dsql:PutWitnessRegion",
"dsql:AddPeerCluster"
],
"Resource": [
"arn:aws:dsql:us-east-1:123456789012:cluster/*",
"arn:aws:dsql:us-east-2:123456789012:cluster/*"
]
}
]
}
```
------
## Exemple 3 : accorder l’autorisation de créer un cluster multi-régions dans une région témoin spécifique
La politique suivante utilise une clé de condition `dsql:WitnessRegion` Aurora DSQL et permet à un utilisateur de créer des clusters multi-régions avec une région témoin dans la région USA Ouest (Oregon). Si vous ne spécifiez pas la condition `dsql:WitnessRegion`, vous pouvez utiliser n’importe quelle région comme région témoin.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dsql:CreateCluster",
"dsql:PutMultiRegionProperties",
"dsql:AddPeerCluster"
],
"Resource": "arn:aws:dsql:*:123456789012:cluster/*"
},
{
"Effect": "Allow",
"Action": [
"dsql:PutWitnessRegion"
],
"Resource": "arn:aws:dsql:*:123456789012:cluster/*",
"Condition": {
"StringEquals": {
"dsql:WitnessRegion": [
"us-west-2"
]
}
}
}
]
}
```
------
# Réponse aux incidents dans Amazon Aurora DSQL
Chez AWS, la sécurité est la priorité numéro 1. Dans le cadre du modèle de responsabilité partagée du AWS cloud, AWS gère un centre de données, un réseau et une architecture logicielle qui répondent aux exigences des organisations les plus sensibles en matière de sécurité. AWS est responsable de toute réponse aux incidents concernant le service Amazon Aurora DSQL lui-même. De plus, en tant que AWS client, vous partagez la responsabilité du maintien de la sécurité dans le cloud. Cela signifie que vous contrôlez la sécurité que vous choisissez de mettre en œuvre à partir des AWS outils et des fonctionnalités auxquels vous avez accès. En outre, vous êtes responsable de la réponse aux incidents dans le cadre du modèle de responsabilité partagée.
En établissant une base de sécurité répondant aux objectifs de vos applications exécutées dans le cloud, vous êtes en mesure de détecter les écarts auxquels vous pouvez réagir. Pour vous aider à comprendre l’impact de la réponse aux incidents et de vos choix sur les objectifs de votre entreprise, nous vous encourageons à consulter les ressources suivantes :
+ [AWS Guide de réponse aux incidents de sécurité](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
+ [AWS Meilleures pratiques en matière de sécurité, d'identité et de conformité](https://aws.amazon.com/architecture/security-identity-compliance/)
+ [Livre blanc sur la perspective de sécurité du cadre d'adoption du AWS cloud (CAF)](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/security-perspective.html)
[Amazon GuardDuty](https://aws.amazon.com/guardduty/) est un service géré de détection des menaces qui surveille en permanence les comportements malveillants ou non autorisés afin d'aider les clients à protéger Comptes AWS leur charge de travail et à identifier les activités suspectes potentielles avant qu'elles ne dégénèrent en incident. Il surveille les activités telles que les appels d’API inhabituels ou les déploiements potentiellement non autorisés indiquant une possible compromission du compte ou des ressources ou une reconnaissance par des acteurs malveillants. Par exemple, Amazon GuardDuty est en mesure de détecter des activités suspectes dans Amazon Aurora DSQL APIs, comme la connexion d'un utilisateur depuis un nouvel emplacement et la création d'un nouveau cluster.
# Validation de la conformité pour Amazon Aurora DSQL
Pour savoir si un [programme Services AWS de conformité Service AWS s'inscrit dans le champ d'application de programmes de conformité](https://aws.amazon.com/compliance/services-in-scope/) spécifiques, consultez Services AWS la section de conformité et sélectionnez le programme de conformité qui vous intéresse. Pour des informations générales, voir Programmes de [AWS conformité Programmes AWS](https://aws.amazon.com/compliance/programs/) de .
Vous pouvez télécharger des rapports d'audit tiers à l'aide de AWS Artifact. Pour plus d'informations, voir [Téléchargement de rapports dans AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Votre responsabilité en matière de conformité lors de l'utilisation Services AWS est déterminée par la sensibilité de vos données, les objectifs de conformité de votre entreprise et les lois et réglementations applicables. Pour plus d'informations sur votre responsabilité en matière de conformité lors de l'utilisation Services AWS, consultez [AWS la documentation de sécurité](https://docs.aws.amazon.com/security/).
# Résilience dans Amazon Aurora DSQL
L'infrastructure AWS mondiale est construite autour Régions AWS de zones de disponibilité (AZ). Régions AWS fournissent plusieurs zones de disponibilité physiquement séparées et isolées, connectées par un réseau à faible latence, à 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 à l’autre sans interruption. Les zones de disponibilité sont davantage disponibles, tolérantes aux pannes et ont une plus grande capacité de mise à l’échelle que les infrastructures traditionnelles à un ou plusieurs centres de données. Aurora DSQL est conçu pour que vous puissiez tirer parti de l'infrastructure AWS régionale tout en fournissant la meilleure disponibilité de base de données. Par défaut, les clusters à une seule région d’Aurora DSQL offrent une disponibilité multi-AZ, ce qui permet de tolérer les défaillances majeures des composants et les perturbations de l’infrastructure susceptibles d’avoir un impact sur l’accès à une zone de disponibilité complète. Les clusters multi-régions offrent tous les avantages de la résilience multi-AZ tout en garantissant une disponibilité des bases de données très constante, même dans les cas où la Région AWS n’est pas accessible aux clients de l’application.
Pour plus d'informations sur les zones de disponibilité Régions AWS et les zones de disponibilité, consultez la section [Infrastructure AWS globale](https://aws.amazon.com/about-aws/global-infrastructure/).
Outre l'infrastructure AWS globale, Aurora DSQL propose plusieurs fonctionnalités pour répondre à vos besoins en matière de résilience et de sauvegarde des données.
## Sauvegarde et restauration
Aurora DSQL prend en charge la sauvegarde et la restauration avec Console AWS Backup. Vous pouvez effectuer une sauvegarde et une restauration complètes pour vos clusters à une seule région ou multi-régions. Pour de plus amples informations, veuillez consulter [Sauvegarde et restauration pour Amazon Aurora DSQLSauvegarde et restauration](backup-aurora-dsql.md).
## Réplication
De par sa conception, Aurora DSQL valide toutes les transactions d'écriture dans un journal de transactions distribué et réplique de manière synchrone toutes les données du journal validées dans des répliques de stockage utilisateur en trois exemplaires. AZs Les clusters multi-régions fournissent des fonctionnalités complètes de réplication entre plusieurs régions entre les régions de lecture et d’écriture.
Une région témoin désignée prend en charge les écritures dans le journal des transactions uniquement et ne consomme pas d’espace de stockage. Les régions témoins ne disposent pas d’un point de terminaison. Cela signifie que les régions témoins ne stockent que des journaux de transactions chiffrés, ne nécessitent aucune administration ni configuration et ne sont pas accessibles aux utilisateurs. Si la région témoin est altérée, cela n'a aucun impact sur la disponibilité du cluster. Les transactions d'écriture peuvent connaître une légère augmentation de la latence jusqu'à ce que la région témoin se rétablisse.
Les journaux de transactions et le stockage utilisateur Aurora DSQL sont distribués avec toutes les données présentées aux processeurs de requêtes Aurora DSQL sous la forme d’un volume logique unique. Aurora DSQL divise, fusionne et réplique automatiquement les données en fonction de la plage de clés primaires de la base de données et des modèles d’accès. Aurora DSQL met à l’échelle automatiquement les réplicas en lecture, à la hausse comme à la baisse, en fonction de la fréquence d’accès en lecture.
Les réplicas de stockage en cluster sont répartis sur une flotte de stockage à locataires multiples. Si un composant ou une AZ est endommagé, Aurora DSQL redirige automatiquement l’accès aux composants survivants et répare de manière asynchrone les réplicas manquants. Une fois qu’Aurora DSQL a corrigé les réplicas défectueux, Aurora DSQL les ajoute automatiquement au quorum de stockage et les met à la disposition de votre cluster.
## Haute disponibilité
Par défaut, les clusters à une seule région et multi-régions dans Aurora DSQL sont actifs-actifs, et il n’est pas nécessaire de provisionner, configurer ni reconfigurer manuellement des clusters. Aurora DSQL automatise entièrement la restauration des clusters, ce qui élimine le besoin d’opérations de basculement principales-secondaires traditionnelles. La réplication est toujours synchrone et effectuée en plusieurs AZs exemplaires. Il n'y a donc aucun risque de perte de données en cas de retard de réplication ou de basculement vers une base de données secondaire asynchrone en cas de reprise après échec.
Les clusters à région unique fournissent un point de terminaison redondant multi-AZ qui permet automatiquement un accès simultané avec une forte cohérence des données entre les trois. AZs Cela signifie que les répliques de stockage utilisateur sur l'un de ces trois AZs types renvoient toujours le même résultat à un ou plusieurs lecteurs et sont toujours disponibles pour recevoir des écritures. Cette forte cohérence et cette résilience multi-AZ sont disponibles dans toutes les régions pour les clusters multi-régions Aurora DSQL. Cela signifie que les clusters multi-régions fournissent deux points de terminaison régionaux très cohérents, de sorte que les clients peuvent lire ou écrire sans distinction dans l’une ou l’autre région sans aucun délai de réplication lors de la validation.
Aurora DSQL assure une disponibilité de 99,99 % pour les clusters à une seule région et de 99,999 % pour les clusters multi-régions.
## Test d’injection de pannes
Amazon Aurora DSQL s'intègre à AWS Fault Injection Service (AWS FIS), un service entièrement géré permettant d'exécuter des expériences d'injection contrôlée de défauts afin d'améliorer la résilience d'une application. En utilisant AWS FIS, vous pouvez :
+ Créer des modèles d’expérimentation qui définissent des scénarios de pannes spécifiques
+ Injecter les pannes (taux d’erreur de connexion au cluster élevés) pour valider les mécanismes de gestion des erreurs et de restauration des applications
+ Testez le comportement des applications multirégionales pour valider le transfert du trafic des applications entre les Régions AWS périodes où le taux d'erreur de connexion Région AWS est élevé
Par exemple, dans un cluster multi-régions couvrant les régions USA Est (Virginie du Nord) et USA Est (Ohio), vous pouvez exécuter une expérience dans la région USA Est (Ohio) pour y tester les pannes pendant que la région USA Est (Virginie du Nord) poursuit ses activités normales. Ces tests contrôlés vous aident à identifier et à résoudre les problèmes potentiels avant qu’ils n’affectent les charges de travail de production.
Consultez la section [Objectifs d'action](https://docs.aws.amazon.com/fis/latest/userguide/action-sequence.html#action-targets) dans le *guide de AWS FIS l'utilisateur* pour obtenir la liste complète des actions AWS FIS prises en charge.
Pour plus d'informations sur les actions Amazon Aurora DSQL disponibles dans AWS FIS, consultez la [référence des actions Aurora DSQL](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#dsql-actions-reference) dans le guide de l'*AWS FIS utilisateur*.
Pour commencer à exécuter des expériences d’injection de pannes, consultez [Planification de vos expériences AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-planning.html) dans le *guide de l’utilisateur AWS FIS *.
# Sécurité de l’infrastructure dans Amazon Aurora DSQL
En tant que service géré, Amazon Aurora DSQL est protégé par les procédures de sécurité du réseau AWS mondial décrites dans la section [Meilleures pratiques en matière de sécurité, d'identité et de conformité](https://aws.amazon.com/architecture/security-identity-compliance).
Vous utilisez des appels d'API AWS publiés pour accéder à Aurora DSQL via le réseau. Les clients doivent prendre en charge le protocole TLS (Transport Layer Security) 1.2 ou version ultérieure. Les clients doivent aussi prendre en charge les 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.
# Gestion et connexion aux clusters SQL Amazon Aurora à l'aide de AWS PrivateLink
Avec AWS PrivateLink Amazon Aurora DSQL, vous pouvez configurer des points de terminaison Amazon VPC (points de terminaison d'interface) dans votre Amazon Virtual Private Cloud. Ces points de terminaison sont directement accessibles depuis des applications installées sur site via Amazon VPC et/ou via un Direct Connect autre système de peering Région AWS via Amazon VPC. En utilisant AWS PrivateLink et en interfacant les points de terminaison, vous pouvez simplifier la connectivité réseau privé entre vos applications et Aurora DSQL.
Les applications de votre Amazon VPC peuvent accéder à Aurora DSQL via les points de terminaison de l’interface Amazon VPC sans avoir besoin d’adresses IP publiques.
Les points de terminaison d'interface sont représentés par une ou plusieurs interfaces réseau élastiques (ENIs) auxquelles des adresses IP privées sont attribuées à partir de sous-réseaux de votre Amazon VPC. Les demandes adressées à Aurora DSQL via les points de terminaison de l'interface restent sur le AWS réseau. Pour plus d’informations sur la façon de connecter votre Amazon VPC à votre réseau sur site, consultez le [Guide de l’utilisateur Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/) et le Guide de l’utilisateur [VPN AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html).
Pour des informations générales sur les points de terminaison d'interface, consultez la section [Accès à un AWS service à l'aide d'un point de terminaison Amazon VPC d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) dans [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink)le guide de l'utilisateur.
## Types de points de terminaison Amazon VPC pour Aurora DSQL
Aurora DSQL nécessite deux types de points de AWS PrivateLink terminaison différents.
1. *Point de terminaison de gestion* : ce point de terminaison est utilisé pour les opérations administratives telles que `get`, `create`, `update`, `delete` et `list` sur les clusters Aurora DSQL. Consultez [Gestion des clusters SQL Aurora à l'aide de AWS PrivateLink](#managing-dsql-clusters-using-privatelink).
1. *Point de terminaison de connexion* : ce point de terminaison est utilisé pour la connexion aux clusters Aurora DSQL via les clients PostgreSQL. Consultez [Connexion aux clusters SQL Aurora à l'aide de AWS PrivateLink](#privatelink-connecting-clusters).
## Considérations relatives à l'utilisation AWS PrivateLink d'Aurora DSQL
Les considérations relatives à Amazon VPC s'appliquent à AWS PrivateLink Aurora DSQL. Pour plus d'informations, consultez la section [Accès à un AWS service à l'aide d'un point de terminaison VPC d'interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#vpce-interface-limitations) et de [AWS PrivateLink quotas](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-limits-endpoints.html) dans le AWS PrivateLink Guide.
## Gestion des clusters SQL Aurora à l'aide de AWS PrivateLink
Vous pouvez utiliser le AWS Command Line Interface ou les kits de développement AWS logiciel (SDKs) pour gérer les clusters Aurora DSQL via les points de terminaison de l'interface Aurora DSQL.
### Création d’un point de terminaison Amazon VPC
Pour créer un point de terminaison d'interface Amazon VPC, consultez la section [Créer un point de terminaison Amazon VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) dans le Guide. AWS PrivateLink
```
aws ec2 create-vpc-endpoint \
--region region \
--service-name com.amazonaws.region.dsql \
--vpc-id your-vpc-id \
--subnet-ids your-subnet-id \
--vpc-endpoint-type Interface \
--security-group-ids client-sg-id \
```
Pour utiliser le nom DNS régional par défaut pour les demandes d’API Aurora DSQL, ne désactivez pas le DNS privé lorsque vous créez le point de terminaison de l’interface Aurora DSQL. Lorsque le DNS privé est activé, les demandes adressées au service Aurora DSQL depuis votre Amazon VPC sont automatiquement résolues vers l’adresse IP privée du point de terminaison Amazon VPC, plutôt que vers le nom DNS public. Lorsque le DNS privé est activé, les demandes Aurora DSQL effectuées au sein de votre Amazon VPC sont automatiquement résolues vers votre point de terminaison Amazon VPC.
Si le DNS privé n'est pas activé, utilisez les `--endpoint-url` paramètres `--region` et avec les AWS CLI commandes pour gérer les clusters Aurora DSQL via les points de terminaison de l'interface Aurora DSQL.
### Établissement de la liste des clusters à l’aide d’une URL de point de terminaison
Dans l'exemple suivant, remplacez le nom DNS Région AWS `us-east-1` et le nom DNS de l'ID du point de terminaison Amazon VPC `vpce-1a2b3c4d-5e6f.dsql.us-east-1.vpce.amazonaws.com` par vos propres informations.
```
aws dsql --region us-east-1 --endpoint-url https://vpce-1a2b3c4d-5e6f.dsql.us-east-1.vpce.amazonaws.com list-clusters
```
### Opérations d’API
Reportez-vous à la [référence de l’API Aurora DSQL](CHAP_api_reference.md) pour obtenir de la documentation sur la gestion des ressources dans Aurora DSQL.
### Gestion des politiques de point de terminaison
En testant et en configurant de manière approfondie les politiques relatives aux points de terminaison Amazon VPC, vous pouvez garantir que votre cluster Aurora DSQL est sécurisé et conforme aux exigences de gouvernance et de contrôle d’accès spécifiques de votre organisation.
**Exemple : stratégie d’accès complète à Aurora DSQL**
La stratégie suivante accorde l’accès total à toutes les actions et ressources Aurora DSQL via le point de terminaison Amazon VPC spécifié.
```
aws ec2 modify-vpc-endpoint \
--vpc-endpoint-id vpce-xxxxxxxxxxxxxxxxx \
--region region \
--policy-document '{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "dsql:*",
"Resource": "*"
}
]
}'
```
**Exemple : stratégie d’accès restreinte à Aurora DSQL**
La stratégie suivante autorise uniquement ces actions Aurora DSQL.
+ `CreateCluster`
+ `GetCluster`
+ `ListClusters`
Toutes les autres actions Aurora DSQL sont refusées.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": [
"dsql:CreateCluster",
"dsql:GetCluster",
"dsql:ListClusters"
],
"Resource": "*"
}
]
}
```
------
## Connexion aux clusters SQL Aurora à l'aide de AWS PrivateLink
Une fois que votre AWS PrivateLink point de terminaison est configuré et actif, vous pouvez vous connecter à votre cluster Aurora DSQL à l'aide d'un client PostgreSQL. Les instructions de connexion ci-dessous décrivent les étapes à suivre pour créer le nom d'hôte approprié pour la connexion via le AWS PrivateLink point de terminaison.
### Configuration d'un point de terminaison de AWS PrivateLink connexion
******Étape 1 : obtenir le nom du service pour votre cluster**
Lorsque vous créez un AWS PrivateLink point de terminaison pour vous connecter à votre cluster, vous devez d'abord récupérer le nom du service spécifique au cluster.
------
#### [ AWS CLI ]
```
aws dsql get-vpc-endpoint-service-name \
--region us-east-1 \
--identifier your-cluster-id
```
Exemple de réponse
```
{
"serviceName": "com.amazonaws.us-east-1.dsql-fnh4"
}
```
Le nom du service inclut un identifiant, comme `dsql-fnh4` dans l’exemple. Cet identifiant est également nécessaire lors de la construction du nom d’hôte pour la connexion à votre cluster.
------
#### [ AWS SDK for Python (Boto3) ]
```
import boto3
dsql_client = boto3.client('dsql', region_name='us-east-1')
response = dsql_client.get_vpc_endpoint_service_name(
identifier='your-cluster-id'
)
service_name = response['serviceName']
print(f"Service Name: {service_name}")
```
------
#### [ AWS SDK for Java 2.x ]
```
import software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.dsql.DsqlClient;
import software.amazon.awssdk.services.dsql.model.GetVpcEndpointServiceNameRequest;
import software.amazon.awssdk.services.dsql.model.GetVpcEndpointServiceNameResponse;
String region = "us-east-1";
String clusterId = "your-cluster-id";
DsqlClient dsqlClient = DsqlClient.builder()
.region(Region.of(region))
.credentialsProvider(DefaultCredentialsProvider.create())
.build();
GetVpcEndpointServiceNameResponse response = dsqlClient.getVpcEndpointServiceName(
GetVpcEndpointServiceNameRequest.builder()
.identifier(clusterId)
.build()
);
String serviceName = response.serviceName();
System.out.println("Service Name: " + serviceName);
```
------
**Étape 2 : créer le point de terminaison Amazon VPC**
À l’aide du nom de service obtenu à l’étape précédente, créez un point de terminaison Amazon VPC.
**Important**
Les instructions de connexion ci-dessous ne fonctionnent que pour la connexion aux clusters lorsque le mode privé est activé par le DNS. N’utilisez pas l’indicateur `--no-private-dns-enabled` lors de la création du point de terminaison, car cela empêcherait les instructions de connexion ci-dessous de fonctionner correctement. Si vous désactivez le DNS privé, vous devrez créer votre propre enregistrement DNS privé joker pointant vers le point de terminaison créé.
------
#### [ AWS CLI ]
```
aws ec2 create-vpc-endpoint \
--region us-east-1 \
--service-name service-name-for-your-cluster \
--vpc-id your-vpc-id \
--subnet-ids subnet-id-1 subnet-id-2 \
--vpc-endpoint-type Interface \
--security-group-ids security-group-id
```
**Exemple de réponse**
```
{
"VpcEndpoint": {
"VpcEndpointId": "vpce-0123456789abcdef0",
"VpcEndpointType": "Interface",
"VpcId": "vpc-0123456789abcdef0",
"ServiceName": "com.amazonaws.us-east-1.dsql-fnh4",
"State": "pending",
"RouteTableIds": [],
"SubnetIds": [
"subnet-0123456789abcdef0",
"subnet-0123456789abcdef1"
],
"Groups": [
{
"GroupId": "sg-0123456789abcdef0",
"GroupName": "default"
}
],
"PrivateDnsEnabled": true,
"RequesterManaged": false,
"NetworkInterfaceIds": [
"eni-0123456789abcdef0",
"eni-0123456789abcdef1"
],
"DnsEntries": [
{
"DnsName": "*.dsql-fnh4.us-east-1.vpce.amazonaws.com",
"HostedZoneId": "Z7HUB22UULQXV"
}
],
"CreationTimestamp": "2025-01-01T00:00:00.000Z"
}
}
```
------
#### [ SDK for Python ]
```
import boto3
ec2_client = boto3.client('ec2', region_name='us-east-1')
response = ec2_client.create_vpc_endpoint(
VpcEndpointType='Interface',
VpcId='your-vpc-id',
ServiceName='com.amazonaws.us-east-1.dsql-fnh4', # Use the service name from previous step
SubnetIds=[
'subnet-id-1',
'subnet-id-2'
],
SecurityGroupIds=[
'security-group-id'
]
)
vpc_endpoint_id = response['VpcEndpoint']['VpcEndpointId']
print(f"VPC Endpoint created with ID: {vpc_endpoint_id}")
```
------
#### [ SDK for Java 2.x ]
Utiliser une URL de point de terminaison pour Aurora DSQL APIs
```
import software.amazon.awssdk.auth.credentials.DefaultCredentialsProvider;
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.ec2.Ec2Client;
import software.amazon.awssdk.services.ec2.model.CreateVpcEndpointRequest;
import software.amazon.awssdk.services.ec2.model.CreateVpcEndpointResponse;
import software.amazon.awssdk.services.ec2.model.VpcEndpointType;
String region = "us-east-1";
String serviceName = "com.amazonaws.us-east-1.dsql-fnh4"; // Use the service name from previous step
String vpcId = "your-vpc-id";
Ec2Client ec2Client = Ec2Client.builder()
.region(Region.of(region))
.credentialsProvider(DefaultCredentialsProvider.create())
.build();
CreateVpcEndpointRequest request = CreateVpcEndpointRequest.builder()
.vpcId(vpcId)
.serviceName(serviceName)
.vpcEndpointType(VpcEndpointType.INTERFACE)
.subnetIds("subnet-id-1", "subnet-id-2")
.securityGroupIds("security-group-id")
.build();
CreateVpcEndpointResponse response = ec2Client.createVpcEndpoint(request);
String vpcEndpointId = response.vpcEndpoint().vpcEndpointId();
System.out.println("VPC Endpoint created with ID: " + vpcEndpointId);
```
------
**Configuration supplémentaire lors de la connexion Direct Connect ou du peering Amazon VPC**
Une configuration supplémentaire peut être nécessaire pour se connecter aux clusters Aurora DSQL à l'aide d'un point de terminaison de AWS PrivateLink connexion provenant d'appareils sur site via Amazon VPC peering ou. Direct Connect Cette configuration n'est pas requise si votre application s'exécute dans le même Amazon VPC que votre AWS PrivateLink point de terminaison. Les entrées DNS privées créées ci-dessus ne seront pas résolues correctement en dehors du VPC Amazon du point de terminaison, mais vous pouvez créer vos propres enregistrements DNS privés qui sont résolus vers votre point de terminaison de AWS PrivateLink connexion.
Créez un enregistrement DNS CNAME privé qui pointe vers le nom de domaine complet du AWS PrivateLink point de terminaison. Le nom de domaine de l'enregistrement DNS créé doit être construit à partir des composants suivants :
1. L’identifiant du service issu du nom du service. Par exemple : `dsql-fnh4`
1. Le Région AWS
Créez l'enregistrement DNS CNAME avec un nom de domaine au format suivant : `*.service-identifier.region.on.aws`
Le format du nom de domaine est important pour deux raisons :
1. Le nom d'hôte utilisé pour se connecter à Aurora DSQL doit correspondre au certificat de serveur d'Aurora DSQL lorsque vous utilisez le `verify-full` mode SSL. Cela garantit le plus haut niveau de sécurité de connexion.
1. Aurora DSQL utilise la partie ID de cluster du nom d'hôte utilisé pour se connecter à Aurora DSQL afin d'identifier le cluster qui se connecte.
S'il n'est pas possible de créer des enregistrements DNS privés, vous pouvez toujours vous connecter à Aurora DSQL. Consultez [Connexion à un cluster Aurora DSQL à l'aide d'un AWS PrivateLink point de terminaison sans DNS privé](#connecting-cluster-id-option).
### Connexion à un cluster SQL Aurora à l'aide d'un point de terminaison de AWS PrivateLink connexion
Une fois que votre AWS PrivateLink point de terminaison est configuré et actif (vérifiez qu'il l'`State`est`available`), vous pouvez vous connecter à votre cluster Aurora DSQL à l'aide d'un client PostgreSQL. Pour obtenir des instructions sur l'utilisation de AWS SDKs, vous pouvez suivre les guides de la section [Programmation avec Aurora DSQL.](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/programming-with.html) Vous devez modifier le point de terminaison du cluster pour qu’il corresponde au format du nom d’hôte.
#### Construction du nom d’hôte
Le nom d'hôte pour la connexion est AWS PrivateLink différent du nom d'hôte DNS public. Vous devez le construire à l’aide des composants suivants.
1. `Your-cluster-id`
1. L’identifiant du service issu du nom du service. Par exemple : `dsql-fnh4`
1. Le Région AWS. Par exemple : `us-east-1`
Utilisez le format suivant : `cluster-id.service-identifier.region.on.aws`
**Exemple : connexion à l’aide de PostgreSQL**
```
# Set environment variables
export CLUSTERID=your-cluster-id
export REGION=us-east-1
export SERVICE_IDENTIFIER=dsql-fnh4 # This should match the identifier in your service name
# Construct the hostname
export HOSTNAME="$CLUSTERID.$SERVICE_IDENTIFIER.$REGION.on.aws"
# Generate authentication token
export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token --hostname $HOSTNAME)
# Connect using psql
psql -d postgres -h $HOSTNAME -U admin
```
#### Connexion à un cluster Aurora DSQL à l'aide d'un AWS PrivateLink point de terminaison sans DNS privé
Les instructions de connexion ci-dessus s'appuient sur des enregistrements DNS privés. Si votre application s'exécute dans le même Amazon VPC que votre AWS PrivateLink point de terminaison, les enregistrements DNS sont créés pour vous. Si vous vous connectez à partir d'appareils sur site via Amazon VPC peering Direct Connect, vous pouvez également créer vos propres enregistrements DNS privés. Cependant, la configuration des enregistrements DNS n'est pas toujours possible en raison des restrictions réseau imposées par vos équipes de sécurité. Si votre application doit se connecter via Direct Connect ou depuis un Amazon VPC homologue et que la configuration d'un enregistrement DNS n'est pas possible, vous pouvez toujours vous connecter à Aurora DSQL.
Aurora DSQL utilise la partie ID de cluster de votre nom d'hôte pour identifier le cluster qui se connecte, mais si la configuration d'un enregistrement DNS n'est pas possible, Aurora DSQL prend en charge la spécification du cluster cible à l'aide de l'`amzn-cluster-id`option de connexion. Avec cette option, il est possible d'utiliser le nom de domaine complet de votre AWS PrivateLink terminal comme nom d'hôte lors de la connexion.
**Important**
Lorsque vous vous connectez avec le nom de domaine complet ou l'adresse IP de votre AWS PrivateLink terminal, le mode `verify-full` SSL n'est pas pris en charge. C'est pourquoi il est préférable de configurer un DNS privé.
**Exemple : Spécification de l'option de connexion avec l'ID du cluster à l'aide de PostgreSQL**
```
# Set environment variables
export CLUSTERID=your-cluster-id
export REGION=us-east-1
export HOSTNAME=vpce-04037adb76c111221-d849uc2p.dsql-fnh4.us-east-1.vpce.amazonaws.com # This should match your endpoint's fully-qualified domain name
# Construct the hostname used to generate the authentication token
export AUTH_HOSTNAME="$CLUSTERID.dsql.$REGION.on.aws"
# Generate authentication token
export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token --hostname $AUTH_HOSTNAME)
# Specify the amzn-cluster-id connection option
export PGOPTIONS="-c amzn-cluster-id=$CLUSTERID"
# Connect using psql
psql -d postgres -h $HOSTNAME -U admin
```
### Résolution des problèmes liés à AWS PrivateLink
#### Problèmes courants et solutions correspondantes
Le tableau suivant répertorie les problèmes courants et les solutions liés à AWS PrivateLink avec Aurora DSQL.
| Problème | Cause possible | Solution |
| --- | --- | --- |
| Délai de connexion | Le groupe de sécurité n’est pas correctement configuré | Utilisez l’analyseur d’accessibilité Amazon VPC pour vous assurer que votre configuration réseau autorise le trafic sur le port 5432. |
| Échec de résolution DNS | DNS privé non activé | Vérifiez que le point de terminaison Amazon VPC a été créé avec le DNS privé activé. |
| Échec d’authentification | Informations d’identification incorrectes ou jeton expiré | Générez un nouveau jeton d’authentification et vérifiez le nom d’utilisateur. |
| Nom de service introuvable | ID de cluster incorrect | Vérifiez l'ID de votre cluster et vérifiez le nom du service Région AWS lorsque vous récupérez le nom du service. |
### Ressources connexes
Pour plus d’informations, consultez les ressources suivantes :
+ [Guide de l’utilisateur Amazon Aurora DSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-dsql.html)
+ [Documentation AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)
+ [Accédez aux AWS services via AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)
# Configuration et analyse des vulnérabilités dans Amazon Aurora DSQL
AWS gère les tâches de sécurité de base telles que l'application de correctifs au système d'exploitation client (OS) et aux bases de données, la configuration du pare-feu et la reprise après sinistre. Ces procédures ont été vérifiées et certifiées par les tiers appropriés. Pour plus de détails, consultez les ressources suivantes :
+ [Modèle de responsabilité partagée](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [Amazon Web Services : présentation des procédures de sécurité](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) (livre blanc)
# Prévention du cas de figure de l’adjoint désorienté entre services
Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, 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é et ses autorisations utilisées pour agir sur les ressources d’un autre client auxquelles on ne serait pas autorisé à accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services avec des principaux de service qui ont eu accès aux ressources de votre compte.
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 afin de limiter les autorisations à la ressource octroyées par Amazon Aurora DSQL à un autre service. Utilisez `aws:SourceArn` si vous souhaitez qu’une seule ressource soit associée à l’accès entre services. Utilisez `aws:SourceAccount` si vous souhaitez autoriser l’association d’une ressource de ce compte à l’utilisation interservices.
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. Si vous ne connaissez pas l’ARN complet de la ressource ou si vous spécifiez plusieurs ressources, 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:dsql:*:123456789012:*`.
Si la valeur `aws:SourceArn` ne contient pas l’ID du compte, tel qu’un ARN de compartiment Amazon S3, vous devez utiliser les deux clés de contexte de condition globale pour limiter les autorisations.
La valeur de `aws:SourceArn` doit être ResourceDescription.
L’exemple suivant montre comment utiliser les clés de contexte de condition globale `aws:SourceArn` et `aws:SourceAccount` dans Aurora DSQL afin d’éviter le problème de l’adjoint confus.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "ConfusedDeputyPreventionExamplePolicy",
"Effect": "Allow",
"Principal": {
"Service": "backup.amazonaws.com"
},
"Action": "dsql:GetCluster",
"Resource": [
"arn:aws:dsql:*:123456789012:cluster/*"
],
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:backup:*:123456789012:*"
},
"StringEquals": {
"aws:SourceAccount": "123456789012"
}
}
}
}
```
------
# Bonnes pratiques de sécurité pour Aurora DSQL
Aurora DSQL fournit différentes fonctionnalités de sécurité à prendre en compte lorsque vous développez et implémentez vos propres politiques de sécurité. Les bonnes pratiques suivantes doivent être considérées comme des instructions générales et ne représentent pas une solution de sécurité complète. Étant donné que ces bonnes pratiques peuvent ne pas être appropriées ou suffisantes pour votre environnement, considérez-les comme des remarques utiles plutôt que comme des recommandations.
**Topics**
+ [Bonnes pratiques de sécurité de détection pour Aurora DSQL](best-practices-security-detective.md)
+ [Bonnes pratiques de sécurité préventive pour Aurora DSQL](best-practices-security-preventative.md)
# Bonnes pratiques de sécurité de détection pour Aurora DSQL
Outre les méthodes suivantes pour utiliser Aurora DSQL en toute sécurité, consultez [Security](https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html) in AWS Well-Architected Tool pour découvrir comment les technologies cloud améliorent votre sécurité.
** 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é.
**Étiquetage de vos ressources Aurora DSQL pour l’identification et l’automatisation**
Vous pouvez attribuer des métadonnées à vos AWS ressources sous forme de balises. Chaque étiquette est un libellé composé d’une clé définie par le client et d’une valeur facultative qui peut faciliter la gestion, la recherche et le filtrage de ressources.
L’étiquetage permet l’implémentation de contrôles groupés. Bien qu’il n’existe pas de types intrinsèques d’étiquettes, celles-ci vous permettent de catégoriser des ressources par objectif, par propriétaire, par environnement ou selon d’autres critères. Voici quelques exemples :
+ Sécurité : utilisée pour déterminer des exigences telles que le chiffrement.
+ Confidentialité – Identifiant pour le niveau spécifique de confidentialité des données qu’une ressource prend en charge.
+ Environnement : utilisé pour différencier les infrastructures de développement, de test et de production.
Vous pouvez attribuer des métadonnées à vos AWS ressources sous forme de balises. Chaque étiquette est un libellé composé d’une clé définie par le client et d’une valeur facultative qui peut faciliter la gestion, la recherche et le filtrage de ressources.
L’étiquetage permet l’implémentation de contrôles groupés. Bien qu’il n’existe pas de types de balises inhérents, elles vous permettent de classer les ressources par objectif, par propriétaire, par environnement ou selon d’autres critères. Voici quelques exemples.
+ Sécurité : utilisée pour déterminer des exigences telles que le chiffrement.
+ Confidentialité : identifiant pour le niveau spécifique de confidentialité des données qu’une ressource prend en charge.
+ Environnement : utilisé pour différencier les infrastructures de développement, de test et de production.
Pour plus d'informations, consultez la section [Meilleures pratiques en matière de balisage AWS des ressources](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html).
# Bonnes pratiques de sécurité préventive pour Aurora DSQL
Outre les méthodes suivantes pour utiliser Aurora DSQL en toute sécurité, consultez [Security](https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html) in AWS Well-Architected Tool pour découvrir comment les technologies cloud améliorent votre sécurité.
**Utilisation des rôles IAM pour authentifier l’accès à Aurora DSQL.**
Les utilisateurs, applications et autres personnes Services AWS qui accèdent à Aurora DSQL doivent inclure des AWS informations d'identification valides dans AWS l'API et les AWS CLI demandes. Vous ne devez pas stocker les AWS informations d'identification directement dans l'application ou dans les instances EC2. Il s’agit d’informations d’identification à long terme qui ne font pas l’objet d’une rotation automatique. La compromission de ces informations d’identification a un impact commercial significatif. Un rôle IAM vous permet d'obtenir des clés d'accès temporaires que vous pouvez utiliser pour accéder Services AWS aux ressources.
Pour de plus amples informations, veuillez consulter [Authentification et autorisation pour Aurora DSQL](authentication-authorization.md).
**Utilisation des politiques IAM pour l’autorisation de base Aurora DSQL.**
Lorsque vous accordez des autorisations, vous décidez qui les reçoit, les opérations d’API Aurora DSQL auxquelles elles s’appliquent, et les actions spécifiques que vous souhaitez autoriser sur ces ressources. L’implémentation d’un privilège minimum est la clé de la réduction des risques de sécurité et de l’impact potentiel d’erreurs ou d’actes de malveillance.
Associez des politiques d’autorisation aux rôles IAM et accordez des autorisations pour exécuter des opérations sur des ressources Aurora DSQL. Des [limites d’autorisations pour les entités IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) sont également disponibles, ce qui vous permet de définir les autorisations maximales qu’une politique basée sur l’identité peut accorder à une entité IAM.
À l'instar des [meilleures pratiques relatives à l'utilisateur root Compte AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html), n'utilisez pas le `admin` rôle dans Aurora DSQL pour effectuer des opérations quotidiennes. Nous vous recommandons plutôt de créer des rôles de base de données personnalisés pour gérer votre cluster et vous y connecter. Pour plus d’informations, consultez [Accès à Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/accessing.html) et [Comprendre l’authentification et l’autorisation pour Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/accessing.html).
**Utilisation de `verify-full` dans les environnements de production.**
Ce paramètre vérifie que le certificat du serveur est signé par une autorité de certification fiable et que le nom d’hôte du serveur correspond au certificat.
**Mise à jour de votre client PostgreSQL**
Mettez régulièrement à jour votre client PostgreSQL vers la dernière version pour bénéficier des améliorations de sécurité. Nous vous recommandons d’utiliser la version 17 de PostgreSQL.