Antes de una auditoría o due diligence: checklist cloud para no improvisar

Una auditoría, una ronda o una venta enterprise puede complicarse por algo básico: nadie sabe explicar con seguridad quién accede a qué, qué logs existen, qué backups se han probado o qué pasaría si una pieza crítica dejara de responder.

Si tu equipo opera producción en AWS, prepararse no significa maquillar la cuenta ni prometer compliance. Significa llegar con una lectura honesta del estado técnico, evidencias razonables y una lista priorizada de riesgos, decisiones y próximos pasos.

Este checklist no sustituye una auditoría formal, una revisión legal ni un proceso de certificación. Es una guía práctica de readiness cloud: qué revisar antes de que un auditor, inversor, cliente enterprise o equipo técnico externo empiece a preguntar.

1. IAM y accesos: quién puede hacer qué, por qué y desde cuándo

La primera pregunta es incómodamente sencilla: ¿quién puede entrar en la cuenta y qué puede hacer?

En AWS, IAM acumula historia. Usuarios antiguos, roles creados para una integración temporal, permisos amplios que nadie se atreve a tocar, credenciales activas para proyectos que ya no existen, accesos de terceros sin responsable claro.

Antes de una due diligence técnica, no basta con decir que existe IAM. Conviene poder enseñar o explicar:

cómo acceden las personas al entorno;
si el usuario root está protegido y no se usa para la operación diaria;
qué usuarios, roles o credenciales siguen activos sin una necesidad clara;
dónde hay permisos demasiado amplios;
qué accesos tienen proveedores, freelancers o herramientas externas;
si hay MFA y credenciales temporales donde corresponde;
quién aprueba nuevos permisos y quién revisa los existentes.

La pregunta útil no es si algo es seguro en abstracto. Es si puedes justificar por qué existe cada acceso relevante y qué impacto tendría si se usara mal.

2. Logging y trazabilidad: poder reconstruir cambios importantes

En una revisión externa aparece una pregunta de trazabilidad: ¿podéis saber quién cambió esto, cuándo y desde dónde?

CloudTrail puede ayudar a registrar actividad de usuarios, roles y servicios en AWS. AWS Config puede aportar histórico de configuración y relaciones entre recursos. CloudWatch Logs y otros sistemas de logs pueden ayudar a entender el comportamiento de aplicaciones e infraestructura.

El matiz importante: tener esos nombres en la cuenta no equivale a tener evidencia suficiente. Revisa:

si CloudTrail está configurado con el alcance y la retención que necesitáis;
qué eventos quedan cubiertos y cuáles no;
si los logs críticos están centralizados o dispersos;
quién puede leer, borrar o modificar evidencias;
cuánto tiempo se conservan los datos relevantes;
si existe una forma razonable de investigar cambios en producción.

El objetivo no es guardar logs infinitos por si acaso. Es que, ante una pregunta seria, el equipo no dependa de memoria tribal ni de capturas sueltas.

3. Superficie pública: saber qué está expuesto y por qué

La exposición de red acumula excepciones: un security group abierto para una prueba, un bucket S3 que debía ser temporalmente público, un endpoint abandonado, un balanceador sin responsable claro, una regla heredada que nadie sabe si puede cerrar.

Antes de una auditoría o due diligence, revisa al menos:

security groups con rangos amplios, especialmente en puertos administrativos;
recursos accesibles desde Internet y su justificación;
buckets S3 y configuración de Block Public Access;
balanceadores, endpoints públicos y reglas heredadas;
excepciones documentadas: qué está abierto, para quién y por qué;
dependencias externas que entran o salen de la plataforma.

No todo recurso público es un error. Una aplicación web tendrá componentes expuestos. Lo preocupante es no saber qué está publicado, quién lo decidió y qué controles compensan ese diseño.

4. Backups: comprobar recuperación, no sólo existencia

Un snapshot, un job de backup o una política en AWS Backup pueden parecer tranquilizadores. Pero una copia que nunca se ha restaurado sigue siendo una hipótesis.

La revisión debería responder preguntas concretas:

qué datos y servicios críticos están respaldados;
con qué frecuencia se hacen copias;
durante cuánto tiempo se conservan;
quién recibe alertas si falla un backup;
cuándo fue la última restauración probada;
qué RPO y RTO aproximados puede asumir el negocio;
qué dependencias no están cubiertas por el plan actual.

No hace falta convertir el plan de backups en un programa de disaster recovery perfecto de la noche a la mañana. Pero sí conviene separar tres estados: lo que está respaldado y probado, lo que está respaldado pero no probado, y lo que directamente no tiene una estrategia clara.

5. Continuidad y DR: no confundir alta disponibilidad con recuperación

Alta disponibilidad, backups y disaster recovery no son lo mismo.

