Visão geral do Access Context Manager

Este documento fornece uma visão geral do serviço do Access Context Manager e das funções dele.Os administradores da organização do Cloud de Confiance by S3NS podem usar o Access Context Manager para definir um controle de acesso refinado e baseado em atributos para projetos e recursos no Cloud de Confiance. Como administrador, primeiro você define uma política de acesso, que é um contêiner para toda a organização para níveis de acesso e perímetros de serviço.

Os níveis de acesso descrevem os requisitos para cumprimento das solicitações. Os exemplos incluem:

  • Tipo de dispositivo e sistema operacional
  • Endereço IP
  • Identidade do usuário

Os perímetros de serviço definem sandboxes de recursos. Os recursos dentro do perímetro podem trocar dados livremente, mas não podem exportar dados para fora do perímetro. O Access Context Manager não é responsável pela aplicação de políticas. Em vez disso, o Access Context Manager foi projetado para definir regras ou contextos específicos. A política é configurada e aplicada em vários pontos, como o VPC Service Controls. Leia mais sobre esses serviços nos respectivos guias do usuário.

É possível configurar e aplicar políticas do Access Context Manager nos seguintes componentes da solução do Chrome Enterprise Premium:

Vantagens

Muitas empresas dependem de um modelo de segurança de perímetro, como um firewall, para ajudar a proteger os recursos internos. Um modelo de segurança de perímetro é muito protegido, com um único ponto de entrada e saída. Tudo o que estiver fora do perímetro é considerado perigoso. e tudo o que estiver do lado de dentro é confiável.

Os firewalls e o modelo de segurança de perímetro funcionam bem se houver um limite bem definido em torno de usuários e serviços específicos. No entanto, se uma força de trabalho for móvel, a variedade de dispositivos aumentará à medida que os usuários trouxerem os próprios dispositivos deles (BYOD, sigla em inglês) e utilizarem serviços baseados em nuvem. Esse cenário resulta em outros vetores de ataque que não são considerados pelo modelo de perímetro. Por isso, o perímetro não é mais apenas o local físico da empresa, e o que está dentro não pode ser considerado seguro.

Use o Access Context Manager para reduzir o tamanho da rede privilegiada e mudar para um modelo em que os endpoints não tenham autoridade de ambiente com base na rede. Em vez disso, é possível conceder acesso com base no contexto da solicitação, como tipo de dispositivo, identidade do usuário e muito mais, além de verificar o acesso à rede corporativa quando necessário.

Políticas de acesso

Uma política de acesso é um contêiner para todos os seus recursos do Access Context Manager, como níveis de acesso e perímetros de serviço.

É possível criar uma política de acesso no contexto de uma organização e usá-la em qualquer lugar da organização. Para delegar a administração de uma política de acesso, crie uma política de acesso com escopo e defina o escopo da política no nível da pasta ou do projeto. O administrador delegado a quem a política com escopo foi atribuída pode gerenciar apenas a política de acesso com escopo, não a política de acesso no nível da organização.

Uma política de acesso é versionada usando um etag. É possível usar etag para segmentar mudanças na política de acesso, como modificações nos níveis de acesso ou em uma versão específica da política. Se várias fontes mudarem sua política de acesso, o uso do campo etag para a ferramenta de linha de comando gcloud e as chamadas de API ajudará a evitar substituições e conflitos não intencionais.

Para saber como criar políticas de acesso, consulte Como criar uma política de acesso.

Níveis de acesso

Os níveis de acesso são usados para permitir o acesso a recursos com base em informações contextuais sobre a solicitação. Usando níveis de acesso, é possível começar a organizar níveis de confiança. Por exemplo, é possível criar um nível de acesso chamado High_Level que permitirá solicitações de um pequeno grupo de indivíduos com privilégios altos. Também é possível identificar um grupo mais geral para confiar, como um intervalo de IP de onde você quer permitir solicitações. Nesse caso, é possível criar um nível de acesso chamado Medium_Level para permitir essas solicitações.

Depois que você definir os níveis de acesso, os serviços de aplicação poderão usá-los para determinar se uma solicitação será atendida. Por exemplo, é possível especificar que, embora muitos recursos estejam disponíveis para Medium_Trust, determinados recursos mais confidenciais exigem o nível High_Trust. Essas verificações são aplicadas além da política padrão do IAM.

Os níveis de acesso são personalizáveis. Os níveis de acesso High_Trust e Medium_Trust são exemplos. É possível especificar vários níveis de acesso como parte de uma política de acesso.

