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 principal) a otra región de Azure (denominada secundaria). 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 la región secundaria. 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, aunque 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 secundario todavía pueda atender las solicitudes.
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 |
|---|---|---|
| Secundario | Sí | Sí |
| Principal | Sí | Es posible |
Si la región secundaria 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 el redireccionamiento de las solicitudes a la región primaria o secundaria.
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 la India, centro de Canadá, este de Canadá, oeste de Japón, centro de Catar, centro de Polonia y centro-oeste de EE. UU. no se pueden extender como una región secundaria en este momento. Otras regiones pueden no estar disponibles para la extensión debido a limitaciones de capacidad en la región.
Facturación
La replicación de varias regiones en la región secundaria incurre en facturación adicional (x2), ya que se consume un nuevo grupo de HSM en la región secundaria. 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 elimina una base de datos secundaria, se purga inmediatamente y no entra en un estado de eliminación temporal que detiene toda la facturación de la base de datos secundaria. Siempre puede extenderse a una nueva región como secundaria 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 la región secundaria, se recomienda crear otro punto de conexión privado una vez que el HSM administrado de la región primaria se replique en el HSM administrado en la región secundaria. 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 secundaria (Centro-oeste de EE. UU.).
Cuando los HSM administrados de las regiones principal y secundaria 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 secundarias, pero solo un punto de conexión privado configurado en principal o secundario. 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, extiende a una base de datos secundaria, consulte estas instrucciones antes de extender. Si extiende desde un grupo de HSM administrado ya existente, siga las instrucciones siguientes para crear un HSM secundario en otra región.
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.
Adición de un HSM secundario en otra región
Para extender un grupo de HSM administrado a otra región, ejecute el siguiente comando que creará automáticamente un segundo HSM.
az keyvault region add --hsm-name "ContosoMHSM" --region "australiaeast"
Nota
"ContosoMHSM" en este ejemplo es el nombre del grupo de HSM primario; "australiaeast" es la región secundaria a la que lo está extendiendo.
Eliminación de un HSM secundario en otra región
Una vez quitado un HSM secundario, 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