La mayor superficie de ataque hoy is your cloud.
Revisión de configuración, identidad y segmentación en AWS, Azure y GCP. La mayoría de los incidentes en la nube no empieza por un fallo del proveedor: empieza por un permiso demasiado amplio, un recurso expuesto sin querer o un secreto olvidado.
En la nube, el error rara vez es del proveedor
El modelo de responsabilidad compartida reparte el trabajo: el proveedor asegura la infraestructura y la configuración es tuya. Los incidentes ocurren en tu mitad: un bucket abierto por comodidad durante una prueba, un rol con permiso administrativo concedido con prisas, una red sin segmentar porque la entrega iba tarde. Nada de eso aparece como vulnerabilidad en un escaneo; aparece como una decisión de configuración que nadie volvió a revisar.
- El permiso concedido como medida temporal casi nunca se revoca después.
- Un recurso creado fuera del proceso estándar no hereda las protecciones que ese proceso aplica.
- Los secretos en variables de entorno y repositorios siguen siendo el camino más corto hacia dentro.
- Sin segmentación, un solo acceso alcanza cuentas y entornos que deberían estar separados.
What's included
El alcance de abajo es el estándar para un engagement típico. Todo es ajustable durante el scoping, sin coste.
- Políticas amplias y comodines en acciones y recursos
- Roles asumibles y cadenas de escalada de privilegios
- Claves de acceso de larga duración y rotación
- Federación, proveedor de identidad y sesiones
- Cuentas de servicio y permisos de carga de trabajo
- Separación entre administración y operación
- Exposición pública de objetos y contenedores
- Cifrado en reposo y gestión de claves
- Política de acceso y compartición entre cuentas
- Versionado, retención y protección ante borrado
- Copias de seguridad y pruebas de restauración
- Datos sensibles fuera de su repositorio previsto
- Reglas de entrada abiertas a toda internet
- Segmentación entre entornos y entre cuentas
- Balanceadores, pasarelas y terminación de tráfico
- Servicios de gestión alcanzables desde fuera
- Conectividad privada y emparejamiento de redes
- Superficie de contenedores y orquestación
- Rastro de auditoría activo en todas las regiones
- Retención y protección del propio registro
- Cobertura de eventos del plano de control
- Alertas ante cambios sensibles de permisos
- Centralización en una cuenta separada
- Integración con la monitorización existente
- IAM, roles, políticas y federación de identidad
- VPC, grupos de seguridad, NACL, peering y exposición pública
- S3, RDS, DynamoDB, Blob Storage y Cloud Storage
- EC2, Lambda, ECS, EKS, AKS y GKE
- CloudTrail, AWS Config, Microsoft Sentinel y Security Command Center
- Proveedores de identidad y SSO federado
Modalities
adjustable to scopeRevisión de configuración
Lectura sistemática del entorno desde un rol de auditoría: identidad, red, almacenamiento, registro y protección de datos, comparados con la documentación del propio proveedor y con referencias públicas.
Prueba de caminos
En lugar de listar configuración, partimos de una posición plausible —credencial de aplicación, contenedor comprometido, usuario común— y comprobamos hasta dónde llega dentro del entorno.
Revisión continua y de infraestructura como código
Análisis de las plantillas y módulos que construyen el entorno, más un ciclo recurrente de verificación. Corregir en el origen evita que la misma desviación vuelva con cada nueva cuenta, proyecto o despliegue.
Cuándo revisar el entorno en la nube
La configuración en la nube cambia a diario y por muchas manos. Algunos momentos concentran más riesgo que otros.
Un entorno movido con prisas suele arrastrar permisos amplios concedidos para desbloquear el cambio, con la promesa de ajustarlos después, y ese después rara vez llega.
Cada equipo creó la suya, cada proyecto abrió otra. Sin un estándar central las protecciones divergen y nadie tiene visión del conjunto.
Un gasto anómalo a veces es desperdicio y a veces es un recurso creado por alguien que no debería haber podido crearlo. Conviene saber cuál de los dos.
La evidencia de controles en la nube ya es un apartado obligatorio en la mayoría de los cuestionarios. Mejor encontrar la brecha antes que quien va a evaluar.
How we conduct it
[pipeline]Levantamiento del entorno
Empezamos por lo que existe: cuentas, suscripciones, proyectos, regiones activas y recursos en uso. Un entorno en la nube casi siempre es mayor de lo que sugiere la documentación, y el recurso ausente del inventario suele ser el desprotegido.
Análisis de identidad y permisos
Mapeamos quién puede hacer qué, incluido lo posible por herencia y por asunción de roles. Lo que interesa no es la política escrita sino el permiso efectivo, que suele ser bastante más amplio de lo que imagina quien lo concedió.
Revisión de configuración
Almacenamiento, red, cifrado, registro, copias y servicios gestionados se comparan con la documentación del proveedor y con referencias públicas de configuración segura, anotando cada desviación y por qué importa en ese entorno concreto.
Verificación de alcance
Simulamos posiciones de partida realistas y medimos el alcance de cada una: qué puede leer una credencial de aplicación, qué alcanza un contenedor comprometido, si es posible cruzar de un entorno a otro. Eso separa una lista de desviaciones de un riesgo demostrado.
Evaluación de registro y alertas
Comprobamos si las acciones ejecutadas dejaron rastro, si ese rastro está protegido ante borrado y si los cambios sensibles de permisos generan alerta. Un entorno sin rastro fiable no permite investigar un incidente después.
Informe y plan de corrección
Las desviaciones se agrupan por causa y no por recurso: diez elementos que vienen de una misma política son una corrección, no diez. Cada grupo recibe orientación aplicable y una sugerencia para impedir la reincidencia en el origen.
Referencias públicas que guían el trabajo
La revisión se apoya en la documentación de los propios proveedores y en referencias abiertas de configuración, lo que hace cada apunte verificable de forma independiente.
- CIS Benchmarks
- Las referencias de configuración para AWS, Azure y GCP dan una línea base objetiva y verificable, punto por punto, para comparar el estado del entorno.
- Well-Architected (pilar de seguridad)
- El material de arquitectura de cada proveedor describe su propia práctica recomendada, lo que evita discutir de dónde sale la recomendación.
- Modelo de responsabilidad compartida
- Define con claridad dónde termina la responsabilidad del proveedor y empieza la tuya: la frontera exacta donde ocurre la mayoría de los incidentes.
- MITRE ATT&CK for Cloud
- La matriz específica de nube pone nombre a las técnicas de abuso de identidad, persistencia y recolección, y sirve para evaluar la cobertura de la detección.
- NIST SP 800-53
- El catálogo de controles es el puente entre el hallazgo técnico y el lenguaje que usan gobierno y auditoría.
- Mínimo privilegio
- No es una norma, es el criterio que orienta el análisis de permisos: cada identidad debería alcanzar solo lo necesario, y toda desviación necesita justificación explícita.
- Azure Security Benchmark
- La línea base propia de Microsoft para Azure, útil cuando el entorno es mayoritariamente Azure y la auditoría espera esa referencia.
- CSA Cloud Controls Matrix
- La matriz de la Cloud Security Alliance mapea los dominios de seguridad en la nube y se cruza con otras normas, lo que ayuda cuando el cuestionario del cliente es extenso.
- ISO/IEC 27017 y 27018
- Las normas específicas de seguridad en la nube y de datos personales en la nube, citadas con frecuencia en contratos corporativos.
- Correspondencia con RGPD y PCI-DSS
- Cuando el entorno trata datos personales o de tarjeta, cada hallazgo sale además referenciado al requisito correspondiente, para servir directamente como evidencia.
Deliverables
dual view · NDAInventario de lo que existe
La lista real de cuentas, proyectos, regiones y recursos activos. Para muchos equipos esta es la primera entrega útil, porque revela entornos que nadie recordaba tener.
Mapa de permisos efectivos
Quién alcanza qué en la práctica, incluidos los caminos indirectos por herencia y asunción de roles. Suele sorprender más que la lista de configuración.
Desviaciones agrupadas por causa
Los apuntes organizados por origen común, cada uno con su referencia pública. Corregir la causa cierra varios elementos a la vez y evita la reincidencia.
Caminos demostrados
Para los riesgos más relevantes, el recorrido concreto: de dónde parte, qué alcanza y por qué importa. Convierte una desviación de configuración en un riesgo comprensible.
Evaluación de rastro y detección
Qué quedó registrado de las acciones ejecutadas, qué estaba desactivado y qué cambios sensibles pasarían hoy desapercibidos.
Plan de corrección priorizado
Un orden de trabajo que pondera riesgo y esfuerzo, separando lo que se resuelve en la configuración de lo que debe cambiar en la infraestructura como código para no volver.
Frequently asked
No. La revisión se hace con un perfil de auditoría de solo lectura, que los tres proveedores ofrecen de forma nativa. Para la verificación de alcance acordamos aparte credenciales específicas y limitadas, con alcance y plazo definidos por escrito.
Las complementa, no las sustituye. La herramienta de postura cubre volumen y sigue la desviación de forma continua, lo cual es valioso. Lo que no hace es encadenar permisos para mostrar que una credencial de aplicación alcanza un dato que debería estar aislado, y esa demostración es la que cambia prioridades.
Sí. El entorno mixto es el caso común, y la comparación entre proveedores suele revelar protección desigual: el mismo tipo de recurso protegido en uno y expuesto en otro, porque los construyeron equipos distintos.
La orquestación entra en el alcance: roles y vínculos de acceso, contexto de seguridad de los contenedores, política de red entre servicios, exposición del plano de control, gestión de secretos y el vínculo entre la identidad del clúster y la de la nube, un camino frecuente de escalada.
El entorno que atiende a producción, como mínimo. Las cuentas de desarrollo y preproducción valen la pena cuando tienen camino de red o de identidad hacia producción, algo más común de lo que se supone, y justo donde la protección suele ser más laxa.
Corrigiendo en el origen. Cuando el entorno nace de infraestructura como código, la corrección va al módulo y vale para todo despliegue futuro. El informe indica, para cada grupo de desviaciones, si debe tratarse en el recurso o en la plantilla que lo crea.
Sí. Cada apunte trae su referencia pública y la evidencia de la configuración observada, en un formato que un auditor puede verificar de forma independiente sin rehacer el análisis.
¿Listo para descubrir tus fallas?
La primera call de scoping es gratuita y cubierta por NDA. En 48 horas recibes propuesta técnica, alcance y cronograma. Sin formularios burocráticos.