Por Lucídio Neto
1. Introdução
Que atualmente existem inúmeros provedores de Cloud, isso não é novidade. Estes por sua vez, visando facilitar o manuseio e a administração de seus portais, muitas vezes permitem facilidades que podem se tornar objeto de exploração de ataques.
Podemos falar que na AWS (Amazon Web Services) a chave é o novo perímetro, ou seja, com posse de uma chave (juntamente com o segredo e opcionalmente o token de sessão), conseguimos acessar o ambiente de nuvem da empresa dona da chave em questão.
Visto que o uso de chave por padrão não tem limites, devido a API da AWS ser exposta e pública, basicamente quando essa chave é acessada por alguém não autorizada, o mesmo pode utilizá-la sem restrições, de acordo com os privilégios dados a ela.
Existem diversas formas de se ter acesso a uma chave, abaixo listamos algumas possibilidades:
i. Console Web / API (momento da criação);
ii. Aplicação;
iii. Metadados (http://169.254.169.254);
iv. Vazamento de código;
v. Endpoint (.aws/credentials , history, hardcoded, arquivos .csv da criação …);
vi. Terceiros (Cross Account);
vii. Configuração de ferramentas (scans, CI/CD);
viii. Engenharia Social.
Nesse contexto, entram dois pontos super importantes para mitigar o problema do vazamento das chaves, primeiramente o mínimo privilégio e, em segundo, a parte condicional do acesso. Essa segunda parte torna o uso da chave vazada mais desafiador para o atacante, pois adiciona-se uma camada extra, que precisará ser descoberta e abusada, para o uso da mesma.
Sendo assim, este artigo tem como objetivo permitir que profissionais ou interessados nesta temática de cibersegurança possam entender a nossa experiência e sugestão de como implementar uma arquitetura que contém condicionais de acesso (neste caso em particular nas “policies” da AWS), como uma forma de adicionar mais uma camada de segurança no processo de administração do provedor utilizado, através de Pontos Únicos de Acesso (PUA).
DESCRIÇÃO DO CENÁRIO
O cenário montado, apresentado e proposto neste artigo, versará pelos conceitos da AWS, entretanto, o modus operandi da filosofia poderá ser portado para outros provedores de Cloud. Vale ressaltar que os passos descritos a seguir não foram aplicados às regras de acesso aos serviços disponibilizados na AWS, foram apenas aos acessos das chaves administrativas.
O cenário aqui proposto utilizará recursos open source, tais como: Linux, IPTables, Squid e OpenVPN para montar o ambiente.
Neste cenário temos um servidor Linux executando os serviços de VPN Server e Proxy Server que viabilizará o acesso dos administradores do provedor do serviço de nuvem (Cloud). A ideia central é restringir todo o acesso administrativo para uma origem específica, minimizando a possibilidade de exploração de um ataque em caso de vazamento de credenciais. Na Figura 1 a seguir, temos a ilustração deste fluxo de acesso.
A seguir será apresentado o detalhamento da implementação do cenário supracitado, como forma de colaboração aos leitores interessados em replicá-lo e obter as vantagens e resultados alcançados por nosso time.
2. Ambiente do Servidor
Nesta seção serão citadas as ferramentas, o sistema operacional e um sobrevoo a 10 mil pés discorrendo sobre as configurações realizadas em cada uma das ferramentas utilizadas no servidor para viabilizar o cenário proposto.
Como visto na “Figura 1” o servidor é o nosso Ponto Único de Acesso (PUA), ou seja, será para onde os usuários administrativos estabelecerão uma VPN (Virtual Private Network) para que seja possível utilizar um proxy, para viabilizar o acesso para a AWS.
O proxy citado no parágrafo anterior também deverá ser usado além das conexões para o console da AWS, mas também para as conexões que por ventura utilizem o “aws cli”, disponível em: “https://aws.amazon.com/pt/cli/”.
Sem mais delongas, vamos às peculiaridades de cada item citado.
2.1. Sistema Operacional
O Servidor Linux pode ser qualquer máquina, incluindo VPS (Virtual Private Server), servidor On-Premise ou uma instância EC2 na AWS. No caso aqui proposto, foi utilizada uma instância EC2 na AWS rodando o sistema operacional Linux Debian 11.
A AMI (Amazon Image) utilizada para lançar a instância EC2 foi selecionada da lista de AMIs mantidas e gerenciadas pela própria equipe do Debian, disponível no link a seguir.
- https://wiki.debian.org/Cloud/AmazonEC2Image/Bullseye
2.2. Regras de firewall
A ferramenta utilizada para se configurar a regra de firewall foi o IPTables, que contém referência no item 8. deste artigo.
Visando manter ainda mais restrito o acesso para o servidor Linux para onde será estabelecida a VPN, optou-se por ocultar a porta do servidor de VPN e configurar um port knocking para disponibilizar a porta do servidor de VPN executando-se um desafio.
# port-knocking
ipset create portknock_p1 hash:ip timeout 60 2> /dev/null
ipset flush portknock_p1
ipset create portknock_p2 hash:ip timeout 60 2> /dev/null
ipset flush portknock_p2
ipset create portknock_p3 hash:ip timeout 60 2> /dev/null
ipset flush portknock_p3
iptables -A INPUT -p tcp –dport 11111 -j SET –add-set portknock_p1 src
iptables -A INPUT -m set –match-set portknock_p1 src \
-p tcp –dport 22222 -j SET –add-set portknock_p2 src
iptables -A INPUT -m set –match-set portknock_p2 src \
-p tcp –dport 33333 -j SET –add-set portknock_p3 src
iptables -A INPUT -m set –match-set portknock_p3 src -p tcp –dport 1194 -j ACCEPT
No exemplo acima encontram-se apenas as regras relacionadas com o port knocking, ou seja, ao se conectar nesta sequência de portas no intervalo de tempo proposto e na sequência disposta, a porta 1194/TCP do OpenVPN ficará disponível pelo intervalo de tempo de 60 segundos para o IP de origem que executou o desafio proposto.
Após a execução do port knocking, o usuário estará apto para o estabelecimento da VPN.
2.3. Serviço de VPN
Como citado na seção de Introdução, o programa adotado para o serviço de VPN, foi o OpenVPN, e a forma como foi configurado o serviço exige que a conexão seja estabelecida utilizando-se um certificado digital. A seguir encontra-se um exemplo de configuração do Openvpn usando certificado digital para o estabelecimento da VPN.
# openvpn configuration local 0.0.0.0 port 1194 proto tcp dev-type tun dev tun0 proto tcp-server mode server tls-server tcp-queue-limit 512 tls-verify "/etc/openvpn/scripts/verify-dn /etc/openvpn/authentication/AllowedUsers" remote-cert-tls client client-config-dir /etc/openvpn/ccd comp-lzo keepalive 10 120 cipher AES-256-CBC data-ciphers AES-256-CBC max-clients 500 persist-key persist-tun status /var/log/openvpn/openvpn-status.log log-append /var/log/openvpn/openvpn.log verb 4 script-security 2 ca /etc/openvpn/certs/cacert.pem cert /etc/openvpn/certs/server_cert.pem key /etc/openvpn/keys/server_key.pem tls-auth /etc/openvpn/keys/tls-auth.key 0 dh /etc/openvpn/keys/dh1024.pem #-- IPs configuration ifconfig 10.0.0.254 10.0.0.253 route 10.0.0.0 255.255.255.0 ifconfig-pool 10.0.0.200 10.0.0.250
Aqui não contemplaremos os procedimentos relativos à geração e manutenção de Certificados Digitais, subentende-se o seu prévio conhecimento. Neste link https://openvpn.net/community-resources/setting-up-your-own-certificate-authority-ca/, entram-se algumas explanações para consulta auxiliar.
Então, para que seja possível o estabelecimento da VPN o usuário terá de possuir um Certificado Digital do tipo “cliente” emitido pela mesma Autoridade Certificadora que gerou o Certificado Digital do tipo “servidor” utilizado na configuração do serviço do OpenVPN.
2.4. Serviço de Proxy
A ferramenta de proxy adotada foi o Servidor Squid. A sua instalação pode ser realizada de forma padrão do sistema, ou seja, “apt-get install squid”, e a sua configuração exige-se apenas o ajuste de uma regra Access List (ACL).
Abaixo pode ser visto a configuração do ajuste de uma ACL para permitir que a faixa do exemplo apresentado possa fazer uso do serviço do proxy.
root@linux-srv:~# grep localnet /etc/squid/squid.conf acl localnet src 10.0.0.0/24 # RFC1918 possible internal network http_access allow localnet
Com a VPN estabelecida, tem-se de setar o Proxy no navegador que será utilizado para a conexão com a AWS. Para título de exemplo escolheu-se o firefox, então, para a realização da configuração acessa-se as preferências do Firefox, e no final da aba de configurações Gerais, encontra-se o link para “Configurações de Proxy”.
Realizados os procedimentos até aqui propostos, o usuário estará apto a realizar requisições para a AWS utilizando-se o IP roteável do Servidor Linux da Seção 2.1.
3. Ambiente na AWS (Amazon Web Services)
Na AWS será adotado o conceito de múltiplas contas, não é escopo deste artigo realizar uma defesa acerca de tal prática, mas… fazendo uma explanação rápida sobre a segregação de contas, podemos citar que tal prática é extremamente benéfica no tocante a segurança onde pode viabilizar o isolamento do ambiente de produção do de homologação e etc. Sem contar com a delimitação dos custos, discriminando exatamente quanto cada ambiente está consumindo.
Então, como prova de conceito, o cenário aqui apresentado contará com 2 contas, uma doravante denominada de Bastion e outra de Produção. Porém, o conceito pode estender-se para outras contas, tais como: Conta de Stage, Homologação, QA, etc…
3.1. Configuração da conta Bastion
A função desta conta Bastion é apenas conter os usuários, não comportando nenhum serviço nesta conta. Os usuários que por ventura conectarem nesta conta, não possuirão absolutamente nenhum tipo de acesso que não seja a permissão de fazer switch role para a outra conta, neste caso a de Produção.
Então a ideia é que o usuário seja criado e posto em um grupo onde nesse grupo só possua permissão para fazer o switch role para a conta de Produção.
Lembrando que é extremamente importante que o usuário criado tenha o seu MFA (Multi-factor authentication) configurado, não podendo haver usuário administrativo sem tal funcionalidade habilitada.
As boas práticas de segurança recomendam que em caso de existência de outras contas na organização, estas devem ter a funcionalidade de IAM restrita e/ou desabilitada. Essa prática facilita o modelo de acesso aqui apresentado, bem como a administração de sistemas e gerenciamento de identidade de usuários.
No caso da AWS, as restrições citadas no parágrafo anterior, podem ser realizadas utilizando-se o serviço do Control Tower e/ou de regras no SCP (Service Control Policy) do Organization.
3.1.1. Policy Bastion-IAM-Policy-Production
Para se criar o grupo e adicionar o usuário a ela, precisamos inicialmente criar a policy. Então, ilustramos a criação da policy (Bastion-IAM-Policy-Production) que só possui permissão para fazer switch role para a conta de destino e que possui o condicional por IP, citado na Introdução deste artigo.
A título de exemplo, a conta Production será referenciada com o ID: 22222222.
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “AllowSTS”,
“Effect”: “Allow”,
“Action”: [
“sts:AssumeRole”
],
“Resource”: [
“arn:aws:iam::222222222222:role/Production-IAM-Role-Admin”
],
“Condition”: {
“IpAddress”: {
“aws:SourceIp”: [
“1.2.3.4/32”
]
}
}
}
]
}
3.1.2. Grupo Bastion-IAM-Group-Production
Para comportar o usuário, cria-se o grupo (Bastion-IAM-Group-Production) e adiciona-se a policy Bastion-IAM-Policy-Production, incluindo o usuário que fará uso do recurso.
Abaixo, encontra-se ilustrado apenas a policy atachada ao grupo.
3.2. Configuração da conta “Production”
O intuito é que o acesso a esta conta esteja estritamente condicionado ao IP do Servidor Linux configurado na seção 2. Para tal, acessa-se inicialmente a conta Production e cria-se a policy Production-IAM-Policy-Admin.
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: “*”,
“Resource”: “*”,
“Condition”: {
“IpAddress”: {
“aws:SourceIp”: [
“1.2.3.4/32”
]
}
}
}
]
}
Em seguida, cria-se a Role Production-IAM-Role-Admin e anexa-se a policy Production-IAM-Policy-Admin.
Na seção “Trust relationships” ilustrada na Figura 4, há a necessidade de se editar a política e ajustar para o usuário que irá realizar o Switch Role, conforme Figura 5, abaixo.
4. Juntando os pontos
Com os itens descritos nas seções 2 e 3 devidamente ajustados, e considerando-se que o usuário administrador já encontra-se com o seu posto de trabalho operacional, isto é, com o seu notebook com o cliente do OpenVPN instalado e com o seu navegador Firefox devidamente configurado para uso do proxy, este usuário poderá executar os seguintes passos para fazer uso dos recursos.
- Realizar o port knocking para ter acesso à porta do OpenVPN;
- Estabelece a conexão de VPN;
- Acessa a página de autenticação da AWS (https://console.aws.amazon.com/console/home) com o Firefox previamente configurado (vide seção 2.4).
- Preenche o formulário de autenticação com os dados requisitados;
-
Uma vez autenticado com o usuário da conta Bastion, executa-se o switch role para a conta de Produção.
O fluxo final da conexão supracitada encontra-se ilustrado na figura 6 a seguir:
5. AWS-CLI (Command Line Interface)
No caso de uso do “aws cli” para administração dos recursos, os procedimentos “a” e “b” da seção 4. deverão ser executados e as variáveis http_proxy e https_proxy devidamente ajustadas para o endereço IP e a porta do Proxy configurado na seção 2.4. No exemplo aqui apresentado ficaria da seguinte forma:
export http_proxy=”http://10.0.0.254:3128”
export https_proxy=”http://10.0.0.254:3128”
As ações “aws sts get-session-token” e “aws sts assume-role” deverão ser utilizadas para a autenticação na conta bastion e o switch-role para a conta de destino. Detalhando um pouco os comandos.
aws sts get-session-token
O get-session-token será utilizado para a autenticação na conta bastion e aquisição do token que será utilizado no switch role para a conta de destino. Segue exemplo.
aws sts get-session-token --serial-number arn:aws:iam::111111111111:mfa/user \ --token-code XXXXXX --profile default
Onde a sequência 111111111111 deverá ser substituída pelo ID da conta Bastion, o “user” deverá ser substituído pelo nome do usuário criado na seção 3.1 e o XXXXXX substituído pelo token apresentado pelo aplicativo gerenciador de MFA, tipo Authy ou Google Authenticator, que deverá estar com a chave de acesso do usuário utilizado na ocasião.
A execução da ação get-session-token fornecerá as credenciais (access_key, secret_key e session_token) que alimentarão o profile “mfa-user” que será utilizado no próximo comando.
aws sts assume-role
A ação “sts assume-role” como o nome sugere, é utilizada para que seja possível realizar o “Switch Role” para a conta de destino. Exemplo de uso da ação.
aws sts assume-role --role-arn \ arn:aws:iam::222222222222:role/Production-IAM-Role-Admin \ --role-session-name bastion-account-session --profile mfa-user
Onde a sequência 222222222222 deverá ser substituída pelo ID da conta de destino e o “mfa-user” deverá ser substituído pelo nome do profile configurado para a ocasião.
A execução da ação “sts assume-role” fornecerá as credenciais (access_key, secret_key e session_token) que alimentarão o profile “production-account” que será utilizado para a execução do comandos.
Naturalmente os profiles “default” e “mfa-user” aqui citados deverão ser configurados de acordo com as access_keys, secret_keys e session_token recebidos nos atos da conexões.
Não serão descritos aqui como gerar e administrar os respectivos profiles, ilustramos apenas o seu formato que deverá estar no arquivo ~/.aws/credentials.
[default] aws_access_key_id = xxx… aws_secret_access_key = xxx… [mfa-user] aws_access_key_id = xxx… aws_secret_access_key = xxx… aws_session_token = xxx… [production-account] aws_access_key_id = xxx… aws_secret_access_key = xxx… aws_session_token = xxx…
Com o profile production-account configurado e as variáveis de ambiente http_proxy e https_proxy devidamente ajustadas, executa-se o comando desejado, no caso ilustramos o comando para uma listagem de bucket.
aws s3api list-buckets --profile production-account
6. Outras aplicabilidades
O conceito de Perímetro Militarizado para acesso administrativo para a Cloud pode ser utilizado tanto em multi-cloud quanto em serviços específicos nas clouds. Como exemplo citaremos o serviço do SSO (Single Sign On) da AWS.
O SSO além de gerenciar com naturalidade a questão do MFA do usuário, também permite que as Policies e Roles sejam configuradas nos mesmos moldes das apresentadas aqui neste artigo.
Desta forma, o usuário só e somente só poderá fazer logon no SSO respeitando o MFA e só poderá executar alguma atividade nas contas as quais tiver permissão de acesso, se estiver rigorosamente dentro do Perímetro Militarizado, ou seja, com a VPN estabelecida e com o proxy devidamente ajustado.
7. Considerações finais
Com base na experiência e resultados obtidos com a solução apresentada neste artigo, podemos perceber que, mesmo com algum nível de esforço adicional que se torna necessário para a implementação desta solução, os benefícios de proteção alcançados acabam valendo muito a pena.
A nossa experiência prática vem mostrando que esta configuração de um ponto único de acesso, com isolamento de usuário e restrição nas políticas de switch role se mostra bastante eficaz no tocante à proteção da conta, em caso de um possível comprometimento de credencial.
Esperamos que o artigo aqui apresentado seja proveitoso e sirva de prolegômeno para elucidar dúvidas e encorajar o uso de soluções que envolvam restrições de acesso.
8. Referências
Amazon Web Services. AWS, 2022. Disponível em: https://aws.amazon.com. Acesso em: 26 de outubro de 2022.
Netfilter. IPTables, 1999-2021. Disponível em: https://netfilter.org. Acesso em: 26 de outubro de 2022.
OpenVPN, 2022. Disponível em: https://openvpn.net. Acesso em: 26 de outubro de 2022.
The Linux Foundation. Linux, 2022. Disponível em: https://www.linuxfoundation.org. Acesso em: 26 de outubro de 2022.The Squid Project.
Squid, 2022. Disponível em: https://squid-cache.org. Acesso em: 26 de outubro de 2022.
