Autenticación sin contraseña para servidores: práctica con ASA

Tenemos aproximadamente dos horas y una audiencia dividida. Algunas personas están aquí en la sala de Zoom y otras están viendo esta grabación en el futuro. Grabaremos la primera mitad con todas estas explicaciones para que las personas del futuro puedan unirse a nosotros. Pero para la segunda mitad práctica, al final, detendré la grabación para que podamos simplemente charlar. Y puedes hacer las preguntas que tal vez no quieras que queden registradas para la posteridad. No tienes que mirar la pantalla mientras escuchas esto. Pero te ayudará ver las capturas de pantalla una vez que llegue al resumen de la configuración.

Ahora, muchos avances en DevOps y gestionar servidores. se centran en alejarnos de ejecutar Eso a menudo es genial. Puedes delegar tareas individuales a personas o entidades especializadas en ellas. Tu base de datos bases de datos, tu herramienta de red es gestionada por expertos en redes. es administrada por expertos en Y eso es genial cuando es algo que puedes hacer. Cuando tienes los recursos para delegar el trabajo específico del dominio a especialistas en esos dominios, generalmente lo harán mejor que tu equipo. Al igual que cuando estás programando, si puedes usar una biblioteca bien probada de primitivas criptográficas en lugar de intentar crear la tuya propia, casi siempre terminarás con un código más seguro como resultado.

Pero muchos de nosotros todavía tenemos que ejecutar servidores. Tal vez sea porque estamos trabajando en la migración de una arquitectura antigua que era de última generación cuando se diseñó por primera vez. O tal vez estamos lidiando con cargas de trabajo que realmente requieren que gestionemos directamente nuestros recursos informáticos. De cualquier manera, cuando gestionamos nuestros propios recursos en la nube o hardware, aún podemos separar tareas individuales que sería mejor hacer con software o servicios diseñados específicamente. Hoy me gustaría presentarles un truco para separar una de las partes difíciles de gestionar quién puede acceder a qué y cuándo, y mostrarles cómo replicar ese truco.

Ahora, como persona que escucha charlas y también usa herramientas, comenzaré con el descargo de responsabilidad que siempre estoy atenta. La herramienta que hace este truco genial, ASA de Okta, no será perfecta para todos los casos de acceso. El mayor obstáculo que podrías encontrar es que el precio es por servidor y se prueba principalmente con la suposición de que estás utilizando Okta como proveedor de identidad. La parte del proveedor de identidad es relativamente negociable, pero lamentablemente el precio no lo es. Sin embargo, incluso si nunca terminas trabajando directamente con ASA, espero que comprender su contexto te ayude a pensar críticamente sobre las fortalezas y debilidades de tus herramientas existentes como SSH convencional. Conocer más sobre tus herramientas y sus alternativas puede ayudarte a tomar las mejores decisiones de seguridad para cada desafío operativo al que te enfrentes.

