Questa guida descrive come estendere i criteri 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 limitazioni di accesso in base a host, percorsi, data e ora degli URL.
Ad esempio, a seconda della configurazione dei criteri, l'app sensibile può:
- Concedi l'accesso a tutti i dipendenti se utilizzano un dispositivo aziendale attendibile dalla 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 solo ai dipendenti del gruppo Accesso con privilegi se il percorso dell'URL inizia con
/admin
.
Prima di iniziare
Prima di iniziare, ti serviranno:
- Un'IAP;app protetta da acquisti in-app a cui vuoi aggiungere l'accesso individuale o di gruppo.
- Nomi di utenti o 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, consulta Creare 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 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
, è possibile aggirare la limitazione andando a /internal%20admin
. Per ulteriori informazioni sulle condizioni relative al nome host e al percorso, consulta Utilizzare le condizioni relative al nome host e al percorso.
Aggiungi e modifica le associazioni condizionali nel criterio IAM seguendo la procedura riportata di seguito.
Console
Per aggiungere un'associazione condizionale utilizzando la console Google Cloud:
Vai alla 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. Devi selezionare il ruolo Utente applicazione web con protezione IAP e disporre delle autorizzazioni a livello di organizzazione per visualizzare i livelli di accesso esistenti. Devi disporre del ruolo assegnato
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 applicazione web con protezione IAP e disporre delle autorizzazioni a livello di organizzazione per visualizzare i livelli di accesso esistenti. Devi disporre del ruolo assegnato
uno dei seguenti ruoli:
Se vuoi aggiungere altri ruoli agli entità, fai clic su Aggiungi un altro ruolo.
Al termine dell'aggiunta dei ruoli, fai clic su Salva.
Ora hai aggiunto un'associazione condizionale alla risorsa.
Per rimuovere un'associazione condizionale:
Vai alla pagina di amministrazione di IAP.
Seleziona la casella di controllo accanto alla risorsa da cui vuoi rimuovere il ruolo IAM di un principale.
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à 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 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.
- Il 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
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 i criteri di accesso, consulta Gestire l'accesso alle risorse protette da IAP.
Prima di svolgere 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 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 richiestacurl
in POST anziché GET.curl -i -H "Authentication: Bearer $(gcloud auth print-access-token)" \ ${GAE_BASE_URL}/:getIamPolicy -d ''
Aggiungi la associazione condizionale IAM al file JSON del criterio IAM. Di seguito è riportato un esempio di file
policy.json
modificato che associa il ruoloiap.httpsResourceAccessor
a due utenti, concedendo loro l'accesso alle risorse protette da IAP. È stata aggiunta una condizione IAM per concedere l'accesso alle risorse solo se è 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.
File policy.json di esempio{ "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 metodosetIamPolicy
.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 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 il criterio IAM per la versione utilizzando i comandi
getIamPolicy
esetIamPolicy
mostrati sopra.
GKE e Compute Engine
Esporta l'ID progetto del servizio di backend.
export BACKEND_SERVICE_NAME=BACKEND_SERVICE_NAME
Recupera il criterio IAM per l'app Compute Engine utilizzando il metodo
getIamPolicy
. Il bit di dati vuoto alla fine trasforma la richiestacurl
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 la associazione condizionale IAM al file JSON del criterio IAM. Di seguito è riportato un esempio di file
policy.json
modificato che associa il ruoloiap.httpsResourceAccessor
a due utenti, concedendo loro l'accesso alle risorse protette da IAP. È stata aggiunta una condizione IAM per concedere l'accesso alle risorse solo se è 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.
File policy.json di esempio{ "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 metodosetIamPolicy
.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 utilizzata per concedere l'accesso solo ai dipendenti del gruppo Accesso privilegiato 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 /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 delle norme.
IAP esegue due controlli dei criteri quando una richiesta ha un percorso non normalizzato. Se il percorso non normalizzato supera il controllo dei criteri, IAP lo normalizza ed esegue un secondo controllo dei criteri. L'accesso viene concesso se sia i percorsi non normalizzati sia quelli normalizzati superano il controllo delle norme.
Ad esempio, se una richiesta ha il percorso /internal;some_param/admin
,
l'IAP esegue prima un controllo delle norme sul percorso non normalizzato (/internal
). Se il controllo va a buon fine,
l'IAP esegue un secondo controllo delle norme sul percorso normalizzato
(/internal/admin
).
Nomi host
I nomi host vengono normalizzati in base a:
- Rimozione dei punti finali
- Caratteri in minuscolo
- Conversione in ASCII
I nomi host che includono caratteri non ASCII vengono ulteriormente normalizzati con il punycoding. Per trovare una corrispondenza, devi punycode la stringa del nome host.
Per eseguire il punycode della stringa del nome host, utilizza un convertitore come Punycoder.
Di seguito sono riportati alcuni esempi di nomi host normalizzati:
FOO.com
è normalizzato afoo.com
café.fr
è normalizzato axn--caf-dma.fr
Percorsi
I percorsi vengono normalizzati in base a:
- Rimozione dei parametri path
- Risolvere i percorsi relativi in base al loro equivalente assoluto
Un parametro path include tutti
i caratteri da un ;
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 a/internal/admin
/a/../b
è normalizzato a/b
/bar;param1/baz;baz;param2
è normalizzato a/bar/baz
Suffissi dei sottodomini
Un criterio impostato su request.host.endsWith("google.com")
corrisponderà sia a sub_domain.google.com
sia a 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 l'impostazione del criterio su request.host.endsWith(".google.com")
corrisponderà a sub_domain.google.com
, ma non a google.com
a causa del .
aggiuntivo.
Cloud Audit Logs e livelli di accesso
L'attivazione dei log di audit di Cloud per il tuo progetto protetto da 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
Esplora log della console Google Cloud 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 registrato traffico verso la tua 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 blu
i
. - L'accesso non autorizzato è contrassegnato da un'icona arancione
!!
.
- L'accesso autorizzato ha un'icona blu
-
Visualizza i livelli di accesso raggiunti 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 si visualizza 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 valore viene determinato confrontando le condizioni della risorsa con i livelli di accesso visibili nella richiesta.
Per ulteriori informazioni sui log, consulta la guida Cloud Audit Logs.