Manual de consola — Seguridad cloud de extremo a extremo

Este manual construye desde la consola, haciendo clic, lo mismo que el módulo de Terraform de este laboratorio crea en un apply. No hace falta Terraform ni la CLI de OCI para seguirlo: la CLI aparece solo en los bloques de verificación, donde una línea confirma en un segundo lo que en la consola tomaría tres pantallas. El laboratorio se despliega en un tenancy de prueba, desechable; no se toca ningún ambiente con datos reales.

---

1. Qué se construye y para qué

Se construyen dos laboratorios y se auditan con el mismo script.

El primero está hecho a la ligera: una sola subred pública, servidores de aplicación con IP pública, la security list por defecto tal como OCI la entrega, un balanceador sin filtro de aplicación y ningún registro de tráfico. No es una caricatura: es cómo queda un ambiente que se levantó para salir del paso y nadie volvió a mirar.

El segundo está hecho bien: tres capas de red, nada con IP pública salvo el balanceador, reglas de tráfico por función, un firewall de aplicación en el borde, acceso administrativo por bastión con sesiones que expiran, registro de flujos de red, alertas ante cambios críticos y detección continua de postura.

La decisión que el laboratorio ayuda a tomar no es si se compra seguridad, sino cuál es el mínimo de controles que un ambiente debe cumplir antes de recibir tráfico real, y quién responde por cada uno. La auditoría pone números sobre la mesa para que esa conversación no sea de opiniones.

El contraste, medido

   A · construido a la ligera             B · construido bien
   ------------------------------------   ------------------------------
   una subred, publica                    tres subredes, una publica
   dos instancias con IP publica          instancias sin IP publica
   SL por defecto: 22 desde 0.0.0.0/0     SL por defecto endurecida
   balanceador sin WAF                    balanceador con WAF
   sin flow logs                          flow logs en la subred de app
   acceso SSH directo desde internet      bastion con TTL y lista de CIDR
   ------------------------------------   ------------------------------
   5 hallazgos altos                      0 hallazgos altos
   3 medios · 2 controles que cumplen     2 medios · 6 que cumplen

Los cinco hallazgos altos del laboratorio A son: balanceador público sin WAF, dos instancias con IP pública y dos security lists que abren el puerto 22 a 0.0.0.0/0 —una de ellas, la que OCI crea sola con cada VCN—. Cloud Guard aparece como sexto hallazgo alto cuando está apagado; en la corrida medida ya estaba encendido.

Arquitectura del laboratorio B

                          Internet
                             | 80 / 443
        +--------------------v--------------------+
        |  Load Balancer publico  +  WAF          |  subred publica
        |  NSG-lb: entra 80 y 443 desde internet  |  10.40.1.0/24
        +--------------------+--------------------+
                             | 80  (solo desde NSG-lb)
        +--------------------v--------------------+
        |  app-1      app-2      sin IP publica   |  subred privada app
        |  NSG-app: 80 desde NSG-lb               |  10.40.2.0/24
        |           22 desde el endpoint bastion  |  salida: NAT + SGW
        +---+-----------------------------+-------+
            | 3306 (solo desde NSG-app)   | 22
        +---v---------------+    +---------+---------+
        |  subred privada   |    |  OCI Bastion      |
        |  datos            |    |  sesion con TTL   |
        |  10.40.3.0/24     |    |  lista de CIDR    |
        |  sin ruta a       |    +-------------------+
        |  internet         |
        +-------------------+

   Flow logs en la subred de app · Events + Notifications ante cambios de
   red e IAM · Cloud Guard sobre el tenancy · Security Zone en su propio
   compartimento

La capa de datos se construye aunque este laboratorio no despliegue ninguna base de datos: así el diagrama de tres capas se puede mostrar completo en la consola, y la regla «el puerto de la base solo se alcanza desde la aplicación» existe como objeto y no como intención.

---

2. Equivalencias con otras nubes

Solo los servicios que aparecen en este manual.

Dos diferencias que sorprenden a quien llega de AWS o Azure:

• Un NSG se referencia a otro como origen o destino. Una regla puede decir literalmente "acepto el puerto 80 cuando el origen es el NSG del balanceador", sin escribir CIDR ni mantener listas de IP. Es la razón por la que aquí las security lists quedan casi vacías.
• Los compartimentos no son grupos de recursos. Son la unidad sobre la que se escriben las políticas de IAM, se mide el costo y se aplican las Security Zones.

---

3. Prerrequisitos

3.1 Permisos

Quien siga este manual necesita, sobre el compartimento del laboratorio, permisos para crear red, cómputo, balanceadores, WAF, bastión y logs; y sobre el tenancy, permiso para habilitar Cloud Guard y para crear la Security Zone y su receta. Si es administrador del tenancy de prueba, ya los tiene.

