Cifrado de la base de datos de Amazon Redshift
En Amazon Redshift, puede habilitar el cifrado de la base de datos de los clústeres para proteger los datos en reposo. Cuando habilita el cifrado para un clúster, se cifran los bloques de datos y metadatos del sistema para el clúster y sus instantáneas.
Puede habilitar el cifrado al lanzar el clúster o puede modificar un clúster sin cifrar para que utilice el cifrado AWS Key Management Service (AWS KMS). Para ello, puede usar una clave administrada por 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.
Si bien el cifrado es una configuración opcional en Amazon Redshift, le recomendamos habilitarlo para los clústeres que contengan información confidencial. 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.
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 NOno se retienen. Para obtener más información, consulte CREATE TABLE o CREATE MATERIALIZED VIEW.
Temas
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 lanza el clúster, Amazon Redshift devuelve una lista de AWS KMS keys que su cuenta de AWS ha creado o tiene permiso para usar 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 la clave predeterminada como la clave raíz. La clave predeterminada es una clave administrada por AWS que se crea para la cuenta de AWS, la cual se utilizará en Amazon Redshift. AWS KMS crea esta clave la primera vez que lanza un clúster cifrado en una región de AWS y elige la clave predeterminada.
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 (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 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 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.
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 habilita la copia de instantáneas de Amazon Redshift en otra región de AWS, y el clúster de origen y sus instantáneas están cifrados con una clave raíz de AWS KMS, deberá configurar una autorización para que Amazon Redshift pueda utilizar una clave raíz en la región de AWS de destino. Esta autorización permite a Amazon Redshift cifrar instantáneas 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.
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.
-
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 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.
-
-
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.
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
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_HSM 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.
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.
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_KEYS 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.
