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 cinco 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.
No primeiro artigo da série, vimos como o modelo de autorização do OCI funciona e como Identity Domains, grupos, verbs, resource-types, compartments, herança e conditions se combinam para determinar o acesso efetivo dentro do tenancy.
Neste segundo artigo, vamos partir dessa base para aplicar o princípio de least privilege de forma prática: reduzir escopo, recursos e permissões sem comprometer a operação. O objetivo é entender como transformar policies que simplesmente funcionam em policies cujo nível de acesso seja proporcional à função que precisam atender.
A partir daqui, começamos a sair do entendimento do modelo e entramos na sua aplicação prática.
Least Privilege no OCI: Como Escrever Policies Melhores e Reduzir o Alcance do Impacto
No primeiro artigo da série, vimos como o OCI combina Identity Domains, grupos, verbs, resource-types, compartments, herança e conditions para determinar o acesso efetivo.
Essa base é importante porque uma policy aparentemente simples pode produzir um resultado bem mais amplo do que o esperado.
Agora a discussão avança para a próxima pergunta:
“O acesso concedido é realmente o mínimo necessário para aquela função?”
Esse é o princípio de least privilege. No OCI, aplicar least privilege não significa simplesmente evitar manage. O nível real de privilégio depende da combinação entre quem recebe o acesso, quais operações são permitidas, quais recursos são afetados, em qual escopo e sob quais condições.
Uma policy com manage pode ser adequada quando está restrita ao contexto correto. Da mesma forma, uma policy com um verbo mais limitado ainda pode representar risco elevado se estiver aplicada a um resource-type amplo ou a todo o tenancy.
Por isso, o objetivo não é escrever a policy mais restritiva possível. É escrever a policy mais restritiva que ainda permita executar a função necessária de forma segura e operacionalmente viável.
Neste artigo, vamos aplicar esse raciocínio de forma prática, reduzindo escopo, resource-types e permissões, além de usar conditions quando elas realmente ajudam a limitar o acesso.
O problema não é conceder acesso. O problema é conceder mais acesso do que o necessário.
Comece pelo Escopo
Quando reviso uma policy, normalmente começo pelo location, antes mesmo de analisar o verb.
O motivo é simples: reduzir o escopo pode diminuir significativamente o alcance do impacto sem alterar o que o usuário consegue fazer dentro do ambiente pelo qual é responsável.
Compare:
| Allow group Corporate/DBAdmins to manage database-family in tenancy |
com:
| Allow group Corporate/DBAdmins to manage database-family in compartment Production-Databases |
O privilégio continua sendo manage database-family. O que mudou foi onde ele pode ser exercido.
No primeiro caso, o acesso se aplica aos recursos correspondentes em todo o tenancy. No segundo, fica limitado ao compartment Production-Databases e aos subcompartments abaixo dele, conforme a hierarquia existente.
A documentação de segurança do OCI orienta, sempre que possível, a limitar policies aos compartments que realmente precisam ser acessados, em vez de utilizar todo o tenancy.
Isso torna o location uma das primeiras perguntas em uma revisão de least privilege:
Esse grupo realmente precisa desse acesso em todo o tenancy?
Se a resposta for não, reduzir o scope costuma ser uma das mudanças mais simples e efetivas.
Quando um grupo precisa acessar dois ambientes independentes, por exemplo, é possível criar statements separados:
| Allow group Corporate/DBAdmins to manage database-family in compartment Production-Databases Allow group Corporate/DBAdmins to manage database-family in compartment DR-Databases |
Isso aumenta um pouco o número de statements, mas mantém os acessos separados. Se, no futuro, o grupo deixar de administrar o ambiente de DR, esse acesso pode ser removido sem alterar a autorização sobre produção.
Nem todo acesso pode ou deve ser limitado dessa forma. Alguns recursos são administrados no nível do tenancy, e determinados grupos realmente possuem responsabilidades que exigem um scope mais amplo.
O ponto não é evitar in tenancy, é conseguir justificar por que ele é necessário.
Boa prática de segurança: antes de reduzir verbs ou quebrar resource families, verifique se o mesmo requisito pode ser atendido diminuindo o scope da policy.
Em muitos casos, essa é a forma mais direta de reduzir o alcance do impacto sem comprometer a operação.
Depois Reduza o Resource-Type
Depois de limitar onde a policy pode ser utilizada, o próximo passo é revisar sobre quais recursos ela atua.
Considere:
| Allow group Corporate/ComputeAdmins to manage all-resources in compartment Production |
Se esse grupo administra apenas recursos de Compute, all-resources concede muito mais acesso do que o requisito indica. Uma primeira redução seria:
| Allow group Corporate/ComputeAdmins to manage instance-family in compartment Production |
E, se a atividade exigir apenas administração das instâncias:
| Allow group Corporate/ComputeAdmins to manage instances in compartment Production |
A documentação do OCI diferencia três níveis: resource-types individuais, como instances; resource families, como instance-family; e all-resources, que abrange todos os resource-types existentes no escopo definido pela policy.
Resource families são úteis porque agrupam recursos normalmente utilizados em conjunto e evitam a necessidade de vários statements. Mas essa conveniência também amplia o conjunto de permissions concedidas.
No caso de instance-family, por exemplo, a documentação mostra que a família inclui algumas permissões adicionais relacionadas a VNICs e volumes para suportar operações comuns com Compute. Ou seja, uma family não deve ser interpretada apenas como uma abreviação textual para seus resource-types individuais.
Isso também significa que trocar uma family por um resource-type específico exige entender a operação que precisa ser executada. Algumas operações OCI dependem de permissões sobre vários tipos de recursos e podem exigir statements adicionais.
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 difícil de entender e manter.
Outro ponto merece atenção: quando novos resource-types são adicionados a um serviço, eles normalmente podem passar a fazer parte da family correspondente. Portanto, policies privilegiadas baseadas em resource families devem ser revisadas periodicamente para verificar se o seu alcance continua adequado.
O objetivo não é eliminar resource families. É utilizá-las quando o conjunto de recursos representado pela family realmente corresponde à função que está sendo concedida.
Depois Reduza o verbo
Depois de limitar o escopo e o resource-type, o próximo passo é revisar o que o grupo realmente precisa fazer.
Considere:
| Allow group Corporate/ComputeOperators to manage instances in compartment Production |
Se esse grupo precisa apenas operar instâncias existentes, manage pode estar concedendo mais permissões do que o necessário. Uma alternativa pode ser:
| Allow group Corporate/ComputeOperators to use instances in compartment Production |
Se a função for apenas consultar informações:
| Allow group Corporate/ComputeOperators to read instances in compartment Production |
A documentação do OCI organiza os quatro metaverbs em níveis crescentes de privilégio.
read inclui as capacidades de inspect; use inclui read e normalmente permite trabalhar com recursos existentes; e manage inclui todas as permissões definidas para aquele resource-type.
Mas existe um detalhe importante: o efeito exato de cada verbo depende do resource-type.
Por exemplo, use normalmente não permite criar ou excluir recursos. Porém, algumas operações de atualização exigem manage quando possuem impacto equivalente à criação, como ocorre com determinadas operações de IAM e Networking.
Por isso, simplesmente trocar manage por use sem entender quais operações são necessárias pode quebrar a função operacional.
Boa prática de segurança: identifique primeiro as operações que a função realmente precisa executar e consulte a Detailed Service Policy Reference para verificar quais permissões e verbs as cobrem.
Esse ponto também é importante durante troubleshooting. Subir progressivamente de read para use e depois para manage até o erro desaparecer pode resolver o problema, mas não necessariamente identifica a permissão que estava faltando.
O objetivo não é evitar manage. É utilizá-lo quando todas, ou praticamente todas, as permissões associadas àquele resource-type fazem parte da função que está sendo concedida.
Quando Usar Permissões Explícitas
Os metaverbs simplificam bastante a criação de policies. Mas existem situações em que inspect, read, use ou manage ainda concedem um conjunto maior de permissões do que a função realmente precisa.
Um exemplo clássico é a administração de grupos. Imagine uma equipe que precisa listar, criar e alterar grupos, mas não pode excluí-los. Para essas operações, o metaverb necessário é manage, que também inclui a permissão GROUP_DELETE.
Nesse caso, a policy pode ser refinada utilizando request.permission:
| Allow group Corporate/IAMOperators to manage groups in tenancy where any { request.permission=’GROUP_INSPECT’, request.permission=’GROUP_CREATE’, request.permission=’GROUP_UPDATE’ } |
A policy continua utilizando manage groups, mas a condição limita quais permissões desse conjunto podem efetivamente ser utilizadas. A documentação do OCI define request.permission como a permissão subjacente solicitada pela operação e apresenta esse mecanismo justamente para reduzir o acesso concedido por um metaverb.
Também seria possível escrever:
| where request.permission != ‘GROUP_DELETE’ |
O resultado parece semelhante, mas existe uma diferença importante. Se novas permissões forem adicionadas futuramente ao conjunto de manage groups, uma condição baseada apenas em != ‘GROUP_DELETE’ poderá permitir essas novas permissões automaticamente. Já a lista explícita continua permitindo somente aquilo que foi definido.
A documentação de boas práticas de IAM da Oracle utiliza exatamente esse exemplo e recomenda a abordagem com as permissões explicitamente permitidas.
Isso não significa que toda policy deva ser escrita dessa forma. A granularidade adicional também aumenta o esforço de manutenção e pode exigir revisão quando novas operações forem necessárias.
Boa prática de segurança: considere permissões explícitas para funções sensíveis ou quando um metaverb concede operações claramente além do requisito. Para atividades operacionais comuns, os metaverbs continuam sendo uma abstração mais simples e adequada.
Least privilege não significa necessariamente escrever a policy mais longa. Significa conseguir justificar cada permissão que permanece.
Condições
Mesmo depois de reduzir escopo, resource-type e verbo, algumas situações ainda exigem um controle mais específico. É aí que entram as conditions.
A cláusula where permite que uma policy seja aplicada somente quando determinadas condições forem atendidas:
| Allow <subject> to <verb> <resource-type> in <location> where <condition> |
Por exemplo, um grupo pode ter acesso a objetos somente quando a requisição partir de uma origem de rede previamente definida:
| Allow group Corporate/BackupOperators to manage object-family in compartment Backups where request.networkSource.name=’corpnet’ |
Nesse caso, pertencer ao grupo não é suficiente. A requisição também precisa ter origem nos endereços definidos no Network Source corpnet. Esse comportamento é documentado no OCI IAM e pode ser usado como uma camada adicional de controle sobre o acesso.
As condições podem utilizar diferentes informações disponíveis no contexto da requisição. Entre as variáveis gerais documentadas estão:
- request.permission – permissão que está sendo solicitada;
- request.operation – operação da API;
- request.region – região onde a requisição é realizada;
- request.networkSource.name – origem de rede;
- request.utc-timestamp – horário da requisição;
- informações sobre o usuário e seus grupos.
Isso permite, por exemplo, restringir uma policy a uma região específica ou combinar condições quando necessário:
| Allow group Corporate/ComputeOperators to manage instances in compartment Production where request.region=’GRU’ |
Conditions são poderosas, mas também aumentam a complexidade da autorização. Uma policy pode parecer correta quando analisada isoladamente e ainda falhar porque determinada condição não é verdadeira naquele contexto.
Boa prática de segurança: use conditions quando elas representarem um requisito real de controle. Evite utilizá-las apenas para compensar uma policy que poderia ser melhor restringida pelo scope, resource-type ou verbo.
Na minha avaliação, a ordem continua sendo importante: primeiro reduza onde, sobre o quê e o que pode ser feito. Depois utilize conditions para controlar em quais circunstâncias esse acesso será permitido.
Essa combinação produz policies mais precisas sem transformar cada autorização em uma regra difícil de entender e manter.
Não Trate all-resources como uma Má Prática por Definição
all-resources é um dos elementos que mais chamam atenção durante uma revisão de IAM. E com razão: ele representa todos os resource-types existentes no escopo definido pela policy.
Mas isso não significa que seu uso esteja errado por definição.
Compare:
| Allow group Corporate/SandboxAdmins to manage all-resources in compartment Sandbox |
com:
| Allow group Corporate/AppAdmins to manage all-resources in tenancy |
Os dois statements utilizam manage all-resources, mas representam riscos muito diferentes.
No primeiro cenário, conceder ampla autonomia dentro de um sandbox isolado pode fazer sentido, dependendo do objetivo daquele ambiente e dos controles existentes.
No segundo, o mesmo grupo recebe capacidade de administrar praticamente qualquer recurso do tenancy. O alcance do impacto é muito maior.
A própria sintaxe documentada do OCI inclui como exemplo válido:
| Allow group A-Admins to manage all-resources in compartment Project-A |
Isso reforça que all-resources é um mecanismo legítimo da linguagem de policies, não necessariamente um erro de configuração.
Do ponto de vista de segurança, a pergunta mais útil não é:
- “Existe all-resources nesta policy?”
Mas sim:
- “Esse grupo realmente precisa administrar todos os tipos de recursos dentro desse escopo?”
Se a resposta for sim, all-resources pode ser uma escolha adequada. Se não, resource families ou resource-types individuais permitem reduzir o privilégio.
Boa prática de segurança: trate all-resources como um indicador para revisão, não como uma vulnerabilidade automática.
Least privilege depende da combinação entre quem recebe o acesso, o que pode fazer e onde pode fazer.
Uma policy ampla em um ambiente pequeno e isolado pode representar menos risco do que uma policy aparentemente mais restritiva aplicada a todo o tenancy.
Erros Comuns de Least Privilege
Depois de revisar escopo, resource-type, verbo e conditions, alguns erros ainda aparecem com frequência em policies IAM.
1. Resolver erros aumentando o privilégio
Durante troubleshooting, é comum começar com read, passar para use e terminar em manage até que a operação funcione.
Isso pode resolver o problema, mas não necessariamente identifica qual permissão estava faltando. Como o comportamento dos metaverbs depende do resource-type, a Detailed Service Policy Reference deve ser usada para confirmar quais operações e permissões são realmente necessárias.
2. Usar in tenancy por conveniência
Uma policy em todo o tenancy pode ser mais simples de escrever, mas também amplia significativamente seu alcance.
Quando a função está associada a um serviço, workload ou ambiente específico, limitar a autorização ao compartment correspondente tende a reduzir o alcance do impacto sem alterar a função operacional.
A documentação de segurança do OCI apresenta o uso de policies restritas a compartments como uma das formas de aplicar least privilege.
3. Usar all-resources sem avaliar o requisito
all-resources não é um erro por definição.
O problema aparece quando ele é usado apenas por conveniência, mesmo que a função precise administrar somente uma família ou um tipo específico de recurso.
Nesse caso, a simplicidade da policy está sendo obtida ao custo de um privilégio maior.
4. Usar manage como escolha padrão
manage inclui todas as permissões disponíveis para o resource-type.
Isso pode ser adequado para funções administrativas, mas tende a ser excessivo para atividades de operação, consulta ou auditoria.
A pergunta correta é:
- Quais operações essa função realmente precisa executar?
e não:
- Qual verbo faz tudo funcionar?
5. Acreditar que uma policy mais restrita reduz outra mais ampla
No modelo tradicional de policies “Allow”, as permissões aplicáveis à identidade se acumulam.
Considere um usuário que já recebe manage instances por meio de outro grupo. Adicionar uma nova policy com acesso apenas de leitura não reduz o privilégio anterior:
| Allow group Corporate/Developers to read instances in compartment Production |
O usuário continua com manage instances porque essa autorização já foi concedida por outro caminho.
Desde novembro de 2025, o OCI também suporta Deny Policies, mas esse é um recurso opt-in, com comportamento e limitações próprias. Esse tema será tratado separadamente nesta série.
6. Ignorar memberships acumulados
Uma policy pode estar adequada e, ainda assim, o usuário possuir privilégios excessivos por pertencer a outros grupos.
A análise precisa considerar o conjunto de memberships e todas as autorizações que chegam até aquela identidade.
A documentação de segurança do OCI recomenda revisões periódicas de memberships e a remoção de acessos que não sejam mais necessários.
Por isso, uma revisão de least privilege não termina na policy. Ela precisa responder três perguntas:
- quem recebe esse acesso;
- por quais caminhos esse acesso é concedido;
- se todos esses privilégios ainda são necessários.
No final, least privilege não é encontrar a policy mais restritiva possível. É conseguir justificar por que cada acesso existe, qual função ele suporta e qual risco permanece depois que esse acesso é concedido.
Checklist de Revisão de um Statement
Depois de entender os principais elementos de uma policy, uma revisão de least privilege pode seguir uma sequência simples. Considere este exemplo:
| Allow group Corporate/DBAdmins to manage database-family in tenancy |
Antes de aprovar ou manter esse statement, eu faria as seguintes perguntas:
1. Quem recebe o acesso?
O subject representa exatamente a função que precisa desse privilégio? Verifique também quem pertence ao grupo. Uma policy bem desenhada perde parte do seu valor se o grupo contém usuários que não precisam daquele acesso.
2. O escopo está correto?
Esse acesso precisa realmente valer para todo o tenancy? Se a função estiver associada apenas a determinados ambientes, restringir o statement a um compartment pode reduzir significativamente o alcance do impacto. A documentação de segurança do OCI recomenda limitar o acesso aos compartments necessários sempre que possível.
3. O resource-type está mais amplo do que o necessário?
O grupo precisa administrar toda a `database-family` ou apenas um resource-type específico? Resource families facilitam a administração, mas também ampliam o conjunto de recursos abrangidos pela autorização.
4. O verbo é realmente necessário?
A função precisa de manage ou as operações podem ser atendidas com use, read ou inspect? Os metaverbs representam níveis crescentes de acesso, mas o conjunto exato de permissões depende do resource-type.
5. Existe uma condição que pode reduzir o acesso?
Em alguns cenários, o requisito pode justificar uma condition baseada em rede de origem, região, operação ou permissão específica. Conditions devem refinar uma autorização que já possui scope e privilégios adequados, não compensar uma policy excessivamente ampla.
6. Esse acesso já existe por outro caminho?
O usuário pode pertencer a outros grupos ou receber autorização por policies definidas em níveis superiores da hierarquia. Por isso, revisar apenas o statement não é suficiente quando o objetivo é determinar o acesso efetivo.
7. Ainda existe uma justificativa para esse acesso?
Essa talvez seja a pergunta mais simples, e uma das mais importantes.
- Qual função de negócio ou operação técnica exige esse privilégio hoje?
Se ninguém consegue responder, o acesso merece revisão.
Na prática, eu resumiria a revisão em cinco perguntas:
Quem pode fazer o quê, sobre quais recursos, onde e sob quais condições?
Se cada uma dessas respostas puder ser justificada, a policy provavelmente está mais próxima de um modelo consistente de least privilege.
Conclusão
No artigo anterior, o foco foi entender como o modelo de autorização do OCI funciona: Identity Domains, grupos, verbs, resource-types, compartments, herança e acesso efetivo.
Nesta segunda parte, o passo seguinte foi aplicar esse conhecimento para reduzir privilégios de forma prática.
A lógica é simples:
- reduza primeiro o escopo;
- depois o resource-type;
- em seguida o verbo;
- use permissões explícitas quando os metaverbs forem amplos demais;
- adicione conditions quando elas realmente ajudarem a limitar o contexto de acesso.
O objetivo não é escrever a policy mais restritiva possível. É conceder apenas o acesso necessário, em um escopo que faça sentido, sem criar uma estrutura difícil de operar e manter.
Least privilege também não termina no statement. É preciso considerar memberships, herança e outros caminhos de autorização que podem ampliar o acesso efetivo.
No próximo artigo, a discussão muda de escala. Vamos analisar como Compartments, Dynamic Groups, Instance Principals e Tag-Based Access Control podem ajudar a estruturar IAM em ambientes maiores, reduzindo dependência de credenciais humanas e evitando a multiplicação desnecessária de policies.
Quanto maior o ambiente, menos IAM pode depender de exceções individuais. A arquitetura começa a importar tanto quanto a policy.