Cómo preparé mi entorno de nube en Colombia

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

No busco migrar todo mi laboratorio a la nube. Sigo siendo fiel a mi Home Lab local, mi Intel NUC. Lo que quiero es un enfoque híbrido: la latencia mínima de tener la nube “en casa” combinada con 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). Actualmente ofrecen hasta 2 OCPUs y 12 GB de RAM (1.500 horas de OCPU y 9.000 GB-hora al mes); Oracle redujo este límite desde los 4 OCPUs/24 GB anteriores a mediados de 2026, sin un anuncio oficial formal. Si tienes una cuenta Pay As You Go, hay reportes de usuarios que siguen viendo el límite anterior sin costo, pero conviene que confirmes tu cupo real en la consola antes de dimensionar la instancia.

Sin embargo, como consultor de seguridad sé que la nube no es segura por defecto: no se trata de lanzar una máquina virtual y empezar a instalar cosas sin más.

Antes de desplegar mi primera instancia me obligué a frenar, leer la documentación oficial y estructurar el tenant correctamente. Aquí te comparto el resumen de los 6 pasos de preparación y seguridad que aplicué 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 mala práctica. La documentación de Oracle es clara en esto: necesitas estructura.

Lo primero que hice fue definir una jerarquía de compartimentos. Piénsalos como carpetas lógicas para aislar recursos.

  • Mi estrategia: creé compartimentos separados según el propósito —por ejemplo, un “Sandbox” para pruebas destructivas y otro para servicios estables.
  • ¿Por qué? Facilita la administración y, sobre todo, la seguridad. Si un script se vuelve loco en el entorno de pruebas, no toca 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.

Configuré 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 solo lo necesario.

Consejo: nunca compartas usuarios. Incluso en un laboratorio personal, acostúmbrate a crear usuarios nominales y asignarlos a grupos, nunca a dar permisos directos al usuario.

3. Redes y conectividad: planificando la VCN

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

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

  • Subredes públicas: para recursos que 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 quedar expuestos.

Aquí también entran los Security Lists y los 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 busquemos aprovechar la capa gratuita, las sorpresas en la facturación llegan si no tenemos cuidado: volúmenes de almacenamiento huérfanos, tráfico de salida que se nos pasa de la mano, etc.

Para mitigar esto en mi nueva región:

  • Tagging: definí un esquema de etiquetas para saber qué recurso pertenece a qué proyecto (por ejemplo, Entorno: Pruebas).
  • Budgets: configuré un presupuesto con alerta de consumo. Mi intención es gastar $0, pero quiero un correo si mi consumo proyectado supera los $10 USD. 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:

  • Audit (Auditoría): 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 que se mantiene aislado, 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 capacidad disponible —cupo de CPUs ARM y memoria— para lo que planeaba desplegar.

¿Qué sigue?

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

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

¡Nos leemos en el siguiente post!