Entradas

Mostrando las entradas etiquetadas como Seguridad

Grupos IAM en AWS: Por Qué Nunca Deberías Adjuntar Políticas Directamente a Usuarios

Cuando el equipo crece de dos a veinte ingenieros, adjuntar políticas directamente a cada usuario de IAM deja de ser un problema de estilo y se convierte en un problema operacional real: permisos inconsistentes, auditorías imposibles y el clásico 'ese usuario tiene acceso a producción pero no sé por qué'. Los grupos de IAM existen precisamente para evitar ese caos. TL;DR: Grupos IAM vs. Políticas Directas en Usuarios Criterio Política directa en usuario Política en grupo IAM Escalabilidad Cada usuario requiere gestión individual Un cambio en el grupo afecta a todos los miembros Consistencia de permisos Alta probabilidad de desviación entre usuarios Permisos uniformes garantizados por diseño Auditoría Requiere revisar cada usuario individualmente Un solo punto de revisión por rol Onboardi...

AWS KMS: ¿Clave Administrada por AWS o CMK para Cifrar tu Bucket S3?

Cuando configuras cifrado en un bucket S3 por primera vez, la pantalla de la consola te presenta opciones que parecen equivalentes pero tienen implicaciones operativas y de costos muy distintas. Elegir entre una clave administrada por AWS y una clave administrada por el cliente (CMK) no es solo una decisión de seguridad — define quién controla el acceso, quién paga por cada operación criptográfica, y qué tan rápido puedes revocar acceso en una emergencia. TL;DR: AWS Managed Key vs. CMK para S3 Dimensión AWS Managed Key (aws/s3) Customer Managed Key (CMK) Creación y rotación Automática, gestionada por AWS Manual o programada, controlada por ti Política de clave No editable Totalmente configurable Costo por API call Sin cargo directo para S3 SSE-KMS Cargo por cada llamada a la API de KMS Auditoría ...

¿Por qué usar Secrets Manager en lugar de hardcodear credenciales?

El repositorio es privado, el equipo es pequeño, la fecha de entrega es mañana — y la contraseña de la base de datos termina incrustada directamente en el código fuente. Es una decisión que se toma en segundos y que puede costar semanas de trabajo de remediación cuando ese repositorio se clona en un entorno de CI, se expone en un log de error, o simplemente un ex-colaborador conserva acceso al historial de Git. AWS Secrets Manager existe precisamente para eliminar esta clase de deuda de seguridad antes de que se convierta en un incidente. TL;DR — Secrets Manager vs. credenciales hardcodeadas Dimensión Credencial hardcodeada AWS Secrets Manager Exposición en repositorio Permanente en historial de Git El código nunca contiene la credencial Rotación de contraseña Manual, propensa a omisión Automática vía Lambda integrada Auditorí...

Cómo Encontrar Quién Eliminó un Recurso en AWS con CloudTrail

Una instancia EC2 desaparece en producción y nadie admite haberla terminado. Antes de escalar el incidente o revisar manualmente cada cuenta IAM, CloudTrail ya registró exactamente quién ejecutó TerminateInstances , desde qué IP y con qué credenciales. El problema no es que la información no exista — es saber dónde buscarla y cómo interpretarla correctamente. TL;DR — Resumen Rápido Paso Acción Resultado esperado 1 Abrir CloudTrail Event History en la consola Vista de eventos de los últimos 90 días 2 Filtrar por nombre de evento: TerminateInstances Lista de eventos de terminación 3 Filtrar por ID de recurso o rango de tiempo Evento específico de la instancia eliminada 4 Inspeccionar el campo userIdentity del evento Usuario IAM, rol asumido, o cuenta raíz responsable 5 Verificar sourceIPAddress y userAgent Contexto adicional del origen de la acción Cómo Funciona CloudTrail Event History CloudT...

Estructura básica de una política IAM: Effect, Action, Resource y Condition explicados

La primera vez que abres una política IAM en JSON y ves cuatro claves que controlan todo el acceso a tu infraestructura, la tentación es asumir que son intercambiables o que alguna tiene prioridad implícita sobre otra. No es así. Cada elemento resuelve una pregunta distinta, y entender exactamente qué pregunta responde cada uno es lo que separa una política que funciona de una que abre brechas silenciosas. TL;DR — Estructura básica de una política IAM Elemento Pregunta que responde Obligatorio Effect ¿Se permite o se deniega? Sí Action ¿Qué operación de API? Sí Resource ¿Sobre qué recurso específico? Sí (en la mayoría de tipos de política) Condition ¿Bajo qué circunstancias adicionales? No Cómo evalúa AWS una política IAM Antes de diseccionar cada elemento, es importante entender el modelo de evaluación. AWS no lee una política IAM como un programa secuencial. Cuando una entidad (usuario, rol, serv...