Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Configurare l'accesso sensibile al contesto con Identity-Aware Proxy

Questa guida descrive come estendere le policy di accesso di Identity-Aware Proxy (IAP) utilizzando i livelli di accesso e il framework delle condizioni di Identity and Access Management (IAM). I livelli di accesso consentono di limitare l'accesso alle risorse in base all'indirizzo IP e agli attributi del dispositivo dell'utente finale. Le condizioni IAM consentono di limitare l'accesso in base a host, percorsi, data e ora degli URL.

Ad esempio, a seconda della configurazione della policy, la tua app sensibile può:

Concedere l'accesso a tutti i dipendenti se utilizzano un dispositivo aziendale attendibile dalla rete aziendale.
Concedere l'accesso ai dipendenti del gruppo Accesso remoto se utilizzano un dispositivo aziendale attendibile con una password sicura e un livello di patch aggiornato, da qualsiasi rete.
Concedere l'accesso ai dipendenti del gruppo Accesso con privilegi solo se il percorso dell'URL inizia con /admin.

Prima di iniziare

Prima di iniziare, avrai bisogno di quanto segue:

Un'app protetta con IAP a cui vuoi aggiungere l'accesso individuale o di gruppo.
I nomi degli utenti o dei gruppi a cui vuoi concedere l'accesso.

Configurare un livello di accesso

Per limitare l'accesso in base all'indirizzo IP o agli attributi del dispositivo dell'utente finale, crea un livello di accesso. Alcuni attributi, come gli attributi del dispositivo, richiedono una licenza Chrome Enterprise Premium. La convalida della licenza viene eseguita solo quando configuri i livelli di accesso e non influisce sull'accesso in fase di runtime. Per scoprire come creare un livello di accesso, consulta la guida di Gestore contesto accesso. IAP utilizza il nome del livello di accesso per associarlo a un'app protetta con IAP.

L'utilizzo di policy con ambito non è supportato da IAP. I livelli di accesso devono essere impostati nella policy di accesso dell'organizzazione. Per ulteriori informazioni, consulta Creare una policy di accesso.

Modificare la policy IAM

Un'app protetta con IAP ha una policy IAM che associa il ruolo IAP all'app.

Se aggiungi un'associazione condizionale IAM alla policy IAM, l'accesso alle tue risorse viene ulteriormente limitato in base agli attributi della richiesta. Questi attributi della richiesta includono:

Livelli di accesso
Host/percorso dell'URL
Data/Ora

Tieni presente che i valori della richiesta confrontati con request.host e request.path specificati in un'associazione condizionale IAM devono essere esatti. Ad esempio, se limiti l'accesso ai percorsi che iniziano con /internal admin, un utente può aggirare la limitazione accedendo a /internal%20admin. Per ulteriori informazioni sulle condizioni di nome host e percorso, consulta Utilizzare le condizioni di nome host e percorso.

Aggiungi e modifica le associazioni condizionali nella policy IAM seguendo la procedura riportata di seguito.

Console

Per aggiungere un'associazione condizionale utilizzando la Google Cloud console:

Vai alla pagina di amministrazione di IAP.
Vai a la pagina di amministrazione di IAP
Seleziona la casella di controllo accanto alle risorse per le quali vuoi aggiornare le autorizzazioni IAM.
Nel riquadro informazioni a destra, fai clic su Aggiungi entità.
Nella casella Nuova entità, inserisci le entità a cui vuoi assegnare un ruolo.
Nell'elenco a discesa Seleziona un ruolo, seleziona il ruolo Utente applicazione web con protezione IAP e specifica le condizioni del livello di accesso che le entità dovranno soddisfare per accedere alla risorsa.
- Per specificare i livelli di accesso esistenti, selezionali dall'elenco a discesa Livelli di accesso. Per visualizzare i livelli di accesso esistenti, devi selezionare il ruolo Utente applicazione web con protezione IAP e disporre delle autorizzazioni a livello di organizzazione.
  - Amministratore Gestore contesto accesso
  - Editor Gestore contesto accesso
  - Lettore Gestore contesto accesso
