Cifrado de datos con una clave administrada por el cliente en Azure Database for PostgreSQL: Servidor flexible

SE APLICA A: Azure Database for PostgreSQL: servidor flexible

El servidor flexible de Azure Database for PostgreSQL usa Cifrado de Azure Storage para cifrar los datos en reposo de forma predeterminada mediante claves administradas por Microsoft. Para los usuarios del servidor flexible de Azure Database for PostgreSQL, es similar al cifrado de datos transparente en otras bases de datos, como SQL Server.

Muchas organizaciones requieren control total del acceso a los datos mediante una clave administrada por el cliente (CMK). El cifrado de datos con CMK para el servidor flexible de Azure Database for PostgreSQL le permite traer la clave (BYOK) para la protección de datos en reposo. También permite a las organizaciones implementar la separación de tareas en la administración de claves y datos. Con el cifrado de CMK, es responsable y, en control total, del ciclo de vida de una clave, de los permisos de uso de claves y de la auditoría de las operaciones en las claves.

El cifrado de datos con CMK para el servidor flexible de Azure Database for PostgreSQL se establece en el nivel de servidor. Para un servidor determinado, se usa un tipo de CMK denominado clave de cifrado de claves (KEK) para cifrar la clave de cifrado de datos (DEK) del servicio. KEK es una clave asimétrica almacenada en una instancia de Azure Key Vault administrada por el cliente y de su propiedad. La KEK y DEK se describen con más detalle más adelante en este artículo.

Key Vault es un sistema de administración de claves externas basado en la nube. Presenta alta disponibilidad y ofrece almacenamiento seguro y escalable para claves criptográficas RSA, respaldadas opcionalmente por módulos de seguridad de hardware (HSM) con certificación FIPS 140. No permite acceso directo a una clave almacenada, pero proporciona servicios de cifrado y descifrado a entidades autorizadas. Key Vault puede generar la clave, importarla o hacer que se transfiera desde un dispositivo HSM local.

Ventajas

El cifrado de datos con CMK para el servidor flexible de Azure Database for PostgreSQL proporciona las siguientes ventajas:

• Controla completamente el acceso a los datos. Puede quitar una clave para que una base de datos sea inaccesible.

• Puede controlar completamente el ciclo de vida de una clave, incluida la rotación de la clave para alinearse con las directivas corporativas.

• Puede administrar y organizar las claves de forma centralizada en Key Vault.

• Activar el cifrado no afecta al rendimiento con o sin CMK, ya que PostgreSQL se basa en la capa de Azure Storage para el cifrado de datos en ambos escenarios. La única diferencia es que cuando se usa una CMK, la clave de cifrado de Azure Storage (que realiza el cifrado de datos real) está cifrada.

• Puede implementar una separación de tareas entre los responsables de seguridad, los administradores de bases de datos y los administradores del sistema.

Terminología

Clave de cifrado de datos (DEK): Una clave AES 256 simétrica que se usa para cifrar una partición o un bloque de datos. El cifrado de cada bloque de datos con una clave diferente dificulta los ataques de criptoanálisis. El proveedor de recursos o la instancia de aplicación que cifra y descifra un bloque específico necesita acceso a los DEK. Cuando se reemplaza una DEK por una nueva clave, solo se deben volver a cifrar los datos de su bloque asociado con la nueva clave.

Clave de cifrado de claves (KEK): Una clave de cifrado que se usa para cifrar los DEK. Una KEK que nunca abandona Key Vault permite el cifrado y control de las DEK. La entidad que tiene acceso a la KEK puede ser diferente de la entidad que requiere los DEK. Dado que la KEK es necesaria para descifrar los DEK, la KEK es efectivamente un único punto por el que se pueden eliminar DEK (eliminando la KEK).

Las DEK, cifradas con una KEK, se almacenan por separado. Solo una entidad que tenga acceso a la KEK puede descifrar estos DEK. Para más información, consulte Seguridad del cifrado en reposo.

Funcionamiento del cifrado de datos con una CMK

