Amazon-Datenschutz

Datenschutzrichtlinie

Die Datenschutzrichtlinie („DPP“) regelt den Empfang, die Speicherung, die Nutzung, die Übertragung und die Entsorgung von Informationen, einschließlich der über die Amazon Services API (einschließlich der Marketplace Web Service API) verkauften und abgerufenen Daten. Diese Richtlinie gilt für alle Systeme, die von der Amazon Services API verkaufte und abgerufene Daten speichern, verarbeiten oder anderweitig verarbeiten. Diese Richtlinie ergänzt die Amazon Services API-Entwicklervereinbarung und die Richtlinien zur akzeptablen Nutzung. Die Nichteinhaltung dieser DPP kann zur Aussetzung oder Beendigung des Amazon Services API-Zugriffs gemäß der Amazon Services API-Entwicklervereinbarung führen.

1. Allgemeine Sicherheitsanforderungen

Im Einklang mit branchenführender Sicherheit werden Entwickler physische, administrative und technische Schutzmaßnahmen sowie andere Sicherheitsmaßnahmen ergreifen, (i) um die Sicherheit und Vertraulichkeit der Informationen zu wahren, auf die ein Entwickler zugreift, die er sammelt, verwendet, speichert oder überträgt, und (ii) um diese Informationen vor bekannten oder vernünftigerweise vorhersehbaren Bedrohungen oder Gefahren für ihre Sicherheit und Integrität, versehentlichem Verlust, Änderung, Offenlegung und allen anderen rechtswidrigen Formen der Verarbeitung zu schützen. Ohne Einschränkung wird der Entwickler die folgenden Anforderungen erfüllen: 

1.1 Netzwerkschutz. Entwickler müssen Netzwerkschutzkontrollen implementieren, einschließlich Netzwerk-Firewalls und Netzwerkzugriffskontrolllisten, um den Zugriff auf nicht autorisierte IP-Adressen zu verhindern. Entwickler müssen in regelmäßigen Abständen (mindestens monatlich) Netzwerksegmentierung, Mechanismen zur Erkennung und Verhinderung von Eindringlingen (einschließlich tiefgreifender Verteidigungsmethoden zur Ergänzung der Regelsätze einer Firewall und der Verwendung von auf IDS- und/oder IPS-Signaturmustern basierenden Mechanismen zur Identifizierung und Verhinderung böswilligen Verhaltens im Netzwerk) sowie Antiviren- und Anti-Malware-Tools implementieren. Entwickler dürfen den Systemzugriff nur auf genehmigte interne Mitarbeiter beschränken, die für Codierung und Entwicklung verantwortlich sind und zuvor Schulungen zum Datenschutz und zur Sensibilisierung für IT-Sicherheit abgeschlossen haben („Genehmigte Benutzer“). Entwickler müssen sichere Codierungspraktiken einhalten und mindestens einmal jährlich Datenschutz- und IT-Sicherheitsbewusstseinsschulungen für genehmigte Benutzer durchführen.
 
 1.2 Zugriffsverwaltung. Entwickler müssen einen formellen Benutzerzugriffsregistrierungsprozess einrichten, um Zugriffsrechte für alle Benutzertypen und Dienste zuzuweisen, indem sie sicherstellen, dass jeder Person mit Computerzugriff auf Informationen eine eindeutige ID zugewiesen wird. Entwickler dürfen keine generischen, gemeinsamen oder standardmäßigen Anmeldeinformationen oder Benutzerkonten erstellen oder verwenden und verhindern, dass Benutzerkonten gemeinsam genutzt werden. Entwickler müssen Baselining-Mechanismen implementieren, um sicherzustellen, dass jederzeit nur die erforderlichen Benutzerkonten auf Informationen zugreifen. Entwickler müssen Mitarbeitern und Auftragnehmern das Speichern von Informationen auf persönlichen Geräten verbieten. Entwickler werden die „Kontosperrung“ aufrechterhalten und durchsetzen, indem sie ungewöhnliche Nutzungsmuster und Anmeldeversuche erkennen und Konten mit Zugriff auf Informationen deaktivieren. Entwickler müssen die Liste der Personen und Dienste mit Zugriff auf Informationen mindestens vierteljährlich überprüfen. Entwickler müssen sicherstellen, dass der Zugriff für gekündigte Mitarbeiter innerhalb von 24 Stunden deaktiviert und/oder entfernt wird.
 