Si prefiere un usuario acotado, el conjunto mínimo se ve así:

Allow group LabSeguridad to manage virtual-network-family in compartment lab
Allow group LabSeguridad to manage instance-family in compartment lab
Allow group LabSeguridad to manage load-balancers in compartment lab
Allow group LabSeguridad to manage waf-family in compartment lab
Allow group LabSeguridad to manage bastion-family in compartment lab
Allow group LabSeguridad to manage logging-family in compartment lab
Allow group LabSeguridad to manage ons-family in compartment lab
Allow group LabSeguridad to manage cloudevents-rules in compartment lab
Allow group LabSeguridad to manage cloud-guard-family in tenancy
Allow group LabSeguridad to manage security-zone in tenancy

Las familias de recursos exactas cambian entre versiones del servicio; si la consola rechaza una operación, el mensaje nombra el verbo y el tipo que faltan [VALIDAR].

3.2 Qué debe existir antes de empezar

3.3 Límites de una cuenta de prueba

Antes de empezar conviene mirar los límites, porque el error de límite aparece a la mitad de la construcción y obliga a devolverse.

Consola de OCIGovernance & Administration › Limits, Quotas and Usage

Si el límite de balanceadores es 1, construya un laboratorio a la vez y audite cada uno por separado. El contraste se pierde en simultaneidad, no en contenido: las dos salidas del script quedan guardadas y se comparan después.

3.4 Valores usados en todo el manual

Los OCID que aparecen en los ejemplos son ficticios y se ven como ocid1.compartment.oc1..aaaaEJEMPLO.

---

4. Compartimentos del laboratorio

