Caso de estudio · Cloud Security
Arquitectura de datos segura en la nube para una empresa de productos digitales
Diseñé de punta a punta la migración a AWS de una empresa con datos dispersos, sistemas aislados y demanda creciente: arquitectura, seguridad de red, gestión de riesgos, auditoría, DevSecOps y privacidad de datos.
- Rol: Cloud Architect
- AWS
- Seguridad por diseño
- Ley 25.326 · GDPR
Proyecto académico · Tecnicatura Superior en Seguridad Informática (TECLAB) · 2026
01 · Contexto
El problema
La empresa (caso Tech Consulting) generaba mucha información pero no podía aprovecharla ni protegerla. El diagnóstico inicial detectó cinco problemas concretos:
P1
Excel como fuente de datos
Cada persona calculaba sus métricas con criterios propios. No existía una única versión de la verdad.
P2
3 bases SQL Server aisladas
Sistemas transaccionales on-premise, sin integración ni recuperación ante desastres.
P3
Eventos en tiempo real perdidos
Los microservicios generaban datos de uso que nadie capturaba.
P4
Datos fuera de todo sistema
Listados de tiendas y categorías sin dueño ni control de versiones.
P5
Sin escalabilidad
Infraestructura fija frente a una demanda creciente de productos digitales.
02 · Diseño
La solución
Propuse una arquitectura en AWS organizada en capas con responsabilidades separadas, con alta disponibilidad en dos zonas y la seguridad integrada desde la primera fase.
Decisión
PaaS gestionado antes que servidores propios
RDS, Glue, Kinesis y Fargate trasladan parches, backups y alta disponibilidad al proveedor, y el equipo se concentra en los datos.
Decisión
Replatform para SQL Server, refactor para analítica
Los 3 sistemas se migran a RDS sin reescribirlos; los datos analíticos se rediseñan como data lake por zonas.
Decisión
Red en 3 capas con grupos de seguridad encadenados
Solo el balanceador queda expuesto a Internet. Cada capa acepta tráfico únicamente de la anterior.
Decisión
Seguridad antes que datos
La fase de fundaciones (IAM, MFA, cifrado, auditoría) va antes de mover un solo registro.
03 · Riesgos
Gestión de riesgos y auditoría
Evalué 10 riesgos con la fórmula Riesgo = Probabilidad × Impacto y definí una estrategia para cada uno. Los riesgos altos estaban todos del lado del cliente en el modelo de responsabilidad compartida.
| Riesgo | Nivel | Control principal |
|---|---|---|
| Configuración incorrecta que expone datos | alto | Infraestructura como código revisada + AWS Config + Security Hub |
| Credenciales comprometidas | alto | MFA, mínimo privilegio, roles temporales, GuardDuty |
| Ransomware | alto | Backups inmutables en cuenta separada + pruebas de restauración |
| Imagen de contenedor vulnerable | alto | Escaneo en el pipeline y en ECR |
| Punto único de fallo | medio | Redundancia Multi-AZ en todas las capas |
Auditoría
Plan de 5 tipos
Web, código fuente, redes, infraestructura y forense, con herramientas y frecuencia definidas.
Registros
Logs inmutables
CloudTrail, Flow Logs y auditoría de SQL Server en una cuenta aislada con Object Lock.
Monitoreo
Activo + pasivo
Alarmas en tiempo real y análisis periódicos para detectar amenazas internas y externas.
04 · Automatización
Pipeline DevSecOps
Diseñé un circuito de entrega continua con controles de seguridad automáticos en cada cambio, contenedores versionados e infraestructura inmutable.
1–2
Código y build
Revisión entre pares y build de la imagen Docker desde una base aprobada.
3–4
Pruebas y escaneo
Tests, análisis estático, dependencias, secretos e imágenes.
5–6
Staging y aprobación
Entorno idéntico a producción y aprobación humana registrada.
7–8
Producción y operación
Despliegue blue/green con rollback automático y monitoreo continuo.
05 · Datos personales
Privacidad y gobierno de datos
Política de privacidad (14 cláusulas)
Alineada con la Ley 25.326 y buenas prácticas del GDPR: finalidades, derechos de los titulares, transferencias internacionales y notificación de brechas en 72 h.
Rol de DPO y matriz RACI
Funciones del Data Protection Officer y responsabilidades repartidas entre DPO, CIO, CSO, CDIO, CTO y Cloud Architect.
DLP en 3 niveles
Prevención de fuga de datos en red, almacenamiento (Amazon Macie) y estaciones de trabajo.
Amenazas insider y outsider
Escenarios de ataque interno y externo durante la migración, con controles para cada uno.
06 · Entregables
Resultados del diseño
63
páginas en el plan integrado (4 documentos técnicos)
10
riesgos evaluados con matriz y plan de tratamiento
5
fases de migración en un cronograma de 9 meses
3 × 2
capas de red × zonas de disponibilidad
Qué aprendí
- Migrar a la nube no traslada la responsabilidad sobre los datos: identidades, configuración y datos siempre son del cliente.
- La seguridad funciona mejor como fase inicial del proyecto que como revisión final.
- Automatizar controles en el pipeline reduce más riesgos que cualquier revisión manual.
- El problema de fondo suele ser de gobierno de datos, no de tecnología.
07 · Herramientas
Stack y conceptos aplicados
Servicios de AWS
- Amazon VPC
- EC2 / Auto Scaling
- ECS Fargate
- RDS SQL Server
- S3 Data Lake
- AWS DMS
- Kinesis
- Glue · Redshift · Athena
- IAM · KMS
- CloudTrail · CloudWatch
- GuardDuty · Config · Security Hub
- Macie
Conceptos y marcos
- Tríada CIA
- Responsabilidad compartida
- RBAC · MFA
- Modelado de amenazas
- Matriz de riesgos
- Well-Architected Framework
- Docker · Kubernetes
- CI/CD · DevSecOps
- Infraestructura inmutable
- DLP
- Ley 25.326 · GDPR
08 · Documentación
Documentos completos
Plan completo · PDF · 63 páginas
Proyecto integrador: plan de migración segura a la nube
Las cuatro partes en un único documento, con resumen ejecutivo, conclusión y referencias.
Parte 1 · PDF · 17 págs.
Problemática y plan de migración
Diagnóstico, objetivos y arquitectura objetivo
Parte 2 · PDF · 17 págs.
Infraestructura y monitoreo
VPC, cómputo, almacenamiento y bases de datos
Parte 3 · PDF · 16 págs.
Riesgos, auditoría y DevOps
Matriz de riesgos, auditoría y pipeline
Parte 4 · PDF · 17 págs.
Privacidad, DPO y ataques
Política de privacidad, DLP y cronograma
“En la nube, la seguridad es compartida, pero la responsabilidad sobre los datos personales nunca se delega.”