Es difícil pasar por alto las recientes interrupciones importantes del servicio en la nube. Los incidentes de alto perfil que afectaron a proveedores como AWS, Azure y Cloudflare han perturbado gran parte de Internet, destruyendo sitios web y servicios de los que dependen muchos otros sistemas. El efecto dominó resultante ha detenido las aplicaciones y los flujos de trabajo de los que muchas organizaciones dependen todos los días.
Para los consumidores, estas interrupciones a menudo se perciben como un inconveniente, como no poder pedir comida, transmitir contenido o acceder a 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 pérdida de ingresos, daños a la reputación e interrupciones operativas.
Estos incidentes resaltan que las interrupciones en la nube afectan mucho más que la computación o las redes. Una de las áreas más críticas e impactantes es la identidad. Cuando autenticación y autorización se interrumpen, el resultado no es sólo tiempo de inactividad; es un incidente operativo y de seguridad central.
Infraestructura en la nube, un punto de falla compartido
Los proveedores de nube no son sistemas de identidad. Pero las arquitecturas de identidad modernas dependen profundamente de la infraestructura alojada en la nube y de los servicios compartidos. Incluso cuando un servicio de autenticación sigue siendo funcional, las fallas en otras partes de la cadena de dependencia pueden inutilizar los flujos de identidad.
La mayoría de las organizaciones dependen de la infraestructura de la nube para componentes críticos relacionados con la identidad, como:
- Almacenes de datos que contienen atributos de identidad e información de directorio
- Datos de política y autorización
- Equilibradores de carga, planos de control y DNS
Estas dependencias compartidas introducen riesgos en el sistema. Una falla en cualquiera de ellos puede bloquear la autenticación o autorización por completo, incluso si técnicamente el proveedor de identidad todavía está ejecutándose. El resultado es un único punto de falla oculto que, desafortunadamente, muchas organizaciones solo descubren durante una interrupción.
La identidad, el guardián de todo
La autenticación y la autorización no son funciones aisladas que se utilizan únicamente durante el inicio de sesión: son guardianes continuos de cada sistema, API y servicio. Los modelos de seguridad modernos, específicamente Zero Trust, se basan en el principio de “nunca confíes, siempre verifica”. Esa verificación depende enteramente de la disponibilidad de sistemas de identidad.
Esto se aplica igualmente a los usuarios humanos y identidades de máquinas. Las aplicaciones se autentican constantemente. Las API autorizan cada solicitud. Los servicios obtienen tokens 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. Deben activar el nivel más alto de respuesta a incidentes, con monitoreo y alertas proactivos en todos los servicios dependientes. Tratar el tiempo de inactividad de la identidad como un problema secundario o puramente técnico subestima significativamente 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 cadena compleja de operaciones entre bastidores.
Los sistemas de identidad suelen ser:
- Resolver atributos de usuario desde directorios o bases de datos.
- Almacenar estado de sesión
- Emitir tokens de acceso que contengan alcances, reclamos y atributos
- Tome decisiones de autorización detalladas utilizando motores de políticas
Las comprobaciones de autorización pueden realizarse tanto durante la emisión de tokens como en tiempo de ejecución cuando se accede a las API. En muchos casos, las API deben autenticarse y obtener 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. Una falla en cualquiera de estos componentes puede bloquear completamente el acceso, afectando a los usuarios, las aplicaciones y los procesos comerciales.
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 primaria en una región con 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 servicios compartidos o globales. Si los sistemas de identidad en varias regiones dependen del mismo plano de control de la nube, proveedor de DNS o servicio de base de datos administrado, la conmutación por error regional proporciona poca protección. En estos escenarios, el sistema de respaldo falla por las mismas razones que el principal.
El resultado es una arquitectura de identidad que parece resiliente en el papel, pero colapsa 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. Para los sistemas de identidad, esto a menudo significa reducir la dependencia de un único proveedor o dominio de falla. Los enfoques pueden incluir estrategias de múltiples nubes o alternativas locales controladas que permanecen accesibles incluso cuando los servicios de nube se degradan.
Igualmente importante es la planificación para un funcionamiento degradado. Denegar completamente el acceso durante una interrupción tiene el mayor impacto empresarial posible. Permitir un acceso limitado, basado en atributos almacenados en caché, decisiones de autorización precalculadas o funcionalidad reducida, puede reducir drásticamente el daño operativo y de 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 fallos que otros, y eso puede ser aceptable. Lo que importa es hacer estas concesiones deliberadamente, basándose en el riesgo empresarial más que en la conveniencia arquitectónica.
Los sistemas de identidad deben diseñarse para fallar con gracia. Cuando los cortes de infraestructura son inevitables, control de acceso debería degradarse de manera predecible, no colapsar por completo.
¿Listo para comenzar con una sólida solución de administración de identidades? Pruebe Curity Identity Server gratis.