Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Considérations de sécurité pour les scripts Canary Synthetics

Les sections suivantes expliquent les problèmes de sécurité que vous devez prendre en compte lors de la création et de l'exécution de scripts Canary dans Synthetics.

Utiliser des connexions sécurisées

Étant donné que le code du script Canary et les résultats des tests peuvent contenir des informations sensibles, ne vous connectez pas aux points de terminaison via des connexions non chiffrées. Utilisez toujours des connexions chiffrées, telles que celles qui commencent par https://.

Considérations relatives à la dénomination des scripts Canary

Le nom de ressource Amazon (ARN) d'un canari est inclus dans l'en-tête de l'agent utilisateur dans le cadre des appels sortants effectués depuis le navigateur Chromium piloté par Puppeteer et inclus dans la bibliothèque de wrappers Synthetics. CloudWatch Cela permet d'identifier le trafic CloudWatch des canaris de Synthetics et de le relier aux canaris qui passent des appels.

L'ARN du script Canary inclut le nom du script. Choisissez des noms de scripts Canary qui ne révèlent pas d'informations exclusives.

En outre, assurez-vous de pointer vos scripts Canary uniquement vers les sites web et les points de terminaison que vous contrôlez.

Secrets et informations sensibles dans le code canary

Si vous transmettez votre code Canary directement au Canary à l'aide d'un fichier zip, le contenu du script est visible dans AWS CloudTrail les journaux.

Si vous avez des informations sensibles ou des secrets (tels que des clés d'accès ou des informations d'identification de base de données) dans un script canary, nous vous recommandons fortement de stocker le script comme un objet versionné dans Amazon S3 et de transmettre l'emplacement Amazon S3 dans le canary, au lieu de transmettre le code canary par un fichier zip.

Si vous utilisez un fichier zip pour transmettre le script canary, nous vous recommandons fortement de ne pas inclure de secrets ou d'informations sensibles dans votre code source canary. Pour plus d'informations sur la façon AWS Secrets Manager de protéger vos secrets, consultez Qu'est-ce que c'est AWS Secrets Manager ? .

Considérations relatives aux autorisations

Nous vous recommandons de restreindre l'accès aux ressources créées ou utilisées par CloudWatch Synthetics. Utilisez des autorisations strictes sur les compartiments Amazon S3 où les scripts Canary stockent les résultats des tests et d'autres artefacts, tels que les journaux et les captures d'écran.

De même, utilisez des autorisations strictes pour les emplacements où votre code source de script Canary est stocké, de sorte qu'aucun utilisateur ne supprime accidentellement ou de façon malveillante les couches Lambda ou les fonctions Lambda utilisées pour le script Canary.

Pour vous assurer que vous exécutez le code de script Canary voulu, vous pouvez utiliser le contrôle de version d'objet sur le compartiment Amazon S3 où votre code de script Canary est stocké. Ensuite, lorsque vous spécifiez ce code à exécuter en tant que script Canary, vous pouvez inclure l'objet versionId dans le chemin d'accès, comme dans les exemples suivants.

https://bucket.s3.amazonaws.com/path/object.zip?versionId=version-id
https://s3.amazonaws.com/bucket/path/object.zip?versionId=version-id
https://bucket.s3-region.amazonaws.com/path/object.zip?versionId=version-id

Traces de pile et messages d'exception

Par défaut, CloudWatch les canaris Synthetics capturent toutes les exceptions générées par votre script Canary, que le script soit personnalisé ou qu'il provienne d'un plan. CloudWatch Synthetics enregistre à la fois le message d'exception et le suivi de la pile à trois emplacements :

Si vous souhaitez envoyer et stocker moins d'informations, vous pouvez capturer les exceptions avant qu'elles ne retournent dans la bibliothèque de CloudWatch wrappers Synthetics.

Vous pouvez également inclure des URL de demande dans vos erreurs. CloudWatch Synthetics analyse toutes les URL contenues dans l'erreur générée par votre script et en supprime les paramètres d'URL restreints en fonction de la configuration. restrictedUrlParameters Si vous journalisez des messages d'erreur dans votre script, vous pouvez utiliser getSanitizedErrorMessage pour effacer les URL avant la journalisation.

