Postagens

Mostrando postagens com o rótulo Segurança

IAM Groups na AWS: Por Que Você Não Deve Anexar Políticas Diretamente a Usuários

Se você já precisou revogar acesso de um desenvolvedor que saiu da empresa e descobriu que ele tinha políticas anexadas diretamente ao usuário — espalhadas por dezenas de permissões individuais — você entende exatamente por que IAM Groups existem. Gerenciar permissões usuário a usuário não escala, e o custo disso aparece sempre no pior momento. TL;DR — IAM Groups vs. Políticas Diretas em Usuários Critério Política Direta no Usuário IAM Group Escalabilidade Não escala — cada usuário precisa de atualização individual Escala — uma mudança no grupo afeta todos os membros Auditoria Difícil — permissões fragmentadas por usuário Centralizada — políticas visíveis no grupo Onboarding Manual e propenso a erro Adicionar ao grupo aplica todas as permissões automaticamente Offboarding Requer auditoria ...

Por que usar o Secrets Manager em vez de hardcoding de credenciais?

A pergunta aparece toda semana em revisões de código: 'o repositório é privado, então qual é o problema de deixar a senha do banco no application.properties ?' O problema é que repositório privado não é modelo de segurança — é uma suposição que falha no primeiro acidente de permissão, no primeiro desenvolvedor que sai da empresa, ou no primeiro vazamento de token do GitHub. O AWS Secrets Manager existe exatamente para eliminar essa suposição do design da aplicação. TL;DR — Hardcoding vs. Secrets Manager Critério Hardcoding / Variável de Ambiente AWS Secrets Manager Rotação de senha Manual, requer redeploy Automática via Lambda rotation function Auditoria de acesso Nenhuma CloudTrail registra cada GetSecretValue Superfície de exposição Código-fonte, logs, variáveis de processo Apenas em memória, no momento do uso Controle de acesso Quem tem acesso ao repo tem a senha IAM policy por role, por recurs...

Quem Deletou Meu EC2? Rastreando TerminateInstances com CloudTrail

Uma instância EC2 sumiu em produção e ninguém assume a responsabilidade. Antes de escalar o incidente, o primeiro passo é consultar o CloudTrail — ele registra cada chamada de API na sua conta, incluindo exatamente quem executou o TerminateInstances e quando. TL;DR — Resumo Rápido Etapa O que fazer 1 Abrir o CloudTrail Event History no console ou usar a CLI 2 Filtrar pelo nome do evento TerminateInstances 3 Identificar o campo userIdentity no evento retornado 4 Confirmar ARN, tipo de principal e hora exata da ação Como o CloudTrail Registra Ações de EC2 O CloudTrail captura chamadas de API feitas à AWS — via console, CLI, SDK ou serviços internos. Para o EC2, cada ação de controle (criar, parar, terminar instância) gera um evento de gerenciamento ( management event ) que fica disponível no Event History por 90 dias, sem necessidade de configurar uma trail separada. O evento TerminateInstances ...

Estrutura Básica de Política IAM: Effect, Action, Resource e Condition

Você abre uma política IAM no console da AWS e vê um bloco JSON com quatro campos que determinam se uma requisição será permitida ou negada. Entender o que cada elemento faz — e como eles interagem — é a diferença entre uma política que funciona como esperado e uma que silenciosamente bloqueia acesso em produção. TL;DR — Estrutura Básica de Política IAM Elemento O que define Obrigatório? Effect Allow ou Deny para o statement Sim Action Quais operações de API estão no escopo Sim Resource Quais recursos AWS são alvo da política Sim Condition Restrições contextuais adicionais (IP, MFA, tags, etc.) Não Como o Motor de Avaliação IAM Processa uma Política Antes de dissecar cada elemento, vale entender o fluxo de decisão. Quando uma principal faz uma chamada de API, o IAM avalia todos os statements aplicáveis e segue uma ordem de precedência estrita: um Deny explícito sempre vence qualquer Allow. A ausênc...

Criando uma Presigned URL no S3: Acesso Temporário a Arquivos Privados

Você tem um arquivo privado no S3 e precisa dar acesso temporário a um usuário sem expor suas credenciais AWS nem tornar o bucket público — esse é exatamente o cenário para o qual as Presigned URLs foram criadas. Com uma URL assinada, você delega acesso a um objeto específico por um período determinado, sem alterar as permissões do bucket. TL;DR — Resumo Rápido Ponto Detalhe O que é URL temporária que carrega credenciais assinadas na própria query string Expiração padrão usada aqui 3600 segundos (1 hora) Quem assina A identidade IAM que gera a URL (usuário, role ou instância) Bucket precisa ser público? Não — o objeto pode permanecer completamente privado SDK usado AWS SDK for Python (Boto3) e AWS SDK for JavaScript v3 Alternativa via CLI aws s3 presign Como a Presigned URL do S3 Funciona Uma Presigned URL não é um token separado — ela é a própria requisição HTTP pré-assinada. O SDK pega ...

Obtendo o Instance ID via Metadados do EC2: Por que IMDSv2 é Mais Seguro que V1

Você está escrevendo um script de inicialização ou uma rotina de automação que precisa saber em qual instância EC2 está rodando — e a pergunta natural é: como obter o Instance ID de dentro da própria máquina, sem depender de variáveis de ambiente ou arquivos de configuração externos? A resposta está no Instance Metadata Service (IMDS), mas a forma como você o acessa faz toda a diferença do ponto de vista de segurança. TL;DR — Resumo Rápido Aspecto IMDSv1 IMDSv2 Autenticação Nenhuma — requisição direta Token de sessão obrigatório Vulnerabilidade SSRF Exposta Mitigada pelo token Método HTTP GET simples PUT para obter token, depois GET Recomendação AWS Legado — evitar Padrão recomendado Configuração necessária Nenhuma Nenhuma (habilitado por padrão em novas instâncias) Como o Instance Metadata Service Funciona O IMDS é um endpoint HTTP local disponível em http://169.254.169.254 — um endereço lin...