Segurança na AWS - Uma analogia para duas importantes regras de segurança a serem lembradas

#ptbr #aws #security #cloud

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 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, 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.