Se usa unaidentidad administrada asignada por el usuario de Microsoft Entra para conectarse y recuperar una CMK. Para crear una identidad, siga este tutorial.

Para que un servidor PostgreSQL use CMK almacenados en Key Vault para el cifrado de la DEK, un administrador de Key Vault proporciona los siguientes derechos de acceso a la identidad administrada que creó:

• obtener: Para recuperar la parte pública y las propiedades de la clave en Key Vault.

• lista: Para enumerar e iterar mediante claves de Key Vault.

• wrapKey: Para cifrar la DEK. La DEK cifrada se almacena en Azure Database for PostgreSQL.

• unwrapKey: Para descifrar la DEK. Azure Database for PostgreSQL necesita la DEK descifrada para cifrar y descifrar los datos.

El administrador de Key Vault también puede habilitar el registro de eventos de auditoría de Key Vault, por lo que se pueden auditar más adelante.

Como alternativa a la asignación dederechos de acceso, como se ha explicado anteriormente, puede crear una nueva asignación de roles de RBAC de Azure con el rol Usuario de cifrado del servicio criptográfico de Key Vault.

Importante

Si no se proporcionan los derechos de acceso anteriores o la asignación de RBAC a una identidad administrada para el acceso a Key Vault, podría producirse un error al capturar una clave de cifrado y al configurar la característica CMK.

Al configurar el servidor para que use la CMK almacenada en Key Vault, el servidor envía la DEK a Key Vault para el cifrado. Key Vault devuelve las DEK cifradas que se almacenan en la base de datos del usuario. Cuando sea necesario, el servidor envía la DEK protegida a Key Vault para el descifrado. Los auditores pueden usar Azure Monitor para revisar los registros de eventos de auditoría de Key Vault, si el registro está activado.

Requisitos de configuración del cifrado de datos para un servidor flexible de Azure Database for PostgreSQL

Estos son los requisitos para configurar Key Vault:

• Key Vault y Azure Database para PostgreSQL Flexible Server deben pertenecer al mismo tenant de Microsoft Entra. No se admiten las interacciones de servidor y Key Vault entre inquilinos. Para mover los recursos de Key Vault posteriormente, es necesario volver a configurar el cifrado de datos.

• Los Días para conservar los almacenes eliminados valor de Key Vault deben estar 90. Si configuró la instancia de Key Vault existente con un número inferior, debe crear una nueva instancia de Key Vault porque no se puede modificar una instancia después de la creación.

• Se recomienda establecer Días durante los cuales se conservarán los almacenes eliminados de Key Vault en 90 días. En caso de que haya configurado una instancia de Key Vault existente con un número inferior, debe seguir siendo válida. Sin embargo, si desea modificar esta configuración y aumentar el valor, es necesario crear una nueva instancia de Key Vault. Una vez creada una instancia, no es posible modificar su configuración.

• Habilite la característica de eliminación temporal en Key Vault para ayudar a proteger contra la pérdida de datos si se elimina accidentalmente una clave o una instancia de Key Vault. Key Vault conserva los recursos eliminados temporalmente durante 90 días a menos que el usuario los recupere o purgue mientras tanto. Las acciones de recuperación y purga tienen permisos propios asociados a una directiva de acceso a Key Vault.

  La característica de eliminación temporal está desactivada de forma predeterminada, pero puede activarla a través de PowerShell o la CLI de Azure. No se puede activar a través de Azure Portal.

• Habilite la protección de purga para aplicar un período de retención obligatorio para almacenes eliminados y objetos de almacén.

• Conceda a la instancia de servidor flexible de Azure Database for PostgreSQL acceso a Key Vault con los permisos obtener, lista, wrapKey, y unwrapKey, mediante su identidad administrada única. Como alternativa, cree una nueva asignación de roles de RBAC de Azure con el rol Usuario de cifrado del servicio criptográfico de Key Vault para la identidad administrada.

Estos son los requisitos para configurar la CMK en el servidor flexible de Azure Database for PostgreSQL:

