La mayoría de las empresas tienen una sólida seguridad externa, por ejemplo, bloquean todo acceso a los activos de producción mediante un firewall y requieren una VPN para obtener acceso “interno” a los entornos de producción. Sin embargo, una vez que está conectado a la VPN, los sistemas internos generalmente están muy mal protegidos y hay poca o ninguna autenticación y autorización para las herramientas y servicios internos.
Dos amenazas comunes a la seguridad interna son las computadoras portátiles de los empleados comprometidas y ataques a la cadena de suministro. En estos escenarios, el atacante opera detrás del firewall, a menudo con acceso a la pink sin restricciones.
Los servicios con una interfaz de usuario internet se pueden proteger utilizando un equilibrador de carga de aplicaciones, por ejemplo, un ALB de AWS con OIDC, pero ¿cómo se protege el acceso a las herramientas basadas en la interfaz de línea de comandos (CLI)? Requerir un nombre de usuario y contraseña para cada invocación de CLI hace que sea doloroso de usar y almacenar las credenciales en el sistema las deja completamente abiertas en caso de que la computadora en la que residen se vea comprometida.
La línea de comando
La mayoría de las herramientas internas tienen una CLI para administrar los servicios que se usan dentro de la empresa y muchas están mal protegidas. ¿Cuál es la mejor manera de autorizar las CLI? ¿Y cómo puede vincular la autorización con el SSO de la empresa?
Una opción es implementar Hashicorp Vault, pero eso requiere mucha configuración y mantenimiento, por lo que, a menos que tenga un equipo para operarlo, Vault podría no ser una buena opción.
Otra opción es la concesión de autorización de dispositivo OAuth2 (RFC8628), que es lo que esta publicación de weblog le mostrará cómo usar.
La concesión de autorización de dispositivos OAuth 2.0 está diseñada para dispositivos conectados a Web que carecen de un navegador para realizar una autorización basada en agente de usuario o tienen restricciones de entrada en la medida en que es necesario que el usuario ingrese texto para autenticarse durante el flujo de autorización. poco práctico. Permite a los clientes de OAuth en dichos dispositivos (como televisores inteligentes, consolas de medios, marcos de fotos digitales e impresoras) obtener la autorización del usuario para acceder a los recursos protegidos mediante el uso de un agente de usuario en un dispositivo separado.
Si alguna vez usó AWS CLI con Single SignOn, esto es lo que hace.
Flujo de dispositivo OAuth2
El flujo de autorización de dispositivos contiene dos rutas diferentes; uno ocurre en el dispositivo que solicita la autorización (la CLI) y el otro ocurre en un navegador. La ruta de flujo del navegador, en la que un código de dispositivo está vinculado a la sesión en el navegador, se presenta como una parte de ruta paralela en la ruta de flujo del dispositivo.
Implementación del flujo de dispositivo OAuth
Ahora veremos cómo se ve el diagrama de secuencia anterior cuando se implementa.
La herramienta CLI interna en Rockset se llama rsctl y se escribe en go. El primer paso es iniciar el flujo del dispositivo para obtener un token de acceso JWT.
$ rsctl login
Trying to routinely open the SSO authorization web page in your default browser.
If the browser doesn't open otherwise you want to use a unique gadget to authorize this request, open the next URL:
https://rockset.auth0.com/activate?user_code=BBLF-JCWB
Then enter the code:
BBLF-JCWB
Efficiently logged in!
Si está utilizando la CLI después de iniciar sesión en otra computadora, por ejemplo, ssh: ing a un servidor Linux, y usa macOS, puede configurar iTérmino para abrir automáticamente el enlace usando un “comando Ejecutar” desencadenar.
La página a la que te lleva el enlace se ve así:
Una vez que haya confirmado que el “código de usuario” es correcto (coincide con lo que muestra la CLI), y haga clic en “Confirmar”, lo llevará a través del procedimiento regular de inicio de sesión de OAuth2 (que en nuestro caso requiere un nombre de usuario, contraseña y {hardware}). simbólico).
Una vez que se full la autenticación, será redirigido y se le presentará un cuadro de diálogo como el que se muestra a continuación, y podrá cerrar la ventana del navegador.
El CLI ahora ha recibido una token de acceso jwt que es válido por un número de horas y se utiliza para autenticar a través de servicios internos. El token puede almacenarse en caché en el disco y reutilizarse entre las invocaciones de la CLI durante su vida útil.
Cuando emites un nuevo rsctl comando, leerá el token de acceso en caché del disco y lo usará para autenticarse con las API internas.
Bajo el capó
Hemos implementado y abierto un módulo go para realizar el flujo de autorización del dispositivo (github.com/rockset/device-autorización). Admite tanto Auth0 como Okta como proveedores de OAuth.
Código de muestra
El siguiente código está disponible en el directorio de ejemplo en el repositorio de git.
Contenido incrustado: https://gist.github.com/pmenglund/5ed2708cdb88b6a6982258aed59a0899
Ahora tenemos un token JWT, que se puede usar para autenticar llamadas REST configurando el encabezado de Autorización en Bearer: <jwt entry token>
Contenido incrustado: https://gist.github.com/pmenglund/b2ac7bb15ce25755a69573f5a063cb14
Ahora depende del extremo receptor validar el token del portador, lo que se puede hacer usando un AWS ALB con autenticación OIDC o un API específica del proveedor del servidor API.
Validación fuera de línea
Otra opción para la validación del token de acceso es la “validación sin conexión”. En la validación fuera de línea, el servidor API obtiene la clave pública utilizada para firmar el token JWT del proveedor (y almacena en caché la clave pública) y realiza la validación en el servidor API, en lugar de realizar una solicitud de validación al proveedor.
Riesgo residual
Una cosa contra la que esto no protege es un atacante con un punto de apoyo en la computadora que ejecuta la CLI. Simplemente pueden esperar hasta que el usuario haya completado la autenticación y luego podrán actuar como el usuario durante la duración del token de acceso.
Para mitigar este riesgo, puede solicitar una contraseña de un solo uso (OTP), por ejemplo, una Yubikey, cada vez que el usuario realiza una acción privilegiada.
$ rsctl delete useful resource foobar
please enter yubikey OTP: ccccccvfbbcddjtuehgnfrbtublkuufbgeebklrubkhf
useful resource foobar deleted
Pensamientos finales
En este weblog, mostramos cómo construimos y abrimos un módulo go para proteger la interfaz de línea de comandos (CLI) usando un flujo de autorización de dispositivo OAuth2 que es appropriate con los proveedores Auth0 y Okta SSO. Puede agregar este módulo go a sus herramientas internas y reducir las amenazas de seguridad internas.
