Elimine la necesidad de un Remote Desktop Gateway o de un jump box para acceder a su entorno utilizando autenticación con multifactor (MFA) integrado con Active Directory

Por: Caio Ribeiro César, Rogerio Kasa, Javier Gálvez

El propósito de un servicio que utiliza Remote Desktop Gateway, » jump boxes » o » bastion host » hosteados en una subred pública (red DMZ) es para restringir el acceso remoto a servidores y/o servicios que están en redes privadas. Pero cabe destacar que al proporcionar una puerta de acceso a una red privada desde una red externa, estos servicios de acceso remoto están expuestos a posibles ataques.

Con la creciente necesidad de mejorar la seguridad de los entornos en la nube (así como en las instalaciones on-premises), algunas empresas optan por implementar soluciones que utilizan una autenticación multifactor (MFA). En este método de autenticación, a un usuario se le otorga acceso solo después de presentar exitosamente dos o más evidencias (o factores) de autenticación, por ejemplo: lo que él sabe (contraseña / frase de contraseña ), lo que el tiene (algo que el usuario, y solo el usuario tiene, por ejemplo un hardware token ) y lo que es , o una característica única de ese usuario como por ejemplo una huella digital o su retina.

Con este tipo de soluciones, los administradores necesitan fortalecer la configuración básica de los servidores que proporcionan el servicio y, por ende, están sujetos a las tareas administrativas de mantenimiento continuo. Esto nos lleva a otra discusión: mayor posibilidad de error humano, gestión de parches de seguridad; además de requerir una configuración compleja para proveer una solución de MFA ( RADIUS ) además de tener un posible alto costo de implementación ( licencias de Windows y hosts *).

En este blog, vamos a discutir sobre la implementación de la autenticación multifactor (MFA) utilizando alguno de nuestros servicios gestionados (AWS SSO y AWS Systems Manager ) y, en consecuencia, mostraremos como podemos eliminar la necesidad de implementar un Remote Desktop Gateway, » jump boxes » o » bastion host »

Con AWS SSO, facilitamos la administración centralizada del acceso a múltiples cuentas de AWS, servicios de productividad y aplicaciones de terceros (por ejemplo, Salesforce, Box, Office365). Con esta solución, podemos administrar usuarios y guardar sus identidades AWS SSO o conectarnos fácilmente a otras opciones de identidad existentes, incluido Microsoft Active Directory, el directorio universal de Okta y Azure Active Directory (AAD). En esta solución, nos enfocaremos en la opción Microsoft Active Directory (AD).

Comenzaremos con los modelos de autenticación para esta solución. Desde la consola de AWS SSO, podemos elegir entre varios proveedores de identidad. En este escenario, usaremos una de las opciones de proveedor de identidad de «Active Directory», donde tenemos un AWS Managed Microsoft AD o AD Connector :

Para AWS Managed Microsoft AD , tenemos las opciones de arquitectura (a) o (b), como se detalla en los siguientes diagramas:

Opción (a): la solicitud de autenticación se realiza en el único AD forest administrado por AWS ( forest usuario «octank.aws»).

Proceso de autenticación (a) – Managed AD

Figura 1 – Proceso de autenticación de AWS Managed AD, el único forest «octank.aws».

Opción (b): el forest de AD administrado por AWS ( forest de recursos «octank.aws») recibe la solicitud de autenticación , sin embargo, la realiza el forest de usuario «octank.local» mediante la forest trust o (confianza del forest).

Proceso de autenticación (b) – Managed AD & AD (Modelo Resource Forest)

Figura 2: proceso de autenticación de AWS Managed AD, forest «octank.aws» con una relación de confianza con el forest «octank.local».

Dentro del servicio de AD Connector , tenemos las opciones de arquitectura (c) o (d), como se detalla en los siguientes diagramas:

Opción (c): la solicitud de autenticación es recibida por AD Connector y enviada al entorno local (octank.local), donde posteriormente será realizada por los Controladores de Dominio en este forest.

Proceso de autenticación (c) – AD Connector y DC en el On-premises

Figura 3 – Conector AD actuando como «Proxy» para el forest «octank.local».

Opción (d): El AD Connector recibe la solicitud de autenticación y la envía al entorno local (octank.local), y luego la realizan los AWS Extended Domain Controllers (instancias EC2) de este forest.

Proceso de autenticación (d) – AD Connector & DC On-premises

Figura 4 – Conector AD actuando como «Proxy» para el forest «octank.local», pero configurado para usar controladores de dominio en EC2 (extensión del forest).

Para iniciar una sesión en instancias EC2, utilizaremos Session Manager del servicio AWS Systems Manager (AWS SSM).

AWS SSM proporciona visibilidad y control de su infraestructura en AWS. Systems Manager ofrece una interfaz de usuario unificada para que pueda visualizar datos operativos de varios servicios de AWS y automatizar todas tareas operativas de sus recursos de AWS. Session Manager es un servicio dentro AWS System Manager completamente gestionado para administrar instancias de EC2, servidores locales y máquinas virtuales (VM) a través de un Shell interactivo basado en el navegador web, o por medio del AWS CLI ( cliente de línea de comando). Session Manager proporciona una gestión de instancias segura y auditable sin la necesidad de abrir puertos de entrada o mantener un jump server o administrar claves SSH. Session Manager también facilita el cumplimiento de las políticas de seguridad corporativas que requieren acceso controlado a las instancias a través de políticas de IAM, prácticas de seguridad estrictas y registros completamente auditables con detalles de acceso a las instancias, donde estos registros se almacenan en CloudWatch o en un bucket de S3,y a su vez se proporciona a los usuarios finales el acceso a sus instancias administradas con un solo clic.

Ahora que comprendemos los conceptos de los modelos de autenticación y también de AWS Systems Manager, podemos diseñar una solución integrada.

Los requerimientos de seguridad son los siguientes:

• El servidor EC2 que vamos a conectar vía RDP y SSH no tendrá los puertos “abiertos”. Es decir, el security group o grupo de seguridad no recibirá la regla de ingreso / Permitir para los puertos 3389 y 22 a través de las reglas de entrada.
• El servidor EC2 que conectaremos vía RDP y SSH será gestionado por SSM. Para ello, debemos agregar un rol de IAM correcto para estas instancias.
• En consecuencia, el SSM Agent se instalará y ejecutará en cada instancia que administraremos con el SSM Session Manager (vía Internet o por los endpoints de SSM VPC).
• Los usuarios que tendrán acceso a las instancias deben tener dispositivos para el MFA registrados en AWS SSO .
• Debemos crear una aplicación de MFA en la política de acceso de SSM Session Manager. Esto garantizará que solo los usuarios que se hayan autenticado con MFA podrán acceder vía los puertos de RDP y SSH.
• Incluso después de la autenticación de MFA, el usuario que realice la conexión debe tener una credencial de acceso EC2 (a través de un archivo .pem o incluso de un usuario de Active Directory).
• El usuario que iniciará sesión debe tener instalado AWS CLI v2 .

Para visualizarlo, estos son los pasos a realizar:

1. El usuario que realizará el acceso ejecuta el comando “aws configure sso”.
2. Se le pedirá que agregue la URL de AWS SSO. Al realizarlo, será redirigido al su navegador para la autenticación.
3. El usuario proporciona una credencial de Active Directory, que lo autenticará.
4. Cuando se autentique con éxito en el Active Directory seleccionado como proveedor de identidad de AWS SSO, deberá agregar una clave de acceso donde   esta vez será una clave generada por del dispositivo registrado con MFA.
5. Cuando se autentique correctamente (autenticación multifactor ), el usuario será redirigido a la AWS CLI.
6. En la AWS CLI, el usuario ejecutará el comando » aws ssm start-session » para iniciar la sesión en la instancia seleccionada.
7. El usuario también puede realizar la Conexión de Escritorio Remoto al puerto local, luego agregar la credencial de acceso al servidor y conectarse sin necesidad de abrir los puertos del Grupo de Seguridad.

La solución final tendría la integración de AWS SSO con MFA habilitado, sumando el SSM Session Manager para acceder a instancias EC2, con esto fácilmente se removería la necesidad de un Remote Desktop Gateway.

Ahora, como siguiente paso, detallaremos la implementación de la solución siguiendo los pasos descritos anteriormente.

Paso 1 : Selección del proveedor de identidad:

En nuestro escenario, vamos a seleccionar un Active Directory administrado por AWS ( Managed Active Directory ), pero también podríamos seleccionar el servicio Conector AD .

Paso 2: Habilitar MFA en AWS SSO

Habilitamos MFA y registramos el dispositivo del usuario final.

Es importante resaltar que en la política de MFA, configuramos que la autenticación de MFA se solicite cada vez que el usuario quiera autenticarse .

Paso 3: Autenticar la AWS CLI con AWS SSO + MFA:

En PowerShell (o incluso un cmd ), configuramos AWS SSO con la URL del entorno:

Nos autenticamos en la consola y en el dispositivo:

Seleccionamos la cuenta donde las instancias estén ubicadas.

Paso 4: Ejecutar SSM Session Manager e iniciar sesión:

En PowerShell , ejecutamos el comando con el ID de instancia:

aws ssm start-session –target “i-05ce322cf94xx1” –document-name AWS-StartPortForwardingSession –parámetros portNumber = 3389, localPortNumber = 123 –profile admin

Recordemos que podemos realizar tareas administrativas vía PowerShell (Windows) o Shell (Linux) utilizando SSM Session Manager vía consola o AWS CLI v2.

* En un entorno productivo de una empresa con aprox. 300 servidores y una plantilla de 60 empleados de tecnología, utilizando instancias bajo demanda con «parada automática» configuradas para ejecutarse 2 horas después del horario laboral, tenemos 4 Remote Desktop Gateway con SO Windows (m5.large) y 2 jump servers con SO Amazon Linux (m5.large):

** Basado en el costo de la definición del servicio  podemos ver el precio de una instancia EC2 con un modelo de facturación ¨bajo demanda¨ Amazon EC2, 09/2020 región de São Paulo.

También recomendamos crear una política de IAM que se asignará un conjunto de permisos (Permissions Set) para el usuario o grupo de AWS SSO, con definiciones de etiquetas (tags) para las instancias que serán administradas. Para obtener más información, haga clic aquí .

En este blog, analizamos el uso de AWS SSO con una autenticación multifactor integrada con AWS SSM para eliminar la necesidad de un Remote Desktop Gateway y/o un jumo host de su entorno. Además, mostramos la posibilidad de integración con AWS SSO con Active Directory.

Para más información sobre este tema, también ofrecemos un video publicado en el canal on demand (inglés).

Sobre los autores

Caio Ribeiro Cesar trabaja actualmente como arquitecto de soluciones especializadas en tecnología de Microsoft en la nube de AWS. Comenzó su carrera profesional como administrador de sistemas, quien continuó durante más de 14 años en áreas como Seguridad de la Información, Identidad Online y Plataformas de correo electrónico empresarial. Recientemente se convirtió en un fan de la computación en la nube de AWS y ayuda a los clientes a aprovechar el poder de la tecnología de Microsoft en AWS.

Rogerio Kasa es consultor de seguridad, riesgo y cumplimiento (SRC) en el equipo de servicios profesionales de AWS. Con más de 20 años de experiencia en el área de seguridad de la información, incluyendo 11 años en el mercado financiero donde fue responsable de importantes proyectos como el cumplimiento de las regulaciones de los bancos centrales, la banca por Internet y la implementación de procesos de respuesta ante incidentes. Como consultor de AWS ayuda a los clientes a implementar controles de seguridad y crear iniciativas estratégicas que permitan la migración segura a escala y la protección de las cargas de trabajo a la nube.

Revisores

Bruno Lopes es formador técnico del equipo de AWS LATAM. Ha trabajado con soluciones de TI durante más de 12 años, con numerosas experiencias en cargas de trabajo de Microsoft, entornos híbridos y habilitación técnica para clientes en su cartera. Como Entrenador, lleva más de 6 años dedicando sus días a enseñar tecnologías de vanguardia a clientes latinoamericanos.

Javier Gálvez trabaja actualmente como arquitecto de soluciones y ha trabajado en tecnología de la información durante más de 22 años, comenzando como administrador de sistemas especializado en tecnologías de Microsoft para grandes instituciones financieras siendo especialista en plataformas de correo e intranets corporativa para luego mas tarde en su carrera pasar a tecnologías de virtualización y soluciones de código abierto como Kubernetes.
En la actualidad, se centra principalmente en el diseño y la entrega de nuevas soluciones hibridas sobre la nube AWS, así como en el desarrollo de actividades técnicas con demostraciones y sesiones interactivas para nuestros clientes.