Servicio // 02

Cloud
Security.

Tu infraestructura cloud tiene más superficie de ataque de la que crees. Un bucket S3 sin lista de acceso, una IAM policy con AdministratorAccess, un secret hardcodeado en un pipeline de GitHub Actions. Los encontramos todos.

Solicitar auditoría cloud Ver todos los servicios
// FICHA DE SERVICIO
ProveedoresAWS / Azure / GCP
ModalidadRead-only / Assume role
Duración media5–15 días hábiles
MarcoCIS Benchmarks + CSPM
EntregableInforme + IaC fixes
Re-scanIncluido sin coste
NDAPrevio al acceso
82%Entornos con over-privileged IAM roles
1 de 3Empresas con buckets o blobs expuestos
67%Pipelines CI/CD con secrets en variables de entorno
CIS L2Benchmark de referencia para todos los hallazgos
Cobertura // 01

AWS, Azure y GCP.

Cubrimos los tres grandes proveedores cloud y entornos híbridos. Selecciona el proveedor para ver qué áreas auditamos en detalle.

AWS
Azure
GCP
Kubernetes
Amazon Web Services
Auditamos toda la superficie de ataque de AWS: desde políticas IAM y SCPs hasta configuraciones de red, almacenamiento y servicios de datos. Usamos AWS Config, SecurityHub y Scout Suite para cobertura completa, complementada con revisión manual de políticas complejas.
IAM policies — least privilege, wildcard actions (*)
IAM roles con trust policies excesivas o cross-account
S3 buckets — ACLs públicas, Block Public Access, cifrado
CloudTrail — cobertura de regiones, integridad de logs
Security Groups — reglas 0.0.0.0/0 en puertos sensibles
RDS — cifrado en reposo, acceso público, snapshots
Lambda — permisos de ejecución, secretos en env vars
ECS/EKS — task roles, network policies, image scanning
Secrets Manager vs. SSM Parameter Store vs. env vars
API Gateway — autenticación, throttling, WAF
KMS — rotación de claves, key policies, grants
GuardDuty / AWS Config / SecurityHub — estado y gaps
Microsoft Azure
Revisión de políticas RBAC, configuraciones de Azure AD, recursos expuestos y postura de seguridad general con Microsoft Defender for Cloud y herramientas especializadas como ScoutSuite y Prowler.
Azure AD — guest access, legacy auth, MFA enforcement
RBAC — roles con Owner/Contributor a nivel suscripción
Blob Storage — acceso público, SAS tokens expirados/excesivos
NSGs — reglas Any/Any, puertos RDP/SSH expuestos a internet
Key Vault — políticas de acceso, soft delete, RBAC
Azure Defender for Cloud — alertas sin responder, score
AKS — RBAC habilitado, network policies, node pool config
Service Principals — credenciales, permisos, expiración
Azure Functions — Managed Identity vs. connection strings
Log Analytics — retención, workspaces, gaps de cobertura
Conditional Access — políticas MFA, trusted locations
Privileged Identity Management — activaciones, JIT
Google Cloud Platform
Auditoría de proyectos y organizaciones GCP con foco en IAM, Cloud Storage, configuración de red y postura general. Usamos Security Command Center, Forseti y revisión manual.
IAM — service accounts con editor/owner a nivel proyecto
Service account keys — rotación, almacenamiento, uso
Cloud Storage — IAM vs. ACLs, acceso público, versioning
Firewall rules — allow all ingress, 0.0.0.0/0 SSH/RDP
Cloud SQL — IPs autorizadas, cifrado, backups automáticos
GKE — Workload Identity, network policies, binary auth
Cloud KMS — rotación de claves, permisos de cifrado
Audit logs — Data Access logs habilitados, exportación
Secret Manager — rotación, IAM, acceso de service accounts
VPC Service Controls — perímetros de seguridad
Cloud Armor — WAF rules, rate limiting
Security Command Center — hallazgos sin resolver
Kubernetes (EKS / AKS / GKE / On-prem)
Auditoría de clústeres Kubernetes independientemente del proveedor. Desde la configuración del API server hasta los pods corriendo con privilegios excesivos. CIS Kubernetes Benchmark + kube-bench.
API Server — anonymous auth, RBAC, audit logging
RBAC — ClusterRoleBindings excesivos, wildcard verbs
Network Policies — allow-all por defecto, egress sin restricción
Pod Security — privileged containers, hostPath, hostNetwork
Secrets — en etcd sin cifrar, montados como env vars
Image scanning — imágenes con CVEs críticos en producción
Service Account tokens — automount, permisos excesivos
Ingress — TLS, WAF, rate limiting, headers de seguridad
etcd — cifrado en reposo, acceso, backups
Runtime security — Falco, Seccomp, AppArmor profiles
Supply chain — Admission controllers, image signing
Hardening CIS Kubernetes Benchmark Level 2
Hallazgos Típicos // 02

