Cenários de arquitetura segura

Cenário: Uma instância do EC2 executa uma aplicação web que precisa ler objetos de um bucket específico do S3. A equipe de segurança exige que nenhuma credencial de longo prazo seja armazenada na instância e que o acesso siga o princípio do privilégio mínimo. Solução: Crie uma função do IAM com uma política que permita apenas s3:GetObject no ARN do bucket específico. Anexe a função à instância do EC2 como um perfil de instância. A aplicação usa o serviço de metadados da instância (IMDS) para recuperar credenciais temporárias automaticamente — não são necessárias chaves armazenadas.

Cenário: Uma empresa armazena PII de clientes em um banco de dados RDS PostgreSQL. A equipe de conformidade exige criptografia em repouso com a possibilidade de auditar o uso das chaves. Solução: Ative a criptografia do RDS usando o AWS KMS com uma Customer Managed Key (CMK). A CMK permite que a equipe de segurança controle a rotação das chaves, visualize o uso delas no CloudTrail e revogue o acesso quando necessário. Observação: a criptografia deve ser ativada durante a criação da instância do RDS — não é possível criptografar no local uma instância do RDS existente e não criptografada. Para criptografar um banco existente, crie um snapshot, copie-o com a criptografia ativada e restaure-o a partir do snapshot criptografado.

Cenário: Um desenvolvedor tornou acidentalmente público um bucket do S3, expondo dados de clientes. A equipe de segurança quer garantir que nenhum bucket do S3 na conta possa ser tornado público, mesmo que um desenvolvedor tente fazê-lo. Solução: Ative o S3 Block Public Access no nível da conta. Isso substitui qualquer política ou ACL no nível do bucket que conceda acesso público, independentemente do que as equipes individuais configurarem. Combine essa configuração com uma regra do AWS Config (s3-bucket-public-read-prohibited) para detectar continuamente e alertar sobre buckets não conformes.

Cenário: Uma empresa quer garantir que seu banco de dados RDS só possa ser acessado pelos servidores de aplicação, e não pela Internet. Solução: Coloque o RDS em uma sub-rede privada sem uma rota para um gateway da Internet. Crie um grupo de segurança para o RDS que permita tráfego de entrada somente na porta 5432 (PostgreSQL) proveniente do grupo de segurança dos servidores de aplicação — não de qualquer intervalo de endereços IP. Isso garante que, mesmo se um servidor de aplicação for comprometido, o invasor não consiga alcançar o banco de dados de fora da VPC, e que o movimento lateral seja limitado pelas regras dos grupos de segurança.

Cenário: Atualmente, o código da aplicação contém credenciais do banco de dados codificadas diretamente em arquivos de configuração. A auditoria de segurança sinaliza isso como um risco crítico. Solução: Armazene as credenciais no AWS Secrets Manager e configure a rotação automática (o Secrets Manager possui funções integradas de rotação do Lambda para o RDS). Atualize a aplicação para buscar as credenciais no Secrets Manager durante a execução, usando o SDK. A aplicação obtém automaticamente credenciais novas sem qualquer implantação a cada rotação. Ative o modelo de rotação de segredos do RDS para obter uma rotação de credenciais totalmente gerenciada e sem tempo de inatividade.

Cenário: Uma empresa quer detectar se as credenciais de uma conta AWS foram comprometidas e estão sendo usadas de locais inesperados. Solução: Ative o Amazon GuardDuty em todas as Regiões. O GuardDuty analisa eventos do CloudTrail, registros de fluxo da VPC e registros de DNS usando aprendizado de máquina para detectar anomalias: chamadas de API de regiões geográficas incomuns, padrões de mineração de Bitcoin no EC2, comunicação com nós de saída do Tor ou padrões de exfiltração de credenciais. O GuardDuty gera descobertas que podem acionar regras do EventBridge para notificar automaticamente a equipe de segurança via SNS ou criar um chamado de suporte.