Um nível de acesso básico consiste em uma coleção de condições usadas para testar solicitações. As condições podem ser definidas como um grupo de atributos que você quer testar, como tipo de dispositivo, endereço IP ou identidade do usuário. Os atributos são combinados como uma operação AND (todos precisam ser verdadeiros) ou uma operação NOR (nenhum precisa ser verdadeiro) para determinar se a condição é atendida.

!(origin.region_code in ['RU', 'BY', 'UA']) -> FAILED  // levels.regions_check

inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED  // levels.ip_check

!(origin.region_code in ['RU', 'BY', 'UA']) || inIpRange(origin.ip, ['205.220.128.0/23']) -> GRANTED

levels.regions_check || levels.ip_check -> GRANTED

Endereço IP

É possível conceder um nível de acesso com base no endereço IP da solicitação de origem. Para especificar o intervalo de IPs permitidos, use um bloco do roteamento entre domínios sem classe (CIDR), uma forma granular de controlar as permissões.

Um único nível de acesso pode conter vários intervalos de IP.

Para saber como criar um nível de acesso que permita o acesso apenas a um intervalo especificado de endereços IP, como aqueles em uma única rede corporativa, consulte Como criar um nível de acesso para acesso à rede corporativa.

Os seguintes intervalos de IP são tratados como intervalos particulares pelo Access Context Manager:

  • 10.0.0.0/8 (RFC 1918)
  • 172.16.0.0/12 (RFC 1918)
  • 192.168.0.0/16 (RFC 1918)
  • 100.64.0.0/10 (espaço de endereços compartilhado RFC 6598)
  • fc00::/7 (endereços locais exclusivos IPv6 RFC 4193)

Identidade do usuário

Em alguns cenários, talvez você queira conceder um nível de acesso a entidades específicas. Nesses cenários, é a identidade do autor da chamada que determina se a condição foi atendida. Esse cenário é muito usado com contas de serviço e o VPC Service Controls.

É possível criar e gerenciar níveis de acesso somente para identidade com a ferramenta de linha de comando gcloud, mas não com o console do Cloud de Confiance .

Para começar a criar um nível de acesso básico, consulte Criar um nível de acesso para o Access Context Manager.

Como combinar condições

Um único nível de acesso pode conter várias condições. As condições podem ser avaliadas usando o operador AND ou OR. Especifique o modo ao criar ou atualizar um nível de acesso.

O caso AND é a opção mais restrita e padrão. Essa opção só concede o nível de acesso se todas as condições forem atendidas. Por exemplo, é possível exigir que uma solicitação venha da rede corporativa e de um dispositivo que execute a versão mais recente de um sistema operacional.

OR é uma opção menos restritiva. Essa opção exige que apenas uma das muitas condições seja verdadeira. Isso é útil ao lidar com identidades de usuário, por exemplo, para excluir entidades específicas (como contas de serviço) dos requisitos normais.

Condições de aninhamento

As condições podem ser aninhadas de maneira que uma dependa da outra. Por exemplo, se você tiver os dois níveis de acesso de confiança "Médio" e "Alto", poderá definir os requisitos para que "Alto" exija "Médio", além de outras condições.

As condições de aninhamento podem tornar o gerenciamento de níveis de acesso mais conveniente. Por exemplo, imagine que seu nível de acesso mais abrangente contém uma versão mínima do sistema operacional e você define os níveis mais restritivos para depender dele. Se você atualizar a versão mínima no futuro, só precisará atualizar uma única condição, em vez de todos os níveis de acesso na política.

Ao aninhar níveis de acesso, lembre-se dos seguintes limites e restrições:

  • Sem dependências circulares: dependências circulares não são permitidas. Os níveis de acesso não podem se referenciar em um loop, seja diretamente (por exemplo, Level_A requer Level_B e Level_B requer Level_A, ou um nível de acesso faz referência a si mesmo) ou transitivamente (por exemplo, Level_A requer Level_B, Level_B requer Level_C e Level_C requer Level_A). Se você tentar criar ou atualizar um nível de acesso que introduza uma dependência circular, a chamada falhará com um erro INVALID_ARGUMENT.

  • Máximo de dependências por condição: em um nível de acesso básico, a lista requiredAccessLevels de uma única condição pode referenciar até 15 outros níveis de acesso.

  • Profundidade de aninhamento: como o Access Context Manager avalia os níveis de acesso aninhados em ordem de dependência em vez de expandi-los de forma recursiva, não há um limite máximo separado de profundidade em uma cadeia de níveis de acesso aninhados além do limite geral de níveis de acesso por política de acesso. Todos os níveis de acesso referenciados precisam pertencer à mesma política de acesso.

Saiba mais