Security by Design in DSGVO-Projekten

Die Umsetzung von DSGVO-Anforderungen (Datenschutz-Grundverordnung) ist eine ganzheitliche betriebliche Aufgabe. Sie betrifft alle Unternehmensbereiche und -prozesse, in denen sensible und personenbezogene Daten verarbeitet werden - egal ob analog oder digital. IT-Führungskräfte müssen sich die Frage stellen, wo sie primär ansetzen müssen, um diese Aufgabe nachhaltig zu lösen und wie verhindert werden kann, dass der damit verbundene Berg an Veränderungen noch größer wird.

Dieser Beitrag nähert sich dem Thema mit dem Fokus auf "SecuritySecurity by Design" für IT-Systeme. Er legt einen Leitfaden, an dem sich IT-Teams orientieren können, die mit der Umsetzung von DSGVO-Projekten betraut sind. Alles zu Security auf CIO.de

Darüber hinaus gibt er Tipps aus meinem Alltag als externer Sicherheits-Lotse. Faktisch geht es dabei um Design, Zugriffsrechte, Datensparsamkeit, Recht auf Vergessen, Anonymisierung und Pseudonymisierung.

Security by Design: zur Umsetzung von DSGVO-Projekten

Die folgenden Abschnitte zeigen auf, wie neu erhobene und bestehende Personendaten zukünftig behandelt werden müssen, damit sich Unternehmen souverän und konform im Spannungsfeld zwischen Business-Aktivität, IT-Sicherheit und DatenschutzDatenschutz bewegen. Schon während des Designs einer Software- oder Datenbanklösung treten Faktoren zu Tage, die auf das Datenschutz-Konto einzahlen. Mit folgenden Empfehlungen halten Entwickler und Administratoren den (Mehr-)Aufwand bei der Implementierung DSGVO-relevanter Punkte überschaubar: Alles zu Datenschutz auf CIO.de

1. Eine klare Trennung von Informationsdaten, Einwilligungsdaten (Opt-in) und archivierungspflichtigen Daten.

Für datenschutzkonforme System-Entwicklungen zeichnet es sich als notwendig ab, Daten redundant zu speichern und sie mindestens in die Kategorien Informationsdaten, widerrufliche Einwilligungsdaten und Archivierungsdaten einzuteilen:

Informationsdaten

Bei Informationsdaten handelt es sich um Informationen zu einer Person, die nicht der gesetzlichen Archivierungspflicht unterliegen. Sie müssen umgehend nach Erfüllung des Erhebungszwecks gelöscht werden. Als Beispiel dient die Löschung von Kreditkartendaten nach dem Bezahlvorgang.

Widerrufliche Einwilligungsdaten / Opt-In-Daten

Widerrufliche Einwilligungsdaten, oder Opt-In-Daten, sind Informationen, die bis zum Widerruf zu einem bestimmten Zweck vorgehalten werden, um die Umsetzung eines wiederkehrenden Wunsches zu ermöglichen. Beispiele hierfür sind die E-Mail-Adresse für den Newsletter oder der Geburtstag für jährliche Glückwünsche. Für werbliche Maßnahmen wie einen Newsletter-Versand dürfen Anwender ausschließlich Daten verwenden, deren Eigentümer ihre explizite, temporäre Zustimmung hierfür abgegeben haben.

Sobald Datenschutzbehörden nachweisen, dass eine Kontaktaufnahme zu Personen erfolgte, die nicht explizit über Opt-in zustimmten, können sie diese mit erheblichen Geldstrafen belegen.

Wichtig ist Transparenz für Dateneigentümer, damit sie überblicken können, wie ihre Daten verwendet werden und sie die einmal erteilte Zustimmung jederzeit zurückziehen können.

Unternehmen sollten darauf achten, Antworten und Aktionen sorgfältig zu dokumentieren, damit Audits gelingen. Empfehlenswert ist zudem das Design eines Datenbank-Bereichs für Textbausteine. Dies können zum Beispiel Einwilligungsvorlagen oder juristische Texte sein.

Archivierungsdaten

Archivierungsdaten stellen eine Sammlung an Informationen dar, die beispielsweise für die gesetzlichen Aufhebungsfristen im medizinischen Bereich oder in der Buchhaltung benötigt werden, um Vorgänge nachvollziehen zu können. Das sind unter anderem Rechnungsdaten zum Kauf von Produkten und Dienstleistungen.

Erst nach Ablauf der gesetzlichen Aufbewahrungspflicht dürfen diese Archivierungsdaten gelöscht werden - ein Löschvorgang, der mit Inkrafttreten der EU-DSGVO bindend ist. Diese Daten dürfen von den Unternehmen nicht mehr verarbeitet werden.

2. Berücksichtigung von Archivierungspflichten

