Versuch der Aufstellung eines Anforderungsmodells und Bewertung am Beispiel einer Anwendung zur mobilen Zeiterfassung

Als Projektarbeit vom 17.03.2017 an der Hamburger Fernhochschule erstellt von Mathias Reinis, B.A..

1 Einleitung

Im Zuge der Europäischen Datenschutz­-Grundverordnung (DSGVO) wird im Artikel 25 das ideelle Konzept „Privacy by Design and by Default“ zum zwingenden Prinzip für die Gestaltung von Systemen und Anwendungen mit Datenschutz­-Relevanz erhoben[1] . Anbieter und Beschaffer von diesen Systemen und Anwendungen werden also künftig vor der Aufgabe stehen, den Datenschutz als eine eigene Anforderungskategorie im Requirement Management zu berücksichtigen.

Eine gängige Meinung sieht Datenschutz durch Technik­ Gestaltung (Englisch: Privacy by Design) als eine sich evolutionär entwickelnde Praxis, deren Schritte über den Systemdatenschutz [2] und datenschutzfördernde
Technologien wie Anonymisierung und Pseudonymisierung [3] führten. Dem entgegen steht der Ansatz, Privacy by Design als ein neueres Konzept zu begreifen, dass auf sieben grundlegenden Prinzipien beruht [4] .

Privacy by default oder Datenschutz durch datenschutzfreundliche Voreinstellungen wird hingegen als selbsterklärend verstanden.

Neben die rechtlich weitgehend ausformulierten Erwartungen an den Schutz personenbezogener Daten innerhalb der Verfahren der Datenverarbeitung tritt bei Privacy by Design und by default die Fähigkeit der zur Verwendung vorgesehenen technischen Systeme und Komponenten, diesen Schutz zu unterstützen. Hersteller werden aus der DSGVO aber nicht in Verantwortung genommen, so dass es anderer Instrumentarien bedarf [5], sie zu einer datenschutzfreundlichen Gestaltung und Voreinstellung zu bewegen.

Als Voraussetzung kann dabei ein grundlegender Satz von Anforderungen angesehen werden. Die EU-­Kommission hat hierzu die Europäischen Normungsinstitute CEN, CENELEC und ETSI mandatiert, demnächst die Ausgestaltung von Privacy by Design für Anwendungsfälle der Sicherheitsindustrie vorzunehmen [6].

In dieser Projektarbeit wird im Abschnitt 2 zunächst ein Überblick über wichtige Begriffe gegeben. Im nächsten Abschnitt 3 wird auf Grundlage technischer und rechtlicher Quellen ein Modell entworfen, dass die
inhaltliche Ausgestaltung einer generellen Anforderungskategorie für Datenschutz in der Gestaltung und Vorkonfiguration von technischen Systemen und Komponenten beansprucht.

Der Abschnitt 4 unternimmt den Versuch, das im Abschnitt 3 erarbeitete Modell auf das Beispiel einer Anwendung anzuwenden, die eine mobile Arbeitszeiterfassung zum Ziel hat. Die Projektarbeit schließt mit einer Schlussbetrachtung im Abschnitt 5.

Sofern in dieser Ausarbeitung eine geschlechtsspezifi­sche Bezeichnung genutzt wird, ist dieses nicht wertend beabsichtigt. Wenn nicht durch die konkrete Situation eingeschränkt, steht jede geschlechtsspezifische Form
daher nur stellvertretend auch für jedes andere Geschlecht.

2 Begriffsdefinitionen

2.1 Privacy und Datenschutz

2.1.1 Privacy (Privatheit)

Nach Klitou stellt sich eine einheitliche Definition von Privacy als schwierig bis unmöglich dar [7]. Ein beachteter Versuch von Westin lautet „the claim of individuals, groups, or institutions to determine for themselves when, who and to what extent information about them is communicated to others“ [8] .

„Privacy is a dynamic concept that can mean different things to different people. For the purpose of these guidelines privacy is defined as the ability of individuals to know how their personal information will be collected, shared and used, and to exercise choice and control over its use“ [9].

ISACA führt sieben Kategorien von Privatheit aus: Die Privatheit der körperlichen Person, die des persönlichen Handelns, die der Kommunikation, die der personenbezogenen Information in jeder Form, die des Denkens und Fühlens, die Unverletzlichkeit des privaten
Raumes und die persönliche Freiheit der Versammlung und
Gruppenzugehörigkeit [10].

2.1.2 Datenschutz

Eine Definition von Datenschutz wird weder im BDSG noch in der DSGVO vorgenommen. Für die vorliegende Arbeit wird daher angenommen, dass Datenschutz die Menge aller Regelungen und Maßnahmen sein soll, die dafür bestimmt oder geeignet sind, die Privatheit von natürlichen Personen zu schützen.