- Per creare e gestire i livelli di accesso, utilizza Gestore contesto accesso.
Se vuoi aggiungere altri ruoli alle entità, fai clic su Aggiungi un altro ruolo.
Al termine dell'aggiunta dei ruoli, fai clic su Salva.

Hai aggiunto un'associazione condizionale alla risorsa.

Per rimuovere un'associazione condizionale:

Vai alla pagina di amministrazione di IAP.
Vai alla pagina di amministrazione di IAP
Seleziona la casella di controllo accanto alla risorsa da cui vuoi rimuovere il ruolo IAM di un'entità.
Nel riquadro informazioni a destra, in Ruolo / entità, fai clic sul ruolo che vuoi rimuovere dall'entità.
Fai clic su Rimuovi accanto all'entità.
Nella finestra di dialogo Rimuovi ruolo dall'entità visualizzata, fai clic su Rimuovi. Per rimuovere tutti i ruoli non ereditati dall'entità nella risorsa selezionata, seleziona la casella di controllo prima di fare clic su Rimuovi.

gcloud

Al momento, puoi utilizzare lo strumento gcloud solo per impostare le associazioni condizionali a livello di progetto.

Per impostare le associazioni condizionali, modifica il file policy.yaml del progetto seguendo la procedura riportata di seguito:

Apri la policy IAM per l'app utilizzando il seguente comando gcloud:
```
gcloud iap web get-iam-policy --project=PROJECT_ID > policy.yaml
```
Modifica il file policy.yaml per specificare quanto segue:
- Gli utenti e i gruppi a cui vuoi applicare la condizione IAM.
- Il ruolo iap.httpsResourceAccessor per concedere loro l'accesso alle risorse.
- La condizione IAM.
  
  Il seguente snippet mostra una condizione IAM con un solo attributo specificato. Questa condizione concede l'accesso all'utente e al gruppo se vengono soddisfatti i requisiti del livello di accesso ACCESS_LEVEL_NAME e il percorso dell'URL della risorsa inizia con /.
```
bindings:
...
  - members:
    - group:EXAMPLE_GROUP@GOOGLE.COM
    - user:EXAMPLE_USER@GOOGLE.COM
    role: roles/iap.httpsResourceAccessor
    condition:
              expression: "accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in
                          request.auth.access_levels && request.path.startsWith("/")
              title: CONDITION_TITLE
...
```
Associa la policy all'applicazione utilizzando il comando set-iam-policy.
```
gcloud iap web set-iam-policy --project=PROJECT_ID policy.yaml
```

La policy IAM ora include un'associazione condizionale.

API

Per modificare il file policy.json dell'app, segui la procedura riportata di seguito per il tipo di app. Per ulteriori informazioni sull'utilizzo dell'API IAM per gestire le policy di accesso, consulta Gestire l'accesso alle risorse protette con IAP.

Prima di eseguire i passaggi dell'API specifici per l'applicazione riportati di seguito, esporta le seguenti variabili:

 export PROJECT_NUM=PROJECT_NUMBER
 export IAP_BASE_URL=https://iap.googleapis.com/v1/projects/${PROJECT_NUM}/iap_web
 # Replace POLICY_FILE.JSON with the name of JSON file to use for setIamPolicy
 export JSON_NEW_POLICY=POLICY_FILE.JSON

App Engine

Esporta le seguenti variabili di App Engine:

# The APP_ID is usually the project ID
export GAE_APP_ID=APP_ID
export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}

Recupera la policy IAM per l'app App Engine utilizzando il metodo getIamPolicy. Il bit di dati vuoto alla fine trasforma la richiesta curl in POST anziché GET.
```
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
${GAE_BASE_URL}/:getIamPolicy -d ''
```
Aggiungi l'associazione condizionale IAM al file JSON della policy IAM. Di seguito è riportato un esempio di file policy.json modificato che associa il ruolo iap.httpsResourceAccessor a due utenti, concedendo loro l'accesso alle risorse protette con IAP. È stata aggiunta una condizione IAM per concedere loro l'accesso alle risorse solo se viene soddisfatto il requisito del livello di accesso ACCESS_LEVEL_NAME e il percorso dell'URL della risorsa inizia con /. Può essere presente una sola condizione per associazione.

