Confiabilidad en HSM administrado de Azure Key Vault

HSM administrado de Azure Key Vault es un servicio en la nube totalmente administrado, de alta disponibilidad, de un solo inquilino y compatible con estándares que permite proteger las claves criptográficas de las aplicaciones en la nube mediante módulos de seguridad de hardware validados (HSM) de FIPS 140-3 nivel 3. Managed HSM proporciona una gama de características de confiabilidad integradas para ayudar a garantizar que las claves permanezcan disponibles.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de capacidades para apoyar la resiliencia y la recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo HSM administrado es resistente a una variedad de posibles interrupciones y problemas, incluidos errores transitorios, errores de hardware y interrupciones de regiones. También se describe cómo puede usar copias de seguridad y el dominio de seguridad para recuperarse de otros tipos de problemas, características de recuperación para evitar la eliminación accidental y se resalta cierta información clave sobre el acuerdo de nivel de servicio (SLA) de HSM administrado.

Recomendaciones de implementación de producción para la confiabilidad

En el caso de las cargas de trabajo de producción, se recomienda que usted:

Introducción a la arquitectura de confiabilidad

Cuando se usa HSM administrado, se implementa una instancia, que a veces también se denomina grupo.

HSM administrado está diseñado para alta disponibilidad y durabilidad a través de su arquitectura:

  • Aislamiento de un solo inquilino: cada instancia de HSM administrada está dedicada a un solo cliente y consta de un clúster de varias particiones HSM que están aisladas criptográficamente.

  • Particiones con redundancia triple: un grupo de HSM administrado consta de tres particiones HSM con equilibrio de carga distribuidas entre bastidores independientes dentro de un centro de datos. Esta distribución proporciona redundancia frente a errores de hardware y garantiza que la pérdida de un único componente (como la fuente de alimentación o el conmutador de red de un bastidor) no afecte a todas las particiones.

  • Computación confidencial: cada instancia de servicio se ejecuta en un entorno de ejecución de confianza (TEE) que usa enclaves de Intel SGX. El personal de Microsoft, incluidos los que tienen acceso físico a los servidores, no puede acceder al material de clave criptográfica.

  • Recuperación automática: si un error de hardware u otro problema afecta a una de las tres particiones, el servicio vuelve a generar automáticamente la partición afectada en hardware correcto sin intervención del cliente y sin exponer secretos.

Para más información sobre cómo el HSM administrado implementa estas capacidades, consulte Soberanía de claves, disponibilidad, rendimiento y escalabilidad en HSM administrado.

Dominio de seguridad

El dominio de seguridad es un componente crítico para la recuperación ante desastres. Es un blob cifrado que contiene todas las credenciales necesarias para recompilar una instancia de HSM administrada desde cero, incluida la clave de propietario de la partición, las credenciales de partición, la clave de ajuste de datos y una copia de seguridad inicial del HSM.

Importante

Sin el dominio de seguridad, no es posible la recuperación ante desastres. Microsoft no tiene ninguna manera de recuperar el dominio de seguridad y no puede acceder a las claves sin ella.

Los dominios de seguridad son una parte fundamental de la seguridad y confiabilidad del HSM administrado. Se recomienda seguir estos procedimientos recomendados:

  • Generar claves de forma segura: Para entornos de producción, genere los pares de claves RSA que protegen el dominio de seguridad en un entorno aislado físicamente (como un HSM local o una estación de trabajo aislada).
  • Almacenar sin conexión: almacene las claves de dominio de seguridad en unidades USB cifradas u otro almacenamiento sin conexión, con cada recurso compartido de claves en un dispositivo independiente en ubicaciones geográficas independientes.
  • Establecer un cuórum de varias personas: use al menos tres titulares de claves para evitar que cualquier persona individual tenga acceso a todas las claves de cuórum y para evitar una dependencia en cualquier persona única.

Para obtener más información, consulte Dominio de seguridad en la información general sobre el HSM administrado.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Cuando se usan servicios de Azure que se integran con HSM administrado, esos servicios controlan los errores transitorios automáticamente.

Si compila aplicaciones personalizadas que se integran con HSM administrado, tenga en cuenta los procedimientos recomendados siguientes para controlar los errores transitorios que puedan producirse:

  • Use los SDK proporcionados por Microsoft para Azure Key Vault, que incluyen mecanismos de reintento integrados. Los SDK están disponibles para .NET, Python y JavaScript.

  • Implemente la lógica de reintentos cuando interactúen directamente con Managed HSM, incluidas las políticas de reintentos de retroceso exponencial.

  • Reduzca el número de dependencias directas en el HSM administrado. Almacene en caché los resultados de la operación criptográfica cuando sea posible para reducir las solicitudes directas a HSM administrado. Para las operaciones de clave pública, como el cifrado, el ajuste y la comprobación, realice estas operaciones localmente almacenando en caché el material de clave pública. La realización de las operaciones localmente reduce la dependencia de su HSM administrado y evita que los errores transitorios interrumpan estas operaciones.

