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

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.

Neste terceiro artigo, o foco muda de uma policy individual para a arquitetura de IAM em escala. À medida que o tenancy cresce, não é suficiente apenas escrever statements mais restritivos. É preciso estruturar compartments, definir identidades para workloads e encontrar formas de evitar a multiplicação de policies difíceis de manter.

A partir daqui, vamos analisar como Compartments, Dynamic Groups, Instance Principals e Tag-Based Access Control podem ser utilizados para construir um modelo de autorização mais escalável, mantendo controle sobre privilégios e fronteiras de confiança.

IAM em escala: Compartments, Dynamic Groups, Instance Principals e Tag-Based Access Control

À medida que o ambiente cresce, o desafio de IAM muda. No início, o foco está em escrever uma boa policy. Depois, passa a ser necessário garantir que dezenas ou centenas de policies continuem coerentes, compreensíveis e fáceis de manter. É nesse ponto que arquitetura começa a pesar tanto quanto sintaxe.

Neste artigo, vamos analisar como Compartments, Dynamic Groups, Instance Principals e Tag-Based Access Control ajudam a estruturar o acesso em ambientes maiores, reduzir dependência de credenciais humanas e evitar que o modelo de autorização se transforme em uma coleção de exceções difíceis de governar.

Compartments como security boundaries

Compartments não servem apenas para organizar recursos no OCI. Eles também são parte importante do modelo de controle de acesso e delegação administrativa.

Uma policy pode conceder acesso a um grupo apenas dentro de determinado compartment:

A documentação do OCI recomenda projetar a hierarquia de compartments considerando access control boundaries e necessidades de governança, e não apenas estrutura organizacional. O Cloud Adoption Framework também recomenda separar workloads de produção e não produção e utilizar child compartments quando forem necessárias camadas adicionais de isolamento administrativo.

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

Nesse caso, o compartment ajuda a estabelecer uma fronteira clara: o grupo administra os recursos de Application-A sem precisar receber o mesmo nível de acesso sobre outras aplicações do tenancy.

Isso permite construir estruturas em que responsabilidades diferentes permanecem separadas. Por exemplo, recursos de Networking podem ser administrados por uma equipe, recursos de Security por outra e workloads por equipes específicas de aplicação. A própria OCI Core Landing Zone utiliza esse tipo de separação para suportar segregação de funções e RBAC.

Existe, porém, uma distinção importante: Compartments são boundaries de autorização e administração, não boundaries de isolamento de rede.

Colocar dois workloads em compartments diferentes não impede, por si só, que exista comunicação entre eles. A documentação do Cloud Adoption Framework faz essa ressalva explicitamente: compartments têm impacto limitado sobre a segurança do workload em si, e não devem ser confundidos com controles de Network Security.

Outro ponto importante é a herança. Um child compartment recebe as autorizações aplicáveis aos compartments acima dele na hierarquia. Portanto, criar mais níveis não significa automaticamente criar mais isolamento. Se uma policy ampla for concedida no parent compartment, ela poderá continuar alcançando os recursos existentes abaixo dele.

Recomendação arquitetural: desenhe compartments a partir das fronteiras de administração e acesso que precisam existir. Depois organize os recursos dentro dessas fronteiras.

Na prática, o compartment design deve facilitar a resposta a uma pergunta simples:

Quem deveria conseguir administrar este conjunto de recursos sem necessariamente administrar os demais?

Quando essa resposta está clara, a hierarquia de compartments tende a produzir policies mais simples e um alcance do impacto mais previsível.

Produção versus Não-Produção

Separar Produção de Não-Produção é uma das decisões mais simples para reduzir o alcance de acessos em ambientes maiores.

A documentação do OCI Cloud Adoption Framework recomenda dividir workloads de produção e não produção em compartments separados. Essa separação permite aplicar policies, quotas e responsabilidades administrativas diferentes para cada ambiente.

Por exemplo, desenvolvedores podem receber maior autonomia em Não-Produção:

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

Enquanto em Produção o mesmo grupo pode receber apenas acesso de leitura:

Allow group Corporate/Developers to read instance-family in compartment Production

O ponto não é apenas organizar recursos. O mesmo usuário pode precisar de níveis de privilégio diferentes dependendo do ambiente.

