Perguntas Frequentes sobre Gerenciamento de Identidade e Acesso

Tópicos de perguntas frequentes

Geral

O que é o OCI IAM (Oracle Cloud Infrastructure Identity and Access Management)?

O OCI IAM é um serviço nativo da OCI que fornece recursos de gerenciamento de identidade e acesso de classe empresarial, como autenticação forte e adaptável, LCM (Lifecycle Management, Gerenciamento do ciclo de vida) do usuário e SSO (Single Sign-On, Logon único) para aplicações empresariais. O OCI IAM é implementado como domínio(s) de identidades na OCI. Os domínios incluídos permitem que as organizações gerenciem o acesso aos serviços da Oracle Cloud (rede, computação, armazenamento etc.) e às aplicações Oracle SaaS. Os clientes podem optar por fazer upgrade ou criar domínios de identidade adicionais para acomodar outros casos de uso, como gerenciar o acesso da força de trabalho a aplicações não Oracle, permitir o acesso do consumidor a aplicações voltadas para o cliente ou incorporar o IAM em aplicações personalizadas.

O que são domínios de identidade?

Cada domínio de identidade do OCI IAM é uma solução de gerenciamento de identidade e acesso independente que pode ser usada para tratar uma variedade de casos de uso do IAM. Por exemplo, você pode usar um domínio de identidade do OCI IAM para gerenciar o acesso de funcionários em várias aplicações na nuvem e on-premises, permitindo autenticação segura, gerenciamento fácil de direitos e SSO integrado para usuários finais. Você também pode querer oferecer um domínio de identidades para permitir o acesso a sistemas de cadeia de suprimento ou de pedidos para parceiros de negócios. Você também pode usar domínios de identidades para ativar o IAM para aplicações voltadas ao consumidor e permitir que os usuários façam autorregistro, logon social e/ou consentimento de termos de uso. Os domínios de identidade representam uma solução abrangente de identidade como serviço (IDaaS) que acomoda vários casos de uso e cenários do IAM.

Que tipo de domínio de identidades devo escolher?

  • Domínios de identidade gratuitos: Cada tenancy da OCI inclui um domínio de identidades do OCI IAM padrão de modo gratuito para gerenciar o acesso aos recursos da OCI (rede, computação, armazenamento etc.). Se você estiver apenas procurando gerenciar o acesso aos recursos da OCI, poderá usar o domínio padrão incluído. Ele oferece um conjunto robusto de funcionalidades do IAM para gerenciar o acesso aos recursos da Oracle Cloud. Dependendo do modelo de segurança e da equipe, os clientes podem optar por reservar esse domínio para Administradores da OCI.
  • Domínios de identidade do Oracle Apps: Várias aplicações da Oracle Cloud (HCM, CRM, ERP, aplicações do setor etc.) podem incluir o uso do OCI IAM por meio de um domínio do Oracle Apps. Esses domínios estão incluídos para uso com aplicações Oracle assinadas e oferecem uma funcionalidade robusta de IAM para gerenciar o acesso à Oracle Cloud e aos serviços SaaS. Os clientes podem optar por adicionar todos os funcionários a esse domínio para ativar o SSO a um serviço de aplicação da Oracle Cloud e podem usar esse domínio para gerenciar o acesso a alguns ou a todos os seus recursos da OCI.
  • Domínios de identidade do Oracle Apps Premium: se você quiser estender um domínio do Oracle Apps com recursos empresariais completos para gerenciar o acesso de aplicações Oracle que podem não ser fornecidas pelo SaaS (por exemplo, Oracle E-Business Suite ou Oracle Databases, on-premises ou hospedados na OCI), os domínios do Oracle Apps Premium oferecem o conjunto completo de recursos e funcionalidades do OCI IAM para uso com destinos Oracle que podem ser implementados em ambientes de nuvem híbrida. Este é um serviço de baixo custo que tem todos os recursos, mas é limitado ao uso com os destinos da Oracle.
  • Domínios de identidade externos: Os domínios de identidade externos oferecem um conjunto completo de recursos e funcionalidades do OCI IAM para não funcionários, como consumidores que acessam um site de varejo, governos que permitem acesso para cidadãos ou empresas que permitem acesso a parceiros de negócios. Não há restrições sobre quais aplicações podem ser direcionadas. No entanto, determinados recursos empresariais que geralmente não são úteis em cenários de não funcionários, como o Gateway de Aplicação e a Ponte de Provisionamento, não estão incluídos. Os domínios externos incluem suporte para logon social, autorregistro, consentimento de termos de uso e gerenciamento de perfil/senha.
  • Domínios de identidade premium: Os domínios de identidade premium oferecem o conjunto completo de recursos e funcionalidades do OCI IAM sem restrições sobre quais aplicações podem ser direcionadas. Os domínios Premium podem ser usados como um serviço de IAM empresarial que gerencia o acesso de funcionários ou da força de trabalho em aplicações on-premises e na nuvem, permitindo autenticação segura, gerenciamento fácil de direitos e SSO integrado para usuários finais.

Posso misturar funcionários e não funcionários em um único domínio de identidades?

Não. O OCI IAM os considera como populações de usuários separadas para fins de licenciamento. No entanto, você pode usar o mesmo serviço OCI IAM para gerenciar dois ou mais domínios que podem acomodar funcionários e não funcionários (parceiros, afiliados, consumidores etc.). Vários domínios podem ser usados para acessar as mesmas aplicações, mas as regras e as políticas de segurança para não funcionários geralmente diferem das aplicadas aos funcionários. Cada domínio tem seu próprio conjunto de definições, configurações e políticas de segurança que são exclusivas para essa população de usuários. Isso é por design para acomodar os requisitos amplamente variados que são típicos de diferentes populações de usuários.

Quem tem acesso a um domínio de identidades?

Cada tenancy da OCI inclui um grupo Administradores que fornece acesso total a todos os recursos da OCI. É importante entender que todos os membros do grupo Administradores da OCI têm acesso total para gerenciar domínios de identidade do OCI IAM. A Oracle recomenda o uso cuidadoso deste grupo. Privilégios administrativos podem ser concedidos em cada domínio por meio de Funções de Administrador que permitem a separação de tarefas entre grupos de pessoas. Consulte Noções Básicas sobre Atribuições de Administrador para obter mais detalhes.

O OCI IAM fornece alta disponibilidade e/ou recuperação de desastres?

Dentro de cada região da OCI, há vários Domínios de Disponibilidade (ADs) ou Domínios de Falha (FD) (em regiões de AD único). Os ADs e FDs têm funções semelhantes, mas os FDs estão fisicamente mais próximos que os ADs. Os domínios de identidades são implementados com instalações redundantes em cada região (duas nos AD/FDs) que oferecem alta disponibilidade. Os domínios de identidade do OCI IAM também oferecem recuperação de desastres (DR) entre regiões por meio de uma abordagem ativa-passiva, aproveitando a replicação de dados de alto desempenho. Isso fornece recuperação de dados confiável para domínios de identidade no caso improvável de toda uma região da OCI ficar indisponível. Esse DR é entregue por meio de um único URL que o torna transparente para as aplicações.

