Os 11 erros de configuração mais comuns na AWS e como evitá-los

Como evitar as 11 principais configurações incorretas da AWS

Ao configurar uma nova infraestrutura de nuvem da AWS ou ao modificar qualquer configuração para conceder ou retirar permissões, sempre há considerações a serem feitas em relação à segurança.

O Modelo de Responsabilidade Compartilhada da AWS enfatiza que você é responsável pela segurança "na" nuvem, enquanto a AWS é responsável pela segurança "da" nuvem. Em termos simples, isso significa que você é responsável pelas alterações que fizer que resultem na exposição pública de quaisquer dados seus.

Neste artigo, exploraremos os conjuntos mais comuns de configurações incorretas nos serviços mais comuns e aconselharemos sobre como permanecer seguro e evitar possíveis violações ao modificar sua infraestrutura.

Top 4 S3 configurações incorretas

1. Buckets públicos ou objetos públicos dentro de buckets

Sempre que você precisar usar o S3 para armazenamento de sites ou como uma opção de hospedagem de websites estáticos, provavelmente precisará tornar parte dele, se não tudo, público. Esse é um processo fácil, mas se feito incorretamente, pode colocar todos os seus dados em risco de violação. Como sabemos, tais violações tiveram consequências extensas nos últimos anos. Se você estiver criando um novo bucket e quiser torná-lo público, há algumas opções para escolher.

Conforme visto na captura de tela abaixo, você pode optar por permitir acesso público a buckets e objetos, por meio de novas ACLs, quaisquer ACLs, novas políticas de ponto de acesso ou quaisquer políticas de ponto de acesso:

Você deve ter cuidado ao escolher a solução mais apropriada para sua aplicação. Além disso, tenha cuidado com o que você adiciona ao seu bucket, pois ele permanecerá público até que você o altere, o que pode expor dados confidenciais.

2. Não usar registro de acesso

O registro de acesso S3 é uma configuração fácil de ativar. Se você navegar até a guia Propriedades de um bucket, você verá isso lá:

Ele está desabilitado por padrão, mas você pode habilitá-lo clicando no botão Editar e atribuindo um bucket de destino para os logs serem armazenados.

O que essa configuração faz é registrar cada solicitação de acesso ao seu bucket. Melhor ainda, esses logs não têm custo extra para uso, então eles podem ser realmente úteis em certas situações e até mesmo ajudar a explicar uma fatura S3 para um cliente. Ainda assim, tenha em mente que você ainda será cobrado pelo armazenamento desses logs no bucket de destino, com os preços do S3 aplicados normalmente. Como esses logs podem se acumular rapidamente, talvez você queira configurar um mecanismo de exclusão para eles.

Também vale a pena notar que seu bucket de destino não deve ter o registro de acesso habilitado, ou você causará um loop infinito e poderá acabar com uma conta alta a pagar.

3. Não usar versionamento + ciclo de vida S3

Ao habilitar o controle de versão de bucket, você pode armazenar várias instâncias de um objeto dentro do mesmo bucket. O aspecto mais útil desse recurso é que ele permite que você se recupere de um mau funcionamento da aplicação ou de qualquer ação não intencional do usuário.

Você pode habilitá-lo por meio do console S3 navegando até a guia Propriedades:

É fácil de ativar e você também deve acompanhá-lo com a exclusão de autenticação multifatorial (MFA) para evitar a exclusão não intencional de instâncias anteriores de objetos.

A desvantagem desse recurso é que, para cada versão de um objeto, ele armazena o objeto inteiro, não apenas a diferença entre esse objeto e outras versões dele mesmo. Isso pode ser mitigado usando regras de configuração do ciclo de vida do S3. Dessa forma, você pode configurar objetos não atuais para se autoexcluírem após um determinado período de tempo; ou pode transferi-los para serviços de armazenamento mais acessíveis, como o S3 Glacier Flexible Retrieval, e excluí-los quando forem substituídos por uma versão mais recente.

4. Não criptografar informações críticas

Se você estiver armazenando dados confidenciais, você deve sempre criptografá-los. Você pode fazer isso no lado do servidor por meio do próprio S3 ou pode fazer isso sozinho no lado do cliente. Se você optar por fazer isso no lado do servidor, será muito mais fácil, pois a Amazon cuida da criptografia, do armazenamento e da descriptografia ao baixar ou copiar um objeto. Você pode ativar isso na guia Propriedades clicando no botão Editar na seção Criptografia padrão:

Isso permitirá que você escolha quais chaves deseja usar para a criptografia. As chaves SSE-S3 são gerenciadas pelo S3 e você não precisa fazer nada. As chaves SSE-KMS são gerenciadas pelo KMS e exigem um pouco mais de configuração.

Se seus dados forem extremamente confidenciais, talvez você queira considerar criptografá-los antes de armazená-los. Isso é possível, mas um pouco perigoso, pois se você perder suas chaves, não poderá recuperar ou descriptografar seus objetos. Esse processo também é extenso e requer configuração, então você deve consultar a documentação da AWS sobre como fazer isso.

As 3 principais configurações incorretas do EC2

1. Snapshots públicos ou Snapshots compartilhados não criptografados

Os snapshots que você faz de suas instâncias são privados por padrão, mas há dois cenários em que isso pode mudar.