1.3 Prinzip der geringsten Privilegien. Entwickler müssen fein abgestimmte Zugriffskontrollmechanismen implementieren, um die Gewährung von Rechten an alle Parteien, die die Anwendung nutzen, und die autorisierten Betreiber der Anwendung nach dem Prinzip der geringsten Rechte zu ermöglichen. Der Zugang zu Informationen muss auf der Grundlage des „Need-to-know“-Prinzips gewährt werden.
 
1.4 Anmeldeinformationsverwaltung. Entwickler müssen Mindestpasswortanforderungen für Personal und Systeme mit Zugriff auf Informationen festlegen. Die Passwortanforderungen müssen mindestens zwölf (12) Zeichen lang sein und dürfen keinen Teil des Benutzernamens, eine Mischung aus Großbuchstaben, Kleinbuchstaben, Zahlen und Sonderzeichen enthalten, einschließlich der Mindestanforderungen für jeden. Entwickler müssen für alle Benutzer ein Mindestalter für Passwörter von 1 Tag und einen maximalen Passwortablauf von 365 Tagen festlegen. Entwickler müssen sicherstellen, dass für alle Benutzerkonten eine Multi-Faktor-Authentifizierung (MFA) erforderlich ist. Entwickler müssen sicherstellen, dass die von Amazon bereitgestellten API-Schlüssel verschlüsselt sind und nur erforderliche Mitarbeiter Zugriff darauf haben.
 
1.5 Verschlüsselung bei der Übertragung. Entwickler müssen alle übertragenen Informationen mit sicheren Protokollen wie TLS 1.2+, SFTP und SSH-2 verschlüsseln. Entwickler müssen diese Sicherheitskontrolle auf allen anwendbaren internen und externen Endpunkten durchsetzen. Entwickler müssen eine Verschlüsselung auf Datennachrichtenebene verwenden, bei der die Kanalverschlüsselung (z. B. mit TLS) in nicht vertrauenswürdiger mandantenfähiger Hardware (z. B. nicht vertrauenswürdigen Proxys) endet.
 
1.6 Risikomanagement und Vorfallreaktionsplan. Entwickler müssen über einen Risikobewertungs- und Managementprozess verfügen, der jährlich von der Geschäftsleitung des Entwicklers überprüft wird. Dazu gehört unter anderem die Bewertung potenzieller Bedrohungen und Schwachstellen sowie der Wahrscheinlichkeit und Auswirkung, um bekannte Risiken zu verfolgen. Entwickler müssen einen Plan und/oder ein Runbook erstellen und verwalten, um Sicherheitsvorfälle zu erkennen und zu behandeln. Solche Pläne müssen die Rollen und Verantwortlichkeiten für die Reaktion auf Vorfälle identifizieren, Vorfalltypen definieren, die sich auf Amazon auswirken können, Verfahren zur Reaktion auf Vorfälle für definierte Vorfalltypen definieren sowie einen Eskalationspfad und Verfahren zur Eskalation von Sicherheitsvorfällen an Amazon definieren. Entwickler müssen den Plan alle sechs (6) Monate und nach jeder größeren Infrastruktur- oder Systemänderung überprüfen und verifizieren, einschließlich Änderungen am System, an Kontrollen, Betriebsumgebungen, Risikostufen und an der Lieferkette. Entwickler müssen Amazon benachrichtigen (per E-Mail an security@amazon.com) innerhalb von 24 Stunden nach Feststellung eines Sicherheitsvorfalls. Es liegt in der alleinigen Verantwortung des Entwicklers, die zuständigen Regierungs- oder Aufsichtsbehörden gemäß den geltenden lokalen Gesetzen zu informieren. Entwickler müssen jeden Sicherheitsvorfall untersuchen und die Beschreibung des Vorfalls, die Abhilfemaßnahmen und die damit verbundenen korrigierenden Prozess-/Systemkontrollen dokumentieren, die implementiert wurden, um ein zukünftiges Wiederauftreten zu verhindern. Entwickler müssen die Sorgerechtskette für alle gesammelten Beweise oder Aufzeichnungen aufrechterhalten und diese Dokumentation muss Amazon auf Anfrage (falls zutreffend) zur Verfügung gestellt werden. Wenn ein Sicherheitsvorfall aufgetreten ist, können Entwickler Amazon nicht gegenüber Aufsichtsbehörden oder Kunden vertreten oder im Namen von Amazon sprechen, es sei denn, Amazon fordert den Entwickler ausdrücklich schriftlich auf, dies zu tun.
 
