A restrición adoita ser a visibilidade, non a sofisticación do atacante
Cando se investiga tarde un incidente en AWS, o debate adoita centrarse en canto de avanzada foi a intrusión. En moitos entornos a restrición real é máis simple: non hai telemetría dabondo para reconstruír o que pasou.
CloudTrail, VPC Flow Logs e data events son imperfectos. Non revelan intención nin capturan payloads. O seu valor é preservar pezas independentes de evidencia que, xuntas, responden preguntas básicas: que identidade actuou, cando, desde onde, sobre que recurso e con que resultado.
Como desaparece o rastro
En entornos multi-conta, o volume de eventos medra rápido. Alguén revisa o custo de almacenamento, indexación ou SIEM e formula a pregunta inevitable: fai falta tanto logging?
As optimizacións chegan a anacos:
- os eventos de lectura desbótanse como «ruído»
- os Flow Logs limítanse a produción, ou só ao tráfico rexeitado
- os data events de S3 desactívanse polo volume
- a retención córtase a 30 ou 90 días
Cada decisión pode parecer razoable. Xuntas poden eliminar o contexto necesario para entender un compromiso.
O recoñecemento aínda é actividade
Despois de obter credenciais válidas, un atacante non necesariamente comeza borrando datos. Fai preguntas. Enumera. Mapea.
En termos de API de AWS iso son operacións lexítimas Get*, List* e Describe*. Para un equipo de produto poden parecer ruído. Para un atacante son un mapa.
Se a telemetría de lectura desaparece do pipeline de seguridade, unha acción posterior como un cambio de política aínda pode ser visible. O que se perde é o comezo da historia: os minutos de enumeración previos.
Tamén existe o patrón inverso: conservar lecturas e filtrar escrituras. A exploración permanece visible… e o momento en que cambian roles, trust policies ou security groups queda incompleto.
Lectura e escritura describen fases diferentes. Escoller só unha non é «visibilidade optimizada»; é cegueira asimétrica.
Que debería preservar unha arquitectura de logging útil
Unha postura sólida non é «rexistrar todo sen criterio». É definir sinais mínimos assequibles e útiles para forense e detección:
- eventos de management de CloudTrail con retención aliñada ao risco
- cobertura de contas e rexións relevantes, non só do entorno «principal»
- Flow Logs onde o contexto de rede importa
- data events selectivos sobre recursos de alto valor
- un camiño claro desde o almacenamento de logs ata quen investiga
O obxectivo non é un museo de eventos. É a capacidade de responder preguntas de seguridade e de negocio con evidencia cando importa.
Como conecta co traballo de TechRebel
En engagements de seguridade AWS e observabilidade partimos dunha premisa simple: a visibilidade é unha decisión de arquitectura, non un extra opcional. Avaliamos que se rexistra, que se retén e que aínda se pode reconstruír antes de falar de controis adicionais.
Para revisar a postura de logging e detección na súa organización AWS, agende unha reunión ou consulte AWS & Cloud Security.