Compartir a través de

Controles de administración de claves

En este artículo se detallan los controles de administración clave para escenarios de nube soberana, centrándose en las consideraciones de seguridad y las ventajas entre diferentes enfoques de administración y soberanía clave. Proporciona instrucciones para las organizaciones que evalúan dónde almacenar y administrar sus claves criptográficas en función de los requisitos operativos, de cumplimiento y soberanía.

Para obtener información completa sobre las soluciones de administración clave de Azure, incluidas las comparaciones detalladas de productos y las instrucciones de selección, consulte:

HSM administrado de Azure Key Vault para la soberanía de claves

Las claves criptográficas son esenciales para proteger los datos confidenciales y garantizar la integridad y la autenticidad de las transacciones digitales. Las organizaciones que evalúan los enfoques de administración clave para escenarios de nube soberana deben comprender las opciones disponibles y sus ventajas.

HSM administrado de Azure Key Vault proporciona soberanía clave a través de la seguridad validada de nivel 3 de FIPS 140-3 con control total de las claves, el aislamiento de un solo inquilino y los dominios de seguridad controlados por el cliente, al tiempo que mantiene los acuerdos de nivel de servicio de Azure y elimina la sobrecarga operativa de la administración física de HSM. Para más información, consulte HSM administrado de Azure Key Vault.

Azure sigue ampliando su cartera de administración clave para abordar diversos requisitos de soberanía. En este artículo también se describe la administración de claves externas como un enfoque conceptual en el que las claves se hospedan en HSM propiedad del cliente separadas físicamente de la infraestructura en la nube, para proporcionar contexto para evaluar diferentes modelos de soberanía.

Arquitectura de protección de claves

Al evaluar las soluciones de administración de claves, es importante comprender los vectores de ataque que podrían poner en peligro la seguridad clave:

Extracción de material de clave privada: el material de clave privada está protegido por muchos mecanismos que proporciona un HSM físico. Extraer las claves puede provocar ataques sin conexión, donde un atacante necesita una copia de los datos cifrados y las claves privadas del HSM. De forma predeterminada, un HSM protege el material de clave privada o las claves privadas dentro y fuera del HSM. Para la protección, los HSM se basan en mundos de seguridad o particiones para proteger el material clave dentro y fuera del HSM. Las funciones de encapsulado y desencapsulado (cifrado o descifrado de una clave de cifrado de datos) de una clave solo deben ejecutarse dentro del entorno de confianza del HSM. Además, también están disponibles las copias de seguridad protegidas y el almacenamiento de claves externas protegidos. El HSM gestiona la protección encapsulando todo el material y sale del HSM con una clave de enmascaramiento, que solo es conocida por la partición desde la que se libera la clave. Normalmente, solo la combinación de la clave de enmascaramiento y la copia de seguridad de clave (HSM) puede exponer una clave privada. Sin embargo, en algunos casos, las claves se pueden marcar como exportables, lo que les permite dejar el HSM en un estado desprotegido.

Uso no autorizado del servicio: aunque el HSM protege las claves, los atacantes pueden usar el servicio sin perder necesariamente las claves. Los usuarios no autorizados capaces de usar la función wrap/unwrap de la API de administración de claves (frente al HSM) pueden exponer la clave de cifrado de datos (DEK) enviando el DEK cifrado al servicio y, por lo tanto, poner en peligro los datos protegidos por la DEK. Aunque el HSM protege el material de clave privada, la API delante del HSM que interactúa entre el servicio de llamada y el HSM también debe protegerse.

La protección de claves requiere proteger tanto el límite de HSM como los servicios y arquitecturas circundantes que interactúan con el HSM.

HSM administrado por Azure Key Vault

HSM administrado por Azure Key Vault es un servicio HSM totalmente administrado y basado en la nube que proporciona seguridad validada de FIPS 140-3 nivel 3 con aislamiento de inquilino único y control total de las claves criptográficas. Este servicio ofrece soberanía clave al tiempo que mantiene la simplicidad operativa. Para obtener información detallada sobre el servicio, sus funcionalidades y la arquitectura, consulte ¿Qué es HSM administrado de Azure Key Vault?

