Confiabilidad en HSM administrado de Azure Key Vault

Azure Key Vault HSM administrado es un servicio en la nube totalmente administrado, de alta disponibilidad, de un solo inquilino y compatible con estándares que le permite proteger las claves criptográficas de las aplicaciones en la nube mediante módulos de seguridad de hardware (HSM) que se validan en 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 varias posibles interrupciones y problemas, incluidos errores transitorios, errores de partición y interrupciones de región. También se describe cómo usar copias de seguridad y el dominio de seguridad para la recuperación ante desastres, cómo las características de recuperación protegen contra la eliminación accidental e información clave sobre el contrato de nivel de servicio (SLA) de HSM administrado.

Recomendaciones de implementación de producción

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

  • Descargue y almacene de forma segura el dominio de seguridad inmediatamente después de aprovisionar el HSM administrado. Necesita el dominio de seguridad para la recuperación ante desastres.
  • Establezca un cuórum de varias personas para el dominio de seguridad con al menos tres poseedores de claves.
  • Habilite la protección de purga para evitar la eliminación accidental o malintencionada.
  • Implemente copias de seguridad periódicas en una cuenta de Azure Storage y use el almacenamiento con redundancia geográfica en regiones admitidas.
  • Habilite la replicación en varias regiones para cargas de trabajo críticas que requieran un Acuerdo de Nivel de Servicio superior.

Introducción a la arquitectura de confiabilidad

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

La arquitectura de HSM administrado está diseñada para lograr alta disponibilidad y durabilidad.

  • Aislamiento de un solo inquilino: Cada instancia de HSM administrada se dedica a un único 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 afecta 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, incluidas las personas con acceso físico a los servidores, no puede acceder a su material criptográfico de claves.

  • 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 obtener información sobre cómo Managed HSM implementa estas funcionalidades, consulte Soberanía clave, disponibilidad, rendimiento y escalabilidad en HSM administrado.

Dominio de seguridad

El dominio de seguridad es un componente crítico de HSM administrado con fines de 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:

  • Genere claves de forma segura: En entornos de producción, genere los pares de claves RSA que protegen el dominio de seguridad en un entorno con disponibilidad inalámbrica, como un HSM local o una estación de trabajo aislada.

  • Almacenar sin conexión: Almacene 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: Utilice al menos tres custodios de claves para evitar que una sola persona tenga acceso a todas las claves del cuórum y para evitar depender de una sola persona.

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 reintento, incluido el retroceso exponencial, para cualquier código que interactúe directamente con HSM administrado.

  • 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. Realice operaciones de clave pública, como el cifrado, el ajuste y la comprobación, localmente mediante el almacenamiento en caché del material de clave pública. La realización de las operaciones localmente reduce la dependencia del HSM administrado y reduce la probabilidad de errores transitorios que interrumpen estas operaciones.

Si usa Managed HSM en escenarios de alto rendimiento, Managed HSM 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 Disponibilidad de HSM administrada para comprender el estado del servicio.

Para escalar el cifrado de grandes volúmenes de datos, use una jerarquía de claves. Almacene solo la clave de cifrado de claves (KEK) en HSM administrado y úsela para encapsular las claves de cifrado de datos de nivel inferior almacenadas en otro lugar del almacenamiento seguro de claves.

Para obtener más información sobre las pruebas comparativas de rendimiento y el planeamiento de la capacidad, consulte Azure guía de escalado de HSM administrado.

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 en buen estado mediante TLS con atestación y enclaves Intel SGX para proteger los secretos durante la recuperación.

Cost

La alta disponibilidad integrada en HSM administrado no agrega ningún costo adicional. Los precios se basan en el número de grupos de HSM y en el número de operaciones que se realizan. 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 del tráfico: HSM administrado administra automáticamente el enrutamiento de tráfico entre sus tres particiones. Durante las operaciones normales, distribuye de forma transparente las solicitudes entre particiones.

  • Replicación de datos: HSM administrado replica de forma sincrónica todos los datos, incluidas las claves, las asignaciones de roles y las directivas de control de acceso, en las tres particiones. Este enfoque 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 detecta errores de partición y responde 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 sin tiempo de inactividad durante un error de partición. Las particiones sanas restantes siguen atendiendo solicitudes.

  • Reenrutamiento 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 en Managed HSM se basa en la distribución a nivel de bastidor dentro de un centro de datos, no en el despliegue explícito en 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 problemas de fuente de alimentación o conmutador de red.

Para protegerse frente a interrupciones en todo el centro de datos o en toda la zona de disponibilidad, use uno de los enfoques descritos en 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, que puede usar para ampliar un grupo de HSM administrado desde una región de Azure (región primaria) a una segunda región Azure (la región extendida). Al configurar esta característica:

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

Requirements

  • Compatibilidad con regiones: Todas las regiones que admiten HSM administrado se pueden usar como regiones principales. 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 en varias regiones incurre en facturación adicional porque la región extendida consume un segundo grupo de HSM. 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

En esta sección se describe qué esperar al configurar la replicación en varias regiones y ambas regiones están operativas.

  • Enrutamiento del 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 Azure Private Link para acceder a HSM administrado, 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

En esta sección se describe qué esperar al configurar la replicación en varias regiones y se produce una interrupción en una de las regiones de réplica.

  • 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 tiempo de vida (TTL) de cinco segundos, aunque los clientes que almacenan en caché las búsquedas de DNS podrían experimentar tiempos de conmutación por error ligeramente más prolongados.
  • 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.

  • Peticiones activas: Las peticiones en curso a la región afectada pueden fallar y requerir que se vuelvan a intentar.

  • Pérdida de datos esperada: Es posible que los cambios realizados en un plazo de seis minutos antes del error de la región no se repliquen en la región extendida. Esos cambios podrían perderse si la región primaria es irrecuperable.

  • 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. Azure 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. Este enfoque 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).

El HSM cifra las copias de seguridad mediante claves criptográficas asociadas al dominio de seguridad de HSM. Solo puede restaurar copias de seguridad 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: Los HSM y las claves eliminados no se eliminan definitivamente de inmediato. Permanecen recuperables durante un período de retención configurable de 7 a 90 días (valor predeterminado: 90 días). 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 el servicio deje de estar disponible temporalmente las particiones mientras aplica 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 autorreparación del servicio confidencial garantiza que el servicio nunca exponga secretos 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.

HSM administrado proporciona un Acuerdo de Nivel de Servicio de disponibilidad estándar para implementaciones de una sola región. Habilitar la replicación multirregional aumenta el tiempo de actividad general previsto, porque las peticiones se pueden atender desde cualquiera de las dos regiones si una deja de estar disponible.

Contenido relacionado

  • Last updated on