Aplicar políticas a grupos de usuários usando vinculações de acesso

É possível usar vinculações de acesso para controlar quais aplicativos e recursos seus grupos de usuários podem acessar. Uma vinculação de acesso especifica como aplicar níveis de acesso e controles de sessão a um grupo de usuários. É possível aplicar o mesmo nível de acesso e controle de sessão a todos os aplicativos ou definir comportamentos específicos para aplicativos individuais.

Para garantir que você configurou tudo corretamente, teste as políticas antes de aplicá-las.

Ao trabalhar com vinculações de acesso, considere o seguinte comportamento:

  • Um grupo de usuários pode ter apenas uma vinculação de acesso.
  • Se um usuário pertencer a vários grupos, ele terá acesso se alguma política permitir (OR, não AND).
  • Para controles de sessão, apenas a vinculação de acesso criada mais recentemente é aplicada.

Usar uma única configuração para todos os aplicativos

Esse método aplica o mesmo nível de acesso e controle de sessão a todos os aplicativos acessados por um grupo de usuários.

Recomendamos que você teste sua política com uma simulação ou a aplique a um pequeno grupo de teste antes de implementá-la na produção.

gcloud

Crie a vinculação de acesso.

gcloud access-context-manager cloud-bindings create \
     --group-key GROUP_ID
     --organization ORG_ID
     --level DEFAULT_ACCESS_LEVEL
  [  --session-length=DEFAULT_SESSION_LENGTH                ]
  [  --session-reauth-method=DEFAULT_SESSION_REAUTH_METHOD  ]

Substitua:

  • GROUP_ID: o ID do grupo. Se você não tiver o ID do grupo disponível, poderá recuperá-lo chamando o método get no recurso do grupo.
  • ORG_ID: o ID da organização.
  • DEFAULT_ACCESS_LEVEL: o nome opcional do nível de acesso, que assume o formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Substitua POLICY_ID pelo ID da política de acesso e ACCESS_LEVEL_NAME pelo nome do nível de acesso.
  • DEFAULT_SESSION_LENGTH: a duração opcional da sessão no formato de hora, como 15h para 15 horas ou 2h para duas horas.
  • DEFAULT_SESSION_REAUTH_METHOD: o método opcional para desafiar os usuários a verificar novamente a identidade, que precisa ser um dos seguintes:
    • LOGIN: aplica o login padrão, que pode incluir MFA ou outros fatores definidos pelo Workspace.
    • PASSWORD: exige apenas uma senha, mesmo que outros fatores estejam definidos. Se as senhas forem gerenciadas usando um IdP externo, os usuários serão redirecionados para o IdP. Se a sessão do IdP estiver ativa, os usuários serão autenticados novamente de forma implícita. Se o IdP não estiver ativo, os usuários precisarão fazer login por ele.
    • SECURITY_KEY: exige uma chave de segurança de hardware.

API

  1. Crie um corpo JSON:

    {
  "groupKey": "GROUP_ID",
  "accessLevels": [
    "DEFAULT_ACCESS_LEVEL"
  ],
  // optional:
  "sessionSettings": {
    "sessionLength": "DEFAULT_SESSION_LENGTH",
    "sessionReauthMethod": "DEFAULT_SESSION_REAUTH_METHOD"
  }
}

    Substitua:

    • GROUP_ID: o ID do grupo. Se você não tiver o ID do grupo disponível, poderá recuperá-lo chamando o método get no recurso do grupo.
    • DEFAULT_ACCESS_LEVEL: o nome opcional do nível de acesso, que assume o formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Substitua POLICY_ID pelo ID da política de acesso e ACCESS_LEVEL_NAME pelo nome do nível de acesso.
    • DEFAULT_SESSION_LENGTH: a duração opcional da sessão no formato de hora, como 15h para 15 horas ou 2h para duas horas.
    • DEFAULT_SESSION_REAUTH_METHOD: o método opcional para desafiar os usuários a verificar novamente a identidade, que precisa ser um dos seguintes:
      • LOGIN: aplica o login padrão, que pode incluir MFA ou outros fatores definidos pelo Workspace.
      • PASSWORD: exige apenas uma senha, mesmo que outros fatores estejam definidos. Se as senhas forem gerenciadas usando um IdP externo, os usuários serão redirecionados para o IdP. Se a sessão do IdP estiver ativa, os usuários serão autenticados novamente de forma implícita. Se o IdP não estiver ativo, os usuários precisarão fazer login por ele.
      • SECURITY_KEY: exige uma chave de segurança de hardware.

  2. Envie a solicitação POST:

    POST https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings

    ORG_ID é o ID da organização que você usou para criar o papel de administrador de vinculação de acesso ao Cloud. Se a propriedade access-context-manager/organization não tiver sido definida, substitua ORG_ID na flag opcional --organization pelo ID da organização que você usou ao criar o papel de administrador de vinculação de acesso ao Cloud.

