Applicare criteri ai gruppi di utenti utilizzando le associazioni di accesso

Puoi utilizzare i binding 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 controllo della sessione a tutte le applicazioni oppure puoi definire comportamenti specifici per singole applicazioni.

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

Quando lavori con i binding di accesso, tieni presente il seguente comportamento:

  • Un gruppo di utenti può avere un solo binding di accesso.
  • Se un utente appartiene a più gruppi, l'accesso viene concesso se una qualsiasi policy lo consente (OR e non AND).
  • Per i controlli della sessione, viene applicato solo il binding di accesso creato più di recente.

Utilizzare una singola configurazione per tutte le applicazioni

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

Ti consigliamo di testare le norme con una prova generale o di applicarle a un piccolo gruppo di test prima di implementarle 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 nella risorsa gruppo.
  • ORG_ID: l'ID organizzazione.
  • DEFAULT_ACCESS_LEVEL: il nome del livello di accesso facoltativo, che assume la forma accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID della policy di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
  • DEFAULT_SESSION_LENGTH: la durata facoltativa della sessione nel formato di durata 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 propria identità, che deve essere uno dei seguenti:
    • LOGIN: applica l'accesso standard, che può includere l&#MFA fattori 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 IdP è attiva, gli utenti vengono riautenticati implicitamente. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
    • SECURITY_KEY: richiedi un token di sicurezza fisico.

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 nella risorsa gruppo.
    • DEFAULT_ACCESS_LEVEL: il nome del livello di accesso facoltativo, che assume la forma accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID della policy di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
    • DEFAULT_SESSION_LENGTH: la durata facoltativa della sessione nel formato di durata 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 propria identità, che deve essere uno dei seguenti:
      • LOGIN: applica l'accesso standard, che può includere l&#MFA fattori 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 IdP è attiva, gli utenti vengono riautenticati implicitamente. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
      • SECURITY_KEY: richiedi un token di sicurezza fisico.

  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 binding di accesso al 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 binding di accesso al cloud.

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

Definisci 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.

Puoi specificare le applicazioni nei binding di accesso utilizzando il relativo ID client OAuth. Puoi specificare le seguenti applicazioni utilizzando il loro nome:

Questo metodo è utile se vuoi:

  • Applica i criteri solo a determinate applicazioni.

  • Crea un criterio generale, ma escludi 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 che vuoi mappare a un livello di accesso specifico, includi una voce 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

    Sostituisci quanto segue:

    • CLIENT_ID: l'ID client OAuth. Devi utilizzare clientId quando un'applicazione contiene sessionSettings.
    • ACCESS_LEVEL_A: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • SESSION_LENGTH: la durata della sessione utilizzando il 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 fattori 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 IdP è attiva, gli utenti vengono riautenticati implicitamente. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
      • SECURITY_KEY: richiedi un token di sicurezza fisico.

    • 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_B: il nome di un 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 dell'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 organizzazione.
    • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get nella risorsa gruppo.
    • BINDING_FILE_PATH: il percorso del file YAML contenente lo schema di binding di accesso. Il file di binding supporta solo scopedAccessSettings.
    • DEFAULT_ACCESS_LEVEL: il nome del livello di accesso facoltativo, che assume la forma accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID della policy di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
    • DEFAULT_SESSION_LENGTH: la durata facoltativa della sessione nel formato di durata 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 propria identità, che deve essere uno dei seguenti:
      • LOGIN: applica l'accesso standard, che può includere l&#MFA fattori 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 IdP è attiva, gli utenti vengono riautenticati implicitamente. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
      • SECURITY_KEY: richiedi un token di sicurezza fisico.

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

  • Se utilizzi solo --binding-file, solo alle applicazioni nel file vengono applicati i criteri.
  • Se utilizzi solo --level, il livello di accesso si applica a tutte le applicazioni.
  • Se utilizzi entrambe, le regole vengono combinate. Il valore --level si applica a tutte le applicazioni, mentre le norme nel file YAML specificato da --binding-file si applicano solo alle applicazioni definite 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 definisci anche i controlli della sessione nel file YAML, questi controlli della sessione sostituiscono le impostazioni predefinite per le applicazioni specifiche.
  • Devi utilizzare sia --session-length sia --session-reauth-method insieme.

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": {
            "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"
          ]
        }
      }
    }
  ]
}