Cenário: Uma aplicação web executada atrás de um ALB está recebendo ataques de injeção de SQL. A aplicação não pode ser modificada imediatamente. Solução: Associe o AWS WAF ao ALB. Implante o grupo de regras AWS Managed Rules for Common Threats (Core Rule Set + grupo de regras de banco de dados SQL), que inclui detecção pré-configurada de injeção de SQL. O WAF inspeciona as solicitações HTTP antes que elas cheguem ao ALB e bloqueia as solicitações que correspondem a padrões de ataque — nenhuma alteração no código da aplicação é necessária. Ative também o registro do WAF no Kinesis Firehose para análise de segurança.

Cenário: Uma conta central de segurança precisa de acesso somente para leitura a todas as contas de cargas de trabalho em uma organização da AWS para executar auditorias de segurança. Solução: Em cada conta de carga de trabalho, crie uma função do IAM com uma política de confiança que permita à conta de segurança (por ID da conta) assumi-la. Anexe uma política somente leitura (por exemplo, a política gerenciada pela AWS SecurityAudit). A equipe de segurança da conta central usa STS AssumeRole para assumir temporariamente a função em cada conta de carga de trabalho. Isso segue o princípio do privilégio mínimo — nenhum usuário permanente do IAM é criado nas contas de carga de trabalho.

Cenário: Uma empresa usa o AWS Organizations e quer impedir que qualquer conta em uma OU que não seja de produção inicie instâncias GPU caras. Solução: Crie uma Service Control Policy (SCP) que negue ec2:RunInstances para famílias de instâncias GPU (p3, p4, g4, g5) e anexe-a à OU que não seja de produção. As SCPs se aplicam até mesmo a usuários raiz e usuários do IAM com nível de administrador nas contas-membro — elas funcionam como barreiras de proteção que nenhuma identidade na conta pode substituir. Isso evita gastos altos acidentais ou maliciosos em contas de desenvolvimento e teste.

Cenário: Uma empresa de serviços financeiros precisa demonstrar aos auditores que todas as chamadas de API da AWS são registradas, protegidas contra adulteração e mantidas por 7 anos. Solução: Crie uma trilha do AWS CloudTrail em várias Regiões que entregue os registros a um bucket dedicado do S3 em uma conta de registro. Ative a validação da integridade dos arquivos de registro (arquivos de resumo criptográfico que detectam adulterações nos registros). Defina uma política de Object Lock do S3 no modo de conformidade, com um período de retenção de 7 anos no bucket de registro. Isso garante que os registros não possam ser excluídos ou modificados — nem mesmo pelo usuário raiz — durante o período de retenção exigido.

Cenário: Instâncias do EC2 em uma VPC privada precisam acessar o S3 sem que o tráfego atravesse a Internet pública. Atualmente, um NAT Gateway é usado, e os custos são altos devido às taxas de processamento de dados do NAT Gateway. Solução: Crie um endpoint de gateway da VPC para o S3. Adicione uma entrada de rota à tabela de rotas da sub-rede privada, apontando a lista de prefixos do S3 para o endpoint. O tráfego para o S3 permanecerá inteiramente dentro da rede de backbone da AWS — sem NAT Gateway e sem necessidade de gateway da Internet. Os endpoints de gateway do S3 são gratuitos (ao contrário dos endpoints de interface, que têm custo por hora e por AZ). Isso também melhora a segurança ao remover o acesso ao S3 do caminho da Internet pública.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) desta lição.

Nesta lição, você trabalhou com cenários que abordaram: funções do IAM e perfis de instância para acesso ao EC2 sem credenciais, Secrets Manager para rotação automática de credenciais do banco de dados, AWS WAF para bloquear ataques de injeção sem alterações no código e CloudTrail com S3 Object Lock para registros de conformidade protegidos contra adulteração. A seguir, abordaremos cenários de arquiteturas resilientes e altamente disponíveis.