• La CMK que se va a usar para cifrar la DEK solo puede ser asimétrica, RSA o RSA-HSM. Se admiten los tamaños de clave de 2048, 3072 y 4096.

• La fecha y hora de activación de claves (si se establece) deben estar en el pasado. La fecha y hora de expiración (si se establece) deben estar en el futuro.

• La clave debe estar en estado *Enabled-.

• Si va a importar una clave existente en Key Vault, proporciónela en los formatos de archivo admitidos (.pfx, .byok, o .backup).

Recomendaciones

Al usar una CMK para el cifrado de datos, estas son recomendaciones para configurar Key Vault:

• Establezca un bloqueo de recursos en Key Vault para controlar quién puede eliminar este recurso crítico y evitar la eliminación accidental o no autorizada.

• Habilite la auditoría y la generación de informes en todas las claves de cifrado. Key Vault proporciona registros que son fáciles de insertar en otras herramientas de administración de eventos e información de seguridad (SIEM). Los registros de Azure Monitor son un ejemplo de un servicio que ya está integrado.

• Para bloquear Key Vault, seleccione Deshabilitar el acceso público y Permitir que los servicios de Microsoft de confianza omitan este firewall.

  

Nota:

Después de seleccionar Deshabilitar el acceso público y Permitir que los servicios de Microsoft de confianza omitan este firewall, es posible que reciba un error similar al siguiente al intentar usar el acceso público para administrar Key Vault a través del portal: "Ha habilitado el control de acceso a la red. Solo las redes permitidas tendrán acceso a este almacén de claves". Este error no impide la capacidad de proporcionar claves durante la instalación de CMK o capturar claves de Key Vault durante las operaciones del servidor.

Estas son las recomendaciones para configurar una CMK:

• Mantenga una copia de la CMK en un lugar seguro o guárdelo en el servicio de custodia.

• Si Key Vault genera la clave, cree una copia de seguridad de claves antes de usar la clave por primera vez. Solo se puede restaurar la copia de seguridad en Key Vault.

Revocación accidental del acceso a la clave de Key Vault

Es posible que alguien con derechos de acceso suficientes para Key Vault deshabilite accidentalmente el acceso del servidor a la clave:

• Revocar los permisos list, get, wrapKey, y unwrapKey de la instancia de Key Vault de la identidad usada para recuperar la clave en KeyVault.

• Eliminación de la clave.

• Eliminación de la instancia de Key Vault.

• Cambio de las reglas de firewall de Key Vault.

• Eliminación de la identidad administrada del servidor en Microsoft Entra ID.

Supervisión de CMK en Key Vault

Para supervisar el estado de la base de datos y activar alertas para la pérdida de acceso al protector de cifrado de datos transparente, configure las siguientes características de Azure:

• Resource Health: Una base de datos que perdió el acceso a la CMK aparece como Inaccesible después de denegar la primera conexión a la base de datos.
• Registro de actividad: Cuando se produce un error en el acceso a CMK en la instancia de Key Vault administrada por el cliente, se agregan entradas al registro de actividad. Puede restablecer el acceso si crea alertas para estos eventos lo antes posible.
• Grupos de acciones: Defina estos grupos para recibir notificaciones y alertas en función de sus preferencias.

Restauración con la clave administrada de un cliente en Key Vault

Después de cifrar un servidor flexible de Azure Database for PostgreSQL con una clave administrada de un cliente almacenada en Key Vault, también se cifra cualquier copia recién creada del servidor. Puede realizar esta nueva copia a través de una restauración a un momento dado (PITR) de operación o réplicas de lectura.

Al configurar el cifrado de datos administrados por el cliente durante la restauración o creación de una réplica de lectura, puede evitar problemas siguiendo estos pasos en los servidores principal y restaurado/réplica:

• Inicie el proceso de restauración o el proceso de creación de una réplica de lectura a partir de la instancia de servidor flexible de Azure Database for PostgreSQL principal.