Todo cuelga de un compartimento padre para que el presupuesto, el filtro de costos y el borrado final cubran los dos laboratorios de una vez.

   lab                      <- el presupuesto apunta aqui
   |- lab-01-elasticidad          <- laboratorio A, el construido a la ligera
   |- lab-02-seguridad          <- laboratorio B, el construido bien
   `- lab-02-zona-segura     <- vacio; se le asocia la Security Zone

Consola de OCIIdentity & Security › Compartments › Create Compartment

1. Cree el padre.

1. En Tags, agregue dos etiquetas libres. Sirven para filtrar el costo después y para reconocer lo desechable de un vistazo.

1. Repita Create Compartment tres veces más, con lab como Parent Compartment, para crear lab-01-elasticidad, lab-02-seguridad y lab-02-zona-segura.
2. Anote los cuatro OCID. Los va a necesitar en la auditoría y en la Security Zone.

Un compartimento recién creado tarda un par de minutos en propagarse. Si aparece en la lista pero un formulario no lo ofrece todavía, recargue la página y espere dos minutos antes de concluir que algo falló.

---

5. Cloud Guard

Cloud Guard va primero, antes de construir nada. No porque la construcción lo necesite, sino porque evalúa los recursos cuando cambian y en barridos periódicos: si se habilita al final, la consola sale vacía justo cuando se quiere mostrar algo. Habilitado antes, cuando el laboratorio A lleve unas horas arriba ya habrá problemas detectados sobre él.

Consola de OCIIdentity & Security › Cloud Guard

1. Abra Cloud Guard. Si el servicio nunca se ha habilitado en este tenancy, la consola presenta directamente el asistente de habilitación.
2. Complete el asistente.

1. El asistente muestra que va a crear las políticas de servicio que Cloud Guard necesita para leer los recursos del tenancy. Acéptelas. Sin ellas el servicio queda habilitado pero ciego.
2. Confirme y espere. La habilitación tarda poco; el primer barrido completo, más.

Verificación:

oci cloud-guard configuration get --compartment-id "<ocid-tenancy>" \
  --query 'data.status'
# -> "ENABLED"

5.1 Dónde se ven los hallazgos

Consola de OCIIdentity & Security › Cloud Guard › Problems

Deje pasar el tiempo. Cuando el laboratorio A esté arriba, esta pantalla debería mostrar problemas sobre sus recursos: instancias con IP pública, puerto de administración abierto, balanceador expuesto. Filtre por compartimento para separar el ruido del resto del tenancy. Cloud Guard detecta; no impide, y esa distinción es la que hace falta para entender el capítulo 17.

---

6. El laboratorio A — el construido a la ligera

Este laboratorio existe para ser auditado. Se construye rápido, a propósito, con las decisiones que se toman cuando el objetivo es que funcione hoy. Si ya tiene desplegado el laboratorio de elasticidad del módulo anterior, úselo y salte este capítulo: es exactamente este ambiente. Si no, lo que sigue reproduce lo mínimo para que la auditoría tenga qué encontrar.

Consola de OCINetworking › Virtual Cloud Networks › Create VCN

1. Cree la VCN.

1. Dentro de la VCN, cree un Internet Gateway con Create Internet Gateway, nombre lab01-igw.
2. En Route Tables, edite la tabla por defecto y agregue una regla:

1. En Security Lists, entre a la lista por defecto y no la toque. Esa es la gracia: OCI la crea con el puerto 22 abierto a 0.0.0.0/0, y así se queda.
2. Cree una segunda security list, lab01-sl-app, con dos reglas de entrada:

1. Cree la subred con Create Subnet.

1. Cree dos instancias en esa subred, con IP pública asignada, imagen Oracle Linux 9 y shape VM.Standard.E4.Flex de 1 OCPU. El detalle está en el capítulo 11; aquí la única diferencia es que sí se asigna IP pública.
2. Cree un balanceador público en esa misma subred, con un listener HTTP en el 80 y las dos instancias como backends (capítulo 12). No le ponga WAF.

Con eso el laboratorio A está listo para producir cinco hallazgos altos.

Este laboratorio no se queda encendido. Tiene dos servidores con IP pública y el puerto 22 abierto a internet. En un tenancy de prueba, desechable y vigilado, durante unas horas, es un ejercicio; encendido una semana es un incidente esperando ocurrir, porque los escáneres encuentran un 22 abierto en minutos, no en días. Bórrelo el mismo día (capítulo 20).

---

7. El laboratorio B — VCN y gateways

A partir de aquí se construye el laboratorio bien hecho, en el compartimento lab-02-seguridad.

Consola de OCINetworking › Virtual Cloud Networks › Create VCN

1. Cree la VCN.

Use Create VCN, no el asistente de VCN con subredes. El asistente crea una topología que después hay que deshacer.

1. Entre a la VCN. En Internet Gateways › Create Internet Gateway:

1. En NAT Gateways › Create NAT Gateway:

1. En Service Gateways › Create Service Gateway:

La opción de servicios ofrece dos alternativas: una solo para Object Storage y otra para todos los servicios de la red de servicios de Oracle. Elija la segunda. El agente de cómputo y el plugin de bastión hablan con el plano de control de OCI a través de ella; con la opción restringida a Object Storage, el bastión no funciona y el síntoma no apunta a la causa.

7.1 Por qué tres gateways y no uno

La capa de datos solo tiene Service Gateway: una base de datos no necesita navegar. Lo primero que intenta un servidor comprometido es salir, y controlar la salida es lo que limita el daño.

---

8. Tablas de ruteo

Cada capa tiene su propia tabla. Es el mecanismo que hace que "la capa de datos no sale a internet" sea un hecho de la plataforma y no una nota en un documento.

Consola de OCINetworking › Virtual Cloud Networks › lab02-vcn › Route Tables › Create Route Table

1. Cree la tabla de la capa pública.

1. Cree la tabla de la capa de aplicación, con dos reglas. Use + Another Route Rule para agregar la segunda.

1. Cree la tabla de la capa de datos, con una sola regla.

Fíjese en lo que no tiene la tabla de datos: ninguna regla hacia 0.0.0.0/0. No hay ruta. No es que el tráfico se filtre y se descarte; es que no hay camino.

---

9. Subredes y la security list por defecto

9.1 Endurecer la security list por defecto — primero

Esto va antes de crear las subredes, porque una subred creada sin especificar security list hereda la por defecto, y la por defecto que OCI entrega trae el puerto 22 abierto a 0.0.0.0/0.

Consola de OCINetworking › Virtual Cloud Networks › lab02-vcn › Security Lists › Default Security List for lab02-vcn

1. Abra la lista por defecto y mire sus reglas de entrada. Verá una regla TCP con origen 0.0.0.0/0 y puerto destino 22. Esa regla es el hallazgo de seguridad más repetido de OCI, y casi nadie la revisa porque "esa lista no está asociada a nada".
2. Borre la regla del puerto 22 con el menú de acciones de la fila.
3. Deje o agregue las dos reglas ICMP. Sin ellas, el descubrimiento de MTU de ruta se rompe y las conexiones fallan de una manera difícil de diagnosticar.

1. En las reglas de salida, deje la regla que permite todo hacia 0.0.0.0/0. El control de salida real lo hacen las tablas de ruteo y los NSG.
2. Renombre la lista a lab02-sl-default-endurecida si la consola lo permite, para que se note en el inventario que alguien la tocó.

9.2 Las tres subredes

Consola de OCINetworking › Virtual Cloud Networks › lab02-vcn › Subnets › Create Subnet

1. Subred pública, solo para el balanceador.

1. Subred privada de aplicación.

1. Subred privada de datos.

Marcar una subred como Private Subnet hace algo más fuerte que "no asignar IP pública por defecto": la plataforma impide asignarla. Cuando alguien cree una instancia ahí dentro dentro de seis meses, la opción de IP pública aparecerá deshabilitada, con la subred como explicación. Es un control que sobrevive al olvido.

---

10. Network Security Groups

Las security lists quedaron casi vacías a propósito. El filtrado real de este laboratorio vive en tres NSG, uno por función.

   internet --80/443--> [nsg-lb] --80--> [nsg-app] --3306--> [nsg-datos]
                                             ^
                          bastion --22-------'
                          (solo desde la IP privada del endpoint)

10.1 Crear los tres grupos

Consola de OCINetworking › Virtual Cloud Networks › lab02-vcn › Network Security Groups › Create Network Security Group

1. Cree lab02-nsg-lb. En la pantalla de reglas del asistente, no agregue ninguna todavía: presione siguiente y cree el grupo vacío.
2. Cree lab02-nsg-app, también vacío.
3. Cree lab02-nsg-datos, también vacío.

Se crean los tres primero porque las reglas se referencian entre sí: la del NSG de aplicación necesita que el NSG del balanceador ya exista para seleccionarlo.

10.2 Reglas del NSG del balanceador

Consola de OCINetworking › Virtual Cloud Networks › lab02-vcn › Network Security Groups › lab02-nsg-lb › Security Rules › Add Rules

1. Entrada desde internet en el 80.

1. Entrada desde internet en el 443, con los mismos campos y puerto destino 443.
2. Salida hacia la aplicación, y solo hacia la aplicación.

El tipo de destino Network Security Group es la pieza interesante: no se escribe un CIDR ni una IP, se nombra el grupo. Si mañana se agregan cuatro servidores más a la capa de aplicación, esta regla no cambia.

10.3 Reglas del NSG de la aplicación

Consola de OCINetworking › Virtual Cloud Networks › lab02-vcn › Network Security Groups › lab02-nsg-app › Security Rules › Add Rules

1. Entrada en el 80, solo desde el balanceador.

Note lo que esta regla no dice: no dice "desde la subred pública". Un recurso cualquiera colocado en la subred pública no alcanza la aplicación; solo la alcanza lo que esté dentro del NSG del balanceador.

1. La regla del puerto 22 se agrega después, en el capítulo 14, porque necesita la IP privada del endpoint del bastión, que todavía no existe. Déjela pendiente.

10.4 Reglas del NSG de datos

Consola de OCINetworking › Virtual Cloud Networks › lab02-vcn › Network Security Groups › lab02-nsg-datos › Security Rules › Add Rules

1. Entrada en el puerto de la base, solo desde la aplicación.

En este laboratorio no hay base de datos: la regla está para que la conversación sobre la capa de datos tenga un objeto al que apuntar.

---

11. Instancias de aplicación, sin IP pública

Dos instancias, en la subred privada de aplicación, con el plugin de bastión habilitado y una aplicación mínima que responde en el 80.

Consola de OCICompute › Instances › Create Instance

1. Datos básicos.

1. En Image and shape, presione Change image y Change shape.

1. En Networking, seleccione la VCN y la subred privada.

1. En la misma sección, active el uso de NSG y seleccione el grupo de la aplicación.

1. En Add SSH keys, pegue el contenido de su llave pública. Aunque el acceso sea por bastión, la llave se instala igual: el bastión transporta la sesión, no reemplaza la autenticación del sistema operativo.
2. Abra Show advanced options y vaya a la pestaña de Oracle Cloud Agent. Verifique que el plugin Bastion esté habilitado. Si no lo está, actívelo aquí. Sin este plugin no hay sesión SSH administrada, solo port forwarding.
3. En la pestaña de opciones de gestión, en el campo de datos de inicialización (user data), pegue la configuración de cloud-init del laboratorio o súbala como archivo. Lo que hace es instalar una aplicación mínima en Python que responde:

1. Presione Create. La instancia queda en aprovisionamiento unos minutos.
2. Repita los pasos 1 a 8 para lab02-app-2, con hostname app2.

11.1 Dos detalles que rompen el laboratorio si se omiten

El cortafuegos del sistema operativo. Oracle Linux trae firewalld activo y con el puerto 80 cerrado. Si no se abre, el health check del balanceador nunca pasa y los backends quedan permanentemente en estado crítico, sin ninguna pista de red que lo explique —los NSG están bien, las rutas están bien—. El cloud-init del laboratorio lo abre. Si crea la instancia sin cloud-init, tendrá que entrar por el bastión y ejecutar:

sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --reload

El plugin de bastión tarda. Después de que la instancia aparece como Running, el plugin necesita unos minutos más para reportarse; diez minutos desde la creación es una espera razonable antes de la primera sesión administrada. Si intenta antes, la sesión falla con un mensaje sobre el recurso destino que no menciona el plugin.

Verificación:

oci compute instance list-vnics --instance-id "<ocid-instancia>" \
  --query 'data[0].{privada:"private-ip",publica:"public-ip"}'
# -> publica debe venir en null

---

12. Balanceador de carga

Consola de OCINetworking › Load Balancers › Load Balancer › Create Load Balancer

1. Detalles del balanceador.

1. Red del balanceador. Es la única parte de la arquitectura que vive en la subred pública.

1. En la pantalla de backends, elija la política y agregue las dos instancias con Add Backends.

1. Configure el health check en la misma pantalla.

1. Configure el listener.

1. Presione Submit. El balanceador tarda varios minutos en quedar activo.
2. Anote la IP pública que aparece en la página de detalle. Se usa en los capítulos de WAF y de validación.

12.1 Sobre el listener sin TLS

Este listener es HTTP porque el laboratorio no debe depender de un certificado. En un ambiente con datos, el listener es 443 con certificado gestionado y el 80 únicamente redirige. Es el control B-03 del checklist, y el script de auditoría lo reporta como hallazgo medio en los dos laboratorios, incluido el bien construido. Está bien que lo reporte: un hallazgo en el laboratorio "correcto" prueba que el script no está amañado.

---

13. WAF sobre el balanceador

Aquí está la demostración central del borde: el mismo ataque contra dos balanceadores, uno responde 200 y el otro 403.

El WAF de OCI se compone de dos objetos: una política (las reglas) y un firewall (la aplicación de esa política sobre un punto de exigencia, en este caso el balanceador). En la consola el asistente los crea casi de corrido, pero conviene saber que son dos cosas, porque en la lista de recursos aparecen separados.

13.1 Las llaves de capacidad y sus versiones — verificar antes

Consola de OCIIdentity & Security › Web Application Firewall › Policies › Create WAF policy

Antes de tocar nada, entienda el punto que hace fallar esta parte del laboratorio más que ningún otro.

Si tiene la CLI a mano, la verificación es una línea por llave:

for k in 941100 942100; do
  oci waf protection-capability list --compartment-id "<ocid-tenancy>" \
    --key "$k" --all \
    --query 'data.items[].{llave:key,version:version,nombre:"display-name"}' \
    --output table
done

Si solo tiene consola, la misma información está en la tabla de selección de capacidades del asistente: cada capacidad muestra las versiones disponibles en la región. Anótelas antes de continuar.

13.2 Crear la política

1. Datos básicos de la política.

1. En el paso de selección del punto de exigencia, elija el balanceador como destino de la política.

1. Defina las dos acciones que la política va a usar. Una permite y la otra devuelve un 403 con cuerpo propio.

El cuerpo propio no es cosmético: cuando alguien pregunte si lo bloqueó el WAF o la aplicación, la respuesta es el texto que aparece en pantalla.

1. Agregue la regla de control de acceso, que se evalúa antes que la protección.

1. Agregue la regla de protección con las dos capacidades OWASP.

Al agregar cada capacidad, mire la columna de versión de esa fila y fíjela en el valor que verificó en 13.1. No asuma que la segunda hereda la de la primera.

1. Revise el resumen y presione Create. La política y el firewall quedan creados y asociados al balanceador.
2. Espere. La política tarda unos minutos en propagarse al punto de exigencia. Si prueba inmediatamente y todo devuelve 200, no concluya que las versiones están mal: espere cinco minutos y vuelva a probar.

Verificación:

oci waf web-app-firewall get --web-app-firewall-id "<ocid-waf>" \
  --query 'data."lifecycle-state"'
# -> "ACTIVE"

13.3 Qué hace y qué no hace el WAF

El WAF no reemplaza el código seguro: compra tiempo cuando aparece una vulnerabilidad nueva y reduce el ruido de los ataques automatizados. Los payloads de la validación son de libro de texto; un atacante con intención es más sutil. Conviene decirlo antes de que lo pregunten.

La regla de control de acceso sobre /admin es más robusta que las reglas OWASP y no depende de versiones de capacidad: si algo falla, esa fila sigue funcionando.

---

14. Bastión

El bastión es el capítulo donde el laboratorio hace su afirmación más incómoda: el puerto 22 abierto a internet no es una necesidad operativa, es una costumbre.

14.1 Crear el bastión

Consola de OCIIdentity & Security › Bastion › Create Bastion

1. Complete el formulario.

El nombre del bastión admite solo caracteres alfanuméricos. No acepta guiones, que es por lo que este recurso rompe la convención de nombres del resto del laboratorio. Si escribe lab02-bastion, el formulario lo rechaza con un mensaje sobre el formato del nombre.

1. Presione Create Bastion y espere a que quede activo.
2. Anote la IP privada del endpoint del bastión, que aparece en la página de detalle. Es un valor dentro de 10.40.2.0/24, y se necesita en el paso 5.

14.2 Cerrar el círculo: la regla del puerto 22

Ahora que existe el endpoint, se puede escribir la regla que faltaba en el capítulo 10.

Consola de OCINetworking › Virtual Cloud Networks › lab02-vcn › Network Security Groups › lab02-nsg-app › Security Rules › Add Rules

1. Agregue la regla de entrada del 22.

Una máscara /32: un solo host. El puerto 22 de la aplicación existe y es alcanzable, pero desde exactamente una dirección de la red interna, que a su vez solo transporta sesiones autenticadas y con vencimiento.

14.3 Abrir una sesión

Consola de OCIIdentity & Security › Bastion › lab02bastion › Sessions › Create Session

1. Elija el tipo de sesión y complete.

1. Presione Create session. Tarda de uno a dos minutos.
2. Cuando la sesión quede activa, use el menú de acciones de la fila para copiar el comando SSH que la consola genera. Ese comando trae un ProxyCommand que salta por el bastión.
3. Reemplace en el comando el marcador de la llave privada por la ruta a su llave, y ejecútelo.

14.4 Qué mirar una vez dentro

Ya conectado a la instancia, tres comandos cuentan la historia completa:

hostname                        # app1
ip -4 addr show | grep inet     # solo 10.40.2.x — ninguna IP publica
curl -s ifconfig.me             # sale por el NAT, no por una IP propia

La última línea suele sorprender: la instancia sí alcanza internet —actualiza paquetes, llama a una API— pero por el NAT Gateway. Internet no la alcanza a ella.

---

15. Flow logs

Sin registro de flujos, después de un incidente no hay forma de reconstruir quién habló con quién. Es un control barato y suele estar apagado.

Consola de OCIObservability & Management › Logging › Log Groups › Create Log Group

1. Cree el grupo de logs.

Consola de OCIObservability & Management › Logging › Logs › Enable Service Log

1. Habilite el log de servicio sobre la subred de aplicación.

1. En las opciones avanzadas, fije la retención.

1. Presione Enable Log. Los primeros registros tardan varios minutos en aparecer.
2. Genere tráfico —basta con abrir la IP del balanceador en el navegador unas veces— y vuelva al log. Use Explore Log o la búsqueda del propio log para ver las entradas.

Cada entrada trae origen, destino, puerto, protocolo, si el paquete fue aceptado o rechazado, y el momento. En una investigación real esa es la diferencia entre creer que entraron por ahí y saberlo, con hora y dirección.

Treinta días de retención es una decisión de laboratorio. En un ambiente con datos se decide con el equipo legal y el de seguridad, y los registros suelen enviarse a un SIEM o a Logging Analytics para correlacionarlos con los de aplicación y los de Audit.

---

16. Alertas ante cambios críticos

Un cambio de regla de red a las dos de la mañana debería despertar a alguien, no descubrirse una semana después. Este capítulo conecta dos servicios: Events, que escucha el plano de control, y Notifications, que entrega el correo.

16.1 El tema y la suscripción

Consola de OCIDeveloper Services › Application Integration › Notifications › Create Topic

1. Cree el tema.

1. Dentro del tema, use Create Subscription.

1. Vaya al correo y haga clic en el enlace de confirmación. Hasta que lo haga, la suscripción queda en estado pendiente y no llega ninguna alerta. Es el paso que más se olvida de todo el manual, y su síntoma —silencio— es indistinguible de "no ha pasado nada".

16.2 La regla de eventos

Consola de OCIObservability & Management › Events Service › Rules › Create Rule

1. Datos de la regla.

1. Agregue los tipos de evento. En la consola se eligen por servicio y luego por tipo; los identificadores correspondientes son:

Si algún tipo de evento no aparece en la lista de su región, quítelo y deje los de security list e IAM. La demostración funciona igual.

1. En Actions, agregue la acción de notificación.

1. Presione Create Rule.

16.3 Probar que funciona

1. Vaya a la VCN, entre a la security list por defecto y agregue cualquier regla inocua —por ejemplo, entrada ICMP desde el CIDR de la VCN—. Guarde.
2. Espere uno o dos minutos. El correo debe llegar con el detalle del evento: quién lo hizo, sobre qué recurso, a qué hora.
3. Quite la regla que agregó.

Ese correo es una alerta reactiva: avisa después de que el cambio ocurrió. El capítulo siguiente es la versión preventiva del mismo problema.

---

17. Security Zone

Cloud Guard detecta. Una Security Zone impide. La diferencia se resume así: detectar le avisa a las tres de la mañana; prevenir no lo despierta.

Una Security Zone asocia una receta de políticas a un compartimento. Desde ese momento, cualquier operación en ese compartimento que viole una política de la receta es rechazada por la plataforma en el momento de crearse. No hay remediación posterior, no hay ventana de exposición: el recurso no llega a existir.

17.1 La receta

Consola de OCIIdentity & Security › Security Zones › Recipes › Create Recipe

1. Datos de la receta.

1. En la lista de políticas disponibles, marque solamente la que prohíbe que los buckets de Object Storage tengan acceso público. Está en la categoría de restricción de acceso público; el nombre exacto en la consola describe la denegación de buckets públicos [VALIDAR el nombre exacto en su región].
2. Presione Create.

Por qué solo una política: la receta máxima que Oracle provee exige, entre otras cosas, llaves de Vault propias en buckets y volúmenes. Con esa receta, hasta el bucket privado del capítulo 17.3 sería rechazado, y el mensaje del ejercicio —lo que cumple pasa sin fricción, lo que no cumple no pasa— se pierde en un muro indiferenciado.

17.2 La zona

Consola de OCIIdentity & Security › Security Zones › Create Security Zone

1. Complete el formulario.

1. Presione Create. La zona queda asociada al compartimento vacío que se creó en el capítulo 4.

Se usa un compartimento vacío a propósito. Asociar una zona a un compartimento que ya tiene recursos no borra lo que viola la política, pero sí bloquea operaciones posteriores sobre esos recursos, y eso produce sorpresas. Se planea antes de poblar el compartimento.

17.3 Qué bloquea de verdad

La prueba está automatizada en scripts/40-prueba-security-zone.sh, que hace exactamente dos cosas y una limpieza:

./40-prueba-security-zone.sh "<ocid-lab-02-zona-segura>"

El mismo par de operaciones se puede hacer por consola: Storage › Buckets › Create Bucket en el compartimento lab-02-zona-segura, una vez con acceso NoPublicAccess y otra marcando la visibilidad pública. La segunda falla, y el mensaje de error nombra la política de la Security Zone que la rechazó.

Lo importante del paso 1 es que no falle. Una barrera que bloquea todo no es una barrera, es una pared, y nadie la deja puesta: lo que convence es que el trabajo legítimo pase sin pedir permiso.

Qué no bloquea: la Security Zone actúa sobre operaciones del plano de control en ese compartimento. No inspecciona el contenido de los objetos, no evalúa lo que pasa dentro de una instancia y no alcanza a otros compartimentos.

---

18. Validación de extremo a extremo

Tres pruebas. Las tres están automatizadas en scripts/, y las tres se pueden hacer a mano si no tiene la CLI.

18.1 La auditoría: el contraste en números

La prueba principal del módulo: el mismo script, contra los dos laboratorios.

cd talleres/02-seguridad/scripts
./10-auditoria-rapida.sh "<ocid-lab-01-elasticidad>" "<ocid-tenancy>"   # el laboratorio A
./10-auditoria-rapida.sh "<ocid-lab-02-seguridad>" "<ocid-tenancy>"   # el laboratorio B

El script es de solo lectura: ejecuta únicamente operaciones de listar y consultar —no crea, no modifica, no borra—, así que es seguro entregárselo a un tercero para que lo corra contra su propio tenancy con un usuario de solo lectura.

Resultado medido:

Los cinco altos del laboratorio A, uno por uno:

Y los dos medios que sí aparecen en el laboratorio bien construido:

18.2 La prueba del WAF: 200 contra 403

./20-prueba-waf.sh "<ip-lb-laboratorio-A>" "<ip-lb-laboratorio-B>"

Cuatro solicitudes contra cada balanceador. Resultado medido:

Solicitud                          Sin WAF     Con WAF
Normal         GET /               200         200
XSS            GET /?q=<script>    200         403
SQL injection  GET /?id=1' OR '1'= 200         403
Ruta admin     GET /admin          200         403

La primera fila es la que da sentido a las otras tres: el tráfico legítimo pasa igual por los dos lados. Si la fila normal diera 403, el WAF estaría roto, no protegiendo.

A mano, sin script, la misma prueba son cuatro comandos:

LB="<ip-del-balanceador-con-waf>"
curl -s -o /dev/null -w '%{http_code}\n' "http://$LB/"
curl -s -o /dev/null -w '%{http_code}\n' "http://$LB/?q=%3Cscript%3Ealert(1)%3C%2Fscript%3E"
curl -s -o /dev/null -w '%{http_code}\n' "http://$LB/?id=1%27%20OR%20%271%27%3D%271"
curl -s -o /dev/null -w '%{http_code}\n' "http://$LB/admin"

Si la segunda línea devuelve 200 contra el balanceador con WAF, el problema casi siempre es la versión de la capacidad 941100: vuelva al capítulo 13.1.

18.3 El bastión hacia una máquina sin IP pública

./30-sesion-bastion.sh 3600

El script crea la sesión, intenta primero la administrada, cae a port forwarding si la administrada falla, y deja el comando SSH armado y listo para pegar. Resultado medido: conexión establecida a una instancia sin IP pública, en la subred 10.40.2.0/24.

Dos detalles que el script resuelve y que hay que conocer si se hace a mano:

• La ruta de la llave privada va entre comillas simples, en una variable aparte. Si el directorio del usuario tiene un espacio —lo normal en Windows— el comando se parte y falla con un mensaje sobre el archivo de identidad inaccesible. Y no pueden ser comillas dobles: el ProxyCommand ya viene envuelto en dobles y unas dobles adentro lo cierran antes de tiempo, con un error desconcertante sobre caracteres inválidos en el nombre de usuario remoto.
• La primera conexión pide aceptar la huella dos veces, la del bastión y la del salto interno. El script agrega StrictHostKeyChecking=accept-new, que acepta huellas nuevas y sigue avisando si una conocida cambia, que es el caso que importa.

18.4 La barrera preventiva

./40-prueba-security-zone.sh "<ocid-lab-02-zona-segura>"

Esperado: el bucket privado se crea, el público se rechaza citando la política. Detalle en el capítulo 17.3.

---

19. Qué puede salir mal

Errores reales, documentados durante la construcción y el ensayo de este laboratorio. No son hipótesis.

19.1 WAF

19.2 Balanceador

19.3 Bastión

19.4 Cloud Guard, alertas y zona

19.5 Construcción en general

---

20. Limpieza

El orden importa: hay recursos que bloquean el borrado de otros.

20.1 Orden de borrado

1. Sesiones activas del bastión — Identity & Security › Bastion › lab02bastion › Sessions. Una sesión viva bloquea el borrado del bastión durante varios minutos, con un mensaje sobre el recurso en uso.
2. El firewall de aplicación y después su política — Identity & Security › Web Application Firewall. Al revés no se deja.
3. El balanceador — Networking › Load Balancers › lab02-lb › Delete. Esto libera los backends.
4. Las instancias — Compute › Instances. Marque la opción de borrar también el volumen de arranque; si no la marca, los volúmenes quedan.
5. El bastión.
6. Los logs y el grupo de logs. El log de flujos primero, el grupo después.
7. La regla de eventos, la suscripción y el tema de notificaciones.
8. La red, en este orden: subredes, NSG, tablas de ruteo, gateways y por último la VCN. Si un objeto se niega a borrarse, algo lo está referenciando; la consola dice qué.
9. El laboratorio A, completo, con la misma secuencia.
10. Los compartimentos, si ya no los va a usar. Un compartimento vacío no cuesta nada, pero deja ruido en el inventario.

Si tiene el módulo de Terraform, todo lo anterior es scripts/99-destroy.sh, que además cierra las sesiones del bastión antes de destruir.

20.2 Qué se queda, y por qué está bien

20.3 Verificar que quedó limpio

Consola de OCIGovernance & Administration › Tenancy Explorer

Filtre por el compartimento lab y sus hijos: debería quedar vacío salvo los compartimentos mismos. Para el costo, Billing & Cost Management › Cost Analysis, filtrando por la etiqueta Efimero = si; los datos de consumo tardan horas en consolidar, así que la cifra del mismo día siempre será menor que la real.

---

21. Documentación oficial

Enlaces a las páginas generales de cada servicio. Las rutas profundas de la documentación cambian entre versiones; desde estas páginas la navegación lateral lleva al procedimiento exacto.

Referencia externa para la conversación de cumplimiento: el CIS OCI Foundations Benchmark, que da una línea base reconocida para medir avance y responder auditorías. El script de auditoría de este laboratorio es una muestra deliberadamente pequeña: para postura continua se usa Cloud Guard, y para cumplimiento, el benchmark.