Lo Que Encontramos.

Estos son los hallazgos más frecuentes y críticos que encontramos en auditorías de cloud. ¿Cuántos existen en tu entorno ahora mismo?

CRÍTICO
IAM con AdministratorAccess o *:* sin MFA
Cuentas de usuario o roles de servicio con permisos de administrador completo sin requerir MFA. Un atacante que comprometa las credenciales tiene acceso total a todos los recursos de la cuenta.
CRÍTICO
S3 / Blob Storage con acceso público sin restricción
Buckets accesibles públicamente con datos de clientes, backups de bases de datos, archivos de configuración o logs internos. El ACL "public-read" activo sin Block Public Access habilitado a nivel cuenta.
CRÍTICO
Secrets en repositorios de código o variables CI/CD
API keys, connection strings de base de datos, tokens OAuth o credenciales cloud hardcodeadas en GitHub Actions, GitLab CI o Terraform. Accesibles para cualquier desarrollador con acceso al repo.
ALTO
Security Groups / NSGs con puertos RDP/SSH abiertos a 0.0.0.0/0
Reglas de firewall que permiten acceso SSH (22) o RDP (3389) desde cualquier IP de internet. Expone instancias directamente a ataques de fuerza bruta y explotación de vulnerabilidades en el protocolo.
ALTO
Kubernetes con privileged containers o hostPath mounts
Pods ejecutándose con privilegios de root en el nodo, acceso al filesystem del host o capabilities de Linux excesivas. Una vulnerabilidad en cualquier aplicación permite container escape hacia el nodo.
ALTO
CloudTrail / audit logs deshabilitados o sin cubrir todas las regiones
Regiones sin CloudTrail activo, logs sin integridad habilitada, o datos de acceso sin registrar. Un atacante puede operar en regiones no monitorizadas sin dejar rastro en los logs de auditoría.
MEDIO
Rotación de claves KMS o service account keys deshabilitada
Claves de cifrado o credenciales de service account que no rotan automáticamente. Si se filtran, permanecen válidas indefinidamente. El principio de tiempo de vida limitado de credenciales no se aplica.
MEDIO
RDS / Cloud SQL con acceso público o backups sin cifrar
Bases de datos relacionales con endpoint público accesible desde internet, o con snapshots automáticos almacenados sin cifrado. Los backups sin cifrar son accesibles si un atacante obtiene acceso a nivel storage.
Proceso // 03

Cómo lo Hacemos.

