Série: OCI IAM Policies – Segurança, Otimização e Governança em Ambientes Corporativos (Parte 4)

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, utilizando Compartments, Dynamic Groups, Instance Principals e Tag-Based Access Control.

Neste quarto artigo, o foco muda novamente. Depois de definir uma boa arquitetura e escrever policies adequadas, surge outro problema: como garantir que esse modelo continue correto ao longo do tempo?

Policies são criadas, alteradas, duplicadas e, muitas vezes, permanecem no ambiente mesmo depois que o requisito original deixou de existir. Grupos mudam, workloads são movidos, novos serviços são adicionados e exceções começam a se acumular.

A partir daqui, vamos tratar IAM como um processo contínuo de governança: inventariar, revisar, identificar excessos, reduzir complexidade e automatizar parte dessa análise sempre que fizer sentido.

Governança de IAM: Como Revisar, Otimizar e Automatizar Policies em Ambientes Corporativos

Uma arquitetura de IAM pode estar bem desenhada hoje e se tornar difícil de entender alguns meses depois. O problema não é necessariamente uma policy incorreta. Muitas vezes, é o acúmulo.

Statements semelhantes, grupos que perderam função, acessos temporários que se tornaram permanentes, policies amplas criadas durante troubleshooting e exceções que ninguém mais sabe explicar.

Governança de IAM começa justamente aí: entender o que existe, por que existe e se ainda deveria existir.

Neste artigo, vamos analisar como estruturar esse processo de forma prática, incluindo inventário de policies, identificação de duplicidades e privilégios excessivos, revisão de acesso efetivo, automação, Policy as Code, Audit e métricas que podem ajudar a acompanhar a evolução do ambiente.

Os Limites Técnicos Importam

Governança de IAM também precisa considerar os limites técnicos da plataforma. Em ambientes pequenos eles raramente aparecem como problema. Em um tenancy com muitos compartments, equipes e aplicações, podem começar a influenciar a própria arquitetura de autorização. Na documentação atual do OCI, alguns limites relevantes são:

• 100 objetos IAM Policy por tenancy;
• 50 statements por objeto Policy;
• 500 statements ao longo de um único caminho da hierarquia de compartments, do root até um leaf compartment.

O terceiro limite merece atenção especial. Considere uma hierarquia formada por Root -> Production -> Business-Unit -> Application-A. Para esse caminho, a soma dos statements definidos nesses quatro níveis não pode ultrapassar 500. Esse é um hard limit e não pode ser aumentado.

Compartments irmãos são avaliados separadamente. Se Application-A e Application-B estiverem em ramos distintos, o cálculo considera cada caminho individualmente. Portanto, não é correto interpretar esse limite como 500 statements para todo o tenancy.

Requisito técnico: O desenho da hierarquia de compartments e o local onde as policies são associadas passam a ter impacto direto sobre o consumo desse limite.

Isso cria uma tentação perigosa: consolidar várias policies específicas em statements mais amplos apenas para reduzir quantidade.

Trocar várias autorizações restritas por algo como manage all-resources in tenancy certamente reduz o número de statements. Também pode aumentar drasticamente o alcance do impacto.

O objetivo da otimização não deveria ser simplesmente ter menos policies. Deveria ser reduzir complexidade sem ampliar privilégios desnecessariamente.

A documentação oficial sugere Tag-Based Access Control (TBAC) como uma das alternativas para reduzir repetição e evitar atingir o limite de statements por hierarquia. Como vimos no artigo anterior, essa abordagem pode funcionar muito bem em escala, mas transfere parte da complexidade para a governança das tags.

Recomendação arquitetural: acompanhe o crescimento das policies antes que os limites se tornem um problema. Quando a quantidade de statements começa a crescer rapidamente, normalmente vale revisar primeiro duplicidades, escopos, padrões repetitivos e o próprio desenho da hierarquia.

Os limites técnicos são importantes. Mas atingir o limite costuma ser apenas o sintoma. A pergunta mais interessante é por que o modelo de autorização precisou de tantos statements para representar o acesso do ambiente.

Não Resolva Limites Apenas Consolidando Permissões

Quando a quantidade de policies começa a se aproximar dos limites técnicos do OCI, a reação mais natural é procurar formas de consolidá-las. Isso faz sentido. O problema começa quando reduzir a quantidade de statements passa a ser mais importante do que preservar o modelo de autorização.

Considere um ambiente no qual uma equipe precisa administrar Compute Instances em um compartment e possui policies específicas para os recursos necessários à operação. Ao identificar que existem muitos statements, alguém pode tentar simplificar o modelo substituindo várias autorizações por uma única policy mais abrangente.

Tecnicamente, isso pode funcionar. Do ponto de vista de segurança, porém, o resultado pode ser bem diferente. Uma consolidação como esta certamente reduz a quantidade de statements:

Allow group Corporate/AppAdmins to manage all-resources in compartment Application-A

Mas também muda completamente a autorização concedida. all-resources não representa apenas os recursos que apareciam nas policies anteriores. Ele abrange todos os resource-types no escopo definido pelo statement. Da mesma forma, manage representa o nível mais amplo entre os verbos normalmente utilizados nas policies do OCI.