2.1.3 Datenschutz durch Technik

„Datenschutz durch Technik bedeutet, dass Datenschutz gerade durch oder mit Hilfe der Technik realisiert wird“ [11] .

2.2 Das Prinzip „Privacy by Design“

„Hinter dem Konzept von Datenschutz durch Technikgestaltung steht die Idee, Technik von Anfang an so zu entwickeln, dass nur die unbedingt erforderlichen Daten überhaupt erhoben werden können“ [12] .

Cavoukian sieht in Privacy by Design ein Konzept, das über die Einhaltung
von regulatorischen Rahmenbedingungen hinaus gehen muss und bei dem der Schutz der Privatheit schon vom normalen Betriebszustand garantiert wird. Ihre sieben Grundsätze besagen, dass Datenschutz vorbeugend und
nicht reaktiv erfolgen soll, seine Konfiguration die Normaleinstellung der verarbeitenden Systeme ist, als integrierte Funktion in Entwurf und Architektur berücksichtigt wird, bei Abwägungen nicht als Hindernis sondern als Bereicherung im Sinne der Unternehmensziele angesehen wird, über den gesamten Lebenszyklus der enthaltenen Daten gewahrt wird, dass offen und transparent über Systeme und Verfahren berichtet wird und dass die Privatheit der Betroffenen bei allen getroffenen Maßnahmen respektiert wird [13].

Nach Klitou bezweckt Privacy by Design „to design and develop a system or device (i.e. software and/or hardware) in a way that supports and materializes those principles, values and rules as goals and functions, whereby that system or device then becomes `privacy­ aware` or `privacy­friendly`“ [14]. Es könne auch definiert werden als „practical measures, in the form of technological and design­based solutions, aimed at bolstering privacy/data protection laws, better ensuring or almost guaranteeing compliance, and minimizing the privacy­intrusive capabilities of the
technologies concerned“ [15] .

2.3 Das Prinzip „Privacy by Default“

„Datenschutzfreundliche `Voreinstellungen`“ charakteri­siert Plath [16] wie folgt:
„Schon bei der `Auslieferung` eines Produktes oder erstmaligem Freischalten oder Zur­-Verfügung­-Stellen einer Leistung sind – im Rahmen der Erforderlichkeit – die `datenschutzfreundlichsten` Einstellungen und
Komponenten zu verwenden. Im Wege der `Opt­-In`­-Lösung kann der Betroffene dann entscheiden, ob und inwiefern er diese Einstellung zum Nachteil seiner Privatsphäre abändern möchte“ [17] .

2.4 Anforderung

Nach ISO/IEC ist eine Anforderung eine „Festlegung, die zu erfüllende Kriterien angibt“ [18]. Anforderungen werden nach Ihrer Art und nach ihrer rechtlichen Verbindlichkeit eingeteilt [19].

Laut Rupp hat sich die Einteilung in die Kategorien funktionale, technologische und Qualitätsanforderungen, Anforderungen an die Benutzeroberfläche , an sonstige Lieferbestandteile, an durchzuführende Tätigkeiten und in rechtlich­-vertragliche Anforderungen bewährt. Die
alternative Kategorie nicht­-funktionale Anforderungen umfasst jede Anforderung, die keine funktionale Anforderung ist [20] . Andere Quellen kennen noch die Kategorie der Betriebsanforderungen [21].

„Die […] Verbindlichkeit beschreibt den Grad der Bedeutung, den der Stakeholder den Angaben in der Anforderungsspezifikation beimisst.[…] Üblicherweise wird die […] Verbindlichkeit durch Verwendung bestimmter Modalverben ausgedrückt“ [22].
Das in dieser Projektarbeit aufzustellende Anforderungsmodell soll Entwicklungsanforderungen zur Unterstützung des Datenschutzes in einer eigene Kategorie bündeln und sich thematisch gegen die Informationssicherheit abgrenzen können.

3 Modell Anforderungskategorie für Privacy by Design und by default

3.1 Modelle zum Datenschutz durch Technikgestaltung und Einordnung

Zunächst werden alternative Modelle aufgeführt und nach ihrer Verwertbarkeit für das aufzustellende Anforderungsmodell ausgewertet.

3.1.1 Technische und Organisatorische Maßnahmen

Das BDSG hat acht organisatorische Anforderungen an den Verantwortlichen für die Verarbeitung benannt, die zu ihrer Erfüllung auf technische Vorbedingungen angewiesen sind [23] . Tabelle A.1 in der Anlage leitet implizite Entwicklungsanforderungen für das Anforderungsmodell aus der Anlage zu §9 BDSG her.

3.1.2 Gewährleistungsziele im Datenschutz