Esempio di file policy.json
```
{
"policy": {
"bindings": [
{
  "role": "roles/iap.httpsResourceAccessor",
  "members": [
      "group:EXAMPLE_GROUP@GOOGLE.COM",
      "user:EXAMPLE_USER@GOOGLE.COM"
  ],
  "condition": {
    "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")",
    "title": "CONDITION_NAME"
  }
}
]
}
}
```

Imposta il nuovo file policy.json utilizzando il metodo setIamPolicy.

curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
${GAE_BASE_URL}:setIamPolicy -d @${JSON_NEW_POLICY}

Servizi e versioni di App Engine

Puoi anche aggiornare la policy IAM di un servizio App Engine , di tutte le versioni o di una versione specifica di un servizio. Per farlo per una versione specifica di un servizio:

Esporta le seguenti variabili aggiuntive.

export GAE_SERVICE=SERVICE_NAME
export GAE_VERSION=VERSION_NAME

Aggiorna la variabile GAE_BASE_URL esportata.

export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}/services/${GAE_SERVICE}/versions/${GAE_VERSION}

Recupera e imposta la policy IAM per la versione utilizzando i comandi getIamPolicy e setIamPolicy mostrati sopra.

GKE e Compute Engine

Esporta l'ID progetto del servizio di backend.

export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME

Recupera la policy IAM per l'app Compute Engine utilizzando il metodo getIamPolicy. Il bit di dati vuoto alla fine trasforma la richiesta curl in POST anziché GET.
```
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
 ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:getIamPolicy \
 -d ''
```
Aggiungi l'associazione condizionale IAM al file JSON della policy IAM. Di seguito è riportato un esempio di file policy.json modificato che associa il ruolo iap.httpsResourceAccessor a due utenti, concedendo loro l'accesso alle risorse protette con IAP. È stata aggiunta una condizione IAM per concedere loro l'accesso alle risorse solo se viene soddisfatto il requisito del livello di accesso ACCESS_LEVEL_NAME e il percorso dell'URL della risorsa inizia con /. Può essere presente una sola condizione per associazione.

Esempio di file policy.json
```
{
"policy": {
"bindings": [
{
"role": "roles/iap.httpsResourceAccessor",
"members": [
  "group":EXAMPLE_GROUP@GOOGLE.COM,
  "user:EXAMPLE_USER@GOOGLE.COM"
],
"condition": {
  "expression": ""accessPolicies/ORGANIZATION_NUMBER/accessLevels/ACCESS_LEVEL_NAME" in request.auth.access_levels && request.path.startsWith("/")",
  "title": "CONDITION_NAME"
}
}
]
}
}
```

Imposta il nuovo file policy.json utilizzando il metodo setIamPolicy.