Définir une portée limitée pour les rôles IAM

Nous vous recommandons de ne pas configurer votre script Canary de façon à ce qu'il visite des URL ou des points de terminaison potentiellement malveillants. Le fait de pointer votre script Canary vers des sites web ou des points de terminaison non fiables ou inconnus pourrait exposer votre code de fonction Lambda à des scripts d'utilisateurs malveillants. En supposant qu'un site web malveillant puisse sortir de Chromium, il pourrait avoir accès à votre code Lambda comme si vous vous y étiez connecté à l'aide d'un navigateur Internet.

Exécutez votre fonction Lambda avec un rôle d'exécution IAM disposant d'autorisations délimitées. Ainsi, si votre fonction Lambda est compromise par un script malveillant, les actions qu'elle peut effectuer lorsqu'elle est exécutée en tant que compte Canary sont limitées. AWS

Lorsque vous utilisez la CloudWatch console pour créer un Canary, celui-ci est créé avec un rôle d'exécution IAM limité.

Expurgation des données sensibles

CloudWatch Synthetics capture les URL, le code d'état, le motif de l'échec (le cas échéant), ainsi que les en-têtes et le corps des demandes et des réponses. Cela permet à un utilisateur d'un script Canary de comprendre, de surveiller et de déboguer les Canary.

Les configurations décrites dans les sections suivantes peuvent être définies à tout moment de l'exécution des scripts Canary. Vous pouvez également choisir d'appliquer différentes configurations à différentes étapes de synthèse.

URL de demande

Par défaut, les journaux CloudWatch Synthetics demandent des URL, des codes d'état et le motif du statut de chaque URL dans Canary Logs. Les URL de demande peuvent également apparaître dans les rapports d'exécution des scripts Canary, les fichiers HAR, etc. L'URL de votre demande peut contenir des paramètres de requête sensibles, tels que des jetons d'accès ou des mots de passe. Vous pouvez supprimer les informations sensibles afin qu'elles ne soient pas enregistrées par CloudWatch Synthetics.

Pour supprimer des informations sensibles, définissez la propriété restrictedUrlParametersde configuration. Pour plus d’informations, consultez SyntheticsConfiguration classe. Cela oblige CloudWatch Synthetics à supprimer les paramètres d'URL, y compris les valeurs des paramètres de chemin et de requête, sur la base de ce qui précède la journalisation. restrictedUrlParameters Si vous journalisez des URL dans votre script, vous pouvez utiliser getSanitizedUrl(url, StepConfig = nul) pour effacer les URL avant la journalisation. Pour plus d’informations, consultez SyntheticsLogHelper classe.

En-têtes

Par défaut, CloudWatch Synthetics n'enregistre pas les en-têtes de demande/réponse. Pour les scripts Canary de l'interface utilisateur, il s'agit du comportement par défaut pour les scripts Canary utilisant la version d'exécution syn-nodejs-puppeteer-3.2 et version ultérieure.

Si vos en-têtes ne contiennent pas d'informations sensibles, vous pouvez activer les en-têtes dans les fichiers HAR et les rapports HTTP en définissant les includeResponseHeaderspropriétés includeRequestHeaderset sur. true Vous pouvez activer tous les en-têtes, mais choisir de restreindre les valeurs des clés d'en-tête sensibles. Par exemple, vous pouvez choisir de ne masquer que les en-têtes Authorization des artefacts produits par des scripts Canary.

Corps de la demande et de la réponse

Par défaut, CloudWatch Synthetics n'enregistre pas le corps de la demande/réponse dans les journaux ou les rapports Canary. Cette information est particulièrement utile pour les scripts Canary d'API. Synthetics capture toutes les requêtes HTTP et peut afficher les en-têtes, les corps de demandes et de réponse. Pour plus d’informations, consultez executeHttpStep(StepName, RequestOptions, [rappel], [StepConfig]). Vous pouvez choisir d'activer le corps de la demande/réponse en définissant les propriétés includeRequestBodyet includeResponseBodysur. true