Seguridad en la nube (Parte 3): lo que te toca proteger en OCI

En la Parte 1 vimos los pilares generales del modelo de responsabilidad compartida. En la Parte 2 los aterrizamos en GCP. Ahora le toca a Oracle Cloud Infrastructure, y el mensaje de fondo no cambia: Oracle asegura la nube, tú aseguras lo que corre en ella.

OCI tiene su propio vocabulario para resolver los mismos problemas que ya viste en GCP: identidad, detección de misconfiguraciones, cifrado, y red. Si vienes de AWS o GCP, algunos términos te van a sonar raros al principio — Compartments, Dynamic Groups, Security Zones — pero la lógica de fondo es la misma que veníamos armando en la serie. Vamos por partes.

1. Gestión de identidades con OCI IAM

Identity Domains

Un Identity Domain es el contenedor que particiona usuarios, grupos, configuración de SSO, OAuth y políticas de MFA dentro de tu tenancy. Es el equivalente de OCI a la capa de identidad de nivel organización que ya conoces de otras nubes.

Cada tenancy nace con un Identity Domain por defecto, pero puedes crear varios para separar, por ejemplo, identidades de producción de las de desarrollo, o para delegar administración a distintas unidades de negocio sin mezclar sus configuraciones de autenticación. Ojo con el tier: no todas las funciones de MFA o federación están disponibles en el tier gratuito del Identity Domain — si vas a exigir MFA obligatorio o SSO con un IdP externo, confirma que tu tenancy tiene el tier adecuado antes de diseñar la arquitectura sobre ese supuesto.

Dynamic Groups + Instance Principals

Este es uno de esos mecanismos que, una vez que lo entiendes, te preguntas por qué no lo usabas antes. Un Dynamic Group agrupa instancias (o recursos) según reglas de coincidencia — por compartment, por tag, por OCID — en lugar de agrupar usuarios humanos.

Cuando le das permisos a un Dynamic Group mediante una política, las instancias que caen dentro de ese grupo se autentican usando Instance Principals: certificados que OCI genera y rota automáticamente para cada instancia. Nunca necesitas embeber una API key en el servidor ni preocuparte por rotarla a mano. Si conoces Workload Identity Federation en GCP, es exactamente el mismo problema resuelto de forma equivalente: eliminar credenciales estáticas de la superficie de ataque.

# Ejemplo de regla para un Dynamic Group que agrupa instancias por compartment
All {instance.compartment.id = 'ocid1.compartment.oc1..aaaaaaaaXXXXXXX'}

Compartments

Los Compartments son la partición lógica de recursos — no de identidades — y funcionan como el alcance sobre el que aplicas políticas. Es la distinción que más confunde a quien llega de otras nubes: un Compartment no es un “proyecto” tipo GCP ni una “cuenta” tipo AWS Organizations. Es simplemente un límite administrativo para tus recursos (VCNs, instancias, buckets), separado del límite administrativo de tus identidades, que vive en el Identity Domain.

Puedes tener un solo Identity Domain gestionando usuarios que operan sobre decenas de Compartments distintos, cada uno con sus propias políticas de acceso.

Sintaxis de políticas OCI

El modelo de políticas de OCI es declarativo y default-deny: todo está negado salvo lo que explícitas. No existe un “Deny” — solo escribes lo que permites, y todo lo demás queda bloqueado por defecto.

Allow group Administradores-Red to manage virtual-network-family in compartment Produccion
Allow dynamic-group DG-App-Servers to read secret-bundles in compartment Produccion where target.secret.name = 'db-password'

La diferencia frente al modelo de roles predefinidos de GCP o AWS es que aquí compones el permiso con verbo + tipo de recurso + compartment + condición opcional. Es más verboso al principio, pero te da un control quirúrgico sobre el alcance exacto de cada permiso.

2. Detección de misconfiguraciones con Cloud Guard

Cloud Guard

Cloud Guard es el servicio de postura de seguridad de OCI, y viene incluido sin costo adicional en cualquier tenancy. Funciona con un modelo de target/detector/responder: defines un Target (el alcance, normalmente un compartment), le aplicas Detector Recipes (reglas que buscan problemas — buckets públicos, listas de seguridad demasiado permisivas, volúmenes sin cifrar, usuarios sin MFA) y, opcionalmente, Responder Recipes que ejecutan remediación automática o semi-automática cuando aparece un hallazgo.

Puedes arrancar con las recetas administradas por Oracle y, con el tiempo, clonarlas y ajustarlas a tus propios requisitos.

Security Zones: la pieza preventiva

Aquí está la distinción que vale la pena marcar bien clara: Cloud Guard es detectivo — encuentra el problema después de que ocurrió. Security Zones es preventivo — bloquea la acción antes de que se ejecute.

Cuando asocias un Compartment a una Security Zone, cualquier operación que viole las políticas de esa zona (crear un bucket público, aplicar una configuración de red que no cumpla con el estándar definido, etc.) es rechazada en el momento, no detectada después. Es la diferencia entre una alarma que suena cuando ya entraron y una puerta que directamente no se abre.

Usar ambos servicios juntos — Security Zones para lo que nunca debería pasar, Cloud Guard para todo lo demás que sí necesitas monitorear y, en algunos casos, remediar automáticamente — es el patrón recomendado.

Findings mapeados al CIS OCI Foundations Benchmark

Los hallazgos de Cloud Guard se pueden mapear directamente contra el CIS Oracle Cloud Infrastructure Foundations Benchmark v3.1.0, actualizado en marzo de 2026 con ajustes menores para mantenerse alineado con cambios recientes en la interfaz y en la estructura de eventos de la plataforma OCI. Si tu organización necesita evidenciar cumplimiento frente a un framework de terceros, este mapeo te ahorra bastante trabajo manual de auditoría.

