Las políticas de OCI se leen como inglés, y por eso es fácil equivocarse peligrosamente

allow group Developers to manage all-resources in compartment dev es una frase que cualquiera puede leer, y esa legibilidad es una de las mejores decisiones de diseño de OCI. También es el motivo por el que las tenancies de OCI acumulan políticas demasiado amplias más rápido que las nubes con JSON verboso: nadie siente el peso de lo que acaba de conceder.

Entiende qué significan los verbos

OCI tiene cuatro verbos, y son acumulativos:

• inspect — listar recursos. Ojo: para algunos tipos de recurso esto incluye metadatos que puedes considerar sensibles.
• read — inspect más recuperar el contenido. Para un secreto de vault, read significa leer el secreto.
• use — read más trabajar con recursos existentes, pero sin crear ni borrar. Para la mayoría de tipos de recurso es el término medio útil.
• manage — todo, borrado incluido.

El error es recurrir a manage cuando se quería decir use. Un grupo que opera un servicio necesita use; un grupo que lo aprovisiona necesita manage. Separar esos dos es la mayor reducción de radio de explosión disponible en una tenancy de OCI.

Los tipos de recurso agregados (instance-family, virtual-network-family, database-family) son cómodos y amplios. all-resources solo debería aparecer en la política de Administradores, e idealmente ni ahí.

Grupos dinámicos: cómo se autentican las cargas sin credenciales

Un grupo dinámico es una regla que empareja recursos en lugar de usuarios:

ALL {instance.compartment.id = 'ocid1.compartment.oc1..aaa'}

Las instancias, funciones, bases de datos autónomas y otros principales de recurso que cumplan la regla pueden recibir permisos directamente. La carga llama a la API y se autentica como sí misma — sin clave de firma de API, sin fichero de clave en disco, sin rotación.

Dos reglas para escribirlos:

Empareja por el atributo más estrecho disponible. Un grupo dinámico que empareje todas las instancias de la tenancy, con manage objects, significa que cualquier VM comprometida puede leer y borrar todos los buckets. Empareja por compartimento más una etiqueta definida, para que la pertenencia sea intencionada y no incidental.

Escribe la política contra el grupo dinámico con una cláusula where. allow dynamic-group app-servers to manage objects in compartment data where target.bucket.name = 'uploads' es defendible. Sin la cláusula has concedido el compartimento entero.

Toda clave de firma de API en un fichero de configuración es candidata a sustitución. Como en otras nubes, la clave de larga vida es la credencial que se filtra — el mismo argumento que las claves de cuenta de servicio de GCP, y el mismo arreglo.

Condiciones, que casi ninguna tenancy usa

Las políticas de OCI admiten cláusulas where sobre un conjunto rico de variables, y están infrautilizadas:

• where request.region = 'eu-madrid-1' — fija la autoridad de un grupo a una región.
• where target.resource.tag.Ops.Environment = 'test' — acotado por etiqueta, para que un grupo de desarrollo pueda gestionar lo etiquetado como test en compartimentos de producción sin tocar recursos productivos.
• where request.user.mfaTotpVerified = 'true' — exige MFA para la operación. Esta merece la pena aplicarla a todas las políticas administrativas.
• where request.permission = '...' — excluye permisos destructivos concretos de una concesión por lo demás amplia.

Los hallazgos que se repiten en revisiones de OCI

• manage all-resources en la tenancy concedido a más grupos que Administradores. Con frecuencia a un grupo de CI, porque era más fácil que enumerar.
• Claves de firma de API para usuarios, sobre todo para un usuario compartido de "automatización". Un usuario con clave de API y política amplia es una cuenta sin MFA, y suele ser el punto más débil de la tenancy.
• Grupos dinámicos que emparejan un compartimento entero con manage sobre una familia.
• Políticas escritas en el compartimento raíz que iban destinadas a una sola carga y conceden autoridad en toda la tenancy como efecto secundario.
• Buckets públicos. Los buckets de Object Storage son privados por defecto, pero las peticiones preautenticadas son fáciles de crear, de larga vida y transferibles. Audítalas: son el equivalente en OCI de una URL prefirmada olvidada en un hilo de Slack, y aplican las mismas lecciones de S3.

Verifica en lugar de suponer

El simulador de políticas de OCI y oci iam policy list en todos los compartimentos te permiten responder "qué puede hacer de verdad este grupo" sin adivinar. Ejecútalo para tus tres grupos más privilegiados y lee el resultado combinado — la herencia hace que la respuesta sea a menudo más amplia de lo que sugiere cualquier política individual.

Activa también el registro de auditoría hacia un compartimento dedicado con retención, y Cloud Guard con la receta del benchmark CIS de OCI, que marca automáticamente casi todos los hallazgos de arriba. Hacemos esta pasada como parte de un diagnóstico de seguridad.

Qué hacer esta semana

Lista todas las sentencias de política que contengan manage all-resources o manage sobre una -family en la raíz de la tenancy. Para cada una, pregúntate si use bastaría y si el compartimento podría ser más estrecho. Esa revisión es una tarde y normalmente elimina la mayor parte de la autoridad sobrante de una tenancy.