Datensicherheit und Datenschutz im digitalen Produktpass

Das Sicherheitsparadox des digitalen Produktpasses

Digitale Produktpässe stehen in einem grundlegenden Spannungsfeld: Sie müssen für Verbraucher und Behörden öffentlich zugänglich sein und zugleich geschäftlich sensible Informationen aus der Lieferkette schützen. Verbraucher sollen die Materialzusammensetzung und Recyclinghinweise sehen, Wettbewerber dagegen weder Lieferantenidentitäten noch Kostenstrukturen oder proprietäre Herstellungsverfahren. Um dieses Paradox aufzulösen, braucht es einen durchdachten, mehrschichtigen Ansatz für Datensicherheit und Zugriffskontrolle.

Die Ökodesign-Verordnung (ESPR) erkennt dieses Spannungsfeld ausdrücklich an. Sie definiert unterschiedliche Zugriffsebenen für unterschiedliche Akteure: öffentliche Daten, die allen zugänglich sind, eingeschränkte Daten, die nur notifizierten Stellen und Marktüberwachungsbehörden zur Verfügung stehen, und vertrauliche Daten, die durch Bestimmungen zum Schutz von Geschäftsgeheimnissen geschützt sind. Diese Zugriffsebenen korrekt umzusetzen, ist sowohl eine technische Herausforderung als auch eine rechtliche Pflicht.

Es steht viel auf dem Spiel. Ein Datenleck, das Lieferantenidentitäten offenlegt, könnte Wettbewerbsvorteile zunichtemachen, die über Jahre der Lieferkettenentwicklung aufgebaut wurden. Ein Datenschutzverstoß mit personenbezogenen Daten könnte Durchsetzungsmaßnahmen nach der DSGVO mit Geldbußen von bis zu vier Prozent des weltweiten Umsatzes auslösen. Und eine Kompromittierung des Systems, die eine Fälschung von Passdaten ermöglicht, könnte Greenwashing in großem Stil begünstigen und damit den eigentlichen Zweck des DPP-Rahmens untergraben.

Datenklassifizierung und Zugriffsebenen

Wirksame DPP-Sicherheit beginnt mit der Datenklassifizierung, also der Festlegung, welche Datenelemente öffentlich, eingeschränkt oder vertraulich sind. Diese Klassifizierung bestimmt jede weitere Sicherheitsentscheidung, von den Zugriffskontrollen bis zur Verschlüsselungsstrategie.

Die ESPR definiert drei Zugriffsebenen, die DPP-Systeme umsetzen müssen:

• Öffentliche Ebene: Daten, die jeder Person zugänglich sind, die den QR-Code scannt oder den Digital Link auflöst, darunter Materialzusammensetzung, Umweltdaten, Reparaturanleitungen und Hinweise zum Ende der Lebensdauer
• Autorisierte Ebene: Daten, die nur authentifizierten Akteuren wie Marktüberwachungsbehörden, Zollbehörden und notifizierten Stellen zugänglich sind, gegebenenfalls einschließlich Prüfberichten, ausführlicher Konformitätsdokumentation und Rückverfolgbarkeitsdaten der Lieferkette
• Vertrauliche Ebene: Daten, die Geschäftsgeheimnisse darstellen und im Pass referenziert, aber nicht direkt über ihn zugänglich sind, etwa genaue Lieferantenidentitäten, proprietäre Rezepturen und Kosteninformationen

Die Umsetzung dieser Ebenen erfordert ein robustes Identitäts- und Zugriffsmanagement (IAM). Öffentliche Daten werden ohne Authentifizierung bereitgestellt. Autorisierte Daten erfordern eine Überprüfung der Berechtigungsnachweise; die ESPR sieht ein föderiertes Identitätssystem vor, bei dem sich Marktüberwachungsbehörden über ihre nationalen Systeme authentifizieren. Vertrauliche Daten werden nie über die DPP-API ausgeliefert; stattdessen kann der Pass Metadaten enthalten, die auf das Vorhandensein vertraulicher Informationen hinweisen und die Rechtsgrundlage für Zugriffsanfragen angeben.

Die Klassifizierung sollte auf Feldebene erfolgen, nicht auf Dokumentebene. Ein einzelner Pass enthält Daten aller drei Ebenen, und die API muss ihre Antwort anhand der Zugriffsebene des Anfragenden filtern können. Dieselbe GS1 Digital Link URI liefert also je nach Anfragendem unterschiedliche Daten. Das ist eine leistungsfähige Funktion, die sorgfältig umgesetzt werden muss, um Informationslecks zu vermeiden.

