Questa pagina è stata tradotta dall'API Cloud Translation.

Configurazione dell'accesso sensibile al contesto con Identity-Aware Proxy

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

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

Concedi l'accesso a tutti i dipendenti se utilizzano un dispositivo aziendale attendibile da la tua rete aziendale.
Concedi l'accesso ai dipendenti del gruppo Accesso remoto se utilizzano una un dispositivo aziendale affidabile con una password sicura e un livello patch aggiornato, da qualsiasi rete.
Concedi l'accesso ai dipendenti nel gruppo Accesso con privilegi solo se l'URL inizia con /admin.

Prima di iniziare

Prima di iniziare, ti serviranno:

Un'app protetta da IAP a cui vuoi aggiungere singole o accesso di gruppo.
Nomi degli utenti o dei gruppi a cui vuoi concedere l'accesso.

Configurazione di un livello di accesso

Per limitare l'accesso in base all'indirizzo IP o agli attributi del dispositivo dell'utente finale, devi creare un livello di accesso. 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 da IAP.

L'utilizzo di criteri basati sugli ambiti non è supportato da IAP. I livelli di accesso devono essere impostati nel criterio di accesso dell'organizzazione. Per ulteriori informazioni le informazioni, vedi Crea un criterio di accesso.

Modifica del criterio IAM

Un'app con protezione IAP ha un criterio IAM che lega il ruolo IAP all'app.

Aggiungendo un'associazione condizionale IAM al criterio IAM, l'accesso alle risorse viene ulteriormente limitato in base agli attributi della richiesta. Questi attributi della richiesta includono:

Livelli di accesso
Host/percorso URL
Data/Ora

Tieni presente che i valori delle richieste vengono confrontati con request.host e request.path specificato in un'associazione condizionale IAM deve essere esatta. Ad esempio, se limiti l'accesso ai percorsi che iniziano con /internal admin, è possibile aggirare la limitazione andando a /internal%20admin. Per ulteriori informazioni Per informazioni sulle condizioni dei nomi host e dei percorsi, consulta l'articolo Utilizzare le condizioni nome host e percorso.

Aggiungi e modifica le associazioni condizionali nel criterio IAM seguendo questa procedura: la procedura riportata di seguito.

Console

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

Vai alla pagina di amministrazione IAP.
Vai a alla pagina di amministrazione IAP
Seleziona la casella di controllo accanto alle risorse per cui vuoi aggiornare le autorizzazioni IAM.
Nel riquadro delle 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. Ti servono per selezionare il ruolo Utente applicazione web con protezione IAP e avere il livello di organizzazione autorizzazioni per visualizzare i livelli di accesso esistenti. La tua richiesta è concessa uno dei seguenti ruoli:
  - 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.
Dopo aver aggiunto i ruoli, fai clic su Salva.

Hai aggiunto un'associazione condizionale alla tua risorsa.

Per rimuovere un'associazione condizionale:

Vai alla pagina di amministrazione di IAP.
Vai a alla pagina di amministrazione IAP
Seleziona la casella di controllo accanto alla risorsa da cui vuoi rimuovere il ruolo IAM di un'entità.
Nel riquadro Informazioni a destra, fai clic sul ruolo da rimuovere dall'entità in Ruolo/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à sulla risorsa selezionata, seleziona la casella di controllo prima di fare clic su Rimuovi.

gcloud

Al momento, puoi utilizzare solo lo strumento gcloud 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 il criterio 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.
- Ruolo iap.httpsResourceAccessor per concedere l'accesso alle risorse.
- La condizione IAM.
  
  Lo snippet seguente mostra una condizione IAM con un solo attributo specificato. Questa condizione concede l'accesso all'utente e al gruppo se i requisiti del livello di accesso ACCESS_LEVEL_NAME sono soddisfatti 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 il criterio all'applicazione utilizzando il comando set-iam-policy.
```
gcloud iap web set-iam-policy --project=PROJECT_ID policy.yaml
```

Il criterio IAM ora include un'associazione condizionale.

API

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