Dem Konzept von Schutzzielen der Informationssicherheit aus Vertraulichkeit, Integrität und Verfügbarkeit wurden hier mit den Zielen Datenminimierung, Nichtverkettung, Transparenz, Intervenierbarkeit, Authentizität und Revisionsfähigkeit sechs weitere Erwartungen zur Seite gestellt [24] . Sie richten sich ebenfalls an den Verantwortlichen für die Verarbeitung und bleiben zu abstrakt, um als Anforderungen für eine
Technologie­-Entwicklung dienen zu können.

3.1.3 Analysemodelle im Datenschutz

Es lassen sich drei Arten von Analysemodellen unterscheiden: Bedrohungsanalysen [25] , Folgenabschätzun­gen [26] und Abwägungsanalysen [27] . Sie können zu speziellen Anforderungen
führen, die das generelle Anforderungsmodell ergänzen aber nicht für andere Systeme gelten. Außerdem sind sie geeignet, die Verbindlichkeit aus dem Anforderungsmodell für ein konkretes System zu ändern.

3.1.4 Zertifizierungen

Die wenigen Zertifizierungsmodelle für IT-­Produkte zum Datenschutz machen von den Gewährleistungszielen [28] und von den technischen und organisatorischen Maßnahmen nach 3.1.1 Gebrauch [29]. Neue Anforderungen stellen sie nicht auf.

3.1.5 Architektur­-Leitlinien

Eine Reihe von Quellen [30] bieten bereits Strategien und Anleitung, wie Funktionen zu entwerfen oder zu kombinieren sind, um eine möglichst Datenschutz-­freundliche Anwendung zu erreichen. Sie können herangezogen werden, um den Anforderungen des nachfolgenden Modells bei der Entwicklung und in der Lösung zu entsprechen.

3.2 Herangehensweise zum Aufbau des Modells

Nach der Abgrenzung und Aufstellung der formalen Grundlagen erfolgt die Erhebung und Auswertung von Anforderungsquellen. Dabei werden diejenigen Anforderungen ausgegrenzt, die sich an das verarbeitende Verfahren, dessen Betrieb oder die Qualifikation des Herstellers und Entwicklers richten. Die verbleibenden Anforderungen werden konkretisiert und entsprechend der formalen Syntax zusammengestellt. Mehrfach auftretende Anforderungen werden aggregiert.

3.2.1 Zielsetzung und Abgrenzung des Modells

Das nachstehende Modell soll Auftraggebern, Herstellern und Entwicklern [31] die generellen Anforderungen aufzeigen, die nach dem Grundsatz des Datenschutzes durch Technik­-Gestaltung und durch datenschutzfreundliche Voreinstellung an die zu entwickelnden technischen Systeme und Komponenten zu stellen sind.

Nicht betrachtet werden dabei Anforderungen, die an den Verantwortlichen für die Verarbeitung beim Einsatz der entwickelten Technologie zu stellen sind und die Anforderungen, die nach dem Stand der Technik bereits aus der Informationssicherheit zwingend zu berücksichtigen sind.

3.2.2 Formale Grundlagen des Modells

Die Anforderungen in diesem Modell werden in einer Schablone mit fester Syntax beschrieben [32] . Sie werden dabei als Funktionen beschrieben, auch wenn sie neben dem Zweck der Anwendung als nicht­-funktionale
Anforderungen zu verstehen sind.

Es werden die Schablonen „FunktionsMAST E R ohne Bedingung“ und „FunktionsMAST E R mit Bedingung“ nach Rupp [33] , wie in den Abbildungen A.1 und A.2 in der Anlage dargestellt, verwendet.

Der Grad der rechtlichen Verbindlichkeit soll in den folgenden vier Schlüsselworten angegeben werden.

Tabelle 3.1: Schlüsselworte der Verbindlichkeit

Schlüsselwort	Verbindlichkeit [34]
muss	Pflicht – zwingend zu erfüllen
soll	Wunsch – unverbindlich
wird	Absicht – deutet künftige Entwicklungen an, die berücksichtigt werden müssen verbindlich
darf nicht	Kommentar – mit dem Zweck, Fehlinterpretationen auszu­schließen ­verbindlich [35]

3.3 Anforderungsquellen

3.3.1 Prinzipien des Datenschutzes

Als allgemein anerkannte Grundsätze des Datenschutzes dürfen die im Privacy Framework [36] niedergelegten Datenschutzprinzipien der OECD (Organisation for Economic Co­-operation and Development) gelten, die von Weiss wie folgt übersetzt werden [37] .

Tabelle 3.2: Privacy Principles aus ISO/IEC 29100 mit Übersetzung nach Weiss