curl -i -H "Content-Type:application/json" \
     -H "Authentication: Bearer $(gcloud auth print-access-token)" \
     ${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:setIamPolicy \
     -d @${JSON_NEW_POLICY}

Utilizzare le condizioni di nome host e percorso

L'accesso all'app può essere protetto utilizzando il nome host e il percorso di un URL di richiesta. Ad esempio, la condizione IAM request.path.startsWith può essere utilizzata per concedere l'accesso ai dipendenti del gruppo Accesso con privilegi solo se il percorso dell'URL inizia con /admin.

Per ulteriori informazioni sull'utilizzo delle condizioni di nome host e percorso, consulta Attributi della richiesta.

Normalizzazione delle stringhe

Un URL ha un nome host e un percorso. Ad esempio, l'URL https://sheets.google.com/create?query=param ha un nome host sheets.google.com e un percorso /create.

I backend possono interpretare i nomi host e i percorsi in modi diversi. Per rimuovere l'ambiguità, IAP normalizza le stringhe di nome host e percorso quando controlla le policy.

IAP esegue due controlli delle policy quando una richiesta ha un percorso non normalizzato. Se il percorso non normalizzato supera il controllo delle policy, IAP normalizza il percorso ed esegue un secondo controllo delle policy. L'accesso viene concesso se sia il percorso non normalizzato sia quello normalizzato superano il controllo delle policy.

Ad esempio, se una richiesta ha il percorso /internal;some_param/admin, IAP esegue prima un controllo delle policy sul percorso non normalizzato (/internal). Se il controllo viene superato, IAP esegue un secondo controllo delle policy sul percorso normalizzato (/internal/admin).

Nomi host

I nomi host vengono normalizzati:

Rimuovendo i punti finali
Convertendo i caratteri in minuscolo
Convertendo in ASCII

I nomi host che includono caratteri non ASCII vengono ulteriormente normalizzati con la codifica Punycode. Per trovare una corrispondenza, devi codificare la stringa del nome host in Punycode.

Per codificare la stringa del nome host in Punycode, utilizza un convertitore come Punycoder.

Di seguito sono riportati esempi di nomi host normalizzati:

FOO.com viene normalizzato in foo.com
café.fr viene normalizzato in xn--caf-dma.fr

Percorsi

I percorsi vengono normalizzati:

Rimuovendo i parametri del percorso
Risolvendo i percorsi relativi nel loro equivalente assoluto

Un parametro del percorso include tutti i caratteri da un ; alla / successiva o alla fine del percorso.

Le richieste che contengono ..; all'inizio di una sezione del percorso sono considerate non valide. Ad esempio, /..;bar/ e /bar/..;/ restituiscono l'HTTP 400: Bad Request errore.

Di seguito sono riportati esempi di percorsi normalizzati:

/internal;some_param/admin viene normalizzato in /internal/admin
/a/../b viene normalizzato in /b
/bar;param1/baz;baz;param2 viene normalizzato in /bar/baz

Finali dei sottodomini

Una policy impostata con request.host.endsWith("google.com") corrisponderà sia a sub_domain.google.com sia a testgoogle.com. Se il tuo obiettivo è limitare la tua policy a tutti i sottodomini che terminano con google.com, imposta la policy su request.host.endsWith(".google.com").

Tieni presente che l'impostazione della policy su request.host.endsWith(".google.com") corrisponderà a sub_domain.google.com, ma non corrisponderà a google.com a causa del . aggiuntivo.

Cloud Audit Logs e livelli di accesso

L'attivazione degli audit log di Cloud per il progetto protetto con IAP ti consente di visualizzare le richieste di accesso autorizzate e non autorizzate. Per visualizzare le richieste e tutti i livelli di accesso soddisfatti da un richiedente, segui la procedura riportata di seguito:

Vai a Google Cloud console Esplora log nella console per il tuo progetto.
Vai alla pagina dei log
Nell'elenco a discesa Selettore risorse, seleziona una risorsa. Le risorse HTTPS protette con IAP si trovano in Applicazione App Engine e Servizio di backend Compute Engine. Le risorse SSH e TCP protette con IAP si trovano in Istanza VM di Compute Engine.
Nell'elenco a discesa Tipo di log, seleziona data_access.
- Il tipo di log data_access viene visualizzato solo se è stato registrato traffico verso la risorsa dopo aver attivato Cloud Audit Logs per IAP.
Fai clic per espandere la data e l'ora dell'accesso che vuoi esaminare.
- L'accesso autorizzato ha un'icona i blu.
- L'accesso non autorizzato ha un'icona !! arancione.
Visualizza i livelli di accesso soddisfatti dal richiedente facendo clic per espandere le sezioni fino a raggiungere protoPayload > requestMetadata > requestAttributes > auth > accessLevels.

Tieni presente che tutti i livelli di accesso soddisfatti da un utente sono visibili quando visualizzi una richiesta, inclusi i livelli di accesso non richiesti per accedervi. La visualizzazione di una richiesta non autorizzata non indica quali livelli di accesso non sono stati soddisfatti. Questo viene determinato confrontando le condizioni della risorsa con i livelli di accesso visibili nella richiesta.

Per ulteriori informazioni sui log, consulta la guida di Cloud Audit Logs.

Configurare l'accesso sensibile al contesto con Identity-Aware Proxy Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.