Observação:

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

Pré-requisitos

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

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.

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:

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

  1. 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'
    
  2. 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'
    
  3. 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.

  4. 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.

  5. 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.

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.

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.

  1. 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.

    Tags de Permissão

  2. 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.

    Grupos de Tags de Permissão

  3. 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.

    Políticas de Tag de Permissão

  4. À 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.

Caso de Uso 1

Observação: Somente administradores devem ser capazes de gerenciar o namespace de tag mgmt e infosec.

Etapa 3: Projetar as seguintes tags de permissão da combinação de tipo Verb+Resource

Criar grupos no OCI.

  1. Faça log-in no domínio do OCI IAM com uma conta Admin que tenha o privilégio de criar grupos.

    Home do OCI

  2. Vá para Identidade e Segurança e clique em Domínios em Identidade.

    Domínios

  3. Selecione seu compartimento e clique no domínio para o qual deseja criar os grupos.

    Selecionar Domínios

  4. Clique em Grupos.

    Grupos

  5. Defina seus Grupos com base nas tags de permissão. (Opcionalmente) adicione seus usuários a esses grupos.

    Criar 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.

  1. 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.
  2. 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.
      • 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.
      • 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.
    • 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.
      • 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.
      • 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.

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.

  1. Faça log-in no domínio do OCI IAM com uma conta Admin que tenha o privilégio de criar políticas.

    Home do OCI

  2. Vá para Identidade e Segurança e clique em Políticas em Identidade.

    Políticas

  3. Selecione o Compartimento raiz e clique em Criar Política.

    Criar Políticas

  4. 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)
      

      Instruções da Política

      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.

Caso de Uso 2

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.

  1. 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.
  2. 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.
  3. 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 recurso manageappdev para a equipe de desenvolvimento do Tenant 1 tem privilégios administrativos para configurar e implantar aplicativos personalizados.
      • t1devuser: Permissão de recurso useappdev para monitorar e ajustar recursos do aplicativo. Os desenvolvedores do tenant 1 usam esses recursos para desenvolvimento e teste diários.
      • t1logsadmin e t1devuser: A permissão de recurso managelogs e uselogs 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 e t1devuser: Permissão de recursos managecspm e usecspm 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 and t3logsadmin 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 recurso managedb 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 recurso usedb para usuários específicos do Tenant acessam seus respectivos esquemas ou serviços de banco de dados.
        • dbreader: A permissão de recurso readdb 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 recurso manageobject 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 recurso readobject para equipes de conformidade revisam configurações de armazenamento e padrões de uso.

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.

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.

Caso de Uso 3

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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 recursos managecspm 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 recursos usecspm 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 recursos readcspm 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 recursos managelogs 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 recursos uselogs 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 recursos readlogs 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 recursos managekeys 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 recursos usekeys 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 recursos readkeys para engenheiros que leem o vault de chaves para compartimentos PROD e Não PROD.
  5. 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 recursos managenetwork, 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 recursos managenetwork, 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 recursos managenetwork, 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.

Observação: para esse cenário toda vez que você integrar uma nova carga de trabalho:

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.

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.

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:

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.

Caso de Uso da Instância 1

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:

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:

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.

Caso de Uso da Instância 2

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:

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’}

Confirmações

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.