Applicare criteri ai gruppi di utenti utilizzando le associazioni di accesso

Puoi utilizzare le associazioni di accesso per controllare a quali applicazioni e risorse possono accedere i tuoi gruppi di utenti. Un'associazione di accesso specifica come applicare i livelli di accesso e i controlli della sessione a un gruppo di utenti. Puoi applicare lo stesso livello di accesso e il medesimo controllo delle sessioni a tutte le applicazioni oppure puoi definire comportamenti specifici per le singole applicazioni.

Per assicurarti di aver configurato tutto correttamente, puoi testare i criteri prima di applicarli.

Quando utilizzi le associazioni di accesso, tieni presente il seguente comportamento:

  • Un gruppo di utenti può avere una sola associazione di accesso.
  • Se un utente appartiene a più gruppi, gli viene concesso l'accesso se un criterio lo consente (OR, non AND).
  • Per i controlli della sessione, viene applicata solo l'associazione di accesso creata più di recente.

Utilizzare una singola configurazione per tutte le applicazioni

Questo metodo applica lo stesso livello di accesso e controllo delle sessioni a tutte le applicazioni a cui accede un gruppo di utenti.

Ti consigliamo di testare il criterio con una prova simulata o di applicarlo a un piccolo gruppo di test prima di implementarlo in produzione.

gcloud

Crea l'associazione di accesso.

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  ]

Sostituisci quanto segue:

  • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa gruppo.
  • ORG_ID: l'ID della tua organizzazione.
  • DEFAULT_ACCESS_LEVEL: il nome facoltativo del livello di accesso, che ha il formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID del criterio di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
  • DEFAULT_SESSION_LENGTH: la durata facoltativa della sessione nel formato ISO 8601, ad esempio 30m per 30 minuti o 2h per due ore.
  • DEFAULT_SESSION_REAUTH_METHOD: il metodo facoltativo per chiedere agli utenti di verificare nuovamente la loro identità, che deve essere uno dei seguenti:
    • LOGIN: applica l'accesso standard, che può includere l&#MFA o altri fattori definiti da Workspace.
    • PASSWORD: richiede solo una password, anche se sono definiti altri fattori. Se le password vengono gestite utilizzando un IdP esterno, gli utenti vengono reindirizzati all'IdP. Se la sessione dell'IdP è attiva, gli utenti vengono autenticati nuovamente in modo implicito. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
    • SECURITY_KEY: richiede un token di sicurezza hardware.

API

  1. Crea un corpo JSON:

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

    Sostituisci quanto segue:

    • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa gruppo.
    • DEFAULT_ACCESS_LEVEL: il nome facoltativo del livello di accesso, che ha il formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID del criterio di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
    • DEFAULT_SESSION_LENGTH: la durata facoltativa della sessione nel formato ISO 8601, ad esempio 30m per 30 minuti o 2h per due ore.
    • DEFAULT_SESSION_REAUTH_METHOD: il metodo facoltativo per chiedere agli utenti di verificare nuovamente la loro identità, che deve essere uno dei seguenti:
      • LOGIN: applica l'accesso standard, che può includere l&#MFA o altri fattori definiti da Workspace.
      • PASSWORD: richiede solo una password, anche se sono definiti altri fattori. Se le password vengono gestite utilizzando un IdP esterno, gli utenti vengono reindirizzati all'IdP. Se la sessione dell'IdP è attiva, gli utenti vengono autenticati nuovamente in modo implicito. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
      • SECURITY_KEY: richiede un token di sicurezza hardware.

  2. Invia la richiesta POST:

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

    ORG_ID è l'ID dell'organizzazione che hai utilizzato per creare il ruolo Amministratore di associazioni di accesso a Cloud. Se la proprietà access-context-manager/organization non è stata impostata, sostituisci ORG_ID nel flag facoltativo --organization con l'ID dell'organizzazione che hai utilizzato quando hai creato il ruolo Amministratore di associazioni di accesso a Cloud.

In caso di esito positivo, dovresti ricevere una rappresentazione dell'oggetto JSON. Se si verifica un problema, riceverai un messaggio di errore.

Definire configurazioni per applicazioni specifiche

Questo metodo ti consente di applicare diversi livelli di accesso e controlli delle sessioni a diverse applicazioni. Puoi anche impostare regole predefinite per le applicazioni che non hanno configurazioni specifiche. Questo metodo è utile se vuoi svolgere le seguenti operazioni:

  • Applica i criteri solo a determinate applicazioni.

  • Crea un criterio generale, ma escludivi alcune applicazioni.