Im Design neuer Software- und Datenbankentwicklungen sollte für nahezu jedes Datenfeld eine Tabelle mit den dazugehörenden gesetzlichen Archivierungspflichten hinterlegt sein. Beispiele für Datenfelder sind Rechnungsnummer, Rechnungsdatum und der Netto-Betrag. Mitarbeiter müssen Belege entsprechend der Abgabeverordnung (AO) nach Steuerrecht zehn Jahre, Belege gemäß Handelsgesetzbuch (HGB) sechs Jahre archivieren.

Wesentlich für Neuprojekte sind jedoch branchenbezogene Spezifika in puncto Archivierungsauflage. So müssen Unternehmen bei der Verarbeitung von Daten wie einer Arztrechnung, in Verbindung mit Patientendaten nach Strahlenschutz- beziehungsweise Röntgenverordnung, eine Frist von bis zu 30 Jahren berücksichtigen. Gleiches zählt auch für Aufzeichnungen nach dem Transfusionsgesetz.

Gelten für personenbezogene Daten mehrere und dabei divergierende Auflagen zur Archivierung, so empfiehlt es sich, nicht nur die maximale Archivierungszeit, sondern alle Fristen anzulegen. Haben Entwickler lediglich die Maximalzeit berücksichtigt, müssen sie bei Veränderungen erneut Hand an die Software legen.

Auch sollten Verantwortliche rollenbasierend den Terminus "Ansichtsfristen" pro Feld hinterlegen. Was bedeutet dies? Archivierungsdaten für Rechnungen sind nur fünf Jahre für die "Rolle A" einsehbar, für die "Rolle B" in der ganzen Laufzeit. Bei besonders schützenswerten Informationen wie Gesundheitsdaten ist ein Einblick für Administratoren ohne Betriebsrat und/oder Datenschutzbeauftragte zu unterbinden, sprich, beide stellen ihren "Schlüssel" zur Einsichtnahme zur Verfügung. Eine auf Datenfeld-basierte Verschlüsselung, die für bestimmte Informationen das Verfallsdatum bereits einbaut, eignet sich hierfür am besten.

3. Datenschutz-Booster für bestehende Systeme

Was passiert mit Datenbanken, deren Datenspeicher zum Bersten gefüllt sind, während niemand weiß, welche personenbezogenen Daten darin lagern. Bei vielen Anwendungen existiert keine Transparenz darüber, wo diese Daten liegen und wer im Unternehmen für die allgemeine Speicherung verantwortlich zeichnet. Dies beschreibt eine Situation, in der sich aktuell viele Firmen, Behörden und Institutionen befinden.

Berücksichtigen IT-Beauftragte Datenschutz und Entwicklungseffizienz, dann ist es unmöglich, auf diese Situation aufzubauen, neue Daten unter DSGVO-Gesichtspunkten zu behandeln und den bestehenden Datenpool zu ignorieren. Alle personenbezogenen Daten jedoch in einem großen Unternehmen zu identifizieren und sie zuzuordnen, scheint, vorsichtig formuliert, ehrgeizig.

Diese umfangreichen und komplizierten Prozesse stellen für alle eine der größten Herausforderungen auf dem Weg zur Datenschutzkonformität dar. Nicht erkannte, frei flottierende und unsachgemäß gespeicherte Datenbestände bergen ein hohes Risiko für Sicherheitsverletzungen und können eine Haftung nach EU-DSGVO mit sich tragen. Konzentrierte Anstrengungen, diese nicht verwendeten Daten zu finden und zu löschen, reduzieren die Strafen im Ernstfall erheblich.

Hier empfiehlt es sich für IT-Verantwortliche, analog zu Neuprojekten zu verfahren. Erschwerend kommt hinzu, dass es schwierig ist herauszufinden, wo sich relevante Informationen befinden und von wem und wie diese prozessiert werden. Dieses Mammutprojekt ist leider nur teilweise mit Software abbildbar, da dies zumeist gelebte Prozesse sind.

4. Software für die Datenlöschung

Was müssen Entwickler und Leiter in Fachabteilungen über brauchbare Lösungen wissen? Sie benötigen zum Start eine Beschreibung des Lösch-Prozesses von personenbezogenen Daten in den operativen und dispositiven Systemen des Unternehmens. Bei der Entwicklung und dem Einsatz von Software muss eine datenschutzkonforme Löschung dieser Daten oberste Priorität haben.

Derzeit gibt es nahezu keine Standardsoftware, mit der Nutzer konform Daten löschen. Diesen Punkt sehen Anwendungsentwickler in der Konzeption von Software meist nicht vor. Um den Anforderungen der EU-DSGVO gerecht zu werden, müssen sie nun nachträglich flächendeckend Softwareänderungen durchführen.

