IAM y compartimentos en OCI: una estructura de acceso que se pueda auditar

Una tenencia de Oracle Cloud Infrastructure (OCI) suele comenzar con pocos recursos y crecer hasta alojar aplicaciones de distintos equipos, proveedores externos y ambientes de producción. Si cada recurso permanece donde lo creó su primer administrador, las autorizaciones acaban dependiendo de excepciones difíciles de revisar.

El objetivo de este artículo es una estructura en la que cualquier persona del equipo pueda explicar quién administra cada conjunto de recursos y por qué tiene acceso. Se proponen criterios para OCI IAM con dominios de identidad y se indica, en cada punto, dónde verificar las reglas del servicio.

Identidad, recursos y red: tres dominios distintos

Un compartimento organiza recursos y es el ámbito sobre el que se aplican las políticas de acceso. Según la documentación de compartimentos, abarcan toda la tenencia y están disponibles en todas las regiones suscritas. Un compartimento llamado «Produccion» no selecciona una región ni controla tráfico.

Un dominio de identidad gestiona una población de usuarios y su configuración de identidad, incluidas federación, inicio de sesión y políticas de seguridad. El apartado de dominios de identidad describe el dominio predeterminado y el uso de dominios adicionales. Crear varios sólo se justifica si existe una necesidad real de separar usuarios o administración.

La segmentación de red, por último, se define en VCN, subredes y reglas de seguridad. Separar recursos en compartimentos ordena responsabilidades, pero no restringe conexiones entre aplicaciones. Una revisión de IAM no reemplaza una revisión de conectividad.

Compartimentos por responsabilidad

El diseño parte de un inventario de cargas, ambientes y responsables. Una estructura posible distingue Plataforma, Produccion y NoProduccion, con compartimentos por aplicación cuando existen equipos o permisos distintos. Es una propuesta que debe ajustarse a las dependencias y a quién aprueba los cambios en cada organización.

El criterio para crear un compartimento es una necesidad concreta de administración o de acceso que se entienda mejor por separado. Una rama por recurso o por persona produce el efecto contrario. Si dos conjuntos comparten responsable, permisos y ciclo de vida, una misma ubicación suele requerir menos excepciones.

Los servicios compartidos merecen atención especial. Una red central puede depender de un equipo distinto del que despliega aplicaciones, lo que exige definir qué permisos necesita cada lado para consumirla. Documentar esas dependencias antes de escribir políticas evita el recurso habitual de conceder administración general ante cada error de permisos.

La guía de estructura de seguridad IAM del marco de adopción de Oracle recomienda separar cargas productivas y no productivas y mantener una estructura manejable. Esa orientación es un buen punto de partida, siempre que las excepciones queden registradas. Un equipo pequeño necesita reglas que pueda sostener cuando alguno de sus miembros no está.

Políticas definidas por tarea

Una política describe cuatro elementos: el principal autorizado, el nivel de acceso, los recursos y el ámbito. La introducción a las políticas IAM los explica y advierte que algunas operaciones requieren permisos sobre varios tipos de recursos. Aprobar una tarea exige, por tanto, revisar sus dependencias además del recurso principal.

Recomendamos formar grupos según tareas (operar una aplicación, administrar la red) y no según cargos. Para cada grupo se escriben primero las acciones y los recursos involucrados, y sólo después se eligen los permisos en la referencia del servicio. El nombre de un grupo no restringe nada: el acceso efectivo lo determinan las políticas.

En tenencias con dominios, los grupos se identifican por dominio y nombre, según la sintaxis del sujeto, que también documenta el comportamiento del dominio predeterminado. Mantener el dominio explícito en la documentación interna evita confusiones entre grupos con nombres parecidos.

La administración de la tenencia se reserva para las funciones que la necesitan. Ante una operación fallida, el procedimiento correcto es identificar el permiso faltante, no ampliar el grupo a todos los recursos. Cada autorización debería quedar asociada a la tarea que la motivó y a quien la aprobó, para poder revisar su vigencia.

Herencia y delegación

Los compartimentos hijos heredan las autorizaciones de sus padres. Una concesión amplia en una rama superior alcanza a cualquier aplicación que se agregue después, como explica la documentación sobre herencia de políticas. Antes de asumir que una rama nueva tiene acceso limitado, deben revisarse las políticas de sus ancestros.

El lugar donde se adjunta una política también importa, porque determina quién puede modificarla o eliminarla. La gestión puede corresponder al equipo central o al responsable de cada compartimento; en ambos casos, delegar la administración de políticas requiere una revisión específica, porque permite cambiar las reglas de acceso de otros.

Una herramienta útil es una matriz con grupos en filas y tareas en columnas. Con una cuenta representativa de cada grupo se prueba una operación autorizada y otra que debe quedar fuera de su alcance, en producción y en no producción. Una prueba hecha sólo con un administrador oculta tanto permisos faltantes como excesivos.

Identidades de automatización

Una aplicación que llama a APIs de OCI necesita una identidad operativa propia. Los grupos dinámicos agrupan recursos mediante reglas de coincidencia, y las políticas les conceden acceso a servicios. Su pertenencia cambia a medida que aparecen o desaparecen recursos que cumplen la regla.

Esa propiedad tiene una consecuencia: si la regla incluye todas las instancias de un compartimento, cualquier instancia futura que coincida obtiene el mismo acceso. El alcance de la regla debe revisarse junto con quién puede crear recursos en esa ubicación y si todos necesitan realmente las mismas capacidades.

Por integración conviene registrar el recurso que ejecuta las llamadas, el servicio de destino, el acceso requerido y el mecanismo de autenticación que admite ese servicio. Así se distinguen los permisos del despliegue de los que la aplicación necesita en tiempo de ejecución.

Revisión periódica y evidencia

Mover recursos entre compartimentos requiere revisar dependencias y permisos: las políticas del destino pasan a aplicarse y algunas dependencias se comportan de forma distinta según el servicio. Oracle detalla las implicaciones del movimiento, que conviene consultar antes de reorganizar una carga existente.

La estructura se considera lista cuando cada punto de la siguiente lista tiene un responsable y una evidencia de comprobación. La misma revisión puede incorporarse a la llegada de aplicaciones nuevas y a los cambios de personal.

• Cada compartimento tiene propietario y ambiente identificados.
• Los grupos y sus autorizaciones están revisados en toda la cadena de compartimentos padres.
• Está documentado quién puede modificar políticas y reglas de grupos dinámicos.
• Las tareas permitidas y los accesos que deben denegarse están probados.
• Las dependencias se documentan antes de mover recursos o cambiar responsables.

OCI Audit registra las llamadas a los endpoints públicos compatibles y permite consultar eventos para investigar actividad; su alcance y excepciones están en la documentación oficial. La evidencia disponible debe verificarse por servicio, y la revisión de cambios relevantes necesita un responsable asignado.

Xterra Engine diseña estructuras de compartimentos y políticas en OCI, y las entrega con su matriz de permisos probada.