Essa separação também facilita a criação de responsabilidades distintas. Uma equipe de desenvolvimento pode administrar recursos em DEV e TEST, enquanto mudanças em Produção ficam restritas a grupos operacionais específicos ou a processos automatizados de deployment.

Do ponto de vista arquitetural, Produção e Não-Produção também podem compartilhar diferentes níveis de infraestrutura. O Cloud Adoption Framework descreve modelos que variam desde ambientes praticamente isolados até estruturas que compartilham serviços centrais como Identity, Networking e Security.

Isso significa que separar Produção e Não-Produção não exige necessariamente duplicar toda a arquitetura.

A decisão depende do nível de isolamento necessário, dos requisitos regulatórios, do modelo operacional e do custo de manter estruturas independentes.

Recomendação arquitetural: separe Produção e Não-Produção pelo menos no nível de compartments e policies. A partir daí, avalie quais serviços podem ser compartilhados sem criar dependências ou ampliar desnecessariamente o alcance das permissões.

Também é importante não interpretar essa separação como isolamento completo. Compartments controlam principalmente organização, autorização e delegação administrativa. Controles de rede, proteção de dados e outros mecanismos continuam sendo necessários para estabelecer as demais fronteiras de segurança.

A separação entre Produção e Não-Produção não resolve todos os problemas de IAM. Mas cria uma fronteira clara para responder a uma pergunta importante:

Quem pode experimentar, alterar ou administrar recursos fora de produção sem receber automaticamente os mesmos privilégios em Produção?

O impacto de mover resources e compartments

Mover um resource entre compartments pode parecer uma mudança apenas organizacional. Do ponto de vista de IAM, não é.

Quando um resource é movido para outro compartment, as policies aplicáveis ao novo compartment passam a controlar o acesso ao recurso imediatamente. Isso significa que usuários podem perder acesso, ou novos grupos podem passar a ter acesso, sem que nenhuma IAM Policy tenha sido alterada.

Considere uma instância Application-A originalmente em Production. Um grupo pode ter manage instances somente nesse compartment. Se a instância for movida para Shared-Services, o conjunto de autorizações aplicável passa a ser o daquele novo local.

O impacto é ainda maior quando o que está sendo movido é um compartment inteiro.

Ao mover um compartment para outro parent, seus subcompartments e resources acompanham a mudança. As policies herdadas do parent anterior deixam de se aplicar, enquanto as policies do novo parent passam a valer.

A própria documentação apresenta um exemplo em que um grupo perde acesso e outro passa a administrar os mesmos resources simplesmente porque o compartment foi movido para outro ramo da hierarquia.

Isso faz com que a movimentação de compartments e resources tenha impacto direto sobre o modelo de autorização e sobre a segurança do ambiente.

Boa prática de segurança: trate a movimentação de resources e compartments como uma mudança de autorização, não apenas como uma alteração organizacional.

O Cloud Adoption Framework recomenda limitar a usuários autorizados a capacidade de mover compartments entre parents e resources entre compartments.

Existe também um requisito técnico importante: para mover um compartment, o usuário precisa possuir manage all-resources no lowest shared parent compartment entre a localização atual e o destino.

Outro cuidado é que nem todas as dependências acompanham automaticamente um resource. Em Compute, mover uma instância para outro compartment não move seus boot volumes e VNICs associados. O comportamento depende do serviço e deve ser validado antes da mudança.

Além das permissões herdadas, revise statements que referenciam diretamente o compartment movido. Conforme o local de attachment, o OCI pode atualizar automaticamente o caminho nesses statements, preservando o acesso.

Na prática, antes de mover um resource ou compartment, três perguntas ajudam a evitar surpresas:

• Quem perderá acesso?
• Quem passará a ter acesso?
• Quais policies serão herdadas no novo local?

Mover um resource pode ser simples. O que muda ao redor dele é que precisa ser entendido.

Workloads não deveriam utilizar credenciais humanas

Uma aplicação rodando em uma Compute Instance pode acessar outros serviços OCI utilizando credenciais de um usuário IAM.

Tecnicamente funciona. O problema é o modelo de segurança criado.

