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 — salvo en organizaciones creadas después del 3 de mayo de 2024, donde la política iam.automaticIamGrantsForDefaultServiceAccounts viene aplicada por defecto. Security Command Center las marca como hallazgo de severidad media 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 el cibercrimen alcanzó máximos históricos, con el robo de credenciales entre las tendencias del año y la IA volviendo más creíbles y precisos los ataques. 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 Federation 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 Secrets 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, 9 de ellas en texto plano.(https://elpais.com/tecnologia/2024-10-17/dos-entidades-de-ciberseguridad-detectan-filtraciones-de-informacion-personal-de-39-diputados-y-senadores-en-la-dark-web.html).

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: el caso de Capital One en 2019 es un ejemplo clásico: la brecha que expuso datos de más de 100 millones de personas se originó en un firewall de aplicaciones web (WAF) mal configurado en la nube. Más en Departamento de Justicia de EE. UU..

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, firewalls 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 gratuitas desde esa fecha, salvo los inscritos en el programa de Actualizaciones de Seguridad Extendidas (ESU). Más en Microsoft Support.

Otro caso reciente, ahora en infraestructura de red: en febrero de 2026, CISA emitió la directiva operativa vinculante BOD 26-02 tras detectar campañas de explotación generalizadas contra dispositivos perimetrales (firewalls, routers, balanceadores de carga y pasarelas VPN) que ya no reciben actualizaciones del fabricante, y ordenó a las agencias federales identificarlos y retirarlos. Más en CISA.

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 vulnerabilidades conocidas (CVE) en el sistema operativo y los paquetes de 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 marzo de 2025, S-RM publicó un incidente del grupo Akira en el que el EDR de la víctima puso en cuarentena el ransomware en un servidor Windows; los atacantes escanearon la red, encontraron una webcam Linux vulnerable sin ningún EDR instalado y cifraron archivos de la red desde ese dispositivo por SMB, sin que el equipo de seguridad lo notara.(https://www.s-rminform.com/latest-thinking/camera-off-akira-deploys-ransomware-via-webcam).

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 2023, el grupo Storm-0558 accedió a los buzones de Exchange Online de 22 organizaciones y más de 500 personas. El Departamento de Estado de EE. UU. lo detectó gracias a un log de acceso a buzones (MailItemsAccessed) que entonces solo estaba disponible con una licencia premium; tras el incidente, Microsoft amplió ese logging a más niveles de licencia. Más en CISA.

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.