1.7 Antrag auf Löschung. Entwickler müssen Informationen innerhalb von 30 Tagen nach Aufforderung durch Amazon dauerhaft und sicher löschen, sofern die Daten nicht zur Erfüllung gesetzlicher Anforderungen, einschließlich steuerlicher oder behördlicher Anforderungen, erforderlich sind. Das sichere Löschen muss in Übereinstimmung mit branchenüblichen Desinfektionsprozessen wie NIST 800-88 erfolgen. Entwickler müssen außerdem alle aktiven (online oder über das Netzwerk zugänglichen) Instanzen von Informationen 90 Tage nach der Benachrichtigung von Amazon dauerhaft und sicher löschen. Auf Anfrage von Amazon wird der Entwickler schriftlich bestätigen, dass alle Informationen sicher vernichtet wurden. 

1.8 Datenzuordnung. Entwickler müssen Informationen in einer separaten Datenbank speichern oder einen Mechanismus implementieren, um die Herkunft aller Daten in jeder Datenbank, die Informationen enthält, zu kennzeichnen und zu identifizieren. 

2. Zusätzliche Sicherheitsanforderungen speziell für personenbezogene Daten

Die folgenden zusätzlichen Sicherheitsanforderungen müssen für personenbezogene Daten („PII“) erfüllt sein. PII werden Entwicklern für ausgewählte steuerliche und vom Händler abgewickelte Versandzwecke auf Pflichtbasis gewährt. Wenn eine Amazon Services-API personenbezogene Daten enthält oder personenbezogene Daten mit nicht personenbezogenen Daten kombiniert werden, muss der gesamte Datenspeicher die folgenden Anforderungen erfüllen: 

2.1 Datenaufbewahrung. Entwickler bewahren personenbezogene Daten nicht länger als 30 Tage nach Lieferung der Bestellung und nur zu dem Zweck und so lange auf, wie dies erforderlich ist, um (i) Bestellungen zu erfüllen, (ii) Steuern zu berechnen und abzuführen, (iii) Steuerrechnungen und andere gesetzlich erforderliche Dokumente zu erstellen und (iv) gesetzliche Anforderungen, einschließlich steuerlicher oder behördlicher Anforderungen, zu erfüllen. Entwickler dürfen Daten nur dann länger als 30 Tage nach Lieferung der Bestellung aufbewahren, wenn dies gesetzlich vorgeschrieben ist und nur zum Zwecke der Einhaltung dieses Gesetzes. Gemäß den Abschnitten 1.5 („Verschlüsselung bei der Übertragung“) und 2.4 („Verschlüsselung im Ruhezustand“) dürfen personenbezogene Daten zu keinem Zeitpunkt ungeschützt übertragen oder gespeichert werden.
 