Privacy Principles [38]	Übersetzung nach Weiss [39]
Consent and choice	Zustimmung und Wahlrecht der betroffenen Personen
Purpose legitimacy and specification	Rechtmäßigkeit und Bestimmung des Verwendungszwecks
Collection limitation	Limitierung bei der Daten­erhebung
Data minimization	Datensparsamkeit und Minimierung auf das Nötigste
Use, retention and disclosure limitation	Zweckgebundenheit bei der Nutzung, Aufbewahrung und Herausgabe der Daten
Accuracy and quality	Richtigkeit und Qualität der Daten
Openness, transparency and notice	Offenheit, Transparenz und Mitteilungspflicht gegenüber den betroffenen Personen
Individual participation and access	individuelle Mitsprache und Garantie des Zugriffsrechts für die betroffenen Personen
Accountability	Verantwortlichkeit und Haftung
Information security	Sicherheit der Daten
Privacy compliance	Datenschutz Compliance

Tabelle A.2 in der Anlage leitet implizite Entwicklungsanforderungen aus den Privacy Principles her.

Ein zusätzliches Prinzip hat die APEC (Asia­-Pacific Economic Cooperation) als „Schadensvermeidung“ formuliert [40] . Die DSGVO führt zusätzlich die Prinzipien „Verarbeitung nach Treu und Glauben“, „Speicherbegrenzung“ und „Rechenschaftspflicht“ ein [41] . Alle diese Erweiterungen implizieren keine Anforderungen an die Gestaltung der Technik.

3.3.2 Weitere Quellen für Anforderungen

Die GSM Association (GSMA) Datenschutz Design Leitlinie [42] nimmt Bezug auf die Prinzipien des Datenschutzes und formuliert hieraus spezifische Anforderungen, die für die Entwicklung mobiler Anwendungen aufgestellt worden sind. Tabelle A.3 in der Anlage zeigt, welche konkreten Anforderungen aus der GSMA Datenschutz Design Leitlinie berücksichtigt
werden.

3.4 Rechtliche Obliegenheiten

Da die Produkthaftung nicht den Datenschutz umfasst, und die DSGVO es versäumt, den Hersteller selbst in die Pflicht zu nehmen [43] , kann der Verbindlichkeitsgrad der Anforderungen für ein Privacy by Design und by default nur mittels Abwägung des Verfassers im Sinne der Technik­-Ethik [44] festgelegt werden. Gewissenhaft durchgeführte Folgenabschätzungen können eine Herauf­- und Herabsetzung der Verbindlichkeit rechtfertigen, aus konkreten Vertragspflichten soll aber keine Herabsetzung folgen dürfen.

3.5 Die Anforderungskategorie Privacy by Design und by Default

In der nachstehenden Tabelle sind mit fortlaufender Zählung die einzelnen Anforderungen aufgeführt, die sich aus den berücksichtigten Quellen ableiten ließen.

Tabelle 3.3: Anforderungen an einen Datenschutz durch Technik­Gestaltung und datenschutzfreundliche Voreinstellung