Sostituisci quanto segue:

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

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

    • LOGIN: applica l'accesso standard, che può includere l&#MFA fattori 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 IdP è attiva, gli utenti vengono riautenticati implicitamente. Se l'IdP non è attivo, gli utenti devono accedere tramite l'IdP.
    • SECURITY_KEY: richiedi un token di sicurezza fisico.

  • 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_B: un nome di 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 binding di accesso al cloud.

Se l'operazione va a buon fine, dovresti ricevere una rappresentazione dell'oggetto JSON o un messaggio di errore in caso di problemi.

Utilizzare i livelli di accesso dry run per simulare l'applicazione

I livelli di accesso dry run ti consentono di testare le tue policy di accesso senza applicarle effettivamente. In questo modo puoi comprendere l'impatto di un criterio prima che venga pubblicato. Puoi visualizzare i log di dry run per vedere cosa sarebbe successo se la policy fosse stata attiva.

Nella modalità di prova possono essere utilizzati solo i livelli di accesso. I controlli sessione non sono disponibili in modalità dry run.

Crea un binding di prova

Puoi definire i livelli di accesso dry run insieme ai livelli di accesso regolari nello stesso binding oppure puoi utilizzare binding separati 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:
        clientId: CLIENT_ID
    dryRunSettings:
      accessLevels:
      - DRY_RUN_ACCESS_LEVEL_2

    Sostituisci quanto segue:

    • 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_A: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • CLIENT_ID: l'ID client OAuth. Devi utilizzare clientId quando un'applicazione contiene sessionSettings.
    • DRY_RUN_ACCESS_LEVEL_2: il nome di un 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 organizzazione.
    • GROUP_ID: l'ID gruppo. Se non hai a disposizione l'ID gruppo, puoi recuperarlo chiamando il metodo get nella risorsa gruppo.
    • BINDING_FILE_PATH: il percorso del file YAML contenente lo schema di binding di accesso. Il file di binding supporta solo scopedAccessSettings.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL_2: un nome di livello di accesso facoltativo nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.

    Includi questo flag per applicare il livello di accesso di prova 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 nella risorsa gruppo.
    • DEFAULT_ACCESS_LEVEL: il nome del livello di accesso facoltativo, che assume la forma accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME. Sostituisci POLICY_ID con l'ID della policy di accesso e ACCESS_LEVEL_NAME con il nome del livello di accesso.
    • DEFAULT_DRY_RUN_ACCESS_LEVEL: un nome di livello di accesso facoltativo nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • 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_A: il nome di un livello di accesso nel formato accessPolicies/POLICY_ID/accessLevels/ACCESS_LEVEL_NAME.
    • DRY_RUN_ACCESS_LEVEL_1: Un nome di 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 di 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 binding di accesso al 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 binding di accesso al cloud.

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

Visualizza i log dry run

Dopo aver configurato una prova generale, puoi controllare i log per vedere quali tentativi di accesso sarebbero stati negati.

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

Nome campo Descrizione
protoPayload.authenticationInfo.principalEmail ID email dell'entità per cui l'accesso è negato.
protoPayload.metadata.deniedApplications Nome dell'applicazione per cui l'accesso è negato.
protoPayload.metadata.evaluationResult Il risultato della valutazione della policy di accesso attiva. Valori possibili: GRANTED o DENIED.
protoPayload.metadata.appliedAccessLevels I livelli di accesso applicati richiesti dalla policy di accesso attiva.
protoPayload.metadata.appliedDryRunAccessLevels I livelli di accesso applicati richiesti dalla policy di accesso dry run.
protoPayload.metadata.dryRunEvaluationResult Il risultato della valutazione della policy di accesso dry run, che indica l'azione prevista quando la policy di accesso viene applicata. Valori possibili: GRANTED o DENIED.

Per informazioni dettagliate su come creare una query per i log, consulta Linguaggio di query di Logging.