gcloud

  1. Crea un file di binding in formato YAML con un elenco di voci di ambito all'interno dell'elenco scopedAccessSettings. Per ogni applicazione da mappare a un livello di accesso specifico, includi una voce clientScope.

    scopedAccessSettings:
  - scope:
      clientScope:
        restrictedClientApplication:
          client_id: CLIENT_ID
    activeSettings:
      accessLevels:
        - ACCESS_LEVEL_A
        - ACCESS_LEVEL_B
      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 `client_id`, 
          # and use the OAuth client ID as the value.
          #
          name: CLIENT_NAME
      activeSettings:
        accessLevels:
        - ACCESS_LEVEL_C

    Sostituisci quanto segue:

    • CLIENT_ID: l'ID client OAuth. Devi utilizzare client_id quando un'applicazione contiene sessionSettings.
    • ACCESS_LEVEL_A: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • ACCESS_LEVEL_B: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • SESSION_LENGTH: la durata della sessione nel formato della durata ISO 8601, ad esempio 30m per 30 minuti o 2h per due ore.

    • SESSION_REAUTH_METHOD: il metodo facoltativo per chiedere agli utenti di verificare nuovamente la propria identità, che deve essere uno dei seguenti:

      • LOGIN: applica l'accesso standard, che può includere l&#MFA o altri fattori definiti da Workspace.
      • PASSWORD: Richiedi solo una password, anche se sono definiti altri fattori. Se le password vengono gestite utilizzando un IdP esterno, gli utenti vengono reindirizzati all'IdP. Se la sessione dell'IdP è attiva, gli utenti vengono implicitamente ri-autenticati. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
      • SECURITY_KEY: richiede un token di sicurezza hardware.

    • CLIENT_NAME: il nome del client. Se l'applicazione contienesessionSettings, non puoi utilizzare il nome del cliente. Utilizza invece l'ID client OAuth.

    • ACCESS_LEVEL_C: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Per impostare un livello di accesso predefinito per le applicazioni non definite nel file YAML, utilizza l'argomento --level. Il file YAML supporta solo impostazioni specifiche per l'applicazione (scopedAccessSettings).

  2. Crea l'associazione di accesso.

    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  ]

    Sostituisci quanto segue:

    • ORG_ID: l'ID della tua organizzazione.
    • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa gruppo.
    • BINDING_FILE_PATH: il percorso del file YAML contenente lo schema di associazione dell'accesso. Il file di binding supporta solo scopedAccessSettings.
    • DEFAULT_ACCESS_LEVEL: il nome facoltativo del livello di accesso, che ha il formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID del criterio di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
    • DEFAULT_SESSION_LENGTH: la durata facoltativa della sessione nel formato ISO 8601, ad esempio 30m per 30 minuti o 2h per due ore.
    • DEFAULT_SESSION_REAUTH_METHOD: il metodo facoltativo per chiedere agli utenti di verificare nuovamente la loro identità, che deve essere uno dei seguenti:
      • LOGIN: applica l'accesso standard, che può includere l&#MFA o altri fattori definiti da Workspace.
      • PASSWORD: richiede solo una password, anche se sono definiti altri fattori. Se le password vengono gestite utilizzando un IdP esterno, gli utenti vengono reindirizzati all'IdP. Se la sessione dell'IdP è attiva, gli utenti vengono autenticati nuovamente in modo implicito. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
      • SECURITY_KEY: richiede un token di sicurezza hardware.

Come interagiscono gli argomenti --level e --binding-file

  • Se utilizzi solo --binding-file, le norme vengono applicate solo alle applicazioni nel file.
  • Se utilizzi solo --level, il livello di accesso si applica a tutte le applicazioni.
  • Se utilizzi entrambi, le regole nel file YAML hanno la priorità. Il valore --level si applica a tutte le applicazioni non elencate nel file.

Utilizzo dei controlli della sessione

  • Per impostare i controlli della sessione predefiniti per tutte le applicazioni, utilizza --session-length e --session-reauth-method.
  • Se nel file YAML definisci anche i controlli sessione, questi ultimi overrideranno le impostazioni predefinite per le applicazioni specifiche.
  • Devi utilizzare --session-length e --session-reauth-method contemporaneamente.

API

Crea un 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": {
            "client_id": "CLIENT_ID"
          }
        }
      },
      "activeSettings": {
        "accessLevels": [
          "ACCESS_LEVEL_A",
          "ACCESS_LEVEL_B"
        ],
        "sessionSettings": [
          {
            "sessionLength": "SESSION_LENGTH",
            "sessionReauthMethod": "SESSION_REAUTH_METHOD",
            "sessionLengthEnabled": true
          }
        ]
      }
    },
    {
      "scope": {
        "clientScope": {
          "restrictedClientApplication": {
            "name": "CLIENT_NAME"
          }
        },
        "activeSettings": {
          "accessLevels": [
            "ACCESS_LEVEL_C"
          ]
        }
      }
    }
  ]
}

Sostituisci quanto segue:

  • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa gruppo.
  • DEFAULT_ACCESS_LEVEL: il nome facoltativo del livello di accesso, che ha il formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID del criterio di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
  • CLIENT_ID: l'ID client OAuth. Devi utilizzare client_id quando un'applicazione contiene sessionSettings.
  • ACCESS_LEVEL_A: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
  • ACCESS_LEVEL_B: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
  • SESSION_LENGTH: la durata della sessione nel formato della durata ISO 8601, ad esempio 30m per 30 minuti o 2h per due ore.

  • SESSION_REAUTH_METHOD: il metodo facoltativo per chiedere agli utenti di verificare nuovamente la propria identità, che deve essere uno dei seguenti:

    • LOGIN: applica l'accesso standard, che può includere l&#MFA o altri fattori definiti da Workspace.
    • PASSWORD: Richiedi solo una password, anche se sono definiti altri fattori. Se le password vengono gestite utilizzando un IdP esterno, gli utenti vengono reindirizzati all'IdP. Se la sessione dell'IdP è attiva, gli utenti vengono implicitamente ri-autenticati. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
    • SECURITY_KEY: richiede un token di sicurezza hardware.

  • CLIENT_NAME: il nome del client. Se l'applicazione contiene sessionSettings, non puoi utilizzare il nome del cliente. Utilizza invece l'ID client OAuth.

  • ACCESS_LEVEL_C: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

