Uso de una plataforma de servicio de identidad totalmente administrada

  • Artículo

Casi todas las aplicaciones en la nube deben trabajar con identidades de usuario. La identidad es la base de los procedimientos de seguridad modernos, como la confianza cero, y la identidad del usuario para las aplicaciones es una parte fundamental de la arquitectura de la solución.

Para la mayoría de las soluciones, se recomienda usar una plataforma de identidad como servicio (IDaaS), una solución de identidad totalmente administrada, en lugar de crear u operar la suya propia. En este artículo, se describen los desafíos de la creación o ejecución de su propio sistema de identidad.

Recomendaciones

Importante

Mediante el uso de IDaaS, como Microsoft Entra ID, Azure AD B2C u otro sistema similar, puede mitigar muchos de los problemas que se describen en este artículo. Se recomienda este enfoque siempre que sea posible.

Los requisitos de la solución pueden llevarle a usar un marco o una solución de identidad estándar que hospede y ejecute usted mismo. Aunque el uso de una plataforma de identidad creada previamente mitiga algunos de los problemas que se describen en este artículo, el control de muchos de estos problemas sigue siendo su responsabilidad con ese tipo de solución.

Debe evitar el uso de un sistema de identidad que cree desde cero.

Evitar almacenar las credenciales

Al ejecutar su propio sistema de identidad, debe almacenar una base de datos de credenciales. Nunca debe almacenar credenciales en texto no cifrado ni como datos cifrados.

En su lugar, puede considerar la posibilidad de aplicar algoritmos hash criptográficos y cifrar con sal las credenciales antes de almacenarlas, lo que hace que sean más difíciles de atacar. Sin embargo, incluso las credenciales con código hash y cifradas con sal son vulnerables a varios tipos de ataques.

Independientemente de cómo proteja las credenciales individuales, el mantenimiento de una base de datos de credenciales le convierte en un objetivo de ataques. Los últimos años han demostrado que tanto las organizaciones grandes como las pequeñas han sufrido ataques a sus bases de datos de credenciales.

Considere el almacenamiento de credenciales como una responsabilidad, no un recurso. Mediante el uso de IDaaS, externaliza el problema del almacenamiento de credenciales en expertos que pueden invertir tiempo y recursos en la administración segura de las credenciales.

Implementación de protocolos de identidad y federación

Los protocolos de identidad modernos son complejos. Los expertos del sector han diseñado OAuth 2, OpenID Connect y otros protocolos para asegurarse de que mitigan los ataques y vulnerabilidades del mundo real. Los protocolos también evolucionan para adaptarse a los cambios en las tecnologías, las estrategias de ataque y las expectativas del usuario. Los especialistas en identidad, con experiencia en los protocolos y cómo se usan, están en la mejor posición para implementar y validar sistemas que siguen estos protocolos. Para obtener más información sobre los protocolos y la plataforma, consulte OAuth 2.0 y OpenID Connect (OIDC) en la Plataforma de identidad de Microsoft.

También es habitual federar los sistemas de identidad. Los protocolos de federación de identidades son complejos de establecer, administrar y mantener, y requieren conocimientos especializados y experiencia. Para obtener más información, consulte Patrón de identidad federada.

Adopción de características de identidad modernas

Los usuarios esperan que un sistema de identidad tenga una variedad de características avanzadas, entre las que se incluyen:

  • Autenticación sin contraseña, que usa enfoques seguros para iniciar sesión que no requieren que los usuarios escriban credenciales.

  • Inicio de sesión único (SSO), que permite a los usuarios iniciar sesión con una identidad de su empleador, escuela u otra organización.

  • Autenticación multifactor (MFA), que solicita a los usuarios que se autentiquen de varias maneras. Por ejemplo, un usuario podría iniciar sesión con una contraseña y también mediante una aplicación autenticadora en un dispositivo móvil o un código enviado por correo electrónico.

  • Auditoría, que realiza un seguimiento de todos los eventos que se producen en la plataforma de identidad, incluidos los intentos de inicio de sesión correctos, erróneos y anulados. Analizar de forma forense un intento de inicio de sesión más adelante podría requerir un registro detallado.

  • Acceso condicional, que crea un perfil de riesgo en torno a un intento de inicio de sesión basado en varios factores. Los factores pueden incluir la identidad del usuario, la ubicación del intento de inicio de sesión, la actividad de inicio de sesión anterior y la confidencialidad de los datos o la aplicación.

  • El control de acceso Just-In-Time, que permite temporalmente a los usuarios iniciar sesión en función de un proceso de aprobación y, a continuación, quita automáticamente la autorización.