Quais são os principais termos e conceitos do Oracle Identity and Access Management?

Os principais conceitos de IAM são:

  • Conta ou Tenancy - Quando você se inscreve na OCI, a Oracle cria uma tenancy para a sua empresa, que é uma partição isolada dentro da OCI onde você pode criar, organizar e administrar seus recursos de nuvem. Às vezes, isso é chamado de conta da OCI.
  • Compartimento - Um contêiner lógico dentro de uma conta da OCI para recursos da Oracle Cloud. Os administradores podem criar um ou mais compartimentos em uma conta da OCI para organizar e gerenciar recursos. Por exemplo, os compartimentos podem ser usados para impor a Separação de Responsabilidades entre diferentes tipos de administradores (rede, computação, armazenamento etc.)
  • Compartimento raiz - O compartimento de nível superior dentro de uma conta da OCI. O compartimento raiz é criado automaticamente para você quando sua conta é provisionada.
  • Domínios de identidade - Um domínio de identidade representa um preenchimento de usuário na OCI e configurações e definições de segurança associadas. Cada conta inclui um domínio de identidades padrão que permite aos clientes gerenciar o acesso aos recursos da OCI. Os clientes podem optar por criar domínios de identidade adicionais com base em suas necessidades específicas. Os domínios de identidade são criados dentro de um compartimento e o acesso para gerenciar domínios está vinculado a permissões de compartimento. As políticas de acesso da OCI podem ser gravadas para permitir que os usuários de um determinado compartimento/domínio acessem recursos em outros compartimentos.
  • Usuário - Uma entidade que pode ser autenticada. Um usuário pode ser uma conta pessoal ou de máquina. Cada usuário tem um nome exclusivo em sua conta e um identificador globalmente exclusivo. Os usuários podem receber senhas para acessar o console da web e chaves para acessar os serviços por meio de APIs.
  • Grupo - Um conjunto de usuários. Grupos são usados para simplificar o gerenciamento de acesso. Por exemplo, os desenvolvedores de software podem ser agrupados como membros de um grupo de "desenvolvedores", o que lhes permite ler, escrever e/ou modificar o código. Um único usuário pode ser membro de vários grupos.
  • Política - Um documento que especifica quem pode acessar quais recursos da OCI e quais privilégios eles têm. Uma política é composta por declarações de política que aproveitam a sintaxe da linguagem natural.

O que há de exclusivo em relação à abordagem da Oracle Cloud Infrastructure para o Identity and Access Management?

Com o OCI IAM, você pode aproveitar um único modelo de autenticação e autorização em todos os serviços da Oracle Cloud e do Cloud Application. O OCI IAM ajuda a gerenciar o acesso a organizações de todos os tamanhos, de uma pessoa trabalhando em um único projeto a grandes empresas com muitos grupos trabalhando em vários projetos ao mesmo tempo, tudo em uma única conta. O gerenciamento e a autorização de recursos podem ocorrer no nível da conta ou no compartimento, enquanto ainda permitem a auditoria e o faturamento centrais. O OCI IAM foi criado do zero para permitir que você aplique o princípio de segurança de privilégio mínimo; por padrão, novos usuários não podem executar nenhuma ação em nenhum recurso. Os administradores podem conceder a cada usuário apenas o acesso apropriado para esse usuário específico.

Além de gerenciar recursos da OCI, o OCI IAM coloca uma solução de classe empresarial IDaaS ao alcance dos seus dedos. Com o clique de um botão, você pode implementar uma solução robusta de IAM que possa ser usada para atender a muitos requisitos de IAM nos casos de uso de funcionários/forças de trabalho, parceiros ou consumidores.

Como a Oracle Cloud Infrastructure suporta autenticação multifator?

O OCI IAM fornece amplo suporte para autenticação multifator (MFA) que inclui uma aplicação MFA móvel que oferece opções para envio ou senha única, suporte para autenticadores FIDO2 e suporte para SMS, e-mail, chamada telefônica e muito mais. O OCI IAM também inclui segurança adaptável sensível ao contexto que reduz o risco sem introduzir obstáculos à experiência do usuário final. A Segurança Adaptável avalia o dispositivo, a rede, o local e o comportamento anterior do usuário para criar uma pontuação de risco para a sessão dele. Os administradores podem configurar políticas de MFA que podem diferir para aplicações específicas ou para grupos de usuários específicos.

As alterações nos usuários, grupos, compartimentos e políticas são registradas para fins de depuração e auditoria?

Sim. Para dar suporte aos requisitos corporativos de auditoria e conformidade, todas as alterações são registradas e esses registros podem ser disponibilizados a você sem nenhum custo adicional.

Como começo a usar o OCI IAM?

O OCI IAM é ativado por padrão sem custo adicional. O primeiro usuário da sua conta é o Administrador padrão. Todos os usuários subsequentes são criados por meio do serviço IAM, onde você concede explicitamente privilégios para interagir com recursos de nuvem especificados.

Você pode acessar o Oracle IAM usando o Console, API Rest ou SDKs.

Como usuário da Oracle Cloud Infrastructure, como redefinir minha senha?

Para redefinir sua senha para a Oracle Cloud Infrastructure, primeiro verifique se você associou um endereço de email à sua conta. Visite a página de perfil do usuário da sua conta Oracle Cloud Infrastructure e adicione um endereço de email ao qual somente você tenha acesso. Você receberá um email para confirmar que pretendia registrar esse endereço na sua conta. Em seguida, você pode redefinir sua senha com sua conta de email, a menos que tenha sido desativada pelo administrador do inquilino.

Compartimentos

Quais problemas os compartimentos são projetados para resolver?

Um compartimento é um contêiner lógico seguro em sua conta usado para hospedar seus recursos de infraestrutura (como computação, armazenamento e rede), juntamente com um conjunto de políticas de gerenciamento de acesso para esses recursos. Compartimentos permitem organizar logicamente seus recursos de nuvem para suportar uma ampla variedade de casos de uso.

A seguir, são apresentadas algumas maneiras comuns de usar compartimentos para:

  • Separar seus ambientes de desenvolvimento de software para administração simples. Por exemplo, você pode ter compartimentos separados para desenvolvimento, teste e produção; ou, você pode ter compartimentos separados para oferecer suporte à implementação azul/verde.
  • Simplifique o gerenciamento de permissões. Por exemplo, você pode criar um compartimento separado para seus recursos de rede (VCNs, sub-redes, gateways da Internet etc.) e permitir que apenas os administradores de rede acessem esse compartimento.
  • Avalie separadamente o uso de unidades de negócios distintas para cobrar adequadamente essas unidades de negócios pelo consumo de recursos na nuvem.
  • Minimize o conjunto de recursos visíveis para determinados conjuntos de usuários. Por exemplo, convém ter um compartimento separado para sua equipe de Finanças que seja visível apenas para determinados funcionários.

