Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Quando si connette un progetto o un'organizzazione di Google Cloud Platform (GCP) a Microsoft Defender for Cloud, il servizio usa l'autenticazione federata per accedere in modo sicuro alle API GCP senza archiviare credenziali di lunga durata.
L'autenticazione viene eseguita scambiando token di breve durata tra Microsoft Entra ID e Google Cloud Security Token Service (STS), consentendo a Defender for Cloud di rappresentare un account del servizio GCP con autorizzazioni con ambito.
Questo articolo illustra le risorse di autenticazione create durante l'onboarding e il funzionamento del modello di attendibilità federata.
Risorse di autenticazione create in GCP
Quando si esegue l'onboarding di un progetto GCP o di un'organizzazione in Defender for Cloud, viene usato un modello GCloud per creare le risorse di autenticazione necessarie per stabilire l'attendibilità tra Microsoft Entra ID e Google Cloud.
Queste risorse includono:
- Provider e pool di identità del carico di lavoro
- Account del servizio e vincoli dei criteri
Queste risorse consentono a Defender for Cloud di eseguire l'autenticazione a GCP e di accedere alle API necessarie per l'individuazione, la valutazione del comportamento e l'analisi della sicurezza.
Modello del provider di identità
Defender for Cloud esegue l'autenticazione a GCP usando la federazione delle identità per i carichi di lavoro.
Un provider di identità di carico di lavoro è configurato in GCP per fidarsi dei token emessi da Microsoft Entra ID. Questo trust consente a Defender for Cloud di scambiare i token Microsoft Entra con i token STS di Google e di impersonare un account di servizio GCP.
Le autorizzazioni dell'account del servizio sono limitate al progetto o all'organizzazione connessa e sono limitate all'accesso richiesto dai piani di Defender abilitati.
Flusso di autenticazione tra cloud
Il diagramma seguente illustra come Defender for Cloud esegue l'autenticazione a GCP usando l'identità federata e lo scambio di token.
Il processo di autenticazione funziona nel modo seguente:
Il servizio CSPM di Microsoft Defender per il cloud acquisisce un token di Microsoft Entra. Microsoft Entra ID firma il token usando l'algoritmo RS256. Il token è valido per un'ora.
Il token Microsoft Entra viene scambiato con il servizio token di sicurezza di Google.
Il servizio token di sicurezza (STS) di Google convalida il token con il provider di identità del carico di lavoro. Viene eseguita la convalida del gruppo di destinatari e il token è firmato. Viene quindi restituito a Defender for Cloud un token STS di Google.
Defender for Cloud usa il token STS di Google per impersonare l'account del servizio. Le credenziali dell'account del servizio vengono usate per analizzare il progetto o l'organizzazione GCP.
Rappresentazione e ambito di accesso dell'account del servizio
Al termine dell'autenticazione, Defender for Cloud utilizza le credenziali di un account di servizio simulato.
L'accesso all'account di servizio è limitato alle risorse GCP che sono state integrate. Se è stato eseguito l'onboarding di un singolo progetto, l'accesso è limitato a tale progetto. Se hai effettuato l'onboarding di un'organizzazione GCP, l'accesso è circoscritto ai progetti inclusi in quell'organizzazione.
Le associazioni di criteri limitano l'accesso solo alle risorse connesse.
Le autorizzazioni concesse all'account del servizio determinano i segnali di sicurezza che Defender for Cloud può raccogliere.
Questo modello garantisce l'accesso con privilegi minimi, pur abilitando una continua valutazione della sicurezza.