O blog da AWS
Criando uma jornada segura na nuvem AWS
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.
Quando os clientes começam suas operações de infrastrutura de serviços de tecnologia em ambiente próprio ou colocation ele mesmo é responsável pela segurança da aplicação em todos os níveis (toda a stack), desde o ambiente físico (servidores, armazenamento, base de dados, etc.) até os dados inseridos na aplicação, passando pela administração de identidade e controle de acesso, instalação do sistema operacional e aplicação, assim como patches e demais configurações de segurança.
No entanto, quando os clientes iniciam sua jornada na nuvem AWS, seja movendo aplicações de negócio existentes ou desenvolvendo novas aplicações nativamente na nuvem, eles passam a adotar o modelo de responsabilidade compartilhada. Neste modelo é a AWS que implementa, opera, gerencia e controla os componentes de segurança desde as instalações físicas até a camada do host de virtualização em que os serviços operam, reduzindo assim uma parte significativa do peso operacional do lado do cliente.
Nesse cenário, a AWS é responsável pela segurança DA nuvem e o cliente responsável pela segurança NA nuvem. Maiores detalhes sobre o modelo de responsabilidade compartilhada podem ser obtidos no site do modelo, bem como no documento AWS Security Best Practices. Este documento de melhores práticas de segurança na AWS detalha o modelo de responsabilidade compartilhada, dividindo os serviços em três categorias: serviços de infraestrutura, serviços auto-contidos e serviços abstratos.
Os serviços de segurança oferecidos pela AWS permitem que empresas altamente reguladas, em diversas partes do mundo, adotem as práticas recomendadas de proteção da informação e dados sensíveis, de forma que possam cumprir suas obrigações de proteção do sigilo e privacidade de dados. Estes serviços são desenvolvidos por engenheiros com profundo conhecimento das práticas de segurança, assim como uma ampla visão das tendências globais e evolução das ameaças cibernéticas. Desta forma, clientes da AWS podem adotar práticas pró-ativas de gerenciamento de riscos cibernéticos emergentes, praticamente em tempo real, pagando apenas pelo que consomem.
Isso significa que o cliente pode escolher e implementar a segurança que melhor se adapta à sua necessidade em cada etapa de sua jornada, sem se preocupar com despesas iniciais e com uma sobrecarga operacional significativamente menor comparada aquela em um ambiente implementado com infraestrutura própria.
Os serviços de segurança na nuvem AWS estão divididos em 5 pilares fundamentais, sendo que em cada um deles existe múltiplos serviços de segurança que podem ser adotados com o objetivo de aumentar o nível de segurança em termos de proteção de dados e resiliência operacional na nuvem AWS. Mais detalhes sobre os serviços de segurança podem ser obtidas no site de serviços de segurança.
Uma vez definida a estratégia de adoção da nuvem AWS, é muito importante definir também a estratégia de segurança, baseada em serviços, práticas e controles, inserindo-a como peça fundamental desta jornada. Nesta definição é possível conciliar a agilidade em atender as necessidades do negócio com a implementação de um ambiente seguro, ou seja, é possível ser ágil e seguro ao mesmo tempo.
Com o objetivo de estabelecer requisitos mínimos e desejáveis com base na experiência e melhores práticas, diversos frameworks e padrões podem ser considerados, como por exemplo, o NIST Cybersecurity Framework (CSF), PCI Data Security Standard (DSS), Well-Architected Framework e Cloud Adoption Framework (CAF) entre outros. Com base nestes frameworks e padrões as empresas podem definir suas práticas e controles de segurança e a partir deles escolher que serviços de segurança irão adotar, e em que momento.
Nesta série de 3 artigos, trataremos de um modelo de jornada de segurança NA nuvem que pode ser utilizado como exemplo para a implementação dos serviços de segurança AWS em 3 diferentes blocos, proporcionando escalar rapidamente o nível de maturidade de segurança de seu ambiente à medida que adota a nuvem AWS.
Dividiremos nossa discussão em 3 grandes blocos:
- Etapa de Acessos – Adoção de melhores práticas e serviços para controlar acessos aos recursos na nuvem AWS.
- Etapa de visibilidade e controle – Adoção de melhores práticas e serviços para aumento de visibilidade e controle de ambiente na nuvem AWS.
- Etapa de automação – Adoção de mehores práticas e serviços para automação de segurança e implementação de princípios de DevSecOps, Segurança como código e Security by Design.
As 3 etapas podem ser executadas paralelamente, trazendo mais agilidade na adoção de controles de segurança ao seu ambiente.
Nesse primeiro Artigo trataremos das melhores práticas de gestão de identidade e acessos, considerando a adoção dos serviços AWS Organizations, IAM, AWS IAM Identity Center (sucessor do AWS Single Sign-On), Session Manager (Systems Manager) e Directory Services.
1. Uso do AWS Organizations.
- É fundamental definir um modelo de múltiplas contas usando o AWS Organizations para segregar os ambientes de desenvolvimento, produção, sandboxing, auditoria, segurança ou outros ambientes que façam sentido para seu modelo de negócio, criando assim uma camada de isolamento lógico entre as diferentes contas, utilizando também o recurso de SCP (Service Control Policies) para permitir, por exemplo, limitar o uso de serviços e regiões autorizadas, bem como a limitação de alterações de configurações de segurança de buckets S3.
Abaixo apresentamos algumas políticas de exemplo que foram aplicadas no cenário de contas apresentado acima. Vale destacar que esses são exemplos de políticas de SCP. Para mais informações e customizações para seu ambiente é importante avaliar a documentação do AWS Organizations e de SCP.
- SCP → Deny Security Services (Exemplo) – Bloqueia acesso aos serviços de segurança na conta de produção, ou seja, mesmo que um usuário tenha permissões administrativas na conta de produção, ele não terá acesso a desabilitar por exemplo o serviço CloudTrail e nem mesmo acessar o GuardDuty, Inspector e SecurityHub.
{
"Version":“2012-10-17”,
"Statement":[
{
"Sid":“Stmt1548170128000”,
"Effect":"Deny",
"Action":[
"“cloudtrail":"*”"
],
"Resource":[
"*"
]
},
{
"Sid":“Stmt1548170142000”,
"Effect":"Deny",
"Action":[
"“guardduty":"*”"
],
"Resource":[
"*"]
},
{
"Sid":“Stmt1548170151000”,
"Effect":"Deny",
"Action":[
"“inspector":"*”"
],
"Resource":[
"*"
]
},
{
"Sid":“Stmt1548170170000”,
"Effect":"Deny",
"Action":[
"“securityhub":"*”"
],
"Resource":[
"*"
]
}
]
}
- SCP → Permited Services (Exemplo) – Liberação apenas de serviços autorizados em produção, nesse caso foi configurado o RDS, EC2, ECR, S3 e Autoscaling.
{
"Version":“2012-10-17”,
"Statement":[
{
"Sid":“Stmt1550329049000”,
"Effect":"Allow",
"Action":[
"“rds":"*”"
],
"Resource":[
"*"
]
},
{
"Sid":“Stmt1550329060000”,
"Effect":"Allow",
"Action":[
"“ec2":"*”"
],
"Resource":[
"*"
]
},
{
"Sid":“Stmt1550329065000”,
"Effect":"Allow",
"Action":[
"“autoscaling":"*”"
],
"Resource":[
"*"
]
},
{
"Sid":“Stmt1550329071000”,
"Effect":"Allow",
"Action":[
"“ecr":"*”"
],
"Resource":[
"*"
]
},
{
"Sid":“Stmt1550329080000”,
"Effect":"Allow",
"Action":[
"“s3":"*”"
],
"Resource":[
"*"
]
}
]
}
- SCP → Deny S3 Public Access (Exemplo) – Força o bloqueio de alteração de configuração de buckets S3 utilizando o recurso Amazon S3 Block Public Access.
{
"Version":“2012-10-17”,
"Statement":[
{
"Sid":“Stmt1548173791000”,
"Effect":"Deny",
"Action":[
"“s3":"GetAccountPublicAccessBlock”",
"“s3":"GetBucketPublicAccessBlock”",
"“s3":"PutAccountPublicAccessBlock”",
"“s3":"PutBucketPublicAccessBlock”"
],
"Resource":[
"*"
]
}
]
}
Outras políticas de SCP e modelo de múltiplas contas podem e devem ser consideradas para atender as suas necessidades de controles de segurança. Mais informações podem também ser obtidas nos 2 Webinars Applying AWS Organizations to Complex Account Structures e AWS re:Invent 2018: Architecting Security & Governance across your AWS Landing Zone.
2. Uso do Session Manager para controlar o acesso de usuários com privilégios administrativos ao ambientes de servidores Windows e LINUX.
- Controlar o acesso de usuários com poderes administrativos é fundamental e a capacidade de utilizar um segundo fator de autenticação para esses usuários de forma integrada é ainda mais relevante. A capacidade de armazenamento de log de todos os comandos executados por usuários administradores nos sistemas acessados de forma nativa é fundamental, especialmente com o armazenamento não só da entrada dos comandos, mas das respostas (saída) e ainda, a capacidade de proteger esses logs contra a deleção utilizando uma camada de criptografia para proteger os logs de comandos e ações executadas.
3. Uso do AWS SSO + AWS AD + AWS Organizations Mapping para gerenciar perfis de acesso em ambiente de múltiplas contas.
- Uma vez que se adota o modelo de múltiplas contas para segregar logicamente ambientes como melhor prática de segurança é possível também utilizar o Serviço AWS SSO juntamente com o serviço AWS Directory Services com o objetivo de otimizar o provisionamento de acessos em múltiplas contas AWS, utilizando um mapeamento de grupos do AD com conjunto de permissões (permission sets) previamente definidas para criar acessos mais controlados e segregados em várias contas.
O exemplo abaixo apresenta um cenário onde usuários admin1, dba1, security1 e auditor1, quando inseridos em grupos pré-definidos do AD, recebem permission sets previamente definidos e que possibilitam acessos através de roles a cada uma das contas AWS (Test, Dev, Prod, Sandbox). Nesse cenário, por exemplo, o usuário admin1 tem acesso de System Administrator nas contas de Dev, Prod, Test e Sandbox.
Essa configuração permite uma integração simplificada com bases autoritativas já existentes em ambiente tradicionais e que podem provisionar usuários de forma automatizada em Grupos de AD com base em suas funções, por exemplo, um dba seria inserido ao Grupo AWS_DBA do AD e automaticamente ganharia o acesso previamente definido nos ambientes corretos.
Da mesma forma, quando um usuário for desligado e/ou removido da base autoritativa e respectivamente do Grupo do AD perderá o acesso aos ambientes e contas AWS automaticamente.
4. Boas práticas de Gestão de Acesso – Além da utilização dos serviços apresentados anteriormente é importante considerar a adoção de práticas como:
- Definir um processo e procedimentos para gerenciar as contas da nuvem AWS. Adote um modelo de governança que permita criar de forma consistente todas as configurações iniciais das contas e deixe clara a responsabilidade e propriedade das contas, utilizando, por exemplo, o serviço Control Tower para definição de GuardRails de forma automatizada na criação de novas contas.
- Configurar corretamente as informações de contatos (especialmente o contato de segurança) de cada uma das contas que serão atualizadas utilizando a console AWS.
- Considerar a criação de contas da AWS vinculadas a listas de distribuição de e-mail ao invés de endereços indidivuais de e-mail. Isso permite que um grupo de pessoas monitore e responda sobre a atividade da conta. Além disso, fornece resiliência quando ocorrem mudanças internas e acelera o tempo para comunicações sensíveis.
- Exigir autenticação forte (token / Múltiplo Fator de Autenticação) de todos os usuários do IAM com credenciais e senhas de acesso a console da Nuvem AWS e considere o uso de MFA também quando integrado com AD e SSO.
- Definir uma política de senha para as contas da AWS, exigindo tamanho mínimo, complexidade para senhas associadas aos usuários e uma política de rotação obrigatória exigindo dos usuários que alterem suas senhas em intervalos regulares.
- Restringir o uso de contas com acesso privilegiado, especialmente a primeira conta criada no ambiente de nuvem AWS. A conta root, como é conhecida, deve ser utilizada apenas para criar outro conjunto inicial de usuários e grupos do IAM que serão utilizados na operação diária. Esta conta deve ser devidamente protegida e suas credencias de acesso armazenadas de forma segura, incluindo a criação de um segundo fator de autenticação (MFA).
- Avaliar o estabelecimento de confiança (trust) com provedores de identidade já existentes em sua organização. O uso de federação reduz a necessidade de criar usuários manualmente no IAM da AWS e você ainda pode aproveitar seu mapeamento de usuários e identidades já existentes, além de papéis e responsabilidades já mapeadas em sua organização. O uso do SSO como apresentado anteriormente deve ser considerado.
- Adotar o princípio de menor privilégio, garantindo que as identidades autenticadas só terão permissão para realizar o conjunto mínimo de funções necessárias cumprindo tarefas específicas. A granularidade de acessos na AWS é implementada através da definição de papéis e políticas definidas no IAM.
- Considerar a adoção do serviço AWS Organizations para gerenciar de forma centralizada diversas contas na nuvem. Além do agrupamento de contas em unidades organizacionais (OUs) ele permite a aplicação de políticas de segurança e controle centralizado de custos de diversas contas e/ou departamentos que usem os serviços da AWS.
- Utilizar o recurso Secrets Manager para proteger as credenciais de acesso de aplicações, evitando assim a exposição de credenciais de acesso em arquivos de configuração, ou locais desprotegidos, além de rotacionar periodicamente essas credenciais de acesso de forma automatizada.
- Realizar revisões de acesso periódicas no mínimo a cada 3 meses, ou conforme determinado em sua política de segurança, avaliando possíveis acessos concedidos e não utilizados, através de recursos como o IAM Access Advisor disponível na ferramenta AWS IAM.
- No modelo de Organizations considerar a utilização de contas dedicadas para o time de Segurança, armazenando logs de auditoria e outras informações sensíveis e relevantes para a Segurança da Informação.
- Sempre que possível usar os mecanismos de roles para dar acesso aos recursos em servidores/instâncias EC2 e outros recursos na nuvem AWS.
Nos próximos artigos falaremos de práticas para melhorar a visibilidade, controle e automação de segurança de seu ambiente na nuvem AWS. Vale destacar que é de suma importância que você avalie as regulamentações, boas práticas e exigências específicas de cada indústria a fim de adequar as melhores práticas de segurança às suas necessidades.
Sobre os Autores
Marcello Zillo
Marcello é especialista de segurança da AWS na América Latina, apoiando empresas dos mais diversos segmentos na criação e execução de suas estratégias de segurança e jornada para a nuvem. Atuando em Segurança da Informação, Riscos e Conformidade há mais de 20 anos, ocupou anteriormente cargos executivos em instituições financeiras, liderando projetos de transformação nas mais diversas disciplinas de Segurança, Riscos e Compliance.
Daniel Garcia
Daniel é arquiteto de soluções de segurança e atualmente está focado em apoiar empresas do setor financeiro na América Latina em sua adoção segura de serviços de computação em nuvem. Com experiência de mais de 18 anos em tecnologia e segurança da informação, Daniel já ajudou dezenas de companhias de vários segmentos e abrangência geográfica a definir, planejar e implementar com sucesso suas estratégias de cibersegurança.