Esse padrão introduz algumas perguntas importantes: quem é o proprietário da credencial? Quem faz a rotação? O que acontece quando esse usuário muda de função ou deixa a organização? Quantas cópias da chave existem?

Além disso, o workload passa a executar operações utilizando a identidade de uma pessoa, quando na prática quem precisa do acesso é a própria aplicação.

A documentação de boas práticas do OCI recomenda não armazenar credenciais de usuários em Compute Instances. Para workloads executados em Compute, uma alternativa é utilizar Instance Principals, permitindo que a própria instância possua uma identidade para acessar outros serviços OCI.

Com Instance Principals, os certificados utilizados para autenticação são criados, associados à instância e rotacionados automaticamente. Isso elimina a necessidade de distribuir e rotacionar manualmente uma API key de usuário no workload.

A autorização continua sendo controlada por IAM Policies. A diferença é quem representa o workload: em vez de um usuário humano, a própria instância passa a atuar como principal.

Isso não elimina a necessidade de least privilege. Pelo contrário. Quem obtém acesso ao sistema operacional da instância pode potencialmente utilizar os privilégios concedidos ao Instance Principal. A documentação do OCI chama atenção explicitamente para esse risco.

Boa prática de segurança: quando o OCI oferece uma identidade própria para o workload, prefira esse modelo a armazenar credenciais persistentes de usuários dentro da aplicação ou da infraestrutura.

O objetivo não é apenas eliminar arquivos de chave. É separar identidade humana de identidade de workload.

Nos próximos tópicos, veremos como Dynamic Groups e Instance Principals trabalham juntos para implementar esse modelo no OCI.

Dynamic Groups

Um Dynamic Group permite agrupar Compute Instances e outros resources OCI como principals, de forma semelhante ao que um grupo faz com usuários. A diferença é que seus membros não são adicionados manualmente: eles são determinados por matching rules.

Por exemplo, uma regra pode incluir todas as instâncias existentes em determinado compartment:

instance.compartment.id = ‘<compartment_ocid>’

Qualquer instância que corresponda à regra passa a fazer parte do Dynamic Group. Novas instâncias criadas nesse mesmo compartment também serão incluídas automaticamente.

Depois, uma IAM Policy pode conceder acesso ao grupo:

Allow dynamic-group AppProdInstances to read object-family in compartment AppData

As matching rules também podem utilizar outros atributos, como:

• OCID da instância ou resource;
• Tipo do resource;
• Compartment;
• Defined tags e seus valores.

Também é possível combinar critérios utilizando ALL e ANY.

Essa flexibilidade exige cuidado. Uma regra baseada apenas em compartment, por exemplo, pode incluir automaticamente qualquer nova instância criada naquele local.

Isso pode ser exatamente o comportamento desejado quando o compartment representa workloads com a mesma função e nível de confiança. Mas pode ampliar o acesso de forma inesperada quando workloads diferentes compartilham o mesmo compartment.

Boa prática de segurança: trate a matching rule como parte da definição de privilégio. Quanto mais ampla a regra, maior o conjunto de workloads que poderá utilizar as permissions concedidas ao Dynamic Group.

Outro ponto operacional importante é que alterações nas matching rules não são necessariamente instantâneas. A documentação atual informa que mudanças podem levar aproximadamente uma hora para produzir efeito, inclusive quando tags são utilizadas para incluir ou remover resources do grupo.

O próximo passo é entender como essa identidade é utilizada pela própria Compute Instance. É aí que entram os Instance Principals.

Instance Principals

Se o Dynamic Group define quais instâncias podem assumir determinada identidade, o Instance Principal é o mecanismo que permite que a própria Compute Instance utilize essa identidade para acessar serviços OCI.

Cada Compute Instance possui sua própria identidade. A autenticação é feita por certificados criados, associados à instância e rotacionados automaticamente pelo OCI, eliminando a necessidade de distribuir API keys de usuários ou arquivos de configuração para o workload.

O fluxo básico é:

1. A instância corresponde à matching rule de um Dynamic Group;
2. Uma IAM Policy concede permissões a esse Dynamic Group;
3. A aplicação utiliza Instance Principal para autenticar;
4. O acesso é permitido de acordo com as policies aplicáveis.