Os compartimentos podem conter recursos em vários Domínios de Disponibilidade?

Sim. Compartimentos são agrupamentos lógicos de recursos distintos das construções físicas dos Domínios de Disponibilidade. Um compartimento individual pode conter recursos nos Domínios de Disponibilidade.

Como os compartimentos são usados para controle de acesso?

Todas as políticas são anexadas ao compartimento raiz ou a um compartimento filho. Cada política consiste em uma ou mais instruções de política que seguem esta sintaxe básica:

Permita grupo no compartimento

As declarações de política permitem usar compartimentos para simplificar o gerenciamento de permissões; por exemplo, você pode escrever uma política que permita ao grupo HRAdministrators gerenciar todos os recursos no compartimento HRCompartment.

Posso excluir compartimentos?

Sim, você pode excluir compartimentos.

Posso mover árvores inteiras de compartimento e os recursos incluídos?

Sim, você pode mover árvores de compartimento inteiras e seus recursos incluídos para outros compartimentos principais.

Posso mover recursos, como uma instância de computação ou bloquear um volume, de um compartimento para outro?

Sim, você pode mover recursos de um compartimento para outro.

Posso criar uma hierarquia de compartimentos?

Sim, você pode criar uma hierarquia de compartimentos aninhando-os. Com compartimentos hierárquicos ou aninhados, o administrador do sistema pode organizar recursos e permitir que os administradores de nível inferior façam o mesmo, mantendo a visibilidade e o controle completos via política.

Quantos níveis de profundidade você pode aninhar compartimentos?

A profundidade máxima de um compartimento aninhado é seis.

As políticas em um compartimento de nível superior se aplicam a um subcompartimento?

Sim, políticas em compartimentos de nível superior são herdadas por subcompartimentos.

Posso rastrear custos e uso por compartimentos?

Sim, você pode acompanhar os custos e o uso pelos compartimentos em Meus Serviços.

O que é compartimento raiz?

Para cada conta, a Oracle Cloud Infrastructure cria automaticamente um compartimento de nível superior conhecido como compartimento raiz. Muito parecido com a pasta raiz em um sistema de arquivos, o compartimento raiz se comporta exatamente como seus compartimentos filhos, exceto por algumas características especiais:

  • Como as permissões são hierárquicas, as permissões de grupo no compartimento raiz serão aplicadas a todos os compartimentos filhos. Por exemplo, se o grupo NetworkAdmins tiver permissão para gerenciar redes virtuais na nuvem (VCN - Virtual Cloud Networks) no compartimento raiz, esse grupo poderá gerenciar VCNs em todos os compartimentos.
  • Atualmente, todos os usuários e grupos são criados dentro do compartimento raiz. As políticas podem ser usadas para conceder acesso apenas a compartimentos específicos para crianças.

Observação: Atualmente, você pode criar compartimentos adicionais apenas no compartimento raiz e não em outros compartimentos.

Quando devo criar recursos no compartimento raiz e quando devo criá-los em um compartimento filho?

Geralmente, os recursos devem ser criados em um compartimento que não seja o compartimento raiz. É melhor projetar sua hierarquia de compartimentos antes de começar a criar compartimentos e recursos.

Usuários

O que um usuário do console da Oracle Cloud Infrastructure pode fazer?

Um usuário é alguém que pode se autenticar com êxito no Oracle IAM e que possui privilégios suficientes para consumir ou gerenciar recursos de nuvem em sua conta. Os administradores podem criar um ou mais usuários em sua conta e atribuí-los a grupos para conceder permissões a recursos em compartimentos específicos.

Quem é capaz de criar e gerenciar usuários?

Sua conta é provisionada com um só usuário: o administrador padrão, e um só grupo: Administradores, do qual o usuário administrador padrão é membro. Este grupo (Administradores) tem acesso total à sua conta. Esse usuário especial (administrador padrão) deve criar usuários adicionais ou conceder permissão a outros usuários para gerar novos usuários.

Qual tipo de acesso um novo usuário tem na criação?

Por padrão, um novo usuário não tem permissão para usar nenhum recurso ou serviço em sua conta - todas as permissões devem ser concedidas explicitamente. Essa abordagem permite aderir ao princípio de segurança de menor privilégio, no qual você concede a cada usuário apenas o acesso necessário para esse usuário específico. Você deve adicionar explicitamente o usuário a um grupo existente ou criar outro grupo para eles e atribuir permissões apropriadas a esse grupo por meio de uma política.

Posso ativar e desativar o acesso do usuário?

Os administradores podem desativar ou bloquear um usuário para desativar seu acesso temporariamente. Eles também podem redefinir senhas de usuário ou remover chaves.

Podemos definir senhas para expirar? Como posso alternar credenciais?

Sim, as políticas de senha permitem que você defina um tempo de expiração para as senhas. Você também pode automatizar redefinições de senha, alterações de chave ou edições em associações de usuários e grupos por meio da API REST e SDKs.

Políticas

O que é uma política?

Uma política é um documento que consiste em instruções de política descritivas que concedem permissões específicas a grupos de usuários. Elas são escritas com uma sintaxe fácil de entender, semelhante ao SQL. Políticas de exemplo podem aplicar:

  • Os Administradores de Sistemas podem "encerrar" ou "reiniciar" suas instâncias de computação bare metal.
  • Os Administradores de Rede podem administrar totalmente todos os recursos de infraestrutura relacionados à rede.
  • Os administradores de TI podem criar usuários e editar associações de grupos

Uma política permite que um grupo trabalhe de determinadas maneiras com tipos específicos de recursos em um compartimento específico. Opcionalmente, as políticas podem conter uma cláusula condicional ("onde...") que restringe ainda mais a declaração da política. As políticas seguem a seguinte sintaxe:

Permitir grupo no compartimento [onde]

Por exemplo, aqui está uma declaração de política que concede permissões para usar instâncias de computação:

Permitir que os Desenvolvedores do grupo usem instâncias no compartimento ProjectA

  • "group_name" é o nome do grupo ao qual estão sendo concedidas permissões.
  • "verbs" são ações que você pode executar em recursos, por exemplo: inspeção, leitura, uso ou gerenciamento.
  • "resource-type" é o recurso de nuvem ao qual as permissões estão sendo concedidas. Exemplo de tipos de recursos incluem: instâncias, volumes e tabelas de roteamento.
  • "compartment_name" é o nome do compartimento no qual os recursos estão organizados.
  • "condições" são especificações adicionais que restringem o escopo da declaração de política. Exemplos incluem: "where request.user.id=target.user.id" ou "where target.group_name != Administrators".

Para mais detalhes, consulte a seção OCI IAM da documentação da Oracle Cloud Infrastructure.