2.2 Daten-Governance. Entwickler müssen für ihre Anwendungen oder Dienste Datenschutz- und Datenverarbeitungs- und Klassifizierungsrichtlinien erstellen, dokumentieren und einhalten, die das angemessene Verhalten und die technischen Kontrollen regeln, die bei der Verwaltung und dem Schutz von Informationsbeständen anzuwenden sind. Es sollte eine Aufzeichnung der Datenverarbeitungsaktivitäten, wie z. B. spezifischer Datenfelder und der Art und Weise, wie diese erfasst, verarbeitet, gespeichert, verwendet, weitergegeben und entsorgt werden, für alle personenbezogenen Daten geführt werden, um die Verantwortlichkeit und die Einhaltung von Vorschriften sicherzustellen. Entwickler müssen einen Prozess einrichten, um die für ihr Unternehmen geltenden Datenschutz- und Sicherheitsgesetze sowie behördlichen Anforderungen zu erkennen und einzuhalten, und dokumentierte Nachweise ihrer Einhaltung aufbewahren. Entwickler müssen ihre Datenschutzrichtlinien für die Einwilligung des Kunden und die Datenrechte auf Zugriff, Berichtigung, Löschung oder Einstellung der Weitergabe/Verarbeitung ihrer Daten festlegen und einhalten, sofern dies anwendbar oder durch Datenschutzbestimmungen erforderlich ist. Entwickler müssen über technische und organisatorische Prozesse und Systeme verfügen, um autorisierte Benutzer bei Zugriffsanfragen betroffener Personen zu unterstützen. Entwickler müssen Vertragsbestimmungen in Arbeitsverträge mit Mitarbeitern aufnehmen, die personenbezogene Daten verarbeiten, um die Vertraulichkeit personenbezogener Daten zu wahren.
 
2.3 Vermögensverwaltung. Entwickler müssen die grundlegende Standardkonfiguration für Informationssysteme beibehalten und regelmäßig Patches, Updates, Fehlerbehebungen und Upgrades installieren. Entwickler müssen ein genaues Inventar der Software und physischen Vermögenswerte (z. B. Computer, Mobilgeräte) mit Zugriff auf PII pflegen und vierteljährlich aktualisieren. Dieses sollte alle Geräte in der Umgebung des Entwicklers sowie den Wartungsstatus jedes Geräts umfassen, um die Einhaltung der Grundlinie sicherzustellen. Entwickler müssen einen Änderungsmanagementprozess für alle Informationssysteme aufrechterhalten, sodass Software und Hardware mit Zugriff auf personenbezogene Daten getestet, verifiziert und genehmigt werden, wobei eine Aufgabentrennung zwischen Änderungsgenehmigern und denen, die die Änderungen vor der Implementierung testen, besteht.  Physische Vermögenswerte, die PII speichern, verarbeiten oder anderweitig verarbeiten, müssen alle in dieser Richtlinie festgelegten Anforderungen erfüllen. Entwickler dürfen personenbezogene Daten nicht auf Wechselmedien, persönlichen Geräten oder ungesicherten öffentlichen Cloud-Anwendungen (z. B. öffentliche Links, die über Google Drive verfügbar gemacht werden) speichern, es sei denn, sie sind mit mindestens AES-128- oder RSA-2048-Bit-Schlüsseln oder höher verschlüsselt. Entwickler müssen alle gedruckten Dokumente, die personenbezogene Daten enthalten, sicher entsorgen. Entwickler müssen DLP-Kontrollen (Data Loss Prevention) implementieren, um unbefugte Datenbewegungen zu überwachen und zu erkennen. 

2.4 Verschlüsselung im Ruhezustand. Entwickler müssen alle ruhenden PII mit mindestens AES-128 oder RSA mit einer Schlüsselgröße von 2048 Bit oder höher verschlüsseln. Die kryptografischen Materialien (z. B. Verschlüsselungs-/Entschlüsselungsschlüssel) und kryptografischen Funktionen (z. B. Daemons, die virtuelle Trusted-Platform-Module implementieren und Verschlüsselungs-/Entschlüsselungs-APIs bereitstellen), die für die Verschlüsselung ruhender PII verwendet werden, dürfen nur für die Prozesse und Dienste des Entwicklers zugänglich sein.
 
2.5 Sichere Codierungspraktiken. Entwickler dürfen vertrauliche Anmeldeinformationen, einschließlich Verschlüsselungsschlüssel, geheime Zugriffsschlüssel oder Passwörter, nicht in ihrem Code fest codieren. Sensible Anmeldeinformationen dürfen nicht in öffentlichen Code-Repositorys offengelegt werden. Entwickler müssen separate Test- und Produktionsumgebungen unterhalten.
 