Prima di eseguire i passaggi indicati di seguito sull'API specifica per l'applicazione, esporta quanto segue 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 il criterio IAM per l'app App Engine utilizzando il metodo getIamPolicy. Il bit di dati vuoto alla fine trasforma la richiesta curl in POST anziché in GET.
```
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \
${GAE_BASE_URL}/:getIamPolicy -d ''
```
Aggiungi l'associazione condizionale IAM al file JSON del criterio IAM. Di seguito è riportato un esempio di file policy.json modificato che associa il token iap.httpsResourceAccessor a due utenti, concedendo loro l'accesso alle risorse protette da IAP. Un account IAM è stata aggiunta una condizione per concedere 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}

Versioni e servizi App Engine

Puoi anche aggiornare il criterio IAM di un App Engine tutte le versioni o 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}

Ottieni e imposta il criterio IAM per la versione utilizzando getIamPolicy e setIamPolicy come mostrato sopra.

GKE e Compute Engine

Esporta l'ID progetto del tuo servizio di backend.
```
export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME
```
Ottieni il criterio IAM per l'app Compute Engine utilizzando il metodo getIamPolicy. Il bit di dati vuoto alla fine trasforma la richiesta curl in POST anziché in 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 del criterio 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 da IAP. Un account IAM è stata aggiunta una condizione per concedere 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 nome host e percorso

L'accesso alla tua 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 utilizzato per concedere l'accesso solo ai dipendenti nel gruppo Accesso con privilegi se il percorso dell'URL inizia con /admin.

Per ulteriori informazioni sull'utilizzo delle condizioni 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 di /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 durante il controllo dei criteri.

IAP applica due criteri verifica se una richiesta ha un percorso non normalizzato. Se lo stato non normalizzato percorso supera il controllo dei criteri, IAP normalizza il percorso viene eseguito un secondo controllo dei criteri. L'accesso viene concesso se sia i pod non normalizzati e i percorsi normalizzati superano il controllo dei criteri.

Ad esempio, se una richiesta ha il percorso /internal;some_param/admin, l'IAP esegue prima un controllo dei criteri sul percorso non normalizzato (/internal). Se il controllo va a buon fine, l'IAP esegue un secondo controllo dei criteri sul percorso normalizzato (/internal/admin).

Nomi host

I nomi host vengono normalizzati in base a:

Rimozione dei punti finali
Uso di lettere minuscole per i caratteri
Conversione in ASCII

I nomi host che includono caratteri non ASCII vengono ulteriormente normalizzati con il punycoding. Devi inserire la stringa del nome host in modo punycode per fare una corrispondenza.

Per utilizzare la stringa del nome host con punycode, utilizza un convertitore come Punycoder.

Di seguito sono riportati alcuni esempi di nomi host normalizzati:

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

Percorsi

I percorsi vengono normalizzati mediante:

Rimozione dei parametri del percorso
Risoluzione dei percorsi relativi all'equivalente assoluto

Un parametro del percorso include tutti caratteri da ; a / successivo o alla fine del percorso.

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

Di seguito sono riportati alcuni esempi di percorsi normalizzati:

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

Suffissi dei sottodomini

Un criterio impostato con request.host.endsWith("google.com") corrisponderà a entrambi sub_domain.google.com e testgoogle.com. Se il tuo obiettivo è limitare il criterio a tutti i sottodomini che terminano con google.com, impostalo su request.host.endsWith(".google.com").

Tieni presente che se imposti il criterio su request.host.endsWith(".google.com"), corrisponde a sub_domain.google.com ma non corrisponderà a google.com a causa di altri ..

Cloud Audit Logs e livelli di accesso

Abilitazione di Cloud Audit Logs per il tuo progetto protetto con IAP ti consente di vedere le risorse richieste di accesso non autorizzate. Visualizza le richieste e tutti i livelli di accesso il richiedente è stato soddisfatto procedendo nel seguente modo:

Vai alla console Google Cloud Esplora log per il tuo progetto.
Vai alla pagina dei log
Nell'elenco a discesa del selettore di risorse, seleziona una risorsa. Le risorse HTTPS protette da IAP si trovano in Applicazione GAE e Servizio di backend GCE. Le risorse SSH e TCP protette da IAP si trovano in Inistanza VM GCE.
Nell'elenco a discesa Tipo di log, seleziona data_access.
- Il tipo di log data_access viene visualizzato solo se è stato eseguito il traffico verso la risorsa, dopo aver abilitato 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 è contrassegnato con 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 un personalizzata, inclusi i livelli di accesso che non erano necessari 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 sulla risorsa con livelli di accesso visibili nella richiesta.

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