As políticas para o compartimento raiz são herdadas pelos compartimentos para crianças?

Sim. Uma política que concede permissões no compartimento raiz concede automaticamente as mesmas permissões para todos os compartimentos filhos. Por exemplo, a política a seguir concede permissão a todos os usuários do grupo "InstanceAdmins" para gerenciar instâncias no compartimento raiz e em todos os compartimentos filhos:

Permitir que os Group InstanceAdmins gerenciem instâncias na locação

As políticas podem ser limitadas a compartimentos específicos?

Sim. Cada política é "anexada" a um compartimento. Onde você o anexa, controla quem pode modificá-lo ou excluí-lo. Se você anexar uma política ao compartimento raiz, qualquer pessoa com acesso para gerenciar políticas no compartimento raiz poderá alterá-la ou excluí-la. Se você anexar a política ao compartimento, qualquer pessoa com acesso para gerenciar políticas nesse compartimento poderá alterá-la ou excluí-la. Em termos práticos, isso significa que é fácil conceder aos administradores do compartimento (ou seja, um grupo com acesso para "gerenciar todos os recursos" no compartimento) o acesso para gerenciar as políticas de seu próprio compartimento, sem fornecer a eles acesso mais amplo para gerenciar as políticas que residem na conta.

Onde posso aprender mais sobre como escrever declarações de política?

Para mais informações sobre políticas e declarações de políticas, consulte "Getting Started with Policies" and "Common Policies" (Introdução às Políticas e Políticas Comuns) na documentação da Oracle Cloud Infrastructure.

Política de negação do IAM

Perguntas frequentes sobre a política de negação do OCI Identity and Access Management

Essas perguntas frequentes orientam os usuários sobre as políticas de negação da Oracle Cloud Infrastructure (OCI Identity and Access Management), que permitem que os usuários que podem gerenciar políticas bloqueiem ações explicitamente, aprimorando a segurança e simplificando o controle de acesso em ambientes da OCI. Para saber mais, consulte a documentação do OCI Identity and Access Management.

Conceitos básicos do IAM Deny

Como eu ativo o recurso IAM Deny na OCI?

O IAM Deny é um recurso opcional que deve ser habilitado explicitamente por um administrador de tenancy acessando o OCI Console, em Policies (Políticas), Actions (Ações) e Policy settings (Configurações de políticas). Não pode ser habilitado por usuários comuns ou autores de políticas. Após ser habilitado, o recurso se torna parte permanente da estrutura do IAM do tenancy e não pode ser desabilitado pela interface do usuário. No entanto, um administrador de tenancy com a capacidade de escrever políticas de negação pode controlar efetivamente o uso dessas políticas, escrevendo uma política de negação de nível raiz que impede todos os usuários de criar ou modificar políticas de negação, exceto o grupo de administradores padrão. Um exemplo é Deny any-user para gerenciar políticas em uma tenancy onde target.policy.type='DENY'

Quando o IAM Deny está ativado

  • A OCI insere automaticamente uma política de negação padrão no compartimento raiz para uso seguro.
  • Somente o grupo de administradores padrão e o administrador da tenancy que ativou o IAM Deny mantêm permissões para configurar e gerenciar as políticas de negação.
  • O administrador da tenancy pode atualizar a política de negação padrão para permitir que usuários autorizados, como grupos de administradores nos compartimentos Banking, Investments e Compliance, gravem políticas de negação no OCI Console.

O que são declarações de negação do OCI Identity and Access Management?

Com as declarações de negação do OCI Identity and Access Management, é possível escrever políticas de negação explícitas para bloquear ações específicas em tenancies da OCI, complementando as declarações de permissão do OCI Identity and Access Management para um controle de acesso preciso. Por exemplo, você pode usar Deny any-user para inspecionar todos os recursos em um tenancy onde request.service='streaming' para definir uma proteção que impeça todo o acesso ao serviço OCI Streaming na tenancy, ao mesmo tempo que concede outras permissões por meio de instruções de permissão.

Quais são os limites para as políticas de negação do IAM?

As políticas de negação do IAM compartilham os mesmos limites que as políticas de permissão. Uma tenancy pode ter até 100 objetos de política IAM, cada um contendo até 50 declarações de política (negar ou permitir), mas o número total de declarações de política em todos os objetos da tenancy é limitado a 100.

Quais metaverbos são compatíveis com as políticas de negação do IAM e eles são novos ou já existentes?

As políticas de negação do IAM usam os metaverbos existentes: gerenciar, usar, ler e inspecionar. Não são introduzidos novos metaverbos. Ao contrário das instruções de permissão, que concedem permissões de forma aditiva (por exemplo, "gerenciar" inclui todas as permissões de nível inferior), as instruções de negação são subtrativas, bloqueando apenas as permissões especificadas e qualquer nível superior na hierarquia.

Por exemplo, a política Deny group DevOps para gerenciar instâncias no compartimento Prod bloqueia apenas a permissão de gerenciamento, permitindo que a equipe de DevOps execute ações de uso, leitura e inspeção. No entanto, negar a inspeção bloqueia todas as permissões, pois é a permissão de nível básico.

Criação e gerenciamento de políticas

Onde posso configurar as políticas de negação na OCI Console?

As políticas de negação são criadas na mesma interface do OCI Console que as políticas de permissão. Navegue até Identity & Security (Identidade e Segurança) e, em seguida, Policies (Políticas), selecione um compartimento e use o editor de políticas para adicionar a palavra-chave de negação ao lado do permitido. O processo não requer interface separada.

Existe um objeto de política separado para políticas de negação?

Não, as políticas de negação usam o mesmo objeto de política que as políticas de permissão. Ambas são gerenciadas dentro do mesmo objeto de política, simplificando a administração.

Posso incluir declarações de negação e permissão em um único objeto de política do IAM?

Sim, você pode combinar declarações de negação e permissão em um único objeto de política para obter um controle de acesso flexível.

Por exemplo, uma única política pode incluir instruções de permissão e negação conforme mostrado abaixo:

Negar ao grupo Estagiários o acesso à instância no compartimento Finanças
Permitir que o grupo Administradores gerencie todos os recursos no compartimento Finanças

Essas políticas permitem que os administradores gerenciem todos os recursos no compartimento de Finanças, ao mesmo tempo que impedem que os estagiários realizem qualquer operação de gravação nas instâncias, simplificando o controle de acesso.

Como posso impedir que usuários com permissão para gerenciar políticas criem políticas de negação?

Para impedir que usuários com permissão para gerenciar políticas criem políticas de negação, crie uma política de negação no nível raiz para bloquear a criação de políticas de negação.

Exemplo: Deny group PolicyAdmins para gerenciar políticas na tenancy em que target.policy.type='DENY'

Esta política garante que os administradores de políticas não possam criar ou modificar políticas de negação, mas ainda assim possam gerenciar políticas de permissão. Os grupos de administradores padrão permanecem isentos e podem criar políticas de negação, se necessário.

