Présentation

Les applications Web qui exposent du contenu privé nécessitent des mécanismes de contrôle d'accès pour garantir que seuls les utilisateurs autorisés peuvent accéder au contenu. Les exemples incluent les portails internes basés sur le SPA qui nécessitent l'authentification de l'utilisateur et le téléchargement de fichiers confidentiels. Le contrôle d'accès peut être mis en œuvre au niveau de l'origine ou du CDN selon le cas d'utilisation.

Cas d'utilisation courants

Autorisation basée sur l'origine

Si vous utilisez CloudFront en tant que proxy inverse sans activer la mise en cache (par exemple, la désactivation de la mise en cache est configurée dans la politique de mise en cache gérée), vous pouvez simplement utiliser les fonctionnalités d'autorisation natives de votre origine (par exemple, API Gateway). Pour que cela fonctionne correctement, configurez la politique de demande d'origine pour transmettre à votre origine l'attribut de demande contenant les informations d'autorisation, tel que l'en-tête d'autorisation.

Si votre contenu peut être mis en cache, mais que vous préférez continuer à gérer les autorisations sur votre propre infrastructure, envisagez d'intégrer CloudFront à vos serveurs d'autorisation à l'aide de Lambda@Edge. Cette architecture vous permet de bénéficier de la mise en cache de CloudFront. Pour en savoir plus sur cette implémentation, consultez ce blog.

Consultez les sections suivantes si vous souhaitez transférer la logique d'autorisation des composants de votre application Web vers CloudFront.

Autorisation basée sur CloudFront à l'aide de jetons signés

CloudFront fournit un mécanisme d'autorisation natif utilisant des URL signées ou des cookies signés. Pour utiliser cette méthode, suivez les étapes décrites dans la documentation :

  • Configurez des clés cryptographiques asymétriques pour les jetons de signature, à l'aide de groupes de clés de signature.
  • Dans votre flux de travail d'authentification, ajoutez les champs de jeton requis dans les paramètres de requête ou dans les cookies de l'URL de la ressource fournie. Le jeton contient une date d'expiration, l'identifiant de la clé de signature, la politique et une signature. La politique vous permet de définir les conditions qui doivent être remplies par une demande pour réussir le test de validation des jetons par CloudFront. Par exemple, vous pouvez utiliser une politique personnalisée pour générer un jeton valide pour toutes les URL commençant par un chemin spécifique.
  • Activez la signature dans le comportement du cache de CloudFront utilisé pour le contenu privé. À partir de ce moment, toutes les demandes seront contrôlées par CloudFront pour la validation des jetons. Les demandes non autorisées reçoivent une erreur 403, qui peut être personnalisée à l'aide de la fonctionnalité de page d'erreur personnalisée de CloudFront.

Utilisez la fonctionnalité aws-sdk pour générer un jeton valide avec votre clé privée. À titre d'illustration, le code ci-dessous dans Nodejs génère une URL signée CloudFront pour un objet spécifique edge-image.jpg valide pendant deux heures.

const AWS = require('aws-sdk');

// It's recommended not to store signing keys in code. The below is just an illustrative example.
const cloudfrontAccessKeyId = 'K25ULYFPSTHQP9';
const cloudFrontPrivateKey = '-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKCAQ....2gvvIH\n-----END RSA PRIVATE KEY-----';

const signer = new AWS.CloudFront.Signer(cloudfrontAccessKeyId, cloudFrontPrivateKey);
const signedUrl = signer.getSignedUrl({
  url: 'https://d3jqlnxofenq2x.cloudfront.net/edge-image.jpg',
  expires: Math.floor((Date.now() + 2 * 60 * 60 * 1000) / 1000),
});
console.log(signedUrl);

La sortie de l'extrait de code ci-dessus ressemble à ceci :

https://d3jqlnxofenq2x.cloudfront.net/edge-image.jpg?Expires=1660317158&Key-Pair-Id=K25ULYFP9THQP9&Signature=agW2XF9S5AW0YCc6c7pkCwccJmxaIAWFO~uXn9KtOXtz4JTY7eRF07opJiseGXJxzlMeD4V6FUH8I-gOH~Gvafa16RFV9IryxCyzL9mIYt-XbDKMrY0ONzTWUk2x16AKDK27VoUwEPiI9dpPXMp7f4MsrpKA-u6huZCsulh0~aAYN~x25uNoDO-WgZpfkKFeKc910u4PVnEaKLlZlpuJ0hqWUjMVPes9DfA~msToJeyjrVzLi2R8O8LuuYHsAMAHXr7E9qB8tAoDWz24CurCirxc6sB45Zc-oK9JigX0L4~F~F1TE9i39ysmQF4UrOyu0bp7MKGSDBwLE1P2C3gWNw__

Autorisation basée sur CloudFront à l'aide des fonctions CloudFront

Si le jeton signé natif de CloudFront ne répond pas à vos exigences d'autorisation, vous pouvez créer une logique d'autorisation personnalisée à l'aide des fonctions de périphérie. Par exemple, vous souhaiterez peut-être utiliser une cryptographie différente pour signer des jetons, telle que la cryptographie symétrique, ou vous souhaiterez peut-être inclure des attributs non standard dans la signature tels que l'en-tête de l'agent utilisateur, ou vous souhaiterez peut-être implémenter une logique de création de jetons conditionnelle basée sur le réseau utilisateur. Les implémentations personnalisées suivantes illustrent certaines des possibilités offertes par les fonctions de périphérie :

  • Fonctions CloudFront pour valider le jeton basé sur JWT. Notez que Fonctions CloudFront n'autorise actuellement pas les appels réseau externes et que, par conséquent, les clés de signature doivent être stockées dans le code de la fonction. Pour réduire le risque de stockage de la clé de signature dans le code de fonction CloudFront, ne configurez pas manuellement la clé dans le code, mais utilisez plutôt une automatisation qui fait pivoter les clés et génère le code de fonction avant le déploiement sur CloudFront. De cette manière, les clés ne risquent pas d'être téléchargées vers des référentiels publics tels que Github.
  • Solution AWS : diffusion multimédia sécurisée en périphérie. Cette solution AWS utilise la fonction CloudFront pour implémenter un mécanisme d'autorisation personnalisé adapté au streaming vidéo.
  • Utiliser OpenID Connect pour authentifier une application à page unique hébergée sur S3. Les solutions utilisent AWS Secrets Manager pour stocker les clés de signature et peuvent fonctionner avec un fournisseur d'identité (IdP) externe tel que Cognito ou Okta. Cette implémentation a été publiée avant le lancement de Fonctions CloudFront, c'est pourquoi elle repose entièrement sur Lambda@Edge. Elle peut être optimisée pour utiliser Fonctions CloudFront pour la partie autorisation et Lambda@Edge pour l'intégration avec les IdP.

Ressources

Cette page vous a-t-elle été utile ?

 Commentaires