# Seguridad en Amazon Aurora La seguridad en la nube de AWS es la mayor prioridad. Como cliente de AWS, se beneficiará de una arquitectura de red y un centro de datos que están 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/) la describe como seguridad *de* la nube y seguridad *en* la nube: + **Seguridad de la nube**: AWS es responsable de proteger la infraestructura que ejecuta los servicios de AWS en la nube de AWS. AWS también proporciona servicios que puede utilizar de forma segura. Auditores independientes prueban y verifican periódicamente la eficacia de nuestra seguridad en el marco de los [programas de conformidad de AWS](https://aws.amazon.com/compliance/programs/). Para obtener información acerca de los programas de conformidad que se aplican a Amazon Aurora (Aurora), consulte los [servicios de AWS en el ámbito del programa de conformidad](https://aws.amazon.com/compliance/services-in-scope/). + **Seguridad en la nube**: su responsabilidad viene determinada por el servicio de AWS que utilice. Usted también es responsable de otros factores incluida la confidencialidad de los datos, los requisitos de la empresa y la legislación y los reglamentos aplicables. Esta documentación le ayuda a comprender cómo aplicar el modelo de responsabilidad compartida cuando se utiliza Amazon Aurora. En los siguientes temas, se le mostrará cómo configurar Amazon Aurora para satisfacer los objetivos de seguridad y conformidad. También puede aprender a utilizar otros servicios de AWS que ayuden a supervisar y proteger los recursos de Amazon Aurora. Puede administrar el acceso a los recursos y las bases de datos de Amazon Aurora en un clúster de base de datos. El método que se utiliza para controlar el acceso depende del tipo de tarea que el usuario necesite realizar con Amazon Aurora: + Ejecute el clúster de base de datos en una nube privada virtual (VPC) en función del servicio de Amazon VPC para el posible control de acceso de red más grande. Para obtener más información acerca de la creación de un clúster de base de datos en una VPC, consulte [VPC de Amazon y Amazon Aurora](USER_VPC.md). + Utilice políticas de AWS Identity and Access Management (IAM) para asignar permisos que determinen quién puede administrar los recursos de Amazon Aurora. Por ejemplo, puede utilizar IAM para determinar quién tiene permiso para crear, describir, modificar y eliminar clústeres de bases de datos, etiquetar recursos o modificar grupos de seguridad. Para revisar ejemplos de política de IAM, consulte [Ejemplos de políticas basadas en identidad para Amazon Aurora](security_iam_id-based-policy-examples.md). + Utilice grupos de seguridad para controlar las direcciones IP o instancias de Amazon EC2 que pueden conectarse a las bases de datos de un clúster de bases de datos. Cuando se crea un clúster de bases de datos por primera vez, su firewall impide cualquier acceso a las bases de datos, salvo si se cumplen las reglas especificadas por un grupo de seguridad asociado. + Utilice la capa de conexión segura (SSL) o seguridad de la capa de transporte (TLS) con clústeres de base de datos que ejecuten Aurora MySQL o Aurora PostgreSQL. Para obtener más información acerca del uso de SSL/TLS con un clúster de bases de datos, consulte [Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos](UsingWithRDS.SSL.md). + Utilice el cifrado de Amazon Aurora para proteger los clústeres de base de datos y las instantáneas en reposo. El cifrado de Amazon Aurora utiliza el algoritmo de cifrado AES-256 estándar del sector para cifrar los datos en el servidor que aloja el clúster de bases de datos. Para obtener más información, consulte  [Cifrado de recursos de Amazon Aurora](Overview.Encryption.md) . + Utilice las características de seguridad del motor de base de datos para controlar quién puede iniciar sesión en las bases de datos en un clúster de bases de datos. Estas características funcionas de igual forma que si la base de datos estuviera en su red local. Para obtener información sobre seguridad con Aurora MySQL, consulte [Seguridad con Amazon Aurora MySQL](AuroraMySQL.Security.md). Para obtener información sobre seguridad con Aurora PostgreSQL, consulte [Seguridad con Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md). Aurora forma parte del servicio de base de datos administrada de Amazon Relational Database Service (Amazon RDS). Amazon RDS es un servicio web que facilita la configuración, el funcionamiento y el escalado de una base de datos relacional en la nube. Si no está familiarizado con Amazon RDS, consulte la [https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html). Aurora incluye un subsistema de almacenamiento de alto rendimiento. Sus motores de base de datos compatibles con MySQL y PostgreSQL están personalizados para aprovechar su almacenamiento de rápida distribución. Aurora también automatiza y estandariza la agrupación en clústeres y la reproducción de base de datos, que suelen ser algunos de los aspectos más problemáticos de la configuración y administración de las bases de datos. En Amazon RDS y Aurora, puede acceder mediante programación de la API de RDS y puede utilizar la AWS CLI para acceder de forma interactiva a la API de RDS. Algunas operaciones de la API de RDS y los comandos de AWS CLI se aplican a Amazon RDS y a Aurora, mientras que otros se aplican a Amazon RDS o a Aurora. Para obtener información sobre operaciones de API de RDS, consulte [Referencia de API de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/Welcome.html). Para obtener más información acerca de AWS CLI, consulte la [referencia de AWS Command Line Interface para Amazon RDS](https://docs.aws.amazon.com/cli/latest/reference/rds/index.html). **nota** Solo tiene que configurar la seguridad para sus casos de uso. No tiene que configurar el acceso de seguridad para procesos que Amazon Aurora administra. Entre ellos, se incluye la creación de copias de seguridad, la conmutación por error automática y otros procesos. Para obtener más información acerca de la administración del acceso a los recursos de Amazon Aurora y las bases de datos de un clúster de bases de datos, consulte los siguientes temas. **Topics** + [ # Autenticación de bases de datos con Amazon Aurora ](database-authentication.md) + [ # Administración de contraseñas con Amazon Aurora y AWS Secrets Manager ](rds-secrets-manager.md) + [ # Protección de datos en Amazon RDS ](DataDurability.md) + [ # Administración de la identidad y el acceso en Amazon Aurora ](UsingWithRDS.IAM.md) + [ # Registro y supervisión en Amazon Aurora ](Overview.LoggingAndMonitoring.md) + [ # Validación de la conformidad en Amazon Aurora ](RDS-compliance.md) + [ # Resiliencia en Amazon Aurora ](disaster-recovery-resiliency.md) + [ # Seguridad de la infraestructura en Amazon Aurora ](infrastructure-security.md) + [ # La API de Amazon RDS y los puntos de enlace de la VPC de tipo interfaz (AWS PrivateLink) ](vpc-interface-endpoints.md) + [ # Prácticas recomendadas de seguridad para Amazon Aurora ](CHAP_BestPractices.Security.md) + [ # Control de acceso con grupos de seguridad ](Overview.RDSSecurityGroups.md) + [ # Privilegios de la cuenta de usuario maestro ](UsingWithRDS.MasterAccounts.md) + [ # Uso de roles vinculados a servicios de Amazon Aurora ](UsingWithRDS.IAM.ServiceLinkedRoles.md) + [ # VPC de Amazon y Amazon Aurora ](USER_VPC.md) # Autenticación de bases de datos con Amazon Aurora Amazon Aurora admite varias formas de autenticar usuarios de bases de datos. La autenticación de contraseña está disponible de forma predeterminada para todos los clústeres de base de datos. Para Aurora MySQL y Aurora PostgreSQL, también puede añadir una o ambas autenticaciones de base de datos de IAM y Kerberos para el mismo clúster de base de datos. La autenticación con contraseña, de Kerberos y de base de datos de IAM utilizan diferentes métodos de autenticación en la base de datos. Por lo tanto, un usuario específico puede iniciar sesión en una base de datos mediante un solo método de autenticación. Para PostgreSQL, utilice solo una de las siguientes configuraciones de rol para un usuario de una base de datos específica: + Para utilizar la autenticación de base de datos de IAM, asigne el rol `rds_iam` al usuario. + Para utilizar la autenticación de Kerberos, asigne el rol `rds_ad` al usuario. + Para utilizar la autenticación con contraseña, no asigne ninguno de los roles `rds_iam` o `rds_ad` al usuario. No asigne el rol `rds_iam` ni el rol `rds_ad` a un usuario de una base de datos de PostgreSQL, de forma directa o indirecta, mediante el acceso de concesión anidada. Si el rol `rds_iam` se agrega al usuario maestro, la autenticación de IAM tiene prioridad sobre la autenticación con contraseña, por lo que el usuario maestro tiene que iniciar sesión como usuario de IAM. **importante** Le recomendamos encarecidamente que no utilice el usuario maestro directamente en sus aplicaciones. En lugar de ello, es mejor ceñirse a la práctica recomendada de utilizar un usuario de base de datos creado con los privilegios mínimos necesarios para su aplicación. **Topics** + [ ## Autenticación de contraseña ](#password-authentication) + [ ## Autenticación de bases de datos de IAM ](#iam-database-authentication) + [ ## Autenticación Kerberos ](#kerberos-authentication) ## Autenticación de contraseña Con la *autenticación de contraseña,* la base de datos realiza toda la administración de cuentas de usuario. Puede crear usuarios con instrucciones SQL como `CREATE USER`, con la cláusula adecuada que requiere el motor de base de datos para especificar contraseñas. Por ejemplo, en MySQL la instrucción es `CREATE USER` *nombre* `IDENTIFIED BY` *contraseña*, mientras que, en PostgreSQL, la instrucción es `CREATE USER` *nombre* `WITH PASSWORD` *contraseña*. Con la autenticación por contraseña, la base de datos controla y autentica las cuentas de usuario. Si un motor de base de datos tiene características sólidas de administración de contraseñas, puede mejorar la seguridad. La autenticación de bases de datos puede ser más fácil de administrar mediante la autenticación de contraseña cuando tiene comunidades de usuarios pequeñas. Debido a que en este caso se generan contraseñas de texto sin formato, la integración con AWS Secrets Manager puede mejorar la seguridad. Para obtener información sobre el uso de Secrets Manager con Amazon Aurora, consulte [Creación de un secreto básico](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_create-basic-secret.html) y [Rotación de secretos para bases de datos de Amazon RDS admitidas](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets-rds.html) en la *Guía del usuario de AWS Secrets Manager*. Si quiere obtener información para recuperar los secretos mediante programación en las aplicaciones personalizadas, consulte [Recuperar el valor secreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html) en la *guía del usuario de AWS Secrets Manager*. ## Autenticación de bases de datos de IAM Puede autenticar en el clúster de bases de datos mediante la autenticación de base de datos de AWS Identity and Access Management (IAM). Con este método de autenticación, no es necesario usar una contraseña al conectarse a un clúster de bases de datos. En su lugar, puede usar un token de autenticación. Para obtener más información acerca de la autenticación de bases de datos de IAM, incluida información sobre la disponibilidad de motores de base de datos específicos, consulte [Autenticación de bases de datos de IAM ](UsingWithRDS.IAMDBAuth.md). ## Autenticación Kerberos Amazon Aurora admite la autenticación externa de usuarios de bases de datos que usan Kerberos y Microsoft Active Directory. Kerberos es un protocolo de autenticación de red que usa tickets y criptografía de clave simétrica para eliminar la necesidad de transmitir contraseñas a través de la red. Kerberos ha sido creado en Active Directory y está diseñado para autenticar usuarios para recursos de redes, como bases de datos. La compatibilidad de Amazon Aurora con Kerberos y Active Directory ofrece beneficios de inicio de sesión único y autenticación centralizada de usuarios de bases de datos. Puede mantener sus credenciales de usuario en Active Directory. Active Directory ofrece un lugar centralizado para almacenar y administrar credenciales para varios clústeres de bases de datos. Para usar las credenciales del Active Directory autoadministrado, debe configurar una relación de confianza con Directory Service para el Microsoft Active Directory al que se haya unido el clúster de base de datos. Aurora PostgreSQL y Aurora MySQL admiten relaciones de confianza unidireccionales y bidireccionales entre bosques con autenticación selectiva o en todo el bosque. En algunos casos, puede configurar la autenticación Kerberos a través de una relación de confianza externa. Esto requiere que el directorio de Active Directory autoadministrado tenga una configuración adicional. Esto incluye, entre otras cosas, [Kerberos Forest Search Order](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/kfso-not-work-in-external-trust-event-is-17). Aurora admite la autenticación Kerberos para clústeres de base de datos de Aurora MySQL y Aurora PostgreSQL. Para obtener más información, consulte [Uso de la autenticación Kerberos para Aurora MySQL](aurora-mysql-kerberos.md) y [Uso de la autenticación Kerberos con Aurora PostgreSQL](postgresql-kerberos.md) . # Administración de contraseñas con Amazon Aurora y AWS Secrets Manager Amazon Aurora se integra con Secrets Manager para administrar las contraseñas de usuario maestras de sus . **Topics** + [ ## Disponibilidad en regiones y versiones ](#rds-secrets-manager-availability) + [ ## Limitaciones de la integración de Secrets Manager con Amazon Aurora ](#rds-secrets-manager-limitations) + [ ## Descripción general de la administración de contraseñas de usuarios maestros con AWS Secrets Manager ](#rds-secrets-manager-overview) + [ ## Ventajas de administrar las contraseñas de usuarios maestros con Secrets Manager ](#rds-secrets-manager-benefits) + [ ## Permisos necesarios para la integración de Secrets Manager ](#rds-secrets-manager-permissions) + [ ## Cumplimiento de la administración de la contraseña del usuario maestro por parte de Aurora en AWS Secrets Manager ](#rds-secrets-manager-auth) + [ ## Administración de la contraseña de usuario maestra para un clúster de base de datos con Secrets Manager ](#rds-secrets-manager-db-cluster) + [ ## Rotación del secreto de contraseña de usuario maestra para un clúster de base de datos ](#rds-secrets-manager-rotate-db-cluster) + [ ## Visualización de los detalles de un secreto para un clúster de base de datos ](#rds-secrets-manager-view-db-cluster) ## Disponibilidad en regiones y versiones La disponibilidad y el soporte de las características varía según las versiones específicas de cada motor de base de datos y entre Regiones de AWS. Para obtener más información sobre la disponibilidad de versiones y regiones con la integración de Secrets Manager con Amazon Aurora, consulte [Regiones y motores de bases de datos Aurora admitidos para la integración de Secrets Manager](Concepts.Aurora_Fea_Regions_DB-eng.Feature.SecretsManager.md). ## Limitaciones de la integración de Secrets Manager con Amazon Aurora Las siguientes funciones no admiten la administración de contraseñas de usuario maestro con Secrets Manager: + Implementaciones azules/verdes de Amazon RDS + Clústeres de base de datos que forman parte de una base de datos de Aurora global + Aurora Serverless v1Clústeres de base de datos de + Réplicas de lectura entre regiones + Replicación externa de registros binarios ## Descripción general de la administración de contraseñas de usuarios maestros con AWS Secrets Manager Con AWS Secrets Manager, puede reemplazar las credenciales con codificación rígida (incluidas las contraseñas de bases de datos), con una llamada a la API de Secrets Manager para recuperar el secreto mediante programación. Para obtener más información acerca de Secrets Manager, consulte la [Guía del usuario de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/). Cuando guarda secretos de base de datos en Secrets Manager, su Cuenta de AWS incurre en cargos. Para obtener más información acerca de los precios, consulte [Precios de AWS Secrets Manager](https://aws.amazon.com/secrets-manager/pricing). Puede especificar que Aurora administre la contraseña de usuario principal en Secrets Manager para un clúster de base de datos de Amazon Aurora al realizar una de las siguientes operaciones: + Creación de un clúster de base de datos + Modificación de un clúster de base de datos + Restauración de un clúster de base de datos desde Amazon S3 (solo Aurora MySQL) Al especificar que Aurora administre la contraseña de usuario principal en Secrets Manager, Aurora genera la contraseña y la almacena en Secrets Manager. Puede interactuar directamente con el secreto para recuperar las credenciales del usuario maestro. También puede especificar una clave gestionada por el cliente para cifrar el secreto o utilizar la clave de KMS que proporciona Secrets Manager. Aurora administra la configuración del secreto y, de forma predeterminada, lo rota cada siete días. Puede modificar algunos de los ajustes, como el programa de rotación. Si elimina un clúster de base de datos que administra un secreto en Secrets Manager, también se eliminarán el secreto y los metadatos asociados. Para conectarse a con las credenciales en un secreto, puede recuperar el secreto en Secrets Manager. Para obtener más información, consulte [Recuperar secretos de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html) y [Conexión a una base de datos SQL con credenciales en un secreto de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets_jdbc.html) en la *Guía del usuario de AWS Secrets Manager*. ## Ventajas de administrar las contraseñas de usuarios maestros con Secrets Manager La administración de las contraseñas de usuarios maestros de Aurora con Secrets Manager ofrece las siguientes ventajas: + Aurora genera automáticamente las credenciales de la base de datos. + Aurora almacena y administra automáticamente las credenciales de la base de datos en AWS Secrets Manager. + Aurora rota las credenciales de la base de datos con regularidad, sin necesidad de realizar cambios en la aplicación. + Secrets Manager protege las credenciales de la base de datos del acceso humano y de la visualización en texto plano. + Secrets Manager permite recuperar las credenciales de la base de datos en secretos para las conexiones a bases de datos. + Secrets Manager permite un control detallado del acceso a las credenciales de la base de datos en secretos mediante IAM. + Si lo desea, puede separar el cifrado de bases de datos del cifrado de credenciales con diferentes claves de KMS. + Puede eliminar la administración manual y la rotación de las credenciales de la base de datos. + Puede monitorear fácilmente las credenciales de la base de datos con AWS CloudTrail y Amazon CloudWatch. Para obtener más información acerca de los beneficios de Secrets Manager, consulte la [Guía del usuario de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/). ## Permisos necesarios para la integración de Secrets Manager Los usuarios deben tener los permisos necesarios para realizar las operaciones relacionadas con la integración de Secrets Manager. Puede crear políticas de IAM que concedan permisos para realizar operaciones de la API concretas en los recursos especificados que necesiten. A continuación, puede asociar esas políticas a los roles o conjuntos de permisos de IAM que necesiten esos permisos. Para obtener más información, consulte [Administración de la identidad y el acceso en Amazon Aurora](UsingWithRDS.IAM.md). Para las operaciones de creación, modificación o restauración, el usuario que especifique que Aurora administra la contraseña de usuario maestro en Secrets Manager debe tener permisos para realizar las siguientes operaciones: + `kms:DescribeKey` + `secretsmanager:CreateSecret` + `secretsmanager:TagResource` El permiso `kms:DescribeKey` es necesario para acceder a la clave administrada por el cliente para `MasterUserSecretKmsKeyId` y para describir `aws/secretsmanager`. Para las operaciones de creación, modificación o restauración, el usuario que especifique la contraseña de usuario maestro en Secrets Manager debe tener permisos para realizar las siguientes operaciones: + `kms:Decrypt` + `kms:GenerateDataKey` + `kms:CreateGrant` Para las operaciones de modificación, el usuario que rote la contraseña de usuario maestro en Secrets Manager debe tener permisos para realizar la siguiente operación: + `secretsmanager:RotateSecret` ## Cumplimiento de la administración de la contraseña del usuario maestro por parte de Aurora en AWS Secrets Manager Puede utilizar las claves de condición de IAM para hacer que Aurora administre la contraseña del usuario maestro en AWS Secrets Manager. La siguiente política no permite a los usuarios crear ni restaurar instancias de base de datos o clústeres de bases de datos a menos que Aurora administre la contraseña del usuario principal en Secrets Manager. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": ["rds:CreateDBInstance", "rds:CreateDBCluster", "rds:RestoreDBInstanceFromS3", "rds:RestoreDBClusterFromS3"], "Resource": "*", "Condition": { "Bool": { "rds:ManageMasterUserPassword": false } } } ] } ``` ------ **nota** Esta política aplica la administración de contraseñas en AWS Secrets Manager cuando se crea. Sin embargo, sigue pudiendo deshabilitar la integración de Secrets Manager y establecer manualmente una contraseña maestra si modifica el clúster. Para evitarlo, incluya `rds:ModifyDBInstance`, `rds:ModifyDBCluster` en el bloque de acciones de la política. Tenga en cuenta que esto impide que el usuario aplique más modificaciones a los clústeres existentes que no tengan habilitada la integración de Secrets Manager. Para obtener más información sobre el uso de las claves de condición en las políticas de IAM, consulte [Claves de condición de políticas para Aurora](security_iam_service-with-iam.md#UsingWithRDS.IAM.Conditions) y [Políticas de ejemplo: uso de claves de condición](UsingWithRDS.IAM.Conditions.Examples.md). ## Administración de la contraseña de usuario maestra para un clúster de base de datos con Secrets Manager Puede configurar la administración de Aurora de la contraseña del usuario maestro en Secrets Manager cuando realice las siguientes acciones: + [Creación de un clúster de base de datos de Amazon Aurora](Aurora.CreateInstance.md) + [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md) + [Migración de datos desde una base de datos MySQL externa a un clúster de base de datos de Amazon Aurora MySQL](AuroraMySQL.Migrating.ExtMySQL.md) Puede utilizar la consola de RDS, la AWS CLI o la API de RSD para realizar estas acciones. ### Consola Siga las instrucciones para crear o modificar un clúster de base de datos con la consola de RDS: + [Creación de un clúster de base de datos](Aurora.CreateInstance.md#Aurora.CreateInstance.Creating) + [Modificación de una instancia de base de datos en un clúster de base de datos](Aurora.Modifying.md#Aurora.Modifying.Instance) En la consola de RDS, puede modificar cualquier instancia de base de datos para especificar la configuración de administración de contraseñas del usuario maestro para todo el clúster de base de datos. + [Restauración de un clúster de base de datos de Amazon Aurora MySQL desde un bucket de Amazon S3](AuroraMySQL.Migrating.ExtMySQL.S3.md#AuroraMySQL.Migrating.ExtMySQL.S3.Restore) Al utilizar la consola de RDS para realizar una de estas operaciones, puede especificar que Aurora administre la contraseña del usuario maestro en Secrets Manager. Para hacerlo al crear o restaurar un clúster de base de datos, seleccione **Administrar las credenciales principales en AWS Secrets Manager** en **Configuración de credenciales**. Cuando modifique un clúster de base de datos, seleccione **Administrar las credenciales principales en AWS Secrets Manager** en **Configuración**. La siguiente imagen es un ejemplo de la configuración **Administrar las credenciales principales en AWS Secrets Manager** que se utiliza al crear o restaurar un clúster de base de datos. ![\[Gestión de las credenciales maestras en AWS Secrets Manager\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-credential-settings.png) Al seleccionar esta opción, Aurora genera la contraseña de usuario maestra y la administra durante todo su ciclo de vida en Secrets Manager. ![\[Gestión de las credenciales maestras en la AWS Secrets Manager seleccionada\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-create.png) Puede optar por cifrar el secreto con una clave de KMS que proporcione Secrets Manager o con la clave gestionada por el cliente que cree usted. Una vez que Aurora administre las credenciales de la base de datos de un clúster de base de datos, no podrá cambiar la clave de KMS que se usa para cifrar el secreto. Puede elegir otros ajustes para cumplir con sus requisitos. Para obtener más información sobre la configuración disponible al crear un clúster de base de datos, consulte [Configuración de clústeres de bases de datos de Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings). Para obtener más información sobre la configuración disponible al modificar un clúster de base de datos, consulte [Configuración para Amazon Aurora](Aurora.Modifying.md#Aurora.Modifying.Settings). ### AWS CLI Para administrar la contraseña del usuario maestro con Aurora en Secrets Manager, especifique la opción `--manage-master-user-password` en uno de los siguientes comandos: + [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) + [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) + [restore-db-cluster-from-s3](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-from-s3.html) Al especificar la opción `--manage-master-user-password` en estos comandos, Aurora genera la contraseña de usuario maestro y la administra durante todo su ciclo de vida en Secrets Manager. Para cifrar el secreto, también puede especificar una clave gestionada por el cliente o utilizar la clave de KMS que proporciona Secrets Manager. Use la opción `--master-user-secret-kms-key-id` para especificar una clave administrada por el cliente. El identificador de la clave de AWS KMS es el ARN de la clave, el identificador de clave, el ARN de alias o el nombre de alias de la clave de KMS. Para especificar una clave en una Cuenta de AWS diferente, debe utilizar la clave de ARN o el alias de ARN. Una vez que Aurora administre las credenciales de la base de datos de un clúster de base de datos, no podrá cambiar la clave de KMS que se usa para cifrar el secreto. Puede elegir otros ajustes para cumplir con sus requisitos. Para obtener más información sobre la configuración disponible al crear un clúster de base de datos, consulte [Configuración de clústeres de bases de datos de Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings). Para obtener más información sobre la configuración disponible al modificar un clúster de base de datos, consulte [Configuración para Amazon Aurora](Aurora.Modifying.md#Aurora.Modifying.Settings). En este ejemplo se crea un clúster de base de datos y se especifica que Aurora administre la contraseña en Secrets Manager. El secreto se cifra mediante la clave de KMS que proporciona Secrets Manager. **Example** Para Linux, macOS o Unix: ``` 1. aws rds create-db-cluster \ 2. --db-cluster-identifier sample-cluster \ 3. --engine aurora-mysql \ 4. --engine-version 8.0 \ 5. --master-username admin \ 6. --manage-master-user-password ``` Para Windows: ``` 1. aws rds create-db-cluster ^ 2. --db-cluster-identifier sample-cluster ^ 3. --engine aurora-mysql ^ 4. --engine-version 8.0 ^ 5. --master-username admin ^ 6. --manage-master-user-password ``` ### API de RDS Para especificar que Aurora administre la contraseña del usuario maestro en Secrets Manager, defina el parámetro `ManageMasterUserPassword` en `true` con alguna de las siguientes operaciones: + [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) + [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) + [RestoreDBClusterFromS3](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromS3.html) Al seleccionar el parámetro `ManageMasterUserPassword` en `true` en una de estas operaciones, Aurora genera la contraseña de usuario maestro y la administra durante todo su ciclo de vida en Secrets Manager. Para cifrar el secreto, también puede especificar una clave gestionada por el cliente o utilizar la clave de KMS que proporciona Secrets Manager. Utilice el parámetro `MasterUserSecretKmsKeyId` para especificar una clave administrada por el cliente. El identificador de la clave de AWS KMS es el ARN de la clave, el identificador de clave, el ARN de alias o el nombre de alias de la clave de KMS. Para especificar una clave en una Cuenta de AWS diferente, debe utilizar la clave de ARN o el alias de ARN. Una vez que Aurora administre las credenciales de la base de datos de un clúster de base de datos, no podrá cambiar la clave de KMS que se usa para cifrar el secreto. ## Rotación del secreto de contraseña de usuario maestra para un clúster de base de datos Cuando Aurora rota un secreto de contraseña de usuario maestro, Secrets Manager genera una nueva versión de secreto para el secreto existente. La nueva versión del secreto contiene la nueva contraseña de usuario maestra. Aurora cambia la contraseña de usuario maestro para el clúster de base de datos para que coincida con la contraseña de la nueva versión de secreto. Puede rotar un secreto inmediatamente en lugar de esperar a que se programe una rotación. Para rotar un secreto de contraseña de usuario maestra en Secrets Manager, modifique el clúster de base de datos . Para obtener más información sobre la modificación de un clúster de bases de datos, consulte [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md). Puede cambiar un secreto de contraseña de usuario maestro inmediatamente con la consola de RDS, la AWS CLI de RDS o la API de RDS. La nueva contraseña siempre tiene 28 caracteres y contiene al menos una mayúscula y una minúscula, un número y un signo de puntuación. ### Consola Para rotar un secreto de contraseña de usuario maestro mediante la consola de RDS, modifique el clúster de base de datos y seleccione **Rotate secret immediately** (Rotar el secreto inmediatamente) en **Settings** (Configuración). ![\[Rotación inmediata de un secreto de contraseña de usuario maestro\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-rotate-aurora.png) Siga las instrucciones para modificar un clúster de base de datos con la consola RDS en [Modificación del clúster de base de datos con la consola, CLI y API](Aurora.Modifying.md#Aurora.Modifying.Cluster). Debe elegir **Apply immediately** (Aplicar inmediatamente) en la página de confirmación. ### AWS CLI Para rotar un secreto de contraseña de usuario maestro mediante la AWS CLI, utilice el comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) y especifique la opción `--rotate-master-user-password`. Debe especificar la opción `--apply-immediately` al rotar la contraseña maestra. En este ejemplo, se rota un secreto de contraseña de usuario maestro. **Example** Para Linux, macOS o Unix: ``` 1. aws rds modify-db-cluster \ 2. --db-cluster-identifier mydbcluster \ 3. --rotate-master-user-password \ 4. --apply-immediately ``` Para Windows: ``` 1. aws rds modify-db-cluster ^ 2. --db-cluster-identifier mydbcluster ^ 3. --rotate-master-user-password ^ 4. --apply-immediately ``` ### API de RDS Puede rotar un secreto de contraseña de usuario maestro mediante la operación [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) y estableciendo el parámetro `RotateMasterUserPassword` en `true`. Debe establecer el parámetro `ApplyImmediately` en `true` al rotar la contraseña maestra. ## Visualización de los detalles de un secreto para un clúster de base de datos Puede recuperar sus secretos mediante la consola ([https://console.aws.amazon.com/secretsmanager/](https://console.aws.amazon.com/secretsmanager/)) o la AWS CLI (comando [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) de Secrets Manager). Puede encontrar el nombre de recurso de Amazon (ARN) de un secreto administrado por Aurora en Secrets Manager con la consola de RDS, la AWS CLI de RDS o la API de RDS. ### Consola **Para visualizar los detalles de un secreto administrado por Aurora en Secrets Manager** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En el panel de navegación, elija **Databases** (Bases de datos). 1. Elija el nombre del clúster de base de datos para mostrar sus detalles. 1. Elija la pestaña **Configuración**. En el **Master Credentials ARN** (ARN de credenciales maestras), puede ver el ARN secreto. ![\[Visualización de los detalles de un secreto administrado por Aurora en Secrets Manager\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/secrets-manager-integration-view-cluster.png) Puede seguir el enlace **Manage in Secrets Manager** (Administrar en Secrets Manager) para ver y administrar el secreto en la consola de Secrets Manager. ### AWS CLI Puede utilizar el comando [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) de la AWS CLI de RDS para buscar la siguiente información sobre un secreto administrado por Aurora en Secrets Manager: + `SecretArn`: ARN del secreto + `SecretStatus`: estado del secreto Otros valores de estado posibles son: + `creating`: se está creando el secreto. + `active`: el secreto está disponible para su uso y rotación normales. + `rotating`: se está rotando el secreto. + `impaired`: el secreto se puede usar para acceder a las credenciales de la base de datos, pero no se puede rotar. Un secreto puede tener este estado si, por ejemplo, se cambian los permisos para que RDS ya no pueda acceder al secreto ni a la clave de KMS del secreto. Cuando un secreto tiene este estado, puede corregir la condición que provocó el estado. Si corrige la condición que causó el estado, el estado sigue siendo `impaired` hasta la siguiente rotación. De forma alternativa, puede modificar el clúster de base de datos para desactivar la administración automática de las credenciales de la base de datos y, a continuación, volver a modificar el clúster de base de datos para activar la administración automática de las credenciales de la base de datos. Para modificar un clúster de base de datos, use la opción `--manage-master-user-password` en el comando [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). + `KmsKeyId`: ARN de la clave de KMS que se utiliza para cifrar el secreto. Especifique la opción `--db-cluster-identifier` para mostrar el resultado de un clúster de base de datos específica. En este ejemplo se muestra el resultado de un secreto que utiliza un clúster de base de datos. **Example** ``` 1. aws rds describe-db-clusters --db-cluster-identifier mydbcluster ``` A continuación, se muestra un ejemplo de resultado de un secreto: ``` "MasterUserSecret": { "SecretArn": "arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx", "SecretStatus": "active", "KmsKeyId": "arn:aws:kms:eu-west-1:123456789012:key/0987dcba-09fe-87dc-65ba-ab0987654321" } ``` Cuando tenga el ARN secreto, podrá ver los detalles del secreto con el comando [get-secret-value](https://docs.aws.amazon.com/cli/latest/reference/secretsmanager/get-secret-value.html) de la CLI de Secrets Manager. En este ejemplo se muestran los detalles del secreto del resultado del ejemplo anterior. **Example** Para Linux, macOS o Unix: ``` aws secretsmanager get-secret-value \ --secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx' ``` Para Windows: ``` aws secretsmanager get-secret-value ^ --secret-id 'arn:aws:secretsmanager:eu-west-1:123456789012:secret:rds!cluster-033d7456-2c96-450d-9d48-f5de3025e51c-xmJRDx' ``` ### API de RDS Puede ver el ARN, el estado y la clave de KMS de un secreto administrado por Aurora en Secrets Manager mediante la operación RDS [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) y estableciendo el parámetro `DBClusterIdentifier` en un identificador de clúster de base de datos. En el resultado se incluyen detalles sobre el secreto. Cuando tenga el ARN secreto, podrá ver los detalles del secreto con la operación [GetSecretValue](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html) de Secrets Manager. # Protección de datos en Amazon RDS El [modelo de responsabilidad compartida](https://aws.amazon.com/compliance/shared-responsibility-model/) de AWS se aplica a la protección de datos en Amazon Relational Database Service. Como se describe en este modelo, AWS 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 Servicios de AWS que utiliza. Para obtener más información sobre la privacidad de los datos, consulta 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, consulta la publicación de blog sobre el [Modelo de responsabilidad compartida de AWS y GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) en el * Blog de seguridad de AWS*. Con fines de protección de datos, recomendamos proteger las credenciales de la Cuenta de AWS y configurar cuentas de usuario individuales con AWS IAM Identity Center o AWS Identity and Access Management (IAM). 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 AWS. Se recomienda el uso de 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 de CloudTrail para capturar actividades de AWS, consulta [Working with CloudTrail trails](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) en la *Guía del usuario de AWS CloudTrail*. + Utiliza las soluciones de cifrado de AWS, junto con todos los controles de seguridad predeterminados dentro de los servicios de Servicios de AWS. + Utiliza servicios de seguridad administrados avanzados, como Amazon Macie, que lo ayuden a detectar y proteger los datos confidenciales almacenados en Amazon S3. + Si necesita módulos criptográficos validados FIPS 140-3 al acceder a AWS a través de una interfaz de línea de comandos o una API, utiliza un punto de conexión de FIPS. Para obtener más información sobre los puntos de conexión de FIPS disponibles, consulta [Estándar de procesamiento de la información federal (FIPS) 140-3](https://aws.amazon.com/compliance/fips/). Se recomienda encarecidamente no introducir nunca información confidencial o sensible, como por ejemplo, direcciones de correo electrónico de clientes, en etiquetas o campos de formato libre, tales como el campo **Nombre**. Esto incluye cuando trabaja con Amazon RDS u otros Servicios de AWS mediante la consola, la API, AWS CLI o los SDK de AWS. Cualquier dato que ingrese en etiquetas o campos de texto de formato libre utilizados para nombres se puede 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. **Topics** + [ # Protección de datos mediante cifrado ](Encryption.md) + [ # Privacidad del tráfico entre redes ](inter-network-traffic-privacy.md) # Protección de datos mediante cifrado Amazon Aurora cifra los recursos de base de datos en la capa de almacenamiento. También puede cifrar conexiones a clústeres de base de datos. **Topics** + [ # Cifrado de recursos de Amazon Aurora ](Overview.Encryption.md) + [ # AWS KMS keyAdministración de ](Overview.Encryption.Keys.md) + [ # Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos ](UsingWithRDS.SSL.md) + [ # Rotar certificados SSL/TLS ](UsingWithRDS.SSL-certificate-rotation.md) # Cifrado de recursos de Amazon Aurora Amazon Aurora protege sus datos tanto en reposo como en tránsito, ya sea entre clientes en las instalaciones y Amazon Aurora, o entre Amazon Aurora y otros recursos de AWS. Amazon Aurora cifra todos los datos de usuario en sus clústeres de bases de datos de Amazon Aurora, incluidos los registros, las copias de seguridad automáticas y las instantáneas. Una vez cifrados los datos, Amazon Aurora gestiona la autenticación del acceso y el descifrado de sus datos de forma transparente con un impacto mínimo en el rendimiento. No es necesario modificar las aplicaciones cliente de base de datos para utilizar el cifrado. **nota** Para los clústeres de de base de datos cifradas y no cifradas, los datos en tránsito entre el origen y las réplicas de lectura están cifrados, incluso al replicar entre regiones de AWS. **Topics** + [ ## Información general del cifrado en los recursos de Amazon Aurora ](#Overview.Encryption.Overview) + [ ## Cifrar un clúster de bases de datos de Amazon Aurora ](#Overview.Encryption.Enabling) + [ ## Determinar si el cifrado está activado para un clúster de bases de datos ](#Overview.Encryption.Determining) + [ ## Disponibilidad del cifrado de Amazon Aurora ](#Overview.Encryption.Availability) + [ ## Cifrado en tránsito ](#Overview.Encryption.InTransit) + [ ## Limitaciones de los clústeres de base de datos cifrados de Amazon Aurora ](#Overview.Encryption.Limitations) ## Información general del cifrado en los recursos de Amazon Aurora Los clústeres de bases de datos cifrados de Amazon Aurora proporcionan una capa adicional de protección de datos al proteger los datos del acceso no autorizado al almacenamiento subyacente. Todos los nuevos clústeres de bases de datos creados a partir del 18 de febrero de 2026 en Amazon Aurora se cifran en reposo utilizando el cifrado AES-256 estándar del sector. Este cifrado se realiza automáticamente en segundo plano, protegiendo sus datos sin necesidad de que usted haga nada. Esto también ayuda a reducir la carga y la complejidad operativas que conlleva la protección de información confidencial. Con el cifrado en reposo, puede proteger las aplicaciones sensibles en materia de cumplimiento normativo y críticas para la seguridad frente a amenazas accidentales y maliciosas, al tiempo que cumple los requisitos normativos. Amazon Aurora usa una clave de AWS Key Management Service para cifrar estos recursos. AWS KMS combina hardware y software seguros y altamente disponibles para ofrecer un sistema de administración de claves escalado para la nube. Al crear un nuevo clúster de bases de datos, Amazon Aurora utiliza el cifrado del servidor (SSE) con una [clave propiedad de AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-key) de forma predeterminada. Sin embargo, puede elegir entre tres tipos de cifrado en función de sus necesidades de seguridad y cumplimiento: + **Clave propiedad de AWS (SSE-RDS)**: una clave de cifrado totalmente controlada por AWS que no se puede ver ni administrar, que Aurora utiliza automáticamente como cifrado predeterminado. + **Clave administrada de AWS (AMK)**: esta clave la crea y administra AWS, y se ve en su cuenta pero no se puede personalizar. No hay una cuota mensual, pero se aplicarán cargos por la API de AWS KMS. + **Clave administrada por el cliente (CMK)**: la clave se almacena en su cuenta y usted la crea, es de su propiedad y la administra. Usted controla plenamente la clave KMS (se aplican los cargos de AWS KMS). Las claves administradas de AWS son una opción de cifrado heredada que sigue estando disponible por motivos de compatibilidad con versiones anteriores. Amazon Aurora utiliza claves propiedad de AWS de forma predeterminada para cifrar los datos, lo que proporciona una sólida protección de seguridad sin cargos adicionales ni gastos de administración. Para la mayoría de los casos de uso, recomendamos utilizar la clave predeterminada propiedad de AWS por simplicidad y rentabilidad, o una clave administrada por el cliente (CMK) si necesita tener un control total sobre sus claves de cifrado. Para obtener más información sobre los tipos de claves, consulte [Claves administradas por el cliente y claves administradas por AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-mgmt). **nota** **Importante:** En el caso de las instancias o clústeres de bases de datos de origen creados antes del 18 de febrero de 2026 , en los que no se haya optado por el cifrado, las instantáneas, los clones y las réplicas de Amazon Aurora (instancia de lectura) creadas a partir de esos orígenes permanecerán sin cifrar. Sin embargo, las operaciones de restauración y la replicación lógica fuera del clúster de Amazon Aurora producirán instancias cifradas. Para un clúster de bases de datos cifrado de Amazon Aurora, todas las instancias de base de datos, los registros, las copias de seguridad y las instantáneas están cifrados. Para obtener más información sobre la disponibilidad y las limitaciones del cifrado, consulte [Disponibilidad del cifrado de Amazon Aurora](#Overview.Encryption.Availability) y [Limitaciones de los clústeres de base de datos cifrados de Amazon Aurora](#Overview.Encryption.Limitations). Cuando crea un clúster de base de datos cifrado, puede elegir una clave administrada por el cliente o la Clave administrada de AWS para que Amazon Aurora cifre su clúster de base de datos. Si no especifica el identificador de clave para una clave administrada por el cliente, Amazon Aurora utilizará la clave Clave administrada de AWS para su nuevo clúster de base de datos. Amazon Aurora crea una Clave administrada de AWS para Amazon Aurora para su cuenta de AWS. Su cuenta de AWS tiene una Clave administrada de AWS diferente para Amazon Aurora para cada región de AWS. Para administrar las claves administradas por el cliente que se usan para cifrar y descifrar los recursos de Amazon Aurora, se utiliza [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/). Si utiliza AWS KMS, podrá crear claves administradas por el cliente y definir las políticas que controlan cómo se pueden utilizar las claves administradas por el cliente. AWS KMS es compatible con CloudTrail, lo que permite auditar la utilización de claves de KMS para comprobar que las claves administradas por el cliente se utilizan de forma adecuada. Puede utilizar las claves administradas por el cliente con Amazon Aurora y los servicios de AWS admitidos, como, por ejemplo, Amazon S3, Amazon EBS y Amazon Redshift. Para ver una lista de los servicios integrados con AWS KMS, consulte [Integración con los servicios de AWS](https://aws.amazon.com/kms/features/#AWS_Service_Integration). Algunas consideraciones sobre el uso de las claves de KMS: + Una vez que haya creado una instancia de base de datos cifrada, no podrá cambiar la clave de KMS utilizada por dicha instancia. Asegúrese de determinar los requisitos de su clave de KMS antes de crear la instancia de base de datos cifrada. Si necesita cambiar la clave de cifrado del clúster de base de datos, siga estos pasos: + Cree una instantánea manual de su clúster. + Restaure la instantánea y habilite el cifrado con la clave de KMS que desee durante la operación de restauración. + Si restaura una instantánea sin cifrar y no selecciona ninguna opción de cifrado, el clúster de bases de datos creado se cifrará con el cifrado predeterminado en reposo (clave propiedad de AWS). + No se puede compartir una instantánea que se haya cifrado con la Clave administrada de AWS de la cuenta de AWS que compartió la instantánea. + Cada instancia de base de datos del clúster de bases de datos comparte el mismo almacenamiento cifrado con la misma clave de KMS. **importante** Amazon Aurora puede perder el acceso a la clave KMS para un clúster de base de datos al deshabilitar la clave KMS. En estos casos, el clúster de bases de datos cifrado entra en estado `inaccessible-encryption-credentials-recoverable`. El clúster de base de datos permanece en este estado durante siete días, durante los cuales la instancia se detiene. Es posible que las llamadas a la API realizadas al clúster de base de datos durante este tiempo no se realicen correctamente. Para recuperar el clúster de base de datos, habilite la clave KMS y reinicie este clúster de base de datos. Puede habilitar la clave de KMS desde la Consola de administración de AWS, la AWS CLI o la API de RDS. Reinicie el clúster de base de datos con el comando de la AWS CLI [start-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/start-db-cluster.html) o la Consola de administración de AWS. El estado `inaccessible-encryption-credentials-recoverable` solo se aplica a clústeres de base de datos que pueden detenerse. Este estado recuperable no se aplica a las instancias que no se pueden detener, como los clústeres con réplicas de lectura entre regiones. Para obtener más información, consulte [Limitaciones para la detención e inicio de clústeres de base de datos de Aurora](aurora-cluster-stop-start.md#aurora-cluster-stop-limitations). Si el clúster de bases de datos no se recupera en sitie días, pasa al estado de terminal `inaccessible-encryption-credentials`. En este estado, el clúster de base de datos ya no se puede usar y solo puede restaurarlo desde una copia de seguridad. Le recomendamos encarecidamente que active siempre las copias de seguridad para protegerse contra la pérdida de datos en sus bases de datos. Durante la creación de un clúster de base de datos, Aurora comprueba si la entidad principal que realiza la llamada tiene acceso a la clave KMS y genera una concesión a partir de la clave KMS que utiliza durante toda la vida útil del clúster de base de datos. La revocación del acceso de la entidad principal que realiza la llamada a la clave KMS no afecta a una base de datos en ejecución. Cuando se utilizan claves KMS en situaciones de varias cuentas, como copiar una instantánea a otra cuenta, la clave KMS debe compartirse con la otra cuenta. Si crea un clúster de base de datos a partir de la instantánea sin especificar una clave de KMS diferente, el nuevo clúster utiliza la clave de KMS de la cuenta de origen. La revocación del acceso a la clave después de crear el clúster de base de datos no afecta al clúster. Sin embargo, la desactivación de la clave afecta a todos los clústeres de base de datos cifrados con esa clave. Para evitarlo, especifique una clave diferente durante la operación de copia de la instantánea. Para obtener más información acerca de claves de KMS, consulte [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) en la *Guía para desarrolladores de AWS Key Management Service* y [AWS KMS keyAdministración de](Overview.Encryption.Keys.md). ## Cifrar un clúster de bases de datos de Amazon Aurora Todos los nuevos clústeres de bases de datos creados a partir del 18 de febrero de 2026 están cifrados de forma predeterminada con una clave propiedad de AWS. Para cifrar un nuevo clúster de bases de datos, utilizando Clave administrada de AWS o una clave administrada por el cliente, seleccione la opción en la consola. Para obtener más información acerca de la creación de un clúster de bases de datos, consulte [Creación de un clúster de base de datos de Amazon Aurora](Aurora.CreateInstance.md). Si utiliza el comando [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) de la AWS CLI para crear un clúster de bases de datos cifrado, establezca el parámetro `--storage-encrypted`. Si utiliza la operación [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) de la API, establezca el parámetro `StorageEncrypted` en true. Una vez que se crea un clúster de bases de datos cifrado, no se puede cambiar la clave de KMS que dicho clúster de bases de datos utiliza. Por tanto, no olvide especificar los requisitos de la clave de KMS antes de crear el clúster de bases de datos cifrado. Si utiliza el comando AWS CLI de la `create-db-cluster` para crear un clúster de bases de datos cifrado con una clave administrada por el cliente, establezca el parámetro `--kms-key-id` en cualquier identificador de clave para la clave de KMS. Si utiliza la operación `CreateDBInstance` de la API de Amazon RDS, establezca el parámetro `KmsKeyId` en cualquier identificador de clave para la clave de KMS. Para utilizar una clave administrada por el cliente en una cuenta de AWS diferente, especifique el ARN de la clave o el ARN del alias. ## Determinar si el cifrado está activado para un clúster de bases de datos Puede utilizar Consola de administración de AWS, AWS CLI o la API de RDS para determinar si el cifrado en reposo está activado para un clúster de bases de datos. ### Consola **Para determinar si el cifrado en reposo está activado para un clúster de bases de datos** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En el panel de navegación, elija **Databases** (Bases de datos). 1. Elija el nombre del clúster de bases de datos que desea verificar para ver los detalles. 1. Elija la pestaña **Configuration** y verifique el valor **Cifrado**. ![\[Verificación del cifrado en reposo de un clúster de bases de datos\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/encryption-aurora-instance.png) ### AWS CLI Para determinar si el cifrado en reposo está activado para un clúster de bases de datos mediante AWS CLI, llame al comando [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) con la siguiente opción: + `--db-cluster-identifier`: el nombre del clúster de bases de datos. En el siguiente ejemplo se utiliza una consulta para devolver ya sea `TRUE` o `FALSE` en relación con el cifrado en reposo del clúster de bases de datos `mydb`. **Example** ``` 1. aws rds describe-db-clusters --db-cluster-identifier mydb --query "*[].{StorageEncrypted:StorageEncrypted}" --output text ``` ### API de RDS Para determinar si el cifrado en reposo está activado para un clúster de bases de datos mediante la API de Amazon RDS, llame a la operación [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) con el siguiente parámetro: + `DBClusterIdentifier`: el nombre del clúster de bases de datos. ## Disponibilidad del cifrado de Amazon Aurora Actualmente, el cifrado de Amazon Aurora; están disponibles para todos los motores de bases de datos y tipos de almacenamiento. **nota** El cifrado de Amazon Aurora no está disponible para la clase de instancia de base de datos sdb.t2.micro. ## Cifrado en tránsito **Cifrado en la capa física** Todos los datos que fluyen en las Regiones de AWS a través de la red global de AWS se cifran automáticamente en la capa física antes de salir de las instalaciones seguras de AWS. Todo el tráfico entre las zonas de disponibiliad está cifrado. Las capas adicionales de cifrado, incluidas las que aparecen en esta sección, pueden proporcionar una protección adicional. **Cifrado proporcionado por el emparejamiento de Amazon VPC y el emparejamiento entre regiones de puerta de enlace de tránsito** Todo el tráfico entre regiones que utiliza la interconexión de Amazon VPC y puerta de enlace de tránsito se cifra de forma masiva automáticamente cuando sale de una región. De manera automática, se proporciona una capa adicional de cifrado en la capa física para todo el tráfico antes de dejar las instalaciones seguras de AWS. **Cifrado entre instancias** AWS proporciona conectividad privada y segura entre instancias de bases de datos de todo tipo. Además, en algunos tipos de instancia, se utilizan las capacidades de descarga del hardware Nitro System subyacente para cifrar de manera automática el tráfico en tránsito entre instancias. Este cifrado utiliza algoritmos de encriptación autenticada con datos asociados (AEAD), con cifrado de 256 bits. No hay impacto en el rendimiento de la red. Para admitir este cifrado adicional del tráfico en tránsito entre instancias, se deben cumplir los siguientes requisitos: + Las instancias utilizan los siguientes tipos de instancias: + **De uso general:** M6i, M6id, M6in, M6idn, M7g + **Optimizada para memoria**: R6i, R6id, R6in, R6idn, R7g, X2idn, X2iedn, X2iezn + Las instancias se encuentran en la misma Región de AWS. + Las instancias están en la misma VPC o VPC interconectadas, y el tráfico no pasa a través de un dispositivo o servicio de red virtual, como un equilibrador de carga o una puerta de enlace de tránsito. ## Limitaciones de los clústeres de base de datos cifrados de Amazon Aurora Existen las siguientes limitaciones para los clústeres de Amazon Aurora con cifrado de bases de datos: + No puede desactivar el cifrado en un clúster de bases de datos cifrado. + Si tiene un clúster sin cifrar, todas las instantáneas creadas a partir de ese clúster tampoco estarán cifradas. Para crear una instantánea cifrada a partir de un clúster sin cifrar, debe copiar la instantánea y especificar una clave administrada por el cliente durante la operación de copia. No puede crear una instantánea cifrada a partir de una instantánea sin cifrar sin especificar una clave administrada por el cliente. + No puede crear una instantánea cifrada de una de base de datos sin cifrar. + Una instantánea de una clúster de bases de datos cifrado debe cifrarse utilizando la misma clave de KMS que la clúster de bases de datos. + No puede convertir un clúster de bases de datos cifrado en uno sin cifrar. Sin embargo, sí es posible restaurar una instantánea sin cifrar en un clúster de bases de datos cifrado de Aurora. Para ello, especifique una clave de KMS cuando realice la restauración partiendo de una instantánea sin cifrar. + Si tiene un clúster sin cifrar existente, cualquier réplica de Amazon Aurora (instancia de lectura) creada a partir de ese clúster tampoco estará cifrada. Para crear un clúster cifrado a partir de un clúster sin cifrar, debe restaurar el clúster de base de datos. El clúster restaurado se cifrará de forma predeterminada tras la operación de restauración. + Para copiar una instantánea cifrada de una región de AWS en otra, debe especificar la clave de KMS de la región de AWS de destino. Esto se debe a que las claves de KMS son específicas de la región de AWS en la que se crean. La instantánea de origen permanece cifrada durante todo el proceso de copia. Amazon Aurora utiliza el cifrado de sobre para proteger los datos durante el proceso de copia. Para obtener más información acerca del cifrado de sobre, consulte [ Cifrado de sobre](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) en la *guía para desarrolladores de AWS Key Management Service*. + No se puede descifrar una clúster de bases de datos cifrado. Sin embargo, puede exportar datos de una clúster de bases de datos cifrado e importar datos a una clúster de bases de datos sin cifrar. # AWS KMS keyAdministración de Amazon Aurora se integra automáticamente con [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/) para la administración de claves. Amazon Aurora utiliza el cifrado de sobre. Para obtener más información acerca del cifrado de sobre, consulte [Cifrado de sobre](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping) en la *Guía para desarrolladores de AWS Key Management Service*. Puede utilizar dos tipos de claves de AWS KMS para cifrar clústeres de bases de datos. + Si desea tener un control total sobre una clave de KMS, debe crear una *clave administrada por el cliente*. Para obtener más información acerca de las claves administradas por el cliente, 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*. + *Las Claves administradas por AWS* son las claves de KMS de la cuenta que se crean, administran y utilizan en su nombre por un servicio de AWS integrado con AWS KMS. De forma predeterminada, se utiliza el RDS Clave administrada de AWS (`aws/rds`) para el cifrado. No puede administrar, rotar ni eliminar el RDS Clave administrada de AWS. Para obtener más información acerca de Claves administradas por AWS, consulte [Claves administradas por AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) en la *Guía para desarrolladores de AWS Key Management Service*. Para administrar las claves KMS usadas para clústeres de bases de datos cifradas de Amazon Aurora, use [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/) en la [consola de AWS KMS](https://console.aws.amazon.com/kms), la AWS CLI o la API de AWS KMS. Para ver los registros de auditoría de cada acción realizada con una clave administrada por AWS o por el cliente, utilice [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/). Para obtener más información sobre la rotación de claves, consulte [Rotación de claves de AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html). ## Autorización del uso de una clave administrada por el cliente Cuando Aurora utiliza una clave administrada por el cliente en las operaciones criptográficas, actúa en nombre del usuario que está creando o modificando el recurso de Aurora. Para crear un recurso de Aurora con una clave administrada por el cliente, un usuario debe tener permisos para llamar a las siguientes operaciones en la clave administrada por el cliente: + `kms:CreateGrant` + `kms:DescribeKey` Puede especificar estos permisos necesarios en una política de claves o en una política de IAM si lo permite la política de claves. **importante** Cuando utiliza instrucciones de denegación explícitas para todos los recursos (\$1) en políticas de claves de AWS KMS con servicios administrados como Amazon RDS, debe especificar una condición para permitir que la cuenta propietaria del recurso acceda. Es posible que las operaciones produzcan un error sin esta condición, incluso si la regla de denegación incluye excepciones para el usuario de IAM. **sugerencia** Para seguir el principio de privilegios mínimos, no permita el acceso completo a `kms:CreateGrant`. En su lugar, use la [clave de condición kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) para permitir al usuario crear concesiones en la clave de KMS solo cuando un servicio de AWS haya creado la concesión en nombre del usuario. Puede hacer que la política de IAM sea más estricta de varias maneras. Por ejemplo, si desea permitir que la clave administrada por el cliente se utilice solo para solicitudes que se originen en Aurora, utilice la [clave de condición kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service) con el valor `rds..amazonaws.com`. Además, puede utilizar las claves o valores de [Contexto de cifrado de Amazon RDS](#Overview.Encryption.Keys.encryptioncontext) como condición para utilizar la clave administrada por el cliente para el cifrado. Para obtener más información, consulte [Permitir a los usuarios de otras cuentas utilizar una clave KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html) en la *Guía para desarrolladores de AWS Key Management Service* y [Políticas de claves en AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies). ## Contexto de cifrado de Amazon RDS Cuando Aurora utiliza la clave KMS o cuando Amazon EBS utiliza la clave KMS en nombre de Aurora, el servicio especifica un [contexto de cifrado](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#encrypt_context). El contexto de cifrado es la [información autenticada adicional](https://docs.aws.amazon.com/crypto/latest/userguide/cryptography-concepts.html#term-aad) (ADD) que AWS KMS usa para garantizar la integridad de los datos. Cuando se especifica un contexto de cifrado para una operación de cifrado, el servicio debe especificar el mismo contexto de cifrado para la operación de descifrado. De lo contrario, el descifrado produce un error. El contexto de cifrado también se escribe en los registros de [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) para ayudarle a entender por qué se usó una determinada clave KMS. Sus registros de CloudTrail pueden contener numerosas entradas que describen el uso de una clave KMS, pero el contexto de cifrado de cada entrada de registro puede ayudarle a determinar el motivo de ese uso concreto. Como mínimo, Aurora siempre utiliza el ID de clúster de base de datos para el contexto de cifrado, como en el siguiente ejemplo con formato JSON: ``` { "aws:rds:dbc-id": "cluster-CQYSMDPBRZ7BPMH7Y3RTDG5QY" } ``` Este contexto de cifrado puede ayudarle a identificar el clúster de base de datos para el que se ha utilizado la clave KMS. Cuando la clave de KMS se usa para un clúster de base de datos y un volumen de Amazon EBS específico, el ID de clúster de base de datos y el ID de volumen de Amazon EBS se usan para el contexto de cifrado, como en el siguiente ejemplo con formato JSON: ``` { "aws:rds:dbc-id": "cluster-BRG7VYS3SVIFQW7234EJQOM5RQ", "aws:ebs:id": "vol-ad8c6542" } ``` # Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos Puede utilizar SSL (Capa de conexión segura) o TLS (Transport Layer Security) desde una aplicación para cifrar una conexión a un clúster de bases de datos que ejecuta Aurora MySQL o Aurora PostgreSQL. Las conexiones SSL/TLS proporcionan una capa de seguridad al cifrar los datos que circulan entre el cliente y el clúster de la base de datos. Si lo desea, su conexión SSL/TLS puede realizar una verificación de identidad del servidor validando el certificado del servidor instalado en su base de datos. Para solicitar la verificación de la identidad del servidor, siga este proceso general: 1. Elija la **entidad de certificación (CA)** que firma el **certificado del servidor de base de datos,** para su base de datos. Para obtener más información acerca de las entidades de certificación, consulte [Entidades de certificación](#UsingWithRDS.SSL.RegionCertificateAuthorities). 1. Descargue un paquete de certificados para usarlo cuando se conecte a la base de datos. Para descargar un paquete de certificados, consulte [Agrupaciones de certificados por Región de AWS](#UsingWithRDS.SSL.CertificatesAllRegions). **nota** Todos los certificados están disponibles solo para descarga con conexiones SSL/TLS. 1. Conéctese a la base de datos mediante el proceso del motor de base de datos para la implementación de las conexiones SSL/TLS. Cada motor base de datos tiene su propio proceso para implementar SSL/TLS. Para obtener información sobre cómo implementar SSL/TLS para su base de datos, siga el enlace que corresponda a su motor de base de datos: + [Seguridad con Amazon Aurora MySQL](AuroraMySQL.Security.md) + [Seguridad con Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md) ## Entidades de certificación La **entidad de certificación (CA)** es el certificado que identifica la CA raíz en la parte superior de la cadena de certificados. La CA firma el **certificado del servidor de base de datos**, que está instalado en cada instancia de base de datos. El certificado del servidor de base de datos identifica la instancia de base de datos como un servidor de confianza. ![\[Información general de la entidad de certificación\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority-overview.png) Amazon RDS proporciona las siguientes CA para firmar el certificado del servidor de base de datos de una base de datos. **** | Entidad de certificación (CA) | Descripción | Nombre común (CN) | | --- | --- | --- | | rds-ca-rsa2048-g1 | Utiliza una entidad de certificación con el algoritmo de clave privada RSA 2048 y el algoritmo de firma SHA256 en la mayoría de las Regiones de AWS. En las AWS GovCloud (US) Regions, este certificado utiliza una entidad de certificación con el algoritmo de clave privada RSA 2048 y el algoritmo de firma SHA384. Esta CA admite la rotación automática de certificados de servidor. | Amazon RDS region-identifier Root CA RSA2048 G1 | | rds-ca-rsa4096-g1 | Utiliza una entidad de certificación con el algoritmo de clave privada RSA 4096 y el algoritmo de firma SHA384. Esta CA admite la rotación automática de certificados de servidor. | Amazon RDS region-identifier Root CA RSA4096 G1 | | rds-ca-ecc384-g1 | Utiliza una entidad de certificación con el algoritmo de clave privada ECC 384 y el algoritmo de firma SHA384. Esta CA admite la rotación automática de certificados de servidor. | Amazon RDS region-identifier Root CA ECC384 G1 | **nota** Si utiliza la AWS CLI, puede ver la validez de las entidades de certificación enumeradas anteriormente mediante [describe-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html). Estos certificados CA se incluyen en el paquete de certificados regionales y globales. Al utilizar la CA rds-ca-rsa2048-g1, rds-ca-rsa4096-g1 o rds-ca-ecc384-g1 con una instancia de base de datos, RDS administra el certificado del servidor de base de datos en la base de datos. RDS rota el certificado del servidor de base de datos de forma automática antes de que caduque. ### Configuración de la CA para su base de datos Puede definir la CA para una base de datos con las tareas siguientes: + Crear un clúster de base de datos de Aurora: puede configurar la CA para una instancia de base de datos en un clúster de Aurora al crear la primera instancia de base de datos del clúster de base de datos mediante la AWS CLI o la API de RDS. Actualmente, no puede definir la CA para las instancias de base de datos en un clúster de base de datos al crear el clúster de base de datos mediante la consola de RDS. Para obtener instrucciones, consulte [Creación de un clúster de base de datos de Amazon Aurora](Aurora.CreateInstance.md) . + Modificar una instancia de base de datos: puede configurar la CA de una instancia de base de datos en un clúster de base de datos modificándola. Para obtener instrucciones, consulte [Modificación de una instancia de base de datos en un clúster de base de datos](Aurora.Modifying.md#Aurora.Modifying.Instance) . **nota** La CA predeterminada está establecida en rds-ca-rsa2048-g1. Puede anular la CA predeterminada para su Cuenta de AWS mediante el comando [modify-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html). Las CA disponibles dependen del motor de base de datos y de la versión del motor de base de datos. Al utilizar la Consola de administración de AWS, puede elegir la CA mediante la configuración de la **Entidad de certificación**, tal como se muestra en la siguiente imagen. ![\[Opción Entidad de certificación\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority.png) La consola solo muestra las CA que están disponibles para le motor de base de datos y la versión del motor de base de datos. Si utiliza la AWS CLI, puede configurar la CA para una instancia de base de datos mediante los comandos [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) o [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html). Si utiliza la AWS CLI, puede ver las CA disponibles para su cuenta mediante el comando [describe-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-certificates.html). Este comando también muestra la fecha de caducidad de cada CA en `ValidTill` en la salida. Puede buscar las CA que están disponibles para un motor de base de datos y una versión de motor de base de datos específicos mediante el comando [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html). El siguiente ejemplo muestra las CA disponibles para la versión predeterminada del motor de base de datos de RDS para PostgreSQL. ``` aws rds describe-db-engine-versions --default-only --engine postgres ``` Su resultado es similar al siguiente. Las CA disponibles se enumeran en `SupportedCACertificateIdentifiers`. El resultado también muestra si la versión del motor de base de datos admite la rotación del certificado sin reiniciarlo en `SupportsCertificateRotationWithoutRestart`. ``` { "DBEngineVersions": [ { "Engine": "postgres", "MajorEngineVersion": "13", "EngineVersion": "13.4", "DBParameterGroupFamily": "postgres13", "DBEngineDescription": "PostgreSQL", "DBEngineVersionDescription": "PostgreSQL 13.4-R1", "ValidUpgradeTarget": [], "SupportsLogExportsToCloudwatchLogs": false, "SupportsReadReplica": true, "SupportedFeatureNames": [ "Lambda" ], "Status": "available", "SupportsParallelQuery": false, "SupportsGlobalDatabases": false, "SupportsBabelfish": false, "SupportsCertificateRotationWithoutRestart": true, "SupportedCACertificateIdentifiers": [ "rds-ca-rsa2048-g1", "rds-ca-ecc384-g1", "rds-ca-rsa4096-g1" ] } ] } ``` ### Validez del certificado del servidor de base de datos La validez del certificado del servidor de base de datos depende del motor de base de datos y de la versión del motor de base de datos. Si la versión del motor de base de datos admite la rotación de certificados sin reinicio, el certificado del servidor de base de datos tiene una validez de 1 año. De no ser así, la validez es de 3 años. Para obtener más información acerca de la rotación de certificados del servidor de base de datos, consulte [Rotación automática de certificados del servidor](UsingWithRDS.SSL-certificate-rotation.md#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation). ### Visualización de la CA de su instancia de base de datos Puede ver los detalles sobre la CA de una base de datos en la pestaña **Conectividad y seguridad** de la consola, como se muestra en la siguiente imagen. ![\[Detalles de la entidad de certificación\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/certificate-authority-details.png) Si utiliza la AWS CLI, puede ver los detalles de la CA de una instancia de base de datos mediante el comando [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html). ## Descarga de agrupaciones de certificados para Aurora Cuando se conecta a la base de datos con SSL o TLS, la instancia de base de datos requiere un certificado de confianza de Amazon RDS. Seleccione el enlace correspondiente en la siguiente tabla para descargar la agrupación correspondiente a la Región de AWS donde se aloja la base de datos. ### Agrupaciones de certificados por Región de AWS Los paquetes de certificados para todas las Regiones de AWS y para regiones de GovCloud (EE. UU.) incluyen los siguientes certificados: + `rds-ca-rsa2048-g1` + `rds-ca-rsa4096-g1` + `rds-ca-ecc384-g1` Los certificados `rds-ca-rsa4096-g1` y `rds-ca-ecc384-g1` no están disponibles en las siguientes regiones: + Asia-Pacífico (Mumbai) + Asia-Pacífico (Melbourne) + Oeste de Canadá (Calgary) + Europa (Zúrich) + Europa (España) + Israel (Tel Aviv) El almacén de confianza de la aplicación solo necesita registrar el certificado CA raíz. No registre los certificados CA intermedios en el almacén de confianza, ya que esto podría provocar problemas de conexión cuando RDS rote automáticamente el certificado del servidor de base de datos. **nota** Amazon RDS Proxy y Aurora Serverless v1 usen certificados de AWS Certificate Manager (ACM). Si está utilizando RDS Proxy, no es necesario descargar certificados de Amazon RDS ni actualizar aplicaciones que usen conexiones RDS Proxy. Para obtener más información, consulte  [Uso de TLS/SSL con RDS Proxy](rds-proxy.howitworks.md#rds-proxy-security.tls) . Si usa Aurora Serverless v1, no es necesario descargar certificados de Amazon RDS. Para obtener más información, consulte  [Uso de TLS/SSL con Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls) . Para descargar una agrupación de certificados de una Región de AWS, seleccione el enlace de la Región de AWS en la que se aloja la base de datos en la tabla siguiente. | **AWS Región de** | **Paquete de certificados (PEM)** | **Paquete de certificados (PKCS7)** | | --- | --- | --- | | Cualquier Región de AWS comercial | [global-bundle.pem](https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem) | [global-bundle.p7b](https://truststore.pki.rds.amazonaws.com/global/global-bundle.p7b) | | EE.UU. Este (Norte de Virginia) | [us-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.pem) | [us-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-east-1/us-east-1-bundle.p7b) | | US East (Ohio) | [us-east-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-east-2/us-east-2-bundle.pem) | [us-east-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-east-2/us-east-2-bundle.p7b) | | EE.UU. Oeste (Norte de California) | [us-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-west-1/us-west-1-bundle.pem) | [us-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-west-1/us-west-1-bundle.p7b) | | EE.UU. Oeste (Oregón) | [us-west-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/us-west-2/us-west-2-bundle.pem) | [us-west-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/us-west-2/us-west-2-bundle.p7b) | | Africa (Cape Town) | [af-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/af-south-1/af-south-1-bundle.pem) | [af-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/af-south-1/af-south-1-bundle.p7b) | | Asia Pacific (Hong Kong) | [ap-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-east-1/ap-east-1-bundle.pem) | [ap-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-east-1/ap-east-1-bundle.p7b) | | Asia-Pacífico (Hyderabad) | [ap-south-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-south-2/ap-south-2-bundle.pem) | [ap-south-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-south-2/ap-south-2-bundle.p7b) | | Asia-Pacífico (Yakarta) | [ap-southeast-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-3/ap-southeast-3-bundle.pem) | [ap-southeast-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-3/ap-southeast-3-bundle.p7b) | | Asia-Pacífico (Malasia) | [ap-southeast-5-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-5/ap-southeast-5-bundle.pem) | [ap-southeast-5-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-5/ap-southeast-5-bundle.p7b) | | Asia-Pacífico (Melbourne) | [ap-southeast-4-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-4/ap-southeast-4-bundle.pem) | [ap-southeast-4-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-4/ap-southeast-4-bundle.p7b) | | Asia Pacific (Bombay) | [ap-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-south-1/ap-south-1-bundle.pem) | [ap-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-south-1/ap-south-1-bundle.p7b) | | Asia Pacific (Osaka) | [ap-northeast-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-3/ap-northeast-3-bundle.pem) | [ap-northeast-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-3/ap-northeast-3-bundle.p7b) | | Asia-Pacífico (Tailandia) | [ap-southeast-7-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-7/ap-southeast-7-bundle.pem) | [ap-southeast-7-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-7/ap-southeast-7-bundle.p7b) | | Asia-Pacífico (Tokio) | [ap-northeast-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.pem) | [ap-northeast-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.p7b) | | Asia Pacific (Seoul) | [ap-northeast-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-northeast-2/ap-northeast-2-bundle.pem) | [ap-northeast-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-northeast-2/ap-northeast-2-bundle.p7b) | | Asia Pacífico (Singapur) | [ap-southeast-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-1/ap-southeast-1-bundle.pem) | [ap-southeast-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-1/ap-southeast-1-bundle.p7b) | | Asia Pacífico (Sídney) | [ap-southeast-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/ap-southeast-2/ap-southeast-2-bundle.pem) | [ap-southeast-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ap-southeast-2/ap-southeast-2-bundle.p7b) | | Canada (Central) | [ca-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ca-central-1/ca-central-1-bundle.pem) | [ca-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ca-central-1/ca-central-1-bundle.p7b) | | Oeste de Canadá (Calgary) | [ca-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/ca-west-1/ca-west-1-bundle.pem) | [ca-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/ca-west-1/ca-west-1-bundle.p7b) | | Europa (Fráncfort) | [eu-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-central-1/eu-central-1-bundle.pem) | [eu-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-central-1/eu-central-1-bundle.p7b) | | Europe (Irlanda) | [eu-west-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-1/eu-west-1-bundle.pem) | [eu-west-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-1/eu-west-1-bundle.p7b) | | Europe (Londres) | [eu-west-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-2/eu-west-2-bundle.pem) | [eu-west-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-2/eu-west-2-bundle.p7b) | | Europe (Milan) | [eu-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-south-1/eu-south-1-bundle.pem) | [eu-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-south-1/eu-south-1-bundle.p7b) | | Europe (Paris) | [eu-west-3-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-west-3/eu-west-3-bundle.pem) | [eu-west-3-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-west-3/eu-west-3-bundle.p7b) | | Europa (España) | [eu-south-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-south-2/eu-south-2-bundle.pem) | [eu-south-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-south-2/eu-south-2-bundle.p7b) | | Europa (Estocolmo) | [eu-north-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-north-1/eu-north-1-bundle.pem) | [eu-north-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-north-1/eu-north-1-bundle.p7b) | | Europa (Zúrich) | [eu-central-2-bundle.pem](https://truststore.pki.rds.amazonaws.com/eu-central-2/eu-central-2-bundle.pem) | [eu-central-2-bundle.p7b](https://truststore.pki.rds.amazonaws.com/eu-central-2/eu-central-2-bundle.p7b) | | Israel (Tel Aviv) | [il-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/il-central-1/il-central-1-bundle.pem) | [il-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/il-central-1/il-central-1-bundle.p7b) | | México (centro) | [mx-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/mx-central-1/mx-central-1-bundle.pem) | [mx-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/mx-central-1/mx-central-1-bundle.p7b) | | Medio Oriente (Baréin) | [me-south-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/me-south-1/me-south-1-bundle.pem) | [me-south-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/me-south-1/me-south-1-bundle.p7b) | | Medio Oriente (EAU) | [me-central-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/me-central-1/me-central-1-bundle.pem) | [me-central-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/me-central-1/me-central-1-bundle.p7b) | | América del Sur (São Paulo) | [sa-east-1-bundle.pem](https://truststore.pki.rds.amazonaws.com/sa-east-1/sa-east-1-bundle.pem) | [sa-east-1-bundle.p7b](https://truststore.pki.rds.amazonaws.com/sa-east-1/sa-east-1-bundle.p7b) | | Cualquier AWS GovCloud (US) Region | [global-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/global/global-bundle.pem) | [global-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/global/global-bundle.p7b) | | AWS GovCloud (EE. UU. Este) | [us-gov-east-1-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-east-1/us-gov-east-1-bundle.pem) | [us-gov-east-1-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-east-1/us-gov-east-1-bundle.p7b) | | AWS GovCloud (EE. UU. Oeste) | [us-gov-west-1-bundle.pem](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-west-1/us-gov-west-1-bundle.pem) | [us-gov-west-1-bundle.p7b](https://truststore.pki.us-gov-west-1.rds.amazonaws.com/us-gov-west-1/us-gov-west-1-bundle.p7b) | ### Visualización del contenido de su certificado de CA Para comprobar el contenido del paquete de certificados de la CA, utilice el siguiente comando: ``` keytool -printcert -v -file global-bundle.pem ``` # Rotar certificados SSL/TLS Los certificados rds-ca-2019 de la entidad de certificación de Amazon RDS caducaron en agosto de 2024. Si usa o planea usar la capa de conexión segura (SSL) o la seguridad de la capa de transporte (TLS) con la verificación de certificados para conectarse a las instancias de base de datos de RDS , considere la posibilidad de utilizar uno de los nuevos certificados de entidad de certificación rds-ca-rsa2048-g1, rds-ca-rsa4096-g1 o rds-ca-ecc384-g1. Si actualmente no utiliza SSL/TLS con verificación de certificados, es posible que aún tenga un certificado de CA caducado y que deba actualizarlo con un certificado de CA nuevo si tiene previsto utilizar SSL/TLS con verificación de certificados para conectarse a sus bases de datos de RDS. Amazon RDS proporciona nuevos certificados de entidad de certificación como una práctica recomendada de seguridad de AWS. Para obtener información sobre los nuevos certificados y las regiones de AWS compatibles, consulte [Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos](UsingWithRDS.SSL.md). Para actualizar el certificado de CA de la base de datos, utilice los métodos siguientes: + [Actualización del certificado de entidad de certificación modificando la instancia de base de datos](#UsingWithRDS.SSL-certificate-rotation-updating) + [Actualización del certificado de entidad de certificación mediante la aplicación de mantenimiento](#UsingWithRDS.SSL-certificate-rotation-maintenance-update) Antes de actualizar sus instancias de base de datos para usar el nuevo certificado de CA, asegúrese de actualizar sus clientes o aplicaciones que se conectan a sus bases de datos de RDS. ## Consideraciones sobre la rotación de certificados Tenga en cuenta las siguientes situaciones antes de rotar el certificado: + Amazon RDS Proxy y Aurora Serverless v1 usen certificados de AWS Certificate Manager (ACM). Si utiliza RDS Proxy, al rotar el certificado SSL/TLS, no es necesario que actualice las aplicaciones que utilizan las conexiones de RDS Proxy. Para obtener más información, consulte  [Uso de TLS/SSL con RDS Proxy](rds-proxy.howitworks.md#rds-proxy-security.tls) . + Si usa Aurora Serverless v1, no es necesario descargar certificados de Amazon RDS. Para obtener más información, consulte  [Uso de TLS/SSL con Aurora Serverless v1](aurora-serverless.md#aurora-serverless.tls) . + Si utiliza la versión 1.15 de una aplicación Go con una instancia de base de datos que se haya creado o actualizado con el certificado rds-ca-2019 antes del 28 de julio de 2020, debe actualizar el certificado de nuevo. Actualice el certificado a rds-ca-rsa2048-g1, rds-ca-rsa4096-g1 o rds-ca-ecc384-g1 en función de su motor . Utilice el comando `modify-db-instance` con el nuevo identificador de certificado de CA. Puede buscar las CA que están disponibles para un motor de base de datos y una versión de motor de base de datos específicos mediante el comando `describe-db-engine-versions`. Si creó su base de datos o actualizó su certificado después del 28 de julio de 2020, no se requiere ninguna acción. Para obtener más información, consulte [Go GitHub issue \$139568](https://github.com/golang/go/issues/39568). ## Actualización del certificado de entidad de certificación modificando la instancia de base de datos En el siguiente ejemplo, se actualiza el certificado de la entidad de certificación de *rds-ca-2019* a *rds-ca-rsa2048-g1*. Puede elegir un certificado diferente. Para obtener más información, consulte [Entidades de certificación](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities). Actualice el almacén de confianza de aplicaciones para reducir el tiempo de inactividad asociado a la actualización del certificado de CA. Para obtener más información acerca de los reinicios asociados a la rotación de certificados de la entidad de certificación, consulte [Rotación automática de certificados del servidor](#UsingWithRDS.SSL-certificate-rotation-server-cert-rotation). **Actualización del certificado de entidad de certificación modificando la instancia de base de datos** 1. Descargue el nuevo certificado SSL/TLS como se describe en [Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos](UsingWithRDS.SSL.md). 1. Actualice las aplicaciones para que usen el nuevo certificado SSL/TLS. Los métodos para actualizar aplicaciones para nuevos certificados SSL/TLS dependen de sus aplicaciones específicas. Trabaje con sus desarrolladores de aplicaciones para actualizar los certificados SSL/TLS para sus aplicaciones. Para obtener información sobre la comprobación de conexiones SSL/TLS y la actualización de cada motor de base de datos, consulte los siguientes temas: + [Actualización de aplicaciones para la conexión a los clústeres de base de datos de MySQL de Aurora con los nuevos certificados TLS](ssl-certificate-rotation-aurora-mysql.md) + [Actualización de aplicaciones para la conexión a los clústeres de base de datos de PostgreSQL de Aurora con los nuevos certificados SSL/TLS](ssl-certificate-rotation-aurora-postgresql.md) Para obtener el mismo script que actualice un almacén de confianza para un sistema operativo Linux, consulte [Script de muestra para la importación de certificados en su almacén de confianza](#UsingWithRDS.SSL-certificate-rotation-sample-script). **nota** El paquete de certificados contiene certificados tanto para la CA antigua como para la nueva, por lo que puede actualizar su aplicación de forma segura y mantener la conectividad durante el período de transición. Si utiliza AWS Database Migration Service para migrar una base de datos a un clúster de base de datos, recomendamos utilizar el paquete de certificados para garantizar la conectividad durante la migración. 1. Modifique la instancia de base de datos para cambiar la CA de **rds-ca-2019** a **rds-ca-rsa2048-g1**. Para comprobar si la base de datos requiere un reinicio para actualizar los certificados de CA, utilice el comando [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) y compruebe el indicador `SupportsCertificateRotationWithoutRestart`. **nota** Reinicie su clúster de Babelfish después de modificarlo para actualizar el certificado de CA. **importante** Si tiene problemas de conectividad después de que el certificado caduque, utilice la opción de aplicación inmediata. Seleccione **Apply immediately (Aplicar inmediatamente)** en la consola o especifique la opción `--apply-immediately` con la AWS CLI. De manera predeterminada, esta operación está programada para ejecutarse durante su próximo periodo de mantenimiento. Para establecer una invalidación para la entidad de certificación del clúster que sea diferente de la entidad de certificación de RDS predeterminada, utilice el comando de la CLI [modify-certificates](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-certificates.html). Puede utilizar la Consola de administración de AWS o la AWS CLI para cambiar el certificado de CA de **rds-ca-2019** a **rds-ca-rsa2048-g1** para una instancia de base de datos . ------ #### [ Console ] 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En el panel de navegación, elija **Bases de datos** y, a continuación, elija la instancia de base de datos que desea modificar. 1. Elija **Modificar**. ![\[Modifique la instancia de base de datos .\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-modify-aurora.png) 1. En la sección **Conectividad**, elija **rds-ca-rsa2048-g1**. ![\[Elegir el certificado de CA\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-ca-rsa2048-g1.png) 1. Elija **Continue** y consulte el resumen de las modificaciones. 1. Para aplicar los cambios inmediatamente, elija **Apply immediately**. 1. En la página de confirmación, revise los cambios. Si son correctos, elija **Modificar la instancia de base de datos** para guardar los cambios. **importante** Cuando programe esta operación, asegúrese de haber actualizado de antemano su tienda de confianza del lado del cliente. O bien, elija **Back (Atrás)** para editar los cambios o **Cancel (Cancelar)** para cancelarlos. ------ #### [ AWS CLI ] Para utilizar la AWS CLI para cambiar la CA de **rds-ca-2019** a **rds-ca-rsa2048-g1** para una instancia de base de datos , llame al comando [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) o [modify-db-clúster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html). Especifique el identificador de instancia de base de datos y la opción `--ca-certificate-identifier`. Utilice el parámetro `--apply-immediately` para aplicar la actualización inmediatamente. De manera predeterminada, esta operación está programada para ejecutarse durante su próximo periodo de mantenimiento. **importante** Cuando programe esta operación, asegúrese de haber actualizado de antemano su tienda de confianza del lado del cliente. **Example** En el siguiente ejemplo, se modifica `mydbinstance` al establecer el certificado de CA en `rds-ca-rsa2048-g1`. Para Linux, macOS o:Unix ``` aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --ca-certificate-identifier rds-ca-rsa2048-g1 ``` Para Windows: ``` aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --ca-certificate-identifier rds-ca-rsa2048-g1 ``` Si su instancia requiere reinicio, puede utilizar el comando de la CLI [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html) y especificar la opción `--no-certificate-rotation-restart`. ------ ## Actualización del certificado de entidad de certificación mediante la aplicación de mantenimiento Realice los siguientes pasos para actualizar el certificado de CA aplicando el mantenimiento. ------ #### [ Console ] **Actualización del certificado de CA aplicando el mantenimiento** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En el panel de navegación, elija **Actualización del certificado**. ![\[Opción de panel de navegación de rotación de certificados\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-certupdate.png) Se muestra la página **Bases de datos que requieren actualización de certificados**. ![\[Actualización del certificado de CA para la base de datos\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-update-multiple.png) **nota** Esta página solo muestra las instancias de base de datos de la Región de AWS actual. Si tiene instancias de base de datos en más de una Región de AWS, consulte esta página en cada Región de AWS para ver todas las instancias de base de datos con certificados SSL/TLS antiguos. 1. Elija la instancia de base de datos que desea actualizar. Elija **Programación** para programar la rotación de certificados para la siguiente ventana de mantenimiento. Para aplicar la rotación inmediatamente, elija **Aplicar ahora**. **importante** Si tiene problemas de conectividad después de que el certificado caduque, utilice la opción **Aplicar ahora**. 1. 1. Si elige **Programación**, se le solicitará que confirme la rotación del certificado de CA. Este mensaje también indica el período programado para la actualización. ![\[Confirmar rotación del certificado\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-confirm-schedule.png) 1. Si elige **Aplicar ahora**, se le solicita que confirme la rotación del certificado de CA. ![\[Confirmar rotación del certificado\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/ssl-rotate-cert-confirm-now.png) **importante** Antes de programar la rotación de certificados de CA en la base de datos, actualice las aplicaciones cliente que utilicen SSL/TLS y el certificado de servidor para conectarse. Estas actualizaciones son específicas de su motor de base de datos. Después de actualizar estas aplicaciones cliente, puede confirmar la rotación del certificado de CA. Para continuar, seleccione la casilla de verificación y, a continuación, seleccione **Confirm (Confirmar)**. 1. Repita los pasos 3 y 4 para cada instancia de base de datos que desee actualizar. ------ ## Rotación automática de certificados del servidor Si su CA raíz admite la rotación automática de certificados del servidor, RDS administra automáticamente la rotación del certificado del servidor de base de datos. RDS utiliza la misma CA raíz para esta rotación automática, por lo que no es necesario descargar un nuevo paquete de CA. Consulte [Entidades de certificación](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities). La rotación y la validez del certificado del servidor de base de datos dependen del motor de base de datos: + Si su motor de base de datos admite la rotación sin reinicio, RDS rota automáticamente el certificado del servidor de base de datos sin que usted tenga que realizar ninguna acción. RDS intenta rotar el certificado del servidor de base de datos en el período de mantenimiento que prefiera a la mitad de la vida del certificado del servidor de base de datos. El nuevo certificado del servidor de base de datos es válido durante 12 meses. + Si el motor de base de datos no admite la rotación sin reiniciar, Amazon RDS hace visible una acción de mantenimiento pendiente `server-certificate-rotation` a través de la API Describe-Pending-Maintenance-Actions, al final de la vida útil del certificado o al menos 3 meses antes de que caduque. Puede aplicar la rotación mediante la API apply-pending-maintenance-action. El nuevo certificado del servidor de base de datos es válido durante 36 meses. Utilice el comando [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) e inspeccione el indicador `SupportsCertificateRotationWithoutRestart` para identificar si la versión del motor de base de datos admite la rotación del certificado sin reinicio. Para obtener más información, consulte  [Configuración de la CA para su base de datos](UsingWithRDS.SSL.md#UsingWithRDS.SSL.RegionCertificateAuthorities.Selection) . ## Script de muestra para la importación de certificados en su almacén de confianza A continuación se muestran scripts de shell de ejemplo que importan el paquete de certificados a un almacén de confianza. Cada script de shell de muestra utiliza keytool, que forma parte del kit de desarrollo de Java (JDK). Para obtener información sobre la instalación de JDK, consulte la [Guía de instalación de JDK](https://docs.oracle.com/en/java/javase/17/install/overview-jdk-installation.html). ------ #### [ Linux ] A continuación se muestra un ejemplo de script de intérprete de comandos que importa el paquete de certificados a un almacén de confianza en un sistema operativo Linux. ``` mydir=tmp/certs if [ ! -e "${mydir}" ] then mkdir -p "${mydir}" fi truststore=${mydir}/rds-truststore.jks storepassword=changeit curl -sS "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem"> ${mydir}/global-bundle.pem awk 'split_after == 1 {n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1}{print > "rds-ca-" n+1 ".pem"}' < ${mydir}/global-bundle.pem for CERT in rds-ca-*; do alias=$(openssl x509 -noout -text -in $CERT | perl -ne 'next unless /Subject:/; s/.*(CN=|CN = )//; print') echo "Importing $alias" keytool -import -file ${CERT} -alias "${alias}" -storepass ${storepassword} -keystore ${truststore} -noprompt rm $CERT done rm ${mydir}/global-bundle.pem echo "Trust store content is: " keytool -list -v -keystore "$truststore" -storepass ${storepassword} | grep Alias | cut -d " " -f3- | while read alias do expiry=`keytool -list -v -keystore "$truststore" -storepass ${storepassword} -alias "${alias}" | grep Valid | perl -ne 'if(/until: (.*?)\n/) { print "$1\n"; }'` echo " Certificate ${alias} expires in '$expiry'" done ``` ------ #### [ macOS ] A continuación se muestra un ejemplo de script de intérprete de comandos que importa el paquete de certificados a un almacén de confianza en macOS. ``` mydir=tmp/certs if [ ! -e "${mydir}" ] then mkdir -p "${mydir}" fi truststore=${mydir}/rds-truststore.jks storepassword=changeit curl -sS "https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem"> ${mydir}/global-bundle.pem split -p "-----BEGIN CERTIFICATE-----" ${mydir}/global-bundle.pem rds-ca- for CERT in rds-ca-*; do alias=$(openssl x509 -noout -text -in $CERT | perl -ne 'next unless /Subject:/; s/.*(CN=|CN = )//; print') echo "Importing $alias" keytool -import -file ${CERT} -alias "${alias}" -storepass ${storepassword} -keystore ${truststore} -noprompt rm $CERT done rm ${mydir}/global-bundle.pem echo "Trust store content is: " keytool -list -v -keystore "$truststore" -storepass ${storepassword} | grep Alias | cut -d " " -f3- | while read alias do expiry=`keytool -list -v -keystore "$truststore" -storepass ${storepassword} -alias "${alias}" | grep Valid | perl -ne 'if(/until: (.*?)\n/) { print "$1\n"; }'` echo " Certificate ${alias} expires in '$expiry'" done ``` ------ Para obtener más información sobre los procedimientos recomendados al usar SSL con Amazon RDS, consulte [ Best practices for successful SSL connections to Amazon RDS para Oracle](https://aws.amazon.com/blogs/database/best-practices-for-successful-ssl-connections-to-amazon-rds-for-oracle/). # Privacidad del tráfico entre redes Las conexiones están protegidas entre Amazon Aurora y las aplicaciones en las instalaciones y entre Amazon Aurora y otros recursos de AWS dentro de la misma región de AWS. ## Tráfico entre el servicio y las aplicaciones y clientes locales 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) Accederá a Amazon Aurora 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. 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 de la identidad y el acceso en Amazon Aurora AWS Identity and Access Management (IAM) es un Servicio de AWS que ayuda a los gestionadores a controlar de forma segura el acceso a los recursos de AWS. Los administradores de IAM controlan quién se puede *autenticar* (iniciar sesión) y *autorizar* (tener permisos) para utilizar los recursos de Amazon RDS. IAM es un servicio de Servicio de AWS que se puedes utilizar sin cargo adicional. **Topics** + [ ## Público ](#security_iam_audience) + [ ## Autenticación con identidades ](#security_iam_authentication) + [ ## Administración de acceso mediante políticas ](#security_iam_access-manage) + [ # Cómo funciona Amazon Aurora con IAM ](security_iam_service-with-iam.md) + [ # Ejemplos de políticas basadas en identidad para Amazon Aurora ](security_iam_id-based-policy-examples.md) + [ # AWSPolíticas administradas por para Amazon RDS ](rds-security-iam-awsmanpol.md) + [ # Actualizaciones de Amazon RDS a políticas administradas por AWS ](rds-manpol-updates.md) + [ # Prevención de los problemas del suplente confuso entre servicios ](cross-service-confused-deputy-prevention.md) + [ # Autenticación de bases de datos de IAM ](UsingWithRDS.IAMDBAuth.md) + [ # Solución de problemas de identidades y accesos en Amazon Aurora ](security_iam_troubleshoot.md) ## Público La forma en que utiliza AWS Identity and Access Management (IAM) difiere en función del trabajo que realiza en Amazon Aurora. **Usuario de servicio**: si utiliza el servicio Aurora para realizar su trabajo, su administrador le proporciona las credenciales y los permisos que necesita. A medida que utilice más características de Aurora para realizar su trabajo, es posible que necesite permisos adicionales. Entender cómo se administra el acceso puede ayudarle a solicitar los permisos correctos a su administrador. Si no puede acceder a una característica en Aurora, consulte [Solución de problemas de identidades y accesos en Amazon Aurora](security_iam_troubleshoot.md). **Administrador de servicio**: si está a cargo de los recursos de –Aurora en su empresa, probablemente tenga acceso completo a Aurora. Su trabajo consiste en determinar qué a características y recursos de Aurora deben acceder sus empleados. A continuación, debe enviar solicitudes a su administrador de para cambiar los permisos de los usuarios de su servicio. Revise la información de esta página para conocer los conceptos básicos de IAM. Para obtener más información sobre cómo su empresa puede utilizar IAM con Aurora, consulte [Cómo funciona Amazon Aurora con IAM](security_iam_service-with-iam.md). **Administrador**: si es un administrador de IAM, es posible que quiera conocer información sobre cómo escribir políticas para administrar el acceso a Aurora. Para ver ejemplos de políticas basadas en la identidad de Aurora que puede utilizar en IAM, consulte [Ejemplos de políticas basadas en identidad para Amazon Aurora](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 estar autenticado como Usuario raíz de la cuenta de AWS, un usuario de IAM o asumiendo un rol de IAM. 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 programático, 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 llamada Cuenta de AWS del *usuario raíz* que tiene acceso completo a todos los Servicios de AWS y recursos. Recomendamos encarecidamente 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 identidades web o Directory Service que accede a 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, le recomendamos 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 a largo plazo. Para obtener más información, consulte [Solicitar que los usuarios humanos utilicen la federación con un proveedor de identidades para acceder a AWS mediante 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*. Puede autenticar en si clúster de bases de datos utilizando autenticación de base de datos de IAM. La autenticación de base de datos de IAM funciona con Aurora. Para obtener más información sobre la autenticación en su clúster de bases de datos con IAM, consulte [Autenticación de bases de datos de IAM ](UsingWithRDS.IAMDBAuth.md). ### Roles de IAM Un *[rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* es una identidad de la Cuenta de AWS que dispone de permisos específicos. Es similar a un usuario, pero no está asociado a una persona específica. Puede asumir temporalmente un rol de IAM en la Consola de administración de AWS [cambiando de roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html). Puede asumir un rol llamando a una operación de la AWS CLI o de la API de AWS, o utilizando una URL personalizada. Para más información sobre los métodos para el uso de roles, consulte [Uso de roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use.html) en la *Guía del usuario de IAM*. Los roles de IAM con credenciales temporales son útiles en las siguientes situaciones: + **Permisos de usuario temporales**: un usuario puede asumir un rol de IAM para recibir temporalmente permisos distintos que le permitan realizar una tarea concreta. + **Acceso de usuario federado**: para asignar permisos a una identidad federada, puede crear un rol y definir sus permisos. Cuando se autentica una identidad federada, se asocia la identidad al rol y se le conceden los permisos define el rol. Para obtener información acerca de roles de federación, consulte [Crear un rol para un proveedor de identidad de terceros (federación)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html) en la *Guía de usuario de IAM*. Si utiliza el IAM Identity Center, debe configurar un conjunto de permisos. IAM Identity Center correlaciona el conjunto de permisos con un rol en IAM para controlar a qué pueden acceder las identidades después de autenticarse. Para obtener información acerca de los conjuntos de permisos, consulta [Conjuntos de permisos](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) en la *Guía del usuario de AWS IAM Identity Center*. + **Acceso entre cuentas**: puede utilizar un rol de IAM para permitir que alguien (una entidad principal de confianza) de otra cuenta acceda a los recursos de la cuenta. Los roles son la forma principal de conceder acceso entre cuentas. No obstante, con algunos Servicios de AWS se puede adjuntar una política directamente a un recurso (en lugar de utilizar un rol como representante). Para obtener información acerca de la diferencia entre los roles y las políticas basadas en recursos para el acceso entre cuentas, consulte [Cómo los roles de IAM difieren de las políticas basadas en recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) en la *Guía del usuario de IAM*. + **Acceso entre servicios**: algunos Servicios de AWS utilizan características de otros Servicios de AWS. Por ejemplo, cuando realiza una llamada en un servicio, es común que ese servicio ejecute aplicaciones en Amazon EC2 o almacene objetos en Amazon S3. Es posible que un servicio haga esto usando los permisos de la entidad principal, usando un rol de servicio o usando un rol vinculado al servicio. + **Sesiones de acceso directo**: 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 [Reenviar sesiones de acceso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html). + **Rol de servicio**: un rol de servicio es un [rol de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que adopta 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 [Creación de 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*. + **Rol vinculado a los servicios**: 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. + **Aplicaciones que se ejecutan en Amazon EC2**: puede utilizar un rol de IAM que le permita administrar credenciales temporales para las aplicaciones que se ejecutan en una instancia de EC2 y realizan solicitudes a la AWS CLI o a la API de AWS. Es preferible hacerlo de este modo a almacenar claves de acceso en la instancia de EC2. Para asignar un rol de AWS a una instancia de EC2 y ponerla a disposición de todas las aplicaciones, cree un perfil de instancia adjuntado a la instancia. Un perfil de instancia contiene el rol y permite a los programas que se ejecutan en la instancia de EC2 obtener credenciales temporales. Para obtener más información, consulte [Uso de un rol de IAM para conceder permisos a aplicaciones que se ejecutan en instancias Amazon EC2](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html) en la *Guía del usuario de IAM*. Para obtener información acerca del uso de los roles de IAM, consulte [Cuándo crear un rol de IAM (en vez de un usuario)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose_role) en la *Guía del usuario de IAM*. ## Administración de acceso mediante políticas Para controlar el acceso en AWS, se crean políticas y se adjuntan a identidades de IAM o recursos de AWS. Una política es un objeto de AWS que, cuando se asocia a una identidad o un recurso, define sus permisos. AWS evalúa estas políticas cuando una entidad (usuario raíz, usuario o rol de IAM) realiza una solicitud. Los permisos en las políticas determinan si la solicitud se permite o se deniega. La mayoría de las políticas se almacenan en AWS como documentos JSON. Para obtener más información sobre la estructura y el contenido de los documentos de política JSON, consulte [Información general de políticas JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) en la *Guía del usuario de IAM*. Un administrador puede utilizar las políticas para especificar quién tiene acceso a los recursos de AWS y qué acciones se pueden realizar en dichos recursos. Cada entidad de IAM (conjunto de permisos o rol) comienza sin permisos. En otras palabras, de forma predeterminada, los usuarios no pueden hacer nada, ni siquiera cambiar sus propias contraseñas. Para conceder permiso a un usuario para hacer algo, el administrador debe adjuntarle una política de permisos. O bien el administrador puede agregar al usuario a un grupo que tenga los permisos necesarios. Cuando el administrador concede permisos a un grupo, todos los usuarios de ese grupo obtienen los permisos. Las políticas de IAM definen permisos para una acción independientemente del método que se utilice para realizar la operación. Por ejemplo, suponga que dispone de una política que permite la acción `iam:GetRole`. Un usuario con dicha política puede obtener información del usuario de la Consola de administración de AWS, la AWS CLI o la API de AWS. ### Políticas basadas en identidades Las políticas basadas en identidad son documentos de políticas de permisos JSON que puede asociar a una identidad, como por ejemplo, un conjunto de permisos o un rol. Estas políticas controlan qué acciones puede realizar dicha identidad, en qué recursos y en qué condiciones. Para obtener más información sobre cómo crear una política basada en identidades, consulte [Creación de políticas de IAM](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 identidades pueden clasificarse además como *políticas insertadas* o *políticas administradas*. Las políticas insertadas se integran directamente en un único conjunto de permisos o un rol. Las políticas administradas son políticas independientes que puede asociar a varios conjuntos de permisos o roles de su cuenta de AWS. Las políticas administradas incluyen las políticas administradas por AWS y las políticas administradas por el cliente. Para más información sobre cómo elegir una política administrada o una política insertada, consulte [Elegir entre políticas administradas y políticas insertadas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#choosing-managed-or-inline) en la *Guía del usuario de IAM*. Para obtener información sobre las políticas administradas de AWS que son específicas de Amazon Aurora, consulte [AWSPolíticas administradas por para Amazon RDS](rds-security-iam-awsmanpol.md). ### Otros tipos de políticas AWS admite otros tipos de políticas adicionales menos frecuentes. Estos tipos de políticas pueden establecer el máximo de permisos que los tipos de políticas más frecuentes le conceden. + **Límites de permisos**: un límite de permisos es una característica avanzada que le permite establecer los permisos máximos que una política basada en identidad puede conceder a una entidad (conjunto de permisos o rol). Puede establecer un límite de permisos para una identidad. Los permisos resultantes son la intersección de las políticas basadas en identidad de la entidad y los límites de sus permisos. Las políticas basadas en recursos que especifiquen el conjunto de permisos o rol en el campo `Principal` no están restringidos por el límite de permisos. Una denegación explícita en cualquiera de estas políticas anulará el permiso. Para obtener más información sobre los límites de los permisos, 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 servicio (SCP)**: las SCP son políticas de JSON que especifican los permisos máximos de una organización o una unidad organizativa (OU) en AWS Organizations. AWS Organizations es un servicio que le permite agrupar y administrar de manera centralizada varias cuentas de AWS que posea su empresa. Si habilita todas las características en una empresa, entonces podrá aplicar políticas de control de servicio (SCP) a una o todas sus cuentas. Una SCP limita los permisos para las entidades de las cuentas de miembros, incluido cada Usuario raíz de la cuenta de AWS. Para obtener más información acerca de Organizations y las SCP, consulte [Funcionamiento de las SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_about-scps.html) en la *Guía del usuario de AWS Organizations*. + **Políticas de sesión**: las políticas de sesión son políticas avanzadas que se pasan como parámetro cuando se crea una sesión temporal mediante programación para un rol o un usuario federado. Los permisos de la sesión resultantes son la intersección de las políticas basadas en identidad del conjunto de permisos o rol y las políticas de la sesión. Los permisos también pueden proceder de una política en función de recursos. Una denegación explícita en cualquiera de estas políticas anulará el permiso. Para 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 con IAM Antes de utilizar IAM para administrar el acceso a Amazon Aurora, debe saber qué características de IAM están disponibles para usar con Aurora. En la siguiente tabla, encontrará las características de IAM que puede usar con Amazon Aurora: | Característica de IAM | Compatibilidad de Amazon Aurora | | --- | --- | | [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) | No | | [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 (específicas del servicio)](#UsingWithRDS.IAM.Conditions) | Sí | | [ACL](#security_iam_service-with-iam-acls) | No | | [Control de acceso basado en atributos (ABAC) (etiquetas en políticas)](#security_iam_service-with-iam-tags) | Sí | | [Credenciales temporales](#security_iam_service-with-iam-roles-tempcreds) | Sí | | [Sesiones de acceso directo](#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 una perspectiva general de cómo funciona Amazon Aurora y otros servicios de AWS con IAM, consulte los [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*. **Topics** + [ ## Políticas de Aurora basadas en identidades ](#security_iam_service-with-iam-id-based-policies) + [ ## Políticas basadas en recursos de Aurora ](#security_iam_service-with-iam-resource-based-policies) + [ ## Acciones de política de Aurora ](#security_iam_service-with-iam-id-based-policies-actions) + [ ## Recursos de políticas de Aurora ](#security_iam_service-with-iam-id-based-policies-resources) + [ ## Claves de condición de políticas para Aurora ](#UsingWithRDS.IAM.Conditions) + [ ## Listas de control de acceso (ACL) de Aurora ](#security_iam_service-with-iam-acls) + [ ## Control de acceso basado en atributos (ABAC) en políticas con etiquetas de Aurora ](#security_iam_service-with-iam-tags) + [ ## Uso de credenciales temporales con Aurora ](#security_iam_service-with-iam-roles-tempcreds) + [ ## Sesiones de acceso directo para Aurora ](#security_iam_service-with-iam-principal-permissions) + [ ## Roles de servicio para Aurora ](#security_iam_service-with-iam-roles-service) + [ ## Roles vinculados a servicios para Aurora ](#security_iam_service-with-iam-roles-service-linked) ## Políticas de Aurora basadas en identidades **Admite 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 de Aurora basadas en identidades Para ver ejemplos de políticas basadas en identidad de Aurora, consulte [Ejemplos de políticas basadas en identidad para Amazon Aurora](security_iam_id-based-policy-examples.md). ## Políticas basadas en recursos de Aurora **Admite políticas basadas en recursos:** no. 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. Para habilitar el acceso entre cuentas, puede especificar toda una cuenta o entidades de IAM de otra cuenta como la entidad principal de una política en función de recursos. 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*. ## Acciones de política de Aurora **Admite las acciones de política:** 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. Las acciones de políticas de Aurora utilizan el siguiente prefijo antes de la acción: `rds:`. Por ejemplo, para conceder a alguien permiso para eliminar un punto de enlace de Amazon RDS con la operación de la API `DescribeDBInstances` de `rds:DescribeDBInstances`, incluya la acción en su política. Las instrucciones de la política deben incluir un elemento `Action` o un elemento `NotAction`. Aurora define su propio conjunto de acciones que describen las tareas que se pueden realizar con este servicio. Para especificar varias acciones de  en una única instrucción, sepárelas con comas del siguiente modo. ``` "Action": [ "rds:action1", "rds:action2" ``` Puede utilizar caracteres comodín (\$1) para especificar varias acciones . Por ejemplo, para especificar todas las acciones que comiencen con la palabra `Describe`, incluya la siguiente acción. ``` "Action": "rds:Describe*" ``` Para ver una lista de las acciones de Aurora, consulte [Acciones definidas por Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) en la *referencia de autorizaciones de servicio*. ## Recursos de políticas de Aurora **Admite 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": "*" ``` El recurso de instancia de base de datos tiene el siguiente nombre de recurso de Amazon (ARN). ``` arn:${Partition}:rds:${Region}:${Account}:{ResourceType}/${Resource} ``` Para obtener más información acerca del formato de los ARN, consulte [Nombres de recursos de Amazon (ARN) y espacios de nombres de servicios de AWS](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). Por ejemplo, para especificar la instancia de base de datos `dbtest` en su instrucción, utilice el siguiente ARN. ``` "Resource": "arn:aws:rds:us-west-2:123456789012:db:dbtest" ``` Para especificar todas las instancias de base de datos que pertenecen a una cuenta específica, utilice el carácter comodín (\$1). ``` "Resource": "arn:aws:rds:us-east-1:123456789012:db:*" ``` Algunas operaciones de API de RDS, como las empleadas para la creación de recursos, no se pueden llevar a cabo en un recurso específico. En dichos casos, utilice el carácter comodín (\$1). ``` "Resource": "*" ``` En muchas operaciones de la API de Amazon RDS se utilizan varios recursos. Por ejemplo, `CreateDBInstance` crea una instancia de base de datos. Puede especificar que un usuario de debe usar un grupo de seguridad y un grupo de parámetros específicos al crear una instancia de base de datos. Para especificar varios recursos en una única instrucción, separe los ARN con comas. ``` "Resource": [ "resource1", "resource2" ``` Para ver una lista de las acciones de Aurora, consulte [Recursos definidos por Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-resources-for-iam-policies) en la *referencia de autorizaciones de servicio*. Para obtener información sobre las acciones con las que puede especificar el ARN de cada recurso, consulte [Acciones definidas por Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions). ## Claves de condición de políticas para Aurora **Admite 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*. Aurora define su propio conjunto de claves de condición y también admite el uso de algunas claves de condición globales. 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*. Todas las operaciones de API de RDS admiten la clave de condición `aws:RequestedRegion`. Para ver una lista de las claves de condición de Aurora, consulte [Claves de condición de Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-policy-keys) en la *referencia de autorizaciones de servicio*. Para obtener más información acerca de las acciones y los recursos con los que puede utilizar una clave de condición, consulte [Acciones definidas por Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions). ## Listas de control de acceso (ACL) de Aurora **Admite las listas de control de acceso (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. ## Control de acceso basado en atributos (ABAC) en políticas con etiquetas de Aurora **Admite las etiquetas de control de acceso basado en atributos (ABAC) 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*. Para obtener más información acerca del etiquetado de recursos de Aurora, consulte [Especificación de condiciones: uso de etiquetas personalizadas](UsingWithRDS.IAM.SpecifyingCustomTags.md). Para consultar un ejemplo de política basada en la identidad para limitar el acceso a un recurso en función de las etiquetas de ese recurso, consulte [Conceda permiso para acciones en un recurso con una etiqueta específica con dos valores diferentes.](security_iam_id-based-policy-examples-create-and-modify-examples.md#security_iam_id-based-policy-examples-grant-permissions-tags). ## Uso de credenciales temporales con Aurora **Admite 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*. ## Sesiones de acceso directo para Aurora **Admite sesiones de acceso directo:** 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 **Admite 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 de un rol de servicio podría interrumpir la funcionalidad de Aurora. Edite los roles de servicio solo cuando Aurora proporcione orientación para hacerlo. ## Roles vinculados a servicios para Aurora **Admite 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 más información acerca de cómo usar los roles vinculados a servicios de Aurora, consulte [Uso de roles vinculados a servicios de Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md). # Ejemplos de políticas basadas en identidad para Amazon Aurora De forma predeterminada, los conjuntos de permisos y roles no tienen permiso para crear ni modificar recursos de Aurora. Tampoco pueden realizar tareas mediante la Consola de administración de AWS, la AWS CLI o la API de AWS. Un administrador debe crear políticas de IAM que concedan conjuntos de permisos y permisos de roles para realizar operaciones de API concretas en los recursos especificados necesarios. El administrador debe asociar esas políticas a los conjuntos de permisos o roles que necesiten esos permisos. Para obtener más información acerca de cómo crear una política basada en identidad de IAM con estos documentos de políticas de JSON de ejemplo, consulte [Creación de políticas en la pestaña JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) en la *Guía del usuario de IAM*. **Topics** + [ ## Prácticas recomendadas relativas a políticas ](#security_iam_service-with-iam-policy-best-practices) + [ ## Mediante la consola de Aurora ](#security_iam_id-based-policy-examples-console) + [ ## Permisos necesarios para usar la consola ](#UsingWithRDS.IAM.RequiredPermissions.Console) + [ ## Cómo permitir a los usuarios consultar sus propios permisos ](#security_iam_id-based-policy-examples-view-own-permissions) + [ # Políticas de permisos para crear, modificar y eliminar recursos en Aurora ](security_iam_id-based-policy-examples-create-and-modify-examples.md) + [ # Políticas de ejemplo: uso de claves de condición ](UsingWithRDS.IAM.Conditions.Examples.md) + [ # Especificación de condiciones: uso de etiquetas personalizadas ](UsingWithRDS.IAM.SpecifyingCustomTags.md) + [ # Concesión de permisos para etiquetar recursos de Aurora durante la creación ](security_iam_id-based-policy-examples-grant-permissions-tags-on-create.md) ## Prácticas recomendadas relativas a políticas Las políticas basadas en identidades determinan si alguien puede crear, eliminar o acceder a los recursos de Amazon RDS de su cuenta. 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*. ## Mediante la consola de Aurora Para acceder a la consola de Amazon Aurora, debe tener un conjunto mínimo de permisos. Estos permisos deben permitirle enumerar y consultar los detalles sobre los recursos de Amazon Aurora en su cuenta de 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, permite acceso únicamente a las acciones que coincidan con la operación de API que intenta realizar. Para asegurarse de que esas entidades puedan seguir usando la consola de Aurora, asocie también la siguiente política administrada por AWS a las entidades. ``` AmazonRDSReadOnlyAccess ``` 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*: ## Permisos necesarios para usar la consola Para que un usuario pueda trabajar con la consola, debe tener un conjunto mínimo de permisos. Estos permisos permiten al usuario describir los recursos de Amazon Aurora de su cuenta de AWS y proporcionar otra información relacionada, incluida información de red y seguridad de Amazon EC2. Si crea una política de IAM que sea más restrictiva que el mínimo de permisos necesarios, la consola no funciona del modo esperado para los usuarios con esa política de IAM. Para asegurarse de que esos usuarios puedan seguir usando la consola, asocie también la política administrada `AmazonRDSReadOnlyAccess` al usuario, según se explica en [Administración de acceso mediante políticas](UsingWithRDS.IAM.md#security_iam_access-manage). No es necesario que conceda permisos mínimos para la consola a los usuarios que solo realizan llamadas a la AWS CLI o a la API de Amazon RDS. La siguiente política concede acceso completo a todos los recursos de Amazon Aurora para la cuenta de AWS raíz: ``` AmazonRDSFullAccess ``` ## 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": "*" } ] } ``` # Políticas de permisos para crear, modificar y eliminar recursos en Aurora En las siguientes secciones, encontrará ejemplos de políticas de permisos para otorgar y limitar el acceso a los recursos: ## Permitir a un usuario crear en instancias de base de datos en una cuenta de AWS A continuación, se muestra el ejemplo de una política que permite que la cuenta con el ID `123456789012` pueda crear instancias de base de datos para su cuenta AWS. La política requiere que el nombre de la nueva instancia de base de datos comience por `test`. La nueva instancia de base de datos también debe utilizar el motor de base de datos MySQL y la clase de instancia de base de datos `db.t2.micro`. Además, la nueva instancia de base de datos debe usar un grupo de opciones y un grupo de parámetros de base de datos que comience por `default` y debe utilizar el grupo de subred `default`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowCreateDBInstanceOnly", "Effect": "Allow", "Action": [ "rds:CreateDBInstance" ], "Resource": [ "arn:aws:rds:*:123456789012:db:test*", "arn:aws:rds:*:123456789012:og:default*", "arn:aws:rds:*:123456789012:pg:default*", "arn:aws:rds:*:123456789012:subgrp:default" ], "Condition": { "StringEquals": { "rds:DatabaseEngine": "mysql", "rds:DatabaseClass": "db.t2.micro" } } } ] } ``` ------ En la política se incluye una sola instrucción que especifica los siguientes permisos para el usuario de: + La política permite a la cuenta crear una instancia de base de datos utilizando la operación [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) de la API (esto también se aplica al comando [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html) de la AWS CLI y a la Consola de administración de AWS). + El elemento `Resource` especifica que el usuario puede realizar acciones en o con recursos. Puede especificar los recursos mediante un nombre de recurso de Amazon (ARN). Este ARN incluye el nombre del servicio al que pertenece el recurso (`rds`), la región AWS (`*` indica cualquier región de este ejemplo), el número de cuenta de AWS (`123456789012` es el número de cuenta en este ejemplo) y el tipo de recurso. Para obtener más información acerca de la creación de nombres ARN, consulte [Nombres de recursos de Amazon (ARN) en Amazon RDS](USER_Tagging.ARN.md). El elemento `Resource` del ejemplo especifica las siguientes restricciones políticas en los recursos del usuario: + El identificador de instancias de bases de datos para la nueva instancia de base de datos debe comenzar por `test` (por ejemplo, `testCustomerData1`, `test-region2-data`). + El grupo de opciones de la nueva instancia de base de datos debe empezar por `default`. + El grupo de parámetros de base de datos de la nueva instancia de base de datos debe empezar por `default`. + El grupo de subred de la nueva instancia de base de datos debe ser el grupo de subred `default`. + El elemento `Condition` especifica que el motor de base de datos debe ser MySQL, mientras que la clase de instancia de base de datos debe ser `db.t2.micro`. El elemento `Condition` especifica las condiciones en las que se debe aplicar una política. Puede añadir permisos o restricciones adicionales mediante el elemento `Condition`. Para obtener más información acerca de cómo especificar condiciones, consulte [Claves de condición de políticas para Aurora](security_iam_service-with-iam.md#UsingWithRDS.IAM.Conditions). Este ejemplo especifica el estado del `rds:DatabaseEngine` y la `rds:DatabaseClass`. Para obtener más información acerca de los valores de estado válidos para `rds:DatabaseEngine`, consulte la lista bajo el parámetro `Engine` en [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html). Para obtener información acerca de los valores de estado válidos para `rds:DatabaseClass`, consulte [Motores de base de datos compatibles para clases de instancia de base de datos](Concepts.DBInstanceClass.SupportAurora.md). La política no especifica el elemento `Principal`, ya que en una política basada en la identidad no se especifica el elemento principal que obtiene el permiso. Al asociar una política a un usuario, el usuario es la entidad principal implícita. Cuando se asocia una política de permisos a un rol de IAM, la entidad principal identificada en la política de confianza del rol obtiene los permisos. Para ver una lista de las acciones de Aurora, consulte [Acciones definidas por Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) en la *referencia de autorizaciones de servicio*. ## Permitir que un usuario realice cualquier acción Describe con cualquier recurso de RDS La siguiente política de permisos concede permisos a un usuario para ejecutar todas las acciones que empiezan por `Describe`. Estas acciones muestran información acerca de un recurso de RDS, como una instancia de base de datos. El carácter de comodín (\$1) en el elemento `Resource` indica que las acciones están permitidas para todos los recursos de Amazon Aurora que pertenecen a la cuenta. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowRDSDescribe", "Effect": "Allow", "Action": "rds:Describe*", "Resource": "*" } ] } ``` ------ ## Permitirle al usuario crear una instancia de base de datos que use los grupos de parámetros de base de datos y de subredes especificados La política de permisos siguiente otorga permisos para permitir que el usuario solo pueda crear una instancia de base de datos que use el grupo de parámetros de base de datos `mydbpg` y el grupo de subredes de base de datos `mydbsubnetgroup`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "rds:CreateDBInstance", "Resource": [ "arn:aws:rds:*:*:pg:mydbpg", "arn:aws:rds:*:*:subgrp:mydbsubnetgroup" ] } ] } ``` ------ ## Conceda permiso para acciones en un recurso con una etiqueta específica con dos valores diferentes. Puede utilizar las condiciones de su política basada en la identidad para controlar el acceso a los recursos de Aurora basados en etiquetas. La siguiente política da permiso para aplicar la operación de API `CreateDBSnapshot` y `stage` en instancias de base de datos con la etiqueta `stage` establecida en `development` o `test`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowAnySnapshotName", "Effect":"Allow", "Action":[ "rds:CreateDBSnapshot" ], "Resource":"arn:aws:rds:*:123456789012:snapshot:*" }, { "Sid":"AllowDevTestToCreateSnapshot", "Effect":"Allow", "Action":[ "rds:CreateDBSnapshot" ], "Resource":"arn:aws:rds:*:123456789012:db:*", "Condition":{ "StringEquals":{ "rds:db-tag/stage":[ "development", "test" ] } } } ] } ``` ------ La siguiente política da permiso para aplicar la operación de API `ModifyDBInstance` en instancias de base de datos con la etiqueta `stage` establecida en `development` o `test`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowChangingParameterOptionSecurityGroups", "Effect":"Allow", "Action":[ "rds:ModifyDBInstance" ], "Resource": [ "arn:aws:rds:*:123456789012:pg:*", "arn:aws:rds:*:123456789012:secgrp:*", "arn:aws:rds:*:123456789012:og:*" ] }, { "Sid":"AllowDevTestToModifyInstance", "Effect":"Allow", "Action":[ "rds:ModifyDBInstance" ], "Resource":"arn:aws:rds:*:123456789012:db:*", "Condition":{ "StringEquals":{ "rds:db-tag/stage":[ "development", "test" ] } } } ] } ``` ------ ## Evitar que un usuario elimine una instancia de base de datos La siguiente política de permisos concede permisos para impedir que un usuario elimine una instancia de base de datos específica. Por ejemplo, puede servir para impedir la eliminación de instancias de base de datos de producción a cualquier usuario que no sea un administrador. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyDelete1", "Effect": "Deny", "Action": "rds:DeleteDBInstance", "Resource": "arn:aws:rds:us-west-2:123456789012:db:my-mysql-instance" } ] } ``` ------ ## Denegar todo el acceso a un recurso Puede denegar explícitamente el acceso a un recurso. Las políticas de denegación tienen prioridad sobre las políticas de permiso. La política siguiente niega explícitamente a un usuario la capacidad de administrar un recurso: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "rds:*", "Resource": "arn:aws:rds:us-east-1:123456789012:db:mydb" } ] } ``` ------ # Políticas de ejemplo: uso de claves de condición Los siguientes ejemplos muestran cómo puede usar claves de condición en las políticas de permisos de IAM para Amazon Aurora. ## Ejemplo 1: conceder permiso para crear una instancia de base de datos que utilice un motor de base de datos específico y no sea Multi-AZ. La siguiente política utiliza una clave de condición de RDS y permite al usuario crear solamente instancias de base de datos que utilizan el motor de base de datos MySQL y no utilizan Multi-AZ. El elemento `Condition` indica el requisito de que el motor de base de datos sea MySQL. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowMySQLCreate", "Effect": "Allow", "Action": "rds:CreateDBInstance", "Resource": "*", "Condition": { "StringEquals": { "rds:DatabaseEngine": "mysql" }, "Bool": { "rds:MultiAz": false } } } ] } ``` ------ ## Ejemplo 2: denegar permiso explícitamente para crear instancias de base de datos para determinadas clases de instancia de base de datos y crear instancias de base de datos que utilizan IOPS provisionadas La siguiente política deniega permiso explícitamente para crear instancias de base de datos que utilizan las clases de instancia de base de datos `r3.8xlarge` y `m4.10xlarge`, que son las clases de instancia de base de datos más costosas y de mayor tamaño. Esta política también evita que los usuarios creen instancias de base de datos que utilizan IOPS provisionadas, las cuales tienen un costo adicional. Al denegarse permiso explícitamente se sustituye a cualquier otro permiso concedido. Esto garantiza que las identidades no obtengan accidentalmente permisos que el usuario no desee conceder nunca. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "DenyLargeCreate", "Effect": "Deny", "Action": "rds:CreateDBInstance", "Resource": "*", "Condition": { "StringEquals": { "rds:DatabaseClass": [ "db.r3.8xlarge", "db.m4.10xlarge" ] } } }, { "Sid": "DenyPIOPSCreate", "Effect": "Deny", "Action": "rds:CreateDBInstance", "Resource": "*", "Condition": { "NumericNotEquals": { "rds:Piops": "0" } } } ] } ``` ------ ## Ejemplo 3: limitar el conjunto de claves y valores de etiquetas que se pueden usar para etiquetar un recurso En la siguiente política se usa una clave condicional de RDS y permite añadir una etiqueta con la clave `stage` a un recurso con los valores `test`, `qa` y `production`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowTagEdits", "Effect": "Allow", "Action": [ "rds:AddTagsToResource", "rds:RemoveTagsFromResource" ], "Resource": "arn:aws:rds:us-east-1:123456789012:db:db-123456", "Condition": { "StringEquals": { "rds:req-tag/stage": [ "test", "qa", "production" ] } } } ] } ``` ------ # Especificación de condiciones: uso de etiquetas personalizadas Amazon Aurora admite la especificación de condiciones en una política de IAM que utiliza etiquetas personalizadas. Por ejemplo, suponga que añade una etiqueta con el nombre `environment` a sus instancias de base de datos con valores como `beta`, `staging`, `production`, etc. Si lo hace, puede crear una política que restrinja a ciertos usuarios en instancias de bases de datos basándose en el valor de la etiqueta `environment`. **nota** Los identificadores de etiquetas personalizados distinguen entre mayúsculas y minúsculas. En la tabla siguiente, se enumeran los identificadores de etiqueta de RDS que puede usar en un elemento `Condition`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAM.SpecifyingCustomTags.html) La sintaxis de una condición de etiqueta personalizada es la siguiente: `"Condition":{"StringEquals":{"rds:rds-tag-identifier/tag-name": ["value"]} }` Por ejemplo, el elemento `Condition` siguiente se aplica a instancias de base de datos con una etiqueta llamada `environment` y un valor de etiqueta `production`. ` "Condition":{"StringEquals":{"rds:db-tag/environment": ["production"]} } ` Para obtener información acerca de la creación etiquetas, consulte [Etiquetado de los recursos de Amazon Aurora y Amazon RDS](USER_Tagging.md). **importante** Si administra el acceso a sus recursos de RDS mediante el etiquetado, recomendamos que proteja el acceso a las etiquetas. Puede administrar el acceso a etiquetas creando políticas para las acciones `AddTagsToResource` y `RemoveTagsFromResource`. Por ejemplo, la política siguiente deniega a los usuarios la posibilidad de agregar o quitar etiquetas para todos los recursos. A continuación, puede crear políticas para permitir que usuarios específicos agreguen o quiten etiquetas. **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"DenyTagUpdates", "Effect":"Deny", "Action":[ "rds:AddTagsToResource", "rds:RemoveTagsFromResource" ], "Resource":"*" } ] } ``` Para ver una lista de las acciones de Aurora, consulte [Acciones definidas por Amazon RDS](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html#amazonrds-actions-as-permissions) en la *referencia de autorizaciones de servicio*. ## Políticas de ejemplo: uso de etiquetas personalizadas Los siguientes ejemplos muestran cómo puede usar etiquetas personalizadas en las políticas de permisos de IAM para Amazon Aurora. Para obtener más información sobre cómo agregar etiquetas a un recurso de Amazon Aurora, consulte [Nombres de recursos de Amazon (ARN) en Amazon RDS](USER_Tagging.ARN.md). **nota** Todos los ejemplos utilizan la región us-west-2 y contienen identificadores de cuenta ficticios. ### Ejemplo 1: conceda permiso para acciones en un recurso con una etiqueta específica con dos valores diferentes. La siguiente política da permiso para aplicar la operación de API `CreateDBSnapshot` en instancias de base de datos con la etiqueta `stage` establecida en `development` o `test`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowAnySnapshotName", "Effect":"Allow", "Action":[ "rds:CreateDBSnapshot" ], "Resource":"arn:aws:rds:*:123456789012:snapshot:*" }, { "Sid":"AllowDevTestToCreateSnapshot", "Effect":"Allow", "Action":[ "rds:CreateDBSnapshot" ], "Resource":"arn:aws:rds:*:123456789012:db:*", "Condition":{ "StringEquals":{ "rds:db-tag/stage":[ "development", "test" ] } } } ] } ``` ------ La siguiente política da permiso para aplicar la operación de API `ModifyDBInstance` en instancias de base de datos con la etiqueta `stage` establecida en `development` o `test`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowChangingParameterOptionSecurityGroups", "Effect":"Allow", "Action":[ "rds:ModifyDBInstance" ], "Resource": [ "arn:aws:rds:*:123456789012:pg:*", "arn:aws:rds:*:123456789012:secgrp:*", "arn:aws:rds:*:123456789012:og:*" ] }, { "Sid":"AllowDevTestToModifyInstance", "Effect":"Allow", "Action":[ "rds:ModifyDBInstance" ], "Resource":"arn:aws:rds:*:123456789012:db:*", "Condition":{ "StringEquals":{ "rds:db-tag/stage":[ "development", "test" ] } } } ] } ``` ------ ### Ejemplo 2: deniegue explícitamente permiso para crear una instancia de base de datos que utilice grupos de parámetros de base de datos especificados. La siguiente política deniega explícitamente permiso para crear una instancia de base de datos que utilice grupos de parámetros de base de datos con valores de etiqueta específicos. Podría aplicar esta política si necesita que se utilice siempre un grupo de parámetros de base de datos específico, creado por el cliente, al crear instancias de base de datos. Las políticas que utilizan `Deny` suelen aplicarse para restringir el acceso concedido por una política más amplia. Al denegarse permiso explícitamente se sustituye a cualquier otro permiso concedido. Esto garantiza que las identidades no obtengan accidentalmente permisos que el usuario no desee conceder nunca. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"DenyProductionCreate", "Effect":"Deny", "Action":"rds:CreateDBInstance", "Resource":"arn:aws:rds:*:123456789012:pg:*", "Condition":{ "StringEquals":{ "rds:pg-tag/usage":"prod" } } } ] } ``` ------ ### Ejemplo 3: conceda permiso para acciones en una instancia de base de datos con un nombre de instancia cuyo prefijo sea un nombre de usuario. La siguiente política da permiso para llamar a cualquier API (salvo `AddTagsToResource` o `RemoveTagsFromResource`) en una instancia de base de datos cuyo prefijo sea un nombre de usuario y que tenga una etiqueta llamada `stage` igual a `devo` o que no tenga ninguna etiqueta llamada `stage`. La línea `Resource` en la política identifica un recurso por su nombre de recurso de Amazon (ARN). Para obtener más información sobre el uso de ARN con recursos de Amazon Aurora, consulte [Nombres de recursos de Amazon (ARN) en Amazon RDS](USER_Tagging.ARN.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowFullDevAccessNoTags", "Effect":"Allow", "NotAction":[ "rds:AddTagsToResource", "rds:RemoveTagsFromResource" ], "Resource":"arn:aws:rds:*:123456789012:db:${aws:username}*", "Condition":{ "StringEqualsIfExists":{ "rds:db-tag/stage":"devo" } } } ] } ``` ------ # Concesión de permisos para etiquetar recursos de Aurora durante la creación Algunas operaciones de la API de RDS le permiten especificar etiquetas durante la creación del recurso. Puede utilizar etiquetas de recursos para implementar el control basado en atributos (ABAC). Para obtener más información, consulte ¿[Qué es ABAC para AWS?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) y [Control del acceso a los recursos de AWS mediante etiquetas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html). Para permitir que los usuarios etiqueten los recursos durante su creación, es preciso que tengan permisos para utilizar la acción que crea el recurso, por ejemplo `rds:CreateDBCluster`. Si se especifican etiquetas en la acción de creación, RDS realiza una autorización adicional en la acción `rds:AddTagsToResource` para verificar que los usuarios tengan permisos para crear etiquetas. Por lo tanto, los usuarios también deben tener permisos explícitos para usar la acción `rds:AddTagsToResource`. En la definición de la política de IAM para la acción `rds:AddTagsToResource`, puede utilizar la clave de condición `aws:RequestTag` para requerir etiquetas en una solicitud de etiquetado de un recurso. Por ejemplo, la siguiente política permite a los usuarios crear instancias de base de datos y aplicar etiquetas durante la creación de instancias de base de datos, pero solo con claves de etiqueta específicas (`environment` o `project`): ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "rds:CreateDBInstance" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "rds:AddTagsToResource" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/environment": ["production", "development"], "aws:RequestTag/project": ["dataanalytics", "webapp"] }, "ForAllValues:StringEquals": { "aws:TagKeys": ["environment", "project"] } } } ] } ``` ------ Esta política deniega cualquier solicitud de creación de instancias de base de datos que incluya etiquetas distintas de las etiquetas `environment` o `project`, o que no especifique ninguna de estas etiquetas. Además, los usuarios deben especificar valores para las etiquetas que coincidan con los valores permitidos en la política. La siguiente política permite a los usuarios crear clústeres de base de datos y aplicar cualquier etiqueta durante la creación, excepto la etiqueta `environment=prod`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "rds:CreateDBCluster" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "rds:AddTagsToResource" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestTag/environment": "prod" } } } ] } ``` ------ ## Acciones de la API de RDS compatibles para etiquetar durante la creación Las siguientes acciones de la API de RDS admiten el etiquetado al crear un recurso. Para estas acciones, puede especificar etiquetas al crear el recurso: + `CreateBlueGreenDeployment` + `CreateCustomDBEngineVersion` + `CreateDBCluster` + `CreateDBClusterEndpoint` + `CreateDBClusterParameterGroup` + `CreateDBClusterSnapshot` + `CreateDBInstance` + `CreateDBInstanceReadReplica` + `CreateDBParameterGroup` + `CreateDBProxy` + `CreateDBProxyEndpoint` + `CreateDBSecurityGroup` + `CreateDBShardGroup` + `CreateDBSnapshot` + `CreateDBSubnetGroup` + `CreateEventSubscription` + `CreateGlobalCluster` + `CreateIntegration` + `CreateOptionGroup` + `CreateTenantDatabase` + `CopyDBClusterParameterGroup` + `CopyDBClusterSnapshot` + `CopyDBParameterGroup` + `CopyDBSnapshot` + `CopyOptionGroup` + `RestoreDBClusterFromS3` + `RestoreDBClusterFromSnapshot` + `RestoreDBClusterToPointInTime` + `RestoreDBInstanceFromDBSnapshot` + `RestoreDBInstanceFromS3` + `RestoreDBInstanceToPointInTime` + `PurchaseReservedDBInstancesOffering` Si utiliza la AWS CLI o la API para crear un recurso con etiquetas, el parámetro `Tags` se utiliza para aplicar etiquetas a los recursos durante la creación. En el caso de estas acciones de la API, si se produce un error al etiquetar, el recurso no se crea y se produce un error en la solicitud. Esto garantiza que los recursos se creen con etiquetas o, de lo contrario, no se creen sin las etiquetas correspondientes. # AWSPolíticas administradas por para Amazon RDS Para añadir permisos a conjuntos de permisos y roles, es más fácil utilizar políticas administradas de AWS que escribirlas uno mismo. Se necesita tiempo y experiencia para [crear políticas administradas por el cliente de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) que le brinden a su equipo solo los permisos necesarios. Para comenzar rápidamente, puede utilizar nuestras políticas administradas de AWS. Estas políticas cubren casos de uso comunes y están disponibles en su Cuenta de AWS. Para obtener más información acerca de las políticas administradas de AWS, consulte [Políticas administradas de 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*. Los Servicios de AWS mantienen y actualizan las políticas administradas por AWS. No puede cambiar los permisos en las políticas administradas de AWS. En ocasiones, los servicios agregan permisos adicionales a una política administrada de AWS para admitir características nuevas. Este tipo de actualización afecta a todas las identidades (conjuntos de permisos y roles) donde se asocia la política. Es más probable que los servicios actualicen una política administrada de AWScuando se lanza una nueva característica o cuando se ponen a disposición nuevas operaciones. Los servicios no quitan permisos de una política administrada por AWS, por lo que las actualizaciones de políticas no deterioran los permisos existentes. Además, AWS admite políticas administradas para funciones de trabajo que abarcan varios servicios. Por ejemplo, la política administrada por `ReadOnlyAccess` AWS proporciona acceso de solo lectura a todos los recursos y a Servicios de AWS. Cuando un servicio lanza una nueva característica, AWS agrega permisos de solo lectura para las operaciones y los recursos nuevos. Para obtener una lista y descripciones de las políticas de funciones de trabajo, consulte [Políticas administradas de AWS para funciones de trabajo](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) en la *Guía del usuario de IAM*. **Topics** + [ ## Política administrada por:AWS AmazonRDSReadOnlyAccess ](#rds-security-iam-awsmanpol-AmazonRDSReadOnlyAccess) + [ ## Política administrada por:AWS AmazonRDSFullAccess ](#rds-security-iam-awsmanpol-AmazonRDSFullAccess) + [ ## Política administrada por:AWS AmazonRDSDataFullAccess ](#rds-security-iam-awsmanpol-AmazonRDSDataFullAccess) + [ ## Política administrada por:AWS AmazonRDSEnhancedMonitoringRole ](#rds-security-iam-awsmanpol-AmazonRDSEnhancedMonitoringRole) + [ ## Política administrada por:AWS AmazonRDSPerformanceInsightsReadOnly ](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly) + [ ## Política administrada por AWS: AmazonRDSPerformanceInsightsFullAccess ](#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess) + [ ## Política administrada por:AWS AmazonRDSDirectoryServiceAccess ](#rds-security-iam-awsmanpol-AmazonRDSDirectoryServiceAccess) + [ ## Política administrada por:AWS AmazonRDSServiceRolePolicy ](#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy) + [ ## Política administrada de:AWS AmazonRDSPreviewServiceRolePolicy ](#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy) + [ ## Política administrada de:AWS AmazonRDSBetaServiceRolePolicy ](#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy) ## Política administrada por:AWS AmazonRDSReadOnlyAccess Esta política permite acceso de solo lectura a Amazon RDS mediante la Consola de administración de AWS. **Detalles de los permisos** Esta política incluye los permisos siguientes: + `rds`: permite a las entidades principales describir los recursos de Amazon RDS y enumerar las etiquetas de los recursos de Amazon RDS. + `cloudwatch`: permite a las entidades principales obtener estadísticas de métricas de Amazon CloudWatch. + `ec2`: permite a las entidades principales describir las zonas de disponibilidad y los recursos de red. + `logs`: permite a las entidades principales describir los flujos de registro de CloudWatch Logs de los grupos de registros y obtener eventos de registro de CloudWatch Logs. + `devops-guru`: permite a las entidades principales describir los recursos que incluyen la cobertura de Amazon DevOps Guru, que se especifica mediante nombres de pila o etiquetas de recursos de CloudFormation. Para obtener más información sobre esta política, incluido el documento de política de JSON, consulte [AmazonRDSReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSReadOnlyAccess.html) en la *Guía de referencia de políticas administradas de AWS*. ## Política administrada por:AWS AmazonRDSFullAccess Esta política proporciona acceso completo a Amazon RDS mediante la Consola de administración de AWS. **Detalles de los permisos** Esta política incluye los permisos siguientes: + `rds`: permite a las entidades principales obtener acceso completo a Amazon RDS. + `application-autoscaling`: permite a las entidades principales describir y administrar los objetivos y las políticas de escalado de Application Auto Scaling. + `cloudwatch`: permite a las entidades principales obtener estadísticas métricas de CloudWatch y administrar alarmas de CloudWatch. + `ec2`: permite a las entidades principales describir las zonas de disponibilidad y los recursos de red. + `logs`: permite a las entidades principales describir los flujos de registro de CloudWatch Logs de los grupos de registros y obtener eventos de registro de CloudWatch Logs. + `outposts`: permite a las entidades principales obtener tipos de instancias AWS Outposts. + `pi`: permite a las entidades principales obtener métricas de Información sobre rendimiento. + `sns`: permite a las entidades principales acceder a las suscripciones y temas de Amazon Simple Notification Service (Amazon SNS), y publicar mensajes de Amazon SNS. + `devops-guru`: permite a las entidades principales describir los recursos que incluyen la cobertura de Amazon DevOps Guru, que se especifica mediante nombres de pila o etiquetas de recursos de CloudFormation. Para obtener más información sobre esta política, incluido el documento de política de JSON, consulte [AmazonRDSFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSFullAccess.html) en la *Guía de referencia de políticas administradas de AWS*. ## Política administrada por:AWS AmazonRDSDataFullAccess Esta política permite tener acceso completo para utilizar la API de datos y el editor de consultas en los clústeres de Aurora Serverless en una Cuenta de AWS determinada. Esta política permite a la Cuenta de AWS obtener el valor de un secreto de AWS Secrets Manager. Puede adjuntar la política de `AmazonRDSDataFullAccess` a las identidades de IAM. **Detalles de los permisos** Esta política incluye los permisos siguientes: + `dbqms`: permite a las entidades principales acceder, crear, eliminar, describir y actualizar consultas. El Database Query Metadata Service (`dbqms`) es un servicio únicamente interno. Proporciona sus consultas recientes y guardadas para el editor de consultas en la Consola de administración de AWS para varios servicios de Servicios de AWS, incluido Amazon RDS. + `rds-data`: permite a las entidades principales ejecutar instrucciones SQL en bases de datos de Aurora Serverless. + `secretsmanager` – permite a las entidades principales obtener el valor de un secreto de AWS Secrets Manager. Para obtener más información sobre esta política, incluido el documento de política de JSON, consulte [AmazonRDSDataFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDataFullAccess.html) en la *Guía de referencia de políticas administradas de AWS*. ## Política administrada por:AWS AmazonRDSEnhancedMonitoringRole Esta política proporciona acceso a registros de Amazon Cloudwatch para Supervisión mejorada de Amazon RDS. **Detalles de los permisos** Esta política incluye los permisos siguientes: + `logs`: permite a las entidades principales crear grupos de registros y políticas de retención de CloudWatch Logs, y crear y describir flujos de registro de CloudWatch Logs de los grupos de registro. También permite a las entidades principales poner y obtener eventos de registro de CloudWatch Logs. Para obtener más información sobre esta política, incluido el documento de política de JSON, consulte [AmazonRDSEnhancedMonitoringRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSEnhancedMonitoringRole.html) en la *Guía de referencia de políticas administradas de AWS*. ## Política administrada por:AWS AmazonRDSPerformanceInsightsReadOnly Esta política proporciona acceso de solo lectura a Información sobre rendimiento de Amazon RDS para instancias de base de datos de Amazon RDS y clústeres de base de datos de Amazon Aurora. Ahora, esta política incluye `Sid` (ID de instrucción) como identificador en las instrucciones de la política. **Detalles de los permisos** Esta política incluye los permisos siguientes: + `rds`: permite a las entidades principales describir instancias de base de datos de Amazon RDS y clústeres de base de datos de Amazon Aurora + `pi`: permite a las entidades principales realizar llamadas a la API de Información sobre rendimiento de Amazon RDS y acceder a las métricas de Información sobre rendimiento. Para obtener más información sobre esta política, incluido el documento de política de JSON, consulte [AmazonRDSPerformanceInsightsReadOnly](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsReadOnly.html) en la *Guía de referencia de políticas administradas de AWS*. ## Política administrada por AWS: AmazonRDSPerformanceInsightsFullAccess Esta política proporciona acceso completo a Información de rendimiento de Amazon RDS para instancias de base de datos de Amazon RDS y clústeres de base de datos de Amazon Aurora. Ahora, esta política incluye `Sid` (ID de instrucción) como identificador en las instrucciones de la política. **Detalles de los permisos** Esta política incluye los permisos siguientes: + `rds`: permite a las entidades principales describir instancias de base de datos de Amazon RDS y clústeres de base de datos de Amazon Aurora + `pi`: permite a los entidades principales realizar llamadas a la API de Información de rendimiento de Amazon RDS y crear, ver y eliminar informes de análisis de rendimiento. + `cloudwatch`: permite a las entidades principales enumerar todas las métricas de Amazon CloudWatch y obtener estadísticas y datos de las métricas. Para obtener más información sobre esta política, incluido el documento de política de JSON, consulte [AmazonRDSPerformanceInsightsFullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPerformanceInsightsFullAccess.html) en la *Guía de referencia de políticas administradas de AWS*. ## Política administrada por:AWS AmazonRDSDirectoryServiceAccess Esta política permite a Amazon RDS realizar llamadas al Directory Service. **Detalles de los permisos** Esta política incluye el siguiente permiso: + `ds`: permite a las entidades principales describir directorios y autorización de control de Directory Service a los directorios de Directory Service. Para obtener más información sobre esta política, incluido el documento de política de JSON, consulte [AmazonRDSDirectoryServiceAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSDirectoryServiceAccess.html) en la *Guía de referencia de políticas administradas de AWS*. ## Política administrada por:AWS AmazonRDSServiceRolePolicy No puede adjuntar la política `AmazonRDSServiceRolePolicy` a sus entidades de IAM. Esta política está adjunta a un rol vinculado a servicios que permite a Amazon RDS realizar acciones en su nombre. Para obtener más información, consulte [Permisos de roles vinculados a servicios de Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions). ## Política administrada de:AWS AmazonRDSPreviewServiceRolePolicy No debe adjuntar `AmazonRDSPreviewServiceRolePolicy` a sus entidades IAM. Esta política está asociada a un rol vinculado a servicios que permite que Amazon RDS llame a los servicios de AWS en nombre de sus recursos de base de datos de RDS. Para obtener más información, consulte [Rol vinculado a servicios para Amazon RDS Preview](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdspreview). **Detalles de los permisos** Esta política incluye los permisos siguientes: + `ec2`: permite a las entidades principales describir las zonas de disponibilidad y los recursos de red. + `secretsmanager` – permite a las entidades principales obtener el valor de un secreto de AWS Secrets Manager. + `cloudwatch`,:`logs` permite a Amazon RDS cargar registros y métricas de instancias de base de datos a CloudWatch a través del agente de CloudWatch. Para obtener más información sobre esta política, incluido el documento de política de JSON, consulte [AmazonRDSPreviewServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSPreviewServiceRolePolicy.html) en la *Guía de referencia de políticas administradas de AWS*. ## Política administrada de:AWS AmazonRDSBetaServiceRolePolicy No debe adjuntar `AmazonRDSBetaServiceRolePolicy` a sus entidades IAM. Esta política está asociada a un rol vinculado a servicios que permite que Amazon RDS llame a los servicios de AWS en nombre de sus recursos de base de datos de RDS. Para obtener más información, consulte [Permisos de roles vinculados a servicios para Amazon RDS Beta](UsingWithRDS.IAM.ServiceLinkedRoles.md#slr-permissions-rdsbeta). **Detalles de los permisos** Esta política incluye los permisos siguientes: + `ec2`: permite a Amazon RDS realizar operaciones de copia de seguridad en la instancia de base de datos, lo que proporciona capacidades de restauración en un momento dado. + `secretsmanager`: permite a Amazon RDS gestionar los secretos específicos de la instancia de base de datos creados por Amazon RDS. + `cloudwatch`,:`logs` permite a Amazon RDS cargar registros y métricas de instancias de base de datos a CloudWatch a través del agente de CloudWatch. Para obtener más información sobre esta política, incluido el documento de política de JSON, consulte [AmazonRDSBetaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSBetaServiceRolePolicy.html) en la *Guía de referencia de políticas administradas de AWS*. # Actualizaciones de Amazon RDS a políticas administradas por AWS Es posible consultar los detalles sobre las actualizaciones de las políticas administradas por AWS para Amazon RDS desde que este servicio comenzó a hacer un seguimiento de estos cambios. Para obtener alertas automáticas sobre cambios en esta página, suscríbase a la fuente RSS en la página de [historial de documentos](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/WhatsNew.html) de la API de Amazon RDS. | Cambio | Descripción | Fecha | | --- | --- | --- | | [Política administrada de:AWS AmazonRDSPreviewServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy): actualización de una política actual | Amazon RDS ha eliminado el permiso `sns:Publish` de `AmazonRDSPreviewServiceRolePolicy` del rol vinculado a un servicio `AWSServiceRoleForRDSPreview`. Para obtener más información, consulte [Política administrada de:AWS AmazonRDSPreviewServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy). | 7 de agosto de 2024 | | [Política administrada de:AWS AmazonRDSBetaServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy): actualización de una política actual | Amazon RDS ha eliminado el permiso `sns:Publish` de `AmazonRDSBetaServiceRolePolicy` del rol vinculado a un servicio `AWSServiceRoleForRDSBeta`. Para obtener más información, consulte [Política administrada de:AWS AmazonRDSBetaServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy). | 7 de agosto de 2024 | | [Política administrada por:AWS AmazonRDSServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy): actualización de una política actual | Amazon RDS ha eliminado el permiso `sns:Publish` de `AmazonRDSServiceRolePolicy` del rol vinculado a un servicio ` AWSServiceRoleForRDS`. Para obtener más información, consulte [Política administrada por:AWS AmazonRDSServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSServiceRolePolicy). | 2 de julio de 2024 | | [AWSPolíticas administradas por para Amazon RDS](rds-security-iam-awsmanpol.md): actualización de una política actual | Amazon RDS agregó un nuevo permiso a la `AmazonRDSCustomServiceRolePolicy` del rol vinculado al servicio `AWSServiceRoleForRDSCustom` para permitir que RDS Custom para SQL Server modifique el tipo de instancia de host de la base de datos subyacente. RDS también agregó el permiso `ec2:DescribeInstanceTypes` para obtener información sobre el tipo de instancia para el host de la base de datos. Para obtener más información, consulte [AWSPolíticas administradas por para Amazon RDS](rds-security-iam-awsmanpol.md). | 8 de abril de 2024 | | [AWSPolíticas administradas por para Amazon RDS](rds-security-iam-awsmanpol.md): política nueva | Amazon RDS agregó una nueva política administrada denominada AmazonRDSCustomInstanceProfileRolePolicy para permitir a RDS Custom realizar acciones de automatización y tareas de administración de bases de datos a través de un perfil de instancia de EC2. Para obtener más información, consulte [AWSPolíticas administradas por para Amazon RDS](rds-security-iam-awsmanpol.md). | 27 de febrero de 2024 | | [Permisos de roles vinculados a servicios de Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): actualización de una política actual | Amazon RDS ha agregado nuevos ID de instrucciones a la `AmazonRDSServiceRolePolicy` del rol vinculado a un servicio `AWSServiceRoleForRDS`. Para obtener más información, consulte [Permisos de roles vinculados a servicios de Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions). | 19 de enero de 2024 | | [AWSPolíticas administradas por para Amazon RDS](rds-security-iam-awsmanpol.md): actualización de políticas existentes | Las políticas administradas `AmazonRDSPerformanceInsightsReadOnly` y `AmazonRDSPerformanceInsightsFullAccess` incluyen ahora `Sid` (ID de instrucción) como identificador en las instrucciones de la política. Para obtener más información, consulte [Política administrada por:AWS AmazonRDSPerformanceInsightsReadOnly](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsReadOnly) y [Política administrada por AWS: AmazonRDSPerformanceInsightsFullAccess](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPerformanceInsightsFullAccess). | 23 de octubre de 2023 | | [AWSPolíticas administradas por para Amazon RDS](rds-security-iam-awsmanpol.md): actualización de una política actual | Amazon RDS ha añadido nuevos permisos a la política administrada `AmazonRDSFullAccess`. Los permisos le permiten generar, ver y eliminar el informe de análisis de rendimiento durante un período de tiempo. Para obtener más información sobre la configuración de políticas de acceso para la Información de rendimiento, consulte [Configuración de directivas de acceso para información sobre rendimiento](USER_PerfInsights.access-control.md) | 17 de agosto de 2023 | | [AWSPolíticas administradas por para Amazon RDS](rds-security-iam-awsmanpol.md): nueva política y actualización de la política existente | Amazon RDS ha añadido nuevos permisos a la política administrada `AmazonRDSPerformanceInsightsReadOnly` y una nueva política administrada  denominada `AmazonRDSPerformanceInsightsFullAccess`. Estos permisos le permiten analizar la Información de rendimiento durante un período de tiempo, ver los resultados del análisis junto con las recomendaciones y eliminar los informes. Para obtener más información sobre la configuración de políticas de acceso para la Información de rendimiento, consulte [Configuración de directivas de acceso para información sobre rendimiento](USER_PerfInsights.access-control.md) | 16 de agosto de 2023 | | [AWSPolíticas administradas por para Amazon RDS](rds-security-iam-awsmanpol.md): actualización de una política actual | Amazon RDS ha añadido el espacio de nombres de Amazon CloudWatch `ListMetrics` a `AmazonRDSFullAccess` y `AmazonRDSReadOnlyAccess`. Este espacio de nombres es necesario para que Amazon RDS publique métricas de uso de recursos específicas. Para obtener más información, consulte [Overview of managing access permissions to your CloudWatch resources](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-access-control-overview-cw.html) (Información general sobre la administración de los permisos de acceso a los recursos de CloudWatch) en la *Guía del usuario de Amazon CloudWatch*. | 4 de abril de 2023 | | [Permisos de roles vinculados a servicios de Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): actualización de una política actual | Amazon RDS ha añadido nuevos permisos a la `AmazonRDSServiceRolePolicy` del rol vinculado a un servicio `AWSServiceRoleForRDS` para su integración con AWS Secrets Manager. RDS debe integrarse con Secrets Manager para administrar las contraseñas de los usuarios maestros en Secrets Manager. El secreto utiliza una convención de nomenclatura reservada y restringe las actualizaciones de los clientes. Para obtener más información, consulte [Administración de contraseñas con Amazon Aurora y AWS Secrets Manager](rds-secrets-manager.md). | 22 de diciembre de 2022 | | [AWSPolíticas administradas por para Amazon RDS](rds-security-iam-awsmanpol.md): actualización de políticas existentes | Amazon RDS ha agregado un nuevo permiso a la política `AmazonRDSFullAccess` y las políticas administradas de `AmazonRDSReadOnlyAccess` para permitirle activar Amazon DevOps Guru en la consola de RDS. Este permiso es necesario para comprobar si DevOps Guru está activado. Para obtener más información, consulte [Configuración de las políticas de acceso de IAM para DevOps Guru para RDS](devops-guru-for-rds.md#devops-guru-for-rds.configuring.access). | 19 de diciembre de 2022 | | [Permisos de roles vinculados a servicios de Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): actualización de una política actual | Amazon RDS ha añadido nuevos espacios de nombres de Amazon CloudWatch a `AmazonRDSPreviewServiceRolePolicy` para `PutMetricData`. Este espacio de nombres es necesario para que Amazon RDS publique métricas de uso de recursos. Para obtener más información, consulte [Uso de claves de condición para limitar el acceso a los espacios de nombres de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) en la *guía del usuario de Amazon CloudWatch*. | 7 de junio de 2022 | | [Permisos de roles vinculados a servicios de Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): actualización de una política actual | Amazon RDS ha añadido nuevos espacios de nombres de Amazon CloudWatch a `AmazonRDSBetaServiceRolePolicy` para `PutMetricData`. Este espacio de nombres es necesario para que Amazon RDS publique métricas de uso de recursos. Para obtener más información, consulte [Uso de claves de condición para limitar el acceso a los espacios de nombres de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) en la *guía del usuario de Amazon CloudWatch*. | 7 de junio de 2022 | | [Permisos de roles vinculados a servicios de Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): actualización de una política actual | Amazon RDS ha añadido nuevos espacios de nombres de Amazon CloudWatch a `AWSServiceRoleForRDS` para `PutMetricData`. Este espacio de nombres es necesario para que Amazon RDS publique métricas de uso de recursos. Para obtener más información, consulte [Uso de claves de condición para limitar el acceso a los espacios de nombres de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) en la *guía del usuario de Amazon CloudWatch*. | 22 de abril de 2022 | | [AWSPolíticas administradas por para Amazon RDS](rds-security-iam-awsmanpol.md): política nueva | Amazon RDS ha añadido una nueva política administrada llamada `AmazonRDSPerformanceInsightsReadOnly` para permitir que Amazon RDS llame a servicios de AWS en nombre de sus instancias de bases de datos. Para obtener más información sobre la configuración de políticas de acceso para la Información de rendimiento, consulte [Configuración de directivas de acceso para información sobre rendimiento](USER_PerfInsights.access-control.md) | 10 de marzo de 2022 | | [Permisos de roles vinculados a servicios de Amazon Aurora](UsingWithRDS.IAM.ServiceLinkedRoles.md#service-linked-role-permissions): actualización de una política actual | Amazon RDS ha añadido nuevos espacios de nombres de Amazon CloudWatch a `AWSServiceRoleForRDS` para `PutMetricData`. Estos espacios de nombres son necesarios para Amazon DocumentDB (compatible con MongoDB) y Amazon Neptune para publicar métricas de CloudWatch. Para obtener más información, consulte [Uso de claves de condición para limitar el acceso a los espacios de nombres de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/iam-cw-condition-keys-namespace.html) en la *guía del usuario de Amazon CloudWatch*. | 4 de marzo de 2022 | | Amazon RDS ha comenzado a hacer un seguimiento de los cambios | Amazon RDS ha comenzado a realizar un seguimiento de los cambios en sus políticas administradas por AWS. | 26 de octubre de 2021 | # Prevención de los problemas del suplente confuso 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 puede 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 pueden ayudarlo a proteger sus datos en todos los servicios con entidades principales de servicio a las que se les ha dado acceso a los recursos de su cuenta. Para obtener más información, consulte [El problema del suplente confuso](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) en la *Guía del usuario de IAM*. A fin de limitar los permisos que Amazon RDS da a otro servicio para un recurso específico, le recomendamos utilizar las claves de contexto de condición global de [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. En algunos casos, el valor de `aws:SourceArn` no contiene el ID de la cuenta, por ejemplo, al utilizar el nombre de recurso de Amazon (ARN) para un bucket de Simple Storage Service (Amazon S3). En estos casos, asegúrese de utilizar ambas claves de contexto de condición global para limitar los permisos. En algunos casos, se utilizan las claves de contexto de condición global y el valor de `aws:SourceArn` contiene el ID de la cuenta. En estos casos, asegúrese de que el valor de `aws:SourceAccount` y la cuenta en `aws:SourceArn` utilicen el mismo ID de cuenta cuando se utilizan en la misma instrucción de política. Si quiere que solo se asocie un recurso al acceso entre servicios, utilice `aws:SourceArn`. Si quiere permitir que cualquier recurso de esa cuenta de AWS se asocie al uso entre servicios, utilice `aws:SourceAccount`. Asegúrese de que el valor de `aws:SourceArn` sea un ARN para un tipo de recurso de Amazon RDS. Para obtener más información, consulte [Nombres de recursos de Amazon (ARN) en Amazon RDS](USER_Tagging.ARN.md). La forma más eficaz de protegerse contra el problema del suplente confuso es utilizar la clave de contexto de condición global de `aws:SourceArn` con el ARN completo del recurso. En algunos casos, es posible que no sepa el ARN completo del recurso o que esté especificando varios recursos. En estos casos, utilice la clave de condición de contexto global de `aws:SourceArn` con comodines (`*`) para las partes desconocidas del ARN. Un ejemplo es `arn:aws:rds:*:123456789012:*`. En el ejemplo siguiente, se muestra cómo se pueden utilizar las claves de contexto de condición global de `aws:SourceArn` y `aws:SourceAccount` en Amazon RDS para evitar el problema del suplente confuso. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Sid": "ConfusedDeputyPreventionExamplePolicy", "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn": "arn:aws:rds:us-east-1:123456789012:db:mydbinstance" }, "StringEquals": { "aws:SourceAccount": "123456789012" } } } } ``` ------ Para ver más ejemplos de las políticas que utilizan las claves de contexto de condición global de `aws:SourceArn` y `aws:SourceAccount`, consulte las siguientes secciones: + [Concesión de permisos para publicar notificaciones en un tema de Amazon SNS](USER_Events.GrantingPermissions.md) + [Configuración del acceso a un bucket de Amazon S3](USER_PostgreSQL.S3Import.AccessPermission.md) (importación de PostgreSQL) + [Configuración del acceso a un bucket de Amazon S3](postgresql-s3-export-access-bucket.md) (exportación de PostgreSQL) # Autenticación de bases de datos de IAM Puede autenticar en su clúster de bases de datos mediante la autenticación de base de datos de AWS Identity and Access Management (IAM). La autenticación de base de datos de IAM funciona con Aurora MySQL y Aurora PostgreSQL. Con este método de autenticación, no es necesario usar una contraseña al conectarse a un clúster de bases de datos. En su lugar, puede usar un token de autenticación. Un *token de autenticación* es una cadena única de caracteres que genera Amazon Aurora bajo demanda. Los tokens de autenticación se generan mediante AWS Signature versión 4. Cada token tiene una vida útil de 15 minutos. No es necesario almacenar credenciales de usuario en la base de datos, ya que la autenticación se administra de forma externa mediante IAM. También puede seguir utilizando la autenticación de base de datos estándar. El token solo se utiliza para la autenticación y no afecta a la sesión después de establecerse. La autenticación de bases de datos de IAM proporciona los siguientes beneficios: + El tráfico de red hacia y desde la base de datos se cifra mediante Secure Socket Layer (SSL) o Transport Layer Security (TLS). Para obtener más información sobre el uso de SSL/TLS con Amazon Aurora, consulte [Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos](UsingWithRDS.SSL.md). + Puede usar IAM para administrar de forma centralizada el acceso a sus recursos de base de datos, en lugar de administrar el acceso individualmente en cada clúster de bases de datos. + Para las aplicaciones que se ejecutan en Amazon EC2, puede usar las credenciales del perfil específicas de la instancia de EC2 para obtener acceso a su base de datos en lugar de una contraseña, para mayor seguridad. En general, considere la posibilidad de utilizar la autenticación de base de datos de IAM cuando sus aplicaciones creen menos de 200 conexiones por segundo y no desee administrar los nombres de usuario y las contraseñas directamente en el código de la aplicación. El controlador JDBC de Amazon Web Services (AWS) admite la autenticación de base de datos de IAM. Para obtener más información, consulte [AWS IAM Authentication Plugin](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/using-the-jdbc-driver/using-plugins/UsingTheIamAuthenticationPlugin.md) en el [repositorio GitHub del controlador JDBC de Amazon Web Services (AWS)](https://github.com/aws/aws-advanced-jdbc-wrapper). El controlador de Python de Amazon Web Services (AWS) admite la autenticación de base de datos de IAM. Para obtener más información, consulte [AWS IAM Authentication Plugin](https://github.com/aws/aws-advanced-python-wrapper/blob/main/docs/using-the-python-driver/using-plugins/UsingTheIamAuthenticationPlugin.md) en el [repositorio GitHub del controlador de Python de Amazon Web Services (AWS)](https://github.com/aws/aws-advanced-python-wrapper). Consulte los siguientes temas para aprender a utilizar el proceso de configuración de IAM para la autenticación de bases de datos: + [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md) + [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md) + [Creación de cuentas de base de datos utilizando autenticación de IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md) + [Conexión a al clúster de bases de datos con la autenticación de IAM](UsingWithRDS.IAMDBAuth.Connecting.md) ## Disponibilidad en regiones y versiones La disponibilidad de las características varía según las versiones específicas de cada motor de base de datos de Aurora y entre Regiones de AWS. Para obtener más información sobre la disponibilidad en las versiones y las regiones de la autenticación de base de datos de IAM y Aurora, consulte [Regiones y motores de base de datos Aurora admitidos para autenticación de bases de datos IAM](Concepts.Aurora_Fea_Regions_DB-eng.Feature.IAMdbauth.md). Respecto de Aurora MySQL, todas las clases de instancia de base de datos admitidas son compatibles con la autenticación de bases de datos de IAM, excepto db.t2.small y db.t3.small. Para obtener más información sobre las clases de instancias de bases de datos admitidas, consulte [Motores de base de datos compatibles para clases de instancia de base de datos](Concepts.DBInstanceClass.SupportAurora.md). ## Soporte de CLI y SDK La autenticación de bases de datos de IAM está disponible para la [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/generate-db-auth-token.html) y para los siguientes SDK de AWS específicos para cada lenguaje: + [AWS SDK para .NET](https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/RDS/TRDSAuthTokenGenerator.html) + [AWS SDK para C\$1\$1](https://docs.aws.amazon.com/sdk-for-cpp/latest/api/class_aws_1_1_r_d_s_1_1_r_d_s_client.html#ae134ffffed5d7672f6156d324e7bd392) + [AWS SDK para Go](https://docs.aws.amazon.com/sdk-for-go/api/service/rds/#pkg-overview) + [AWS SDK para Java](https://docs.aws.amazon.com/sdk-for-java/latest/reference/software/amazon/awssdk/services/rds/RdsUtilities.html) + [AWS SDK para JavaScript](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/modules/_aws_sdk_rds_signer.html) + [AWS SDK para PHP](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.Rds.AuthTokenGenerator.html) + [AWS SDK para Python (Boto3)](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/rds.html#RDS.Client.generate_db_auth_token) + [AWS SDK para Ruby](https://docs.aws.amazon.com/sdk-for-ruby/v3/api/Aws/RDS/AuthTokenGenerator.html) ## Restricciones a la autenticación de bases de datos de IAM Si utiliza la autenticación de base de datos de IAM, se aplicarán las siguientes limitaciones: + Actualmente, la autenticación de base de datos de IAM no admite todas las claves de contexto de condición global. Para obtener más información sobre las claves de condición globales, 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 PostgreSQL, si se agrega el rol de IAM (`rds_iam`) a un usuario (incluido el usuario maestro de RDS), la autenticación de IAM tiene prioridad sobre la autenticación de la contraseña, por lo que el usuario debe iniciar sesión como un usuario de IAM. + No puede utilizar un registro DNS personalizado de Route 53 en lugar del punto de conexión del clúster de base de datos para generar el token de autenticación. + CloudWatch y CloudTrail no registran la autenticación de IAM. Estos servicios no rastrean las llamadas a la API `generate-db-auth-token` que autorizan a la función de IAM a habilitar la conexión a la base de datos. + La autenticación de la base de datos de IAM requiere recursos informáticos en el clúster de la base de datos. Debe tener entre 300 MiB y 1000 MiB de memoria adicional en la base de datos para obtener una conectividad fiable. Para ver la memoria necesaria para la carga de trabajo, compare la columna RES de los procesos RDS en la lista de procesos de supervisión mejorada antes y después de habilitar la autenticación de bases de datos de IAM. Consulte [Visualización de métricas OS en la consola de RDS](USER_Monitoring.OS.Viewing.md). Si está utilizando una instancia de clase ampliable, evite quedarse sin memoria mediante la reducción de la memoria utilizada por otros parámetros como búferes y caché en la misma cantidad. + Para Aurora MySQL, no puede utilizar la autenticación basada en contraseñas para un usuario de base de datos que configure con la autenticación de IAM. + La autenticación de base de datos de IAM no es compatible con RDS en Outposts para ningún motor. ## Recomendaciones para la autenticación de base de datos de IAM Recomendamos lo siguiente cuando se utiliza la autenticación de base de datos de IAM: + Utilice la autenticación de base de datos de IAM cuando la aplicación necesite menos de 200 conexiones nuevas por segundo para la autenticación de bases de datos de IAM. Los motores de base de datos que funcionan con Amazon Aurora no imponen ninguna restricción a los intentos de autenticación por segundo. Sin embargo, al usar la autenticación de bases de datos de IAM, su aplicación debe generar un token de autenticación. A continuación, su aplicación usa ese token para conectarse a el clúster de bases de datos. Si supera el límite máximo de nuevas conexiones por segundo, la sobrecarga adicional de la autenticación de bases de datos de IAM puede dar lugar a la limitación controlada de las conexiones. Considere la posibilidad de utilizar la agrupación de conexiones en sus aplicaciones para mitigar la creación constante de conexiones. Esto puede reducir la sobrecarga de la autenticación de bases de datos de IAM y permitir que las aplicaciones reutilicen las conexiones existentes. De forma alternativa, también puede utilizar RDS Proxy para estos casos de uso. RDS Proxy tiene costos adicionales. Consulte los [precios de RDS Proxy](https://aws.amazon.com/rds/proxy/pricing/). + El tamaño de un token de autenticación de base de datos de IAM depende de muchos factores, como la cantidad de etiquetas de IAM, las políticas de servicio de IAM, las longitudes del ARN y otras propiedades de IAM y de la base de datos. El tamaño mínimo de este token suele ser de aproximadamente 1 KB, pero puede ser mayor. Dado que este token se utiliza como contraseña en la cadena de conexión a la base de datos mediante la autenticación de IAM, debe asegurarse de que ni el controlador de la base de datos (por ejemplo, ODBC) ni ninguna herramienta limiten ni trunquen de otro modo este token debido a su tamaño. Un token truncado provocará un error en la validación de autenticación que realiza la base de datos e IAM. + Si utiliza credenciales temporales al crear un token de autenticación de base de datos de IAM, las credenciales temporales deben seguir siendo válidas cuando utilice el token de autenticación de base de datos de IAM para realizar una solicitud de conexión. ## Claves de contexto de condición globales de AWS admitidas La autenticación de base de datos de IAM no admite el siguiente subconjunto de claves de contexto de condición globales de AWS. + `aws:Referer` + `aws:SourceIp` + `aws:SourceVpc` + `aws:SourceVpce` + `aws:UserAgent` + `aws:VpcSourceIp` Para obtener más información, 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*. # Activación y desactivación de la autenticación de bases de datos de IAM De forma predeterminada, la autenticación de bases de datos de IAM está deshabilitada en los clústeres de base de datos. Puede activar o desactivar la autenticación de bases de datos de IAM mediante la Consola de administración de AWS, la AWS CLI o la API. Puede habilitar la autenticación de base de datos de IAM cuando realice una de las siguientes acciones: + Para crear un nuevo clúster de bases de datos con la autenticación de base de datos de IAM activada, consulte [Creación de un clúster de base de datos de Amazon Aurora](Aurora.CreateInstance.md). + Para modificar un clúster de bases de datos para activar la autenticación de bases de datos de IAM, consulte [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md). + Para restaurar un clúster de bases de datos a partir de una instantánea con la autenticación de base de datos de IAM activada, consulte [Restauración de una instantánea de clúster de base de datos](aurora-restore-snapshot.md). + Para restaurar un clúster de bases de datos a un momento dado con la autenticación de base de datos de IAM habilitada, consulte [Restauración de un clúster de base de dato a un momento indicado](aurora-pitr.md). ## Consola Cada flujo de trabajo de creación o modificación tiene una sección **Database authentication (Autenticación de base de datos)**, donde puede activar o desactivar la autenticación de base de datos de IAM. En esa sección, elija **Password and IAM database authentication (Autenticación de bases de datos con contraseña e IAM)** para activar la autenticación de base de datos de IAM. **Para activar o desactivar la autenticación de IAM para un clúster de bases de datos existente** 1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En el panel de navegación, seleccione **Databases (Bases de datos)**. 1. Elija el clúster de bases de datos que desea modificar. **nota** Solo puede habilitar la autenticación de IAM si todas las instancias de base de datos del clúster de bases de datos son compatibles con IAM. Compruebe los requisitos de compatibilidad en [Disponibilidad en regiones y versiones](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability). 1. Elija **Modify**. 1. En la sección **Autenticación de base de datos**, elija **Autenticación de bases de datos de IAM** para habilitar la autenticación de bases de datos de IAM. Elija **Autenticación con contraseña** o **Contraseña y autenticación Kerberos** para deshabilitar la autenticación de IAM. 1. También puede elegir habilitar la publicación de registros de autenticación de bases de datos de IAM en Registros de CloudWatch. En **Exportaciones de registros**, elija la opción **registro iam-db-auth-error**. La publicación de los registros en Registros de CloudWatch consume almacenamiento y se generan cargos por dicho almacenamiento. Asegúrese de eliminar los Registros de CloudWatch que ya no necesite. 1. Elija **Continue**. 1. Para aplicar los cambios inmediatamente, elija **Immediately (Inmediatamente)** en la sección **Scheduling of modifications (Programación de modificaciones)**. 1. Elija **Modify cluster (Modificar clúster)**. ## AWS CLI Para crear un clúster de bases de datos nuevo con la autenticación de IAM mediante la AWS CLI, use el comando [https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html). Especifique la opción `--enable-iam-database-authentication`. Para actualizar un clúster de bases de datos existente para que tenga o no tenga autenticación de IAM, utilice el comando [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) de la `modify-db-cluster`. Especifique la opción `--enable-iam-database-authentication` o `--no-enable-iam-database-authentication`, como proceda. **nota** Solo puede habilitar la autenticación de IAM si todas las instancias de base de datos del clúster de bases de datos son compatibles con IAM. Compruebe los requisitos de compatibilidad en [Disponibilidad en regiones y versiones](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability). De forma predeterminada, Aurora realiza la modificación durante el siguiente periodo de mantenimiento. Si desea invalidar esto y habilitar la autenticación de bases de datos de IAM lo antes posible, use el parámetro `--apply-immediately`. Si restaura un clúster de bases de datos, use uno de los siguientes comandos de AWS CLI: + `[restore-db-cluster-to-point-in-time](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-cluster-to-point-in-time.html)` + `[restore-db-cluster-from-db-snapshot](https://docs.aws.amazon.com/cli/latest/reference/rds/restore-db-instance-from-db-snapshot.html)` De forma predeterminada, la configuración de la autenticación de bases de datos de IAM será la de la instantánea de origen. Para cambiar esta configuración, establezca la opción `--enable-iam-database-authentication` o `--no-enable-iam-database-authentication`, como proceda. ## API de RDS Para crear una instancia de base de datos nueva con la autenticación de IAM mediante la API, use la operación de la API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html). Defina el parámetro `EnableIAMDatabaseAuthentication` como `true`. Para actualizar un clúster de bases de datos existente para que tenga o no tenga autenticación de IAM, utilice la operación de la API [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html). Establezca el parámetro `EnableIAMDatabaseAuthentication` en `true` para habilitar la autenticación de IAM o en `false` para deshabilitarla. **nota** Solo puede habilitar la autenticación de IAM si todas las instancias de base de datos del clúster de bases de datos son compatibles con IAM. Compruebe los requisitos de compatibilidad en [Disponibilidad en regiones y versiones](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability). Si restaura un clúster de bases de datos, use una de las siguientes operaciones de la API: + [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterFromSnapshot.html) + [https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_RestoreDBClusterToPointInTime.html) De forma predeterminada, la configuración de la autenticación de bases de datos de IAM será la de la instantánea de origen. Para cambiar esta configuración, establezca el parámetro `EnableIAMDatabaseAuthentication` en `true` para habilitar la autenticación de IAM o `false` para deshabilitarla. # Creación y uso de una política de IAM para el acceso a bases de datos de IAM Para permitir a un usuario o rol conectarse a su clúster de base de datos, debe crear una política de IAM. Después de eso, puede asociar la política a un conjunto de permisos o un rol. **nota** Para obtener más información acerca de las políticas de IAM, consulte [Administración de la identidad y el acceso en Amazon Aurora](UsingWithRDS.IAM.md). La siguiente política de ejemplo permite a un usuario conectarse a un clúster de base de datos mediante la autenticación de bases de datos de IAM. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "rds-db:connect" ], "Resource": [ "arn:aws:rds-db:us-east-2:111122223333:dbuser:cluster-ABCDEFGHIJKL01234/db_user" ] } ] } ``` ------ **importante** Un usuario con permisos de administrador puede acceder a los clústeres de base de datos sin permiso explícito en una política de IAM. Si desea restringir el acceso del administrador a los clústeres de de base de datos, puede crear un rol de IAM con los permisos privilegiados menores y asignarlo al administrador. **nota** No confunda el prefijo `rds-db:` con otros prefijos de operación de la API de RDS que empiezan por `rds:`. Puede usar el prefijo `rds-db:` y la acción `rds-db:connect` solo para la autenticación de bases de datos de IAM. No son válidos en ningún otro contexto. La política de ejemplo incluye una sola instrucción con los siguientes elementos: + `Effect`: especifique `Allow` para conceder acceso al clúster de bases de datos. Si no permite el acceso de forma explícita, el acceso se deniega de forma predeterminada. + `Action`: especifique `rds-db:connect` para permitir las conexiones al clúster de bases de datos. + `Resource`: especifique un nombre de recurso de Amazon (ARN) que describa una cuenta de base de datos en un clúster de bases de datos. El formato del ARN es el siguiente. ``` arn:aws:rds-db:region:account-id:dbuser:DbClusterResourceId/db-user-name ``` En este formato, reemplace lo siguiente: + `region` es la región de AWS para la y clúster de bases de datos. En la política de ejemplo, la región de AWS es `us-east-2`. + `account-id` es el número de cuenta de AWS para la y clúster de bases de datos. En la política de ejemplo, el número de cuenta es `1234567890`. El usuario debe estar en la misma cuenta que la cuenta de el clúster de base de datos. Para realizar el acceso entre cuentas, cree un rol de IAM con la política que se muestra arriba en la cuenta para el clúster de base de datos y permita que su otra cuenta asuma el rol. + `DbClusterResourceId` es el identificador del clúster de bases de datos. Este identificador es único para una región de AWS y nunca cambia. En la política de ejemplo, el identificador es `cluster-ABCDEFGHIJKL01234`. Para buscar un ID de recurso de clúster de bases de datos en la Consola de administración de AWS de Amazon Aurora, elija el clúster de bases de datos para ver los detalles. A continuación, elija la pestaña **Configuration (Configuración)**. El **Resource ID (ID de recurso)** se muestra en la sección **Configuration (Configuración)**. También puede usar el comando de la AWS CLI para enumerar los identificadores e ID de recurso para todas sus y clústeres de base de datos en la región de AWS actual, como se muestra a continuación. ``` aws rds describe-db-clusters --query "DBClusters[*].[DBClusterIdentifier,DbClusterResourceId]" ``` **nota** Si se está conectando a una base de datos a través del proxy de RDS, especifique el ID del recurso proxy; por ejemplo, `prx-ABCDEFGHIJKL01234`. Para obtener información sobre el uso de la autenticación de bases de datos de IAM con el proxy de RDS, consulte [Conexión a una base de datos mediante autenticación de IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam). + `db-user-name` es el nombre de la cuenta de base de datos que se asociará a la autenticación de IAM. En la política de ejemplo, la cuenta de base de datos es `db_user`. Puede crear otros ARN que admitan diversos patrones de acceso. La siguiente política permite el acceso a dos cuentas de base de datos diferentes en un cluster de base de datos. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "rds-db:connect" ], "Resource": [ "arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/jane_doe", "arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-ABCDEFGHIJKL01234/mary_roe" ] } ] } ``` ------ La siguiente política usa el carácter "\$1" a fin de buscar coincidencias con todas las y clústeres de base de datos y cuentas de base de datos para una cuenta de AWS y una región de AWS determinadas. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "rds-db:connect" ], "Resource": [ "arn:aws:rds-db:us-east-2:111122223333:dbuser:*/*" ] } ] } ``` ------ La siguiente política busca coincidencias con todas las y clústeres de base de datos para una cuenta de AWS y una región de AWS determinadas. Sin embargo, la política solo concede acceso a clústeres de base de datos que tienen una cuenta de base de datos `jane_doe`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "rds-db:connect" ], "Resource": [ "arn:aws:rds-db:us-east-2:123456789012:dbuser:*/jane_doe" ] } ] } ``` ------ El usuario o el rol solo tiene acceso a las mismas bases de datos que el usuario de la base de datos. Por ejemplo, suponga que su clúster de bases de datos tiene una base de datos denominada *dev* y otra llamada *test*. Si el usuario de base de datos `jane_doe` solo tiene acceso a *dev*, cualquier usuario o rol que obtenga acceso a ese clúster de base de datos con el usuario `jane_doe` también tendrá acceso únicamente a *dev*. Esta restricción del acceso también se aplica a otros objetos de la base de datos tales como tablas, vistas, etc. Un administrador debe crear políticas de IAM que concedan permisos a las entidades para realizar operaciones de la API concretas en los recursos especificados que necesiten. El administrador debe asociar esas políticas a los conjuntos de permisos o roles que necesiten esos permisos. Para ver algunos ejemplos de políticas, consulte [Ejemplos de políticas basadas en identidad para Amazon Aurora](security_iam_id-based-policy-examples.md). ## Asociación de una política de IAM a un conjunto de permisos o un rol Tras crear una política de IAM que permita la autenticación de bases de datos, es necesario asociar la política a un conjunto de permisos o un rol. Para ver un tutorial acerca de este tema, consulte [ Crear y asociar su primera política administrada por el cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) en la *Guía del usuario de IAM*. Mientras realiza el tutorial, puede usar uno de los ejemplos de política mostrados en esta sección como punto de partida y adaptarlo a sus necesidades. Al final del tutorial, tiene un conjunto de permisos con una política asociada que puede utilizar la acción `rds-db:connect`. **nota** Puede asignar varios conjuntos de permisos o roles a la misma cuenta de usuario de base de datos. Por ejemplo, suponga que su política de IAM ha especificado el siguiente ARN del recurso. ``` arn:aws:rds-db:us-east-2:123456789012:dbuser:cluster-12ABC34DEFG5HIJ6KLMNOP78QR/jane_doe ``` Si adjunta la política a los usuarios *Jane*, *Bob* y *Diego*, cada uno de esos usuarios puede conectarse al clúster especificado de base de datos por medio de la cuenta de la base de datos de `jane_doe`. # Creación de cuentas de base de datos utilizando autenticación de IAM Con la autenticación de bases de datos de IAM, no es necesario asignar contraseñas de la base de datos a las cuentas de usuario creadas. Si quita un usuario asignado a una cuenta de base de datos, también debe quitar la cuenta de base de datos con la instrucción `DROP USER`. **nota** El nombre de usuario utilizado para la autenticación de IAM debe coincidir con el nombre de usuario en la base de datos. **Topics** + [ ## Uso de la autenticación de IAM con Aurora MySQL ](#UsingWithRDS.IAMDBAuth.DBAccounts.MySQL) + [ ## Uso de la autenticación de IAM con AuroraPostgreSQL ](#UsingWithRDS.IAMDBAuth.DBAccounts.PostgreSQL) ## Uso de la autenticación de IAM con Aurora MySQL Con Aurora MySQL, `AWSAuthenticationPlugin` gestiona la autenticación. Se trata de un complemento proporcionado por AWS que funciona perfectamente con IAM para autenticar a sus usuarios. Conecte al clúster de de base de datos como usuario maestro o como usuario diferente que pueda crear usuarios y conceder privilegios. Tras la conexión, lance la instrucción `CREATE USER`, tal como se muestra en el siguiente ejemplo. ``` CREATE USER 'jane_doe' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS'; ``` La cláusula `IDENTIFIED WITH` permite que Aurora MySQL usen `AWSAuthenticationPlugin` para autenticar la cuenta de base de datos (`jane_doe`). La cláusula de `AS 'RDS'` hace referencia al método de autenticación. Asegúrese de que el nombre de usuario de la base de datos especificado sea igual a un recurso de la política de IAM para el acceso a la base de datos de IAM. Para obtener más información, consulte [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). **nota** Si ve el siguiente mensaje, significa que el complemento proporcionado por AWS no está disponible para la y clúster de bases de datos actual. `ERROR 1524 (HY000): Plugin 'AWSAuthenticationPlugin' is not loaded` Para identificar este error, verifique que usa una configuración admitida y que ha habilitado la autenticación de bases de datos de IAM en su clúster de bases de datos. Para obtener más información, consulte [Disponibilidad en regiones y versiones](UsingWithRDS.IAMDBAuth.md#UsingWithRDS.IAMDBAuth.Availability) y [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md). Después de crear una cuenta mediante `AWSAuthenticationPlugin`, puede administrarla de la misma forma que otras cuentas de base de datos. Por ejemplo, puede modificar los privilegios de cuenta con las instrucciones `GRANT` y `REVOKE`, o bien modificar diversos atributos de cuenta con la instrucción `ALTER USER`. El tráfico de la red de la base de datos se cifra mediante SSL/TLS cuando se utiliza IAM. Para permitir las conexiones SSL, modifique la cuenta de usuario con el siguiente comando. ``` ALTER USER 'jane_doe'@'%' REQUIRE SSL; ``` ## Uso de la autenticación de IAM con AuroraPostgreSQL Para usar la autenticación de IAM con Aurora PostgreSQL, conéctese al clúster de base de datos como usuario maestro o como usuario diferente que pueda crear usuarios y conceder privilegios. Tras la conexión, cree usuarios de base de datos y, a continuación, concédales el rol `rds_iam` tal como se muestra en el siguiente ejemplo. ``` CREATE USER db_userx; GRANT rds_iam TO db_userx; ``` Asegúrese de que el nombre de usuario de la base de datos especificado sea igual a un recurso de la política de IAM para el acceso a la base de datos de IAM. Para obtener más información, consulte [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). Debe conceder el rol `rds_iam` para utilizar la autenticación de IAM. También puede utilizar suscripciones anidadas o concesiones indirectas del rol. Tenga en cuenta que un usuario de base de datos de PostgreSQL puede usar una autenticación de IAM o Kerberos, pero no ambas, por lo que este usuario tampoco puede tener el rol `rds_ad`. Esto se aplica también a las membresías anidadas. Para obtener más información, consulte [Paso 7: crear usuarios de PostgreSQL para las entidades principales de Kerberos](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins). # Conexión a al clúster de bases de datos con la autenticación de IAM Con la autenticación de bases de datos de IAM, puede usar un token de autenticación al conectarse a su clúster de bases de datos. Un *token de autenticación* es una cadena de caracteres que usa en lugar de una contraseña. Después de generar un token de autenticación, será válido durante 15 minutos antes de caducar. Si intenta conectarse mediante un token caducado, la solicitud de conexión se deniega. Todos los tokens de autenticación deben ir acompañados de una firma válida, mediante AWS Signature versión 4. (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.*). AWS CLI y un SDK de AWS, como AWS SDK para Java o AWS SDK para Python (Boto3), pueden firmar automáticamente cada token que cree. Puede utilizar un token de autenticación cuando se conecte a Amazon Aurora desde otro servicio de AWS, como AWS Lambda. Al utilizar un token, puede evitar introducir una contraseña en el código. De forma opcional, puede usar un SDK de AWS para crear y firmar mediante programación un token de autenticación. Una vez que tenga un token de autenticación de IAM firmado, podrá conectarse a un clúster de bases de datos de Aurora. A continuación, puede aprender cómo hacer esto mediante una herramienta de línea de comandos o un SDK de AWS, como AWS SDK para Java o AWS SDK para Python (Boto3). Para obtener más información, consulte las siguientes entradas del blog: + [Use IAM authentication to connect with SQL Workbench/J to Aurora MySQL or Amazon RDS for MySQL](https://aws.amazon.com/blogs/database/use-iam-authentication-to-connect-with-sql-workbenchj-to-amazon-aurora-mysql-or-amazon-rds-for-mysql/) + [Using IAM authentication to connect with pgAdmin Amazon Aurora PostgreSQL or Amazon RDS para PostgreSQL (Usar la autenticación de IAM para conectar pgAdmin con Amazon Aurora PostgreSQL o Amazon RDS para PostgreSQL)](https://aws.amazon.com/blogs/database/using-iam-authentication-to-connect-with-pgadmin-amazon-aurora-postgresql-or-amazon-rds-for-postgresql/) **Requisitos previos** A continuación, se muestran requisitos previos para conectarse al clúster de de base de datos mediante la autenticación de IAM: + [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md) + [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md) + [Creación de cuentas de base de datos utilizando autenticación de IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md) **Topics** + [ # Conexión a su clúster de de base de datos mediante la autenticación IAM con los controladores de AWS ](IAMDBAuth.Connecting.Drivers.md) + [ # Conexión a su clúster de bases de datos con autenticación de IAM desde la línea de comandos: AWS CLI y cliente de MySQL ](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.md) + [ # Conexión a su clúster de bases de datos desde la línea de comandos: AWS CLI y psql Client ](UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.PostgreSQL.md) + [ # Conexión al clúster de base de datos mediante la autenticación de IAM y el AWS SDK para .NET ](UsingWithRDS.IAMDBAuth.Connecting.NET.md) + [ # Conexión al clúster de base de datos mediante la autenticación de IAM y el AWS SDK para Go ](UsingWithRDS.IAMDBAuth.Connecting.Go.md) + [ # Conexión al clúster de base de datos mediante la autenticación de IAM y el AWS SDK para Java ](UsingWithRDS.IAMDBAuth.Connecting.Java.md) + [ # Conexión al clúster de base de datos mediante la autenticación de IAM y el AWS SDK para Python (Boto3) ](UsingWithRDS.IAMDBAuth.Connecting.Python.md) # Conexión a su clúster de de base de datos mediante la autenticación IAM con los controladores de AWS El conjunto de controladores de AWS se ha diseñado para permitir tiempos de transición y conmutación por error más rápidos y autenticarse con AWS Secrets Manager, AWS Identity and Access Management (IAM) e identidad federada. Los controladores de AWS se basan en la supervisión del estado del clúster de base de datos y en el conocimiento de la topología del clúster para determinar quién es el nuevo escritor. Este enfoque reduce los tiempos de transición y conmutación por error a segundos de un solo dígito, en comparación con las decenas de segundos de los controladores de código abierto. Para obtener más información sobre los controladores de AWS, consulte el controlador de idioma correspondiente a su clúster de base de datos de [Aurora MySQL](Aurora.Connecting.md#Aurora.Connecting.JDBCDriverMySQL) o [Aurora PostgreSQL](Aurora.Connecting.md#Aurora.Connecting.AuroraPostgreSQL.Utilities). # Conexión a su clúster de bases de datos con autenticación de IAM desde la línea de comandos: AWS CLI y cliente de MySQL Puede conectarse desde la línea de comando a un clúster de bases de datos de Auroracon AWS CLI y la herramienta de línea de comandos de `mysql` como se describe a continuación. **Requisitos previos** A continuación, se muestran requisitos previos para conectarse al clúster de de base de datos mediante la autenticación de IAM: + [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md) + [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md) + [Creación de cuentas de base de datos utilizando autenticación de IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md) **nota** Para obtener información sobre cómo conectarse a la base de datos mediante SQL Workbench/J con la autenticación IAM, consulte la publicación de blog [Use IAM authentication to connect with SQL Workbench/J to Aurora MySQL or Amazon RDS for MySQL](https://aws.amazon.com/blogs/database/use-iam-authentication-to-connect-with-sql-workbenchj-to-amazon-aurora-mysql-or-amazon-rds-for-mysql/). **Topics** + [ ## Generación de un token de autenticación de IAM ](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken) + [ ## Conexión a su clúster de bases de datos ](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect) ## Generación de un token de autenticación de IAM En el siguiente ejemplo se muestra cómo obtener un token de autenticación firmado mediante la AWS CLI. ``` aws rds generate-db-auth-token \ --hostname rdsmysql.123456789012.us-west-2.rds.amazonaws.com \ --port 3306 \ --region us-west-2 \ --username jane_doe ``` En el ejemplo, los parámetros son los siguientes: + `--hostname`: el nombre de host del clúster de bases de datos a los que desea obtener acceso. + `--port`: el número de puerto que se utiliza para conectarse al clúster de bases de datos. + `--region`: la región de AWS en la que se ejecuta el clúster de bases de datos + `--username`: la cuenta de base de datos a la que desea acceder. Los primeros caracteres del token tienen un aspecto similar al siguiente. ``` rdsmysql.123456789012.us-west-2.rds.amazonaws.com:3306/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900... ``` **nota** No puede utilizar un registro DNS personalizado de Route 53 en lugar del punto de conexión del clúster de base de datos para generar el token de autenticación. ## Conexión a su clúster de bases de datos El formato general para conectarse se muestra a continuación. ``` mysql --host=hostName --port=portNumber --ssl-ca=full_path_to_ssl_certificate --enable-cleartext-plugin --user=userName --password=authToken ``` Los parámetros son los siguientes: + `--host`: el nombre de host del clúster de bases de datos a los que desea obtener acceso. + `--port`: el número de puerto que se utiliza para conectarse al clúster de bases de datos. + `--ssl-ca`: la ruta completa al archivo de certificado SSL que contiene la clave pública Para obtener más información, consulte [Conexiones TLS a clústeres de base de datos de Aurora MySQL](AuroraMySQL.Security.md#AuroraMySQL.Security.SSL). Para descargar un certificado SSL, consulte [Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos](UsingWithRDS.SSL.md). + `--enable-cleartext-plugin`: un valor que especifica que `AWSAuthenticationPlugin` debe usarse para esta conexión. Si está utilizando un cliente MariaDB, la opción `--enable-cleartext-plugin` no es necesaria. + `--user`: la cuenta de base de datos a la que desea acceder. + `--password`: un token de autenticación de IAM firmado. El token de autenticación consta de varios cientos de caracteres. Puede ser difícil de tratar en la línea de comando. Una forma de solucionar esto es guardar el token en una variable de entorno y, a continuación, usar esa variable al conectarse. En el siguiente ejemplo se muestra una forma de realizar esta alternativa. En el ejemplo, */sample\$1dir/* es la ruta completa al archivo de certificado SSL que contiene la clave pública. ``` RDSHOST="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com" TOKEN="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 3306 --region us-west-2 --username jane_doe )" mysql --host=$RDSHOST --port=3306 --ssl-ca=/sample_dir/global-bundle.pem --enable-cleartext-plugin --user=jane_doe --password=$TOKEN ``` Al conectarse mediante `AWSAuthenticationPlugin`, la conexión está protegida mediante SSL. Para verificar esto, escriba lo siguiente en el símbolo del sistema `mysql>`. ``` show status like 'Ssl%'; ``` En las siguientes líneas de la salida aparecen más detalles. ``` +---------------+-------------+ | Variable_name | Value | +---------------+-------------+ | ... | ... | Ssl_cipher | AES256-SHA | | ... | ... | Ssl_version | TLSv1.1 | | ... | ... +-----------------------------+ ``` Si desea conectarse a un clúster de base de datos a través de un proxy, consulte [Conexión a una base de datos mediante autenticación de IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam). # Conexión a su clúster de bases de datos desde la línea de comandos: AWS CLI y psql Client Puede conectarse desde la línea de comando a un clúster de bases de datos de Aurora PostgreSQL con AWS CLI y la herramienta de línea de comandos psql como se describe a continuación. **Requisitos previos** A continuación, se muestran requisitos previos para conectarse al clúster de de base de datos mediante la autenticación de IAM: + [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md) + [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md) + [Creación de cuentas de base de datos utilizando autenticación de IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md) **nota** Para obtener información acerca de cómo conectarse a la base de datos mediante pgAdmin con la autenticación IAM, consulte la entrada de blog [Use IAM authentication to connect with pgAdmin to Amazon Aurora PostgreSQL or Amazon RDS for PostgreSQL (Usar la autenticación de IAM para conectarse con pgAdmin a Amazon Aurora PostgreSQL o Amazon RDS for PostgreSQL)](https://aws.amazon.com/blogs/database/using-iam-authentication-to-connect-with-pgadmin-amazon-aurora-postgresql-or-amazon-rds-for-postgresql/). **Topics** + [ ## Generación de un token de autenticación de IAM ](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.AuthToken.PostgreSQL) + [ ## Conexión a un clúster de Aurora PostgreSQL ](#UsingWithRDS.IAMDBAuth.Connecting.AWSCLI.Connect.PostgreSQL) ## Generación de un token de autenticación de IAM El token de autenticación consta de varios cientos de caracteres por que puede ser difícil de tratar en la línea de comando. Una forma de solucionar esto es guardar el token en una variable de entorno y, a continuación, usar esa variable al conectarse. En el siguiente ejemplo se muestra cómo usar la AWS CLI para obtener un token de autenticación firmado mediante el comando `generate-db-auth-token` y almacenarlo en una variable de entorno `PGPASSWORD`. ``` export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com" export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )" ``` En el ejemplo, los parámetros para el comando `generate-db-auth-token` son los siguientes: + `--hostname`: el nombre de host del clúster (punto de enlace del clúster) de base de datos a los que desea obtener acceso. + `--port`: el número de puerto que se utiliza para conectarse al clúster de bases de datos. + `--region`: la región de AWS en la que se ejecuta el clúster de bases de datos + `--username`: la cuenta de base de datos a la que desea acceder. Los primeros caracteres del token generado tienen un aspecto similar al siguiente. ``` mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com:5432/?Action=connect&DBUser=jane_doe&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900... ``` **nota** No puede utilizar un registro DNS personalizado de Route 53 en lugar del punto de conexión del clúster de base de datos para generar el token de autenticación. ## Conexión a un clúster de Aurora PostgreSQL El formato general para usar psql para conectarse se muestra a continuación. ``` psql "host=hostName port=portNumber sslmode=verify-full sslrootcert=full_path_to_ssl_certificate dbname=DBName user=userName password=authToken" ``` Los parámetros son los siguientes: + `host`: el nombre de host del clúster (punto de enlace del clúster) de base de datos a los que desea obtener acceso. + `port`: el número de puerto que se utiliza para conectarse al clúster de bases de datos. + `sslmode`: el modo de SSL que se debe utilizar. Cuando se utiliza `sslmode=verify-full`, la conexión SSL verifica el punto de conexión del clúster de bases de datos con respecto al punto de enlace del certificado SSL. + `sslrootcert`: la ruta completa al archivo de certificado SSL que contiene la clave pública Para obtener más información, consulte [Protección de los datos de Aurora PostgreSQL con SSL/TLS](AuroraPostgreSQL.Security.md#AuroraPostgreSQL.Security.SSL). Para descargar un certificado SSL, consulte [Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos](UsingWithRDS.SSL.md). + `dbname`: la base de datos a la que desea obtener acceso. + `user`: la cuenta de base de datos a la que desea acceder. + `password`: un token de autenticación de IAM firmado. **nota** No puede utilizar un registro DNS personalizado de Route 53 en lugar del punto de conexión del clúster de base de datos para generar el token de autenticación. El siguiente ejemplo muestra el uso de psql para conectarse. En el ejemplo, psql utiliza la variable de entorno `RDSHOST` para el host y la variable de entorno `PGPASSWORD` para el token generado. Además, */sample\$1dir/* es la ruta completa al archivo de certificado SSL que contiene la clave pública. ``` export RDSHOST="mypostgres-cluster.cluster-123456789012.us-west-2.rds.amazonaws.com" export PGPASSWORD="$(aws rds generate-db-auth-token --hostname $RDSHOST --port 5432 --region us-west-2 --username jane_doe )" psql "host=$RDSHOST port=5432 sslmode=verify-full sslrootcert=/sample_dir/global-bundle.pem dbname=DBName user=jane_doe password=$PGPASSWORD" ``` Si desea conectarse a un clúster de base de datos a través de un proxy, consulte [Conexión a una base de datos mediante autenticación de IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam). # Conexión al clúster de base de datos mediante la autenticación de IAM y el AWS SDK para .NET Puede conectarse a un clúster de bases de datos de Aurora MySQL o Aurora PostgreSQL con el AWS SDK para .NET como se describe a continuación. **Requisitos previos** A continuación, se muestran requisitos previos para conectarse al clúster de de base de datos mediante la autenticación de IAM: + [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md) + [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md) + [Creación de cuentas de base de datos utilizando autenticación de IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md) **Ejemplos** En los siguientes ejemplos de código, se muestra cómo se genera un token de autenticación y cómo se utiliza para conectarse a un clúster de bases de datos. Para ejecutar este ejemplo de código, necesita [AWS SDK para .NET](https://aws.amazon.com/sdk-for-net/), que se encuentra en el sitio de AWS. Los paquetes `AWSSDK.CORE` y `AWSSDK.RDS` son necesarios. Para conectarse a un clúster de base de datos, use el conector de base de datos .NET para el motor de base de datos, como MySqlConnector para MariaDB o MySQL, o Npgsql para PostgreSQL. Este código se conecta a un clúster de bases de datos de Aurora MySQL. Modifique los valores de las siguientes variables según sea necesario: + `server`: el punto de enlace del clúster de bases de datos que desea acceder + `user`: la cuenta de base de datos a la que desea acceder. + `database`: la base de datos a la que desea obtener acceso. + `port`: el número de puerto que se utiliza para conectarse al clúster de bases de datos. + `SslMode`: el modo de SSL que se debe utilizar. Cuando se utiliza `SslMode=Required`, la conexión SSL verifica el punto de conexión del clúster de bases de datos con respecto al punto de enlace del certificado SSL. + `SslCa`: la ruta completa al certificado SSL de Amazon Aurora Para descargar un certificado, consulte [Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos](UsingWithRDS.SSL.md). **nota** No puede utilizar un registro DNS personalizado de Route 53 en lugar del punto de conexión del clúster de base de datos para generar el token de autenticación. ``` using System; using System.Data; using MySql.Data; using MySql.Data.MySqlClient; using Amazon; namespace ubuntu { class Program { static void Main(string[] args) { var pwd = Amazon.RDS.Util.RDSAuthTokenGenerator.GenerateAuthToken(RegionEndpoint.USEast1, "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 3306, "jane_doe"); // for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated MySqlConnection conn = new MySqlConnection($"server=mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com;user=jane_doe;database=mydB;port=3306;password={pwd};SslMode=Required;SslCa=full_path_to_ssl_certificate"); conn.Open(); // Define a query MySqlCommand sampleCommand = new MySqlCommand("SHOW DATABASES;", conn); // Execute a query MySqlDataReader mysqlDataRdr = sampleCommand.ExecuteReader(); // Read all rows and output the first column in each row while (mysqlDataRdr.Read()) Console.WriteLine(mysqlDataRdr[0]); mysqlDataRdr.Close(); // Close connection conn.Close(); } } } ``` Este código se conecta a un clúster de bases de datos de Aurora PostgreSQL. Modifique los valores de las siguientes variables según sea necesario: + `Server`: el punto de enlace del clúster de bases de datos que desea acceder + `User ID`: la cuenta de base de datos a la que desea acceder. + `Database`: la base de datos a la que desea obtener acceso. + `Port`: el número de puerto que se utiliza para conectarse al clúster de bases de datos. + `SSL Mode`: el modo de SSL que se debe utilizar. Cuando se utiliza `SSL Mode=Required`, la conexión SSL verifica el punto de conexión del clúster de bases de datos con respecto al punto de enlace del certificado SSL. + `Root Certificate`: la ruta completa al certificado SSL de Amazon Aurora Para descargar un certificado, consulte [Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos](UsingWithRDS.SSL.md). **nota** No puede utilizar un registro DNS personalizado de Route 53 en lugar del punto de conexión del clúster de base de datos para generar el token de autenticación. ``` using System; using Npgsql; using Amazon.RDS.Util; namespace ConsoleApp1 { class Program { static void Main(string[] args) { var pwd = RDSAuthTokenGenerator.GenerateAuthToken("postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com", 5432, "jane_doe"); // for debug only Console.Write("{0}\n", pwd); //this verifies the token is generated NpgsqlConnection conn = new NpgsqlConnection($"Server=postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com;User Id=jane_doe;Password={pwd};Database=mydb;SSL Mode=Require;Root Certificate=full_path_to_ssl_certificate"); conn.Open(); // Define a query NpgsqlCommand cmd = new NpgsqlCommand("select count(*) FROM pg_user", conn); // Execute a query NpgsqlDataReader dr = cmd.ExecuteReader(); // Read all rows and output the first column in each row while (dr.Read()) Console.Write("{0}\n", dr[0]); // Close connection conn.Close(); } } } ``` Si desea conectarse a un clúster de base de datos a través de un proxy, consulte [Conexión a una base de datos mediante autenticación de IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam). # Conexión al clúster de base de datos mediante la autenticación de IAM y el AWS SDK para Go Puede conectarse a un clúster de bases de datos de Aurora MySQL o Aurora PostgreSQL con el AWS SDK para Go como se describe a continuación. **Requisitos previos** A continuación, se muestran requisitos previos para conectarse al clúster de de base de datos mediante la autenticación de IAM: + [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md) + [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md) + [Creación de cuentas de base de datos utilizando autenticación de IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md) **Ejemplos** Para ejecutar estos ejemplos de código, necesita [AWS SDK para Go](https://aws.amazon.com/sdk-for-go/), que se encuentra en el sitio de AWS. Modifique los valores de las siguientes variables según sea necesario: + `dbName`: la base de datos a la que desea obtener acceso. + `dbUser`: la cuenta de base de datos a la que desea acceder. + `dbHost`: el punto de enlace del clúster de bases de datos que desea acceder **nota** No puede utilizar un registro DNS personalizado de Route 53 en lugar del punto de conexión del clúster de base de datos para generar el token de autenticación. + `dbPort`: el número de puerto que se utiliza para conectarse al clúster de bases de datos. + `region`: la región de AWS en la que se ejecuta el clúster de bases de datos Además, debe asegurarse de que las bibliotecas importadas en el código de muestra existen en el sistema. **importante** En los ejemplos de esta sección se utiliza el código siguiente para proporcionar credenciales que tienen acceso a una base de datos desde un entorno local: `creds := credentials.NewEnvCredentials()` Si accede a una base de datos desde un servicio de AWS, como Amazon EC2 o Amazon ECS, puede reemplazar el código por el siguiente código: `sess := session.Must(session.NewSession())` `creds := sess.Config.Credentials` Si realiza este cambio, asegúrese de agregar la siguiente importación: `"github.com/aws/aws-sdk-go/aws/session"` **Topics** + [ ## Conexión mediante la autenticación de IAM y el V2 AWS SDK para Go ](#UsingWithRDS.IAMDBAuth.Connecting.GoV2) + [ ## Conexión mediante la autenticación de IAM y el V1 AWS SDK para Go ](#UsingWithRDS.IAMDBAuth.Connecting.GoV1) ## Conexión mediante la autenticación de IAM y el V2 AWS SDK para Go Se puede conectar a un de instancia de base de datos mediante la autenticación de IAM y el V2AWS SDK para Go. En los siguientes ejemplos de código, se muestra cómo se genera un token de autenticación y cómo se utiliza para conectarse a un clúster de bases de datos. Este código se conecta a un clúster de bases de datos de Aurora MySQL. ``` package main import ( "context" "database/sql" "fmt" "github.com/aws/aws-sdk-go-v2/config" "github.com/aws/aws-sdk-go-v2/feature/rds/auth" _ "github.com/go-sql-driver/mysql" ) func main() { var dbName string = "DatabaseName" var dbUser string = "DatabaseUser" var dbHost string = "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com" var dbPort int = 3306 var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort) var region string = "us-east-1" cfg, err := config.LoadDefaultConfig(context.TODO()) if err != nil { panic("configuration error: " + err.Error()) } authenticationToken, err := auth.BuildAuthToken( context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials) if err != nil { panic("failed to create authentication token: " + err.Error()) } dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true", dbUser, authenticationToken, dbEndpoint, dbName, ) db, err := sql.Open("mysql", dsn) if err != nil { panic(err) } err = db.Ping() if err != nil { panic(err) } } ``` Este código se conecta a un clúster de bases de datos de Aurora PostgreSQL. ``` package main import ( "context" "database/sql" "fmt" "github.com/aws/aws-sdk-go-v2/config" "github.com/aws/aws-sdk-go-v2/feature/rds/auth" _ "github.com/lib/pq" ) func main() { var dbName string = "DatabaseName" var dbUser string = "DatabaseUser" var dbHost string = "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com" var dbPort int = 5432 var dbEndpoint string = fmt.Sprintf("%s:%d", dbHost, dbPort) var region string = "us-east-1" cfg, err := config.LoadDefaultConfig(context.TODO()) if err != nil { panic("configuration error: " + err.Error()) } authenticationToken, err := auth.BuildAuthToken( context.TODO(), dbEndpoint, region, dbUser, cfg.Credentials) if err != nil { panic("failed to create authentication token: " + err.Error()) } dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s", dbHost, dbPort, dbUser, authenticationToken, dbName, ) db, err := sql.Open("postgres", dsn) if err != nil { panic(err) } err = db.Ping() if err != nil { panic(err) } } ``` Si desea conectarse a un clúster de base de datos a través de un proxy, consulte [Conexión a una base de datos mediante autenticación de IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam). ## Conexión mediante la autenticación de IAM y el V1 AWS SDK para Go Conexión a un clúster de bases de datos mediante la autenticación de IAM y el V1 AWS SDK para Go En los siguientes ejemplos de código, se muestra cómo se genera un token de autenticación y cómo se utiliza para conectarse a un clúster de bases de datos. Este código se conecta a un clúster de bases de datos de Aurora MySQL. ``` package main import ( "database/sql" "fmt" "log" "github.com/aws/aws-sdk-go/aws/credentials" "github.com/aws/aws-sdk-go/service/rds/rdsutils" _ "github.com/go-sql-driver/mysql" ) func main() { dbName := "app" dbUser := "jane_doe" dbHost := "mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com" dbPort := 3306 dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort) region := "us-east-1" creds := credentials.NewEnvCredentials() authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds) if err != nil { panic(err) } dsn := fmt.Sprintf("%s:%s@tcp(%s)/%s?tls=true&allowCleartextPasswords=true", dbUser, authToken, dbEndpoint, dbName, ) db, err := sql.Open("mysql", dsn) if err != nil { panic(err) } err = db.Ping() if err != nil { panic(err) } } ``` Este código se conecta a un clúster de bases de datos de Aurora PostgreSQL. ``` package main import ( "database/sql" "fmt" "github.com/aws/aws-sdk-go/aws/credentials" "github.com/aws/aws-sdk-go/service/rds/rdsutils" _ "github.com/lib/pq" ) func main() { dbName := "app" dbUser := "jane_doe" dbHost := "postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com" dbPort := 5432 dbEndpoint := fmt.Sprintf("%s:%d", dbHost, dbPort) region := "us-east-1" creds := credentials.NewEnvCredentials() authToken, err := rdsutils.BuildAuthToken(dbEndpoint, region, dbUser, creds) if err != nil { panic(err) } dsn := fmt.Sprintf("host=%s port=%d user=%s password=%s dbname=%s", dbHost, dbPort, dbUser, authToken, dbName, ) db, err := sql.Open("postgres", dsn) if err != nil { panic(err) } err = db.Ping() if err != nil { panic(err) } } ``` Si desea conectarse a un clúster de base de datos a través de un proxy, consulte [Conexión a una base de datos mediante autenticación de IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam). # Conexión al clúster de base de datos mediante la autenticación de IAM y el AWS SDK para Java Puede conectarse a un clúster de bases de datos de Aurora MySQL o Aurora PostgreSQL con el AWS SDK para Java como se describe a continuación. **Requisitos previos** A continuación, se muestran requisitos previos para conectarse al clúster de de base de datos mediante la autenticación de IAM: + [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md) + [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md) + [Creación de cuentas de base de datos utilizando autenticación de IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md) + [Configurar el SDK de AWS para Java](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/setup-install.html) Para ver ejemplos de cómo usar el SDK para Java 2.x, consulte [Ejemplos de Amazon RDS que utilizan SDK para Java 2.x](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java_rds_code_examples.html). También puede utilizar el contenedor JDBC avanzado de AWS; consulte la [documentación del contenedor JDBC avanzado de AWS](https://github.com/aws/aws-advanced-jdbc-wrapper/blob/main/docs/Documentation.md). **Topics** + [ ## Generación de un token de autenticación de IAM ](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken) + [ ## Creación manual de un token de autenticación de IAM ](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken2) + [ ## Conexión a su clúster de bases de datos ](#UsingWithRDS.IAMDBAuth.Connecting.Java.AuthToken.Connect) ## Generación de un token de autenticación de IAM Si escribe programas mediante AWS SDK para Java, puede obtener un token de autenticación firmado mediante la clase `RdsIamAuthTokenGenerator`. El uso de esta clase requiere que proporcione las credenciales de AWS. Para hacer esto, puede crear una instancia de la clase `DefaultAWSCredentialsProviderChain`. `DefaultAWSCredentialsProviderChain` usa la primera clave de acceso y clave secreta de AWS que encuentra en la [cadena predeterminada de proveedores de credenciales](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default). A fin de obtener más información acerca de las claves de acceso de AWS, consulte [Administración de claves de acceso para usuarios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html). **nota** No puede utilizar un registro DNS personalizado de Route 53 en lugar del punto de conexión del clúster de base de datos para generar el token de autenticación. Tras crear una instancia de `RdsIamAuthTokenGenerator`, puede llamar al método `getAuthToken` para obtener un token firmado. Proporcione la región de AWS el nombre de host, el número de puerto y el nombre de usuario. En el siguiente ejemplo de código se ilustra cómo hacerlo. ``` package com.amazonaws.codesamples; import com.amazonaws.auth.DefaultAWSCredentialsProviderChain; import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest; import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator; public class GenerateRDSAuthToken { public static void main(String[] args) { String region = "us-west-2"; String hostname = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com"; String port = "3306"; String username = "jane_doe"; System.out.println(generateAuthToken(region, hostname, port, username)); } static String generateAuthToken(String region, String hostName, String port, String username) { RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder() .credentials(new DefaultAWSCredentialsProviderChain()) .region(region) .build(); String authToken = generator.getAuthToken( GetIamAuthTokenRequest.builder() .hostname(hostName) .port(Integer.parseInt(port)) .userName(username) .build()); return authToken; } } ``` ## Creación manual de un token de autenticación de IAM En Java, la forma más sencilla de generar un token de autenticación es usar `RdsIamAuthTokenGenerator`. Esta clase crea automáticamente un token de autenticación y, a continuación, lo firma mediante AWS Signature versión 4. 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*. Sin embargo, también puede crear y firmar un token de autenticación manualmente, como se muestra en el siguiente ejemplo de código. ``` package com.amazonaws.codesamples; import com.amazonaws.SdkClientException; import com.amazonaws.auth.DefaultAWSCredentialsProviderChain; import com.amazonaws.auth.SigningAlgorithm; import com.amazonaws.util.BinaryUtils; import org.apache.commons.lang3.StringUtils; import javax.crypto.Mac; import javax.crypto.spec.SecretKeySpec; import java.nio.charset.Charset; import java.security.MessageDigest; import java.text.SimpleDateFormat; import java.util.Date; import java.util.SortedMap; import java.util.TreeMap; import static com.amazonaws.auth.internal.SignerConstants.AWS4_TERMINATOR; import static com.amazonaws.util.StringUtils.UTF8; public class CreateRDSAuthTokenManually { public static String httpMethod = "GET"; public static String action = "connect"; public static String canonicalURIParameter = "/"; public static SortedMap canonicalQueryParameters = new TreeMap(); public static String payload = StringUtils.EMPTY; public static String signedHeader = "host"; public static String algorithm = "AWS4-HMAC-SHA256"; public static String serviceName = "rds-db"; public static String requestWithoutSignature; public static void main(String[] args) throws Exception { String region = "us-west-2"; String instanceName = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com"; String port = "3306"; String username = "jane_doe"; Date now = new Date(); String date = new SimpleDateFormat("yyyyMMdd").format(now); String dateTimeStamp = new SimpleDateFormat("yyyyMMdd'T'HHmmss'Z'").format(now); DefaultAWSCredentialsProviderChain creds = new DefaultAWSCredentialsProviderChain(); String awsAccessKey = creds.getCredentials().getAWSAccessKeyId(); String awsSecretKey = creds.getCredentials().getAWSSecretKey(); String expiryMinutes = "900"; System.out.println("Step 1: Create a canonical request:"); String canonicalString = createCanonicalString(username, awsAccessKey, date, dateTimeStamp, region, expiryMinutes, instanceName, port); System.out.println(canonicalString); System.out.println(); System.out.println("Step 2: Create a string to sign:"); String stringToSign = createStringToSign(dateTimeStamp, canonicalString, awsAccessKey, date, region); System.out.println(stringToSign); System.out.println(); System.out.println("Step 3: Calculate the signature:"); String signature = BinaryUtils.toHex(calculateSignature(stringToSign, newSigningKey(awsSecretKey, date, region, serviceName))); System.out.println(signature); System.out.println(); System.out.println("Step 4: Add the signing info to the request"); System.out.println(appendSignature(signature)); System.out.println(); } //Step 1: Create a canonical request date should be in format YYYYMMDD and dateTime should be in format YYYYMMDDTHHMMSSZ public static String createCanonicalString(String user, String accessKey, String date, String dateTime, String region, String expiryPeriod, String hostName, String port) throws Exception { canonicalQueryParameters.put("Action", action); canonicalQueryParameters.put("DBUser", user); canonicalQueryParameters.put("X-Amz-Algorithm", "AWS4-HMAC-SHA256"); canonicalQueryParameters.put("X-Amz-Credential", accessKey + "%2F" + date + "%2F" + region + "%2F" + serviceName + "%2Faws4_request"); canonicalQueryParameters.put("X-Amz-Date", dateTime); canonicalQueryParameters.put("X-Amz-Expires", expiryPeriod); canonicalQueryParameters.put("X-Amz-SignedHeaders", signedHeader); String canonicalQueryString = ""; while(!canonicalQueryParameters.isEmpty()) { String currentQueryParameter = canonicalQueryParameters.firstKey(); String currentQueryParameterValue = canonicalQueryParameters.remove(currentQueryParameter); canonicalQueryString = canonicalQueryString + currentQueryParameter + "=" + currentQueryParameterValue; if (!currentQueryParameter.equals("X-Amz-SignedHeaders")) { canonicalQueryString += "&"; } } String canonicalHeaders = "host:" + hostName + ":" + port + '\n'; requestWithoutSignature = hostName + ":" + port + "/?" + canonicalQueryString; String hashedPayload = BinaryUtils.toHex(hash(payload)); return httpMethod + '\n' + canonicalURIParameter + '\n' + canonicalQueryString + '\n' + canonicalHeaders + '\n' + signedHeader + '\n' + hashedPayload; } //Step 2: Create a string to sign using sig v4 public static String createStringToSign(String dateTime, String canonicalRequest, String accessKey, String date, String region) throws Exception { String credentialScope = date + "/" + region + "/" + serviceName + "/aws4_request"; return algorithm + '\n' + dateTime + '\n' + credentialScope + '\n' + BinaryUtils.toHex(hash(canonicalRequest)); } //Step 3: Calculate signature /** * Step 3 of the &AWS; Signature version 4 calculation. It involves deriving * the signing key and computing the signature. Refer to * http://docs.aws.amazon * .com/general/latest/gr/sigv4-calculate-signature.html */ public static byte[] calculateSignature(String stringToSign, byte[] signingKey) { return sign(stringToSign.getBytes(Charset.forName("UTF-8")), signingKey, SigningAlgorithm.HmacSHA256); } public static byte[] sign(byte[] data, byte[] key, SigningAlgorithm algorithm) throws SdkClientException { try { Mac mac = algorithm.getMac(); mac.init(new SecretKeySpec(key, algorithm.toString())); return mac.doFinal(data); } catch (Exception e) { throw new SdkClientException( "Unable to calculate a request signature: " + e.getMessage(), e); } } public static byte[] newSigningKey(String secretKey, String dateStamp, String regionName, String serviceName) { byte[] kSecret = ("AWS4" + secretKey).getBytes(Charset.forName("UTF-8")); byte[] kDate = sign(dateStamp, kSecret, SigningAlgorithm.HmacSHA256); byte[] kRegion = sign(regionName, kDate, SigningAlgorithm.HmacSHA256); byte[] kService = sign(serviceName, kRegion, SigningAlgorithm.HmacSHA256); return sign(AWS4_TERMINATOR, kService, SigningAlgorithm.HmacSHA256); } public static byte[] sign(String stringData, byte[] key, SigningAlgorithm algorithm) throws SdkClientException { try { byte[] data = stringData.getBytes(UTF8); return sign(data, key, algorithm); } catch (Exception e) { throw new SdkClientException( "Unable to calculate a request signature: " + e.getMessage(), e); } } //Step 4: append the signature public static String appendSignature(String signature) { return requestWithoutSignature + "&X-Amz-Signature=" + signature; } public static byte[] hash(String s) throws Exception { try { MessageDigest md = MessageDigest.getInstance("SHA-256"); md.update(s.getBytes(UTF8)); return md.digest(); } catch (Exception e) { throw new SdkClientException( "Unable to compute hash while signing request: " + e.getMessage(), e); } } } ``` ## Conexión a su clúster de bases de datos El siguiente ejemplo de código, muestra cómo generar un token de autenticación y, a continuación, usarlo para conectarse a un clúster que ejecuta Aurora MySQL. Para ejecutar este ejemplo de código, necesita [AWS SDK para Java](https://aws.amazon.com/sdk-for-java/), que se encuentra en el sitio de AWS. Además, necesitará lo siguiente: + MySQL Connector/J. Este ejemplo de código se ha probado con `mysql-connector-java-5.1.33-bin.jar`. + Un certificado intermedio para Amazon Aurora que es específico de una región de AWS. (Para obtener más información, consulte [Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos](UsingWithRDS.SSL.md).) En tiempo de ejecución, el cargador de clases busca el certificado en el mismo directorio que este ejemplo de código Java, de modo que el cargador de clases pueda encontrarlo. + Modifique los valores de las siguientes variables según sea necesario: + `RDS_INSTANCE_HOSTNAME`: el nombre de anfitrión del clúster de bases de datos que desea acceder. + `RDS_INSTANCE_PORT`: el número de puerto usado para conectarse al clúster de bases de datos de PostgreSQL. + `REGION_NAME`: la región de AWS en la que se ejecuta el clúster de bases de datos. + `DB_USER`: la cuenta de base de datos a la que desea acceder. + `SSL_CERTIFICATE`: un certificado de SSL para Amazon Aurora que es específico de una región de AWS. Para descargar un certificado para su región de AWS, consulte [Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos](UsingWithRDS.SSL.md). Coloque el certificado SSL en el mismo directorio que este archivo de programa Java, de modo que el cargador de clases pueda encontrar el certificado en tiempo de ejecución. En este ejemplo de código, se obtienen las credenciales de AWS de la [cadena predeterminada de proveedores de credenciales](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default). **nota** Especifique una contraseña para `DEFAULT_KEY_STORE_PASSWORD` que no sea la que se muestra aquí como práctica recomendada de seguridad. ``` package com.amazonaws.samples; import com.amazonaws.services.rds.auth.RdsIamAuthTokenGenerator; import com.amazonaws.services.rds.auth.GetIamAuthTokenRequest; import com.amazonaws.auth.BasicAWSCredentials; import com.amazonaws.auth.DefaultAWSCredentialsProviderChain; import com.amazonaws.auth.AWSStaticCredentialsProvider; import java.io.File; import java.io.FileOutputStream; import java.io.InputStream; import java.security.KeyStore; import java.security.cert.CertificateFactory; import java.security.cert.X509Certificate; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement; import java.util.Properties; import java.net.URL; public class IAMDatabaseAuthenticationTester { //&AWS; Credentials of the IAM user with policy enabling IAM Database Authenticated access to the db by the db user. private static final DefaultAWSCredentialsProviderChain creds = new DefaultAWSCredentialsProviderChain(); private static final String AWS_ACCESS_KEY = creds.getCredentials().getAWSAccessKeyId(); private static final String AWS_SECRET_KEY = creds.getCredentials().getAWSSecretKey(); //Configuration parameters for the generation of the IAM Database Authentication token private static final String RDS_INSTANCE_HOSTNAME = "rdsmysql.123456789012.us-west-2.rds.amazonaws.com"; private static final int RDS_INSTANCE_PORT = 3306; private static final String REGION_NAME = "us-west-2"; private static final String DB_USER = "jane_doe"; private static final String JDBC_URL = "jdbc:mysql://" + RDS_INSTANCE_HOSTNAME + ":" + RDS_INSTANCE_PORT; private static final String SSL_CERTIFICATE = "rds-ca-2019-us-west-2.pem"; private static final String KEY_STORE_TYPE = "JKS"; private static final String KEY_STORE_PROVIDER = "SUN"; private static final String KEY_STORE_FILE_PREFIX = "sys-connect-via-ssl-test-cacerts"; private static final String KEY_STORE_FILE_SUFFIX = ".jks"; private static final String DEFAULT_KEY_STORE_PASSWORD = "changeit"; public static void main(String[] args) throws Exception { //get the connection Connection connection = getDBConnectionUsingIam(); //verify the connection is successful Statement stmt= connection.createStatement(); ResultSet rs=stmt.executeQuery("SELECT 'Success!' FROM DUAL;"); while (rs.next()) { String id = rs.getString(1); System.out.println(id); //Should print "Success!" } //close the connection stmt.close(); connection.close(); clearSslProperties(); } /** * This method returns a connection to the db instance authenticated using IAM Database Authentication * @return * @throws Exception */ private static Connection getDBConnectionUsingIam() throws Exception { setSslProperties(); return DriverManager.getConnection(JDBC_URL, setMySqlConnectionProperties()); } /** * This method sets the mysql connection properties which includes the IAM Database Authentication token * as the password. It also specifies that SSL verification is required. * @return */ private static Properties setMySqlConnectionProperties() { Properties mysqlConnectionProperties = new Properties(); mysqlConnectionProperties.setProperty("verifyServerCertificate","true"); mysqlConnectionProperties.setProperty("useSSL", "true"); mysqlConnectionProperties.setProperty("user",DB_USER); mysqlConnectionProperties.setProperty("password",generateAuthToken()); return mysqlConnectionProperties; } /** * This method generates the IAM Auth Token. * An example IAM Auth Token would look like follows: * btusi123---cmz7kenwo2ye---rds---cn-north-1.amazonaws.com.rproxy.goskope.com.cn:3306/?Action=connect&DBUser=iamtestuser&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20171003T010726Z&X-Amz-SignedHeaders=host&X-Amz-Expires=899&X-Amz-Credential=AKIAPFXHGVDI5RNFO4AQ%2F20171003%2Fcn-north-1%2Frds-db%2Faws4_request&X-Amz-Signature=f9f45ef96c1f770cdad11a53e33ffa4c3730bc03fdee820cfdf1322eed15483b * @return */ private static String generateAuthToken() { BasicAWSCredentials awsCredentials = new BasicAWSCredentials(AWS_ACCESS_KEY, AWS_SECRET_KEY); RdsIamAuthTokenGenerator generator = RdsIamAuthTokenGenerator.builder() .credentials(new AWSStaticCredentialsProvider(awsCredentials)).region(REGION_NAME).build(); return generator.getAuthToken(GetIamAuthTokenRequest.builder() .hostname(RDS_INSTANCE_HOSTNAME).port(RDS_INSTANCE_PORT).userName(DB_USER).build()); } /** * This method sets the SSL properties which specify the key store file, its type and password: * @throws Exception */ private static void setSslProperties() throws Exception { System.setProperty("javax.net.ssl.trustStore", createKeyStoreFile()); System.setProperty("javax.net.ssl.trustStoreType", KEY_STORE_TYPE); System.setProperty("javax.net.ssl.trustStorePassword", DEFAULT_KEY_STORE_PASSWORD); } /** * This method returns the path of the Key Store File needed for the SSL verification during the IAM Database Authentication to * the db instance. * @return * @throws Exception */ private static String createKeyStoreFile() throws Exception { return createKeyStoreFile(createCertificate()).getPath(); } /** * This method generates the SSL certificate * @return * @throws Exception */ private static X509Certificate createCertificate() throws Exception { CertificateFactory certFactory = CertificateFactory.getInstance("X.509"); URL url = new File(SSL_CERTIFICATE).toURI().toURL(); if (url == null) { throw new Exception(); } try (InputStream certInputStream = url.openStream()) { return (X509Certificate) certFactory.generateCertificate(certInputStream); } } /** * This method creates the Key Store File * @param rootX509Certificate - the SSL certificate to be stored in the KeyStore * @return * @throws Exception */ private static File createKeyStoreFile(X509Certificate rootX509Certificate) throws Exception { File keyStoreFile = File.createTempFile(KEY_STORE_FILE_PREFIX, KEY_STORE_FILE_SUFFIX); try (FileOutputStream fos = new FileOutputStream(keyStoreFile.getPath())) { KeyStore ks = KeyStore.getInstance(KEY_STORE_TYPE, KEY_STORE_PROVIDER); ks.load(null); ks.setCertificateEntry("rootCaCertificate", rootX509Certificate); ks.store(fos, DEFAULT_KEY_STORE_PASSWORD.toCharArray()); } return keyStoreFile; } /** * This method clears the SSL properties. * @throws Exception */ private static void clearSslProperties() throws Exception { System.clearProperty("javax.net.ssl.trustStore"); System.clearProperty("javax.net.ssl.trustStoreType"); System.clearProperty("javax.net.ssl.trustStorePassword"); } } ``` Si desea conectarse a un clúster de base de datos a través de un proxy, consulte [Conexión a una base de datos mediante autenticación de IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam). # Conexión al clúster de base de datos mediante la autenticación de IAM y el AWS SDK para Python (Boto3) Puede conectarse a un clúster de bases de datos de Aurora MySQL o Aurora PostgreSQL con el AWS SDK para Python (Boto3) como se describe a continuación. **Requisitos previos** A continuación, se muestran requisitos previos para conectarse al clúster de de base de datos mediante la autenticación de IAM: + [Activación y desactivación de la autenticación de bases de datos de IAM](UsingWithRDS.IAMDBAuth.Enabling.md) + [Creación y uso de una política de IAM para el acceso a bases de datos de IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md) + [Creación de cuentas de base de datos utilizando autenticación de IAM](UsingWithRDS.IAMDBAuth.DBAccounts.md) Además, debe asegurarse de que las bibliotecas importadas en el código de muestra existen en el sistema. **Ejemplos** Los ejemplos de código utilizan perfiles para credenciales compartidas. Para obtener información acerca de la especificación de credenciales, consulte [Credenciales](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/credentials.html) en la documentación de AWS SDK para Python (Boto3). En los siguientes ejemplos de código, se muestra cómo se genera un token de autenticación y cómo se utiliza para conectarse a un clúster de bases de datos. Para ejecutar este ejemplo de código, necesita [AWS SDK para Python (Boto3)](https://aws.amazon.com/sdk-for-python/), que se encuentra en el sitio de AWS. Modifique los valores de las siguientes variables según sea necesario: + `ENDPOINT`: el punto de enlace del clúster de bases de datos que desea acceder + `PORT`: el número de puerto que se utiliza para conectarse al clúster de bases de datos. + `USER`: la cuenta de base de datos a la que desea acceder. + `REGION`: la región de AWS en la que se ejecuta el clúster de bases de datos + `DBNAME`: la base de datos a la que desea obtener acceso. + `SSLCERTIFICATE`: la ruta completa al certificado SSL de Amazon Aurora Para `ssl_ca`, especifique un certificado SSL. Para descargar un certificado SSL, consulte [Uso de SSL/TLS para cifrar una conexión a un clúster de base de datos](UsingWithRDS.SSL.md). **nota** No puede utilizar un registro DNS personalizado de Route 53 en lugar del punto de conexión del clúster de base de datos para generar el token de autenticación. Este código se conecta a un clúster de bases de datos de Aurora MySQL. Antes de ejecutar este código, siga las instrucciones del [índice del paquete de Python](https://pypi.org/project/PyMySQL/) para instalar el controlador PyMySQL. ``` import pymysql import sys import boto3 import os ENDPOINT="mysqlcluster.cluster-123456789012.us-east-1.rds.amazonaws.com" PORT="3306" USER="jane_doe" REGION="us-east-1" DBNAME="mydb" os.environ['LIBMYSQL_ENABLE_CLEARTEXT_PLUGIN'] = '1' #gets the credentials from .aws/credentials session = boto3.Session(profile_name='default') client = session.client('rds') token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION) try: conn = pymysql.connect(auth_plugin_map={'mysql_clear_password':None},host=ENDPOINT, user=USER, password=token, port=PORT, database=DBNAME, ssl_ca='SSLCERTIFICATE', ssl_verify_identity=True, ssl_verify_cert=True) cur = conn.cursor() cur.execute("""SELECT now()""") query_results = cur.fetchall() print(query_results) except Exception as e: print("Database connection failed due to {}".format(e)) ``` Este código se conecta a un clúster de bases de datos de Aurora PostgreSQL. Antes de ejecutar este código, instale `psycopg2` y siga las instrucciones en [Psycopg documentation](https://pypi.org/project/psycopg2/) (Documentación de Psycopg). ``` import psycopg2 import sys import boto3 import os ENDPOINT="postgresmycluster.cluster-123456789012.us-east-1.rds.amazonaws.com" PORT="5432" USER="jane_doe" REGION="us-east-1" DBNAME="mydb" #gets the credentials from .aws/credentials session = boto3.Session(profile_name='RDSCreds') client = session.client('rds') token = client.generate_db_auth_token(DBHostname=ENDPOINT, Port=PORT, DBUsername=USER, Region=REGION) try: conn = psycopg2.connect(host=ENDPOINT, port=PORT, database=DBNAME, user=USER, password=token, sslrootcert="SSLCERTIFICATE") cur = conn.cursor() cur.execute("""SELECT now()""") query_results = cur.fetchall() print(query_results) except Exception as e: print("Database connection failed due to {}".format(e)) ``` Si desea conectarse a un clúster de base de datos a través de un proxy, consulte [Conexión a una base de datos mediante autenticación de IAM](rds-proxy-connecting.md#rds-proxy-connecting-iam). # Solución de problemas de autenticación de bases de datos de IAM A continuación, encontrará ideas para la solución de problemas comunes de autenticación de bases de datos de IAM e información sobre los registros y métricas de CloudWatch para la autenticación de base de datos de IAM. ## Exportación de registros de errores de autenticación de bases de datos de IAM a Registros de CloudWatch Los registros de errores de autenticación de bases de datos de IAM se almacenan en el host de base de datos y puede exportar estos registros a la cuenta de Registros de CloudWatch. Utilice los registros y métodos de solución de esta página para solucionar los problemas de autenticación de bases de datos de IAM. Puede habilitar la exportación de registros a Registros de CloudWatch desde la consola, la AWS CLI y la API de RDS. Para obtener instrucciones sobre la consola, consulte [Publicación de registros de base de datos en registros de Amazon Cloudwatch](USER_LogAccess.Procedural.UploadtoCloudWatch.md). Para exportar los registros de errores de autenticación de bases de datos de IAM a Registros de CloudWatch al crear clúster de bases de datos desde la AWS CLI, utilice el siguiente comando: ``` aws rds create-db-cluster --db-cluster-identifier mydbinstance \ --region us-east-1 \ --engine postgres \ --engine-version 16 \ --master-username master \ --master-user-password password \ --publicly-accessible \ --enable-iam-database-authentication \ --enable-cloudwatch-logs-exports=iam-db-auth-error ``` Para exportar los registros de errores de autenticación de bases de datos de IAM a Registros de CloudWatch al modificar clúster de bases de datos desde la AWS CLI, utilice el siguiente comando: ``` aws rds modify-db-cluster --db-instance-identifier mydbcluster \ --region us-east-1 \ --cloudwatch-logs-export-configuration '{"EnableLogTypes":["iam-db-auth-error"]}' ``` Para verificar si el clúster de bases de datos está exportando los registros de autenticación de base de datos de IAM a Registros de CloudWatch, compruebe si el parámetro `EnabledCloudwatchLogsExports` está establecido en `iam-db-auth-error` en la salida del comando `describe-db-instances`. ``` aws rds describe-db-cluster --region us-east-1 --db-cluster-identifier mydbcluster ... "EnabledCloudwatchLogsExports": [ "iam-db-auth-error" ], ... ``` ## Métricas de CloudWatch de autenticación de bases de datos de IAM Amazon Aurora proporciona métricas casi en tiempo real sobre la autenticación de bases de datos de IAM a la cuenta de Amazon CloudWatch. En la siguiente tabla se enumeran las métricas de autenticación de bases de datos de IAM disponibles mediante CloudWatch: | Métrica | Descripción | | --- | --- | | `IamDbAuthConnectionRequests` | Número total de solicitudes de conexión realizadas con autenticación de bases de datos de IAM. | | `IamDbAuthConnectionSuccess` | Número total de solicitudes de autenticación de bases de datos de IAM correctamente realizadas. | | `IamDbAuthConnectionFailure` | Número total de solicitudes de autenticación de bases de datos de IAM con error. | | `IamDbAuthConnectionFailureInvalidToken` | Número total de solicitudes de autenticación de bases de datos de IAM con error debido a un token no válido. | | `IamDbAuthConnectionFailureInsufficientPermissions` | Número total de solicitudes de autenticación de bases de datos de IAM con error debido a políticas o permisos incorrectos. | | `IamDbAuthConnectionFailureThrottling` | Número total de solicitudes de autenticación de bases de datos de IAM con error debido a la limitación de la autenticación de bases de datos de IAM. | | `IamDbAuthConnectionFailureServerError` | Número total de solicitudes de autenticación de bases de datos de IAM con error debido a un error interno del servidor en la característica de autenticación de bases de datos de IAM. | ## Problemas y soluciones comunes de Es posible que se encuentre con los siguientes problemas al utilizar la autenticación de bases de datos de IAM. Utilice los pasos de corrección de la tabla para resolver los problemas: | Error | Métricas | Causa | Solución | | --- | --- | --- | --- | | `[ERROR] Failed to authenticate the connection request for user db_user because the provided token is malformed or otherwise invalid. (Status Code: 400, Error Code: InvalidToken)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInvalidToken` | El token de autenticación de bases de datos de IAM en la solicitud de conexión no es un token SigV4a válido o no tiene el formato correcto. | Compruebe la estrategia de generación de tokens en la aplicación. En algunos casos, asegúrese de que pasa el token con un formato válido. Si se trunca el token (o se aplica un formato de cadena incorrecto), el token no será válido. | | `[ERROR] Failed to authenticate the connection request for user db_user because the token age is longer than 15 minutes. (Status Code: 400, Error Code:ExpiredToken)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInvalidToken` | El token de autenticación de bases de datos de IAM ha caducado. Los tokens solo son válidos durante 15 minutos. | Compruebe la lógica de almacenamiento en caché de tokens o de reutilización de tokens en la aplicación. No debe reutilizar tokens que tengan más de 15 minutos. | | `[ERROR] Failed to authorize the connection request for user db_user because the IAM policy assumed by the caller 'arn:aws:sts::123456789012:assumed-role/ / ' is not authorized to perform `rds-db:connect` on the DB instance. (Status Code: 403, Error Code:NotAuthorized)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureInsufficientPermissions` | Este error es posible que se deba a las siguientes razones: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.Troubleshooting.html) | Verifique el rol o la política de IAM que está asumiendo en la aplicación. Asegúrese de que asume la misma política para generar el token que para conectarse a la base de datos. | | `[ERROR] Failed to authorize the connection request for user db_user due to IAM DB authentication throttling. (Status Code: 429, Error Code: ThrottlingException)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureThrottling` | Está realizando demasiadas solicitudes de conexión a la base de datos en un corto período de tiempo. El límite de limitación de autenticación de bases de datos de IAM es de 200 conexiones por segundo. | Reduzca la velocidad de establecimiento de nuevas conexiones con la autenticación de IAM. Considere implementar la agrupación de conexiones mediante Proxy de RDS para reutilizar las conexiones establecidas en la aplicación. | | `[ERROR] Failed to authorize the connection request for user db_user due to an internal IAM DB authentication error. (Status Code: 500, Error Code: InternalError)` | `IamDbAuthConnectionFailure` `IamDbAuthConnectionFailureThrottling` | Se ha producido un error interno al autorizar la conexión de la base de datos con la autenticación de bases de datos de IAM. | Póngase en contacto con https://aws.amazon.com/premiumsupport/ para investigar el problema. | # Solución de problemas de identidades y accesos en Amazon Aurora Utilice la información siguiente para diagnosticar y solucionar los problemas comunes que puedan surgir cuando trabaje con Aurora e IAM. **Topics** + [ ## No tengo autorización para realizar una acción en Aurora ](#security_iam_troubleshoot-no-permissions) + [ ## No estoy autorizado a realizar la operación iam:PassRole ](#security_iam_troubleshoot-passrole) + [ ## Quiero permitir que personas ajenas a mi cuenta de AWS accedan a mis recursos de Aurora. ](#security_iam_troubleshoot-cross-account-access) ## No tengo autorización para realizar una acción en Aurora Si la Consola de administración de AWS le indica que no está autorizado para llevar a cabo una acción, debe ponerse en contacto con su gestionador para recibir ayuda. El gestionador es la persona que le proporcionó las credenciales de inicio de sesión. En el siguiente ejemplo, el error se produce cuando el usuario `mateojackson`, intenta utilizar la consola para ver detalles sobre un *widget*, pero no tiene permisos `rds:GetWidget`. ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: rds:GetWidget on resource: my-example-widget ``` En este caso, Mateo pide a su administrador que actualice sus políticas de forma que pueda obtener acceso al recurso `my-example-widget` mediante la acción `rds:GetWidget`. ## No estoy autorizado a realizar la operación iam:PassRole Si recibe un error que indica que no está autorizado para llevar a cabo la acción `iam:PassRole`, debe ponerse en contacto con su administrador para recibir ayuda. El administrador es la persona que le proporcionó las credenciales de inicio de sesión. Pida a la persona que actualice sus políticas de forma que pueda transferir un rol a Aurora. 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 denominado `marymajor` intenta utilizar la consola para realizar una acción en Aurora. Sin embargo, la acción requiere que el servicio cuente con permisos otorgados por 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, Mary pide a su administrador que actualice sus políticas de forma que pueda realizar la acción `iam:PassRole`. ## Quiero permitir que personas ajenas a mi cuenta de AWS accedan a mis recursos de Aurora. 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 admite estas características, consulte [Cómo funciona Amazon Aurora con IAM](security_iam_service-with-iam.md). + Para obtener información acerca de 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 los 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 sobe cómo proporcionar acceso mediante una identidad federada, 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 obtener información sobre la diferencia entre los roles y las políticas basadas en recursos para el acceso entre cuentas, consulte [Cómo los roles de IAM difieren de las políticas basadas en recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_compare-resource-policies.html) en la *Guía del usuario de IAM*. # Registro y supervisión en Amazon Aurora La supervisión es una parte importante del mantenimiento de la fiabilidad, la disponibilidad y el rendimiento de Amazon Aurora y las soluciones de AWS. Debe recopilar datos de supervisión de todas las partes de la solución de AWS para que pueda depurar un error multipunto de una forma más fácil si se produce. AWS proporciona varias herramientas para supervisar los recursos de Amazon Aurora y responder a posibles incidentes: **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. **AWS CloudTrailRegistros de ** CloudTrail proporciona un registro de las acciones que realiza un usuario, un rol o un servicio de AWS en Amazon Aurora. CloudTrail captura todas las llamadas a la API para Amazon Aurora como eventos, incluidas las llamadas procedentes de la consola y de las llamadas de código a operaciones de la API de Amazon RDS. Mediante la información que recopila CloudTrail, puede determinar la solicitud que se envió a Amazon Aurora, la dirección IP desde la que se realizó la solicitud, quién realizó la solicitud, cuándo se realizó y detalles adicionales. Para obtener más información, consulte  [Supervisión de llamadas a la API de Amazon Aurora en AWS CloudTrail](logging-using-cloudtrail.md) . **Enhanced Monitoring (Monitorización mejorada)** Amazon Aurora proporciona métricas en tiempo real para el sistema operativo (SO) en el que se ejecuta el clúster. Puede ver las métricas de el clúster de bases de datos con la consola o usar la salida JSON de la supervisión mejorada de Registros de Amazon CloudWatch en un sistema de supervisión de su elección. Para obtener más información, consulte  [Supervisión de las métricas del sistema operativo con Supervisión mejorada](USER_Monitoring.OS.md) . **Amazon RDS Performance Insights** La información de rendimiento amplía las características de supervisión existentes de Amazon Aurora para ilustrar el rendimiento de la base de datos y le ayuda a analizar cualquier problema que le afecte. Con el panel de Performance Insights, puede visualizar la carga de la base de datos y filtrarla por esperas, instrucciones SQL, hosts o usuarios. Para obtener más información, consulte  [Monitoreo de la carga de base de datos con Performance Insights en Amazon Aurora](USER_PerfInsights.md) . **Registros de la base de datos** Puede ver, descargar y monitorizar los registros de base de datos usando la Consola de administración de AWS, la AWS CLI o la API de RDS. Para obtener más información, consulte  [Supervisión de archivos de registro de Amazon Aurora](USER_LogAccess.md) . ** Recomendaciones de Amazon Aurora** Amazon Aurora proporciona recomendaciones automatizadas de recursos de la base de datos. Estas recomendaciones proporcionan instrucciones de las prácticas recomendadas mediante el análisis de los datos de rendimiento, uso y configuración de el clúster de bases de datos. Para obtener más información, consulte  [Recomendaciones para Amazon Aurora](monitoring-recommendations.md) . ** Notificación de eventos de Amazon Aurora** Amazon Aurora usa Amazon Simple Notification Service (Amazon SNS) para proporcionar una notificación cuando se produce un evento de Amazon Aurora. Estas notificaciones pueden realizarse con cualquier método que admita Amazon SNS para una región de AWS, como un email, un mensaje de texto o una llamada a un punto de enlace HTTP. Para obtener más información, consulte  [Uso de notificaciones de eventos de Amazon RDS](USER_Events.md) . **AWS Trusted Advisor** Trusted Advisor aprovecha las prácticas recomendadas aprendidas al atender a cientos de miles de clientes de AWS. Trusted Advisor inspecciona su entorno de AWS y realiza recomendaciones cuando surge la oportunidad de ahorrar dinero, mejorar el rendimiento y la disponibilidad del sistema o ayudar a cerrar deficiencias de seguridad. Todos los clientes de AWS tienen acceso a cinco comprobaciones de Trusted Advisor. Los clientes con un plan de soporte Business o Enterprise pueden ver todas las comprobaciones de Trusted Advisor. Trusted Advisor cuenta con las siguientes comprobaciones relacionadas con Amazon Aurora: + Instancias de bases de datos inactivas de Amazon Aurora + Riesgo de acceso de grupos de seguridad de Amazon Aurora + Copias de seguridad de Amazon Aurora + Multi-AZ de Amazon Aurora + Accesibilidad de instancias de base de datos de Aurora Para obtener más información acerca de estas comprobaciones, consulte [Prácticas recomendadas de Trusted Advisor (verificaciones)](https://aws.amazon.com/premiumsupport/trustedadvisor/best-practices/). **Secuencias de actividades de la base de datos** Las secuencias de actividades de la base de datos pueden proteger su bases de datos contra las amenazas internas, mediante el control del acceso de los DBA a las secuencias de actividades de la base de datos. Así, los DBA que administran la base de datos no tienen acceso a la recopilación, la transmisión, el almacenamiento y el procesamiento posterior de la secuencia de actividades de la base de datos. Las secuencias de actividad de la base de datos puede proporcionar medidas de seguridad que protejan su base de datos y cumplir los requisitos normativos y de cumplimiento. Para obtener más información, consulte[Supervisión de Amazon Aurora con flujos de actividad de la base de datos](DBActivityStreams.md) . Para obtener más información acerca de la supervisión de Aurora, consulte [Supervisión de métricas en un clúster de Amazon Aurora](MonitoringAurora.md). # Validación de la conformidad en Amazon Aurora Auditores externos evalúan la seguridad y la conformidad de Amazon Aurora como parte de varios programas de conformidad de AWS. Estos incluyen SOC, PCI, FedRAMP, HIPAA y otros. Para obtener una lista de AWS servicios en el ámbito de programas de cumplimiento específicos, consulte los [AWS servicios en ámbito por programa de cumplimiento](https://aws.amazon.com/compliance/services-in-scope/). Para obtener información general, consulte [Programas de conformidad de AWS](https://aws.amazon.com/compliance/programs/). Se 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 cumplimiento al utilizar Amazon Aurora está determinada por la confidencialidad de los datos, los objetivos de cumplimiento de la organización, y las leyes y regulaciones aplicables. AWS proporciona los siguientes recursos para ayudar con el cumplimiento de normas: + [Guías de inicio rápido de seguridad y conformidad](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance): estas guías de implementación tratan consideraciones sobre arquitectura y ofrecen pasos para implementar los entornos de referencia centrados en la seguridad y la conformidad en AWS. + [Architecting for HIPAA Security and Compliance on Amazon Web Services](https://docs.aws.amazon.com/pdfs/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.pdf) (Arquitectura para la seguridad y el cumplimiento de la HIPAA en Amazon Web Services): en este documento técnico, se describe cómo las empresas pueden utilizar AWS para crear aplicaciones que cumplan los requisitos de HIPAA. + [Recursos de conformidad de AWS](https://aws.amazon.com/compliance/resources/): este conjunto de manuales y guías podría aplicarse a su sector y ubicación. + [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html): este servicio de AWS evalúa en qué medida las configuraciones de los recursos cumplen las prácticas internas, las directrices del sector y la normativa. + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html): este Servicio de AWS proporciona una visión completa de su estado de seguridad en AWS. Security Hub CSPM utiliza controles de seguridad para evaluar sus recursos de AWS y comprobar su cumplimiento con los estándares y las prácticas recomendadas del sector de la seguridad. Para obtener una lista de los servicios y controles compatibles, consulte la [Referencia de controles de Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html). # Resiliencia en Amazon Aurora La infraestructura global de AWS se compone de regiones y zonas de disponibilidad de AWS. AWS Las regiones 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 zonas de disponibilidad sin interrupciones. Las zonas de disponibilidad tienen una mayor disponibilidad, tolerancia a errores y escalabilidad que las infraestructuras tradicionales de centros de datos únicos o múltiples. Para obtener más información sobre las zonas de disponibilidad y las regiones de AWS, consulte [Infraestructura global de AWS](https://aws.amazon.com/about-aws/global-infrastructure/). Además de la infraestructura global de AWS, Aurora ofrece características que lo ayudan con sus necesidades de resiliencia y copia de seguridad de los datos. ## Copia de seguridad y restauración Aurora crea copias de seguridad del volumen de clúster automáticamente y retiene los datos de restauración durante la duración del *periodo de retención de copia de seguridad*. Las copias de seguridad de Aurora son continuas y progresivas para que se pueda restaurar con rapidez a cualquier punto durante el periodo de retención de copia de seguridad. No se produce ningún impacto en el desempeño ni ninguna interrupción del servicio de base de datos durante la escritura de los datos de copia de seguridad. Puede especificar un periodo de retención de copia de seguridad de 1 a 35 días cuando cree o modifique un clúster de bases de datos. Si desea conservar una copia de seguridad más allá del periodo de retención de copia de seguridad, también puede crear un snapshot de los datos del volumen de clúster. Aurora retiene los datos de restauración progresiva durante todo el periodo de retención de copia de seguridad. Por tanto, solo tiene que crear una instantánea de los datos que desee conservar después del periodo de retención de copia de seguridad. Puede crear un nuevo clúster de bases de datos a partir de la instantánea. Puede recuperar sus datos creando un nuevo clúster de bases de datos Aurora a partir de los datos de copias de seguridad conservados por Aurora; o de una instantánea de clúster de bases de datos que haya guardado. Puede crear rápidamente una nueva copia del clúster de bases de datos a partir de los datos de la copia de seguridad de cualquier momento dado durante el periodo de retención de copia de seguridad. La naturaleza continua e incremental de las copias de seguridad de Aurora durante el periodo de retención de copia de seguridad implica que no es necesario realizar instantáneas de los datos con demasiada frecuencia para mejorar los tiempos de restauración. Para obtener más información, consulte [Copias de seguridad y restauración de un clúster de base de datos de Amazon Aurora](BackupRestoreAurora.md). ## Replicación Las réplicas de Aurora son puntos de enlace independientes de un clúster de bases de datos Aurora que se utilizan preferentemente para ajustar la escala de las operaciones de lectura e incrementar la disponibilidad. Se puede distribuir un máximo de 15 réplicas de Aurora entre las distintas zonas de disponibilidad que abarca un clúster de bases de datos dentro de una región de AWS. El volumen del clúster de bases de datos consta de varias copias de los datos del clúster de bases de datos. No obstante, los datos del volumen del clúster se representan como un único volumen lógico para la instancia de base de datos principal y para las réplicas de Aurora del clúster de bases de datos. Si la instancia principal da error, una réplica de Aurora se convierte en la instancia de base de datos principal. Aurora también admite opciones de replicación que son específicas de Aurora MySQL y Aurora PostgreSQL. Para obtener más información, consulte [Replicación con Amazon Aurora](Aurora.Replication.md). ## Conmutación por error Aurora almacena copias de los datos en un clúster de bases de datos en varias zonas de disponibilidad en una única región de AWS. Este almacenamiento se produce independientemente de si las instancias de base de datos en el clúster de bases de datos abarca varias zonas de disponibilidad. Al crear réplicas de Aurora entre zonas de disponibilidad, Aurora las aprovisiona automáticamente y las mantiene de forma síncrona. La instancia de base de datos principal se replica de forma síncrona en distintas zonas de disponibilidad en réplicas de Aurora para proporcionar redundancia de datos, eliminar las congelaciones de E/S y minimizar los picos de latencia durante las copias de seguridad del sistema. Ejecutar un clúster de bases de datos con alta disponibilidad puede mejorar la disponibilidad durante el mantenimiento de sistema planificado y ayuda a proteger las bases de datos contra los errores y las interrupciones de las zonas de disponibilidad. Para obtener más información, consulte [Alta disponibilidad para Amazon Aurora](Concepts.AuroraHighAvailability.md). # Seguridad de la infraestructura en Amazon Aurora Como se trata de un servicio administrado, Amazon Relational Database Service está protegido por la seguridad de red global de AWS. Para obtener información sobre los servicios de seguridad de AWS y sobre cómo AWS protege la infraestructura, consulte [Seguridad en la nube de AWS](https://aws.amazon.com/security/). Para diseñar su entorno de AWS siguiendo las prácticas recomendadas de seguridad de infraestructura, consulte [Protección de la infraestructura](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html) en *Portal de seguridad de AWS Well‐Architected Framework*. Puede utilizar llamadas a la API publicadas en AWS para acceder a Amazon RDS a través de la red. 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. Además, Aurora ofrece características para ayudar a admitir la seguridad de la infraestructura. ## Grupos de seguridad Los grupos de seguridad controlan el acceso del tráfico entrante y saliente a un clúster de base de datos. De forma predeterminada, el acceso de red está deshabilitado para un clúster de base de datos. Puede especificar reglas en un grupo de seguridad que permitan el acceso desde un rango de direcciones IP, un puerto o un grupo de seguridad. Una vez configuradas las reglas de entrada, se aplican las mismas reglas a todos los clústeres de base de datos que estén asociadas a ese grupo de seguridad. Para obtener más información, consulte [Control de acceso con grupos de seguridad](Overview.RDSSecurityGroups.md). ## Public accessibility (Accesibilidad pública) Cuando lance una instancia de base de datos dentro de una nube privada virtual (VPC, por sus siglas en inglés) basada en el servicio de Amazon VPC, podrá activar o desactivar la accesibilidad pública para esa instancia de base de datos. Para designar si la instancia de base de datos que se crea tiene un nombre de DNS que se resuelve en una dirección IP pública, utilice el parámetro *Public accessibility* (Accesibilidad pública). Con este parámetro podrá especificar si hay acceso público a la instancia de base de datos. Es posible modificar una instancia de base de datos para activar o desactivar la accesibilidad pública modificando el parámetro *Public accessibility (Accesibilidad pública)*. Para obtener más información, consulte [Cómo ocultar un clúster de base de datos en una VPC desde Internet.](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.Hiding). **nota** Si la instancia de base de datos se encuentra en una VPC pero no es accesible públicamente, también puede usar una conexión AWS Site-to-Site VPN o una conexión de Direct Connect para acceder a ella desde una red privada. Para obtener más información, consulte [Privacidad del tráfico entre redes](inter-network-traffic-privacy.md). # La API de Amazon RDS y los puntos de enlace de la VPC de tipo interfaz (AWS PrivateLink) Puede establecer una conexión privada entre los puntos de enlace de la VPC y la API de Amazon RDS mediante la creación de un *punto de enlace de la VPC de tipo interfaz*. Puntos de enlace de tipo interfaz con tecnología de [AWS PrivateLink](https://aws.amazon.com/privatelink). AWS PrivateLink permite acceder de forma privada a las operaciones de la API de Amazon RDS sin una puerta de enlace de Internet, un dispositivo NAT, una conexión de VPN o una conexión de Direct Connect. Las instancias de bases de datos de su VPC no necesitan direcciones IP públicas para comunicarse con los puntos de conexión de la API de Amazon RDS para lanzar, modificar o terminar instancias de base de datos y clústeres de base de datos. Las instancias de bases de datos tampoco necesitan direcciones IP públicas para utilizar ninguna de las operaciones de la API de RDS disponibles. El tráfico entre la VPC y Amazon RDS no sale de la red de Amazon. Cada punto de enlace de la interfaz está representado por una o más interfaces de red elásticas en las subredes. Para obtener más información sobre las interfaces de red elásticas, consulte [Interfaces de red elásticas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) en la *Guía del usuario de Amazon EC2.* Para obtener más información sobre puntos de enlace de la VPC, consulte [Puntos de enlace de la VPC de tipo interfaz (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) en la *Guía del usuario de Amazon VPC*. Para obtener información sobre las operaciones de la API de RDS, consulte la [referencia de la API de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/). No necesita un punto de conexión de VPC de la interfaz para conectarse con un clúster de base de datos. Para obtener más información, consulte [Escenarios de acceso a un clúster de base de datos en una VPC](USER_VPC.Scenarios.md). ## Consideraciones para los puntos de enlace de VPC Antes de configurar un punto de enlace de la VPC de tipo interfaz para los puntos de enlace de la API de Amazon RDS, asegúrese de revisar [Propiedades y limitaciones de puntos de enlace de interfaz](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-interface-limitations) en la *Guía del usuario de Amazon VPC*. Todas las operaciones de la API de RDS relevantes para la administración de los recursos de Amazon Aurora están disponibles desde la VPC mediante el uso de AWS PrivateLink. Las políticas de puntos de enlace de VPC son compatibles con los puntos de enlace de API de RDS. De forma predeterminada, se permite el acceso completo a las operaciones de API de RDS a través del punto de enlace. Para obtener más información, consulte [Control del acceso a los servicios con puntos de enlace de la VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) en la *guía del usuario de Amazon VPC*. ## Disponibilidad La API de Amazon RDS actualmente admite puntos de enlace de la VPC en las siguientes regiones de AWS: + US East (Ohio) + Este de EE. UU. (Norte de Virginia) + Oeste de EE. UU. (Norte de California) + Oeste de EE. UU. (Oregón) + África (Ciudad del Cabo) + Asia-Pacífico (Hong Kong) + Asia-Pacífico (Mumbai) + Asia-Pacífico (Nueva Zelanda) + Asia-Pacífico (Osaka) + Asia-Pacífico (Seúl) + Asia-Pacífico (Singapur) + Asia-Pacífico (Sídney) + Asia-Pacífico (Taipéi) + Asia-Pacífico (Tailandia) + Asia-Pacífico (Tokio) + Canadá (centro) + Oeste de Canadá (Calgary) + China (Pekín) + China (Ningxia) + Europa (Fráncfort) + Europa (Zúrich) + Europa (Irlanda) + Europa (Londres) + Europa (París) + Europa (Estocolmo) + Europa (Milán) + Israel (Tel Aviv) + México (centro) + Medio Oriente (Baréin) + América del Sur (São Paulo) + AWS GovCloud (Este de EE. UU.) + AWS GovCloud (EE. UU. Oeste) ## Creación de un punto de enlace de la VPC de interfaz para Amazon RDS API Puede crear un punto de enlace de la VPC para la API de Amazon RDS mediante la consola de Amazon VPC o AWS Command Line Interface (AWS CLI). Para obtener más información, consulte [Creación de un punto de enlace de interfaz](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#create-interface-endpoint) en la *Guía del usuario de Amazon VPC*. Cree un punto de enlace de la VPC para Amazon RDS API mediante el uso del nombre del servicio `com.amazonaws.region.rds`. Salvo en las regiones de AWS en China, si habilita un DNS privado para el punto de enlace, podrá realizar solicitudes de la API a Amazon RDS con el punto de enlace de la VPC mediante el nombre de DNS predeterminado de la región de AWS, por ejemplo `rds.us-east-1.amazonaws.com`. En las regiones de China (Pekín) y China (Ningxia) de AWS, puede realizar solicitudes de la API con el punto de enlace de la VPC mediante `rds-api---cn-north-1.amazonaws.com.rproxy.goskope.com.cn` y `rds-api---cn-northwest-1.amazonaws.com.rproxy.goskope.com.cn`, respectivamente. Para obtener más información, consulte [Acceso a un servicio a través de un punto de enlace de interfaz](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) en la *Guía del usuario de Amazon VPC*. ## Creación de una política de punto de enlace de la VPC para la Amazon RDS API Puede asociar una política de punto de enlace con el punto de enlace de la VPC que controla el acceso a la Amazon RDS API. La política especifica la siguiente información: + La entidad principal que puede realizar acciones. + Las acciones que se pueden realizar. + Los recursos en los que se pueden llevar a cabo las acciones. Para obtener más información, consulte [Control del acceso a los servicios con puntos de enlace de la VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) en la *guía del usuario de Amazon VPC*. **Ejemplo: política de punto de enlace de la VPC para acciones de la Amazon RDS API** A continuación, se muestra un ejemplo de una política de punto de enlace para la Amazon RDS API. Cuando se asocia a un punto de enlace, esta política concede acceso a las acciones de la Amazon RDS API enumeradas para todos las entidades principales de todos los recursos. ``` { "Statement":[ { "Principal":"*", "Effect":"Allow", "Action":[ "rds:CreateDBInstance", "rds:ModifyDBInstance", "rds:CreateDBSnapshot" ], "Resource":"*" } ] } ``` **Ejemplo: política de punto de enlace de la VPC que deniega todo el acceso desde una cuenta de AWS especificada** La siguiente política de punto de conexión de VPC deniega a la cuenta de AWS `123456789012` todo el acceso a los recursos mediante el punto de conexión. La política permite todas las acciones de otras cuentas. ``` { "Statement": [ { "Action": "*", "Effect": "Allow", "Resource": "*", "Principal": "*" }, { "Action": "*", "Effect": "Deny", "Resource": "*", "Principal": { "AWS": [ "123456789012" ] } } ] } ``` # Prácticas recomendadas de seguridad para Amazon Aurora Utilice cuentas de AWS Identity and Access Management (IAM) para controlar el acceso a las operaciones de la API de Amazon RDS, especialmente operaciones que crean, modifican o eliminan recursos de Amazon Aurora. Dichos recursos incluyen clústeres de base de datos, grupos de seguridad y grupos de parámetros. Utilice también IAM para controlar acciones que realizan acciones administrativas comunes como copias de seguridad y restauración de clústeres de base de datos. + Cree un usuario individual para cada persona que administre recursos de Amazon Aurora, incluido usted mismo. No utilice las credenciales raíz de AWS para administrar los recursos de Amazon Aurora. + Asigne a cada usuario el conjunto mínimo de permisos requerido para realizar sus tareas. + Use los grupos de IAM para administrar con eficacia los permisos para varios usuarios. + Rote con regularidad sus credenciales de IAM. + Configure AWS Secrets Manager para rotar automáticamente los secretos para Amazon Aurora. Para obtener más información, consulte [Rotación de sus secretos de AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) en la *guía del usuario de AWS Secrets Manager*. También puede recuperar mediante programación las credenciales desde AWS Secrets Manager. Para obtener más información, consulte [Recuperar el valor secreto](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_retrieve-secret.html) en la *guía del usuario de AWS Secrets Manager*. Para obtener más información acerca de la seguridad de Amazon Aurora, consulte [Seguridad en Amazon Aurora](UsingWithRDS.md). Para obtener más información acerca de IAM, consulte [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/Welcome.html). Para obtener información acerca de las prácticas recomendadas de IAM, consulte [Prácticas recomendadas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html). AWS Security Hub CSPM utiliza controles de seguridad para evaluar las configuraciones de los recursos y los estándares de seguridad para ayudarlo a cumplir varios marcos de conformidad. Para obtener más información sobre el uso de Security Hub CSPM para evaluar los recursos de RDS, consulte [Controles de Amazon Relational Database Service](https://docs.aws.amazon.com/securityhub/latest/userguide/rds-controls.html) en la Guía del usuario de AWS Security Hub. Puede supervisar el uso de RDS en relación con las prácticas recomendadas de seguridad con Security Hub CSPM. Para obtener más información, consulte [¿Qué es AWS Security Hub CSPM?](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html). Utilice la Consola de administración de AWS, la AWS CLI o la API de RDS para cambiar la contraseña para el usuario maestro. Si usa otra herramienta, como un cliente de SQL, para cambiar la contraseña del usuario maestro, podría provocar involuntariamente la revocación de privilegios para el usuario. Amazon GuardDuty es un servicio de monitorización de la seguridad continuo que analiza y procesa una variedad de orígenes de datos, incluida la actividad de inicio de sesión de Amazon RDS. Utiliza fuentes de información de amenazas y machine learning para identificar la actividad inesperada y potencialmente no autorizada, comportamientos sospechosos de inicio de sesión, así como la actividad malintencionada en su entorno de AWS. Cuando la protección de RDS de Amazon GuardDuty detecta un intento de inicio de sesión sospechoso o anómalo que implica una amenaza para su base de datos, GuardDuty genera un nuevo resultado con detalles de la base de datos que está potencialmente afectada. Para obtener más información, consulte  [Supervisión de amenazas con Amazon GuardDuty RDS Protectionpara Amazon Aurora](guard-duty-rds-protection.md) . # Control de acceso con grupos de seguridad Los grupos de seguridad de VPC controlan el acceso del tráfico entrante y saliente de un clúster de base de datos. De forma predeterminada, el acceso de red está desactivado para un clúster de base de datos. Puede especificar reglas en un grupo de seguridad que permitan el acceso desde un rango de direcciones IP, un puerto o un grupo de seguridad. Una vez configuradas las reglas de entrada, se aplican las mismas reglas a todos los clústeres de base de datos que estén asociadas a ese grupo de seguridad. Puede especificar hasta 20 reglas en un grupo de seguridad. ## Información general de los grupos de seguridad de VPC Cada regla de grupo de seguridad de VPC permite a un origen específico acceder a un clúster de base de datos de una VPC asociada a ese grupo de seguridad de VPC. El origen puede ser un rango de direcciones (por ejemplo, 203.0.113.0/24), u otro grupo de seguridad de VPC. Cuando se especifica un grupo de seguridad de VPC como origen, se permite el tráfico entrante procedente de todas las instancias, normalmente servidores de aplicaciones, que utilizan el grupo de seguridad de VPC. Los grupos de seguridad de VPC pueden tener reglas que rijan el tráfico entrante y saliente. Sin embargo, las reglas de tráfico saliente normalmente no se aplican a clústeres de bases de datos. Las reglas de tráfico saliente solo se aplican si el clúster de base de datos actúa como cliente. Debe utilizar la [API de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Welcome.html) o la opción **Security Group (Grupo de seguridad)** de la consola de VPC para crear grupos de seguridad de VPC. Cuando cree reglas para el grupo de seguridad de la VPC que permitan el acceso a los clústeres de la VPC, debe especificar un puerto para cada rango de direcciones a las que la regla permite el acceso. Por ejemplo, si desea habilitar el acceso Secure Shell (SSH) a las instancias de la VPC, puede crear una regla que permita el acceso al puerto TCP 22 para el rango de direcciones especificado. Puede configurar varios grupos de seguridad de VPC que permitan el acceso a puertos distintos para las distintas instancias de la VPC. Por ejemplo, puede crear un grupo de seguridad de VPC que permita el acceso al puerto TCP 80 para los servidores web de la VPC. A continuación, puede crear otro grupo de seguridad de la VPC que permita el acceso al puerto TCP 3306 para las instancias de base de datos de Aurora MySQL en la VPC. **nota** En un clúster de bases de datos de Aurora, el grupo de seguridad de VPC asociado al clúster de bases de datos también se asocia a todas las instancias de base de datos en el clúster de bases de datos. Si cambia el grupo de seguridad de VPC para el clúster de bases de datos o para la instancia de base de datos, el cambio se aplica automáticamente a todas las instancias de base de datos en el clúster de bases de datos. Para obtener más información sobre los grupos de seguridad de VPC, consulte [Grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) en la *Guía del usuario de Amazon Virtual Private Cloud*. **nota** Si el clúster de la base de datos se encuentra en una VPC pero no es accesible públicamente, también puede usar una conexión AWS Site-to-Site VPN o una conexión de Direct Connect para acceder desde una red privada. Para obtener más información, consulte  [Privacidad del tráfico entre redes](inter-network-traffic-privacy.md) . ## Escenario de grupos de seguridad Un uso común de clúster de base de datos en una VPC es compartir datos con un servidor de aplicaciones que se ejecuta en una instancia de Amazon EC2 de la misma VPC, al que obtiene acceso desde una aplicación cliente situada fuera de la VPC. Para este escenario, se utilizan las páginas de RDS y VPC de la Consola de administración de AWS o las operaciones de la API de RDS y EC2 para crear las instancias y los grupos de seguridad necesarios: 1. Cree un grupo de seguridad de VPC (por ejemplo, `sg-0123ec2example`) y defina reglas de entrada que utilicen las direcciones IP de la aplicación cliente como origen. Este grupo de seguridad permite que la aplicación cliente se conecte a las instancias EC2 de una VPC que utilice este grupo de seguridad. 1. Cree una instancia EC2 para la aplicación y añada la instancia EC2 al grupo de seguridad de VPC (`sg-0123ec2example`) que creó en el paso anterior. 1. Cree un segundo grupo de seguridad de VPC (por ejemplo, `sg-6789rdsexample`) y cree una regla nueva especificando el grupo de seguridad de VPC que creó en el paso 1 (`sg-0123ec2example`) como origen. 1. Cree un clúster nuevo de base de datos y agregue el clúster de base de datos al grupo de seguridad de la VPC (`sg-6789rdsexample`) que creó en el paso anterior. Cuando cree el clúster de base de datos, utilice el mismo número de puerto que especificó para la regla de grupo de seguridad de VPC (`sg-6789rdsexample`) que creó en el paso 3. En el siguiente diagrama se muestra este escenario. ![\[Clúster de base de datos e instancia EC2 en una VPC\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png) Para obtener instrucciones detalladas acerca de la configuración de una VPC para este escenario, consulte [Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (solo IPv4)](CHAP_Tutorials.WebServerDB.CreateVPC.md). Para obtener más información acerca del uso de una VPC, consulte [VPC de Amazon y Amazon Aurora](USER_VPC.md). ## Creación de un grupo de seguridad de VPC Puede crear un grupo de seguridad de VPC para una instancia de base de datos mediante la consola de VPC. Para obtener información sobre la creación de un grupo de seguridad, consulte [Proporcionar acceso al clúster de base de datos en la VPC mediante la creación de un grupo de seguridad](CHAP_SettingUp_Aurora.md#CHAP_SettingUp_Aurora.SecurityGroup) y [Grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) en la *Guía del usuario de Amazon Virtual Private Cloud*. ## Asociación de un grupo de seguridad con un clúster de bases de datos Puede asociar un grupo de seguridad con un clúster de bases de datos mediante la opción **Modificar el clúster** de la consola de RDS, la API de Amazon RDS `ModifyDBCluster` o el comando `modify-db-cluster` de AWS CLI. El siguiente ejemplo de la CLI asocia un grupo de VPC específico y elimina los grupos de seguridad de base de datos del clúster de base de datos. ``` aws rds modify-db-cluster --db-cluster-identifier dbName --vpc-security-group-ids sg-ID ``` Para obtener información acerca de la modificación de un clúster de base de datos, consulte [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md). # Privilegios de la cuenta de usuario maestro Cuando se crea un clúster nuevo de base de datos, el usuario maestro predeterminado que se utiliza obtiene determinados privilegios para ese clúster de bases de datos. No se puede cambiar el nombre de usuario maestro después de crear el clúster de base de datos. **importante** Le recomendamos encarecidamente que no utilice el usuario maestro directamente en sus aplicaciones. En lugar de ello, es mejor ceñirse a la práctica recomendada de utilizar un usuario de base de datos creado con los privilegios mínimos necesarios para su aplicación. **nota** Si elimina los permisos para el usuario maestro de forma accidental, puede restaurarlos modificando el clúster de base de datos y estableciendo una nueva contraseña para el usuario maestro. Para obtener más información acerca de la modificación de un clúster de base de datos, consulte [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md) . En la siguiente tabla se muestran los privilegios y los roles de base de datos que obtiene el usuario maestro para cada uno de los motores de bases de datos. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html) # Uso de roles vinculados a servicios de Amazon Aurora Amazon Aurora utiliza [roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) 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 a Amazon Aurora. Los roles vinculados a servicios están predefinidos por Amazon Aurora e incluyen todos los permisos que el servicio requiere para llamar a otros servicios de AWS en su nombre. Un rol vinculado a un servicio simplifica el uso de Amazon Aurora porque ya no tendrá que agregar manualmente los permisos necesarios. Amazon Aurora define los permisos de sus roles vinculados a servicios y, a menos que esté definido de otra manera, solo Amazon Aurora puede asumir sus roles. Los permisos definidos incluyen las políticas de confianza y de permisos, y que la política de permisos no se pueda asociar a ninguna otra entidad de IAM. Las funciones se pueden eliminar únicamente después de eliminar primero sus recursos relacionados. De esta forma, se protegen los recursos de Amazon Aurora, ya que se evita que se puedan eliminar accidentalmente permisos de acceso a los recursos. Para obtener información sobre otros servicios que admiten roles vinculados al servicio, 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**. Seleccione una opción **Sí** con un enlace para ver la documentación acerca del rol vinculado al servicio en cuestión. ## Permisos de roles vinculados a servicios de Amazon Aurora Amazon Aurora utiliza el rol vinculado al servicio denominado AWSServiceRoleForRDS para permitir que Amazon RDS llame a servicios de AWS en nombre de sus clústeres de base de datos. El rol vinculado al servicio AWSServiceRoleForRDS confía en que los siguientes servicios asuman el rol: + `rds.amazonaws.com` Este rol vinculado al servicio tiene una política de permisos adjunta llamada `AmazonRDSServiceRolePolicy`, que le otorga permisos para operar en su cuenta. Para obtener más información sobre esta política, incluido el documento de política de JSON, consulte [AmazonRDSServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonRDSServiceRolePolicy.html) en la *Guía de referencia de políticas administradas de AWS*. **nota** Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o función) crear, editar o eliminar la descripción de una función vinculada a un servicio. Si aparece el siguiente mensaje de error: **Unable to create the resource. Verify that you have permission to create service linked role. Otherwise wait and try again later.** Asegúrese de que tiene habilitados los permisos siguientes: ``` { "Action": "iam:CreateServiceLinkedRole", "Effect": "Allow", "Resource": "arn:aws:iam::*:role/aws-service-role/rds.amazonaws.com/AWSServiceRoleForRDS", "Condition": { "StringLike": { "iam:AWSServiceName":"rds.amazonaws.com" } } } ``` Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*. ### Creación de un rol vinculado a un servicio de Amazon Aurora No necesita crear manualmente un rol vinculado a un servicio. Cuando crea un clúster de base de datos, Amazon Aurora crea por usted el rol vinculado al servicio. **importante** Si utilizaba el servicio Amazon Aurora antes del 1 de diciembre de 2017, cuando comenzó a admitir roles vinculados a servicios, entonces Amazon Aurora creó el rol AWSServiceRoleForRDS en su cuenta. Para obtener más información, consulte [Un nuevo rol ha aparecido en mi cuenta de AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_roles.html#troubleshoot_roles_new-role-appeared). Si elimina este rol vinculado a servicio y necesita crearlo de nuevo, puede utilizar el mismo proceso para volver a crear el rol en su cuenta. Cuando crea una instancia de base de datos, Amazon Aurora vuelve a crear por usted el rol vinculado al servicio. ### Modificación de un rol vinculado a un servicio de Amazon Aurora Amazon Aurora no permite editar el rol vinculado al servicio AWSServiceRoleForRDS. Después de crear un rol vinculado a un servicio, no puede cambiarle el nombre, ya que varias entidades pueden hacer referencia al mismo. Sin embargo, sí puede editar la descripción del rol con IAM. Para obtener más información, consulte [Editar un rol vinculado al servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) en la *Guía del usuario de IAM*. ### Eliminación de un rol vinculado a un servicio de Amazon Aurora Si ya no necesita utilizar una característica o servicio que requiere un rol vinculado a un servicio, le recomendamos que elimine dicho rol. De esta forma no tiene una entidad no utilizada que no se monitoree ni mantenga de forma activa. Sin embargo, debe eliminar todos los clústeres para poder eliminar el rol vinculado al servicio. #### Limpiar un rol vinculado a un servicio Antes de poder utilizar IAM para eliminar un rol vinculado a un servicio, primero debe confirmar que dicho rol no tiene sesiones activas y eliminar los recursos que utiliza. **Para comprobar si el rol vinculado a un servicio tiene una sesión activa en la consola de IAM** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. En el panel de navegación de la consola de IAM, elija **Roles**. Luego, elija el nombre (no la casilla de verificación) del rol AWSServiceRoleForRDS. 1. En la página **Resumen** del rol seleccionado, elija la pestaña **Acceso reciente**. 1. En la pestaña **Acceso reciente**, revise la actividad reciente del rol vinculado a servicios. **nota** Si no está seguro de si Amazon Aurora utiliza el rol AWSServiceRoleForRDS, puede intentar eliminar el rol para comprobarlo. Si el servicio está utilizando el rol, este no podrá eliminarse y podrá ver las regiones de AWS en las que se está utilizando. Si el rol se está utilizando, debe esperar que la sesión finalice para poder eliminarlo. No se puede revocar la sesión de un rol vinculado a un servicio. Si desea eliminar el rol AWSServiceRoleForRDS, primero debe eliminar sus clústeres de base de datos *totales*. ##### Eliminación de todos los clústeres Use alguno de estos procedimientos para eliminar un clúster. Repita el procedimiento para cada uno de los clústeres. **Para eliminar un clúster (consola)** 1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En la lista **Databases (Bases de datos)**, elija el clúster que desea eliminar. 1. En **clúster Actions (Acciones de clúster)**, seleccione **Delete (Eliminar)**. 1. Elija **Eliminar**. **Para eliminar un clúster (CLI)** Consulte `[delete-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/delete-db-cluster.html)` en la *referencia de comandos de AWS CLI*. **Para eliminar un clúster (API)** Consulte `[DeleteDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBCluster.html)` en la *Amazon RDS API Reference*. Utilice la consola de IAM, la CLI de IAM o la API de IAM para eliminar el rol vinculado al servicio AWSServiceRoleForRDS. Para obtener más información, consulte [Eliminar un rol vinculado a un servicio](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role) en la *Guía del usuario de IAM*. ## Permisos de roles vinculados a servicios para Amazon RDS Beta Amazon Aurora utiliza el rol vinculado al servicio llamado `AWSServiceRoleForRDSBeta` para que Amazon Aurora pueda llamar a los servicios AWS en nombre de sus recursos de base de datos de RDS. El rol vinculado al servicio AWSServiceRoleForRDSBeta depende de los siguientes servicios para asumir el rol: + `rds.amazonaws.com` Este rol vinculado al servicio tiene una política de permisos adjunta llamada `AmazonRDSBetaServiceRolePolicy` que le otorga permisos para operar en su cuenta. Para obtener más información, consulte [Política administrada de:AWS AmazonRDSBetaServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSBetaServiceRolePolicy). **nota** Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o función) crear, editar o eliminar la descripción de una función vinculada a un servicio. Si aparece el siguiente mensaje de error: **Unable to create the resource. Verify that you have permission to create service linked role. Otherwise wait and try again later.** Asegúrese de que tiene habilitados los permisos siguientes: ``` { "Action": "iam:CreateServiceLinkedRole", "Effect": "Allow", "Resource": "arn:aws:iam::*:role/aws-service-role/custom.rds.amazonaws.com/AmazonRDSBetaServiceRolePolicy", "Condition": { "StringLike": { "iam:AWSServiceName":"custom.rds.amazonaws.com" } } } ``` Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*. ## Rol vinculado a servicios para Amazon RDS Preview Amazon Aurora utiliza el rol vinculado al servicio llamado `AWSServiceRoleForRDSPreview` para que Amazon Aurora pueda llamar a los servicios AWS en nombre de sus recursos de base de datos de RDS. El rol vinculado al servicio AWSServiceRoleForRDSPreview depende de los siguientes servicios para asumir el rol: + `rds.amazonaws.com` Este rol vinculado al servicio tiene una política de permisos adjunta llamada `AmazonRDSPreviewServiceRolePolicy` que le otorga permisos para operar en su cuenta. Para obtener más información, consulte [Política administrada de:AWS AmazonRDSPreviewServiceRolePolicy](rds-security-iam-awsmanpol.md#rds-security-iam-awsmanpol-AmazonRDSPreviewServiceRolePolicy). **nota** Debe configurar permisos para permitir a una entidad de IAM (como un usuario, grupo o función) crear, editar o eliminar la descripción de una función vinculada a un servicio. Si aparece el siguiente mensaje de error: **Unable to create the resource. Verify that you have permission to create service linked role. Otherwise wait and try again later.** Asegúrese de que tiene habilitados los permisos siguientes: ``` { "Action": "iam:CreateServiceLinkedRole", "Effect": "Allow", "Resource": "arn:aws:iam::*:role/aws-service-role/custom.rds.amazonaws.com/AmazonRDSPreviewServiceRolePolicy", "Condition": { "StringLike": { "iam:AWSServiceName":"custom.rds.amazonaws.com" } } } ``` Para obtener más información, consulte [Permisos de roles vinculados a servicios](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) en la *Guía del usuario de IAM*. # VPC de Amazon y Amazon Aurora Amazon Virtual Private Cloud (Amazon VPC) hace posible lanzar recursos de AWS, como clústeres de base de datos de Aurora, en una nube privada virtual (VPC). Cuando utilice una VPC, puede controlar todos los aspectos del entorno de red virtual. Puede elegir su propio rango de direcciones IP, crear subredes y configurar listas de enrutamiento y control de acceso. Es posible ejecutar el clúster de base de datos en una VPC sin ningún coste adicional. Las cuentas tienen una VPC predeterminada. Todos los nuevos clústeres de bases de datos se crean en la VPC predeterminada, a menos que se especifique lo contrario. **Topics** + [ # Uso de una clúster de base de datos en una VPC ](USER_VPC.WorkingWithRDSInstanceinaVPC.md) + [ # Escenarios de acceso a un clúster de base de datos en una VPC ](USER_VPC.Scenarios.md) + [ # Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (solo IPv4) ](CHAP_Tutorials.WebServerDB.CreateVPC.md) + [ # Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (modo de pila doble) ](CHAP_Tutorials.CreateVPCDualStack.md) A continuación, encontrará una discusión acerca de la funcionalidad de la VPC relevante a clústeres de base de datos de Amazon Aurora. Para obtener más información sobre Amazon VPC, consulte la [guía de introducción de Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/) y la [guía del usuario de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/). # Uso de una clúster de base de datos en una VPC Su clúster de base de datos debe estar dentro de la nube privada virtual (VPC). Una VPC es una red virtual aislada lógicamente de otras redes virtuales en la nube de AWS. Amazon VPC le permite lanzar recursos de AWS, como o una instancia de Amazon EC2, en una VPC. La VPC puede ser una VPC predeterminada que viene con la cuenta o una que se haya creado en ella. Todas las VPC están asociadas a la cuenta de AWS. La VPC predeterminada tiene tres subredes que se pueden utilizar para aislar recursos dentro de la VPC. La VPC predeterminada también tiene una puerta de enlace de Internet que se puede utilizar para proporcionar acceso a los recursos situados dentro de la VPC desde fuera de la VPC. Para obtener una lista de los escenarios relacionados con los clústeres de bases de datos de Amazon Aurora fuera de una VPC, consulte [Escenarios de acceso a un clúster de base de datos en una VPC](USER_VPC.Scenarios.md). **Topics** + [ ## Uso de una clúster de base de datos en una VPC ](#Overview.RDSVPC.Create) + [ ## Control de cifrado de VPC ](#USER_VPC.EncryptionControl) + [ ## Uso de los grupos de subredes de base de datos ](#USER_VPC.Subnets) + [ ## Subredes compartidas ](#USER_VPC.Shared_subnets) + [ ## Direccionamiento IP de Amazon Aurora ](#USER_VPC.IP_addressing) + [ ## Cómo ocultar un clúster de base de datos en una VPC desde Internet. ](#USER_VPC.Hiding) + [ ## Creación de un clúster de base de datos en una VPC ](#USER_VPC.InstanceInVPC) En los siguientes tutoriales se explica cómo crear una VPC que se puede utilizar en un escenario de Amazon Aurora habitual: + [Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (solo IPv4)](CHAP_Tutorials.WebServerDB.CreateVPC.md) + [Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (modo de pila doble)](CHAP_Tutorials.CreateVPCDualStack.md) ## Uso de una clúster de base de datos en una VPC A continuación se ofrecen algunos consejos para utilizar un clúster de base de datos en una VPC: + La VPC debe tener dos subredes como mínimo. Estas subredes deben estar en dos zonas de disponibilidad distintas de la Región de AWS en la que desea implementar el clúster de base de datos. Una *subred* es un segmento del rango de direcciones IP de una VPC que puede especificar y que le permite agrupar clústeres de base de datos según sus necesidades operativas y de seguridad. + Si desea que un clúster de base de datos de la VPC sea accesible públicamente, debe activar los atributos *DNS hostnames* y *DNS resolution*. + La VPC debe tener un grupo de subredes de base de datos que haya creado. Para crear un grupo de subredes de base de datos, especifique las subredes que ha creado. Amazon Aurora elige una subred y una dirección IP dentro de esa subred para asociarla con la instancia de base de datos principal de su clúster de base de datos. La instancia de base de datos principal utiliza la zona de disponibilidad que contiene la subred. + La VPC debe tener un grupo de seguridad de VPC que permita el acceso a el clúster de base de datos. Para obtener más información, consulte [Escenarios de acceso a un clúster de base de datos en una VPC](USER_VPC.Scenarios.md). + Los bloques de CIDR de cada una de las subredes deben ser lo suficientemente grandes como para acomodar direcciones IP de repuesto para que Amazon Aurora las use durante las actividades de mantenimiento, incluyendo la conmutación por error y el escalado de recursos de computación. Por ejemplo, un rango como 10.0.0/24 y 10.0.2.0/24 suele ser lo suficientemente grande. + El atributo *instance tenancy* de una VPC puede definirse como *default* o *dedicated*. Todas las VPC predeterminadas tienen el atributo de tenencia de instancia definido como default, y una VPC predeterminada puede admitir cualquier clase de instancia de base de datos. Si opta por tener el clúster de base de datos en una VPC dedicada cuyo atributo de tenencia de instancia está establecido en dedicado, la clase de instancia de base de datos de el clúster debe ser uno de los tipos aprobados de instancia dedicada de Amazon EC2. Por ejemplo, la instancia dedicada r5.large de EC2 corresponde a la clase de instancia de base de datos r5.large. Para obtener información acerca de la tenencia de instancias en una VPC, consulte [Instancias dedicadas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-instance.html) en la *Guía del usuario de Amazon Elastic Compute Cloud*. Para obtener más información acerca de los tipos de instancias que puede haber en una instancia dedicada, consulte [Instancias dedicadas de Amazon EC2](https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/) en la página de precios de Amazon EC2. **nota** Cuando establece el atributo de tenencia de instancia en dedicado para un clúster de base de datos, no garantiza que el clúster de base de datos se ejecute en un host dedicado. ## Control de cifrado de VPC Los controles de cifrado de VPC le permiten aplicar el cifrado en tránsito para todo el tráfico de red dentro de las VPC. Utilice el control de cifrado para cumplir con los requisitos de conformidad normativa, asegurándose de que solo se pueda aprovisionar hardware basado en Nitro con capacidad de cifrado en las VPC designadas. El control de cifrado también detecta los problemas de compatibilidad cuando se solicita la API y no durante el aprovisionamiento. Las cargas de trabajo actuales siguen funcionando y solo se bloquean las nuevas solicitudes incompatibles. Configure los controles de cifrado de la VPC configurando el modo de control de la VPC en: + *desactivado* (predeterminado) + *supervisar* + *forzado* Para comprobar el modo de control actual de la VPC, utilice la Consola de administración de AWS o el comando de la API o la CLI [DescribeVpcs](https://docs.aws.amazon.com//AWSEC2/latest/APIReference/API_DescribeVpcs.html). Si la VPC aplica el cifrado, solo puede aprovisionar clústeres de base de datos basados en Nitro que admitan el cifrado en tránsito en esa VPC. Para obtener más información, consulte [Tipos de clase de instancia de base de datos](Concepts.DBInstanceClass.Types.md). Para obtener información sobre las instancias de Nitro, consulte [Instancias integradas en AWS Nitro System](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) en la *Guía del usuario de Amazon EC2*. **nota** Si intenta aprovisionar clústeres de base de datos incompatibles en una VPC con cifrado, Aurora devuelve una excepción `VpcEncryptionControlViolationException`. Para Aurora Serverless para MySQL y PostreSQL, el control de cifrado requiere la versión de la plataforma 3 o superior. ## Uso de los grupos de subredes de base de datos Las *subredes* son segmentos del rango de direcciones IP de una VPC que se definen para agrupar recursos de acuerdo con las necesidades operativas y de seguridad. Un *grupo de subredes de base de datos* es una colección de subredes (normalmente privadas) que se crean en una VPC y que después se asignan a los clústeres de bases de datos. Un grupo de subredes de base de datos le permite especificar una VPC específica al crear clústeres de bases de datos utilizando la AWS CLI o la API de RDS. Si utiliza la consola, solo puede elegir la VPC y los grupos de subredes que desea utilizar. Cada grupo de subredes de base de datos debe tener subredes como mínimo en dos zonas de disponibilidad de una determinada Región de AWS. Cuando crea un clúster de base de datos en una VPC, debe elegir un grupo de subredes de base de datos. Desde el grupo de subred de base de datos, Amazon Aurora elige una subred y una dirección IP dentro de esa subred para asociarla con la instancia de base de datos principal de su clúster de base de datos. La base de datos utiliza la zona de disponibilidad que contiene la subred. Aurora siempre asigna una dirección IP desde una subred que tiene espacio de dirección IP libre. Las subredes de un grupo de subredes de base de datos son públicas o privadas. Las subredes son públicas o privadas, en función de la configuración que establezca para sus listas de control de acceso a la red (ACL de red) y tablas de enrutamiento. Para que un clúster de base de datos sea accesible públicamente, todas las subredes del grupo de subredes de base de datos deben ser públicas. Si una subred asociada a un clúster de base de datos de acceso público cambia de pública a privada, eso puede afectar a la disponibilidad de el clúster de base de datos. Para crear un grupo de subredes de base de datos que admita el modo de pila doble, asegúrese de que cada subred que agregue al grupo de subredes de base de datos tenga un bloque de CIDR de protocolo de Internet versión 6 (IPv6) asociado. Para obtener más información, consulte [Direccionamiento IP de Amazon Aurora](#USER_VPC.IP_addressing) y el tema sobre cómo [migrar a IPv6](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-migrate-ipv6.html) en la *Guía del usuario de Amazon VPC*. Cuando Amazon Aurora crea un clúster de base de datos en una VPC, asigna una interfaz de red a el clúster de base de datos utilizando una dirección IP del grupo de subredes de base de datos. Sin embargo, le recomendamos que utilice el nombre del sistema de nombres de dominio (DNS) para conectarse a el clúster de base de datos. Se recomienda hacerlo porque la dirección IP subyacente cambia durante la conmutación por error. **nota** Para cada clúster de base de datos que ejecute en una VPC, asegúrese de reservar al menos una dirección en cada subred del grupo de subredes de base de datos para que la utilice Amazon Aurora para las acciones de recuperación. ## Subredes compartidas Puede crear un clúster de base de datos en una VPC compartida. Algunas consideraciones a tener en cuenta al utilizar las VPC compartidas: + Puede mover un clúster  de base de datos de una subred de VPC compartida a una subred de VPC no compartida y viceversa. + Los participantes de una VPC compartida deben crear un grupo de seguridad en la VPC que les permita crear un clúster de base de datos. + Los propietarios y los participantes de una VPC compartida pueden acceder a la base de datos mediante consultas SQL. Sin embargo, solo el creador de un recurso puede realizar llamadas a la API en el recurso. ## Direccionamiento IP de Amazon Aurora Las direcciones IP permiten que los recursos de la VPC se comuniquen entre sí y con otros recursos a través de Internet. Amazon Aurora admite los protocolos de direcciones IPv4 e IPv6. De forma predeterminada, Amazon Aurora y Amazon VPC utilizan el protocolo de direccionamiento IPv4. No puedes desactivar este comportamiento. Al crear una VPC, debe especificar un bloque de CIDR IPv4 (un intervalo de direcciones IPv4 privadas). De manera opcional, puede asignar un bloque de CIDR IPv6 a su VPC y sus subredes y asignar direcciones IPv6 de dicho bloque a clústers de base de datos de su subred La compatibilidad con el protocolo IPv6 amplía el número de direcciones IP admitidas. Al utilizar el protocolo IPv6, se asegura de tener suficientes direcciones disponibles para el futuro crecimiento de Internet. Los recursos de RDS nuevos y existentes pueden utilizar direcciones IPv4 e IPv6 dentro de su VPC. Configurar, proteger y traducir el tráfico de red entre los dos protocolos utilizados en diferentes partes de una aplicación puede provocar sobrecarga operativa. Puede estandarizar el protocolo IPv6 para los recursos de Amazon RDS para simplificar la configuración de la red. **Topics** + [ ### Direcciones IPv4 ](#USER_VPC.IP_addressing.IPv4) + [ ### Direcciones IPv6 ](#USER_VPC.IP_addressing.IPv6) + [ ### Modo de pila doble ](#USER_VPC.IP_addressing.dual-stack-mode) ### Direcciones IPv4 Al crear una VPC, debe especificar un rango de direcciones IPv4 para la VPC como bloque de CIDR como `10.0.0.0/16`. Un *grupo de subredes* de base de datos define el rango de direcciones IP de este bloque de CIDR que puede utilizar un clúster de base de datos. Esta dirección IP puede ser privada o pública. Una dirección IPv4 privada es una dirección IP a la que no se puede obtener acceso desde Internet. Se pueden usar direcciones IPv4 privadas para la comunicación entre el clúster de la base de datos y otros recursos, como instancias de Amazon EC2, en la misma VPC. Cada clúster de base de datos tiene una dirección IP privada para la comunicación en la VPC. Una dirección IP pública es una dirección IPv4 a la que se puede acceder desde Internet. Se pueden usar direcciones públicas para la comunicación entre el clúster de la base de datos y los recursos en Internet, como un cliente SQL. Debe controlar si un clúster de base de datos recibe una dirección IP pública. Amazon RDS utiliza direcciones IPv4 públicas elásticas del conjunto de direcciones IPv4 públicas de EC2 para las instancias de bases de datos de acceso público. Estas direcciones IP están visibles en la cuenta de AWS cuando se usa la CLI de `describe-addresses`, la API o se consulta la sección de IP elásticas (EIP) en la Consola de administración de AWS. Cada dirección IP administrada por RDS se marca con un atributo `service_managed` establecido en `"rds"`. Aunque estas IP están visibles en la cuenta, Amazon RDS las administra en su totalidad y no se pueden modificar ni lanzar. Amazon RDS vuelve a lanzar las IP en el conjunto de direcciones IPv4 públicas cuando ya no se utilizan. CloudTrail registra las llamadas a la API relacionadas con EIP de RDS, como `AllocateAddress`. La entidad principal del servicio `rds.amazonaws.com` invoca estas llamadas a la API. **nota** Las IP asignadas por Amazon RDS no se tienen en cuenta para los límites de EIP de la cuenta. Para ver un tutorial que muestra cómo crear una VPC con solo direcciones IPv4 privadas que puede utilizar con un escenario habitual de Amazon Aurora, consulte [Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (solo IPv4)](CHAP_Tutorials.WebServerDB.CreateVPC.md). ### Direcciones IPv6 De manera opcional, puede asociar un bloque de CIDR IPv6 a su VPC y sus subredes y asignar direcciones IPv6 desde dicho bloque a los recursos de su VPC. Cada dirección IPv6 es única a nivel mundial. El bloque de CIDR IPv6 de su VPC se asigna automáticamente de entre el grupo de direcciones IPv6 de Amazon. Usted no puede elegir el rango. Al conectarse a una dirección IPv6, asegúrese de que se cumplan las siguientes condiciones: + El cliente se ha configurado de manera que se permita el tráfico de la base de datos a través de IPv6. + Los grupos de seguridad de RDS utilizados por la instancia de base de datos están configurados correctamente para permitir el tráfico de cliente a la base de datos a través de IPv6. + La pila del sistema operativo de cliente permite el tráfico en la dirección IPv6. Además, los controladores y bibliotecas del sistema operativo están configurados para elegir el punto de conexión de la instancia de base de datos predeterminado correcto (IPv4 o IPv6). Para obtener más información sobre IPv6, consulte el tema sobre [direccionamiento IP](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) en la *Guía del usuario de Amazon VPC*. ### Modo de pila doble Un clúster de base de datos se ejecuta en modo de pila doble cuando puede comunicarse a través de los protocolos de direcciones tanto IPv4 como IPv6. A continuación, los recursos pueden comunicarse con el clúster de base de datos mediante IPv4, IPv6 o ambos protocolos. Las instancias de base de datos privadas en modo de pila doble tienen puntos de conexión de IPv6 que RDS restringe al acceso de VPC únicamente, lo que garantiza que los puntos de conexión de IPv6 permanezcan privados. Las instancias de base de datos en modo de pila doble público proporcionan puntos de conexión de IPv4 e IPv6 a los que puede acceder desde Internet. **Topics** + [ #### Modo de pila doble y grupos de subredes de base de datos ](#USER_VPC.IP_addressing.dual-stack-db-subnet-groups) + [ #### Utilización de instancias de base de datos en modo de pila doble ](#USER_VPC.IP_addressing.dual-stack-working-with) + [ #### Modificación de clústeres de base de datos de solo IPv4 para utilizar el modo de pila doble ](#USER_VPC.IP_addressing.dual-stack-modifying-ipv4) + [ #### Disponibilidad de clústeres de base de datos de red de pila doble ](#USER_VPC.IP_addressing.dual-stack-availability) + [ #### Limitaciones de clústeres de base de datos de red de pila doble ](#USER_VPC.IP_addressing.dual-stack-limitations) Para ver un tutorial donde se muestra cómo crear una VPC con las direcciones IPv4 y IPv6 que puede utilizar en un escenario habitual de Amazon Aurora, consulte [Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (modo de pila doble)](CHAP_Tutorials.CreateVPCDualStack.md). #### Modo de pila doble y grupos de subredes de base de datos Para utilizar el modo de pila doble, asegúrese de que cada subred del grupo de subredes de base de datos que asocie a el clúster de base de datos tenga un bloque de CIDR de IPv6 asociado. Puede crear un nuevo grupo de subredes de base de datos o modificar un grupo existente de subredes de base de datos para cumplir este requisito. Cuando un clúster de base de datos esté en modo de pila doble, los clientes podrán conectarse como siempre. Asegúrese de que los firewalls de seguridad del cliente y los grupos de seguridad de instancias de base de datos RDS estén configurados correctamente para permitir el tráfico a través de IPv6. Para conectarse, los clientes utilizan el punto de conexión de la instancia principal del clúster de base de datos. Las aplicaciones de cliente pueden especificar qué protocolo prefieren al conectarse a una base de datos. En modo de pila doble, el clúster de base de datos detecta el protocolo de red preferido del cliente (IPv4 o IPv6) y utiliza ese protocolo para la conexión. Si un grupo de subredes de base de datos deja de admitir el modo de pila doble debido a la eliminación de subredes o a la disociación de CIDR, existe el riesgo de que se produzca un estado de red incompatible para las instancias de base de datos asociadas al grupo de subredes de base de datos. Además, no puede utilizar el grupo de subredes de base de datos al crear un clúster nuevo de base de datos en modo de pila doble. Para determinar si un grupo de subredes de base de datos admite el modo de pila doble mediante la Consola de administración de AWS, consulte **Network type** (Tipo de red) en la página de detalles del grupo de subredes de base de datos. Para determinar si un grupo de subredes de base de datos admite el modo de pila doble mediante la AWS CLI, ejecute el comando [describe-db-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-subnet-groups.html) y la vista `SupportedNetworkTypes` en la salida. Las réplicas de lectura se tratan como instancias de base de datos independientes y pueden tener un tipo de red diferente al de la instancia de base de datos principal. Si cambia el tipo de red de la instancia de base de datos principal de una réplica de lectura, la réplica de lectura no se verá afectada. Al restaurar una instancia de base de datos, puede restaurarla a cualquier tipo de red compatible. #### Utilización de instancias de base de datos en modo de pila doble Al crear o modificar un clúster de base de datos, puede especificar que el modo de pila doble permita que los recursos se comuniquen con su clúster de base de datos a través de IPv4, IPv6 o ambos. Al utilizar la Consola de administración de AWS para crear o modificar una instancia de base de datos, puede especificar el modo de pila doble en la sección **Network type** (Tipo de red). En la imagen siguiente se muestra la sección **Network type** (Tipo de red) en la consola. ![\[Sección Tipo de red de la consola con la opción Modo de pila doble seleccionada.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png) Si utiliza la AWS CLI para crear o modificar un clúster de base de datos, establezca la opción `--network-type` en `DUAL` para utilizar el modo de pila doble. Si utiliza la API de RDS para crear o modificar un clúster de base de datos, establezca el parámetro `NetworkType` en `DUAL` para utilizar el modo de pila doble. Al modificar el tipo de red de una instancia de base de datos, puede haber un tiempo de inactividad. Si el modo de pila doble no es compatible con la versión del motor de base de datos o el grupo de subredes de base de datos especificados, se devuelve el error `NetworkTypeNotSupported`. Para obtener más información acerca de la creación de un clúster de base de datos, consulte [Creación de un clúster de base de datos de Amazon Aurora](Aurora.CreateInstance.md). Para obtener más información sobre la modificación de un clúster de base de datos, consulte [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md). Para determinar si un clúster de base de datos está en modo de pila doble mediante la consola, consulte **Network type** (Tipo de red) en la pestaña **Connectivity & security** (Conectividad y seguridad) de el clúster de base de datos. #### Modificación de clústeres de base de datos de solo IPv4 para utilizar el modo de pila doble Puede modificar el clúster de base de datos solo IPv4 para utilizar el modo de pila doble. Para ello, cambie el tipo de red de el clúster de base de datos. La modificación podría dar lugar a un tiempo de inactividad. Se recomienda cambiar el tipo de red de los clústeres de base de datos de Amazon Aurora durante un período de mantenimiento. Actualmente, no se admite la configuración del tipo de red de las nuevas instancias en el modo de doble pila. Puede configurar el tipo de red manualmente mediante el comando `modify-db-cluster`. Antes de modificar un clúster de base de datos para utilizar el modo de pila doble, asegúrese de que su grupo de subredes de base de datos admite el modo de pila doble. Si el grupo de subredes de base de datos asociado a el clúster de base de datos no admite el modo de pila doble, especifique otro grupo de subredes de base de datos que lo admita cuando modifique el clúster de base de datos. La modificación del grupo de subredes de base de datos de un clúster de base de datos puede provocar un tiempo de inactividad. Si modifica el grupo de subredes de base de datos de un clúster de base de datos antes de cambiar el clúster de base de datos para utilizar el modo de doble pila, asegúrese de que el grupo de subredes de base de datos sea válido para el clúster de base de datos antes y después del cambio. Le recomendamos que ejecute la API [modify-db-clúster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) únicamente con el parámetro `--network-type` con el valor `DUAL` para cambiar la red de un clúster de Amazon Aurora al modo de doble pila. Si se añaden otros parámetros junto con el parámetro `--network-type` en la misma llamada a la API, se podría producir un tiempo de inactividad. Si no puede conectarse a el clúster de base de datos después del cambio, asegúrese de que los firewalls de seguridad de la base de datos y del cliente y las tablas de enrutamiento se hayan configurado correctamente para permitir el tráfico a la base de datos de la red seleccionada (IPv4 o IPv6). Es posible que también tenga que modificar los parámetros, las bibliotecas o los controladores del sistema operativo para conectarse mediante una dirección IPv6. **Para modificar un clúster de base de datos solo IPv4 para utilizar el modo de pila doble** 1. Modifique un grupo de subredes de base de datos para admitir el modo de pila doble o cree un grupo de subredes de base de datos que admita el modo de pila doble: 1. Asocie un bloque de CIDR IPv6 a su VPC. Para obtener más información, consulte el tema [Agregue un bloque CIDR de IPv6 a su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#vpc-associate-ipv6-cidr) en la *Guía del usuario de Amazon VPC*. 1. Adjunte el bloque de CIDR IPv6 a todas las subredes de su grupo de subredes de base de datos. Para obtener más información, consulte el tema [Agregue un bloque CIDR de IPv6 a su subred](https://docs.aws.amazon.com/vpc/latest/userguide/modify-subnets.html#subnet-associate-ipv6-cidr) en la *Guía del usuario de Amazon VPC*. 1. Confirme que el grupo de subredes de base de datos admita el modo de pila doble. Si utiliza la Consola de administración de AWS, seleccione el grupo de subredes de base de datos y asegúrese de que el valor **Supported network types** (Tipos de redes compatibles) sea **Dual, IPv4** (Doble, IPv4). Si utiliza la AWS CLI, ejecute el comando [describe-db-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-subnet-groups.html) y asegúrese de que el valor `SupportedNetworkType` de la instancia de base de datos sea `Dual, IPv4`. 1. Modifique el grupo de seguridad asociado a el clúster de base de datos para permitir conexiones IPv6 a la base de datos o cree un nuevo grupo de seguridad que permita conexiones IPv6. Para obtener instrucciones, consulte el tema sobre cómo [crear un grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) en la *Guía del usuario de Amazon VPC*. 1. Modifique la instancia base de datos para admitir el modo de pila doble. Para ello, defina **Network type** (Tipo de red) en **Dual-stack mode** (Modo de pila doble). Si utiliza la consola, asegúrese de que la siguiente configuración sea correcta: + **Network type** (Tipo de red): **Dual-stack mode** (Modo de pila doble) ![\[Sección Tipo de red de la consola con la opción Modo de pila doble seleccionada.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png) + **DB subnet group** (Grupo de subredes de base de datos): el grupo de subredes de base de datos que configuró en un paso anterior + **Security group (Grupo de seguridad)**: la seguridad que configuró en el paso anterior Si utiliza la AWS CLI, asegúrese de que la siguiente configuración sea correcta: + `--network-type` – `dual` + `--db-subnet-group-name`: el grupo de subredes de base de datos que configuró en un paso anterior + `--vpc-security-group-ids`: el grupo de seguridad de la VPC que configuró en un paso anterior Por ejemplo: ``` aws rds modify-db-cluster --db-cluster-identifier my-cluster --network-type "DUAL" ``` 1. Confirme que el clúster de base de datos admite el modo de pila doble. Si utiliza la consola, elija la pestaña **Configuration** (Configuración) para la instancia de base de datos. En esa pestaña, asegúrese de que el valor de **Network type** (Tipo de red) es **Dual-stack mode** (Modo de pila doble). Si utiliza la AWS CLI, ejecute al comando [describe-db-clústers](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) y asegúrese de que el valor `NetworkType` del clúster de base de datos sea `dual`. Ejecute el comando `dig` en el punto de conexión de la instancia de base de datos del escritor para identificar la dirección IPv6 que tiene asociada. ``` dig db-instance-endpoint AAAA ``` Utilice el punto de conexión de la instancia de base de datos del escritor (no la dirección IPv6) para conectarse a el clúster de base de datos. #### Disponibilidad de clústeres de base de datos de red de pila doble Los clústeres de base de datos de red de doble pila están disponibles en todas las Regiones de AWS, a excepción de las siguientes: + Asia-Pacífico (Hyderabad) + Asia-Pacífico (Malasia) + Asia-Pacífico (Melbourne) + Asia-Pacífico (Tailandia) + Oeste de Canadá (Calgary) + Europa (España) + Europa (Zúrich) + Israel (Tel Aviv) + México (centro) + Medio Oriente (EAU) Las siguientes versiones del motor de base de datos admiten clústeres de base de datos de red de doble pila: + Versiones de Aurora MySQL: + Versiones 3.02 y posteriores a la 3 + Versión 2.09.1 y posteriores a la 2 Para obtener más información sobre Aurora MySQL, consulte las [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/Welcome.html). + Versiones de Aurora PostgreSQL: + Versiones 15.2 y posteriores + Versión 14.3 y versiones posteriores a la 14 + Versión 13.7 y versiones posteriores a la 13 Para obtener más información sobre Aurora PostgreSQL, consulte las [https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraPostgreSQLReleaseNotes/Welcome.html). #### Limitaciones de clústeres de base de datos de red de pila doble Las siguientes limitaciones se aplican a los clústeres de base de datos de red de pila doble: + Los clústeres de base de datos no pueden utilizar el protocolo IPv6 exclusivamente. Pueden utilizar IPv4 exclusivamente o utilizar el protocolo IPv4 y IPv6 (modo de pila doble). + Amazon RDS no admite subredes IPv6 nativas. + No puede utilizar RDS Proxy con clústeres de base de datos en modo de pila doble. ## Cómo ocultar un clúster de base de datos en una VPC desde Internet. Un escenario común de Amazon Aurora consiste en tener una VPC en la que hay una instancia de Amazon EC2 con una aplicación web abierta al público y un clúster de base de datos con una base de datos que no es de acceso público. Por ejemplo, puede crear una VPC que tenga una subred pública y una subred privada. Las instancias de EC2 que funcionan como servidores web se pueden implementar en la subred pública. Los Las instancias de base de datos se implementan en la subred privada. En una implementación de este tipo, solo los servidores web tienen acceso a los clústeres de bases de datos. Para ver una ilustración de este escenario, consulte [Acceso a un clúster de base de datos en una VPC desde una instancia de Amazon EC2 de la misma VPC](USER_VPC.Scenarios.md#USER_VPC.Scenario1). Cuando lanza un clúster de base de datos dentro de una VPC, el clúster de base de datos tiene una dirección IP privada para el tráfico dentro de la VPC. Esta dirección IP privada no es accesible públicamente. Puede utilizar la opción **Public access** (Acceso público) para designar si el clúster de base de datos también tiene una dirección IP pública además de la dirección IP privada. Si el clúster se designa como de acceso público, su punto de conexión DNS se resuelve en la dirección IP privada desde dentro de la VPC. Se resuelve en la dirección IP pública desde fuera de la VPC. Acceso a la instancia de base de datos está controlado en última instancia por el grupo de seguridad que utiliza. No se permite el acceso público si el grupo de seguridad asignado al clúster de la base de datos no incluye reglas de entrada que lo permitan. Además, para que un clúster de base de datos sea accesible públicamente, las subredes del grupo de subredes de base de datos deben tener una puerta de enlace de Internet. Para obtener más información, consulte [No puede conectarse a la instancia de base de datos de Amazon RDS](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Connecting). Es posible modificar un clúster de base de datos para activar o desactivar la accesibilidad pública modificando la opción **Public access** (Acceso público). En la ilustración siguiente se muestra la opción **Public access (Acceso público)** en la sección **Additional connectivity configuration (Configuración de conectividad adicional)**. Para definir la opción, abra la sección **Additional connectivity configuration (Configuración de conectividad adicional)** en la sección **Connectivity (Conectividad)**. ![\[Ponga la opción Acceso público de la base de datos en la sección Configuración de conectividad adicional en No.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/VPC-example4.png) Para obtener información sobre cómo modificar una instancia de base de datos para establecer la opción **Public access (Acceso público)**, consulte [Modificación de una instancia de base de datos en un clúster de base de datos](Aurora.Modifying.md#Aurora.Modifying.Instance). ## Creación de un clúster de base de datos en una VPC Los siguientes procedimientos le ayudan a crear un clúster de base de datos en una VPC. Para utilizar la VPC predeterminada, puede comenzar con el paso 2, y utilizar la VPC y el grupo de subredes de la base de datos que ya se han creado para usted. Si desea crear una VPC adicional, puede crear una VPC nueva. **nota** Si desea que un clúster de base de datos de la VPC sea accesible públicamente, debe actualizar la información de DNS para la VPC activando los atributos *DNS hostnames* y *DNS resolution* de la VPC. Para obtener información acerca de cómo actualizar la información de DNS para una instancia de VPC, consulte [Actualización de la compatibilidad de DNS para su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html). Siga estos pasos para crear una instancia de base de datos en una VPC: + [Paso 1: Crear una VPC](#USER_VPC.CreatingVPC) + [Paso 2: Crear un grupo de subredes de base de datos](#USER_VPC.CreateDBSubnetGroup) + [Paso 3: Crear un grupo de seguridad de VPC](#USER_VPC.CreateVPCSecurityGroup) + [Paso 4: Crear la instancia de base de datos en la VPC](#USER_VPC.CreateDBInstanceInVPC) ### Paso 1: Crear una VPC Cree una VPC con subredes en al menos dos zonas de disponibilidad. Utilizará estas subredes cuando cree un grupo de subredes de base de datos. Si tiene una VPC predeterminada, se crea automáticamente una subred en cada zona de disponibilidad de la Región de AWS. Para obtener más información, consulte [Creación de una VPC con subredes públicas y privadas](CHAP_Tutorials.WebServerDB.CreateVPC.md#CHAP_Tutorials.WebServerDB.CreateVPC.VPCAndSubnets) o [Creación de una VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC) en la *Guía del usuario de Amazon VPC*. ### Paso 2: Crear un grupo de subredes de base de datos Un grupo de subredes de base de datos es una colección de subredes (normalmente privadas) que se crean para una VPC y que después se asignan a los clústeres de bases de datos. Un grupo de subredes de base de datos le permite especificar una VPC específica al crear clústeres de bases de datos utilizando la AWS CLI o API. Si utiliza la consola, solo puede elegir la VPC y las subredes que desea utilizar. Cada grupo de subredes de base de datos debe tener como mínimo una subred en al menos dos zonas de disponibilidad de la Región de AWS. Como práctica recomendada, cada grupo de subredes de base de datos debería tener al menos una subred por cada una de las zonas de disponibilidad en la Región de AWS. Para que un clúster de base de datos sea accesible públicamente, las subredes del grupo de subredes de base de datos deben tener una puerta de enlace de Internet. Para obtener más información sobre las puertas de enlace de Internet, consulte [Conectar subredes a Internet por medio de una puerta de enlace de Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) en la *Guía del usuario de Amazon VPC*. Cuando crea una clúster de base de datos en una VPC, debe elegir un grupo de subredes de base de datos. Amazon Aurora elige una subred y una dirección IP dentro de esa subred para asociarla con el clúster de base de datos. Si no existen grupos de subredes de base de datos, Amazon Aurora crea un grupo de subredes predeterminado cuando se crea un clúster de base de datos. Amazon Aurora crea y asocia una interfaz de red elástica a su clúster de base de datos con esa dirección IP. El clúster de base de datos utiliza la zona de disponibilidad que contiene la subred. En este paso, debe crear un grupo de subredes de base de datos y debe agregar las subredes que creó para la VPC. **Para crear un grupo de subredes de base de datos** 1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En el panel de navegación, elija **Subnet groups**. 1. Elija **Create DB Subnet Group**. 1. En **Name**, escriba el nombre del grupo de subredes de base de datos. 1. En **Description**, escriba la descripción del grupo de opciones de base de datos. 1. Para la **VPC**, elija la VPC predeterminada o la VPC que ha creado. 1. En la sección **Agregar subredes**, elija las zonas de disponibilidad que incluyen las subredes en **Zonas de disponibilidad**, y, a continuación, elija las subredes en **Subredes**. ![\[Creación de un grupo de subredes de base de datos.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/RDSVPC101.png) 1. Seleccione **Create (Crear)**. El nuevo grupo de subredes de base de datos aparece en la lista de grupos de subredes de base de datos de la consola de RDS. Puede elegir el grupo de subredes de base de datos para ver los detalles, incluidas todas las subredes asociadas al grupo, en el panel de detalles de la parte inferior de la ventana. ### Paso 3: Crear un grupo de seguridad de VPC Antes de crear el clúster de base de datos, debe crear un grupo de seguridad de VPC para asociarlo a el clúster de base de datos. Si no crea un grupo de seguridad de VPC, puede utilizar el grupo de seguridad predeterminado cuando cree un clúster de base de datos. Para obtener instrucciones sobre cómo crear un grupo de seguridad para el clúster de base de datos, consulte [Creación de un grupo de seguridad de VPC para un clúster de base de datos privada](CHAP_Tutorials.WebServerDB.CreateVPC.md#CHAP_Tutorials.WebServerDB.CreateVPC.SecurityGroupDB) o consulte [Controlar el tráfico hacia los recursos mediante grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) en la *Guía del usuario de Amazon VPC*. ### Paso 4: Crear la instancia de base de datos en la VPC En este paso, se crea un clúster de base de datos y se utiliza el nombre de la VPC, el grupo de subredes de base de datos y el grupo de seguridad de VPC creados en los pasos anteriores. **nota** Si desea que un clúster de base de datos de la VPC sea accesible públicamente, debe activar los atributos *DNS hostnames* y *DNS resolution* de la VPC. Para obtener más información, consulte [Atributos de DNS para su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) en la *Guía del usuario de Amazon VPC*. Para obtener más información sobre cómo crear un clúster de base de datos, consulte [Creación de un clúster de base de datos de Amazon Aurora](Aurora.CreateInstance.md). Cuando la sección **Connectivity** (Conectividad) se lo pida, introduzca el nombre de la VPC, el grupo de subredes de base de datos y el grupo de seguridad de la VPC. **nota** La actualización de VPC no se admite actualmente para los clústeres de Aurora. # Escenarios de acceso a un clúster de base de datos en una VPC Amazon Aurora admite los siguientes escenarios para acceder a un clúster de base de datos en una VPC: + [Una instancia de Amazon EC2 de la misma VPC](#USER_VPC.Scenario1) + [Una instancia EC2 de otra VPC](#USER_VPC.Scenario3) + [Una aplicación cliente a través de Internet](#USER_VPC.Scenario4) + [Una red privada](#USER_VPC.NotPublic) ## Acceso a un clúster de base de datos en una VPC desde una instancia de Amazon EC2 de la misma VPC Un uso común de un clúster de base de datos en una VPC es compartir datos con un servidor de aplicaciones que se ejecuta en una instancia de Amazon EC2 de la misma VPC. En el siguiente diagrama se muestra este escenario. ![\[Escenario de una VPC con un servidor web público y una base de datos privada.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png) La forma más sencilla de administrar el acceso entre instancias EC2 e clústeres de bases de datos en la misma VPC es la siguiente: + Cree el grupo de seguridad de VPC al que pertenecerán los clústeres de bases de datos. Este grupo de seguridad se puede utilizar para restringir el acceso a los clústeres de bases de datos. Por ejemplo, puede crear una regla personalizada para este grupo de seguridad. Esto puede permitir el acceso TCP utilizando el puerto que asignó a el clúster de base de datos cuando lo creó y una dirección IP que utiliza para acceder a el clúster de base de datos para el desarrollo u otras finalidades. + Cree el grupo de seguridad de VPC al que pertenecerán las instancias EC2 (clientes y servidores web). Este grupo de seguridad puede, si es necesario, permitir el acceso a la instancia EC2 desde Internet a través de la tabla de enrutamiento de la VPC. Por ejemplo, puede establecer reglas en este grupo de seguridad para permitir el acceso mediante TCP a la instancia EC2 a través del puerto 22. + Cree reglas personalizadas en el grupo de seguridad para los clústeres de bases de datos que permitan las conexiones desde el grupo de seguridad que creó para las instancias EC2. Estas reglas podrían permitir a cualquier miembro del grupo de seguridad acceder a los clústeres de base de datos. Hay una subred pública y privada adicional en una zona de disponibilidad independiente. Un grupo de subredes de base de datos de RDS requiere una subred en al menos dos zonas de disponibilidad. La subred adicional facilita el cambio a una implementación de instancia de base de datos multi-AZ en el futuro. Para ver un tutorial que muestra cómo crear una VPC con subredes públicas y privadas para este escenario, consulte [Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (solo IPv4)](CHAP_Tutorials.WebServerDB.CreateVPC.md). **sugerencia** Puede configurar la conectividad de red entre una instancia de Amazon EC2 y un clúster de base de datos automáticamente al crear el clúster de base de datos. Para obtener más información, consulte [Configurar la conectividad de red automática con una instancia de EC2](Aurora.CreateInstance.md#Aurora.CreateInstance.Prerequisites.VPC.Automatic) . **Para crear una regla en un grupo de seguridad de VPC que permita establecer conexiones desde otro grupo de seguridad, haga lo siguiente:** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com/vpc). 1. En el panel de navegación, elija **Grupos de seguridad**. 1. Elija o cree el grupo de seguridad al que desea que puedan tener acceso los miembros de otro grupo de seguridad. En el escenario anterior, este es el grupo de seguridad que utiliza para los clústeres de base de datos. Elija la pestaña **Inbound Rules (Reglas de entrada)** y, a continuación, elija **Edit inbound rules (Editar reglas de entrada)**. 1. En la página **Edit inbound rules (Editar reglas de entrada)**, elija **Add Rule (Agregar regla)**. 1. En **Type (Tipo)**, elija la entrada que corresponda al puerto que utilizó al crear el clúster de base de datos, como **MySQL/Aurora**. 1. En el cuadro **Origen**, comience a escribir el ID del grupo de seguridad, que enumera los grupos de seguridad coincidentes. Elija el grupo de seguridad cuyos miembros desea que tengan acceso a los recursos protegidos por este grupo de seguridad. En el escenario anterior, este es el grupo de seguridad que utiliza para su instancia EC2. 1. Si es necesario, repita los pasos para el protocolo TCP creando una regla con **Todo TCP** en el campo **Tipo** y con el grupo de seguridad en el campo **Origen**. Si va a utilizar el protocolo UDP, cree una regla con **All UDP (Todo UDP)** en el campo **Type (Tipo)** y con el grupo de seguridad en el campo **Source (Origen)**. 1. Seleccione **Guardar reglas**. La siguiente pantalla muestra una regla de entrada con un grupo de seguridad para su origen. ![\[Adición de un grupo de seguridad a las reglas de otro grupo de seguridad.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/con-vpc-add-sg-rule.png) Para obtener más información sobre cómo conectarse al clúster de base de datos desde su instancia de EC2, consulte [Conexión a un clúster de base de datos Amazon Aurora](Aurora.Connecting.md). ## Acceso a un clúster de base de datos en una VPC desde una instancia EC2 de otra VPC Cuando un clúster de base de datos está en una VPC que no coincide con la de la instancia EC2 que se está utilizando para obtener acceso a ella, puede usar la interconexión con VPC para obtener acceso a el clúster de base de datos. En el siguiente diagrama se muestra este escenario. ![\[Acceso a una instancia de base de datos en una VPC desde una instancia de Amazon EC2 de otra VPC.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/RDSVPC2EC2VPC-aurora.png) Una conexión de emparejamiento de VPC es una conexión de redes entre dos VPC que permite direccionar el tráfico entre ellas mediante direcciones IP privadas. Los recursos de ambas VPC se pueden comunicar entre sí siempre que se encuentren en la misma red. Puede crear una conexión de emparejamiento de VPC entre sus propias VPC, con una VPC de otra cuenta de AWS o con una VPC de otra Región de AWS. Para obtener más información sobre las interconexiones de VPC, consulte [Interconexión con VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) en la *Guía de usuario de Amazon Virtual Private Cloud*. ## Acceso a un clúster de base de datos en una VPC desde una aplicación cliente a través de internet Para acceder a un clúster de base de datos en una VPC desde una aplicación cliente a través de internet, configure una VPC con una subred pública única y una puerta de enlace de Internet para permitir la comunicación a través de internet. En el siguiente diagrama se muestra este escenario. ![\[Acceso a un clúster de base de datos en una VPC desde una aplicación cliente a través de internet.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/GS-VPC-network-aurora.png) Recomendamos la siguiente configuración: + Una VPC de tamaño /16 (por ejemplo, CIDR: 10.0.0.0/16). Este tamaño proporciona 65 536 direcciones IP privadas. + Una subred de tamaño /24 (por ejemplo, CIDR: 10.0.0.0/24). Este tamaño proporciona 256 direcciones IP privadas. + Un clúster de base de datos de Amazon Aurora que se ha asociado a la VPC y a la subred. Amazon RDS asigna una dirección IP de la subred a el clúster de base de datos. + Una gateway de Internet que conecte la VPC a Internet y a otros productos de AWS. + Un grupo de seguridad asociado a el clúster de base de datos. Las reglas de entrada del grupo de seguridad permiten a la aplicación cliente obtener acceso a el clúster de base de datos. Para obtener información acerca de la creación de un clúster de base de datos en una VPC, consulte [Creación de un clúster de base de datos en una VPC](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.InstanceInVPC). ## Un clúster de base de datos en una VPC a la que se accede mediante una red privada Si su clúster de base de datos no es accesible públicamente, tiene las siguientes opciones para acceder a ella desde una red privada: + 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) + Una conexión de AWS Client VPN. Para obtener más información, consulte [¿Qué es AWS Client VPN?](https://docs.aws.amazon.com//vpn/latest/clientvpn-admin/what-is.html) El siguiente diagrama muestra un escenario con una conexión de Site-to-site VPN AWS. ![\[Acceso a clústeres de bases de datos en una VPC desde una red privada.\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/site-to-site-vpn-connection-aurora.png) Para obtener más información, consulte [Privacidad del tráfico entre redes](inter-network-traffic-privacy.md). # Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (solo IPv4) Un escenario común incluye un clúster de base de datos en una nube privada virtual (VPC) basada en el servicio Amazon VPC. Esta VPC comparte datos con un servidor web que se ejecuta en la misma VPC. En este tutorial se crea la VPC para este escenario. En el siguiente diagrama se muestra este escenario. Para obtener información acerca de otros escenarios, consulte [Escenarios de acceso a un clúster de base de datos en una VPC](USER_VPC.Scenarios.md). ![\[Escenario de VPC única\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-aurora.png) Su clúster de bases de datos debe estar disponible únicamente para su servidor web, y no para la Internet pública. Además, cree de una VPC con subredes públicas y privadas. El servidor web está alojado en la subred pública, para que pueda obtener acceso a la red pública de internet. El clúster de base de datos se aloja en una subred privada. El servidor web puede conectarse a el clúster de base de datos porque se aloja en la misma VPC. Sin embargo, el clúster de base de datos no está disponible en la red pública de internet, lo que proporciona mayor seguridad. Este tutorial configura una subred pública y privada adicional en una zona de disponibilidad independiente. En el tutorial no se utilizan estas subredes. Un grupo de subredes de base de datos de RDS requiere una subred en al menos dos zonas de disponibilidad. La subred adicional facilita la configuración de más de una instancia de base de datos de Aurora. En este tutorial se describe la configuración de una VPC para clústeres de bases de datos de Amazon Aurora de . Para ver un tutorial que muestra cómo crear un servidor web para este escenario de la VPC, consulte [Explicación: crear un servidor web y un clúster de base de datos de Amazon Aurora](TUT_WebAppWithRDS.md). Para obtener más información sobre Amazon VPC, consulte la [guía de introducción de Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/) y la [guía del usuario de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/). **sugerencia** Puede configurar la conectividad de red entre una instancia de Amazon EC2 y un clúster de base de datos automáticamente al crear el clúster de base de datos. La configuración de red es similar a la que se describe en este tutorial. Para obtener más información, consulte [Configurar la conectividad de red automática con una instancia de EC2](Aurora.CreateInstance.md#Aurora.CreateInstance.Prerequisites.VPC.Automatic). ## Creación de una VPC con subredes públicas y privadas Utilice el siguiente procedimiento para crear una VPC con subredes públicas y privadas. **Para crear una VPC y las subredes** 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. En la esquina superior derecha de la Consola de administración de AWS, elija la región en la que desea crear la VPC. En este ejemplo se utiliza la región Oeste de EE. UU. (Oregón). 1. En la esquina superior izquierda, elija **VPC Dashboard (Panel de control VPC)**. Para comenzar a crear una VPC, elija **Create VPC (Crear una VPC)**. 1. En **Resources to create (Recursos para crear)**, en **VPC settings (Configuración VPC)**, elija **VPC and more (VPC y más)**. 1. En **VPC settings (Configuración de la VPC)**, establezca estos valores: + **Name tag auto-generation (Generación automática de etiquetas de nombre)**: **tutorial** + **IPv4 CIDR block (Bloque de CIDR IPv4)**: **10.0.0.0/16** + **IPv6 CIDR block (Bloque de CIDR IPv6)**: **ningún bloque de CIDR IPv6** + **Tenancy (Tenencia)**: **predeterminada** + **Number of Availability Zones (AZs) (Número de zonas de disponibilidad)**: **2** + **Customize AZs (Personalizar AZ)**: conserve los valores predeterminados. + **Number of public subnet (Número de subredes públicas)**: **2** + **Number of private subnets (Número de subredes privadas)**: **2** + **Customize subnets CIDR blocks (Personalizar bloques CIDR de subredes)**: conserve los valores predeterminados. + **NAT gateways (\$1) (Puertas de enlace NAT)**: **ninguna** + **VPC endpoints (Puntos de conexión de VPC)**: **ninguna** + **DNS options (Opciones de DNS)**: conserve los valores predeterminados. 1. Seleccione **Creación de VPC**. ## Creación de un grupo de seguridad de VPC para un servidor web público Primero debe crear un grupo de seguridad para el acceso público. Para conectarse a instancias de EC2 públicas en su VPC, añada reglas de entrada a su grupo de seguridad de VPC. Permiten que el tráfico se conecte desde Internet. **Para crear un grupo de seguridad de VPC** 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Elija **VPC Dashboard (Panel VPC)**, seguido de **Security Groups (Grupos de seguridad)** y, por último, **Create Security Group (Crear grupo de seguridad)**. 1. En la página **Create Security Group (Crear grupo de seguridad)**, establezca estos valores: + **Security group name (Nombre de grupo de seguridad:** **tutorial-securitygroup** + **Description:** **Tutorial Security Group** + **VPC**: elija la VPC que creó en el paso anterior, por ejemplo, **vpc-*identificador*(tutorial-vpc)** 1. Agregar reglas de entrada al grupo de seguridad 1. Determine la dirección IP que usará para conectarse a las instancias de EC2 mediante Secure Shell (SSH). Para determinar su dirección IP pública, en una ventana o pestaña distinta del navegador, puede utilizar el servicio en [https://checkip.amazonaws.com](https://checkip.amazonaws.com). Un ejemplo de dirección IP es `203.0.113.25/32`. En muchos casos, puede conectarse a través de un proveedor de servicios de internet (ISP) o protegido por un firewall sin una dirección IP estática. Si es así, busque el rango de direcciones IP utilizadas por los ordenadores cliente. **aviso** Si utiliza `0.0.0.0/0` para el acceso SSH, permita que todas las direcciones IP accedan a sus instancias públicas mediante SSH. Este método es aceptable para un periodo de tiempo corto en un entorno de prueba, pero no es seguro en entornos de producción. En entornos de producción, solo debe autorizar una dirección IP específica o un intervalo de direcciones para acceder a sus instancias mediante SSH. 1. En la sección **Inbound rules (Reglas de entrada)**, elija **Add rule (agregar regla)**. 1. Establezca los siguientes valores para la regla de entrada nueva con objeto de permitir el acceso SSH a la instancia de Amazon EC2. Si lo hace, puede conectarse a la instancia de Amazon EC2 para instalar el servidor web y otras utilidades. También puede conectarse a su instancia de EC2 para cargar contenido para el servidor web. + **Tipo:** **SSH** + **Origen:** la dirección IP o el rango de direcciones del Paso a, por ejemplo **203.0.113.25/32**. 1. Seleccione **Add rule (Agregar regla)**. 1. Establezca los siguientes valores para la regla de entrada nueva con objeto de permitir el acceso HTTP al servidor web. + **Tipo:** **HTTP** + **Source:** **0.0.0.0/0** 1. Para crear el grupo de seguridad, elija **Create security group (Crear grupo de seguridad)**. Anote el ID del grupo de seguridad, ya que lo necesitará más tarde en este tutorial. ## Creación de un grupo de seguridad de VPC para un clúster de base de datos privada Para que un clúster de base de datos sea privada, debe crear un segundo grupo de seguridad para el acceso privado. Para conectarse a clústeres de base de datos privada en la VPC, agregue reglas de entrada al grupo de seguridad de la VPC que permitan el tráfico solo desde el servidor web. **Para crear un grupo de seguridad de VPC** 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Elija **VPC Dashboard (Panel VPC)**, seguido de **Security Groups (Grupos de seguridad)** y, por último, **Create Security Group (Crear grupo de seguridad)**. 1. En la página **Create Security Group (Crear grupo de seguridad)**, establezca estos valores: + **Security group name (Nombre de grupo de seguridad:** **tutorial-db-securitygroup** + **Description:** **Tutorial DB Instance Security Group** + **VPC**: elija la VPC que creó en el paso anterior, por ejemplo, **vpc-*identificador*(tutorial-vpc)** 1. Agregar reglas de entrada al grupo de seguridad 1. En la sección **Inbound rules (Reglas de entrada)**, elija **Add rule (gregar regla)**. 1. Establezca los siguientes valores para la regla de entrada nueva con objeto de permitir el tráfico de MySQL en el puerto 3306 desde la instancia de Amazon EC2. Si lo hace, podrá conectarse desde su servidor web a su clúster de base de datos. Si lo hace, puede almacenar y recuperar datos en la base de datos desde la aplicación web. + **Tipo:** **MySQL/Aurora** + **Source (Origen):** el identificador del grupo de seguridad **tutorial-securitygroup** que creó anteriormente en este tutorial, por ejemplo, **sg-9edd5cfb**. 1. Para crear el grupo de seguridad, elija **Create security group (Crear grupo de seguridad)**. ## Creación de un grupo de subredes de base de datos Un *grupo de subredes de base de datos* es una colección de subredes que se crea en una VPC y que después se asigna a los clústeres de bases de datos. Un grupo de subredes de base de datos le permite especificar una VPC específica al crear clústeres de bases de datos. **Para crear un grupo de subredes de base de datos** 1. Identifique las subredes privadas de la base de datos en la VPC. 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Seleccione **VPC Dashboard (Panel de control de VPC)** y, a continuación, seleccione **Subnets (Subredes)**. 1. Observe los ID de subred de las subredes denominadas **tutorial-subred-private1-us-west-2a** y**tutorial-subnet-private2-us-west-2b**. Necesitará los ID de subred cuando cree el grupo de subredes de base de datos. 1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). Asegúrese de conectarse a la consola de Amazon RDS, no a la consola de Amazon VPC. 1. En el panel de navegación, elija **Subnet groups**. 1. Elija **Create DB Subnet Group (Crear grupo de subredes de base de datos)**. 1. En la página **Create DB subnet group (Crear grupo de subredes de base de datos)**, establezca estos valores en **Subnet group details (Detalles del grupo de subredes)**: + **Name:** **tutorial-db-subnet-group** + **Description:** **Tutorial DB Subnet Group** + **VPC:** **tutorial-vpc (vpc-*identificador*)** 1. En la sección **Agregar subredes** elija las **Zonas de disponibilidad** y **Subredes**. Para este tutorial, elija **us-west-2a** y **us-west-2b** en **Availability Zones (Zonas de disponibilidad)**. En **Subnets (Subredes)**, elija las subredes privadas que identificó en el paso anterior. 1. Seleccione **Crear**. El nuevo grupo de subredes de base de datos aparece en la lista de grupos de subredes de base de datos de la consola de RDS. Puede elegir el grupo de subredes de base de datos para ver los detalles en el panel de detalles de la parte inferior de la ventana. Estos detalles incluyen todas las subredes asociadas al grupo. **nota** Si creó esta VPC para completar [Explicación: crear un servidor web y un clúster de base de datos de Amazon Aurora](TUT_WebAppWithRDS.md), cree el clúster de la de base de datos siguiendo las instrucciones que se indican en [Crear un clúster de base de datos de Amazon Aurora](CHAP_Tutorials.WebServerDB.CreateDBCluster.md). ## Eliminación de la VPC Después de crear la VPC y otros recursos para este tutorial, puede eliminarlos si ya no son necesarios. **nota** Si agregó recursos en la VPC que creó para este tutorial, es posible que primero tenga que eliminar estos para poder eliminar la VPC. Por ejemplo, estos recursos pueden incluir instancias de Amazon EC2 o clústeres de base de datos de Amazon RDS. Para obtener más información, consulte [Eliminación de la VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting) en la *Guía del usuario de Amazon VPC*. **Para eliminar una VPC y los recursos relacionados** 1. Elimine el grupo de subred de base de datos. 1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En el panel de navegación, elija **Subnet groups**. 1. Seleccione el grupo de subred de base de datos que desea eliminar, como **tutorial-db-subnet-group**. 1. Elija **Eliminar** y, a continuación, elija **Eliminar** en la ventana de confirmación. 1. Anote el ID de la VPC. 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Seleccione **VPC Dashboard (Panel de control de VPC)** y, a continuación, seleccione **VPCs**. 1. En la lista, identifique la VPC que creó, como, por ejemplo, **tutorial-vpc**. 1. Anote el **ID de la VPC** que ha creado. Necesitará el ID de la VPC en pasos posteriores. 1. Elimine los grupos de seguridad. 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Seleccione **Panel de control de VPC** y, a continuación, seleccione **Grupos de seguridad**. 1. Seleccione el grupo de seguridad de la instancia de base de datos de Amazon RDS, como, por ejemplo, **tutorial-db-securitygroup**. 1. En **Actions (Acciones)**, elija **Delete security groups (Eliminar grupos de seguridad)** y, a continuación, seleccione **Delete (Eliminar)** en la página de confirmación. 1. En la página **Grupos de seguridad**, seleccione el grupo de seguridad para la instancia de Amazon EC2, como, por ejemplo, **tutorial-securitygroup**. 1. En **Actions (Acciones)**, elija **Delete security groups (Eliminar grupos de seguridad)** y, a continuación, seleccione **Delete (Eliminar)** en la página de confirmación. 1. Eliminación de la VPC 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Seleccione **VPC Dashboard (Panel de control de VPC)** y, a continuación, seleccione **VPCs**. 1. Seleccione la VPC que desea eliminar, como, por ejemplo **tutorial-vpc**. 1. En **Actions (Acciones)**, elija **Delete VPC (Eliminar VPC)**. La página de confirmación muestra otros recursos asociados a la VPC que también se eliminarán, incluidas las subredes asociadas a ella. 1. En la página de confirmación, introduzca **delete** y elija **Eliminar**. # Tutorial: Creación de una VPC para utilizarla con un clúster de base de datos (modo de pila doble) Un escenario común incluye un clúster de base de datos en una nube privada virtual (VPC) basada en el servicio Amazon VPC. Esta VPC comparte datos con una instancia de Amazon EC2 pública que se ejecuta en la misma VPC. En este tutorial, creará la VPC para este escenario que funciona con una base de datos que se ejecuta en modo de pila doble. Modo de doble pila para permitir la conexión a través del protocolo de direccionamiento IPv6. Para obtener más información sobre el direccionamiento de IP, consulte [Direccionamiento IP de Amazon Aurora](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing). Los clústeres de red de doble pila se admiten en la mayoría de las regiones. Para obtener más información consulte () [Disponibilidad de clústeres de base de datos de red de pila doble](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing.dual-stack-availability). Para ver las limitaciones del modo de doble pila, consulte [Limitaciones de clústeres de base de datos de red de pila doble](USER_VPC.WorkingWithRDSInstanceinaVPC.md#USER_VPC.IP_addressing.dual-stack-limitations). En el siguiente diagrama se muestra este escenario. ![\[Escenario de VPC para el modo de pila doble\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/con-VPC-sec-grp-dual-stack-aurora.png) Para obtener información acerca de otros escenarios, consulte [Escenarios de acceso a un clúster de base de datos en una VPC](USER_VPC.Scenarios.md). Su clúster de base de datos debe estar disponible únicamente para su instancia de Amazon EC2, y no para la Internet pública. Además, cree de una VPC con subredes públicas y privadas. La instancia de Amazon EC2 está alojada en la subred pública, para que pueda acceder a la red pública de internet. El clúster de base de datos se aloja en una subred privada. La instancia de Amazon EC2 se puede conectar a el clúster de base de datos porque se aloja en la misma VPC. Sin embargo, el clúster de base de datos no está disponible en la red pública de internet, lo que proporciona mayor seguridad. Este tutorial configura una subred pública y privada adicional en una zona de disponibilidad independiente. En el tutorial no se utilizan estas subredes. Un grupo de subredes de base de datos de RDS requiere una subred en al menos dos zonas de disponibilidad. La subred adicional facilita la configuración de más de una instancia de base de datos de Aurora. Para crear un clúster de base de datos que utilice el modo de pila doble, especifique **Dual-stack mode (Modo pila doble)** en el ajuste **Network type (Tipo de red)**. También puede modificar un clúster de base de datos con el mismo ajuste. Para obtener más información acerca de la creación de un clúster de base de datos, consulte [Creación de un clúster de base de datos de Amazon Aurora](Aurora.CreateInstance.md). Para obtener más información sobre la modificación de un clúster de base de datos, consulte [Modificación de un clúster de base de datos de Amazon Aurora](Aurora.Modifying.md). En este tutorial se describe la configuración de una VPC para clústeres de bases de datos de Amazon Aurora de . Para obtener más información acerca de Amazon VPC, consulte la [Guía del usuario de Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/). ## Creación de una VPC con subredes públicas y privadas Utilice el siguiente procedimiento para crear una VPC con subredes públicas y privadas. **Para crear una VPC y las subredes** 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. En la esquina superior derecha de la Consola de administración de AWS, elija la región en la que desea crear la VPC. En este ejemplo se utiliza la región Este de EE. UU. (Ohio). 1. En la esquina superior izquierda, elija **VPC Dashboard (Panel de control VPC)**. Para comenzar a crear una VPC, elija **Create VPC (Crear una VPC)**. 1. En **Resources to create (Recursos para crear)**, en **VPC settings (Configuración VPC)**, elija **VPC and more (VPC y más)**. 1. Para el resto de opciones de **VPC settings (Configuración de la VPC)**, defina estos valores: + **Name tag auto-generation (Generación automática de etiquetas de nombre** – **tutorial-dual-stack** + **IPv4 CIDR block (Bloque de CIDR IPv** – **10.0.0.0/16** + **IPv6 CIDR block (Bloque de CIDR IPv6)**: **bloque de CIDR IPv6 proporcionado por Amazon** + **Tenancy (Tenencia)**: **predeterminada** + **Number of Availability Zones (AZs) (Número de zonas de disponibilidad)** – **2** + **Customize AZs (Personalizar AZ)**: conserve los valores predeterminados. + **Number of public subnet (Número de subredes públicas** – **2** + **Number of private subnets (Número de subredes privadas** – **2** + **Customize subnets CIDR blocks (Personalizar bloques CIDR de subredes)**: conserve los valores predeterminados. + **NAT gateways (\$1) (Puertas de enlace NAT)**: **ninguna** + **Egress only internet gateway (Puerta de enlace de internet solo de salida)**: **no** + **VPC endpoints (Puntos de conexión de VPC)**: **ninguna** + **DNS options (Opciones de DNS)**: conserve los valores predeterminados. **nota** Amazon RDS requiere al menos dos subredes en dos zonas de disponibilidad diferentes para admitir implementaciones de instancias de base de datos multi-AZ. En este tutorial se crea una implementación Single-AZ, pero el requisito facilita la conversión a una implementación de instancia de base de datos Multi-AZ en el futuro. 1. Seleccione **Creación de VPC**. ## Para crear un grupo de seguridad de la VPC para una instancia de Amazon EC2 pública Primero debe crear un grupo de seguridad para el acceso público. Para conectarse a instancias EC2 públicas, añada reglas de entrada al grupo de seguridad de la VPC que permitan el tráfico para las conexiones desde internet. **Para crear un grupo de seguridad de VPC** 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Elija **VPC Dashboard (Panel VPC)**, seguido de **Security Groups (Grupos de seguridad)** y, por último, **Create Security Group (Crear grupo de seguridad)**. 1. En la página **Create Security Group (Crear grupo de seguridad)**, establezca estos valores: + **Security group name (Nombre de grupo de seguridad:** **tutorial-dual-stack-securitygroup** + **Description:** **Tutorial Dual-Stack Security Group** + **VPC**: elija la VPC que creó en el paso anterior, por ejemplo, **vpc-*identificador*(tutorial-dual-stack-vpc)** 1. Agregar reglas de entrada al grupo de seguridad 1. Determine la dirección IP que usará para conectarse a las instancias de EC2 mediante Secure Shell (SSH). Un ejemplo de dirección del protocolo de internet versión 4 (IPv4) es `203.0.113.25/32`. Un ejemplo de rango de direcciones del protocolo de internet versión 6 (IPv6) es `2001:db8:1234:1a00::/64`. En muchos casos, puede conectarse a través de un proveedor de servicios de internet (ISP) o protegido por un firewall sin una dirección IP estática. Si es así, busque el rango de direcciones IP utilizadas por los ordenadores cliente. **aviso** Si utiliza `0.0.0.0/0` para IPv4 o `::0` para IPv6, permitirá que todas las direcciones IP tengan acceso a las instancias públicas mediante SSH. Este método es aceptable para un periodo de tiempo corto en un entorno de prueba, pero no es seguro en entornos de producción. En los entornos de producción, debe autorizar el acceso a sus instancias únicamente a una dirección IP o a un rango de direcciones IP específicos. 1. En la sección **Inbound rules (Reglas de entrada)**, elija **Add rule (agregar regla)**. 1. Establezca los siguientes valores para la regla de entrada nueva con objeto de permitir el acceso Secure Shell (SSH) a la instancia de Amazon EC2. Si lo hace, podrá conectarse a la instancia de EC2 para instalar clientes SQL y otras aplicaciones. Especifique una dirección IP para permitir poder acceder a su instancia de EC2: + **Tipo:** **SSH** + **Origen:** la dirección IP o el rango del paso a. Un ejemplo de dirección IP IPv4 es **203.0.113.25/32**. Un ejemplo de dirección IP IPv6 es **2001:DB8::/32**. 1. Para crear el grupo de seguridad, elija **Create security group (Crear grupo de seguridad)**. Anote el ID del grupo de seguridad, ya que lo necesitará más tarde en este tutorial. ## Creación de un grupo de seguridad de VPC para un clúster de base de datos privada Para que un clúster de base de datos sea privada, debe crear un segundo grupo de seguridad para el acceso privado. Para conectarse a clústeres de base de datos privadas en su VPC, añada reglas de entrada a su grupo de seguridad de VPC. Estos permiten el tráfico de su instancia de Amazon EC2 solamente. **Para crear un grupo de seguridad de VPC** 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Elija **VPC Dashboard (Panel VPC)**, seguido de **Security Groups (Grupos de seguridad)** y, por último, **Create Security Group (Crear grupo de seguridad)**. 1. En la página **Create Security Group (Crear grupo de seguridad)**, establezca estos valores: + **Security group name (Nombre de grupo de seguridad:** **tutorial-dual-stack-db-securitygroup** + **Description:** **Tutorial Dual-Stack DB Instance Security Group** + **VPC**: elija la VPC que creó en el paso anterior, por ejemplo, **vpc-*identificador*(tutorial-dual-stack-vpc)** 1. Agregar reglas de entrada al grupo de seguridad: 1. En la sección **Inbound rules (Reglas de entrada)**, elija **Add rule (gregar regla)**. 1. Establezca los siguientes valores para la regla de entrada nueva con objeto de permitir el tráfico de MySQL en el puerto 3306 desde la instancia de Amazon EC2. Si lo hace, podrá conectarse desde su instancia de EC2 a su clúster de base de datos. Esto significa que puede enviar datos desde la instancia de EC2 a la base de datos. + **Type** (Tipo): **MySQL/Aurora** + **Source (Origen):** identificador del grupo de seguridad **tutorial-dual-stack-securitygroup** que creó anteriormente en este tutorial, por ejemplo, **sg-9edd5cfb**. 1. Para crear el grupo de seguridad, elija **Crear grupo de seguridad**. ## Creación de un grupo de subredes de base de datos Un *grupo de subredes de base de datos* es una colección de subredes que se crea en una VPC y que después se asigna a los clústeres de bases de datos. Un grupo de subredes de base de datos le permite especificar una VPC específica al crear clústeres de bases de datos. Para crear un grupo de subredes de base de datos que sea compatible con `DUAL`, todas las subredes deben ser compatibles con `DUAL`. Para que sea compatible con `DUAL`, una subred debe tener asociado un CIDR IPv6. **Para crear un grupo de subredes de base de datos** 1. Identifique las subredes privadas de la base de datos en la VPC. 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Seleccione **VPC Dashboard (Panel de control de VPC)** y, a continuación, seleccione **Subnets (Subredes)**. 1. Anote los ID de subred de las subredes denominadas **tutorial-subred-dual-stack-private1-us-west-2a** y **tutorial-subred-dual-stack-private2-us-west-2b**. Necesitará los ID de subred cuando cree el grupo de subredes de base de datos. 1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). Asegúrese de conectarse a la consola de Amazon RDS, no a la consola de Amazon VPC. 1. En el panel de navegación, elija **Subnet groups**. 1. Elija **Create DB Subnet Group (Crear grupo de subredes de base de datos)**. 1. En la página **Create DB subnet group (Crear grupo de subredes de base de datos)**, establezca estos valores en **Subnet group details (Detalles del grupo de subredes)**: + **Name:** **tutorial-dual-stack-db-subnet-group** + **Description:** **Tutorial Dual-Stack DB Subnet Group** + **VPC:** **tutorial-dual-stack-vpc (vpc-*identificador*)** 1. En la sección **Add subnets (Agregar subredes)** elija las **Availability Zones (Zonas de disponibilidad)** y las **Subnets (Subredes)**. Para este tutorial, elija **us-east-2a** y **us-east-2b** en **Availability Zones (Zonas de disponibilidad)**. En **Subnets (Subredes)**, elija las subredes privadas que identificó en el paso anterior. 1. Seleccione **Crear**. El nuevo grupo de subredes de base de datos aparece en la lista de grupos de subredes de base de datos de la consola de RDS. Puede elegir el grupo de subredes de base de datos para ver la información detallada, que incluye los protocolos de direcciones compatibles y todas las subredes asociadas al grupo y al tipo de red admitidos por el grupo de subredes de base de datos. ## Crear una instancia de Amazon EC2 en el modo de pila doble Para crear una instancia de Amazon EC2, siga las instrucciones indicadas en [Lanzar una instancia con el nuevo asistente de inicialización de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) en la *Guía del usuario de Amazon EC2*. En la página **Configure Instance Details (Configurar detalles de instancia)**, defina estos valores y mantenga los demás con sus valores predeterminados: + **Red**: elija una VPC existente con las subredes pública y privada, como **tutorial-dual-stack-vpc** (vpc-*identificador*) creada en [Creación de una VPC con subredes públicas y privadas](#CHAP_Tutorials.CreateVPCDualStack.VPCAndSubnets) + **Subnet (Subred)**: elija una subred pública existente, como **subnet-*identificador* \$1 tutorial-dual-stack-subnet-public1-us-east-2a \$1 us-east-2a**, creada en [Para crear un grupo de seguridad de la VPC para una instancia de Amazon EC2 pública](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupEC2). + **Auto-assign Public IP (Asignar automáticamente IP pública)**: elija **Enable (Habilitar)**. + **Auto-assign IPv6 IP (Asignar automáticamente IP IPv6)**: elija **Enable (Habilitar)**. + **Firewall (security groups) (Firewall [grupos de seguridad])**: elija **Select an existing security group (Seleccionar un grupo de seguridad existente)**. + **Common security groups** (Grupos de seguridad comunes): elija un grupo de seguridad existente, como el `tutorial-securitygroup` creado en [Para crear un grupo de seguridad de la VPC para una instancia de Amazon EC2 pública](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupEC2). Asegúrese de que el grupo de seguridad que elija incluya reglas de entrada para acceso Secure Shell (SSH) y HTTP. ## Crear un clúster de base de datos en el modo de pila doble En este paso, debe crear un clúster de base de datos que se ejecute en modo de pila doble. **Para crear una instancia de base de datos** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En la esquina superior derecha de la consola, elija la Región de AWS en la que desea crear el clúster de base de datos. En este ejemplo se utiliza la región Este de EE. UU. (Ohio). 1. En el panel de navegación, elija **Databases** (Bases de datos). 1. Elija **Create database (Creación de base de datos)**. 1. En la página **Create database (Crear base de datos)**, asegúrese de que la opción **Standard Create (Creación estándar)** esté seleccionada y luego, elija el tipo de motor de base de datos Aurora MySQL. 1. En la sección **Conectivity (Conectividad)**, establezca estos valores: + **Network type (Tipo de red)**: elija **Dual-stack mode (Modo de pila doble)** ![\[Sección Network type (Tipo de red) de la consola con Dual-stack mode (Modo de pila doble) seleccionado\]](http://docs.aws.amazon.com/es_es/AmazonRDS/latest/AuroraUserGuide/images/dual-stack-mode.png) + **Virtual private cloud (VPC) (Nube privada virtual [VPC])**: elija una VPC existente con las subredes pública y privada, como **tutorial-dual-stack-vpc** (vpc-*identificador*) creada en [Creación de una VPC con subredes públicas y privadas](#CHAP_Tutorials.CreateVPCDualStack.VPCAndSubnets) La VPC debe tener subredes en diferentes zonas de disponibilidad. + **DB subnet group (Grupo de subredes de base de datos)**: grupo de subredes de base de datos para la VPC, como **tutorial-dual-stack-db-subnet-group**, creado en [Creación de un grupo de subredes de base de datos](#CHAP_Tutorials.CreateVPCDualStack.DBSubnetGroup) + **Public access (Acceso público)**: elija **No**. + **VPC security group (firewall) (Grupo de seguridad de VPC [firewall])**: seleccione **Choose existing (Elegir existente)**. + **Existing VPC security groups (Grupos de seguridad de la VPC existentes)**: elija un grupo de seguridad de la VPC existente configurado para el acceso público, como **tutorial-dual-stack-db-securitygroup** creado en [Creación de un grupo de seguridad de VPC para un clúster de base de datos privada](#CHAP_Tutorials.CreateVPCDualStack.SecurityGroupDB). Elimine otros grupos de seguridad, como el grupo de seguridad predeterminado, seleccionando la **X** asociada con cada uno de ellos. + **Availability Zone (Zona de disponibilidad)**: elija **us-west-2a**. Para evitar el tráfico entre zonas de disponibilidad, asegúrese de que la instancia de base de datos y la instancia de EC2 estén en la misma zona de disponibilidad. 1. En el resto de secciones, especifique los ajustes de configuración del clúster de base de datos. Para obtener más información acerca de cada ajuste, consulte [Configuración de clústeres de bases de datos de Aurora](Aurora.CreateInstance.md#Aurora.CreateInstance.Settings). ## Conectarse a la instancia de Amazon EC2 y a el clúster de base de datos Después de crear el clúster de base de datos y la instancia de Amazon EC2 en el modo de pila doble, puede conectarse a cada una mediante el protocolo IPv6. Para conectarse a una instancia de Amazon EC2 mediante el protocolo IPv6, siga las instrucciones indicadas en [Conexión con la instancia de Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html) en la *Guía del usuario de Amazon EC2*. Para conectarse al clúster de base de datos de Aurora MySQL desde la instancia de Amazon EC2, siga las instrucciones de [Conectarse a un clúster de base de datos de Aurora MySQL](CHAP_GettingStartedAurora.CreatingConnecting.Aurora.md#CHAP_GettingStartedAurora.Aurora.Connect). ## Eliminación de la VPC Después de crear la VPC y otros recursos para este tutorial, puede eliminarlos si ya no son necesarios. Si agregó recursos en la VPC que creó para este tutorial, es posible que primero tenga que eliminar estos para poder eliminar la VPC. Algunos ejemplos de recursos son las instancias de Amazon EC2 o los clústeres de base de datos. Para obtener más información, consulte [Eliminación de la VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#VPC_Deleting) en la *Guía del usuario de Amazon VPC*. **Para eliminar una VPC y los recursos relacionados** 1. Elimine el grupo de subredes de base de datos: 1. Abra la consola de Amazon RDS en [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. En el panel de navegación, elija **Subnet groups**. 1. Seleccione el grupo de subredes de base de datos a eliminar, como **tutorial-db-subnet-group**. 1. Elija **Delete (Eliminar)** y, a continuación, elija **Delete (Eliminar)** en la ventana de confirmación. 1. Anote el ID de la VPC: 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Seleccione **VPC Dashboard (Panel de control de VPC)** y, a continuación, seleccione **VPCs**. 1. En la lista, identifique la VPC que creó, como, por ejemplo, **tutorial-dual-stack-vpc**. 1. Anote el **ID de la VPC** que ha creado. Necesitará el ID de la VPC en los pasos subsiguientes. 1. Elimine los grupos de seguridad: 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Seleccione **VPC Dashboard (Panel de control de VPC)** y, a continuación, seleccione **Security Groups (Grupos de seguridad)**. 1. Seleccione el grupo de seguridad de la instancia de base de datos de Amazon RDS, como, por ejemplo, **tutorial-dual-stack-db-securitygroup**. 1. En **Actions (Acciones)**, elija **Delete security groups (Eliminar grupos de seguridad)** y, a continuación, seleccione **Delete (Eliminar)** en la página de confirmación. 1. En la página **Security Groups (Grupos de seguridad)**, seleccione el grupo de seguridad para la instancia de Amazon EC2, como, por ejemplo, **tutorial-dual-stack-securitygroup**. 1. En **Actions (Acciones)**, elija **Delete security groups (Eliminar grupos de seguridad)** y, a continuación, seleccione **Delete (Eliminar)** en la página de confirmación. 1. Elimine la puerta de enlace NAT: 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Seleccione **VPC Dashboard (Panel de control de VPC)** y, a continuación, seleccione **NAT Gateways (Puertas de enlace NAT)**. 1. Seleccione la puerta de enlace NAT de la VPC que creó. Utilice el ID de VPC para identificar la puerta de enlace NAT correcta. 1. En ** Actions (Acciones)**, seleccione **Delete NAT gateway (Eliminar puerta de enlace NAT)**. 1. En la página de confirmación, introduzca **delete** y elija **Eliminar**. 1. Elimine la VPC: 1. Abra la consola de Amazon VPC en [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/). 1. Seleccione **VPC Dashboard (Panel de control de VPC)** y, a continuación, seleccione **VPCs**. 1. Seleccione la VPC que desea eliminar, como, por ejemplo **tutorial-dual-stack-vpc**. 1. En **Actions (Acciones)**, elija **Delete VPC (Eliminar VPC)**. La página de confirmación muestra otros recursos asociados a la VPC que también se eliminarán, incluidas las subredes asociadas a ella. 1. En la página de confirmación, introduzca **delete** y elija **Eliminar**. 1. Libere las direcciones IP elásticas: 1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/). 1. Seleccione **EC2 Dashboard (Panel de EC2)** y, a continuación, seleccione **Elastic IPs (Direcciones IP elásticas)**. 1. Seleccione la dirección IP elástica que desea liberar. 1. Desde **Actions (Acciones)**, elija **Release Elastic IP addresses (Liberar direcciones IP elásticas)**. 1. En la página de confirmación, seleccione **Release (Liberar)**.