Amazon Redshift dejará de admitir la creación de nuevas UDF de Python a partir del parche 198. Las UDF de Python existentes seguirán funcionando hasta el 30 de junio de 2026. Para obtener más información, consulte la [publicación del blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
# Cifrado de datos
La protección de los datos se refiere a salvaguardarlos mientras se encuentran en tránsito (cuando se desplazan desde y hacia Amazon Redshift) y en reposo (cuando están almacenados en los discos de los centros de datos de Amazon Redshift). Los datos en tránsito se pueden proteger mediante el uso de SSL o cifrado del lado del cliente. Dispone de las siguientes opciones para proteger los datos en reposo en Amazon Redshift.
+ **Uso del cifrado del lado del servidor**: solicita a Amazon Redshift que cifre sus datos antes de guardarlos en los discos de sus centros de datos y que los descifre cuando descargue los objetos.
+ **Uso del cifrado del lado del cliente**: puede cifrar los datos del lado del cliente y cargar los datos cifrados en Amazon Redshift. En este caso, administra el proceso de cifrado, las claves de cifrado y las herramientas relacionadas.
# Cifrado en reposo
El cifrado del lado del servidor representa el cifrado de datos en reposo; esto implica que Amazon Redshift cifra opcionalmente los datos a medida que los escribe en sus centros de datos y los descifra cuando accede a ellos. Siempre que autentique su solicitud y tenga permiso de acceso, no existe diferencia alguna en la forma de obtener acceso a datos cifrados o sin cifrar.
Amazon Redshift protege los datos en reposo a través del cifrado. De forma opcional, puede proteger todos los datos almacenados en los discos en un clúster y todas las copias de seguridad en Amazon S3 con Advanced Encryption Standard AES-256.
Para administrar las claves que se usan para cifrar y descifrar los recursos de Amazon Redshift, utiliza [AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/). AWS KMS combina hardware y software seguros y de gran disponibilidad para proporcionar un sistema de administración de claves con escala para la nube. Si utiliza AWS KMS, puede crear claves de cifrado y definir las políticas que controlan cómo se pueden utilizar dichas claves. AWS KMS es compatible con AWS CloudTrail, lo que permite auditar el uso de claves para comprobar que las claves se utilizan de forma adecuada. Puede utilizar las claves de AWS KMS en combinación con Amazon Redshift y los servicios admitidos de AWS. Para obtener una lista de los servicios que admiten AWS KMS, consulte [Cómo los servicios de AWS usan AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services.html) en la *Guía para desarrolladores de AWS Key Management Service*.
Si decide administrar el clúster aprovisionado o la contraseña de administrador del espacio de nombres sin servidor con AWS Secrets Manager, Amazon Redshift también acepta una clave de AWS KMS adicional que AWS Secrets Manager utiliza para cifrar sus credenciales. Esta clave adicional puede ser una clave generada automáticamente en AWS Secrets Manager o una clave personalizada proporcionada por usted.
El editor de consultas v2 de Amazon Redshift almacena de forma segura la información introducida en el editor de consultas de la siguiente manera:
+ el nombre de recurso de Amazon (ARN) de la clave KMS que se utiliza para cifrar los datos del editor de consultas v2
+ la información de conexión de base de datos
+ los nombres y el contenido de archivos y carpetas
El editor de consultas v2 de Amazon Redshift cifra la información mediante el cifrado del nivel del bloque con su clave KMS o la clave KMS de la cuenta del servicio. El cifrado de los datos de Amazon Redshift se controla mediante las propiedades del clúster de Amazon Redshift.
**Topics**
+ [Cifrado de la base de datos de Amazon Redshift](working-with-db-encryption.md)
# Cifrado de la base de datos de Amazon Redshift
En Amazon Redshift, la base de datos se cifra de forma predeterminada para proteger los datos en reposo. El cifrado de la base de datos se aplica al clúster y también a las instantáneas.
Puede modificar un clúster no cifrado para utilizar el cifrado de AWS Key Management Service (AWS KMS). Para ello, puede usar una clave propiedad de AWS o una clave administrada por el cliente. Cuando modifica su clúster para habilitar el cifrado de AWS KMS, Amazon Redshift migra sus datos de manera automática a un nuevo clúster cifrado. Las instantáneas creadas a partir del clúster cifrado también se cifran. También puede migrar un clúster cifrado a un clúster sin cifrar modificando el clúster y cambiando la opción **Encrypt database (Cifrar base de datos)**. Para obtener más información, consulte [Cambio del cifrado del clúster](changing-cluster-encryption.md).
Aunque puede transformar el clúster cifrado predeterminado en uno sin cifrar después de crear el clúster, le recomendamos que mantenga cifrado el clúster que contenga datos confidenciales. Además, es posible que sea obligatorio utilizar cifrado según las directrices o regulaciones que rigen los datos. Por ejemplo, el Estándar de seguridad de datos (Data Security Standard, DSS) del sector de tarjetas de pago (Payment Card Industry, PCI), la Ley de Sarbanes-Oxley (SOX), la Ley de Portabilidad y Responsabilidad de Seguros Médicos (Health Insurance Portability and Accountability Act, HIPAA) y otras regulaciones similares proporcionan directrices para el manejo de tipos específicos de datos.
Amazon Redshift utiliza una jerarquía de claves de cifrado para cifrar la base de datos. Puede usar AWS Key Management Service (AWS KMS) o un módulo de seguridad por hardware (HSM) para administrar las claves de cifrado de nivel superior en esta jerarquía. El proceso que utiliza Amazon Redshift para el cifrado varía según la manera en que usted administra las claves. Amazon Redshift se integra automáticamente a AWS KMS, pero no a un HSM. Cuando utilice un HSM, deberá usar certificados de cliente y servidor para configurar una conexión segura entre Amazon Redshift y el HSM.
**importante**
Amazon Redshift puede perder el acceso a la clave de KMS para un clúster aprovisionado o un espacio de nombres sin servidor al desactivar la clave de KMS administrada por el cliente. En estos casos, Amazon Redshift realiza una copia de seguridad del almacén de datos de Amazon Redshift y la coloca en un estado `inaccessible-kms-key` durante 14 días. Si restaura la clave de KMS dentro de ese periodo, Amazon Redshift restablecerá el acceso y el almacén funcionará con normalidad. Si el periodo de 14 días finaliza sin que se restablezca la clave de KMS, Amazon Redshift eliminará el almacén de datos. Mientras un almacén se encuentra en estado `inaccessible-kms-key`, tiene las siguientes características:
No puede ejecutar ninguna consulta en el almacén de datos.
Si el almacén de datos es el almacén productor de un recurso compartido de datos, no puede ejecutar consultas de recurso compartido de datos en él desde almacenes del consumidor.
No puede crear copias de instantáneas entre regiones.
Para obtener información sobre cómo restaurar una clave de KMS desactivada, consulte [Habilitar y desactivar claves](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) en la *Guía para desarrolladores de AWS Key Management Service*. Si se ha eliminado la clave de KMS del almacén, puede utilizar la copia de seguridad para crear un nuevo almacén de datos antes de eliminar el almacén de estado `inaccessible-kms-key`.
## Mejoras en el proceso de cifrado para mejorar el rendimiento y la disponibilidad
### Cifrado con nodos RA3
Las actualizaciones del proceso de cifrado de los nodos RA3 han mejorado mucho la experiencia. Las consultas de lectura y las de escritura se pueden ejecutar durante el proceso con un menor impacto en el rendimiento del cifrado. Además, el cifrado finaliza mucho más rápido. Los pasos del proceso actualizado incluyen una operación de restauración y la migración de los metadatos del clúster a un clúster de destino. La experiencia mejorada se aplica a tipos de cifrado como AWS KMS, por ejemplo. Cuando tiene volúmenes de datos a escala de petabytes, la operación se ha reducido de semanas a días.
Antes de cifrar el clúster, si tiene previsto seguir ejecutando cargas de trabajo de bases de datos, puede mejorar el rendimiento y acelerar el proceso agregando nodos con un cambio de tamaño elástico. No puede utilizar el cambio de tamaño elástico cuando el cifrado está en proceso, así que hágalo antes de cifrar. Tenga en cuenta que agregar nodos suele generar un costo más alto.
### Cifrado con otros tipos de nodos
Al cifrar un clúster con nodos DC2, no tiene la capacidad de ejecutar consultas de escritura, como ocurre con los nodos RA3. Solo se pueden ejecutar consultas de lectura.
### Notas de uso para el cifrado con nodos RA3
La siguiente información y los recursos le ayudan a prepararse para el cifrado y a monitorear el proceso.
+ **Ejecución de consultas después de iniciar el cifrado**: una vez iniciado el cifrado, las lecturas y escrituras están disponibles en unos quince minutos. El tiempo que tarda todo el proceso de cifrado en completarse depende de la cantidad de datos del clúster y de los niveles de carga de trabajo.
+ **Cuánto tarda el cifrado?** - El tiempo necesario para cifrar los datos depende de varios factores: entre ellos, la cantidad de cargas de trabajo en ejecución, los recursos informáticos que se utilizan, la cantidad de nodos y el tipo de nodos. Le recomendamos que primero realice el cifrado en un entorno de pruebas. Como regla general, si trabaja con volúmenes de datos en petabytes, es probable que el cifrado tarde entre 1 y 3 días en completarse.
+ **Cómo sé que el cifrado ha finalizado?** - Tras habilitar el cifrado, al completar la primera instantánea se confirma que el cifrado se ha completado.
+ **Revertir el cifrado**: si necesita revertir la operación de cifrado, la mejor forma de hacerlo es restaurar desde la copia de seguridad más reciente realizada antes de iniciar el cifrado. Deberá volver a aplicar las actualizaciones nuevas (actualizaciones/eliminaciones/inserciones) después de la última copia de seguridad.
+ **Realizar una restauración de tablas**: tenga en cuenta que no puede restaurar una tabla de un clúster no cifrado a un clúster cifrado.
+ **Cifrado de un clúster de un solo nodo**: el cifrado de un clúster de un solo nodo tiene limitaciones de rendimiento. Se tarda más que el cifrado en un clúster de varios nodos.
+ **Creación de una copia de seguridad después del cifrado**: al cifrar los datos del clúster, no se crea una copia de seguridad hasta que el clúster esté completamente cifrado. El tiempo que dure puede variar. El tiempo necesario para realizar la copia de seguridad puede ser de horas a días, en función del tamaño del clúster. Una vez completo el cifrado, es posible que se produzca un retraso antes de que pueda crear una copia de seguridad.
Tenga en cuenta que como durante el proceso de cifrado se produce una operación de copia de seguridad y restauración, las tablas o vistas materializadas creadas con `BACKUP NO` no se retienen. Para obtener más información, consulte [CREATE TABLE](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html) o [CREATE MATERIALIZED VIEW](https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-create-sql-command.html).
**Topics**
+ [Mejoras en el proceso de cifrado para mejorar el rendimiento y la disponibilidad](#resize-classic-encryption)
+ [Cifrado mediante AWS KMS](#working-with-aws-kms)
+ [Cifrado mediante módulos de seguridad de hardware](#working-with-HSM)
+ [Rotación de claves de cifrado](#working-with-key-rotation)
+ [Cambio del cifrado del clúster](changing-cluster-encryption.md)
+ [Migración a un clúster cifrado con HSM](migrating-to-an-encrypted-cluster.md)
+ [Rotación de las claves de cifrado](manage-key-rotation-console.md)
## Cifrado mediante AWS KMS
Cuando elige AWS KMS para administrar las claves con Amazon Redshift, hay una jerarquía de cuatro niveles en las claves de cifrado. Estas claves, en orden jerárquico, son la clave raíz, una clave de cifrado de clúster (CEK), una clave de cifrado de base de datos (DEK) y claves de cifrado de datos.
Cuando inicia el clúster, Amazon Redshift devuelve una lista de las AWS KMS keys que Amazon Redshift o la cuenta de AWS ha creado o tiene permiso para utilizar en AWS KMS. Seleccione una clave KMS para utilizar como la clave raíz en la jerarquía de cifrado.
De forma predeterminada, Amazon Redshift selecciona una clave propiedad de AWS generada automáticamente como clave raíz para que la cuenta de AWS la utilice en Amazon Redshift.
Si no desea utilizar la clave predeterminada, debe tener (o crear) una clave KMS administrada por el cliente por separado en AWS KMS antes de lanzar su clúster en Amazon Redshift. Las claves administradas por el cliente le ofrecen una mayor flexibilidad, incluida la opción de crear, rotar, desactivar, definir los controles de acceso y auditar las claves de cifrado que se utilizan para proteger los datos. Para obtener más información sobre la creación de claves KMS, consulte [Creating Keys](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) (Creación de claves) en la *Guía para desarrolladores de AWS Key Management Service*.
Si desea utilizar una clave de AWS KMS de otra cuenta de AWS, debe tener permiso para utilizar la clave y especificar su nombre de recurso de Amazon (ARN) en Amazon Redshift. Para obtener más información acerca del acceso a las claves en AWS KMS, consulte [Control del acceso a sus claves](https://docs.aws.amazon.com/kms/latest/developerguide/control-access.html) en la *Guía para desarrolladores de AWS Key Management Service*.
Después de elegir una clave raíz, Amazon Redshift le solicitará a AWS KMS que genere una clave de datos y la cifre con la clave raíz seleccionada. Esta clave de datos se utiliza como la CEK en Amazon Redshift. AWS KMS exporta la CEK cifrada a Amazon Redshift, donde se almacena internamente en el disco en una red separada del clúster junto con la autorización de la clave KSM y el contexto de cifrado de la CEK. Solo se exporta la CEK cifrada a Amazon Redshift; la clave KMS permanece en AWS KMS. Amazon Redshift también transmite la CEK cifrada a través de un canal seguro al clúster y la carga en la memoria. Luego, Amazon Redshift llama a AWS KMS para descifrar la CEK y carga la CEK descifrada en la memoria. Para obtener más información acerca de las autorizaciones, el contexto de cifrado y otros conceptos relacionados con AWS KMS, consulte [Conceptos](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html) en la *Guía para desarrolladores de AWS Key Management Service*.
A continuación, Amazon Redshift genera aleatoriamente una clave para utilizarla como la DEK y la carga en la memoria del clúster. La CEK descifrada se utiliza para cifrar la DEK, que luego se transmite a través de un canal seguro desde el clúster para que la almacene internamente Amazon Redshift en el disco a través de una red separada del clúster. Como sucede con la CEK, ambas versiones cifradas y descifradas de la DEK se cargan en la memoria del clúster. La versión descifrada de la DEK se utiliza posteriormente para cifrar las claves de cifrado individuales que se generan aleatoriamente para cada bloque de datos de la base de datos.
Cuando se reinicia el clúster, Amazon Redshift comienza a funcionar con las versiones cifradas de la CEK y la DEK almacenadas internamente, las vuelve a cargar en la memoria y, luego, llama a AWS KMS para que descifre de nuevo la CEK con la clave KSM para poder cargarla en la memoria. La CEK descifrada se utiliza posteriormente para descifrar la DEK nuevamente, y la DEK descifrada se carga en la memoria y se utiliza para cifrar y descifrar las claves de bloque de datos según sea necesario.
Para obtener más información acerca de la creación de clústeres de Amazon Redshift que están cifrados con claves de AWS KMS, consulte [Creación de un clúster](create-cluster.md).
### Copia de instantáneas cifradas por AWS KMS en otra Región de AWS
Las claves de AWS KMS son específicas de una Región de AWS. Si desea habilitar la copia de instantáneas de Amazon Redshift desde un clúster de origen cifrado a otra Región de AWS, pero desea utilizar una clave AWS KMS propia para instantáneas en el destino, debe configurar una concesión para que Amazon Redshift utilice una clave raíz en la cuenta en la Región de AWS de destino. Esta concesión permite a Amazon Redshift cifrar instantáneas en la Región de AWS de destino. Si desea que las instantáneas en el destino estén cifradas por una clave propiedad de Región de AWS, no necesita configurar ninguna concesión en la Región de AWS de destino. Para obtener más información acerca de la copia de instantáneas entre regiones, consulte [Copia de una instantánea a otra región de AWS](cross-region-snapshot-copy.md).
**nota**
Si habilita la copia de instantáneas desde un clúster cifrado y utiliza AWS KMS como la clave raíz, no puede cambiar el nombre del clúster, ya que el nombre del clúster es parte del contexto de cifrado. Si debe cambiar el nombre del clúster, puede desactivar la copia de instantáneas en la región de AWS de origen, cambiar el nombre del clúster y, luego, configurar y habilitar de nuevo la copia de instantáneas.
A continuación se detalla el proceso para configurar la autorización para la copia de instantáneas.
1. En la región de AWS de destino, cree una autorización de copia de instantáneas llevando a cabo las siguientes acciones:
+ Si no dispone de una clave de AWS KMS, cree una. Para obtener más información sobre cómo crear claves de AWS KMS, consulte [Creación de claves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía para desarrolladores de AWS Key Management Service*.
+ Especifique un nombre para la autorización de copia de instantáneas. Este nombre debe ser único en esa región de AWS para su cuenta de AWS.
+ Especifique el ID de la clave de AWS KMS para la que crea la autorización. Si no especifica un ID de clave, la autorización se aplica a la clave predeterminada.
1. En la región de AWS de origen, habilite la copia de instantáneas y especifique el nombre de la autorización de copia de instantáneas que creó en la región de AWS de destino.
Este proceso anterior solo es necesario si habilita la copia de instantáneas a través de la AWS CLI, la API de Amazon Redshift o los SDK. Si utiliza la consola, Amazon Redshift proporciona el flujo de trabajo adecuado para configurar la autorización cuando usted habilita la copia de instantáneas entre regiones. Para obtener más información acerca de la configuración para copiar instantáneas entre regiones con clústeres cifrados por AWS KMS mediante la consola, consulte [Configuración de la copia de instantáneas entre regiones para un clúster cifrado por AWS KMS](xregioncopy-kms-encrypted-snapshot.md).
Antes de copiar la instantánea en la región de AWS de destino, Amazon Redshift descifra la instantánea con la clave raíz en la región de AWS de origen y la vuelve a cifrar temporalmente utilizando una clave de RSA generada de forma aleatoria que Amazon Redshift administra de manera interna. Luego, Amazon Redshift copia la instantánea a través de un canal seguro en la región de AWS de destino, descifra la instantánea con la clave de RSA administrada internamente y, a continuación, vuelve a cifrar la instantánea con la clave raíz en la región de AWS de destino.
## Cifrado mediante módulos de seguridad de hardware
Si no utiliza AWS KMS para la administración de las claves, puede usar un módulo de seguridad de hardware (HSM) para administrar las claves con Amazon Redshift.
**importante**
No se admite el cifrado de HSM para los tipos de nodos DC2 y RA3.
Los HSM son dispositivos que proporcionan control directo de la generación y administración de claves. Proporcionan más seguridad, ya que separan la administración de claves de las capas de aplicación y base de datos. Amazon Redshift admite AWS CloudHSM Classic para la administración de claves. El proceso de cifrado es diferente cuando usa HSM para administrar las claves de cifrado en lugar de AWS KMS.
**importante**
Amazon Redshift solo es compatible con AWS CloudHSM Classic. No se admite el servicio AWS CloudHSM más reciente.
AWS CloudHSM Classic está cerrado para los clientes nuevos. Para obtener más información, consulte [Precios de CloudHSM Classic](https://aws.amazon.com/cloudhsm/pricing-classic/). AWS CloudHSM Classic no está disponible en todas las regiones de AWS. Para obtener más información acerca de las regiones de AWS disponibles, consulte la [Tabla de regiones de AWS](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).
Cuando configura el clúster para utilizar un HSM, Amazon Redshift envía una solicitud al HSM para generar y almacenar una clave para utilizarla como la CEK. Sin embargo, a diferencia de AWS KMS, el HSM no exporta la CEK a Amazon Redshift. En cambio, Amazon Redshift genera aleatoriamente la DEK en el clúster y la transmite al HSM para que se cifre con la CEK. El HSM devuelve la DEK cifrada a Amazon Redshift, donde se cifra aún más utilizando una clave raíz interna que se genera de forma aleatoria y se almacena internamente en el disco en una red separada del clúster. Amazon Redshift también carga la versión descifrada de la DEK en la memoria del clúster para que se pueda utilizar para cifrar y descifrar las claves individuales de los bloques de datos.
Si se reinicia el clúster, Amazon Redshift descifra la DEK con doble cifrado que se almacenó de forma interna con la clave raíz interna para que la DEK almacenada de forma interna vuelva al estado cifrado por la CEK. Luego, la DEK cifrada por la CEK se transmite al HSM para que se descifre y transfiera de nuevo a Amazon Redshift, donde se puede cargar en la memoria otra vez para utilizarla con las claves individuales de los bloques de datos.
### Configuración de una conexión segura entre Amazon Redshift y un HSM
Cuando elige utilizar un HSM para la administración de la clave del clúster, debe configurar un enlace de red seguro entre Amazon Redshift y el HSM. Para hacerlo, necesita configurar los certificados de cliente y servidor. La conexión segura se utiliza para transmitir las claves de cifrado entre el HSM y Amazon Redshift durante las operaciones de cifrado y descifrado.
Amazon Redshift crea un certificado público de cliente a partir de un par de claves, una privada y otra pública generadas aleatoriamente. Estas se cifran y almacenan internamente. Descargue y registre el certificado de cliente público en el HSM, y asígnelo a la partición de HSM aplicable.
Tiene que proporcionar a Amazon Redshift la dirección IP del HSM, el nombre de partición del HSM, la contraseña de partición del HSM y un certificado de servidor del HSM público, que se cifra utilizando una clave raíz interna. Amazon Redshift completa el proceso de configuración y verifica que puede conectarse al HSM. Si no puede conectarse, el clúster se coloca en el estado INCOMPATIBLE\$1HSM y no se crea. En este caso, debe eliminar el clúster incompleto y volver a intentarlo.
**importante**
Cuando modifica el clúster para que use una partición de HSM diferente, Amazon Redshift verifica que pueda conectarse a la nueva partición, pero no verifica si existe una clave de cifrado válida. Antes de usar la nueva partición, debe replicar las claves en la nueva partición. Si el clúster se reinicia y Amazon Redshift no puede encontrar una clave válida, el reinicio produce un error. Para obtener más información, consulte [Replicación de claves en varios HSM](https://docs.aws.amazon.com/cloudhsm/latest/userguide/cli-clone-hapg.html).
Después de la configuración inicial, si Amazon Redshift no puede conectarse al HSM, se registra un evento. Para obtener más información acerca de estos eventos, consulte [Notificaciones de eventos de Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-event-notifications.html).
## Rotación de claves de cifrado
En Amazon Redshift, puede rotar las claves de cifrado de los clústeres cifrados. Cuando inicia el proceso de rotación de claves, Amazon Redshift rota la CEK del clúster especificado y de cualquier instantánea automatizada o manual del clúster. Amazon Redshift también rota la DEK del clúster especificado, pero no puede rotar la DEK de las instantáneas mientras están almacenadas internamente en Amazon Simple Storage Service (Amazon S3) y permanecen cifradas con la DEK existente.
Mientras la rotación está en curso, el clúster entra en el estado ROTATING\$1KEYS hasta que finaliza el proceso, momento en el que vuelve al estado AVAILABLE. Amazon Redshift administra el descifrado y el recifrado durante el proceso de rotación de claves.
**nota**
No puede cambiar claves para instantáneas que no tienen un clúster de origen. Antes de eliminar un clúster, verifique si sus instantáneas dependen de una rotación de claves.
Debido a que el clúster no está disponible momentáneamente durante el proceso de rotación de claves, debe cambiar las claves solo cuando lo requieran los datos o cuando sospeche que las claves están en riesgo. Como práctica recomendada, debe revisar el tipo de datos que almacena y planificar la frecuencia con la que cambia las claves que cifran esos datos. La frecuencia de la rotación de claves varía según las políticas corporativas de seguridad de datos y cualquier estándar que se refiera a información confidencial y conformidad normativa. Asegúrese de que el plan equilibre las necesidades de seguridad con las consideraciones de disponibilidad para el clúster.
Para obtener más información acerca de rotación de claves, consulte [Rotación de las claves de cifrado](manage-key-rotation-console.md).
# Cambio del cifrado del clúster
Puede modificar un clúster no cifrado para que use el cifrado de AWS Key Management Service (AWS KMS), mediante una clave propiedad de AWS o una clave administrada por el cliente. Cuando modifica su clúster para habilitar el cifrado de AWS KMS, Amazon Redshift migra sus datos de manera automática a un nuevo clúster cifrado. También puede migrar un clúster cifrado a un clúster no cifrado modificando el clúster con la AWS CLI, pero no con la Consola de administración de AWS.
Durante la operación de migración, el clúster se encuentra disponible en modo de solo lectura y su estado es **resizing (cambiando tamaño)**.
Si el clúster está configurado para permitir la copia de instantáneas entre regiones de AWS, debe desactivarla antes de cambiar el cifrado. Para obtener más información, consulte [Copia de una instantánea a otra región de AWS](cross-region-snapshot-copy.md) y [Configuración de la copia de instantáneas entre regiones para un clúster cifrado por AWS KMS](xregioncopy-kms-encrypted-snapshot.md). No puede habilitar el cifrado de Hardware Security Module (HSM, Módulo de seguridad de hardware) modificando el clúster. En lugar de ello, debe crear un nuevo clúster cifrado con HSM y migrar los datos al nuevo clúster. Para obtener más información, consulte [Migración a un clúster cifrado con HSM](migrating-to-an-encrypted-cluster.md).
------
#### [ Amazon Redshift console ]
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon Redshift en [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. En el menú de navegación, elija **Clusters** (Clústeres) y, a continuación, elija el clúster del cual desea modificar el cifrado.
1. Seleccione **Propiedades**.
1. En la sección **Database configurations** (Configuraciones de las bases de datos), elija **Edit** (Editar) y, luego, **Edit encryption** (Editar cifrado).
1. Elija alguna de las opciones de cifrado y seleccione **Save changes** (Guardar cambios).
------
#### [ AWS CLI ]
Para modificar su clúster no cifrado para usar AWS KMS, ejecute el comando de la CLI `modify-cluster` y especifique `–-encrypted`, tal como se muestra a continuación. De forma predeterminada, se utiliza la clave de KMS predeterminada. Para especificar una clave administrada por el cliente, incluya la opción `--kms-key-id`.
```
aws redshift modify-cluster --cluster-identifier --encrypted --kms-key-id
```
Para quitar el cifrado de su clúster, ejecute el siguiente comando de la CLI.
```
aws redshift modify-cluster --cluster-identifier --no-encrypted
```
------
# Migración a un clúster cifrado con HSM
Para migrar un clúster sin cifrar a un clúster cifrado mediante un módulo de seguridad de hardware (HSM), debe crear un nuevo clúster cifrado y trasladar los datos al nuevo clúster. No puede realizar una migración a un clúster cifrado con HSM modificando el clúster.
Para migrar de un clúster sin cifrar a un clúster cifrado con HSM, primero debe descargar los datos del clúster de origen existente. A continuación, vuelva a cargar los datos en un clúster nuevo, o clúster de destino, con la configuración de cifrado que desee. Para obtener más información sobre cómo lanzar un clúster cifrado, consulte [Cifrado de la base de datos de Amazon Redshift](working-with-db-encryption.md).
Durante el proceso de migración, el clúster de origen está disponible para consultas de solo lectura hasta el último paso. El último paso consiste en cambiar el nombre de los clústeres de destino y de origen, lo que cambia los puntos de enlace para que todo el tráfico se dirija al nuevo clúster de destino. El clúster de destino no está disponible hasta que se reinicia después de cambiarle el nombre. Suspenda todas las cargas de datos y otras operaciones de escritura en el clúster de origen mientras durante la transferencia de los datos.
**Para preparar la migración**
1. Identifique todos los sistemas dependientes que interactúan con Amazon Redshift, por ejemplo, las herramientas de inteligencia empresarial (BI) y los sistemas de extracción, transformación y carga (ETL).
1. Identifique las consultas de validación que permiten probar la migración.
Por ejemplo, puede utilizar la consulta siguiente para buscar el número de tablas definidas por el usuario.
```
select count(*)
from pg_table_def
where schemaname != 'pg_catalog';
```
La consulta siguiente devuelve una lista de todas las tablas definidas por el usuario y el número de filas de cada tabla.
```
select "table", tbl_rows
from svv_table_info;
```
1. Elija un buen momento para la migración. Para encontrar un momento en el que el uso del clúster sea mínimo, monitorice las métricas del clúster, como la utilización de la CPU y el número de conexiones a la base de datos. Para obtener más información, consulte [Visualización de datos de rendimiento del clúster](performance-metrics-perf.md).
1. Elimine las tablas que no se utilicen.
Para crear una lista de tablas con el número de veces que se ha consultado cada tabla, ejecute la consulta siguiente.
```
select database,
schema,
table_id,
"table",
round(size::float/(1024*1024)::float,2) as size,
sortkey1,
nvl(s.num_qs,0) num_qs
from svv_table_info t
left join (select tbl,
perm_table_name,
count(distinct query) num_qs
from stl_scan s
where s.userid > 1
and s.perm_table_name not in ('Internal worktable','S3')
group by tbl,
perm_table_name) s on s.tbl = t.table_id
where t."schema" not in ('pg_internal');
```
1. Lance un clúster cifrado nuevo.
Utilice el mismo número de puerto para el clúster de destino que para el clúster de origen. Para obtener más información sobre cómo lanzar un clúster cifrado, consulte [Cifrado de la base de datos de Amazon Redshift](working-with-db-encryption.md).
1. Configure el proceso de descarga y carga.
Puede utilizar la [utilidad Unload/Copy de Amazon Redshift](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/UnloadCopyUtility) para facilitar la migración de datos entre clústeres. La utilidad exporta los datos del clúster de origen a una ubicación en Amazon S3. Los datos se cifran con AWS KMS. A continuación, la utilidad importa automáticamente los datos en el clúster de destino. También puede usar la utilidad para limpiar Amazon S3 una vez finalizada la migración.
1. Ejecute una prueba para verificar el proceso y estimar durante cuánto tiempo deben suspenderse las operaciones de escritura.
Durante las operaciones de descarga y carga, mantenga la consistencia de los datos suspendiendo las cargas de datos y otras operaciones de escritura. Ejecute el proceso de descarga y carga usando una de sus tablas más grandes para realizar una estimación del tiempo.
1. Cree los objetos de base de datos, como esquemas, vistas y tablas. Los scripts de [AdminViews](https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AdminViews) del repositorio GitHub de AWS pueden ayudarlo a generar las instrucciones de lenguaje de definición de datos (DDL) necesarias.
**Para migrar el clúster**
1. Detenga todos los procesos ETL en el clúster de origen.
Para confirmar que no hay operaciones de escritura en proceso, utilice la consola de administración de Amazon Redshift para monitorear las IOPS de escritura. Para obtener más información, consulte [Visualización de datos de rendimiento del clúster](performance-metrics-perf.md).
1. Ejecute las consultas de validación que identificó anteriormente para recopilar información sobre el clúster de origen sin cifrar antes de la migración.
1. (Opcional) Cree una cola de administración de cargas de trabajo (WLM) para utilizar el máximo de recursos disponibles, tanto en el clúster de origen como en el de destino. Por ejemplo, cree una cola denominada `data_migrate` y configúrela con una memoria del 95 por ciento y una simultaneidad de 4. Para obtener más información, consulte [Enrutamiento de consultas a las colas en función de los grupos de usuarios y consultas](https://docs.aws.amazon.com/redshift/latest/dg/tutorial-wlm-routing-queries-to-queues.html) en la *Guía para desarrolladores de bases de datos de Amazon Redshift*.
1. Ejecute UnloadCopyUtility utilizando la cola `data_migrate`.
Monitoree el proceso de UNLOAD y COPY a través de la consola de Amazon Redshift.
1. Vuelva a ejecutar las consultas de validación y verifique que los resultados coinciden con los del clúster de origen.
1. Cambie el nombre de los clústeres de origen y de destino para intercambiar los puntos de enlace. Para evitar interrupciones, realice esta operación fuera del horario normal de trabajo.
1. Compruebe que puede conectarse al clúster de destino utilizando todos sus clientes SQL, como las herramientas de ETL y de generación de informes.
1. Cierre el clúster de origen sin cifrar.
# Rotación de las claves de cifrado
Puede utilizar el siguiente procedimiento para rotar las claves de cifrado con la consola de Amazon Redshift.
**Rotar las claves de cifrado de un clúster.**
1. Inicie sesión en la Consola de administración de AWS y abra la consola de Amazon Redshift en [https://console.aws.amazon.com/redshiftv2/](https://console.aws.amazon.com/redshiftv2/).
1. En el menú de navegación, elija **Clusters** (Clústeres) y, a continuación, elija el clúster del cual desea actualizar las claves de cifrado.
1. Para **Actions (Acciones)**, haga clic en **Rotate encryption (Rotar cifrado)** para mostrar la página **Rotate encryption keys (Rotar claves de cifrado)**.
1. En la página **Rotate encryption keys (Rotar claves de cifrado)**, haga clic en **Rotate encryption keys (Rotar claves de cifrado)**.
# Cifrado en tránsito
Puede configurar el entorno para proteger la confidencialidad y la integridad de los datos en tránsito.
Los detalles siguientes se aplican al cifrado de datos en tránsito entre un clúster de Amazon Redshift y clientes SQL a través de JDBC/ODBC:
+ Puede conectarse a clústeres de Amazon Redshift desde herramientas de cliente SQL mediante conexiones Java Database Connectivity (JDBC) y Open Database Connectivity (ODBC).
+ Amazon Redshift admite las conexiones de capa de conexión segura (SSL) para cifrar datos y los certificados de servidor para validar el certificado del servidor al que se conecta el cliente. El cliente se conecta al nodo principal de un clúster de Amazon Redshift. Para obtener más información, consulte [Configuración de las opciones de seguridad para las conexiones](connecting-ssl-support.md).
+ Para admitir las conexiones SSL, Amazon Redshift crea e instala los certificados emitidos por AWS Certificate Manager (ACM) en cada clúster. Para obtener más información, consulte [Migración a certificados de ACM para las conexiones SSL](connecting-transitioning-to-acm-certs.md).
+ Para proteger los datos en tránsito dentro de la nube de AWS, Amazon Redshift usa SSL con aceleración por hardware para comunicarse con Amazon S3 o Amazon DynamoDB en las operaciones de COPY, UNLOAD, copia de seguridad y restauración.
Los detalles siguientes se aplican al cifrado de datos en tránsito entre un clúster de Amazon Redshift y Amazon S3 o DynamoDB:
+ Amazon Redshift usa SSL con aceleración por hardware para comunicarse con Amazon S3 o DynamoDB en las operaciones de COPY, UNLOAD, copia de seguridad y restauración.
+ Redshift Spectrum admite el cifrado del lado del servidor (SSE) de Amazon S3 mediante el uso de la clave predeterminada de su cuenta administrada por AWS Key Management Service (KMS).
+ Puede cifrar las cargas de Amazon Redshift con Amazon S3 y AWS KMS. Para obtener más información, consulte [Encrypt Your Amazon Redshift Loads with Amazon S3 and AWS KMS](https://aws.amazon.com/blogs/big-data/encrypt-your-amazon-redshift-loads-with-amazon-s3-and-aws-kms/).
Los detalles siguientes se aplican al cifrado y firma de datos en tránsito entre los clientes de la AWS CLI, el SDK o la API, y los puntos de conexión de Amazon Redshift:
+ Amazon Redshift proporciona puntos de enlace HTTPS para cifrar datos en tránsito.
+ Para proteger la integridad de las solicitudes de la API a Amazon Redshift, las llamadas a la API deben estar firmadas por la persona que llama. Las llamadas se firman con un certificado X.509 o con la clave de acceso secreta de AWS del cliente, según el proceso de firma de Signature Version 4 (Sigv4). Para obtener más información, consulte [Proceso de firma Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) en la *Referencia general de AWS*.
+ Use la AWS CLI o alguno de los AWS SDK para efectuar solicitudes a AWS. Estas herramientas firman automáticamente las solicitudes con la clave de acceso especificada al configurar las herramientas.
Los detalles siguientes se aplican al cifrado de datos en tránsito entre los clústeres de Amazon Redshift y el editor de consultas V2 de Amazon Redshift:
+ Los datos se transmiten entre el editor de consultas v2 y los clústeres de Amazon Redshift a través de un canal con cifrado de TLS.
# Controles de cifrado de VPC con Amazon Redshift
Amazon Redshift admite los [controles de cifrado de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-encryption-controls.html), una característica de seguridad que lo ayuda a aplicar el cifrado en tránsito para todo el tráfico dentro de las VPC de una región y entre ellas. En este documento, se describe cómo utilizar los controles de cifrado de VPC con clústeres y grupos de trabajo sin servidor de Amazon Redshift.
Los controles de cifrado de las VPC proporcionan un control centralizado para supervisar y aplicar el cifrado en tránsito dentro de las VPC. Cuando se habilita en el modo obligatorio, se garantiza que todo el tráfico de la red esté cifrado en la capa de hardware (mediante el sistema AWS Nitro) o en la capa de aplicación (mediante TLS/SSL).
Amazon Redshift se integra con los controles de cifrado de VPC para ayudarlo a cumplir los requisitos de conformidad de sectores como el sanitario (HIPAA), el gobierno (FedRAMP) y el financiero (PCI DSS).
## Cómo funcionan los controles de cifrado de VPC con Amazon Redshift
Los controles de cifrado de VPC funcionan de dos modos:
+ Modo de supervisión: proporciona visibilidad del estado de cifrado de los flujos de tráfico y ayuda a identificar los recursos que permiten el tráfico no cifrado.
+ Modo obligatorio: impide la creación o el uso de recursos que permiten el tráfico sin cifrar dentro de la VPC. Todo el tráfico debe cifrarse en la capa de hardware (instancias basadas en Nitro) o en la capa de aplicación (TLS/SSL).
## Requisitos para usar los controles de cifrado de VPC
**Requisitos de tipo de instancia**
Amazon Redshift requiere que las instancias basadas en Nitro admitan los controles de cifrado de VPC. Todos los tipos de instancias de Redshift modernos admiten las capacidades de cifrado necesarias.
**Requisitos de SSL/TLS**
Cuando los controles de cifrado de VPC están habilitados en el modo obligatorio, el parámetro require\$1ssl debe estar establecido en true y no se puede desactivar. Esto garantiza que todas las conexiones de los clientes utilizan conexiones TLS cifradas.
## Migración a controles de cifrado de VPC
**Para clústeres y grupos de trabajo existentes**
No puede habilitar los controles de cifrado de la VPC en el modo de aplicación en una VPC que contenga grupos de trabajo sin servidor o clústeres de Redshift existentes. Consulte los siguientes pasos para usar los controles de cifrado si tiene un clúster o un grupo de trabajo existente:
1. Creación de una instantánea del clúster o espacio de nombres existente
1. Creación de una nueva VPC con los controles de cifrado de VPC habilitados en el modo de aplicación
1. Restaure desde la instantánea a la nueva VPC mediante una de estas operaciones:
+ Para los clústeres aprovisionados: utilice la operación `restore-from-cluster-snapshot`
+ Para sistemas sin servidor: utilice la operación `restore-from-snapshot` en el grupo de trabajo
**Al crear nuevos clústeres o grupos de trabajo en una VPC con los controles de cifrado habilitados, el parámetro require\$1ssl debe estar establecido en true.**
Amazon Redshift requiere que las instancias basadas en Nitro admitan los controles de cifrado de VPC. Todos los tipos de instancias de Redshift modernos admiten las capacidades de cifrado necesarias.
**Requisitos de SSL/TLS**
Cuando los controles de cifrado de VPC están habilitados en el modo obligatorio, el parámetro require\$1ssl debe estar establecido en true y no se puede desactivar. Esto garantiza que todas las conexiones de los clientes utilizan conexiones TLS cifradas.
## Consideraciones y limitaciones
Cuando utilice controles de cifrado de VPC en Amazon Redshift, tenga en cuenta lo siguiente:
**Restricciones estatales de VPC**
+ La creación de clústeres y grupos de trabajo se bloquea cuando los controles de cifrado de VPC están en estado `enforce-in-progress`
+ Debe esperar a que la VPC alcance el modo `enforce` antes de crear nuevos recursos
**Configuración de SSL**
+ Parámetro require\$1ssl: debe ser siempre `true` para los clústeres y grupos de trabajo creados en VPC con cifrado reforzado
+ Una vez que se crea un clúster o un grupo de trabajo en una VPC con cifrado reforzado, `require_ssl` no se puede desactivar durante toda su vida útil
**Disponibilidad por región**
Esta característica no está disponible en modo obligatorio con Amazon Redshift sin servidor en las siguientes regiones:
+ América del Sur (São Paulo)
+ Europa (Zúrich)
# Administración de claves
Puede configurar su entorno para proteger los datos con las claves.
+ Amazon Redshift se integra automáticamente a AWS Key Management Service (AWS KMS) para la administración de claves. AWS KMS utiliza el cifrado de sobres. Para obtener más información, consulte [Cifrado de sobre](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping).
+ Cuando las claves de cifrado se administran en AWS KMS, Amazon Redshift usa una arquitectura de cuatro niveles basada en claves para el cifrado. La arquitectura consta de claves de cifrado de datos AES-256 generadas aleatoriamente, una clave de base de datos, una clave de clúster y una clave raíz. Para obtener más información, consulte [Cómo Amazon Redshift usa AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-redshift.html).
+ Puede crear su propia clave administrada por el cliente en AWS KMS. Para obtener más información, consulte [Creación de claves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html).
+ También puede importar su propio material de claves para las nuevas AWS KMS keys. Para obtener más información, consulte [Importación de material de claves en AWS Key Management Service (AWS KMS)](https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html).
+ Amazon Redshift admite la administración de claves de cifrado en módulos de seguridad de hardware (HSM) externos. El HSM puede estar ubicado en las instalaciones o ser AWS CloudHSM. Cuando utilice un HSM, deberá usar certificados de cliente y servidor para configurar una conexión segura entre Amazon Redshift y el HSM. Amazon Redshift solo admite AWS CloudHSM Classic para la administración de claves. Para obtener más información, consulte [Cifrado mediante módulos de seguridad de hardware](working-with-db-encryption.md#working-with-HSM). Para obtener más información sobre AWS CloudHSM, consulte [¿Qué es AWS CloudHSM?](https://docs.aws.amazon.com/cloudhsm/latest/userguide/introduction.html)
+ Puede cambiar las claves de cifrado para los clústeres cifrados. Para obtener más información, consulte [Rotación de claves de cifrado](working-with-db-encryption.md#working-with-key-rotation).