01
Acceso Read-Only y Permitrología Mínima
Solicitamos acceso con permisos mínimos de lectura (SecurityAudit en AWS, Reader en Azure). No necesitamos credenciales de administrador para la fase de auditoría. Documentamos y acordamos exactamente qué permisos se conceden antes de comenzar.
SecurityAudit role
Read-only SPs
Viewer roles GCP
Signed NDA
02
Enumeración Automatizada con CSPM
Ejecutamos herramientas especializadas de Cloud Security Posture Management para enumerar todos los recursos y evaluar su configuración contra CIS Benchmarks y best practices del proveedor. Este paso genera el inventario inicial de potenciales hallazgos.
Prowler
ScoutSuite
CloudSploit
kube-bench
03
Revisión Manual de IAM y Políticas Complejas
Las herramientas automatizadas no entienden el contexto de negocio ni detectan combinaciones de políticas que individualmente parecen seguras pero en conjunto crean rutas de escalada. Revisamos manualmente los trust policies, resource-based policies, SCPs y permisos efectivos.
AWS Policy Simulator
IAM Access Analyzer
Manual review
PMapper
04
Análisis de CI/CD y Gestión de Secretos
Revisamos pipelines de CI/CD (GitHub Actions, GitLab CI, Jenkins, CodePipeline) para identificar secrets en variables de entorno, permisos excesivos de los runners, y posibilidad de inyección de código en el pipeline. También evaluamos si los secrets están en el lugar correcto (Secrets Manager vs. env vars vs. código).
truffleHog
gitleaks
Semgrep
Manual review
05
Informe con Fixes en IaC
Cada hallazgo incluye no solo la descripción y el riesgo, sino también el fix concreto: política IAM corregida en JSON, Terraform snippet para la configuración correcta, o comando CLI específico para remediar. El objetivo es que tu equipo pueda cerrar el 80% de los hallazgos en la primera semana.
Terraform examples
AWS CLI snippets
CVSS 3.1
Re-scan incluido
FAQ // 04

Preguntas Frecuentes.

¿Necesitáis acceso de administrador a nuestra cuenta cloud? +
No. Trabajamos con permisos de solo lectura. En AWS creamos un rol con la política gestionada SecurityAudit. En Azure, el rol Reader a nivel suscripción. En GCP, el rol Viewer en los proyectos a auditar. Esto nos da visibilidad completa sin capacidad de modificar nada en tu entorno. El proceso de acceso está documentado y es reversible en cualquier momento.
¿La auditoría cloud puede afectar a la disponibilidad de nuestros servicios? +
No. Con acceso de solo lectura, las herramientas que usamos únicamente llaman a APIs de consulta (describe, list, get). No ejecutamos ninguna operación que modifique recursos. El único impacto posible es un incremento marginal en las llamadas a las APIs de gestión, que está muy por debajo de los límites de throttling estándar de cualquier proveedor.
¿Podéis auditar entornos multi-cuenta (AWS Organizations, Azure Management Groups)? +
Sí. Para entornos enterprise con múltiples cuentas o suscripciones, configuramos acceso desde la cuenta de gestión (Management Account en AWS, Root Management Group en Azure) para tener visibilidad centralizada. Esto permite detectar también problemas de configuración a nivel organización: SCPs mal definidas, políticas de guardrail incompletas y cuentas fuera del perímetro de seguridad.
¿Auditáis infraestructura definida como código (Terraform, CloudFormation)? +
Sí, y recomendamos incluirlo siempre. Analizar el IaC permite detectar problemas antes de que lleguen a producción y entender la intención de la configuración (qué estaba pensado ser privado pero quedó expuesto por un error). Usamos tfsec, Checkov y Semgrep para análisis estático, complementado con revisión manual de los módulos más críticos.
¿El informe sirve para cumplimiento ENS, ISO 27001 o SOC 2? +
El informe está alineado con CIS Benchmarks (nivel 1 y 2) para cada proveedor, y cada hallazgo incluye referencia al control correspondiente de ENS, ISO 27001 Annex A y CIS Controls v8. Puede presentarse como evidencia en procesos de certificación y auditorías regulatorias, aunque la decisión final sobre su validez corresponde al organismo certificador.
// ¿TIENES BUCKETS O ROLES SIN REVISAR?

Un bucket público puede costarte más que la auditoría.

Primera llamada de diagnóstico sin coste. En 30 minutos identificamos los riesgos más urgentes de tu entorno cloud.

Solicitar auditoría cloud Ver todos los servicios