View a markdown version of this page

Protection des données dans AWS Security Agent - Agent de sécurité AWS
Chiffrement au reposChiffrement en transitGestion des clésConfidentialité du trafic inter-réseauCross-Region traitement des donnéesSuppression de données

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.

Protection des données dans AWS Security Agent

Le modèle de responsabilité partagée d'AWS s'applique à la protection des données dans AWS Security Agent. Comme décrit dans ce modèle, AWS est responsable de la protection de l'infrastructure globale sur laquelle l'ensemble du cloud AWS s'exécute. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité pour les services AWS que vous utilisez. Pour plus d'informations sur la protection des données en Europe, consultez le modèle de responsabilité partagée d'AWS et le billet de blog sur le RGPD sur le blog de sécurité AWS. À des fins de protection des données, nous vous recommandons de protéger les informations d'identification des comptes AWS et de configurer des utilisateurs individuels avec AWS IAM Identity Center ou AWS Identity and Access Management (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous :

  • Utilisez l’authentification multifactorielle (MFA) avec chaque compte.

  • SSL/TLS À utiliser pour communiquer avec les ressources AWS. Nous exigeons TLS 1.2 et recommandons TLS 1.3.

  • Configurez l'API et la journalisation des activités des utilisateurs avec AWS CloudTrail. Pour plus d'informations sur l'utilisation des CloudTrail sentiers pour capturer les activités AWS, consultez la section Travailler avec des CloudTrail sentiers dans le guide de CloudTrail l'utilisateur AWS.

  • Utilisez des solutions de chiffrement AWS, ainsi que tous les contrôles de sécurité par défaut au sein des services AWS.

  • Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3.

  • Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-3 pour accéder à AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez Norme FIPS (Federal Information Processing Standard) 140-3.

Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ Nom. Cela inclut lorsque vous travaillez avec l'agent de sécurité AWS ou d'autres services AWS à l'aide de la console, de l'API, de l'interface de ligne de commande AWS ou des kits SDK AWS. Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur.

Chiffrement au repos

AWS Security Agent chiffre toutes les données au repos à l'aide de clés AWS-managed de chiffrement par défaut. Cela inclut notamment les éléments suivants :

  • Documents de conception et code : tous les documents de conception, les référentiels de code et les artefacts d'application que vous fournissez pour les révisions de sécurité sont chiffrés par AES-256 chiffrement.

  • Résultats de sécurité : tous les résultats de sécurité, les rapports de vulnérabilité et les recommandations de correction sont chiffrés au repos.

  • Données de configuration : les exigences de sécurité, les politiques personnalisées et les configurations de service sont cryptées.

  • Journaux d'audit : tous les journaux d'activité des services et les pistes d'audit sont chiffrés.

AWS Security Agent utilise AWS Key Management Service (AWS KMS) pour gérer les clés de chiffrement. Vous pouvez éventuellement utiliser une clé gérée par le client pour chiffrer vos données, ce qui vous donne un contrôle total sur les clés de chiffrement qui protègent vos ressources. Pour de plus amples informations, veuillez consulter Clés gérées par le client pour AWS Security Agent.

Chiffrement en transit

AWS Security Agent chiffre toutes les données en transit à l'aide du protocole TLS (Transport Layer Security) 1.2 ou supérieur. Cela s’applique aux éléments suivants :

  • Communications par API : tous les appels d'API entre vos applications et AWS Security Agent utilisent le protocole HTTPS avec chiffrement TLS.

  • Accès à la console — La console AWS Security Agent est accessible via HTTPS.

  • Connexions aux référentiels : les connexions aux référentiels de code GitHub et à d'autres référentiels utilisent des protocoles chiffrés.

  • Communications avec les agents : toutes les communications entre le service AWS Security Agent et les agents de test d'intrusion utilisent des canaux cryptés.

Gestion des clés

AWS Security Agent utilise AWS Key Management Service (AWS KMS) pour gérer les clés de chiffrement. Par défaut, les données sont chiffrées à l'aide de AWS-managed clés. Vous pouvez éventuellement spécifier une clé gérée par le client lors de la création de ressources telles que les espaces d'agent et les intégrations. Pour de plus amples informations, veuillez consulter Clés gérées par le client pour AWS Security Agent.

Confidentialité du trafic inter-réseau

AWS Security Agent utilise l'Internet public pour communiquer avec les fournisseurs de contrôle de source hébergés dans le cloud (GitHub, GitLab, Bitbucket) et Confluence Cloud.

Pour les fournisseurs auto-hébergés ( GitHub Enterprise Server) GitLab Self-Managed, vous pouvez configurer des connexions privées à l'aide d'Amazon VPC Lattice afin de conserver tout le trafic au sein du réseau AWS. Pour de plus amples informations, veuillez consulter Connectez-vous au contrôle de source hébergé en privé.

Dans la configuration par défaut, AWS Security Agent utilise l'Internet public pour accéder à votre application à des fins de test d'intrusion. Vous pouvez éventuellement configurer des tests de pénétration pour utiliser un VPC pour accéder à votre application. Pour de plus amples informations, veuillez consulter Connect l'agent aux ressources VPC privées.

Cross-Region traitement des données

AWS Security Agent utilise l'inférence entre régions pour optimiser les ressources de calcul disponibles et la disponibilité des modèles. Selon la région d'où provient la demande, nous pouvons traiter les demandes de saisie et les résultats de sortie dans une autre région.

  • Dans l'est des États-Unis (Virginie du Nord)us-east-1, l'ouest des États-Unis (Oregon)us-west-2, l'Asie-Pacifique (Sydney)ap-southeast-2, l'Asie-Pacifique (Tokyo)ap-northeast-1, l'Europe (Francfort) et l'Europe (Irlande)eu-west-1, AWS Security Agent utilise l'inférence géographique entre régions. eu-central-1 Pour la plupart des fonctionnalités, le traitement des données reste à l'intérieur de la limite géographique (comme les États-Unis, l'UE, l'Australie ou le Japon) d'où provient la demande. Pour la correction du code, les demandes provenant de l'Australie et du Japon sont traitées dans l'Union européenne. Pour obtenir des informations de routage spécifiques aux fonctionnalités, consultez le tableau d'inférence entre régions.

  • En Asie-Pacifique (Mumbai)ap-south-1, en Asie-Pacifique (Singapour) ap-southeast-1 et en Amérique du Sud (São Paulo)sa-east-1, AWS Security Agent utilise l'inférence interrégionale globale. Nous pouvons traiter les demandes de saisie et les résultats de sortie dans n'importe quelle région AWS commerciale.

Dans tous les cas, vos données restent stockées uniquement dans la région d'où provient la demande. Toutes les données transmises lors d'opérations interrégionales restent sur le réseau AWS et ne transitent pas par l'Internet public. Nous chiffrons les données en transit entre les régions AWS.

Cross-Region l'inférence est toujours activée et ne peut pas être désactivée. Pour plus de détails sur les régions qui traitent les demandes pour chaque fonctionnalité, consultez la section Inférence entre régions dansBonnes pratiques de sécurité pour AWS Security Agent.

Suppression de données

Lorsque vous supprimez des données d'AWS Security Agent :

  • Les données sont marquées pour suppression et ne sont plus accessibles via le service.

  • Les données sont supprimées de tous les systèmes AWS Security Agent dans un délai de 30 jours.

Pour supprimer vos données

  1. Dans la console AWS, accédez à AWS Security Agent.

  2. Choisissez les données que vous souhaitez supprimer (évaluations de sécurité, résultats ou exigences personnalisées).

  3. Choisissez Supprimer et confirmez la suppression.