# Seguridad en Amazon Aurora DSQL
La seguridad en la nube en AWS es la máxima prioridad. Como cliente de AWS, se beneficiará de una arquitectura de red y de centros de datos diseñados para satisfacer los requisitos de seguridad de las organizaciones más exigentes.
La seguridad es una responsabilidad compartida entre AWS y usted. El [modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/) aborda tanto la seguridad *de* la nube como la seguridad *en* la nube:
+ **Seguridad de la nube**: AWS es responsable de proteger la infraestructura que ejecuta servicios de AWS en la Nube de AWS. AWS también le proporciona servicios que puede utilizar de forma segura. Los auditores externos prueban y verifican periódicamente la eficacia de nuestra seguridad como parte de los [Programas de conformidad de AWS](https://aws.amazon.com/compliance/programs/) . Para obtener información sobre los programas de cumplimiento que se aplican a Amazon Aurora DSQL, consulte [Servicios de AWS en el ámbito del programa de cumplimiento](https://aws.amazon.com/compliance/services-in-scope/).
+ **Seguridad en la nube**: su responsabilidad viene determinada por el servicio de AWS que utilice. También es responsable de otros factores, incluida la confidencialidad de los datos, los requisitos de la empresa y la legislación y la normativa aplicables.
Esta documentación lo ayuda a comprender cómo aplicar el modelo de responsabilidad compartida cuando se utiliza Aurora DSQL. En los siguientes temas, se le mostrará cómo configurar Aurora DSQL para satisfacer los objetivos de seguridad y cumplimiento. También puede aprender a utilizar otros servicios de AWS que lo ayuden a supervisar y proteger los recursos de Aurora DSQL.
**Topics**
+ [Políticas administradas de AWS para Amazon Aurora DSQL](security-iam-awsmanpol.md)
+ [Protección de datos en Amazon Aurora DSQL](data-protection.md)
+ [Cifrado de datos para Amazon Aurora DSQL](data-encryption.md)
+ [Administración de la identidad y el acceso para Aurora DSQL](security-iam.md)
+ [Políticas basadas en recursos para Aurora DSQL](resource-based-policies.md)
+ [Uso de los roles vinculados al servicio en Aurora DSQL](working-with-service-linked-roles.md)
+ [Uso de claves de condición de IAM con Amazon Aurora DSQL](using-iam-condition-keys.md)
+ [Respuesta a incidentes en Amazon Aurora DSQL](incident-response.md)
+ [Validación del cumplimiento para Amazon Aurora DSQL](compliance-validation.md)
+ [Resiliencia en Amazon Aurora DSQL](disaster-recovery-resiliency.md)
+ [Seguridad de infraestructuras en Amazon Aurora DSQL](infrastructure-security.md)
+ [Configuración y análisis de vulnerabilidades en Amazon Aurora DSQL](configuration-vulnerability.md)
+ [Prevención de la sustitución confusa entre servicios](cross-service-confused-deputy-prevention.md)
+ [Prácticas recomendadas de seguridad para Aurora DSQL](best-practices-security.md)
# Políticas administradas de AWS para Amazon Aurora DSQL
Una política administrada de AWS es una política independiente que AWS crea y administra. Las políticas administradas de AWS se diseñan para ofrecer permisos para muchos casos de uso comunes, por lo que puede empezar a asignar permisos a los usuarios, grupos y roles.
Considere que es posible que las políticas administradas por AWS no concedan permisos de privilegio mínimo para los casos de uso concretos, ya que están disponibles para que las utilicen todos los clientes de AWS. Se recomienda definir [políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) específicas para sus casos de uso a fin de reducir aún más los permisos.
No puede cambiar los permisos definidos en las políticas administradas AWS. Si AWS actualiza los permisos definidos en una política administrada de AWS, la actualización afecta a todas las identidades de entidades principales (usuarios, grupos y roles) a las que está asociada la política. Lo más probable es que AWS actualice una política administrada de AWS cuando se lance un nuevo Servicio de AWS o las operaciones de la API nuevas estén disponibles para los servicios existentes.
Para obtener más información, consulte [Políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) en la *Guía del usuario de IAM*.
## Política administrada de AWS: AmazonAuroraDSQLFullAccess
Puede asociar `AmazonAuroraDSQLFullAccess` a los usuarios, grupos y roles.
Esta política concede permisos que permiten el acceso administrativo completo a Aurora DSQL. Las entidades principales con estos permisos pueden realizar:
+ Creación, eliminación y actualización de clústeres de Aurora DSQL, incluidos los clústeres multirregionales
+ Administración de las políticas insertadas del clúster (políticas de creación, visualización, actualización y eliminación)
+ Agregación y eliminación de etiquetas de clústeres
+ Muestra de los clústeres y visualización de la información sobre clústeres individuales
+ Visualización de las etiquetas asociadas a los clústeres de Aurora DSQL
+ Conexión a la base de datos como cualquier usuario, incluido el administrador
+ Realización de operaciones de copia de seguridad y restauración para los clústeres de Aurora DSQL, como inicio, detención y supervisión de los trabajos de copia de seguridad y restauración
+ Uso de claves de AWS KMS administradas por el cliente para el cifrado de clústeres
+ Visualización de cualquier métrica de CloudWatch de la cuenta
+ Uso de AWS Fault Injection Service (AWS FIS) para inyectar errores en los clústeres de Aurora DSQL para realizar pruebas de tolerancia a errores
+ Creación de roles vinculados a servicios para el servicio de `dsql.amazonaws.com`, lo que es necesario para crear clústeres
**Detalles de los permisos**
Esta política incluye los siguientes permisos.
+ `dsql`: concede a las entidades principales acceso completo a Aurora DSQL.
+ `cloudwatch`: concede permiso para publicar puntos de datos de métricas en Amazon CloudWatch.
+ `iam`: concede permiso para crear un rol vinculado a servicios.
+ `backup and restore`: concede permisos para iniciar, detener y supervisar los trabajos de copia de seguridad y restauración de los clústeres de Aurora DSQL.
+ `kms`: concede los permisos necesarios para validar el acceso a las claves administradas por el cliente utilizadas para el cifrado de clústeres de Aurora DSQL al crear, actualizar o conectarse a los clústeres.
+ `fis`: concede permisos para usar AWS Fault Injection Service (AWS FIS) para inyectar errores en los clústeres de Aurora DSQL para realizar pruebas de tolerancia a errores.
Puede encontrar la política de `AmazonAuroraDSQLFullAccess` en la consola de IAM y en la [Guía de referencia de las políticas administradas de AWS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLFullAccess.html).
## Política administrada de AWS: AmazonAuroraDSQLReadOnlyAccess
Puede asociar `AmazonAuroraDSQLReadOnlyAccess` a los usuarios, grupos y roles.
Permite el acceso de lectura a Aurora DSQL. Las entidades principales con estos permisos pueden enumerar clústeres y ver información sobre clústeres individuales. Pueden ver las etiquetas asociadas a los clústeres de Aurora DSQL y ver las políticas insertadas del clúster. Pueden recuperar y ver cualquier métrica de CloudWatch en la cuenta.
**Detalles de los permisos**
Esta política incluye los siguientes permisos.
+ `dsql`: concede permisos de solo lectura a todos los recursos de Aurora DSQL.
+ `cloudwatch`: concede permiso para recuperar cantidades de lotes de datos de métricas de CloudWatch y realizar cálculos de métricas en función de los datos recuperados
Puede encontrar la política de `AmazonAuroraDSQLReadOnlyAccess` en la consola de IAM y la [Guía de referencia de las políticas administradas de AWS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLReadOnlyAccess.html).
## Política administrada de AWS: AmazonAuroraDSQLConsoleFullAccess
Puede asociar `AmazonAuroraDSQLConsoleFullAccess` a los usuarios, grupos y roles.
Permite el acceso administrativo completo a Amazon Aurora DSQL a través de la Consola de administración de AWS. Las entidades principales con estos permisos pueden realizar:
+ Creación, eliminación y actualización de clústeres de Aurora DSQL, incluidos los clústeres multirregionales, con la consola
+ Administración de las políticas insertadas del clúster a través de la consola (políticas de creación, visualización, actualización y eliminación)
+ Muestra de los clústeres y visualización de la información sobre clústeres individuales
+ Visualización de las etiquetas de cualquier recurso en la cuenta
+ Conexión a la base de datos como cualquier usuario, incluido el administrador
+ Realización de operaciones de copia de seguridad y restauración para los clústeres de Aurora DSQL, como inicio, detención y supervisión de los trabajos de copia de seguridad y restauración
+ Uso de claves de AWS KMS administradas por el cliente para el cifrado de clústeres
+ Lanzamiento de AWS CloudShell desde la Consola de administración de AWS
+ Visualización de cualquier métrica de CloudWatch en la cuenta
+ Uso de AWS Fault Injection Service (AWS FIS) para inyectar errores en los clústeres de Aurora DSQL para realizar pruebas de tolerancia a errores
+ Creación de roles vinculados a servicios para el servicio de `dsql.amazonaws.com`, lo que es necesario para crear clústeres
Puede encontrar la política `AmazonAuroraDSQLConsoleFullAccess` en la consola de IAM y [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLConsoleFullAccess.html) en la Guía de referencia de las políticas administradas de AWS.
**Detalles de los permisos**
Esta política incluye los siguientes permisos.
+ `dsql`: concede permisos administrativos completos a todos los recursos de Aurora DSQL a través de la Consola de administración de AWS.
+ `cloudwatch`: concede permiso para recuperar cantidades de lotes de datos de métricas de CloudWatch y realizar cálculos de métricas en función de los datos recuperados.
+ `tag`: concede permiso para devolver valores y claves de etiqueta actualmente en uso en la Región de AWS especificada para la cuenta de llamada.
+ `backup and restore`: concede permisos para iniciar, detener y supervisar los trabajos de copia de seguridad y restauración de los clústeres de Aurora DSQL.
+ `kms`: concede los permisos necesarios para validar el acceso a las claves administradas por el cliente utilizadas para el cifrado de clústeres de Aurora DSQL al crear, actualizar o conectarse a los clústeres.
+ `cloudshell`: concede permisos para lanzar AWS CloudShell para interactuar con Aurora DSQL.
+ `ec2`: concede permiso para ver la información del punto de conexión de Amazon VPC necesaria para las conexiones de Aurora DSQL.
+ `fis`: concede permisos para usar AWS FIS para inyectar errores en los clústeres de Aurora DSQL para realizar pruebas de tolerancia a errores.
+ `access-analyzer:ValidatePolicy` concede permiso para el linter en el editor de políticas, que proporciona información en tiempo real sobre los errores, las advertencias y los problemas de seguridad de la política actual.
+ `fis`: concede permisos para usar AWS Fault Injection Service (AWS FIS) para inyectar errores en los clústeres de Aurora DSQL para realizar pruebas de tolerancia a errores.
Puede encontrar la política de `AmazonAuroraDSQLConsoleFullAccess` en la consola de IAM y la [Guía de referencia de las políticas administradas de AWS](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonAuroraDSQLConsoleFullAccess.html).
## Política administrada de AWS: AuroraDSQLServiceRolePolicy
No puede asociar AuroraDSQLServiceRolePolicy a las entidades de IAM. Esta política está asociada a un rol vinculado al servicio que permite a Aurora DSQL acceder a los recursos de la cuenta.
Puede encontrar la política `AuroraDSQLServiceRolePolicy` en la consola de IAM y [AuroraDSQLServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDSQLServiceRolePolicy.html) en la Guía de referencia de las políticas administradas de AWS.
## Actualizaciones de Aurora DSQL en las políticas administradas de AWS
Vea los detalles sobre las actualizaciones de las políticas administradas de AWS para Aurora DSQL desde que este servicio comenzó a realizar el seguimiento de estos cambios. Para obtener alertas automáticas sobre los cambios realizados en esta página, suscríbase a la fuente RSS en la Página del historial de revisión de Aurora DSQL.
| Cambio | Descripción | Fecha |
| --- | --- | --- |
| Actualización de AmazonAuroraDSQLFullAccess y AmazonAuroraDSQLConsoleFullAccess | Se ha agregado compatibilidad para la integración de AWS Fault Injection Service (AWS FIS) con Aurora DSQL. Esto le permite inyectar errores en los clústeres de Aurora DSQL de una región y mutirregionales para probar la tolerancia a errores de las aplicaciones. Puede crear plantillas de experimentos en la consola de AWS FIS para definir escenarios de error y dirigirse a clústeres de Aurora DSQL específicos para realizar pruebas. Para obtener más información sobre estas políticas, consulte [AmazonAuroraDSQLFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) y [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess). | 19 de agosto de 2025 |
| Actualización de AmazonAuroraDSQLFullAccess, AmazonAuroraDSQLReadOnlyAccess y AmazonAuroraDSQLConsoleFullAccess | Se ha agregado compatibilidad con políticas basadas en recursos (RBP) con nuevos permisos: `PutClusterPolicy`, `GetClusterPolicy` y `DeleteClusterPolicy`. Estos permisos permiten administrar políticas insertadas en los clústeres de Aurora DSQL para el control de acceso detallado. Para obtener más información, consulte [AmazonAuroraDSQLFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess), [AmazonAuroraDSQLReadOnlyAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLReadOnlyAccess) y [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess). | 15 de octubre de 2025 |
| Actualización de AmazonAuroraDSQLFullAccess | Agrega la capacidad de realizar operaciones de copia de seguridad y restauración para los clústeres de Aurora DSQL, incluidos los trabajos de inicio, detención y supervisión. También agrega la capacidad de utilizar claves de KMS administradas por el cliente para el cifrado de clústeres. Para obtener más información, consulte [AmazonAuroraDSQLFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) y [Uso de roles vinculados a servicios en Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 21 de mayo de 2025 |
| Actualización de AmazonAuroraDSQLConsoleFullAccess | Agrega la capacidad de realizar operaciones de copia de seguridad y restauración para los clústeres de Aurora DSQL a través de AWS Console Home. Esto incluye iniciar, detener y supervisar los trabajos. También admite el uso de claves de KMS administradas por el cliente para el cifrado de clústeres y el lanzamiento de AWS CloudShell. Para obtener más información, consulte [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess) y [Uso de roles vinculados al servicio en Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 21 de mayo de 2025 |
| Actualización de AmazonAuroraDSQLFullAccess | La política agrega cuatro nuevos permisos para crear y administrar clústeres de bases de datos en múltiples Regiones de AWS: `PutMultiRegionProperties`, `PutWitnessRegion`, `AddPeerCluster` y `RemovePeerCluster`. Estos permisos incluyen controles de recursos y claves de condición para que pueda controlar qué usuarios de clústeres puede modificar. La política también agrega el permiso `GetVpcEndpointServiceName` para ayudarlo a conectarse a los clústeres de Aurora DSQL a través de AWS PrivateLink. Para obtener más información, consulte [AmazonAuroraDSQLFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLFullAccess) y [Uso de los roles vinculados al servicio en Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 13 de mayo de 2025 |
| Actualización de AmazonAuroraDSQLReadOnlyAccess | Incluye la capacidad de determinar el nombre de servicio de punto de conexión de VPC correcto al conectarse a los clústeres de Aurora DSQL a través de AWS PrivateLink Aurora DSQL crea puntos de conexión únicos por celda, por lo que esta API lo ayuda a asegurarse de que puede identificar el punto de conexión correcto para el clúster y evitar errores de conexión.Para obtener más información, consulte [AmazonAuroraDSQLReadOnlyAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLReadOnlyAccess) y [Uso de roles vinculados al servicio en Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 13 de mayo de 2025 |
| Actualización de AmazonAuroraDSQLConsoleFullAccess | Agrega nuevos permisos a Aurora DSQL para admitir la administración de clústeres multirregionales y la conexión de puntos de conexión de VPC. Los nuevos permisos incluyen PutMultiRegionProperties, PutWitnessRegion, AddPeerCluster, RemovePeerCluster y GetVpcEndpointServiceName Para obtener más información, consulte [AmazonAuroraDSQLConsoleFullAccess](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonAuroraDSQLConsoleFullAccess) y [Uso de roles vinculados al servicio en Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 13 de mayo de 2025 |
| Actualización de AuroraDsqlServiceLinkedRolePolicy | Agrega a la política la capacidad de publicar métricas en AWS/AuroraDSQL y los espacios de nombres de AWS/Usage CloudWatch. Esto permite que el servicio o el rol asociado emita datos de uso y rendimiento más completos al entorno de CloudWatch. Para obtener más información, consulte [AuroraDsqlServiceLinkedRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDsqlServiceLinkedRolePolicy.html) y [Uso de roles vinculados al servicio en Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/working-with-service-linked-roles.html). | 8 de mayo de 2025 |
| Página creada | Inicio del seguimiento de políticas administradas de AWS relacionadas con Amazon Aurora DSQL | 3 de diciembre de 2024 |
# Protección de datos en Amazon Aurora DSQL
El [modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/) se aplica a la protección de datos en . Como se describe en este modelo, es responsable de proteger la infraestructura global que ejecuta toda la Nube de AWS. Eres responsable de mantener el control sobre el contenido alojado en esta infraestructura. También eres responsable de las tareas de administración y configuración de seguridad para los que utiliza. Para obtener más información sobre la privacidad de los datos, consulte las [Preguntas frecuentes sobre la privacidad de datos](https://aws.amazon.com/compliance/data-privacy-faq/). Para obtener información sobre la protección de datos en Europa, consulte la publicación del blog [ Shared Responsibility Model and GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) en el *Blog de seguridad de *.
Con fines de protección de datos, recomendamos proteger las credenciales y configurar usuarios individuales con AWS IAM Identity Center o AWS Identity and Access Management. De esta manera, solo se otorgan a cada usuario los permisos necesarios para cumplir sus obligaciones laborales. También recomendamos proteger sus datos de la siguiente manera:
+ Utiliza la autenticación multifactor (MFA) en cada cuenta.
+ Utiliza SSL/TLS para comunicarse con los recursos de . Exigimos TLS 1.2 y recomendamos TLS 1.3.
+ Configure los registros de API y de actividad de los usuarios con AWS CloudTrail. Para obtener información sobre cómo utilizar registros de seguimiento para capturar actividades, consulte [Cómo trabajar con los registros de seguimiento](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) en la *Guía del usuario*.
+ Utilice las soluciones de cifrado, junto con todos los controles de seguridad predeterminados dentro de Servicios de AWS.
+ Utiliza servicios de seguridad administrados avanzados, como Amazon Macie, que lo ayuden a detectar y proteger la información confidencial almacenada en Amazon S3.
Se recomienda encarecidamente no ingresar nunca información confidencial o sensible, como por ejemplo, direcciones de correo electrónico de clientes, en etiquetas o campos de texto de formato libre, como el campo **Nombre**. Esto incluye las situaciones en las que debe trabajar con u otros mediante la consola, la API, la AWS CLI o los SDK de AWS. Cualquier dato que introduzca en etiquetas o campos de formato libre utilizados para los nombres se pueden emplear para los registros de facturación o diagnóstico. Si proporciona una URL a un servidor externo, recomendamos encarecidamente que no incluya información de credenciales en la URL a fin de validar la solicitud para ese servidor.
## Cifrado de datos
Amazon Aurora DSQL proporciona una infraestructura de almacenamiento de alta durabilidad diseñada para el almacenamiento de datos principales y críticos. Los datos se almacenan de forma redundante en varios dispositivos de diversas instalaciones dentro de una región de Aurora DSQL.
### Cifrado en tránsito
De forma predeterminada, el cifrado en tránsito está configurado para usted. Aurora DSQL utiliza TLS para cifrar todo el tráfico entre el cliente de SQL y Aurora DSQL.
Cifrado y firma de datos en tránsito entre los clientes de la AWS CLI, el SDK o la API y los puntos de conexión de Aurora DSQL:
+ Aurora DSQL proporciona puntos de conexión HTTPS para cifrar los datos en tránsito.
+ Para proteger la integridad de las solicitudes de la API a Aurora DSQL, las llamadas a la API deben estar firmadas por el intermediario. Las llamadas se firman con un certificado X.509 o con la clave de acceso secreta de AWS del cliente, según el proceso de firma de Signature Version 4 (Sigv4). Para obtener más información, consulte [Proceso de firma Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) en la *Referencia general de AWS*.
+ Use la AWS CLI o alguno de los AWS SDK para efectuar solicitudes a AWS. Estas herramientas firman automáticamente las solicitudes con la clave de acceso especificada al configurar las herramientas.
#### Conformidad con FIPS
Los puntos de conexión del plano de datos de Aurora DSQL (puntos de conexión del clúster que se utilizan para las conexiones de bases de datos) utilizan módulos criptográficos validados por FIPS 140-2 de forma predeterminada. No se requieren puntos de conexión FIPS independientes para las conexiones de los clústeres.
Para las operaciones del plano de control, Aurora DSQL proporciona puntos de conexión FIPS dedicados en las regiones compatibles. Para obtener más información acerca de los puntos de conexión FIPS del plano de control, consulte [Puntos de conexión y cuotas de Aurora DSQL](https://docs.aws.amazon.com/general/latest/gr/dsql.html) en *Referencia general de AWS*.
Para el cifrado en reposo, consulte [Cifrado en reposo en Aurora DSQL](data-encryption.md#encryption-at-rest).
### Privacidad del tráfico entre redes
Las conexiones están protegidas tanto entre Aurora DSQL y las aplicaciones en las instalaciones como entre Aurora DSQL y otros recursos de AWS dentro de la misma Región de AWS.
Tiene dos opciones de conectividad entre su red privada y AWS:
+ Una conexión de Site-to-Site VPN de AWS. Para obtener más información, consulte [¿Qué es AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html)
+ Una conexión de Direct Connect. Para obtener más información, consulte [¿Qué es Direct Connect?](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html)
Obtendrá acceso a Aurora DSQL a través de la red mediante las operaciones de la API publicadas por AWS. Los clientes deben admitir lo siguiente:
+ Seguridad de la capa de transporte (TLS). Exigimos TLS 1.2 y recomendamos TLS 1.3.
+ Conjuntos de cifrado con confidencialidad directa total (PFS) como DHE (Ephemeral Diffie-Hellman) o ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La mayoría de los sistemas modernos como Java 7 y posteriores son compatibles con estos modos.
## Protección de datos en regiones testigo
Al crear un clúster multirregional, una región testigo ayuda a permitir la recuperación automática de errores al participar en la replicación sincrónica de las transacciones cifradas. Si un clúster interconectado deja de estar disponible, la región testigo permanece disponible para validar y procesar las operaciones de escritura en la base de datos, lo que garantiza que no se pierda la disponibilidad.
Las regiones testigo protegen y aseguran sus datos mediante estas características de diseño:
+ La región testigo recibe y almacena únicamente registros de transacciones cifradas. Nunca aloja, almacena ni transmite sus claves de cifrado.
+ La región testigo se centra únicamente en las funciones de registro de transacciones de escritura y cuórum. No puede leer los datos por diseño.
+ La región testigo funciona sin puntos de conexión de clústeres ni procesadores de consultas. Esto impide el acceso de los usuarios a la base de datos.
Para obtener más información sobre las regiones testigo, consulte [Configuración de clústeres multirregionales](configuring-multi-region-clusters.md).
# Configuración de certificados SSL/TLS para conexiones de Aurora DSQL
Aurora DSQL requiere que todas las conexiones utilicen el cifrado de seguridad de la capa de transporte (TLS). Para establecer conexiones seguras, el sistema cliente debe confiar en la Autoridad de certificación raíz de Amazon (Amazon Root CA 1). Este certificado viene preinstalado en muchos sistemas operativos. Esta sección proporciona instrucciones para verificar el certificado de Amazon Root CA 1 preinstalado en varios sistemas operativos y le guía a través del proceso de instalación manual del certificado si aún no está presente.
Recomendamos utilizar la versión 17 de PostgreSQL.
**importante**
Para los entornos de producción, recomendamos utilizar el modo de SSL `verify-full` para garantizar el máximo nivel de seguridad de la conexión. Este modo verifica que el certificado del servidor esté firmado por una autoridad de certificación de confianza y que el nombre de host del servidor coincida con el certificado.
## Verificación de certificados preinstalados
En la mayoría de los sistemas operativos, **Amazon Root CA 1** ya viene preinstalado. Para validarlo, puede seguir los pasos que se indican a continuación.
### Linux (RedHat/CentOS/Fedora)
Ejecute el siguiente comando en el terminal:
```
trust list | grep "Amazon Root CA 1"
```
Si el certificado está instalado, verá el siguiente resultado:
```
label: Amazon Root CA 1
```
### macOS
1. Abra la búsqueda Spotlight (**Comando** \$1 **Espacio**)
1. Búsqueda de **Keychain Access**
1. Selección de **System Roots** en **System Keychains**
1. Búsqueda de **Amazon Root CA 1** en la lista de certificados
### Windows
**nota**
Debido a un problema conocido con el cliente psql de Windows, el uso de certificados raíz del sistema (`sslrootcert=system`) puede devolver el siguiente error: `SSL error: unregistered scheme`. Puede seguir [Conexión desde Windows](#connect-windows) como forma alternativa de conectarse al clúster mediante SSL.
Si **Amazon Root CA 1** no está instalado en el sistema operativo, siga los pasos que se indican a continuación.
## Instalación de certificados
Si el certificado `Amazon Root CA 1` no está preinstalado en el sistema operativo, tendrá que instalarlo de forma manual para establecer conexiones seguras con el clúster de Aurora DSQL.
### Instalación de certificados de Linux
Siga estos pasos para instalar el certificado de entidad de certificación de Amazon Root en sistemas de Linux.
1. Descargue el certificado raíz:
```
wget https://www.amazontrust.com/repository/AmazonRootCA1.pem
```
1. Copie el certificado en el almacén de confianza:
```
sudo cp ./AmazonRootCA1.pem /etc/pki/ca-trust/source/anchors/
```
1. Actualice el almacén de confianza de la entidad de certificación:
```
sudo update-ca-trust
```
1. Verificar la instalación:
```
trust list | grep "Amazon Root CA 1"
```
### Instalación de certificado de macOS
Estos pasos de instalación del certificado son opcionales. [Instalación de certificados de Linux](#install-linux) también funciona para macOS.
1. Descargue el certificado raíz:
```
wget https://www.amazontrust.com/repository/AmazonRootCA1.pem
```
1. Agregue el certificado al llavero del sistema:
```
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain AmazonRootCA1.pem
```
1. Verificar la instalación:
```
security find-certificate -a -c "Amazon Root CA 1" -p /Library/Keychains/System.keychain
```
## Conexión con verificación SSL/TLS
Antes de configurar los certificados SSL/TLS para conexiones seguras al clúster de Aurora DSQL, asegúrese de cumplir los siguientes requisitos previos.
+ Se ha instalado la versión 17 de PostgreSQL
+ La AWS CLI se ha configurado con las credenciales apropiadas
+ Información del punto de conexión del clúster de Aurora DSQL
### Conexión desde Linux
1. Genere y configure el token de autenticación:
```
export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint)
```
1. Conéctese mediante certificados del sistema (si están preinstalados):
```
PGSSLROOTCERT=system \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
1. O bien, conéctese mediante un certificado descargado:
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
**nota**
Para obtener más información sobre la configuración de PGSSLMODE, consulte [sslmode](https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-SSLMODE) en la documentación de [Database Connection Control Functions](https://www.postgresql.org/docs/current/libpq-connect.html) de PostgreSQL 17.
### Conexión desde macOS
1. Genere y configure el token de autenticación:
```
export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --hostname your-cluster-endpoint)
```
1. Conéctese mediante certificados del sistema (si están preinstalados):
```
PGSSLROOTCERT=system \
PGSSLMODE=verify-full \
psql --dbname postgres \
--username admin \
--host your-cluster-endpoint
```
1. O bien, descargue el certificado raíz y guárdelo como `root.pem` (si el certificado no está preinstalado)
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql —dbname postgres \
--username admin \
--host your_cluster_endpoint
```
1. Conexión mediante psql:
```
PGSSLROOTCERT=/full/path/to/root.pem \
PGSSLMODE=verify-full \
psql —dbname postgres \
--username admin \
--host your_cluster_endpoint
```
### Conexión desde Windows
#### Uso del símbolo del sistema
1. Generación del token de autenticación:
```
aws dsql generate-db-connect-admin-auth-token ^
--region=your-cluster-region ^
--expires-in=3600 ^
--hostname=your-cluster-endpoint
```
1. Establezca la variables de entorno de contraseña:
```
set "PGPASSWORD=token-from-above"
```
1. Establezca la configuración de SSL:
```
set PGSSLROOTCERT=C:\full\path\to\root.pem
set PGSSLMODE=verify-full
```
1. Conexión a la base de datos:
```
"C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres ^
--username admin ^
--host your-cluster-endpoint
```
#### Con PowerShell
1. Genere y configure el token de autenticación:
```
$env:PGPASSWORD = (aws dsql generate-db-connect-admin-auth-token --region=your-cluster-region --expires-in=3600 --hostname=your-cluster-endpoint)
```
1. Establezca la configuración de SSL:
```
$env:PGSSLROOTCERT='C:\full\path\to\root.pem'
$env:PGSSLMODE='verify-full'
```
1. Conexión a la base de datos:
```
"C:\Program Files\PostgreSQL\17\bin\psql.exe" --dbname postgres `
--username admin `
--host your-cluster-endpoint
```
## Recursos adicionales
+ [Documentación de PostgreSQL SSL](https://www.postgresql.org/docs/current/libpq-ssl.html)
+ [Servicios de confianza de Amazon](https://www.amazontrust.com/repository/)
# Cifrado de datos para Amazon Aurora DSQL
Amazon Aurora DSQL cifra todos los datos en reposo del usuario. Para mejorar la seguridad, este cifrado utiliza AWS Key Management Service (AWS KMS). Esta funcionalidad ayuda a reducir la carga y la complejidad operativas que conlleva la protección de información confidencial. El cifrado en reposo le ayuda a:
+ Reducción de la carga operativa de proteger la información confidencial
+ Creación de aplicaciones sensibles a la seguridad que necesitan cumplimiento estricto de cifrado y requisitos normativos
+ Agregación de una capa adicional de protección de datos protegiendo siempre los datos en un clúster cifrado
+ Conformidad con las políticas de la organización, las normativas del sector o gubernamentales y los requisitos de conformidad
Con Aurora DSQL, puede crear aplicaciones sensibles a la seguridad que necesitan cumplimiento estricto de cifrado y requisitos normativos. En las siguientes secciones se explica cómo configurar el cifrado para las bases de datos de Aurora DSQL nuevas y existentes y cómo administrar las claves de cifrado.
**Topics**
+ [Tipos de claves de KMS para Aurora DSQL](#kms-key-types)
+ [Cifrado en reposo en Aurora DSQL](#encryption-at-rest)
+ [Uso de AWS KMS y claves de datos con Aurora DSQL](#using-kms-and-data-keys)
+ [Autorización del uso de la AWS KMS key para Aurora DSQL](#authorizing-kms-key-use)
+ [Contexto de cifrado de Aurora DSQL](#dsql-encryption-context)
+ [Supervisión de la interacción de Aurora DSQL con AWS KMS](#monitoring-dsql-kms-interaction)
+ [Creación de un clúster de Aurora DSQL cifrado](#creating-encrypted-cluster)
+ [Eliminación o actualización de una clave para el clúster de Aurora DSQL](#updating-encryption-key)
+ [Consideraciones sobre el cifrado con Aurora DSQL](#considerations-with-encryption)
## Tipos de claves de KMS para Aurora DSQL
Aurora DSQL se integra con AWS KMS para administrar las claves de cifrado de los clústeres. Para obtener más información acerca de los tipos y estados de las claves, consulte los [conceptos de AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/concepts-intro.html) en la *Guía para desarrolladores de AWS Key Management Service*. Al crear un clúster nuevo, puede elegir entre los siguientes tipos de claves de KMS para cifrar el clúster:
**Clave propiedad de AWS**
Tipo de cifrado predeterminado. Aurora DSQL es el propietario de la clave sin cargo adicional para usted. Amazon Aurora DSQL descifra de forma transparente los datos del clúster cuando accede a un clúster cifrado. No es necesario que cambie el código o las aplicaciones para utilizar o administrar clústeres cifrados y todas las consultas de Aurora DSQL funcionan con los datos cifrados.
**Clave administrada por clientes**
Puede crear, poseer y administrar la clave en la Cuenta de AWS. Tiene control total de la clave de KMS. Se aplican los cargos de AWS KMS.
El cifrado en reposo mediante la Clave propiedad de AWS está disponible sin cargo adicional. Sin embargo, se aplican cargos de AWS KMS para las claves administradas por el cliente. Para obtener más información, consulte la [Página](https://aws.amazon.com/kms/pricing/) de precios de AWS KMS.
Puede cambiar entre estos tipos de claves en cualquier momento. Para obtener más información sobre los tipos de claves, consulte [Claves administradas por el cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) y [Claves propiedad de AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) en la *Guía para desarrolladores de AWS Key Management Service*.
**nota**
El cifrado en reposo de Aurora DSQL está disponible en todas las regiones de AWS donde esté disponible Aurora DSQL.
## Cifrado en reposo en Aurora DSQL
Amazon Aurora DSQL utiliza el estándar de cifrado avanzado de 256 bits (AES-256) para cifrar los datos en reposo. Este cifrado ayuda a proteger los datos del acceso no autorizado al almacenamiento subyacente. AWS KMS administra las claves de cifrado de los clústeres. Puede usar la opción [Claves propiedad de AWS](#aws-owned-keys) predeterminada, o elegir usar su propia [Claves administradas por el cliente](#customer-managed-keys) de AWS KMS. Para obtener más información sobre cómo especificar y administrar las claves de los clústeres de Aurora DSQL, consulte [Creación de un clúster de Aurora DSQL cifrado](#creating-encrypted-cluster) y [Eliminación o actualización de una clave para el clúster de Aurora DSQL](#updating-encryption-key).
**Topics**
+ [Claves propiedad de AWS](#aws-owned-keys)
+ [Claves administradas por el cliente](#customer-managed-keys)
### Claves propiedad de AWS
Aurora DSQL cifra todos los clústeres de forma predeterminada con Claves propiedad de AWS. Estas claves son de uso gratuito y se rotan anualmente para proteger los recursos de la cuenta. No necesita ver, administrar, usar ni auditar estas claves, por lo que no es necesario realizar ninguna acción para proteger los datos. Para obtener más información acerca de Claves propiedad de AWS, consulte [Claves propiedad de AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk) en la *Guía para desarrolladores de AWS Key Management Service*.
### Claves administradas por el cliente
Cree, posea y administre las claves administradas por el cliente en la Cuenta de AWS. Tiene el control total sobre estas claves de KMS, incluidas sus políticas, el material de cifrado, las etiquetas y los alias. Para obtener más información acerca de cómo administrar los permisos, consulte [Claves administradas por el cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) en la *Guía para desarrolladores de AWS Key Management Service*.
Cuando especifica una clave administrada por el cliente para el cifrado en el nivel de clúster, Aurora DSQL cifra el clúster y todos sus datos regionales con esa clave. Para evitar la pérdida de datos y mantener el acceso al clúster, Aurora DSQL necesita acceder a la clave de cifrado. Si desactiva la clave administrada por el cliente, programa su eliminación o tiene una política que restringe el acceso al servicio, el estado de cifrado del clúster cambia a `KMS_KEY_INACCESSIBLE`. Cuando Aurora DSQL no puede acceder a la clave, los usuarios no pueden conectarse al clúster, el estado de cifrado del clúster cambia a `KMS_KEY_INACCESSIBLE` y el servicio pierde el acceso a los datos del clúster.
En el caso de los clústeres de varias regiones, los clientes pueden configurar la clave de cifrado de AWS KMS de cada región de forma independiente y cada clúster regional utiliza su propia clave de cifrado en el nivel de clúster. Si Aurora DSQL no puede acceder a la clave de cifrado de un par en un clúster de varias regiones, el estado de ese par pasa a ser `KMS_KEY_INACCESSIBLE` y deja de estar disponible para las operaciones de lectura y escritura. Los demás pares continúan con sus operaciones normales.
**nota**
Si Aurora DSQL no puede acceder a su clave administrada por el cliente, el estado de cifrado del clúster cambia a `KMS_KEY_INACCESSIBLE`. Tras restaurar el acceso de la clave, el servicio detectará automáticamente la restauración en 15 minutos. Para obtener más información, consulte clúster en espera.
Para los clústeres de varias regiones, si se pierde el acceso de la clave durante un periodo prolongado, el tiempo de restauración del clúster depende de la cantidad de datos que se hayan escrito mientras la clave no estaba accesible.
## Uso de AWS KMS y claves de datos con Aurora DSQL
La característica de cifrado en reposo de Aurora DSQL utiliza una AWS KMS key y una jerarquía de claves de datos para proteger los datos del clúster.
Le recomendamos que planifique la estrategia de cifrado antes de implementar el clúster en Aurora DSQL. Si almacena datos confidenciales en Aurora DSQL, considere incluir el cifrado del cliente en el plan. De esta forma, puede cifrar los datos lo más cerca posible del origen y garantizar la protección durante todo el ciclo de vida.
**Topics**
+ [Uso de AWS KMS key con Aurora DSQL](#aws-kms-key)
+ [Uso de claves de clúster con Aurora DSQL](#cluster-keys)
+ [Almacenamiento en caché de la clave de clúster](#cluster-key-caching)
### Uso de AWS KMS key con Aurora DSQL
El cifrado en reposo protege el clúster de Aurora DSQL con una AWS KMS key. De forma predeterminada, Aurora DSQL utiliza una Clave propiedad de AWS, una clave de cifrado de varios inquilinos que se crea y administra en una cuenta de servicio de Aurora DSQL. Sin embargo, puede cifrar los clústeres de Aurora DSQL con una clave administrada por el cliente en la Cuenta de AWS. Puede seleccionar una clave de KMS diferente para cada clúster, incluso si participa en una configuración de varias regiones.
Seleccione la clave de KMS para un clúster al crear o actualizar el clúster. Puede cambiar la clave de KMS de un clúster en cualquier momento, ya sea en la consola de Aurora DSQL o utilizando la operación `UpdateCluster`. El proceso de cambio de claves no precisa tiempo de inactividad ni degradación del servicio.
**importante**
Aurora DSQL solo admite claves de KMS simétricas. No puede utilizar una clave de KMS asimétrica para cifrar los clústeres de Aurora DSQL.
Una clave administrada por el cliente proporciona los siguientes beneficios.
+ Puede crear y administrar la clave de KMS, incluida la configuración de políticas de claves y políticas de IAM para controlar el acceso a la clave de KMS. Puede habilitar y deshabilitar la clave KMS, habilitar y deshabilitar la rotación de claves automática y eliminar la clave KMS cuando ya no esté en uso.
+ Puede utilizar una clave administrada por el cliente con material de claves importado o una clave administrada por el cliente en un almacén de claves personalizado que tenga y administre.
+ Puede auditar el cifrado y descifrado del clúster de Aurora DSQL examinando las llamadas a la API de Aurora DSQL a AWS KMS en los registros de AWS CloudTrail.
Sin embargo, la Clave propiedad de AWS es gratuita y su uso no se contabiliza en las cuotas de solicitudes o de recursos de AWS KMS. Las claves administradas por el cliente generan cargos por cada llamada a la API y se aplican cuotas de AWS KMS a estas claves.
### Uso de claves de clúster con Aurora DSQL
Aurora DSQL utiliza la AWS KMS key para el clúster para generar y cifrar una clave de datos única para el clúster, conocida como **clave de clúster**.
La clave del clúster se utiliza como clave de cifrado de claves. Aurora DSQL utiliza esta clave de clúster para proteger las claves de cifrado de datos que se utilizan para cifrar los datos del clúster. Aurora DSQL genera una clave de cifrado de datos única para cada estructura subyacente en un clúster, pero varios elementos del clúster pueden protegerse mediante la misma clave de cifrado de datos.
Para descifrar la clave del clúster, Aurora DSQL envía una solicitud a AWS KMS cuando se accede por primera vez a un clúster cifrado. Para mantener el clúster disponible, Aurora DSQL verifica periódicamente el acceso de descifrado a la clave de KMS, incluso cuando no se está accediendo de forma activa al clúster.
Aurora DSQL almacena y utiliza la clave de clúster y las claves de cifrado de datos fuera de AWS KMS. Protege todas las claves con cifrado Advanced Encryption Standard (AES) y claves de cifrado de 256 bits. A continuación, almacena las claves cifradas con los datos cifrados para que estén disponibles para descifrar los datos del clúster bajo demanda.
Si cambia la clave de KMS del clúster, Aurora DSQL vuelve a cifrar la clave de clúster existente con la nueva clave de KMS.
### Almacenamiento en caché de la clave de clúster
Para evitar llamar a AWS KMS para cada operación de Aurora DSQL, Aurora DSQL almacena en la memoria caché las claves del clúster de texto no cifrado para cada intermediario. Si Aurora DSQL recibe una solicitud de la clave de clúster almacenada en caché tras 15 minutos de inactividad, envía una nueva solicitud a AWS KMS para descifrar la clave de clúster. Esta llamada capturará los cambios realizados en las políticas de acceso de la AWS KMS key, AWS KMS o AWS Identity and Access Management (IAM) desde la última solicitud para descifrar la clave del clúster.
## Autorización del uso de la AWS KMS key para Aurora DSQL
Si utiliza una clave administrada por el cliente en la cuenta para proteger el clúster de Aurora DSQL, las políticas en esa clave deben conceder permiso a Aurora DSQL para utilizarla en su nombre.
Tiene control total sobre las políticas en una clave administrada por el cliente. Aurora DSQL no necesita autorización adicional para utilizar la Clave propiedad de AWS predeterminada para proteger los clústeres de Aurora DSQL de la Cuenta de AWS.
### Política de claves para una clave administrada por el cliente
Cuando selecciona una clave administrada por el cliente para proteger un clúster de Aurora DSQL, Aurora DSQL necesita permiso para utilizar la AWS KMS key en nombre de la entidad principal que realiza la selección. Esa entidad principal, un usuario o rol, deben tener los permisos en la AWS KMS key que precisa Aurora DSQL. Puede proporcionar estos permisos en una política de claves o en una política de IAM.
Como mínimo, Aurora DSQL precisa los siguientes permisos en una clave administrada por el cliente:
+ `kms:Encrypt`
+ `kms:Decrypt`
+ `kms:ReEncrypt*` (para kms:ReEncryptFrom y kms:ReEncryptTo)
+ `kms:GenerateDataKey`
+ `kms:DescribeKey`
Por ejemplo, la política de claves de ejemplo siguiente proporciona solo los permisos necesarios. La política tiene las siguientes consecuencias:
+ Permite a Aurora DSQL utilizar la AWS KMS key en operaciones criptográficas, pero solo cuando actúa en nombre de las entidades principales de la cuenta que tienen permiso para usar Aurora DSQL. Si las entidades principales especificadas en la declaración de política no tienen permiso para utilizar Aurora DSQL, la llamada produce un error, incluso cuando proviene del servicio de Aurora DSQL.
+ La clave de condición `kms:ViaService` permite los permisos solo cuando la solicitud proviene de Aurora DSQL en nombre de las entidades principales mostradas en la declaración de política. Estas entidades principales no pueden llamar a estas operaciones directamente.
Antes de utilizar una política de claves de ejemplo, sustituya las entidades principales de ejemplo por las entidades principales reales de su cuenta de Cuenta de 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"
}
}
}
```
## Contexto de cifrado de Aurora DSQL
Un contexto de cifrado es un conjunto de pares de clave-valor que contienen datos no secretos arbitrarios. Cuando se incluye un contexto de cifrado en una solicitud para cifrar datos, AWS KMS vincula criptográficamente el contexto de cifrado a los datos cifrados. Para descifrar los datos, es necesario pasar el mismo contexto de cifrado.
Aurora DSQL utiliza el mismo contexto de cifrado en todas las operaciones criptográficas de AWS KMS. Si utiliza una clave administrada por el cliente para proteger el clúster de Aurora DSQL, puede utilizar el contexto de cifrado para identificar el uso de la AWS KMS key en los registros de auditoría y en los registros. También aparece en texto sin formato en registros, como aquellos en AWS CloudTrail.
El contexto de cifrado también se puede utilizar como condición para la autorización en políticas.
En sus solicitudes a AWS KMS, Aurora DSQL utiliza un contexto de cifrado con un par clave-valor:
```
"encryptionContext": {
"aws:dsql:ClusterId": "w4abucpbwuxx"
},
```
El par clave-valor identifica el clúster que Aurora DSQL está cifrando. La clave es `aws:dsql:ClusterId`. El valor es el identificador del clúster.
## Supervisión de la interacción de Aurora DSQL con AWS KMS
Si utiliza una clave administrada por el cliente para proteger los clústeres de Aurora DSQL, puede utilizar los registros de AWS CloudTrail para realizar un seguimiento de las solicitudes que Aurora DSQL envía a AWS KMS en su nombre.
Expanda las siguientes secciones para obtener información sobre cómo Aurora DSQL utiliza las operaciones de AWS KMS `GenerateDataKey` y `Decrypt`.
### `GenerateDataKey`
Cuando habilita el cifrado en reposo en un clúster, Aurora DSQL crea una clave de clúster única. Envía una solicitud de `GenerateDataKey` a AWS KMS que especifica la AWS KMS key del clúster.
El evento que registra la operación `GenerateDataKey` es similar al siguiente evento de ejemplo. El usuario es la cuenta del servicio de Aurora DSQL. Los parámetros incluyen el Nombre de recurso de Amazon (ARN) de la AWS KMS key, un especificador de claves que requiere una clave de 256 bits y el contexto de cifrado que identifica el clúster.
```
{
"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
Cuando accede a un clúster de Aurora DSQL cifrado, Aurora DSQL necesita descifrar la clave del clúster de manera que pueda descifrar las claves que hay debajo en la jerarquía. A continuación, descifra los datos del clúster. Para descifrar la clave del clúster, Aurora DSQL envía una solicitud `Decrypt` a AWS KMS que especifica la AWS KMS key del clúster.
El evento que registra la operación `Decrypt` es similar al siguiente evento de ejemplo. El usuario es la entidad principal en la Cuenta de AWS que está accediendo al clúster. Los parámetros incluyen la clave del clúster cifrada (como blob de texto cifrado) y el contexto de cifrado que identifica el clúster. AWS KMS deriva el ID de la AWS KMS key del texto cifrado.
```
{
"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"
}
```
## Creación de un clúster de Aurora DSQL cifrado
Todos los clústeres de Aurora DSQL se cifran en reposo. De forma predeterminada, los clústeres utilizan una Clave propiedad de AWS sin costo o puede especificar una clave de AWS KMS personalizada. Siga estos pasos para crear el clúster cifrado desde la Consola de administración de AWS o desde la AWS CLI.
------
#### [ Console ]
**Creación de un clúster cifrado en la Consola de administración de AWS**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Aurora DSQL en [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql/).
1. En el panel de navegación en el lado izquierdo de la consola, en DAX, elija **Clústeres**.
1. Elija **Crear clúster** en la parte superior derecha y seleccione **Región única**.
1. En la **Configuración de cifrado del clúster**, elija una de las siguientes opciones.
+ Acepte la configuración predeterminada para cifrar con una Clave propiedad de AWS sin costo adicional.
+ Seleccione **Personalizar la configuración de cifrado (avanzada)** para especificar una clave de KMS personalizada. A continuación, busque o ingrese el ID o el alias de la clave de KMS. Otra opción, elija **Crear una clave de AWS KMS** para crear una clave nueva en la consola de AWS KMS.
1. Elija **Create cluster**.
Para confirmar el tipo de cifrado del clúster, vaya a la página **Clústeres** y seleccione el ID del clúster para ver los detalles del clúster. Revise la pestaña **Configuración del clúster**. La configuración de la **clave de KMS del clúster** muestra la **clave predeterminada de Aurora DSQL** para los clústeres que utilizan claves propiedad de AWS o el ID de clave para otros tipos de cifrado.
**nota**
Si decide ser propietario y administrar su propia clave, asegúrese de establecer la política de claves de KMS adecuada. Para obtener más información y ejemplos, consulte [Política de claves para una clave administrada por el cliente](#key-policy-customer-managed-key).
------
#### [ CLI ]
**Creación de un clúster que esté cifrado con la Clave propiedad de AWS predeterminada**
+ Utilice el siguiente comando para crear un clúster de Aurora DSQL.
```
aws dsql create-cluster
```
Como se muestra en los siguientes detalles de cifrado, el estado de cifrado del clúster está habilitado de forma predeterminada y el tipo de cifrado predeterminado es la clave propiedad de AWS. El clúster ahora está cifrado con la clave predeterminada propiedad de AWS en la cuenta de servicio de Aurora DSQL.
```
"encryptionDetails": {
"encryptionType" : "AWS_OWNED_KMS_KEY",
"encryptionStatus" : "ENABLED"
}
```
**Creación de un clúster cifrado con la clave administrada por el cliente**
+ Utilice el siguiente comando para crear un clúster de Aurora DSQL y sustituya el ID de clave en texto rojo por el ID de la clave administrada por el cliente.
```
aws dsql create-cluster \
--kms-encryption-key d41d8cd98f00b204e9800998ecf8427e
```
Como se muestra en los siguientes detalles de cifrado, el estado de cifrado del clúster está habilitado de forma predeterminada y el tipo de cifrado es la clave de KMS administrada por el cliente. El clúster ahora está cifrado con su clave.
```
"encryptionDetails": {
"encryptionType" : "CUSTOMER_MANAGED_KMS_KEY",
"kmsKeyArn" : "arn:aws:kms:us-east-1:111122223333:key/d41d8cd98f00b204e9800998ecf8427e",
"encryptionStatus" : "ENABLED"
}
```
------
## Eliminación o actualización de una clave para el clúster de Aurora DSQL
Puede utilizar la Consola de administración de AWS o la AWS CLI para actualizar o eliminar las claves de cifrado de los clústeres existentes en Amazon Aurora DSQL. Si quita una clave sin sustituirla, Aurora DSQL utilizará la Clave propiedad de AWS predeterminada. Siga estos pasos para actualizar las claves de cifrado de un clúster existente desde la consola de Aurora DSQL o desde la AWS CLI.
------
#### [ Console ]
**Actualización o eliminación de una clave de cifrado en la Consola de administración de AWS**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Aurora DSQL en [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql/).
1. En el panel de navegación en el lado izquierdo de la consola, en DAX, elija **Clústeres**.
1. En la vista de lista, busque y seleccione la fila del clúster que desea actualizar.
1. Seleccione el menú **Acciones** y, a continuación, elija **Modificar**.
1. En la **Configuración de cifrado del clúster**, elija una de las siguientes opciones para modificar la configuración de cifrado.
+ Si desea cambiar de una clave personalizada a una Clave propiedad de AWS, desactive la opción **Personalizar la configuración de cifrado (avanzada)**. Se aplicará la configuración predeterminada y se cifrará el clúster con una Clave propiedad de AWS sin costo alguno.
+ Si desea cambiar de una clave de KMS personalizada a otra o de una Clave propiedad de AWS a una clave de KMS, seleccione la opción **Personalizar la configuración de cifrado (avanzada)** si aún no está seleccionada. A continuación, busque y seleccione el ID o el alias de la clave que desee utilizar. Otra opción, elija **Crear una clave de AWS KMS** para crear una clave nueva en la consola de AWS KMS.
1. Seleccione **Save**.
------
#### [ CLI ]
Los siguientes ejemplos muestran cómo usar la AWS CLI para actualizar un clúster cifrado.
Actualización de un clúster cifrado con la Clave propiedad de AWS predeterminada
```
aws dsql update-cluster \
--identifier aiabtx6icfp6d53snkhseduiqq \
--kms-encryption-key "AWS_OWNED_KMS_KEY"
```
El `EncryptionStatus` de la descripción del clúster se establece en `ENABLED` y el `EncryptionType` es `AWS_OWNED_KMS_KEY`.
```
"encryptionDetails": {
"encryptionType" : "AWS_OWNED_KMS_KEY",
"encryptionStatus" : "ENABLED"
}
```
Este clúster está ahora cifrado mediante la Clave propiedad de AWS predeterminada en la cuenta de servicio de Aurora DSQL.
Actualización de un clúster cifrado con una clave administrada por el cliente para Aurora DSQL
Actualice el clúster cifrado, como en el siguiente ejemplo:
```
aws dsql update-cluster \
--identifier aiabtx6icfp6d53snkhseduiqq \
--kms-encryption-key arn:aws:kms:us-east-1:123456789012:key/abcd1234-abcd-1234-a123-ab1234a1b234
```
El `EncryptionStatus` de la descripción del clúster pasa a `UPDATING` y el `EncryptionType` es `CUSTOMER_MANAGED_KMS_KEY`. Cuando Aurora DSQL termine de propagar la nueva clave a través de la plataforma, el estado de cifrado pasará a `ENABLED`
```
"encryptionDetails": {
"encryptionType" : "CUSTOMER_MANAGED_KMS_KEY",
"kmsKeyArn" : "arn:aws:us-east-1:kms:key/abcd1234-abcd-1234-a123-ab1234a1b234",
"encryptionStatus" : "ENABLED"
}
```
------
**nota**
Si decide ser propietario y administrar su propia clave, asegúrese de establecer la política de claves de KMS adecuada. Para obtener más información y ejemplos, consulte [Política de claves para una clave administrada por el cliente](#key-policy-customer-managed-key).
## Consideraciones sobre el cifrado con Aurora DSQL
+ Aurora DSQL cifra todos los datos en reposo del clúster. No puede desactivar este cifrado ni cifrar solo algunos elementos de un clúster.
+ AWS Backup cifra las copias de seguridad y los clústeres restaurados a partir de estas copias de seguridad. Puede cifrar los datos de copia de seguridad en AWS Backup mediante la clave propiedad de AWS o una clave administrada por el cliente.
+ Los siguientes estados de protección de datos están habilitados para Aurora DSQL:
+ **Datos en reposo**: Aurora DSQL cifra todos los datos estáticos de los medios de almacenamiento persistentes
+ **Datos en tránsito**: Aurora DSQL cifra todas las comunicaciones mediante la seguridad de la capa de transporte (TLS) de forma predeterminada
+ Cuando realice la transición a una clave diferente, le recomendamos que mantenga la clave original habilitada hasta que se complete la transición. AWS necesita la clave original para descifrar los datos antes de cifrarlos con la nueva clave. El proceso finaliza cuando el `encryptionStatus` del clúster es `ENABLED` y usted ve el `kmsKeyArn` de la nueva clave administrada por el cliente.
+ Cuando desactiva la clave administrada por el cliente o revoca el acceso para que Aurora DSQL utilice su clave, el clúster pasará al estado `IDLE`.
+ La API de Consola de administración de AWS y de Amazon Aurora DSQL utilizan términos diferentes para los tipos de cifrado:
+ Consola de AWS: en la consola, verá `KMS` cuando use una clave administrada por el cliente y `DEFAULT` cuando use una Clave propiedad de AWS.
+ API: la API de Amazon Aurora DSQL utiliza `CUSTOMER_MANAGED_KMS_KEY` para las claves administradas por el cliente y `AWS_OWNED_KMS_KEY` para Claves propiedad de AWS.
+ Si no especifica una clave de cifrado durante la creación del clúster, Aurora DSQL cifra automáticamente los datos mediante Clave propiedad de AWS.
+ Puede alternar entre una Clave propiedad de AWS y una clave administrada por el cliente en cualquier momento. Realice este cambio mediante la Consola de administración de AWS, la AWS CLI o la API de Amazon Aurora DSQL.
# Administración de la identidad y el acceso para Aurora DSQL
AWS Identity and Access Management (IAM) es un Servicio de AWS que ayuda a los administradores a controlar de forma segura el acceso a los recursos de AWS. Los administradores de IAM controlan a qué personas se puede *autenticar* (pueden iniciar sesión) y *autorizar* (tienen permisos) para utilizar recursos de Aurora DSQL. IAM es un Servicio de AWS que se puede utilizar sin cargo adicional.
**Topics**
+ [Público](#security_iam_audience)
+ [Autenticación con identidades](#security_iam_authentication)
+ [Administración del acceso con políticas](#security_iam_access-manage)
+ [Cómo funciona Amazon Aurora DSQL con IAM](security_iam_service-with-iam.md)
+ [Ejemplos de políticas basadas en identidad para Amazon Aurora DSQL](security_iam_id-based-policy-examples.md)
+ [Solución de problemas de identidades y accesos en Amazon Aurora DSQL](security_iam_troubleshoot.md)
## Público
La forma de utilizar AWS Identity and Access Management (IAM) varía en función del rol:
+ **Usuario del servicio:** solicite permisos al administrador si no puede acceder a las características (consulte [Solución de problemas de identidades y accesos en Amazon Aurora DSQL](security_iam_troubleshoot.md)).
+ **Administrador del servicio:** determine el acceso de los usuarios y envíe las solicitudes de permiso (consulte [Cómo funciona Amazon Aurora DSQL con IAM](security_iam_service-with-iam.md)).
+ **Administrador de IAM**: escribe las políticas para administrar el acceso (consulte [Ejemplos de políticas basadas en identidad para Amazon Aurora DSQL](security_iam_id-based-policy-examples.md)).
## Autenticación con identidades
La autenticación es la manera de iniciar sesión en AWS mediante credenciales de identidad. Debe autenticarse como el Usuario raíz de la cuenta de AWS, como un usuario de IAM o asumiendo un rol de IAM.
Se puede iniciar sesión como una identidad federada con las credenciales de un origen de identidad, como AWS IAM Identity Center (IAM Identity Center), la autenticación de inicio de sesión único o las credenciales de Google/Facebook. Para obtener más información sobre el inicio de sesión, consulte [Cómo iniciar sesión en la Cuenta de AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) en la *Guía del usuario de AWS Sign-In*.
Para el acceso mediante programación, AWS proporciona un SDK y una CLI para firmar criptográficamente las solicitudes. Para obtener más información, consulte [AWS Signature Version 4 para solicitudes de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) en la *Guía del usuario de IAM*.
### Usuario raíz de la Cuenta de AWS
Cuando se crea una Cuenta de AWS, se comienza con una identidad de inicio de sesión denominada *usuario raíz* de la Cuenta de AWS que tiene acceso completo a todos los Servicios de AWS y recursos. Se recomiendaencarecidamente que no utilice el usuario raíz para las tareas diarias. Para ver las tareas que requieren credenciales de usuario raíz, consulte [Tareas que requieren credenciales de usuario raíz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) en la *Guía del usuario de IAM*.
### Identidad federada
Como práctica recomendada, exija a los usuarios humanos que utilicen la federación con un proveedor de identidades para acceder a Servicios de AWS con credenciales temporales.
Una *identidad federada* es un usuario del directorio empresarial, proveedor de identidad web o Directory Service que accede a los Servicios de AWS mediante credenciales de un origen de identidad. Las identidades federadas asumen roles que proporcionan credenciales temporales.
Para una administración de acceso centralizada, se recomienda AWS IAM Identity Center. Para obtener más información, consulte [¿Qué es el Centro de identidades de IAM?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) en la *Guía del usuario de AWS IAM Identity Center*.
### Usuarios y grupos de IAM
Un *[usuario de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* es una identidad con permisos específicos para una sola persona o aplicación. Recomendamos el uso de credenciales temporales en lugar de usuarios de IAM con credenciales de larga duración. Para obtener más información, consulte [Exigir que los usuarios humanos utilicen la federación con un proveedor de identidades para acceder a AWS con credenciales temporales](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) en la *Guía del usuario de IAM*.
Un [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica un conjunto de usuarios de IAM y facilita la administración de los permisos para grupos grandes de usuarios. Para obtener más información, consulte [Casos de uso para usuarios de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) en la *Guía del usuario de IAM*.
### Roles de IAM
Un *[Rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* es una identidad con permisos específicos que proporciona credenciales temporales. Se puede asumir un rol [cambiando de un usuario a un rol de IAM (consola)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) o llamando a una operación de la API de la AWS CLI o AWS. Para obtener más información, consulte [Métodos para asumir un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) en la *Guía del usuario de IAM*.
Los roles de IAM son útiles para el acceso de usuario federado, los permisos de usuario de IAM temporales, el acceso entre cuentas, el acceso entre servicios y las aplicaciones que se ejecutan en Amazon EC2. Para obtener más información, consulte [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
## Administración del acceso con políticas
Para controlar el acceso en AWS, se crean políticas y se adjuntan a identidades o recursos de AWS. Una política define los permisos cuando se asocia a una identidad o un recurso. AWS evalúa estas políticas cuando una entidad principal realiza una solicitud. La mayoría de las políticas se almacenan en AWS como documentos JSON. Para obtener más información sobre los documentos de políticas de JSON, consulte [Información general de políticas de JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) en la *Guía del usuario de IAM*.
Mediante las políticas, los administradores especifican quién tiene acceso a qué, definiendo qué **entidad principal** puede realizar **acciones** sobre qué **recursos** y en qué **condiciones**.
De forma predeterminada, los usuarios y los roles no tienen permisos. Un administrador de IAM crea políticas de IAM y las agrega a roles, que los usuarios pueden asumir posteriormente. Las políticas de IAM definen permisos independientemente del método que se utilice para realizar la operación.
### Políticas basadas en identidades
Las políticas basadas en identidad son documentos de política de permisos JSON que asocia a una identidad (usuario, grupo o rol). Estas políticas controlan qué acciones pueden realizar las identidades, en qué recursos y en qué condiciones. Para obtener más información sobre cómo crear una política basada en la identidad, consulte [Definición de permisos de IAM personalizados con políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*.
Las políticas basadas en identidad pueden ser *políticas insertadas* (incrustadas directamente en una sola identidad) o *políticas administradas* (políticas independientes asociadas a varias identidades). Para obtener información sobre cómo elegir entre políticas administradas e insertadas, consulte [Selección entre políticas administradas y políticas insertadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) en la *Guía del usuario de IAM*.
### Políticas basadas en recursos
Las políticas basadas en recursos son documentos de políticas JSON que se asocian a un recurso. Los ejemplos incluyen las *Políticas de confianza de roles* de IAM y las *Políticas de bucket* de Amazon S3. En los servicios que admiten políticas basadas en recursos, los administradores de servicios pueden utilizarlos para controlar el acceso a un recurso específico. Debe [especificar una entidad principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) en una política basada en recursos.
Las políticas basadas en recursos son políticas insertadas que se encuentran en ese servicio. No se pueden utilizar políticas de IAM administradas por AWS en una política basada en recursos.
### Otros tipos de políticas
AWS admite tipos de políticas adicionales que pueden establecer el máximo de permisos concedidos por los tipos de políticas más frecuentes:
+ **Límites de permisos:** establecen los permisos máximos que una política basada en identidad puede conceder a una entidad de IAM. Para obtener más información, consulte [Límites de permisos para las entidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) en la *Guía del usuario de IAM*.
+ **Políticas de control de servicios (SCP):** especifican los permisos máximos para una organización o unidad organizativa en AWS Organizations. Para obtener más información, consulte [Políticas de control de servicios](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) en la *Guía del usuario de AWS Organizations*.
+ **Políticas de control de recursos (RCP):** definen los permisos máximos disponibles para los recursos de las cuentas. Para obtener más información, consulte [Políticas de control de recursos (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) en la *Guía del usuario de AWS Organizations*.
+ **Políticas de sesión:** políticas avanzadas que se pasan como parámetro cuando se crea una sesión temporal para un rol o un usuario federado. Para obtener más información, consulte [Políticas de sesión](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) en la *Guía del usuario de IAM*.
### Varios tipos de políticas
Cuando se aplican varios tipos de políticas a una solicitud, los permisos resultantes son más complicados de entender. Para obtener información acerca de cómo AWS decide si permitir o no una solicitud cuando hay varios tipos de políticas implicados, consulte [Lógica de evaluación de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) en la *Guía del usuario de IAM*.
# Cómo funciona Amazon Aurora DSQL con IAM
Antes de utilizar IAM para administrar el acceso a Aurora DSQL, obtenga más información sobre qué características de IAM se encuentran disponibles para utilizarlas con Aurora DSQL.
**Características de IAM que puede utilizar con Amazon Aurora DSQL**
| Característica de IAM | Compatibilidad con Aurora DSQL |
| --- | --- |
| [Políticas basadas en identidades](#security_iam_service-with-iam-id-based-policies) | Sí |
| [Políticas basadas en recursos](#security_iam_service-with-iam-resource-based-policies) | Sí |
| [Acciones de políticas](#security_iam_service-with-iam-id-based-policies-actions) | Sí |
| [Recursos de políticas](#security_iam_service-with-iam-id-based-policies-resources) | Sí |
| [Claves de condición de política](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Sí |
| [ACL](#security_iam_service-with-iam-acls) | No |
| [ABAC (etiquetas en políticas)](#security_iam_service-with-iam-tags) | Sí |
| [Credenciales temporales](#security_iam_service-with-iam-roles-tempcreds) | Sí |
| [Permisos de entidades principales](#security_iam_service-with-iam-principal-permissions) | Sí |
| [Roles de servicio](#security_iam_service-with-iam-roles-service) | Sí |
| [Roles vinculados al servicio](#security_iam_service-with-iam-roles-service-linked) | Sí |
Para obtener información general sobre cómo funcionan Aurora DSQL y otros servicios de AWS con la mayoría de las características de IAM, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) en la *Guía del usuario de IAM*.
## Políticas basadas en identidad para Aurora DSQL
**Compatibilidad con las políticas basadas en identidad:** sí
Las políticas basadas en identidad son documentos de políticas de permisos JSON que puede asociar a una identidad, como un usuario de IAM, un grupo de usuarios o un rol. Estas políticas controlan qué acciones pueden realizar los usuarios y los roles, en qué recursos y en qué condiciones. Para obtener más información sobre cómo crear una política basada en la identidad, consulte [Definición de permisos de IAM personalizados con políticas administradas por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*.
Con las políticas basadas en identidades de IAM, puede especificar las acciones y los recursos permitidos o denegados, así como las condiciones en las que se permiten o deniegan las acciones. Para obtener más información sobre los elementos que puede utilizar en una política de JSON, consulte [Referencia de los elementos de la política de JSON de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) en la *Guía del usuario de IAM*.
### Ejemplos de políticas basadas en identidad para Aurora DSQL
Para ver ejemplos de políticas basadas en identidad de Aurora DSQL, consulte [Ejemplos de políticas basadas en identidad para Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## Políticas basadas en recursos de Aurora DSQL
**Compatibilidad con las políticas basadas en recursos:** sí
Las políticas basadas en recursos son documentos de política JSON que se asocian a un recurso. Los ejemplos de políticas basadas en recursos son las políticas de confianza de roles de IAM y las políticas de bucket de Amazon S3. En los servicios que admiten políticas basadas en recursos, los administradores de servicios pueden utilizarlos para controlar el acceso a un recurso específico. Para el recurso al que se asocia la política, la política define qué acciones puede realizar una entidad principal especificada en ese recurso y en qué condiciones. Debe [especificar una entidad principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) en una política basada en recursos. Las entidades principales pueden incluir cuentas, usuarios, roles, usuarios federados o servicios de AWS. Las políticas basadas en recursos son políticas insertadas que se encuentran en ese servicio. No puede utilizar políticas administradas de AWS de IAM en una política basada en recursos.
Para obtener información sobre cómo crear y administrar políticas basadas en recursos para los clústeres de Aurora DSQL, consulte [Políticas basadas en recursos para Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/resource-based-policies.html).
## Acciones de políticas para Aurora DSQL
**Compatibilidad con las acciones de políticas:** sí
Los administradores pueden utilizar las políticas JSON de AWS para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Action` de una política JSON describe las acciones que puede utilizar para conceder o denegar el acceso en una política. Incluya acciones en una política para conceder permisos y así llevar a cabo la operación asociada.
Para ver una lista de las acciones de Aurora DSQL, consulte [Acciones definidas por Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-actions-as-permissions) en la *Referencia de autorizaciones de servicio*.
Las acciones de políticas de Aurora DSQL utilizan el siguiente prefijo antes de la acción:
```
dsql
```
Para especificar varias acciones en una única instrucción, sepárelas con comas.
```
"Action": [
"dsql:action1",
"dsql:action2"
]
```
Para ver ejemplos de políticas basadas en identidad de Aurora DSQL, consulte [Ejemplos de políticas basadas en identidad para Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## Recursos de políticas para Aurora DSQL
**Compatibilidad con los recursos de políticas:** sí
Los administradores pueden utilizar las políticas JSON de AWS para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Resource` de la política JSON especifica el objeto u objetos a los que se aplica la acción. Como práctica recomendada, especifique un recurso utilizando el [Nombre de recurso de Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). En el caso de las acciones que no admiten permisos por recurso, utilice un carácter comodín (\$1) para indicar que la instrucción se aplica a todos los recursos.
```
"Resource": "*"
```
Para ver una lista de tipos de recursos de Aurora DSQL y los ARN, consulte [Tipos de recurso definidos por Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-resources-for-iam-policies) en la *Referencia de autorizaciones de servicio*. Para obtener información acerca de las acciones con las que puede especificar el ARN de cada recurso, consulte [Acciones definidas por Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html#your_service-actions-as-permissions).
Para ver ejemplos de políticas basadas en identidad de Aurora DSQL, consulte [Ejemplos de políticas basadas en identidad para Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## Claves de condición de políticas de Aurora DSQL
**Compatibilidad con claves de condición de políticas específicas del servicio:** sí
Los administradores pueden utilizar las políticas JSON de AWS para especificar quién tiene acceso a qué. Es decir, qué **entidad principal** puede realizar **acciones** en qué **recursos** y en qué **condiciones**.
El elemento `Condition` especifica cuándo se ejecutan las instrucciones en función de criterios definidos. Puede crear expresiones condicionales que utilizan [operadores de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), tales como igual o menor que, para que la condición de la política coincida con los valores de la solicitud. Para ver todas las claves de condición globales de AWS, consulte [Claves de contexto de condición globales de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) en la *Guía del usuario de IAM*.
Para ver una lista de las claves de condición de Aurora DSQL, consulte [Claves de condición para Amazon Aurora DSQL](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonauroradsql.html#amazonauroradsql-policy-keys) en la *Referencia de autorizaciones de servicio*. Para obtener información acerca de las acciones y los recursos con los que puede utilizar una clave de condición, consulte [Acciones definidas por Amazon Aurora DSQL](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonauroradsql.html#amazonauroradsql-actions-as-permissions).
Para ver ejemplos de políticas basadas en identidad de Aurora DSQL, consulte [Ejemplos de políticas basadas en identidad para Amazon Aurora DSQL](security_iam_id-based-policy-examples.md).
## ACL en Aurora DSQL
**Compatibilidad con ACL**: no
Las listas de control de acceso (ACL) controlan qué entidades principales (miembros de cuentas, usuarios o roles) tienen permisos para acceder a un recurso. Las ACL son similares a las políticas basadas en recursos, aunque no utilizan el formato de documento de políticas JSON.
## ABAC con Aurora DSQL
**Admite ABAC (etiquetas en las políticas):** sí
El control de acceso basado en atributos (ABAC) es una estrategia de autorización que define permisos en función de atributos denominados etiquetas. Puede asociar etiquetas a entidades de IAM y recursos de AWS y, a continuación, diseñar políticas de ABAC para permitir operaciones cuando la etiqueta de la entidad principal coincida con la etiqueta del recurso.
Para controlar el acceso en función de etiquetas, debe proporcionar información de las etiquetas en el [elemento de condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de una política utilizando las claves de condición `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` o `aws:TagKeys`.
Si un servicio admite las tres claves de condición para cada tipo de recurso, el valor es **Sí** para el servicio. Si un servicio admite las tres claves de condición solo para algunos tipos de recursos, el valor es **Parcial**.
*Para obtener más información sobre ABAC, consulte [Definición de permisos con la autorización de ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) en la Guía del usuario de IAM*. Para ver un tutorial con los pasos para configurar ABAC, consulte [Uso del control de acceso basado en atributos (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) en la *Guía del usuario de IAM*.
## Uso de credenciales temporales con Aurora DSQL
**Compatibilidad con credenciales temporales:** sí
Las credenciales temporales proporcionan acceso a corto plazo a los recursos de AWS y se crean automáticamente cuando se utiliza la federación o se cambia de rol. AWS recomienda generar credenciales temporales de forma dinámica en lugar de usar claves de acceso a largo plazo. Para obtener más información, consulte [Credenciales de seguridad temporales en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) y [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) en la *Guía del usuario de IAM*.
## Permisos de entidades principales entre servicios de Aurora DSQL
**Admite sesiones de acceso directo (FAS):** sí
Las sesiones de acceso directo (FAS) utilizan los permisos de la entidad principal para llamar a un Servicio de AWS, combinados con el Servicio de AWS solicitante, para realizar solicitudes a servicios posteriores. Para obtener información sobre las políticas a la hora de realizar solicitudes de FAS, consulte [Sesiones de acceso directo](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Roles de servicio para Aurora DSQL
**Compatible con roles de servicio:** sí
Un rol de servicio es un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que asume un servicio para realizar acciones en su nombre. Un administrador de IAM puede crear, modificar y eliminar un rol de servicio desde IAM. Para obtener más información, consulte [Crear un rol para delegar permisos a un Servicio de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) en la *Guía del usuario de IAM*.
**aviso**
Cambiar los permisos para un rol de servicio podría interrumpir la funcionalidad de Aurora DSQL. Edite los roles de servicio solo cuando Aurora DSQL proporcione orientación para hacerlo.
## Roles vinculados al servicio para Aurora DSQL
**Compatible con roles vinculados al servicio:** sí
Un rol vinculado a servicios es un tipo de rol de servicio que está vinculado a un Servicio de AWS. El servicio puede asumir el rol para realizar una acción en su nombre. Los roles vinculados a servicios aparecen en la Cuenta de AWS y son propiedad del servicio. Un administrador de IAM puede ver, pero no editar, los permisos de los roles vinculados a servicios.
Para obtener información acerca de cómo crear o administrar roles vinculados a servicios para Aurora SQL, consulte [Uso de los roles vinculados al servicio en Aurora DSQL](working-with-service-linked-roles.md).
# Ejemplos de políticas basadas en identidad para Amazon Aurora DSQL
De forma predeterminada, los usuarios y roles no tienen permiso para crear, ver ni modificar recursos de Aurora DSQL. Un administrador de IAM puede crear políticas de IAM para conceder permisos a los usuarios para realizar acciones en los recursos que necesitan.
Para obtener información acerca de cómo crear una política basada en identidad de IAM mediante el uso de estos documentos de políticas JSON de ejemplo, consulte [Creación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) en la *Guía del usuario de IAM*.
Para obtener detalles sobre las acciones y los tipos de recursos definidos por Aurora DSQL, incluido el formato de los ARN para cada uno de los tipos de recursos, consulte [Acciones, recursos y claves de condición para Amazon Aurora DSQL](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_your_service.html) en la *Referencia de autorización de servicios*.
**Topics**
+ [Prácticas recomendadas sobre las políticas](#security_iam_service-with-iam-policy-best-practices)
+ [Uso de la consola de Aurora DSQL](#security_iam_id-based-policy-examples-console)
+ [Cómo permitir a los usuarios consultar sus propios permisos](#security_iam_id-based-policy-examples-view-own-permissions)
+ [Permitir la administración del clúster y la conexión a bases de datos](#security_iam_id-based-policy-examples-cluster-management)
+ [Acceso a recursos de Aurora DSQL basados en etiquetas](#security_iam_id-based-policy-examples-tag-based-access)
## Prácticas recomendadas sobre las políticas
Las políticas basadas en identidad determinan si alguien puede crear recursos de Aurora DSQL de la cuenta, acceder a ellos o eliminarlos. Estas acciones pueden generar costos adicionales para su Cuenta de AWS. Siga estas directrices y recomendaciones al crear o editar políticas basadas en identidades:
+ **Comience a utilizar las políticas administradas de AWS y avance hacia permisos de privilegios mínimos**. Para empezar a conceder permisos a los usuarios y cargas de trabajo, utilice las *políticas administradas de AWS* que otorgan permisos para muchos casos de uso comunes. Están disponibles en su Cuenta de AWS. Se recomienda definir políticas administradas por el cliente de AWS específicas para sus casos de uso a fin de reducir aún más los permisos. Con el fin de obtener más información, consulte las [políticas administradas por AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) o las [políticas administradas por AWS para funciones de tarea](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) en la *Guía de usuario de IAM*.
+ **Aplique permisos de privilegio mínimo**: cuando establezca permisos con políticas de IAM, conceda solo los permisos necesarios para realizar una tarea. Para ello, debe definir las acciones que se pueden llevar a cabo en determinados recursos en condiciones específicas, también conocidos como *permisos de privilegios mínimos*. Con el fin de obtener más información sobre el uso de IAM para aplicar permisos, consulte [Políticas y permisos en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) en la *Guía del usuario de IAM*.
+ **Utilice condiciones en las políticas de IAM para restringir aún más el acceso**: puede agregar una condición a sus políticas para limitar el acceso a las acciones y los recursos. Por ejemplo, puede escribir una condición de políticas para especificar que todas las solicitudes deben enviarse utilizando SSL. También puede usar condiciones para conceder acceso a acciones de servicios si se emplean a través de un Servicio de AWS determinado como, por ejemplo, CloudFormation. Para obtener más información, consulte [Elementos de la política de JSON de IAM: Condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) en la *Guía del usuario de IAM*.
+ **Utiliza el analizador de acceso de IAM para validar las políticas de IAM con el fin de garantizar la seguridad y funcionalidad de los permisos**: el analizador de acceso de IAM valida políticas nuevas y existentes para que respeten el lenguaje (JSON) de las políticas de IAM y las prácticas recomendadas de IAM. El analizador de acceso de IAM proporciona más de 100 verificaciones de políticas y recomendaciones procesables para ayudar a crear políticas seguras y funcionales. Para más información, consulte [Validación de políticas con el Analizador de acceso de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) en la *Guía del usuario de IAM*.
+ **Solicite la autenticación multifactor (MFA)**: si se encuentra en una situación en la que necesite usuarios raíz o de IAM en su Cuenta de AWS, active la MFA para obtener una mayor seguridad. Para exigir la MFA cuando se invoquen las operaciones de la API, añada condiciones de MFA a sus políticas. Para más información, consulte [Acceso seguro a la API con MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) en la *Guía del usuario de IAM*.
Para obtener más información sobre las prácticas recomendadas de IAM, consulte [Prácticas recomendadas de seguridad en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) en la *Guía del usuario de IAM*.
## Uso de la consola de Aurora DSQL
Para acceder a la consola de Amazon Aurora DSQL, debe tener un conjunto mínimo de permisos. Estos permisos deben permitirle mostrar y consultar los detalles sobre los recursos de Aurora DSQL en la Cuenta de AWS. Si crea una política basada en identidades que sea más restrictiva que el mínimo de permisos necesarios, la consola no funcionará del modo esperado para las entidades (usuarios o roles) que tengan esa política.
No es necesario conceder permisos mínimos para la consola a los usuarios que solo realizan llamadas a la AWS CLI o a la API de AWS. En su lugar, permita el acceso únicamente a las acciones que coincidan con la operación de API que intentan realizar.
Para asegurarse de que los usuarios y los roles puedan seguir utilizando la consola de Aurora DSQL, asocie también a las entidades la política administrada de AWS `AmazonAuroraDSQLConsoleFullAccess` o `AmazonAuroraDSQLReadOnlyAccess` de Aurora DSQL. Para obtener más información, consulte [Adición de permisos a un usuario](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) en la *Guía del usuario de IAM*:
## Cómo permitir a los usuarios consultar sus propios permisos
En este ejemplo, se muestra cómo podría crear una política que permita a los usuarios de IAM ver las políticas administradas e insertadas que se asocian a la identidad de sus usuarios. Esta política incluye permisos para llevar a cabo esta acción en la consola o mediante programación con la AWS CLI o la API de 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": "*"
}
]
}
```
## Permitir la administración del clúster y la conexión a bases de datos
La siguiente política otorga a un usuario de IAM permiso para administrar y conectarse a un clúster de Aurora DSQL específico. La política aplica las acciones de administración y conexión de clústeres a un único nombre de recurso de Amazon (ARN) del clúster, al tiempo que permite `dsql:ListClusters` en todos los recursos, ya que esta acción no admite permisos a nivel de recurso.
Este ejemplo se utiliza `dsql:DbConnectAdmin` para conectarse con el rol de `admin`. Para conectarse con un rol de base de datos personalizado, sustituya `dsql:DbConnectAdmin` por `dsql:DbConnect`. Para obtener más información, consulte [Autenticación y autorización para 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": "*"
}
]
}
```
------
## Acceso a recursos de Aurora DSQL basados en etiquetas
Puede utilizar las condiciones de su política basada en identidad para controlar el acceso a los recursos de Aurora DSQL basados en etiquetas. En el siguiente ejemplo se muestra cómo se puede crear una política que permita visualizar un clúster. Sin embargo, los permisos solo se conceden si la etiqueta de clúster `Owner` tiene el valor del nombre de usuario de dicho usuario. Esta política también proporciona los permisos necesarios para llevar a cabo esta acción en la consola.
------
#### [ 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}"
}
}
}
]
}
```
------
También puede asociar esta política al usuario de IAM en su cuenta. Si un usuario llamado `richard-roe` intenta ver un clúster de Aurora DSQL, el clúster debe tener la etiqueta `Owner=richard-roe` o `owner=richard-roe`. De lo contrario, IAM deniega el acceso. La clave de la etiqueta de condición `Owner` coincide con los nombres de las claves de condición `Owner` y `owner` porque no distinguen entre mayúsculas y minúsculas. Para obtener más información, consulte [Elementos de la política de JSON de IAM: Condición](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) en la *Guía del usuario de IAM*.
La siguiente política permite a un usuario crear clústeres solo si etiqueta el clúster con su propio nombre de usuario como `Owner`. También permite etiquetar solo los clústeres que el usuario ya posee.
------
#### [ 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}"
}
}
}
]
}
```
------
# Solución de problemas de identidades y accesos en Amazon Aurora DSQL
Utilice la siguiente información para diagnosticar y solucionar los problemas comunes que puedan surgir cuando trabaje con Aurora DSQL e IAM.
**Topics**
+ [No tengo autorización para realizar una acción en Aurora DSQL](#security_iam_troubleshoot-no-permissions)
+ [No tengo autorización para realizar la operación iam:PassRole](#security_iam_troubleshoot-passrole)
+ [Quiero permitir a personas externas a mi Cuenta de AWS el acceso a mis recursos en Aurora DSQL](#security_iam_troubleshoot-cross-account-access)
## No tengo autorización para realizar una acción en Aurora DSQL
Si recibe un error que indica que no tiene autorización para realizar una acción, las políticas se deben actualizar para permitirle realizar la acción.
En el siguiente ejemplo, el error se produce cuando `mateojackson` intenta utilizar la consola para consultar los detalles acerca de un recurso `my-dsql-cluster`, pero no tiene los permisos `GetCluster`.
```
User: iam:::user/mateojackson is not authorized to perform: GetCluster on resource: my-dsql-cluster
```
En este caso, la política del usuario `mateojackson` debe actualizarse para permitir el acceso al recurso `my-dsql-cluster` mediante la acción `GetCluster`.
Si necesita ayuda, contacte con su administrador de . El administrador es la persona que le proporcionó las credenciales de inicio de sesión.
## No tengo autorización para realizar la operación iam:PassRole
Si recibe un error que indica que no tiene autorización para realizar la acción `iam:PassRole`, se deben actualizar las políticas a fin de permitirle pasar un rol a Aurora DSQL.
Algunos Servicios de AWS le permiten transferir un rol existente a dicho servicio en lugar de crear un nuevo rol de servicio o uno vinculado al servicio. Para ello, debe tener permisos para transferir el rol al servicio.
En el siguiente ejemplo, el error se produce cuando un usuario de IAM denominado `marymajor` intenta utilizar la consola para realizar una acción en Aurora DSQL. Sin embargo, la acción requiere que el servicio cuente con permisos que otorguen un rol de servicio. Mary no tiene permisos para transferir el rol al servicio.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
En este caso, las políticas de Mary se deben actualizar para permitirle realizar la acción `iam:PassRole`.
Si necesita ayuda, póngase en contacto con su administrador de AWS. El administrador es la persona que le proporcionó las credenciales de inicio de sesión.
## Quiero permitir a personas externas a mi Cuenta de AWS el acceso a mis recursos en Aurora DSQL
Se puede crear un rol que los usuarios de otras cuentas o las personas externas a la organización puedan utilizar para acceder a sus recursos. Se puede especificar una persona de confianza para que asuma el rol. En el caso de los servicios que admitan las políticas basadas en recursos o las listas de control de acceso (ACL), puede utilizar dichas políticas para conceder a las personas acceso a sus recursos.
Para obtener más información, consulte lo siguiente:
+ Para obtener información acerca de si Aurora DSQL admite estas características, consulte [Cómo funciona Amazon Aurora DSQL con IAM](security_iam_service-with-iam.md).
+ Para obtener información sobre cómo proporcionar acceso a los recursos de las Cuentas de AWS de su propiedad, consulte [Proporcionar acceso a un usuario de IAM a otra Cuenta de AWS de la que es propietario](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) en la *Guía del usuario de IAM*.
+ Para obtener información acerca de cómo proporcionar acceso a sus recursos a Cuentas de AWS de terceros, consulte [Proporcionar acceso a Cuentas de AWS que son propiedad de terceros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) en la *Guía del usuario de IAM*.
+ Para obtener información sobre cómo proporcionar acceso mediante una federación de identidades, consulte [Proporcionar acceso a usuarios autenticados externamente (identidad federada)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) en la *Guía del usuario de IAM*.
+ Para conocer sobre la diferencia entre las políticas basadas en roles y en recursos para el acceso entre cuentas, consulte [Acceso a recursos entre cuentas en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) en la *Guía del usuario de IAM*.
# Políticas basadas en recursos para Aurora DSQL
Utilice políticas basadas en recursos para Aurora DSQL a fin de restringir o conceder el acceso a los clústeres mediante documentos de política JSON que se adjuntan directamente a los recursos del clúster. Estas políticas proporcionan un control detallado sobre quién puede acceder al clúster y en qué condiciones.
Se puede acceder a los clústeres de Aurora DSQL desde el Internet público de forma predeterminada, con la autenticación de IAM como control de seguridad principal. Las políticas basadas en recursos le permiten agregar restricciones de acceso, especialmente para bloquear el acceso desde el Internet público.
Las políticas basadas en recursos funcionan junto con políticas basadas en identidad de IAM. AWS evalúa ambos tipos de políticas para determinar los permisos finales para cualquier solicitud de acceso al clúster. De forma predeterminada, los clústeres de Aurora DSQL son accesibles dentro de una cuenta. Si un usuario o rol de IAM tiene permisos de Aurora DSQL, puede acceder a los clústeres sin una política basada en recursos adjunta.
**nota**
Con el tiempo, los cambios en las políticas basadas en los recursos son coherentes y, por lo general, se hacen efectivos en un minuto.
Para obtener más información sobre las diferencias entre las políticas basadas en identidad y las políticas basadas en recursos, consulte [Políticas basadas en identidad y políticas basadas en recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html) en la *Guía del usuario de IAM*.
## Cuándo utilizar políticas basadas en recursos
Las políticas basadas en recursos son particularmente útiles en estos escenarios:
+ *Control de acceso basado en la red*: restrinja el acceso en función de la VPC o la dirección IP desde la que se originan las solicitudes o bloquee por completo el acceso público a Internet. Use claves de condición como `aws:SourceVpc` y `aws:SourceIp` para controlar el acceso a la red.
+ *Varios equipos o aplicaciones*: conceda acceso al mismo clúster para varios equipos o aplicaciones. En lugar de administrar las políticas de IAM individuales para cada entidad principal, se definen las reglas de acceso una vez en el clúster.
+ *Acceso condicional complejo*: controle el acceso en función de varios factores, como los atributos de la red, el contexto de la solicitud y los atributos del usuario. Puede combinar varias condiciones en una sola política.
+ *Gobernanza de seguridad centralizada*: permita a los propietarios de los clústeres controlar el acceso mediante una sintaxis de políticas de AWS familiar que se integre con las prácticas de seguridad actuales.
**nota**
Las políticas basadas en recursos de Aurora DSQL aún no admiten el acceso entre cuentas, pero estará disponible en futuras versiones.
Cuando alguien intenta conectarse al clúster de Aurora DSQL, AWS evalúa su política basada en recursos como parte del contexto de autorización, junto con cualquier política de IAM pertinente, para determinar si la solicitud se debe permitir o rechazar.
Las políticas basadas en recursos pueden conceder acceso a las entidades principales de la misma cuenta de AWS que el clúster. En el caso de los clústeres de varias regiones, cada clúster regional tiene su propia política basada en los recursos, lo que permite establecer controles de acceso específicos para cada región cuando sea necesario.
**nota**
Las claves de contexto de condición pueden variar entre regiones (como los ID de VPC).
**Topics**
+ [Cuándo se debe usar](#rbp-when-to-use)
+ [Creación con políticas](rbp-create-cluster.md)
+ [Agregación y edición de políticas](rbp-attach-policy.md)
+ [Visualización de la política](rbp-view-policy.md)
+ [Eliminación de política](rbp-remove-policy.md)
+ [Ejemplos de políticas](rbp-examples.md)
+ [Bloqueo del acceso público](rbp-block-public-access.md)
+ [Operaciones de API](rbp-api-operations.md)
# Creación de clústeres con políticas basadas en recursos
Puede adjuntar políticas basadas en recursos al crear un nuevo clúster para garantizar que los controles de acceso estén implementados desde el principio. Cada clúster puede tener una única política insertada adjunta directamente al clúster.
## AWSConsola de administración de
**Agregación de una política basada en recursos durante la creación del clúster**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Aurora DSQL en [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql).
1. Elija **Create cluster**.
1. Configure el nombre, las etiquetas y los ajustes multirregionales del clúster según sea necesario.
1. En la sección **Configuración del clúster**, busque la opción de **política basada en recursos**.
1. Active **Agregar una política basada en recursos**.
1. Ingrese el documento de la política en el editor JSON. Por ejemplo, para bloquear el acceso público a Internet:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect",
"dsql:DbConnectAdmin"
],
"Condition": {
"Null": {
"aws:SourceVpc": "true"
}
}
}
]
}
```
1. Puede usar **Editar instrucción** o **Agregar nueva instrucción** para crear la política.
1. Complete la configuración del clúster restante y elija **Crear clúster**.
## AWS CLI
Utilice el parámetro `--policy` al crear un clúster para adjuntar una política insertada:
```
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 SDK
------
#### [ 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());
```
------
# Agregación y edición de políticas basadas en recursos para clústeres
## AWSConsola de administración de
**Agregación de una política basada en recursos a un clúster existente**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Aurora DSQL en [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql).
1. Elija el clúster de la lista de clústeres para abrir la página de detalles del clúster.
1. Elija la pestaña **Permisos**.
1. En la sección **Política basada en recursos**, elija **Agregar política**.
1. Ingrese el documento de la política en el editor JSON. Puede usar **Editar instrucción** o **Agregar nueva instrucción** para crear la política.
1. Elija **Add Policy (Agregar política)**.
**Edición de una política basada en recursos existente**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Aurora DSQL en [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql).
1. Elija el clúster de la lista de clústeres para abrir la página de detalles del clúster.
1. Elija la pestaña **Permisos**.
1. En la sección **Política basada en recursos**, seleccione **Editar**.
1. Modifique el documento de la política en el editor JSON. Puede usar **Editar instrucción** o **Agregar nueva instrucción** para actualizar la política.
1. Seleccione **Save changes (Guardar cambios)**.
## AWS CLI
Use el comando `put-cluster-policy` para adjuntar una nueva política o actualizar una política existente en un clúster:
```
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 SDK
------
#### [ 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);
```
------
# Visualización de políticas basadas en recursos
Puede ver las políticas basadas en recursos asociadas a los clústeres para comprender los controles de acceso vigentes actualmente.
## AWSConsola de administración de
**Visualización de políticas basadas en recursos**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Aurora DSQL en [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql).
1. Elija el clúster de la lista de clústeres para abrir la página de detalles del clúster.
1. Elija la pestaña **Permisos**.
1. Consulte la política adjunta en la sección de **política basada en recursos**.
## AWS CLI
Use el comando `get-cluster-policy` para ver la política basada en recursos de un clúster:
```
aws dsql get-cluster-policy --identifier your_cluster_id
```
## AWS SDK
------
#### [ 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());
```
------
# Eliminación de políticas basadas en recursos
Puede eliminar las políticas basadas en recursos de los clústeres para cambiar los controles de acceso.
**importante**
Cuando elimine todas políticas basadas en recursos de un clúster, el acceso lo controlarán por completo las políticas basadas en la identidad de IAM.
## AWSConsola de administración de
**Eliminación de una política basada en recursos**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Aurora DSQL en [https://console.aws.amazon.com/dsql/](https://console.aws.amazon.com/dsql).
1. Elija el clúster de la lista de clústeres para abrir la página de detalles del clúster.
1. Elija la pestaña **Permisos**.
1. En la sección **Política basada en recursos**, elija **Eliminar**.
1. En el cuadro de diálogo de confirmación, ingrese **confirm** para confirmar la eliminación.
1. Elija **Eliminar**.
## AWS CLI
Utilice el comando `delete-cluster-policy` para eliminar una política de un clúster:
```
aws dsql delete-cluster-policy --identifier your_cluster_id
```
## AWS SDK
------
#### [ 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");
```
------
# Ejemplos de políticas basadas en recursos comunes
Estos ejemplos muestran patrones comunes para controlar el acceso a los clústeres de Aurora DSQL. Puede combinar y modificar estos patrones para adaptarlos a sus requisitos de acceso específicos.
## Bloqueo del acceso público a Internet
Esta política bloquea las conexiones a los clústeres de Aurora DSQL desde el Internet público (no VPC). La política no especifica desde qué VPC pueden conectarse los clientes, solo que deben conectarse desde una VPC. Para limitar el acceso a una VPC específica, use `aws:SourceVpc` con el operador de condición `StringEquals`.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect",
"dsql:DbConnectAdmin"
],
"Condition": {
"Null": {
"aws:SourceVpc": "true"
}
}
}
]
}
```
**nota**
Este ejemplo solo usa `aws:SourceVpc` para comprobar las conexiones de VPC. Las claves de condición `aws:VpcSourceIp` y `aws:SourceVpce` proporcionan un mayor grado de detalle, pero no son necesarias para el control de acceso básico exclusivo de la VPC.
Para proporcionar una excepción para roles específicos, utilice esta política en su lugar:
```
{
"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"
]
}
}
}
]
}
```
## Restricción del acceso a una organización de AWS
Esta política restringe el acceso a las entidades principales de una organización de AWS:
```
{
"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"
}
}
}
]
}
```
## Restricción del acceso a una unidad organizativa específica
Esta política restringe el acceso a las entidades principales de una unidad organizativa (UO) específica de una organización de AWS, lo que proporciona un control más detallado que el acceso a toda la organización:
```
{
"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/*"
}
}
}
]
}
```
## Políticas de clúster multirregionales
En el caso de los clústeres multirregionales, cada clúster regional tiene su propia política de recursos, lo que permite establecer controles específicos para cada región. A continuación, se muestra un ejemplo con diferentes políticas por región:
*Política de us-east:*
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect"
],
"Condition": {
"StringNotEquals": {
"aws:SourceVpc": "vpc-east1-id"
},
"Null": {
"aws:SourceVpc": "true"
}
}
}
]
}
```
*Política de us-east:*
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"dsql:DbConnect"
],
"Condition": {
"StringEquals": {
"aws:SourceVpc": "vpc-east2-id"
}
}
}
]
}
```
**nota**
Las claves de contexto de condición pueden variar entre Regiones de AWS (como los ID de VPC).
# Bloqueo de acceso público con políticas basadas en recursos en Aurora DSQL
El bloqueo de acceso público (BPA) es una característica que identifica y evita que se asocien políticas basadas en recursos que conceden acceso público a los clústeres de Aurora DSQL en las cuentas de AWS. Con BPA, puede impedir el acceso público a los recursos de Aurora DSQL. BPA realiza comprobaciones durante la creación o modificación de una política basada en recursos y ayuda a mejorar la seguridad con Aurora DSQL.
BPA utiliza un [razonamiento automatizado](https://aws.amazon.com/what-is/automated-reasoning/) para analizar el acceso que concede su política basada en recursos y le avisa si encuentra dichos permisos al administrar una política basada en recursos. El análisis verifica el acceso a todas las instrucciones de políticas basadas en recursos, las acciones y el conjunto de claves de condición que se utilizan en sus políticas.
**importante**
BPA ayuda a proteger los recursos al impedir que se conceda acceso público a través de las políticas basadas en recursos que se asocian directamente a los recursos de Aurora DSQL, como clústeres. Además de habilitar BPA, analice detenidamente las siguientes políticas para confirmar que no otorgan acceso público:
Políticas basadas en identidad asociadas a las entidades principales de AWS vinculadas (por ejemplo, los roles de IAM)
Políticas basadas en recursos adjuntas a recursos de AWS asociados (por ejemplo, claves de AWS Key Management Service [KMS])
Debe asegurarse de que la [entidad principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) no incluya una entrada `*` o que una de las claves de condición especificadas restrinja el acceso de las entidades principales al recurso. Si la política basada en recursos concede acceso público al clúster en las cuentas de AWS, Aurora DSQL le impedirá crear o modificar la política hasta que se corrija la especificación de la política y se considere no pública.
Para que una política no sea pública, especifique una o más entidades principales dentro del bloque `Principal`. El siguiente ejemplo de política basada en recursos bloquea el acceso público al especificar dos entidades principales.
```
{
"Effect": "Allow",
"Principal": {
"AWS": [
"123456789012",
"111122223333"
]
},
"Action": "dsql:*",
"Resource": "arn:aws:dsql:us-east-1:123456789012:cluster/cluster-id"
}
```
Las políticas que restringen el acceso al especificar determinadas claves de condición tampoco se consideran públicas. Junto con la evaluación de la entidad principal especificada en la política basada en recursos, se utilizan las siguientes [claves de condición fiables](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) para completar la evaluación de una política basada en recursos para el acceso no público:
+ `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`
Además, para que una política basada en recursos no sea pública, los valores del Nombre de recurso de Amazon (ARN) y las claves de cadena no deben contener comodines ni variables. Si su política basada en recursos usa la clave `aws:PrincipalIsAWSService`, debe asegurarse de establecer el valor de la clave en true.
La siguiente política limita el acceso al usuario `Ben` de la cuenta especificada. La condición limita a la `Principal` y no se considera pública.
```
{
"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"
}
}
}
```
El siguiente ejemplo de una política basada en recursos no pública restringe `sourceVPC` al usar el operador `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"
]
}
}
}
]
}
```
# Operaciones de la API de Aurora DSQL y políticas basadas en recursos
Las políticas basadas en recursos de Aurora DSQL controlan el acceso a operaciones de API específicas. En las siguientes secciones se muestran todas las operaciones de la API de Aurora DSQL organizadas por categoría, con una indicación de cuáles admiten políticas basadas en recursos.
La columna *Admite RBP* indica si la operación de la API está sujeta a una evaluación de políticas basada en los recursos cuando se adjunta una política al clúster.
## API de etiquetas
| Operación de API | Descripción | Admite RBP |
| --- | --- | --- |
| [ListTagsForResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_ListTagsForResource.html) | Muestra las etiquetas de un recurso de Aurora DSQL | Sí |
| [TagResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_TagResource.html) | Agrega etiquetas a un recurso de Aurora DSQL | Sí |
| [UntagResource](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_UntagResource.html) | Elimina etiquetas de un recurso de Aurora DSQL | Sí |
## API de administración de clústeres
| Operación de API | Descripción | Admite RBP |
| --- | --- | --- |
| [CreateCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_CreateCluster.html) | Crea un nuevo clúster. | No |
| [DeleteCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_DeleteCluster.html) | Elimina un clúster | Sí |
| [GetCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetCluster.html) | Recupera información sobre un clúster | Sí |
| [GetVpcEndpointServiceName](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetVpcEndpointServiceName.html) | Recupera el nombre de servicio del punto de conexión de VPC para un clúster | Sí |
| [ListClusters](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_ListClusters.html) | Muestra los clústeres de la cuenta | No |
| [UpdateCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_UpdateCluster.html) | Actualiza la configuración de un clúster | Sí |
## API de propiedad multirregional
| Operación de API | Descripción | Admite RBP |
| --- | --- | --- |
| [AddPeerCluster](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_AddPeerCluster.html) | Agrega un clúster de emparejamiento a una configuración multirregional | Sí |
| [PutMultiRegionProperties](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutMultiRegionProperties.html) | Establece las propiedades multirregionales de un clúster | Sí |
| [PutWitnessRegion](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutWitnessRegion.html) | Establece la región testigo de un clúster multirregional | Sí |
## API de política basada en recursos
| Operación de API | Descripción | Admite RBP |
| --- | --- | --- |
| [DeleteClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_DeleteClusterPolicy.html) | Elimina la política basada en recursos de un clúster | Sí |
| [GetClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetClusterPolicy.html) | Recupera la política basada en recursos de un clúster | Sí |
| [PutClusterPolicy](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_PutClusterPolicy.html) | Crea o actualiza la política basada en recursos de un clúster | Sí |
## AWS Fault Injection ServiceLas API de
| Operación de API | Descripción | Admite RBP |
| --- | --- | --- |
| [InjectError](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_InjectError.html) | Inyecta errores en las pruebas de inyección de errores | No |
## API de copia de seguridad y restauración
| Operación de API | Descripción | Admite RBP |
| --- | --- | --- |
| [GetBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetBackupJob.html) | Recupera información sobre un trabajo de copia de seguridad | No |
| [GetRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_GetRestoreJob.html) | Recupera información sobre un trabajo de restauración | No |
| [StartBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StartBackupJob.html) | Inicia un trabajo de copia de seguridad para un clúster | Sí |
| [StartRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StartRestoreJob.html) | Inicia un trabajo de restauración a partir de una copia de seguridad | No |
| [StopBackupJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StopBackupJob.html) | Detiene un trabajo de copia de seguridad en ejecución | No |
| [StopRestoreJob](https://docs.aws.amazon.com/aurora-dsql/latest/APIReference/API_StopRestoreJob.html) | Detiene un trabajo de restauración en ejecución | No |
# Uso de los roles vinculados al servicio en Aurora DSQL
Aurora DSQL utiliza [roles vinculados al servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) de AWS Identity and Access Management (IAM). Un rol vinculado a un servicio es un tipo único de rol de IAM que está vinculado directamente con Aurora DSQL. Los roles vinculados al servicio están predefinidos en Aurora DSQL e incluyen todos los permisos que el servicio requiere para llamar a Servicios de AWS en nombre del clúster de Aurora DSQL.
Los roles vinculados al servicio facilitan el proceso de configuración porque no tiene que agregar manualmente los permisos necesarios para utilizar Aurora DSQL. Cuando crea un clúster, Aurora DSQL crea automáticamente un rol vinculado al servicio para usted. Puede eliminar el rol vinculado al servicio solo después de eliminar todos los clústeres. De esta forma, se protegen los recursos de Aurora DSQL, ya que evita que se puedan eliminar accidentalmente los permisos necesarios para acceder a los recursos.
Para obtener información sobre otros servicios que admiten roles vinculados a servicios, consulte [Servicios de AWS que funcionan con IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) y busque los servicios que muestran **Sí** en la columna **Rol vinculado al servicio**. Elija una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión.
Los roles vinculados al servicio están disponibles en todas las regiones de Aurora DSQL admitidas.
## Permisos de rol vinculado al servicio para Aurora DSQL
Aurora DSQL utiliza el rol vinculado al servicio denominado `AWSServiceRoleForAuroraDsql`. Permite a Amazon Aurora DSQL crear y administrar recursos de AWS en su nombre. Este rol vinculado al servicio está asociado a la siguiente política administrada: [AuroraDsqlServiceLinkedRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AuroraDsqlServiceLinkedRolePolicy.html).
**nota**
Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o rol) crear, editar o eliminar un rol vinculado a servicios. Podría encontrarse con el siguiente mensaje de error: `You don't have the permissions to create an Amazon Aurora DSQL service-linked role`. Si aparece este mensaje, asegúrese de que tiene los siguientes permisos habilitados:
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CreateDsqlServiceLinkedRole",
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:AWSServiceName": "dsql.amazonaws.com"
}
}
}
]
}
```
Para obtener más información, consulte [Permisos de rol vinculado al servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#service-linked-role-permissions.html).
## Creación de un rol vinculado al servicio
No necesita crear manualmente un rol vinculado al servicio AuroraDSQLServiceLinkedRolePolicy. Aurora DSQL crea el rol vinculado al servicio por usted. Si el rol vinculado al servicio AuroraDSQLServiceLinkedRolePolicy se ha eliminado de la cuenta, Aurora DSQL crea el rol cuando usted crea un nuevo clúster de Aurora DSQL.
## Edición de un rol vinculado a servicios
Aurora DSQL no le permite editar el rol vinculado al servicio AuroraDSQLServiceLinkedRolePolicy. Después de crear un rol vinculado a un servicio, no puede cambiarle el nombre, ya que varias entidades pueden hacer referencia a él. No obstante, puede editar la descripción del rol con la consola de IAM, la AWS Command Line Interface (AWS CLI) o la API de IAM.
## Eliminar un rol vinculado a un servicio
Si ya no necesita usar una característica o servicio que requieran un rol vinculado a un servicio, le recomendamos que elimine dicho rol. De esta forma, no tiene una entidad no utilizada que no se supervise ni mantenga de forma activa.
Antes de poder eliminar un rol vinculado al servicio de una cuenta, debe eliminar cualquier clúster de la cuenta.
Puede utilizar la consola de IAM, la AWS CLI o la API de IAM para eliminar un rol vinculado a un servicio. Para obtener más información, consulte [Creación de un rol vinculado al servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html#delete-service-linked-role) en la Guía del usuario de IAM.
## Regiones admitidas para los roles vinculados al servicio de Aurora DSQL
Aurora DSQL admite el uso de roles vinculados al servicio en todas las regiones en las que el servicio esté disponible. Para obtener más información, consulte [Puntos de conexión y Regiones de AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# Uso de claves de condición de IAM con Amazon Aurora DSQL
Al conceder permisos en Aurora DSQL, puede especificar condiciones que determinan cómo se aplica una política de permisos. Los siguientes ejemplos muestran cómo puede usar claves de condición en las políticas de permisos de Aurora DSQL.
## Ejemplo 1: concesión de permiso para crear un clúster en una Región de AWS específica
La siguiente política concede permiso para crear clústeres en las regiones Este de EE. UU. (Norte de Virginia) y Este de EE. UU. (Ohio). Esta política utiliza el recurso ARN para limitar las regiones permitidas, por lo que Aurora DSQL solo puede crear clústeres si ese ARN está especificado en la sección `Resource` de la política.
------
#### [ 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"
}
]
}
```
------
## Ejemplo 2: concesión de permiso para crear un clúster multirregional en una Región de AWS específica o en varias
La siguiente política concede permiso para crear clústeres multirregionales en las regiones Este de EE. UU. (Norte de Virginia) y Este de EE. UU. (Ohio). Esta política utiliza el ARN de recurso para limitar las regiones permitidas, por lo que Aurora DSQL solo puede crear clústeres de varias regiones si ese ARN está especificado en la sección `Resource` de la política. Tenga en cuenta que la creación de clústeres de varias regiones también requiere los permisos `PutMultiRegionProperties`, `PutWitnessRegion` y `AddPeerCluster` en cada región especificada.
------
#### [ 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/*"
]
}
]
}
```
------
## Ejemplo 3: concesión de permiso para crear un clúster multirregional con una región testigo específica
La siguiente política utiliza una clave de condición `dsql:WitnessRegion` de Aurora DSQL y permite a un usuario crear clústeres multirregionales con una región testigo en Oeste de EE. UU. (Oregón). Si no especifica la condición `dsql:WitnessRegion`, puede usar cualquier región como testigo.
------
#### [ 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"
]
}
}
}
]
}
```
------
# Respuesta a incidentes en Amazon Aurora DSQL
La seguridad de AWS es nuestra mayor prioridad. Como parte del modelo de responsabilidad compartida de la nube de AWS, AWS administra una arquitectura de red, software y centro de datos que cumple los requisitos de seguridad de las organizaciones más exigentes. AWS se encarga de responder a cualquier incidente relacionado con el propio servicio de Amazon Aurora DSQL. Como cliente de AWS, usted comparte la responsabilidad de mantener la seguridad en la nube. Esto significa que usted controla la seguridad que decide implementar desde las herramientas y características de AWS a las que tiene acceso. Además, usted es responsable de la respuesta a los incidentes en su parte del modelo de responsabilidad compartida.
Al establecer una base de seguridad que cumpla con los objetivos de las aplicaciones que se ejecutan en la nube, puede detectar las desviaciones a las que puede responder. Para ayudarle a entender el impacto que la respuesta a los incidentes y sus decisiones tienen en sus objetivos empresariales, le recomendamos que consulte los siguientes recursos:
+ [AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)
+ [AWS Prácticas recomendadas para la seguridad, la identidad y el cumplimiento de](https://aws.amazon.com/architecture/security-identity-compliance/)
+ Documento técnico [Perspectiva de seguridad de AWS Cloud Adoption Framework (CAF)](https://docs.aws.amazon.com/whitepapers/latest/overview-aws-cloud-adoption-framework/security-perspective.html)
[Amazon GuardDuty](https://aws.amazon.com/guardduty/) es un servicio administrado de detección de amenazas que supervisa de forma continua los comportamientos malintencionados o no autorizados para ayudar a los clientes a proteger las cargas de trabajo y las Cuentas de AWS e identificar posibles actividades sospechosas antes de que se conviertan en un incidente. Supervisa actividades como las llamadas inusuales a la API o las implementaciones potencialmente no autorizadas, lo que indica la posibilidad de que las cuentas o los recursos se vean comprometidos o el reconocimiento por parte de personas malintencionadas. Por ejemplo, Amazon GuardDuty es capaz de detectar actividades sospechosas en las API de Amazon Aurora DSQL, como el inicio de sesión de un usuario desde una nueva ubicación y la creación de un nuevo clúster.
# Validación del cumplimiento para Amazon Aurora DSQL
Para saber si un Servicio de AWS está incluido en el alcance de programas de cumplimiento específicos, se consulta [Servicios de AWS incluidos por programa de cumplimiento](https://aws.amazon.com/compliance/services-in-scope/) y se elige el programa de cumplimiento que interese. Para obtener información general, consulte [Programas de conformidad de AWS](https://aws.amazon.com/compliance/programs/).
Puede descargar los informes de auditoría de terceros utilizando AWS Artifact. Para obtener más información, consulte [Descarga de informes en AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Su responsabilidad de conformidad al utilizar Servicios de AWS se determina en función de la confidencialidad de los datos, los objetivos de conformidad de la empresa, así como de la legislación y los reglamentos aplicables. Para obtener más información sobre la responsabilidad de cumplimiento al usar Servicios de AWS, consulte la [Documentación de seguridad de AWS](https://docs.aws.amazon.com/security/).
# Resiliencia en Amazon Aurora DSQL
La infraestructura global de AWS se divide en Regiones de AWS y zonas de disponibilidad (AZ). Las Regiones de AWS proporcionan varias zonas de disponibilidad físicamente independientes y aisladas que se encuentran conectadas mediante redes con un alto nivel de rendimiento y redundancia, además de baja latencia. Con las zonas de disponibilidad, puede diseñar y utilizar aplicaciones y bases de datos que realizan una conmutación por error automática entre las zonas sin interrupciones. Las zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las infraestructuras tradicionales de uno o varios centros de datos. Aurora DSQL se ha diseñado para que pueda aprovechar la infraestructura regional de AWS y, al mismo tiempo, proporcionar la máxima disponibilidad de base de datos. De forma predeterminada, los clústeres de una sola región en Aurora DSQL tienen disponibilidad Multi-AZ, lo que proporciona tolerancia a los principales errores de los componentes y a las interrupciones de la infraestructura que podrían afectar el acceso a una AZ completa. Los clústeres multirregionales proporcionan todos los beneficios de la resiliencia Multi-AZ a la vez que siguen proporcionando la disponibilidad de base de datos de alta coherencia, incluso en los casos en los que Región de AWS es inaccesible para los clientes de la aplicación.
Para obtener más información sobre las Regiones de AWS y las zonas de disponibilidad, consulte [Infraestructura global de AWS](https://aws.amazon.com/about-aws/global-infrastructure/).
Además de la infraestructura global de AWS, Aurora DSQL ofrece varias características que lo ayudan con las necesidades de resiliencia y copia de seguridad de los datos.
## Copia de seguridad y restauración
Aurora DSQL admite copias de seguridad y restauración con Consola de AWS Backup. Puede realizar una copia de seguridad completa y restaurar los clústeres de una sola región y de varias regiones. Para obtener más información, consulte [Copia de seguridad y restauración para Amazon Aurora DSQLCopia de seguridad y restauración](backup-aurora-dsql.md).
## Replicación
Por diseño, Aurora DSQL confirma todas las transacciones de escritura en un registro de transacciones distribuido y replica de forma síncrona todos los datos de registro confirmados en réplicas de almacenamiento de usuario en tres AZ. Los clústeres multirregionales proporcionan capacidades completas de replicación entre regiones de lectura y escritura.
Una región testigo designada admite escrituras solo de registro de transacciones y no consume almacenamiento. Las regiones testigo no tienen punto de conexión. Esto significa que las regiones testigo solo almacenan registros de transacciones cifrados, no requieren administración ni configuración y no son accesibles para los usuarios. Si la región testigo deja de funcionar correctamente, la disponibilidad del clúster no se ve afectada. Las transacciones de escritura podrían experimentar un ligero aumento de la latencia hasta que la región testigo se recupere.
Los registros de transacciones de Aurora DSQL y el almacenamiento del usuario se distribuyen con todos los datos presentados a los procesadores de consultas de Aurora DSQL como un único volumen lógico. Aurora DSQL divide, combina y replica automáticamente los datos basándose en el intervalo de clave principal de la base de datos y en los patrones de acceso. Aurora DSQL escala y reduce verticalmente las réplicas de lectura de forma automática basándose en la frecuencia de acceso de lectura.
Las réplicas de almacenamiento de clúster se distribuyen a través de una flota de almacenamiento de varios inquilinos. Si un componente o AZ se deteriora, Aurora DSQL redirige automáticamente el acceso a los componentes supervivientes y repara de forma asíncrona las réplicas que faltan. Una vez que Aurora DSQL repara las réplicas deterioradas, las vuelve a agregar automáticamente al quórum de almacenamiento y las pone a disposición del clúster.
## Alta disponibilidad
De forma predeterminada, los clústeres de una sola región y multirregionales en Aurora DSQL son activo-activo, y no necesita aprovisionar, configurar ni reconfigurar manualmente ningún clúster. Aurora DSQL automatiza completamente la recuperación del clúster, lo que elimina la necesidad de las tradicionales operaciones de conmutación por error principal-secundario. La replicación es siempre síncrona y se realiza en múltiples AZ, por lo que no hay riesgo de pérdida de datos debido al retardo en la replicación o a la conmutación por error a una base de datos secundaria asíncrona durante la recuperación por error.
Los clústeres de una sola región proporcionan un punto de conexión redundante Multi-AZ que habilita automáticamente el acceso simultáneo con una gran coherencia de datos en tres AZ. Esto significa que las réplicas de almacenamiento de usuario en cualquiera de estas tres AZ siempre devuelven el mismo resultado a uno o más lectores y siempre están disponibles para recibir escrituras. Esta sólida coherencia y resiliencia Multi-AZ está disponible en todas las regiones para los clústeres multirregionales de Aurora DSQL. Esto significa que los clústeres multirregionales proporcionan dos puntos de conexión regionales de alta coherencia, por lo que los clientes pueden leer o escribir indistintamente en cualquiera de las regiones con un retardo de replicación cero en la confirmación.
Aurora DSQL proporciona una disponibilidad del 99,99 % para clústeres de una sola región y del 99,999 % para clústeres multirregionales.
## Pruebas de inyección de errores
Amazon Aurora DSQL se integra con AWS Fault Injection Service (AWS FIS), un servicio totalmente administrado para ejecutar experimentos de inyección de errores controlados a fin de mejorar la resiliencia de una aplicación. Con AWS FIS, puede:
+ Creación de plantillas de experimentos que definan escenarios de error específicos
+ Inserción de errores (tasas elevadas de errores de conexión al clúster) para validar los mecanismos de gestión y recuperación de errores de las aplicaciones
+ Prueba del comportamiento de las aplicaciones multirregionales para validar el cambio de tráfico de una aplicación entre Regiones de AWS cuando una Región de AWS está experimentando altas tasas de error de conexión
Por ejemplo, en un clúster multirregional que abarca Este de EE. UU. (Norte de Virginia) y Este de EE. UU. (Ohio), puede ejecutar un experimento en Este de EE. UU. (Ohio) para probar errores allí, mientras que Este de EE. UU. (Norte de Virginia) continúa con las operaciones normales. Estas pruebas controladas le ayudan a identificar y resolver posibles problemas antes de que afecten a las cargas de trabajo de producción.
Consulte los [Objetivos de acción](https://docs.aws.amazon.com/fis/latest/userguide/action-sequence.html#action-targets) en la *Guía del usuario de AWS FIS* para obtener una lista completa de las acciones de AWS FIS compatibles.
Para obtener información sobre las acciones de Amazon Aurora DSQL disponibles en AWS FIS, consulte la [Referencia sobre las acciones de Aurora DSQL](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html#dsql-actions-reference) en la *Guía del usuario de AWS FIS*.
Para empezar a realizar experimentos de inyección de errores, consulte [Planificación de los experimentos de AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/getting-started-planning.html) en la *Guía del usuario de AWS FIS*.
# Seguridad de infraestructuras en Amazon Aurora DSQL
Como servicio administrado, Amazon Aurora DSQL está protegido por los procedimientos de seguridad de red globales de AWS que se describen en [Prácticas recomendadas para seguridad, identidad y conformidad](https://aws.amazon.com/architecture/security-identity-compliance).
Utilice las llamadas a la API publicadas por AWS para acceder a Aurora DSQL a través de la red. Los clientes deben ser compatibles con Transport Layer Security (TLS) 1.2 o con una versión posterior. Los clientes también deben ser compatibles con conjuntos de cifrado con confidencialidad directa total (PFS) tales como DHE (Ephemeral Diffie-Hellman) o ECDHE (Elliptic Curve Ephemeral Diffie-Hellman). La mayoría de los sistemas modernos como Java 7 y posteriores son compatibles con estos modos.
Además, las solicitudes deben estar firmadas mediante un ID de clave de acceso y una clave de acceso secreta que esté asociada a una entidad principal de IAM. También puedes utilizar [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) para generar credenciales de seguridad temporales para firmar solicitudes.
# Administración y conexión a clústeres de Amazon Aurora DSQL mediante AWS PrivateLink
Con AWS PrivateLink para Amazon Aurora DSQL, puede aprovisionar puntos de conexión de Amazon VPC de la interfaz (puntos de conexión de interfaz) en Amazon Virtual Private Cloud. A estos puntos de conexión se puede acceder directamente desde las aplicaciones que se encuentran en las instalaciones a través de Amazon VPC y Direct Connect, o bien, en una Región de AWS diferente mediante el emparejamiento de Amazon VPC. Al usar AWS PrivateLink y puntos de conexión de interfaz, puede simplificar la conectividad de la red privada desde las aplicaciones a Aurora DSQL.
Las aplicaciones en la Amazon VPC pueden acceder a Aurora DSQL mediante los puntos de conexión de interfaz de Amazon VPC sin necesidad de direcciones IP públicas.
Los puntos de conexión de la interfaz se representan mediante una o más interfaces de red elásticas (ENI) a las que se asignan direcciones IP privadas desde subredes de la Amazon VPC. Las solicitudes a Aurora DSQL a través de puntos de conexión de interfaz permanecen en la red de AWS. Para obtener más información sobre cómo conectar Amazon VPC a la red en las instalaciones, consulte la [Guía del usuario de Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/) y la [Guía del usuario de AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html).
Para obtener información general sobre los puntos de conexión de interfaz, consulte [Acceso a un servicio de AWS mediante un punto de conexión de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) en la [Guía del usuario de AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink).
## Tipos de puntos de conexión de Amazon VPC para Aurora DSQL
Aurora DSQL requiere dos tipos diferentes de puntos de conexión de AWS PrivateLink.
1. *Punto de conexión de administración*: este punto de conexión se utiliza para operaciones de administración, como `get`, `create`, `update`, `delete` y `list` en clústeres de Aurora DSQL. Consulte [Administración de clústeres de Aurora DSQL mediante AWS PrivateLink](#managing-dsql-clusters-using-privatelink).
1. *Punto de conexión*: este punto de conexión se utiliza para conectarse a los clústeres de Aurora DSQL a través de clientes de PostgreSQL. Consulte [Conexión a clústeres de Aurora DSQL mediante AWS PrivateLink](#privatelink-connecting-clusters).
## Consideraciones al utilizar AWS PrivateLink para Aurora DSQL
Las consideraciones de Amazon VPC se aplican a AWS PrivateLink para Aurora DSQL. Para obtener más información, consulte [Acceso a un servicio de AWS con un punto de conexión de VPC de interfaz](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#vpce-interface-limitations) y [Cuotas de AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-limits-endpoints.html) en la Guía de AWS PrivateLink.
## Administración de clústeres de Aurora DSQL mediante AWS PrivateLink
Puede utilizar la AWS Command Line Interface o los kits de desarrollo de software (SDK) de AWS para administrar clústeres de Aurora DSQL a través de puntos de conexión de interfaz de Aurora DSQL.
### Creación de un punto de conexión de VPC de Amazon
Para crear un punto de conexión de interfaz de Amazon VPC, consulte [Creación de un punto de conexión de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint-aws) en la Guía de 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 \
```
Para utilizar el nombre DNS regional predeterminado para las solicitudes de la API de Aurora DSQL, no desactive el DNS privado cuando cree el punto de conexión de interfaz de Aurora DSQL. Cuando el DNS privado esté habilitado, las solicitudes al servicio Aurora DSQL realizadas desde dentro de Amazon VPC se resolverán automáticamente en la dirección IP privada del punto de conexión de VPC de Amazon, en lugar del nombre DNS público. Si el DNS privado está habilitado, las solicitudes de Aurora DSQL realizadas dentro de Amazon VPC se resolverán automáticamente en el punto de conexión de VPC de Amazon.
Si el DNS privado no está habilitado, utilice los parámetros `--region` y `--endpoint-url` con comandos de la AWS CLI para administrar los clústeres de Aurora DSQL a través de los puntos de conexión de interfaz de Aurora DSQL.
### Enumeración de clústeres mediante una URL de punto de conexión
En el siguiente ejemplo, reemplace la Región de AWS `us-east-1` y el nombre DNS del ID de punto de conexión de Amazon VPC `vpce-1a2b3c4d-5e6f.dsql.us-east-1.vpce.amazonaws.com` con información propia.
```
aws dsql --region us-east-1 --endpoint-url https://vpce-1a2b3c4d-5e6f.dsql.us-east-1.vpce.amazonaws.com list-clusters
```
### Operaciones de API
Consulte la [referencia de la API de Aurora DSQL](CHAP_api_reference.md) para obtener documentación sobre la administración de recursos en Aurora DSQL.
### Administración de políticas de punto de conexión
Al probar y configurar detenidamente las políticas de punto de conexión de Amazon VPC, puede ayudar a garantizar que el clúster de Aurora DSQL sea seguro, cumpla las normas y se ajuste a los requisitos específicos de control de acceso y gobernanza de la organización.
**Ejemplo: política de acceso completo a Aurora DSQL**
La siguiente política concede acceso completo a todas las acciones y recursos de Aurora DSQL a través del punto de conexión de Amazon VPC especificado.
```
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": "*"
}
]
}'
```
**Ejemplo: política de acceso restringido a Aurora DSQL**
La siguiente política solo permite estas acciones de Aurora DSQL.
+ `CreateCluster`
+ `GetCluster`
+ `ListClusters`
Se deniegan todas las demás acciones de Aurora DSQL.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": [
"dsql:CreateCluster",
"dsql:GetCluster",
"dsql:ListClusters"
],
"Resource": "*"
}
]
}
```
------
## Conexión a clústeres de Aurora DSQL mediante AWS PrivateLink
Una vez que el punto de conexión de AWS PrivateLink esté configurado y activo, podrá conectarse al clúster de Aurora DSQL mediante un cliente de PostgreSQL. Las instrucciones de conexión que aparecen a continuación describen los pasos para construir el nombre de host adecuado para conectarse a través del punto de conexión de AWS PrivateLink.
### Configuración de un punto de conexión de AWS PrivateLink
******Paso 1: obtención del nombre del servicio del clúster**
Cuando cree un punto de conexión de AWS PrivateLink para conectarse al clúster, primero deberá obtener el nombre de servicio específico del clúster.
------
#### [ AWS CLI ]
```
aws dsql get-vpc-endpoint-service-name \
--region us-east-1 \
--identifier your-cluster-id
```
Respuesta de ejemplo
```
{
"serviceName": "com.amazonaws.us-east-1.dsql-fnh4"
}
```
El nombre del servicio incluye un identificador, como `dsql-fnh4` en el ejemplo. Este identificador también es necesario al construir el nombre de host para conectarse al clúster.
------
#### [ 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);
```
------
**Paso 2: creación del punto de conexión de Amazon VPC**
Mediante el nombre de servicio obtenido en el paso anterior, cree un punto de conexión de Amazon VPC.
**importante**
Las instrucciones de conexión que aparecen a continuación solo funcionan para conectarse a clústeres cuando está habilitado el DNS privado. No utilice la marca `--no-private-dns-enabled` al crear el punto de conexión, ya que esto impedirá que las instrucciones de conexión que figuran a continuación funcionen correctamente. Si desactiva el DNS privado, tendrá que crear un registro DNS privado comodín propio que apunte al punto de conexión creado.
------
#### [ 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
```
**Ejemplo de respuesta**
```
{
"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 ]
Uso de una URL de punto de conexión para las API de Aurora DSQL
```
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);
```
------
**Configuración adicional al conectarse mediante Direct Connect o el emparejamiento de Amazon VPC**
Puede que se requiera una configuración adicional para conectarse a los clústeres de Aurora DSQL mediante un punto de conexión de AWS PrivateLink desde dispositivos en las instalaciones a través del emparejamiento de Amazon VPC o Direct Connect. Esta configuración no es necesaria si su aplicación se ejecuta en la misma instancia de Amazon VPC que su punto de conexión de AWS PrivateLink. Las entradas de DNS privado creadas anteriormente no se resolverán de forma correcta fuera de la instancia de Amazon VPC del punto de conexión, pero puede crear sus propios registros DNS privados que se resuelvan en su punto de conexión de AWS PrivateLink.
Cree un registro DNS de CNAME privado que apunte al nombre de dominio completo del punto de conexión de AWS PrivateLink. El nombre de dominio del registro DNS creado debe construirse a partir de los siguientes componentes:
1. El identificador del servicio a partir del nombre del servicio. Por ejemplo: .: `dsql-fnh4`
1. la Región de AWS,
Cree el registro DNS de CNAME con un nombre de dominio que tenga el siguiente formato: `*.service-identifier.region.on.aws`
El formato del nombre de dominio es importante por dos motivos:
1. El nombre de host utilizado para conectarse a Aurora DSQL debe coincidir con el certificado de servidor de Aurora DSQL cuando se utilice el modo SSL `verify-full`. Esto garantiza el máximo nivel de seguridad de la conexión.
1. Aurora DSQL utiliza la parte del ID de clúster del nombre de host que se utiliza para conectarse a Aurora DSQL a fin de identificar el clúster que se conecta.
Si no es posible crear registros DNS privados, puede seguir conectándose a Aurora DSQL. Consulte [Conexión a un clúster de Aurora DSQL mediante un punto de conexión de AWS PrivateLink sin DNS privado.](#connecting-cluster-id-option).
### Conexión a un clúster de Aurora DSQL mediante un punto de conexión de AWS PrivateLink
Una vez que el punto de conexión de AWS PrivateLink esté configurado y activo (compruebe que `State` es `available`), puede conectarse al clúster de Aurora DSQL mediante un cliente de PostgreSQL. Para obtener instrucciones sobre cómo utilizar los AWS SDK, puede seguir las guías de [Programación con Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/programming-with.html). Debe cambiar el punto de conexión del clúster para que coincida con el formato del nombre de host.
#### Construcción del nombre de host
El nombre de host para conectarse a través de AWS PrivateLink difiere del nombre de host DNS público. Debe construirlo con los siguientes componentes.
1. `Your-cluster-id`
1. El identificador del servicio a partir del nombre del servicio. Por ejemplo: .: `dsql-fnh4`
1. La Región de AWS. Por ejemplo: .: `us-east-1`
Use el siguiente formato: `cluster-id.service-identifier.region.on.aws`
**Ejemplo: conexión mediante 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
```
#### Conexión a un clúster de Aurora DSQL mediante un punto de conexión de AWS PrivateLink sin DNS privado.
Las instrucciones de conexión anteriores se basan en registros DNS privados. Si la aplicación se ejecuta en la misma instancia de Amazon VPC que el punto de conexión de AWS PrivateLink, los registros DNS se crean de forma automática. Como alternativa, si se conecta desde dispositivos en las instalaciones a través del emparejamiento de Amazon VPC o Direct Connect, podrá crear sus propios registros DNS privados. Sin embargo, la configuración de los registros DNS no es siempre posible debido a las restricciones de red impuestas por sus equipos de seguridad. Si la aplicación debe conectarse mediante Direct Connect o desde una instancia de Amazon VPC emparejada, y la configuración de registros DNS no es posible, puede seguir conectándose a Aurora DSQL.
Aurora DSQL utiliza la parte del ID de clúster del nombre de host para identificar el clúster que se conecta, pero si la configuración de registros DNS no es posible, Aurora DSQL permite especificar el clúster de destino mediante la opción de conexión `amzn-cluster-id`. Con esta opción, es posible utilizar el nombre de dominio completo del punto de conexión de AWS PrivateLink como nombre de host al conectarse.
**importante**
Al conectarse con la dirección IP o el nombre de dominio completo del punto de conexión de AWS PrivateLink, no se admite el modo SSL `verify-full`. Por este motivo, se prefiere configurar un DNS privado.
**Ejemplo: Especificación de la opción de conexión de ID de clúster mediante 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
```
### Solución de problemas con AWS PrivateLink
#### Problemas y soluciones comunes
En la siguiente tabla se muestran los problemas y las soluciones más comunes relacionados con AWS PrivateLink con Aurora DSQL.
| Problema | Causa posible | Solución |
| --- | --- | --- |
| Tiempo de espera de conexión | El grupo de seguridad no está configurado correctamente | Utilice Analizador de accesibilidad de Amazon VPC para asegurarse de que la configuración de red permite el tráfico en el puerto 5432. |
| Error de resolución de DNS | DNS privado no habilitado | Compruebe que el punto de conexión de VPC de Amazon se ha creado con el DNS privado habilitado. |
| Error de autenticación | Credenciales incorrectas o token caducado | Genere un nuevo token de autenticación y verifique el nombre de usuario. |
| No se ha encontrado el nombre de servicio | ID de clúster incorrecto | Compruebe el ID del clúster y Región de AWS al obtener el nombre del servicio. |
### Activos relacionados
Para obtener más información, consulte los siguientes recursos:
+ [Guía del usuario de Amazon Aurora DSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-dsql.html)
+ [AWS PrivateLink documentación](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)
+ [Acceso a los servicios de AWS a través de AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-access-aws-services.html)
# Configuración y análisis de vulnerabilidades en Amazon Aurora DSQL
AWS gestiona las tareas de seguridad básicas, como la aplicación de parches en la base de datos y el sistema operativo (SO) de invitado, la configuración del firewall y la recuperación de desastres. Estos procedimientos han sido revisados y certificados por los terceros pertinentes. Para obtener más detalles, consulte los siguientes recursos:
+ [Modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [Amazon Web Services: Información general de procesos de seguridad (documento técnico)](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf)
# Prevención de la sustitución confusa entre servicios
El problema de la sustitución confusa es un problema de seguridad en el que una entidad que no tiene permiso para realizar una acción puede obligar a una entidad con más privilegios a realizar la acción. En AWS, la suplantación entre servicios puede dar lugar al problema de la sustitución confusa. La suplantación entre servicios puede producirse cuando un servicio (el *servicio que lleva a cabo las llamadas*) llama a otro servicio (el *servicio al que se llama*). El servicio que lleva a cabo las llamadas se puedes manipular para utilizar sus permisos a fin de actuar en función de los recursos de otro cliente de una manera en la que no debe tener permiso para acceder. Para evitarlo, AWS proporciona herramientas que lo ayudan a proteger sus datos para todos los servicios con entidades principales de servicio a las que se les ha dado acceso a los recursos de su cuenta.
Se recomienda utilizar las claves de contexto de condición global [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) y [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) en las políticas de recursos para limitar los permisos que Amazon Aurora DSQL concede a otro servicio para el recurso. Utiliza `aws:SourceArn` si desea que solo se asocie un recurso al acceso entre servicios. Utiliza `aws:SourceAccount` si quiere permitir que cualquier recurso de esa cuenta se asocie al uso entre servicios.
La forma más eficaz de protegerse contra el problema de la sustitución confusa es utilizar la clave de contexto de condición global de `aws:SourceArn` con el ARN completo del recurso. Si no conoce el ARN completo del recurso o si está especificando varios recursos, utilice la clave de condición de contexto global `aws:SourceArn` con caracteres comodines (`*`) para las partes desconocidas del ARN. Por ejemplo, `arn:aws:dsql:*:123456789012:*`.
Si el valor de `aws:SourceArn` no contiene el ID de cuenta, como un ARN de bucket de Amazon S3, debe utilizar ambas claves de contexto de condición global para limitar los permisos.
El valor de `aws:SourceArn` debe ser ResourceDescription.
El siguiente ejemplo muestra cómo se pueden utilizar las claves de contexto de condición global `aws:SourceArn` y `aws:SourceAccount` en Aurora DSQL para prevenir el error de la sustitución confusa.
------
#### [ 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"
}
}
}
}
```
------
# Prácticas recomendadas de seguridad para Aurora DSQL
Aurora DSQL proporciona una serie de características de seguridad que debe tener en cuenta a la hora de desarrollar e implementar las políticas de seguridad propias. Las siguientes prácticas recomendadas son directrices generales y no constituyen una solución de seguridad completa. Puesto que es posible que estas prácticas recomendadas no sean adecuadas o suficientes para el entorno, considérelas como consideraciones útiles en lugar de como normas.
**Topics**
+ [Prácticas recomendadas de detección de seguridad para Aurora DSQL](best-practices-security-detective.md)
+ [Prácticas recomendadas de seguridad preventiva para Aurora DSQL](best-practices-security-preventative.md)
# Prácticas recomendadas de detección de seguridad para Aurora DSQL
Además de las siguientes formas de utilizar Aurora DSQL de forma segura, consulte [Seguridad](https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html) en AWS Well-Architected Tool para obtener información sobre cómo las tecnologías en la nube mejoran la seguridad.
**Alarmas de Amazon CloudWatch**
Con las alarmas de Amazon CloudWatch, puede ver una métrica determinada durante el periodo especificado. Si la métrica supera un límite determinado, se envía una notificación a un tema de Amazon SNS o a una política de AWS Auto Scaling. Las alarmas de CloudWatch no invocan acciones simplemente porque se encuentren en determinado estado. En su lugar, el estado debe haber cambiado y debe mantenerse durante el número de periodos especificado.
**Etiquetado de los recursos de Aurora DSQL para la identificación y la automatización**
Puede asignar metadatos a los recursos de AWS en forma de etiquetas. Cada etiqueta es una marca que consta de una clave definida por el cliente y un valor opcional que puede hacer que sea más fácil administrar, buscar y filtrar recursos.
El etiquetado permite implementar controles agrupados. Aunque no hay tipos inherentes de etiquetas, lo habilitan a clasificar los recursos según su finalidad, propietario, entorno u otros criterios. A continuación se muestran algunos ejemplos:
+ Seguridad: se utiliza para determinar requisitos tales como el cifrado.
+ Confidencialidad: un identificador para el nivel concreto de confidencialidad de los datos que admite un recurso.
+ Entorno: utilizado para distinguir entre el desarrollo, la prueba y la infraestructura de producción.
Puede asignar metadatos a los recursos de AWS en forma de etiquetas. Cada etiqueta es una marca que consta de una clave definida por el cliente y un valor opcional que puede hacer que sea más fácil administrar, buscar y filtrar recursos.
El etiquetado permite implementar controles agrupados. Aunque no hay tipos inherentes de etiquetas, le permiten clasificar recursos de según su finalidad, propietario, entorno u otro criterio. A continuación se muestran algunos ejemplos.
+ Seguridad: se utiliza para determinar requisitos tales como el cifrado.
+ Confidencialidad: un identificador para el nivel concreto de confidencialidad de los datos que admite un recurso.
+ Entorno: utilizado para distinguir entre el desarrollo, la prueba y la infraestructura de producción.
Para obtener información, consulte [Prácticas recomendadas para el etiquetado de los recursos de AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html).
# Prácticas recomendadas de seguridad preventiva para Aurora DSQL
Además de las siguientes formas de utilizar Aurora DSQL de forma segura, consulte [Seguridad](https://docs.aws.amazon.com/wellarchitected/latest/framework/security.html) en AWS Well-Architected Tool para obtener información sobre cómo las tecnologías en la nube mejoran la seguridad.
**Use roles de IAM para autenticar el acceso a Aurora DSQL.**
Los usuarios, las aplicaciones y demás Servicios de AWS que accedan a Aurora DSQL deben incluir credenciales de AWS válidas en la API de AWS y en las solicitudes de la AWS CLI. No debe almacenar las credenciales de AWS de forma directa en la aplicación ni en las instancias EC2. Se trata de credenciales a largo plazo que no se rotan automáticamente. Existe un impacto empresarial significativo si estas credenciales se ven comprometidas. Un rol de IAM le permite obtener claves de acceso temporal que puede utilizar para acceder a los recursos y los Servicios de AWS.
Para obtener más información, consulte [Autenticación y autorización para Aurora DSQL](authentication-authorization.md).
**Use políticas de IAM para la autorización de la base de Aurora DSQL.**
Cuando concede permisos, usted decide quién los obtiene, para qué operaciones de la API de Aurora DSQL obtiene permisos y las acciones específicas que desea permitir en esos recursos. La implementación de privilegios mínimos es la clave a la hora de reducir los riesgos de seguridad y el impacto que podrían causar los errores o los intentos malintencionados.
Asocie políticas de permisos a los roles de IAM y conceda permisos para realizar operaciones en los recursos de Aurora DSQL. También están disponibles los [límites de permisos para entidades de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html), que le permiten establecer los permisos máximos que una política basada en identidad puede conceder a una entidad de IAM.
De forma similar a las [prácticas recomendadas para el usuario raíz de la Cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html), no utilice el rol de `admin` en Aurora DSQL para realizar operaciones cotidianas. En su lugar, le recomendamos que cree roles de base de datos personalizados para administrar y conectarse al clúster. Para obtener más información, consulte [Acceso a Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/accessing.html) y [Descripción de la autenticación y autorización para Aurora DSQL](https://docs.aws.amazon.com/aurora-dsql/latest/userguide/accessing.html).
**Use `verify-full` en entornos de producción.**
Esta configuración comprueba que el certificado del servidor esté firmado por una autoridad de certificación de confianza y que el nombre de host del servidor coincida con el certificado.
**Actualización del cliente de PostgreSQL**
Actualice periódicamente el cliente de PostgreSQL a la versión más reciente para beneficiarse de las mejoras de seguridad. Recomendamos utilizar la versión 17 de PostgreSQL.