Dado que estamos hablando de security, me gustaría asegurarme de que todos entendamos qué significa exactamente la autenticación. Esto puede ser algo conocido para algunos de ustedes, pero todos lo escuchan por primera vez en algún momento y las personas ingresan a DevOps desde diferentes ámbitos. El truco de la autenticación es que se expande en dos formas diferentes. Primero, puede referirse a la autenticación. La autenticación responde a la pregunta: ¿es esta la misma persona que antes? Por ejemplo, una licencia de conducir o un pasaporte se utilizan a menudo para la autenticación y poder ingresar a lugares como bares o aviones. El documento con mi foto muestra que probablemente soy la misma persona a la que el gobierno emitió esa identificación. Mi nombre de usuario, contraseña y acceso a mi teléfono son una forma de autenticación para muchas cuentas en línea. Si los tengo, probablemente soy la misma persona que creó la cuenta. El microchip de mi gato también es una forma de autenticación. Si se escapara y alguien escaneara su chip para averiguar cómo llevarla de vuelta a casa, les diría que es el mismo gato que se registró en esa base de datos cuando la llevé por primera vez al veterinario. El descargo de responsabilidad aquí es que ninguna forma de autenticación es perfecta. En cualquier lugar donde el software interactúa con el resto del mundo, hay margen para que ocurran cosas inesperadas. Si alguien conociera todos mis secretos y tuviera acceso a todos mis dispositivos y pudiera usar mis biometrías, podría hacerse pasar por mí. Si alguien pudiera hacer que su rostro se parezca convincentemente al mío, podría pretender ser yo usando mi identificación con foto. Parafraseando a un gran autor, a medida que avanza la tecnología, la tecnología para engañar a esa tecnología crece junto con ella. Esto mantiene las cosas interesantes. Pero lo que podemos hacer es dificultar enormemente que alguien más se haga pasar por nosotros. Cada vez que agregamos otro factor de autenticación, hacemos que sea más difícil para un atacante pretender con éxito ser nosotros. Para acceder a mis cuentas de trabajo, necesitarías conocer mi contraseña, tener mi teléfono y tener mis biometrías juntas. Es relativamente fácil que una contraseña se vea comprometida, especialmente si alguien la reutiliza. Es relativamente fácil que un teléfono sea robado o que se secuestre una tarjeta SIM. Pero cuanto más factores se sumen, más cosas tendrían que salir bien para que un atacante pueda derrotar tus mecanismos de autenticación. Entonces, eso es la autenticación. Responde a la pregunta: ¿eres la misma persona que el tonto? Ahora, la autenticación es necesaria pero no suficiente para la autorización. Al igual que ser la misma persona en mi identificación no es suficiente para garantizar que pueda ingresar a un bar, también necesito estar autorizado por ser mayor de edad. Tener un pasaporte no es suficiente para permitirte subir a un avión, también necesitas estar autorizado para ese vuelo al tener un boleto. La autorización puede cambiar de un día para otro o incluso de un minuto a otro. Si tenía un boleto para este vuelo ayer, eso no significa que pueda subir al mismo vuelo mañana sin un nuevo boleto. Si estoy conectado a mi cuenta de Google y alguien comparte un documento conmigo, no estaba autorizado para verlo hace un momento y ahora sí lo estoy. Entonces, la autorización responde a la pregunta: ¿se le permite a esta persona autenticada hacer lo que está intentando? ¿Qué tiene que ver esto con el acceso a los servidores? Bueno, si alguna vez has gestionado el acceso a los recursos como persona de Operaciones, has razonado sobre la autenticación de los usuarios y la autorización.

Hay un mecanismo familiar de autenticación y autorización. Si creas una clave con una frase de contraseña, entonces quien conozca la frase de contraseña probablemente sea la misma persona que creó la clave o al menos alguien a quien le hayan delegado eso. Pero solo tener la clave no te da acceso al host. Alguien tiene que colocar la clave en el host. Cuando colocan tu clave pública en el host, autorizan a cualquier persona con tu clave a iniciar sesión en él siempre que esa clave pública permanezca allí. Entonces, en el cliente, tienes tu clave privada. En el servidor, tienes tu clave pública. Y cuando intentas iniciar sesión, hacen algunos cálculos juntos para asegurarse de que las dos mitades probablemente provengan de la misma clave. Bueno, hacen cálculos que demostrarían que sería prohibitivamente difícil falsificar la clave por ahora. Algún día en el futuro, las claves que estamos usando actualmente se volverán cada vez más fáciles de romper a medida que avance la tecnología. O a veces tendrás un grupo de personas que comparten una clave y todas inician sesión en la misma cuenta en un servidor. El servidor cree que solo hay un cliente, lo cual a veces está bien. Pero a menudo conduce a consecuencias no deseadas. Gestionar todo esto a gran escala tiende a convertirse en una verdadera aventura. Aunque hay algunas soluciones diferentes para diferentes partes del problema. Con claves compartidas, la incorporación es trivial. Simplemente les das una copia de la clave. Pero hacer la desvinculación correctamente es muy costoso. ¿Qué sucede cuando alguien se retira a una isla tropical y necesitas sacarlo del sistema? ¿Vas a rotar la clave para todos los que la tienen? ¿O simplemente te rendirás y los expulsarás de la red, eliminando su acceso en otro nivel para que incluso si pudieran pasar, aún tendrían la clave y podrían iniciar sesión? A veces esto se resuelve simplemente tratando de no pensar en cuántas copias de esa clave privada están vagando por ahí en los archivos de antiguos colegas. Con una clave por usuario, la desvinculación es solo cuestión de eliminar la única clave de cada host al que la agregaste. Pero parte de la carga se traslada a la incorporación. Debes configurar y mantener la automatización para enviar las nuevas claves a todos los hosts a los que les estás otorgando acceso y ninguno de los que no lo estás haciendo. Esto debe ejecutarse correctamente y de manera oportuna cada vez que agregues un usuario y cada vez que un usuario necesite cambiar su clave por cualquier motivo, y hacer que alguien del equipo de operaciones siga una lista de verificación o su memoria para realizar el trabajo de un trabajo de CI manualmente sigue siendo una forma de automatización. Los scripts son scripts, incluso si ejecutas cada paso manualmente, hacerlo manualmente es más lento y más propenso a errores y crea sufrimiento humano adicional.

