Cuando las interrupciones de la nube se propaga...

Es difícil pasar por alto las recientes interrupciones importantes del servicio en la nube. Los incidentes más notorios que afectan a proveedores como AWS, Azure y Cloudflare han interrumpido gran parte de Internet y han provocado la caída de sitios web y servicios de los que dependían muchos otros sistemas. El efecto dominó resultante ha interrumpido las aplicaciones y los flujos de trabajo en los que muchas organizaciones confían todos los días.

Para los consumidores, estas interrupciones suelen ser un inconveniente, como no poder pedir comida, transmitir contenido o acceder a los servicios en línea. Sin embargo, para las empresas, el impacto es mucho más grave. Cuando el sistema de reservas de una aerolínea se desconecta, la pérdida de disponibilidad se traduce directamente en una pérdida de ingresos, un daño a la reputación y una interrupción operativa.

Estos incidentes ponen de relieve que las interrupciones de la nube afectan a mucho más que a la computación o las redes. Una de las áreas más críticas e impactantes es la identidad. ¿Cuándo autenticación y autorización se interrumpen, el resultado no es solo un tiempo de inactividad, sino un incidente operativo y de seguridad fundamental.

Infraestructura en la nube, un punto de falla compartido

Los proveedores de nube no son sistemas de identidad. Sin embargo, las arquitecturas de identidad modernas dependen en gran medida de la infraestructura alojada en la nube y de los servicios compartidos. Incluso cuando un servicio de autenticación en sí mismo sigue funcionando, las fallas en otras partes de la cadena de dependencia pueden hacer que los flujos de identidad sean inutilizables.

La mayoría de las organizaciones confían en la infraestructura de nube para los componentes críticos relacionados con la identidad, como:

• Almacenes de datos que contienen atributos de identidad e información de directorio
• Datos de políticas y autorizaciones
• Balanceadores de carga, planos de control y DNS

Estas dependencias compartidas introducen riesgos en el sistema. Un error en cualquiera de ellas puede bloquear por completo la autenticación o la autorización, incluso si el proveedor de identidad técnicamente sigue funcionando. El resultado es un punto único de error oculto que, lamentablemente, muchas organizaciones solo descubren durante una interrupción.

Identity, el guardián de todo

La autenticación y la autorización no son funciones aisladas que se utilizan solo durante el inicio de sesión, sino que son guardianes continuos para cada sistema, API y servicio. Los modelos de seguridad modernos, específicamente Zero Trust, se basan en el principio de «nunca confíes, verifica siempre» . Esa verificación depende completamente de la disponibilidad de los sistemas de identidad.

Esto se aplica igualmente a los usuarios humanos y identidades de máquinas . Las aplicaciones se autentican constantemente. Las API autorizan todas las solicitudes. Los servicios obtienen fichas para llamar a otros servicios. Cuando los sistemas de identidad no están disponibles, nada funciona.

Debido a esto, las interrupciones de identidad amenazan directamente la continuidad del negocio. Deberían activar el nivel más alto de respuesta a los incidentes, con una supervisión y alertas proactivas en todos los servicios dependientes. Tratar el tiempo de inactividad de la identidad como un problema secundario o puramente técnico subestima considerablemente su impacto.

La complejidad oculta de los flujos de autenticación

La autenticación implica mucho más que verificar un nombre de usuario y una contraseña, o una clave de acceso, a medida que las organizaciones avanzan cada vez más hacia modelos sin contraseña. Un único evento de autenticación suele desencadenar una compleja cadena de operaciones entre bastidores.

Los sistemas de identidad suelen ser:

• Resolver los atributos de usuario de directorios o bases de datos
• Almacene el estado de la sesión
• Emita tokens de acceso que contengan alcances, reclamos y atributos
• Lleve a cabo decisiones de autorización detalladas mediante motores de políticas

Las comprobaciones de autorización se pueden realizar tanto durante la emisión del token como durante el tiempo de ejecución cuando se accede a las API. En muchos casos, las API deben autenticarse y obtener los tokens antes de llamar a otros servicios.

Cada uno de estos pasos depende de la infraestructura subyacente. Los almacenes de datos, los motores de políticas, los almacenes de tokens y los servicios externos pasan a formar parte del flujo de autenticación. Un error en cualquiera de estos componentes puede bloquear por completo el acceso y afectar a los usuarios, las aplicaciones y los procesos empresariales.

Por qué la alta disponibilidad tradicional no es suficiente

La alta disponibilidad está ampliamente implementada y es absolutamente necesaria, pero a menudo es insuficiente para los sistemas de identidad. La mayoría de los diseños de alta disponibilidad se centran en la conmutación por error regional: una implementación principal en una región y una secundaria en otra. Si una región falla, el tráfico se desplaza hacia la copia de seguridad.

Este enfoque fracasa cuando las fallas afectan a los servicios compartidos o globales. Si los sistemas de identidad de varias regiones dependen del mismo plano de control de la nube, proveedor de DNS o servicio de base de datos gestionado, la conmutación por error regional ofrece poca protección. En estos casos, el sistema de respaldo falla por los mismos motivos que el principal.

El resultado es una arquitectura de identidad que parece resiliente sobre el papel, pero que se derrumba ante interrupciones a gran escala en la nube o en toda la plataforma.

Diseño de resiliencia para sistemas de identidad

La verdadera resiliencia debe diseñarse deliberadamente. En el caso de los sistemas de identidad, esto suele significar reducir la dependencia de un único proveedor o dominio de fallos. Los enfoques pueden incluir estrategias de nube múltiple o alternativas locales controladas que permanecen accesibles incluso cuando los servicios en la nube se degradan.

Igualmente importante es la planificación de una operación degradada. La denegación total del acceso durante una interrupción tiene el mayor impacto empresarial posible. Permitir un acceso limitado, en función de los atributos almacenados en caché, las decisiones de autorización precalculadas o la reducción de la funcionalidad, puede reducir drásticamente el daño operativo y a la reputación.

No todos los datos relacionados con la identidad necesitan el mismo nivel de disponibilidad. Algunos atributos o fuentes de autorización pueden ser menos tolerantes a errores que otros, y eso puede ser aceptable. Lo que importa es hacer estas concesiones de forma deliberada, basándose en el riesgo empresarial y no en la conveniencia arquitectónica.

Los sistemas de identidad deben diseñarse para que fallen sin problemas. Cuando las interrupciones de la infraestructura son inevitables, control de acceso debería degradarse de manera predecible, no colapsar por completo.

¿Está listo para comenzar con una solución sólida de administración de identidades? Pruebe el servidor Curity Identity de forma gratuita .