Épicos de segurança, área por área

Objetivo

Estabelecer os princípios e as práticas transversais antes de entrar no detalhe de cada área. É aqui que se decide como separar ambientes, como proteger o que há de mais sensível em uma conta e como saber se os controles realmente reduzem o risco.

Os 7 princípios de design do pilar

• Construir uma base forte de identidade: menor privilégio, separação de funções e o objetivo de eliminar credenciais estáticas de longo prazo.
• Manter rastreabilidade: monitorar, alertar e auditar ações e mudanças em tempo real.
• Aplicar segurança em todas as camadas: defesa em profundidade, da borda da rede ao código.
• Automatizar as práticas de segurança: controles definidos como código em templates versionados.
• Proteger dados em trânsito e em repouso: classificar e usar criptografia, tokenização e controle de acesso.
• Manter pessoas longe dos dados: reduzir o acesso direto e o processamento manual.
• Preparar-se para eventos de segurança: processos de incidente, simulações e automação.

Boas práticas do Well-Architected (8 listadas)

Por onde começar

1. Separe produção, desenvolvimento e workloads em contas distintas.
2. Proteja o usuário root de cada conta: sem acesso programático, com controles adequados e sem uso rotineiro.
3. Derive os objetivos de controle dos seus requisitos de conformidade e dos riscos levantados em um modelo de ameaças.

Objetivo

Gerenciar as identidades que acessam seus ambientes e o que cada uma pode fazer. São duas frentes: identidades (quem é) e permissões (o que pode fazer, em quais recursos e sob quais condições).

Dois tipos de identidade

• Humanas: a equipe (administradores, desenvolvedores, operadores), terceiros (fornecedores, parceiros) e os usuários dos seus aplicativos.
• De máquina: aplicações, ferramentas operacionais e componentes, como instâncias EC2 e funções Lambda, além de máquinas fora da AWS que precisam de acesso.

Boas práticas do Well-Architected (15 listadas)

Por onde começar

1. Centralize o acesso humano em um provedor de identidade e use credenciais temporárias no lugar de chaves de longo prazo.
2. Escreva as permissões com privilégio mínimo e revise-as continuamente com base no uso real.
3. Defina guardrails para a organização e analise regularmente os acessos públicos e entre contas.

Objetivo

A detecção tem duas partes: perceber mudanças de configuração inesperadas ou indesejadas e perceber comportamento inesperado. A primeira pode acontecer em vários pontos do ciclo de entrega, inclusive antes do deploy, nos pipelines de CI/CD. A segunda envolve, por exemplo, monitorar chamadas de API que alteram a postura de segurança.

Boas práticas do Well-Architected (4 listadas)

Por onde começar

1. Ative o logging dos serviços e das aplicações e centralize em um local padronizado.
2. Use detecção de ameaças gerenciada (por exemplo, Amazon GuardDuty) e monitore chamadas de API que mudam a postura de segurança.
3. Automatize a correção de recursos que saem da conformidade.

Objetivo

Garantir que sistemas e serviços do workload estejam protegidos contra acesso não autorizado e contra vulnerabilidades. Isso inclui definir limites de confiança (rede e conta), configuração e manutenção segura dos sistemas (hardening, minimização, patching), autenticação e autorização nos sistemas operacionais e pontos de aplicação de política, como WAF e API gateways.

Zero Trust nas redes

• Em vez de confiar em tudo que está dentro da rede, trate os componentes como discretos: nenhum componente ou microsserviço confia em outro.
• O desenho da rede é a base do isolamento. Apoie-o com mecanismos de inspeção e proteção automatizados.

Boas práticas do Well-Architected (9 listadas)

Por onde começar

1. Separe a rede em camadas e controle o fluxo de tráfego entre elas.
2. Provisione computação a partir de imagens reforçadas e mantenha um processo contínuo de gerenciamento de vulnerabilidades.
3. Reduza o acesso interativo e o gerenciamento manual dos recursos.

Objetivo

A classificação de dados organiza as informações por nível de sensibilidade, e a criptografia as torna ininteligíveis para quem não tem autorização. Esses métodos sustentam objetivos como evitar o manuseio indevido e cumprir obrigações regulatórias.

Técnicas complementares

• Criptografia: transforma o conteúdo de forma que só seja legível com a chave.
• Tokenização: substitui uma informação sensível por um token sem significado próprio, o que pode reduzir o escopo de conformidade.
• Mascaramento: oculta parte do dado até o ponto em que o restante deixa de ser sensível.
• Auditoria de chaves: acompanhe o uso das chaves (por exemplo, pelo CloudTrail) para validar que os controles de acesso estão corretos.

Boas práticas do Well-Architected (8 listadas)

Por onde começar

1. Entenda e documente o esquema de classificação dos seus dados.
2. Habilite criptografia em repouso e em trânsito e implemente gerenciamento seguro de chaves e certificados.
3. Automatize a proteção dos dados e audite o uso das chaves.

Objetivo

A preparação influencia diretamente a capacidade das equipes de operar durante um incidente: isolar, conter, fazer forense e restaurar a operação a um estado seguro. Ter ferramentas e acessos prontos antes do incidente, e praticar com game days, ajuda a recuperar-se minimizando a interrupção do negócio.

Preparar nos três domínios

• Pessoas: identificar as partes interessadas e treiná-las em resposta a incidentes e em tecnologias de nuvem.
• Processos: documentar arquiteturas, criar planos de resposta e playbooks.
• Tecnologia: configurar acessos, agregar e monitorar logs, criar alertas e desenvolver capacidade de resposta e investigação.

As 5 fases da operação

• Detecção: identificar um possível evento de segurança.
• Análise: determinar se é um incidente e avaliar o escopo.
• Contenção: minimizar e limitar o alcance do evento.
• Erradicação: remover recursos ou artefatos não autorizados e corrigir a causa.
• Recuperação: restaurar os sistemas a um estado seguro e monitorar para garantir que a ameaça não volte.

Boas práticas do Well-Architected (8 listadas)

Por onde começar

1. Identifique quem participa da resposta (internos e externos) e documente um plano de gerenciamento de incidentes.
2. Provisione acessos e ferramentas antes de precisar delas.
3. Pratique com simulações e transforme cada incidente em aprendizado.

Objetivo

Segurança de aplicações é o processo de como você projeta, constrói e testa as propriedades de segurança dos workloads que desenvolve. Pessoas treinadas, entendimento da segurança da infraestrutura de build e release e automação para identificar problemas são a base. Quanto mais cedo no ciclo de desenvolvimento, menor o custo de corrigir, e uma modelagem de ameaças na fase de design ajuda a achar falhas cedo.

Quatro áreas de foco

• Organização e cultura.
• Segurança do pipeline (a infraestrutura de build e release).
• Segurança no pipeline (testes e verificações automatizados).
• Gerenciamento de dependências.

Boas práticas do Well-Architected (8 listadas)

Por onde começar

1. Faça modelagem de ameaças já na fase de design e treine as equipes em segurança de aplicações.
2. Automatize testes de segurança e revisões de código no pipeline e implante software de forma programática.
3. Centralize pacotes e dependências e avalie periodicamente a segurança dos próprios pipelines.