Invia la richiesta POST:

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

ORG_ID è l'ID dell'organizzazione che hai utilizzato per creare il ruolo Cloud Access Binding Admin. Se la proprietà access-context-manager/organization non è stata impostata, sostituisci ORG_ID nel flag facoltativo --organization con l'ID dell'organizzazione che hai utilizzato quando hai creato il ruolo Amministratore di associazioni di accesso a Cloud.

In caso di esito positivo, dovresti ricevere una rappresentazione dell'oggetto JSON o un messaggio di errore se si è verificato un problema.

Utilizzare i livelli di accesso di prova per simulare l'applicazione

I livelli di accesso di prova ti consentono di testare i criteri di accesso senza applicarli effettivamente. In questo modo puoi comprendere l'impatto di un criterio prima che venga attivato. Puoi visualizzare i log del dry run per vedere cosa sarebbe successo se il criterio fosse stato attivo.

In modalità di prova è possibile utilizzare solo i livelli di accesso. I controlli sessione non sono disponibili in modalità dry run.

Creare un'associazione di prova

Puoi definire i livelli di accesso per i dry run insieme ai livelli di accesso regolari nella stessa binding oppure utilizzare binding separate per i dry run.

gcloud

  1. Configura le impostazioni di accesso.

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

    Sostituisci quanto segue:

    • CLIENT_NAME: il nome del client. Se l'applicazione contienesessionSettings, non puoi utilizzare il nome del cliente. Utilizza invece l'ID client OAuth.
    • ACCESS_LEVEL_A: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: l'ID client OAuth. Devi utilizzare client_id quando un'applicazione contiene sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Crea l'associazione di accesso.

    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

    Sostituisci quanto segue:

    • ORG_ID: l'ID della tua organizzazione.
    • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa gruppo.
    • BINDING_FILE_PATH: il percorso del file YAML contenente lo schema di associazione dell'accesso. Il file di binding supporta solo scopedAccessSettings.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL_2: un nome facoltativo del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Includi questo flag per applicare il livello di accesso per la simulazione specificato a tutte le applicazioni per impostazione predefinita, se non sono specificate nel file YAML.

API

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

    Sostituisci quanto segue:

    • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get sulla risorsa gruppo.
    • DEFAULT_ACCESS_LEVEL: il nome facoltativo del livello di accesso, che ha il formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID del criterio di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: un nome facoltativo del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_NAME: il nome del client. Se l'applicazione contienesessionSettings, non puoi utilizzare il nome del cliente. Utilizza invece l'ID client OAuth.
    • ACCESS_LEVEL_A: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: l'ID client OAuth. Devi utilizzare client_id quando un'applicazione contiene sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2: un nome del livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

  2. Invia la richiesta POST:

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

    ORG_ID è l'ID dell'organizzazione che hai utilizzato per creare il ruolo Amministratore di associazioni di accesso a Cloud. Se la proprietà access-context-manager/organization non è stata impostata, sostituisci ORG_ID nel flag facoltativo --organization con l'ID dell'organizzazione che hai utilizzato quando hai creato il ruolo Amministratore di associazioni di accesso a Cloud.

    In caso di esito positivo, dovresti ricevere una rappresentazione dell'oggetto JSON. Se si verifica un problema, riceverai un messaggio di errore.

Visualizza i log del dry run

Dopo aver configurato una simulazione, puoi controllare i log per vedere quali tentativi di accesso sare stati rifiutati.

La tabella seguente elenca i campi dei log che puoi utilizzare per creare ed eseguire la query per recuperare i log:

Nome campo Descrizione
protoPayload.authenticationInfo.principalEmail ID email dell'entità principale per cui l'accesso è negato.
protoPayload.metadata.deniedApplications Nome dell'applicazione per cui l'accesso è negato.
protoPayload.metadata.evaluationResult Il risultato della valutazione del criterio di accesso attivo. Valori possibili: GRANTED o DENIED.
protoPayload.metadata.appliedAccessLevels I livelli di accesso applicati richiesti dal criterio di accesso attivo.
protoPayload.metadata.appliedDryRunAccessLevels I livelli di accesso applicati richiesti dal criterio di accesso per la simulazione.
protoPayload.metadata.dryRunEvaluationResult Il risultato della valutazione del criterio di accesso di prova, che indica l'azione prevista quando il criterio di accesso viene applicato. Valori possibili: GRANTED o DENIED.

Per informazioni dettagliate su come creare una query per i log, consulta Lingua delle query di logging.