Si usa HSM administrado en escenarios de alto rendimiento, tenga en cuenta que HSM administrado no limita las operaciones criptográficas. Utiliza su hardware HSM al máximo de su capacidad. Cada instancia de HSM administrada tiene tres particiones. Durante las operaciones de mantenimiento o recuperación, es posible que una partición no esté disponible. Para la planificación de la capacidad, suponga que hay dos particiones disponibles. Si necesita un rendimiento garantizado, planee como si solo una partición estuviera disponible. Supervise la métrica Managed HSM Availability para comprender el estado del servicio.

Para escalar el cifrado de grandes cantidades de datos, use una jerarquía de claves donde solo se almacena la clave de cifrado de claves (KEK) en HSM administrado y se usa para encapsular claves de nivel inferior almacenadas en otra ubicación de almacenamiento de claves segura.

Para obtener instrucciones detalladas sobre pruebas comparativas de rendimiento y planeamiento de capacidad, consulte Guía de escalado de HSM administrado de Azure.

Resistencia a errores de partición

HSM administrado logra una alta disponibilidad a través de su arquitectura triple redundante, donde cada grupo de HSM consta de tres particiones HSM distribuidas entre bastidores de servidores independientes dentro de un centro de datos. Esta distribución de nivel de bastidor proporciona redundancia frente a errores de hardware localizados.

Diagrama que muestra las tres particiones de un grupo de HSM administrado, cada una en un servidor físico independiente y en un bastidor de servidores diferente.

Cuando se producen errores de hardware o interrupciones localizadas, el HSM administrado redirige automáticamente las solicitudes a particiones correctas y vuelve a generar particiones afectadas a través de un proceso denominado recuperación del servicio confidencial. Las particiones fallidas se reconstruyen automáticamente en hardware sano utilizando enclaves de TLS e Intel SGX atestados para proteger los secretos durante la recuperación.

Cost

No hay ningún costo adicional asociado a la alta disponibilidad integrada en HSM administrado. Los precios se basan en el número de grupos de HSM y en el número de operaciones realizadas. Para obtener más información, consulte los precios de Azure Managed HSM.

Comportamiento cuando todas las particiones están en buen estado

En esta sección se describe qué esperar cuando los grupos de HSM administrados están operativos y no hay particiones disponibles.

  • Enrutamiento de tráfico: HSM administrado administra automáticamente el enrutamiento del tráfico entre sus tres particiones. Durante las operaciones normales, las solicitudes se distribuyen entre particiones de forma transparente.

  • Replicación de datos: todos los datos, incluidas las claves, las asignaciones de roles y las directivas de control de acceso, se replican sincrónicamente en las tres particiones. Esto garantiza la coherencia y la disponibilidad incluso si una partición deja de estar disponible.

Comportamiento durante un error de partición

En esta sección se describe qué esperar cuando una o varias particiones no están disponibles.

  • Detección y respuesta: el servicio HSM administrado es responsable de detectar errores de partición y responder automáticamente a ellos. No es necesario realizar ninguna acción durante un fallo de partición.

  • Solicitudes activas: durante un error de partición, las solicitudes en curso a la partición afectada pueden producir un error y requerir que las aplicaciones cliente vuelvan a intentarlas. Para minimizar los efectos de las interrupciones de particiones, las aplicaciones cliente deben seguir los procedimientos transitorios de control de errores.

  • Pérdida de datos esperada: no se espera ninguna pérdida de datos durante un error de partición debido a la replicación sincrónica entre particiones.

  • Tiempo de inactividad esperado: para las operaciones de lectura y la mayoría de las operaciones criptográficas, debe haber un tiempo de inactividad mínimo o nulo durante un error de partición. Las particiones sanas restantes siguen atendiendo solicitudes.

  • Redireccionamiento del tráfico: HSM administrado vuelve a enrutar automáticamente el tráfico de la partición afectada a particiones correctas sin necesidad de intervención del cliente.

Recuperación de particiones