Uma aplicação executada na instância pode, portanto, acessar Object Storage ou outros serviços OCI sem utilizar ~/.oci/config, fingerprint ou uma private key de usuário.

No OCI CLI, por exemplo:

oci os ns get –auth instance_principal

Também é possível definir o método de autenticação para toda a sessão:

export OCI_CLI_AUTH=instance_principal

Para Terraform executado dentro da Compute Instance, o provider pode utilizar:

provider “oci” {   auth   = “InstancePrincipal”   region = var.region }

Nesse modelo, não é necessário informar tenancy_ocid, user_ocid, fingerprint ou private_key_path no provider.

O ganho não está apenas em remover uma chave do filesystem. O lifecycle da identidade deixa de depender de uma pessoa e passa a acompanhar o próprio workload.

Existe um ponto de segurança importante: quem consegue acessar o sistema operacional da instância pode potencialmente utilizar os privilégios concedidos ao Instance Principal. A documentação do OCI alerta explicitamente para esse comportamento.

Isso muda a análise de risco. Uma conta com acesso SSH à instância pode também ganhar, indiretamente, acesso aos serviços OCI permitidos para aquela identidade.

Boa prática de segurança: aplique least privilege também às policies dos Dynamic Groups e controle cuidadosamente quem pode acessar o sistema operacional das instâncias que utilizam Instance Principals.

Outro detalhe documentado é que todos os Compute Instance Principals recebem a permissão compartment_inspect, que não pode ser revogada. Ela permite listar algumas informações sobre compartments no tenancy.

Instance Principals resolvem um problema importante: a aplicação deixa de precisar da identidade de uma pessoa para acessar a cloud.

O Dynamic Group define quais recursos pertencem ao grupo por meio de matching rules. As IAM Policies concedem permissões aos membros desse grupo. Cada Compute Instance autentica utilizando sua própria identidade por meio de Instance Principals

O risco escondido do Instance Principal

Instance Principals eliminam a necessidade de armazenar credenciais humanas no workload, mas isso não elimina o risco de comprometimento da identidade.

O que muda é onde está a confiança.

A documentação do OCI é explícita: um usuário que possui acesso à Compute Instance, por exemplo via SSH, também pode utilizar os privilégios concedidos ao Instance Principal daquela instância.

Considere uma instância pertencente ao Dynamic Group AppProdInstances, com esta policy:

Allow dynamic-group AppProdInstances to manage object-family in compartment AppData

Se alguém obtiver acesso à instância, poderá potencialmente executar operações em Object Storage utilizando a identidade dela. Não é necessário conhecer uma API key de usuário ou obter um private_key.pem.

Esse ponto é importante porque o Instance Principal representa a instância, não uma aplicação específica executada dentro dela. Processos e usuários com capacidade de utilizar o mecanismo de autenticação da instância podem potencialmente acessar os mesmos serviços autorizados para essa identidade.

Uma policy excessivamente ampla pode aumentar bastante o alcance do impacto caso a instância seja comprometida. Considere este exemplo:

Allow dynamic-group AppProdInstances to manage all-resources in tenancy

Nesse cenário, o problema não está apenas na aplicação que motivou a criação da policy. Se alguém obtiver controle da instância, poderá potencialmente utilizar o Instance Principal para acessar qualquer recurso permitido por esse statement.

Quanto maior o privilégio concedido ao Dynamic Group, maior pode ser o impacto de um comprometimento do workload.

A documentação de segurança do Compute recomenda, além da criação de policies adequadas, restringir o acesso às próprias instâncias.

Boa prática de segurança: trate o privilégio do Instance Principal como parte do impacto potencial de comprometimento da instância. Quanto maior a permissão concedida ao Dynamic Group, maior pode ser o alcance do impacto.

Na prática, isso conecta três controles que não deveriam ser analisados separadamente:

• Quem pode acessar o sistema operacional;
• Quais instâncias entram no Dynamic Group;
• Quais permissões a IAM Policy concede a esse grupo.

Instance Principal reduz o risco associado ao armazenamento e à rotação de credenciais persistentes. Mas não transforma uma instância comprometida em uma identidade segura.

Ele troca gestão de credenciais por gestão de confiança no workload.

Tag-Based Access Control