Nr.	Quelle	Anforderung
A1	§9 BDSG	Das System muss eine individuelle Anmeldefunktion enthalten, die die Funktion der Anwendung erst nach erfolgreicher Authentisierung und Abgleich mit den Rechten des Anwenders bereitstellt.
A2	§9 BDSG	Die Beschreibung zum System muss jeden vorgesehenen Kommunikationsfluss dokumentieren.
A3	§9 BDSG	Das System wird Daten verschlüsselt und Integritätsgesichert übermitteln.
A4	§9 BDSG	Das System muss die Aufzeichnung und Auswertung von Änderungen an den gespeicherten Daten ermöglichen.
A5	§9 BDSG	Das System soll mandantenfähig sein.
A6	§9 BDSG	Das Datenmodell des Systems soll eine Trennung von Datensätzen nach den unterstützten Funktionen umsetzen.
A7	Privacy Principles	Das System soll vorerfasste Daten erst nach ausdrücklicher Bestätigung durch den Nutzer entgegennehmen.
A8	Privacy Principles	Das System soll im Anwender­-Kontext der Bestätigungsmöglichkeit eine Anzeigemöglichkeit für Datenschutzinformationen der Verantwortlichen Stelle bereitstellen.
A9	Privacy Principles	Das System soll eine Möglichkeit, mit der ein Nutzer seine vorherige Bestätigung widerrufen kann, bereitstellen. Bestätigung und Widerruf sollen dabei dokumentiert werden.
A10	Privacy Principles	Das Datenmodell zum System soll nur Datenfelder, von denen auch eine Funktion notwendig abhängt, aufweisen.
A11	Privacy Principles	Eine automatische Aktualisierung von Daten soll das System nur wenn eine Funktion davon abhängt, vornehmen.
A12	Privacy Principles	Das System soll angepasste Systemrechte für jede Anwenderrolle nach dem Need-­to­-Know Prinzip implementieren.
A13	Privacy Principles	Sofern für eine Funktionalität keine personenbezogenen Daten erforderlich sind, soll das System diese Daten auch nicht erheben und speichern müssen.
A14	Privacy Principles	Das System soll das selektive Löschen oder Sperren von Datensätzen aus dem Datenbestand ermöglichen.
A15	Privacy Principles	Das System soll eine Konfiguration für die Festlegung von Aufbewahrungsdauer und Löschfristen anbieten.
A16	Privacy Principles	Das Datenmodell und das System soll die Bildung und Nutzung von Pseudonymen an Stelle von Klardaten ermöglichen.
A17	Privacy Principles	Wenn ohne Funktionsverlust möglich soll im Datenmodell mit anonymisierten Daten an Stelle von Klardaten gearbeitet werden.
A18	Privacy Principles	Das System soll eine Möglichkeit zur Kenntnisnahme der gespeicherten Daten für den Betroffenen anbieten.
A19	Privacy Principles	Das System soll fähig sein, unbefugtes lesen, ändern oder löschen von Daten zu erkennen und zu melden.
A20	GSMA	Das System darf nicht ohne Kenntnis des Nutzers Daten erheben.
A21	GSMA	Das System soll die Möglichkeit bieten, vor jeder Übermittlung von Daten an außerhalb des Systems den Betroffenen um Zustimmung zu bitten.
A22	GSMA	Das System darf nicht seine Programmkomponenten auf Anwenderseite ohne Kenntnis des Anwenders austauschen oder aktualisieren.
A23	2.3	Das System soll mit der jeweils Datenschutz­-freundlichsten Einstellung ausgeliefert werden.

Der Ausdruck System ist jeweils als Platzhalter für alle Arten von technischen Entwicklungsergebnissen zu verstehen.

4 Anwendung des Modells an einem Beispiel

4.1 Beschreibung des Beispiels

Eine Server­Anwendung für die Arbeitszeiterfassung über Browser und mobile Android Applikation soll nach dem Grundsatz von Datenschutz durch Technik-­Gestaltung konzipiert werden. Die Vorgabe stammt von einem interessierten Großkunden. Der Hersteller möchte neben der klassischen kommt/geht Buchung auch den im Mobiltelefon eingebautem
GPS­-Empfänger als Datenlieferanten nutzen.

4.2 Anwendung der Anforderungen

In der nachstehenden Tabelle wird zu jeder Anforderung aus 3.5 dargestellt, mit welchen Maßnahmen der Anforderung begegnet wurde bzw. warum eine Anforderung nicht erfüllt werden konnte.

Tabelle 4.1: Umsetzung der Anforderungen in der Beispielanwendung

