“Continuando nuestra serie de confiabilidad de Azure para ser lo más transparentes posible en cuanto a las iniciativas clave en curso a fin de seguir mejorando la disponibilidad, hoy centramos nuestra atención en Azure Active Directory. Microsoft Azure Active Directory (Azure AD) es un servicio de identidad en la nube que proporciona acceso seguro a más de 250 millones de usuarios activos mensuales, conectando más de 1,4 millones de aplicaciones únicas y procesando más de 30 000 millones de solicitudes de autenticación diarias. Esto hace que Azure AD no solo sea la mayor solución de administración de identidad y acceso empresarial, sino fácilmente uno de los mayores servicios del mundo. Nadim Abdo, director asociado del departamento de ingeniería, escribió la publicación mostrada a continuación. Es, además, líder de estos esfuerzos.” - Mark Russinovich, director de tecnología, Azure

---

 

Nuestros clientes confían en Azure AD para administrar el acceso seguro a todas sus aplicaciones y servicios. Para nosotros, esto significa que todas las solicitudes de autenticación son una operación crítica. Dadas la naturaleza crítica y la escala del servicio, la prioridad principal de nuestro equipo de identidad es la confiabilidad y seguridad del servicio. Azure AD se ha diseñado para aportar disponibilidad y seguridad mediante una arquitectura verdaderamente nativa en la nube, de hiperescala y multiinquilino, y nuestro equipo tiene un programa continuo de subida del listón de la confiabilidad y la seguridad.

Azure AD: principios de disponibilidad principales

Diseñar un servicio de esta escala, complejidad e importancia crítica para que su disponibilidad sea alta en un mundo donde todo lo que creamos produce un error o puede producirlo es una tarea compleja.

Nuestras inversiones en resistencia se organizan en torno al conjunto de principios de confiabilidad indicados a continuación:

Nuestro trabajo de disponibilidad adopta un enfoque de defensa por niveles para reducir la posibilidad de errores visibles del cliente tanto como sea posible; si se produce un error, reduzca el impacto de dicho error en la medida de lo posible y, por último, reduzca el tiempo que se tarda en recuperar y mitigar un error tanto como sea posible.

En las próximas semanas y meses, profundizaremos en el diseño y la comprobación en la práctica de cada uno de los principios, y proporcionaremos ejemplos a nuestros clientes de su funcionamiento.

Con redundancia alta

Azure AD es un servicio global con varios niveles de redundancia interna y capacidad de recuperación automática. Azure AD se implementa en más de 30 centros de datos de todo el mundo aprovechando Azure Availability Zones donde está presente. Este número aumenta con rapidez a medida que se implementan regiones de Azure adicionales.

Para aportar durabilidad, cualquier elemento de datos escritos en Azure AD se replica en al menos cuatro y hasta 13 centros de datos dependiendo de la configuración del inquilino. En cada centro de datos, los datos vuelven a replicarse al menos 19 veces por razones de durabilidad, pero también para escalar horizontalmente la capacidad para proporcionar la carga de autenticación. A modo de ilustración, esto significa que en cualquier momento hay al menos 36 copias de los datos del directorio disponibles en nuestro servicio, en nuestra región más pequeña. Por razones de durabilidad, las escrituras en Azure AD no se completan hasta que se proporciona una confirmación correcta a un centro de datos fuera de la región.

Este enfoque nos aporta tanto la durabilidad de los datos como una redundancia masiva: varias rutas de acceso de red y centros de datos pueden atender cualquier solicitud de autorización especificada, y el sistema lleva a cabo reintentos y enrutamientos de forma automática e inteligente en torno a errores dentro de un centro de datos y entre los centros de datos.

Para validar esto, solemos llevar a cabo la inserción de errores, además de validar la resistencia del sistema a errores de los componentes del sistema en los que se basa Azure AD. Esto se amplía totalmente para extraer centros de datos completos de forma regular a fin de confirmar que el sistema puede tolerar la pérdida de un centro de datos sin impacto alguno en los clientes.

Ningún único punto de error (SPOF)

Como ya se ha mencionado, el propio Azure AD se ha diseñado con varios niveles de resistencia interna, pero nuestro principio se amplía aún más para tener resistencia en todas nuestras dependencias externas. Esto se expresa en nuestro principio de ningún único punto de error (SPOF).

Dada la importancia crítica de nuestros servicios, no aceptamos SPOF en sistemas externos críticos como el servicio de nombres distribuidos (DNS), instancias de Content Delivery Network (CDN) o proveedores de telecomunicaciones que transportan nuestra Multi-Factor Authentication (MFA), incluidos SMS y voz. En cada uno de estos sistemas, usamos varios sistemas redundantes configurados en una configuración activa-activa completa.

Gran parte de ese trabajo en este principio ha finalizado durante el último año natural y, a modo de ilustración, cuando un proveedor de DNS de gran tamaño ha sufrido una interrupción recientemente, Azure AD en su totalidad se ha librado de verse afectado, ya que contábamos con una ruta de acceso activa/activa a un proveedor alternativo.

