Utilisation d'AWS pour héberger une partie de la console 2 de l'agent personnalisé

Dans un précédent article de blog nous avons examiné les étapes nécessaires à la configuration d'une console d'agent personnalisé. Nous avons transféré une page sur S3 et configuré une distribution CloudFront pouvant être ajoutée à la liste blanche puis utilisée avec Amazon Connect.

Pour simplifier les choses, nous n'avons pas plongé dans les paramètres CloudFront, dont beaucoup peuvent faire du déploiement d'un site Web personnalisé beaucoup plus sûr et facile à gérer. Voici quelques étapes à considérer lors de la configuration d'une console d'agent personnalisé:

1. Gardez votre instance de test facile à mettre à jour

L'un des avantages de CloudFront est que votre site sera mis en cache dans le monde entier. Il en résulte des temps de chargement plus rapides pour vos utilisateurs et moins de correspondances avec votre origine (dans ce cas, le compartiment S3 hébergeant le site Web). Toutefois, si vous testez un nouveau site Web et apportez toujours des modifications fréquentes au code, cette fonctionnalité peut vous rendre la vie plus difficile. Je ne peux même pas compter le nombre de fois où j'ai téléchargé un nouveau fichier index.html dans S3, uniquement pour accéder à mon lien CloudFront et pour voir l'ancienne version mise en cache sans aucune de mes mises à jour récentes.

pouvez utiliser le contrôle de version (chargez un index_v2.html et naviguez ensuite directement vers celui-ci), des répertoires différents ou même des règles d'invalidation. Par exemple, en créant une invalidation qui exclut tous les fichiers de votre dossier de scripts, vous pouvez être sûr que vous obtiendrez toujours les fichiers JavaScript les plus récents. Notez que si vous décidez d'invalider un dossier entier, vous devez utiliser un caractère générique à la fin de votre chemin. Voir plus de détails ici.

Le seul inconvénient de l'utilisation des règles d'invalidation est que vous devez les créer après avoir créé une distribution et que vous en aurez besoin. attendez quelques minutes pour qu'il prenne effet. Tout dépend de la provenance exacte de votre contenu, mais j'ai constaté que les règles d'invalidation prennent jusqu'à une demi-heure à entrer en vigueur. Pour cette raison, ma méthode préférée pour configurer des sites Web opérationnels, sans encombrer le compartiment S3 de plusieurs versions du même fichier, est de définir le TTL par défaut sur 0.

Lorsque vous configurez votre distribution pour la première fois, vous pouvez décider de la durée pendant laquelle CloudFront doit mettre en cache vos objets. La durée de vie par défaut est de 86 400 secondes, ce qui correspond à 24 heures. Toutefois, lorsque vous testez votre site Web, vous pouvez facilement définir cette valeur sur 0. Si vous définissez la valeur par défaut sur 0, chaque demande adressée à CloudFront sera directement transmise à votre origine et récupérera les derniers objets. [19659002] Assurez-vous de configurer cela lors de la première configuration de la distribution et de la mettre à jour une fois le site finalisé.

2. Verrouillage du compartiment S3

Dans notre précédent article de blog, nous avons simplement configuré l'hébergement S3. notre site Web doit être accessible publiquement, cependant, CloudFront peut très facilement verrouiller l'accès au compartiment sans aucun inconvénient pour votre console d'agent personnalisé.

Il vous suffit de sélectionner l'option Limiter l'accès au compartiment lors de la création de la distribution. Vous devrez également créer une identité d’origine (ou, si vous en avez déjà une, la réutiliser). Il s’agit d’une identité d’utilisateur virtuel que CloudFront utilisera pour accéder à votre compartiment. Assurez-vous de sélectionner «Oui, l'option Mettre à jour la stratégie de compartiment» ou entrez et modifiez la stratégie de compartiment S3 de manière appropriée. Voici à quoi pourrait ressembler une politique de compartiment S3 après le déploiement d'une OAI.

 {
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Déclaration": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::BUCKETNAME/*"
        }
    ]
}

Cela signifie qu'il est désormais impossible d'accéder directement au compartiment S3 et que tout le trafic devra passer par votre distribution CloudFront. Voici quelques détails sur l'OAI .

3. N'autorisez que certaines adresses IP.
   

Si vous verrouillez le compartiment S3 comme indiqué ci-dessus, vous pouvez utiliser CloudFront pour surveiller tout le trafic sur votre site. CloudFront ne dispose pas vraiment de mécanisme robuste pour bloquer les accès malveillants. C’est là que AWS WAF entre en jeu. AWS WAF est un pare-feu d'application Web qui vous permet de surveiller les demandes adressées à CloudFront et peut être configuré pour autoriser ou bloquer certaines demandes.

Vous devriez consulter la documentation officielle mais l'idée principale de WAF est que vous sélectionnerez une ressource (telle qu'une distribution CloudFront), appliquerez certaines conditions (le plus souvent, des conditions de correspondance IP, mais vous pourrez également effectuer une correspondance géographique ou une correspondance de chaîne), puis déciderez enfin si vous devez autoriser ou bloquer les requêtes qui correspondent à la condition. ] Voici les étapes de base pour bloquer le trafic provenant d'une certaine adresse IP:

• Accédez à WAF à l'intérieur de la console AWS et sélectionnez Conditions> Adresses IP. Entrez l'adresse que vous souhaitez bloquer pour accéder à votre site.
  
• Créez une nouvelle liste de contrôle d'accès Web à partir du lien de la liste de contrôle d'accès Web, attribuez-lui un nom approprié et sélectionnez la ressource CloudFront à laquelle vous souhaitez bloquer l'accès.
• Le panneau de l’assistant vous permettra de créer des conditions, mais nous avons déjà les adresses IP dont nous avons besoin, alors cliquez simplement sur suivant pour configurer notre règle. Créez une nouvelle règle pour le moment où une demande provient de d'une adresse IP dans l'état que nous avons créé (dans la capture d'écran ci-dessous, l'état que j'ai créé s'appelle bloqué).

• Décidez enfin de ce qui devrait se passer si nous recevons une demande qui remplit cette règle (chaque règle peut avoir de multiples conditions, permettant un contrôle très granulaire). Dans cet exemple, nous souhaitons bloquer toutes les demandes provenant de la condition IP bloquée, donc effectuez les sélections suivantes.

Notez que nous définissons l'action par défaut pour autoriser tout le trafic ne correspondant pas à une règle. Vous pouvez facilement l'inverser pour n'autoriser que le trafic provenant d'un bloc prédéfini. d’adresses IP.

Cela devrait être le cas, une fois que vous aurez examiné et créé le trafic ACL des adresses IP sélectionnées sera bloqué avec une erreur 403.

Espérons que cela Ce post vous a donné des idées sur la meilleure façon d’utiliser CloudFront pour déployer votre console d’agent personnalisé ou tout autre site Web personnalisé. Pour obtenir de l'aide pour le déploiement de votre propre site Web ou pour toute rubrique liée à Amazon Connect, veuillez demander une démonstration d'Amazon Connect.