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, l'app sensibile può:
- Concedi l'accesso a tutti i dipendenti se utilizzano un dispositivo aziendale attendibile della tua rete aziendale.
- Concedi 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.
- Concedi l'accesso ai dipendenti del gruppo Privileged Access solo se il percorso dell'URL inizia con
/admin.
Prima di iniziare
Prima di iniziare, sarà necessario:
- Un'app protetta da IAP a cui vuoi aggiungere l'accesso individuale o di gruppo.
- Nomi di utenti o gruppi a cui vuoi concedere l'accesso.
Configura 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 quelli dei dispositivi, richiedono una licenza Chrome Enterprise Premium. La convalida della licenza avviene 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 da 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 saperne di più, consulta Crea una policy di accesso.
Modifica la policy IAM
Un'app protetta da IAP ha una policy IAM che associa il ruolo IAP all'app.
Aggiungendo un binding 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 andando su /internal%20admin. Per saperne di più sulle condizioni relative a nome host e percorso, consulta Utilizza le condizioni relative a 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 console Google Cloud :
Vai alla pagina di amministrazione IAP.
Seleziona la casella di controllo accanto alle risorse per cui vuoi aggiornare le autorizzazioni IAM.
Nel riquadro Informazioni sul lato destro, 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 app 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. Devi selezionare il ruolo Utente app web con protezione IAP e disporre delle autorizzazioni a livello di organizzazione per visualizzare i livelli di accesso esistenti. Devi avere ricevuto 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.
- Per specificare i livelli di accesso esistenti, selezionali dall'elenco a discesa Livelli di accesso. Devi selezionare il ruolo Utente app web con protezione IAP e disporre delle autorizzazioni a livello di organizzazione per visualizzare i livelli di accesso esistenti. Devi avere ricevuto uno dei seguenti ruoli:
Se vuoi aggiungere altri ruoli alle entità, fai clic su Aggiungi un altro ruolo.
Quando hai finito di aggiungere i ruoli, fai clic su Salva.
Ora hai aggiunto un'associazione condizionale alla tua risorsa.
Per rimuovere un'associazione condizionale:
Vai 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 sul lato destro, 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 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 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.yamlper specificare quanto segue:- Gli utenti e i gruppi a cui vuoi applicare la condizione IAM.
- Il ruolo
iap.httpsResourceAccessorper concedere 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 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 la policy all'applicazione utilizzando il comando
set-iam-policy.gcloud iap web set-iam-policy --project=PROJECT_ID policy.yaml
La tua policy IAM ora include un'associazione condizionale.
API
Per modificare il file policy.json della tua app, segui la procedura riportata di seguito per il tipo di app.
Per saperne di più sull'utilizzo dell'API IAM per gestire le policy di accesso, consulta Gestione dell'accesso alle risorse protette da 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
1. Export the following App Engine variables:
<pre class="devsite-click-to-copy prettyprint lang-html" suppresswarning="suppresswarning">
\# The APP_ID is usually the project ID
export GAE_APP_ID=<var>APP_ID</var>
export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}</pre>
1. Get the IAM policy for the App Engine app using the `getIamPolicy` method. The empty data bit at the end turns the `curl` request into POST instead of GET.
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \\ ${GAE_BASE_URL}/:getIamPolicy -d ''
**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" } } ] } }
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \\
${GAE_BASE_URL}:setIamPolicy -d @${JSON_NEW_POLICY}#### Servizi e versioni di App Engine
You can also update the IAM policy of a App Engine
service, all versions, or a specific version of a service. To do this for a specific version of a service:
1. Export the following additional variables.
export GAE_SERVICE=SERVICE_NAME export GAE_VERSION=VERSION_NAME
export GAE_BASE_URL=${IAP_BASE_URL}/appengine-${GAE_APP_ID}/services/${GAE_SERVICE}/versions/${GAE_VERSION}
getIamPolicy
e setIamPolicy mostrati sopra.
### GKE e Compute Engine
1. Esporta l'ID progetto del tuo servizio di backend.export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME
2. Get the IAM policy for the Compute Engine app using the `getIamPolicy` method. The empty data bit at the end turns the `curl` request into POST instead of GET.
<pre class="devsite-click-to-copy prettyprint lang-html" suppresswarning="suppresswarning">
curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \\
${IAP_BASE_URL}/compute/services/${BACKEND_SERVICE_NAME}:getIamPolicy \\
-d ''</pre>
3. Add your IAM conditional binding to the IAM policy JSON file.
The following is an example of an edited `policy.json` file that binds the
`iap.httpsResourceAccessor` role to two users, granting them access to the IAP-secured resources. An IAM
condition has been added to grant them access to the resources only if the <var>ACCESS_LEVEL_NAME</var> access level requirement is met and the resource URL path starts with `/`.
Each binding can have only one condition.
<br/>**Example policy.json file**
{ "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" } } ] } }
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}
Utilizza le condizioni relative a 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 utilizzata per concedere l'accesso ai dipendenti del gruppo Privileged Access solo se il percorso dell'URL inizia con /admin.
Per saperne di più sull'utilizzo delle condizioni relative a 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 del nome host e del percorso durante il controllo delle 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 e viene eseguito un secondo controllo delle policy. L'accesso viene concesso se sia il percorso non normalizzato sia quello normalizzato superano il controllo della policy.
Ad esempio, se una richiesta ha il percorso /internal;some_param/admin, IAP esegue prima un controllo della policy sul percorso non normalizzato (/internal). Se il controllo ha esito positivo, IAP esegue un secondo controllo della policy sul percorso normalizzato (/internal/admin).
Nomi host
I nomi host vengono normalizzati:
- Rimozione dei punti finali
- Conversione dei caratteri in minuscolo
- Conversione in ASCII
I nomi host che includono caratteri non ASCII vengono ulteriormente normalizzati con la codifica Punycode. Per trovare una corrispondenza, devi convertire la stringa del nome host in Punycode.
Per convertire la stringa del nome host in Punycode, utilizza un convertitore come Punycoder.
Di seguito sono riportati alcuni esempi di nomi host normalizzati:
FOO.comè normalizzato infoo.comcafé.frè normalizzato inxn--caf-dma.fr
Percorsi
I percorsi vengono normalizzati in base a:
- Rimozione dei parametri del percorso
- Risoluzione dei percorsi relativi nel loro equivalente assoluto
Un parametro di percorso include tutti i caratteri da ; al successivo / 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'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
Terminazioni dei sottodomini
Un criterio impostato con request.host.endsWith("google.com") corrisponderà sia a sub_domain.google.com sia a testgoogle.com. Se il tuo obiettivo è limitare la 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 a google.com a causa dell'aggiunta di ..
Cloud Audit Logs e livelli di accesso
Abilitando Cloud Audit Logs per il tuo progetto protetto da IAP, puoi visualizzare le richieste di accesso autorizzate e non autorizzate. Visualizza le richieste e tutti i livelli di accesso soddisfatti da un richiedente completando i seguenti passaggi:
-
Vai a
Esplora log della console Google Cloud per il tuo progetto.
Vai alla pagina dei log - Nell'elenco a discesa del selettore delle risorse, seleziona una risorsa. Le risorse HTTPS protette da IAP si trovano in Applicazione App Engine e Servizio di backend Compute Engine. Le risorse SSH e TCP protette da 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 tua risorsa dopo l'attivazione di 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
iblu. - L'accesso non autorizzato è contrassegnato da un'icona
!!arancione.
- L'accesso autorizzato ha un'icona
-
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 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 della risorsa con i livelli di accesso visibili nella richiesta.
Per saperne di più sui log, consulta la guida di Cloud Audit Logs.