Se for bem-sucedido, você vai receber uma representação do objeto JSON. Se ocorrer um problema, você vai receber uma mensagem de erro.

Definir configurações para aplicativos específicos

Com esse método, é possível aplicar diferentes níveis de acesso e controles de sessão a aplicativos diferentes. Também é possível definir regras padrão para aplicativos que não têm configurações específicas.

É possível especificar aplicativos em vinculações de acesso usando o ID do cliente OAuth. É possível especificar os seguintes aplicativos usando o nome deles:

Esse método é útil quando você quer:

  • Aplicar políticas apenas a determinados aplicativos.

  • Criar uma política geral, mas excluir alguns aplicativos dela.

gcloud

  1. Crie um arquivo de vinculação no formato YAML com uma lista de entradas de escopo na lista scopedAccessSettings. Para cada aplicativo que você quer mapear para um nível de acesso específico, inclua uma entrada clientScope.

    scopedAccessSettings:
- scope:
    clientScope:
      restrictedClientApplication:
        clientId: CLIENT_ID
  activeSettings:
    accessLevels:
    - ACCESS_LEVEL_A
    sessionSettings:
      sessionLength: SESSION_LENGTH
      sessionReauthMethod: SESSION_REAUTH_METHOD
      sessionLengthEnabled: true
- scope:
    clientScope:
      restrictedClientApplication:
        name: CLIENT_NAME
  activeSettings:
    accessLevels:
    - ACCESS_LEVEL_B

    Substitua:

    • CLIENT_ID: o ID do cliente OAuth. É possível usar clientId ou name quando um aplicativo contém sessionSettings.
    • ACCESS_LEVEL_A: um nome de nível de acesso no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • SESSION_LENGTH: a duração da sessão no formato de hora, como 15h para 15 horas ou 2h para duas horas.

    • SESSION_REAUTH_METHOD: o método opcional para desafiar os usuários a verificar novamente a identidade, que precisa ser um dos seguintes:

      • LOGIN: aplique o login padrão, que pode incluir autenticação multifator (MFA) ou outros fatores definidos pelo Workspace.
      • PASSWORD: exige apenas uma senha, mesmo que outros fatores estejam definidos. Se as senhas forem gerenciadas usando um IdP externo, os usuários serão redirecionados para o IdP. Se a sessão do IdP estiver ativa, os usuários serão reautenticados implicitamente. Se o IdP não estiver ativo, os usuários precisarão fazer login por ele.
      • SECURITY_KEY: exige uma chave de segurança de hardware.

    • CLIENT_NAME: o nome do cliente. É possível usar name ou clientId quando um aplicativo contém sessionSettings.

    • ACCESS_LEVEL_B: um nome de nível de acesso no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Para definir um nível de acesso padrão para aplicativos não definidos no arquivo YAML, use o argumento --level. O arquivo YAML só é compatível com configurações específicas do aplicativo (scopedAccessSettings).

  2. Crie a vinculação de acesso.

    gcloud access-context-manager cloud-bindings create
    --organization ORG_ID
    --group-key GROUP_ID
    --binding-file BINDING_FILE_PATH
  [  --level DEFAULT_ACCESS_LEVEL ]
  [  --session-length=DEFAULT_SESSION_LENGTH                ]
  [  --session-reauth-method=DEFAULT_SESSION_REAUTH_METHOD  ]

    Substitua:

    • ORG_ID: o ID da organização.
    • GROUP_ID: o ID do grupo. Se você não tiver o ID do grupo disponível, poderá recuperá-lo chamando o método get no recurso do grupo.
    • BINDING_FILE_PATH: o caminho para o arquivo YAML que contém o esquema de vinculação de acesso. O arquivo de vinculação é compatível apenas com scopedAccessSettings.
    • DEFAULT_ACCESS_LEVEL: o nome opcional do nível de acesso, que assume o formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Substitua POLICY_ID pelo ID da política de acesso e ACCESS_LEVEL_NAME pelo nome do nível de acesso.
    • DEFAULT_SESSION_LENGTH: a duração opcional da sessão no formato de hora, como 15h para 15 horas ou 2h para duas horas.
    • DEFAULT_SESSION_REAUTH_METHOD: o método opcional para desafiar os usuários a verificar novamente a identidade, que precisa ser um dos seguintes:
      • LOGIN: aplica o login padrão, que pode incluir MFA ou outros fatores definidos pelo Workspace.
      • PASSWORD: exige apenas uma senha, mesmo que outros fatores estejam definidos. Se as senhas forem gerenciadas usando um IdP externo, os usuários serão redirecionados para o IdP. Se a sessão do IdP estiver ativa, os usuários serão autenticados novamente de forma implícita. Se o IdP não estiver ativo, os usuários precisarão fazer login por ele.
      • SECURITY_KEY: exige uma chave de segurança de hardware.

