Bonjour, tout le monde, et bienvenue à nouveau.
Dans la vidéo d'aujourd'hui, nous allons parler de l'identité d'accès d'origine dans Cloud Front.
L'un des défis à relever dans une architecture en nuage est que les mesures de sécurité appliquées au niveau
du nuage peuvent facilement être contournées si un attaquant envoie la requête directement à l'origine.
Par exemple, vous êtes au niveau de la façade du nuage.
Vous avez appliqué un certain filtre de restriction géographique qui bloque la demande provenant d'un pays A et bloque
la demande provenant d'un pays B. Ainsi, si un utilisateur d'un pays A ou B envoie une demande à l'ami du nuage, cette
demande sera automatiquement bloquée.
Maintenant, ce que cet attaquant peut faire, c'est qu'au lieu d'envoyer la demande au front du nuage, parce que l'attaquant
sait que vous avez un nuage pour la distribution et il doit y avoir une origine à laquelle l'ami du nuage
doit envoyer la demande.
Ainsi, au lieu d'envoyer la demande au front du nuage, l'attaquant décide d'envoyer directement
une demande à l'origine, qui est le seau S3.
Et comme la demande est envoyée directement au seau S3, toutes les restrictions que vous avez appliquées au niveau
du cloud seront facilement contournées.
Et c'est quelque chose que vous ne voulez pas vraiment dans les environnements de production.
Pour y remédier, vous pouvez utiliser une fonction appelée "cloud print, origin, access
identity", qui garantit que le seau S3 que vous possédez ne reçoit que les demandes du cloud front. Si un
attaquant tente d'envoyer directement une demande au seau S3, cette demande sera refusée.
Ainsi, dans le seau, vous avez également une politique qui stipule que seules les connexions à partir du nuage de la distribution avec un ID spécifique
de la distribution que vous avez dans votre environnement sont autorisées.
Voilà pour l'aperçu général.
Commençons par une démonstration rapide pour mieux comprendre.
Maintenant, pour la démonstration d'aujourd'hui, j'ai une distribution de nuage qui est disponible, et cette distribution
est à son tour associée à l'origine de S3 Bucket.
Le nom du seau est CFPB's assets Bucket.
C'est très similaire ici.
Seau d'actifs des laboratoires du CPU.
Maintenant, de façon similaire à ce que nous avions vu sur des politiques de bucket très spécifiques associées au niveau S3.
Examinons aussi rapidement cette question.
Donc si je vais dans les autorisations, allons un peu plus bas ici.
Vous voyez qu'il existe une politique spécifique en matière de seaux.
En fait, laissez-moi vous expliquer en détail ce que fait cette politique spécifique du seau.
Il autorise les demandes provenant du service frontal du nuage.
Donc si c'est autorisé depuis le service de cloud et que l'action est d'obtenir un objet et que vous avez
le seau ici et à l'intérieur vous avez une condition qui stipule que la source doit être ceci.
Et qu'est-ce que cela signifie ?
Vous avez l'idée du cloud pour la distribution.
Donc ça se termine par v v un.
Si vous regardez à nouveau l'identifiant de distribution du nuage, il se termine par v v un.
Ainsi, quel que soit le nombre de distributions de nuages que vous avez dans un compte, cela n'a pas d'importance.
Seule la distribution en nuage qui correspond à cet ID spécifique sera autorisée à envoyer la demande d'obtention
d'objet au seau S3.
Très bien, il s'agit donc d'un aperçu de très haut niveau de l'identité d'Origin Access.
Là encore, il s'agit d'une fonctionnalité simple, mais très utile pour les environnements de production.
C'est ainsi que se termine la vidéo d'aujourd'hui.