2.6 Protokollierung und Überwachung. Entwickler müssen Protokolle sammeln, um sicherheitsrelevante Ereignisse in ihren Anwendungen und Systemen zu erkennen, einschließlich Erfolg oder Misserfolg des Ereignisses, Datum und Uhrzeit, Zugriffsversuche, Datenänderungen und Systemfehler. Entwickler müssen diesen Protokollierungsmechanismus auf allen Kanälen (z. B. Service-APIs, Speicherschicht-APIs, Verwaltungs-Dashboards) implementieren, die den Zugriff auf Informationen ermöglichen. Entwickler müssen Protokolle in Echtzeit (z. B. SIEM-Tool) oder alle zwei Wochen überprüfen. Alle Protokolle müssen über Zugriffskontrollen verfügen, um unbefugten Zugriff und Manipulationen während ihres gesamten Lebenszyklus zu verhindern. Protokolle dürfen keine PII enthalten, es sei denn, die PII sind zur Erfüllung gesetzlicher Anforderungen, einschließlich steuerlicher oder behördlicher Anforderungen, erforderlich. Sofern das geltende Recht nichts anderes vorschreibt, müssen Protokolle für den Fall eines Sicherheitsvorfalls als Referenzzwecke mindestens 90 Tage lang aufbewahrt werden. Entwickler müssen Mechanismen zur Überwachung der Protokolle und aller Systemaktivitäten entwickeln, um bei verdächtigen Aktionen (z. B. mehrere nicht autorisierte Anrufe, unerwartete Anforderungsrate und Datenabrufvolumen sowie Zugriff auf Canary-Datensätze) Ermittlungsalarme auszulösen. Entwickler müssen Überwachungsalarme und -prozesse implementieren, um zu erkennen, ob Informationen aus ihren geschützten Grenzen extrahiert werden oder außerhalb dieser gefunden werden können. Entwickler sollten eine Untersuchung durchführen, wenn Überwachungsalarme ausgelöst werden, und dies sollte im Incident Response Plan des Entwicklers dokumentiert werden.
 
2.7 Schwachstellenmanagement. Entwickler müssen einen Plan und/oder ein Runbook erstellen und verwalten, um Schwachstellen zu erkennen und zu beheben. Entwickler müssen physische Hardware, die personenbezogene Daten enthält, vor technischen Schwachstellen schützen, indem sie Schwachstellenscans durchführen und entsprechende Gegenmaßnahmen ergreifen. Entwickler müssen mindestens alle 180 Tage Schwachstellenscans, mindestens alle 365 Tage Penetrationstests durchführen und den Code vor jeder Veröffentlichung auf Schwachstellen scannen. Entwickler müssen über geeignete Verfahren und Pläne verfügen, um im Falle eines physischen oder technischen Vorfalls die Verfügbarkeit und den Zugriff auf PII rechtzeitig wiederherzustellen.

3. Audit und Bewertung

Entwickler müssen während der Laufzeit dieser Vereinbarung und für 12 Monate danach alle geeigneten Bücher und Aufzeichnungen führen, die angemessenerweise erforderlich sind, um die Einhaltung der Richtlinie zur akzeptablen Nutzung, dieses DPP und der Amazon Services API-Entwicklervereinbarung zu überprüfen. Auf schriftliche Anfrage von Amazon müssen Entwickler Amazon schriftlich bestätigen, dass sie diese Richtlinien einhalten. 