Como os argumentos --level e --binding-file funcionam juntos

  • Se você usar apenas --binding-file, somente os aplicativos no arquivo terão as políticas aplicadas.
  • Se você usar apenas --level, o nível de acesso será aplicado a todos os aplicativos.
  • Se você usar os dois, as regras serão combinadas. O valor --level se aplica a todos os aplicativos, enquanto as políticas no arquivo YAML especificado por --binding-file se aplicam apenas aos aplicativos conforme definido no arquivo.

Como trabalhar com controles de sessão

  • Para definir controles de sessão padrão para todos os aplicativos, use --session-length e --session-reauth-method.
  • Se você também definir controles de sessão no arquivo YAML, eles vão substituir as configurações padrão desses aplicativos específicos.
  • Use --session-length e --session-reauth-method juntos.

API

Crie um corpo JSON:

{
  "groupKey": "GROUP_ID",
   //
   // Optional; if specified, all applications that aren't defined in
   // scopedAccessSettings have these access levels applied.
   //
   // If more than one access level is specified, the user is
   // granted access if any one resolves to TRUE (OR logic, not AND).
   //
   // If you omit this key entirely, then no policy enforcement is
   // applied by default.
   //
  "accessLevels": [
    "DEFAULT_ACCESS_LEVEL"
  ],
  "scopedAccessSettings": [
    {
      "scope": {
        "clientScope": {
          "restrictedClientApplication": {
            "clientId": "CLIENT_ID"
          }
        }
      },
      "activeSettings": {
        "accessLevels": [
          "ACCESS_LEVEL_A"
        ],
        "sessionSettings": {
          "sessionLength": "SESSION_LENGTH",
          "sessionReauthMethod": "SESSION_REAUTH_METHOD",
          "sessionLengthEnabled": true
        }
      }
    },
    {
      "scope": {
        "clientScope": {
          "restrictedClientApplication": {
            "name": "CLIENT_NAME"
          }
        },
        "activeSettings": {
          "accessLevels": [
            "ACCESS_LEVEL_B"
          ]
        }
      }
    }
  ]
}

Substitua:

  • GROUP_ID: o ID do grupo. Se você não tiver o ID do grupo disponível, poderá recuperá-lo chamando o método get no recurso do grupo.
  • DEFAULT_ACCESS_LEVEL: o nome opcional do nível de acesso, que assume o formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Substitua POLICY_ID pelo ID da política de acesso e ACCESS_LEVEL_NAME pelo nome do nível de acesso.
  • CLIENT_ID: o ID do cliente OAuth. É possível usar clientId ou name quando um aplicativo contém sessionSettings.
  • ACCESS_LEVEL_A: um nome de nível de acesso no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
  • SESSION_LENGTH: a duração da sessão no formato de hora, como 2h para duas horas.

  • SESSION_REAUTH_METHOD: o método opcional para desafiar os usuários a verificar novamente a identidade, que precisa ser um dos seguintes:

    • LOGIN: aplica o login padrão, que pode incluir MFA ou outros fatores definidos pelo Workspace.
    • PASSWORD: exige apenas uma senha, mesmo que outros fatores estejam definidos. Se as senhas forem gerenciadas usando um IdP externo, os usuários serão redirecionados para o IdP. Se a sessão do IdP estiver ativa, os usuários serão reautenticados implicitamente. Se o IdP não estiver ativo, os usuários precisarão fazer login por ele.
    • SECURITY_KEY: exige uma chave de segurança de hardware.

  • CLIENT_NAME: o nome do cliente. É possível usar name ou clientId quando um aplicativo contém sessionSettings.

  • ACCESS_LEVEL_B: um nome de nível de acesso no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