El servicio aborda los requisitos clave de seguridad a través de la arquitectura de computación confidencial:

Arquitectura de HSM administrada

Aspectos destacados de la arquitectura de seguridad

HSM administrado de Azure Key Vault aprovecha Azure Confidential Computing para crear un entorno que coincida o supere la seguridad externa de HSM. Para obtener detalles técnicos completos, consulte Detalles técnicos de HSM gestionado.

  • Se crea un entorno de ejecución de confianza (TEE) para cada instancia que usa el cliente.
  • El TEE se basa en la confianza externa y las claves fuera del control de Microsoft (Intel Software Guard Extensions (SGX)).
  • Todos los secretos usados por el servicio se generan dentro de la instancia protegida por TEE.
  • Sin secretos de texto plano en la memoria activa de los servidores físicos
  • Ningún usuario o sistema fuera del entorno de confianza tiene las credenciales de HSM.
  • El acceso al servicio se limita mediante programación a la instancia de Id. de Microsoft Entra del cliente.
  • Solo los clientes pueden solicitar, descargar y descifrar el dominio de seguridad (incluida la clave de enmascaramiento). Esta información no se almacena en la nube.
  • El material de clave privada del HSM se establece como no exportable a menos que se solicite una liberación segura de claves. Las claves normales no son exportables y, por lo tanto, el HSM no libera el material de clave privada en un estado sin enmascarar.
  • El HSM tiene un registro de auditoría para ver las interacciones en la partición de HSM.

Evaluación de seguridad contra vectores de ataque

A medida que el HSM y las claves se hospedan en la infraestructura de Azure, es importante evaluar la protección frente a los dos vectores de ataque principales:

Extracción de material de clave privada:

  • Un Marvel Liquid HSM que ejecuta firmware normal se usa para proporcionar la protección del material de clave privada
  • Las credenciales del propio HSM no son legibles humanamente y se almacenan únicamente dentro de los entornos de ejecución de confianza del sistema.
  • La clave de enmascaramiento que protege los materiales de clave privada está exclusivamente en manos del cliente, protegida por las claves que este genera y administra. Es responsabilidad del cliente salvaguardar la clave de enmascaramiento. Esta separación garantiza que las claves (copias de seguridad) y la clave de enmascaramiento (protección para esas claves) se almacenan en dos lugares diferentes.
  • Aunque Microsoft Azure puede realizar copias de seguridad completas del HSM físico (incluidas todas las particiones), esta copia de seguridad está protegida por cada clave de enmascaramiento de particiones individual (que solo el cliente tiene acceso, protegido por los pares de claves a los que crea y administra el cliente).
  • La exposición prevista o no deseada del dominio de seguridad no proporciona acceso a las claves. Para que los atacantes obtengan acceso al material de clave privada, necesitarían obtener acceso a una copia de seguridad (clave), el dominio de seguridad y las claves generadas por el cliente que se usan para proteger el dominio de seguridad.
  • La exposición prevista o no deseada de la copia de seguridad no permitiría a los atacantes obtener acceso al material de clave privada, ya que también necesitarían tener el dominio de seguridad y las claves generadas por el cliente usadas para proteger el dominio de seguridad, que no se deben almacenar en Azure.