Cuando se recupera la partición afectada, Managed HSM restaura automáticamente las operaciones mediante el restablecimiento confidencial del servicio. Este proceso:

  1. Crea una nueva instancia de servicio en hardware en buen estado.
  2. Establece una conexión TLS atestada con la partición principal.
  3. Intercambia de forma segura las credenciales y el material criptográfico.
  4. Asegura los datos de servicio a una nueva CPU.

La plataforma Azure administra completamente este proceso y no requiere ninguna intervención del cliente.

Resistencia a errores de zona de disponibilidad

La alta disponibilidad de los HSM administrados se basa en la distribución a nivel de bastidor dentro de un centro de datos, no en la implementación explícita de zonas de disponibilidad. Cada partición se ejecuta en un servidor independiente en un bastidor diferente, que protege frente a errores de nivel de bastidor, como la fuente de alimentación o los problemas de conmutador de red.

Si necesita ser resistente a interrupciones en todo el centro de datos o en toda la zona de disponibilidad, considere la posibilidad de usar uno de los enfoques para la resistencia a errores de toda la región.

Resistencia a errores en toda la región

Los recursos de HSM administrados se implementan en una sola región de Azure. Si la región deja de estar disponible, el HSM administrado tampoco está disponible. Sin embargo, hay enfoques que puede usar para ayudar a garantizar la resistencia a las interrupciones de la región.

Replicación en varias regiones

Managed HSM admite la replicación opcional de varias regiones, lo que permite ampliar un grupo de HSM administrado de una región de Azure (la región primaria) a una segunda región de Azure (la región extendida). Una vez configurado:

  • Ambas regiones están activas y pueden atender solicitudes.
  • El material, los roles y los permisos clave se replican automáticamente entre regiones.
  • Las solicitudes se enrutan a la región disponible más cercana mediante Azure Traffic Manager.
  • El Acuerdo de Nivel de Servicio combinado aumenta.

Requirements

  • Compatibilidad regional: todas las regiones HSM administradas de Azure se admiten como regiones primarias. No hay ninguna dependencia en los emparejamientos de regiones de Azure.

    HSM administrado no admite todas las regiones como regiones extendidas. Para más información, consulte Compatibilidad con regiones de Azure.

  • Número máximo de regiones: Puede agregar una región extendida, para un máximo de dos regiones en total.

Cost

La replicación multirregional conlleva costos adicionales porque se consume un segundo grupo de HSM en la región extendida. Para obtener más información, consulte los precios de Azure Managed HSM.

Configuración de la replicación en varias regiones

Comportamiento cuando todas las regiones están en buen estado

Cuando la replicación en varias regiones está habilitada y ambas regiones están operativas:

  • Enrutamiento de tráfico: todas las regiones pueden atender solicitudes. Azure Traffic Manager enruta las solicitudes a la región con la proximidad geográfica más cercana o la latencia más baja.

    Si usa Private Link, configure puntos de conexión privados en ambas regiones para un enrutamiento óptimo durante la conmutación por error. Para obtener más información, consulte Comportamiento de Private Link con replicación en varias regiones.

  • Replicación de datos: todos los cambios en las claves, las definiciones de roles y las asignaciones de roles se replican de forma asincrónica en la región extendida en un plazo de seis minutos. Espere seis minutos después de crear o actualizar una clave antes de usarla en la región extendida.

Comportamiento durante una falla de región

Cuando la replicación en varias regiones está habilitada y una región experimenta una interrupción:

  • Detección y respuesta: Azure Traffic Manager detecta la región incorrecta y enruta las solicitudes futuras a la región correcta. Los registros DNS tienen un TTL de cinco segundos, aunque las búsquedas DNS en caché por los clientes pueden experimentar tiempos de conmutación por error ligeramente más largos.
  • Notificación: Microsoft no le notifica automáticamente cuando una región está inactiva. Sin embargo, puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de región, y puede configurar alertas de Service Health para notificarle problemas.

  • Solicitudes activas: las solicitudes en tránsito a la región afectada pueden fallar y requerir un nuevo intento.

  • Pérdida de datos esperada: puede haber pérdida de datos para los cambios realizados en un plazo de seis minutos antes del error de la región si esos cambios no se hubieran completado la replicación.

  • Tiempo de inactividad esperado: Las operaciones de lectura y escritura permanecen disponibles en la región correcta durante la conmutación por error.

    Las aplicaciones cliente que están cerca de la región incorrecta pueden seguir siendo dirigidas a esa región hasta que se actualicen los registros DNS, pero esta actualización tiene lugar en aproximadamente cinco segundos. Para minimizar el tiempo de conmutación por error, los clientes deben evitar el almacenamiento en caché de las búsquedas DNS por más tiempo del TTL del registro DNS.

  • Reenrutar: Azure Traffic Manager vuelve a enrutar automáticamente las solicitudes a la región correcta.