Envie a solicitação POST:

POST https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings

ORG_ID é o ID da organização que você usou para criar o papel de administrador de vinculação de acesso ao Cloud. Se a propriedade access-context-manager/organization não tiver sido definida, substitua ORG_ID na flag opcional --organization pelo ID da organização que você usou ao criar o papel de administrador de vinculação de acesso do Cloud.

Se for bem-sucedido, você vai receber uma representação do objeto JSON ou uma mensagem de erro se houver um problema.

Usar níveis de acesso de simulação para simular a aplicação

Os níveis de acesso de simulação permitem testar as políticas de acesso sem aplicá-las. Isso ajuda a entender o impacto de uma política antes que ela seja publicada. É possível visualizar os registros de simulação para ver o que teria acontecido se a política estivesse ativa.

Somente os níveis de acesso podem ser usados no modo de teste. Os controles de sessão não estão disponíveis no modo de teste.

Criar uma política de simulação geral

Esse método aplica o mesmo nível de acesso de simulação a todos os aplicativos acessados por um grupo de usuários.

gcloud

Crie a vinculação de acesso com a flag --dry-run-level.

gcloud access-context-manager cloud-bindings create \
     --group-key=<var>GROUP_ID</var> \
     --organization=<var>ORG_ID</var> \
     --dry-run-level=<var>DEFAULT_DRY_RUN_ACCESS_LEVEL</var>

Substitua:

  • GROUP_ID: o ID do grupo. Se você não tiver o ID do grupo disponível, poderá recuperá-lo chamando o método get no recurso do grupo.
  • ORG_ID: o ID da organização.
  • DEFAULT_DRY_RUN_ACCESS_LEVEL: o nome do nível de acesso de simulação no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

API

  1. Crie um corpo JSON que contenha dry_run_access_levels.

    {
  "group_key": "GROUP_ID",
  "dry_run_access_levels": [
    "DEFAULT_DRY_RUN_ACCESS_LEVEL"
  ]
}

    Substitua:

    • GROUP_ID: o ID do grupo. Se você não tiver o ID do grupo disponível, poderá recuperá-lo chamando o método get no recurso do grupo.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: o nome do nível de acesso de simulação no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Envie a solicitação POST:

    POST https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings

    ORG_ID é o ID da organização que você usou para criar o papel de administrador de vinculação de acesso ao Cloud. Se a propriedade access-context-manager/organization não tiver sido definida, substitua ORG_ID na flag opcional --organization pelo ID da organização que você usou ao criar o papel de administrador de vinculação de acesso ao Cloud.

Criar uma política de simulação para aplicativos específicos

Esse método permite aplicar diferentes níveis de acesso de simulação a diferentes aplicativos. Também é possível definir regras padrão para aplicativos sem uma configuração específica.

gcloud

  1. Defina as configurações de acesso em um arquivo de vinculação YAML usando o campo dryRunSettings.

    scopedAccessSettings:
- scope:
    clientScope:
      restrictedClientApplication:
        name: CLIENT_NAME
  activeSettings:
    accessLevels:
    - ACCESS_LEVEL_A
  dryRunSettings:
    accessLevels:
    - DRY_RUN_ACCESS_LEVEL_1
- scope:
    clientScope:
      restrictedClientApplication:
        clientId: CLIENT_ID
  dryRunSettings:
    accessLevels:
    - DRY_RUN_ACCESS_LEVEL_2

    Substitua:

    • CLIENT_NAME: o nome do cliente. É possível usar name ou clientId quando um aplicativo contém sessionSettings.
    • ACCESS_LEVEL_A: um nome de nível de acesso no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: um nome de nível de acesso no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: o ID do cliente OAuth. É possível usar clientId ou name quando um aplicativo contém sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2: um nome de nível de acesso no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Crie a vinculação de acesso.

    gcloud access-context-manager cloud-bindings create \
  --organization ORG_ID \
  --group-key GROUP_ID \
  --binding-file BINDING_FILE_PATH
  --dry-run-level DEFAULT_DRY_RUN_ACCESS_LEVEL

    Substitua:

    • ORG_ID: o ID da organização.
    • GROUP_ID: o ID do grupo. Se você não tiver o ID do grupo disponível, poderá recuperá-lo chamando o método get no recurso do grupo.
    • BINDING_FILE_PATH: o caminho para o arquivo YAML que contém o esquema de vinculação de acesso. O arquivo de vinculação é compatível apenas com scopedAccessSettings.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: um nome opcional de nível de acesso de simulação no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Inclua essa flag para aplicar o nível de acesso de simulação especificado a todos os aplicativos por padrão, se eles não estiverem especificados no YAML.