Tener varios contenedores detrás de un balanceador puede ayudar ante ciertos fallos. Tener backups puede ayudar ante pérdida o corrupción de datos. Tener un plan de disaster recovery implica saber cómo se recupera el servicio ante escenarios más graves y qué degradación acepta el negocio.

Una revisión realista debería documentar escenarios como:

caída de una instancia, nodo, task o servicio gestionado;
pérdida o corrupción de datos;
fallo de una zona de disponibilidad;
indisponibilidad de una dependencia crítica;
error humano durante un cambio de infraestructura;
necesidad de reconstruir o restaurar un entorno desde cero.

La respuesta no tiene que ser multi-region para todo. Para muchos equipos sería caro, innecesario o difícil de operar bien. La respuesta útil es explicar qué arquitectura existe, qué escenarios cubre, cuáles no cubre y qué riesgos se aceptan conscientemente.

6. Observabilidad y alertas: señales que alguien puede usar

En una due diligence técnica, la observabilidad no se evalúa sólo por tener dashboards. Se evalúa por si el equipo puede detectar, entender y responder a problemas relevantes.

Revisa si existen señales mínimas para los servicios críticos:

métricas de infraestructura y aplicación;
logs consultables durante incidentes;
alarmas accionables, no ruido permanente;
responsable claro de cada alerta importante;
dashboards que expliquen la salud del servicio, no sólo CPU;
relación entre despliegues, cambios e incidentes.

CloudWatch puede cubrir parte de esto dentro de AWS, pero la herramienta concreta importa menos que la disciplina operativa. Una alerta que nadie entiende no es evidencia fuerte. Un dashboard que nadie mira tampoco.

7. Infraestructura como código y cambios: saber cuál es la fuente de verdad

Terraform o cualquier enfoque de infraestructura como código ayuda cuando permite revisar cambios, entender dependencias y reducir configuración manual invisible. Pero no conviene venderlo como religión.

Antes de una auditoría o revisión externa, lo importante es saber:

qué parte de la infraestructura está en código;
qué parte se cambia manualmente;
cómo se revisan los cambios antes de tocar producción;
si hay pull requests, planes, aprobaciones o un flujo equivalente;
dónde puede existir drift entre Terraform y la realidad;
quién mantiene módulos, estados y secretos;
qué cambios recientes podrían explicar incidentes o riesgos.

Si todo está en Terraform pero nadie se atreve a ejecutar un plan, no hay tanta madurez como parece. Si parte de la plataforma es manual pero está documentada, controlada y con responsables claros, quizá el riesgo sea manejable mientras se prioriza una mejora gradual.

8. Documentación y ownership: responder sin improvisar

Muchas revisiones técnicas se atascan menos por falta de controles que por falta de explicación. La plataforma puede estar razonablemente bien, pero si nadie puede describirla, parece más frágil de lo que es.

Antes de que llegue la presión externa, prepara lo básico:

diagrama actual de arquitectura;
lista de servicios críticos y dependencias;
responsables por área: infraestructura, seguridad, datos, despliegues, incidentes;
runbooks para operaciones sensibles;
decisiones de arquitectura importantes y su contexto;
riesgos conocidos y estado de mitigación;
roadmap de mejoras con prioridades realistas.

La documentación útil no tiene que ser larga. Tiene que evitar que cada respuesta dependa de la persona que se acuerda de cómo se montó aquello.

9. Priorizar: no todo se arregla antes de la auditoría

Un error común es convertir una revisión previa en una carrera por arreglarlo todo. Eso suele producir cambios apresurados, poca evidencia y más riesgo operativo.

Una salida más útil es clasificar hallazgos en cuatro grupos:

Bloqueantes reales: riesgos que conviene remediar antes de la revisión externa.
Riesgos relevantes aceptados: decisiones que no se corrigen aún, pero se explican con contexto.
Mejoras rápidas: ajustes de bajo riesgo que reducen incertidumbre.
Roadmap posterior: trabajo importante que requiere diseño, pruebas o presupuesto.

Esto cambia el tono de la conversación. En lugar de prometer que todo está perfecto, el equipo puede decir: esto está cubierto, esto está en proceso, esto se acepta por ahora y esto requiere una decisión de negocio.

Llegar preparado no es prometer compliance

La preparación seria antes de una auditoría o due diligence no consiste en fabricar una imagen impecable de AWS. Consiste en entender la plataforma, enseñar evidencias razonables y hablar con claridad sobre riesgos.

IAM, logging, exposición pública, backups, recuperación, observabilidad, IaC, documentación y ownership no son una garantía de compliance. Son áreas donde una plataforma muestra si se opera con criterio o si depende demasiado de memoria, urgencias y suerte.

Si tu equipo se prepara para una auditoría, una ronda o una venta enterprise y necesita separar riesgos reales de ruido operativo, AstralDeploy puede ayudarte con una revisión de arquitectura y seguridad AWS orientada a evidencias, prioridades y próximos pasos.