Conceitos Básicos de Políticas
Em primeiro lugar, decida se e como começar a usar políticas e se familiarizar com perguntas comuns sobre políticas.
Se você não tiver experiência em políticas do serviço IAM, este tópico fornecerá orientação sobre como proceder.
Se Estiver Realizando uma Prova de Conceito
Crie um projeto de prova de conceito com recursos de infraestrutura.
Se você estiver experimentando o Oracle Cloud Infrastructure ou realizando um projeto de prova de conceito com recursos de infraestrutura, talvez precise de apenas alguns administradores com acesso total a tudo. Nesse caso, você pode simplesmente criar novos usuários necessários e adicioná-los ao grupo Administradores. Os usuários poderão fazer qualquer coisa com qualquer tipo de recurso. E você pode criar todos os seus recursos diretamente na tenancy (o compartimento raiz). Você não precisa criar compartimentos ainda, ou qualquer outra política além da Política de Administração de Tenants, que vem automaticamente com sua tenancy e não pode ser alterada.
Não se esqueça de adicionar seus novos usuários ao grupo Administradores; é fácil esquecer isso após criá-los.
Se Você já Tiver Passado da Fase da Prova de Conceito
Restringindo o acesso aos recursos após a fase de prova de conceito.
Se já tiver realizado a fase de prova de conceito e quiser restringir o acesso aos seus recursos, primeiro:
- Certifique-se de estar familiarizado com os componentes básicos do serviço IAM e leia o cenário de exemplo: Cenário de Exemplo
- Pense em como organizar seus recursos em compartimentos: Conheça as Melhores Práticas para Configurar a Sua Tenancy
- Saiba mais sobre os conceitos básicos sobre como as políticas funcionam: Como as Políticas Funcionam
- Veja algumas políticas típicas: Políticas Comuns
- Leia a seção a seguir para obter mais informações
Mais Informações sobre Políticas
Mais informações sobre políticas.
Todos eles, incluindo o próprio serviço IAM. Você pode encontrar detalhes específicos para gravar políticas para cada serviço na Referência de Política.
Sim. Todos os usuários podem fazer essas coisas automaticamente sem uma política explícita:
- Alterar ou redefinir sua própria senha da Console.
- Gerencie suas próprias chaves de assinatura de API e outras credenciais.
Você pode colocar todos os seus recursos em um compartimento único e usar políticas para controlar o acesso, mas perderia os benefícios de medir o uso e faturamento por compartimento, da administração de política simples no nível do compartimento e da clara separação de recursos entre projetos ou unidades de negócios.
Sim. No entanto, algumas coisas a saber primeiro:
- As empresas normalmente têm vários usuários que precisam de permissões semelhantes; dessa forma, as políticas devem fornecer acesso a grupos de usuários, e não a usuários individuais. Um usuário recebe acesso estando presente no grupo.
- As políticas devem permitir acesso e não há "negação" explícita ao gravar uma política.
Se você precisar conceder acesso a um usuário específico, poderá adicionar uma condição à política que especifica o OCID do usuário em uma variável. Esta construção restringe o acesso concedido na política apenas ao usuário especificado na condição. Por exemplo:
allow any-group to read object-family in compartment ObjectStorage where request.user.id ='ocid1.user.oc1..<user_OCID>'Para obter informações sobre o uso de condições e variáveis em políticas, consulte Condições.
Se precisar restringir o acesso de um usuário específico, você poderá:
- Remover o usuário do grupo de interesse específico
- Excluir o usuário inteiramente do serviço IAM (você deve remover o usuário de todos os grupos primeiro)
Verifique primeiro se o usuário não está em algum grupo. Só então você poderá excluir o usuário.
Você precisa examinar as instruções individuais em todas as suas políticas para ver quais instruções se aplicam a qual grupo. No momento, não há uma maneira fácil de obter essas informações.
Você precisa examinar as instruções individuais em todas as políticas na tenancy para ver se alguma se aplica ao compartimento em particular. Você também precisa verificar qualquer política no próprio compartimento. As políticas em qualquer um dos compartimentos irmãos não podem se referir ao compartimento de interesse, portanto você não precisa verificar essas políticas.
Noções Básicas de Políticas
O serviço IAM usa políticas para restringir o acesso aos recursos.
Por padrão, existem políticas no nível da tenancy e podem ser aplicadas a domínios de identidade. Você também pode criar políticas com um escopo menor, por exemplo, limitando o acesso a um recurso específico. Consulte Como as Políticas Funcionam.
Exemplo de Cenário
Exemplos que mostram como diferentes componentes do IAM funcionam juntos.
A meta deste cenário é mostrar como os componentes específicos do serviço IAM trabalham juntos e recursos básicos de políticas.
Neste cenário, a Acme Company tem duas equipes que utilizarão os recursos do Oracle Cloud Infrastructure para a infraestrutura: Projeto A e Projeto B. Na realidade, sua empresa pode ter muito mais.
A Acme Company planeja usar uma rede virtual na nuvem (VCN) para ambas as equipes e deseja que um administrador de rede gerencie a VCN.
A Acme Company também deseja que a equipe do Projeto A e a equipe do Projeto B tenham cada uma seu próprio conjunto de instâncias e volumes de armazenamento em blocos. A equipe do Projeto A e as equipes do Projeto B não devem poder usar as instâncias uma da outra. Essas duas equipes também não devem ter permissão para alterar nada sobre a configuração da VCN feita pelo administrador da rede. A Acme Company deseja que cada equipe tenha administradores para os recursos da equipe. Os administradores da equipe do Projeto A podem decidir quem pode usar os recursos da nuvem do Projeto A e como. Idem para a equipe do Projeto B.
A Acme Company começa a utilizar o Oracle Cloud Infrastructure
A Acme Company se registra para usar o Oracle Cloud Infrastructure e informa à Oracle que uma funcionária chamada Wenpei será a administradora padrão. Em resposta, a Oracle:
- Cria uma tenancy para a Acme Company (veja o diagrama a seguir).
- Cria uma conta de usuário do serviço IAM para a Wenpei na tenancy.
- Cria o grupo Administradores na tenancy e coloca a Wenpei nesse grupo.
- Cria uma política na tenancy da Acme Company que dá ao grupo Administradores acesso para gerenciar todos os recursos na tenancy. Aqui está a política:
Allow group Administrators to manage all-resources in tenancy
O Administrador Padrão Cria Alguns Grupos e Outro Administrador
Em seguida, Wenpei cria vários grupos e usuários (consulte o diagrama a seguir). Ela:
- Cria grupos chamados NetworkAdmins, A-Admins e B-Admins (esses dois últimos são para o Projeto A e o Projeto B dentro da empresa)
- Cria um usuário chamado Alex e o coloca no grupo Administradores.
- Deixa os novos grupos vazios.
Para saber como criar grupos, consulte Gerenciando Grupos. Para saber como criar usuários e colocá-los em grupos, consulte Gerenciando Usuários.
O Administrador Padrão Cria Alguns Compartimentos e Políticas
Em seguida, Wenpei cria os compartimentos para agrupar recursos (consulte o diagrama a seguir). Ela:
- Cria um compartimento chamado Redes para controlar o acesso à VCN, às sub-redes, à VPN Site a Site VPN e a outros componentes da Acme Company no serviço Networking.
- Cria um compartimento chamado Projeto-A para organizar recursos de nuvem da equipe do Projeto A e controlar o acesso a eles.
- Cria um compartimento chamado Projeto-B para organizar recursos da nuvem da equipe do Projeto B e controlar o acesso a eles.
Para saber como gerenciar compartimentos, consulte Gerenciando Compartimentos.
Em seguida, Wenpei cria uma política para fornecer aos administradores de cada compartimento seu nível de acesso necessário. Ela acrescenta a política à tenancy, o que significa que somente usuários com acesso para gerenciar políticas na tenancy poderão atualizar ou excluir a política posteriormente. Neste cenário, é somente o grupo Administradores. A política inclui várias instruções que:
- Dão ao grupo NetworkAdmins acesso para gerenciar redes e instâncias (para que possam testar a rede facilmente) no compartimento Redes
- Dão aos grupos A-Admins e B-Admins acesso para usar as redes do compartimento Redes (para que possam criar instâncias na rede).
- Dão ao grupo A-Admins acesso para gerenciar todos os recursos no compartimento Projeto-A.
- Dão ao grupo Administradores-B acesso para gerenciar todos os recursos no compartimento Projeto-B.
Veja como é a política (observe que ela tem várias instruções):
Allow group NetworkAdmins to manage virtual-network-family in compartment Networks
Allow group NetworkAdmins to manage instance-family in compartment Networks
Allow group A-Admins,B-Admins to use virtual-network-family in compartment Networks
Allow group A-Admins to manage all-resources in compartment Project-A
Allow group B-Admins to manage all-resources in compartment Project-B
Observe a diferença nos verbos (manage, use), bem como nos recursos (virtual-network-family, instance-family, all-resources). Para obter mais informações sobre eles, consulte Verbs e Resource-Types. Para saber como criar políticas, consulte Criando uma Política.
Os A-Admins e B-Admins podem usar a família de redes virtuais (virtual-network-family) no compartimento Redes. Porém, eles não podem criar instâncias nesse compartimento. Eles só podem criar instâncias no compartimento Projeto-A ou Projeto-B. Lembre-se de que um compartimento é um agrupamento lógico, e não físico, para que os recursos que compõem ou residem na mesma VCN possam pertencer a outros compartimentos.
A Acme Company deseja permitir que os administradores dos compartimentos Projeto-A e Projeto-B decidam quais usuários podem usar os recursos nesses compartimentos. Dessa forma, Wenpei cria mais dois grupos: Usuários-A e Usuários-B. Em seguida, ela adiciona mais seis instruções que concedem aos administradores de compartimentos o acesso necessário para adicionar e remover usuários desses grupos:
Allow group A-Admins to use users in tenancy where target.group.name='A-Users'
Allow group A-Admins to use groups in tenancy where target.group.name='A-Users'
Allow group B-Admins to use users in tenancy where target.group.name='B-Users'
Allow group B-Admins to use groups in tenancy where target.group.name='B-Users'
Allow group A-Admins,B-Admins to inspect users in tenancy
Allow group A-Admins,B-Admins to inspect groups in tenancyObserve que essa política não permite que os administradores do projeto criem novos usuários ou gerenciem credenciais para os usuários. Ela permite decidir quais usuários existentes podem estar nos grupos Usuários-A e Usuários-B. As duas últimas instruções são necessárias para que A-Admins e B-Admins listem todos os usuários e grupos e confirmem quais usuários estão em quais grupos.
| Item | Descrição |
|---|---|
 |
