Aplicar políticas a grupos de usuarios mediante enlaces de acceso

Puedes usar enlaces de acceso para controlar a qué aplicaciones y recursos pueden acceder tus grupos de usuarios. Un enlace de acceso especifica cómo aplicar niveles de acceso y controles de sesión a un grupo de usuarios. Puedes aplicar el mismo nivel de acceso y control de sesión a todas las aplicaciones o definir comportamientos específicos para cada aplicación.

Para asegurarte de que has configurado todo correctamente, puedes probar tus políticas antes de aplicarlas.

Cuando trabajes con enlaces de acceso, ten en cuenta lo siguiente:

  • Un grupo de usuarios solo puede tener un enlace de acceso.
  • Si un usuario pertenece a varios grupos, se le concede acceso si alguna política lo permite (OR no AND).
  • En el caso de los controles de sesión, solo se aplica el enlace de acceso creado más recientemente.

Usar una sola configuración para todas las aplicaciones

Este método aplica el mismo nivel de acceso y control de sesión a todas las aplicaciones a las que accede un grupo de usuarios.

Te recomendamos que pruebes tu política con una prueba general o que la apliques a un pequeño grupo de prueba antes de implementarla en producción.

gcloud

Crea el enlace de acceso.

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  ]

Haz los cambios siguientes:

  • GROUP_ID: el ID del grupo. Si no tienes el ID del grupo, puedes obtenerlo llamando al método get en el recurso de grupo.
  • ORG_ID: el ID de tu organización.
  • DEFAULT_ACCESS_LEVEL: nombre de nivel de acceso opcional, que tiene el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sustituye POLICY_ID por el ID de la política de acceso y ACCESS_LEVEL_NAME por el nombre del nivel de acceso.
  • DEFAULT_SESSION_LENGTH: duración de la sesión opcional en formato de duración ISO 8601, como 30m para 30 minutos o 2h para dos horas.
  • DEFAULT_SESSION_REAUTH_METHOD: método opcional para pedir a los usuarios que vuelvan a verificar su identidad. Debe ser uno de los siguientes:
    • LOGIN: aplica el inicio de sesión estándar, que puede incluir la autenticación multifactor u otros factores definidos por Workspace.
    • PASSWORD: solo se requiere una contraseña, aunque se hayan definido otros factores. Si las contraseñas se gestionan con un proveedor de identidades externo, se redirige a los usuarios al proveedor de identidades. Si la sesión del IdP está activa, los usuarios se vuelven a autenticar de forma implícita. Si el proveedor de identidades no está activo, los usuarios deben iniciar sesión a través de él.
    • SECURITY_KEY: requiere una llave de seguridad de hardware.

API

  1. Crea un cuerpo JSON:

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

    Haz los cambios siguientes:

    • GROUP_ID: el ID del grupo. Si no tienes el ID del grupo, puedes obtenerlo llamando al método get en el recurso de grupo.
    • DEFAULT_ACCESS_LEVEL: nombre de nivel de acceso opcional, que tiene el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sustituye POLICY_ID por el ID de la política de acceso y ACCESS_LEVEL_NAME por el nombre del nivel de acceso.
    • DEFAULT_SESSION_LENGTH: duración de la sesión opcional en formato de duración ISO 8601, como 30m para 30 minutos o 2h para dos horas.
    • DEFAULT_SESSION_REAUTH_METHOD: método opcional para pedir a los usuarios que vuelvan a verificar su identidad. Debe ser uno de los siguientes:
      • LOGIN: aplica el inicio de sesión estándar, que puede incluir la autenticación multifactor u otros factores definidos por Workspace.
      • PASSWORD: solo se requiere una contraseña, aunque se hayan definido otros factores. Si las contraseñas se gestionan con un proveedor de identidades externo, se redirige a los usuarios al proveedor de identidades. Si la sesión del IdP está activa, los usuarios se vuelven a autenticar de forma implícita. Si el proveedor de identidades no está activo, los usuarios deben iniciar sesión a través de él.
      • SECURITY_KEY: requiere una llave de seguridad de hardware.

  2. Envía la solicitud POST:

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

    ORG_ID Es el ID de la organización que has usado para crear el rol Administrador de enlace de acceso de Cloud. Si no se ha definido la propiedad access-context-manager/organization, sustituye ORG_ID en la marca opcional --organization por el ID de la organización que usaste al crear el rol Administrador de enlaces de acceso a Cloud.