Ou seja, o número de statements diminuiu, mas o alcance do impacto aumentou. Esse é exatamente o tipo de otimização que recomendo evitar.

O OCI trabalha com permissões como unidades atômicas de autorização. Os verbos inspect, read, use e manage existem para agrupar conjuntos dessas permissões e facilitar a construção das policies. Portanto, utilizar um verbo ou um resource-type mais amplo não é apenas uma simplificação sintática. Pode representar uma mudança real no conjunto de operações autorizadas.

Boa prática de segurança: Antes de consolidar statements, compare o acesso efetivo antes e depois da mudança. A pergunta não deve ser apenas “quantos statements vou eliminar?”, mas principalmente “quais novas operações ou recursos passarão a ser acessíveis depois dessa consolidação?”

Existem formas melhores de reduzir repetição. Se vários statements concedem exatamente o mesmo nível de acesso a resource-types que pertencem a uma mesma família e o requisito operacional realmente exige acesso a toda essa família, utilizar um family resource-type pode ser uma simplificação coerente. O OCI permite que uma policy utilize tanto resource-types individuais quanto families, justamente para representar conjuntos de recursos normalmente utilizados em conjunto.

A parte importante está em “se o requisito realmente exige”. Substituir três resource-types por uma family sem verificar o que mais essa family inclui é apenas outra forma de ampliar privilégios silenciosamente.

O mesmo raciocínio vale para escopo. Se várias policies existem somente porque o mesmo modelo de acesso precisa ser repetido em diversos compartments classificados da mesma maneira, talvez o problema não esteja nas permissões. Pode estar na forma como o acesso está sendo representado.

Como vimos no artigo anterior, Tag-Based Access Control pode permitir que um único statement represente um padrão de autorização aplicável a vários compartments ou resources. A própria documentação do OCI recomenda considerar TBAC como uma forma de reduzir a quantidade de statements e evitar o limite de 500 statements por caminho da hierarquia.

Por exemplo, em vez de repetir a mesma policy para cada environment de produção, pode fazer sentido utilizar uma classificação controlada por tag:

Allow group Corporate/ProdOperators to manage all-resources in tenancy where target.resource.compartment.tag.Governance.Environment=’PROD’

Nesse caso, a consolidação não acontece simplesmente porque o statement ficou mais amplo. Ela acontece porque um atributo de governança passou a representar um conjunto de compartments com o mesmo requisito de autorização.

Como discutimos na Parte 3, isso também cria uma nova fronteira de confiança. Se a tag participa da decisão de autorização, controlar quem pode aplicá-la ou alterá-la passa a fazer parte do modelo de segurança. A documentação do OCI chama atenção explicitamente para esse risco.

Outra oportunidade normalmente menos arriscada é eliminar redundância real. Policies duplicadas, statements que concedem acesso já concedido por outro nível da hierarquia, regras antigas que perderam a finalidade e autorizações criadas temporariamente são candidatos melhores para revisão do que simplesmente substituir várias policies específicas por uma policy genérica.

Esse é um ponto importante para governança: redundância e granularidade não são a mesma coisa.

Uma policy granular pode existir por um bom motivo. Uma policy redundante provavelmente não. Por isso, quando o objetivo for reduzir a quantidade de statements, siga esta ordem:

1. Identificar statements duplicados ou sem finalidade conhecida;
2. Identificar autorizações que já são concedidas por outras policies aplicáveis;
3. Avaliar se resource families representam corretamente o requisito operacional;
4. Procurar padrões repetitivos que possam ser representados por conditions ou TBAC;
5. Somente depois avaliar consolidações que alterem verbos, resource-types ou escopo.

O limite técnico precisa ser tratado. Mas resolver um problema de quantidade criando um problema de privilégio excessivo não é otimização. É apenas trocar um risco visível por outro que pode ser muito mais difícil de perceber.

Discovery

Antes de revisar policies, procurar duplicidades ou calcular risco, existe uma etapa que considero obrigatória: descobrir o que realmente existe no ambiente. Parece óbvio, mas esse é um dos pontos em que a governança costuma começar errado.

Abrir algumas policies no Console e procurar statements aparentemente amplos não é discovery. Isso é uma amostragem. Em um tenancy maior, policies podem estar distribuídas por diferentes níveis da hierarquia de compartments. Grupos podem pertencer a diferentes Identity Domains. Dynamic Groups podem incluir workloads por matching rules que não são evidentes olhando apenas para a policy. Além disso, uma mesma identidade pode receber permissões por meio de vários statements diferentes.

Por isso, o primeiro objetivo deveria ser construir um inventário confiável do modelo de autorização.

No OCI, um objeto Policy pertence a um compartment específico. O comando abaixo, por exemplo, lista as policies existentes no compartment informado:

oci iam policy list –compartment-id <compartment_ocid> –all

Executar esse comando apenas para o root compartment não significa necessariamente descobrir todas as policies do tenancy. ListPolicies lista as policies existentes no compartment especificado. Portanto, para construir um inventário completo, primeiro é necessário conhecer a hierarquia de compartments e depois consultar os locais onde as policies estão armazenadas.

O OCI CLI permite obter a hierarquia de compartments a partir do root utilizando –compartment-id-in-subtree:

oci iam compartment list –compartment-id <tenancy_ocid> –compartment-id-in-subtree true –access-level ANY –include-root –all

A partir dessa estrutura, o processo de discovery pode percorrer cada compartment e coletar suas respectivas policies.

Mas encontrar os objetos Policy é apenas o começo. Para cada policy, procure registrar pelo menos:

• Nome e OCID da policy;
• Compartment onde o objeto Policy está armazenado;
• Descrição e estado da policy;
• Cada statement individualmente;
• Identity Domain, grupo, Dynamic Group ou outro principal referenciado;
• Verbo utilizado;
• Resource-type ou family;
• Escopo definido no statement;
• Conditions utilizadas;
• Referências a tags;
• Data da última alteração, quando disponível;
• Owner ou finalidade da autorização, quando essa informação existir fora do OCI.

O objetivo é transformar uma coleção de textos em dados que possam ser analisados.

Quando todos os statements seguem uma estrutura comum, torna-se possível procurar automaticamente por manage all-resources, comparar policies semelhantes, identificar subjects com muitos privilégios, localizar uso excessivo de tenancy scope, encontrar conditions repetidas e detectar padrões que dificilmente apareceriam em uma revisão manual.

Existe outro ponto que considero importante: não confundir o compartment onde a policy está armazenada com o escopo de acesso definido pelo statement.

Como vimos anteriormente na série, Policy Attachment e Policy Scope são conceitos diferentes. Durante o discovery, os dois precisam ser registrados separadamente.

Caso contrário, uma ferramenta pode concluir incorretamente que uma policy afeta apenas o compartment onde o objeto foi criado.

Também não considero suficiente inventariar apenas policies. Se o objetivo é governança de acesso, é necessário correlacionar as policies com as identidades às quais elas se referem.

Isso significa conhecer grupos, memberships, Identity Domains e Dynamic Groups. No caso dos Dynamic Groups, a matching rule é especialmente importante. Uma policy pode parecer perfeitamente restritiva, mas uma matching rule muito ampla pode fazer com que mais workloads utilizem aquelas permissões.

Essa relação entre principal, policy e recurso é o que começa a transformar discovery em algo útil. Ainda assim, existe uma distinção importante: Discovery não é Effective Access.

O discovery constrói o mapa. O effective access exige interpretar esse mapa. Uma identidade pode pertencer a vários grupos, receber autorizações por diferentes policies e ser afetada pela hierarquia de compartments e pelas conditions existentes nos statements. A própria documentação do OCI deixa claro que não existe uma operação de API que simplesmente retorne todas as policies aplicáveis a determinado grupo ou compartment. Para chegar a essa resposta, é necessário analisar os statements das policies.

Por isso separe essas duas etapas:

• Primeiro, descobrir e normalizar;
• Depois, correlacionar e analisar.

Essa separação também ajuda na automação. Um processo de discovery pode ser executado periodicamente e gerar um snapshot do IAM do tenancy. A camada de análise pode então trabalhar sobre esse snapshot para encontrar mudanças, duplicidades, aumento de privilégios ou outros indicadores de risco. E existe um benefício adicional: histórico.

Se eu sei como o IAM estava estruturado ontem e como está hoje, a pergunta deixa de ser apenas “Quais policies existem?” e passa a ser “O que mudou no nosso modelo de autorização?”

Para governança, essa segunda pergunta é muito mais interessante.

OCI CLI para Inventário

Depois de definir o que precisa ser descoberto, o próximo passo é tornar essa coleta reproduzível. Para isso, o OCI CLI é uma ferramenta bastante útil. Ele permite consultar a hierarquia de compartments, recuperar os objetos Policy e trabalhar com os resultados em JSON, o que facilita bastante a criação de scripts para inventário, comparação e análise.

O ponto importante é não começar pelas policies. Primeiro, precisamos descobrir a estrutura do tenancy.

A documentação do OCI permite listar toda a hierarquia de compartments a partir do root utilizando –compartment-id-in-subtree true. Quando combinado com –access-level ANY, o comando percorre os subcompartments da árvore. O parâmetro –include-root também permite incluir o próprio root compartment no resultado.

Um exemplo seria:

oci iam compartment list –compartment-id <tenancy_ocid> –compartment-id-in-subtree true –access-level ANY –include-root –all

Esse comando nos fornece a base para a próxima etapa. Para cada compartment encontrado, podemos consultar os objetos Policy armazenados naquele nível:

oci iam policy list –compartment-id <compartment_ocid> –all

O comando oci iam policy list retorna as policies existentes no compartment informado. A própria documentação chama atenção para outro detalhe importante: para determinar quais policies se aplicam a determinado grupo ou compartment, é necessário analisar os statements existentes. Não existe uma operação da API que retorne automaticamente essa correlação.

Isso reforça um ponto que discutimos no tópico anterior: o OCI CLI ajuda a construir o inventário. Ele não calcula effective access por nós.

Automatizando a Coleta

Em vez de executar esses comandos manualmente, podemos combinar o OCI CLI com ferramentas como “jq” para percorrer a hierarquia e consolidar as policies encontradas. Um fluxo simplificado poderia ser:

