Seguridad en Data Engineering
Proteger los datos de tu empresa y los de tus usuarios no es opcional. Una sola brecha puede costar millones y destruir la reputación corporativa. Este capítulo cubre las prácticas de seguridad de un verdadero Data Engineer Senior.
IAM y Control de Acceso (RBAC)
El manejo de identidad y acceso (IAM - Identity and Access Management) asegura que solo quien necesita acceso lo obtenga (Principio de Menor Privilegio).
- RBAC (Role-Based Access Control): Los permisos se asignan a "Roles" (ej.
DataAnalyst,DataEngineer), no a usuarios individuales. Los usuarios asumen roles. - ABAC (Attribute-Based Access Control): Controles dinámicos. Ej: "Solo puedes leer datos si el atributo
departmentde tu perfil coincide con el del dataset."
Otorga a las cuentas (y a las máquinas/servicios) solo el acceso exacto que necesitan para hacer su trabajo. Nunca uses AdministratorAccess o el superusuario de la base de datos en aplicaciones.
Manejo de Secretos
Nunca, jamás, pongas contraseñas, tokens de API o claves SSH directamente en el código o en Git.
# ❌ MAL: Secretos en código (Será encontrado por hackers en segundos)
db_password = "SuperSecretPassword123"
# ✅ BIEN: Usar variables de entorno (al menos en desarrollo)
import os
db_password = os.environ.get("DB_PASSWORD")
# 🚀 EXCELENTE: Usar un Secret Manager (AWS Secrets Manager, HashiCorp Vault)
import boto3
import json
def get_db_credentials():
client = boto3.client('secretsmanager')
response = client.get_secret_value(SecretId='prod/db/credentials')
return json.loads(response['SecretString'])
Cifrado (Encryption)
Los datos deben estar cifrados en dos estados principales:
- En tránsito (In Transit): Cuando viajan por la red. Usa siempre
TLS/SSL(HTTPS, conexiones de base de datos seguras). - En reposo (At Rest): Cuando están guardados en discos o S3. Cloud providers suelen hacerlo por defecto (ej. SSE-S3 o SSE-KMS en AWS), pero asegúrate de que esté habilitado.
Datos PII y Enmascaramiento
PII (Personally Identifiable Information) incluye nombres, correos, SSN, tarjetas de crédito. Se debe evitar ingresar PII al Data Lake a menos que sea estrictamente necesario. Si es necesario, se debe ofuscar o aplicar hashing criptográfico unidireccional (ej. SHA-256 con un salt).
Data Masking en Snowflake (Ejemplo)
-- 1. Crear una política de enmascaramiento
CREATE OR REPLACE MASKING POLICY email_mask AS (val string) RETURNS string ->
CASE
WHEN current_role() IN ('HR_ADMIN', 'DATA_ENGINEER') THEN val
ELSE '***@***.com'
END;
-- 2. Aplicar la política a la columna
ALTER TABLE employees MODIFY COLUMN email SET MASKING POLICY email_mask;
-- Si entra un Data Analyst, verá: "***@***.com"
Compliance y Regulaciones
| Regulación | Región / Industria | Puntos Clave para DEs |
|---|---|---|
| GDPR | Unión Europea | Derecho al olvido (borrar a un usuario debe borrar sus datos en todo el Data Lake). Privacidad por diseño. |
| CCPA | California, EE. UU. | Derecho a optar por no participar en la venta de datos personales. Similar a GDPR. |
| HIPAA | Salud, EE. UU. | Protección estricta de PHI (Protected Health Information). Auditorías rigurosas de accesos. |
| PCI-DSS | Finanzas (Tarjetas) | Nunca almacenar CVV. Números de tarjeta fuertemente cifrados, accesos ultrarrestringidos. |