À medida que o número de compartments, grupos e workloads cresce, repetir policies para cada combinação pode tornar o modelo difícil de manter.

O Tag-Based Access Control (TBAC) permite utilizar tags como parte da decisão de autorização. Com isso, uma policy pode conceder acesso com base em atributos aplicados ao recurso, ao compartment ou até ao principal que realiza a requisição.

Considere compartments de produção distribuídos em diferentes áreas do tenancy, todos identificados com a defined tag:

Governance.Environment = ‘PROD’

Uma policy pode utilizar essa classificação para controlar o acesso:

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

Nesse cenário, a autorização não depende do nome ou do OCID de cada compartment. O grupo pode administrar os recursos localizados em compartments classificados com a tag definida pela policy. A documentação do OCI confirma que target.resource.compartment.tag é suportada por todos os serviços OCI.

Essa autorização também alcança os recursos nos compartments descendentes. Portanto, aplicar a tag a um compartment de nível superior pode ampliar o escopo do acesso para toda a subárvore, mesmo que os descendentes não tenham recebido diretamente essa tag.

Essa abordagem pode reduzir bastante a repetição de statements em ambientes grandes. Também permite que novos compartments entrem no modelo de autorização sem que seja necessário alterar a policy, desde que recebam a classificação adequada.

Mas isso muda a fronteira de confiança. Quando uma tag participa da autorização, alterar essa tag também pode alterar o acesso.

A documentação do OCI alerta explicitamente que aplicar tags a grupos, usuários ou resources pode conferir acesso quando existem policies baseadas nessas tags. Por isso, é necessário controlar cuidadosamente quem pode aplicar ou modificar tags utilizadas por IAM.

Recomendação arquitetural: tags utilizadas para autorização devem ser tratadas como controles de segurança. Quem pode alterá-las pode, dependendo da policy, influenciar diretamente quem terá acesso aos recursos.

Nesse cenário, faz sentido separar responsabilidades entre quem administra os resources, quem administra as tags utilizadas para autorização e quem controla as IAM Policies.

Também existem limitações importantes. Policies baseadas em target.resource.tag não conseguem, por si só, conceder permissões de criação, porque o recurso ainda não existe e ainda não possui uma tag no momento da autorização. Permissões necessárias para listar recursos também podem exigir statements adicionais.

Além disso, nem todos os serviços suportam target.resource.tag, embora target.resource.compartment.tag tenha suporte mais amplo. Alguns serviços possuem ainda limitações específicas sobre determinadas operações e resource-types.

Por isso, TBAC não deve ser visto apenas como uma forma de reduzir o número de policies. Ele troca parte da complexidade de IAM por governança de tags.

Quando essa governança existe, TBAC pode ajudar bastante a escalar o modelo de autorização. Quando não existe, uma simples alteração de tag pode produzir um efeito de segurança muito maior do que aparenta.

O novo security boundary: quem controla a tag?

Quando uma tag é usada apenas para organização ou cost tracking, alterar seu valor normalmente tem impacto administrativo.

Com TBAC, isso muda. Se uma IAM Policy utiliza uma tag para decidir quem pode acessar determinado recurso, alterar essa tag pode alterar o resultado da autorização sem modificar a policy.

A documentação do OCI chama atenção explicitamente para esse risco: quando tags são utilizadas para controlar acesso, é necessário governar cuidadosamente quem pode aplicá-las. Aplicar ou remover uma tag de um grupo, usuário ou resource pode conceder ou remover acesso.

Considere novamente uma policy baseada na classificação do compartment:

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

Nesse modelo, adicionar Governance.Environment=PROD a um compartment pode fazer com que seus resources passem a fazer parte do escopo dessa autorização.

A mudança parece ser apenas de metadata. Do ponto de vista de IAM, não é.

Isso cria uma nova fronteira de confiança. Quem possui permissão para aplicar ou modificar tags utilizadas em TBAC pode, dependendo da policy, influenciar diretamente o acesso aos resources.

Por isso, em ambientes onde tags participam da autorização, faz sentido separar responsabilidades:

• Quem administra os resources;
• Quem controla as tags utilizadas para segurança;
• Quem administra IAM Policies.

