Estrenando la Región Bogotá en OCI: Cómo preparé mi entorno de nube en Colombia

Introducción

Hace poco decidí dar el paso y crear una nueva cuenta (tenant) en Oracle Cloud Infrastructure (OCI). Lo interesante de esta movida es que, por primera vez, estoy desplegando recursos directamente en la región Colombia Central (Bogotá).

Mi objetivo no es migrar todo mi laboratorio a la nube —sigo siendo fiel a mi Home Lab local (mi Intel NUC)—, sino tener un enfoque híbrido. Quiero aprovechar lo mejor de ambos mundos: la latencia mínima de tener la nube "en casa" y la potencia de la infraestructura de Oracle.

Una de las grandes motivaciones para usar OCI son sus instancias Always Free, especialmente las basadas en procesadores ARM (Ampere). Son increíblemente generosas: ofrecen hasta 4 OCPUs y 24 GB de RAM. Sin embargo, como consultor de seguridad, sé que la nube no es segura por defecto. No se trata simplemente de lanzar una máquina virtual y empezar a instalar cosas.

Antes de desplegar mi primera instancia, me obligué a detenerme, leer la documentación oficial y estructurar el tenant correctamente. Aquí les comparto el resumen de los 6 pasos de preparación y seguridad que apliqué antes de tocar una sola máquina virtual.

---

1. Define tu plan de organización (No uses el "Root" para todo)

La tentación de crear todo en el compartimento raíz (*root compartment*) es grande, pero es una mala práctica. La documentación de Oracle es clara: necesitas estructura.

Lo primero que hice fue definir una jerarquía de Compartimentos. Piensa en ellos como carpetas lógicas para aislar recursos.

• Mi estrategia: Creé compartimentos separados para distintos propósitos (por ejemplo, un "Sandbox" para pruebas destructivas y otro para servicios estables).
• ¿Por qué? Esto facilita la administración y, más importante aún, la seguridad. Si un script se vuelve loco en el entorno de pruebas, no afectará a los recursos estables.

2. Gestión de Identidad (IAM): El principio de mínimo privilegio

Aunque soy el dueño de la cuenta, operar siempre como "Administrador Supremo" es un riesgo innecesario.

Me enfoqué en configurar el IAM (Identity and Access Management) siguiendo el principio de segregación de funciones.

• Creé Grupos específicos (Administradores, Operadores de Red, Seguridad).
• Evité las políticas genéricas. En lugar de dar acceso a todo, diseñé políticas que permiten acceso solo a lo necesario.
• Consejo: Nunca compartas usuarios. Incluso en un laboratorio personal, acostúmbrate a crear usuarios nominales y asignarlos a grupos, nunca asignar permisos directos al usuario.

3. Redes y Conectividad: Planificando la VCN

Antes de pensar en servidores, hay que pensar en carreteras. En OCI, esto es la VCN (Virtual Cloud Network).

Al crear mi VCN en la región de Bogotá, tuve que decidir el diseño de mis subredes. Aunque es un laboratorio, es vital separar lo público de lo privado:

• Subredes Públicas: Para recursos que estrictamente necesitan salir o recibir tráfico de internet (con sus respectivos *Internet Gateways*).
• Subredes Privadas: Para bases de datos o servicios internos que no deben estar expuestos.

Aquí también entran los Security Lists y Network Security Groups (NSG). Configuré reglas de firewall estrictas desde el inicio (nada de `0.0.0.0/0` abierto al puerto 22 para todo el mundo).

4. Etiquetas y Gobernanza de Costos (¡Cuidado con la tarjeta!)

Aunque estemos buscando aprovechar la capa gratuita, las sorpresas en la facturación ocurren si no tenemos cuidado (por ejemplo, al dejar volúmenes de almacenamiento huérfanos o superar el tráfico de salida).

Para mitigar esto en mi nueva región:

• Tagging: Definí un esquema de etiquetas para saber qué recurso pertenece a qué proyecto (ej: `Entorno: Pruebas`).
• Budgets: Configuré un presupuesto (Budget) con una alerta de consumo. Aunque mi intención es gastar $0, quiero recibir un correo si mi consumo proyectado supera los $10 USD. Es mejor una alerta temprana que una factura inesperada a fin de mes.

5. Seguridad Base y la cuenta "Break-Glass"

Más allá de los firewalls, hay configuraciones a nivel de *tenant* que no se pueden ignorar:

• Cloud Audit: Verifiqué que el servicio de auditoría esté registrando los eventos. Necesito saber qué pasó, cuándo y quién lo hizo.
• Cuenta de Emergencia (Break-Glass): Siguiendo las guías de administración, configuré una cuenta de acceso de emergencia. Es un usuario con permisos máximos, pero que se mantiene aislado y con una contraseña extremadamente compleja, para usar *solo* si pierdo el acceso a mi federación de identidad o a mis usuarios principales.

6. Revisión de Límites de Servicio (Service Limits)

Finalmente, antes de emocionarme lanzando la VM, fui a la consola a revisar los Service Limits para la región de Bogotá.

No hay nada más frustrante que configurar toda la red y, al momento de crear la instancia, recibir un error de "Límite excedido". Verifiqué que mi *tenancy* tuviera la capacidad disponible (cupo de CPUs ARM y memoria) para lo que planeaba desplegar.

---

¿Qué sigue?

Con estos 6 pasos, mi entorno en Oracle Cloud está listo, seguro y organizado. Ya no es un terreno baldío, sino una base sólida para empezar a construir.

En la próxima entrada, pasaremos a la acción: les mostraré cómo desplegué mi primera máquina virtual, los comandos que utilicé para actualizar el sistema operativo y qué servicios base instalé para dejarla 100% operativa.

¡Nos leemos en el siguiente post!