Acceso o uso no autorizado:

  • El acceso al servicio se limita a los tokens de autenticación firmados por el identificador de Microsoft Entra del cliente. El servicio usa dos listas de ACL: Azure RBAC para crear y eliminar instancias y RBAC de HSM para roles de HSM. Aunque se usa un Entra ID único, un propietario de la suscripción de Azure no puede tomar el control forzado del HSM administrado si no tiene acceso al HSM.
  • Existe un rol de administrador de HSM de emergencia para el grupo "Administradores globales de Entra ID". Independientemente de los permisos de las suscripciones de Azure, el acceso a la instancia de HSM administrado permite que un administrador global de Entra ID tome el control del HSM. No les proporciona acceso a materiales de clave privada, pero les permite cambiar la lista de ACL de HSM. Se requiere precaución con las membresías de los administradores globales.
  • Las credenciales de cada partición de HSM (individual) nunca se exponen y, por tanto, los sistemas o personas no autorizados no pueden usar las credenciales.
  • Los certificados TLS (https) se generan mediante y dentro del entorno de ejecución de confianza, lo que hace que la clave privada de las conexiones TLS del servicio esté únicamente disponible para la instancia.
  • El servicio front-end se ejecuta completamente en la computación confidencial y no es posible el acceso externo por parte de otros sistemas o seres humanos. La instancia no se puede mover a un host en peligro, ya que los parámetros TEE pueden cambiar. Además, el acceso al "almacén de secretos" que contiene las credenciales y las claves privadas del servicio solo es posible en la CPU física original debido al uso de una clave de sellado de CPU dentro del TEE.

Características de seguridad adicionales:

  • El servicio tiene redundancias integradas. Cada servicio HSM administrado creado crea 3 instancias de back-end (individuales). El intercambio de claves entre las instancias está protegido por una clave de cifrado de base de datos (compartida entre todas las instancias) y la clave de enmascaramiento de particiones de HSM, lo que garantiza que el material de clave privada solo se puede intercambiar entre instancias del mismo servicio y que solo se puede acceder a los materiales de clave privada cuando se importan en las particiones de HSM que pertenecen a la misma instancia de servicio.
  • Los procedimientos operativos y de administración en los HSM se limitan a los controladores de Azure Fabric. Por lo tanto, no se puede llamar a las operaciones fuera de límites que no están integradas en el servicio. El acceso directo a las particiones (y, por tanto, las operaciones clave o las operaciones de toda la partición) está restringido a cada instancia única dentro de sus respectivos TEE. No es posible ningún acceso humano ni fuera de los límites a la partición, simplemente porque las credenciales de una partición solo son conocidas por cada instancia específica.

Para más información sobre la arquitectura de HSM administrado, las características de seguridad y los procedimientos recomendados, consulte:

Arquitectura de administración de claves externas

La administración de claves externas es un enfoque conceptual en el que las organizaciones usan sus propios módulos de seguridad de hardware (HSM) para las operaciones criptográficas mientras consumen servicios en la nube, separando físicamente las claves de los datos y la infraestructura en la nube.

En esta sección se proporciona contexto educativo para comprender las arquitecturas de administración de claves externas, sus consideraciones de seguridad y desventajas operativas. Este patrón arquitectónico se puede comparar con los servicios HSM administrados por la nube, como HSM administrados por Azure Key Vault al evaluar los requisitos de soberanía. Para obtener información sobre las funcionalidades de administración de claves de Azure, consulte:

Arquitecturas de almacén de claves externas

Componentes de la arquitectura

Normalmente, una arquitectura de almacén de claves externa incluye cuatro componentes:

  • El servicio en la nube: este servicio llama a un servicio de administración de claves para proporcionar la DEK sin cifrar necesaria para procesar o desbloquear los datos. Normalmente, el servicio en la nube usa una identidad (administrada) para autorizarse a la clave de cifrado de claves de destino.
  • Servicio de administración de claves basado en la nube: este componente suele ser necesario, ya que la mayoría de los servicios en la nube están estrechamente integrados con el servicio de administración de claves del proveedor. El servicio de administración de claves puede servir claves hospedadas en la nube o tener claves de referencia o referencia que apunten a una clave externa.
  • El proxy de gestión de claves: dado que las organizaciones pueden elegir su propio HSM (proveedor/tipo), es necesario realizar una conversión entre el servicio de gestión de claves y la llamada HSM real. El proxy tiene una dirección URL (externa) a la que el servicio de administración de claves reenvía las llamadas de encapsulado o desencapsulado y el proxy debe convertirlas a las llamadas API de HSM del proveedor específicas. En muchos casos, el proxy también realiza la conversión y validación de identidades, ya que es posible que el proveedor de identidades de HSM no sea el mismo que la identidad administrada del servicio en la nube.
  • HSM: varios HSMs pueden usarse en el backend, pero, dado que se requiere acceso continuo, el HSM elegido debe estar siempre en línea, y el acceso debe ser concedido mediante principios de servicio o cuentas de usuario (gestionados por el proxy). Dados los servicios en la nube necesitan un uso normal de las claves, el HSM normalmente no puede usar controles MFA basados en cuórum (como tarjetas inteligentes) para los procedimientos de encapsulado y desencapsulado.

