Cloud Best Practices
Resumen
Esta guía de estudio independiente reúne prácticas de arquitectura, seguridad y gobernanza para operar en la nube, en el contexto de la certificación LFCA. No está afiliada ni avalada por la Linux Foundation ni por ningún proveedor. Las recomendaciones se presentan como criterios para tomar decisiones, no como una lista de productos. Los marcos de AWS, Microsoft Azure, Google Cloud y NIST se citan como referencias de industria.
Una buena práctica no es una regla universal. Es una decisión que reduce un riesgo conocido y que debe justificarse en su contexto. Aplicar controles sin entender el coste operativo produce burocracia; ignorarlos produce incidentes. El objetivo es equilibrar seguridad, fiabilidad, coste y velocidad de entrega.
Objetivos de aprendizaje
Al terminar este tema deberías poder:
- Explicar cómo los marcos Well-Architected y NIST CSF organizan las decisiones de nube.
- Aplicar mínimo privilegio, aislamiento y cifrado como principios de seguridad.
- Diseñar controles de gobernanza y cumplimiento proporcionados al riesgo.
- Usar infraestructura como código y automatización para reducir errores manuales.
- Evaluar el coste y la sostenibilidad como parte de la arquitectura.
Prerrequisitos y conexiones
Requiere cloud-computing, en especial el modelo de responsabilidad compartida, y performance-availability para los conceptos de resiliencia y objetivos de servicio. Se complementa con budgeting para el control del gasto y con cloud-networking para segmentación y exposición. También se apoya en los fundamentos de administración de sistemas: cuentas, permisos, servicios, logs y actualizaciones.
Marcos de referencia
Los marcos de arquitectura organizan las decisiones en pilares. El AWS Well-Architected Framework agrupa excelencia operativa, seguridad, fiabilidad, eficiencia de rendimiento, optimización de costes y sostenibilidad. Google Cloud Architecture Framework y Azure Well-Architected proponen estructuras equivalentes con matices propios. No son certificaciones ni recetas; son lentes para revisar un diseño.
El NIST Cybersecurity Framework, por su parte, organiza la gestión de ciberseguridad en funciones como identificar, proteger, detectar, responder y recuperar. Es útil porque conecta la seguridad técnica con la gobernanza y la respuesta a incidentes. Un diseño cloud maduro combina ambas perspectivas: pilares de arquitectura para construir y funciones de seguridad para operar.
Los marcos ayudan a formular preguntas. ¿Qué pasa si falla esta zona? ¿Quién puede leer este dato? ¿Cómo detectamos un acceso anómalo? ¿Cuánto cuesta mantener esta redundancia? La revisión debe hacerse antes del despliegue y repetirse cuando cambia el sistema.
Seguridad y control de acceso
El mínimo privilegio es el principio central: cada identidad recibe solo los permisos necesarios para su tarea y durante el tiempo necesario. En la práctica implica evitar credenciales de largo plazo, separar roles humanos y de servicio, y revisar permisos periódicamente. Una cuenta con permisos amplios compartida por todo el equipo elimina la trazabilidad y amplifica cualquier error.
La autenticación multifactor debe cubrir las cuentas administrativas y, cuando sea posible, el acceso de los usuarios. La federación de identidad con el directorio corporativo reduce cuentas locales y facilita la baja de empleados. La autorización debe basarse en roles o atributos, no en listas manuales que se desactualizan.
El aislamiento separa entornos y cargas mediante cuentas, suscripciones, proyectos, redes y políticas. Producción no debería compartir credenciales ni redes abiertas con desarrollo. La segmentación de red limita el movimiento lateral; los grupos de seguridad y las políticas de red deben permitir solo el tráfico necesario.
El cifrado protege datos en tránsito y en reposo. En tránsito se usa TLS correctamente configurado; en reposo, cifrado con claves gestionadas por el proveedor o por el cliente según el requisito. La gestión de claves y secretos debe ser centralizada, con rotación y auditoría. Cifrar sin controlar quién puede descifrar no resuelve el problema.
Gobernanza y cumplimiento
La gobernanza define quién puede hacer qué, en qué condiciones y con qué evidencia. Se implementa con políticas, etiquetas, presupuestos, controles de identidad y registros de auditoría. El cumplimiento normativo añade requisitos externos, como protección de datos, retención o residencia de la información.
Un control debe ser proporcional al riesgo. Una organización pequeña no necesita el mismo aparato que una entidad regulada, pero ambas necesitan saber qué datos poseen, dónde están y quién accede. El inventario de datos y de recursos es la base de casi cualquier control.
Las políticas como código permiten evaluar configuraciones de forma automática y bloquear desviaciones antes de que lleguen a producción. El etiquetado obligatorio facilita coste, inventario y cumplimiento. Los registros de auditoría deben estar protegidos contra modificación y conservarse según la política aplicable.
El cumplimiento no se demuestra con una captura de pantalla. Se demuestra con evidencia reproducible: configuraciones versionadas, resultados de análisis, registros de acceso y procedimientos probados. La auditoría debe ser una consecuencia del diseño, no una reconstrucción de último momento.
Automatización e infraestructura como código
La infraestructura como código describe recursos en archivos versionados y los aplica mediante herramientas declarativas. Sus ventajas son reproducibilidad, revisión mediante pull requests y capacidad de reconstruir entornos. También reduce la deriva: si alguien cambia algo a mano, la diferencia se puede detectar y corregir.
La automatización debe cubrir el ciclo de vida: aprovisionamiento, configuración, despliegue y eliminación. Un entorno que se crea automáticamente pero se destruye a mano acumula recursos huérfanos y coste. Las pruebas de infraestructura y los análisis de seguridad en la tubería de CI/CD detectan errores antes del despliegue.
La automatización no elimina la necesidad de revisión. Un cambio automatizado mal diseñado se propaga más rápido. Por eso importan los controles de revisión, los límites de alcance y la capacidad de revertir. La trazabilidad del cambio es tan valiosa como la velocidad.
Operación, respuesta y mejora
La excelencia operativa incluye procedimientos documentados, runbooks, gestión de cambios y revisión de incidentes. Un incidente debe generar aprendizaje: qué falló, cómo se detectó, cuánto tardó la respuesta y qué se cambiará. La cultura de culpa inhibe el reporte y empeora la seguridad.
La observabilidad aporta métricas, logs y trazas para detectar y diagnosticar. Debe complementarse con alertas accionables y con una revisión periódica de su calidad. Un panel que nadie mira no es un control.
La respuesta a incidentes necesita roles, canales y criterios de escalado. En la nube, la capacidad de aislar una credencial comprometida o una instancia afectada es parte del diseño. También hay que ensayar la recuperación: restauración de copias, conmutación de región y comunicación con usuarios.
La sostenibilidad es un pilar emergente: eficiencia energética, uso de servicios gestionados y reducción de recursos ociosos. No se trata solo de imagen; el desperdicio de capacidad suele coincidir con desperdicio de dinero.
Identidades, secretos y acceso administrativo
El control de acceso empieza por inventariar identidades: personas, servicios, pipelines y cuentas de emergencia. Cada una debe tener un propietario y un propósito. Las cuentas humanas se agrupan en roles o grupos; las de servicio usan identidades dedicadas, nunca credenciales personales. La separación de funciones evita que una sola identidad pueda desplegar y aprobar el mismo cambio, y el registro de auditoría debe conservar quién hizo qué y cuándo.
Los secretos —claves de API, contraseñas de base de datos, certificados— no pertenecen al repositorio ni a la imagen del contenedor. Se guardan en un gestor de secretos, se inyectan en tiempo de ejecución y se rotan con un procedimiento probado. El cifrado con claves gestionadas por el proveedor reduce el trabajo operativo; el gestionado por el cliente añade control pero exige custodiar la clave y planificar su recuperación. En ambos casos, la pregunta decisiva es quién puede descifrar y cómo se audita ese acceso.
Las cuentas de emergencia deben ser pocas, con MFA, uso registrado y revisión posterior. Una cuenta de break-glass que nadie recuerda es un riesgo; una que se usa a diario deja de ser excepcional. Revisar permisos trimestralmente, retirar accesos al cambiar de rol y automatizar la baja reducen la acumulación de privilegios. El objetivo no es eliminar la excepción, sino que cada excepción tenga fecha, motivo y responsable.
Protección de datos y continuidad
Clasificar la información permite aplicar controles proporcionados: no todos los datos requieren el mismo cifrado, la misma retención ni la misma frecuencia de copia. Una clasificación útil incluye público, interno, confidencial y restringido, con reglas claras de etiquetado y de acceso. La residencia y la retención son requisitos de negocio y legales, no detalles de almacenamiento; deben decidirse antes de elegir la región o el servicio.
La continuidad se diseña con dos objetivos explícitos: el punto de recuperación aceptable (RPO), que mide cuántos datos se pueden perder, y el tiempo de recuperación aceptable (RTO), que mide cuánto puede tardar el servicio en volver. Las copias deben ser inmutables o estar aisladas de las credenciales de producción, porque un atacante con permisos amplios puede borrar también los respaldos. Una copia que nunca se ha restaurado es una hipótesis, no una garantía.
Probar la restauración completa —no solo la existencia del archivo— revela dependencias olvidadas: claves, configuraciones, DNS y permisos. La conmutación de región o de zona debe ensayarse con criterios de éxito medibles y con un responsable de la decisión. Después del ejercicio conviene registrar el tiempo real, los errores encontrados y las mejoras, de modo que el siguiente ensayo sea más corto y más fiable.
Diseño de red y superficie de exposición
La red es una frontera administrativa y una superficie de exposición. Separar cuentas, proyectos o suscripciones por entorno limita el alcance de un error; dentro de cada uno, las subredes agrupan cargas con requisitos parecidos. La exposición debe justificarse: un servicio público necesita una entrada controlada, no una instancia con dirección pública y puerto abierto. Los balanceadores, las puertas de enlace y los endpoints privados permiten publicar o consumir servicios sin repartir direcciones públicas.
El filtrado debe ser explícito en ambas direcciones. Las reglas de entrada protegen contra accesos no deseados; las de salida limitan la exfiltración y el movimiento lateral. Denegar por defecto y documentar cada excepción convierte la revisión de red en una tarea verificable. El registro de flujos y de rechazos aporta evidencia para investigar incidentes y para retirar reglas que ya no se usan.
La administración no debería compartir camino con el tráfico de aplicación. Un bastión, un acceso mediado o una VPN con MFA reducen la exposición de SSH y RDP. La verificación de identidad y dispositivo añade contexto antes de conceder acceso, y el principio de menor privilegio se aplica también a las reglas de red: una regla «temporal» sin fecha de caducidad suele quedarse para siempre.
Observabilidad, objetivos de servicio y alertas
La observabilidad se planifica a partir de preguntas: ¿el servicio está disponible?, ¿responde con latencia aceptable?, ¿procesa correctamente?, ¿cuánto se ha degradado? Los indicadores de nivel de servicio (SLI) responden a esas preguntas con datos; los objetivos (SLO) fijan el umbral; el presupuesto de error es la diferencia tolerada entre ambos. Sin objetivos, las alertas se vuelven ruido y las discusiones sobre prioridad carecen de criterio.
Métricas, logs y trazas cumplen funciones distintas. Las métricas son baratas de agregar y buenas para tendencias y umbrales; los logs explican eventos concretos; las trazas muestran el recorrido de una petición entre servicios. La cardinalidad descontrolada encarece las métricas y degrada su utilidad, así que conviene limitar etiquetas de alta variabilidad. El muestreo de trazas reduce coste, pero debe conservar los casos lentos o fallidos que interesan al diagnóstico.
Las alertas deben activarse por síntomas que afectan al usuario, no por cada causa posible. Una alerta sin acción asociada consume atención y entrena al equipo a ignorarla. Cada alerta relevante necesita un runbook con pasos de verificación, criterios de escalado y una forma de confirmar la recuperación. Revisar periódicamente qué alertas se dispararon, cuántas fueron útiles y cuánto tardó la respuesta convierte la observabilidad en un proceso de mejora.
Coste, capacidad y ciclo de vida
El coste es una consecuencia de las decisiones de arquitectura. Etiquetar recursos por aplicación, entorno y propietario permite atribuir gasto y detectar desviaciones; sin etiquetas, la factura se convierte en un total imposible de repartir. Los presupuestos y las alertas de gasto no sustituyen al diseño, pero avisan antes de que un error de configuración se convierta en una sorpresa mensual.
La capacidad debe ajustarse a la demanda real. El sobredimensionamiento permanente desperdicia dinero; el subdimensionamiento degrada el servicio y empuja al equipo a apagar incendios. Medir utilización y latencia antes de cambiar el tamaño evita decisiones basadas en impresiones. El escalado automático ayuda cuando la carga varía, pero necesita límites y pruebas: un escalado que reacciona tarde o que multiplica instancias sin control puede empeorar el incidente.
El ciclo de vida incluye almacenamiento, instantáneas y recursos ociosos. Las clases de almacenamiento de menor coste sirven para datos poco consultados, siempre que se conozca el tiempo de recuperación. Las instantáneas antiguas, las direcciones reservadas sin uso y los entornos de prueba olvidados acumulan gasto silencioso. Revisar la unidad de coste —por petición, por usuario o por transacción— ayuda a comparar alternativas y a evitar optimizaciones que ahorran en una partida y encarecen otra.
Resiliencia y despliegues seguros
La resiliencia se construye con redundancia, aislamiento de fallos y recuperación probada. Distribuir réplicas entre zonas evita que un fallo local detenga el servicio, pero solo si la aplicación no comparte un único punto de dependencia, como una base de datos con una sola zona o una cola sin réplica. Los dominios de fallo deben revisarse de extremo a extremo: cómputo, almacenamiento, red y servicios gestionados de los que depende la carga.
El despliegue también puede introducir fragilidad. Las estrategias por lotes, canario o azul-verde reducen el impacto de una versión defectuosa cuando incluyen métricas de salud y una reversión rápida. Un despliegue gradual sin observación solo retrasa la detección del error. La reversión debe probarse con la misma frecuencia que el despliegue, porque una versión anterior incompatible con el esquema de datos puede no ser una salida válida.
La capacidad de reserva tiene un coste y debe justificarse. Mantener duplicado todo el sistema en otra región puede ser necesario para ciertos requisitos, pero en otros casos basta con una copia de los datos y un procedimiento de reconstrucción. La decisión depende del RTO, del RPO y del coste de la interrupción, no de una preferencia estética por la redundancia.
La revisión de dependencias externas completa el análisis: proveedores de identidad, DNS, certificados y servicios de terceros pueden convertirse en un fallo común para varias zonas. Documentar esas dependencias y sus alternativas permite priorizar qué se prueba primero y qué se acepta como riesgo residual.
Los ensayos deben incluir la pérdida de una zona, no solo el fallo de una instancia. Simular la indisponibilidad de una dependencia compartida revela si la arquitectura realmente tolera el fallo o si solo lo aparenta. Los resultados se convierten en cambios concretos: réplicas adicionales, timeouts más realistas o una secuencia de recuperación distinta.
Ejemplos prácticos
Escenario 1. Un equipo comparte una clave de acceso con permisos de administrador. Se sustituye por roles federados con MFA, permisos mínimos y credenciales temporales. Las acciones quedan atribuidas a personas concretas y la rotación deja de depender de un archivo compartido.
Escenario 2. Producción y desarrollo comparten la misma red. Se separan en cuentas o proyectos distintos, con redes y políticas independientes. Un error en desarrollo deja de tener acceso directo a datos reales.
Escenario 3. La infraestructura se modifica por consola sin registro. Se migra a infraestructura como código, se revisan los cambios en pull requests y se detecta la deriva. La reconstrucción de un entorno deja de ser un ejercicio artesanal.
Errores frecuentes
- Aplicar controles sin evaluar el riesgo. La burocracia excesiva ralentiza sin proteger mejor.
- Usar credenciales de largo plazo y compartidas. Dificultan la auditoría y amplifican el impacto de una filtración.
- Cifrar sin gestionar claves y accesos. El cifrado es tan fuerte como el control de quien puede descifrar.
- Confundir cumplimiento con seguridad. Un checklist no garantiza que el sistema resista un ataque.
- Automatizar sin revisión ni reversión. Los errores se propagan más rápido.
- Tratar el coste como un problema posterior. El desperdicio suele ser síntoma de mal diseño.
Puntos clave para el examen
- Los marcos Well-Architected organizan decisiones en pilares; NIST CSF organiza la ciberseguridad por funciones.
- Mínimo privilegio, MFA, federación y separación de entornos son controles fundamentales.
- La gobernanza necesita inventario, políticas, etiquetas, auditoría y evidencia.
- La infraestructura como código aporta reproducibilidad y reduce la deriva.
- La respuesta a incidentes y la recuperación deben probarse, no solo documentarse.
- Seguridad, coste y fiabilidad son decisiones interrelacionadas.
Recursos externos
- AWS Well-Architected Framework: https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html
- Google Cloud Architecture Framework: https://cloud.google.com/architecture/framework
- Microsoft Azure Well-Architected Framework: https://learn.microsoft.com/en-us/azure/well-architected/
- NIST Cybersecurity Framework: https://www.nist.gov/cyberframework
Autoevaluación
1. ¿Qué significa mínimo privilegio?
Respuesta: Conceder solo los permisos necesarios para una tarea y durante el tiempo necesario.
Justificación: Reduce la superficie de ataque y limita el impacto de una credencial comprometida. No significa denegar todo, sino ajustar el permiso al trabajo real.
2. ¿Para qué sirve la infraestructura como código?
Respuesta: Para describir y aplicar recursos de forma versionada y reproducible, reduciendo cambios manuales y deriva.
Justificación: Los archivos permiten revisión, auditoría y reconstrucción. La automatización sin control de cambios puede propagar errores más rápido.
3. ¿Qué aporta el NIST Cybersecurity Framework frente a un marco de arquitectura?
Respuesta: Aporta una estructura de funciones —identificar, proteger, detectar, responder y recuperar— que conecta los controles técnicos con la gobernanza y la respuesta a incidentes.
Justificación: Un marco de arquitectura guía cómo construir; NIST CSF guía cómo operar y demostrar gestión del riesgo. Se complementan: uno diseña, el otro verifica y responde.
4. ¿Por qué separar producción y desarrollo en cuentas o proyectos distintos?
Respuesta: Para limitar el alcance de un error o compromiso y evitar accesos accidentales a datos reales.
Justificación: La separación crea una frontera administrativa y de red. Compartir credenciales y redes elimina esa barrera.
5. ¿Qué hace útil a un control de gobernanza?
Respuesta: Que sea proporcional al riesgo, verificable con evidencia y automatizable cuando sea posible.
Justificación: Un control sin evidencia no demuestra cumplimiento; uno desproporcionado frena sin proteger. La automatización mejora consistencia y trazabilidad.