TENANCY_OCID="<tenancy_ocid>"

oci iam compartment list --compartment-id "$TENANCY_OCID" --compartment-id-in-subtree true --access-level ANY --include-root --lifecycle-state ACTIVE --all --output json > compartments.json

Depois, percorremos os compartments encontrados e coletamos as policies:

jq -r '.data[].id' compartments.json |
while read -r compartment_id
do
   oci iam policy list \
     --compartment-id "$compartment_id" \
     --all \
     --output json
done

Esse exemplo ainda não é um inventário completo. Ele apenas mostra o mecanismo de coleta. O próximo passo é estruturar o resultado.

Uma possibilidade é normalizar alguns dos principais atributos de cada objeto Policy:

jq --arg compartment_id "$compartment_id" '
   .data[] |
   {
     policy_id: .id,
     policy_name: .name,
     policy_compartment_id: ."compartment-id",
     description: .description,
     lifecycle_state: ."lifecycle-state",
     time_created: ."time-created",
     version_date: ."version-date",
     statements: .statements
   }
'

Os objetos Policy retornados pelo OCI incluem atributos como OCID, nome, descrição, compartment, lifecycle state, data de criação e os próprios statements.

Preserve o Dado Original

Aqui existe uma decisão que considero importante. Não descarte o statement original depois de fazer o parsing. Mesmo que a ferramenta consiga separar:

Allow group Corporate/ProdOperators to manage instance-family in compartment Production

em algo como:

Subject: Corporate/ProdOperators
Verb: manage
Resource-Type: instance-family
Scope: compartment Production

Conditions tornam a linguagem de policies mais complexa. Policies podem utilizar tags, variáveis, OCIDs, múltiplas condições e outras construções que dificultam uma normalização perfeita.

Se o parser interpretar algo incorretamente, o statement original continua sendo a referência.

Por isso, trabalhe com duas representações:

Raw

Allow group Corporate/ProdOperators to manage instance-family in compartment Production

Normalized

Subject: Corporate/ProdOperators
Verb: manage
Resource-Type: instance-family
Scope-Type: compartment
Scope: Production
Condition: none

A versão normalizada facilita consultas. A versão raw preserva a evidência.

JSON primeiro, CSV depois

Outro erro que se deve evitar é transformar imediatamente todo o inventário em CSV. CSV é excelente para planilhas e análises simples, mas IAM possui naturalmente estruturas de um-para-muitos. Uma policy possui vários statements. Um statement pode possuir várias conditions. Uma identidade pode pertencer a vários grupos. Um Dynamic Group pode possuir uma matching rule complexa.

Forçar tudo isso para uma única linha pode gerar perda de informação ou criar colunas difíceis de interpretar. Utilize JSON como formato primário do inventário. Depois, gere visões específicas em CSV quando necessário, por exemplo:

Policy
Compartment
Subject
Verb
Resource-Type
Scope
Condition

Essa tabela é muito útil para procurar padrões, mas não deveria substituir o inventário original.

Use o próprio OCI CLI para reduzir ruído

O OCI CLI também suporta –query, permitindo utilizar expressões JMESPath para selecionar campos antes mesmo de retornar o resultado. A documentação mostra esse recurso para selecionar atributos específicos das respostas.

Por exemplo:

oci iam policy list \
   --compartment-id <compartment_ocid> \
   --all \
   --query 'data[].{Name:name,OCID:id,Statements:statements}'

Isso pode ser útil para consultas rápidas. Para um processo formal de discovery, entretanto, prefira inicialmente coletar mais informações e filtrar depois. Existe uma razão para isso.

Discovery deveria evitar decisões prematuras sobre quais dados serão importantes no futuro.

Hoje podemos estar interessados apenas nos statements. Amanhã podemos querer comparar datas, lifecycle state, descrição, tags ou versões. Se o snapshot original preserva essas informações, novas análises podem ser feitas sem executar novamente todo o processo de coleta.

Um snapshot do IAM

Depois dessa coleta, o resultado pode ser tratado como um snapshot do modelo IAM naquele momento.

Por exemplo:

iam-inventory-2026-09-29.json

Na execução seguinte:

iam-inventory-2026-10-06.json

A partir daí podemos comparar os dois arquivos e identificar:

• Policies criadas;
• Policies removidas;
• Statements adicionados;
• Statements removidos;
• Alterações de escopo;
• Mudanças de read para use ou manage;
• Introdução de all-resources;
• Novas conditions;
• Alterações envolvendo tags.

Isso transforma o OCI CLI em algo mais interessante do que uma ferramenta de consulta. Ele passa a fazer parte de um processo de continuous IAM governance.

O ponto não é executar oci iam policy list de tempos em tempos. O objetivo é criar um processo capaz de responder: o que existe hoje, o que mudou desde a última execução e qual dessas mudanças merece ser revisada?

Essa diferença parece pequena. Na prática, é o que separa inventário de governança.

Detectando Duplicidades

Depois de construir o inventário, uma das primeiras análises que podemos fazer é procurar duplicidades. Mas duplicidade em IAM não significa apenas encontrar dois statements com o mesmo texto. Uma ferramenta de governança deveria procurar diferentes tipos de sobreposição.