Si se ejecuta correctamente, deberías recibir una representación del objeto JSON. Si hay algún problema, recibirás un mensaje de error.

Definir configuraciones para aplicaciones específicas

Este método te permite aplicar diferentes niveles de acceso y controles de sesión a distintas aplicaciones. También puedes definir reglas predeterminadas para las aplicaciones que no tengan configuraciones específicas.

Puedes especificar aplicaciones en las vinculaciones de acceso mediante su ID de cliente de OAuth. Puedes especificar las siguientes aplicaciones con su nombre:

Este método es útil si quieres hacer lo siguiente:

  • Aplicar políticas solo a determinadas aplicaciones.

  • Crea una política general, pero excluye algunas aplicaciones.

gcloud

  1. Crea un archivo de vinculación en formato YAML con una lista de entradas de ámbito dentro de la lista scopedAccessSettings. Por cada aplicación que quieras asignar a un nivel de acceso específico, incluye una 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

    Haz los cambios siguientes:

    • CLIENT_ID: el ID de cliente de OAuth. Debes usar clientId cuando una aplicación contenga sessionSettings.
    • ACCESS_LEVEL_A: nombre de un nivel de acceso con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • SESSION_LENGTH: duración de la sesión en formato de duración ISO 8601, como 30m para 30 minutos o 2h para dos horas.

    • SESSION_REAUTH_METHOD: método opcional para pedir a los usuarios que vuelvan a verificar su identidad. Debe ser uno de los siguientes:

      • LOGIN: aplica el inicio de sesión estándar, que puede incluir la autenticación multifactor u otros factores definidos por Workspace.
      • PASSWORD: Solo se requiere una contraseña, aunque se hayan definido otros factores. Si las contraseñas se gestionan mediante un IdP externo, se redirige a los usuarios al IdP. Si la sesión del IdP está activa, los usuarios se vuelven a autenticar de forma implícita. Si el IdP no está activo, los usuarios deben iniciar sesión a través del IdP.
      • SECURITY_KEY: requiere una llave de seguridad de hardware.

    • CLIENT_NAME: el nombre del cliente. Si la solicitud contiene sessionSettings, no puede usar el nombre del cliente. En su lugar, usa el ID de cliente de OAuth.

    • ACCESS_LEVEL_B: nombre de un nivel de acceso con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Para definir un nivel de acceso predeterminado para las aplicaciones que no estén definidas en el archivo YAML, usa el argumento --level. El archivo YAML solo admite ajustes específicos de la aplicación (scopedAccessSettings).

  2. Crea el enlace de acceso.

    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  ]

    Haz los cambios siguientes:

    • ORG_ID: el ID de tu organización.
    • GROUP_ID: el ID del grupo. Si no tienes el ID del grupo, puedes obtenerlo llamando al método get en el recurso de grupo.
    • BINDING_FILE_PATH: ruta al archivo YAML que contiene el esquema de vinculación de acceso. El archivo de vinculación solo admite scopedAccessSettings.
    • DEFAULT_ACCESS_LEVEL: nombre de nivel de acceso opcional, que tiene el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sustituye POLICY_ID por el ID de la política de acceso y ACCESS_LEVEL_NAME por el nombre del nivel de acceso.
    • DEFAULT_SESSION_LENGTH: duración de la sesión opcional en formato de duración ISO 8601, como 30m para 30 minutos o 2h para dos horas.
    • DEFAULT_SESSION_REAUTH_METHOD: método opcional para pedir a los usuarios que vuelvan a verificar su identidad. Debe ser uno de los siguientes:
      • LOGIN: aplica el inicio de sesión estándar, que puede incluir la autenticación multifactor u otros factores definidos por Workspace.
      • PASSWORD: solo se requiere una contraseña, aunque se hayan definido otros factores. Si las contraseñas se gestionan con un proveedor de identidades externo, se redirige a los usuarios al proveedor de identidades. Si la sesión del IdP está activa, los usuarios se vuelven a autenticar de forma implícita. Si el proveedor de identidades no está activo, los usuarios deben iniciar sesión a través de él.
      • SECURITY_KEY: requiere una llave de seguridad de hardware.