Um eine aufwendige und fehleranfällige manuelle Löschung zu vermeiden, bietet sich die Entwicklung automatischer Löschroutinen an. Auch bei der Erstellung von Personendaten-Übersichten sollten Entwickler Prozesse softwareseitig unterstützen, um die enormen Aufwände und Fehleranfälligkeit einer manuellen Auswertung zu vermeiden.

Nach welchen Kriterien sich eine Anpassung lohnt und wann eine neue Softwarelösung sinnvoll ist, zeigt sich als klassische Güter-Abwägung. Tendenziell empfiehlt es sich Refactoring den Vorzug zu geben statt alte, unzeitgemäße Systeme in die neue Welt hinüber zu retten.

5. Mindestprüfungen und Small Data

Bei bestehenden IT-Systemen müssen Entwickler etablierte Prozesse wie Audits und Penetrations-Tests adaptieren. Diese Projekte sind teilweise mit großen Herausforderungen verbunden. Es gibt hierbei jedoch Mindestanforderungen an Überprüfungen bestehender Systeme.

Unter der Voraussetzung, dass mindestens drei Umgebungen (Dev = Entwicklung, Test und Prod = Produktion) vorhanden sind, sollten Administratoren, Entwickler und IT-Sicherheitsmitarbeiter idealerweise folgende Seiten automatisch vornehmen:

• Schwachstellenanalyse (Vulnerability Scans),

• Schadsoftware-Überprüfungen (Malware Scans)

• ComplianceCompliance Scans wie Härtungen, bei der IT-Komponenten auf Sicherheitsaspekte hin verändert werden Alles zu Compliance auf CIO.de

• Historisierung der Codes innerhalb der Software-Entwicklung (idealerweise bei jedem Commit), Einführung eines Versionskontrollsystems (beispielweise mit GIT)

Diese Mindestprüfungen müssen Anwender ausführen und die Ergebnisse in der Deployment-Pipeline lückenlos dokumentieren. Ein praxisnahes Konzept zeigt auf, wie IT-Beauftragte anfallende Daten verarbeiten und worauf sie gesondert achten müssen.

Zu Beginn erfassen Projektverantwortliche alle anfallenden Daten und klassifizieren sie. Im Klassifizierungsprozess spielt auch eine Rolle, dass neben der DSGVO noch weitere Gesetze, Regularien und Behördenauflagen existieren. Dazu zählen die Abgabenordnung (AO) als elementares Gesetz des deutschen Steuerrechts; das IT-Sicherheitsgesetz (IT-SiG), weithin unter KRITIS bekannt, und diverse eHealth-Gesetze wie die EU-Verordnungen zu Medizinprodukten und In-vitro-Diagnostika.

Verordnungen widersprechen sich teilweise

Interessanterweise widersprechen sich diese Verordnungen zum Teil und erfordern eine permanente und gründliche Prüfung aller Parameter, die für die eigenen Daten greifen. Festhalten kann man, dass bei unterschiedlichen Zeiträumen zur Datenspeicherung und Archivierung immer der längste zählt.

Als nächstes sollten Projektverantwortliche prüfen, wie personenbezogene Daten, die sich auf Geschäftsaktivitäten beziehen, in datenschutzkonformem Umfang gesammelt werden können und / oder wie eine Pseudonymisierung der Daten gelingt. Diese Pseudonymisierung meint die "Verarbeitung personenbezogener Daten in einer Weise, dass diese ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt werden und technischen und organisatorischen Maßnahmen unterliegen, die gewährleisten, dass die personenbezogenen Daten nicht einer identifizierten oder identifizierbaren natürlichen Person zugewiesen werden" [Kapitel 1 Art. 4 DSGVO].

Mit Verschlüsselung on Rest, in Transit und in Use vertraut machen

Nach dem neuen Gesetz "Clarifying Lawful Overseas Use of Data Act" (CLOUD) sind amerikanische Internet-Unternehmen, also auch Cloud-Service-Provider aus den USA, dazu verpflichtet, amerikanischen Sicherheitsbehörden Zugriff auf Nutzerdaten zu ermöglichen, die außerhalb der USA gespeichert sind. Daraus folgt der zwingende Rat an Entwickler, auch unter Berücksichtigung der DSGVO, sich mit der Verschlüsselung on Rest, in Transit und in Use vertraut machen und so schnell wie möglich mit der Implementierung zu beginnen.

Fazit

Zusammenfassend lässt sich festhalten, dass eine exakte Bestandaufnahme aller datenverarbeitenden Prozesse und ihrer IT-Systeme im Unternehmen die Basis aller Entscheidungen pro und contra Neuentwicklung bildet. Darauf bauen Überlegungen zu Security by Design-Projekten, zu ihrem Umfang, dem personellen Einsatz und den eingesetzten Methoden auf.