Dois statements podem ser textualmente diferentes e ainda representar a mesma autorização. Por isso, antes da comparação, faz sentido normalizar elementos como subject, verbo, resource-type, escopo e conditions.

A hierarquia de compartments também precisa entrar nessa análise.

Imagine que Application-A seja um subcompartment de Production e existam estes dois statements:

Allow group Corporate/AppAdmins to manage instances in compartment Production Allow group Corporate/AppAdmins to manage instances in compartment Production:Application-A

O primeiro statement já alcança as instâncias de Application-A por herança. Considerando somente essas autorizações, o segundo pode não acrescentar novas permissões. Esse tipo de redundância não aparece em uma simples comparação de texto. A ferramenta precisa conhecer a hierarquia de compartments.

O mesmo acontece quando um grant é coberto por outro mais amplo.

Allow group Corporate/AppAdmins to read instances in compartment Production Allow group Corporate/AppAdmins to manage instances in compartment Production

Nesse caso, manage já inclui as capacidades concedidas por read para esse resource-type.

Isso não significa que o statement com read deva ser removido automaticamente. Talvez o acesso que precise ser revisto seja justamente o manage.

Resource families criam situação semelhante:

Allow group Corporate/AppAdmins to manage instances in compartment Production Allow group Corporate/AppAdmins to manage instance-family in compartment Production

O segundo grant cobre instances, mas também pode incluir outros resource-types. A ferramenta deveria identificar essa relação sem assumir que o grant mais amplo é o correto. Conditions também precisam fazer parte da comparação. Dois statements com o mesmo subject, verbo, resource-type e escopo podem produzir autorizações diferentes se um deles possuir uma condition adicional.

Por isso, não utilize apenas uma classificação Duplicate = true/false. Uma análise mais útil poderia distinguir:

• EXACT_DUPLICATE
• SEMANTIC_DUPLICATE
• INHERITED_REDUNDANCY
• COVERED_BY_HIGHER_VERB
• COVERED_BY_RESOURCE_FAMILY
• REVIEW_REQUIRED

O objetivo não é remover policies automaticamente, é identificar onde existem sobreposições e criar uma fila de revisão. Duplicidade, nesse contexto, funciona mais como um indicador de complexidade e higiene do modelo IAM do que como uma medida direta de segurança. Um tenancy pode não possuir nenhum statement duplicado e ainda assim possuir privilégios excessivos. Por isso, depois de identificar redundâncias, a próxima etapa é mais importante: determinar quais autorizações representam maior risco e deveriam ser revisadas primeiro.

Risk Scoring

Depois de identificar duplicidades e sobreposições, ainda resta um problema: por onde começar a revisão?

Em um tenancy com centenas de statements, revisar tudo com a mesma prioridade não é eficiente. É aqui que um modelo de Risk Scoring pode ajudar. O objetivo não é determinar automaticamente se uma policy está correta ou incorreta. O score serve para colocar primeiro na fila aquilo que possui maior potencial de impacto.

Recomendação técnica: O modelo abaixo é uma proposta de governança e não representa um mecanismo ou classificação oficial do OCI.

Uma abordagem simples pode considerar alguns elementos que já fazem parte da própria sintaxe das policies:

Fator	Menor Risco	Maior Risco
Verb	inspect / read	manage
Resource-Type	recurso específico	all-resources
Scope	compartment específico	tenancy
Principal	grupo restrito | grupo amplo	any-group ou any-user
Conditions	restrições adicionais	nenhuma restrição adicional

A documentação do OCI mostra que os verbos representam níveis crescentes de permissões, que all-resources abrange todos os resource-types no escopo definido e que tenancy amplia o alcance para todo o tenancy. Esses elementos podem, portanto, ser utilizados como sinais objetivos durante a classificação.

Um modelo inicial poderia atribuir pontos, por exemplo:

Verb
inspect = 0
read = 5
use = 10
manage = 20

Resource-Type
individual resource-type = 0
resource family = 10
all-resources = 20
Scope compartment específico = 0
compartment com grande hierarquia = 10
tenancy = 20

Outros fatores podem ser adicionados como modificadores, incluindo grupos com muitos membros, Dynamic Groups com matching rules muito amplas ou acesso a recursos administrativos particularmente sensíveis. Assim, um statement contendo manage all-resources in tenancy naturalmente aparece próximo do topo da fila de revisão, enquanto uma autorização read sobre um resource-type específico em um compartment restrito tende a receber prioridade menor.

Isso não significa que a primeira policy esteja necessariamente errada. Um grupo administrativo pode realmente precisar desse acesso. O Risk Scoring apenas sinaliza que, caso aquela autorização esteja incorreta ou seja comprometida, o alcance do impacto tende a ser maior.

Também evite utilizar o score isoladamente como critério para remover ou alterar uma policy. Ele deveria funcionar como uma camada de priorização sobre o inventário:

Discovery -> Normalização -> Duplicidades -> Risk Scoring -> Revisão

Com o tempo, esse score pode ser refinado utilizando informações que não existem diretamente no statement, como criticidade do environment, quantidade de identidades afetadas, exposição do workload e histórico de utilização.