Cómo funcionan juntos los argumentos --level y --binding-file

  • Si solo usas --binding-file, solo se aplicarán las políticas a las aplicaciones del archivo.
  • Si solo usas --level, el nivel de acceso se aplica a todas las aplicaciones.
  • Si usas ambas, las reglas se combinan. El valor --level se aplica a todas las aplicaciones, mientras que las políticas del archivo YAML especificado por --binding-file solo se aplican a las aplicaciones definidas en el archivo.

Trabajar con los controles de sesión

  • Para definir los controles de sesión predeterminados de todas las aplicaciones, usa --session-length y --session-reauth-method.
  • Si también defines controles de sesión en el archivo YAML, esos controles de sesión anularán la configuración predeterminada de esas aplicaciones específicas.
  • Debes usar --session-length y --session-reauth-method al mismo tiempo.

API

Crea un cuerpo 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"
          ]
        }
      }
    }
  ]
}

Haz los cambios siguientes:

  • GROUP_ID: el ID del grupo. Si no tienes el ID del grupo, puedes obtenerlo llamando al método get en el recurso de grupo.
  • DEFAULT_ACCESS_LEVEL: nombre de nivel de acceso opcional, que tiene el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sustituye POLICY_ID por el ID de la política de acceso y ACCESS_LEVEL_NAME por el nombre del nivel de acceso.
  • CLIENT_ID: el ID de cliente de OAuth. Debes usar clientId cuando una aplicación contenga sessionSettings.
  • ACCESS_LEVEL_A: nombre de un nivel de acceso con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
  • SESSION_LENGTH: la duración de la sesión en formato de duración ISO 8601, como 30m para 30 minutos o 2h para dos horas.

  • SESSION_REAUTH_METHOD: método opcional para pedir a los usuarios que vuelvan a verificar su identidad. Debe ser uno de los siguientes:

    • LOGIN: aplica el inicio de sesión estándar, que puede incluir la autenticación multifactor u otros factores definidos por Workspace.
    • PASSWORD: Solo se requiere una contraseña, aunque se hayan definido otros factores. Si las contraseñas se gestionan mediante un IdP externo, se redirige a los usuarios al IdP. Si la sesión del IdP está activa, los usuarios se vuelven a autenticar de forma implícita. Si el IdP no está activo, los usuarios deben iniciar sesión a través del IdP.
    • SECURITY_KEY: requiere una llave de seguridad de hardware.

  • CLIENT_NAME: el nombre del cliente. Si la aplicación contiene sessionSettings, no puedes usar el nombre del cliente. En su lugar, usa el ID de cliente de OAuth.

  • ACCESS_LEVEL_B: nombre de un nivel de acceso con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

Envía la solicitud POST:

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

ORG_ID es el ID de la organización que has usado para crear el rol Administrador de enlace de acceso de Cloud. Si no se ha definido la propiedad access-context-manager/organization, sustituye ORG_ID en la marca opcional --organization por el ID de la organización que usaste al crear el rol Administrador de enlaces de acceso a Cloud.

Si se realiza correctamente, deberías recibir una representación del objeto JSON o un mensaje de error si ha habido algún problema.

Usar niveles de acceso de prueba para simular la aplicación

Los niveles de acceso de prueba te permiten probar tus políticas de acceso sin aplicarlas. De esta forma, puedes conocer el impacto de una política antes de que se publique. Puedes ver los registros de la prueba para saber qué habría ocurrido si la política estuviera activa.

Solo se pueden usar niveles de acceso en el modo de prueba. Los controles de sesión no están disponibles en el modo de ejecución de prueba.

