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 Resource Name (ARN) d'un script Canary est inclus dans l'en-tête de l'agent utilisateur dans le cadre des appels sortants effectués à partir du navigateur Chromium piloté par Puppeteer-inclus dans la bibliothèque d'enveloppe CloudWatch Synthetics. Cela permet d'identifier le trafic des scripts Canary CloudWatch Synthetics et de le relier aux scripts Canary qui font 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 dans le script canary en utilisant un fichier zip, le contenu du script peut être vu dans les journaux AWS CloudTrail.

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 amples informations sur l'utilisation de AWS Secrets Manager pour protéger vos secrets, veuillez consulter Qu'est-ce que 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, les scripts Canary CloudWatch Synthetics capturent toutes les exceptions lancées par votre script Canary, que ce dernier soit personnalisé ou issu d'un modèle. CloudWatch Synthetics enregistre à la fois le message d'exception et la trace de pile à trois emplacements :

Si vous souhaitez envoyer et stocker moins d'informations, vous pouvez capturer les exceptions avant qu'elles ne soient retournées dans la bibliothèque d'enveloppe CloudWatch Synthetics.

Vous pouvez également avoir des URL de requête dans vos erreurs. CloudWatch Synthetics recherche toutes les URL dans l'erreur générée par votre script et 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. De cette façon, si votre fonction Lambda est compromise par un script malveillant, elle est limitée dans les actions qu'elle peut effectuer lors de l'exécution en tant que compte AWS de votre script Canary.

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

Rédaction de données sensibles

CloudWatch Synthetics capture les URL, le code d'état, le motif d'échec (le cas échéant), ainsi que les en-têtes et corps de requêtes et de 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, CloudWatch Synthetics enregistre les URL de demande, les codes d'état et la raison d'état de chaque URL dans les journaux de scripts Canary. 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 effacer les informations sensibles qui sont journalisées par CloudWatch Synthetics.

Pour effacer des informations sensibles, définissez la propriété de configuration restrictedUrlParameters. Pour de plus amples informations, consultez Classe SyntheticsConfiguration. Cela permet à CloudWatch Synthetics d'effacer les paramètres d'URL, y compris les valeurs de chemin d'accès et de paramètre de requête, en fonction de restrictedUrlParameters avant la journalisation. Si vous journalisez des URL dans votre script, vous pouvez utiliser getSanitizedUrl(url, stepConfig = null) pour effacer les URL avant la journalisation. Pour de plus amples informations, consultez Classe SyntheticsLogHelper.

En-têtes

Par défaut, CloudWatch Synthetics ne consigne 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 le fichier HAR et les rapports HTTP en définissant les propriétés includeRequestHeaders et includeResponseHeaders 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 des scripts Canary ou les rapports. 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 de plus amples informations, consultez executeHttpStep(stepName, requestOptions, [callback], [stepConfig]). Vous pouvez choisir d'activer le corps de la demande/réponse en définissant les propriétés includeRequestBody et includeResponseBody sur true.