O objetivo não é produzir uma nota perfeita, é responder uma pergunta muito mais prática: entre centenas de autorizações, quais eu deveria revisar primeiro?

Policy as Code

Depois de inventariar, normalizar e classificar as policies, o próximo passo natural é reduzir alterações manuais.

É aqui que Policy as Code começa a fazer sentido. A ideia é tratar as IAM Policies como código versionado: alterações passam por repositório, revisão, comparação de mudanças e um processo controlado de deployment. No OCI, isso pode ser feito com Terraform utilizando o resource oci_identity_policy, que permite declarar o compartment, o nome da policy e seus statements.

Um exemplo simples seria:

resource "oci_identity_policy" "app_admins" {
   compartment_id = var.tenancy_ocid
   name = "AppAdminsPolicy"
   description = "Acesso administrativo da equipe AppAdmins"

   statements = [
     "Allow group Corporate/AppAdmins to manage instances in compartment Production"
   ]
}

O ganho principal não está em escrever a policy em HCL. Está no processo que passa a existir ao redor dela.

Esse modelo cria algumas vantagens importantes:

• Primeiro, histórico. É possível identificar quem alterou uma policy, quando a mudança ocorreu e qual era a configuração anterior;
• Segundo, revisão antes da mudança. Um statement excessivamente amplo pode ser identificado durante o Pull Request, antes de chegar ao ambiente;
• Terceiro, automação. O pipeline pode executar validações para localizar padrões que merecem revisão, como:
  • manage all-resources;
  • acesso no nível do tenancy;
  • any-group ou any-user;
  • ausência de conditions em determinados cenários;
  • aumento do Risk Score;
  • duplicidades com policies existentes.

O OCI Resource Manager também suporta configurações Terraform e permite executar operações de Plan e Apply separadamente. Isso ajuda a incorporar revisão e aprovação ao processo de mudança.

Policy as Code não significa policy segura

Esse ponto é importante, Terraform não corrige um modelo de autorização ruim.

Podemos perfeitamente versionar esta policy:

Allow group Corporate/Developers to manage all-resources in Tenancy

O fato de ela estar em Git, passar por Terraform e possuir histórico não reduz o privilégio concedido. Policy as Code melhora controle, rastreabilidade e consistência. A segurança continua dependendo da qualidade da policy e do processo de revisão. É aqui que as etapas anteriores começam a se conectar. O Discovery fornece o inventário, a análise de duplicidades identifica sobreposições, o Risk Scoring ajuda a priorizar a revisão e Policy as Code adiciona controle ao processo de mudança.

O principal ganho é justamente esse: a governança deixa de acontecer somente depois que a policy foi criada e passa a fazer parte do processo de criação e alteração da policy.

Pipeline de Mudança

Policy as Code só entrega valor de governança quando existe um processo claro para controlar a mudança. Versionar Terraform em Git é importante, mas não é suficiente. O ponto central é criar gates antes que uma alteração de IAM chegue ao ambiente.

Estruture o pipeline em quatro etapas principais:

• Validação da mudança
• Análise de risco
• Aprovação
• Deployment e validação posterior

Validação antes do Plan

A primeira camada deveria procurar problemas que podem ser identificados sem alterar o ambiente. Isso inclui:

• Sintaxe inválida;
• Statements duplicados;
• Aumento de escopo;
• Mudança para verbos mais amplos;
• Introdução de all-resources;
• Uso de tenancy;
• Alteração de conditions;
• Aumento significativo do Risk Score.

A ideia não é bloquear automaticamente toda mudança considerada ampla, é tornar essas mudanças visíveis antes da aprovação.

Uma alteração de read instances para manage instance-family não deveria aparecer no Pull Request apenas como algumas palavras modificadas.

Do ponto de vista de segurança, ocorreu uma mudança relevante de privilégio.

O Plan precisa fazer parte da revisão

Quando Terraform é utilizado, o plan adiciona outra camada importante. No OCI Resource Manager, um Plan Job gera o execution plan com as ações que serão executadas posteriormente pelo Apply. A documentação recomenda executar um Plan antes do Apply.

Para IAM, isso permite revisar não apenas o código alterado, mas também o impacto que Terraform pretende produzir no OCI. Evite pipelines nos quais o Pull Request aprovado executa diretamente um Apply sem que o plano resultante seja revisado.

Aprovação deve considerar risco

Nem toda mudança precisa ter o mesmo processo de aprovação. Uma alteração restrita, como adicionar read para um resource-type específico em um compartment de desenvolvimento, pode seguir um fluxo mais simples.

É aqui que o Risk Scoring desenvolvido anteriormente pode ser utilizado como um dos critérios para definir o nível de aprovação necessário. O score não decide se a mudança é permitida. Ele ajuda a decidir quem precisa revisá-la antes da execução.

Apply controlado

Depois da aprovação, o Apply deve executar exatamente a mudança que foi revisada. No OCI Resource Manager, um Apply Job pode utilizar o execution plan gerado anteriormente, em vez de gerar uma execução independente. Isso reduz a diferença entre aquilo que foi revisado e aquilo que será aplicado. Esse detalhe é importante em um pipeline de segurança. Se o código muda depois do Plan, o processo deveria exigir uma nova validação.

A mudança não termina no Apply

