Introducción

Los errores de configuración siguen siendo una de las causas más explotadas de brechas de seguridad, y no porque sean sofisticados de atacar, sino porque casi siempre son fáciles de detectar desde afuera. En la nube el problema se agrava: un solo firewall mal configurado o una Service Account con permisos de sobra puede exponer todo un entorno. Si ya revisaste los principios generales del modelo de responsabilidad compartida y CSPM en la Parte 1, este artículo baja un nivel más: los 7 errores concretos que veo con más frecuencia, cómo se traducen en GCP y OCI, y casos reales que muestran su impacto.

1. Credenciales Predeterminadas

En on-premise es el clásico “admin/admin123”. En la nube, la versión moderna es la Service Account o el usuario local que nadie tocó desde el día del provisioning.

En GCP: las Service Accounts creadas por defecto suelen heredar el rol Editor a nivel de proyecto — mucho más de lo que necesitan. Security Command Center las marca como hallazgo de alta prioridad si no se restringen. Lo cubrimos con más detalle en la Parte 2 (GCP), sección de IAM.

En OCI: el equivalente es dejar usuarios locales con contraseñas estáticas en lugar de aprovechar Identity Domains, Dynamic Groups e Instance Principals para eliminar credenciales fijas por completo. Ver Parte 3 (OCI).

Esto mapea directo con la sección de Identity and Access Management del CIS GCP Foundation Benchmark v5.0.0 y del CIS OCI Foundations Benchmark v3.1.0, y con la función Protect (PR.AA – Identity Management, Authentication and Access Control) de NIST CSF 2.0.

Caso real: en 2024 se registró un aumento significativo de ciberataques que explotaron credenciales predeterminadas, en parte porque las herramientas de IA hicieron más precisos estos intentos. Más en El País.

Recomendación: cambia las credenciales predeterminadas apenas configures un sistema, sin excepciones. En la nube, ve más allá: elimina las credenciales estáticas donde puedas (Instance Principals en OCI, Workload Identity en GCP) en lugar de solo rotarlas.

2. Reutilización de Contraseñas

Usar la misma contraseña en varios sistemas multiplica el riesgo: si un atacante consigue una, tiene la llave de todo lo demás. En la nube, el equivalente son las claves de Service Account compartidas entre proyectos o entornos.

En GCP: centraliza secretos en Secret Manager en lugar de incrustar claves en variables de entorno o repositorios; evita reutilizar la misma clave de Service Account en múltiples workloads.

En OCI: OCI Vault con envelope encryption (MEK/DEK) cumple el mismo rol — detallado en la Parte 3 (OCI).

Caso real: en octubre de 2024, un estudio de Proton y Constella Intelligence encontró información personal de 39 diputados y senadores españoles expuesta en la dark web. La mayoría de las filtraciones ocurrieron porque usaron su correo oficial para registrarse en servicios de terceros (LinkedIn, Adobe, Dropbox) que luego sufrieron brechas; entre los datos filtrados había 14 contraseñas en texto plano. Más en El País.

El caso de Capital One en 2019 es otro ejemplo clásico: la brecha que expuso datos de más de 100 millones de clientes se originó en una mala configuración en la nube. Más en Keeper Security.

Recomendación: una contraseña única por sistema, sin atajos, y rotación de claves de Service Account según lo que exige el benchmark CIS de tu proveedor.

3. Servicios Expuestos

Un servicio expuesto a internet sin las medidas adecuadas es, básicamente, un blanco fácil — y en la nube esto suele ser un error de un clic, no de intención.

En GCP: reglas de firewall que permiten tráfico entrante desde 0.0.0.0/0 a puertos de administración; Security Command Center lo detecta, pero solo si está habilitado.

En OCI: exponer un servicio interno directamente a internet en lugar de usar Service Gateway para tráfico hacia servicios de Oracle sin salir por internet pública, o el WAF de OCI como capa de filtrado frente a aplicaciones expuestas. Ver Parte 3 (OCI).

Caso real: en 2024 creció el número de ataques dirigidos a proveedores y empleados remotos del sector bancario, aprovechando aplicaciones no autorizadas y dispositivos personales expuestos. Detalles en Cinco Días.

Un antecedente ineludible: los ataques de 2021 contra servidores Microsoft Exchange locales, que permitieron a los atacantes acceder a correos y datos confidenciales de miles de organizaciones. Más en Computer Weekly.

Recomendación: MFA, cortafuegos y listas de control de acceso no son opcionales para nada que esté expuesto a internet. En la nube, revisa primero las reglas de red antes que cualquier otra capa.

4. Puertos Abiertos

Un puerto abierto no es peligroso por sí solo, pero es la puerta que un atacante necesita para el siguiente paso si no lo gestionas.

En OCI: este es justo el error que discutimos entre NSGs (a nivel de VNIC, más granular) y Security Lists (a nivel de subred, más permisivas por diseño) en la Parte 3 (OCI) — usar Security Lists donde correspondía una NSG es de los descuidos más comunes que veo en auditorías.

En GCP: las reglas de firewall por defecto de la red default permiten tráfico interno amplio entre instancias; conviene reemplazarlas por reglas basadas en tags o Service Accounts.

Caso real: En 2023, una vulnerabilidad crítica en la utilidad de configuración de F5 BIG-IP (CVE-2023-46747, CVSS 9.8) permitió a atacantes remotos ejecutar comandos arbitrarios en sistemas donde esa utilidad quedaba accesible por el puerto de administración. Más en Devel Group.

