En cualquier pipeline de datos, siempre surgen dos preguntas fundamentales: "¿Quién está intentando acceder a esto?" y "¿Qué se le permite hacer?" Estas son las dos bases de la seguridad en la nube: autenticación y autorización. Imagínalo como la entrada a un edificio de oficinas seguro: pasar tu tarjeta en la puerta es autenticación (demuestras quién eres), y el hecho de que tu tarjeta solo abra ciertas puertas es autorización (define lo que puedes acceder). En la ingeniería de datos con AWS, dominar estos conceptos es fundamental para el examen DEA-C01.
Autenticación — Demostrando tu Identidad
En los pipelines de datos, los servicios necesitan autenticarse entre sí constantemente. Glue necesita leer desde S3. Lambda necesita escribir en DynamoDB. EMR necesita procesar archivos en S3. Nada de esto puede ocurrir sin verificación de identidad. Y en la mayoría de los casos, no es una persona quien inicia sesión — es un servicio de AWS que prueba su identidad ante otro servicio.
Roles IAM — El Sistema de Delegación para Servicios
IAM (Identity and Access Management) es el sistema de identidad central de AWS. Mientras los usuarios IAM son cuentas para que las personas accedan a la consola, los roles IAM son identidades temporales que los servicios de AWS toman prestadas para actuar en tu nombre. Piensa en un rol como una carta de autorización firmada: "Este trabajo de Glue está autorizado a acceder al bucket S3 X en nombre de nuestro equipo."
Cuando un trabajo ETL de Glue comienza, asume un rol IAM. Ese rol declara "tengo permiso para leer de S3, escribir logs en CloudWatch y acceder al Catálogo de Datos de Glue." Sin el rol, Glue no puede hacer absolutamente nada — AWS deniega todo acceso por defecto.
Patrones comunes de roles IAM en ingeniería de datos:
| Escenario | Tipo de Rol | Propósito | |-----------|------------|-----------| | ETL de Glue lee/escribe S3 | Rol de servicio de Glue | Glue asume este rol para acceder a S3 y al Catálogo Glue | | Lambda escribe en DynamoDB | Rol de ejecución de Lambda | Lambda lo usa para interactuar con DynamoDB | | EMR procesa datos desde S3 | Perfil de instancia EC2 | Adjuntado a cada nodo EC2 en el clúster | | Step Functions llama a Lambda y Glue | Rol de ejecución de Step Functions | El orquestador necesita permiso para activar servicios hijos |
La conclusión más importante: cada interacción servicio-a-servicio en AWS requiere un rol IAM. Si un pipeline falla con "Access Denied," lo primero que hay que investigar es si el rol IAM existe, está adjuntado correctamente y tiene los permisos adecuados.
Seguridad de Red VPC — Controlando por Qué Caminos Viajan los Datos
La autenticación responde "¿quién eres?", pero la seguridad de red responde "¿por qué camino debes llegar?". Un VPC (Virtual Private Cloud) es tu propia red privada dentro de AWS — un espacio aislado, separado de internet.
Por defecto, cuando una instancia EC2 o una función Lambda habla con S3, ese tráfico viaja por internet y regresa. Esto expone tu transferencia de datos y genera costos de transferencia. Los VPC Endpoints corrigen esto enrutando el tráfico completamente por la red interna de AWS.
Dos tipos de VPC endpoints son fundamentales en ingeniería de datos:
Los Gateway Endpoints son gratuitos y sirven para S3 y DynamoDB. Agregas una entrada de ruta en tu tabla de rutas, y todo el tráfico hacia S3 o DynamoDB desde esa VPC fluye automáticamente por la red interna de AWS.
Los Interface Endpoints (PrivateLink) funcionan para la mayoría de los servicios: Glue, KMS, Secrets Manager, Kinesis, SQS y más. Provisionan una dirección IP privada dentro de tu VPC que se conecta directamente al servicio de AWS. Hay un pequeño costo por hora, pero el beneficio de seguridad es significativo.
Los Security Groups actúan como firewalls virtuales alrededor de recursos de cómputo como EC2, clústeres EMR y clústeres Redshift. Para un clúster Redshift, una configuración típica permite solo el puerto 5439 entrante desde el CIDR de la VPC del equipo de análisis, y solo saliente hacia el VPC endpoint de S3.
AWS PrivateLink extiende este concepto a escenarios entre cuentas. Si tu plataforma de datos necesita exponer un servicio a una cuenta consumidora, PrivateLink crea un enlace privado entre ellas sin internet, sin VPN, sin exposición.
Gestión de Credenciales — Nunca Pongas Contraseñas en tu Código
Los pipelines de datos frecuentemente necesitan conectarse a bases de datos externas, APIs de terceros o sistemas locales. Hardcodear estas credenciales en el código fuente es un grave error de seguridad — terminan en el historial de Git, en archivos de log, o en imágenes de contenedores.
AWS Secrets Manager es la solución correcta para credenciales sensibles que necesitan rotarse regularmente. Su característica más importante es la rotación automática. Supón que tu política de seguridad exige que todas las contraseñas de bases de datos cambien cada 90 días. Secrets Manager lo maneja completamente solo: invoca una función Lambda que cambia la contraseña en la base de datos (RDS, Redshift, DocumentDB), actualiza el secreto almacenado, y tu pipeline recupera automáticamente las credenciales actualizadas la próxima vez que se conecta.
AWS Systems Manager Parameter Store es una alternativa más ligera para configuraciones que no necesitan rotación automática. Almacena tanto valores en texto plano como valores cifrados usando el tipo SecureString, respaldado por KMS.
| Característica | Secrets Manager | Parameter Store | |--------------|----------------|----------------| | Rotación automática | Sí, vía integración con Lambda | No | | Costo | $0.40 por secreto al mes | Gratis para parámetros estándar | | Mejor caso de uso | Contraseñas de BD, claves API | Config de apps, variables de entorno | | Acceso entre cuentas | Sí | Sí |
!Autenticación vs autorización
Autorización — Decidiendo Qué Tienes Permitido Hacer
Una vez confirmada la identidad, la autorización determina qué acciones puede realizar esa identidad. AWS implementa la autorización mediante políticas IAM y controles de acceso específicos de cada servicio.
Políticas IAM — Las Reglas Escritas de los Permisos
Una política IAM es un documento JSON que declara explícitamente "permitir o denegar estas acciones en estos recursos." Las políticas se adjuntan a roles, usuarios o grupos.
Tres patrones de políticas aparecen constantemente en ingeniería de datos:
Las políticas de rol de servicio se adjuntan a los roles IAM que los servicios asumen. Una política de rol de servicio de Glue típicamente concede s3:GetObject y s3:PutObject en buckets S3 específicos, acceso de escritura a CloudWatch Logs, y lectura del Catálogo de Datos de Glue.
Las políticas de recursos se adjuntan directamente a un recurso en lugar de a una identidad. Una política de bucket S3 puede decir "este bucket solo permite lecturas desde el ARN de rol X" o "permite acceso desde la cuenta AWS 123456789012." Las políticas de recursos son críticas para el acceso entre cuentas.
El principio de mínimo privilegio es la práctica de seguridad más importante: otorgar solo los permisos absolutamente necesarios, con el alcance más estrecho posible. En lugar de conceder s3:GetObject en todos los buckets, limítalo al bucket y prefijo específicos que el trabajo realmente necesita.
Permisos de Lake Formation — Control de Acceso Granular para el Data Lake
AWS Lake Formation proporciona gobernanza centralizada para tu data lake. Se sitúa sobre S3 y el Catálogo de Datos de Glue y agrega control de acceso a nivel de columna, fila y tabla — cosas que las políticas IAM simples no pueden hacer.
Antes de Lake Formation, controlar el acceso a tablas del data lake era complejo: había que configurar por separado las políticas IAM, las políticas de bucket S3 y las políticas de recursos del Catálogo Glue. Una inconsistencia entre ellas y un usuario podría acceder a datos que no debería. Lake Formation consolida todo esto en un único modelo de permisos.
Niveles de permisos que Lake Formation soporta:
Nivel de base de datos: otorgar a un equipo acceso a todas las tablas dentro de una base de datos Glue específica Nivel de tabla: restringir a un usuario solo a tablas específicas Nivel de columna: ocultar columnas sensibles como credit_card_number o ssn Nivel de fila: usar filtros de datos para mostrar solo filas que cumplan una condición — por ejemplo, un equipo regional solo ve filas donde region = 'us-west'
RBAC (Control de Acceso Basado en Roles) otorga permisos según el rol organizacional de una persona. Defines roles como "analista de datos" o "ingeniero de datos" y les adjuntas permisos. Cuando llega un nuevo empleado, le asignas el rol apropiado y hereda automáticamente todos sus permisos.
TBAC (Control de Acceso Basado en Etiquetas) usa etiquetas de metadatos para hacer coincidir recursos con usuarios automáticamente. Etiquetas una tabla con sensitivity=high y etiquetas a un usuario con clearance=high. Lake Formation ve las etiquetas coincidentes y concede acceso sin necesidad de escribir entradas de permisos individuales para cada combinación tabla-usuario. Con cientos de tablas y docenas de equipos, TBAC reduce drásticamente el trabajo de gestión.
Control de Acceso en Redshift — La Capa de Seguridad del Data Warehouse
Redshift opera su propio sistema de control de acceso interno además de IAM.
Los usuarios y grupos de Redshift funcionan de manera similar a PostgreSQL. Dentro de la base de datos, creas usuarios, los asignas a grupos y usas sentencias SQL GRANT para dar a los grupos privilegios SELECT, INSERT o UPDATE en esquemas o tablas específicas.
Redshift Data Sharing permite que un clúster Redshift (productor) comparta datos en tiempo real con otro clúster o cuenta de AWS (consumidor) sin copiar los datos. El consumidor tiene acceso de solo lectura. Esta es la arquitectura preferida para separar el data warehouse de producción de las cargas de trabajo analíticas.
Cuando se usa Redshift Spectru