Crear un enlace de prueba

Puedes definir niveles de acceso de prueba junto con niveles de acceso normales en el mismo enlace o usar enlaces independientes para las pruebas.

gcloud

  1. Configura los ajustes de acceso.

    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

    Haz los cambios siguientes:

    • CLIENT_NAME: el nombre del cliente. Si la solicitud contiene sessionSettings, no puede usar el nombre del cliente. En su lugar, usa el ID de cliente de OAuth.
    • ACCESS_LEVEL_A: nombre de un nivel de acceso con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: nombre de un nivel de acceso con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: el ID de cliente de OAuth. Debes usar clientId cuando una aplicación contenga sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2: nombre de un nivel de acceso con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Crea el enlace de acceso.

    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

    Haz los cambios siguientes:

    • ORG_ID: el ID de tu organización.
    • GROUP_ID: el ID del grupo. Si no tienes el ID del grupo, puedes obtenerlo llamando al método get en el recurso de grupo.
    • BINDING_FILE_PATH: ruta al archivo YAML que contiene el esquema de vinculación de acceso. El archivo de vinculación solo admite scopedAccessSettings.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL_2: nombre de nivel de acceso opcional con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Incluya esta marca para aplicar el nivel de acceso de prueba especificado a todas las aplicaciones de forma predeterminada si no se especifican en el archivo YAML.

API

  1. Crea un cuerpo 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"
        ]
      }
    }
  ]
}

    Haz los cambios siguientes:

    • GROUP_ID: el ID del grupo. Si no tienes el ID del grupo, puedes obtenerlo llamando al método get en el recurso de grupo.
    • DEFAULT_ACCESS_LEVEL: nombre de nivel de acceso opcional, que tiene el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sustituye POLICY_ID por el ID de la política de acceso y ACCESS_LEVEL_NAME por el nombre del nivel de acceso.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: nombre de nivel de acceso opcional con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_NAME: el nombre del cliente. Si la solicitud contiene sessionSettings, no puede usar el nombre del cliente. En su lugar, usa el ID de cliente de OAuth.
    • ACCESS_LEVEL_A: nombre de un nivel de acceso con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: nombre de nivel de acceso con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: el ID de cliente de OAuth. Debes usar client_id cuando una aplicación contenga sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2: nombre de nivel de acceso con el formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Envía la solicitud POST:

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

    ORG_ID Es el ID de la organización que has usado para crear el rol Administrador de enlace de acceso de Cloud. Si no se ha definido la propiedad access-context-manager/organization, sustituye ORG_ID en la marca opcional --organization por el ID de la organización que usaste al crear el rol Administrador de enlaces de acceso a Cloud.

    Si se ejecuta correctamente, deberías recibir una representación del objeto JSON. Si hay algún problema, recibirás un mensaje de error.

Ver los registros de la prueba

Después de configurar una prueba, puedes consultar los registros para ver qué intentos de acceso se habrían denegado.

En la siguiente tabla se indican los campos de registro que puede usar para crear y ejecutar la consulta con la que obtener los registros:

Nombre del campo Descripción
protoPayload.authenticationInfo.principalEmail ID de correo del principal al que se le ha denegado el acceso.
protoPayload.metadata.deniedApplications Nombre de la aplicación cuyo acceso se ha denegado.
protoPayload.metadata.evaluationResult El resultado de la evaluación de la política de acceso activa. Valores posibles: GRANTED o DENIED.
protoPayload.metadata.appliedAccessLevels Los niveles de acceso aplicados que requiere la política de acceso activa.
protoPayload.metadata.appliedDryRunAccessLevels Los niveles de acceso aplicados que requiere la política de acceso de la prueba.
protoPayload.metadata.dryRunEvaluationResult El resultado de la evaluación de la política de acceso de la prueba, que indica la acción prevista cuando se aplique la política de acceso. Valores posibles: GRANTED o DENIED.

Para obtener información sobre cómo crear una consulta de registros, consulta Lenguaje de consultas de almacenamiento de registros.