Um pipeline de IAM não deveria considerar sucesso apenas porque Terraform terminou sem erro. Depois da mudança, inclua uma validação simples para confirmar:

• Se a policy esperada foi criada ou alterada;
• Se nenhum statement inesperado apareceu;
• Se o inventário continua consistente;
• Se o Risk Score final corresponde ao esperado.

Dependendo da maturidade do processo, um novo snapshot de IAM pode ser gerado automaticamente e comparado com o snapshot anterior. Assim, o pipeline fecha o ciclo entre mudança planejada e estado efetivamente encontrado no tenancy.

O objetivo não é tornar cada alteração burocrática, é garantir que mudanças de autorização tenham o mesmo nível de controle que esperamos para qualquer outro componente crítico da infraestrutura.

IAM também é configuração de segurança. Tratar sua alteração como código significa tratar sua mudança como um processo controlado.

Audit e Monitoração

Inventário e Policy as Code ajudam a controlar o estado desejado do IAM. Mas governança também precisa responder outra pergunta: o que realmente mudou no ambiente? É aqui que o OCI Audit entra no processo.

O serviço registra automaticamente chamadas realizadas contra endpoints públicos suportados do OCI, incluindo operações originadas pela Console, pelo OCI CLI, SDKs, APIs e outros serviços OCI. Os eventos registram informações como horário, origem da chamada, recurso afetado, operação executada e resultado.

Para governança de IAM, isso permite acompanhar eventos relacionados a mudanças como criação, alteração ou remoção de policies e outras operações administrativas executadas por meio das APIs do OCI.

O ponto importante é que Audit não substitui o inventário.

O inventário responde: Qual é a configuração atual?

O Audit responde: O que aconteceu para chegarmos a essa configuração?

As duas informações se complementam.

Procure mudanças que alterem autorização

Não tente monitorar todos os eventos com a mesma prioridade. O foco deveria estar nas operações capazes de alterar o modelo de autorização.

Alguns exemplos que merecem atenção são:

• Criação, alteração ou exclusão de IAM Policies;
• Alterações em grupos e memberships;
• Mudanças em Dynamic Groups e matching rules;
• Movimentação de resources ou compartments quando isso puder alterar as policies aplicáveis;
• Alterações em tags utilizadas em TBAC;
• Mudanças administrativas que ampliem o acesso de uma identidade.

O Risk Scoring desenvolvido anteriormente também pode ser utilizado aqui. Se uma alteração introduzir manage, all-resources, escopo em tenancy ou remover uma condition, o evento pode receber prioridade maior para revisão.

Isso muda a monitoração de uma abordagem baseada apenas em eventos para uma abordagem baseada em impacto potencial sobre a autorização.

Audit não é monitoração em tempo real

Também é importante considerar que o OCI Audit não deve ser tratado como um mecanismo de detecção instantânea. A documentação informa que novos eventos normalmente aparecem em até aproximadamente 15 minutos após a chamada de API, embora esse tempo possa variar.

Para governança isso costuma ser suficiente. Para controles que exijam resposta em tempo real, o requisito precisa ser analisado separadamente.

Os logs do OCI Audit são mantidos por 365 dias, de acordo com a documentação atual do serviço. Dependendo dos requisitos de retenção, investigação ou compliance da organização, pode fazer sentido enviar esses dados para outro destino.

Integre Audit ao processo de monitoração

O Connector Hub permite utilizar logs como origem e encaminhá-los para serviços como Object Storage, Streaming, Logging Analytics, Monitoring ou Notifications. A própria documentação apresenta cenários utilizando Audit logs como origem.

Isso permite construir controles como:

• Alertar sobre determinadas alterações de IAM;
• Arquivar eventos para retenção adicional;
• Enviar dados para uma plataforma de SIEM;
• Gerar métricas sobre mudanças;
• Correlacionar eventos de Audit com o inventário de policies.

O objetivo não é gerar uma notificação para cada alteração. Se todo evento produz um alerta, rapidamente ninguém presta atenção.

Sugiro priorizar mudanças que realmente alteram o risco do ambiente. Uma nova policy restrita pode simplesmente ser registrada para revisão posterior. Uma alteração que expanda o escopo de compartment para tenancy, por outro lado, pode justificar uma análise imediata.

Compare mudança planejada com mudança observada

Quando Policy as Code estiver sendo utilizado, Audit adiciona outra informação importante. O pipeline mostra o que deveria ter sido alterado. O Audit mostra o que foi executado no OCI.

Essa comparação ajuda a identificar alterações realizadas fora do processo esperado, por exemplo, uma policy modificada diretamente pela Console enquanto o modelo oficial está mantido em Terraform.

Esse tipo de diferença pode ser tratado como configuration drift e entrar novamente no processo de revisão. No final, a monitoração de IAM não deveria servir apenas para descobrir quem alterou uma policy.

Ela deveria ajudar a responder três perguntas:

• O que mudou?
• Quem realizou a mudança?
• Essa alteração modificou o risco ou o modelo de autorização esperado?

É essa correlação entre inventário, Audit, Risk Scoring e processo de mudança que transforma logs em governança.

Métricas

