Habilitar la replicación de varias regiones en HSM administrado de Azure
La replicación en varias regiones permite ampliar un grupo de HSM administrado desde una región de Azure (denominada región primaria) a otra región de Azure (denominada región extendida). Una vez configurada, ambas regiones están activas, pueden atender solicitudes y, con la replicación automatizada, compartir el mismo material clave, roles y permisos. La región disponible más cercana a la aplicación recibe y cumple la solicitud, lo que maximiza el rendimiento de lectura y la latencia. Aunque las interrupciones regionales son poco frecuentes, la replicación de varias regiones mejora la disponibilidad de claves criptográficas críticas si una región deja de estar disponible. Para más información sobre el Acuerdo de Nivel de Servicio, consulte Acuerdo de Nivel de Servicio para HSM administrado de Azure Key Vault.
Architecture
Cuando la replicación en varias regiones está habilitada en un HSM administrado, se crea un segundo grupo de HSM administrado, con tres particiones HSM con equilibrio de carga, en una región extendida. Cuando se emiten solicitudes al punto de conexión DNS global <hsm-name>.managedhsm.azure.net de Traffic Manager, la región disponible más cercana recibe y cumple la solicitud. Aunque cada región mantiene individualmente la alta disponibilidad regional debido a la distribución de HSM en toda la región, el administrador de tráfico garantiza que incluso si todas las particiones de un HSM administrado en una región no están disponibles debido a una catástrofe, el grupo de HSM administrado todavía puede atender las solicitudes en la región extendida.
Latencia de replicación
Cualquier operación de escritura en el HSM administrado, como crear o actualizar una clave, crear o actualizar una definición de rol, o crear o actualizar una asignación de roles, puede tardar hasta 6 minutos antes de que ambas regiones se repliquen completamente. Dentro de esta ventana, no se garantiza que el material escrito se haya replicado entre las regiones. Por lo tanto, es mejor esperar seis minutos entre crear o actualizar la clave y usar la clave para asegurarse de que el material de clave se ha replicado completamente entre regiones. Lo mismo se aplica a las asignaciones de roles y las definiciones de roles.
Comportamiento de conmutación por error
La conmutación por error se produce cuando una de las regiones de un HSM administrado de varias regiones deja de estar disponible debido a una interrupción y la otra región comienza a atender todas las solicitudes. La interrupción puede limitarse solo al grupo de HSM, al servicio HSM administrado completo o a toda la región de Azure. Durante la conmutación por error, puede observar un cambio en el comportamiento en función de la región afectada.
| Región afectada | Lecturas permitidas | Escrituras permitidas |
|---|---|---|
| Región extendida | Sí | Sí |
| Región principal | Sí | Es posible |
Si una región extendida deja de estar disponible, las operaciones de lectura (obtener clave, enumerar claves, todas las operaciones criptográficas, enumerar asignaciones de roles) están disponibles si la región primaria está activa. Las operaciones de escritura (crear y actualizar claves, crear y actualizar asignaciones de roles, crear y actualizar definiciones de roles) también están disponibles.
Si la región primaria no está disponible, las operaciones de lectura están disponibles, pero es posible que las operaciones de escritura no, en función del ámbito de la interrupción.
Tiempo de conmutación por error
En segundo plano, la resolución DNS controla la redirección de solicitudes a las regiones primarias o extendidas.
Si ambas regiones están activas, Traffic Manager resuelve las solicitudes entrantes en la ubicación que tiene la proximidad geográfica más cercana o la latencia de red más baja al origen de la solicitud. Los registros DNS se configuran con un TTL predeterminado de 5 segundos.
Si una región notifica un estado incorrecto a Traffic Manager, las futuras solicitudes se resuelven en la otra región si están disponibles. Los clientes que almacenan en caché las búsquedas DNS pueden experimentar un tiempo de conmutación por error extendido. Pero una vez que las cachés del lado cliente expiren, las solicitudes futuras deben enrutarse a la región disponible.
Compatibilidad con regiones de Azure
Las siguientes regiones se admiten como regiones principales (regiones desde las que puede replicar un grupo de HSM administrado)
- Este de EE. UU.
- Este de EE. UU. 2
- Norte de Reino Unido
- Oeste de Europa
- Oeste de EE. UU.
- Este de Canadá
- Centro de Catar
- Este de Asia
- Sudeste de Asia
- Sur de Reino Unido 2
- Centro de EE. UU.
- Japón Oriental
- Norte de Suiza
- Sur de Brasil
- Centro de Australia
- India central
- Oeste de EE. UU. 3
- Centro de Canadá
- Este de Australia
- Sur de India
- Centro de Suecia
- Norte de Sudáfrica
- Centro de Corea del Sur
- Norte de Europa
- Centro de Francia
- Japón Occidental
- Centro y Sur de EE. UU.
- Centro de Polonia
- Oeste de Suiza
- Sudeste de Australia
- India occidental
- Centro de Emiratos Árabes Unidos
- Norte de Emiratos Árabes Unidos
- Oeste de EE. UU. 2
- Centro-oeste de EE. UU.
Nota:
Centro de EE. UU., Este de EE. UU., Centro-sur de EE. UU., Oeste de EE. UU. 2, Norte de Suiza, Oeste de Europa, Centro de Canadá, Este de Canadá, Oeste de Japón, Centro de Qatar, Centro de Polonia y Centro-oeste de EE. UU. en este momento, no se pueden ampliar las regiones. Otras regiones pueden no estar disponibles para la extensión debido a limitaciones de capacidad en la región.
Facturación
La replicación en varias regiones en una región extendida incurre en facturación adicional (x2), ya que se consume un nuevo grupo de HSM en una región extendida. Para más información, consulte Precios del HSM administrado de Azure.
Comportamiento de eliminación temporal
La característica de eliminación temporal de HSM administrado permite la recuperación de HSM eliminados y claves, sin embargo, en un escenario habilitado para la replicación en varias regiones, hay diferencias sutiles en las que el HSM secundario debe eliminarse antes de que se pueda ejecutar la eliminación temporal en el HSM principal. Además, cuando se quita una región extendida del HSM principal, el HSM en la región eliminada se purga en lugar de escribir un estado de eliminación temporal y la facturación del HSM purgado finaliza inmediatamente. Siempre puede extenderse a una nueva región extendida desde la principal si es necesario.
Comportamiento de vínculo privado con replicación de varias regiones
La característica de Azure Private Link permite acceder al servicio de HSM administrado a través de un punto de conexión privado en la red virtual. Configuraría el punto de conexión privado en el HSM administrado en la región primaria del mismo modo que lo haría al no usar la característica de replicación de varias regiones. Para el HSM administrado en una región extendida, se recomienda crear otro punto de conexión privado y una zona DNS privada una vez que el HSM administrado de la región primaria se replique en el HSM administrado en una región extendida. Esto redirigirá las solicitudes de cliente al HSM administrado más cercano a la ubicación del cliente.
Algunos escenarios siguientes con ejemplos: HSM administrado en una región primaria (Sur de Reino Unido) y otro HSM administrado en una región extendida (Centro-oeste de EE. UU.).
Cuando los HSM administrados de las regiones primarias y extendidas están en funcionamiento con el punto de conexión privado habilitado, las solicitudes de cliente se redirigen al HSM administrado más cercano a la ubicación del cliente. Las solicitudes de cliente van al punto de conexión privado de la región más cercana y, a continuación, se dirigen al HSM administrado de la misma región por el administrador de tráfico.
Cuando uno de los HSM administrados (Sur de Reino Unido, como ejemplo) en un escenario replicado de varias regiones no está disponible con puntos de conexión privados habilitados, las solicitudes de cliente se redirigen al HSM administrado disponible (Centro-oeste de EE. UU.). Las solicitudes de cliente del sur de Reino Unido irán primero al punto de conexión privado del sur de Reino Unido y, después, se dirigirán al HSM administrado por el centro de EE. UU. por el administrador de tráfico.
HSM administrados en regiones primarias y extendidas, pero solo un punto de conexión privado configurado en la región primaria o extendida. Para que un cliente de otra red virtual (VNET1) se conecte a un HSM administrado a través de un punto de conexión privado en otra red virtual (VNET2), requiere emparejamiento de VNET entre las dos redes virtuales. Puede agregar un vínculo de red virtual para la zona DNS privada que se crea durante la creación del punto de conexión privado.
En el diagrama siguiente, el punto de conexión privado solo se crea en la región Sur de Reino Unido, mientras que hay dos HSM administrados en funcionamiento uno en el Sur de Reino Unido y el otro en el Centro-oeste de EE. UU. Las solicitudes de ambos clientes van al HSM administrado por el sur del Reino Unido, ya que las solicitudes se enrutan a través del punto de conexión privado y la ubicación del punto de conexión privado en este caso se encuentra en el Sur de Reino Unido.
En el diagrama siguiente, el punto de conexión privado solo se crea en la región Sur de Reino Unido, solo el HSM administrado en el Centro-oeste de EE. UU. está disponible y el HSM administrado en el Sur de Reino Unido no está disponible. En este caso, las solicitudes se redirigirán al HSM administrado Centro-oeste de EE. UU. a través del punto de conexión privado del Sur de Reino Unido porque Traffic Manager detecta que el HSM administrado por el Sur de Reino Unido no está disponible.
Comandos de la CLI de Azure
Si crea un nuevo grupo de HSM administrado y, después, se extiende a una región extendida, consulte estas instrucciones antes de extenderse. Si se extiende desde un grupo de HSM administrado ya existente, siga estas instrucciones para extender el grupo de HSM a una región extendida.
Nota:
Estos comandos requieren la versión 2.48.1 o posterior de la CLI de Azure. Para instalar la última versión, vea Cómo instalar la CLI de Azure.
Extensión de un HSM principal a una región extendida
Para extender un grupo de HSM administrado a otra región, ejecute el siguiente comando que creará automáticamente un nuevo HSM en una región extendida.
az keyvault region add --hsm-name "ContosoMHSM" --region "australiaeast"
Nota:
"ContosoMHSM" en este ejemplo es el nombre del grupo de HSM principal; "australiaeast" es la región extendida en la que se va a extender.
Eliminación de una región extendida del HSM principal
Una vez quitado un HSM extendido, se purgarán las particiones de HSM de la otra región. Deben eliminarse todos los secundarios antes de poder borrar o purgar un HSM administrado como primario. Solo se pueden eliminar secundarios mediante este comando. La base de datos principal solo se puede eliminar mediante los comandos de eliminación temporal y purga
az keyvault region remove --hsm-name ContosoMHSM --region australiaeast
Enumerar todas las regiones
az keyvault region list --hsm-name ContosoMHSM