Verschlüsselung und Datenschutz bei Übertragung und Speicherung

Verschlüsselung ist das technische Fundament des Datenschutzes im DPP. Daten müssen sowohl bei der Übertragung (zwischen Systemen) als auch bei der Speicherung (in Datenbanken und Dateisystemen) verschlüsselt sein. Die konkreten Anforderungen hängen von der Klassifizierungsebene ab.

Alle DPP-Daten müssen bei der Übertragung TLS 1.3 (mindestens TLS 1.2) mit starken Cipher Suites verwenden. HSTS-Header sollten HTTPS an allen Endpunkten erzwingen. Certificate Pinning kann für Maschine-zu-Maschine-API-Verbindungen zwischen vertrauenswürdigen Partnern sinnvoll sein, erhöht jedoch den betrieblichen Aufwand bei der Zertifikatsrotation.

Für die Verschlüsselung gespeicherter Daten sollte AES-256 bei Datenbankfeldern mit eingeschränkten oder vertraulichen Daten eingesetzt werden. Das Schlüsselmanagement ist entscheidend: Schlüssel gehören in ein Hardware-Sicherheitsmodul (HSM) oder einen Cloud-Schlüsselverwaltungsdienst (KMS), niemals in Anwendungskonfigurationsdateien oder Umgebungsvariablen neben den verschlüsselten Daten. Richtlinien zur Schlüsselrotation sollten festgelegt und automatisiert werden.

Die Verschlüsselung auf Feldebene verdient bei DPP-Systemen besondere Aufmerksamkeit. Statt die gesamte Datenbank zu verschlüsseln, werden gezielt nur die als eingeschränkt oder vertraulich klassifizierten Felder verschlüsselt. So können Abfragen und Indizierung auf öffentlichen Feldern ohne Entschlüsselungsaufwand laufen, während sensible Daten selbst bei einer Kompromittierung der Datenbank geschützt bleiben. Die Pass-API entschlüsselt eingeschränkte Felder nur, wenn sie authentifizierte Anfragen mit entsprechender Berechtigung bedient.

DSGVO-Konformität für DPP-Daten

Digitale Produktpässe können personenbezogene Daten enthalten oder auf sie verweisen und damit Pflichten nach der DSGVO auslösen. Der offensichtlichste Fall liegt vor, wenn Passdaten Namen von Personen enthalten, die an der Herstellung beteiligt sind, etwa Kunsthandwerker, Designer, Qualitätsprüfer oder Lieferkettenverantwortliche. Personenbezogene Daten können aber auch weniger offensichtlich auftreten: IP-Adressen in Zugriffsprotokollen, E-Mail-Adressen in Herkunftsnachweisen von Daten und sogar eindeutige Produktkennungen, die sich einzelnen Käufern zuordnen lassen.

Die DSGVO-Konformität von DPP-Systemen erfordert mehrere konkrete Maßnahmen. Die Datenminimierung verlangt, dass Pässe nur die personenbezogenen Daten enthalten, die für ihren regulatorischen Zweck unbedingt erforderlich sind. Ist der Name eines Kunsthandwerkers im delegierten Rechtsakt zur ESPR nicht vorgeschrieben, sollte er nicht aufgenommen werden, auch wenn er kommerziell interessant sein mag. Die Zweckbindung stellt sicher, dass für die DPP-Konformität erhobene personenbezogene Daten nicht für Marketing oder Profiling zweckentfremdet werden.

Das Recht auf Löschung („Recht auf Vergessenwerden“) stellt DPP-Systeme vor besondere Herausforderungen. Macht ein Designer, dessen Name in Produktpässen erscheint, dieses Recht geltend, muss das System seine personenbezogenen Daten in allen betroffenen Pässen entfernen oder anonymisieren können, ohne die regulatorische Konformität der Pässe zu gefährden. Das erfordert eine sorgfältige Architektur, die personenbezogene Kennungen von Konformitätsdaten trennt.

Mit allen Parteien, die DPP-Daten mit personenbezogenen Informationen verarbeiten, müssen Auftragsverarbeitungsverträge (AVV) geschlossen werden. Dazu gehören Cloud-Hosting-Anbieter, CDN-Dienste, Analyseplattformen und alle Drittanbieter-Tools in der DPP-Pipeline. Der Vertrag muss die Arten der verarbeiteten personenbezogenen Daten, die Verarbeitungszwecke sowie die getroffenen technischen und organisatorischen Sicherheitsmaßnahmen festlegen.