Como posso bloquear um serviço da OCI por completo usando uma política de negação do IAM?

Para bloquear um serviço do OCI inteiro, crie uma política de negação no compartimento raiz visando os recursos ou ações do serviço usando uma condição como request.service.name.

Por exemplo, para bloquear o serviço OCI Streaming em toda a tenancy

Deny any-user para inspecionar todos os recursos na tenancy em que request.service.name='streaming'

Essa política impede todo o acesso ao serviço OCI Streaming, o que é útil para conformidade em setores como o da saúde. Coloque a política no compartimento raiz para garantir que ela se aplique a todos os compartimentos, reduzindo a expansão da política.

Como posso impedir que um grupo gerencie recursos em uma região específica?

Para impedir que um grupo gerencie recursos em uma região específica, use uma política de negação com um request.region condition.

Por exemplo, se quiser impedir que um grupo execute qualquer ação além do acesso somente leitura em uma região específica, você pode criar uma política de negação como esta:

Deny group RegionalAdmins para usar todos os recursos na tenancy em que request.region='sa-saopaulo-1'

Essa política impede que o grupo RegionalAdmins use recursos na região de São Paulo, mas permite permissões de uso, leitura e inspeção. É ideal para instituições financeiras que atendam à conformidade com as leis regionais de residência de dados.

Como posso impedir que um grupo acesse instâncias de computação em um compartimento específico?

Para impedir que um grupo acesse instâncias de computação em um compartimento específico, use

Deny group DevTeam para inspecionar a instância no compartimento ProjectX

Esta política bloqueia todas as permissões (inspecionar, ler, usar, gerenciar) em instâncias de computação no compartimento ProjectX. Por exemplo, uma empresa de tecnologia pode usar isso para impedir que a equipe de desenvolvimento acesse instâncias de produção, isolando os ambientes de desenvolvimento e produção para maior segurança.

Como posso impedir que um grupo gerencie o armazenamento de objetos em um compartimento específico?

Para impedir que um grupo gerencie recursos de armazenamento de objetos em um compartimento específico, use

Negar ao grupo StorageUsers a permissão para inspecionar a família de objetos no compartimento DataLake

Esta política bloqueia todas as permissões (inspecionar, ler, usar, gerenciar) em recursos de armazenamento de objetos no compartimento DataLake. Por exemplo, uma organização de saúde pode aplicar isso para impedir que o grupo StorageUsers acesse dados confidenciais de pacientes, garantindo a conformidade com as regulamentações de privacidade.

Como posso delegar tarefas a usuários que podem gerenciar políticas em um compartimento filho sem permitir que eles modifiquem determinados recursos ou criem políticas de negação?

Para delegar tarefas com segurança aos usuários que podem gerenciar a política em um compartimento filho, você pode

  • Conceda permissões específicas para compartimentos ou recursos designados usando políticas de permissão.
  • Restrinja a autoria de políticas de negação para impedir que usuários que podem gerenciar políticas em um compartimento filho criem políticas disruptivas.
  • Use políticas de negação para bloquear o acesso a recursos confidenciais.

Por exemplo, para permitir que usuários que podem gerenciar políticas em um compartimento filho gerenciem recursos computacionais em um compartimento, restringindo alterações de rede e negando a criação de políticas, use as seguintes políticas:

Negar ao grupo ProjectAdmins o gerenciamento da família de redes no compartimento ProjectX Negar ao grupo ProjectAdmins o gerenciamento de políticas no compartimento ProjectXonde target.policy.type='DENY'

Permita que o grupo ProjectAdmins gerencie a família de instâncias no compartimento ProjectX

Essas políticas permitem que os ProjectAdmins gerenciem instâncias no ProjectX, bloqueiem a modificação de redes e os impeçam de gravar políticas de negação, oferecendo suporte à delegação segura. Uma organização financeira poderia usar essa abordagem para permitir que subadministradores gerenciem recursos computacionais, mantendo um controle rigoroso sobre as configurações de rede e o gerenciamento de políticas.

Mecanismos de segurança e recuperação

As políticas de negação são avaliadas antes de permitir políticas?

Sim, o OCI Identiy and Access Management usa um modelo de avaliação que prioriza a negação, no qual as políticas de negação são avaliadas antes das políticas de permissão na hierarquia de compartimentos. Se uma solicitação corresponder a uma política de negação, o acesso será bloqueado, independentemente de quaisquer políticas de permissão. Os grupos de administradores padrão estão isentos de políticas de negação para evitar bloqueios.

Por exemplo, as seguintes políticas podem existir no compartimento Prod:

Negar ao grupo Devs o gerenciamento da família de instâncias no compartimento Prod
Permitir ao grupo Devs o gerenciamento de todos os recursos no compartimento Prod

A política de negação impede que os desenvolvedores gerenciem instâncias, enquanto os administradores padrão ainda podem gerenciar instâncias.

O que acontece se um usuário que pode gerenciar políticas gravar uma política de negação que bloqueie todos os usuários na tenancy?

O grupo de administradores padrão está isento de políticas de negação, para que os membros possam fazer login, exibir e editar políticas para resolver bloqueios. Essa proteção ajuda a evitar interrupções em toda a tenancy.

Exemplo: Se a política Negar any-user para inspecionar todos os recursos na tenancy for aplicada, os usuários do grupo de administradores padrão ainda poderão fazer login e acessar o editor de políticas para removê-la ou ajustá-la.

Como faço para me recuperar de uma política de negação em toda a tenancy que bloqueia todos os usuários?

Uma política de negação em toda a tenancy, como Negar que qualquer usuário inspecione todos os recursos na tenancy, pode bloquear todo o acesso do usuário, causando uma interrupção. Para recuperar:

1. Faça login como membro do grupo de administradores padrão (isento de políticas de negação).
2. No OCI Console, vá para Identity & Security (Identidade e Segurança), depois Policies (Políticas).
3. Localize a política problemática no compartimento raiz.
4. Edite ou exclua a política (por exemplo, altere "Negar a qualquer usuário a inspeção de todos os recursos no locatário" para "Negar ao grupo Estagiários a inspeção de todos os recursos na tenancy").
5. Como alternativa, use a seguinte interface de linha de comando do OCI: oci iam policy update --policy-id --statements '["Negar ao grupo Estagiários a inspeção de todos os recursos na tenancy"]

Por exemplo, se um usuário que pode gerenciar políticas em um compartimento filho aplicar acidentalmente a política "Negar a qualquer usuário a inspeção de todos os recursos no locatário", um usuário do grupo de administradores padrão poderá fazer login e modificá-la para que se aplique apenas ao grupo "Convidados", evitando bloqueios futuros. Para evitar esses problemas, teste as políticas minuciosamente e limite a criação de políticas de negação.

Efeitos de permissão

O que acontece se eu negar a permissão "gerenciar"?