O primeiro é quando qualquer pessoa com permissões suficientes (até mesmo um serviço como o AWS Lambda) altera os dados para públicos, tornando um estado anterior de todos os seus dados publicamente disponível, o que pode ser desastroso. O segundo cenário aconteceria se você precisasse compartilhar um instantâneo não criptografado. Nesse caso, o destinatário do snapshot poderia criar volumes a partir dele, praticamente inicializando uma instância com todos os seus dados.

De qualquer forma, você deve criptografar seus snapshots, o que significa criptografar suas instâncias na criação ou criar um snapshot criptografado e, em seguida, um novo volume raiz a partir desse snapshot.

2. Instâncias de backend que vivem em sub-redes públicas

Se você tiver instâncias que não exijam conectividade com a Internet, como bancos de dados ou APIs simples, você deve mantê-las dentro de sub-redes privadas. Estar conectado à Internet é uma ameaça constante que pode ocorrer a qualquer momento, já que você nunca sabe quem tem acesso ao IP da sua instância.

A maneira de fazer uma instância ficar ativa em uma sub-rede privada é simplesmente remover a atribuição automática dos endereços IPv4 e IPv6. Você pode fazer isso acessando a guia Sub-rede no console da VPC, escolhendo a sub-rede da sua instância e desativando essa configuração:

3. AMIs públicas/não criptografadas

Se você precisar criar uma AMI, talvez seja necessário compartilhá-la com outra conta. Nesse caso, você deve ter cuidado e tomar algumas medidas para evitar qualquer violação de segurança.

Primeiro, você deve criptografar seus volumes, para que qualquer AMI que possa incluir um volume seja criptografada por padrão e não revele nenhum dado. Em segundo lugar, você deve ter cuidado ao dar permissões ao EC2 porque isso pode incluir definir a disponibilidade da AMI como pública; isso pode ser um problema se você tiver um ator malicioso dentro da sua empresa ou se algum serviço como o AWS Lambda estiver comprometido.

Por fim, você deve sempre compartilhar suas AMIs por meio do console para evitar possíveis contratempos que possam expô-las ao mundo:

As 4 principais configurações incorretas do IAM

1. Falta de MFA/rotação de chaves

A autenticação multifatorial (MFA) é crucial e deve ser exigida para qualquer entidade adicionada ao gerenciamento de identidade e acesso (IAM), especialmente usuários. Dessa forma, você pode mitigar chaves roubadas e eliminar uma grande superfície de ataque. Para torná-la obrigatória, você precisa navegar até a aba Credenciais de Segurança do usuário para o qual deseja habilitá-la e selecioná-la lá:

Você também deve impor a rotação de chaves de acesso em toda a conta. Embora a AWS não tenha uma maneira automática de fazer isso e sugira fazê-lo manualmente, existem ferramentas de código aberto que podem automatizar e simplificar o processo para você. Isso se aplica somente a usuários do IAM e não a funções, pois as funções já têm expiração automática de chave após um período de tempo definido.

2. Não usar funções

Por meio do Identity Access Management (IAM), você pode optar por conceder permissões aos usuários anexando políticas diretamente a eles. Mas fazer isso é uma prática ruim em infraestruturas grandes e críticas, pois você pode estar dando permissões erradas para as pessoas erradas; além disso, se você esquecer de remover essas permissões, elas permanecerão lá para sempre.

Ao usar funções como o método preferencial de concessão de permissões, você obtém expiração automática de chaves, o que é uma maneira muito mais gerenciável de lidar com permissões excessivas ou chaves roubadas. Você também pode optar por usar grupos se tiver muitos usuários que compartilham privilégios comuns, mas tente não anexar políticas diretamente aos usuários.

3. Dar muitos privilégios

Ao conceder permissões, você deve fazê-lo de acordo com o Princípio do Privilégio Mínimo. Se um usuário ou função precisar de acesso a um serviço, você deve reunir as ações específicas que eles devem tomar para fazer seu trabalho e atribuir esses privilégios à entidade do IAM, em vez de seguir o caminho mais fácil e apenas conceder acesso ao serviço como um todo. Como abordamos, há muitos conjuntos de permissões simples, mas muito poderosos, que, quando concedidos, podem ter consequências desastrosas.

4. Manter credenciais não utilizadas por perto

Você deve sempre monitorar suas chaves, usuários ativos e funções em toda a sua infraestrutura. Se algum usuário ficar inativo por qualquer motivo (por exemplo, férias, dispensa, etc.), você pode considerar desativar essas chaves pelo tempo necessário e excluí-las depois de algum tempo.

Dessa forma, você não terá nenhum conjunto de chaves que ainda tenha permissões anexadas e apresente uma brecha no seu ambiente. É sempre preferível recriar um usuário em vez de ficar exposto a possíveis ataques internos.

Sumário

Há muitas maneiras pelas quais modificar sua infraestrutura pode dar errado e, se você não tomar cuidado, pode acabar comprometendo seus dados. No entanto, isso pode ser atenuado fazendo mudanças para evitar as configurações incorretas acima de forma gradual e consciente.

Como alternativa, você pode contar com a CrowdStrike para fornecer a segurança necessária. Fomos recomendados pela AWS por alcançar a distinção de Detecção e Remediação de Ameaças. O CrowdStrike Falcon^® for AWS pode ajudar você a analisar e mitigar todos os problemas listados aqui e muitos outros.