Los dispositivos IoT con puertos abiertos y configuraciones débiles son otro blanco recurrente. Más en EasyDMARC.

Recomendación: audita puertos abiertos con regularidad y cierra lo que no uses. En OCI, prefiere NSGs sobre Security Lists cuando necesites reglas específicas por recurso; considera el Bastion Service para acceso administrativo en vez de abrir puertos de gestión directamente.

5. Uso Continuado de Software Fin de Soporte (EoS) o Fin de Vida (EoL)

Software sin soporte significa software sin parches. Es cuestión de tiempo antes de que alguien lo explote.

Caso real: el 14 de octubre de 2025 terminó el soporte de Windows 10 — un sistema todavía usado por una porción enorme del parque instalado, lo que deja millones de equipos sin actualizaciones de seguridad desde esa fecha. Más en Microsoft Support.

En software de terceros, WinRAR sigue siendo un ejemplo recurrente: la CVE-2023-38831 permitió ejecución de código al abrir ZIPs manipulados, y en 2025 apareció una nueva falla (CVE-2025-6218) explotada por el grupo RomCom en campañas activas. Detalles en WeLiveSecurity.

En GCP y OCI: ambos ofrecen escaneo de vulnerabilidades gestionado — Security Command Center en GCP y el servicio de Vulnerability Scanning en OCI (ver Parte 3) — que detectan sistemas operativos y paquetes fuera de soporte en tus instancias sin que tengas que auditarlo manualmente.

Recomendación: planifica la migración con margen, antes de que el software llegue a su fecha de EoS/EoL. Activa el escaneo de vulnerabilidades nativo de tu proveedor para que este tipo de deuda técnica no dependa de que alguien se acuerde de revisarla.

6. Falta de Detección y Respuesta de Punto Final (EDR)

Sin EDR, una organización básicamente opera a ciegas frente a actividad maliciosa en sus endpoints, y eso se traduce directamente en tiempos de respuesta más largos.

En GCP: Chronicle centraliza y correlaciona señales de seguridad a escala, cubierto en la Parte 2 (GCP).

En OCI: Cloud Guard cumple un rol equivalente a nivel de postura y detección en la capa cloud (no reemplaza EDR de endpoint, pero cierra buena parte del vacío de visibilidad) — ver Parte 3 (OCI), incluida la comparación con Security Zones.

Ambos se alinean con la función Detect (DE) de NIST CSF 2.0.

Caso real: En 2023, Microsoft reportó que los grupos norcoreanos Diamond Sleet y Onyx Sleet explotaron una vulnerabilidad de JetBrains TeamCity (CVE-2023-42793) para mantener acceso persistente, aprovechando precisamente la falta de EDR en las organizaciones afectadas. Más en SC Media.

Recomendación: implementa EDR (o su equivalente cloud-native) para monitorear y responder en tiempo real — no solo para detectar después del hecho.

7. Logs Inhabilitados

Sin logs, no hay forma real de reconstruir qué pasó ni de detectar algo raro mientras ocurre.

En GCP: Cloud Logging combinado con Chronicle como SIEM.

En OCI: OCI Logging & Audit para el registro base, y Logging Analytics cuando necesitas correlación y búsqueda a mayor escala — ambos cubiertos en la Parte 3 (OCI).

Esto corresponde a la sección de logging de ambos benchmarks CIS y a la categoría DE.CM (Continuous Monitoring) de NIST CSF 2.0.

Caso real: en 2024 se registraron varios incidentes donde la ausencia de logs dificultó la respuesta, alargando tiempos de recuperación y pérdidas económicas. Más en INCIBE.

Recomendación: asegúrate de que todo sistema crítico genere logs y los envíe a una solución centralizada como un SIEM. Un log que nadie revisa tampoco sirve de mucho, pero es el primer paso.

Checklist Rápido

Antes de dar por cerrada tu revisión de configuración, confirma:

  • Ninguna credencial ni Service Account/usuario local sigue con valores por defecto.
  • Contraseñas y claves son únicas por sistema; secretos centralizados en Secret Manager (GCP) u OCI Vault.
  • No hay reglas de firewall/Security List abiertas a 0.0.0.0/0 en puertos de administración.
  • Preferiste NSGs sobre Security Lists (OCI) o reglas por tag/Service Account (GCP) donde la granularidad importa.
  • El escaneo de vulnerabilidades nativo (Security Command Center / OCI Vulnerability Scanning) está activo y sin hallazgos críticos abiertos.
  • Cloud Guard / Chronicle (o tu EDR de endpoint) están habilitados y con alertas monitoreadas.
  • Logging & Audit / Cloud Logging están activos en todos los recursos críticos y centralizados en un SIEM.

Conclusión

La mayoría de estos errores son evitables desde el diseño: cambiar credenciales por defecto, cerrar lo que no se usa, mantener software soportado y no bajar la guardia con logs y EDR. En la nube, la diferencia es que casi todos tienen una herramienta nativa que los detecta por ti — Security Command Center, Cloud Guard, Vulnerability Scanning — el problema rara vez es la falta de tecnología, es no activarla. Si quieres profundizar en el marco general (responsabilidad compartida, CSPM) o en la implementación específica por proveedor, revisa la Parte 1, la Parte 2 (GCP) y la Parte 3 (OCI) de la serie.