IAM Policies parecem ser uma das partes mais simples do Oracle Cloud Infrastructure: definir quem pode executar determinada ação sobre determinado recurso. Na prática, essa simplicidade desaparece rapidamente quando um tenancy passa a suportar vários workloads, ambientes, equipes, compartments, Dynamic Groups, automações e integrações.
Ao longo desta série, vamos analisar como projetar, revisar e otimizar políticas IAM no OCI sem transformar a busca por simplicidade em permissões excessivamente amplas.
A série será dividida em cin2o partes:
- OCI IAM Policies: como o modelo de autorização realmente funciona;
- Least Privilege no OCI: como escrever policies melhores e reduzir o alcance do impacto;
- IAM em Escala: Compartments, Dynamic Groups, Instance Principals e Tag-Based Access Control;
- Governança de IAM: como revisar, otimizar e automatizar policies em ambientes corporativos;
- OCI IAM Deny Policies: guardrails, limitações e novos modelos de segurança.
OCI IAM Policies: Como o Modelo de Autorização Realmente Funciona
OCI IAM Policies são relativamente fáceis de começar a utilizar. Um grupo precisa administrar algumas instâncias:
| Allow group Corporate/ComputeAdmins to manage instance-family in compartment Production |
Outro grupo precisa acessar recursos de rede:
| Allow group Corporate/NetworkAdmins to manage virtual-network-family in tenancy |
A sintaxe parece simples e, em essência, realmente é. O problema começa quando tentamos responder a uma pergunta aparentemente básica:
- O que exatamente determinado usuário consegue fazer no tenancy?
Em ambientes corporativos, essa resposta pode depender de vários grupos, policies criadas em diferentes níveis da hierarquia de compartments, condições, Dynamic Groups, administrator roles e outros mecanismos de autorização. Antes de discutir least privilege ou otimização, portanto, precisamos entender como o OCI realmente calcula autorização.
IAM com Identity Domains
O modelo atual de Identity and Access Management do OCI é baseado em Identity Domains. Um Identity Domain funciona como um contêiner de identidades e configurações de segurança, reunindo usuários, grupos, métodos de autenticação, MFA, federação, Single Sign-On (SSO), aplicações e mecanismos de lifecycle management.
Essa arquitetura é resultado da integração do antigo Oracle Identity Cloud Service (IDCS) ao OCI IAM. Em vez de manter identidades do OCI e identidades federadas em estruturas separadas, o modelo atual incorpora essas capacidades diretamente em IAM por meio dos Identity Domains.
Do ponto de vista de segurança, é importante separar dois conceitos:
- Identity Domain – Identidade e Autenticação. Define quem são os usuários, como eles autenticam, a quais grupos pertencem e quais controles de autenticação se aplicam, como MFA, SSO ou federação com um Identity Provider corporativo.
- OCI IAM Policies – Autorização sobre Recursos OCI. Determinam o que essas identidades, normalmente por meio de grupos, podem fazer sobre Compute, Networking, Database, Object Storage e outros recursos OCI.
Por exemplo, um grupo chamado DatabaseAdmins pode existir dentro do Identity Domain Corporate. A existência do usuário nesse grupo, por si só, não concede acesso aos bancos de dados OCI. O acesso é concedido por uma IAM Policy, como:
| Allow group Corporate/DatabaseAdmins to manage database-family in compartment Production |
Nesse caso, o Identity Domain determina a identidade e o membership, enquanto a IAM Policy transforma essa associação em autorização sobre recursos OCI.
Cada tenancy possui um Default Identity Domain, localizado no root compartment. Ele contém originalmente o usuário administrador do tenancy, o grupo Administrators e a policy administrativa inicial. O Default Domain acompanha o ciclo de vida do tenancy e não pode ser removido ou desativado.
O OCI também permite criar múltiplos Identity Domains. Isso pode ser útil quando existem populações de usuários, requisitos de autenticação ou fronteiras administrativas diferentes. A documentação do Oracle Cloud Adoption Framework apresenta, entre os possíveis cenários, a separação de identidades entre ambientes de desenvolvimento e produção quando requisitos de segurança exigem esse isolamento.
Entretanto, criar vários Identity Domains não deve ser uma decisão automática. Cada domínio adiciona uma nova fronteira administrativa e seu próprio conjunto de usuários, grupos, configurações e políticas de autenticação. Para muitas organizações, um domínio corporativo bem estruturado com grupos adequados pode ser mais simples de governar do que diversos domínios separados.
Outro ponto relevante é que administrator roles do Identity Domain e OCI IAM Policies são mecanismos diferentes. Roles como Identity Domain Administrator ou Security Administrator delegam capacidades administrativas dentro de um domínio, enquanto IAM Policies controlam principalmente o acesso aos recursos OCI. Essa distinção se torna particularmente importante na análise de privilégios administrativos.
Para o restante desta série, podemos considerar o fluxo básico como: a identidade é estabelecida no Identity Domain e a autorização aos recursos OCI é determinada pelas IAM Policies. Nos próximos tópicos veremos como essa autorização é construída e como subject, verb, resource-type, location e conditions determinam seu alcance.
Anatomia de uma Policy IAM
Uma IAM Policy no OCI é formada por um ou mais statements que definem quem pode acessar determinado recurso, com qual nível de privilégio e em qual escopo.
A estrutura básica é:
| Allow <subject> to <verb> <resource-type> in <location> where <condition> |
Por exemplo:
| Allow group Corporate/DBAdmins to manage database-family in compartment Production |
Esse statement pode ser interpretado como:
Permitir que o grupo DBAdmins, do Identity Domain Corporate, administre recursos da família de Database no compartment Production.
Os principais elementos são:
| Elemento | Função | Exemplo |
| subject | Quem recebe o acesso | group Corporate/DBAdmins |
| verb | Nível de acesso | manage |
| rerource-type | Recursos abrangidos | Database-family |
| location | Escopo da autorização | compartment Production |
| condition | Restrição adicional, opcional | where … |
O subject normalmente referência um grupo, enquanto o verb define o nível de privilégio por meio dos metaverbs inspect, read, use e manage.
O resource-type pode representar um recurso específico, como instances, uma família de recursos, como instance-family, ou um conjunto muito amplo, como all-resources.
Já o location determina onde a autorização será válida. Compare:
- in compartment Production
com:
- in tenancy
O segundo caso possui um escopo significativamente maior, e consequentemente, um maior alcance de impacto.
Por fim, a cláusula opcional where permite adicionar condições à autorização, como restringir uma operação por região, rede de origem, permissão específica ou atributos do recurso.
Embora a sintaxe seja simples, o alcance de uma policy depende da combinação entre subject, verb, resource-type, location e conditions. É essa combinação (e não apenas o verbo utilizado) que deve ser analisada durante uma revisão de segurança.
Inspect, read, use ou manage?
O verb define o nível de acesso concedido por uma IAM Policy. O OCI possui quatro metaverbs, organizados de forma cumulativa:
| Verb | Acesso Geral |
| inspect | Permite principalmente listar recursos |
| read | Inclui inspect e permite consultar informações e o próprio recurso |
| use | Inclui read e permite operar recursos existentes |
| manage | Inclui todas as permissões disponíveis para aquele resource-type |
Assim, de forma geral:
Porém, essa progressão deve ser interpretada com cuidado. O significado exato de cada verbo depende do resource-type ao qual ele está associado. A Oracle mantém na Detailed Service Policy Reference o mapeamento entre metaverbs, permissões e operações de API para cada serviço.
O verbo use, por exemplo, normalmente permite trabalhar com recursos existentes, mas não criá-los ou excluí-los. Algumas operações de atualização também exigem manage quando possuem impacto equivalente à criação de um recurso.
Considere:
| Allow group Corporate/ComputeOperators to use instances in compartment Production |
e:
| Allow group Corporate/ComputeOperators to manage instances in compartment Production |
Os dois statements atuam sobre os mesmos recursos e no mesmo compartment, mas o segundo concede um conjunto maior de permissões.
Por isso, durante troubleshooting, aumentar sucessivamente o privilégio até chegar a manage pode resolver um erro de autorização, mas também pode conceder permissões desnecessárias.
Boa prática de segurança: utilize o menor verbo que permita executar as operações necessárias e consulte a Policy Reference antes de elevar uma policy para manage.
Há ainda exceções importantes. inspect, por exemplo, normalmente evita expor informações confidenciais ou metadados definidos pelo usuário, mas algumas operações List, como as relacionadas a policies e determinados recursos de Networking, retornam informações mais detalhadas.
Portanto, os metaverbs devem ser vistos como abstrações convenientes sobre conjuntos de permissões, e não como níveis universais com exatamente o mesmo comportamento em todos os serviços OCI.
Resource-types e resource families
O resource-type define sobre quais recursos uma IAM Policy será aplicada. No OCI, ele pode representar um recurso individual, uma família de recursos relacionados ou, de forma mais ampla, todos os recursos de determinado escopo.
Por exemplo: instances, representa especificamente instâncias Compute, enquanto instance-family agrupa diversos resource-types relacionados ao serviço Compute, como instâncias, console connections, images e outros componentes associados.
Isso permite escrever uma policy mais simples em vez de criar vários statements separados para cada resource-type:
| Allow group Corporate/ComputeAdmins to manage instance-family in compartment Production |
As resource families são uma abstração útil para simplificar a administração. Porém, essa simplicidade tem um trade-off: a autorização passa a abranger todos os resource-types incluídos naquela família.
Por isso, quando apenas um tipo específico de recurso é necessário, uma policy mais restrita pode ser preferível:
| Allow group Corporate/ComputeOperators to manage instances in compartment Production |
Existe ainda o resource-type especial all-resources, que representa todos os resource-types disponíveis no compartment ou tenancy definido no statement. Por seu alcance, deve ser utilizado principalmente quando essa amplitude fizer parte do requisito administrativo, e não apenas para simplificar a escrita da policy.
Boa prática de segurança: utilize o resource-type mais específico que atenda ao requisito, mas sem criar uma granularidade que torne a policy excessivamente difícil de manter.
Outro ponto importante é que resource families podem evoluir. Quando novos resource-types são adicionados a um serviço, eles podem passar a fazer parte da família correspondente. Uma policy baseada em uma family pode passar a abranger novos tipos de recurso após uma atualização do serviço. Por esse motivo policies privilegiadas que utilizam resource families devem fazer parte das revisões periódicas de acesso.
Escopo: Tenancy vs Compartment
O location define onde a autorização será válida. No OCI, os dois escopos mais comuns são: in tenancy e in compartment <compartment-name>.
Uma policy com in tenancy concede a autorização para os recursos correspondentes em toda o tenancy, incluindo seus compartments. Já in compartment restringe o acesso ao compartment informado, e devido ao modelo de herança do OCI, também aos seus subcompartments.
Compare:
| Allow group Corporate/DBAdmins to manage database-family in tenancy |
com:
| Allow group Corporate/DBAdmins to manage database-family in compartment Production-Databases |
Nos dois casos o grupo, o verbo e o resource-type são iguais. A diferença está no alcance do acesso. No primeiro, o grupo poderá administrar os recursos correspondentes em todo o tenancy; no segundo, o acesso fica limitado à hierarquia de Production-Databases. Por isso, o escopo é um dos elementos mais importantes na aplicação do princípio do menor privilégio.
Boa prática de segurança: utilize in compartment sempre que a função não exigir acesso aos mesmos recursos em todo o tenancy.
Também é importante considerar a hierarquia de compartments. Por exemplo, uma autorização concedida em in compartment Production também pode alcançar recursos existentes nos compartments abaixo dele, como Production:App-A e Production:App-B.
Quando necessário, a própria hierarquia pode ser utilizada no statement:
| Allow group Corporate/AppAdmins to manage instances in compartment Production:App-A |
Isso permite restringir a autorização a uma parte específica da estrutura.
Nem toda autorização, entretanto, pode ser limitada a um compartment. Alguns recursos IAM existem no nível do tenancy, e nesses casos, in tenancy é necessário. Um exemplo típico é:
| Allow group Corporate/HelpDesk to manage users in tenancy |
Portanto, in tenancy não deve ser considerado incorreto por definição. O ponto é utilizá-lo somente quando o recurso ou requisito realmente exigir esse alcance. Quanto maior o escopo concedido, maior também será o alcance do impacto caso uma conta, grupo ou credencial privilegiada seja utilizada indevidamente.
Policy Attachment não é o mesmo que Policy Scope
No OCI, toda IAM Policy precisa ser associada (attached) a um compartment no momento de sua criação. Esse local de associação não deve ser confundido com o escopo de acesso definido pelos statements da policy.
Em termos práticos:
- Policy Attachment define onde o objeto Policy é administrado e quem pode alterá-lo ou excluí-lo;
- Policy Scope define onde as permissões concedidas pelos statements serão aplicadas.
Por exemplo, uma policy pode estar associada ao root compartment e conter:
| Allow group Corporate/AppAdmins to manage instance-family in compartment Application-A |
Nesse caso, a policy é administrada no nível do tenancy, mas a autorização concedida pelo statement continua limitada ao compartment Application-A e à hierarquia aplicável abaixo dele.
Por outro lado, quando uma policy é associada a um child compartment, administradores que possuem permissão para gerenciar policies naquele compartment podem também alterar ou excluir essa policy, sem necessariamente receber capacidade para administrar policies do tenancy inteiro. Esse mecanismo é importante para implementar administração delegada.
Essa separação é particularmente importante em ambientes corporativos. Policies corporativas ou de segurança podem permanecer sob administração centralizada, enquanto policies específicas de aplicações podem ser delegadas aos administradores dos respectivos compartments.
Herança de Policies
No OCI, a hierarquia de compartments também influencia a autorização. Compartments filhos herdam as permissões concedidas aos seus compartments pais.
Considere a seguinte estrutura:
A policy a seguir permite que o grupo administre os recursos correspondentes não apenas em Production, mas também nos subcompartments Application-A e Application-B:
| Allow group Corporate/NetworkAdmins to manage virtual-network-family in compartment Production |
Isso significa que, ao analisar o acesso a um determinado compartment, não basta verificar somente as policies diretamente associadas a ele. Também é necessário considerar as autorizações aplicáveis aos seus compartments superiores.
A herança facilita bastante a administração de ambientes com requisitos comuns. Por exemplo, uma equipe responsável por toda a infraestrutura de produção pode receber acesso no compartment Production sem que seja necessário repetir a mesma policy para cada aplicação. Por outro lado, conceder permissões muito amplas em níveis superiores da hierarquia pode aumentar significativamente o alcance do impacto de uma credencial comprometida ou de uma configuração incorreta.
Por esse motivo, utilizar child compartments para criar níveis adicionais de isolamento e definir policies adequadas para cada nível da estrutura pode ajudar a reduzir o alcance das permissões e tornar a delegação administrativa mais controlada.
Por que effective access é dificil de determinar?
Uma IAM Policy isolada mostra apenas uma parte da autorização. O acesso efetivo de um usuário ou workload é resultado da combinação de todos os privilégios que se aplicam àquela identidade.
Um usuário, por exemplo, pode pertencer a vários grupos (Corporate/Developers, Corporate/DBOperators, Corporate/Auditors) e cada grupo pode receber permissões por meio de policies diferentes. Como as permissões podem ser concedidas por statements distintos e por diferentes grupos dos quais o usuário participa, o resultado precisa ser analisado de forma consolidada.
Além disso, a análise precisa considerar:
- memberships em múltiplos grupos;
- policies aplicadas em diferentes níveis da hierarquia;
- herança de permissões de parent compartments;
- condições definidas nos statements;
- administrator roles dos Identity Domains;
- Dynamic Groups e workload identities, quando aplicável;
- Deny Policies, caso esse recurso tenha sido habilitado no tenancy.
Por exemplo, uma policy aparentemente restritiva, não garante que aqueles usuários possuam apenas acesso de leitura.
| Allow group Corporate/Developers to read database-family in compartment Production |
Um membro desse grupo pode também pertencer a “DBOperators”, que recebe:
| Allow group Corporate/DBOperators to manage database-family in compartment Production |
Nesse caso, o acesso efetivo inclui as permissões concedidas pelo segundo statement.
Condições tornam essa análise ainda mais contextual. Saber quais permissões foram concedidas não é suficiente, pois a cláusula “where” pode limitar essas permissões a determinados recursos ou circunstâncias específicas.
Boa prática de segurança: uma revisão de IAM deve analisar o conjunto de autorizações aplicáveis à identidade, e não apenas cada policy individualmente.
Esse é um dos principais motivos pelos quais ambientes OCI maiores se beneficiam de inventário automatizado, revisão periódica de grupos e análise de privilégios efetivos, assuntos que serão aprofundados nos próximos artigos da série.
Conclusão
Na prática, uma boa revisão de IAM começa com algumas perguntas simples:
- Quem recebe o acesso?
- Por meio de qual grupo?
- Qual verbo está sendo utilizado?
- O resource-type está mais amplo do que o necessário?
- O acesso precisa realmente valer para todo o tenancy?
- Existem permissões herdadas de compartments superiores?
- O usuário pertence a outros grupos que ampliam esse acesso?
Responder a essas perguntas já ajuda a identificar boa parte dos excessos de privilégio mais comuns. Antes de criar ou alterar uma policy, vale também consultar a Detailed Service Policy Reference para confirmar quais permissões e operações estão realmente associadas ao verbo escolhido.
No próximo artigo da série, vamos partir dessa base para aplicar least privilege de forma prática, reduzindo escopo, privilégios e alcance do impacto sem comprometer a operação do ambiente.