Negar a permissão de gerenciamento bloqueia apenas a permissão de gerenciamento, enquanto as funções de usar, ler e inspecionar permanecem intactas.

Exemplo: Negar ao grupo DevOps a permissão para gerenciar instâncias no compartimento de Produção impede que o DevOps gerencie instâncias, mas permite que eles as usem, leiam ou inspecionem.

O que acontece se eu negar a permissão de "uso"?

Negar o uso bloqueia as permissões de uso e gerenciamento, mas as permissões de leitura e inspeção permanecem permitidas.

Exemplo: Impedir que o grupo de Avaliadores use o bucket no compartimento de Controle de Qualidade (QA). Isso impede que eles usem ou gerenciem buckets, mas permite que os leiam ou inspecionem.

O que acontece se eu negar a permissão de "leitura"?

Negar a leitura bloqueia as permissões de leitura, uso e gerenciamento, mas a inspeção ainda é permitida.

Exemplo: Impedir que os auditores do grupo leiam os registros no compartimento. O registro impede que os auditores leiam, usem ou gerenciem os registros, mas permite a inspeção.

O que acontece se eu negar a permissão de "inspeção"?

Negar a permissão de inspeção bloqueia todas as outras permissões (inspecionar, ler, usar, gerenciar), já que a permissão de inspeção é a permissão de nível básico.

Exemplo: Negar ao grupo Visualizadores o acesso à instância no compartimento Público bloqueia completamente o acesso dos Visualizadores às instâncias.

Casos de uso avançados e solução de problemas

Como posso monitorar as políticas de negação para garantir que funcionem conforme o esperado?

Revise os logs de auditoria do OCI para rastrear as ações bloqueadas pelas políticas de negação. Se uma política como Deny any-user para inspecionar o cloud-shell na tenancy causar problemas, refine-a para "Negar ao grupo Estagiários a inspeção do cloud-shell na tenancy". Configure alertas para alterações de política para manter uma postura proativa.

Exemplo: Monitore os logs para ajustar a política "Negar ao grupo Drivers o gerenciamento da família de instâncias no compartimento Fleet" caso tarefas legítimas sejam bloqueadas.

Quais são os erros comuns a serem evitados com políticas de negação?

O primeiro modelo de negação da OCI prioriza políticas de negação em vez de políticas de permissão, o que pode levar a interrupções se as políticas forem excessivamente amplas. Erros comuns incluem a aplicação de bloqueios em toda a tenancy ou em todo o compartimento ou o uso de condições excessivamente amplas baseadas em tags.

Por exemplo, uma política como "Negar a qualquer usuário a inspeção de todos os recursos na tenancy" pode bloquear todo o acesso, causando um bloqueio em toda a tenancy. Em vez disso, use políticas direcionadas, como as seguintes:

Deny group Interns to inspect all-resources in compartment Public

Isso restringe o acesso apenas para o grupo de estagiários, evitando interrupções não intencionais. Uma empresa de tecnologia pode usar essa abordagem para limitar o acesso de convidados, preservando a funcionalidade para outros usuários. Para evitar problemas, teste as políticas em um ambiente de sandbox, mantenha-as simples e restrinja a autoria da política de negação.

As declarações de negação são compatíveis com casos de uso entre tenancies?

Sim, as declarações de negação são compatíveis com cenários entre tenancies. Uma única declaração de negação de endosso ou negação de admissão pode bloquear solicitações entre tenancies, ao contrário dos pares de endosso/admissão que exigem que ambos sejam atendidos.

A seguinte tenancy de origem é um exemplo:

Autorizar o grupo Devs a usar a família de objetos na tenancy PartnerTenancy Negar autorização ao grupo Devs para gerenciar a família de objetos na tenancy PartnerTenancy

Isso permite que os desenvolvedores usem o armazenamento de objetos na tenancy PartnerTenancy, mas bloqueia as ações de gerenciamento. Uma organização parceira pode usar isso para habilitar o compartilhamento de dados, mantendo o controle sobre os recursos.

Como as políticas de negação interagem com o OCI Zero Trust Packet Routing?

O OCI Zero Trust Packet Routing opera na camada 4 (nível de rede) do modelo Open Systems Interconnection, enquanto as políticas de negação do IAM impõem o acesso na camada 7 (nível da aplicação). Se o OCI Zero Trust Packet Routing permitir comunicação, as políticas de negação do IAM ainda poderão bloquear ações.

Exemplo:

  • Política do OCI Zero Trust Packet Routing: Permitir que dynamic-group FrontEnd na VCN web:vcn se conecte à backend:server-instance na VCN vcn:server permite o tráfego de rede.
  • A política IAM: Negar ao grupo dinâmico FrontEnd a permissão para gerenciar a família de instâncias no compartimento ProjectA bloqueia o gerenciamento de instâncias, apesar da permissão do OCI Zero Trust Packet Routing.

As políticas do OCI Zero Trust Packet Routing e do IAM são avaliadas sequencialmente, com o IAM como o controlador final.

Como as políticas definidas pelo sistema interagem com as políticas de negação?

As políticas padrão do sistema sempre substituem as políticas de negação definidas pelo usuário para garantir o funcionamento dos serviços essenciais (por exemplo, Permitir que qualquer usuário leia domínios no locatário onde target.domain.id='request.domain.id').

Exemplo: Uma política de negação, como "Negar permissão de leitura de domínios para usuários do grupo em uma tenancy", não bloqueará uma política de sistema padrão que permita o acesso ao domínio.

As políticas de negação são avaliadas de forma diferente das políticas de permissão?

O OCI Identity and Access Management usa um modelo de avaliação que prioriza a negação, no qual as políticas de negação são avaliadas antes das políticas de permissão na hierarquia de compartimentos. Se uma solicitação corresponder a uma política de negação, o acesso será bloqueado, independentemente de quaisquer políticas de permissão. As políticas definidas pelo sistema podem substituir as negações definidas pelo usuário (consulte a pergunta 27). Os grupos de administradores padrão estão isentos de políticas de negação, para que possam gerenciar políticas durante bloqueios.

Exemplo: Se a política "Negar ao grupo Usuários que gerenciem a família de instâncias no compartimento Prod" existir juntamente com a política "Permitir ao grupo Usuários que gerenciem todos os recursos no compartimento Prod", a política de negação bloqueará o gerenciamento de instâncias.

A política de negação do IAM substitui as funções de administração do domínio de identidade da Oracle (por exemplo, administrador do domínio de identidade, administrador de segurança e gerenciador de usuários)?

Na versão atual, as políticas de negação do IAM não substituem as funções de administração do Oracle Identity Cloud Service (por exemplo, administrador de domínio de identidade, administrador de segurança e gerente de usuários). Esta é uma limitação. Na próxima versão, a política de negação do IAM terá precedência sobre as funções de administração do Oracle Identity Cloud Service para um controle de acesso consistente.

Como posso usar a política de negação do IAM para que o acesso a um serviço ocorra somente por meio do novo OCI Private Service Access?