API-Sicherheit und Authentifizierung

Die DPP-API ist die wichtigste Angriffsfläche für böswillige Akteure. Ihre Absicherung erfordert ein gestaffeltes Verteidigungskonzept (Defence in Depth), also mehrere Schutzschichten, die alle überwunden werden müssen, damit ein Angriff Erfolg hat.

Die Authentifizierungsmechanismen sollten der jeweiligen Zugriffsebene entsprechen. Öffentliche Endpunkte, die verbraucherorientierte Passdaten liefern, benötigen keine Authentifizierung, sollten aber zum Schutz vor Missbrauch eine Ratenbegrenzung einsetzen. Autorisierte Endpunkte sollten OAuth 2.0 mit JWTs (JSON Web Tokens) verwenden, die Identität, Organisation und Zugriffsrechte des Anfragenden kodieren. Maschine-zu-Maschine-Integrationen sollten den OAuth 2.0 Client Credentials Flow mit kurzlebigen Tokens nutzen.

Eingabevalidierung ist an jedem API-Endpunkt unverzichtbar. Alle Query-Parameter, Pfadparameter und Request-Bodies müssen gegen strikte Schemas validiert werden. GS1 Digital Link Kennungen sollten auf Format und korrekte Prüfziffer geprüft werden. Freitext-Suchparameter sollten bereinigt werden, um Injection-Angriffe zu verhindern. Die API sollte jede Anfrage ablehnen, die nicht dem dokumentierten Schema entspricht, und dabei aussagekräftige Fehlermeldungen zurückgeben, die legitimen Aufrufern bei der Korrektur helfen, ohne interne Systemdetails preiszugeben.

Weitere Maßnahmen zur API-Sicherheit:

• Ratenbegrenzung pro API-Schlüssel mit gestaffelten Limits je nach Abonnementstufe
• Signierung von Webhook-Payloads zum Schutz vor Manipulation
• IP-Allowlisting für administrative Endpunkte
• Umfassende Audit-Protokollierung aller authentifizierten API-Aufrufe
• CORS-Konfiguration, die browserbasierten API-Zugriff auf autorisierte Domains beschränkt
• Content-Security-Policy-Header in HTML-Antworten zur Abwehr von XSS-Angriffen

Ausführliche Hinweise zur API-Implementierung finden Sie in unserem Leitfaden zur API-Integration für digitale Produktpässe.

Schutz von Lieferkettendaten

Transparenz in der Lieferkette und Schutz von Geschäftsgeheimnissen schließen sich nicht aus, doch ihr Ausgleich erfordert bewusste Architekturentscheidungen. Die ESPR verlangt Rückverfolgbarkeitsinformationen, mit denen Behörden Produktangaben überprüfen können, jedoch keine öffentliche Offenlegung jedes einzelnen Lieferanten der Kette.

Zu den Techniken zum Schutz von Lieferkettendaten im DPP gehören Aggregation (Angabe der Materialherkunft nach Region statt nach konkretem Lieferanten), Pseudonymisierung (Ersetzen von Lieferantenidentitäten durch konsistente, aber undurchsichtige Kennungen) und selektive Offenlegung (detaillierte Lieferketteninformationen nur für authentifizierte Behörden).

Zero-Knowledge-Beweise sind ein aufkommender Ansatz zur Überprüfung von Lieferketten. Ein Hersteller kann nachweisen, dass sein Produkt bestimmte Nachhaltigkeitskriterien erfüllt, zum Beispiel, dass kein Lieferant seiner Kette auf einer Sanktionsliste steht, ohne die Identität dieser Lieferanten preiszugeben. Diese Technologie ist nach der ESPR zwar noch nicht vorgeschrieben, könnte aber mit der Weiterentwicklung der DPP-Anforderungen an Bedeutung gewinnen.

Zur praktischen Lieferkettensicherheit gehört auch, dass die von Lieferanten an das DPP-System übermittelten Daten selbst geschützt sind. Lieferantenportale sollten starke Authentifizierung, verschlüsselte Verbindungen und rollenbasierte Zugriffskontrollen verwenden. Vereinbarungen zur Datenweitergabe sollten genau festlegen, welche Informationen in öffentliche Pässe aufgenommen werden, damit Lieferanten Einblick und Kontrolle über die Nutzung ihrer Daten haben.