API

  1. Crie um corpo JSON:

    {
  "group_key": "GROUP_ID",
  //
  // Optional; if specified, all applications that aren't defined in scopedAccessSettings will have these dry-run access levels applied.
  //
  "dry_run_access_levels": [
    "DEFAULT_DRY_RUN_ACCESS_LEVEL"
  ],
  "scoped_access_settings": [
    {
      "scope": {
        "client_scope": {
          "restricted_client_application": {
            "name": "CLIENT_NAME"
          }
        }
      },
      "active_settings": {
        "access_levels": [
          "ACCESS_LEVEL_A"
        ]
      },
      "dry_run_settings": {
        "access_levels": [
          "DRY_RUN_ACCESS_LEVEL_1"
        ]
      }
    },
    {
      "scope": {
        "client_scope": {
          "restricted_client_application": {
            "client_id": "CLIENT_ID"
          }
        }
      },
      "dry_run_settings": {
        "access_levels": [
          "DRY_RUN_ACCESS_LEVEL_2"
        ]
      }
    }
  ]
}

    Substitua:

    • GROUP_ID: o ID do grupo. Se você não tiver o ID do grupo disponível, poderá recuperá-lo chamando o método get no recurso do grupo.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: um nome opcional de nível de acesso de simulação no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_NAME: o nome do cliente. É possível usar name ou clientId quando um aplicativo contém sessionSettings.
    • ACCESS_LEVEL_A: um nome de nível de acesso no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: um nome de nível de acesso no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: o ID do cliente OAuth. É possível usar client_id ou name quando um aplicativo contém sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2: um nome de nível de acesso no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Envie a solicitação POST:

    POST https://accesscontextmanager.googleapis.com/v1/organizations/ORG_ID/gcpUserAccessBindings

    ORG_ID é o ID da organização que você usou para criar o papel de administrador de vinculação de acesso ao Cloud. Se a propriedade access-context-manager/organization não tiver sido definida, substitua ORG_ID na flag opcional --organization pelo ID da organização que você usou ao criar o papel de administrador de vinculação de acesso ao Cloud.

    Se for bem-sucedido, você vai receber uma representação do objeto JSON. Se ocorrer um problema, você vai receber uma mensagem de erro.

Ver os registros de simulação

Depois de configurar uma simulação, verifique os registros para ver quais tentativas de acesso teriam sido negadas.

A tabela a seguir lista os campos de registro que podem ser usados para criar e executar a consulta para receber os registros:

Nome do campo Descrição
protoPayload.authenticationInfo.principalEmail ID de e-mail do principal que teve o acesso negado.
protoPayload.metadata.deniedApplications Nome do aplicativo que teve o acesso negado.
protoPayload.metadata.evaluationResult O resultado da avaliação da política de acesso ativa. Valores possíveis: GRANTED ou DENIED. Se nenhum nível de acesso ativo for aplicado na vinculação, esse campo será definido como GRANTED.
protoPayload.metadata.appliedAccessLevels Os níveis de acesso aplicados exigidos pela política de acesso ativa.
protoPayload.metadata.appliedDryRunAccessLevels Os níveis de acesso aplicados exigidos pela política de acesso de simulação.
protoPayload.metadata.dryRunEvaluationResult O resultado da avaliação da política de acesso de simulação, que indica a ação pretendida quando a política de acesso é aplicada. Valores possíveis: GRANTED ou DENIED. Se nenhum nível de acesso de simulação for aplicado na vinculação, esse campo será definido como GRANTED, mesmo quando evaluationResult for DENIED.
protoPayload.metadata.unsatisfiedAccessLevels Os níveis de acesso na organização que a solicitação não conseguiu atender. Essa lista pode incluir níveis de acesso que não são aplicados na vinculação de acesso. Para identificar quais níveis de acesso causaram uma negação de acesso, compare esse campo com appliedAccessLevels ou appliedDryRunAccessLevels.

Para instruções sobre como criar uma consulta para registros, consulte Linguagem de consulta do Logging.