Políticas anexadas à tenancy:
|
Um Administrador Cria Novos Usuários
Nesse ponto, Alex está no grupo Administradores e agora tem acesso para criar novos usuários. Portanto, ele provisiona os usuários chamados Leslie, Jorge e Cheri e os coloca nos grupos NetworkAdmins, A-Admins e B-Admins, respectivamente. Alex também cria outros usuários que serão por fim colocados nos grupos Usuários-A e Usuários-B pelos administradores do Projeto A e do Projeto B.
| Item | Descrição |
|---|---|
|
Políticas anexadas à tenancy:
|
O Administrador da Rede Configura a Rede
Leslie (no grupo NetworkAdmins) tem acesso para gerenciar virtual-network-family e instance-family no compartimento Redes. Ela cria uma VCN (rede virtual na nuvem) com uma única sub-rede nesse compartimento. Ela também configura um gateway de Internet para a VCN e atualiza a tabela de roteamento da VCN para permitir o tráfego por meio desse gateway. Para testar a conectividade da VCN com a rede local, ela inicia uma instância na sub-rede na VCN. Como parte da solicitação de ativação, ela deve especificar em qual compartimento a instância deve residir. Ela especifica o compartimento Redes, que é o único a que ela tem acesso. Em seguida, confirma a conectividade da rede local com a VCN fazendo login na instância por meio do SSH na rede local.
Leslie encerra sua instância de teste e avisa Jorge e Cheri que a VCN está ativa e em execução e pronta para ser testada. Ela avisa a eles que seus compartimentos são nomeados como Projeto-A e Projeto-B, respectivamente. Para obter mais informações sobre a configuração de uma rede na nuvem, consulte Networking. Para obter informações sobre como iniciar instâncias na rede, consulte Compute.
Os Administradores de Compartimento configuram seus Compartimentos
Jorge e Cheri agora precisam configurar seus respectivos compartimentos. Cada administrador precisa fazer o seguinte:
- Iniciar instâncias em seu próprio compartimento
- Colocar usuários no seu grupo de "usuários" (por exemplo, Usuários-A)
- Decidir o tipo de acesso para dar a esses usuários e anexar adequadamente uma política ao compartimento deles
Jorge e Cheri iniciam instâncias na sub-rede na VCN, nos compartimentos de suas respectivas equipes. Eles criam e anexam volumes em blocos às instâncias. Somente os administradores do compartimento podem iniciar/encerrar instâncias ou anexar/desanexar volumes em blocos nos compartimentos de suas respectivas equipes.
Topologia de Rede e Acesso ao Compartimento São Conceitos Distintos
É importante entender a diferença entre a topologia de rede da VCN e o controle de acesso que os compartimentos fornecem. A instância que Jorge iniciou reside na VCN do ponto de vista da topologia de rede. Porém, do ponto de vista de acesso, ela está no compartimento Projeto-A, não no compartimento Redes onde a VCN está. Leslie (a administradora de Redes) não pode encerrar ou reinicializar as instâncias de Jorge nem iniciar novas no compartimento Projeto-A. Mas Leslie controla a rede das instâncias, portanto ela controla qual tráfego será roteado para elas. Se Jorge tivesse especificado o compartimento Redes em vez do compartimento Projeto-A ao iniciar suas instâncias, sua solicitação teria sido negada. A história é semelhante para Cheri e o compartimento Projeto-B.
Mas também é importante observar que Wenpei e Alex no grupo Administradores têm acesso aos recursos nos compartimentos, porque eles têm acesso para gerenciar todos os tipos de recursos na tenancy. Os compartimentos herdam todas as políticas anexadas ao compartimento pai (a tenancy), de modo que o acesso de Administradores também se aplica a todos os compartimentos na tenancy.
Em seguida, o Jorge coloca vários usuários criados por Alex no grupo Usuários-A. Cheri faz o mesmo para o grupo Usuários-B.
Em seguida, Jorge grava uma política que dá aos usuários o nível de acesso necessário no compartimento do Projeto-A.
Allow group A-Users to use instance-family in compartment Project-A
Allow group A-Users to use volume-family in compartment Project-A
Allow group A-Users to inspect virtual-network-family in compartment Networks
Isso permite que eles usem instâncias existentes (com volumes em blocos anexados) que os administradores de compartimentos já iniciaram no compartimento e interrompam/iniciem/reinicializem essas instâncias. Não permite que os Usuários-A criem/excluam ou anexem/desanexem qualquer volume. Para permitir essa capacidade, a política precisaria incluir manage volume-family.
Jorge anexa essa política ao compartimento do Projeto-A. Qualquer pessoa com a capacidade de gerenciar políticas no compartimento agora pode modificar ou excluir esta política. No momento, isto é apenas o grupo A-Admins (e o grupo Administradores, que pode fazer qualquer coisa em toda a tenancy).
Cheri cria e anexa sua própria política ao compartimento do Projeto-B, semelhante à política do Jorge:
Allow group B-Users to use instance-family in compartment Project-B
Allow group B-Users to use volume-family in compartment Project-B
Allow group B-Users to inspect virtual-network-family in compartment Networks
Agora os Usuários-A e Usuários-B podem trabalhar com as instâncias existentes e os volumes anexados nos compartimentos do Projeto-A e Projeto-B, respectivamente. Veja como fica o layout:
| Item | Descrição |
|---|---|
|
Políticas anexadas à tenancy:
|
 |