Consideraciones operativas

En arquitecturas de almacén de claves externas, los clientes tienen control total sobre el HSM físico y sus procesos operativos, incluidos los flujos de trabajo de MFA y de varias aprobaciones para operaciones administrativas, como la creación de claves, la copia de seguridad y la restauración.

Las organizaciones son totalmente responsables de hospedar y proteger los componentes de proxy, que desempeñan un papel fundamental en las comunicaciones de servicio. El software proxy debe traducir correctamente las llamadas API y, a menudo, realizar traducciones de identidades entre los servicios en la nube y el uso de claves de HSM. Aunque los proveedores de HSM proporcionan a menudo servidores proxy, las especificaciones basadas en estándares abiertos permiten implementaciones personalizadas.

Evaluación de seguridad contra vectores de ataque

Las organizaciones que consideran almacenes de claves externos deben evaluar la protección frente a los mismos vectores de ataque:

Extracción de material de clave privada:

  • La copia de seguridad de HSM (que contiene todas las claves en estado cifrado) y la clave de enmascaramiento (para anular el cifrado de la copia de seguridad) se encuentran en la misma ubicación, administradas por la misma entidad y protegidas por el mismo proveedor de identidades (con o sin MFA).
  • Las credenciales legibles humanas son necesarias para tomar posesión del HSM, para realizar tareas diarias, como copias de seguridad, rotación de claves, supervisión y acciones de partición raíz de HSM.
  • El componente proxy es un componente propietario, de código abierto o autoadministrado que tiene acceso completo al HSM, las claves y las interacciones. Un compromiso del servicio proxy puede resultar en un compromiso de material clave. En función de cómo se diseñe o escriba el proxy, este podría tener privilegios de "uso de todas las claves", lo que amplía el alcance de su vulnerabilidad.
  • El proxy de administración de claves hospeda una dirección URL accesible externa que está protegida con un certificado TLS. Es fundamental que las comunicaciones entre el servicio de administración de claves en la nube y el proxy de administración de claves no se interrumpan ni se pongan en peligro mientras se devuelve la DEK (sin cifrar).

Uso no autorizado del servicio:

  • Almacenar o gestionar las credenciales para el uso efectivo del HSM (operaciones de cifrado/descifrado) mediante el proxy supone un riesgo de robo de credenciales. Con esas credenciales, un sistema no autorizado puede realizar llamadas directas de HSM para operaciones de encapsulado y desencapsulado sin validación.
  • El servicio de administración de claves basado en la nube requiere confianza como componente en la arquitectura. Este servicio actúa como proxy para las solicitudes de los servicios de la nube hacia el proxy de administración de claves a través de una clave de referencia. Un compromiso de ese servicio podría permitir reemplazos de claves no autorizados o instrucciones inapropiadas para encapsular/desencapsular.
  • El servicio de administración de claves basado en la nube es responsable de autorizar el servicio en la nube para usar la clave de referencia. Una vez que se invoca la clave de referencia, la solicitud reenviada al proxy de gestión de claves no necesariamente conoce el servicio que llama ni tiene la capacidad de validar si la solicitud ha sido autorizada correctamente, excepto para validar la solicitud del Servicio de Gestión de Claves.

