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, environments, 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. No segundo, aplicamos least privilege para reduzir escopo, recursos e permissões. No terceiro, avançamos para a arquitetura de IAM em escala. No quarto, tratamos da governança necessária para descobrir, revisar, priorizar, controlar e monitorar essas autorizações ao longo do tempo.
Neste quinto e último artigo, entramos em uma mudança importante no modelo de autorização do OCI: Deny Policies.
Até aqui, praticamente toda a discussão partiu de uma pergunta: quem deve receber determinada permissão?
Com Deny Policies, surge outra: quais ações precisam permanecer bloqueadas mesmo quando alguma Allow Policy concederia acesso?
A partir daqui, vamos analisar como esse mecanismo pode ser utilizado para criar guardrails, limitar determinados privilégios e estabelecer restrições que não dependem apenas de revisar todas as Allow Policies existentes.
OCI IAM Deny Policies: Guardrails, Limitações e Novos Modelos de Segurança
Durante muito tempo, o modelo de autorização do OCI foi essencialmente aditivo. Uma identidade recebia acesso quando alguma policy aplicável concedia as permissões necessárias. Se existissem vários grupos e várias policies, essas autorizações se acumulavam para formar o effective access.
Deny Policies introduzem uma nova variável nesse modelo. Um deny aplicável pode impedir uma ação mesmo quando uma Allow Policy concederia aquela permissão. Isso permite construir controles que antes dependiam exclusivamente de garantir que nenhuma autorização incompatível fosse criada em outro ponto do tenancy.
Mas esse poder também aumenta o risco de erro. Uma Deny Policy excessivamente ampla pode bloquear operações legítimas e afetar usuários que anteriormente possuíam acesso válido. Existem ainda exceções e limitações importantes: o grupo Administrators padrão do domínio Default é isento de Deny Policies, Deny Policies não sobrepõem roles administrativas de Identity Domains e existem known issues envolvendo tags e Dynamic Groups.
Além disso, o recurso não está habilitado por padrão. A ativação precisa ser feita explicitamente e, uma vez realizada, não pode ser desfeita. Isso por si só já indica que a decisão deve ser tratada como uma mudança arquitetural de IAM, e não apenas como mais uma configuração.
Neste artigo, vamos analisar onde Deny Policies realmente agregam valor, como sua precedência altera a avaliação de acesso, quais guardrails podem ser construídos, quais limitações precisam ser consideradas e, principalmente, quando negar explicitamente é melhor do que continuar tentando controlar tudo apenas com Allow Policies.
Allow versus Deny
Até a introdução das Deny Policies, o modelo de autorização do OCI era essencialmente baseado em concessões.
Uma Allow Policy responde: o que essa identidade pode fazer?
Se nenhuma policy aplicável conceder as permissões necessárias, o acesso não acontece.
Deny Policies acrescentam uma segunda camada à avaliação: mesmo existindo uma concessão, existe alguma regra que bloqueia essa ação?
A documentação do OCI define que uma Deny Policy aplicável tem precedência sobre uma Allow Policy. Em termos conceituais, o effective access passa a ser resultado das permissões concedidas pelas Allow Policies, limitado pelas Deny Policies aplicáveis.
Considere uma equipe que possui esta autorização:
| Allow group Corporate/AppAdmins to manage instances in compartment Production |
Depois, uma Deny Policy é adicionada para o mesmo grupo e escopo:
| Deny group Corporate/AppAdmins to manage instances in compartment Production |
A existência da primeira policy não anula a segunda. Para as permissões atingidas pelo deny, a restrição prevalece.
Mas existe um detalhe importante: Allow e Deny não possuem comportamento simétrico quando utilizamos os metaverbs.
Em uma Allow Policy, manage inclui as permissões associadas a use, read e inspect. Em uma Deny Policy, negar manage não significa necessariamente negar também esses níveis inferiores. A documentação chama esse comportamento de Metaverb Inversion.
Isso significa que Deny Policies não devem ser tratadas simplesmente como uma versão negativa das Allow Policies.
A lógica de autorização mudou.
- Com Allow Policies, o objetivo é construir as permissões necessárias.
- Com Deny Policies, o objetivo é estabelecer limites que continuam válidos mesmo quando outras policies concedem acesso.
Essa diferença torna o mecanismo especialmente interessante para criação de guardrails, mas também exige mais cuidado: uma regra de deny mal desenhada pode bloquear operações legítimas em vários pontos do tenancy.
Por isso, utilize Deny Policies para representar restrições que precisam permanecer verdadeiras independentemente das concessões existentes, e não como substituto para um modelo bem definido de least privilege.
Feature opt-in
Deny Policies não estão habilitadas por padrão no OCI. Antes de utilizar qualquer statement deny, o recurso precisa ser ativado explicitamente. Segundo a documentação atual, somente membros do grupo Administrators padrão do domínio Default podem realizar essa ativação pela Console.
Existe um detalhe que torna essa decisão especialmente importante: depois de habilitado, o recurso não pode ser desabilitado.
A ativação é permanente. É possível controlar posteriormente quem pode criar ou alterar Deny Policies, mas não retornar o tenancy ao estado anterior no qual o recurso estava desabilitado.
Por isso, trate a habilitação como uma decisão de arquitetura e governança de IAM, e não apenas como a ativação de mais uma funcionalidade.
Antes de habilitar o recurso, defina pelo menos:
- Quem poderá criar e alterar Deny Policies;
- Como essas mudanças serão revisadas;
- Quais guardrails serão implementados primeiro;
- Como recuperar o acesso caso uma regra excessivamente ampla bloqueie operações legítimas;
- Como Deny Policies entrarão no processo de Policy as Code, Audit e monitoração.
O workflow de ativação também permite que o OCI crie uma Deny Policy no root para restringir quem pode escrever outros statements deny. Nesse modelo, o administrador que habilitou o recurso e os membros do grupo Administrators padrão continuam autorizados a gerenciar essas policies.
Existe ainda uma proteção importante contra lockout: os membros do grupo Administrators padrão do domínio Default são sempre isentos das Deny Policies. Isso preserva um caminho administrativo caso uma regra excessivamente ampla bloqueie outros usuários.
Essa exceção também precisa fazer parte do desenho de segurança. Deny Policies podem criar guardrails fortes para grande parte do tenancy, mas não representam uma camada absoluta de bloqueio sobre esse grupo administrativo.
O ponto principal é simples: habilitar Deny Policies é fácil. Decidir como elas serão governadas antes da habilitação é a parte realmente importante.
Administrators group
Deny Policies podem bloquear acessos concedidos por Allow Policies, mas existe uma exceção importante: os membros do grupo Administrators padrão do domínio Default são sempre isentos das Deny Policies.
Essa exceção existe como mecanismo de prevenção de lockout. Uma Deny Policy excessivamente ampla poderia bloquear inclusive o administrador que a criou. Manter o grupo Administrators fora da avaliação de deny preserva um caminho administrativo para recuperar o ambiente.
O grupo Administrators faz parte do domínio Default criado com o tenancy e possui, por padrão, uma policy que permite administrar todos os recursos:
| Allow group Administrators to manage all-resources in tenancy |
Como essa policy se aplica ao tenancy, o grupo possui acesso administrativo aos recursos existentes nos compartments abaixo do root.
Essa exceção tem uma consequência importante para o desenho dos guardrails. Considere uma Deny Policy criada para impedir determinada operação no tenancy. Ela pode restringir grupos administrativos delegados, desenvolvedores, operadores e outros principals, mas não pode ser utilizada para impedir os membros desse grupo Administrators de realizar a mesma operação.
Por isso, Deny Policies não devem ser interpretadas como uma camada absoluta de proteção contra qualquer identidade administrativa. O controle sobre o grupo Administrators continua sendo crítico.
Mantenha sua membership reduzida, proteja fortemente essas contas e utilize grupos administrativos delegados para as atividades que não exigem acesso irrestrito ao tenancy.
Também é importante não generalizar essa exceção. Ela se aplica especificamente ao grupo Administrators padrão do domínio Default. Um grupo criado manualmente com nome semelhante não recebe essa proteção simplesmente por ser chamado de Administrators. Da mesma forma, administrative roles dos Identity Domains são outro mecanismo de autorização e possuem comportamento próprio em relação às Deny Policies.
Na prática, trate o grupo Administrators como uma identidade de recuperação e administração de último nível.
Deny Policies ajudam a limitar privilégios elevados, mas não substituem a governança de quem continua fora desses guardrails.
Metaverb inversion
Uma das diferenças mais importantes entre Allow e Deny Policies está no comportamento dos metaverbs.
Nas Allow Policies, os níveis de acesso são cumulativos. read inclui as permissões de inspect, use inclui as permissões de read e inspect, e manage representa o conjunto mais amplo para aquele resource-type.
Com Deny Policies, essa lógica precisa ser interpretada de forma diferente. Negar manage não significa negar automaticamente use, read e inspect. O deny remove as permissões correspondentes ao nível especificado e, dependendo do metaverb utilizado, permissões de níveis inferiores podem continuar disponíveis se alguma Allow Policy as conceder.
Considere este exemplo:
| Allow group Corporate/AppAdmins to manage buckets in compartment Production Deny group Corporate/AppAdmins to manage buckets in compartment Production |
O deny manage pode bloquear operações administrativas, como exclusão, sem necessariamente impedir leitura ou inspeção dos buckets. A própria documentação utiliza esse tipo de exemplo para demonstrar o comportamento.
Se o objetivo for aplicar uma restrição mais ampla, o metaverb usado no deny precisa ser escolhido de acordo com as permissões que realmente devem ser removidas.
De forma simplificada:
| Deny utilizado | Efeito esperado |
| deny manage | restringe permissões de `manage`, sem necessariamente bloquear níveis inferiores |
| deny use | restringe permissões de `use` e operações superiores que dependem delas |
| deny read | restringe `read` e níveis superiores |
| deny inspect | produz a restrição mais ampla entre os metaverbs |
Esse detalhe cria uma armadilha importante. Em uma Allow Policy, utilizar manage amplia o acesso. Em uma Deny Policy, utilizar manage pode produzir uma restrição menor do que alguém esperaria ao apenas inverter a palavra allow para deny. Por isso, evite converter Allow Policies em Deny Policies de forma mecânica.
Primeiro identifique quais permissões precisam ser bloqueadas. Depois escolha o metaverb que corresponda ao alcance real dessa restrição.
Deny Policies não invertem apenas a decisão de acesso. Elas também mudam a forma como os metaverbs precisam ser interpretados.
Deny como guardrail
O principal valor das Deny Policies aparece quando elas são utilizadas como guardrails.
Uma Allow Policy define o acesso necessário para uma função. Um guardrail define uma restrição que deve continuar válida mesmo que outra policy conceda permissões mais amplas no futuro.
Considere um grupo administrativo com permissão ampla sobre Object Storage em Production:
| Allow group Corporate/StorageAdmins to manage object-family in compartment Production |
Se a organização decidir que esse grupo pode administrar o ambiente, mas não deve excluir buckets ou objetos, a restrição pode ser expressa de forma explícita:
| Deny group Corporate/StorageAdmins to {BUCKET_DELETE, OBJECT_DELETE} in compartment Production |
Mesmo que outra Allow Policy continue concedendo manage object-family, as permissões explicitamente negadas permanecem bloqueadas porque Deny Policies têm precedência sobre Allow Policies.
Esse modelo é diferente de tentar garantir a restrição revisando todas as Allow Policies existentes.
Sem o guardrail, uma nova policy criada posteriormente poderia reintroduzir a permissão que deveria permanecer restrita. Com o deny, a restrição passa a fazer parte do próprio modelo de autorização.
A documentação do OCI destaca justamente esse uso: administradores no root podem estabelecer restrições amplas que funcionam como guardrails para o tenancy.
Isso não significa que todo controle de segurança deva virar uma Deny Policy. Utilize guardrails para requisitos que precisam permanecer verdadeiros independentemente das concessões feitas por outras equipes, por exemplo:
- Impedir determinadas operações destrutivas;
- Proteger recursos ou compartments críticos;
- Impedir que determinados grupos executem operações administrativas específicas;
- Restringir quem pode criar ou alterar Deny Policies.
No exemplo de Object Storage, essa preocupação também está alinhada à recomendação da documentação de segurança do serviço de limitar BUCKET_DELETE e OBJECT_DELETE a um conjunto mínimo de identidades.
Quanto mais amplo o guardrail, maior deve ser o cuidado com sua implementação.
Uma Deny Policy criada em um nível elevado da hierarquia pode afetar muitos recursos e identidades. Antes de aplicá-la, valide o escopo, as permissões negadas e os workloads que podem depender delas.
A lógica é simples:
Allow define o que uma identidade precisa fazer. Deny pode estabelecer aquilo que ela não deve conseguir fazer, mesmo quando uma concessão futura tentar ampliar esse acesso.
É nesse papel que Deny Policies deixam de ser apenas uma nova sintaxe e passam a funcionar como uma camada de governança.
Delegated administration
Deny Policies também mudam a forma como a administração de IAM pode ser delegada.
Em ambientes maiores, é comum permitir que uma equipe administre policies dentro de determinado compartment sem conceder controle sobre todo o tenancy. O problema é que, depois que Deny Policies estão habilitadas, permitir que esse administrador gerencie policies pode incluir também a capacidade de criar statements deny.
Isso aumenta significativamente o poder da delegação.
A documentação do OCI alerta que administradores de compartments filhos podem utilizar Deny Policies para bloquear acessos concedidos a administradores em níveis superiores da hierarquia. A exceção continua sendo o grupo Administrators padrão do domínio Default, que permanece isento das Deny Policies.
Por isso, delegar manage policies passa a exigir uma decisão adicional: esse administrador deve poder criar apenas Allow Policies ou também Deny Policies?
O OCI disponibiliza a variável de contexto target.policy.type justamente para controlar esse comportamento. Ela permite diferenciar operações sobre policies que contêm statements allow das que contêm statements deny.
Considere uma equipe responsável pelo IAM do compartment Application-A:
| Allow group Corporate/AppA-IAM-Admins to manage policies in compartment Application-A |
Sem outra restrição, esse grupo pode administrar as policies dentro do escopo concedido.
Se a intenção for permitir administração delegada de Allow Policies, mas impedir a criação ou alteração de Deny Policies, acrescente um guardrail:
| Deny group Corporate/AppA-IAM-Admins to manage policies in compartment Application-A where target.policy.type = ‘deny’ |
O grupo continua podendo administrar policies permitidas pela primeira concessão, mas operações que envolvam Deny Policies são bloqueadas pela segunda regra. A documentação apresenta esse uso de target.policy.type como mecanismo para restringir quais tipos de policy um autor pode modificar.
Esse controle é especialmente importante porque uma Deny Policy não afeta apenas quem a criou. Uma regra excessivamente ampla em um compartment pode bloquear outras equipes que possuíam acesso legítimo por meio de policies definidas em níveis superiores.
Portanto, não trate a permissão para criar Deny Policies como uma extensão automática da administração normal de IAM.
Separe, sempre que possível, três responsabilidades:
- Administração dos recursos;
- Criação de Allow Policies;
- Criação e alteração de Deny Policies.
A ativação inicial do recurso já segue essa lógica. O workflow do OCI pode criar uma policy no root que restringe quem está autorizado a escrever Deny Policies, mantendo essa capacidade com o administrador que habilitou o recurso e com o grupo Administrators padrão.
Utilize esse princípio também nas delegações criadas posteriormente.
Administrar acesso e criar guardrails são responsabilidades diferentes. Quanto maior o alcance de uma Deny Policy, mais restrito deve ser o grupo autorizado a criá-la ou alterá-la.
Known Issues
Deny Policies ainda possuem algumas limitações documentadas que precisam fazer parte do desenho do controle. Ignorar esses comportamentos pode criar uma situação perigosa: a policy parece representar um guardrail, mas determinadas operações podem não ser bloqueadas como esperado. A documentação atual do OCI lista quatro Known Issues principais.
Propagação inicial de Deny Policies baseadas em tags
Quando Deny Policies são habilitadas pela primeira vez no tenancy, policies baseadas em tags aplicadas a users, groups e Dynamic Groups podem levar até 24 horas para se tornarem totalmente efetivas. Não trate a criação da policy como evidência de que o guardrail já está completamente ativo.
Se uma Deny Policy baseada em tags estiver protegendo uma operação crítica, considere esse período durante o planejamento da ativação e valide o comportamento antes de depender do controle.
Administrative Roles dos Identity Domains
Deny Policies não sobrepõem administrative roles dos Identity Domains, como Identity Domain Administrator, Security Administrator ou User Manager.
Esse comportamento é diferente da exceção do grupo Administrators padrão que vimos anteriormente. Uma Deny Policy pode restringir permissões concedidas por IAM Policies, mas não deve ser utilizada como mecanismo para limitar privilégios originados dessas administrative roles.
Exclusões pela Console com conditions baseadas em tags
Existe também um Known Issue envolvendo Deny Policies que utilizam tags do recurso de destino.
Atualmente, uma Deny Policy baseada em target.resource.tag pode não impedir a exclusão de users, groups ou Dynamic Groups quando a operação é iniciada pela Console. Isso significa que um guardrail baseado em tags precisa ser testado considerando o caminho utilizado para executar a operação, e não apenas a sintaxe da policy.
Identificadores de Dynamic Groups
Conditions de Deny Policies que utilizem target.dynamicgroup.id ou target.dynamicgroup.name não são suportadas atualmente para enforcement pela Console, SDK ou API.
Portanto, evite construir um guardrail dependendo dessas variáveis enquanto essa limitação permanecer documentada. A documentação recomenda utilizar tags como alternativa para controlar acesso relacionado a Dynamic Groups.
Trate Known Issues como parte do desenho
Essas limitações não tornam Deny Policies inadequadas para guardrails.
Elas mostram que um statement deny não deve ser considerado um controle efetivo apenas porque foi criado com sucesso. Valide o comportamento pela Console, OCI CLI, SDK ou API conforme os caminhos utilizados no ambiente e inclua os Known Issues na revisão técnica antes de colocar o guardrail em produção.
Como esse recurso é relativamente novo e esses comportamentos podem mudar, consulte novamente a documentação de Deny Policies Known Issues sempre que novos controles forem implementados. A página oficial continua listando explicitamente essas quatro limitações.
Modelo recomendado
Deny Policies acrescentam uma nova camada ao modelo de autorização do OCI, mas não deveriam se tornar o mecanismo principal para corrigir permissões excessivamente amplas.
O modelo mais seguro continua começando pelas Allow Policies. Conceda apenas o acesso necessário, utilizando escopo, resource-types, verbs e conditions compatíveis com a função que precisa ser executada. Utilize Deny Policies depois, como uma camada adicional para representar restrições que precisam permanecer válidas mesmo quando outras autorizações forem criadas.
A documentação de melhores práticas da Oracle segue essa mesma direção: Deny Policies são recomendadas para guardrails explícitos, enquanto as Allow Policies continuam responsáveis por definir o acesso necessário.
Mantenha Allow como base
Evite partir de uma autorização excessivamente ampla e tentar corrigir tudo posteriormente com denies.
Por exemplo, conceder manage all-resources in tenancy e depois criar dezenas de Deny Policies para retirar acessos específicos tende a produzir um modelo difícil de entender e manter. A própria documentação de melhores práticas recomenda evitar all-resources quando não for realmente necessário e continuar utilizando Allow Policies explícitas para os serviços que precisam ser acessados.
O princípio permanece o mesmo discutido na Parte 2 desta série: comece pelo menor acesso necessário.
Utilize Deny para regras que não devem ser ultrapassadas
Reserve Deny Policies para restrições que representem guardrails reais.
Alguns exemplos são:
- Impedir operações destrutivas específicas;
- Proteger recursos ou compartments críticos;
- Limitar determinados privilégios de administradores delegados;
- Restringir quem pode criar ou alterar Deny Policies;
- Estabelecer controles que precisam continuar válidos mesmo após novas Allow Policies.
Quando o requisito for tenancy-wide, a documentação de melhores práticas recomenda implementar esses guardrails no root compartment, com statements específicos e cuidadosamente avaliados.
Restrinja quem pode escrever Deny Policies
Preserve a Deny Policy criada durante a habilitação do recurso e permita autoria de novos denies apenas para grupos que realmente precisam dessa responsabilidade.
A recomendação oficial é manter essa policy como baseline e alterar somente as exceções necessárias para permitir, por exemplo, que uma equipe central de segurança ou compliance também possa administrar Deny Policies. Para administração delegada, utilize target.policy.type para separar quem pode trabalhar com Allow Policies de quem pode criar ou alterar Deny Policies.
Preserve um caminho de recuperação
O grupo Administrators padrão do domínio Default permanece isento das Deny Policies.
Isso evita que um erro em um guardrail produza um lockout completo do tenancy. Essa proteção não elimina a necessidade de governança. Mantenha a membership desse grupo reduzida e utilize grupos administrativos delegados para atividades que não precisam de acesso irrestrito.
Teste o efeito, não apenas a sintaxe
Uma Deny Policy aceita pelo OCI não significa necessariamente que o controle produzirá o comportamento esperado.
Metaverb inversion, conditions, tags, Dynamic Groups e os Known Issues atuais podem alterar o resultado da avaliação.
Antes de aplicar um guardrail amplo, valide:
- Quais permissões serão efetivamente negadas;
- Quais identidades serão atingidas;
- Qual é o escopo hierárquico do statement;
- Se existem administrative roles fora do alcance do deny;
- Se o comportamento utilizado possui algum Known Issue documentado.
Monitore mudanças
Deny Policies possuem capacidade de bloquear operações mesmo quando Allow Policies concedem acesso.
Por isso, mudanças nesse tipo de policy merecem tratamento semelhante a outras alterações críticas de segurança. O OCI permite habilitar notificações para mudanças envolvendo Deny Policies, e a própria documentação recomenda monitorar essas alterações para ajudar no controle de risco. Integre essas mudanças ao mesmo processo de governança desenvolvido no artigo anterior: revisão, Policy as Code, Audit, monitoração e métricas.
O modelo recomendado pode ser resumido em um princípio: Allow define o acesso necessário. Deny define os limites que esse acesso não deve ultrapassar.
Quando essas duas camadas são utilizadas com funções claras, Deny Policies complementam o least privilege sem transformar o modelo de autorização em uma coleção de exceções difíceis de compreender.
Quando Deny agrega valor
Deny Policies agregam mais valor quando representam uma restrição que precisa continuar válida independentemente das Allow Policies existentes ou criadas no futuro.
Esse é o principal critério. Se o problema pode ser resolvido simplesmente reduzindo uma autorização excessivamente ampla, ajuste a Allow Policy. Deny não deve servir para compensar continuamente um modelo de least privilege mal definido.
Por outro lado, considere Deny quando o requisito for um guardrail.
Alguns cenários são especialmente adequados:
- Impedir operações destrutivas específicas sobre recursos críticos;
- Estabelecer restrições uniformes em todo o tenancy ou em uma hierarquia de compartments;
- Proteger ambientes de Production contra determinadas ações administrativas;
- Limitar administradores delegados sem remover sua autonomia operacional;
- Restringir quem pode criar ou alterar Deny Policies;
- Impedir que uma nova Allow Policy reintroduza um acesso que precisa permanecer bloqueado.
A documentação do OCI destaca justamente esse papel de explicit blocking e guardrails, inclusive permitindo que administradores no root estabeleçam restrições aplicáveis ao tenancy.
Deny também pode ser útil quando a restrição depende de contexto. Por exemplo, o OCI permite utilizar conditions para bloquear acessos com base em atributos da requisição, identidade, tags ou outros elementos suportados pela linguagem de policies. Isso permite criar controles mais específicos do que simplesmente remover um verbo de uma Allow Policy.
Um exemplo é exigir que determinado serviço seja acessado apenas por um caminho privado. A documentação apresenta o uso de Deny para bloquear acessos ao Object Storage quando a requisição não utiliza OCI Private Service Access, mesmo que outras Allow Policies concedam acesso ao serviço.
Esse é um bom exemplo da diferença entre os dois mecanismos:
- A Allow Policy continua respondendo quem pode acessar o serviço.
- A Deny Policy estabelece uma condição que esse acesso não pode violar.
Quando Deny provavelmente não é necessário
Evite introduzir Deny apenas porque uma Allow Policy ficou ampla demais.
Se um grupo possui manage all-resources in tenancy, por exemplo, criar uma grande quantidade de denies para reconstruir least privilege tende a produzir um modelo mais difícil de entender e revisar. As melhores práticas publicadas pela Oracle recomendam continuar definindo explicitamente os serviços que precisam ser permitidos e evitar all-resources quando ele não for realmente necessário.
Também evite Deny quando a restrição já pode ser expressa de forma clara com escopo, resource-type, verbo ou condition na própria Allow Policy. Cada camada adicional aumenta a quantidade de elementos que precisam ser considerados para determinar o effective access.
Por isso, antes de criar um deny, faça uma pergunta simples: essa restrição precisa sobreviver a futuras concessões de acesso?
Se a resposta for não, refine a Allow Policy. Se a resposta for sim, existe um bom candidato a guardrail.
Esse é o ponto em que Deny Policies realmente agregam valor: não apenas reduzindo acesso, mas estabelecendo limites que o restante do modelo de autorização não deve conseguir ultrapassar.
Quando não usar
Deny Policies são úteis para guardrails, mas não devem ser utilizadas como correção padrão para qualquer problema de autorização.
O primeiro caso em que Deny provavelmente não é necessário é quando o acesso pode ser reduzido diretamente na Allow Policy. Se um grupo possui permissões excessivas, prefira corrigir a origem do problema. Reduza o verbo, restrinja o resource-type, diminua o escopo ou adicione uma condition apropriada.
Evite, por exemplo, manter manage all-resources in tenancy e tentar reconstruir least privilege por meio de uma coleção de Deny Policies. As melhores práticas publicadas pela Oracle recomendam evitar all-resources quando não for realmente necessário e definir explicitamente os serviços que precisam ser acessados.
Também evite Deny quando a restrição:
- Depende de um comportamento listado atualmente como Known Issue;
- Pode bloquear operações essenciais sem um procedimento claro de recuperação;
- Utiliza any-user ou escopo no root sem que o impacto tenha sido testado;
- Existe apenas para compensar uma arquitetura de compartments ou delegação mal definida;
- Não representa uma regra que precise permanecer válida diante de futuras concessões.
Policies excessivamente amplas no root merecem atenção especial. A documentação de melhores práticas recomenda guardrails claros e específicos e alerta que denies muito abrangentes podem interromper operações legítimas no tenancy.
Outro caso importante envolve controles que já possuem mecanismo próprio no OCI. Se o requisito for aplicar regras predefinidas de configuração segura para determinados recursos, avalie se Security Zones atendem melhor ao objetivo. Deny Policies são mais adequadas para restrições personalizadas de autorização, enquanto Security Zones aplicam regras de segurança próprias sobre configurações de recursos.
Também não utilize Deny para tentar restringir o grupo Administrators padrão do domínio Default ou administrative roles dos Identity Domains. O primeiro é explicitamente isento das Deny Policies, e essas policies também não sobrepõem os privilégios concedidos por administrative roles dos Identity Domains.
A regra prática é simples:
- se o requisito é reduzir o acesso concedido, corrija primeiro a Allow Policy.
- Se o requisito é estabelecer um limite que futuras concessões não devem ultrapassar, então Deny pode ser o mecanismo adequado.
Quanto mais uma arquitetura depender de denies para compensar allows excessivos, mais difícil será entender e revisar o effective access ao longo do tempo.
Conclusão da série
Ao longo deste artigo, vimos que Deny Policies não são apenas o inverso de Allow Policies.
Elas acrescentam uma segunda camada ao modelo de autorização do OCI: além de definir o que uma identidade pode fazer, passa a ser possível estabelecer limites que continuam válidos mesmo quando outras policies concedem acesso. Esse mecanismo abre espaço para guardrails mais fortes, mas também exige cuidado.
Deny Policies possuem comportamento próprio, incluindo precedência sobre allows aplicáveis, metaverb inversion, exceção para o grupo Administrators padrão do domínio Default, impactos sobre delegated administration e Known Issues que precisam ser considerados antes da adoção em produção.
Por isso, utilize Deny Policies para representar restrições que precisam permanecer verdadeiras independentemente das concessões existentes ou futuras.
Não utilize deny para compensar sistematicamente Allow Policies excessivamente amplas.
O modelo recomendado continua sendo:
- Allow Policies como base do acesso, seguindo least privilege;
- Deny Policies como guardrails para restrições explícitas;
- Administração restrita de quem pode criar ou alterar denies;
- Caminho administrativo de recuperação preservado;
- Validação do comportamento antes da adoção em produção;
- Monitoração das mudanças e revisão periódica dos controles.
Esse equilíbrio é importante.
Deny Policies ajudam a impor limites claros, mas não eliminam a necessidade de um bom desenho de acesso. Se o modelo de Allow estiver mal definido, adicionar denies apenas torna o effective access mais difícil de entender.
Finalizando a série
Esta série começou com uma pergunta relativamente simples: como o modelo de autorização do OCI realmente funciona?
A partir daí, avançamos por cinco etapas.
No primeiro artigo, construímos a base do modelo de autorização: Identity Domains, grupos, verbs, resource-types, compartments, herança, conditions e effective access.
No segundo, aplicamos least privilege de forma prática, reduzindo escopo, recursos e permissões para limitar o alcance do impacto.
No terceiro, saímos da policy individual e entramos em IAM em escala, utilizando Compartments, Dynamic Groups, Instance Principals e Tag-Based Access Control.
No quarto, tratamos de como manter esse modelo sob controle ao longo do tempo, com Discovery, inventário, duplicidades, Risk Scoring, Policy as Code, Audit, monitoração e métricas.
E, neste quinto artigo, adicionamos uma nova camada com Deny Policies, guardrails e restrições explícitas.
O fio condutor entre todas essas partes é o mesmo: IAM não é apenas escrever policies que funcionam. É entender como o acesso é construído, limitar o que é necessário e manter esse modelo compreensível à medida que o ambiente cresce.
Uma policy pode estar sintaticamente correta e ainda assim conceder acesso demais. Uma arquitetura pode estar bem estruturada e ainda permitir que uma nova concessão ultrapasse um limite importante. E um guardrail pode existir, mas não produzir o efeito esperado se suas exceções, condições ou limitações não forem compreendidas.
Por isso, segurança em IAM depende da combinação de vários elementos: modelo de autorização bem compreendido, least privilege, arquitetura coerente e guardrails onde eles realmente agregam valor.
Não existe uma única policy que resolva IAM. Existe um modelo que precisa continuar compreensível, revisável e proporcional ao risco do ambiente. E quanto maior o tenancy, mais importante isso se torna.