Diseño de la gestión de usuarios para la máquina.

Por Aviad Mizrachi, InfoWorld |

Tecnología emergente analizada por tecnólogos

Si un usuario carece de rasgos humanos y no tiene mucha personalidad, puede haber una buena razón para ello. El usuario puede ser una máquina.

Hoy en día, más del 90 % del tráfico de Internet se realiza entre máquinas. En realidad, las máquinas que consumen su aplicación SaaS B2B también son usuarios, simplemente un tipo diferente de usuario. Es por eso que cada aplicación en línea y SaaS actual debe incluir prácticas y políticas de administración de usuarios bien pensadas y diseñadas específicamente para manejar los diferentes desafíos y requisitos de las interacciones de máquina a máquina (M2M).

Basándome en años de experiencia ayudando a las empresas B2B SaaS a manejar las interacciones M2M, he elaborado una guía rápida con las mejores prácticas para una gestión de usuarios de máquina a máquina eficiente, eficaz y segura. Sumerjámonos.

El contexto puede ser crítico en la administración de usuarios humanos, pero es aún más crítico para las máquinas porque los usuarios de las máquinas ofrecen mucha menos información sobre su estado, situación e intención. A menudo, los usuarios de máquinas solo acceden a un único servicio o a una pequeña cantidad de servicios, mientras que los usuarios humanos acceden a muchos más.

Las interacciones de máquina a máquina no contienen pistas útiles como el agente del navegador, la dirección MAC o NIC o los datos de geolocalización. Es más probable que sean una llamada API en un protocolo de uso común con un mínimo de características de identificación. El contexto en torno a las solicitudes de servicio que realiza un usuario de máquina debe determinar cómo se aplican las políticas y cómo se diseña la gestión de usuarios.

Para la gestión de usuarios M2M, cada servicio debe saber cómo puede comunicarse con otros servicios y con qué servicios debe comunicarse. Todos los servicios necesitan saber cómo se comunican con otro servicio y los servicios clave a los que se les debe otorgar permiso para acceder. Esto es en parte lo que pueden ofrecer las puertas de enlace API y las mallas de servicios, pero ninguno tiene un enfoque centrado en el usuario (incluso para usuarios M2M).

Para los usuarios humanos de hoy, MFA es una parte crítica del proceso de validación de seguridad. Para los usuarios de máquinas, MFA no es una opción. Al mismo tiempo, las transacciones M2M tienden a operar en milisegundos, porque las máquinas pueden interactuar a una velocidad mucho mayor que los humanos. Esto crea una nueva área de superficie de ataque que muchos ciberdelincuentes ahora intentan explotar activamente a través de ataques API. Para los equipos de SecDevOps que ejecutan procesos de administración de usuarios contra interacciones M2M, esto significa que se debe prestar una atención mucho más estricta a otros mecanismos de seguridad, como la limitación de direcciones IP, la limitación de la tasa de solicitudes, la rotación de certificados o claves e, idealmente, políticas generadas por humanos o máquinas. que reconocen patrones de uso anómalos.

Si una solicitud proviene de una máquina interna o de un usuario externo, debe desencadenar consideraciones de seguridad muy diferentes. Si una solicitud es interna y proviene de un clúster de Kubernetes de un servicio a otro, la autenticación se aplica internamente y, por lo general, con un toque más ligero. Por ejemplo, las mallas de servicios se utilizan para establecer políticas sobre a qué servicios se puede conectar un servicio interno determinado. En realidad, muchas organizaciones aún no están autenticando las interacciones internas de máquina a máquina, pero los CISO y los equipos de administración de riesgos están presionando para implementar la autenticación básica en todas partes.

Hasta la fecha, muchas operaciones de plataforma y equipos de SecDevOps usan autenticación ingenua para la seguridad interna, es decir, secretos compartidos. Sin embargo, la autenticación ingenua requiere un proceso sólido para reemplazar fácilmente los secretos que han sido violados o expuestos de alguna manera. Sin este proceso de intercambio de secretos, una organización corre el riesgo de tiempo de inactividad mientras se crean y comparten nuevos secretos. A escala, los cambios en los secretos que deben sincronizarse entre pares o tríos de usuarios de máquinas son mucho trabajo. Entonces, incluso para la comunicación M2M interna, existen desafíos tecnológicos.