Essa separação nem sempre precisa envolver equipes diferentes, mas as permissões devem refletir o risco envolvido.

Também é importante diferenciar free-form tags de defined tags. Para aplicar uma defined tag, o principal precisa ter permissão para utilizar o respectivo tag namespace. Isso oferece um ponto adicional de controle sobre quem pode aplicar classificações utilizadas em policies.

O Cloud Adoption Framework também sugere considerar valores predefinidos para defined tags utilizadas em TBAC. Isso ajuda a reduzir variações de valores e torna o modelo mais previsível.

Recomendação arquitetural: se uma tag influencia autorização, trate a capacidade de alterar essa tag como uma permissão de segurança, e não apenas como administração de metadata.

TBAC pode reduzir bastante a quantidade de policies necessárias em ambientes grandes. Mas a complexidade não desaparece.

Parte dela muda de IAM Policy para tag governance.

O problema das operações List

TBAC introduz uma particularidade importante quando a condição depende de uma tag aplicada diretamente ao resource.

Considere uma policy que permita administrar apenas resources classificados como PROD:

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

Essa policy pode permitir operações sobre resources que possuam a tag esperada. Porém, ela não concede as permissões necessárias para listar esses resources. Durante uma operação List, o OCI não está avaliando um resource individual que permita testar target.resource.tag. A documentação descreve essa limitação explicitamente.

Na prática, o usuário pode ter autorização para administrar determinado resource e, ainda assim, não conseguir encontrá-lo pela Console. Para acessar o resource pela CLI ou SDK, seria necessário conhecer previamente seu OCID.

Uma forma documentada de resolver esse problema é conceder separadamente a capacidade de listar os resources:

Allow group Corporate/ProdOperators to inspect all-resources in compartment Operations

O primeiro statement continua controlando quais resources podem ser administrados pela tag. O segundo permite que o usuário visualize os resources existentes no compartment, sem conceder automaticamente capacidade para modificá-los.

Existe um trade-off importante: ao adicionar inspect, o usuário passa a visualizar metadata de resources que podem não possuir a tag autorizada. A flexibilidade do TBAC, nesse caso, exige aceitar uma expansão limitada da visibilidade para tornar a operação prática.

Outra alternativa é aplicar a tag ao compartment e utilizar target.resource.compartment.tag. Como a autorização passa a depender da classificação do compartment, essa abordagem evita algumas das limitações existentes quando a condição depende diretamente da tag do resource.

Boa prática de segurança: ao desenhar policies baseadas em tags, teste separadamente operações de List, leitura e alteração. Uma policy pode autorizar a ação desejada e, ainda assim, produzir uma experiência incompleta na Console.

Esse é um bom exemplo de um princípio recorrente em IAM: uma policy tecnicamente válida não significa necessariamente uma experiência operacional completa.

Conclusão

No artigo anterior, o foco foi aplicar least privilege de forma prática, reduzindo escopo, resource-types, verbos e permissões para limitar o alcance do impacto.

Neste terceiro artigo, a discussão avançou para a arquitetura necessária para sustentar esse modelo em escala.

Compartments ajudam a criar fronteiras administrativas claras. Dynamic Groups e Instance Principals permitem que workloads tenham identidade própria, sem depender de credenciais humanas persistentes. TBAC adiciona flexibilidade ao modelo, mas também transforma tag governance em parte da segurança.

Esse é o ponto principal desta etapa da série: quanto maior o ambiente, menos IAM pode depender apenas de statements individuais. A estrutura passa a determinar boa parte da segurança.

Na prática, algumas perguntas passam a ser tão importantes quanto a própria policy:

• O compartment está refletindo uma fronteira real de administração?
• O workload precisa de uma identidade própria?
• A matching rule do Dynamic Group está ampla demais?
• Quem consegue utilizar o Instance Principal?
• Quem pode alterar uma tag usada na autorização?

No próximo artigo, o foco muda novamente. Vamos sair da arquitetura de acesso e entrar em governança de IAM, analisando como revisar, otimizar e automatizar policies em ambientes corporativos, incluindo inventário, duplicidades, risk scoring, Policy as Code, Audit e métricas.

A arquitetura define a base. A governança é o que mantém essa base funcionando ao longo do tempo.