Ciao a tutti e bentornati.
Nel video di oggi parleremo dell'identità di accesso all'origine nel cloud front.
Ora, una delle sfide che si presentano in un'architettura basata sul cloud è che le misure di sicurezza applicate a
livello di cloud possono essere facilmente aggirate se un utente malintenzionato invia la query direttamente
all'origine.
Ad esempio, siete al livello del fronte del cloud.
Avete applicato un filtro di restrizione geografica che blocca la richiesta da un paese A e blocca la richiesta
da un paese B, quindi se un utente di un paese A o B invia una richiesta all'amico Cloud, questa richiesta
verrà automaticamente bloccata.
Ora, l'aggressore può fare in modo che, invece di inviare la richiesta al cloud front, perché l'aggressore
sa che avete un cloud per la distribuzione e ci deve essere un'origine a cui il cloud friend
deve inviare la richiesta.
Quindi, invece di inviare la richiesta al cloud front, l'attaccante decide di inviare direttamente una
richiesta all'origine, che è il bucket S3.
E poiché la richiesta viene inviata direttamente al bucket S3, tutte le restrizioni applicate a livello frontale
del cloud saranno facilmente aggirate.
E questo è un aspetto che non si desidera in ambienti di produzione.
Per ovviare a questo problema, è possibile utilizzare una funzione chiamata cloud print, origin, access
identity, che assicura che il bucket S3 riceva le richieste solo dal cloud front, nel caso in cui un utente malintenzionato
tenti di inviare direttamente una richiesta al bucket S3, tale richiesta verrà rifiutata.
Quindi nel bucket è presente anche un criterio che afferma di consentire solo le connessioni dal cloud dalla distribuzione
con un ID specifico della distribuzione presente nell'ambiente.
Questa è la panoramica di alto livello.
Vediamo una rapida dimostrazione per capire meglio questo aspetto.
Per la dimostrazione di oggi, ho una distribuzione cloud disponibile e questa distribuzione è a
sua volta associata all'origine del bucket S3.
Il nome del bucket è "CFPB's assets Bucket".
La situazione è molto simile.
Secchio delle risorse dei laboratori della CPU.
Ora, analogamente a quanto abbiamo visto per le politiche dei bucket molto specifiche associate al livello S3.
Vediamo anche di analizzarlo rapidamente.
Quindi, se vado su autorizzazioni, scendiamo un po' più in basso.
Si nota che esiste una politica specifica per i secchi.
Anzi, permettetemi di approfondire le caratteristiche di questa specifica politica dei secchi.
Consente di ricevere richieste dal servizio cloud front.
Quindi, se è consentito dal servizio di cloud e l'azione è get object e c'è il bucket
qui e qui c'è una condizione che afferma che l'origine deve essere questa.
E cosa significa?
Avete l'idea del cloud per la distribuzione.
Quindi termina con v v un.
Se si esamina nuovamente l'id di distribuzione del cloud, termina con v v un.
Quindi, a prescindere dal numero di distribuzioni cloud presenti in un account, non ha importanza.
Solo la distribuzione di cloud run che corrisponde a questo ID specifico sarà autorizzata a inviare la richiesta
di get object al bucket S3.
Bene, questa è una panoramica di alto livello sull'identità di Origin Access.
Anche in questo caso si tratta di una funzione semplice, ma molto utile per gli ambienti di produzione.
Con questo si conclude il video di oggi.