Nr.	Verbindlichkeit Erfüllungsstatus	Maßnahme
A1	Muss erfüllt	Zugriff an allen Bedienerschnittstellen (Server, Webclient und Android­-Client) nur nach Login möglich.
A2	Muss erfüllt	Im technischen Handbuch der Anwendung dokumentiert.
A3	Wird erfüllt	Alle Kommunikationswege sind aktuell nach TLS 1.2 verschlüsselt.
A4	Muss erfüllt	Jede Datenänderung wird in einem Transaktionslog aufgezeichnet.
A5	Soll erfüllt	Das Server­-Datenmodell lässt eine getrennte Datenhaltung nach Mandanten zu.
A6	Soll erfüllt	Das Server­-Datenmodell zeichnet Datensätze in nach Funktionen getrennten Tabellen auf.
A7	Soll erfüllt	Jede Zeitbuchung muss durch den Mitarbeiter ausgelöst werden. Für die Nutzung der Geo­-Lokation ist eine eigene Einwilligung erforderlich.
A8	Soll erfüllt	Pflichtanzeigen und Hilfefenster unterstützen den Nutzer bei der Ausübung seines Wahlrechtes.
A9	Soll nicht anwendbar	Da jede Buchung eine explizite Einwilligung darstellt ist ein Widerruf für die Zukunft nicht erforderlich.
A10	Soll erfüllt	Das Datenmodell folgt der gewünschten Funktionalität. Nicht konfigurierte Funktionen werden auch im Datenmodell nicht befüllt.
A11	Soll erfüllt	Die einzig vorgesehene automatisierte Aktualisierung erfolgt im Anwendungsfeld gefahrenträchtiger Arbeitseinsätze. In diesen Fällen erfolgt eine zeitgesteuerte Aktualisierung der Geo­-Position um einen Gefährdungsfall zeitnah zu erkennen und Hilfe senden zu können.
A12	Soll erfüllt	Die Nutzerrollen am System sind festgelegt und mit ihrer Aufgabe angepassten Systemrechten versehen.
A13	Soll nicht anwendbar	Nicht anwendbar. Nach dem vorliegenden Anwendungszweck gibt es keine Funktionen, die ohne Erfassung personenbezogener Daten auskommen können.
A14	Soll nicht anwendbar	Diese Anforderung muss hinter dem Integritätsanspruch der fachlichen Funktion einer revisionssicheren Zeitaufzeichnung zurückstehen.
A15	Soll erfüllt	Es gibt eine konfigurierbare Aufbewahrungsfrist, nach deren Ablauf die jeweiligen Zeitbuchungen tageweise gelöscht werden.
A16	Soll erfüllt	Der Personaleinsatzstatus ist nur auf Ebene der Filialleitung personalisiert dargestellt. Für die Führungskräfte höherer Ebenen (Regional-­ und Bereichsleiter) ist nur ein pseunonymisierter Personalstatus einsehbar.
A17	Soll nicht erfüllt	Im heutigen Anwendungsumfang sind keine Funktionen auf Basis anonymisierter Daten möglich.
A18	Soll erfüllt	Jeder Mitarbeiter erhält eine Systemrolle zugewiesen, mit der er seine eigenen Zeitbuchungen einsehen und ggf. Korrekturbuchungen ausführen kann.
A19	Soll nicht erfüllt	Zugriffe beruhen auf Nutzerrechten. Die Anwendung verweigert unberechtigten Rollen den Zugriff, kann aber nicht zwischen berechtigtem und unberechtigtem Nutzer einer Nutzerrolle unterscheiden.
A20	Darf nicht erfüllt	Eine verdeckte Datenerhebung erfolgt an keiner Stelle.
A21	Soll nicht erfüllt	Die Anwendung verfügt über eine Schnittstelle zu SAP­-Systemen der Personalverwaltung. Die Übermittlung erfolgt jeweils für den gesamten Datenauszug und ist nicht nach Mitarbeiter personalisierbar.
A22	Darf nicht erfüllt	Programmaktualisierungen werden grundsätzlich nicht verdeckt aufgespielt sondern müssen ausdrücklich vom Anwender aufgerufen und gestartet werden.
A23	Soll erfüllt	Die Anwendung wird in einer „gestoppten“ Konfiguration ausgeliefert. Vor der ersten Arbeitszeitbuchung sind Datenschutzangaben zu hinterlegen und jeder Nutzer muss der Datenerhebung erstmalig zustimmen.

 

4.3 Auswertung des Beispiels

Das vorliegenden Beispiel zeigt, dass das aufgestellte Anforderungsmodell für ein konkretes Vorhaben grundsätzlich mit geeigneten Maßnahmen der Technik­-Gestaltung beantwortet werden kann.

5 Schlussbetrachtung

Angesichts des bevorstehenden Inkrafttretens der DSGVO erscheint es befremdlich, dass sich noch kaum andere Arbeiten mit der Übersetzung von Datenschutz in Entwicklungsvorgaben auseinandergesetzt haben. Es wäre daher wünschenswert, wenn das hier aufgestellte Anforderungsmodell als Grundlage für weitere Arbeiten dienen kann.

Quellenverzeichnis

Artikel­29 Datenschutzgruppe (2009): Die Zukunft des Datenschutzes – Gemeinsamer Beitrag zu der Konsultation der Europäischen Kommission zu dem Rechtsrahmen für das Grundrecht auf den Schutz der personenbezogenen Daten. URL: http://ec.europa.eu
/justice/data­protection/article­29/documentation/opi
nion­recommendation/files/2009/wp168_de.pdf [Stand
04.03.2017].

Barlag, Ch. (2016): VI. Datensicherheit. In: Roßnagel, A.: Europäische Datenschutz­-Grundverordnung: Vorrang des Unionsrechts ­ Anwendbarkeit des nationalen Rechts. Baden­Baden: Nomos.

BfDI (2009): Info 1 ­ Bundesdatenschutzgesetz – Text und Erläuterung. Bonn: Der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit.

Bräutigam, L.; Höller, H.; Scholz, R. (1990): Datenschutz als Anforderung an die Systemgestaltung. Opladen, Westdeutscher Verlag

Cavoukian, A. (2011): Privacy by Design – The 7 Foundational
Principles. URL: https://www.ipc.on.ca/wp­content/uploads/Resources/
7foundationalprinciples.pdf [Stand 04.03.2017].

Ebel, N. (2011): PRINCE2:2009TM ­ für Projektmanagement mit Methode. München: Addison­Wesley.

