Levantar la infraestructura en cloud no la hace segura: cambia el sitio donde están los fallos. La mayoría de las brechas en cloud no vienen de un fallo del proveedor, vienen de una configuración de permisos que alguien dejó abierta para salir del paso y nadie volvió a mirar.
Dónde acaba la responsabilidad del proveedor
El modelo de responsabilidad compartida es claro sobre el papel y confuso en la práctica. El proveedor responde de la seguridad de la nube; usted responde de la seguridad en la nube: identidades, permisos, configuración, datos, red y todo lo que despliegue encima. Ahí es donde trabajamos.
Qué revisamos
Identidad y permisos: cuentas con privilegios excesivos, roles que nadie usa, claves de acceso que llevan años sin rotar y rutas de escalada dentro del propio proveedor. Es la primera causa de incidente en cloud.
Exposición: almacenamiento público, bases de datos accesibles desde Internet, paneles de administración publicados y grupos de seguridad abiertos de par en par.
Red y segmentación: si un contenedor comprometido llega a la base de datos de producción o se queda donde debe.
Cifrado y gestión de claves: en reposo, en tránsito y quién puede descifrar qué.
Contenedores y Kubernetes: imágenes, secretos, políticas de admisión y privilegios de los pods.
Infraestructura como código: revisión de las plantillas, que es donde se corrige el fallo de una vez y para siempre.
Registro y trazabilidad: si podría reconstruir qué pasó en caso de incidente, que es justo cuando se descubre que no se estaba registrando.
Cómo trabajamos
1
Inventario real
Qué hay desplegado de verdad, en cuántas cuentas y en cuántas regiones. Es habitual encontrar entornos de pruebas olvidados y facturando.
2
Revisión de configuración
Contrastada con las buenas prácticas del proveedor y con los CIS Benchmarks correspondientes.
3
Análisis de rutas de escalada
No basta con listar permisos: hay que ver qué cadena de permisos lleva de una cuenta cualquiera a control total.
4
Pruebas técnicas
Con alcance pactado, comprobamos lo que se puede alcanzar de verdad desde fuera y desde dentro.
5
Plan de remediación
Priorizado y, siempre que se pueda, expresado como cambio en la infraestructura como código para que no reaparezca.
6
Verificación
Retest de lo corregido y línea base para medir la deriva en la siguiente revisión.
Qué recibe
Inventario de cuentas, servicios y activos desplegados.
Informe de configuración con hallazgos priorizados y evidencia.
Mapa de rutas de escalada de privilegios.
Plan de remediación con el cambio concreto, a ser posible en código.
Línea base para medir la deriva de configuración en el tiempo.
Quién lo ejecuta. El mismo equipo que audita, no un perfil comercial. En gobierno, riesgo y cumplimiento: CISSP, CISM, ISO 27001 Lead Auditor, ENS y Análisis de Riesgos (CCN), DPD/DPO certificado, CCSP y CDPP (ISMS Forum) y PMP (PMI). En la parte técnica: OSCP, CRTO II y eWPTX, con presencia en el Top 1 % de la plataforma Atenea del CCN-CERT.
Preguntas que nos hacen
Usamos un proveedor grande. ¿No es seguro ya?
Su infraestructura sí. Lo que usted despliega encima, no necesariamente. Prácticamente todas las brechas sonadas en cloud han sido errores de configuración del cliente, no fallos del proveedor.
¿Trabajan con AWS, Azure y Google Cloud?
Sí, y también con entornos híbridos y multi-cloud, que son los que más problemas de identidad acumulan porque nadie tiene la foto completa.
¿Esto es lo mismo que un pentest?
Se complementan. La revisión de configuración encuentra el permiso mal puesto; el pentest demuestra hasta dónde se llega con él. Lo habitual es empezar por la configuración, que da más por menos.
¿Nos sirve para el ENS o para ISO 27001?
Sí, y además le ahorra trabajo: buena parte de las evidencias técnicas que pide un auditor salen directamente de esta revisión.
Revise su cloud antes de que lo haga otro
Media hora con un auditor para acotar cuentas, entornos y alcance.
Teléfono: +34 686 250 244 (L-V, 9:00 a 18:00) · Email: info@jaymonsecurity.com
Respondemos en 2 horas dentro del horario laboral.
