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 os 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 tudo esteja configurado corretamente, teste suas 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 vai receber acesso se qualquer política permitir (OR, não AND).
  • Para controles de sessão, apenas a vinculação de acesso mais recente é 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 a 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 sua organização.
  • DEFAULT_ACCESS_LEVEL: o nome opcional do nível de acesso, que tem 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 usando o formato de duração ISO 8601, como 30m para 30 minutos ou 2h para duas horas.
  • DEFAULT_SESSION_REAUTH_METHOD: o método opcional para solicitar que os usuários revalidem a identidade, que precisa ser um dos seguintes:
    • LOGIN: aplique o login padrão, que pode incluir MFA ou outros fatores definidos pelo Workspace.
    • PASSWORD: exige apenas uma senha, mesmo que outros fatores sejam 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 vão precisar 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 tem 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 usando o formato de duração ISO 8601, como 30m para 30 minutos ou 2h para duas horas.
    • DEFAULT_SESSION_REAUTH_METHOD: o método opcional para solicitar que os usuários revalidem a identidade, que precisa ser um dos seguintes:
      • LOGIN: aplique o login padrão, que pode incluir MFA ou outros fatores definidos pelo Workspace.
      • PASSWORD: exige apenas uma senha, mesmo que outros fatores sejam 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 vão precisar 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 --organization opcional pelo ID da organização que você usou ao criar o papel de administrador da vinculação de acesso do Cloud.

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

Definir configurações para aplicativos específicos

Esse método permite 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. Esse método é útil quando você quer fazer o seguinte:

  • Aplicar políticas apenas a determinados aplicativos.

  • Crie uma política geral, mas exclua 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:
        #
        # because this app is specified by `name`,
        # it won't work with sessionSettings.
        #
        # if you add sessionSettings, make sure to
        # replace the `name` key with `clientId`,
        # and use the OAuth client ID as the value.
        #
        name: CLIENT_NAME
  activeSettings:
    accessLevels:
    - ACCESS_LEVEL_B

    Substitua:

    • CLIENT_ID: o ID do cliente OAuth. É necessário usar 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.
    • SESSION_LENGTH: a duração da sessão usando o formato de duração ISO 8601, como 30m para 30 minutos ou 2h para duas horas.

    • SESSION_REAUTH_METHOD: o método opcional para pedir aos usuários que revalidem a identidade, que precisa ser um dos seguintes:

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

    • CLIENT_NAME: o nome do cliente. Se o aplicativo contiver sessionSettings, não será possível usar o nome do cliente. Em vez disso, use o ID do cliente OAuth.

    • 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 oferece suporte apenas a 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 sua 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 só oferece suporte a scopedAccessSettings.
    • DEFAULT_ACCESS_LEVEL: o nome opcional do nível de acesso, que tem 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 usando o formato de duração ISO 8601, como 30m para 30 minutos ou 2h para duas horas.
    • DEFAULT_SESSION_REAUTH_METHOD: o método opcional para solicitar que os usuários revalidem a identidade, que precisa ser um dos seguintes:
      • LOGIN: aplique o login padrão, que pode incluir MFA ou outros fatores definidos pelo Workspace.
      • PASSWORD: exige apenas uma senha, mesmo que outros fatores sejam 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 vão precisar 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, apenas 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 no arquivo YAML terão prioridade. O valor --level se aplica a todos os aplicativos que não estão listados 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, esses controles vão substituir as configurações padrão para esses aplicativos específicos.
  • É necessário usar --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 tem 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. É necessário usar 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.
  • SESSION_LENGTH: a duração da sessão usando o formato de duração ISO 8601, como 30m para 30 minutos ou 2h para duas horas.

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

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

  • CLIENT_NAME: o nome do cliente. Se o aplicativo contiver sessionSettings, não será possível usar o nome do cliente. Em vez disso, use o ID do cliente OAuth.

  • 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 --organization opcional pelo ID da organização que você usou ao criar o papel de administrador da vinculação de acesso do Cloud.

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

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

Os níveis de acesso de simulação permitem testar suas políticas de acesso sem aplicá-las. Isso ajuda a entender o impacto de uma política antes de ela ser ativada. É possível acessar os registros de simulação para saber 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 vinculação de simulação

É possível definir níveis de acesso de simulação junto com os níveis de acesso normais na mesma vinculação ou usar vinculações separadas para simulações.

gcloud

  1. Defina as configurações de acesso.

    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. Se o aplicativo contiver sessionSettings, não será possível usar o nome do cliente. Em vez disso, use o ID do cliente OAuth.
    • 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. É necessário usar clientId 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 sua 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 só oferece suporte a scopedAccessSettings.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL_2: um nome de nível de acesso opcional no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Inclua essa flag para aplicar o nível de acesso de teste especificado a todos os aplicativos por padrão, caso eles não sejam especificados no YAML.

API

  1. Crie um corpo JSON:

    {
  "group_key": "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
   // be applied by default.
   //
  "access_levels": [
    "DEFAULT_ACCESS_LEVEL"
  ],
   //
   // 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"
          }
        }
      },
      "active_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_ACCESS_LEVEL: o nome opcional do nível de acesso, que tem 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_DRY_RUN_ACCESS_LEVEL: um nome de nível de acesso opcional no formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_NAME: o nome do cliente. Se o aplicativo contiver sessionSettings, não será possível usar o nome do cliente. Em vez disso, use o ID do cliente OAuth.
    • 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. É necessário usar client_id 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:

    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 --organization opcional pelo ID da organização que você usou ao criar o papel de administrador da vinculação de acesso ao Cloud.

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

Conferir os registros de simulação

Depois de configurar um teste, é possível verificar os registros para saber 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 e receber os registros:

Nome do campo Descrição
protoPayload.authenticationInfo.principalEmail ID de e-mail do principal a que o acesso foi negado.
protoPayload.metadata.deniedApplications Nome do app que teve o acesso negado.
protoPayload.metadata.evaluationResult O resultado da avaliação da política de acesso ativo. Valores possíveis: GRANTED ou DENIED.
protoPayload.metadata.appliedAccessLevels Os níveis de acesso aplicados exigidos pela política de acesso ativo.
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.

Para saber como criar uma consulta de registros, consulte Linguagem de consulta do Logging.