A lo largo de los años, las personas han ideado soluciones mejores y peores para gestionar los dolores de cabeza de seguridad que rodean la autenticación y autorización. Por ejemplo, a menudo es apropiado dirigir el tráfico a los hosts internos a través de un bastión, que está mejor protegido de lo que sería práctico hacer con todos los servidores en tu implementación. Y en ese bastión, puedes implementar exactamente la supervisión y el registro que necesitas. La mayoría de las implementaciones permiten aplicar reglas de red para evitar el acceso entre hosts, donde ninguna persona autorizada querría conectarse, pero un atacante sí. Por ejemplo, las personas autorizadas probablemente nunca se conectarán directamente desde el servidor de la aplicación A al servidor de la aplicación B. Como, ¿por qué harías eso? Pero porque siempre estarán yendo por una ruta diferente, como a través del bastión. Pero un atacante que haya comprometido el servidor de la aplicación A, realmente querrá ir directamente al servidor de la aplicación B. Así que simplemente puedes prohibir ese acceso. Estas capas adicionales de security generalmente son excelentes de tener, pero no necesariamente obvian todo el problema subyacente. Por ejemplo, si mis permisos necesitan cambiar en un host en el que tengo mi clave, alguien tiene que iniciar sesión y cambiarlos. Si dejo de formar parte de un equipo autorizado para acceder al host, alguien o algún script tiene que eliminar mi clave pública de él. Esta es la antigua y familiar forma de gestionar el acceso, y funciona bastante bien para muchos casos de uso. Tiene una cierta simplicidad, ubicuidad y familiaridad a su favor. Pero la gran desventaja es que hace que tus claves SSH y frases de contraseña sean extremadamente valiosas, peligrosas de perder e incómodas de reemplazar. Son literalmente las llaves de tu castillo. Y nadie quiere tener que volver a cambiar cada cerradura, ya sea física o digital. Sin embargo, cuando me incorporé a Okta, me presentaron un paradigma totalmente diferente pero sorprendentemente compatible hacia atrás para gestionar el acceso al servidor. En lugar de tener una única clave valiosa y de larga duración, resulta que puedes crear claves de uso único para el acceso SSH y RDP a los servidores, las cuales tú, como usuario, nunca tienes que tocar ni pensar en ellas. En lugar de preguntar a cada host de la red quién tiene permiso para acceder, puedes utilizar la misma fuente de verdad sobre la identidad que ya están utilizando todas tus otras aplicaciones, como el chat y el correo electrónico. Así que, en lugar de pedir a los equipos de operaciones que manejen otro conjunto de secretos cruciales, puedes aprovechar la authentication que ya están utilizando en su navegador para acceder a todas sus otras herramientas vitales. Los protocolos SSH y RDP todavía se utilizan porque son realmente buenos. Son ubicuos y están bien probados y soportados. Solo estamos cambiando los detalles de cómo gestionamos las claves involucradas para reducir el valor de esas claves para los atacantes. Así que te mostraré cómo se ve. Es súper aburrido porque divertido e interesante no son palabras que quiero escuchar cuando hablamos de un flujo de trabajo que nos permite acceder donde lo necesitamos para resolver incidentes y cortes más rápido. Entonces, esto resulta ser una laptop bastante nueva. En realidad no tengo nada en mi directorio SSH. No necesito ninguna clave aquí. Tengo un archivo de configuración. He configurado un proxy en la configuración para poder usar mi binario SSH local.