EC (2015): M/530 Commission Implementing Decision. URL:
http://ec.europa.eu/growth/tools­databases/mandates/
index.cfm?fuseaction=search.detail&id=548# [Stand 04.03.2017].

EU, Amtsblatt (2016): Verordnung (EU) 2016/679 des Europäischen Parlaments und des Rates – Datenschutz­-Grundverordnung. URL: http://eur­lex.europa.eu/legal­-content/DE/TXT/PDF/?uri=CELEX:32016R0679 [Stand 04.03.2017].

Finneran Dennedy, M.; Fox, J.; Finneran, T. (2014): The Privacy Engineer`s Manifesto – Getting from Policy to Code to QA to Value. New York: Apress.

Gilliot, M.; Matyas, V.; Wohlgemuth, S. (2009): Privacy and Identity. In: Rannenberg, K.; Royer, D.; Deuker, A.: The Future of Identity in the Information Society. Heidelberg: Springer.

Greveler,U. (2016): Die Smart­-Metering­-Debatte 2010­ 2016 und ihre Ergebnisse zum Schutz der Privatsphäre. In: Datenbank Spektrum Jg.2016, H.2, 137­145.

Grunwald, A. (2011): Technikethik. In: Düwell, M.; Hübenthal, Ch.; Werner, M.: Handbuch Ethik. Stuttgart: Metzler/Poeschel.

GSMA (2012): Mobile and Privacy – Privacy Design Guidelines for Mobile application Development. URL: http://www.gsma.com/publicpolicy/wp­content/uploads/2012/03/gsmaprivacydesignguidelinesformobileapplicati
ondevelopmentv1.pdf [Stand 07.02.2017].

Hedbom, H. (2008): A Survey on Transparency Tools for Enhancing Privacy. In: Matyáš, V.; Fischer­-Hübner, S et.al.: The Future of Identity in the In­formation Society. IFIP Advances in Information and Communication Technology Vol. 298. Berlin/Heidelberg: Springer.

ISACA (2017): Infographic ­ The Seven Categories of Privacy that every Enterprise must address. URL: http://www.isaca.org/Knowledge­Center/Research/Documents/Privacy­Infographic_res_eng_0117.pdf [Stand 04.03.2017].

Klitou, D. (2014): Privacy­-Invading Technologies and Privacy by Design – Safeguarding Privacy, Liberty and Security in the 21st Century. Berlin/Heidelberg: T.M.C. Asser/Springer.

Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder (2016): Das Standard­-Datenschutzmodell ­ – Eine Methode zur
Datenschutzberatung und ­prüfung auf der Basis einheitlicher Gewährleistungsziele. URL: https://datenschutzzentrum.de/uploads/SDM­Methode_V_1_0.pdf [Stand 13.03.2017]

NORM ISO (2004) ISO/IEC Guide 2:2004 – Standardization and related activities – General vocabulary. Genf: ISO.

NORM ISO (2011): ISO/IEC 29100:2011 Information technology ­­ – Security techniques – ­­ Privacy framework. Genf: ISO.

NORM ISO (2013): ISO/IEC 29101:2013 Information technology ­­ – Security techniques ­­ – Privacy architecture framework. Genf: ISO.

Orrù, E. (2017): Minimum Harm by Design: Reworking Privacy by Design to Mitigate the Risks of Surveillance. In: Leenes, R. Et al.: Data Protection and Privacy: (In)visibilities and Infrastructures. Cham: Springer.

Plath, K.­U. (2016): BDSG/DSGVO – Kommentar zum BDSG und zur DSGVO sowie den Datenschutzbestimmungen von TMG und TKG. Köln: Dr. Otto Schmidt KG.

Rupp, Ch. et al. (2014):Requirements Engineering und ­-Management – Aus der Praxis von klassisch bis agil.6., aktualisierte und erweiterte Auflage. München: Hanser.

Scholz, P. (2014): §3a Datenvermeidung und Datensparsamkeit. In:
Simits,S.: Bundesdatenschutzgesetz. 8.Auflage, Baden­Baden: Nomos.

Shostack, A. (2014): threat modeling – designing for security. Indianapolis: Wiley.

Tayeh, M. (2014): Nein oder nicht Nein – Die Mär von der bösen negativen Anforderung. URL: https://www.sophist.de/fileadmin/SOPHIST/Puplikationen/re6/Kapitel_01/Nein_oder_nicht_Nein_­
_Der_Maer_von_der_boesen_negativen_Anforderung_30.10.
2014.pdf [Stand 12.03.2017].

ULD (2014): Anforderungskatalog v 2.0 für die Begutachtung von IT­Produkten im Rahmen des Gütesiegelverfahrens beim ULD SH. Kiel: ULD

Weiss, S. (2013): 6.Kapitel – Risikomanagement und Umgang mit besonderen Risikosituationen. In: Inderst, C.; Bannenberg, B.; Poppe, S: Compliance – Aufbau – Management – Risikobereiche. 2. neu bearb. Auflage. Heidelberg/München/Landsberg/Frechen/Hamburg: C.F.Müller.

Kurzreferenzen im Beitrag:

Anlagen

Tabelle A.1: Implizite Entwicklungsanforderungen aus der Anlage zu §9 BDSG

Maßnahme nach Anlage zu §9 BDSG	Entwicklungsanforderung an die verwendete Technologie
Zutrittskontrolle ­	– keine – ­
Zugangskontrolle ­	– keine – ­
Zugriffskontrolle	Das System muss eine individuelle Anmeldefunktion enthalten, die die Funktion der Anwendung erst nach erfolgreicher Authentisierung und Abgleich mit den Rechten des Anwenders bereitstellt
Weitergabekontrolle	1.Die Beschreibung zum System muss jeden vorgesehenen Kommunikationsfluss dokumentieren 2. Das System wird Daten verschlüsselt und Integritätsgesichert übermitteln
Eingabekontrolle	Das System muss die Aufzeichnung und Auswertung von Änderungen an den gespeicherten Daten ermöglichen
Auftragskontrolle	­- keine –
Verfügbarkeitskontrolle ­	– keine – ­
Zwecktrennung	1. Das Datenmodell zum System soll mandantenfähig sein 2. Das System soll eine Trennung von Datensätzen nach den unterstützten Funktionen umsetzen

Tabelle A.2: Implizite Entwicklungsanforderungen aus den Privacy principles nach ISO/IEC 29100:2011

1. Das System soll vorerfasste Daten erst nach ausdrücklicher Bestätigung durch den Nutzer entgegennehmen.

2. Das System soll im Anwender­ Kontext der Bestätigungs­möglichkeit eine Anzeigemög­lichkeit für Datenschutzinfor­mationen der Verantwortlichen Stelle bereitstellen.

3. Das System soll eine Möglichkeit, mit der ein Nutzer seine vorherige Bestätigung widerrufen kann, bereitstellen. Bestätigung und Widerruf sollen dabei dokumentiert werden.

Privacy principles	Entwicklungsanforderung an die verwendete Technologie
Consent and choice
Purpose legitimacy and specification	– keine ­-
Collection limitation	1. Das Datenmodell des Systems soll nur Datenfelder, von denen auch eine Funktion notwendig abhängt, aufweisen. 2. Eine automatische Aktuali­sierung von Daten soll das System nur wenn eine Funktion davon abhängt, vornehmen.
Data minimization	Das System soll angepasste Systemrechte für jede Anwenderrolle nach dem Need­-to­-Know Prinzip implementieren.
Use, retention and disclosure limitation	1. Sofern für eine Funktionalität keine personenbezogenen Daten erforderlich sind, soll das System diese Daten auch nicht erheben und speichern müssen. 2. Das System soll das selektive Löschen oder Sperren von Datensätzen aus dem Datenbestand ermöglichen. 3. Das System soll eine Konfi­guration für die Festlegung von Aufbewahrungs­dauer und Löschfristen anbieten. 4. Das Datenmodell und das System soll die Bildung und Nutzung von Pseudonymen an Stelle von Klardaten ermöglichen.5. Wenn ohne Funktionsverlust möglich soll im Datenmodell mit anonymisierten Daten an Stelle von Klardaten gearbeitet werden.
Accuracy and quality	– keine –
Openness, transparency and ­notice	– keine ­-
Individual participation and access	Das System soll eine Möglichkeit zur Kenntnisnahme der gespeicherten Daten für den Betroffenen anbieten.
Accountability ­	– keine – ­
Information security	Das System soll fähig sein, unbefugtes lesen, ändern oder löschen von Daten zu erkennen und zu melden.
Privacy compliance ­	– keine –

Tabelle A.3: Berücksichtigte Entwicklungsanforderungen aus der GSMA Datenschutz Design Leitlinie

GSMA	Entwicklungsanforderung an die verwendete Technologie
TCC1 Do not surreptitiously access or collect personal information.	Das System darf nicht ohne Kenntnis des Nutzers Daten erheben.
TCC5 Where necessary, gain the user’s active consent	Das System soll die Möglichkeit bieten, vor jeder Übermittlung von Daten an außerhalb des Systems den Betroffenen um Zustimmung zu bitten.
TCC7 No silent (‘secret’) updates.	Das System darf nicht seine Programmkomponenten auf Anwenderseite ohne Kenntnis des Anwenders austauschen oder aktualisieren.