Vorfallreaktion und Umgang mit Datenschutzverletzungen

Trotz bester Vorbeugung kann es zu Sicherheitsvorfällen kommen. Ein umfassender, auf DPP-Daten zugeschnittener Vorfallreaktionsplan ist daher unverzichtbar. Er sollte Rollen und Zuständigkeiten, Kommunikationsabläufe, technische Reaktionsschritte und behördliche Meldepflichten festlegen.

Nach der DSGVO müssen Verletzungen des Schutzes personenbezogener Daten binnen 72 Stunden nach Bekanntwerden der zuständigen Aufsichtsbehörde gemeldet werden. Besteht ein hohes Risiko für die Betroffenen, sind auch diese zu benachrichtigen. Bei DPP-spezifischen Vorfällen kommen weitere Aspekte hinzu: Wurden Passdaten gefälscht, müssen die Marktüberwachungsbehörden informiert werden, damit sie beurteilen können, ob die betroffenen Produkte Sicherheits- oder Konformitätsrisiken bergen.

Der Vorfallreaktionsplan sollte konkrete Playbooks für typische DPP-Sicherheitsszenarien enthalten:

• Unbefugter Zugriff auf eingeschränkte Passdaten: kompromittierte Zugangsdaten widerrufen, Datenexposition bewerten, betroffene Parteien benachrichtigen
• Fälschung von Passdaten: betroffene Produkte identifizieren, korrigierte Pässe ausstellen, Marktüberwachungsbehörden benachrichtigen
• DDoS-Angriffe auf die Infrastruktur zur Passauflösung: Abwehr auf CDN-Ebene aktivieren, auf Backup-Infrastruktur umschalten, Dienst für kritische behördliche Abfragen aufrechterhalten
• Offenlegung von Lieferkettendaten: betroffene Lieferanten benachrichtigen, Auswirkungen auf den Wettbewerb bewerten, Rechtsberatung zur Bewertung der Verletzung von Geschäftsgeheimnissen hinzuziehen

Regelmäßige Sicherheitsaudits und Penetrationstests sollten die Wirksamkeit der DPP-Sicherheitsmaßnahmen bestätigen. Diese Prüfungen sollten sowohl die technische Infrastruktur als auch die menschlichen Prozesse abdecken, denn Social-Engineering-Angriffe auf Mitarbeitende mit Zugriff auf vertrauliche Passdaten können selbst die stärksten technischen Kontrollen umgehen.

Eine DPP-Kultur mit Sicherheit an erster Stelle

Technische Sicherheitsmaßnahmen sind notwendig, reichen aber ohne eine unterstützende Unternehmenskultur nicht aus. Alle, die mit DPP-Daten arbeiten, von Produktdesignern, die Materialien festlegen, bis zu IT-Administratoren, die die Infrastruktur betreuen, müssen die Sicherheitsfolgen ihrer Entscheidungen verstehen.

Schulungen zum Sicherheitsbewusstsein sollten DPP-spezifische Szenarien abdecken: Phishing-Versuche auf Passdaten erkennen, Anforderungen an Datenklassifizierung und Datenumgang verstehen, korrekte Verfahren zur Vergabe und zum Entzug von Zugriffsrechten einhalten und mutmaßliche Sicherheitsvorfälle umgehend melden. Diese Schulungen sollten jährlich wiederholt und an neue Bedrohungen angepasst werden.

Für Organisationen, die ihre DPP-Fähigkeiten aufbauen, enthält der Leitfaden zur Erstellung Ihres ersten digitalen Produktpasses grundlegende Sicherheitsaspekte, die von Anfang an berücksichtigt werden sollten. Sicherheit nachträglich in ein bestehendes DPP-System einzubauen, ist weitaus kostspieliger und störender, als sie von Beginn an einzuplanen.

Sicherheit ist kein Feature, das einmal umgesetzt und dann vergessen wird. Sie ist eine fortlaufende Disziplin, die sich mit der Bedrohungslage, dem regulatorischen Umfeld und dem DPP-Ökosystem weiterentwickeln muss. Organisationen, die jetzt in robuste Sicherheitspraktiken investieren, sind besser aufgestellt, um sich anzupassen, wenn die DPP-Anforderungen reifen und die Menge an Passdaten wächst.