Observação:
- Este tutorial requer acesso ao Oracle Cloud. Para se inscrever em uma conta gratuita, consulte Conceitos Básicos do Oracle Cloud Infrastructure Free Tier.
- Ele usa valores de exemplo para credenciais, tenancy e compartimentos do Oracle Cloud Infrastructure. Ao concluir seu laboratório, substitua esses valores por valores específicos do seu ambiente de nuvem.
Aprofunde-se nas Políticas do Oracle Cloud Infrastructure Identity and Access Management baseadas em Tag
Introdução
As políticas do OCI IAM (Oracle Cloud Infrastructure Identity and Access Management) são a base de um ambiente de nuvem robusto e seguro. Eles fornecem um mecanismo poderoso e flexível para controlar o acesso aos recursos da OCI, garantindo que apenas usuários e serviços autorizados possam executar ações específicas em recursos designados.
Em sua essência, uma política do OCI IAM é um conjunto de instruções declarativas escritas em uma sintaxe legível por humanos que determina quem pode acessar o quê e em quais condições. Essas políticas permitem que as organizações apliquem o princípio de privilégio mínimo, concedendo aos usuários e serviços apenas as permissões necessárias para executar suas tarefas e nada mais. Isso minimiza os riscos de segurança, mantendo a eficiência operacional.
As políticas do OCI IAM são aplicadas em vários níveis da hierarquia do OCI, incluindo compartimentos, tenancy e recursos específicos, tornando-as altamente adaptáveis a estruturas organizacionais complexas. Com a herança e a compartimentação de políticas da OCI, os administradores podem estabelecer controles granulares personalizados para seus requisitos operacionais e de segurança específicos. Para obter mais informações sobre políticas do OCI, consulte Conceitos Básicos de Políticas.
Neste tutorial, vamos nos aprofundar na importância da otimização de políticas, explorar as melhores práticas para políticas de ajuste fino para alcançar os melhores resultados e destacar cenários em que a otimização de políticas pode ser aproveitada ao máximo.
Objetivos
-
Desmistifique componentes e sintaxe da política.
-
Entenda por que o ajuste das políticas do OCI IAM é crucial para a escalabilidade e os limites da política.
-
Fornecer melhores práticas acionáveis.
-
Enfatize a função de marcação no gerenciamento de políticas.
-
Destaque desafios e soluções comuns ao mostrar casos de uso do mundo real.
Pré-requisitos
-
Acesso a uma tenancy do OCI.
-
Compreensão básica dos conceitos da OCI.
-
Conhecimento do OCI IAM.
-
Familiaridade com sintaxe de política.
-
Noções básicas de compartimentalização e marcação.
-
Consciência do princípio do menor privilégio.
-
A política do OCI limita o conhecimento.
-
Experiência com padrões de governança e conformidade.
Desmistificar Componentes de Política e Sintaxe
Para ajustar efetivamente as políticas do OCI IAM, é essencial entender sua estrutura e os principais componentes. As políticas no OCI definem permissões especificando quem (principal), o que (ação) no que (recurso) e onde (escopo). Vamos detalhar isso:
Principais Componentes de uma Política do OCI IAM
-
Principal (Assunto): A entidade que solicita acesso, que pode ser uma das seguintes:
-
Usuário: Uma conta individual no OCI, geralmente representando uma pessoa. Para obter mais informações, consulte Gerenciando Usuários.
-
Grupo: Um conjunto de usuários com necessidades de acesso compartilhado. Para obter mais informações, consulte Trabalhando com Grupos.
-
Grupo Dinâmico: Um conjunto de recursos do OCI (por exemplo, instâncias de computação, funções) identificados por regras específicas. Os recursos em um grupo dinâmico são agrupados automaticamente com base em critérios como tags ou metadados. Para obter mais informações, consulte Gerenciando Grupos Dinâmicos.
-
Controlador de Recursos: Um serviço (como OCI Functions ou Oracle Autonomous Database) que age em seu próprio nome. Os controladores de recursos permitem que os serviços sejam autenticados com segurança com o OCI e outros recursos sem exigir credenciais explícitas. Para obter mais informações, consulte Autenticação do Controlador de Recursos.
-
Controlador de Instâncias: Um tipo de controlador de recursos específico para instâncias de computação. Ele permite que as instâncias interajam diretamente com serviços do OCI (por exemplo, OCI Object Storage ou Identity) usando políticas do OCI IAM, sem incorporar credenciais no aplicativo em execução na instância. Para obter mais informações, consulte Principais de Instância.
-
-
Ação (Verbo): Especifica as operações que o principal pode executar:
inspect
: Exibe metadados sobre o recurso.read
: Exiba metadados e dados dentro do recurso.use
: Executar ações de leitura e operações de gerenciamento limitadas.manage
: Execute todas as ações, incluindo a criação e a exclusão de recursos.
Consulte Operações.
-
Recurso (Resource-Type): Define o tipo de recurso do OCI ao qual a ação se aplica, como:
- Instâncias de computação, buckets de armazenamento, VCNs, bancos de dados etc.
- Os recursos podem ser organizados hierarquicamente usando compartimentos para melhor gerenciamento.
Para obter mais informações, consulte Recursos.
-
Escopo (Local): Especifica o local em que a política se aplica:
- Compartimento: Um contêiner lógico para recursos, ativando a organização hierárquica.
- Tenancy: Toda a conta do OCI, geralmente usada para permissões globais.
Para obter mais informações, consulte Local.
-
Regra de Correspondência (condições): Especifique uma ou mais condições. Use qualquer ou todos com várias condições para um OR ou AND lógico, respectivamente.
- Sintaxe de uma única condição:
variable =|!= value
. - Síntese de várias condições:
any|all {<condition>,<condition>,...}
.
Para obter mais informações, consulte Condições.
- Sintaxe de uma única condição:
Dica de Bônus: Noções Básicas sobre o Conceito de Set-Intersect na Política do OCI IAM
A interseção de conjuntos nas políticas do OCI IAM é usada para conceder acesso somente quando há uma sobreposição entre dois conjuntos de valores. Isso garante que as permissões sejam concedidas dinamicamente com base na associação a grupos, tags de recursos ou outros atributos, em vez de codificar usuários ou grupos específicos em políticas.
-
Exemplo de Sets-Intersect na Política do OCI IAM
Allow any-user to manage database-family-resources in tenancy where sets-intersect(request.groups.name, target.resource.compartment.tag.database.admins)
Quebrando a Declaração de Política:
-
Permitir qualquer usuário: Esta política se aplica a qualquer usuário autenticado no OCI (independentemente da associação de grupo específica).
-
para gerenciar recursos de família de bancos de dados: Concede controle administrativo total sobre todos os recursos relacionados ao banco de dados (bancos de dados autônomos, sistemas de banco de dados, backups etc.).
-
na tenancy: A política se aplica a toda a tenancy (todos os compartimentos).
-
em que sets-intersect(
request.groups.name
,target.resource.compartment.tag.database.admins
)request.groups.name
: Representa os grupos aos quais o usuário pertence.target.resource.compartment.tag.database.admins
: Uma tag no compartimento que contém uma lista de grupos permitidos que podem gerenciar recursos de banco de dados nesse compartimento.- sets-intersect(...): Garante que o acesso só seja concedido se o usuário pertencer a pelo menos um grupo listado na tag.
-
Modelo de Política do OCI IAM para Grande Escala
As políticas do OCI IAM são uma das partes fundamentais da proteção de cargas de trabalho na OCI. É crucial ser capaz de escalar e suportar uma grande carga de trabalho para nossos clientes. É por isso que criamos um modelo de política que requer um pequeno número de políticas, dentro dos limites de política da OCI, que funcionam para qualquer tamanho de carga de trabalho. A seguir estão alguns dos motivos para adotar o modelo de política escalável. Para obter mais informações, consulte Serviço IAM With Identity Domains Limits.
Ajustar as políticas do OCI IAM é uma tarefa crítica para manter um ambiente de nuvem seguro, escalável e eficiente, mantendo-se dentro dos limites da política da OCI. É por isso que esse processo é essencial:
-
Limites e Restrições de Política: O OCI impõe limites específicos ao número de políticas que podem ser criadas em uma tenancy e compartimentos. Esses limites podem ser rapidamente esgotados em ambientes complexos ou de grande escala se as políticas não forem otimizadas.
-
Os principais motivos incluem:
- Evite Redundância: A definição repetida de políticas semelhantes para diferentes compartimentos ou recursos pode levar ao inchaço da política, dificultando o gerenciamento.
- Permanecer nos Limites de Política do OCI: o OCI tem um número máximo de instruções de política por política e por tenancy. O ajuste garante que você não atinja esses limites prematuramente.
-
-
Melhorando a Gerenciabilidade: à medida que as organizações crescem, o gerenciamento de centenas de políticas em vários compartimentos pode se tornar difícil sem ajuste. Políticas otimizadas:
- Simplifique o gerenciamento reduzindo o número total de políticas.
- Melhore a clareza e evite regras sobrepostas ou conflitantes, facilitando a depuração e a auditoria.
-
Escalabilidade em Ambientes Complexos: As políticas ajustadas permitem um dimensionamento contínuo por meio de:
- Usando curingas e permissões no nível do recurso quando apropriado para reduzir a necessidade de regras específicas do compartimento ou do recurso. Para obter mais informações, consulte Condições.
- Aproveitando a herança da política para que políticas de nível superior se apliquem a compartimentos filhos sem a necessidade de instruções duplicadas. Para obter mais informações, consulte Herança de Políticas.
- Agrupar usuários e recursos logicamente para aplicar permissões mais amplas, mas ainda seguras.
-
Otimização de Desempenho: A OCI avalia políticas durante cada solicitação de acesso. Um grande número de políticas redundantes ou excessivamente específicas pode aumentar o tempo de avaliação, levando potencialmente a decisões de controle de acesso mais lentas. Políticas otimizadas reduzem a sobrecarga, garantindo operações mais rápidas e eficientes.
-
Aderindo ao Princípio do Privilégio Mínimo: ao ajustar a escalabilidade, é fundamental manter o princípio do privilégio mínimo. Políticas amplas e não verificadas podem comprometer a segurança, portanto, é essencial encontrar um equilíbrio entre acesso mínimo e escalabilidade.
A Função da Marcação com Tags no Gerenciamento de Políticas
O Tagging é um recurso avançado na OCI que aprimora significativamente o gerenciamento de políticas, permitindo um controle refinado sobre os recursos. Tags são rótulos de metadados, representados como pares de chave/valor, que podem ser anexados aos recursos. Eles ajudam a organizar, gerenciar e impor o controle de acesso em escala, especialmente em ambientes de nuvem complexos com várias equipes e projetos. Para obter mais informações, consulte Visão Geral do Serviço Tagging.
Como o Tagging Aprimora o Gerenciamento de Políticas
-
Simplifica a Identificação de Recursos: As tags fornecem uma maneira unificada de categorizar recursos com base em atributos como projetos, ambientes, proprietários ou departamentos. Isso simplifica o processo de aplicação de políticas a subconjuntos específicos de recursos.
Exemplo: A marcação de recursos com
Project: ProjectX
permite políticas de acesso direcionadas.Allow group Developers to manage instances in tenancy where tag.Project = 'ProjectX'
-
Ativar Aplicação de Política Dinâmica: Políticas baseadas em tags se adaptam à alteração de atributos de recursos. Por exemplo, se uma nova instância for marcada com
Environment: Production
, ela herdará automaticamente as políticas definidas para ambientes de produção.Exemplo de Política:
Allow group QA to inspect instances in tenancy where tag.Environment = 'Test'
-
Simplifica a Governança de Vários Projetos e Várias Equipes: As tags ajudam a isolar o acesso associando recursos a equipes ou projetos específicos. Isso reduz a complexidade ao gerenciar permissões em vários grupos.
-
Facilita a Automação: As tags podem conduzir workflows automatizados para criação de recursos, monitoramento e gerenciamento do ciclo de vida. Por exemplo, scripts de rastreamento de custos podem recuperar todos os recursos marcados com a tag CostCenter: Marketing para gerar relatórios de despesas detalhados.
-
Melhora o Gerenciamento de Custos e a Geração de Relatórios: As tags permitem a atribuição de custos granulares a projetos, departamentos ou ambientes específicos. Isso ajuda as organizações a rastrear os gastos e otimizar os orçamentos de forma mais eficaz.
Governança de Tag: Controlando o Gerenciamento de Tag
Para manter a consistência, a confiabilidade e a segurança no gerenciamento de políticas, a criação e a modificação de tags devem ser rigorosamente controladas. A governança garante que as tags sejam aplicadas corretamente e alinhadas com os padrões organizacionais. Restringir o gerenciamento de tags a um conjunto específico de indivíduos ou grupos é um elemento-chave para manter o controle, a consistência e a segurança dentro do ambiente de nuvem de uma organização.
-
Por que restringir o gerenciamento de tags?
Tagging é uma ferramenta poderosa para organizar e controlar recursos, mas se mal gerenciado, pode levar a controle de acesso inconsistente ou não autorizado, problemas de rastreamento de custos e desafios de governança. Ao implementar políticas rigorosas sobre quem pode gerenciar tags, as organizações podem garantir que apenas funcionários autorizados possam criar, modificar ou excluir tags críticas, preservando a integridade do ambiente.
-
Impedir Alterações Não Autorizadas: As tags geralmente estão vinculadas a processos de negócios importantes, como alocação de custos, categorização de recursos e controle de acesso. Permitir acesso irrestrito para modificar tags pode levar a alterações não autorizadas ou acidentais, o que pode interromper as operações ou resultar em recursos mal alocados.
-
Garanta Padrões de Tag Consistentes: As organizações se beneficiam de esquemas de tag padronizados que ajudam a organizar recursos e permitem um rastreamento fácil. Ao limitar o gerenciamento de tags a um grupo definido de administradores, as organizações podem garantir a adesão a esses padrões, impedindo a fragmentação e a inconsistência nas práticas de tags.
-
Manter Segurança e Conformidade: As tags podem ser aproveitadas para impor políticas de segurança e requisitos de conformidade. Por exemplo, as tags podem definir ambientes (por exemplo, Produção, Desenvolvimento) ou classificações de dados confidenciais. Permitir que apenas usuários autorizados modifiquem essas tags garante que ambientes confidenciais sejam protegidos e que os controles de acesso sejam aplicados corretamente.
-
Reduzir o Risco de Configuração Incorreta de Política: As políticas baseadas em tag no OCI (como controle de acesso a recursos) dependem do uso de tag consistente e preciso. Se o grupo ou indivíduo errado puder modificar ou excluir tags, isso poderá resultar inadvertidamente em políticas de acesso excessivamente amplas ou restritivas.
-
-
Como Restringir o Gerenciamento de Tags no OCI
No OCI, o gerenciamento de tags pode ser controlado criando e aplicando políticas do OCI IAM que definem quem pode executar operações de tags, como criar, atualizar ou excluir tags. Essas políticas podem ser personalizadas para conceder acesso a usuários, grupos ou compartimentos específicos, garantindo que apenas indivíduos autorizados tenham o poder de alterar tags críticas.
Aqui estão algumas maneiras de restringir o gerenciamento de tags a indivíduos ou grupos específicos:
-
Usar Controle de Acesso Baseado em Grupo: A primeira etapa no controle do gerenciamento de tags é garantir que apenas grupos específicos recebam as permissões necessárias para gerenciar tags. Por exemplo, um grupo designado, como
TagAdmins
, pode receber permissões exclusivas para tratar a criação e as atualizações de tags.Exemplo de Política do OCI IAM:
Allow group TagAdmins to manage tag-namespaces in tenancy
Essa política garante que somente o grupo
TagAdmins
possa criar, modificar ou excluir tags e namespaces de tag em toda a tenancy. Para permitir que alguns grupos, como engenheiros de devops ou grupos do Terraform Runner, possam usar essas tags criadas por meio da console para scripts, você pode definir a política a seguir.Allow group devopsTeam to use tag-namespaces in tenancy Allow group terraformRunner to use tag-namespaces in tenancy Allow dynamic-group terraformRunner to use tag-namespaces in tenancy
-
Usar Políticas no Nível do Compartimento para Controle Granular: As políticas de gerenciamento de tags podem ser aplicadas no nível do compartimento; portanto, somente determinados compartimentos têm acesso de gerenciamento de tags. Por exemplo, se você quiser restringir o gerenciamento de tags a um projeto ou unidade de negócio específico, poderá aplicar políticas que limitem o acesso a tags no compartimento relevante.
Exemplo de Política para Gerenciamento de Tags Específicas do Compartimento:
Allow group TagAdmins to manage tag-namespaces in compartment ProjectA
Isso garante que somente os usuários do grupo
TagAdmins
possam gerenciar tags no compartimentoProjectA
, limitando seu acesso a outros compartimentos. Além disso, você pode criar grupos para permitir que apenas os usuários usem as tags criadas, mas não modificá-las no nível do compartimento.Allow group TagUser to use tag-namespaces in compartment ProjectA
-
Controle de Tag com Namespaces de Tag: O OCI suporta
tag namespaces
, que agrupa tags relacionadas juntas. Você pode controlar quem pode gerenciar tags em um namespace específico, o que permite um controle mais granular sobre quem tem acesso a tipos específicos de tags.Exemplo de Política para Gerenciamento de Tags Específicas do Namespace:
Allow group TagAdmins to manage tag-namespaces in tenancy where tag.namespace = 'Billing'
Isso garante que somente usuários com permissões
TagAdmins
possam gerenciar tags no Namespace de faturamento, fornecendo uma governança mais rígida em relação a tags de rastreamento de custos. -
Auditar e Monitorar Alterações de Tag: para garantir que o gerenciamento de tags permaneça seguro, as organizações devem implementar políticas de auditoria e monitoramento para rastrear todas as alterações feitas nas tags. Os logs de auditoria do OCI fornecem visibilidade de ações relacionadas à criação, exclusão e modificação de tags. O monitoramento desses logs ajuda a identificar quaisquer tentativas não autorizadas de modificar tags ou quaisquer padrões que sugiram mau gerenciamento.
-
Políticas do OCI IAM baseadas em tag para casos de uso real
Agora, com tudo o que você aprendeu acima, vamos trabalhar no ajuste das políticas do OCI IAM para princípios de Usuário e princípios de Instância em casos de uso da vida real. Mas antes de fazer isso, existem algumas políticas comuns que todos os clientes exigirão, independentemente de seu caso de uso.
-
Políticas Comuns do OCI IAM:
-
Políticas do OCI IAM para Gerenciamento de Usuários: o grupo
IAMAdmin
é responsável por gerenciar configurações relacionadas ao OCI IAM, como domínios, usuários e grupos do OCI IAM.Allow group IAMAdmin to manage domains in tenancy Allow group IAMAdmin to manage users in tenancy Allow group IAMAdmin to manage groups in tenancy
-
Políticas do OCI IAM para Gerenciamento de Tags: O grupo
InfoSec
é responsável por gerenciar configurações relacionadas à segurança, como políticas, usuários e namespaces de tag do OCI IAM.Allow group InfoSec to manage tag-namespaces in tenancy Allow group InfoSec to manage policies in tenancy Allow group InfoSec to use users in tenancy Allow group InfoSec to manage groups in tenancy where all {target.group.name != ‘Administrators’, target.group.name != ‘InfoSec’}
-
Políticas do OCI IAM para (Terraform Runner): O grupo
terraform-runner
é dedicado à execução de scripts de automação do Terraform para provisionamento de infraestrutura.Allow group terraform-runner to use tag-namespaces in tenancy Allow group terraform-runner to manage instance-family in compartment Tenants Allow group terraform-runner to manage virtual-network-family in compartment Tenants Allow group terraform-runner to manage volume-family in compartment Tenants Allow group terraform-runner to manage object-family in compartment Storage Allow group terraform-runner to manage secret-family in compartment Tenants Allow group terraform-runner to manage key-family in compartment Tenants
-
Dimensionar Políticas do OCI IAM para Controladores de Usuários
Modelo de Política do OCI IAM: Neste modelo de política, o objetivo é escrever um pequeno número de políticas mais gerenciáveis que são informadas por dados (tags no nosso caso), também conhecidas como Controle de Acesso Baseado em Atributo. Vamos nos referir a tags designadas ao recurso de destino ou ao compartimento de recursos de destino para controle de acesso como tags de permissão.
Tags de Permissão: Defina a tag de permissão para cada combinação de Verbo (Ação) + Tipo de Recurso na tenancy. Eles definem uma permissão exclusiva que você precisa atribuir a um grupo de usuários para recursos de destino. A lista não é definida e concluída uma vez. Comece com um pequeno número de tags de permissão. Depois de obter um identificador sobre o modelo de política, você poderá adicionar mais tags de permissão. Para este tutorial, criaremos um namespace de tag de permissão como mgmt
. Além disso, criaremos um namespace de tag (chamaremos isso de infosec
) com uma chave de tag chamada gname
.
-
Para a estrutura de compartimento a seguir com quatro tipos de recursos e para designar permissões de gerenciamento e uso para esses recursos, criaremos tags de permissão.
-
Para cada permissão que você precisa atribuir a um destino (compartimentos na maioria dos casos), crie um grupo. Designamos tags de permissão aos recursos (usando tags padrão de compartimento) e aos compartimentos de recursos. O valor da tag é o grupo que deve ter a permissão fornecida no recurso de destino.
-
Depois que as tags de permissão forem definidas, poderemos gravar políticas. O resultado final é que precisaremos de apenas uma política por tag de permissão definida na tenancy. A mesma política para a permissão fornecida funcionará em toda a tenancy.
-
À medida que integramos mais cargas de trabalho, se houver mais tipos de recursos a serem gerenciados, talvez você precise adicionar mais tags de permissão e políticas para essas tags de permissão. Caso contrário, basta atribuir tags de permissão existentes à nova carga de trabalho com um grupo de usuários que devem ter acesso. Não precisamos criar novas políticas para a nova carga de trabalho.
Essa abordagem permanecerá consistente em todos os exemplos discutidos aqui, servindo como base para definir Grupos e Políticas do OCI IAM.
Exemplo 1: Compartimento para Cada Aplicativo
Etapa 1: Obtenha uma Compreensão Abrangente da Visão Geral de Negócios do Cliente
CompanyA é uma empresa de tecnologia em crescimento que desenvolve e implementa vários aplicativos nativos da nuvem para seus clientes. Cada aplicativo atende a um segmento de cliente específico, com requisitos rigorosos de segurança e conformidade. Para garantir isolamento, escalabilidade e controle de acesso eficiente, o CompanyA organiza seus recursos da OCI usando uma abordagem de compartimentação estruturada.
Etapa 2: Projetar Estrutura do Compartimento para a Carga de Trabalho
Conforme descrito, CompanyA segue o modelo de política do OCI IAM para dimensionar suas políticas do OCI IAM. Eles criaram compartimentos separados para seus aplicativos para manter o isolamento de recursos.
Observação: Somente administradores devem ser capazes de gerenciar o namespace de tag
mgmt
einfosec
.
Etapa 3: Projetar as seguintes tags de permissão da combinação de tipo Verb+Resource
Criar grupos no OCI.
-
Faça log-in no domínio do OCI IAM com uma conta Admin que tenha o privilégio de criar grupos.
-
Vá para Identidade e Segurança e clique em Domínios em Identidade.
-
Selecione seu compartimento e clique no domínio para o qual deseja criar os grupos.
-
Clique em Grupos.
-
Defina seus Grupos com base nas tags de permissão. (Opcionalmente) adicione seus usuários a esses grupos.
Observação: você terá que criar grupos para uma combinação exclusiva de permissão e destino. Se o mesmo grupo funcional de usuários (NetworkAdmin) precisar ter acesso para gerenciar a rede em todos os destinos, você precisará de apenas um grupo para gerenciar o acesso em todos os destinos.
A seguir estão as tags de permissão e os grupos do OCI IAM para essas tags. Siga as etapas acima para criar grupos para cada uma das tags de permissão definidas.
-
Compartimento Raiz: O compartimento raiz serve como camada de gerenciamento de nível superior. Onde teremos nossos grupos de administradores marcados com tags de permissão. As seguintes etiquetas são:
- Administradores: permissão
manageall
para gerenciar o gerenciamento geral da tenancy. - UseAdministrators: Permissão
useall
para acessar recursos na tenancy. - Auditor: Permissão
readall
com acesso somente para leitura a recursos para monitoramento na tenancy.
- Administradores: permissão
-
Modelo de Compartimento por Aplicativo: CompanyA tem vários aplicativos baseados na nuvem. Criaremos um compartimento pai separado para cada aplicativo. Vamos explorar como esse modelo se aplica ao Aplicativo 1 (App1) e ao Aplicativo 2 (App2) como compartimentos pais.
-
Aplicativo 1 (App1): Um aplicativo voltado para o cliente hospedado no OCI.
- Compartimento de Rede: Compartimento de todos os recursos relacionados à rede, como VCN, sub-redes etc. Agora, vamos criar as tags de permissão e seus respectivos grupos do OCI IAM.
- App1NetworkAdmin: Tag de permissão de recursos
managenetwork
para engenheiros que gerenciam recursos de rede para App1. - App1NetworkUser: Tag de permissão de recursos
usenetwork
para desenvolvedores que precisam de acesso limitado às configurações de rede de App1. - App1NetworkReader: Tag de permissão de recursos
readnetwork
para auditores que verificam a configuração de rede de App1.
- App1NetworkAdmin: Tag de permissão de recursos
- Compartimento de Computação: Compartimento para instâncias de computação. Agora, vamos criar as tags de permissão e seus respectivos grupos do OCI IAM.
- App1ComputeAdmin: Tag de permissão de recursos
managecompute
para administradores de sistema provisionarem e dimensionarem instâncias de computação para o backend App1. - App1ComputeUser: Tag de permissão de recursos
usecompute
para desenvolvedores que implantam e testam serviços de backend de App1. - App1ComputeReader: Tag de permissão de recursos
readcompute
para auditores que monitoram o uso de recursos de computação para App1.
- App1ComputeAdmin: Tag de permissão de recursos
- Compartimento de Dados: Compartimento para recursos relacionados a banco de dados e armazenamento. Agora, vamos criar as tags de permissão e seus respectivos grupos do OCI IAM.
- App1DataAdmin: Tag de permissão de recursos
managedb
para administradores de banco de dados que gerenciam Oracle Autonomous Databases e OCI Object Storage para App1. - App1DataUser: Tag de permissão de recursos
usedb
para cientistas de dados que acessam conjuntos de dados para análise com relação a App1. - App1DataReader: Tag de permissão de recursos
readdb
para auditores que analisam configurações de banco de dados de App1.
- App1DataAdmin: Tag de permissão de recursos
- Compartimento de Rede: Compartimento de todos os recursos relacionados à rede, como VCN, sub-redes etc. Agora, vamos criar as tags de permissão e seus respectivos grupos do OCI IAM.
-
Aplicativo 2 (App2): Um sistema interno de planejamento de recursos empresariais (ERP) para operações da CompanyA.
Observação: Aqui também seguiremos a mesma abordagem de estrutura de compartimento e criaremos Compartimento de Rede, Compartimento de Computação e Compartimento de Dados no compartimento App2 pai. Para evitar redundância, vamos apenas anotar as tags de permissão e os grupos do OCI IAM para App2.
-
Compartimento de Rede:
- App2NetworkAdmin: Tag de permissão de recursos
managenetwork
. - App2NetworkUser: Tag de permissão de recursos
usenetwork
. - App2NetworkReader: Tag de permissão de recursos
readnetwork
.
- App2NetworkAdmin: Tag de permissão de recursos
-
Compartimento de Computação:
- App2ComputeAdmin: Tag de permissão de recursos
managecompute
. - App2ComputeUser: Tag de permissão de recursos
usecompute
. - App2ComputeReader: Tag de permissão de recursos
readcompute
.
- App2ComputeAdmin: Tag de permissão de recursos
-
Compartimento de Dados:
- App2DataAdmin: Tag de permissão de recursos
managedb
. - App2DataUser: Tag de permissão de recursos
usedb
. - App2DataReader: Tag de permissão de recursos
readdb
.
- App2DataAdmin: Tag de permissão de recursos
-
-
Observação: aplique uma tag de permissão a um destino (o destino pode ser um recurso ou compartimento) para ditar qual grupo terá essa permissão específica no destino para App1 e App2.
Etapa 4: Gravar Políticas do OCI IAM para essas Tags de Permissão
Criaremos as políticas para CompanyA usando a mesma abordagem discutida aqui: Tenha menos Mais - Dimensionando políticas do OCI IAM para Grupos. Para isso, crie um namespace de tag (chamaremos isso de infosec
) com uma chave de tag chamada gname
.
-
Faça log-in no domínio do OCI IAM com uma conta Admin que tenha o privilégio de criar políticas.
-
Vá para Identidade e Segurança e clique em Políticas em Identidade.
-
Selecione o Compartimento raiz e clique em Criar Política.
-
Informe o Nome, a Descrição da sua política e adicione as Instruções de Política também. Clique em Criar.
-
Política de Todos os Recursos:
Allow any-user to manage all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageall) Allow any-user to use all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useall) Allow any-user to read all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readall)
Observação: Siga o mesmo procedimento para definir todas as políticas mencionadas a seguir e adicionar suas respectivas instruções de política.
-
Política do Cloudguard:
Allow any-user to manage cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecspm) Allow any-user to use cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecspm) Allow any-user to read cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcspm)
-
Política de Rede:
Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork) Allow any-user to use virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useetwork) Allow any-user to read virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readnetwork)
-
Política de Computação:
Allow any-user to manage instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecompute) Allow any-user to use instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecompute) Allow any-user to read instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcompute)
-
Política de Banco de Dados:
Allow any-user to manage database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managedb) Allow any-user to use database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usedb) Allow any-user to read database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readdb)
-
Exemplo 2: Compartimento para Cada Cliente/Tenant
Etapa 1: Obtenha uma Compreensão Abrangente da Visão Geral de Negócios do Cliente
CompanyB Solutions é um ISV (Independent Software Vendor, Fornecedor de software independente) líder que fornece aplicativos SaaS baseados em tenant em infraestrutura de nuvem, gerenciamento de dados e análise avançada. A CompanyB atende a vários clientes em todos os setores, oferecendo soluções contínuas, seguras e escaláveis. Seu sucesso depende do uso da OCI com uma estrutura compartimental bem projetada para gerenciar recursos com eficiência, aderindo aos requisitos de segurança e conformidade.
Etapa 2: Projetar Estrutura do Compartimento para a Carga de Trabalho
CompanyB isolou as cargas de trabalho de seus clientes e criou um subcompartimento dedicado. Além disso, eles têm um compartimento de rede, armazenamento compartilhado e compartimento de banco de dados. Mesmo CompanyB segue o modelo de política do OCI IAM para dimensionar suas políticas do OCI IAM.
Etapa 3: Criar Tags de Permissão Seguintes da Combinação Tipo Verb+Resource
Para criar grupos, consulte o Exemplo 1 Etapa 3. Você terá que criar grupos para todas as tags de permissão definidas abaixo.
-
Compartimento-Raiz - Governança Centralizada: O componente-raiz atua como a camada central para supervisionar todos os recursos e atividades na tenancy do OCI. Onde teremos nossos grupos de administradores marcados com tags de permissão. As seguintes etiquetas são:
- Administradores: permissão
manageall
para gerenciar o gerenciamento geral da tenancy. - UseAdministrators: Permissão
useall
para acessar recursos na tenancy. - Auditor: Permissão
readall
com acesso somente para leitura a recursos para monitoramento na tenancy.
- Administradores: permissão
-
Compartimento de Rede - Backbone de Operações: O compartimento de rede suporta a infraestrutura de rede em nuvem do CompanyB, permitindo a conectividade em todos os recursos. Isso inclui Redes Virtuais na Nuvem (VCNs), sub-redes, gateways e balanceadores de carga. Vamos definir as tags de permissão e os respectivos grupos do OCI IAM para ele.
- NetworkAdmin: Tag de permissão de recursos
managenetwork
para engenheiros que gerenciam recursos de rede para CompanyB. - NetworkUser: Tag de permissão de recursos
usenetwork
para desenvolvedores que precisam de acesso limitado às configurações de rede de CompanyB. - NetworkReader: Tag de permissão de recursos
readnetwork
para auditores que verificam a configuração de rede de CompanyB.
- NetworkAdmin: Tag de permissão de recursos
-
Compartimento de Tenants - Compartimentos Isolados para Diferentes Cargas de Trabalho do Cliente: O compartimento de tenants é estruturado para isolar recursos e cargas de trabalho de cada cliente (tenant). Isso garante que o CompanyB ofereça serviços seguros e privados, mantendo a eficiência operacional.
-
Compartimento do Tenant 1: O tenant 1 representa um cliente empresarial principal que usa CompanyB para serviços de log e desenvolvimento de aplicativos. Veja a seguir as tags de permissão e os respectivos grupos do OCI IAM:
t1devadmin
: A permissão de recursomanageappdev
para a equipe de desenvolvimento do Tenant 1 tem privilégios administrativos para configurar e implantar aplicativos personalizados.t1devuser
: Permissão de recursouseappdev
para monitorar e ajustar recursos do aplicativo. Os desenvolvedores do tenant 1 usam esses recursos para desenvolvimento e teste diários.t1logsadmin
et1devuser
: A permissão de recursomanagelogs
euselogs
para registro em log e monitoramento de funções garante que os administradores configurem serviços de registro em log enquanto os desenvolvedores acessam logs para depurar e otimizar aplicativos.t1devadmin
et1devuser
: Permissão de recursosmanagecspm
eusecspm
para o Tenant 1, pois eles também têm foco na postura de segurança, com a capacidade de monitorar e remediar riscos de segurança.
-
Tenant 2 and Tenant 3 Compartments: The structure for Tenant 2 and Tenant 3 mirrors that of Tenant 1, with roles like
t2devadmin
,t2devuser
,t3devadmin
,t3devuser
,t2logsadmin
andt3logsadmin
ensuring that each tenant operates in a fully isolated environment. Essa abordagem permite que a CompanyB mantenha uma governança consistente enquanto atende às necessidades específicas do locatário. -
Compartimento Compartilhado - Recursos Centralizados para Todos os Tenants: O compartimento compartilhado inclui recursos como bancos de dados e armazenamento de objetos que vários tenants utilizam, mas permanecem logicamente segregados para privacidade e segurança.
- Compartimento do Banco de Dados:
dbadmin
: A permissão de recursomanagedb
para administradores de banco de dados da CompanyB lidam com bancos de dados compartilhados usados por todos os tenants, incluindo provisionamento, dimensionamento e aplicação de patches.dbuser
: A permissão de recursousedb
para usuários específicos do Tenant acessam seus respectivos esquemas ou serviços de banco de dados.dbreader
: A permissão de recursoreaddb
para auditores tem acesso somente para leitura para garantir que as configurações do banco de dados estejam em conformidade com as políticas de segurança.
- Compartimento de Armazenamento: O OCI Object Storage é gerenciado centralmente, com buckets dedicados para cada tenant:
osadmin
: Permissão de recursomanageobject
responsável pelo gerenciamento dos recursos de armazenamento de objetos compartilhados.osuser
:useobject
Permissão de recurso de armazenamento específico do tenant (ou exemplo,t1osur
,t2osur
,t3osur
) garante que os tenants acessem apenas seus respectivos buckets.osreader
: A permissão de recursoreadobject
para equipes de conformidade revisam configurações de armazenamento e padrões de uso.
- Compartimento do Banco de Dados:
-
Etapa 4: Gravar Políticas do OCI IAM para essas Tags de Permissão
Para criar políticas, consulte o Exemplo 1 Etapa 4. Você terá que criar as políticas a seguir.
-
Política de Todos os Recursos:
Allow any-user to manage all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageall) Allow any-user to use all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useall) Allow any-user to read all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readall)
-
Política do Cloudguard:
Allow any-user to manage cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecspm) Allow any-user to use cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecspm) Allow any-user to read cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcspm)
-
Política de Rede:
Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork) Allow any-user to use virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useetwork) Allow any-user to read virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readnetwork)
-
Política de Logs:
Allow any-user to manage logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managelogs) Allow any-user to use logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.uselogs) Allow any-user to read logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readlogs)
-
Política de Appdev:
Allow any-user to manage instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageappdev) Allow any-user to use instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useappdev) Allow any-user to read instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readappdev)
-
Política de BD:
Allow any-user to manage database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managedb) Allow any-user to use database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usedb) Allow any-user to read database-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readdb)
-
Política de Armazenamento:
Allow any-user to manage object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageobject) Allow any-user to use object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useobject) Allow any-user to read object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readobject)
Exemplo 3: Estrutura de Compartimentos Corporativos Grandes
Etapa 1: Obtenha uma Compreensão Abrangente da Visão Geral de Negócios do Cliente
A CompanyC Solutions, uma organização multinacional especializada em soluções de software inovadoras, decidiu migrar suas cargas de trabalho de missão crítica para a OCI. A empresa opera em setores altamente regulamentados, como finanças e saúde, onde segurança, conformidade e escalabilidade são de extrema importância.
Etapa 2: Projetar Estrutura do Compartimento para a Carga de Trabalho
Vamos agora explorar a estrutura de compartimento para CompanyC, que segue o modelo de política do OCI IAM para dimensionar suas políticas do OCI IAM.
Etapa 3: Projetar as seguintes tags de permissão da combinação de tipo Verb+Resource
Para criar grupos, consulte o Exemplo 1 Etapa 3. Você precisa criar grupos para todas as tags de permissão a seguir.
-
Compartimento-Raiz - Governança Centralizada: O componente-raiz atua como a camada central para supervisionar todos os recursos e atividades na tenancy do OCI. Onde teremos nossos grupos de administradores marcados com tags de permissão. As seguintes etiquetas são:
- Administradores: permissão
manageall
para gerenciar o gerenciamento geral da tenancy. - UseAdministrators: Permissão
useall
para acessar recursos na tenancy. - Auditor: Permissão
readall
com acesso somente para leitura a recursos para monitoramento na tenancy.
- Administradores: permissão
-
Compartimento PROD: o compartimento para hospedar cargas de trabalho de produção de missão crítica que afetam diretamente as operações de negócios e os usuários finais. Cada aplicativo tem seu subcompartimento dedicado para isolamento de recursos e gerenciamento otimizado. Vamos definir as tags de permissão e os respectivos grupos do OCI IAM para ele.
- NetworkAdmin: Tag de permissão de recursos
managenetwork
para engenheiros que gerenciam recursos de Rede para CompanyC. - NetworkReader: Tag de permissão de recursos
readnetwork
para auditores que verificam a configuração de rede de CompanyC. - ComputeAdmin: Tag de permissão de recursos
managecompute
para administradores de sistema provisionando e dimensionando instâncias de computação para CompanyC. - ComputeReader: Tag de permissão de recursos
readcompute
para auditores que monitoram o uso de recursos de computação para CompanyC. - StorageReader: Permissão de recurso
manageobject
para que as equipes administrativas de armazenamento gerenciem configurações de armazenamento. - StorageReader: A permissão de recurso
readobject
para equipes de conformidade revisam configurações de armazenamento e padrões de uso. - SecurityAdmin: A permissão de recurso
managecspm
para o Compartment PROD, pois também tem foco na postura de segurança, com a capacidade de monitorar e remediar riscos de segurança.
Agora, vamos definir as tags de permissão e os respectivos grupos do OCI IAM para subcompartimentos específicos do aplicativo. No interesse do tempo, mesclamos e definimos permissões para todos os 3 compartimentos de aplicativos diferentes.
- Compartimentos do Aplicativo:
- PRApp1NetAdmin, PRApp2NetAdmin e PRApp3NetAdmin: Administre grupos do OCI IAM com a tag de permissão de recursos
managenetwork
para engenheiros que gerenciam recursos de Rede para App1, App2 e App3, respectivamente. - PRApp1NetUser, PRApp2NetUser e PRApp3NetUser: Administre grupos do OCI IAM com a tag de permissão de recursos
usenetwork
para engenheiros que gerenciam recursos de rede para App1, App2 e App3, respectivamente. - PRApp1ComputeAdmin, PRApp2ComputeAdmin e PRApp3ComputeAdmin: Administre grupos do OCI IAM com a tag de permissão de recursos
managecompute
para engenheiros que gerenciam instâncias do OCI Compute para App1, App2 e App3, respectivamente. - PRApp1ComputeUser, PRApp2ComputeUser e PRApp3ComputeUser: Administre grupos do OCI IAM com a tag de permissão de recursos
usecompute
para engenheiros que usam instâncias do OCI Compute para App1, App2 e App3, respectivamente. - PRApp1StorageAdmin, PRApp2StorageAdmin e PRApp3StorageAdmin: Administre grupos do OCI IAM com a tag de permissão de recursos
manageobject
para engenheiros que gerenciam o OCI Object Storage para App1, App2 e App3, respectivamente. - PRApp1StorageUser, PRApp2StorageUser e PRApp3StorageUser: Administre grupos do OCI IAM com a tag de permissão de recursos
useobject
para engenheiros que usam o OCI Object Storage para App1, App2 e App3, respectivamente.
- PRApp1NetAdmin, PRApp2NetAdmin e PRApp3NetAdmin: Administre grupos do OCI IAM com a tag de permissão de recursos
- NetworkAdmin: Tag de permissão de recursos
-
Compartimento NPROD: dedicado a ambientes de preparação, desenvolvimento e garantia de qualidade. Este compartimento é estruturado de forma semelhante ao PROD para garantir a consistência. Vamos definir as tags de permissão e os respectivos grupos do OCI IAM para ele.
- NetworkAdmin: Tag de permissão de recursos
managenetwork
para engenheiros que gerenciam recursos de rede para CompanyC. - NetworkReader: Tag de permissão de recursos
readnetwork
para auditores que verificam a configuração de rede de CompanyC. - ComputeAdmin: Tag de permissão de recursos
managecompute
para administradores de sistema provisionarem e dimensionarem instâncias do OCI Compute para CompanyC. - ComputeReader: Tag de permissão de recursos
readcompute
para auditores que monitoram o uso de recursos do OCI Compute para CompanyC. - StorageReader: Permissão de recurso
manageobject
para que as equipes administrativas de armazenamento gerenciem configurações de armazenamento. - StorageReader: A permissão de recurso
readStorage
para equipes de conformidade revisam configurações de armazenamento e padrões de uso. - SecurityAdmin: Permissão de recurso
managecspm
para o Compartimento NPROD, pois eles também têm foco na postura de segurança, com a capacidade de monitorar e remediar riscos de segurança.
Da mesma forma, agora vamos definir as tags de permissão e os respectivos grupos do OCI IAM para subcompartimentos específicos do aplicativo.
- Compartimentos do Aplicativo:
- NPApp1NetAdmin, NPApp2NetAdmin e NPApp3NetAdmin: Administre grupos do OCI IAM com a tag de permissão de recursos
managenetwork
para engenheiros que gerenciam recursos de rede para App1, App2 e App3, respectivamente. - NPApp1NetUser, NPApp2NetUser e NPApp3NetUser: Administre grupos do OCI IAM com a tag de permissão de recursos
usenetwork
para engenheiros que gerenciam recursos de rede para App1, App2 e App3, respectivamente. - NPApp1ComputeAdmin, NPApp2ComputeAdmin e NPApp3ComputeAdmin: Administre grupos do OCI IAM com a tag de permissão de recursos
managecompute
para engenheiros que gerenciam instâncias do OCI Compute para App1, App2 e App3, respectivamente. - NPApp1ComputeUser, NPApp2ComputeUser e NPApp3ComputeUser: Administre grupos do OCI IAM com a tag de permissão de recursos
usecompute
para engenheiros que usam instâncias do OCI Compute para App1, App2 e App3, respectivamente. - NPApp1StorageAdmin, NPApp2StorageAdmin e NPApp3StorageAdmin: Administre grupos do OCI IAM com a tag de permissão de recursos
manageobject
para engenheiros que gerenciam o OCI Object Storage para App1, App2 e App3, respectivamente. - NPApp1StorageUser, NPApp2StorageUser e NPApp3StorageUser: Administre grupos do OCI IAM com a tag de permissão de recursos
useobject
para engenheiros que usam o OCI Object Storage para App1, App2 e App3, respectivamente.
- NPApp1NetAdmin, NPApp2NetAdmin e NPApp3NetAdmin: Administre grupos do OCI IAM com a tag de permissão de recursos
- NetworkAdmin: Tag de permissão de recursos
-
Compartimento Compartilhado: O compartimento compartilhado hospeda recursos para monitoramento, como registro em log e serviços do OCI do Cloud Guard. Ele também tem chaves para criptografia e descriptografia que são utilizadas por vários tenants, garantindo a segregação lógica para manter a privacidade e a segurança. Todos os Administradores de seus Aplicativos que precisam de acesso a esses serviços serão adicionados aos grupos do OCI IAM criados para esses serviços. Vamos definir as tags de permissão e os respectivos Grupos do OCI IAM para ele.
-
Compartimentos do Oracle Cloud Guard:
cspmAdmin
: Administre grupos do OCI IAM com a tag de permissão de recursosmanagecspm
para administradores que gerenciam o Oracle Cloud Guard para compartimentos PROD e Não PROD.cspmUser
: Grupos do OCI IAM com tag de permissão de recursosusecspm
para engenheiros que usam/monitoram o Oracle Cloud Guard para compartimentos PROD e Non PROD.cspmReader
: Grupos do OCI IAM com tag de permissão de recursosreadcspm
para engenheiros que leem o Oracle Cloud Guard para compartimentos PROD e Não PROD.
-
Compartimentos do OCI Logging:
logsAdmin
: Administre grupos do OCI IAM com a tag de permissão de recursosmanagelogs
para administradores que gerenciam o OCI Logging para compartimentos PROD e Não PROD.logsUser
: Grupos do OCI IAM com tag de permissão de recursosuselogs
para engenheiros que usam/monitoram o OCI Logging para compartimentos PROD e Non PROD.logsReader
: Grupos do OCI IAM com tag de permissão de recursosreadlogs
para engenheiros que leem o OCI Logging para compartimentos PROD e Não PROD.
-
Compartimentos de Chaves:
kmsAdmin
: Administre grupos do OCI IAM com a tag de permissão de recursosmanagekeys
para administradores que gerenciam o cofre de chaves para compartimentos PROD e Não PROD.kmsUser
: Grupos do OCI IAM com tag de permissão de recursosusekeys
para engenheiros que usam/monitoram o cofre de chaves para compartimentos PROD e Não PROD.kmsReader
: Grupos do OCI IAM com tag de permissão de recursosreadkeys
para engenheiros que leem o vault de chaves para compartimentos PROD e Não PROD.
-
-
Compartimento do Playground: um ambiente flexível e isolado para experimentação, desenvolvimento e teste. Este compartimento não está vinculado a restrições de produção ou conformidade, tornando-o ideal para inovação. Aqui teremos apenas um grupo de administradores do OCI IAM para compartimento muito filho e concederemos os privilégios de gerenciamento a todos os recursos do OCI necessários para testar os requisitos.
-
Compartimentos de Desenvolvimento:
DevAdmin
: Administre grupos do OCI IAM com a permissão de recursosmanagenetwork
,managecompute
,manageobject
,managekeys
,managelogs
para administradores de Desenvolvimento para testar uma nova implementação no Compartimento de Desenvolvimento.
-
Testar Compartimentos:
TestAdmin
: Administre grupos do OCI IAM com a permissão de recursosmanagenetwork
,managecompute
,manageobject
,managekeys
,managelogs
para administradores de Desenvolvimento para testar uma nova implementação no Compartimento de Teste.
-
Compartimentos de Teste de Desempenho:
PerfTestAdmin
: Administre grupos do OCI IAM com a permissão de recursosmanagenetwork
,managecompute
,manageobject
,managekeys
,managelogs
para administradores de Desenvolvimento para testar uma nova implementação no Compartimento de Teste de Desempenho.
-
Etapa 4: Gravar Políticas do OCI IAM para essas Tags de Permissão
Para criar políticas, consulte o Exemplo 1 Etapa 4. Você precisa criar as políticas a seguir.
-
Política de Todos os Recursos:
Allow any-user to manage all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageall) Allow any-user to use all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useall) Allow any-user to read all-resources in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readall)
-
Política de Logs:
Allow any-user to manage logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managelogs) Allow any-user to use logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.uselogs) Allow any-user to read logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readlogs)
-
Política do Cloudguard:
Allow any-user to manage cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecspm) Allow any-user to use cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecspm) Allow any-user to read cloud-guard-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readcspm)
-
Política da Chave
Allow any-user to manage keys in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managekeys) Allow any-user to use keys in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usekeys) Allow any-user to read keys in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.readkeys)
-
Política do Aplicativo:
Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork) Allow any-user to use virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useetwork) Allow any-user to manage instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managecompute) Allow any-user to use instance-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.usecompute) Allow any-user to manage object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageobject) Allow any-user to use object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.useobject)
-
Política do campo de jogos:
Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork) Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managenetwork) Allow any-user to manage object-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.manageobject) Allow any-user to manage logging-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.mgmt.managelogs) Allow any-user to manage vaults in compartment Playground where request.principal.group.tag.infosec.gname=target.compartment.tag.mgmt.manageVaults Allow any-user to manage keys in compartment Playground where request.principal.group.tag.infosec.gname=target.compartment.tag.mgmt.manageKeys
Observação: para esse cenário toda vez que você integrar uma nova carga de trabalho:
- Verifique se você precisa de tags de permissão adicionais. Se você fizer isso, crie-os com políticas do OCI IAM para essas tags de permissão.
- Crie grupos para gerenciar o acesso ao novo compartimento de carga de trabalho.
- Marque o compartimento de carga de trabalho usando tags de permissão e os grupos criados.
Modelo de Permissão baseado em Tag para Controle de Acesso Granular
Até agora, todos os exemplos discutimos criar permissões de gerenciamento, usuário ou leitura para uma família de recursos. No entanto, a maioria dos clientes precisa de um controle de acesso granular para seguir o modelo de privilégio mínimo. O foco do tutorial é entender o modelo de política, e é por isso que falamos sobre um caso de uso simples. No entanto, deixe-me dar um exemplo de quatro pessoas de rede e como você pode projetar tags de permissão granulares e políticas do OCI IAM para essas quatro personas.
-
NetworkOwner: Esta pessoa ou equipe possui a implementação de rede da tenancy do OCI. Eles têm acesso para configurar FastConnect e permissão para gerenciar a rede de todos os aplicativos.
-
NetworkAdmin: Essa equipe possui a implementação de rede das equipes de aplicativos. Eles podem criar VCNs para equipes de aplicativos. No entanto, eles não têm acesso para configurar um firewall de rede ou FastConnect.
-
NetworkOperator: Esta equipe possui a rede do aplicativo. A equipe pode criar uma sub-rede de aplicativo na VCN do aplicativo ou em uma VCN compartilhada. No entanto, eles não têm permissão para gerenciar ou atualizar VCNs.
-
NetworkUser: Esta é a equipe de administração de aplicativos que requer permissão de uso nos recursos da rede de aplicativos.
Definiremos networkowner
, networkadmin
, networkoperator
e networkuser
como quatro tags no compartimento de rede. Para essas tags, designaremos nomes de grupo que tenham acesso ao compartimento de rede.
-
Política NetworkOwner:
Allow any-user to manage virtual-network-family in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkowner)
-
Política NetworkAdmin:
Allow any-user to manage vcns in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage subnets in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage route-tables in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage security-lists in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage network-security-groups in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage dhcp-options in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage local-peering-gateways in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage service-gateways in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin) Allow any-user to manage internet-gateways in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkadmin)
-
Política NetworkOperator:
Allow any-user to {VCN_ATTACH,VCN_DETACH} in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to inspect vcns in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to manage subnets in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to manage route-tables in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to manage security-lists in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to manage network-security-groups in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator) Allow any-user to manage dhcp-options in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkoperator)
-
Política NetworkUser:
Allow any-user to inspect vcns in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser) Allow any-user to use subnets in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser) Allow any-user to use vnics in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser) Allow any-user to use security-lists in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser) Allow any-user to use network-security-groups in tenancy where sets-intersect(request.groups.name,target.resource.compartment.tag.Net.networkuser)
Dimensionar políticas do OCI IAM para Controladores de Instâncias
Exemplo 1: Controle de Acesso de Instância Multitenant para Armazenamento Compartilhado e Segredos no OCI
Etapa 1: Obtenha uma Compreensão Abrangente da Visão Geral de Negócios do Cliente
XYZ Cloud Solutions é um provedor SaaS que oferece um Sistema de Gerenciamento de Documentos (DMS) hospedado na OCI. A plataforma atende a vários clientes corporativos, cada um exigindo isolamento rigoroso de seus dados enquanto aproveita uma infraestrutura compartilhada.
Requisitos do Cliente:
- Cada empresa (locatário) deve ter instâncias isoladas para processar e gerenciar documentos.
- Os segredos de cada tenant (chaves de API, credenciais de banco de dados) só devem estar acessíveis às instâncias desse tenant.
- Todos os tenants armazenam seus documentos em um compartimento centralizado do OCI Object Storage, mas eles só devem acessar seu próprio bucket.
- O sistema deve oferecer suporte ao dimensionamento automático e à integração fácil de novos locatários.
Etapa 2: Projetar Estrutura do Compartimento para a Carga de Trabalho
Vamos agora explorar a estrutura de compartimentos do XYZ Cloud Solutions, que segue o modelo de política do OCI IAM para dimensionar suas políticas do OCI IAM.
-
Isolamento de Tenant com Compartimentos:
- Crie um compartimento dedicado do OCI para cada cliente empresarial (Tenant1, Tenant2 etc.).
- Implante instâncias de computação (VMs, Funções ou Contêineres) dentro de seus respectivos compartimentos.
- Armazenamento centralizado com controle de acesso.
-
Mantenha um Compartimento de Armazenamento Compartilhado para Buckets do OCI Object Storage:
- Cada tenant obtém um bucket dedicado, marcado com
Enterprise.Tenant=<TenantName>
. - As políticas do OCI IAM garantem que as instâncias de cada tenant só possam ser lidas de seu próprio bucket.
- Gerenciamento de segredos com o OCI Vault.
- Cada tenant obtém um bucket dedicado, marcado com
-
Armazenar Credenciais do Banco de Dados, Chaves de API e Chaves de Criptografia no OCI Vault:
- Os segredos de cada tenant são marcados com
Enterprise.Tenant=<TenantName>
. - As políticas do OCI IAM permitem que apenas as instâncias desse tenant recuperem seus segredos.
- Estratégia de marcação empresarial para governança.
- Os segredos de cada tenant são marcados com
-
Defina um Namespace de Tag Empresarial com
Enterprise.Tenant
para rastrear a Propriedade do Tenant:- Aplique tags padrão de compartimento para marcar automaticamente os recursos no compartimento de cada tenant.
- Use políticas baseadas em tags para controle de acesso automatizado.
Etapa 3: Criar Grupos do OCI IAM
Para garantir o gerenciamento de acesso seguro e isolado em um ambiente multitenant do OCI, as seguintes políticas serão definidas para:
-
Grupo InfoSec: Administradores de segurança com acesso para gerenciar políticas, tags, usuários e grupos.
-
Grupo de Executores do Terraform: Grupo de execução de Infraestrutura como Código (IaC) para gerenciar recursos do OCI.
Observação: Esses grupos e políticas do OCI IAM já foram criados conforme descrito acima na seção Políticas Comuns do OCI IAM.
Etapa 4: Criar Políticas do OCI IAM para os Grupos Definidos
Políticas de Acesso a Recursos do Tenant: Para manter o isolamento de dados, os recursos do tenant só poderão acessar seus próprios segredos e armazenamento de objetos.
Allow any-user to use object-family in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant
Allow any-user to use secret-family in compartment Tenants where request.principal.compartment.tag.Enterprise.Tenant = target.resource.tag.Enterprise.Tenant
Se os princípios da instância do tenant também exigirem permissão para criar novos objetos, você poderá criar nomes de bucket com o mesmo nome que o nome do tenant e usar a tag de nome do tenant para comparar com o nome do bucket.
Allow any-user to manage objects in compartment Storage where request.principal.compartment.tag.Enterprise.Tenant = target.bucket.name
Exemplo 2: Controle de Acesso Detalhado para Acesso a Dados de Vários Serviços em um Modelo de Armazenamento Compartilhado do OCI
Etapa 1: Obtenha uma Compreensão Abrangente da Visão Geral de Negócios do Cliente
A XYZ Corp é uma empresa em rápido crescimento especializada em soluções de transformação digital. Com uma presença global, a XYZ Corp opera em várias regiões e aproveita a OCI para hospedar aplicações críticas, gerenciar dados e garantir a colaboração perfeita entre as equipes.
Requisitos do Cliente:
- Todas as instâncias do Serviço Admin para um tenant específico podem ler Buckets Admin no compartimento de armazenamento compartilhado.
- Todas as instâncias do Serviço de Vendas para um tenant específico podem ler Buckets de Vendas no compartimento de armazenamento compartilhado.
- Todas as instâncias do Serviço de Suprimento para um tenant específico podem ler Buckets de Suprimento no compartimento de armazenamento compartilhado.
- Todas as instâncias de um tenant específico podem ler Buckets do Shared Services no compartimento de armazenamento compartilhado.
- Todas as instâncias de um tenant específico podem ler Segredos desse tenant no compartimento do tenant.
Etapa 2: Projetar Estrutura do Compartimento para a Carga de Trabalho
Vamos agora explorar a estrutura de compartimentos da XYZ Corp, que segue o modelo de política do OCI IAM para dimensionar suas políticas do OCI IAM.
-
Criação de Compartimento Específico do Tenant:
- Crie um compartimento dedicado para cada tenant.
- Todos os recursos pertencentes a um tenant devem ser provisionados dentro do compartimento desse tenant.
-
Namespace de Tag da Empresa:
- Defina um Namespace de Tag Empresarial com as seguintes chaves de tag:
Enterprise.Tenant
Captura o nome do tenant.Enterprise.Service
Captura o tipo de serviço. Por exemplo, Admin, Vendas, Suprimento ou Compartilhado.
- Defina um Namespace de Tag Empresarial com as seguintes chaves de tag:
-
Tags Padrão para Compartimentos do Tenant:
- Configure Tags Padrão de Compartimento para cada compartimento de tenant, garantindo que a tag
Enterprise.Tenant
seja aplicada automaticamente a todos os recursos dentro do compartimento, capturando o nome do tenant.
- Configure Tags Padrão de Compartimento para cada compartimento de tenant, garantindo que a tag
-
Marcação no Nível do Recurso:
- Cada recurso em um compartimento de tenant deve ser marcado com a tag
Enterprise.Service
especifica o tipo de serviço. Por exemplo, Admin, Vendas, Suprimento etc.
- Cada recurso em um compartimento de tenant deve ser marcado com a tag
-
Marcação de Recursos de Destino (Buckets e Segredos):
- Marque cada recurso de destino (como buckets e segredos) com:
Enterprise.Tenant
Captura o nome do tenant.Enterprise.Service
Captura o tipo de serviço associado.
- Marque cada recurso de destino (como buckets e segredos) com:
-
Marcando com Tag Buckets Compartilhados:
- Para recursos de bucket compartilhado, defina
Enterprise.Service = 'Shared'
para indicar a acessibilidade entre serviços.
- Para recursos de bucket compartilhado, defina
Etapa 3: Criar Grupos do OCI IAM
Para garantir o gerenciamento de acesso seguro e isolado em um ambiente multitenant do OCI, as seguintes políticas serão definidas para:
-
Grupo InfoSec: Administradores de segurança com acesso para gerenciar políticas, tags, usuários e grupos.
-
Grupo de Executores do Terraform: Grupo de execução de Infraestrutura como Código (IaC) para gerenciar recursos do OCI.
-
Grupo dinâmico AdminInstances: Com a regra de correspondência
All {tag.Enterprise.Service.value=’Admin’}
. -
Grupo dinâmico SalesInstances: Com a regra de correspondência
All {tag.Enterprise.Service.value=’Sales’}
. -
Grupo dinâmico SupplyInstances: Com a regra de correspondência
All {tag.Enterprise.Service.value=’Supply’}
.
Observação: Os grupos InfoSec e Terraform-Runner e as políticas do IAM já foram criados conforme descrito acima na seção Políticas Comuns do OCI IAM.
Etapa 4: Criar Políticas do OCI IAM para os Grupos Definidos
Políticas de Acesso a Recursos do Tenant: Para manter o isolamento de dados, os recursos do tenant só poderão acessar seus próprios segredos e armazenamento de objetos.
Allow dynamic-group AdminInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}
Allow dynamic-group SalesInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}
Allow dynamic-group SupplyInstances to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}
Allow any-user to use object-family in compartment Storage where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Shared’}
Allow dynamic-group AdminInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Admin’}
Allow dynamic-group SalesInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Sales’}
Allow dynamic-group SupplyInstances to use secret-family in compartment Tenants where all {request.principal.compartment.tag.Enterprise.Tenant=target.resource.tag.Enterprise.Tenant, target.resource.tag.Enterprise.Service=’Supply’}
Links Relacionados
Confirmações
-
Autor - Chetan Soni (Engenheiro Sênior de Nuvem)
-
Colaborador - Kiran Thakkar (Arquiteto Principal de Nuvem)
Mais Recursos de Aprendizagem
Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal Oracle Learning YouTube. Além disso, visite education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.
Para obter a documentação do produto, visite o Oracle Help Center.
Deep Dive into Tag based Oracle Cloud Infrastructure Identity and Access Management Policies
G30370-01
Copyright ©2025, Oracle and/or its affiliates.