Tema 3
Una arquitectura cloud segura no empieza con servidores ni aplicaciones, sino con una base organizada: cuentas o proyectos separados, redes controladas, registros centralizados, políticas preventivas y una estructura preparada para crecer sin perder gobierno.
Cloud permite crear recursos rápidamente, pero esa velocidad puede volverse un problema si no existe una arquitectura base. Sin organización, aparecen cuentas mezcladas, permisos excesivos, redes improvisadas, datos sin clasificación, logs incompletos y ambientes productivos expuestos por decisiones tomadas con urgencia.
La arquitectura segura busca establecer una estructura inicial que permita desplegar aplicaciones con controles consistentes. Esa estructura debe separar responsabilidades, limitar impactos, facilitar auditoría y permitir que los equipos trabajen sin tener que reinventar criterios de seguridad en cada proyecto.
En este tema veremos cómo ordenar cuentas o proyectos, ambientes, regiones, redes, logging, políticas y guardrails para construir una base cloud confiable.
Una arquitectura cloud segura es un diseño que define cómo se organizan y protegen los recursos antes de que las aplicaciones entren en producción. No se limita a diagramas de red: incluye identidad, gobierno, separación de ambientes, políticas, monitoreo, cifrado, costos, operación y respuesta.
Sus objetivos principales son:
Los proveedores cloud utilizan distintos nombres para organizar recursos: cuentas, suscripciones, proyectos, carpetas u organizaciones. Aunque el nombre cambie, el propósito es similar: crear límites administrativos, financieros y de seguridad.
Usar una sola cuenta para todo suele ser un error. Mezclar desarrollo, pruebas, producción, seguridad y administración en el mismo contenedor lógico aumenta el riesgo de cambios accidentales, permisos excesivos y baja trazabilidad.
| Elemento | Función | Riesgo si se diseña mal |
|---|---|---|
| Organización raíz | Agrupa cuentas, políticas globales y facturación | Permisos centrales demasiado amplios o sin auditoría |
| Cuenta o proyecto | Aísla recursos, identidades, cuotas y costos | Ambientes mezclados y dificultad para contener incidentes |
| Carpeta o unidad organizativa | Agrupa cuentas por función, equipo o criticidad | Políticas inconsistentes o herencia de permisos incorrecta |
| Etiquetas | Identifican dueño, ambiente, aplicación, costo y criticidad | Inventario incompleto y baja responsabilidad operativa |
Separar ambientes es una de las decisiones más importantes. Desarrollo, pruebas, staging y producción no deberían compartir el mismo nivel de permisos, datos ni exposición.
La separación puede hacerse por cuentas, proyectos, redes, namespaces, clusters o combinaciones de estos mecanismos. Para cargas críticas, separar por cuenta o proyecto suele ofrecer un límite más fuerte que separar solo por etiquetas o nombres.
Una landing zone es una base cloud preparada para alojar workloads de manera segura y gobernada. Define estructura organizativa, redes, identidades, logging, políticas, monitoreo, conectividad, seguridad y criterios de operación.
Una landing zone suele incluir:
En arquitecturas maduras se usan cuentas o proyectos especializados para separar funciones críticas. Esta separación mejora la contención y permite aplicar permisos más precisos.
| Cuenta o proyecto | Propósito | Control principal |
|---|---|---|
| Seguridad | Centralizar alertas, herramientas de detección y respuesta | Acceso restringido y registros protegidos |
| Logging | Recibir logs de auditoría, red y actividad administrativa | Retención, inmutabilidad y separación del entorno observado |
| Red compartida | Gestionar conectividad común, DNS, enlaces privados y egreso | Cambios revisados y segmentación explícita |
| Producción | Ejecutar workloads críticos | Permisos mínimos, cambios controlados y monitoreo fuerte |
| Sandbox | Permitir experimentación limitada | Cuotas, bloqueo de datos sensibles y limpieza automática |
La elección de regiones no es solo técnica. Afecta latencia, disponibilidad, costo, cumplimiento, residencia de datos y estrategia de recuperación. Una arquitectura segura define dónde se pueden desplegar recursos y bajo qué condiciones.
Una política de arquitectura debería bloquear o alertar despliegues en regiones no aprobadas para evitar incumplimientos y dispersión operativa.
La red cloud debe diseñarse con segmentación, rutas controladas y exposición pública mínima. Aunque cloud abstrae parte de la infraestructura, las decisiones de subredes, gateways, firewalls, DNS, peering y conectividad privada siguen siendo críticas.
Buenas prácticas iniciales:
Los guardrails son límites preventivos o detectivos que ayudan a mantener la postura de seguridad. No reemplazan el criterio técnico, pero reducen errores comunes y evitan configuraciones de alto riesgo.
| Guardrail | Tipo | Ejemplo |
|---|---|---|
| Bloqueo de regiones no aprobadas | Preventivo | Impedir creación de recursos fuera de regiones autorizadas |
| Prohibición de almacenamiento público | Preventivo | Denegar buckets públicos salvo excepción aprobada |
| Detección de puertos administrativos abiertos | Detectivo | Alertar reglas con SSH o RDP expuestos a internet |
| Etiquetado obligatorio | Preventivo o detectivo | Exigir dueño, ambiente, aplicación y criticidad |
| Cifrado requerido | Preventivo | Bloquear discos, bases o colas sin cifrado habilitado |
Una arquitectura segura debe registrar actividad administrativa y eventos relevantes desde el inicio. Si los logs se configuran después de un incidente, ya es tarde para reconstruir lo ocurrido.
El logging centralizado debe considerar:
La arquitectura inicial debe definir cómo se autentican los usuarios, cómo se asignan roles y cómo se accede a funciones administrativas. El uso de cuentas locales permanentes y credenciales estáticas debe reducirse al mínimo.
La arquitectura segura debe poder repetirse. Si cada cuenta o proyecto se configura manualmente, la consistencia se pierde rápido. Infraestructura como código permite versionar, revisar y aplicar la base de manera controlada.
Esto aporta:
La automatización debe tener permisos acotados. Un pipeline que crea infraestructura no debería tener privilegios ilimitados si solo necesita gestionar recursos específicos.
Una organización pequeña o mediana podría iniciar con una estructura simple pero segura:
El diseño exacto depende del tamaño, regulación, equipos y criticidad, pero el principio es el mismo: separar lo que tiene distinto riesgo, dueño o ciclo de vida.
Una arquitectura cloud segura no aparece por accidente. Requiere decisiones explícitas sobre separación, regiones, redes, logging, identidad, automatización y políticas. Estas decisiones forman la base sobre la que luego se despliegan aplicaciones, contenedores, clusters y pipelines.
En el próximo tema estudiaremos la gestión de identidades y accesos: IAM, MFA, roles, políticas y privilegio mínimo.