Auf begründete Anfrage kann Amazon die Bücher, Aufzeichnungen, Einrichtungen, Abläufe und die Sicherheit aller Systeme, die mit der Anwendung eines Entwicklers an der Abfrage, Speicherung oder Verarbeitung von Informationen beteiligt sind, prüfen, bewerten und inspizieren oder eine unabhängige, zertifizierte Wirtschaftsprüfungsgesellschaft beauftragen, die von Amazon ausgewählt wird. Amazon wird alle nicht öffentlichen Informationen, die von einem Entwickler im Rahmen dieser Prüfung, Bewertung oder Inspektion offengelegt werden und die als vertraulich gelten oder die aufgrund der Art der Informationen oder der Umstände ihrer Offenlegung vernünftigerweise als vertraulich angesehen werden sollten, vertraulich behandeln. Entwickler müssen im Zusammenhang mit der Prüfung oder Bewertung, die in den Einrichtungen des Entwicklers und/oder bei Subunternehmern stattfinden kann, mit Amazon oder dem Prüfer von Amazon zusammenarbeiten. Wenn die Prüfung oder Bewertung Mängel, Verstöße und/oder Nichteinhaltung unserer Geschäftsbedingungen oder Richtlinien aufdeckt, muss der Entwickler auf eigene Kosten alle angemessenerweise erforderlichen Maßnahmen ergreifen, um diese Mängel innerhalb eines vereinbarten Zeitrahmens zu beheben. Auf Anfrage muss der Entwickler Abhilfenachweise in der von Amazon geforderten Form vorlegen (einschließlich Richtlinien, Dokumenten, Screenshots oder Bildschirmfreigabe von Anwendungs- oder Infrastrukturänderungen) und vor Abschluss der Prüfung eine schriftliche Genehmigung der eingereichten Nachweise von Amazon einholen. 

4. Definitionen

„Amazon Services-API“ bezeichnet jede Anwendungsprogrammierschnittstelle (API), die von Amazon angeboten wird, um autorisierten Amazon-Benutzern den programmgesteuerten Datenaustausch zu erleichtern. 

„API-Materialien“ bezeichnet Materialien, die wir im Zusammenhang mit der Amazon Services API zur Verfügung stellen, einschließlich APIs, Dokumentation, Spezifikationen, Softwarebibliotheken, Software Development Kits und andere unterstützende Materialien, unabhängig vom Format.

„Bewerbung“ bezeichnet eine Softwareanwendung oder Website, die mit der Amazon Services API oder den API-Materialien verbunden ist.

„Autorisierter Benutzer“ bezeichnet einen Benutzer der Systeme oder Dienste von Amazon, der von Amazon ausdrücklich zur Nutzung der entsprechenden Systeme oder Dienste autorisiert wurde.

„Inhalt“ bezeichnet urheberrechtlich geschützte Werke nach geltendem Recht und Inhalte, die nach geltendem Recht geschützt sind.

„Kunde“ bezeichnet jede natürliche oder juristische Person, die Artikel oder Dienstleistungen auf den öffentlich zugänglichen Websites von Amazon gekauft hat.

„Entwickler“ bezeichnet jede natürliche oder juristische Person (einschließlich Ihnen, falls zutreffend), die die Amazon Services API oder die API-Materialien für eine zulässige Nutzung im Namen eines autorisierten Benutzers nutzt.

„Informationen“ bezeichnet alle Informationen, die über die Amazon Services API, Amazon-Portale oder die öffentlich zugänglichen Websites von Amazon offengelegt werden. Diese Daten können öffentlich oder nicht öffentlich sein, einschließlich personenbezogener Daten über Amazon-Kunden.

„Materialien“ bezeichnet Software, Daten, Text, Audio, Video, Bilder oder andere Inhalte. 

„Persönlich identifizierbare Informationen“ („PII“) bezeichnet Informationen, die allein oder zusammen mit anderen Informationen verwendet werden können, um einen Amazon-Kunden oder autorisierten Benutzer zu identifizieren, zu kontaktieren, im Kontext zu identifizieren oder zu lokalisieren. Dazu gehören unter anderem der Name, die Adresse, die E-Mail-Adresse, die Telefonnummer, der Inhalt von Geschenknachrichten, Umfrageantworten, Zahlungsdetails, Einkäufe, Cookies, der digitale Fingerabdruck (z. B. Browser, Benutzergerät), die IP-Adresse, der geografische Standort, die Postleitzahl oder die Produktkennung eines mit dem Internet verbundenen Geräts eines Kunden oder autorisierten Benutzers.

„Sicherheitsvorfall“ bezeichnet jeden tatsächlichen oder vermuteten unbefugten Zugriff, jede Sammlung, jeden Erwerb, jede Nutzung, Übertragung, Offenlegung, Korruption oder den Verlust von Informationen oder den Verstoß gegen eine Umgebung, die Informationen enthält.