Checklist consolidado y recursos

El checklist completo

Configuración de sistema (SC)

• Aplicaciones, procesos y cuentas de servicio corren con el mínimo privilegio posible
• El código de infraestructura (IaC) también sigue el principio de mínimo privilegio
• Se eliminó toda funcionalidad innecesaria: archivos, cuentas, software y demos
• No queda código de prueba ni funcionalidad no destinada a producción antes del despliegue
• La configuración de seguridad está en un formato legible por humanos y es auditable
• Los entornos de desarrollo y producción están aislados, con acceso restringido a grupos autorizados
• Existe un sistema de control de cambios que registra modificaciones en desarrollo y producción
• Las páginas sensibles no son indexables (robots.txt, X-Robots-Tag, meta robots)
• Los métodos HTTP innecesarios (WebDAV, PUT, DELETE sin usar) están deshabilitados
• Los headers HTTP no revelan sistema operativo, versión del servidor ni framework
• .git, .svn u otra metadata de control de versiones no son accesibles desde la web
• No hay contraseñas, secretos ni claves en texto plano en código, artefactos o cliente
• La documentación interna y las APIs internas no son accesibles públicamente

Gestión de archivos (FM)

• El listado de directorios está desactivado
• Los archivos subidos por usuarios no viven en el mismo contexto web que la aplicación
• Los directorios de carga no tienen privilegios de ejecución
• Los archivos y recursos de la aplicación son de solo lectura en producción
• El acceso a archivos y recursos usa listas de permitidos, no de bloqueados

Seguridad en la nube (CS)

• Se implementa gestión de acceso Just-In-Time (JIT)
• Las imágenes de contenedor están escaneadas y provienen de un registro privado confiable
• La infraestructura se aprovisiona mediante Infrastructure as Code
• Las políticas de seguridad se aplican mediante Policy as Code

Cómo adaptar este checklist a un proyecto real

El propio OWASP Developer Guide aclara que esta lista es un punto de partida, no un estándar cerrado. Recomendaciones para llevarlo a la práctica:

1. Priorizar por exposición real: un servicio interno sin acceso a internet no necesita la misma urgencia en “métodos HTTP deshabilitados” que una API pública, pero sí en mínimo privilegio y gestión de secretos.
2. Incorporarlo a la Definition of Done: agregar los ítems relevantes a la plantilla de Pull Request o a los criterios de aceptación, para que se revisen en cada cambio y no una vez al año en una auditoría.
3. Automatizar lo que se pueda verificar por código: headers HTTP, escaneo de imágenes y políticas de IaC se prestan a gates automáticos en CI/CD (ver capítulo 4). Lo que no se puede automatizar (aislamiento de entornos, control de cambios) queda como checklist de revisión humana.
4. Revisar el checklist cuando cambia el stack: migrar de un monolito a microservicios, o de VMs a serverless, cambia qué ítems aplican y cómo se implementan (por ejemplo, “aislar entornos” en serverless se resuelve con cuentas de AWS separadas, no con VLANs).

Referencias

• OWASP Developer Guide — Secure by Default (fuente original de este tutorial)
• OWASP Top 10 Proactive Controls — C5: Secure by Default Configurations
• OWASP Cheat Sheet Series — Infrastructure as Code Security
• OWASP Cheat Sheet Series — HTTP Headers
• OWASP Cheat Sheet Series — File Upload
• CIS Benchmarks — configuraciones de hardening detalladas por producto (Linux, Docker, Kubernetes, cloud providers)
• NIST SP 800-53 — control CM-6 (Configuration Settings) — marco de referencia para gestión de configuraciones seguras
• OWASP Application Security Verification Standard (ASVS) — sección V14 (Configuration) profundiza en varios de estos controles con niveles de rigurosidad