Ahora, la parte súper conveniente de todo este proceso es que, como usuario, tengo menos cosas en qué pensar que si estuviera administrando mis propias claves. Al reutilizar un proveedor de identidad donde la organización ya centralizaba el acceso a otras aplicaciones como chat y correo electrónico, acceder a los servidores se vuelve como iniciar sesión en cualquier otra cosa. Por lo tanto, la parte práctica de este laboratorio se sentirá un poco artificial porque estamos empezando desde cero. No asumimos que tienes los permisos adecuados para jugar así en una cuenta existente de Okta. Al igual que escribir una aplicación de demostración con un marco web completo requerirá más código y dependencias que una aplicación de demostración similar con un marco que no escala tan bien, esta configuración es excesiva para las tareas que realizaremos en la demostración. Explicaré rápidamente cómo funciona la configuración ahora porque las personas que vean la grabación más tarde podrán pausarla si desean seguirla paso a paso. Amigos en la sala, no recomiendo intentar seguir cada paso en este momento. Después de detener la grabación, explicaré tres niveles de dificultad para poner en práctica ASA y te guiaré en cada uno mientras respondo preguntas y ayudo a debug cualquier problema que puedas encontrar. Para las opciones sencillas, te permitiré usar mi organización de demostración y el servidor de juguete que te mostré hace un minuto. Pero los desactivaré después de la conferencia, por lo que no serán útiles para las personas en el futuro. Para jugar con ASA a través de Okta, primero necesitaremos una cuenta de Okta para hacerlo. Simplemente crearemos una cuenta de prueba gratuita. Para evitar sorpresas, ten en cuenta que el soporte está muy entusiasmado por ponerse en contacto y ayudar a resolver cualquier problema que puedas tener. Si eso afecta tu elección de cómo proporcionas tu dirección de correo electrónico o incluso si decides registrarte, simplemente infórmate. Ve a okta.com. Crea una cuenta, recibe tu correo electrónico de activación y luego inicia sesión y cambia tu contraseña. Configura un segundo factor cuando te lo solicite, porque lo necesitarás cuando inicies sesión en esa cuenta como administrador, cuando accedas al panel de administración. Entonces, en esa cuenta de Okta, vamos a ingresar al panel de administración para convertirnos en administradores. Aquí te obligará a tener un segundo factor porque no podemos tener administradores que solo usen una contraseña. Y podemos ver que somos administradores porque se puede ver `admin` en la URL y la consola se ve diferente. Luego iremos a aplicaciones en la barra lateral y aplicaciones debajo de eso y navegaremos por el catálogo de aplicaciones. Haremos una búsqueda rápida de advanced server access y agregaremos esa aplicación a nuestra cuenta de prueba. No es necesario cambiar ninguna configuración aquí, simplemente hace lo correcto de inmediato. Y luego Okta necesita saber quién tiene permiso para usar ASA antes de permitir que alguien lo use.

Este es el paso de autorización. Para hacer la demostración mínima viable, asignaré mi usuario y elegiré el nombre de usuario que ASA me dará. Aunque, si estuviera en una instancia de Okta con grupos establecidos, agregaría personas por grupos. Agregaría el grupo que representa al equipo de Okta. Siempre puedes volver más tarde y cambiarlo para dar permisos a través de grupos en lugar de usuarios individuales. Así que mantén abierta la pestaña de ASA en la pestaña de inicio de sesión. Tendrás la configuración, vas a prepararte para editar esa configuración. Y también abrirás app.scaleft.com y comenzarás a crear un nuevo equipo. Ahora, aquí está la única parte realmente complicada de todo el proceso. Necesitamos que las dos aplicaciones básicamente se den la mano. Okta necesita saber algunas cosas sobre ScaleFT, y ScaleFT necesita saber algunas cosas sobre la aplicación ASA en Okta. Por lo tanto, este intercambio de información es básicamente la única parte difícil. Entonces, en tu pestaña de Okta, verás algo que se ve así. Editando tu configuración. En tu pestaña de ScaleFT ASA, verás algo como lo que está a la derecha, donde ingresas algunas configuraciones, copias algunas configuraciones. Aquí elegirás un nombre de equipo. Recomiendo encarecidamente elegir, por ejemplo, tu nombre DevOps JS, tu nombre testing. Algo así. Porque los nombres de equipo son únicos a nivel mundial. Como la nomenclatura de los buckets de S3. Para transferir información entre las dos aplicaciones, esa URL llamada metadatos del proveedor de identidad, esa URL se coloca en el cuadro de URL de metadatos del proveedor de identidad. Y luego la URL base y las restricciones de audiencia se transfieren en sentido contrario. Primero, guardas en Okta. Y luego, una vez que hayas hecho todo hasta este punto, presionas el botón de autenticación en ScaleFT. Si encuentras un error al intentar autenticarte, es posible que hayas olvidado agregar tu usuario y darle permisos. Es posible que no hayas ingresado la URL base y la restricción de audiencia en Okta o tal vez tengas un valor incorrecto o no válido en la URL de metadatos del proveedor de identidad. Es una de esas cosas en las que seguir los pasos con precisión importa mucho. Esa fue la parte más difícil. Felicidades. Eso ocurre exactamente una vez por organización.

Tus entornos como desarrollo, producción y puesta en escena se representarán como proyectos separados dentro del mismo equipo. Así que nunca tendrás que hacer esa configuración nuevamente a medida que crezcas.

Ahora, si queremos que los cambios en la membresía del grupo de Okta y los permisos de usuario y demás se envíen automáticamente a ASA, tenemos un enlace más que hacer. Si solo estás jugando con esto por tu cuenta, puedes omitir esta parte, pero es realmente útil si quieres jugar con la sincronización de equipos de ida y vuelta. En la pestaña de aprovisionamiento de Okta, configuraremos la integración de la API haciendo clic en ese botón. Se abrirá ASA aquí. Aprobaremos la concesión de permisos y daremos al usuario de servicio un nombre de usuario de servicio que reconoceremos. Lo aprobaremos y luego lo guardaremos en Okta. Ese es el sistema para la gestión de identidad entre dominios, y luego podrás sincronizar cosas de ida y vuelta.

Entonces, los últimos pasos de configuración para prepararnos para inscribir servidores son que necesitaremos crear un proyecto en el lado de ASA. Es posible que desees usar proyectos para dividir como Desarrollo, Puesta en Escena y Producción. Más adelante, ofreceré crear proyectos individuales para aquellos que deseen inscribir un servidor de juguete no compartido, y acabo de crear el proyecto DevOpsJS para jugar hoy. Así que hay muchas opciones en el cuadro de diálogo Crear Proyecto. Son útiles en implementaciones reales. No te preocupes por las opciones. Lo único que te importa para jugar con esto, para comenzar, es tener el nombre. Finalmente, necesitamos autorizar a las personas para que realicen acciones. Con fines de demostración, agregaré el grupo Todos al proyecto. Más adelante, puedes crear más grupos y sincronizarlos para gestionar permisos más detallados, y más adelante, a medida que juegues con esto, puedes jugar con lo que llamamos pseudo permisos que permitirán que ciertos usuarios o grupos solo usen sudo para comandos específicos. Hemos resuelto el proveedor de identidad y esa fue la parte difícil. También es la parte que solo se hace una vez, independientemente del tamaño de la implementación. Ahora, obtengamos un servidor. Si estuviéramos haciendo esto para un montón de servidores, podríamos hacer la configuración una vez en la imagen que planeamos implementar, y luego simplemente clonarla varias veces. Y esos clones se registrarán en ASA, y será como, oh, fuiste implementado desde esa imagen. Genial. Y crear el host en sí mismo. O si tuviéramos una cuenta de AWS o GCP, podríamos configurarla para inscribir automáticamente todos los servidores nuevos en ASA incluso sin el token. Sin embargo, la demostración mínima viable es jugar con la inscripción de tokens porque es lo más simple para una sola vez. Entonces, aquí mismo, en mi proyecto de ASA, en la inscripción, crearé un token de inscripción.