Política anexada e gerenciada por Jorge:
|
 |
Política anexada e gerenciada por Cheri:
|
Para obter mais informações sobre recursos básicos e avançados de políticas, consulte Como as Políticas Funcionam. Para obter exemplos de outras políticas típicas que sua organização pode usar, consulte Políticas Comuns.
Permita que os administradores de backup gerenciem apenas backups.
Tipo de acesso: Capacidade de fazer todas as coisas com backups de volume, mas não criar e gerenciar volumes propriamente ditos. Isso faz sentido se você quiser que um único conjunto de administradores de backup de volume gerencie todos os backups de volume em todos os compartimentos. A primeira instrução fornece o acesso necessário ao volume que está sendo armazenado; a segunda instrução permite a criação do backup (e a capacidade de excluir backups). A terceira instrução permite a criação e o gerenciamento de políticas de backup definidas pelo usuário; a quarta instrução permite a atribuição e a remoção da atribuição de políticas de backup.
Onde criar a política: Na tenancy, para que o acesso seja facilmente concedido a todos os compartimentos por meio da herança da política. Para reduzir o escopo do acesso apenas aos volumes e backups em um compartimento em particular, especifique esse compartimento em vez da tenancy.
Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancySe o grupo for usar a Console, a seguinte política fornecerá uma melhor experiência ao usuário:
Allow group VolumeBackupAdmins to use volumes in tenancy
Allow group VolumeBackupAdmins to manage volume-backups in tenancy
Allow group VolumeBackupAdmins to inspect volume-attachments in tenancy
Allow group VolumeBackupAdmins to inspect instances in tenancy
Allow group VolumeBackupAdmins to manage backup-policies in tenancy
Allow group VolumeBackupAdmins to manage backup-policy-assignments in tenancyAs duas últimas instruções não são necessárias para gerenciar backups de volume. No entanto, elas permitem que a Console exiba todas as informações sobre um determinado volume e as políticas de backup disponíveis.
Anexo de Política
Anexos de políticas
Outro recurso básico de políticas é o conceito de anexação. Quando você cria uma política, deve anexá-la a um compartimento (ou tenancy, que é o compartimento raiz). O local ao qual você a associa determina quem pode modificá-la ou excluí-la. Se você anexá-la à tenancy (em outras palavras, se a política estiver no compartimento raiz), qualquer pessoa com acesso para gerenciar políticas na tenancy poderá alterá-la ou excluí-la. Normalmente, é o grupo Administradores ou qualquer grupo semelhante que você cria e ao qual dá um amplo acesso. Qualquer pessoa com acesso somente a um compartimento filho não pode modificar ou excluir essa política.
Se você, em vez disso, anexar a política a um compartimento filho, todos que tenham acesso para gerenciar as políticas nesse compartimento poderão alterá-la ou excluí-la. Em termos práticos, isso significa que é fácil conceder aos administradores de compartimentos (ou seja, um grupo com acesso a manage all-resources no compartimento) para gerenciar as políticas dos seus próprios compartimentos, sem lhes dar acesso mais amplo para gerenciar políticas que residam na tenancy. Para obter um exemplo que usa esse tipo de design de administrador de compartimento, consulte Exemplo de Cenário. (Lembre-se de que, devido à herança de política, os usuários com acesso para gerenciar políticas na tenancy automaticamente têm a capacidade de gerenciar políticas em compartimentos dentro da tenancy.)
O processo de anexação da política é fácil (seja anexando a um compartimento ou à tenancy): se você estiver usando a Console, quando adicionar a política ao serviço IAM, basta certificar-se de que você está no compartimento desejado ao criar a política. Se você estiver usando a API, especifique o OCID do compartimento desejado (a tenancy ou outro compartimento) como parte da solicitação para criar a política.
Quando você anexar uma política a um compartimento, deverá estar nesse compartimento e indicar diretamente na instrução à qual ele se aplica. Se você não estiver no compartimento, receberá um erro se tentar anexar a política a outro compartimento. Observe que a anexação ocorre durante a criação da política, o que significa que uma política pode ser anexada a apenas um compartimento. Para saber como anexar uma política a um compartimento, consulte Criando uma Política.