Cloud Guard y Security Zones: la capa de prevención de OCI es mejor que su capa de detección

Oracle Cloud incluye dos servicios de seguridad que parecen similares y hacen cosas opuestas. Cloud Guard detecta: evalúa tu tenancy contra recetas de reglas detectoras y produce problemas. Las Security Zones previenen: un compartimento designado como zona de seguridad rechaza la creación de un recurso que viole su política.

El segundo es el más interesante de los dos, y está infrautilizado porque llega con una restricción que parece rígida hasta que te das cuenta de que ese es el objetivo.

Security Zones: la prevención como propiedad del compartimento

Designa un compartimento como zona de seguridad con una receta y OCI impone la receta en la API. Intenta crear un bucket público dentro y la llamada falla. Intenta lanzar una instancia con IP pública donde la receta lo prohíbe y la llamada falla. No hay ningún hallazgo que triar porque el recurso no existe.

La receta de máxima seguridad cubre lo que más importa:

• Sin buckets públicos, sin subredes públicas para recursos de base de datos.
• Los recursos deben usar claves gestionadas por el cliente desde OCI Vault.
• Las bases de datos e instancias deben crearse desde orígenes aprobados.
• Los recursos de la zona no pueden moverse a un compartimento fuera de ella — la regla que se olvida y que es justamente lo que impide una exfiltración silenciosa por reubicación.
• Los volúmenes de bloque y de arranque deben estar cifrados con tus claves y tener políticas de copia.

La objeción habitual es que esto es demasiado rígido para un compartimento de propósito general, y es correcta. El uso adecuado es dirigido: designa como zona de seguridad el compartimento con datos regulados y deja el resto bajo la detección de Cloud Guard. Una zona pequeña y estrictamente impuesta vale más que una grande y auditada.

Empieza con una receta personalizada menos estricta si la máxima bloquea trabajo legítimo, pero no empieces sin nada. La capacidad equivalente en otras nubes —las restricciones de org policy de GCP, Azure Policy en modo Deny— es el único tipo de control que hace permanente una mejora de postura en lugar de un proyecto de remediación que se repite al año siguiente.

Cloud Guard: actívalo bien y después tría por exposición

Cloud Guard es gratuito y debería estar activado en la raíz de la tenancy, con la región de informes fijada y todos los compartimentos en alcance. Activa la receta del benchmark CIS de OCI junto a la predeterminada — mapea directamente a lo que preguntará un auditor.

Después tría los problemas igual que en cualquier otra nube: alcanzable desde internet y concede o expone credenciales primero. En concreto, en una tenancy de OCI recién revisada, la lista que importa suele ser:

• Buckets con acceso público o peticiones preautenticadas de larga vida.
• Listas de seguridad o NSG que permiten 0.0.0.0/0 en SSH, RDP o puertos de base de datos.
• Usuarios con claves de API y políticas amplias, y usuarios sin MFA.
• Políticas manage all-resources fuera del grupo de Administradores — los hallazgos de las políticas y grupos dinámicos de OCI.
• Instancias con IP públicas en compartimentos que no deberían tenerlas.

Las reglas de respuesta pueden actuar automáticamente sobre algunos tipos de problema — desactivar un bucket público, parar una instancia. Activa aquellas cuya acción sea inequívocamente segura y deja el resto como notificaciones. Una respuesta automática que para una instancia de producción durante un falso positivo enseña al equipo a desactivar las respuestas del todo.

Manda los problemas a algún sitio

Los problemas de Cloud Guard pueden publicarse en el servicio Events de OCI y de ahí a Notifications, a una Function o a un tema de Streaming. Conecta los problemas de riesgo alto a tu canal de guardia y el resto a tickets, y deja de esperar que alguien abra la consola. Es la misma lección que convertir GuardDuty en un turno que alguien atiende, y es el paso que más a menudo se salta.

El resto de la línea base

Cloud Guard y las Security Zones no lo cubren todo. Junto a ellos:

• Los logs de auditoría están activos por defecto con un periodo de retención — extiéndelo y exporta a un bucket en un compartimento en el que los equipos de carga no puedan escribir, con reglas de retención y versionado de objetos.
• OCI Vault para claves y secretos, con una clave maestra gestionada por el cliente para todo lo regulado.
• Flow logs de VCN y logs de servicio hacia OCI Logging, y una búsqueda guardada que alguien pueda ejecutar de verdad durante un incidente.
• El Vulnerability Scanning Service para instancias e imágenes de contenedor en OCI Registry, que es gratuito y que nadie activa.
• El servicio Bastion en lugar de saltos con IP públicas, para que el acceso SSH sea una sesión con tiempo limitado y no un puerto abierto.

Recorremos todo este conjunto en un diagnóstico de seguridad, y los escáneres open source de nuestro artículo de herramientas también cubren OCI si quieres una segunda opinión antes de actuar.

Qué hacer esta semana

Activa Cloud Guard en la raíz de la tenancy con la receta CIS, si no lo está ya. Después elige el compartimento con tus datos más sensibles y lee la receta de máxima seguridad contra él — no para activarla todavía, sino para ver cuántas de sus reglas ya cumples. Esa lista de huecos es tu backlog real de seguridad.