Confidentialité des données Amazon
Politique de protection des données
La Politique de protection des données (« DPP ») régit la réception, le stockage, l'utilisation, le transfert et l'élimination des informations, y compris les données vendues et récupérées via l'API Amazon Services (y compris l'API Marketplace Web Service). Cette politique s'applique à tous les systèmes qui stockent, traitent ou gèrent de toute autre manière les données vendues et récupérées à partir de l'API Amazon Services. Cette politique complète la Contrat de développement de l'API Amazon Services et le Politique d'utilisation acceptable. Le non-respect de ce DPP peut entraîner la suspension ou la résiliation de l'accès à l'API Amazon Services conformément au Contrat de développeur de l'API Amazon Services.
1. Exigences générales de sécurité
Conformément à la sécurité de pointe du secteur, les développeurs maintiendront des protections physiques, administratives et techniques, ainsi que d'autres mesures de sécurité (i) pour maintenir la sécurité et la confidentialité des informations consultées, collectées, utilisées, stockées ou transmises par un développeur, et (ii) pour protéger ces informations contre les menaces ou dangers connus ou raisonnablement anticipés pour leur sécurité et leur intégrité, la perte accidentelle, l'altération, la divulgation et toute autre forme illégale de traitement. Sans limitation, le Développeur se conformera aux exigences suivantes :
1.1 Protection du réseau. Les développeurs doivent mettre en œuvre des contrôles de protection du réseau, notamment des pare-feu réseau et des listes de contrôle d'accès au réseau pour refuser l'accès aux adresses IP non autorisées. Les développeurs doivent mettre en œuvre une segmentation du réseau, des mécanismes de détection et de prévention des intrusions (y compris des méthodes de défense approfondies pour compléter les ensembles de règles d'un pare-feu et l'utilisation de mécanismes basés sur des modèles de signature IDS et/ou IPS pour identifier et empêcher les comportements malveillants transitant sur le réseau), ainsi que des outils antivirus et anti-malware périodiquement (au moins une fois par mois). Les développeurs doivent restreindre l'accès aux systèmes uniquement aux employés internes approuvés qui ont des responsabilités en matière de codage et de développement et qui ont déjà suivi des formations de sensibilisation à la protection des données et à la sécurité informatique (« Utilisateurs approuvés »). Les développeurs doivent maintenir des pratiques de codage sécurisées et organiser des formations de sensibilisation à la protection des données et à la sécurité informatique pour les utilisateurs approuvés au moins une fois par an.
1.2 Gestion des accès. Les développeurs doivent établir un processus formel d'enregistrement de l'accès des utilisateurs pour attribuer des droits d'accès à tous les types d'utilisateurs et à tous les services en garantissant qu'un identifiant unique est attribué à chaque personne ayant accès à l'information par ordinateur. Les développeurs ne doivent pas créer ou utiliser des informations de connexion ou des comptes d'utilisateur génériques, partagés ou par défaut et empêcher le partage des comptes d'utilisateur. Les développeurs doivent mettre en œuvre des mécanismes de référence pour garantir qu'à tout moment, seuls les comptes d'utilisateurs requis accèdent aux informations. Les développeurs doivent empêcher les employés et les sous-traitants de stocker des informations sur des appareils personnels. Les développeurs maintiendront et appliqueront le « verrouillage des comptes » en détectant les modèles d'utilisation anormaux et les tentatives de connexion, et en désactivant les comptes ayant accès aux informations. Les développeurs doivent revoir la liste des personnes et des services ayant accès aux informations au moins une fois par trimestre. Les développeurs doivent s'assurer que l'accès est désactivé et/ou supprimé dans les 24 heures pour les employés licenciés.
1.3 Principe du moindre privilège. Les développeurs doivent mettre en œuvre des mécanismes de contrôle d'accès précis pour permettre l'octroi de droits à toute partie utilisant l'application et aux opérateurs autorisés de l'application selon le principe du moindre privilège. L'accès à l'information doit être accordé sur la base du « besoin de connaître ».
1.4 Gestion des informations d'identification. Les développeurs doivent établir des exigences minimales en matière de mot de passe pour le personnel et les systèmes ayant accès aux informations. Les exigences relatives au mot de passe doivent comporter au moins douze (12) caractères, sans inclure aucune partie du nom de l'utilisateur, un mélange de lettres majuscules, de lettres minuscules, de chiffres et de caractères spéciaux, y compris les exigences minimales pour chacun. Les développeurs doivent établir une durée minimale d'expiration du mot de passe de 1 jour et une expiration maximale de 365 jours pour tous les utilisateurs. Les développeurs doivent s'assurer que l'authentification multifacteur (MFA) est requise pour tous les comptes d'utilisateurs. Les développeurs doivent s'assurer que les clés API fournies par Amazon sont cryptées et que seuls les employés requis y ont accès.
1.5 Chiffrement en transit. Les développeurs doivent chiffrer toutes les informations en transit avec des protocoles sécurisés tels que TLS 1.2+, SFTP et SSH-2. Les développeurs doivent appliquer ce contrôle de sécurité sur tous les points de terminaison internes et externes applicables. Les développeurs doivent utiliser le chiffrement au niveau des messages de données où le chiffrement des canaux (par exemple, à l'aide de TLS) se termine sur du matériel multi-tenant non fiable (par exemple, des proxys non fiables).
1.6 Plan de gestion des risques et de réponse aux incidents. Les développeurs doivent disposer d'un processus d'évaluation et de gestion des risques qui est examiné chaque année par la haute direction du développeur, qui comprend, sans toutefois s'y limiter, l'évaluation des menaces et des vulnérabilités potentielles ainsi que de la probabilité et de l'impact afin de suivre les risques connus. Les développeurs doivent créer et maintenir un plan et/ou un runbook pour détecter et gérer les incidents de sécurité. Ces plans doivent identifier les rôles et les responsabilités en matière de réponse aux incidents, définir les types d'incidents susceptibles d'affecter Amazon, définir les procédures de réponse aux incidents pour les types d'incidents définis, et définir un chemin et des procédures de remontée des incidents de sécurité vers Amazon. Les développeurs doivent examiner et vérifier le plan tous les six (6) mois et après toute modification majeure de l'infrastructure ou du système, y compris les modifications apportées au système, aux contrôles, aux environnements opérationnels, aux niveaux de risque et à la chaîne d'approvisionnement. Les développeurs doivent informer Amazon (par e-mail à security@amazon.com) dans les 24 heures suivant la détection d'un incident de sécurité. Il est de la seule responsabilité du Développeur d’informer les agences gouvernementales ou réglementaires compétentes, comme l’exigent les lois locales applicables. Les développeurs doivent enquêter sur chaque incident de sécurité et documenter la description de l'incident, les actions correctives et les contrôles de processus/système correctifs associés mis en œuvre pour éviter toute récidive. Les développeurs doivent maintenir la chaîne de contrôle de toutes les preuves ou enregistrements collectés, et cette documentation doit être mise à la disposition d'Amazon sur demande (le cas échéant). Si un incident de sécurité s'est produit, les développeurs ne peuvent pas représenter ou parler au nom d'Amazon auprès d'une autorité de régulation ou de clients, à moins qu'Amazon ne demande spécifiquement par écrit au développeur de le faire.
1.7 Demande de suppression. Les développeurs doivent supprimer définitivement et en toute sécurité les informations conformément à l'avis d'Amazon exigeant la suppression dans les 30 jours suivant la demande d'Amazon, à moins que les données ne soient nécessaires pour répondre aux exigences légales, y compris les exigences fiscales ou réglementaires. La suppression sécurisée doit être effectuée conformément aux processus de nettoyage standard de l'industrie tels que NIST 800-88. Les développeurs doivent également supprimer définitivement et en toute sécurité toutes les instances d'informations en direct (en ligne ou accessibles sur le réseau) 90 jours après la notification d'Amazon. Si Amazon le demande, le Développeur certifiera par écrit que toutes les Informations ont été détruites en toute sécurité.
1.8 Attribution des données. Les développeurs doivent stocker les informations dans une base de données distincte ou mettre en œuvre un mécanisme pour baliser et identifier l'origine de toutes les données dans toute base de données contenant des informations.
2. Exigences de sécurité supplémentaires spécifiques aux informations personnelles identifiables
Les exigences de sécurité supplémentaires suivantes doivent être respectées pour les informations personnelles identifiables (« PII »). Les informations personnelles sont accordées aux développeurs pour certaines raisons liées aux taxes et à l'expédition par le commerçant, sur une base indispensable. Si une API Amazon Services contient des informations personnelles ou si des informations personnelles sont combinées avec des informations non personnelles, l'ensemble du magasin de données doit être conforme aux exigences suivantes :
2.1 Conservation des données. Les développeurs conserveront les informations personnelles pendant 30 jours maximum après la livraison de la commande et uniquement dans le but et aussi longtemps que nécessaire pour (i) exécuter les commandes, (ii) calculer et verser les taxes, (iii) produire des factures fiscales et autres documents légalement requis, et (iv) répondre aux exigences légales, y compris les exigences fiscales ou réglementaires. Les développeurs peuvent conserver les données pendant plus de 30 jours après la livraison de la commande uniquement si la loi l'exige et uniquement dans le but de se conformer à cette loi. Conformément aux sections 1.5 (« Chiffrement en transit ») et 2.4 (« Chiffrement au repos »), les informations personnelles ne doivent à aucun moment être transmises ou stockées sans protection.
2.2 Gouvernance des données. Les développeurs doivent créer, documenter et respecter une politique de confidentialité, de traitement et de classification des données pour leurs applications ou services, qui régit la conduite appropriée et les contrôles techniques à appliquer dans la gestion et la protection des actifs informationnels. Un enregistrement des activités de traitement des données telles que les champs de données spécifiques et la manière dont elles sont collectées, traitées, stockées, utilisées, partagées et éliminées pour toutes les informations personnelles doit être conservé afin d'établir la responsabilité et le respect des réglementations. Les développeurs doivent établir un processus pour détecter et se conformer aux lois et aux exigences réglementaires en matière de confidentialité et de sécurité applicables à leur entreprise et conserver des preuves documentées de leur conformité. Les développeurs doivent établir et respecter leur politique de confidentialité concernant le consentement du client et les droits en matière de données pour accéder, rectifier, effacer ou arrêter de partager/traiter leurs informations lorsque cela est applicable ou requis par la réglementation sur la confidentialité des données. Les développeurs doivent disposer de processus et de systèmes techniques et organisationnels pour aider les utilisateurs autorisés dans leurs demandes d'accès aux personnes concernées. Les développeurs doivent inclure des dispositions contractuelles dans les contrats de travail avec les employés qui traitent les informations personnelles afin de préserver la confidentialité des informations personnelles.
2.3 Gestion des actifs. Les développeurs doivent maintenir une configuration standard de base pour les systèmes d'information et installer régulièrement des correctifs, des mises à jour, des correctifs de défauts et des mises à niveau. Les développeurs doivent maintenir et mettre à jour trimestriellement un inventaire précis des logiciels et des actifs physiques (par exemple, ordinateurs, appareils mobiles) ayant accès aux informations personnelles, qui doit inclure tous les appareils de l'environnement du développeur ainsi que l'état de maintenance de chaque appareil pour garantir la conformité par rapport à la référence. Les développeurs doivent maintenir un processus de gestion des modifications pour tous les systèmes d'information, de sorte que les logiciels et le matériel ayant accès aux informations personnelles soient testés, vérifiés et approuvés, avec une séparation des tâches entre les approbateurs des modifications et ceux qui testent les modifications avant la mise en œuvre. Les actifs physiques qui stockent, traitent ou manipulent des informations personnelles doivent respecter toutes les exigences énoncées dans cette politique. Les développeurs ne doivent pas stocker les informations personnelles sur des supports amovibles, des appareils personnels ou des applications de cloud public non sécurisées (par exemple, des liens publics mis à disposition via Google Drive), à moins qu'elles ne soient cryptées à l'aide d'au moins des clés AES-128 ou RSA-2048 bits ou supérieures. Les développeurs doivent éliminer en toute sécurité tous les documents imprimés contenant des informations personnelles. Les développeurs doivent mettre en place des contrôles de prévention des pertes de données (DLP) pour surveiller et détecter les mouvements non autorisés de données.
2.4 Chiffrement au repos. Les développeurs doivent chiffrer toutes les informations personnelles au repos en utilisant au moins AES-128 ou RSA avec une taille de clé de 2 048 bits ou plus. Les matériaux cryptographiques (par exemple, les clés de chiffrement/déchiffrement) et les capacités cryptographiques (par exemple, les démons implémentant des modules de plateforme de confiance virtuels et fournissant des API de chiffrement/déchiffrement) utilisés pour le chiffrement des informations personnelles au repos doivent être uniquement accessibles aux processus et services du développeur.
2.5 Pratiques de codage sécurisé. Les développeurs ne doivent pas coder en dur les informations d'identification sensibles dans leur code, notamment les clés de chiffrement, les clés d'accès secrètes ou les mots de passe. Les informations d’identification sensibles ne doivent pas être exposées dans des référentiels de codes publics. Les développeurs doivent maintenir des environnements de test et de production distincts.
2.6 Journalisation et surveillance. Les développeurs doivent rassembler des journaux pour détecter les événements liés à la sécurité sur leurs applications et systèmes, y compris le succès ou l'échec de l'événement, la date et l'heure, les tentatives d'accès, les modifications de données et les erreurs système. Les développeurs doivent mettre en œuvre ce mécanisme de journalisation sur tous les canaux (par exemple, les API de service, les API de couche de stockage, les tableaux de bord administratifs) donnant accès aux informations. Les développeurs doivent examiner les journaux en temps réel (par exemple, outil SIEM) ou toutes les deux semaines. Tous les journaux doivent disposer de contrôles d'accès pour empêcher tout accès non autorisé et toute falsification tout au long de leur cycle de vie. Les journaux ne doivent pas contenir de PII, sauf si les PII sont nécessaires pour répondre aux exigences légales, notamment fiscales ou réglementaires. Sauf disposition contraire de la loi applicable, les journaux doivent être conservés pendant au moins 90 jours à titre de référence en cas d'incident de sécurité. Les développeurs doivent créer des mécanismes pour surveiller les journaux et toutes les activités du système afin de déclencher des alarmes d'investigation sur les actions suspectes (par exemple, plusieurs appels non autorisés, un taux de requêtes et un volume de récupération de données inattendus, et l'accès aux enregistrements de données Canary). Les développeurs doivent mettre en œuvre des alarmes et des processus de surveillance pour détecter si les informations sont extraites ou peuvent être trouvées au-delà de leurs limites protégées. Les développeurs doivent effectuer une enquête lorsque des alarmes de surveillance sont déclenchées, et cela doit être documenté dans le plan de réponse aux incidents du développeur.
2.7 Gestion des vulnérabilités. Les développeurs doivent créer et maintenir un plan et/ou un runbook pour détecter et corriger les vulnérabilités. Les développeurs doivent protéger le matériel physique contenant des informations personnelles contre les vulnérabilités techniques en effectuant des analyses de vulnérabilité et en les corrigeant de manière appropriée. Les développeurs doivent effectuer une analyse des vulnérabilités au moins tous les 180 jours, des tests d'intrusion au moins tous les 365 jours et analyser le code à la recherche de vulnérabilités avant chaque version. Les développeurs doivent disposer de procédures et de plans appropriés pour restaurer la disponibilité et l'accès aux informations personnelles en temps opportun en cas d'incident physique ou technique.
3. Audit et évaluation
Les développeurs doivent conserver tous les livres et registres appropriés raisonnablement requis pour vérifier la conformité à la politique d'utilisation acceptable, au présent DPP et au contrat de développeur d'API Amazon Services pendant la période du présent contrat et pendant 12 mois par la suite. À la demande écrite d'Amazon, les développeurs doivent certifier par écrit à Amazon qu'ils se conforment à ces politiques.
Sur demande raisonnable, Amazon peut, ou peut demander à un cabinet d'expertise comptable indépendant sélectionné par Amazon, auditer, évaluer et inspecter les livres, registres, installations, opérations et sécurité de tous les systèmes impliqués dans l'application d'un développeur dans la récupération, le stockage ou le traitement des informations. Amazon gardera confidentielle toute information non publique divulguée par un développeur dans le cadre de cet audit, évaluation ou inspection qui est désignée comme confidentielle ou qui, compte tenu de la nature de l'information ou des circonstances entourant sa divulgation, devrait raisonnablement être considérée comme confidentielle. Les Développeurs doivent coopérer avec Amazon ou l'auditeur d'Amazon dans le cadre de l'audit ou de l'évaluation, qui peut avoir lieu dans les installations du Développeur et/ou des sous-traitants. Si l'audit ou l'évaluation révèle des déficiences, des violations et/ou des manquements à nos termes, conditions ou politiques, le développeur doit, à ses seuls frais, prendre toutes les mesures raisonnablement nécessaires pour remédier à ces déficiences dans un délai convenu. Sur demande, le développeur doit fournir des preuves de correction sous la forme demandée par Amazon (qui peuvent inclure une politique, des documents, des captures d'écran ou le partage d'écran de modifications d'application ou d'infrastructure) et obtenir l'approbation écrite des preuves soumises par Amazon avant la clôture de l'audit.
4. Définitions
"API des services Amazon" désigne toute interface de programmation d'application (API) proposée par Amazon dans le but d'aider les utilisateurs autorisés d'Amazon à échanger des données par programmation.
"Matériaux API" désigne les Documents que nous mettons à disposition dans le cadre de l'API Amazon Services, y compris les API, la documentation, les spécifications, les bibliothèques de logiciels, les kits de développement de logiciels et autres documents de support, quel que soit leur format.
"Candidature" désigne une application logicielle ou un site Web qui s'interface avec l'API Amazon Services ou les éléments API.
"Utilisateur autorisé" désigne un utilisateur des systèmes ou services d'Amazon qui a été spécifiquement autorisé par Amazon à utiliser les systèmes ou services applicables.
"Contenu" désigne les œuvres protégées par le droit d'auteur en vertu de la loi applicable et le contenu protégé en vertu de la loi applicable.
"Client" désigne toute personne ou entité qui a acheté des articles ou des services sur les sites Web publics d'Amazon.
"Développeur" désigne toute personne ou entité (y compris vous, le cas échéant) qui utilise l'API Amazon Services ou les éléments API pour une utilisation autorisée au nom d'un utilisateur autorisé.
"Informations" désigne toute information exposée via l'API Amazon Services, les portails Amazon ou les sites Web publics d'Amazon. Ces données peuvent être publiques ou non publiques, y compris les informations personnellement identifiables sur les clients Amazon.
« Matériaux » désigne un logiciel, des données, du texte, de l'audio, de la vidéo, des images ou tout autre contenu.
"Informations personnelles identifiables" ("PII") désigne des informations qui peuvent être utilisées seules ou avec d'autres informations pour identifier, contacter, identifier dans le contexte ou localiser un client Amazon ou un utilisateur autorisé. Cela inclut, sans s'y limiter, le nom, l'adresse, l'adresse e-mail, le numéro de téléphone, le contenu du message cadeau, les réponses à l'enquête, les détails de paiement, les achats, les cookies, l'empreinte numérique (par exemple, navigateur, appareil utilisateur), l'adresse IP, la géolocalisation, le code postal ou l'identifiant de produit de l'appareil connecté à Internet d'un client ou d'un utilisateur autorisé.
"Incident de sécurité" désigne tout accès, collecte, acquisition, utilisation, transmission, divulgation, corruption ou perte non autorisés, réels ou suspectés, d'informations, ou violation de tout environnement contenant des informations.