O OCI Private Service Access permite o acesso aos serviços Oracle por um caminho de rede privada, em vez de por meio da internet pública. O OCI Private Service Access foi projetado para clientes que desejam conectividade privada entre cargas de trabalho e os serviços da Oracle, por motivos de conformidade, desempenho ou segurança.

Se você estiver usando o OCI Private Service Access para acessar um serviço com segurança (como OCI Object Storage ou OCI Streaming), talvez queira exigir que todo o acesso seja feito por meio do OCI Private Service Access. Com o IAM Deny, você pode bloquear explicitamente todo o tráfego que não seja do OCI Private Service Access para um serviço, mesmo que existam políticas de permissão.

Por exemplo, para permitir o acesso ao OCI Object Storage somente por meio do OCI Private Service Access, use

Deny any-user para acessar a família de objetos na tenancy onde qualquer {not request.gateway.id, request.gateway.type !='privateserviceaccess'}

Essa política impede que os usuários acessem o OCI Object Storage, a menos que seu tráfego seja roteado por meio de um endpoint do OCI Private Service Access. Isso é especialmente útil se você configurou um OCI Private Service Access para dados confidenciais e deseja eliminar o risco de acesso por meio de rotas públicas não intencionais.

Qual a diferença entre as políticas de negação do OCI Identity and Access Management e as Oracle Security Zones, e quando devo usá-las?

A OCI oferece políticas de negação do IAM e Oracle Security Zones para proteger seu ambiente, impedindo ações inseguras. Embora ambas reforcem a segurança, elas diferem em seu funcionamento e flexibilidade.

  • Semelhanças: tanto as políticas de negação do IAM quanto as Oracle Security Zones bloqueiam ações específicas para proteger seus recursos e aplicar as melhores práticas de segurança no ambiente da OCI.
  • Principais diferenças
    • Políticas de negação do IAM: você cria políticas personalizadas para bloquear ações com base em condições como identidade do usuário, tipo de recurso, endereço IP ou tags. Essas políticas funcionam como diretrizes, e a partir da próxima versão terão precedência sobre todas as políticas do IAM. Por exemplo, você pode bloquear um grupo de usuários específico de excluir recursos críticos se o recurso tiver uma tag específica, como environment:production.
    • Oracle Security Zones: aplicam regras de segurança predefinidas a compartimentos ou a toda a tenancy. Quando ativada, o Oracle Security Zones impõe automaticamente restrições para algum conjunto de serviços do OCI, como impedir sub-redes públicas ou desativar a criptografia. Não é necessário criar políticas, as regras são integradas e verificam automaticamente as configurações do recurso.
  • Quando usar
    • Use políticas de negação do IAM para restrições personalizadas e direcionadas, como bloquear usuários específicos ou ações com base em suas condições definidas.
    • Use o Oracle Security Zones para regras de segurança automáticas e prontas para uso, que permitem aplicar as melhores práticas com o mínimo de configuração.
    • Combine ambos para uma proteção ainda mais robusta. Habilite o Oracle Security Zones para diretrizes básicas e abrangentes e adicione políticas de negação do IAM para controles específicos e personalizados.

Obtenha ajuda com as políticas de negação do OCI Identity and Access Management

Para obter ajuda adicional, consulte a documentação do OCI Identity and Access Management ou entre em contato com a equipe da sua conta da OCI.

Grupos

O que é um grupo?

Um grupo é uma coleção de usuários que precisam de privilégios de acesso semelhantes para usar ou gerenciar um recurso específico em sua conta. Os usuários podem estar em vários grupos. Permissões são aditivas. Por exemplo, se a associação em um grupo permitir que um usuário use instâncias de computação, e a associação em um segundo grupo permitir que o usuário gerencie volumes em blocos, o usuário poderá gerenciar instâncias e volumes em blocos.

Os administradores gravam diretivas que especificam grupos (não usuários individuais) com o acesso necessário de que precisam, seja em um compartimento específico ou na conta. Os administradores adicionam usuários aos grupos apropriados.

Posso ter vários Administradores?

Sim. Sua conta é provisionada com um único administrador padrão que pertence a um grupo de Administradores dentro do seu compartimento raiz. Este grupo tem privilégios totais para criar e gerenciar todos os recursos da Oracle Cloud Infrastructure em sua conta, incluindo usuários, grupos, políticas e compartimentos, além de todos os outros recursos de infraestrutura de nuvem em qualquer compartimento. Você pode adicionar usuários adicionais a este grupo Administradores.

Recursos

Como o OCI IAM atende aos requisitos de expiração de senha?

As políticas de senha permitem que você defina um tempo de expiração para as senhas. Uma política de senha padrão define que as senhas expiram após 120 dias. Isso é configurável e diferentes políticas podem ser aplicadas a subconjuntos de usuários.

Como posso executar tarefas na instância de computação sem incorporar credenciais de usuário nelas?

Use grupos de recursos dinâmicos para designar um conjunto de recursos de computação a um grupo. Você pode então designar esse grupo de permissões por meio de uma política. Isso permite que uma instância de computação acesse outros recursos da OCI de forma segura sem incorporar credenciais em scripts.

Federação

O que é federação de identidade na Oracle Cloud Infrastructure?

A federação de identidade é um mecanismo para delegar o gerenciamento de usuários para a sua locação Oracle Cloud Infrastructure a outra entidade chamada provedor de identidade ou IdP. Isso é útil para empresas que possuem um Sistema de identidades existente que gostariam de usar, em vez de criar e manter um novo conjunto de usuários. A federação requer uma configuração exclusiva entre a Oracle Cloud Infrastructure e o IdP conhecida como Federation Trust.

O que são usuários federados?

Usuários federados (identidades externas) são usuários que você gerencia fora do Oracle Cloud Infrastructure (por exemplo, no diretório corporativo), mas a quem você concede acesso à sua conta no Oracle Cloud Infrastructure. Eles diferem dos usuários da Oracle Cloud Infrastructure, criados e mantidos em sua conta Oracle Cloud Infrastructure.

Os usuários federados podem acessar o console da Oracle Cloud Infrastructure?

Sim. Usuários federados podem acessar o Console Oracle Cloud Infrastructure.

Os usuários federados podem acessar o Oracle Cloud Infrastructure SDK e CLI?

Sim. Os usuários federados podem acessar o Oracle Cloud Infrastructure SDK e CLI.

Quais ações os usuários da Oracle Cloud Infrastructure podem executar no console que os usuários federados não podem executar?

Usuários federados não podem alterar nem redefinir suas senhas no Console Oracle Cloud Infrastructure.

Como controlo o que um usuário federado pode fazer quando está conectado ao console?

