As políticas de acesso do OCI IAM (Identity and Access Management) estabelecem as permissões mínimas necessárias para a nuvem, para que usuários e serviços autorizados realizem operações nos recursos. Elas seguem uma sintaxe padrão: allow <sujeito> to <ação> in <localização> where <condição>. A sintaxe assegura quem tem acesso ao quê, onde e sob quais condições.
Neste artigo nós vamos explorar alguns conceitos básicos detalhados no curso de OCI Architect Associate e futuramente, vamos detalhar condicionais, dynamic-groups, controle de acesso baseado em tags, e otimização de políticas IAM.
Princípios de Segurança no OCI
Antes de falarmos sobre como escrever policies, precisamos entender dois princípios: o princípio de privilégio mínimo e o modelo de "negação padrão, permissão explícita" (default-deny, explicit-allow).
Princípio de Privilégio Mínimo
O princípio de privilégio mínimo determina que um usuário, grupo ou serviço deve receber estritamente as permissões necessárias para desempenhar sua função de trabalho, e nada além disso.
Quando você dá poder demais a uma conta, se ela for invadida, o invasor tem ampla superfície de ataque. Além disso, o usuário com privilégio máximo é propenso a acidentes e mal uso do poder no ambiente virtual.
No OCI, isso significa isolar acessos por compartments específicos, escolher verbos menores sempre que viável (como use em vez de manage para tudo) e limitar os tipos de recursos agregados.
Default-Deny, Explicit-Allow
O princípio do OCI (Oracle Cloud Infrastructure) que nega todas as permissões, a menos que sejam explicitamente concedidas, é chamado de modelo de "negação padrão, permissão explícita" (default-deny, explicit-allow).
Por padrão, nenhum usuário ou grupo tem permissão para acessar recursos. O acesso só é liberado por meio de declarações explícitas de Allow (Permitir) nas políticas de IAM. O OCI não utiliza declarações de Deny (Negar) para estabelecer esse bloqueio inicial; a negação é o estado implícito de todas as coisas.
Sintaxe das Policies no OCI
Embora definir privilégios no OCI possa parecer difícil por não ter um botão de ligar ou desligar privilégios, lidar com policies é bem simples. A complexidade surge quando as permissões necessárias são granulares, mas a sintaxe facilita muito. Em resumo, ela dá acesso a uma ação sobre um recurso em algum lugar sob determinadas condições.
allow <Subjects> to <Actions> in <Placement> where <Conditions>
1. Subject Clause
A policy permite a um usuário, grupo ou conjunto de recursos (em outro artigo falaremos mais de Dynamic-Groups) a fazer algo.
allow user fulano...
allow group HelpDeskAdmins...
allow dynamic-group MeusRecursos...
2. Actions Clause
A ação aqui é sempre <Verbo> + <Tipo de Recurso>.
Por exemplo, quando você cria sua conta no OCI, sua conta é automaticamente tornada parte do grupo Administrators. A primeira Policy já definida no OCI assim que você cria a conta é:
Allow group Administrators to manage all-resources in tenancy
O verbo é manage e o tipo de recursos agregado é all-resources.
Enquanto manage é o verbo que lhe entrega todas as permissões do OCI sobre um determinado recurso, all-resources é auto-explicativo, ele lhe entrega todos os recursos do OCI.
Tabela de Verbos e Permissões da Actions Clause
| Verbo | Exemplo de Permissões de API | Âmbito de Permissão Geral |
|---|---|---|
inspect |
VOLUME_INSPECT |
Listar recursos |
read |
VOLUME_INSPECT |
Listar recursos + ler detalhes (metadados) |
use |
VOLUME_INSPECT, VOLUME_UPDATE, VOLUME_WRITE
|
read + atualizar e editar recursos existentes |
manage |
VOLUME_INSPECT, VOLUME_UPDATE, VOLUME_WRITE, VOLUME_CREATE, VOLUME_DELETE
|
Todas as permissões anteriores + criar e deletar recursos; permissão total |
Todas as permissões anteriores + criar e deletar recursos; permissão total
Ao invés do verbo, você pode desejar conceder controle mais granular de permissões para um usuário. Por exemplo, você quer que um usuário crie, leia e edite, mas não delete volumes: allow user fulano { VOLUME_INSPECT, VOLUME_UPDATE, VOLUME_WRITE, VOLUME_CREATE } in compartment XPTO.
Dessa forma, a operação VOLUME_DELETE fica de fora da declaração, impedindo a destruição de dados sem a necessidade de regras complexas de contorno.
Tipos de Recurso Agregado vs Tipos de Recurso Não-Agregado
Os tipos de recursos podem ser divididos em dois tipos. O tipo de recursos agregados (Aggregate Resource-Type) do OCI são projetados para reduzir a quantidade de políticas. Um tipo agregado é equivalente a escrever várias declarações Allow separadas para cada tipo de recurso individual contido nele.
| Tipo de Recurso Agregado | Tipos de Recursos Individuais Incluídos | Serviço ao qual Pertence |
|---|---|---|
virtual-network-family |
vcns, subnets, route-tables, security-lists, internet-gateways, nat-gateways, drgs… |
Rede (Networking) |
instance-family |
instances, instance-images, console-histories, instance-console-connection, volume-attachments entre outros |
Computação (Compute) |
volume-family |
volumes, volume-attachments, volume-backups, boot-volume-backups, backup-policies, etc. |
Armazenamento em Bloco (Block Volume) |
all-resources |
Todos os recursos do OCI | Todos os Recursos do OCI |
Por granularidade (fine-grain access control). você pode determinar que um usuário ou grupo tenha controle de apenas um tipo de recurso não-agregado. Por exemplo, se você quer que um usuário seja capaz de controlar sub-redes, mas não necessariamente controle toda a VCN, você pode escrever allow user fulano to manage subnets in compartment XPTO.
3. Placement Clause
É o escopo da policy. Onde ela é realizada.
Temos dois tipos de placement
in tenancy: Se aplica à tenancy toda.
in compartment: Se aplica ao compartment que você nomear.
4. Conditions Clause
Vamos falar delas com mais profundidade no próximo artigo, mas para fins de explicação, ela faz com que a policy seja aplicada sob uma condição. Por exemplo:
allow group SupportDev to manage all-resource in tenancy where all target.resource.tag.Development.Environment='Dev'
Essa policy garante que o grupo SupportDev tenha controle total de todos os recursos da tenancy desde que os recursos sejam etiquetados com a tag 'Dev'. Se a tag for outra, o grupo SupportDev não tem acesso nenhum.
Existem várias outras condições aplicáveis, como Network Sources (com blocos CIDR de IP), nome ou ocid do recurso, mas as condicionais ficam para um outro artigo onde podemos falar delas com mais profundidade.
Criando Policies
Para criar Policies, vá em Identity & Security e então Policies.
Escolha o Compartment ao qual você vai aplicar a política clique em Create Policy. Para fins de exemplo, vamos criar Policies para um grupo chamado IAMAdmins, que são responsáveis por controlar quem tem acesso a quais recursos dentro do ambiente tecnológico (nuvem, on-prem) de uma organização.
Insira nome e descrição. O Policy Builder ajuda a criar templates para casos de uso específicos, mas nós vamos fazer do jeito difícil para dominarmos a ferramenta. Clique em Show Manual Editor.
Agora um erro muito comum é simplesmente entregar os recursos de IAM nas mãos do IAMAdmin. Isso viola os Princípios de Privilégio Mínimo:
Allow group IAMAdmins to manage domains in tenancy
Allow group IAMAdmins to manage users in tenancy
Allow group IAMAdmins to manage groups in tenancy
Se você aprovar esta Policy, os IAMAdmins vão ter acesso amplo à conta Administrators (incluindo a conta que criou a Tenancy)!
Talvez, por regra de negócio, você queira isso para recuperar sua conta Administrator caso perca a senha, mas existem formas mais seguras de fazer isto.
Como seria a prática recomendada? Visualização ampla e controle operacional limitado:
Allow group IAMAdmins to inspect users in tenancy
Allow group IAMAdmins to use users in tenancy where target.group.name != 'Administrators'
Allow group IAMAdmins to inspect groups in tenancy
Allow group IAMAdmins to use groups in tenancy where target.group.name != 'Administrators'
Desta forma, o grupo Administrators é visível na listagem de usuários dos IAMAdmins sem que eles tenham acesso a dados sensíveis e também não podem adicionar ou remover Administrators à revelia.
Usar use em vez de manage segue o princípio do menor privilégio, para evitar conceder ao IAMAdmins permissões excessivas que possam comprometer a segurança.
No meu exemplo, os IAMAdmins não poderão criar contas de novos usuários (isso fica nas mãos dos Administrators da Tenancy), mas se você preferir delegar criação e remoção de usuários, utilize manage users no lugar de use users.
Mas e esse target.group.name? Fica pro próximo artigo, onde falaremos sobre condicionais com mais profundidade!
Conclusão
As políticas de acesso (policies) no Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) controlam quem pode executar operações específicas sobre recursos da nuvem. Elas garantem que usuários, grupos e instâncias tenham apenas as permissões estritamente necessárias para suas funções.
FAQ
Qual é a principal diferença entre os verbos use e manage no OCI?
O verbo use concede permissão para ler e modificar configurações de recursos já criados, sem autorizar a criação de novos itens ou a exclusão de existentes. Já o verbo manage confere ciclo de vida completo, abrangendo criação, movimentação entre compartments e destruição.
O OCI IAM aceita declarações com a palavra-chave Deny?
Não. O modelo de controle do OCI trabalha com declarações Allow de forma padrão. O bloqueio é o estado padrão da plataforma (default-deny); se uma ação não estiver explicitamente liberada por uma política, ela é negada. O Deny é um recurso opcional que pode ser habilitado por um administrador de tenancy (Administrator) acessando o OCI Console, em Policies > Actions > Policy Settings. Após ser habilitado, o recurso se torna parte permanente da estrutura da tenancy. O que muda: Quando o Deny é habilitado, ele se sobrepõe a qualquer Allow sobre o mesmo recurso, grupo e condições.
Quando devo usar permissões individuais entre chaves em vez de verbos?
O uso de permissões individuais entre chaves { PERMISSAO_A, PERMISSAO_B } é indicado quando nenhum dos verbos padrão (inspect, read, use, manage) atende com precisão ao privilégio mínimo exigido, como na necessidade de criar e editar recursos bloqueando a capacidade de excluí-los.
Políticas aplicadas na Tenancy afetam todos os compartments?
Sim. Políticas aplicadas no nível raiz (tenancy) são herdadas automaticamente por todos os compartments e subcompartments da hierarquia. Para isolar o acesso, declare a política selecionando diretamente o compartment de destino.
O que acontece quando uso um tipo de recurso agregado como all-resources?
Ao utilizar all-resources, você concede ao grupo especificado a permissão correspondente ao verbo escolhido sobre todos os serviços e recursos da nuvem contidos naquele escopo de compartment ou tenancy. A recomendação é que fique somente para o grupo de administradores da tenancy, ou adicionada de condicionais severas (como tags).
Como aplicar políticas em compartments filhos hierárquicos?
As políticas criadas em compartments pai são herdadas automaticamente por todos os seus subcompartments filhos. Caso queira que uma permissão se aplique apenas a um compartment específico sem afetar a hierarquia superior, declare a política explicitamente dentro do compartment de destino.
É possível aplicar políticas do OCI diretamente a um usuário individual?
Embora domínios modernos de identidade suportem cenários pontuais, a boa prática da Oracle recomenda associar policies sempre a grupos (group) ou a grupos dinâmicos (dynamic-group). Usuários recebem permissões ao serem adicionados a esses grupos, simplificando a governança e auditoria de acessos.