Governança precisa ser mensurável. Depois de construir o inventário, classificar riscos e monitorar mudanças, podemos transformar parte dessas informações em métricas que mostrem se o modelo de IAM está melhorando ou apenas ficando mais complexo.

Evite utilizar apenas números como quantidade de policies ou quantidade de statements. Um tenancy pode ter poucas policies e ainda conceder privilégios excessivos. As métricas precisam representar qualidade e risco, não apenas volume.

Alguns indicadores que recomendo acompanhar são:

Métrica	O que ajuda a identificar
High-Risk Statements	Quantidade ou percentual de statements com Risk Score elevado
Broad Access	Uso de manage, all-resources, tenancy, any-group ou any-user
Duplicate / Overlapping Grants	Autorizações duplicadas ou cobertas por grants mais amplos
Review Coverage	Percentual das policies revisadas dentro do período definido
IAM Change Rate	Quantidade de alterações de IAM por período
Configuration Drift	Diferenças entre a configuração esperada e o estado encontrado no OCI
Risk Score Trend	Evolução do risco agregado ao longo do tempo

O valor maior aparece quando acompanhamos a tendência, e não apenas o número absoluto.

Por exemplo, encontrar 25 statements classificados como alto risco pode não dizer muito isoladamente. Saber que esse número caiu de 60 para 25 depois de três ciclos de revisão mostra uma evolução real.

O mesmo vale para duplicidades. O objetivo não precisa ser chegar a zero, mas evitar que a quantidade cresça continuamente à medida que novas policies são adicionadas.

Métricas também podem gerar alertas

Esses indicadores não precisam existir apenas em uma planilha ou dashboard externo. O OCI Monitoring permite publicar custom metrics, consultá-las posteriormente e criar alarms sobre elas. Portanto, um processo de governança pode calcular seus próprios indicadores e publicá-los no Monitoring.

Por exemplo, um processo periódico poderia publicar métricas como:

iam.high_risk_statements = 18
iam.duplicate_statements = 7
iam.configuration_drift = 2
iam.review_coverage = 84

A partir daí, podemos criar alertas quando determinados limites forem ultrapassados ou quando houver uma mudança significativa em relação à execução anterior.

Não transforme o score em objetivo

Existe um cuidado importante: Quando uma métrica vira meta, existe sempre o risco de otimizar o número em vez do problema.

Reduzir o Risk Score consolidando várias policies específicas em manage all-resources, por exemplo, seria claramente uma distorção do objetivo. Por isso, utilize métricas como instrumentos de decisão, não como prova de que o ambiente está seguro.

No final, um conjunto pequeno de métricas bem escolhidas deveria ajudar a responder três perguntas:

• O risco está aumentando ou diminuindo?
• A complexidade do IAM está sob controle?
• Estamos revisando primeiro aquilo que possui maior alcance do impacto?

Se as métricas conseguem responder essas perguntas, já estão cumprindo seu papel na governança.

Conclusão

No artigo anterior, o foco foi IAM em escala, analisando como Compartments, Dynamic Groups, Instance Principals e Tag-Based Access Control ajudam a estruturar o modelo de autorização à medida que o tenancy cresce.

Neste quarto artigo, o foco mudou da arquitetura para a governança contínua. Uma policy pode estar correta no momento em que é criada e deixar de fazer sentido meses depois. Ambientes mudam, aplicações são desativadas, grupos recebem novas responsabilidades, exceções se acumulam e novos statements são adicionados sem que os anteriores sejam necessariamente revisados.

Por isso, governança de IAM não deveria ser tratada como uma atividade pontual.

O processo começa pelo Discovery, passa pela construção de um inventário confiável, identificação de duplicidades e sobreposições, priorização por meio de Risk Scoring e controle das mudanças com Policy as Code e pipelines de aprovação. Audit, monitoração e métricas completam esse ciclo, permitindo acompanhar não apenas o estado atual, mas também como ele está evoluindo ao longo do tempo.

O ponto principal desta etapa da série é:

Não basta escrever uma boa policy. É preciso garantir que ela continue adequada depois que o ambiente mudar.

Na prática, algumas perguntas ajudam a direcionar esse processo:

• Sabemos quais policies e statements existem hoje?
• Conseguimos identificar autorizações redundantes ou excessivamente amplas?
• Sabemos quais mudanças aumentaram o alcance do impacto?
• Alterações de IAM passam por revisão antes de chegar ao ambiente?
• Conseguimos identificar mudanças feitas fora do processo esperado?
• Temos métricas que mostram se o modelo está melhorando ou ficando mais complexo?

Governança não elimina a necessidade de revisão humana. Ela cria contexto, priorização e rastreabilidade para que essa revisão seja feita onde realmente importa.

No próximo e último artigo da série, vamos analisar um mecanismo que muda uma característica importante do modelo tradicional de autorização do OCI: Deny Policies.

Até aqui, trabalhamos principalmente com a pergunta: quem deve receber determinada permissão?

Na Parte 5, entra uma segunda pergunta: quais ações queremos impedir mesmo quando alguma Allow Policy concederia acesso? Esse será o ponto de partida para discutir guardrails, precedência entre Allow e Deny, limitações e os novos modelos de segurança que esse recurso permite construir no OCI.