Recuperación de regiones

Cuando se recupera la región afectada, HSM administrado reanuda automáticamente las operaciones. Traffic Manager comienza a enrutar las solicitudes a ambas regiones de nuevo en función de la proximidad.

Prueba de fallos de región

HSM administrado gestiona completamente el enrutamiento del tráfico, la conmutación por error y la recuperación tras el fallo para los fallos regionales, por lo que no es necesario validar los procesos de fallos regionales ni proporcionar ninguna intervención adicional.

Soluciones personalizadas de varias regiones para la resistencia

Si la replicación en varias regiones no es adecuada para sus necesidades, puede implementar la recuperación ante desastres manual. Todo ello requiere:

  • Dominio de seguridad del HSM de origen.
  • Las claves privadas (al menos el número de cuórum) que cifran el dominio de seguridad.
  • Una copia de seguridad completa de HSM reciente del HSM de origen.

Para realizar la recuperación ante desastres:

  1. Cree una nueva instancia de HSM administrada en otra región.
  2. Active el modo de recuperación de dominio de seguridad y cargue el dominio de seguridad.
  3. Realice una copia de seguridad del nuevo HSM (necesario antes de la restauración).
  4. Restaure la copia de seguridad desde el HSM de origen.

Importante

El nuevo HSM tiene un nombre y un URI de punto de conexión de servicio diferentes. Debe actualizar la configuración de la aplicación para usar la nueva ubicación.

Para procedimientos detallados de recuperación ante desastres, consulte Recuperación ante desastres de HSM administrado.

Copias de seguridad y restauración

Managed HSM admite copias de seguridad y restauración completas de todas las claves, versiones, atributos, etiquetas y asignaciones de roles. Las copias de seguridad se almacenan en una cuenta de Azure Storage. Si la región lo admite, se recomienda realizar una copia de seguridad de HSM administrado en una cuenta de Azure Storage que tenga habilitado el almacenamiento con redundancia geográfica (GRS).

Las copias de seguridad se cifran mediante claves criptográficas asociadas al dominio de seguridad del HSM y solo se pueden restaurar en un HSM con el mismo dominio de seguridad.

Managed HSM no admite la programación de copias de seguridad, pero puede crear su propio programador usando un servicio como Azure Functions o Azure Automation.

Mientras una copia de seguridad está en curso, es posible que el HSM no funcione en un rendimiento completo porque algunas particiones están ocupadas realizando la operación de copia de seguridad.

Para obtener procedimientos detallados de copia de seguridad y restauración, consulte Copia de seguridad y restauración completas.

Resistencia a la eliminación accidental

Managed HSM proporciona dos características clave de recuperación para evitar la eliminación accidental o malintencionada:

  • Eliminación temporal: al eliminar un HSM o una clave, permanece recuperable durante un período de conservación configurable (de 7 a 90 días, 90 días por defecto). La eliminación temporal siempre está habilitada y no se puede deshabilitar.

    Note

    Los recursos HSM administrados eliminados temporalmente continúan incurr en facturación hasta que se purgan.

  • Protección de purga: cuando está habilitada, evita la eliminación permanente del HSM administrado y sus claves hasta que transcurre el período de retención. Nadie puede deshabilitar ni invalidar la protección de purga, incluido Microsoft.

Se recomienda encarecidamente habilitar la protección de purga para entornos de producción. Para más información, consulte Managed HSM soft-delete and purge protection (Eliminación temporal de HSM administrado y protección de purga).

Resistencia al mantenimiento del servicio

HSM administrado controla el mantenimiento del servicio, incluidas las actualizaciones de firmware, la aplicación de revisiones y la recuperación de hardware, sin intervención del cliente. Durante el mantenimiento:

  • Es posible que las particiones no estén disponibles temporalmente mientras se aplican las actualizaciones.
  • Al menos dos de tres particiones permanecen disponibles durante el mantenimiento rutinario.
  • Las aplicaciones cliente deben implementar lógica de reintento para controlar breves interrupciones.

El proceso de saneamiento del servicio confidencial evita que los secretos se expongan durante las operaciones de mantenimiento.

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Managed HSM proporciona un Acuerdo de Nivel de Servicio estándar para implementaciones de una sola región. Al habilitar la replicación en varias regiones, aumenta el Acuerdo de Nivel de Servicio combinado para ambas regiones.

Contenido relacionado

  • Last updated on