Vulnerability Scanning Service

Como complemento a Cloud Guard, el Vulnerability Scanning Service escanea hosts (instancias de cómputo) y, según el caso, imágenes de contenedores, buscando CVEs conocidos y problemas de configuración a nivel de sistema operativo. Es la pieza que llena el hueco que Cloud Guard no cubre: Cloud Guard mira configuración de la plataforma, el Vulnerability Scanning Service mira el software que corre dentro de tus instancias.

3. Monitoreo y respuesta con OCI Logging + Audit

Audit Service

El servicio de Audit registra automáticamente todas las llamadas a la API a nivel de tenancy — quién hizo qué, cuándo, desde dónde. Está activo por defecto, no lo tienes que habilitar, y es tu fuente de verdad para cualquier investigación forense o requerimiento de cumplimiento.

Logging Analytics: la pieza de correlación (no un SIEM)

Logging Analytics es donde OCI centraliza y correlaciona logs de distintas fuentes — Audit, VCN Flow Logs, logs de aplicación. Piénsalo como una plataforma de análisis y búsqueda avanzada de logs dentro de OCI, no como una solución completa de detección y respuesta. Te da correlación y búsqueda potentes, pero si necesitas las capacidades completas de un SIEM (correlación entre múltiples nubes, playbooks de respuesta compleja, threat intelligence integrada), muchas organizaciones terminan integrando Logging Analytics con un SIEM de terceros vía Streaming o Service Connector Hub.

Responders automáticos

Los Responder Recipes de Cloud Guard pueden disparar acción automática sobre patrones específicos — por ejemplo, aislar una instancia si detecta comportamiento consistente con criptominería, o bloquear una IP tras un patrón de fuerza bruta contra la consola. Es la parte donde detección y respuesta dejan de ser dos pasos manuales separados.

4. Cifrado y gestión de secretos con OCI Vault

Vault (KMS)

OCI Vault gestiona tus claves de cifrado y soporta claves administradas por el cliente (customer-managed keys), respaldadas por HSM si tu caso de uso lo exige. Como en cualquier KMS, el modelo se apoya en dos niveles: una Master Encryption Key (MEK) que nunca sale del Vault, y Data Encryption Keys (DEK) que esa master key cifra y descifra bajo demanda para proteger tus datos. Esto te da control real sobre el ciclo de vida de la clave — rotación, revocación, quién puede usarla — en lugar de depender únicamente de las claves gestionadas por Oracle.

Vault Secrets

Vault Secrets es tu gestor de credenciales, API keys y strings de conexión, con rotación y auditoría de acceso incluidas. Es el equivalente funcional a Secret Manager en GCP o Secrets Manager en AWS — mismo problema, misma solución, distinto nombre.

Cifrado por defecto

Por defecto, OCI cifra los datos en reposo con claves administradas por Oracle, sin que tengas que configurar nada. Si necesitas control granular sobre la clave (por requisito regulatorio, por ejemplo), ahí es donde entran las customer-managed keys de Vault.

5. Hardening de red: VCN, NSGs, Bastion, WAF

NSGs vs. Security Lists

Los Network Security Groups (NSGs) operan a nivel de VNIC — la interfaz de red de cada instancia individual. Las Security Lists operan a nivel de subnet, aplicando las mismas reglas a todo lo que viva ahí. Si tienes varias instancias con distintos perfiles de exposición en la misma subnet, las Security Lists te obligan a un mínimo común denominador poco preciso. Los NSGs te dejan escribir reglas por instancia o por grupo funcional de instancias, independientemente de en qué subnet estén. Por eso NSGs es el enfoque más moderno y el que deberías preferir salvo que tengas una razón puntual para usar Security Lists.

Bastion Service

El Bastion service resuelve un problema clásico: necesitas acceso administrativo puntual a una instancia sin IP pública, pero no quieres mantener un bastion host expuesto a internet corriendo 24/7. Con Bastion creas sesiones de acceso temporales y con tiempo de vida limitado — cuando expiran, se acabó el acceso, sin que tengas que gestionar un servidor bastión permanente.

Service Gateway / Private Endpoints

El Service Gateway te permite consumir servicios de OCI (Object Storage, por ejemplo) desde tu VCN sin que el tráfico salga a internet público. Es la pieza que cierra la superficie de exposición cuando tus cargas de trabajo necesitan hablar con servicios de la plataforma pero no tienen — ni deberían tener — salida directa a internet.

OCI WAF

El Web Application Firewall de OCI cumple el mismo rol que Cloud Armor en GCP: protección a nivel de capa 7 contra SQL injection, XSS, bots maliciosos y patrones de tráfico anómalo, delante de tus aplicaciones web.

6. Frameworks de referencia

• CIS OCI Foundations Benchmark — la guía prescriptiva de configuración segura específica para OCI.
• NIST CSF 2.0 — el mismo framework que usamos en la Parte 2 para GCP, por consistencia de la serie.
• Zero Trust (NIST SP 800-207) — vale mencionar que OCI está diseñado con arquitectura zero-trust desde la base: virtualización de red fuera del host, raíz de confianza en hardware, y cifrado activo por defecto en toda la plataforma. No es un feature que activas — es parte de cómo Oracle construyó la infraestructura.

Cierre del trío

Parte 1 te dio los principios. Parte 2 los aterrizó en GCP. Esta Parte 3 los aterriza en OCI. Y el mensaje de fondo, después de recorrer tres nubes distintas, sigue siendo el mismo: las herramientas de seguridad están ahí, casi siempre incluidas sin costo adicional. El trabajo real — y donde la mayoría de los incidentes en la nube realmente ocurren — es configurarlas bien desde el día uno y mantenerlas alineadas a medida que tu tenancy crece.