# 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/).