Para las comunicaciones M2M externas y la gestión de usuarios de máquinas, las cosas se complican mucho más. Compartir secretos es una seguridad insuficiente. Para demostrar esto, considere el siguiente ejemplo. Digamos que tenemos dos servicios: un servicio de usuario y un servicio de correo electrónico. Queremos enviar un correo electrónico a un usuario. No todos los usuarios tienen derecho a recibir correos electrónicos. Por lo tanto, para administrar correctamente al usuario, la aplicación debe tener conocimiento de qué usuario tiene derecho a correo electrónico y qué correo electrónico debe indicarse para los mensajes enviados a ese usuario. Los secretos se rompen rápidamente en este mundo.

Este caso de uso también destaca por qué los tokens web M2M JSON (JWT) son preferibles a los servicios de comunicación M2M genéricos. Luego, el servicio de administración de usuarios debe generar un token para un usuario específico o una organización específica. El token se puede revocar o configurar para que requiera renovaciones en ciertos intervalos.

Una política de ciclo de vida del token y un sistema operativo bien diseñados permiten que los servicios de administración de usuarios y seguridad revoquen el acceso rápidamente o roten las claves sin interrupción operativa. La política se aplica automáticamente a través de listas de revocación o renovación de certificados. Si las renovaciones se realizan en plazos relativamente cortos, entonces es posible ajustar la gestión de usuarios para proporcionar una confianza casi cero para los usuarios de M2M. Los JWT pueden tener múltiples atributos, por lo que son particularmente útiles para codificar contexto.

Una segunda forma en que las organizaciones manejan la autenticación externa es a través del token de acceso, donde un usuario recibe una cadena de un solo valor. Así es como funciona un token de acceso:

Un token de acceso es muy bueno para transacciones simples, pero puede fallar en escenarios más complicados, creando un único punto de falla. Por ejemplo, si por alguna razón el token de acceso no se valida, no hay un recurso fácil ni ningún otro mecanismo para calificar la confianza. Al ejecutarse en una arquitectura de microservicios, esto implica un flujo más complicado que es más difícil de administrar. Un usuario de máquina necesitaría una validación instantánea saliendo a un servidor de validación y pista de servicio separados. Con JWT, todo lo que el servicio necesita saber es si el usuario tiene un JWT válido, que almacena todo el contexto de acceso. No es necesario ejecutar un proceso separado para validar esto.

Una tercera ruta son las credenciales del cliente. Se trata de un conjunto de información de identificación proporcionada por una aplicación, como un ID de cliente y un secreto, que se utilizan para autenticar la aplicación y autorizar el acceso a un servidor de recursos. Las credenciales de los clientes a menudo incorporan JWT y tienen la ventaja de ser más seguras porque requieren dos documentos de identificación. Y aunque las credenciales de los clientes pueden ser menos fáciles de usar, eso es un problema menor cuando el usuario no es un ser humano.

Sin embargo, con las credenciales del cliente, el sistema debe diseñarse con cuidado para permitir la mitigación rápida de fallas y el alivio de cuellos de botella. Esto puede ser particularmente desafiante cuando confía en otros sistemas distribuidos, como Google u OAuth, o un certificado de nube de terceros o una autoridad de token. En este escenario, una organización podría confiar en un JWT que no genera ni controla.

Un término medio entre las credenciales del cliente y los controles de acceso podría ser TLS mutuo (mTLS). mTLS garantiza que las partes en cada extremo de una conexión de red sean quienes dicen ser al verificar que ambos tengan la clave privada correcta. Esto pone en capas mecanismos de validación de confianza adicionales en el punto de negociación. Algunas mallas de servicio, proxies inversos y puertas de enlace API aplican mTLS de forma predeterminada, pero sincronizar mTLS en toda la pila de infraestructura requiere un diseño de sistema real y una reflexión cuidadosa.

A medida que la cantidad de servicios y microservicios continúa aumentando, y se diseñan más aplicaciones sobre las API, el desarrollo de una sólida estrategia y práctica de administración de usuarios para las interacciones M2M se vuelve crítico. Esto significa:

Recuerde, las máquinas también son usuarios. Deberá tratarlos como usuarios para asegurarse de que los servicios que utilizan estén disponibles, sean rápidos, escalables y seguros.

Aviad Mizrachi es CTO y cofundador de Frontegg.

—

New Tech Forum ofrece un lugar para explorar y discutir la tecnología empresarial emergente en una profundidad y amplitud sin precedentes. La selección es subjetiva, basada en nuestra elección de las tecnologías que creemos que son importantes y de mayor interés para los lectores de InfoWorld. InfoWorld no acepta garantías de marketing para la publicación y se reserva el derecho de editar todo el contenido aportado. Envíe todas las consultas a [email protected].

A continuación, lea esto:

Blog