Você usa as mesmas políticas do Oracle Cloud Infrastructure para gerenciar usuários federados que você usa para gerenciar usuários nativos. Você mapeia funções e grupos em seu Provedor de Identidade para grupos no Oracle Cloud Infrastructure. Quando um usuário federado efetua login, o Oracle Cloud Infrastructure Console aplica políticas com base em sua associação ao grupo Oracle Cloud Infrastructure, assim como nos usuários nativos. Veja exemplos na documentação.

Uma única função ou grupo em seu Provedor de Identidade pode ser mapeado para vários grupos Oracle Cloud Infrastructure. Além disso, várias funções ou grupos no seu Provedor de Identidade podem ser mapeados para um único grupo do Oracle Cloud Infrastructure.

A quantos usuários federados posso conceder acesso ao Console Oracle Cloud Infrastructure?

Não há limite para o número de usuários federados que podem ter acesso ao console.

Quais Provedores de Identidade são compatíveis?

O OCI IAM suporta qualquer provedor de identidades compatível com SAML 2.0, Open ID Connect ou OAuth, incluindo soluções populares como Oracle Access Manager, Microsoft Active Directory Federation Services (AD FS) e Okta.

Autenticação multifator

O que é autenticação multifator (MFA, Multifactor Authentication) e por que é tão importante?

Usualmente as contas eram protegidas apenas com usuário e senha. Porém, as senhas podem ser esquecidas facilmente e relativamente fáceis de descobrir usando técnicas simples de ataque, como sniffers, phishing e ataques de força bruta. Se alguém descobrisse suas credenciais podem adotar a sua identidade e acessar todas as suas contas e recursos.

A autenticação multifator (MFA) é um recurso de segurança popular que ajuda a reduzir o risco de aquisição de contas, fortalecendo a garantia de que um usuário do aplicativo é quem ele afirma ser. A MFA exige que os usuários autentiquem sua identidade em duas ou mais etapas. Há três categorias de fatores de autenticação: algo que você conhece (como senha ou PIN), algo que você tem (como token de segurança ou celular) e algo que você é (como dados biométricos, como impressão digital ou varredura de rosto). Quando a MFA é habilitada, mesmo que um invasor consiga a sua senha, não conseguirão continuar com a autenticação por não conseguirem validar o token, por exemplo, exigido pelo mecanismo de segurança. Isso previne acesso não autorizado e protege informações confidenciais contra vazamentos ou outras ações inadequadas. Habilitar a MFA ajuda a cumprir os padrões regulatórios e compliance adotados pela indústria, tais como aqueles fornecidos pelo National Institute of Standards and Technology (NIST).

Quem deve usar a MFA?

A Oracle recomenda que todos os usuários habilitem a MFA. Você deve, como medida cautelar, habilitar a MFA para usuários com direitos de administrador, que tenham, por exemplo, autorização de criar e gerenciar os recursos da OCI. Também recomendamos o uso da MFA para acessar qualquer aplicação que hospede informações confidenciais ou ofereçam ações de alto risco.

Qual será a experiência do usuário final quando os administradores habilitam a MFA?

Quando a MFA for habilitada pela primeira vez por um administrador, os usuários serão solicitados a habilitarem a MFA no próximo login. Após a configuração inicial, os usuários passarão pelo mecanismo da MFA a cada novo evento de login. Caso o administrador tenha habilitado Trusted Devices (Dispositivos Confiáveis), os usuários poderão clicar em "confiar neste dispositivo". Desta forma, sempre que o usuário utilizar o mesmo dispositivo o mecanismo da MFA não será ativado.

Para mais informações, os usuários podem consultar as seguintes referências:

A MFA é obrigatória em todos os cenários?

Não. A MFA não é obrigatória em todos os cenários. Se você estiver concedendo acesso a um site público, por exemplo, normalmente não exigiria autenticação. Se você quiser que os usuários se conectem ao fazer uma compra para saber qual conta cobrar e onde entregar produtos, talvez um nome de usuário e senha sejam suficientes. No entanto, se esse mesmo usuário quiser alterar o método de pagamento ou o endereço de entrega ou se o aplicativo permitir ações que possam impactar sua organização, a MFA será recomendada.

A Oracle recomenda você habilitar a MFA para todos os administradores de nuvem e das aplicações. Por fim, você deve avaliar se deve impor a MFA com base nas políticas internas de segurança e na avaliação de risco da sua organização. Mas é uma boa prática começar com uma política que a MFA é sempre obrigatória e requer aprovações executivas para quaisquer aplicativos para os quais você deseja tornar a MFA opcional.

Quais fatores da MFA são disponibilizados? Há algum custo?

Para entender totalmente os fatores e o custo disponíveis, é importante primeiro entender qual tipo de tenancy do OCI você tem. Para determinar se a sua tenancy possui o OCI Identity and Access Management (IAM) com os domínios de identidade ou se a tenancy possui o OCI IAM sem domínios de identidade, consulte esta documentação.

  • Se sua tenancy tiver o OCI IAM com domínios de identidades, todos os tipos de domínio de identidades suportarão MFA sem custo adicional. Os domínios de identidade do tipo Livre não podem usar SMS como um fator de autenticação, mas outros fatores estão disponíveis. Para ver todos os detalhes, consulte a documentação sobre o OCI IAM com MFA de domínios de autenticação.
  • Caso a sua tenancy possua o OCI IAM sem domínios de identidade, existem duas MFAs possíveis:
    • Habilitar a MFA para o login direto do usuário através do serviço OCI IAM. Esta opção oferece um conjunto limitado de fatores de autenticação sem nenhum custo adicional. Para ver todos os detalhes, consulte a documentação sobre o OCI IAM sem MFA de domínios de autenticação.
    • Aproveite o Oracle Identity Cloud Service (IDCS) para autenticar o login na OCI dos usuários. Esta opção oferece mais recursos de MFA e opções de autenticação.
  • Se você estiver usando o IDCS na autenticação, existem dois tipos de licença:
    • O IDCS Foundation (Modo Gratuito) suporta MFA apenas para acesso à console do OCI, sem custo, com um conjunto limitado de fatores de autenticação conforme disposto aqui. Para proteger as outras aplicações, será necessário atualizar para o IDCS Standard.
    • O IDCS Standard oferece suporte a uma variedade de opções de MFA para qualquer serviço ou aplicação protegida sem nenhum custo adicional. Para ver todos os detalhes, consulte a documentação sobre a MFA no Identity Cloud Service (IDCS).

Onde posso aprender mais sobre a implementação da MFA?

As instruções específicas para implementar a MFA variam, dependendo do tipo de tenancy do OCI que você tem. Para determinar se a sua tenancy possui o OCI Identity and Access Management (IAM) com os domínios de identidade ou se a tenancy possui o OCI IAM sem domínios de identidade, consulte esta documentação.

O que acontece se eu não implementar a MFA?

Caso você não habilite a MFA, terá maior risco de sofrer um ataque bem-sucedido direcionado à sua conta. Por outro lado, com a MFA habilitada entre outros processos de autenticação, a sua operação continua normalmente.