Se escala elásticamente

Azure AD ya es un sistema masivo que se ejecuta en más de 300 000 núcleos de CPU y puede contar con la escalabilidad masiva de la nube de Azure para escalar verticalmente de forma dinámica y rápida a fin de satisfacer cualquier demanda. Esto puede incluir aumentos naturales del tráfico, como un pico en las autenticaciones a las 9 de la mañana en una región especificada, pero también volúmenes elevados de tráfico nuevo que atiende nuestro Azure AD B2C, el cual potencia algunos de los mayores eventos del mundo y suele ver demandas de millones de nuevos usuarios.

Como nivel de resistencia adicional, Azure AD aprovisiona su capacidad en exceso y un punto de diseño es que la conmutación por error de un centro de datos completo no requiere ningún aprovisionamiento adicional de la capacidad para controlar la carga redistribuida. Esto nos proporciona la flexibilidad de saber que en una emergencia ya tenemos a mano toda la capacidad que necesitamos.

Implementación segura

La implementación segura garantiza que los cambios (código o configuración) progresen gradualmente de la automatización interna a los anillos de autohospedaje internos de Microsoft y la producción. En producción, adoptamos un aumento muy graduado y lento del porcentaje de usuarios expuestos a un cambio con comprobaciones de estado automatizadas que controlan la progresión de un anillo de implementación al siguiente. Este proceso completo tarda más de una semana en implementar totalmente un cambio en la producción y puede revertirse rápidamente en cualquier momento al último estado correcto conocido.

Este sistema suele detectar posibles errores en lo que llamamos nuestros "anillos anticipados", internos de Microsoft en su totalidad, y evita su implementación en aquellos anillos que afectarían al tráfico de cliente o producción.

Verificación moderna

Para respaldar las comprobaciones de estado que controlan la implementación segura y proporcionan a nuestro equipo de ingeniería información sobre el estado de los sistemas, Azure AD emite una cantidad masiva de telemetría interna, métricas y señales usadas para supervisar el estado de nuestros sistemas. En nuestra escala, esto es superior a 11 petabytes por semana de señales que alimentan nuestros sistemas de seguimiento de estado automatizados. A su vez, esos sistemas desencadenan alertas de automatización, así como nuestro equipo de ingenieros con disponibilidad total que responden a cualquier posible degradación de la disponibilidad o la Calidad de servicio (QoS).

Nuestro recorrido aquí amplía esa telemetría para proporcionar una óptica no solo del estado de los servicios, sino de las métricas que realmente representan el estado integral de un escenario especificado para un inquilino determinado. Nuestro equipo ya alerta sobre estas métricas de forma interna y evaluamos cómo exponer estos datos de estado por inquilino directamente para los clientes en Azure Portal.

Creación de particiones y dominios de error específicos

Una buena analogía para entender mejor Azure AD son los compartimientos de un submarino, diseñados para poder inundarse sin que afecte a otros compartimientos o a la integridad de toda la nave.

El equivalente de Azure AD es un dominio de error y las unidades de escalado que proporcionan un conjunto de inquilinos en un dominio de error se han diseñado para aislarse completamente de otras unidades de escalado del dominio de error. Estos dominios de error proporcionan el aislamiento permanente de muchas clases de errores de tal forma que la "onda expansiva" de un error se incluya en un dominio de error especificado.

Hasta ahora, Azure AD ha constado de cinco dominios de error independientes. En el último año y con vistas a finalizar el próximo verano, este número aumentará hasta 50 dominios de error y muchos servicios, incluida Azure Multi-Factor Authentication (MFA), migran para aislarse completamente en esos mismos dominios de error.

Este trabajo de creación de particiones permanente se ha diseñado para ser un comodín final que abarca cualquier interrupción o error para un máximo de 1/50 o el ~2 % de nuestros usuarios. Nuestro objetivo es aumentarlo aún más hasta cientos de dominios de error en el próximo año.

Una vista previa de lo que está por llegar

El objetivo de los principios anteriores es proteger el servicio de Azure AD principal. Dada la naturaleza crítica de Azure AD, no nos detendremos ahí: en las futuras publicaciones se tratarán las nuevas inversiones que realizamos, incluidos la implementación en producción un segundo y un servicio de identidad no correlacionado al 100 % con los errores que puede proporcionar compatibilidad con la autenticación de reserva sin problemas en caso de que se produzca un error en el servicio de Azure AD principal.

Piense en esto como el equivalente a un generador de copias de seguridad o un sistema de alimentación ininterrumpida (UPS) que puede proporcionar cobertura y protección en caso de que la red eléctrica se vea afectada. Este sistema es totalmente transparente y perfecto para los usuarios finales, y en estos momentos se encuentra en producción protegiendo una parte de nuestros flujos de autenticación críticos para un conjunto de cargas de trabajo de M365. Ampliaremos rápidamente su aplicabilidad para abarcar más escenarios y cargas de trabajo.

Esperamos compartir más en nuestro blog sobre identidad de Azure Active Directory, así como escuchar sus preguntas y temas de interés para futuras publicaciones.