Segurança na AWS - Uma analogia para duas importantes regras de segurança a serem lembradas
Tags: ptbr, aws, security, cloud
Published: 2020-04-13 00:09:41

Todos sabemos sobre a violação do Capital One de 2019 - 106 milhões de registros de dados de clientes violados, todos na AWS. E assim, quando os senadores norte-americanos Elizabeth Warren e Ron Wyden pediram uma investigação sobre o papel e a [responsabilidade da Amazon](https://www.usatoday.com/story/tech/talkingtech/2019/07/30/amazon-aws-unit-says-its-not-responsible-capital-one-data-breach/1868862001/) nesse incidente, a resposta da Amazon foi mais ou menos "Não é problema nosso. Está funcionando como pretendido".

Embora a AWS tenha delineado suas tarefas de segurança em seu [modelo de responsabilidade compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/), assim como seu estilo, é claro o suficiente para passar tecnicamente e ambíguo o suficiente para brechas. No entanto, não existe uma "lista de verificação" que possa ser organizada com precisão para ver o que eles são responsáveis ​​e pelo o que a AWS é responsável. No entanto, podemos resumir a linha na areia em nossa primeira regra de segurança para se lembrar:

# Regra 1 - Se você pode configurá-lo, você é responsável pela segurança dele.

Isso significa que, se você iniciar uma instância do EC2, desconfigurar um firewall e permitir que 106 milhões de registros de clientes escapem de você, a AWS não tentará salvá-lo. Seu navio afundará e a AWS passará direto por você, provavelmente em um iate.

*"Mas por que?"*

Por que não há mais especialistas técnicos, especialmente aqueles no espaço da AWS, atribuindo a culpa à AWS? Por que, apesar do fluxo constante de violações do bucket do S3, eles não estão vindo da AWS? Bem, isso nos leva a nossa segunda regra de segurança para lembrar:

# Regra 2 - Tudo na AWS é IMPLICITAMENTE NEGADO, a menos que seja EXPLICITAMENTE PERMITIDO. No entanto, negativas explícitas tem prioridade.

Isso é especialmente verdadeiro para o Gerenciamento de Identidade e Acesso (IAM), mas se aplica amplamente a tudo na AWS. Quando você cria um novo bucket S3, NINGUÉM, exceto a conta raiz (_root account_), pode acessá-lo. Quando você cria um novo usuário do IAM, **ele não pode fazer nada**. Se você criar uma instância do EC2, a menos que você abra o firewall ou use uma entrada com um par de chaves SSH, **NINGUÉM poderá acessá-lo**. Se você criar uma Lambda, a mesma coisa, fechado para o mundo por padrão. **Para que alguém possa acessar qualquer coisa, o proprietário da conta da AWS deve permitir explicitamente.**

(Sim, existem exceções, mas geralmente são para as ofertas "PaaS" da AWS, serviços como LightSail, Elastic Beanstalk etc. A VPC (Virtual Private Cloud) padrão, vem com acesso público à Internet, mas isso parece ser uma decisão para facilitar a experiência do usuário).

E assim, como sua casa, se você deixar todas as portas e janelas abertas, não poderá culpar os construtores e arquitetos se os insetos e ladrões entrarem.

**"Mas então, por que existem tantas violações?"**

Bem, ao contrário de uma casa menor, com entradas limitadas, a AWS é mais como uma mansão (e potencialmente assombrada) com uma equipe enorme que precisa se movimentar. No entanto, como todas as portas, janelas e aberturas estão fechadas e trancadas por padrão... elas não podem realmente fazer nada. Bob, o mordomo, precisa pegar um tônico e nem consegue sair do quarto. Então você abre o quarto dele, mas agora ele não pode sair do corredor. E assim você destranca o corredor. Enquanto isso, Mary, a empregada, também não pode sair do quarto e precisa ir buscar um pouco de Gin, porque um Gin e Tônico usando "micros-serviços" são o "novo melhor padrão" para a elaboração de bebidas.

Depois de 100 mordomos e empregadas pedirem para você abrir várias portas, o que você provavelmente fará?

**"Tudo bem, apenas desbloqueie todos eles Jerry!"**

Jerry concede e agora ele e Jenkins vão pulando pelo corredor, desequilibrados e desimpedidos. As operações das mansões começam a funcionar sem problemas e sua arquitetura de micros-serviços está fluindo perfeitamente. Ou seja, até você começa a perceber figuras mascaradas se misturando com a equipe.

Sussurros e suspeitas leves a princípio. Claro, já se passaram três dias desde que você viu Jerry. Na verdade, Jenkins também não esteve por perto, mas sempre foi devagar. E assim, com seu chá da tarde, você liga a televisão para encontrar os dois idiotas sorridentes compartilhando sua rotina de banho com o mundo.

---

Esse foi um longo discurso para chegar ao meu ponto. Por que existem tantas violações então? Porque fica mais fácil abrir tudo ao desenvolver serviços e aplicativos complexos. Já é bastante difícil criar algumas dessas coisas incríveis e esse atalho, intencional ou por ignorância, acelera as coisas. Mas uma vez que você faz isso, é demorado e tedioso descobrir cada abertura que DEVE ser fechada. Fechar a abertura errada pode resultar em uma interrupção temporária do serviço e horas de trabalho para as quais você não tem tempo.

Não, nenhuma das razões acima mencionadas é uma desculpa boa o suficiente, mas é fácil perder de vista o fato de que não estamos apenas lidando com máquinas aqui. Estamos lidando com empresas e humanos por trás de máquinas. Prazos próximos podem transformar pequenas falhas de segurança em baixa prioridade. A memória humana pode simplesmente... esquecer completamente que havia uma lacuna em primeiro lugar. E quando existem 100 lugares em potencial, essas lacunas podem existir? Bem... errar é humano.

# Créditos

- [Two Important AWS Security Rules to Remember](https://start.jcolemorrison.com/two-important-aws-security-rules-to-remember/), escrito originalmente por [J Cole Morrison](https://twitter.com/JColeMorrison)