Si va a crear un componente de identidad como parte de la solución empresarial, es poco probable que pueda justificar el trabajo que implica la implementación de estas características y su mantenimiento. Algunas de estas características también requieren trabajo adicional, como la integración con proveedores de mensajería para enviar códigos de MFA, y almacenar y conservar los registros de auditoría durante un período de tiempo suficiente.

Las plataformas IDaaS también pueden proporcionar un conjunto mejorado de características de seguridad basadas en el volumen de solicitudes de inicio de sesión que reciben. Por ejemplo, las siguientes características funcionan mejor cuando hay un gran número de clientes que usan una única plataforma de identidad:

  • Detección de eventos de inicio de sesión de riesgo, como los intentos de inicio de sesión desde redes de robots (botnets)
  • Detección de viaje imposible entre las actividades de un usuario
  • Detección de credenciales comunes, como contraseñas que son utilizadas frecuentemente por otros usuarios que, por lo tanto, están sujetas a un mayor riesgo de verse comprometidas
  • Uso de técnicas de aprendizaje automático para clasificar los intentos de inicio de sesión como válidos o no válidos
  • Supervisión de la llamada web oscura para las credenciales filtradas y evitar su explotación
  • Supervisión continua del panorama de amenazas y los vectores actuales que usan los atacantes

Si crea o ejecuta su propio sistema de identidad, no podrá aprovechar estas características.

Uso de un sistema de identidad de confianza y de alto rendimiento

Dado que los sistemas de identidad son una parte clave de las aplicaciones en la nube modernas, deben ser fiables. Si el sistema de identidad no está disponible, el resto de la solución podría verse afectada y funcionar de forma degradada o no funcionar en absoluto. Mediante el uso de IDaaS con un contrato de nivel de servicio, puede aumentar la confianza en que el sistema de identidad permanecerá operativo cuando lo necesite. Por ejemplo, Microsoft Entra ID ofrece un SLA de tiempo de actividad para los niveles de servicio Básico y Premium, que abarca tanto los procesos de inicio de sesión como los de emisión de tokens. Para obtener más información, vea SLA para Microsoft Entra ID.

Del mismo modo, un sistema de identidad debe funcionar bien y ser capaz de escalar al nivel de crecimiento que pueda experimentar el sistema. En función de la arquitectura de la aplicación, es posible que todas las solicitudes requieran interacción con el sistema de identidad y que los problemas de rendimiento sean evidentes para los usuarios. Los sistemas IDaaS tienen incentivos para escalar a cargas de usuario de gran tamaño. Están diseñados para absorber grandes volúmenes de tráfico, incluido el tráfico generado por las diferentes formas de ataques.

Prueba de la seguridad y aplicación de controles estrictos

Si ejecuta un sistema de identidad, es su responsabilidad mantenerlo protegido. Algunos ejemplos de los controles que debe considerar la posibilidad de implementar incluyen:

  • Pruebas periódicas de penetración, lo que requiere experiencia especializada.
  • Investigación de empleados y cualquier otra persona con acceso al sistema.
  • Control estricto de todos los cambios en la solución con todos los cambios revisados por expertos.

Estos controles suelen ser costosos y difíciles de implementar.

Uso de controles de seguridad nativos de nube

Al usar Microsoft Entra ID como proveedor de identidades de la solución, puede aprovechar las características de seguridad nativas de la nube, como las identidades administradas para recursos de Azure.

Si decide usar una plataforma de identidad independiente, debe tener en cuenta cómo puede aprovechar la aplicación las ventajas de las identidades administradas y otras características de Microsoft Entra a la vez que se integra con su propia plataforma de identidad.

Centrarse en el valor principal

Es costoso y complejo mantener una plataforma de identidad segura, confiable y con capacidad de respuesta. En la mayoría de los casos, un sistema de identidad no es un componente que agregue valor a la solución o que le diferencie de sus competidores. Es bueno externalizar los requisitos de identidad a un sistema creado por expertos. De este modo, puede centrarse en el diseño y la creación de los componentes de la solución que agregan valor empresarial para los clientes.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

  • John Downs | Senior Customer Engineer, FastTrack for Azure

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes