Elimine a necessidade de Remote Desktop Gateway & Bastion Host do seu ambiente com a integração de autenticação multifator e Active Directory

Por: Caio Ribeiro César, Arquiteto de Soluções Especialista em Microsoft,
Rogerio Kasa, Consultor de Segurança, Risco e Compliance e
Renato Schmidt, Arquiteto de Soluções Enterprise Greenfield

12 de setembro de 2022: Este blogpost foi atualizado para refletir o novo nome do AWS Single Sign-On (SSO) – AWS IAM Identity Center. Leia mais sobre a mudança de nome aqui.

Remote Desktop Gateways, “jump boxes” ou até “bastion hosts” são servidores criados em uma sub-rede pública (rede DMZ) e configurados com o propósito de isolar os acessos dos serviços e servidores entre diferentes redes.  Com o fornecimento de acesso a uma rede privada proveniente de uma rede externa, estes servidores estão expostos a potenciais ataques.

Com esta solução, os administradores têm a necessidade de efetuar o hardening destes servidores e, com isso, estão sujeitos à tarefas de gerenciamento dos hosts. Isso nos leva a uma outra discussão: maior possibilidade de falha humana, gestão de patches de segurança; além de exigir uma configuração complexa para MFA (RADIUS) e ter associado um alto custo para implementação (licenciamento Windows e hosts*).

Com o aumento da necessidade de melhoria da segurança de ambientes Cloud (e até mesmo on-premises), algumas empresas optam pela implementação de autenticação multifator. Com este método de autenticação, um usuário tem acesso concedido apenas após apresentar com sucesso duas ou mais evidências (ou fatores) para um mecanismo de autenticação: o que ele sabe (senha/passphrase), o que ele tem (algo que o usuário, e apenas o usuário, possui) e o que ele é (algo que o usuário, e apenas o usuário é, como por exemplo retina ou digital para biometria).

Neste blog, iremos discutir a implementação da autenticação de multifator (MFA) com serviços gerenciados AWS (AWS IAM Identity Center (sucessor do AWS Single Sign-On) e AWS Systems Manager), e consequentemente eliminar a necessidade de implementação de Remote Desktop Gateways (Windows) e consequentemente Jump Boxes/Bastion Hosts de outros sistemas operacionais.

Com o AWS IAM Identity Center (sucessor do AWS Single Sign-On), facilitamos o gerenciamento centralizado do acesso a várias contas AWS, serviços de produtividade e 3rd party apps (por exemplo Salesforce, Box, Microsoft 365). Com esta solução, podemos gerenciar usuários e suas identidades no armazenamento do AWS IAM Identity Center (sucessor do AWS Single Sign-On) ou conectar-se facilmente a outras opções de identidade existente, incluindo o Microsoft Active Directory, o diretório universal da Okta e o Azure Active Directory. Nesta solução, iremos focar na opção do Microsoft Active Directory (AD).

Iniciaremos com os modelos de autenticação desta solução. Da console do AWS IAM Identity Center (sucessor do AWS Single Sign-On), podemos optar por diversos provedores de identidade. Neste cenário, utilizaremos uma das opções do provedor de identidade “Active Directory”, onde temos o AWS Managed Microsoft AD ou o AD Connector:

Para AWS Managed Microsoft AD, temos as opções de arquitetura (a) ou (b), conforme detalhado nos diagramas a seguir:

Opção (a): o pedido de autenticação é efetuado na única floresta do AWS Managed AD (user forest “octank.aws”).

Figura 1 – processo de autenticação de AWS Managed AD, única floresta “octank.aws”.

Opção (b): o pedido de autenticação é recebido pela floresta do AWS Managed AD (resource forest “octank.aws”), porém é efetuado pela floresta de usuários “octank.local” utilizando o forest trust.

Figura 2 – processo de autenticação de AWS Managed AD, floresta “octank.aws” com uma relação de confiança com a floresta “octank.local”.

Para AD Connector, temos as opções de arquitetura (c) ou (d), conforme detalhado nos diagramas a seguir:

Opção (c): o pedido de autenticação é recebido pelo AD Connector e enviado para o ambiente local (octank.local), onde posteriormente será efetuado pelos Domain Controllers desta floresta.

Figura 3 – AD Connector atuando como “Proxy” para a floresta “octank.local”.

Opção (d): o pedido de autenticação é recebido pelo AD Connector e enviado para o ambiente local (octank.local), e posteriormente efetuado pelos Domain Controllers extendidos para a AWS (instâncias EC2) desta floresta.

Figura 4 – AD Connector atuando como “Proxy” para a floresta “octank.local”, porém configurado para utilizar os Domain Controllers em EC2 (extensão da floresta).

Para efetuar o login nas instâncias EC2, utilizaremos a solução Session Manager do AWS Systems Manager (AWS SSM).

O AWS SSM oferece visibilidade e controle da sua infraestrutura na AWS. O Systems Manager oferece uma interface de usuário unificada para que você possa ver dados operacionais de vários serviços da AWS e automatizar tarefas operacionais em todos os seus recursos da AWS. O Session Manager é um recurso do AWS Systems Manager totalmente gerenciado que permite administrar suas instâncias do EC2, servidores locais e máquinas virtuais (VMs), por meio de um shell interativo baseado em navegador, ou por meio da AWS CLI. O Session Manager fornece gerenciamento de instâncias seguro e auditável sem a necessidade de abrir portas de entrada, manter bastion hosts ou gerenciar chaves SSH. O Session Manager também facilita a conformidade com políticas corporativas que exigem acesso controlado a instâncias por meio de políticas de IAM, práticas rigorosas de segurança e logs totalmente auditáveis com detalhes de acesso a instâncias sendo armazenados no CloudWatch ou em um bucket do S3, sem deixar de fornecer aos usuários finais acesso as suas instâncias gerenciadas com apenas um clique. Agora que entendemos os modelos de autenticação e o AWS Systems Manager, vamos desenhar a solução em si. As premissas de segurança são:

• O servidor EC2 que iremos conectar via RDP e SSH não possuirá as portas “liberadas”. Ou seja, o Security Group não receberá a regra de Allow para as portas 3389 e 22 via inbound.
• O servidor EC2 que iremos conectar via RDP e SSH será gerenciado pelo SSM. Para isto, precisamos adicionar a IAM role correta nestas instâncias.
• Consequentemente, o SSM Agent será instalado e executado em cada instância que iremos utilizar com o SSM Session Manager (através da Internet ou com VPC endpoints do SSM).
• Os usuários que terão acesso às instâncias devem possuir dispositivos para o MFA cadastrado no AWS IAM Identity Center (sucessor do AWS Single Sign-On).
• Devemos criar um enforcement do MFA na política de acesso ao SSM Session Manager. Isto irá nos garantir que apenas usuários que efetuaram autenticação com MFA poderão ter acesso ao RDP e SSH.
• Mesmo após a autenticação de multifator, o usuário que fará a conexão deve possuir uma credencial de acesso ao EC2 (via .pem ou até um usuário do próprio Active Directory).
• O usuário que efetuará o acesso deve ter instalado o AWS CLI v2.

Em passos, temos:

1. O usuário que irá efetuar o acesso executa o comando “aws configure sso”.
2. Ele receberá um pedido para adicionar a URL do AWS IAM Identity Center (sucessor do AWS Single Sign-On). Ao adicionar, ele será redirecionado para o browser para a autenticação.
3. O usuário adiciona uma credencial do Active Directory, que fará a autenticação.
4. Ao autenticar com sucesso no Active Directory selecionado como provedor de identidade do AWS IAM Identity Center (sucessor do AWS Single Sign-On), ele terá que adicionar uma chave de acesso, desta vez pelo dispositivo registradono MFA.
5. Ao se autenticar com sucesso (Multi Factor Authentication), o usuário será redirecionado para o AWS CLI.
6. No AWS CLI, o usuário irá executar o comando “aws ssm start-session” para a instância selecionada.
7. O usuário poderá também efetuar o Remote Desktop Connection para a porta local, posteriormente adicionando a credencial de acesso para o servidor e se conectando sem liberar esta porta via Security Group.

A solução final seria uma integração do AWS IAM Identity Center (sucessor do AWS Single Sign-On) com MFA habilitado, e o SSM Session Manager para o acesso das instâncias EC2, sem a necessidade do Remote Desktop Gateway:

Agora, vamos detalhar a implementação da solução juntamente com os passos acima elaborados.

Parte 1: Selecionando o provedor de identidade:

No nosso cenário, estamos selecionando um Active Directory gerenciado da AWS (Managed Active Directory), porém poderíamos também selecionar o AD Connector.

Parte 2: Habilitar MFA no AWS IAM Identity Center (sucessor do AWS Single Sign-On)

Habilitamos MFA e registramos o dispositivo do usuário final.

É importante ressaltar que na política de MFA, fizemos um prompt de autenticação multifator para todas as vezes que o usuário fizer o sign-in.

Parte 3: Autenticando o AWS CLI com AWS IAM Identity Center (sucessor do AWS Single Sign-On) + MFA:

No PowerShell (ou até mesmo shell), configuramos o AWS IAM Identity Center (sucessor do AWS Single Sign-On) com a URL do ambiente:

Autenticamos na console e no dispositivo:

Selecionamos a conta que as instâncias estão localizadas.

Parte 4: Executando o SSM Session Manager e efetuando login:

No PowerShell, executamos o comando com o ID da instância:

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

Lembrando também que podemos efetuar acessos administrativos via PowerShell (Windows) ou Shell (Linux) com o SSM Session Manager via console ou AWS CLI v2.

*Em um ambiente produtivo de uma empresa com aprox. 300 servidores e um staff de 60 funcionários de tecnologia, utilizando instâncias sob demanda com “auto-stop” configurado para executar 2 horas após o horário de trabalho, temos 4 Remote Desktop Gateways com Windows (m5.large) e 2 Bastion Hosts em Amazon Linux (m5.large):

**Baseando-se no custo do site de Definição de preço sob demanda do Amazon EC2, 09/2020 região de São Paulo.

Recomendamos também a criação de uma política de IAM que será atribuída ao Permission Set do grupo ou usuário do AWS IAM Identity Center (sucessor do AWS Single Sign-On), com as definições de tag para as instâncias que serão gerenciadas.

No exemplo abaixo, temos a política criada para o SSM para ambos AWS-StartPortForwadingSession e também o AWS-StartSSHSession para ambientes Linux (SSH):

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Action": [

                "ssm:StartSession",

                "ssm:SendCommand"

            ],

            "Resource": [

                "arn:aws:ec2:*:ACCOUNTID:instance/*",

                "arn:aws:ssm:*:ACCOUNTID:document/SSM-SessionManagerRunShell"

            ],

            "Condition": {

                "StringLike": {

                    "ssm:resourceTag/TAGKEY": [

                        "TAGVALUE"

                    ]

                }

            }

        },

        {

            "Effect": "Allow",

            "Action": [

                "ssm:StartSession"

            ],

            "Resource": [

                "arn:aws:ssm:*:*:document/AWS-StartSSHSession",

                "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession"

            ]

        },

        {

            "Effect": "Allow",

            "Action": [

                "ssm:DescribeSessions",

                "ssm:GetConnectionStatus",

                "ssm:DescribeInstanceInformation",

                "ssm:DescribeInstanceProperties",

                "ec2:DescribeInstances"

            ],

            "Resource": "*"

        },

        {

            "Effect": "Allow",

            "Action": [

                "ssm:TerminateSession"

            ],

            "Resource": [

                "arn:aws:ssm:*:*:session/${aws:username}-*"

            ]

        }

    ]

}

Para mais informações de como criar policies customizadas, clique aqui.

Neste blog, discutimos a utilização do AWS IAM Identity Center (sucessor do AWS Single Sign-On) com autenticação multifator integrado com o AWS SSM para eliminar a necessidade do Remote Desktop Gateway e dos Bastion Hosts do seu ambiente. Além disso, integramos o AWS IAM Identity Center (sucessor do AWS Single Sign-On) com o Active Directory.

Para mais informações sobre este assunto, também oferecemos um vídeo publicado no canal on demand (inglês).”

Sobre os autores

Caio Ribeiro Cesar atualmente trabalha como arquiteto de soluções especializadas em tecnologia da Microsoft na nuvem AWS. Ele iniciou sua carreira profissional como administrador de sistemas, que continuou por mais de 14 anos em áreas como Segurança da Informação, Identity Online e Plataformas de Email Corporativo. Recentemente, se tornou fã da computação em nuvem da AWS e auxilia os clientes a utilizar o poder da tecnologia da Microsoft na AWS.

Rogerio Kasa atua como consultor de segurança, risco e compliance (SRC) na equipe de Professional Services da AWS. Com mais de 20 anos de experiência na área de segurança da informação, sendo deles 11 anos no mercado financeiro onde foi responsável por importantes projetos como adequação a normativas do banco central, internet banking e implementação de processos de resposta a incidentes. Como consultor da AWS ajuda clientes na implementação de controles de segurança e na criação de iniciativas estratégicas que habilitam a migração segura em escala e proteção de workloads para nuvem.

Renato Schmidt é arquiteto de soluções para o segmento Enterprise Greenfield na AWS e há 7 anos ajuda as empresas em sua jornada de nuvem. Seu background inclui projetos de sistemas distribuídos, sistemas embarcados e TV digital, sempre buscando desafiar o estado atual da tecnologia para desbloquear novos negócios através de soluções inovadoras.

Revisor

Bruno Lopes é Technical Trainer no time da AWS LATAM. Trabalha com soluções de TI há mais de 12 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes. Como Trainer, já está há mais de 6 anos dedicando seus dias a ensinar tecnologias de ponta aos clientes da América Latina.