Otras consideraciones:

  • Las organizaciones son totalmente responsables de la adquisición, el alojamiento y el mantenimiento de infraestructuras de HSM y proxy complejas y redundantes, incluidos el entrenamiento, los procedimientos operativos y la administración de riesgos para incidentes de seguridad tanto no intencionados como intencionados.
  • Las organizaciones controlan las directivas de HSM, incluida la capacidad de marcar las claves como exportables, lo que podría reducir la seguridad si no se administra correctamente.
  • La pérdida de claves, disponibilidad del servicio proxy o conectividad de API da como resultado la inaccesibilidad inmediata e irrecuperable de los datos para los servicios en la nube dependientes.

Nota:

Aunque se indica el acceso externo al proxy de administración de claves, este tráfico se puede hospedar en redes controladas por el cliente o el proveedor en la nube, como conexiones directas y conexiones WAN, y no requiere accesibilidad pública a Internet.

Evaluación de los enfoques de administración de claves

Consideraciones sobre el modelo de confianza y seguridad

La confianza en la administración de claves se extiende más allá de la ubicación física del material clave. Independientemente del enfoque, la confianza es necesaria en los métodos de cifrado, el firmware y los servicios que median entre el consumo de aplicaciones y el almacenamiento de claves.

Enfoque de administración de claves externas:

  • Separación física de claves de la infraestructura en la nube
  • Requiere confianza en los componentes proxy que traducen las llamadas iniciadas por la nube en operaciones específicas de HSM.
  • Sigue dependiendo de los puntos de integración del servicio de administración de claves en la nube.
  • Pone toda la responsabilidad de la seguridad, confiabilidad, durabilidad y rendimiento en la organización

HSM administrado de Azure Key Vault:

  • Proporciona soberanía clave a través de la arquitectura de computación confidencial de Azure con credenciales protegidas por Intel SGX
  • Proporciona protección de HSM validada por FIPS 140-3 de nivel 3 en centros de datos de Azure
  • Permite la autenticación multifactor, los procesos de aprobación múltiple y los requisitos de quorum del dominio de seguridad a través de Microsoft Entra ID
  • Usa dominios de seguridad únicos con claves de enmascaramiento controladas por el cliente y mecanismos de protección
  • Admite la API estándar de Azure Key Vault con RSA-HSM y tipos de claves y algoritmos de OCT-HSM
  • La raíz de confianza es externa al proveedor de nube (HSM y silicio de CPU de Intel)
  • Equilibrio de responsabilidad: Microsoft controla el rendimiento, la integridad clave, la confiabilidad del servicio y la durabilidad; los clientes protegen el dominio de seguridad y las claves de protección

Para obtener comparaciones detalladas de las soluciones de administración de claves de Azure, consulte Elección de la solución de administración de claves adecuada.

Conclusión

Las organizaciones que evalúan los enfoques clave de soberanía deben equilibrar los requisitos de seguridad, las funcionalidades operativas y los modelos de confianza. Existen diferentes patrones arquitectónicos para proteger el material clave, cada uno con ventajas distintas.

HSM administrado de Azure Key Vault ofrece soberanía de claves hoy a través de la protección validada FIPS 140-3 de nivel 3 con arquitectura de computación confidencial, ofreciendo dedicación exclusiva y control del cliente sobre las claves mientras Microsoft maneja las responsabilidades operativas. Las arquitecturas de administración de claves externas ofrecen un control máximo sobre el acceso y las directivas de HSM, pero requieren que las organizaciones administren una infraestructura compleja y mantengan la disponibilidad del servicio para cargas de trabajo en la nube dependientes.

Las organizaciones deben evaluar los enfoques basados en los requisitos de cumplimiento, la capacidad operativa, las necesidades de integración y el equilibrio de responsabilidades que se alinean con sus objetivos de soberanía.

Pasos siguientes

  • Clasificación de cargas de trabajo según la intensidad de control de claves necesaria (claves administradas por la plataforma → claves administradas por el cliente → HSM administrado)
  • Frecuencias de rotación de documentos y activadores de revocación por dominio específico
  • Evaluación de la computación confidencial y la viabilidad de la liberación segura de clave para cargas de trabajo de alta sensibilidad

Consulte también

  • Last updated on