• En el servidor de réplica o restaurado, puede cambiar la CMK o la identidad de Microsoft Entra que se usa para acceder a Key Vault en la configuración de cifrado de datos. Asegúrese de que el servidor recién creado tiene lista, encapsular, y desencapsular permisos para la clave almacenada en Key Vault.

• No revoque la clave original después de restaurarla. En este momento, no se admite la revocación de claves después de restaurar un servidor habilitado para CMK en otro servidor.

HSM administrados

Los módulos de seguridad de hardware (HSM) son dispositivos de hardware resistentes a alteraciones que ayudan a proteger los procesos criptográficos mediante la generación, protección y administración de claves usadas para cifrar datos, descifrar datos, crear firmas digitales y crear certificados digitales. Los HSM se prueban, validan y certifican con los estándares de seguridad más altos, incluidos FIPS 140 y Criterios comunes.

HSM administrado de Azure Key Vault es un servicio en la nube totalmente administrado, de alta disponibilidad, de un solo inquilino y compatible con los estándares. Puede usarlo para proteger las claves criptográficas de las aplicaciones en la nube a través de HSM validados de FIPS 140-3.

Al crear nuevas instancias de servidor flexible de Azure Database for PostgreSQL en Azure Portal con la característica CMK, puede elegir Azure Key Vault Managed HSM como almacén de claves como alternativa a Azure Key Vault. Los requisitos previos, en términos de identidad y permisos definidos por el usuario, son los mismos que con Azure Key Vault (como se muestra anteriormente en este artículo). Para más información sobre cómo crear una instancia de HSM administrada, sus ventajas y diferencias de un almacén de certificados compartido basado en Key Vault y cómo importar claves en HSM administrado, vea ¿Qué es HSM administrado de Azure Key Vault?.

Condición CMK inaccesible

Cuando se configura el cifrado de datos con una clave administrada por el cliente en Key Vault, es necesario el acceso continuo a esta clave para que el servidor permanezca en línea. Si el servidor pierde el acceso a CMK en Key Vault, el servidor comienza a denegar todas las conexiones en un plazo de 10 minutos. El servidor emite un mensaje de error correspondiente y cambia el estado del servidor a inaccesible.

Algunas de las razones por las que el estado del servidor se convierte en Inaccesible son:

• Si elimina la instancia de Key Vault, la instancia de servidor flexible de Azure Database for PostgreSQL no puede acceder a la clave y se mueve a un estado de Inaccesible. Para que el servidor Disponible, recuperar la instancia de Key Vault y volver a validar el cifrado de datos.
• Si elimina la clave de Key Vault, la instancia de servidor flexible de Azure Database for PostgreSQL no puede acceder a la clave y se mueve a un estado de Inaccesible. Para que el servidor Disponible, recuperar la clave y volver a validar el cifrado de datos.
• Si elimina, de Microsoft Entra ID, una identidad administrada que se usa para recuperar una clave de Key Vault o mediante la eliminación de la asignación de roles de RBAC de Azure con el rol Usuario de cifrado del servicio criptográfico de Key Vault. la instancia de servidor flexible de Azure Database for PostgreSQL no puede acceder a la clave y pasa al estado Inaccesible. Para que el servidor Disponible, recuperar la identidad y volver a validar el cifrado de datos.
• Si revoca las directivas de acceso Key Vaultlist, get, wrapKey, y unwrapKey de la identidad administrada que se usa para recuperar una clave de Key Vault, la instancia de servidor flexible de Azure Database for PostgreSQL no puede acceder a la clave y se mueve a un estado de Inaccesible. Agregar directivas de acceso necesarias a la identidad en Key Vault.
• Si configura reglas de firewall de Key Vault excesivamente restrictivas, el servidor flexible de Azure Database for PostgreSQL no puede comunicarse con Key Vault para recuperar claves. Al configurar un firewall de Key Vault, asegúrese de seleccionar la opción para permitir que los servicios de Microsoft de confianza omitan el firewall.

Nota:

Cuando una clave está deshabilitada, eliminada, expirada o no accesible, un servidor que tiene datos cifrados a través de esa clave se convierte en Inaccesible, como se indicó anteriormente. El servidor no estará disponible hasta que vuelva a habilitar la clave o asigne una nueva clave.

Por lo general, un servidor se convierte en Inaccesible en un plazo de 60 minutos después de deshabilitar, eliminar, expirar o no acceder a una clave. Después de que la clave esté disponible, el servidor puede tardar hasta 60 minutos en volverse Accesible.

Recuperación de la eliminación de una identidad administrada

En raras ocasiones, cuando la identidad administrada de Entra ID que usa CMK para recuperar una clave de Azure Key Vault (AKV) se elimina en Microsoft Entra ID, se recomiendan los siguientes pasos para la recuperación:

1. Recuperar la identidad o crear una nueva identidad administrada de Entra ID
2. Asegúrese de que esta identidad tenga los permisos adecuados para las operaciones en la clave en Azure Key Vault (AKV). En función del modelo de permisos del almacén de claves (directiva de acceso o RBAC de Azure), se puede conceder acceso al almacén de claves mediante la creación de una directiva de acceso en el almacén de claves (directivas de acceso list, get, wrapKey y unwrapKey) o mediante la creación de una nueva asignación de roles de RBAC de Azure con el rol Usuario de cifrado del servicio criptográfico de Key Vault.
3. Vuelva a validar el cifrado de datos de CMK con una identidad nueva o recuperada en la pantalla Azure Database for PostgreSQL: Cifrado de datos del servidor flexible de Azure Portal.

Importante

Por sí misma, la creación de una nueva identidad de Entra ID con el mismo nombre que la identidad eliminada no recupera la eliminación de la identidad administrada.

Uso del cifrado de datos con CMK y características de continuidad empresarial con redundancia geográfica

El servidor flexible de Azure Database for PostgreSQL admite características avanzadas de recuperación de datos, como réplicas y copia de seguridad con redundancia geográfica. A continuación se muestran los requisitos para configurar el cifrado de datos con CMK y estas características, además de requisitos básicos para el cifrado de datos con CMK:

• La clave de cifrado de copia de seguridad con redundancia geográfica debe crearse en una instancia de Key Vault en la región donde se almacena la copia de seguridad con redundancia geográfica.
• La versión de la API de REST de Azure Resource Manager (ARM) para admitir servidores CMK habilitados para copia de seguridad con redundancia geográfica es "2022-11-01-preview". Si quiere usar Plantillas de Azure Resource Manager para automatizar la creación de servidores que usan cifrado con CMK y características de copia de seguridad con redundancia geográfica, use esta versión de API.
• No puede usar la misma identidad administrada por el usuario para autenticarse para la instancia de Key Vault de la base de datos principal y la instancia de Key Vault que contiene la clave de cifrado para la copia de seguridad con redundancia geográfica. Para mantener la resistencia regional, se recomienda crear la identidad administrada por el usuario en la misma región que las copias de seguridad con redundancia geográfica.
• Si configura una base de datos de réplica de lectura para cifrarse con CMK durante la creación, su clave de cifrado debe estar en una instancia de Key Vault en la región donde reside la base de datos de réplica de lectura. La identidad asignada por el usuario para autenticarse en esta instancia de Key Vault debe crearse en la misma región.

Limitaciones

Estas son las limitaciones actuales para configurar la CMK en el servidor flexible de Azure Database for PostgreSQL:

• Solo puede configurar el cifrado CMK durante la creación de un nuevo servidor, no como una actualización de una instancia de servidor flexible de Azure Database for PostgreSQL existente. En su lugar, puede restaurar la copia de seguridad de PITR en un nuevo servidor con cifrado CMK.

• Después de configurar el cifrado CMK, no se puede quitar. Si desea quitar esta característica, la única manera es restaurar el servidor en un servidor que no sea CMK.

Pasos siguientes

• Obtenga información sobre Microsoft Entra Domain Services.