Soberanía, disponibilidad, rendimiento y escalabilidad de claves en HSM administrado
Las claves criptográficas son la raíz de confianza para proteger los sistemas informáticos modernos, ya sean en la nube o en el entorno local. Por lo tanto, controlar quién tiene autoridad sobre esas claves es fundamental para crear aplicaciones seguras y compatibles.
En Azure, nuestra visión de cómo se debe realizar la administración de claves en la nube es la soberanía de claves. La soberanía de claves se da cuando la organización de un cliente tiene el control total y exclusivo sobre quién puede acceder a las claves y cambiar las directivas de administración de claves, y sobre qué servicios de Azure consumen estas claves. Una vez tomadas estas decisiones por el cliente, se impide a través de medios técnicos que el personal de Microsoft cambie estas decisiones. El código del servicio de administración de claves ejecuta las decisiones del cliente hasta que el cliente le indique lo contrario, y el personal de Microsoft no puede intervenir.
Al mismo tiempo, creemos que cada servicio en el nube debe estar totalmente administrado. El servicio debe proporcionar las promesas básicas de disponibilidad, resistencia, seguridad y nube necesarias, respaldadas por contratos de nivel de servicio (SLA). Para ofrecer un servicio administrado, Microsoft debe aplicar revisiones a los servidores de administración de claves, actualizar el firmware del módulo de seguridad de hardware (HSM), recuperar hardware con errores, realizar conmutaciones por error y realizar otras operaciones con privilegios elevados. Como la mayoría de los profesionales de seguridad saben, denegar a alguien con privilegios elevados o acceso físico a un acceso del sistema a los datos de ese sistema es un problema difícil.
En este artículo se explica cómo solucionamos este problema en el servicio de HSM administrado de Azure Key Vault, lo que proporciona a los clientes la soberanía de claves completa y los SLA de servicio totalmente administrados mediante el uso de tecnología de computación confidencial emparejada con HSM.
Entorno de hardware de HSM administrado
El grupo de HSM administrado de un cliente en cualquier región de Azure está en un centro de datos de Azure seguro. Tres instancias se distribuyen entre varios servidores. Cada instancia se implementa en un bastidor diferente para garantizar la redundancia. Cada servidor tiene un adaptador Marvell LiquidSecurity HSM validado por FIPS 140-2 de nivel 3 con varios núcleos criptográficos. Los núcleos se usan para crear particiones HSM totalmente aisladas, incluidas credenciales totalmente aisladas, almacenamiento de datos y control de acceso.
La separación física de las instancias dentro del centro de datos es fundamental para garantizar que la pérdida de un único componente (por ejemplo, el conmutador en la parte superior del bastidor o una unidad de administración de energía en un bastidor) no pueda afectar a todas las instancias de un grupo. Estos servidores están dedicados al equipo de HSM de seguridad de Azure. Los servidores no se comparten con otros equipos de Azure y no se implementan cargas de trabajo de cliente en estos servidores. Los controles de acceso físico, incluidos los bastidores bloqueados, se usan para evitar el acceso no autorizado a los servidores. Estos controles cumplen con FedRAMP-High, PCI, SOC 1/2/3, ISO 270x y otros estándares de seguridad y privacidad, y se comprueban periódicamente de forma independiente como parte del Programa de cumplimiento de Azure. Los HSM han mejorado la seguridad física, validada para cumplir los requisitos de FIPS 140-2 de nivel 3. Todo el servicio de HSM administrado se basa en la plataforma segura estándar de Azure, incluido el inicio seguro, que protege contra amenazas persistentes avanzadas.
Los adaptadores HSM pueden admitir docenas de particiones HSM aisladas. La ejecución en cada servidor es un proceso de control denominado Node Service. Node Service toma posesión de cada adaptador e instala las credenciales para el propietario del adaptador, en este caso, Microsoft. El HSM está diseñado para que la propiedad del adaptador no proporcione a Microsoft acceso a los datos almacenados en las particiones del cliente. Solo permite a Microsoft crear, cambiar el tamaño y eliminar particiones del cliente. Admite las copias de seguridad ciegas de cualquier partición del cliente. En una copia de seguridad ciega, una clave proporcionada por el cliente ajusta la copia de seguridad que solo se puede restaurar mediante el código de servicio dentro de una instancia de HSM administrado que es propiedad del cliente y cuyo contenido no es legible por Microsoft.
Arquitectura de un grupo de HSM administrado
En la figura 1 se muestra la arquitectura de un grupo de HSM, que consta de tres máquinas virtuales Linux, y cada una se ejecuta en un servidor HSM en su propio bastidor de centros de datos para admitir la disponibilidad. Los componentes importantes son:
- El controlador de tejido de HSM (HFC) es el plano de control del servicio. El HFC controla la aplicación automatizada de revisiones y las reparaciones para el grupo.
- Un límite criptográfico exclusivo para cada cliente compuesto por tres enclaves confidenciales de Intel Secure Guard Extensions (Intel SGX) conectados a tres instancias de HSM compatibles con FIPS 140-2 nivel 3. Las claves raíz de este límite se generan y almacenan en los tres HSM. Como se describe más adelante en este artículo, ninguna persona asociada a Microsoft tiene acceso a los datos que están dentro de este límite. Solo el código del servicio que se ejecuta en el enclave de Intel SGX (incluido el agente de Node Service), que actúa en nombre del cliente, tiene acceso.
Entorno de ejecución de confianza (TEE)
Un grupo de HSM administrado consta de tres instancias de servicio. Cada instancia de servicio se implementa como un entorno de ejecución de confianza (TEE) que usa las funcionalidades de Intel SGX y el SDK de Open Enclave. La ejecución dentro de un TEE garantiza que ninguna persona de la máquina virtual que hospeda el servicio o el servidor de host de la máquina virtual tenga acceso a secretos de cliente, datos o la partición de HSM. Cada TEE está dedicado a un cliente específico y ejecuta la administración de TLS, el control de solicitudes y el control de acceso a la partición HSM. No existen credenciales ni claves de cifrado de datos específicas del cliente en texto no cifrado fuera de este TEE, excepto como parte del paquete de dominio de seguridad. Ese paquete se cifra en una clave proporcionada por el cliente y se descarga cuando se crea por primera vez su grupo.
Los TEE se comunican entre sí mediante TLS atestiguado. El TLS atestiguado combina las capacidades de atestación remotas de la plataforma de Intel SGX con TLS 1.2. Esto permite que el código de HSM administrado en el TEE limite su comunicación a solo otro código firmado por la misma clave de firma de código del servicio HSM administrado, lo que impide ataques de tipo “Man in the middle”. La clave de firma de código del servicio HSM administrado se almacena en Microsoft Product Release and Security Service (que también se usa para almacenar, por ejemplo, la clave de firma de código de Windows). La clave se controla mediante el equipo de HSM administrado. Como parte de nuestras obligaciones normativas y de cumplimiento para la administración de cambios, ningún otro equipo de Microsoft puede usar esta clave para firmar su código.
El código de servicio emite automáticamente los certificados TLS que se usan para la comunicación de TEE a TEE dentro del TEE. Los certificados contienen un informe de plataforma generado por el enclave de Intel SGX en el servidor. El informe de plataforma se firma con claves derivadas de claves fusionadas por Intel en la CPU cuando se fabrica. El informe identifica el código que se carga en el enclave de Intel SGX mediante su clave de firma de código y el hash binario. De este informe de plataforma, las instancias de servicio pueden determinar que un nodo del mismo nivel también está firmado por la clave de firma de código del servicio HSM administrado y, con algún entrelazamiento criptográfico a través del informe de la plataforma, también pueden determinar que la clave de firma de certificado autoemitido también debe haberse generado dentro del TEE para impedir la suplantación externa.
Ofrecer acuerdos de nivel de servicio de disponibilidad con control completo de claves administradas por el cliente
Para garantizar la alta disponibilidad, el servicio HFC crea tres instancias de HSM en la región de Azure seleccionada por el cliente.
Creación de grupos de HSM administrados
Las propiedades de alta disponibilidad de los grupos de HSM administrado proceden de las instancias HSM con redundancia triple administradas automáticamente que siempre se mantienen sincronizadas (o si se usa la replicación de varias regiones, se mantienen sincronizadas las seis instancias). El servicio HFC administra la creación del grupo, que asigna grupos en el hardware disponible en la región de Azure elegida por el cliente.
Cuando se solicita un nuevo grupo, HFC selecciona tres servidores en varios bastidores con espacio disponible en sus adaptadores HSM y, después, comienza a crear el grupo:
El HFC indica a los agentes de Node Service en cada uno de los tres TEE que inicien una nueva instancia del código de servicio mediante un conjunto de parámetros. Los parámetros identifican el inquilino de Microsoft Entra del cliente, las direcciones IP de red virtual interna de las tres instancias y otras configuraciones de servicio. Una partición se asigna aleatoriamente como principal.
Se inician las tres instancias. Cada instancia se conecta a una partición en su adaptador HSM local y, a continuación, inicializa con ceros e inicializa la partición mediante nombres de usuario y credenciales generados aleatoriamente (para asegurarse de que un operador humano u otra instancia de TEE no puede tener acceso a la partición).
La instancia principal crea un certificado raíz del propietario de la partición mediante la clave privada que se genera en el HSM. Establece la propiedad del grupo mediante la firma de un certificado de nivel de partición para la partición HSM mediante este certificado raíz. La instancia principal también genera una clave de cifrado de datos, que se usa para proteger todos los datos en reposo del cliente dentro del servicio. En el caso del material de la clave, se utiliza un ajuste doble porque el HSM también protege el propio material de la clave.
A continuación, estos datos de propiedad se sincronizan con las dos instancias secundarias. Cada instancia secundaria se pone en contacto con la principal mediante TLS atestiguado. La instancia principal comparte el certificado raíz del propietario de la partición con la clave privada y la clave de cifrado de datos. Ahora, las secundarias usan el certificado raíz de partición para emitir un certificado de partición a sus propias particiones HSM. Una vez hecho esto, tenemos particiones de HSM en tres servidores independientes que pertenecen al mismo certificado raíz de partición.
Sobre el vínculo TLS atestiguado, la partición HSM principal comparte con las instancias secundarias la clave de ajuste de datos generada (que se usa para cifrar mensajes entre los tres HSM), mediante una API segura proporcionada por el proveedor de HSM. Durante este intercambio, los HSM confirman que tienen el mismo certificado de propietario de partición y luego utilizan un esquema Diffie-Hellman para cifrar los mensajes de modo que el código de servicio de Microsoft no pueda leerlos. Todo lo que el código de servicio puede hacer es transportar blobs opacos entre los HSM.
En este momento, las tres instancias están listas para exponerse como un grupo en la red virtual del cliente. Comparten el mismo certificado de propietario de partición y clave privada, la misma clave de cifrado de datos y una clave de ajuste de datos común. Sin embargo, cada instancia tiene credenciales únicas para sus particiones de HSM. Ahora se completan los pasos finales.
Cada instancia genera un par de claves RSA y una solicitud de firma de certificado (CSR) para su certificado TLS orientado al público. El CSR está firmado por el sistema de infraestructura de clave pública (PKI) de Microsoft mediante una raíz pública de Microsoft y el certificado TLS resultante se devuelve a la instancia.
Las tres instancias obtienen su propia clave de sellado de Intel SGX de su CPU local. La clave se genera mediante la propia clave única de la CPU y la clave de firma de código del TEE.
El grupo deriva una clave de grupo única de las claves de sellado de Intel SGX, cifra todos sus secretos con esta clave de grupo y, a continuación, escribe los blobs cifrados en el disco. Estos blobs se pueden descifrar únicamente si la misma clave de sellado de Intel SGX que se ejecuta en la misma CPU física los firma con código. Los secretos se enlazan con esta instancia en específico.
El proceso de arranque seguro ahora está completo. Este proceso ha permitido la creación de un grupo de HSM con redundancia triple y la creación de una garantía criptográfica de la soberanía de los datos del cliente.
Mantenimiento de acuerdos de nivel de servicio de disponibilidad en tiempo de ejecución mediante la recuperación de servicios confidenciales
La narración de creación de grupos que se describe en este artículo puede explicar cómo el servicio HSM administrado puede entregar sus SLA de alta disponibilidad mediante la administración segura de los servidores que subyacen al servicio. Imagine que se produce un error en un servidor, un adaptador HSM, o incluso la fuente de alimentación en el bastidor. El objetivo del servicio HSM administrado es, sin intervención del cliente ni la posibilidad de que los secretos se expongan en texto no cifrado fuera del TEE, recuperar el grupo a tres instancias correctas. Esto se logra a través de la recuperación de servicios confidenciales.
Comienza con el HFC detectando qué grupos tenían instancias en el servidor con errores. HFC busca servidores nuevos y correctos dentro de la región del grupo para implementar las instancias de reemplazo en. Inicia nuevas instancias, que luego se tratan exactamente como secundarias durante el paso de aprovisionamiento inicial: inicializar el HSM, buscar sus secretos principales e intercambiar secretos de forma segura a través de TLS atestiguado, firmar el HSM en la jerarquía de propiedad y, a continuación, sellar sus datos de servicio en su nueva CPU. El servicio ahora está curado, totalmente automáticamente y totalmente confidencialmente.
Recuperación ante desastres mediante el dominio de seguridad
El dominio de seguridad es un blob protegido que contiene todas las credenciales necesarias para recompilar la partición de HSM desde cero: la clave de propietario de la partición, las credenciales de la partición, la clave de ajuste de datos, además de una copia de seguridad inicial del HSM. Antes de que el servicio pase a estar activo, el cliente debe descargar el dominio de seguridad proporcionando un conjunto de claves de cifrado RSA para protegerlo. Los datos del dominio de seguridad se originan en los TEE y están protegidos por una clave simétrica generada y una implementación del algoritmo de uso compartido de secretos de Shamir, que divide los recursos compartidos de claves entre las claves públicas RSA proporcionadas por el cliente según los parámetros de cuórum seleccionados por el cliente. Durante este proceso, ninguna de las claves ni las credenciales del servicio se exponen como texto no cifrado fuera del código de servicio que se ejecuta en el TEE. Solo el cliente, al presentar un cuórum de sus claves RSA al TEE, puede descifrar el dominio de seguridad durante un escenario de recuperación.
El dominio de seguridad solo es necesario cuando, debido a alguna catástrofe, toda una región de Azure se pierde y Microsoft pierde las tres instancias del grupo simultáneamente. Si solo se pierden una o incluso dos instancias, la recuperación del servicio confidencial se recuperará de manera silenciosa en tres instancias correctas sin intervención del cliente. Si se pierde toda la región, porque las claves de sellado de Intel SGX son únicas para cada CPU, Microsoft no tiene forma de recuperar las credenciales de HSM y las claves de propietario de la partición. Solo existen en el contexto de las instancias.
En el caso extremadamente improbable de que se produzca esta catástrofe, el cliente puede recuperar el estado y los datos del grupo anterior mediante la creación de un nuevo grupo en blanco, insertarlo en el dominio de seguridad y, a continuación, presentar su cuórum de clave RSA para demostrar la propiedad del dominio de seguridad. Si un cliente ha habilitado la replicación en varias regiones, la catástrofe aún más improbable de que ambas regiones experimentan un error simultáneo, se tendría que producir un error completo antes de que se necesite la intervención del cliente para recuperar el grupo del dominio de seguridad.
Control del acceso al servicio
Como hemos descrito, nuestro código de servicio en el TEE es la única entidad con acceso al propio HSM, ya que las credenciales necesarias no se proporcionan al cliente ni a nadie más. En su lugar, el grupo del cliente está enlazado a su instancia de Microsoft Entra y se usa para la autenticación y autorización. En el aprovisionamiento inicial, el cliente puede elegir un conjunto inicial de empleados para asignar el rol Administrador para el grupo. Estas personas, y los empleados del rol Administrador global de inquilinos de Microsoft Entra del cliente, pueden establecer directivas de control de acceso dentro del grupo. El servicio almacena todas las directivas de control de acceso en la misma base de datos que las claves enmascaradas, que también están cifradas. Solo el código de servicio del TEE tiene acceso a estas directivas de control de acceso.
Resumen
HSM administrado elimina la necesidad de que los clientes realicen compensaciones entre la disponibilidad y el control sobre las claves criptográficas mediante tecnología de enclave confidencial respaldada por hardware de vanguardia. Como se describe en este artículo, en esta implementación, ningún personal ni representante de Microsoft pueda acceder al material de la clave administrada por el cliente ni a los secretos relacionados, incluso con acceso físico a las máquinas de host y los HSM administrados de HSM. Esta seguridad ha permitido a nuestros clientes en los servicios financieros, fabricación, sector público, defensa y otros sectores acelerar su migración a la nube con plena confianza.