You are on page 1of 210

Herausgeber

Georg Borges und Brigitte Werners

Identitätsmanagement im Cloud Computing


Evaluation ökonomischer und rechtlicher Rahmenbedingungen
Herausgeber
Georg Borges
Institut für Rechtsinformatik, Universität des Saarlandes, Saarbrücken, Deutschland

Brigitte Werners
Fakultät für Wirtschaftswissenschaft, Ruhr-Universität Bochum, Bochum, Deutschland

ISBN 978-3-662-55583-5 e-ISBN 978-3-662-55584-2


https://doi.org/10.1007/978-3-662-55584-2

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen


Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de
abrufbar.

© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die
nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des
Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen,
Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk


berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im
Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher
von jedermann benutzt werden dürften.

Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und
Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind.
Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder
implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen.

Springer ist ein Imprint der eingetragenen Gesellschaft Springer-Verlag GmbH, DE und ist ein
Teil von Springer Nature.
Die Anschrift der Gesellschaft ist: Heidelberger Platz 3, 14197 Berlin, Germany
Vorwort
Die zentrale Bedeutung des Identitätsmanagements für die digitale Gesellschaft, die wesentlich auf
der Kommunikation per Internet beruht und notwendig des Zugriffs per Internet auf geschützte
Anwendungen oder Inhalte bedarf, kann inzwischen als allgemein anerkannt angesehen werden.
Zugleich besteht Unsicherheit hinsichtlich der Anforderungen an ein passendes
Identitätsmanagement.
Die Etablierung eines geeigneten Identitätsmanagements ist eine Aufgabe, die nur
interdisziplinär gelöst werden kann. Dies gilt ebenso für die Formulierung der entsprechenden
rechtlichen Rahmenbedingungen.
Die wesentliche Stellschraube für die Konkretisierung der rechtlichen Anforderungen an
Identitätsmanagement ist das Verhältnis von Aufwand und Nutzen der jeweiligen
Schutzmaßnahmen. Damit sind Ökonomie und Recht unter Einbeziehung technischer Grundlagen
gefragt, geht es doch um die Optimierung des Schutzes gegen Identitätsmissbrauch im Verhältnis
zum Aufwand.
Die damit aufgeworfene Aufgabe war Gegenstand eines gemeinsamen Forschungsprojekts des
Lehrstuhls für Betriebswirtschaftslehre, insbesondere Unternehmensforschung und
Rechnungswesen (Prof. Dr. Werners) und des Lehrstuhls für Bürgerliches Recht, deutsches und
internationales Wirtschaftsrecht, insb. IT-Recht (Prof. Dr. Borges) der Ruhr-Universität Bochum.
Die wesentlichen Ergebnisse der Untersuchung sind in diesem Werk zusammengefasst. Aus
unserer Sicht ist die Untersuchung auch ein Beleg für das Potential der interdisziplinären
Zusammenarbeit in der IT-Sicherheit.
Das Forschungsprojekt und dieses Buch wären nicht möglich gewesen ohne die Horst Görtz
Stiftung, die das Projekt finanziert hat. Dafür sagen wir der Stiftung und Herrn Horst Görtz
persönlich herzlichen Dank!
Georg Borges
Brigitte Werners
Danksagungen
Herausgeber und Autoren danken der Horst Görtz Stiftung für die Förderung des Projektes
„IDENTITÄTSMANAGEMENT IM CLOUD COMPUTING“, welches die Grundlage für die
vorliegende Schrift war.
Inhaltsverzeichnis
Kapitel 1 Einführung:​ Herausforderunge​n an das Identitätsmanage​ment im Cloud
Computing
Georg Borges

Kapitel 2 Cloud Computing:​ Einsatz-, Bedrohungs- und Schadensszenarie​n


Alexander Golland und Andreas Schilling

Kapitel 3 Schutzmaßnahmen zur sicheren Identifizierung und Authentifizierun​g für Cloud-


basierte Systeme
Andreas Schilling

Kapitel 4 Rechtliche Rahmenbedingunge​n des Identitätsmangem​e nts im Cloud Computing


Alexander Golland und Peter Schneidereit

Kapitel 5 Quantitative Entscheidungsunt​e rstützung für ein sicheres Identitäts- und


Zugriffsmanageme​nt
Andreas Schilling und Brigitte Werners

Kapitel 6 Konkretisierung rechtlicher Anforderungen an das Identitätsmanage​ment im Cloud


Computing
Torben Kriegesmann und Peter Schneidereit

Kapitel 7 Zusammenfassung der Ergebnisse


Torben Kriegesmann und Andreas Schilling
© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018
Georg Borges und Brigitte Werners (Hrsg.), Identitätsmanagement im Cloud Computing, https://doi.org/10.1007/978-3-662-55584-
2_1

1. Einführung: Herausforderungen an das


Identitätsmanagement im Cloud Computing
Georg Borges1
(1) Universität des Saarlandes, Lehrstuhl für Bürgerliches Recht, Rechtsinformatik, deutsches
und internationales Wirtschaftsrecht sowie Rechtstheorie, 66123 Saarbrücken, Deutschland

Georg Borges
Email: georg.borges@uni-saarland.de

1 Cloud Computing und Identitätsmanagement


2 Konkretisierung rechtlicher Anforderungen an Identitätsmanagement
3 Grundlagen des Identitätsmanagements im Cloud Computing
3.1 Rechtliche Rahmenbedingungen des Identitätsmanagements
3.2 Bedrohungs- und Schadenszenarien
3.3 Kosten-Nutzen-Untersuchung technischer Sicherheitsmaßnahmen
4 Konkretisierung rechtlicher Anforderungen durch ökonomische Analyse
5 Identitätsmanagement und Compliance in der Praxis
Literatur

1 Cloud Computing und Identitätsmanagement


Cloud Computing entwickelt sich zu einer technischen und organisatorischen Grundlage der
digitalen Gesellschaft. Datenverarbeitung, nicht zuletzt die Datenspeicherung, erfolgt zunehmend
nicht durch eigene Datenverarbeitungsanlagen, sondern durch Nutzung von Cloud-Diensten. Dies
beruht zu einem großen Teil auf den enormen Effizienzvorteilen durch gemeinsame Nutzung von
Ressourcen, die zu erheblichen Kostenersparnissen führen können.1 Darüber hinaus ergeben sich
Vorteile auch durch eine einfache Handhabung des Zugriffs auf Daten per Internet durch
unterschiedliche Geräte, die von Verbrauchern, ebenso wie von Unternehmen, geschätzt werden.2
Entsprechend hat sich ein starker Trend zur Nutzung von Cloud-Diensten entwickelt, dem
Unternehmen, Behörden und ebenso Verbraucher folgen.3
Cloud Computing birgt aber auch spezifische Risiken, die insbesondere auf die für das Cloud
Computing charakteristischen Zugriffe auf die Daten per Internet zurückgehen, da hierdurch
internetbasierte Angriffe auf die Daten ermöglicht werden.
In diesem Zusammenhang hat der Missbrauch von Identitäten große praktische Bedeutung.
Identitätsmissbrauch liegt vor, wenn eine Identität (Identitätsdaten) unbefugt verwendet wird.4
Angriffe erfolgen in der Praxis sehr häufig durch den Missbrauch von Authentisierungsmedien (z.
B. Passwort) eines berechtigten Nutzers. Die Dimension dieser Herausforderungen wird durch
das Phänomen des Phishing und anderer Formen des Identitätsmissbrauchs deutlich.
Identitätsmissbrauch per Internet wurde in Deutschland durch die ersten großen Phishingwellen im
Online-Banking bekannt, die ab 2004 auftraten.5
Seitdem hat sich die Intensität des Identitätsmissbrauchs erheblich ausgeweitet. So war nach
Schätzungen des US-amerikanischen Justizministeriums im Jahr 2014 jeder siebte US-Bürger über
16 Jahren – insgesamt 17,6 Mio. Bürger – Opfer von Identitätsmissbrauch.6 Betroffen sind nahezu
alle Bereiche des elektronischen Geschäftsverkehrs. Insbesondere beim Online-Banking und im
Online-Handel sind immer neuere und aufwendigere Angriffsszenarien zu verzeichnen.7
Eine zentrale Herausforderung bei der Nutzung von Cloud-Diensten ist es daher, Daten gegen
den Zugriff Unbefugter per Internet zu schützen, insbesondere den Missbrauch von Identitäten
abzuwehren. Damit steht das Identitätsmanagement8 im Zentrum des Schutzes von Daten gegen
Zugriffe Unbefugter9

2 Konkretisierung rechtlicher Anforderungen an


Identitätsmanagement
Der Schutz von Daten gegen Zugriffe durch Unbefugte ist Gegenstand zahlreicher rechtlicher
Anforderungen. Identitätsmanagement ist damit eine Compliance-Aufgabe, die Nutzer und
Anbieter von Cloud-Diensten gleichermaßen trifft.
Das Ziel der Compliance, die Erfüllung rechtlicher Anforderungen in der Organisation zu
sichern,10 verlangt in Bezug auf die Abwehr von Identitätsmissbrauch und unbefugten Datenzugriff
die Kenntnis des Inhalts rechtlicher Anforderungen an Schutzmaßnahmen. Diese ist indes nicht
leicht zu erlangen. Die rechtlichen Anforderungen an das Identitätsmanagement im Cloud
Computing sind nicht spezifisch gesetzlich geregelt. Sie sind vielmehr aus allgemeinen rechtlichen
Anforderungen unterschiedlichster Art abzuleiten. Dabei gilt, dass sich die Anforderung, konkret:
die rechtliche Pflicht zur Durchführung bestimmter Schutzmaßnahmen, regelmäßig aus einer
Abwägung von Schutzbedarf und wirtschaftlicher Zumutbarkeit einer Schutzmaßnahme ergibt.
Sehr deutlich wird dieser Zusammenhang in § 9 Abs. 1 BDSG, der wie folgt lautet: „Öffentliche
und nicht-öffentliche Stellen […] haben die technischen und organisatorischen Maßnahmen zu
treffen, die erforderlich sind, um die Ausführung der Vorschriften dieses Gesetzes […] zu
gewährleisten. Erforderlich sind Maßnahmen nur, wenn ihr Aufwand in einem angemessenen
Verhältnis zu dem angestrebten Schutzzweck steht.“
Satz 1 formuliert eine gesetzliche Pflicht zur Vornahme der erforderlichen Schutzmaßnahmen,
und Satz 2 macht deutlich, dass die Konkretisierung der gesetzlichen Pflicht durch eine Abwägung
zwischen dem Schutzbedarf der jeweiligen Datenverarbeitung und dem Aufwand einer in Betracht
kommenden Schutzmaßnahme zu ermitteln ist.
Die damit erforderliche Abwägung stellt hohe Anforderungen an Nutzer und Anbieter von
Cloud-Diensten als Adressaten der gesetzlichen Pflicht.11 Entsprechend besteht insoweit
erhebliche Unsicherheit hinsichtlich der konkreten Anforderungen, viele Aspekte sind umstritten.12
Es ist daher von großem Interesse, wie eine verlässliche Konkretisierung der Anforderungen
erreicht werden kann.
In jüngster Zeit gibt es einige Ansätze zur Konkretisierung der Anforderungen an den Schutz
von Daten gegen unbefugten Zugriff. Ein interessanter Ansatz wurde etwa im Bereich des
Datenschutzrechts entwickelt. So hat das Pilotprojekt „Datenschutz-Zertifizierung für Cloud-
Dienste“13 im Auftrag des Bundesministeriums für Wirtschaft und Energie einen Prüfstandard für
Cloud-Dienste, das sogenannte Trusted Cloud-Datenschutzprofil für Cloud-Dienste (TCDP),14
entwickelt, dessen ausdrückliches Ziel es ist, die datenschutzrechtlichen Anforderungen des
BDSG für Cloud-Dienste zu konkretisieren.15 Einen teilweise ähnlichen Ansatz verfolgt das BSI
mit dem Schutzstandard „Anforderungen an Sicherheit im Cloud Computing“ (C 5),16 der
allerdings keinen direkten Bezug zu rechtlichen Normen hat.
Beide Ansätze verfolgen das Ziel, Anforderungen u. a. an Identitätsmanagement für den
Bereich des Cloud Computing zu konkretisieren. Sie geben jedoch keine konkrete Auskunft
darüber, wie die wirtschaftlichen Aspekte verschiedener in Betracht kommender
Schutzmechanismen im Zusammenhang mit rechtlichen Anforderungen zu berücksichtigen sind.
Diese Frage ist ein zentraler Gegenstand dieses Werks.

3 Grundlagen des Identitätsmanagements im Cloud Computing


3.1 Rechtliche Rahmenbedingungen des Identitätsmanagements
Das Identitätsmanagement im Cloud Computing ist in vielfacher Hinsicht Gegenstand rechtlicher
Regulierung. Hier sind vor allem die Regeln zum Schutz gegen Zugriffe durch Unbefugte von
Bedeutung. Auch insoweit können zahlreiche Normen ganz unterschiedlicher Art anwendbar sein.
Da Cloud-Dienste regelmäßig aufgrund eines Vertrags zwischen Anbieter und Nutzer des Cloud-
Dienstes erbracht werden, können Anforderungen an Schutzmaßnahmen vertraglich vereinbart
werden und ergeben sich, soweit keine ausdrückliche Regelung getroffen wird, aus allgemeinen
Schutzpflichten im Sinne des § 241 Abs. 2 BGB.17 Für einige Vertragsverhältnisse, etwa im
Bereich von Finanzleistungen, bestehen konkrete vertragsrechtliche Schutzanforderungen, etwa in
§ 675m BGB, für Zahlungsdienste.18
Neben vertraglichen Anforderungen bestehen deliktische Pflichten, die ihre Grundlage sowohl
in den allgemeinen Normen des Deliktsrechts, namentlich § 823 Abs. 1 BGB sowie § 823 Abs. 2
BGB in Verbindung mit Schutzgesetzen, als auch in Spezialgesetzen haben. Die größte Bedeutung
für Cloud Computing haben insofern die Anforderungen des Datenschutzrechts, da sehr häufig
personenbezogene Daten verarbeitet werden.19 Große Bedeutung haben branchenspezifische
Gesetze, etwa im Finanzbereich oder im Bereich von Sozialdaten.20
Ergänzend treten spezifische Regelungen zur IT-Sicherheit hinzu. Die steigende Bedeutung von
IT-Sicherheit – jüngst auch spezifisch und sektorübergreifend – kommt beispielsweise deutlich in
dem 2015 erlassenen IT-Sicherheitsgesetz zum Ausdruck.21
Die rechtlichen Rahmenbedingungen des Identitätsmanagements werden im vierten Kapitel im
Einzelnen dargestellt.
3.2 Bedrohungs- und Schadenszenarien
Die konkreten Anforderungen an den Schutz von Daten gegen unbefugten Zugriff sind, wie
dargestellt,22 regelmäßig durch eine Abwägung von Schutzbedarf und Kosten der in Betracht
kommenden Schutzmaßnahmen zu ermitteln. Die Ermittlung des Schutzbedarfs erfolgt auf der
Grundlage einer Risikoanalyse, bei der insbesondere der Umfang eines möglichen Schadens bei
Zugriff Unbefugter sowie die Wahrscheinlichkeit unbefugten Zugriffs zu berechnen sind.23
Eine solche Risikoanalyse ist ohne Kenntnis möglicher Angriffe nicht durchführbar. Daher
werden im folgenden zweiten Kapitel24 relevante internetgestützte Angriffe auf Cloud-Dienste
dargestellt.

3.3 Kosten-Nutzen-Untersuchung technischer Sicherheitsmaßnahmen


Der Kern der IT-Sicherheitsstrategie liegt in der Wahl geeigneter Maßnahmen der IT-Sicherheit.
Aus ökonomischer Sicht ist dabei eine Kosten-Nutzen-Analyse durchzuführen. Dabei ist
maßgeblich, welchen Nutzen (Sicherheitsgewinn) eine bestimmte Maßnahme der IT-Sicherheit
verspricht und welche Kosten damit verbunden sind. Um eine Quantifizierung effizient
durchzuführen, sollten bestehende, auch externe Informationen verwendet und in einem
quantitativen Ansatz berücksichtigt werden.25

4 Konkretisierung rechtlicher Anforderungen durch ökonomische


Analyse
Die rechtlichen Anforderungen an das Identitätsmanagement im Cloud Computing sind, wie
dargestellt,26 nicht ausdrücklich geregelt, sondern aus allgemeinen Bestimmungen zur Sicherheit
oder gar dem allgemeinen Deliktsrecht abzuleiten.
Eine zentrale Anforderung der Compliance im Cloud Computing ist es daher, allgemeine
rechtliche Anforderungen konkret für das Identitätsmanagement zu definieren. Insoweit hat sich in
den letzten Jahren eine breite Diskussion entwickelt, und es haben sich konkrete Pflichten
herausgebildet. Diese werden im sechsten Kapitel dargestellt. Entsprechend dem rechtlichen
Rahmen sind dabei insbesondere branchenübergreifende27 und branchenspezifische
Anforderungen28 zu unterscheiden.
Da sich die konkreten rechtlichen Anforderungen an IT-Sicherheit aus einer Abwägung von
Schutzbedarf und Zumutbarkeit von Schutzmaßnahmen ergeben, gewinnen die Ergebnisse aus
ökonomischer Analyse rechtliche Bedeutung. Bisher ist jedoch weitgehend unklar, inwieweit sich
als Ergebnis einer ökonomischen Analyse eine konkretere rechtliche Anforderung ergibt. Diese
Grundlagenfrage wird im sechsten Kapitel anhand der Ergebnisse des fünften Kapitels
analysiert.29
Die im Rahmen des Identitätsmanagements maßgeblichen Anforderungen, konkret die Pflichten
zum Schutz von Daten gegen Zugriffe Unbefugter, sind für eine Reihe weiterer rechtlicher Aspekte
von Bedeutung. Auch insofern können die Ergebnisse der Analyse fruchtbar gemacht werden.
Daher werden die Verantwortlichkeit unter dem Gesichtspunkt der Rechtsscheinhaftung30 sowie
die für die Praxis oft zentralen Beweisfragen31 im Lichte der Ergebnisse aus der ökonomischen
und rechtlichen Konkretisierung analysiert. Auch insoweit ergeben sich gegenüber dem bisherigen
Diskussionsstand Konkretisierungen.32

5 Identitätsmanagement und Compliance in der Praxis


Nutzer und Anbieter von Cloud-Diensten müssen in vielfacher Hinsicht eine Risikoabwägung
treffen und entsprechend Schutzmaßnahmen ergreifen, um die rechtlichen Anforderungen an Schutz
der Daten vor unbefugten Zugriffen zu erfüllen. Daher werden im siebten Kapitel die wesentlichen
Ergebnisse so zusammengefasst, dass sie für die Praxis nutzbar gemacht werden können.

Literatur
Auer-Reinsdorff, Astrid/Conrad, Isabell: Handbuch IT- und Datenschutzrecht, 2. Aufl., München 2016.

Borges, Georg/Meents, Jan Geert: Cloud Computing. Rechtshandbuch, München 2016.

Borges, Georg/Schwenk, Jörg/Stuckenberg, Carl-Friedrich/Wegener, Christoph: Identitätsdiebstahl und Identitätsmissbrauch im


Internet, Heidelberg 2011.

Borges, Georg: Cloud Computing und Datenschutz. Zertifizierung als Ausweg aus einem Dilemma, DuD 2014, 165–169.
[Crossref]

Borges, Georg: Die Datenschutz-Grundverordnung. Potentiale für praxisgerechten Datenschutz, in:


Schweighofer/Hötzendorfer/Sorge, Trends und Communities der Rechtsinformatik/Trends and Communities of Legal Informatics,
Tagungsband des 20. Internationalen Rechtsinformatik Symposions IRIS 2017, Wien 2017.

Borges, Georg: Rechtliche Aspekte der Internetportale für Heilberufe. Zugang, Beweis, Datensicherung, Baden-Baden 2007.

Borges, Georg: Rechtsfragen der Haftung im Zusammenhang mit dem elektronischen Identitätsnachweis, Baden-Baden 2011.

Borges, Georg: Rechtsfragen der Internet-Auktion, 2. Aufl., Baden-Baden 2014.


[Crossref]

Borges, Georg: Rechtsfragen des Phishing – Ein Überblick, NJW 2005, 3313–3117.

Busch, Christoph: Biometrie und Identitätsdiebstahl, DuD 2009, 317–317.


[Crossref]

Derleder, Peter/Knops, Kai-Oliver/Bamberger, Heinz Georg: Deutsches und europäisches Bank- und Kapitalmarktrecht, 3.
Aufl., Berlin Heidelberg 2017.

Gola, Peter/Schomerus, Rudolf: Bundesdatenschutzgesetz, 12. Aufl., München 2015.

Hameurlein, Abdelkader/Küng, Josef/Wagner, Roland/Schewe, Klaus-Dieter/Bosa, Karoly: Transactions on Large-Scale Data-


and Knowledge-Centered Systems XXX, Heidelberg 2016.

Hauschka, Christoph E./Moosmayer, Klaus/Lösler, Thomas: Corporate Compliance. Handbuch der Haftungsvermeidung im
Unternehmen, 3. Aufl., München 2016.

Hennrich, Thorsten: Compliance in Clouds. Datenschutz und Datensicherheit in Datenwolken, CR 2011, 546–552.

Hilber, Marc: Handbuch Cloud Computing, Köln 2014.

Hoeren, Thomas/Sieber, Ulrich/Holznagel, Bernd: Handbuch Multimedia-Recht, 43. EL, Stand: Juli 2016, München 2016.
Hossenfelder, Martin: Pflichten von Internetnutzern zur Abwehr von Malware und Phishing in Sonderverbindungen, Baden-Baden
2013, zugl. Dissertation an der Ruhr-Universität Bochum 2011/2012.

Martinek, Michael/Semler, Franz-Jörg/Flohr, Eckhard: Handbuch des Vertriebsrechts, 4. Aufl., München 2016.

Matros, Raimund: Der Einfluss von Cloud-Computing auf IT-Dienstleister, Wiesbaden 2012, zugl. Dissertation an der Universität
Heidelberg 2012.

Niemann, Fabian/Paul, Jörg-Alexander: Praxishandbuch Rechtsfragen des Cloud Computing, Berlin 2014.

Passarge, Malte: Risiken und Chancen mangelhafter Compliance in der Unternehmensinsolvenz, NZI 2009, 86–91.

Repschläger, Jonas/Pannicke, Danny/Zarnekow, Rüdiger: Cloud Computing: Definitionen, Geschäftsmodelle und


Entwicklungspotenziale, HMD Praxis der Wirtschaftsinformatik, Volume 47, 2010, 6–15.
[Crossref]

Roßnagel, Alexander: Wolken über dem Rechtsstaat?, Baden-Baden 2015.

Selzer, Annika: Die Kontrollpflicht nach § 11 Abs. 2 Satz 4 BDSG im Zeitalter des Cloud Computing. Alternativen zur Vor-Ort-
Kontrolle des Auftragnehmers durch den Auftraggeber, DuD 2013, 215–219.
[Crossref]

Simitis, Spiros: Bundesdatenschutzgesetz, 8. Aufl., Baden-Baden 2014.

Taeger, Jürgen/Gabel, Detlev: Kommentar zum BDSG und den einschlägigen Vorschriften des TMG und TKG, 2. Aufl. 2013,
Frankfurt a.M. 2013.

Tsolkas, Alexander/Schmidt, Klaus: Rollen und Berechtigungskonzepte, Wiesbaden 2010.

Wolff, Heinrich Amadeus/Brink, Stefan: Datenschutzrecht in Bund und Ländern, München 2013.

Fußnoten
1 Bieber/Schröder, in: Niemann/Paul, S. 37, 43; Matros, S. 60 f.; Repschläger/Pannicke/Zarnekow, HMD Praxis der
Wirtschaftsinformatik, 6, 13; Weiss, in: Hilber, Teil 1 A Rn. 22; siehe http://​www.​heise.​de/​microsites/​das-insider-portal/​cloud/​
kostenersparnis-und-mehr-agilitaet-durch-die-cloud/​150/​474/​1645/​ (zuletzt abgerufen am 25.10.2017); ebenso https://​business-
services.​heise.​de/​specials/​erfolgsfaktor-digitalisierung/​deutsche-cloud/​beitrag/​lohnt-sich-die-cloud-fuer-ihr-unternehmen-eine-
studie-sagt-ein-vergleich-kann-sich-lohnen-2984.​html (zuletzt abgerufen am 25.10.2017).

2 Bieber/Schröder, in: Niemann/Paul, S. 37, 42 f.; Weiss, in: Hilber, Teil 1 A Rn. 22 f.; dazu auch BMWi Monatsbericht 09-2013,
S. 1, abrufbar unter: https://​www.​bmwi.​de/​Redaktion/​DE/​Downloads/​Monatsbericht/​Monatsbericht-Themen/​09-2013-cloud-
computing.​pdf?​_ ​_ ​blob=​publicationFile&​v=​5 (zuletzt abgerufen am 25.10.2017); zu den Vorteilen des Cloud Computing siehe
https://​www.​heise.​de/​download/​blog/​Die-Vorteile-und-Nachteile-des-Cloud-Computing-3713041 und http://​www.​wiwo.​de/​
technologie/​digitale-welt/​cloud-welche-vorteile-bieten-cloud-dienste/​6288784-2.​html (zuletzt abgerufen am 25.10.2017).

3 Jaikar/Noh, in: Hameurlein et al., S. 2; nach einer Umfrage der Bitkom Research hat sich die Zahl der Unternehmen, die Nutzer
von Cloud-Diensten sind, von 28 % (2011) auf 54 % (2015) erhöht: Cloud-Monitor 2016, Charts (S. 5), abrufbar unter https://​
www.​bitkom.​org/​P resse/​Anhaenge-an-PIs/​2016/​Mai/​Bitkom-KPMG-Charts-PK-Cloud-Monitor-12-05-2016.​pdf, (zuletzt
abgerufen am 17.02.2017); hierzu auch https://​www.​bitkom.​org/​P resse/​P resseinformatio​n/​Erstmals-nutzt-die-Mehrheit-der-
Unternehmen-Cloud-Computing.​html. Ferner siehe auch https://​business-services.​heise.​de/​it-management/​cloud-computing/​
beitrag/​was-bringt-das-jahr-2016-aktuelle-trends-in-der-entwicklung-von-cloud-computing-services-2760.​html?​tx_​hbs_​
pi1%5B%40widget_​0%5D%5BcurrentPage%5D=​2&​cHash=​be745cfd9543441c​f0a7b4ec6b99dbda​ und http://​www.​it-cloud-
index.​de/​cloud-vorteile-zunehmend-akzepiert/​ (alle Seiten zuletzt abgerufen am 25.10.2017).

4 Borges, Identitätsnachweis, S. 113; Borges et al., S. 9; Busch, DuD 2009, 317; Hossenfelder, S. 122.

5 Borges, NJW 2005, 3313, 3313; Schwenk, in: Borges, Internet-Auktion, S. 355.

6 Harrell in U.S. Departement of Justice, Victims of Identity Theft, 2014, Sept. 2015 NCJ 248991, abrufbar unter: https://​www.​bjs.​
gov/​content/​pub/​pdf/​vit14.​pdf (zuletzt abgerufen am 25.10.2017). Verglichen mit dem Jahr 2008, in dem die Zahl der Opfer auf
11,7 Mio. US-Bürger geschätzt wurde (Pressemeldung U.S. Department of Justice v. 26.12.2010, abrufbar unter: https://​ojp.​gov/​
newsroom/​pressreleases/​2010/​BJS11044.​htm (zuletzt abgerufen am 25.10.2017)), bedeutet dies eine Steigerung von über 50 %.

7 Schwenk, in: Borges, Internet-Autkion, S. 359; Zu den Angriffsszenarien im Onlinebanking: Borges, in:
Derleder/Knops/Bamberger, Kap. I § 9 Rn. 262 ff.

8 Der Begriff des Identitätsmanagements wird unterschiedlich definiert. Hornung definiert den Begriff im rechtlichen Sinne als
nahe an technischen Konzepten liegendes „Identifizierungs-, Attributs- und/oder Berechtigungsmanagement“, das dem Nachweis
dient, dass eine Person bestimmte Eigenschaften und Berechtigungen inne hat, die durch das technische Konzept in Form von
Daten repräsentiert werden, Hornung, in: Roßnagel, Wolken über dem Rechtsstaat?, S. 189, 190 f.; in dieser Untersuchung
bezeichnet Identitätsmanagement den zielgerichteten Umgang mit Identitäten und deren Authentifizierung, siehe zur
Begriffsbestimmung Kap.​ 3, 2.​2.

9 Vgl. Hornung, in: Roßnagel, Wolken über dem Rechtsstaat?, S. 189, 200; Tsolkas/Schmidt, S. 33 f.; siehe dazu im Einzelnen
Kap.​ 2, 1.

10 Passarge, NZI 2009, 86, 86; ders., in: Martinek/Semler/Flohr, § 79 Rn. 88; ähnliche Definitionen bei: Behling, in:
Borges/Meents, § 13 Rn. 1; Hennrich, CR 2011, 546, 547; nach anderem Verständnis meint Compliance die Einhaltung
gesetzlicher Vorschriften, vgl.: Kramer/Meints, in: Hoeren/Sieber/Holznagel, Teil 16.5 Rn. 6.

11 Siehe dazu Kap.​ 4, 5.​3.

12 Zu den praktischen Problemen der Abwägung des § 9 beim Cloud Computing Hennrich, CR 2011, 546, 551; zur Erfüllung der
Kontrollpflicht gem. § 11 Abs. 2 S. 4 BDSG beim Cloud Computing Borges, in: Borges/Meents, § 7 Rn. 67 ff.; Selzer, DuD
2013, 215, 217 ff.

13 Siehe zu diesem Projekt Borges, DuD 2014, 165, 167; ders., Die Datenschutz-Grundverordnung. Potentiale für praxisgerechten
Datenschutz, in: Schweighofer/Hötzendorfer/Sorge, S. 67, 69 ff.; Conrad/Strittmatter, in: Auer-Reinsdorff/Conrad, § 22 Rn. 168;
siehe auch www.​tcdp.​de (zuletzt abgerufen am 25.10.2017).

14 Das TCDP ist abrufbar unter www.​tcdp.​de (zuletzt abgerufen am 25.10.2017).

15 TCDP – Version 1, S. 4, http://​www.​tcdp.​de/​data/​pdf/​TCDP-1-0.​pdf (zuletzt abgerufen am 25.10.2017); vgl. auch die Präambel
der Verfahrensordnung für Zertifizierungen nach TCDP, abrufbar unter http://​www.​tcdp.​de/​data/​pdf/​Verfahrensordnun​g-1-0.​pdf
(zuletzt abgerufen am 25.10.2017).

16 Siehe dazu https://​www.​bsi.​bund.​de/​DE/​Themen/​DigitaleGesellsc​haft/​CloudComputing/​Anforderungskata​log/​Anforderungskata​


log_​node.​html (zuletzt abgerufen am 25.10.2017).

17 Dazu unten Kap.​ 4, insb. unter 2.​1.​3, 2.​1.​4; Kap.​ 6, 2.​1.​1, 2.​1.​2; Kap.​ 7, 3.​2.

18 Dazu unten Kap.​ 6, 3.​1.​2.

19 Dazu unten Kap.​ 4, 5; Kap.​ 6, 2.​2; Kap.​ 7, 3.​4.

20 Dazu unten Kap.​ 4, 6.​1 – Kreditwirtschaft, 6.​2 – Sozialversicherungsträger; zu Verpflichtungen der öffentlichen Hand, 8 –
Öffentliches Recht.

21 Dazu unten. Kap.​ 4, 3 – TMG.

22 Vgl. oben 2.

23 Borges, Heilberufe, S. 68; Ernestus, in Simitis, BDSG, § 9 Rn. 27; Gola/Klug/Körffer, in: Gola/Schomerus, § 9 BDSG Rn. 9;
Hartung/Storm, in Hilber, Teil 4 Rn. 114; Karg, in: Wolff/Brink, § 9 BDSG Rn. 82, 84 f., 101; dazu auch: Schultze-Melling, in:
Taeger/Gabel, § 9 BDSG Rn. 25, 27, 29 ff.

24 Vgl. Kap.​ 2, 4.

25 Vgl. Kap.​ 5.
26 Vgl. oben 2 und 3.1.

27 Dazu. Kap.​ 6, 2.

28 Dazu Kap.​ 6, 3 und 6, 4.

29 Dazu Kap.​ 6, 5.

30 Dazu Kap.​ 6, 6.​1.

31 Vgl. Kap.​ 6, 6.​2.

32 Siehe Kap.​ 6, 6.​1, 6.​2 und 7.


© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018
Georg Borges und Brigitte Werners (Hrsg.), Identitätsmanagement im Cloud Computing, https://doi.org/10.1007/978-3-662-55584-
2_2

2. Cloud Computing: Einsatz-, Bedrohungs- und


Schadensszenarien
Alexander Golland1 und Andreas Schilling2
(1) Landgericht Bochum, 44787 Bochum, Deutschland
(2) Ruhr-Universität Bochum, Fakultät für Wirtschaftswissenschaft, 44780 Bochum, Deutschland

Alexander Golland (Korrespondenzautor)


Email: alexander.golland@rub.de

Andreas Schilling
Email: andreas.schilling@rub.de

1 Cloud Computing und Identitätsmanagement


2 Cloud Computing
2.1 Anwendungsgebiete
2.2 Formen des Cloud Computing
2.3 Einsatzszenarien
3 Prozesse des Zugriffs- und Identitätsmanagements
3.1 Struktur einer Identität
3.2 Aktuelle Erscheinungsformen
3.3 Potenzielle Erscheinungsformen
4 Bedrohungsszenarien
4.1 Angriffsmethoden
4.1.1 Externe Angriffe
4.1.2 Interne Angriffe
4.1.3 Cloud-spezifische Angriffe
4.1.4 Angriffe bei Verwendung von Nutzername und Kennwort
4.1.4.1 Klassische Angriffe auf Identifizierungssysteme
4.1.4.2 Angriffe aus der Cloud
4.1.4.3 Probleme durch Einschaltung von Unterauftragnehmern
4.1.5 Angriffe bei Verwendung einer Zwei-Faktor-Authentisierung
4.1.5.1 Einmalpasswörter (OTP)
4.1.5.1.1 E-Mail
4.1.5.1.2 SMS
4.1.5.1.3 App
4.1.5.1.4 Standalone-Geräte
4.1.5.2 Smartcards
4.1.5.3 Elektronischer Identitätsnachweis (eID)
4.1.6 Angriffe bei Verwendung von Single-Sign-On (SSO)
4.1.7 Folgeangriffe
5 Schadensszenarien
5.1 Szenario 1: Mittelständisches Unternehmen
5.1.1 Zugriffsverhinderung
5.1.2 Löschen von Daten
5.1.3 Ausspähen von Daten Dritter
5.1.4 Manipulation von Daten Dritter
5.2 Szenario 2: Kreditwirtschaft
5.3 Szenario 3: Sozialleistungsträger
5.4 Szenario 4: Berufsgeheimnisträger
5.5 Szenario 5: Verbraucher
Literatur

1 Cloud Computing und Identitätsmanagement


Die Berechtigung zum Datenzugriff im Cloud Computing erfordert in vielen Bereichen die
Identifizierung der Person, die Zugriff auf die Daten nehmen will. Damit rückt die zuverlässige
Feststellung der Identität einer konkreten natürlichen Person in den Fokus. Das Identitäts- und
Zugriffsmanagement ist somit ein Schlüsselfaktor für das Cloud Computing.
Der Begriff des Identitätsmanagements bezeichnet allgemein den zielgerichteten Umgang mit
Identitäten und deren Authentifizierung.1 Primäres Ziel ist die Authentifizierung von Attributen
eines Nutzers, um so die sichere Interaktion mit Informationssystemen zu ermöglichen. Es ist die
Aufgabe des Identitätsmanagements im Cloud Computing, sicherzustellen, dass Nutzer jederzeit
und von überall auf Informationen zugreifen können. Gleichzeitig dürfen nur Nutzer Zugriff auf
Informationen haben, für die eine Berechtigung zum Zugriff vorliegt. Um Daten vor dem Zugriff
Unbefugter zu schützen, können verschiedene Authentifizierungsmethoden eingesetzt werden. In
der Praxis wird eine Vielzahl unterschiedlicher Verfahren eingesetzt. Teilweise werden
besonders kritische Systeme stärker geschützt, wohingegen in anderen Fällen nur unzureichende
Maßnahmen getroffen werden.
Es besteht nach wie vor große Unsicherheit darin, welche Schutzmaßnahmen im Rahmen des
Identitätsmanagements ökonomisch sinnvoll und rechtlich geboten sind. Eine besondere
Schwierigkeit besteht darin, dass die rechtliche Pflicht zur Vornahme bestimmter
Schutzmaßnahmen aufgrund einer Abwägung von Eingriffsrisiken und daraus resultierenden
Schadensszenarien einerseits und dem Aufwand für die technisch möglichen Schutzmaßnahmen
andererseits zu bestimmen ist. Zugleich liefern rechtliche Vorgaben zentrale Parameter für die
ökonomische Entscheidung über den Einsatz bestimmter Sicherungsmaßnahmen. Eine
entsprechende Analyse der Interdependenzen von technischen, ökonomischen und rechtlichen
Aspekten ist daher Schwerpunkt dieser Untersuchung. Dazu wurden mathematische
Optimierungsmodelle entwickelt und eingesetzt, um die umfangreichen Interdependenzen
strukturiert zu erfassen, eine quantitative Evaluation zu ermöglichen und eine
Entscheidungsunterstützung abzuleiten.
Bei der Untersuchung des Identitätsmanagements werden in diesem Buch verschiedene
Anwendungsszenarien berücksichtigt, die jeweils durch bestimmte rechtliche Anforderungen und
ökonomische Faktoren charakterisiert sind. Es werden unter anderem die aktuell eingesetzten
Authentisierungsmethoden, namentlich die Verwendung von Benutzername und Kennwort sowie
von OTP und SSO, berücksichtigt und deren Eignung überprüft. Zur Analyse werden weitere
sichere Verfahren hinzugezogen, die bereits außerhalb des Cloud Computing Anwendung finden,
wie beispielsweise Smartcards und der Einsatz des elektronischen Identitätsnachweises.
Ebenfalls weit verbreitet ist die Nutzung eines zweiten Kommunikationskanals, über welchen ein
Teil der Kommunikation abgewickelt wird. Ein typisches Beispiel sind Aktivierungscodes, die
als Kurznachricht auf einem Mobiltelefon empfangen werden und anschießend über den primären
Kommunikationskanal zurückkommuniziert werden müssen. Die Sicherheit dieses Verfahrens
beruht auf der Annahme, dass ein Angreifer nicht beide Kanäle gleichzeitig angreift. Um eine
umfassende Aussage und Empfehlungen für ein sicheres Cloud Computing zu treffen, werden diese
und weitere Aspekte kombiniert und aus wirtschaftlicher sowie rechtlicher Sicht diskutiert.

2 Cloud Computing
2.1 Anwendungsgebiete
Ein wichtiger Anwendungsbereich des Cloud Computing ist die ausgelagerte Datenverarbeitung
kleiner und mittlerer Unternehmen. Diese verfügen häufig nicht über die notwendige
informationstechnische Infrastruktur oder das nötige Know-how, um große Datenmengen zu
verarbeiten, Leistungsskalierbarkeit zu gewährleisten und eine hohe Verlässlichkeit hinsichtlich
Ausfallzeiten zu garantieren.
Zudem werden Unternehmen der Kreditwirtschaft betrachtet, welche zunehmend in Cloud
Computing investieren: 56 % der deutschen und österreichischen Banken planen Investitionen in
Cloud Computing.2 Da Online-Banking seit langem ein attraktives Ziel für Angriffe ist, gibt es hier
ein besonders hohes Schadenspotenzial durch Identitätsmissbrauch. In rechtlicher Hinsicht gelten
für die Datenverarbeitung über die Anforderungen des BDSG hinaus Sondervorschriften.
Drittens werden Sozialleistungsträger betrachtet: Krankenkassen, Pflegekassen,
Berufsgenossenschaften, Träger der gesetzlichen Rentenversicherung und andere
Sozialleistungsträger benötigen zur Erfüllung ihrer Aufgaben höchst detaillierte und intime
Informationen. Um diesem besonderen Eingriff in die Privatsphäre gerecht zu werden, hat der
Gesetzgeber den Sozialdatenschutz normiert. In rechtlicher Hinsicht gelten für die
Datenverarbeitung die spezielleren Vorschriften des 10. Sozialgesetzbuchs, insb. § 80 SGB X.
Ein viertes Anwendungsfeld sind andere Berufsgeheimnisträger wie z. B. Rechtsanwälte oder
Ärzte. Neben den allgemeinen datenschutzrechtlichen Anforderungen finden berufsrechtliche
Sondervorschriften Anwendung. Für Berufsgeheimnisträger sind außerdem strafrechtliche
Sanktionen durch Verletzung des § 203 StGB denkbar.
Ein fünftes wichtiges Feld, in dem Cloud Computing Anwendung findet, stellen Angebote dar,
die sich direkt an den Verbraucher richten, insbesondere Filehoster3 und E-Mail-Konten4 in der
Cloud. In datenschutzrechtlicher Hinsicht besteht hier die Besonderheit, dass der Cloud-Nutzer
sowohl verantwortliche Stelle als auch von der Datenverarbeitung Betroffener ist.

2.2 Formen des Cloud Computing


Der Begriff des Cloud Computing umfasst verschiedenste Aspekte, die zu einer Vielzahl
variierender Definitionen führen. Die Definition des National Institute of Standards and
Technology (NIST) umfasst die wesentlichen Begrifflichkeiten und wird im Folgenden als
Referenz verwendet.
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access
to a shared pool of configurable computing resources (e.g., networks, servers, storage,
applications, and services) that can be rapidly provisioned and released with minimal
management effort or service provider interaction. This cloud model is composed of five
essential characteristics, three service models, and four deployment models.5

Die fünf charakteristischen Eigenschaften nach Mell/Grance sind:


On-demand self-service: Bei Bedarf werden automatisch Rechenressourcen bereitgestellt,
sodass keine Interaktion mit dem Anbieter nötig ist.
Broad network access: Der Zugriff auf Ressourcen über ein Netzwerk wird durch
Standardtechnologien ermöglicht, was zusätzlich eine große Heterogenität der Clients
ermöglicht.
Resource pooling: Ressourcen werden mehreren Clients parallel zur Verfügung gestellt.
Diese Eigenschaft wird auch als Mandantenfähigkeit bezeichnet. Verschiedene physische
Ressourcen werden den Konsumenten nach Bedarf zugeteilt bzw. unter diesen aufgeteilt. Der
Konsument hat keine Kontrolle oder Kenntnis über den exakten physischen Standort seiner
Ressourcen.
Rapid elasticity: Ressourcen werden elastisch, also im weitesten Sinne variabel, teils
automatisch entsprechend dem Bedarf zugeteilt. Der Umfang der Leistung ist also skalierbar
und kann zu jeder Zeit der Nachfrage angepasst werden.
Measured service: Das System ist in der Lage, Ressourcen zu kontrollieren und deren Einsatz
optimal zu gestalten. Dies schließt die Überwachung, Kontrolle und Berichterstattung
gegenüber dem Anbieter und Nutzer ein. Dies ist erforderlich, um eine nutzungsabhängige
Abrechnung der Ressourcennutzung zu ermöglichen.
Die bedeutendsten Servicemodelle im Cloud Computing sind Software as a Service (SaaS),
Platform as a Service (PaaS) und Infrastructure as a Service (IaaS). Die Unterscheidung grenzt
den Umfang der zur Verfügung gestellten Ressourcen voneinander ab. Im SaaS-Modell werden
ausschließlich Anwendungen bereitgestellt, welche auf einer Cloud-Infrakstruktur oder -Plattform
betrieben werden. Für den Anwender ist diese Komplexität vollständig verborgen, und er
interagiert ausschließlich über die Anwendung selbst. Bei der Nutzung von PaaS wird dem
Anwender eine Plattform angeboten, die zur Bereitstellung eigener Anwendungen genutzt werden
kann. Die eigentliche Infrastruktur bleibt weiterhin verborgen, und wird vom Anbieter verwaltet.
Im IaaS-Modell erhält der Konsument direkten Zugriff auf die virtualisierten Ressourcen (wie z.
B. virtuelle Maschinen, Datenbanken oder Netze) und kann so eine eigene Cloud-Infrastruktur
erzeugen. Jede virtuelle Instanz kann beliebig konfiguriert und entsprechend den Anforderungen
angepasst werden.6 Einzelne Ressourcen auf Infrastrukturebene werden teilweise noch weiter
klassifiziert. Verschiedene Speicherkapazitäten werden als Data-Storage as a Service (DaaS)
bezeichnet, Kommunikationsmöglichkeiten als Communications as a Service (CaaS) und
ausgelagerte Hardware als Hardware as a Service (HaaS).7
Bei der Bereitstellung der Services werden vier Bereitstellungsmodelle unterschieden,
welche sich im Wesentlichen hinsichtlich der organisatorischen Form der Anwender
unterscheiden. Im Falle einer Private Cloud werden Ressourcen einer einzelnen Organisation
bereitgestellt. Dieses Bereitstellungsmodell kann zu einer erhöhten Sicherheit führen, wenn
Anbieter und Benutzer derselben Organisation angehören. Es handelt sich jedoch auch um eine
Private Cloud, wenn ein externer Anbieter die Ressourcen exklusiv nur einem Kunden anbietet.
Der Nutzer hat allerdings in beiden Fällen eine erhöhte Kontrolle über die bereitgestellten
Ressourcen. Im Falle einer Community Cloud werden Ressourcen gemeinsam von mehreren
Organisationen genutzt, die sich üblicherweise in ihren Anforderungen ähneln. Die Ressourcen
einer Public Cloud werden öffentlich angeboten. Hybrid Clouds umfassen alle möglichen
Mischformen der genannten Modelle.8

2.3 Einsatzszenarien
Die – insbesondere ökonomischen9 – Vorteile des Cloud Computing haben zu einer Verbreitung
der Nutzung des Cloud Computing im gewerblichen Bereich geführt. Durch die Möglichkeit auf
Leistungen über das Internet zugreifen zu können, sinken in vielen Bereichen die
Markteintrittsbarrieren. So reduzieren sich Investitionskosten für Start-Ups oder kleine und
mittelständische Unternehmen in die IT-Infrastruktur sowie Kosten für entsprechendes Personal
zur Implementierung und Pflege der Systeme.10
Durch die hohe Skalierbarkeit und einen „on-demand self-service“ können Dienste schnell und
flexibel an die Bedürfnisse eines Unternehmens angepasst werden. Aufgaben, welche auf hohe
Rechenkapazitäten angewiesen sind, können dadurch flexibel abgearbeitet werden, ohne dass
Investitionen für die Anschaffung zusätzlicher Ressourcen notwendig sind. Durch die Messbarkeit
der in Anspruch genommenen Leistungen ist eine leistungsabhängige Abrechnung möglich. Kosten,
die in Leerzeiten bzw. bei ungenutzten Kapazitäten entstehen, werden vermieden.
Im Vergleich zu klassischen IT-Infrastrukturen zeichnen sich Cloud Computing-Angebote
durch eine erhöhte Effizienz aus, da die eingesetzten physikalischen Maschinen deutlich höhere
Nutzungsquoten aufweisen. Die verbesserte Ausnutzug realer Ressourcen wird durch den Einsatz
von Virtualisierung erreicht. Die Virtualisierung von Ressourcen ermöglicht zudem deutliche
Skalierungseffekte. Der Nutzer nimmt die zur Verfügung stehenden Ressourcen dadurch praktisch
als unbegrenzt wahr. Die tatsächliche Kapazität ist jedoch weiterhin durch die Infrastruktur des
Anbieters limitiert. Durch ein ausgeglichenes Mehrbenutzersystem und die dadurch entstehenden
Skalierungseffekte können die Ressourcen so verteilt werden, dass der Nutzungsgrad der
Infrastruktur deutlich steigt.
Die Nutzung von Cloud-Angeboten hat zur Folge, dass die notwendigen Fachkenntnisse im IT-
Bereich für die nutzenden Unternehmen zurückgehen. Prinzipiell kann durch die Auslagerung der
Verantwortung für den Betrieb der Anwendungen und Systeme die Zuverlässigkeit sowie die
Sicherheit deutlich gesteigert werden. Dies wird vornehmlich durch die höhere Spezialisierung
und eine starke Expertise der Anbieter erreicht.11 Dies impliziert jedoch nicht, dass Cloud-
Lösungen prinzipiell sicherer sind. Durch eine sachgerechte Analyse der veränderten
Gegebenheiten und die Anwendung entsprechender Maßnahmen besteht allerdings das Potenzial,
die Sicherheit zu steigern.
Heutzutage wird Cloud Computing auch im Bereich des Banking12 und des Online-Handels13
eingesetzt. Auf dem Markt haben sich Anbieter positioniert, die Cloud-Lösungen für spezielle
Anwendungsbereiche entwickelt haben, wie z. B. für Rechtsanwälte und Steuerberater14 oder
Krankenhäuser.15 Vornehmlich geht es hier um die Bereitstellung von Speicher- und
Rechenkapazitäten (IaaS).16 Daneben gibt es Angebote, die sich direkt an den Verbraucher richten.
Diese umfassen sowohl Bereiche des IaaS17 als auch Bereiche des SaaS.18
Die European Network and Information Security Agency (ENISA) bezeichnet Cloud
Computing aufgrund der hohen Konzentration von Nutzern und Daten sowie der zunehmenden
Anwendung in sensiblen Sektoren, wie Finanz-, Gesundheits- und Versicherungswesen, als
bedenklich.19

3 Prozesse des Zugriffs- und Identitätsmanagements


Die Sicherheit von Informationssystemen hängt grundsätzlich von drei allgemeinen Bereichen ab.
Der erste Bereich ist die „Trusted Computing Base“ (TCB), welche sich aus Hardware,
Firmware und Software zusammensetzt. Dies sind die Komponenten, welche im Kern für die
Sicherheit des Systems verantwortlich sind. Treten dort Sicherheitsprobleme auf, beeinträchtigt
dies unmittelbar die Sicherheit des Systems und damit aller weiteren Systemkomponenten. Der
nächste Bereich ist die Authentifizierung in Informationssystemen, welche sicherstellt, dass
Benutzer korrekt identifiziert werden. Die Authentifizierung von Benutzern ist unmittelbare
Vorstufe des dritten Bereichs, der Autorisierung. 20 Die Autorisierung von Benutzern stellt nach
erfolgreicher Authentifizierung sicher, dass Benutzer nur auf Daten oder Ressourcen zugreifen
können, für die eine Berechtigung vorliegt.21
Wenngleich alle Bestandteile zur Gesamtsicherheit beitragen, beschränkt sich diese
Untersuchung vornehmlich auf die Authentifizierung von Nutzern.

3.1 Struktur einer Identität


Der Begriff der Identität ist vielschichtig in seiner Bedeutung und wird in der Literatur
unterschiedlich definiert. Grundsätzlich ist die Identität die Summe der Informationen über eine
Entität, welche erforderlich sind um diese eindeutig zu identifizieren.22 Bedingt durch
verschiedene mögliche Rollen einer Entität kann eine Identität aus mehreren Teil-Identitäten
bestehen. Jede Teil-Identität identifiziert die Entität folglich in einem spezifischen Kontext und
besteht nur aus den für diese Identifizierung notwendigen Informationen. Die Informationen setzen
sich allgemein aus Identitätsbezeichnern und Attributen zusammen.23 Bezeichner sind in der Regel
innerhalb eines Kontextes eindeutig und dienen der direkten Identifizierung (z. B. Personalnummer
in einem Unternehmen).24 Zur Klassifizierung verschiedener Attributstypen unterscheiden
Bertino/Takahashi zwischen dokumentbasierten, demografischen, finanztechnischen,
biometrischen und transaktionsbasierten Attributen.25
Dokumentenbasierte Attribute sind Teil von offiziellen Dokumenten, welche von Behörden
ausgestellt werden. Typische Dokumente sind der Personalausweis, Reisepass oder die
Geburtsurkunde. Die eigentlichen Attribute sind beispielsweise die Personalausweisnummer oder
die Sozialversicherungsnummer. Durch die strenge Prüfung und Kontrolle bei der Ausstellung
entsprechender Dokumente zählen dokumentenbasierte Attribute zu den stärksten Attributstypen.
Im Gegensatz dazu ermöglichen demografische Attribute nur eine sehr schwache Identifizierung.
Mögliche Werte sind Alter, Geschlecht, Staatsangehörigkeit oder die Postadresse. Obwohl ein
einzelnes Attribut selten zur eindeutigen Identifizierung genutzt werden kann, ist dies oft in
Kombination mit weiteren Daten möglich. Die finanztechnischen Attribute sind verwandt mit
dokumentenbasierten Attributen und unterscheiden sich hauptsächlich durch die ausstellende
Institution. Aufgrund der weiten Verbreitung von Finanzprodukten eignen sich die zugehörigen
Attribute, wie die Kontonummer oder Kreditkartennummer, gut zur Identifizierung von Personen.
Biometrische Attribute müssen nicht ausgestellt werden, sondern sind Teil einer Person und
identifizieren diese häufig eindeutig. Diese Attribute bestehen im Gegensatz zu den bisher
genannten Typen aus physikalischen Charakteristiken einer Person, wie einem Fingerabdruck oder
der Iris im Auge. Dem letzten Typen gehören transaktionsbasierte Attribute an, welche die
Aktionen von Personen umfassen. Durch bestimmte Aktionen, wie einen Kaufvorgang und die
zugehörige Rechnung, kann eine Person identifiziert werden. Beispielsweise kann ein treuer
Kunde durch mehrere Käufe innerhalb einer bestimmten Zeit erkannt werden.26
Allgemein ist eine digitale Identität die Rechnerrepräsentation einer Identität.27 Camp
präzisiert diese sehr allgemeine Aussage und gibt an, dass eine digitale Identität eine Menge von
dauerhaft gespeicherten Attributen ist, welche mit einer konkreten Entität verknüpft ist.28 Digitale
Identitäten existieren grundsätzlich nicht nur für natürliche Personen, sondern auch für andere
Objekte innerhalb eines Rechners oder eines Netzwerks.29 Für die folgenden Betrachtungen
genügt der Identitätsbegriff bezogen auf Personen, also die Benutzer einer Anwendung oder
Teilnehmer in einem Netzwerk. Die Authentifizierung, also der Identitätsnachweis eines
Benutzers, kann mithilfe von Berechtigungsnachweisen realisiert werden.30
Berechtigungsnachweise sind Attribute eines Benutzers, die einen Beweis der Identität
ermöglichen. Häufig wird dazu eine Kombination aus Benutzername (zur Identifizierung) und
Passwort (zur Autorisierung bzw. Authentifizierung) eingesetzt. Möglich sind aber generell alle
Attribute, die einem Benutzer angehängt sind und entweder nur diesem bekannt sind oder zur
Verfügung stehen.31

3.2 Aktuelle Erscheinungsformen


In der praktischen Umsetzung wird die Authentisierung gegenüber einem Cloud-Service häufig
ausschließlich durch die Abfrage von Benutzername und Passwort realisiert.32 Weniger verbreitet
sind Dienste, die eine Zwei-Faktor-Authentisierung33 ermöglichen; hierbei wird i.d.R. auf
Einmalpasswörter (OTP)34 zurückgegriffen.
3.3 Potenzielle Erscheinungsformen
Bei der regelmäßigen Nutzung eines Cloud-Services steigt die Zahl der möglichen Angriffe mit
der Zahl der Authentisierungsvorgänge, die der Cloud-Nutzer gegenüber dem Cloud-Anbieter
durchführt. Als mögliche Lösung wird teilweise die Verwendung von Single-Sign-On (SSO)35
vorgeschlagen. Die Zahl der tatsächlichen Anmeldungsvorgänge wird dadurch reduziert, dass sich
der Benutzer nicht für jeden Dienst separat anmelden muss. Stattdessen registriert sich ein Nutzer
einmalig bei einem Identitätsprovider (IdP), welcher Anmeldevorgänge bei kompatiblen Services
über standardisierte Schnittstellen realisiert. Zur Anmeldung bei einem Service muss der Nutzer
sich folglich ausschließlich bei seinem IdP authentisieren (siehe Abb. 2.1).36

Abb. 2.1 Bei der Nutzung eines Identitätsproviders (IdP) erfolgt die Authentifizierung des Nutzers bei Anwendungen über den IdP

Eine weitere Möglichkeit zur Identifizierung ist die sogenannte Zwei-Faktor-Authentisierung:


Hier erfolgt die Authentisierung nicht nur durch Wissen, sondern zusätzlich über einen weiteren
Faktor, etwa durch Besitz eines Hardware Tokens.37 Häufig verwendete Verfahren in diesem
Kontext sind die Verwendung von Security-Token in Form von Smartcards38 oder des
elektronischen Identitätsnachweises (eID).39

4 Bedrohungsszenarien
Ein Identitätsmissbrauch setzt zunächst das Erlangen einer fremden Identität, etwa durch einen
Identitätsdiebstahl, voraus.40 Dieser Angriff erfordert in der Regel eine Kompromittierung des
Authentisierungssystems aufseiten desjenigen, der sich bei einem Webdienst authentisieren will.
Ein klassisches Beispiel hierfür ist das Ausspähen von Benutzername und Passwort mittels eines
Keyloggers bei der Verwendung von Online-Handelsplattformen oder Online-Banking. In
derartigen Konstellationen ist nicht relevant, ob die jeweilige Plattform, bei der die
Authentisierung erfolgt, aus einem klassischen Serververbund besteht oder ob der Betreiber sie in
der Cloud betreibt, respektive auf Ressourcen eines Cloud-Anbieters zurückgreift.

4.1 Angriffsmethoden
Bei Angriffen ist zu unterscheiden zwischen externen Angriffen, bei denen ein Dritter auf den
Computer des Nutzers zugreift oder die dargestellten Inhalte manipuliert, und internen Angriffen,
also Angriffen, die unmittelbar am zu kompromittierenden Rechner erfolgen.

4.1.1 Externe Angriffe


Passive Angriffe zielen auf das Abfangen der bei der Authentisierung eingegebenen
Berechtigungsnachweise ab: Mögliche Angriffsmethoden mittels Schadsoftware sind der Einsatz
von Keyloggern, Phishing, Pharming41 und Brute-Force42 Angriffe. Demgegenüber stehen aktive
Angriffe, bei denen der Angreifer in die Kommunikation zwischen Server und Client eingreift und
die übermittelten Daten manipuliert. Hierunter fallen insbesondere der Man-in-the-Middle-Angriff
(MitM), aber auch Cross-Site-Scripting-Angriffe (XSS).43 In beiden Fällen kann sich der
Angreifer gegenüber dem jeweiligen Dienst wie ein Berechtigter identifizieren
(Accountübernahme).
Ein relevanter Unterschied zwischen diesen beiden Angriffen liegt dort, wo der Angriff
ansetzt: Während ein MitM-Angriff dem sorgfältigen Cloud-Nutzer – etwa durch Warnmeldungen
des Browsers – auffallen kann, bleibt ein XSS-Angriff vom Nutzer grundsätzlich44 unbemerkt.
Dagegen bleibt ein MitM-Angriff vom Cloud-Anbieter unbemerkt, ein XSS-Angriff kann jedoch
durch Einhaltung von Sicherheitsstandards vom Cloud-Anbieter verhindert werden. Folglich kann
nur der Cloud-Nutzer Vorkehrungen gegen MitM-Angriffe und nur der Cloud-Anbieter
Vorkehrungen gegen XSS-Angriffe treffen.
Weitere häufige aktive Angriffe sind DoS- und DDos-Attacken. Da diese jedoch nicht das
Ausspähen von Daten ermöglichen, also nicht zum Identitätsmissbrauch verwendet werden
können, bleiben diese unbeleuchtet.45

4.1.2 Interne Angriffe


Neben diesen Angriffen kommen weitere hinzu, etwa durch kriminelle Mitarbeiter des
Serverbetreibers oder durch externe Unternehmen, die zur Wartung der Infrastruktur eingesetzt
werden.
Insbesondere von Administratoren des jeweiligen Cloud-(Sub-)Netzwerks können interne
Angriffe ausgehen. Durch Einschaltung von Unterauftragnehmern46 erhöht sich auch die Zahl
potenzieller interner Angreifer.
Auch Mitarbeiter des eigenen Unternehmens können Authentisierungsmedien unterschlagen
oder Passwörter ausspähen (sog. „Shoulder Surfing“47). Auch denkbar ist beispielsweise das
Erlangen von Zugangsdaten durch Reinigungspersonal, welches vertrauliche Informationen
durchsucht, die intakt entsorgt wurden (sog. „dumpster diving“).

4.1.3 Cloud-spezifische Angriffe


Gegenstand der Untersuchung sind Angriffe auf Identifizierungs- bzw. Authentisierungssysteme
(dazu oben 3.) von Cloud-Diensten. Jedoch erfolgt auch die Authentisierung des Cloud-Nutzers
gegenüber dem Cloud-Anbieter mittels herkömmlicher Authentisierungsmethoden. Die
vorgenannten Angriffe stellen folglich die Grundlage für cloudspezifische Schadensszenarien dar.
Konkrete Bedrohungen ergeben sich durch die Kombination der einzelnen Angriffe für die
verwendeten Sicherheitskomponenten, wie etwa Webservices oder Browser.48 Maßgeblich ist
daher, welche Authentisierungssysteme der Cloud-Anbieter dem Cloud-Nutzer zur Verfügung
stellt.

4.1.4 Angriffe bei Verwendung von Nutzername und Kennwort


Der Cloud-Nutzer hat bei seinem Cloud-Anbieter ein Nutzerkonto. Er authentisiert sich gegenüber
dem Cloud-Anbieter mittels klassischer Authentisierungsmethoden,49 i.d.R. mittels Benutzername
und Passwort. Die vorgenannten „klassischen“ Angriffe sind grundsätzlich also auch in Cloud-
Umgebungen denkbar. Die in diesem Rahmen infrage kommenden Angriffsziele sind der Computer
des Cloud-Nutzers sowie der Datentransfer zwischen diesem und dem Cloud-Anbieter.
4.1.4.1 Klassische Angriffe auf Identifizierungssysteme
Soweit die Identifizierung des Cloud-Nutzers gegenüber dem Cloud-Anbieter durch die
Verwendung von Benutzername und Kennwort verläuft, kommen Angriffe in Form des viren-
/trojanerbasierten Identitätsdiebstahls auf den Cloud-Nutzer in Betracht. Auch die Kommunikation
zwischen Cloud-Nutzer und Cloud-Anbieter ist ebenso kompromittierbar wie bei einer üblichen
Client-Server-Kommunikation, namentlich durch einen Man-in-the-Middle- oder einen XSS-
Angriff.
4.1.4.2 Angriffe aus der Cloud
Daneben ist denkbar, dass der Angreifer selbst Kunde des Cloud-Anbieters wird und dann mittels
seiner eigenen (legitim genutzten) Zugangsdaten und durch Manipulation des eigenen
Datenverkehrs fremde Sessions des Cloud-Nutzers übernimmt.50 Eine weitere Möglichkeit ist der
Ausbruch aus der (selbst angemieteten) virtuellen Maschine, um die Kontrolle über das Wirt-
System und somit die virtuellen Maschinen anderer Cloud-Nutzer zu erlangen. Letzteres hat zwar
den Nachteil, dass der Angreifer nicht weiß, welche virtuellen Maschinen er übernimmt,
andererseits den Vorteil, dass der Angreifer in der Lage ist, mit einem einzelnen Angriff mehrere
Cloud-Nutzer zugleich zu attackieren.51
4.1.4.3 Probleme durch Einschaltung von Unterauftragnehmern
Die Einschaltung von Subunternehmern ist unter Cloud-Anbietern weit verbreitet: Rund zwei von
fünf Anbietern nutzen Unterauftragnehmer; weniger als ein Zehntel besitzt keine eigenen
Ressourcen für Cloud-Dienstleistungen und nutzt ausschließlich Unterauftragnehmer zur eigenen
Service-Erbringung.52 Dies kann die Sicherheit der Cloud hinsichtlich externer Angriffe nachteilig
beeinflussen.

4.1.5 Angriffe bei Verwendung einer Zwei-Faktor-Authentisierung53


4.1.5.1 Einmalpasswörter (OTP)
OTPs bieten keinerlei Schutz gegen Man-in-the-Middle-Angriffe.54 Die weiteren
Angriffsmöglichkeiten sind davon abhängig, welches Medium als Empfänger des OTP dient.
4.1.5.1.1 E-Mail
Das Abfangen einer E-Mail ist nur möglich, wenn der Angreifer die Zugangsdaten zum genutzten
E-Mail-Account kennt. Während der genutzte E-Mail-Provider – jedenfalls sofern der Cloud-
Nutzer eine Webseite betreibt – relativ einfach durch eine DENIC-Abfrage zu ermitteln ist,
gestaltet sich dies bei einem Nutzerkonto nebst zugehörigem Passwort schwieriger; vorausgesetzt,
es handelt sich nicht um einen Mitarbeiter des Cloud-Nutzers.
Das E-Mail-Konto ist für einen externen Angreifer nur dann zu ermitteln, wenn dieses auch zu
anderen Zwecken genutzt wird, etwa als Kontakt-E-Mailadresse. Für die Sicherheit des E-Mail-
Passworts gelten die allgemeinen Grundsätze.55 Die Sicherheit des Versendens von OTPs per E-
Mail steht und fällt somit mit der Art der Handhabe des Cloud-Nutzers.

4.1.5.1.2 SMS
Die Übersendung eines OTPs an ein Mobiltelefon via SMS ist vergleichbar mit dem im Online-
Banking genutzten mTAN-Verfahren.56 Dies bietet zwei Ansatzpunkte für Angriffe.
Zum einen kommt die Erlangung des Besitzes am Mobiltelefon in Betracht, wenn die
Authentisierung komplett über das Mobiltelefon durchgeführt wird, da dann keine Trennung der
Geräte mehr existiert.57 Die Authentisierung reduziert sich folglich auf Besitz. Dies ist in den
erstgenannten Szenarien58 eher selten der Fall, da hier i.d.R. stationäre Arbeitsplätze zur
Interaktion mit dem Cloud-Anbieter dienen. Relevant kann dies nur im letztgenannten Szenario des
E-Mail-Providers oder Filehosters werden.
Zum anderen wurde das mTAN-Verfahren bereits mit einem sogenannten Zeus-in-the-Mobile-
Angriff (ZitMo-Angriff) geknackt.59 Ähnliches ist auch bei der Au-thentisierung gegenüber Cloud-
Anbietern denkbar. Der Besitz des Mobiltelefons ist hierbei obsolet; die Authentisierung reduziert
sich damit auf einen Faktor und ist auf Sicherheitsebene vergleichbar mit der Authentisierung
mittels Benutzername und Passwort. Die steigende Zahl von Malware für Mobiltelefone60 ist ein
weiterer Grund, dieses Verfahren als unsicher einzustufen.
4.1.5.1.3 App
Eine weit verbreitete Applikation zur Authentisierung stellt der Google Authenticator61 dar.
Angriffe hierauf sind bisher nicht bekannt.
4.1.5.1.4 Standalone-Geräte
Eine weitere Möglichkeit sind Standalone-OTP-Generatoren. Diese sind mit einem Display und
ggf. einer Anforderungstaste versehen; eine Verbindung zum Internet oder zu einem anderen Gerät
besteht nicht. Daher kann ein entfernter Angreifer keinen direkten Einfluss auf das Gerät nehmen.62

4.1.5.2 Smartcards
Die Sicherheit von Smartcards hängt von dem eingesetzten Smartcard-Leser ab. So konnte bei
Verwendung von Klasse-1- und Klasse-2-Lesern mit klassischen Angriffen, insb. Keyloggern, die
jeweilige PIN ausgelesen werden.63 Angriffe auf chipkartenbasierte Identifizierungssysteme, bei
denen Klasse-3-Leser zum Einsatz kommen, sind bislang nicht bekannt.
4.1.5.3 Elektronischer Identitätsnachweis (eID)
Bei der Nutzung eines Basislesegeräts ist ein Angriff mittels malwarebasiertem MitM-Angriff
erfolgversprechend.64 Hier ist das Wissen der PIN erforderlich, sodass dieser Angriff entweder in
Kombination mit einer protokollierenden Malware durchgeführt oder auf eine der anderen
Methoden (z. B. Phishing) zurückgegriffen werden muss.
Durch Benutzung eines Standard- oder Komfortlesers, bei dem die PIN-Eingabe nicht über die
PC-Tastatur erfolgt, ist ein Angriff zwar möglich, jedoch erheblich schwieriger.65

4.1.6 Angriffe bei Verwendung von Single-Sign-On (SSO)


Die Authentisierung zwischen Cloud-Nutzer und IdP erfolgt regelmäßig durch Benutzername und
Passwort. Damit sind klassische Bedrohungsszenarien denkbar.66 Zwar reduziert SSO die Zahl
der erforderlichen Identifizierungen, die ein Nutzer vornehmen muss; durch die Verwendung von
Single-Sign-On besteht jedoch die Gefahr, dass ein Angreifer, sobald ihm einmal ein Angriff
gelungen ist, sich gegenüber allen Service Providern authentisieren kann. Er kann somit auf alle
Dienste, einschließlich des Cloud-Anbieters, unter Verwendung einer fremden Identität zugreifen
(sog. „single point of failure“).67

4.1.7 Folgeangriffe
Die im Rahmen eines Angriffs erlangten Daten sind für den Angreifer für Folgeangriffe nutzbar.
Aus Angreifersicht ist dies dort reizvoll, wo eine Verknüpfung mit Kontodaten vorliegt,
beispielsweise im Rahmen des Banking, bei Handelsplattformen oder sonstigen Plattformen mit
der Möglichkeit, Transaktionen vorzunehmen.68 Als klassische Angriffe ohne Relevanz für das
Identitätsmanagement in der Cloud sind diese jedoch nicht Gegenstand der Untersuchung.

5 Schadensszenarien
Die relevanten Schadensszenarien werden anhand der zu untersuchenden Einsatzgebiete
dargestellt. In Abhängigkeit von Einsatzgebiet und Bedrohungsszenario ergeben sich verschiedene
Schäden. Die Frage der Risikotragung, also bei welchem Beteiligten der aus dem jeweiligen
Schadensszenario resultierende Schaden eintritt, bestimmt sich nach den im jeweiligen Kontext
geltenden Normen.

5.1 Szenario 1: Mittelständisches Unternehmen


Die möglichen Schadensszenarien im Rahmen des IT-Outsourcing mittelständischer Unternehmen
ergeben sich aus der Kombination der im jeweiligen Anwendungsfall genutzten
Authentisierungsmethode, der daraus resultierenden möglichen Angriffe sowie der wiederum
daraus resultierenden möglichen Schäden. Diese Darstellung erfolgt anhand praktisch relevanter
Fallgruppen.
Ein Angriff kann in zwei Richtungen Auswirkungen haben: Zum einen gegenüber dem Cloud-
Nutzer, zum anderen gegenüber dem Betroffenen, also demjenigen, dessen personenbezogene
Daten in der Cloud verarbeitet werden. Diese Unterscheidung ist wichtig, da Cloud-Nutzer und
Betroffener häufig zwei verschiedene Personen sind.

5.1.1 Zugriffsverhinderung
Resultat eines Angriffs kann die Nichtverfügbarkeit des angebotenen Cloud-Dienstes bzw. eine
Zugriffsunterbrechung sein. Eine solche Verhinderung des Zugriffs auf die Cloud oder ein – wenn
auch nur vorübergehender – Ausfall der Infrastruktur kann entscheidenden Einfluss auf die
Betriebsabläufe des Cloud-Nutzers haben und erheblichen finanziellen Schaden verursachen.
Zu untersuchen ist, welche ökonomische Relevanz ein (vorübergehender) Betriebsausfall hat.
Dies hängt maßgeblich von der Redundanz der in der Cloud genutzten Systeme, der Art des
Angriffs sowie der Zeit, in der es möglich ist, den status quo ante wiederherzustellen, ab.
In diesen Fällen kommen vertragliche69 und deliktische70 Ansprüche des Cloud-Nutzers gegen
den Cloud-Anbieter in Betracht.

5.1.2 Löschen von Daten


Das (endgültige) Löschen von Daten kann dazu führen, dass der Betrieb seine Arbeit temporär
nicht durchführen kann, einzelnen Aufträgen nicht oder nicht rechtzeitig nachkommen kann oder
sogar dauerhaft stillgelegt ist. Der Schaden im konkreten Fall ist von der Menge der gelöschten
Daten, von der Bedeutung dieser Daten für den Betrieb sowie vom Geschäftsmodell des Betriebs
abhängig. Auch hier kommt eine vertragliche oder deliktische Haftung des Cloud-Anbieters in
Betracht.

5.1.3 Ausspähen von Daten Dritter


Ein anderes, aus einem Angriff resultierendes Problem sind sogenannte Datenlecks.71 Beim
klassischen Identitätsmissbrauch ist das Opfer eines vorangegangenen Identitätsdiebstahls i.d.R.
zugleich derjenige, der unmittelbar vom Identitätsmissbrauch betroffen ist.72
Die Auswirkungen einer unbefugten Authentisierung gegenüber dem Cloud-Anbieter können
jedoch weitreichender sein: Ein Erschleichen des Zugangstoken hat, sofern – wie beim Cloud
Computing üblich – massenhaft Personendaten verarbeitet werden, zur Folge, dass der Angreifer
personenbezogene Daten Dritter in erheblicher Zahl erhält.

5.1.4 Manipulation von Daten Dritter


Die Manipulation von Daten kann sowohl zu Schäden aufseiten des Cloud-Nutzers führen als auch
aufseiten des durch die Datenverarbeitung Betroffenen: Einerseits verarbeitet der Cloud-Nutzer in
diesen Fällen falsche Daten, was dessen Betriebsabläufe stören kann.73 Auf der anderen Seite
kann es aber auch sein, dass dem Betroffenen ein Schaden entsteht.74

5.2 Szenario 2: Kreditwirtschaft


Banken nutzen vorrangig sogenannte „Private Clouds“. Dabei handelt es sich um Cloud-Lösungen,
die innerhalb des eigenen Unternehmens untergebracht werden oder die auf einen bestimmten
Kunden ausgerichtet sind und deren Bereitstellung über ein unternehmensinternes Intranet erfolgt.
Die genutzten Systeme unterscheiden sich jedoch nicht grundlegend von normalen Clouds; die
möglichen Bedrohungsszenarien sind damit grundsätzlich vergleichbar. Da die Ressourcen jedoch
einem einzelnen Cloud-Nutzer überlassen werden, kommen Angriffe aus der Cloud75 nicht in
Betracht. Besondere Relevanz hingegen haben daher interne Angriffe76 auf die genutzten Systeme.
Die Schadensszenarien, in denen sich die jeweiligen Angriffe manifestieren, sind jedoch mit
denen des normalen IT-Outsourcings deckungsgleich.77

5.3 Szenario 3: Sozialleistungsträger


Maßgeblicher Unterschied zwischen Sozialleistungsträgern und sonstigen datenverarbeitenden
Stellen ist der Umgang mit Sozialdaten. Sozialdaten sind nach der Legaldefinition des § 67 Abs. 1
SGB X personenbezogene Daten, die ein Leistungsträger im Hinblick auf Erfüllung seiner
Aufgaben nach dem 10. Sozialgesetzbuch erhebt, verarbeitet oder nutzt. Dies betrifft u. a.
Leistungen der Ausbildungsförderung, Arbeitsförderung, Grundsicherung, gesetzlichen Kranken-,
Pflege-, Unfall- und Rentenversicherung, der Sozial-, Kinder- und Jugendhilfe sowie Kinder-,
Eltern- und Wohngeld; mithin besonders sensible Daten. Abgesehen vom erhöhten Schutzniveau
bestehen auch hier mit den vorgenannten Varianten deckungsgleiche Schadensszenarien.

5.4 Szenario 4: Berufsgeheimnisträger


Im Bereich der Berufsgeheimnisträger bestehen Besonderheiten. Diese sind durch berufsrechtliche
und strafrechtliche Vorschriften zu besonderer Sorgfalt verpflichtet. Verstößt ein
Berufsgeheimnisträger gegen die im jeweiligen Kontext geltende Vorschrift, kann dies
berufsrechtliche Konsequenzen haben (beispielsweise der Entzug der Zulassung eines Arztes oder
Rechtsanwalts). In einem derartigen Fall würde dies mit einem jedenfalls temporären
Betriebsausfall einhergehen. Hier stellt sich auch die Frage, ob der Cloud-Anbieter – sofern der
den Schadensfall auslösende Grund aus seiner Risikosphäre stammt – gegenüber dem Cloud-
Nutzer haftet.

5.5 Szenario 5: Verbraucher


Cloud-Dienste, die sich an Verbraucher richten, zeichnen sich dadurch aus, dass der Cloud-
Nutzer, sofern er seine eigenen personenbezogen Daten in der Cloud verarbeitet, zugleich der
Betroffene ist. Datenschutzrechtliche Probleme bestehen in diesem Schadensszenario zwischen
Betroffenem und Cloud-Anbieter folglich grundsätzlich nicht. Anderes gilt bei der Verarbeitung
fremder personenbezogener Daten. Hier ist außerdem zu differenzieren zwischen der nach § 1
Abs. 2 Nr. 3 BDSG nicht vom Anwendungsbereich des Datenschutzrechts erfassten Verarbeitung
im Rahmen persönlicher oder familiärer Tätigkeiten und der sonstigen Verarbeitung fremder
Daten.
Auch bei der privaten Datenverarbeitung in der Cloud besteht die Möglichkeit, dass sich
jemand unbefugt gegenüber dem Cloud-Anbieter authentisiert und dann durch Änderung des
Passworts den Zugriff des Berechtigten hemmt, die in der Cloud abgelegten Daten löscht oder
verändert.
Der Täter wird dem Identitätsinhaber regelmäßig nicht bekannt sein, sodass Ansprüche gegen
diesen nicht in Betracht kommen. Eine Haftung des Cloud-Anbieters schließt dieser gegenüber
dem Cloud-Nutzer regelmäßig durch AGB aus.78 Hier stellt sich die Frage, inwieweit eine solche
Vereinbarung Wirksamkeit entfalten kann, wenn der Cloud-Nutzer nicht bloß eigene, sondern auch
fremde personenbezogene Daten verarbeitet. In diesem Fall kann ein Anspruch des Betroffenen
gegen den Cloud-Anbieter bestehen.

Literatur
Abadi, Martin/Burrows, Michael/Lampson, Butler: A Calculus for Access Control in Distributed Systems, 1991.

Baier, Tobias: Persönliches digitales Identitätsmanagement. Untersuchung und Entwicklung von Konzepten und
Systemarchitekturen für die kontrollierte Selbstdarstellung in digitalen Netzen, Dissertation an der Universität Hamburg 2006.
Bertino, Elisa/Takahashi, Kenji: Identity Management: Concepts, Technologies, and Systems, Norwood 2010.

Bothe, Steffen: Datenschutz und Datensicherheit im Cloud Computing, Bremen 2012.

Borges, Georg/Schwenk, Jörg/Stuckenberg, Carl-Friedrich/Wegener, Christoph: Identitätsdiebstahl und Identitätsmissbrauch im


Internet, Heidelberg 2011.

Borges, Georg/Schwenk, Jörg: Daten- und Identitätsschutz in Cloud Computing, E-Government und E-Commerce, Heidelberg
2013.

Camp, L. Jean: Digital identity, in: Technology and Society Magazine, IEEE 23 (3), S. 34–41. DOI: https://​doi.​org/​10.​1109/​MTAS.​
2004.​1337889 (zuletzt abgerufen am 27.11.2017), 2004.
[Crossref]

Derleder, Peter/Knops, Kai-Oliver/Bamberger, Heinz Georg: Deutsches und europäisches Bank- und Kapitalmarktrecht, 3.
Aufl., Berlin Heidelberg 2017.

Duisberg et al. : Rechtliche Anforderungen an Cloud Computing, IT-Gipfel 2011.

Heidrich, Joerg/Christoph, Wegener: Sichere Datenwolken – Cloud Computing und Datenschutz, MMR, 2010, 803–807.

Hommel, Wolfgang/Reiser, Helmut: Federated Identity Management: Die Notwendigkeit zentraler Koordinationsdienste, in: Lecture
Notes in Informatics, Heft 61, 2005, S. 65–72.

Hornung, Gerrit: Die digitale Identität. Rechtsprobleme von Chipkartenausweisen: Digitaler Personalausweis, elektronische
Gesundheitskarte, JobCard-Verfahren, Baden-Baden 2005.
[Crossref]

Marston, Sean/Li, Zhi/Bandyopadhyay, Subhajyoti/Zhang, Juheng/Ghalsasi, Anand: Cloud Computing – the business
perspective, in: Decision Support Systems, Heft 51, 2011, S. 176–189.
[Crossref]

Mell, Peter/Grance, Timothy: The NIST Definition of Cloud Computing, 2011.

Morgner, Frank/Oepen, Dominik: „Die gesamte Technik ist sicher“. Besitz und Wissen: Relay-Angriffe auf den neuen
Personalausweis, 27th Chaos Communication Congress, 2010.

Nägele, Thomas/Jacobs, Sven: Rechtsfragen des Cloud Computing, ZUM 2010, 281–292.

Niemann, Fabian/Hennrich, Thorsten: Kontrolle in den Wolken? Auftragsdatenverarbeitung in Zeiten des Cloud Computings, CR
2010, 686–692.

Niemann, Fabian/Paul, Jörg-Alexander: Bewölkt oder wolkenlos – Rechtliche Herausforderungen des Cloud Computings, K&R
2009, S. 444–452.

Nordmeier, Carl Friedrich: Cloud Computing und Internationales Privatrecht, MMR 2010, 151–156.

Pfitzmann, Andreas/Hansen, Marit: A terminology for talking about privacy by data minimization: Anonymity, Unlinkability,
Undetectability, Unobservability, Pseudonymity, and Identity Management; Working Paper v0.34; S. 30 f., August 10, 2010; https://​
dud.​inf.​tu-dresden.​de/​literatur/​Anon_​Terminology_​v0.​34.​pdf (zuletzt abgerufen am 27.11.2017).

Rabai, Latifa Ben Arfa/Jouini, Mouna/Aissa, Anis Ben/Mili, Ali: A Cybersecurity Model in Cloud Computing Environments, in:
Journal of King Saud University – Computer and Information Sciences, Heft 25, 2013, S. 63–75.
[Crossref]

Rammos, Thanos/Vonhoff, Hans: Cloud Computing und Sozialdatenschutz, CR 2013, 265–272.

Schimansky, Herbert/Bunte, Hermann-Josef/Lwowski, Hans Jürgen: Bankrechts-Handbuch, 4. Aufl., München 2011.


Schulz, Carsten/Rosenkranz, Timo: Cloud Computing – Bedarfsorientierte Nutzung von IT-Ressourcen, ITRB 2009, 232–236.

Schuster, Fabian/Reichl, Wolfgang: Cloud Computing & SaaS: Was sind die wirklich neuen Fragen? Die eigentlichen
Unterschiede zu Outsourcing, ASP & Co liegen im Datenschutz und in der TK-Anbindung, CR 2010, 38–43.

Simitis, Spiros: Bundesdatenschutzgesetz, 8. Aufl., Baden-Baden 2014.

Tietz, Christian/Pelchen, Chris/Meinel, Christoph/Schnjakin, Maxim: Management digitaler Identitäten, Potsdam 2017.

Weichert, Thilo: Cloud Computing und Datenschutz, DuD 2010, 679–687.


[Crossref]

Winkelmann, Michael: Cloud Computing: Sicherheit und Datenschutz, 2010.

Youseff, Lamia/Butrico, Maria A./Da Silva, Dilma: Toward a Unified Ontology of Cloud Computing, in: Grid Computing
Environments Workshop p. 1–10, 2008.

Fußnoten
1 Vgl. zum Begriff unten Kap.​ 3, 2.​2.

2 http://​www.​heise.​de/​ix/​meldung/​Studie-Mehrheit-der-Banken-will-in-Cloud-Computing-investieren-1773616.​html (zuletzt
abgerufen am 27.11.2017).

3 Z. B. Rapidshare, iCloud oder Dropbox.

4 Z. B. Telekom Mail & Cloud, iCloud oder GMail.

5 Vgl. Mell/Grance (2011), S. 2.

6 Vgl. Marston et al. (2011), S. 178; Mell/Grance (2011), S. 2 f.

7 Vgl. Youseff et al. (2008), S. 5 ff.

8 Vgl. Mell/Grance (2011), S. 3.

9 BITKOM, Leitfaden Cloud Computing, S. 55 ff., abrufbar unter https://​www.​bitkom.​org/​noindex/​P ublikationen/​2009/​Leitfaden/​


Leitfaden-Cloud-Computing/​090921-BITKOM-Leitfaden-CloudComputing-Web.​pdf (zuletzt abgerufen am 27.11.2017).
10 Vgl. Marston et al. (2011), S. 178.

11 Vgl. Rabai et al. (2013), S. 63 f.

12 Z. B. https://​www.​fiduciagad.​de/​leistungen/​rechenzentren.​html; dazu auch http://​www.​wiwo.​de/​technologie/​vernetzt/​


auslagerung-von-daten-banken-wollen-in-die-cloud/​11602608.​html (zuletzt abgerufen am 27.11.2017).

13 Z. B. http://​www.​versacommerce.​de (zuletzt abgerufen am 27.11.2017).

14 Z. B. https://​www.​cloud-steuerberater.​de/​online-steuerberatung/​ (zuletzt abgerufen am 27.11.2017).

15 Z. B. https://​www-old.​ibh.​de/​index_​gmbh_​4_​1058.​html (zuletzt abgerufen am 27.11.2017).

16 Z. B. Amazon Web Services oder Microsoft Azure.

17 Insb. Online-Speicher, z. B. Dropbox oder Rapidshare.

18 Z. B. Microsoft Office 365 oder Google Drive.

19 https://​www.​enisa.​europa.​eu/​activities/​Resilience-and-CIIP/​cloud-computing/​critical-cloud-computing/​at_​download/​fullReport
(zuletzt abgerufen am 27.11.2017).

20 Autorisierung wird im Englischen auch als Access Control bezeichnet.

21 Vgl. Abadi et al. (1991), S. 1.

22 Vgl. zu den verschiedenen Begriffsbestimmungen Borges et al., Identitätsdiebstahl, S. 1 ff.

23 Vgl. Pfitzmann/Hansen (2010), S. 30 f.


24 Vgl. BITKOM (2005), S. 6; Camp (2004), S. 35.

25 Vgl. Bertino/Takahashi (2010), S. 25 f.; Tietz et al. (2017), S. 13 f.

26 Vgl. Bertino/Takahashi (2010), S. 25 f.

27 Vgl. BITKOM (2005), S. 7.

28 Vgl. Camp (2004), S. 36.

29 Vgl. BITKOM (2005), S. 7.

30 Vgl. Baier (2006), S. 38 ff.

31 Vgl. Baier (2006), S. 81.

32 So z. B. die Standardkonfiguration bei Verwendung der Amazon Web Services. Eine Zwei-Faktor-Authentisierung wird optional
angeboten.

33 Zur Zwei-Faktor-Authentisierung siehe Kap.​ 3, 3.​1 und 3.​5.

34 Microsoft und Google versenden zur Nutzung ihrer Dienste nach Eingabe des Passworts einen Sicherheitscode per Mail, SMS
oder App.

35 http://​de.​wikipedia.​org/​wiki/​Single_​Sign-on (zuletzt abgerufen am 27.11.2017). Die beiden bekanntesten Protokolle sind OpenID
und OAuth.

36 Vgl. Hommel/Reiser (2005), S. 66.


37 Siehe Kap.​ 3, 3.​1 und 3.​5.

38 Z. B. https://​www.​kv-rlp.​de/​ (zuletzt abgerufen am 27.11.2017).

39 Siehe auch http://​www.​die-eid-funktion.​de/​ (zuletzt abgerufen am 27.11.2017).

40 Vgl. zu den unterschiedlichen Begriffsbestimmungen des Identitätsmissbrauchs und Identitätsdiebstahls Borges et al.,
Identitätsdiebstahl, S. 9 ff.

41 Vertiefend zu Keylogging, Pharming und Phishing: Borges et al., Identitätsdiebstahl, S. 25; vgl. auch Kap.​ 5, 2.​3.​1.​1, 2.​3.​1.​2 und
2.​3.​1.​3.

42 Siehe zur Methode Kap.​ 5, 2.​3.​1.​4.

43 Eine Darstellung eines derartigen Angriffs auf die Amazon Web Services findet sich bei Borges/Schwenk, Identitätsschutz, S.
16 ff.

44 Anderes gilt nur bei Installation bestimmter Browser-Plugins, bspw. NoScript.

45 Zur Relevanz dieser Angriffe im Bereich des Cloud Computing: Winkelmann (2010), S. 13 f.

46 Vgl. 4.1.4.3.

47 Siehe Kap.​ 5, 2.​3.​2.​1.

48 Borges et al., Identitätsdiebstahl, S. 140.

49 Zu Authentisierungsmethoden siehe Hornung, S. 29.

50 Bothe, S. 45.
51 Bothe, S. 46.

52 Broschüre „Cloud Computing – Navigation in der Wolke“, abrufbar unter http://​www.​pwc.​de/​de_​DE/​de/​prozessoptimieru​ng/​


assets/​CloudComputing-studie.​pdf (zuletzt abgerufen am 27.11.2017).

53 Zur Authentisierung mittels zweier oder mehrerer Faktoren siehe Kap.​ 3, 3.​1 und 3.​5.

54 Borges et al., Identitätsdiebstahl, S. 31.

55 http://​de.​wikipedia.​org/​wiki/​P asswort#Sicherheitsfakto​ren (zuletzt abgerufen am 27.11.2017).

56 Vgl. zum mTAN-Verfahren Borges, in: Derleder /Knops /Bamberger, § 11 Rn. 41; Maihold, in: Schimansky/Bunte/Lwowsky,
§ 55 Rn. 14.

57 Borges et al., Identitätsdiebstahl, S. 37.

58 Vgl. 2.​1.

59 http://​www.​heise.​de/​security/​meldung/​Online-Banking-Trojaner-attackiert-Smartphones-mit-Windows-Mobile-1195455.​html
(zuletzt abgerufen am 27.11.2017).

60 Borges et al., Identitätsdiebstahl, S. 118 f.

61 http://​de.​wikipedia.​org/​wiki/​Google_​Authenticator (zuletzt abgerufen am 27.11.2017).

62 Borges et al., Identitätsdiebstahl, S. 31.

63 Borges et al., Identitätsdiebstahl, S. 83.


64 http://​www.​heise.​de/​security/​meldung/​CCC-zeigt-Sicherheitsprobl​eme-beim-elektronischen-Personalausweis-auf-Update-
1083649.​html (zuletzt abgerufen am 27.11.2017).

65 Zum Angriff bei Benutzung eines Lesegeräts mit separater Tastatur siehe Morgner/Oepen (2010), S. 2 ff.

66 Siehe 4.1.4.1.

67 Winkelmann (2010), S. 25.

68 So geschehen beim Angriff auf das Sony Playstation Network im April 2011, http://​www.​heise.​de/​newsticker/​meldung/​Angriff-
auf-Playstation-Network-Persoenliche-Daten-von-Millionen-Kunden-gestohlen-1233136.​html (zuletzt abgerufen am 27.11.2017).
Dabei machten sich die Angreifer selbst Cloud-Rechenkapazitäten zunutze, http://​www.​heise.​de/​tr/​artikel/​Angriff-aus-der-Wolke-
1363872.​html (zuletzt abgerufen am 27.11.2017).

69 Vgl. Kap.​ 4, 2.​1.​3, 2.​1.​4.

70 Vgl. Kap.​ 4, 2.​2.​2.

71 Vgl. bspw. den Sony Playstation Network-Angriff, Fn. 68.

72 Beispielhaft sei die Erschleichung von Nutzername/Kennwort bei einer Handelsplattform genannt und die anschließende,
unbefugte Nutzung zum Vertragsschluss.

73 Vgl. 5.​1.​1 und 5.​1.​2.

74 Vgl. 5.​1.​3.

75 Siehe dazu 4.​1.​4.​2.

76 Siehe dazu 4.​1.​2.


77 Vgl. 5.​1.

78 Siehe dazu bspw. https://​www.​dropbox.​com/​terms2017 (zuletzt abgerufen am 27.11.2017).


© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018
Georg Borges und Brigitte Werners (Hrsg.), Identitätsmanagement im Cloud Computing, https://doi.org/10.1007/978-3-662-55584-
2_3

3. Schutzmaßnahmen zur sicheren Identifizierung


und Authentifizierung für Cloud-basierte Systeme
Andreas Schilling1
(1) Ruhr-Universität Bochum, Fakultät für Wirtschaftswissenschaft, 44780 Bochum, Deutschland

Andreas Schilling
Email: andreas.schilling@rub.de

1 Einleitung
2 Begriffe und Definitionen
2.1 Identität
2.2 Identitätsmanagement
2.3 Identifizierung
2.4 Authentisierung
2.5 Authentifizierung
2.6 Autorisierung
3 Rahmenbedingungen zur sicheren Identifizierung
3.1 Grundprinzipien der Authentifizierung
3.2 Authentifizierung durch das Wissen einer Person
3.2.1 Textuelle Passwörter
3.2.2 Grafische Passwörter
3.3 Authentifizierung durch den Besitz eines Gegenstandes
3.3.1 Identifikations- oder Authentifikations-Token
3.3.2 Chipkarten
3.4 Authentifizierung durch eine Eigenschaft einer Person
3.4.1 Fingerabdruck
3.4.2 Iris und Stimme
3.5 Mehr-Faktor-Authentifizierung
3.5.1 Kombination aus Wissen und Besitz
3.5.2 Kombination aus Besitz und einer Eigenschaft
4 Konkretisierung möglicher Schutzmaßnahmen
4.1 Maßnahmen zur Authentifizierung
4.1.1 Passwort
4.1.2 Personal Identification Number (PIN)
4.1.3 Fingerabdruck
4.1.4 Handy TAN
4.1.5 E-Mail TAN
4.1.6 Hardware OTP Token
4.1.7 Smartcard
4.1.8 Software OTP Token
4.1.9 TAN-Liste
4.1.10 eID (nPA)
4.2 Möglichkeiten der Ein-Faktor-Authentifizierung
4.3 Möglichkeiten der Zwei-Faktor-Authentifizierung
4.4 Ergänzende Maßnahmen
Literatur

1 Einleitung
Durch die zunehmende Digitalisierung der Gesellschaft nimmt die Bedeutung von digitalen
Identitäten natürlicher Personen fortwährend zu, und die Sicherheit von Informationssystemen ist
maßgeblich durch die Identitäten von Personen geprägt. Bei allen Zugriffen auf Ressourcen muss
die Identität immer geprüft und der Zugriff authentifiziert werden. Entsprechende Maßnahmen und
Verfahren zur Feststellung der Identität sind daher von zentraler Bedeutung für den sicheren
Betrieb von Informationssystemen. Im Folgenden sind vorwiegend digitale Abbilder realer
Identitäten relevant. Die vorgestellten Authentifizierungsmaßnahmen und -verfahren basieren
daher auf Identitätsbezeichnern und Attributen natürlicher Personen bzw. sind eng mit diesen
verknüpft.1 Entsprechende Maßnahmen zur Identifizierung und Authentifizierung von Personen
werden in Kap.​ 5 betrachtet.
Um den Zugriff zu schützen, können verschiedene Authentifizierungsmaßnahmen eingesetzt
werden. Ein Blick auf praktisch angewandte Methoden zeigt, dass eine Vielzahl unterschiedlicher
Verfahren Anwendung findet. Teilweise werden besonders kritische Systeme stärker geschützt,
wohingegen in anderen Fällen nur unzureichende Maßnahmen getroffen werden. Insbesondere der
Schutz personenbezogener Daten wird häufig nicht angemessen gewichtet.
Durch die Veränderungen bei der Nutzung von Ressourcen im Cloud Computing ergeben sich
zusätzlich einige entscheidende Änderungen für die Identifizierung und Authentifizierung von
Nutzern. Der zentrale Punkt ist der Übergang zu ausgelagerten Ressourcen und Anwendungen,
welche per Fernzugriff über das Internet genutzt werden (Outsourcing). Da Anwendungen über das
Internet verfügbar sind, ist das Gefährdungspotenzial deutlich höher als bei ausschließlich intern
verfügbaren Ressourcen. Hinzu kommt eine wachsende Anzahl von spezialisierten Anwendungen
und Komponenten unterschiedlicher Anbieter. Die Anzahl der verwendeten Anwendungen steigt
also, und der sichere Zugriff auf jede Anwendung muss sichergestellt werden.
2 Begriffe und Definitionen
2.1 Identität
Die Sicherheit von Informationssystemen ist maßgeblich durch Identitäten geprägt. Eine Identität
kann sowohl eine reale Entität (z. B. ein Host in einem Netzwerk oder eine Person) als auch ein
Programm (z. B. ein Daemon bzw. Dienst) sein. Der Begriff der Identität wird unterschiedlich
bestimmt.2 In diesem Werk wird unter einer Identität grundsätzlich die Summe der Informationen
über eine Entität, welche erforderlich sind, um diese eindeutig zu identifizieren, verstanden.3

2.2 Identitätsmanagement
Der Begriff des Identitätsmanagements bezeichnet allgemein den zielgerichteten Umgang mit
Identitäten und deren Authentifizierung. Das primäre Ziel ist die Authentifizierung von Attributen
eines Nutzers, um so die sichere Interaktion mit Informationssystemen zu ermöglichen. Im Rahmen
moderner Kommunikation ist es die Aufgabe des Identitätsmanagements, sicherzustellen, dass
Nutzer jederzeit und von überall auf Informationen zugreifen können. Gleichzeitig bedeutet dies,
dass nur Nutzer Zugriff auf Informationen haben, für die eine Berechtigung zum Zugriff vorliegt.4

2.3 Identifizierung
Bevor die Identität eines Benutzers überprüft werden kann, muss dieser seine Identität mitteilen.
Der Vorgang, bei dem die Identität mitgeteilt wird, heißt Identifizierung. Um die Identität zu
beweisen muss der Benutzer sich anschließend (oder gleichzeitig) authentisieren. Der
Kommunikationspartner kann die übermittelten Informationen anschließend dazu verwenden, den
Benutzer zu authentifizieren.5
Die Identifizierung (also die Übermittlung der Identität) wird häufig synonym mit dem aus der
Psychologie stammenden Begriff der Identifikation (dem Einfühlen in eine andere Person)
verwendet. Eine Unterscheidung der beiden Begriffe wird meist nicht getroffen und die
Verwendung beider Begriffe hat sich als gebräuchlich durchgesetzt.

2.4 Authentisierung
Die Authentisierung beschreibt den Vorgang, bei dem eine Entität einem Kommunikationspartner
ihre Identität nachweist. Es findet also eine Identifizierung statt, bei der Berechtigungsnachweise
übermittelt werden (siehe Abb. 3.1). Der anschließende Vorgang des Überprüfens dieser
Informationen heißt Authentifizierung. Hierbei wird verifiziert, dass die vorgegebene Identität
korrekt ist.6
Abb. 3.1 Die Authentisierung besteht zunächst nur in der Übermittlung der Berechtigungsnachweise einer Entität

Der Begriff Authentisierung ist nah verwandt mit dem der Authentifizierung. Häufig werden
beide Begriffe auch synonym verwendet, da im Englischen keine Unterscheidung getroffen wird
und beide Begriffe mit „authentication“ übersetzt werden.

2.5 Authentifizierung
Der Begriff der Authentifizierung (engl. authentication) bezieht sich auf die Sicherstellung bzw.
den Nachweis der Authentizität von Informationen. Im Rahmen des Identitätsmanagements wird
die Echtheit der Identität bestätigt. Der Vorgang der Authentifizierung stellt sicher, dass die
angegebene Identität einer Entität (z. B. einer Person) korrekt ist.7 In Abb. 3.2 ist dieser Vorgang
visualisiert: Nach der Übermittlung der Berechtigungsnachweise folgt die Prüfung der Identität
beim Kommunikationspartner. Kann die Identität bestätigt werden, wird die anfragende Entität
autorisiert.

Abb. 3.2 Bei der Authentifizierung prüft der Kommunikationspartner die Identität der anfragenden Entität, und bei erfolgreicher
Prüfung wird die Identität bestätigt

Der Begriff Authentifikation wird häufig synonym verwendet und hat seinen Ursprung in der
fehlerhaften Übersetzung des englischen Begriffs „authentication“.

2.6 Autorisierung
Bei der Autorisierung werden einer anfragenden Entität die zugewiesenen Rechte eingeräumt. Die
Autorisierung erfolgt daher nach erfolgreicher Authentifizierung.

3 Rahmenbedingungen zur sicheren Identifizierung


Wesentliche Bestandteile des Identitätsmanagements sind die Identifizierung, Au-thentisierung und
Authentifizierung von Personen in Informationssystemen. Dies bedeutet, dass eine Person zunächst
ihre Identität angibt (Identifizierung) und um Berechtigungsnachweise ergänzt (Authentisierung).
Anschließend versucht ein Kommunikationspartner diese anhand der Berechtigungsnachweise zu
bestätigen (Authentifizierung). Nur wenn es möglich ist, die Identität einer Person eindeutig
festzustellen und zu verifizieren, kann der Zugriff auf Ressourcen freigegeben und reguliert werden
(Autorisierung). Zu diesem Zweck ist jeder Person mindestens eine digitale Identität zugeordnet,
welche mit konkreten Zugriffsberechtigungen verknüpft werden kann. Als Vorstufe des
Zugriffsmanagements (engl. access control) ist die zuverlässige Identifizierung und
Authentifizierung einer Person zwingend erforderlich.8
Zur Identifizierung einer Person, also der eindeutigen Zuordnung einer digitalen Identität,
können verschiedene Berechtigungsnachweise verwendet werden (siehe Abb. 3.3).
Berechtigungsnachweise sind Attribute der Person, die einen Nachweis der Identität
ermöglichen.9

Abb. 3.3 Eine Entität (z. B. eine Person) verfügt über eine (digitale) Identität, welche über Berechtigungsnachweise nachgewiesen
werden kann

3.1 Grundprinzipien der Authentifizierung


Die Identifizierung von Nutzern bzw. die Authentifizierung von Nutzern kann allgemein unter
Verwendung von drei verschiedenen Faktoren erfolgen. Zur Erhöhung der Sicherheit können
unterschiedliche Attribute eines Faktors mehrfach abgefragt oder Faktoren beliebig kombiniert
werden. Ist eine erhöhte Sicherheit gefordert, wird häufig eine Authentifizierung unter
Verwendung von zwei Faktoren verwendet (Zwei-Faktor-Authentifizierung).10
Der erste Faktor zur Identifizierung einer Person basiert auf dem Wissen der Person
(„Something you know“). Die verschiedenen wissensbasierten Attribute können unterschiedlich
stark ausgeprägt sein, müssen aber zwingend mindestens ein Attribut beinhalten, welches nur dem
Nutzer bekannt ist. Ein bekanntes Beispiel für die Verwendung dieses Faktors ist eine persönliche
Identifikationsnummer (PIN). Sehr verbreitet ist auch die Kombination aus einem Benutzernamen
und einem Passwort, wobei lediglich das Passwort zwingend geheim sein muss. Die Sicherheit
dieser Authentifizierungsmethode hängt maßgeblich von der Geheimhaltung und der Komplexität
des geheimen Attributs ab.11
Die Sicherheit dieser Methode resultiert aus dem Wissen der zu authentifizierenden Person.
Wenn eine PIN oder ein Passwort nur genau einer Person bekannt ist, kann diese eindeutig
identifiziert werden. Problematisch bei wissensbasierten Attributen ist die Geheimhaltung. Sollte
ein Attribut einem Angreifer bekannt werden, kann dieser die Identität der Person annehmen. Da
ein Passwort jedes Mal zur Authentisierung eingegeben wird, besteht die Möglichkeit, dass dieses
ausgespäht wird („Shoulder Surfing“12). Zusätzlich kann ein Angreifer bei einer unverschlüsselten
Verbindung oder der Speicherung im Klartext das geheime Attribut erhalten. Des Weiteren wird
häufig die Komplexität des Geheimnisses zu gering gewählt, wodurch es möglicherweise in einem
Brute-Force-Angriff13 erraten werden kann. Da das Geheimnis ausschließlich im Gedächtnis der
Person gespeichert ist, neigen Personen dazu, sehr einfache Kombinationen zu wählen. Wird ein
ausreichend starkes Geheimnis gewählt, nutzen Personen dies häufig für mehrere verschiedene
Services. Ist dies der Fall, kann durch einen erfolgreichen Angriff gegebenenfalls direkt der
Zugriff auf mehrere Services erlangt werden.14
Der zweite Faktor beinhaltet alle Attribute, die unmittelbarer Teil der Person sind, also
beispielsweise biologische Eigenschaften der Person betreffen („Something you are“). Dies sind
vornehmlich biometrische Attribute, wie ein Fingerabdruck oder die Iris des Auges. Möglich sind
aber auch temporäre Attribute, wie der aktuelle Aufenthaltsort.15 Im Falle biometrischer Attribute
ist prinzipiell eine eindeutige Identifizierung einer Person möglich. Es existieren allerdings
praxistaugliche Angriffsmethoden, welche z. B. einen Fingerabdruck replizieren können.16
Der dritte Faktor basiert auf Gegenständen, die sich im Besitz einer Person befinden
(„Something you have“). Bekannte Beispiele sind ein Autoschlüssel oder ein Security-Token.17
Die Authentifizierung basiert also alleinig auf dem Besitz des Gegenstandes, weshalb die
eindeutige Identifizierung einer Person nur bedingt möglich ist. Wenn der Gegenstand in den
Besitz eines Angreifers kommt, nimmt der Angreifer de facto die Identität des ursprünglichen
Besitzers an. Für den Zugriff zu Informationssystemen reicht dieser Faktor als alleiniges
Authentifizierungsmerkmal daher meist nicht aus.

3.2 Authentifizierung durch das Wissen einer Person


Bei der Authentifizierung durch Wissen wird ein Berechtigungsnachweis von der Person
gefordert, der nur dieser Person bekannt ist. Um die Authentifizierung zu sichern wird der
Berechtigungsnachweis im System gespeichert und bei der Authentifizierung abgerufen. Eine weit
verbreitete Methode ist die Speicherung einer eindeutigen Benutzerkennung (z. B. Benutzername)
und eines Passworts. Durch die Benutzerkennung kann die Person identifiziert werden. Wird
zusätzlich zur Benutzerkennung das passende Passwort angegeben, ist die Authentifizierung der
Person erfolgreich.18

3.2.1 Textuelle Passwörter


Die Verwendung textueller Passwörter ist weit verbreitet und wird für die Authentifizierung in
einer Vielzahl von Systemen verwendet. Der Grund für die weite Verbreitung ist die Einfachheit
der Methode. Allgemein ist die Implementierung von wissensbasierten
Authentifizierungsmethoden mit einem geringeren Aufwand verbunden, als Methoden, welche auf
andere Faktoren zurückgreifen. Textuelle Passwörter haben zudem den Vorteil, dass sie über ein
Standard-Formulareingabefeld erfasst werden können und kein authentifizierungsspezifisches
Interface benötigen. Die Speicherung und Verifizierung eines textuellen Passwortes ist einfach und
benötigt vergleichsweise geringe Ressourcen.
Zur Speicherung eines textuellen Passwortes x wird üblicherweise ein Hash-Wert h(x) mit
einer Hash-Funktion h berechnet. Der Hash-Wert wird gespeichert und zum Vergleich bei einem
Authentifizierungsvorgang verwendet. Da eine Hash-Funktion nicht umkehrbar ist, kann das
gespeicherte Passwort nachträglich nicht mehr im Klartext ausgelesen werden.19
Die Sicherheit des gewählten Passwortes hängt maßgeblich von dem verwendeten
Zeichenraum und der Länge ab. Ein Passwort, welches nur aus Ziffern besteht, ist deutlich
weniger sicher als ein Passwort, das zusätzlich Klein- und Großbuchstaben enthält. Tab. 3.1 gibt
die Größe des Schlüsselraums in Abhängigkeit von der verwendeten Komplexität und Länge des
Passwortes an. Bei einem zu kleinen Schlüsselraum kann ein Passwort durch einen Brute-Force-
Angriff (also das Ausprobieren aller möglichen Passwörter)20 ermittelt werden.
Tab. 3.1 Passwortsicherheit als Anzahl möglicher Passwörter in Abhängigkeit von Komplexität und Länge

Zeichenlänge
Verwendete Zeichen 4 7 10 13
0–9 (10)

a-z (26)

a-z, 0–9 (36)

a-z, A-Z (52)

a-z, A-Z, 0–9 (62)

a-z, A-Z, 0–9, Sonderzeichen (96)

In Tab. 3.1 ist farblich gekennzeichnet, ob ein entsprechendes Passwort anfällig für einen
Brute-Force-Angriff ist. Dazu wird angenommen, dass eine Milliarde Passwortvergleiche pro
Sekunde durchgeführt werden können. Unter der Voraussetzung idealer Bedingungen und unter
Berücksichtigung moderner Computerhardware ist dies eine plausible Annahme. Eine rote
Hintergrundfarbe kennzeichnet, dass unter obiger Annahme weniger als ein Tag benötigt wird, um
das Passwort zu berechnen. Eine orange Färbung kennzeichnet eine Rechendauer von mehr als
einem Tag, aber weniger als 20 Jahren. Bei einer grünen Färbung werden mehr als 20 Jahre
benötigt.
Menschen können sich kurze und einfache Passwörter besser merken und tendieren daher dazu,
Passwörter mit geringer Sicherheit zu wählen.21 Häufig wird deshalb eine Passwortrichtlinie
festgelegt, die eine Mindestkomplexität vorschreibt. Wie der Tabelle zu entnehmen ist, erhöht sich
die Sicherheit bei der Verwendung von Passwörtern mit zunehmender Länge und Komplexität.
Werden zu komplexe Passwörter gewählt, sinkt jedoch die Benutzbarkeit. Ist die
Passwortrichtlinie zu streng, können sich Personen Passwörter möglicherweise nicht mehr merken
und neigen dazu, sie zu notieren, wodurch ein neuer Angriffspunkt entsteht.
Die Verwendung desselben Passwortes für unterschiedliche Services ist besonders kritisch.
Sollte ein Service kompromittiert worden sein, ist es möglich, dass das Passwort einem Angreifer
bekannt geworden ist und anschließend für den Zugang zu einem anderen Service verwendet wird.
Wird für jeden Service ein unterschiedliches Passwort gewählt, besteht diese Gefahr nicht. Da
jedes Passwort möglichst komplex sein sollte, verringert sich jedoch auch die Benutzbarkeit. Eine
mögliche Lösung sind Passwortmanager oder Single-Sign-On Verfahren.22

3.2.2 Grafische Passwörter


Die Verwendung textueller Passwörter hat den großen Nachteil, dass die Sicherheit maßgeblich
von der Länge und Komplexität abhängt. Benutzer neigen allerdings dazu, kurze und wenig
komplexe Passwörter zu wählen. Werden durch Richtlinien eine Mindestlänge oder eine
Mindestkomplexität vorgeschrieben, entstehen Probleme bei der Benutzbarkeit, da Personen sich
die Passwörter nicht gut merken können. Als Alternative wurden grafische Passwörter entwickelt.
Die Idee grafischer Passwörter basiert auf der Feststellung, dass das menschliche Gehirn sehr
gut in der Lage ist, grafische Strukturen zu erkennen und sich diese einzuprägen. Durch die
Verwendung von grafischen Passwörtern kann eine geforderte hohe Komplexität unter
Berücksichtigung der Benutzbarkeit deshalb gut realisiert werden. Erste Untersuchungen haben
jedoch gezeigt, dass Benutzer, ebenso wie bei textuellen Passwörtern, meistens sehr schwache
Passwörter, also einfache grafische Strukturen, wählen.23
Die Verwendung grafischer Passwörter ist besonders auf mobilen Endgeräten, wie Tablets
oder Smartphones, verbreitet, welche über ein Touch-Benutzerinterface verfügen. Das Passwort
wird bei diesen Geräten durch Zeichnen mit dem Finger direkt eingegeben.

3.3 Authentifizierung durch den Besitz eines Gegenstandes


Die Authentifizierung durch den Besitz eines Gegenstandes basiert auf der Annahme, dass ein
Angreifer nicht ohne Weiteres in den Besitz des Gegenstandes kommen kann. Entsprechende
Authentifizierungsverfahren sind besonders stark außerhalb des IT-Bereichs verbreitet. Ein
typisches Beispiel ist ein einfacher Schlüssel, welcher zum Öffnen eines mechanischen Schlosses
verwendet werden kann.24 Eine Anwendung ist das Öffnen der Wohnungstür. Um das Kopieren
eines Schlüssels zu vermeiden, wird häufig zusätzlich eine digitale Komponente eingebaut, die
dies verhindert (z. B. Autoschlüssel mit einem Mikrochip).
Bei einem Gegenstand als Faktor wird eine Person immer korrekt authentifiziert, wenn sie im
Besitz des Gegenstandes ist. Gibt es mehrere identische Gegenstände, die im Besitz mehrerer
Personen sind, ist eine Identifizierung nicht mehr möglich. Infolgedessen kann ausschließlich eine
Autorisierung erfolgen, aber keine Authentifizierung. Kann ein Gegenstand einer Person eindeutig
zugeordnet werden (z. B. durch eine Karte mit Magnetstreifen oder Chip), ist die Identifizierung
möglich. Es besteht aber weiterhin das Problem, dass der Gegenstand weitergegeben bzw.
entwendet werden kann. Daher findet dieser Faktor häufig Anwendung im Rahmen einer Zwei-
Faktor-Authentifizierung25 in Kombination mit einem wissensbasierten Attribut. Auf diese Weise
wird ein Angreifer gezwungen, sich den Gegenstand vor Ort zu beschaffen und zusätzlich an das
Wissen der Person zu gelangen. Durch die Kombination werden reine Remote Angriffe
verhindert.26

3.3.1 Identifikations- oder Authentifikations-Token


Ein Identifikations- oder Authentifikations-Token ist eine Hardwarekomponente, die dazu dient,
die Identifikation und Authentifizierung einer Person durch Besitz sicherzustellen. Dies wird
üblicherweise durch einen kryptografischen Einmalschlüssel erreicht, welcher jeweils vom Token
generiert wird. Um ein Duplizieren des Token zu verhindern (z. B. durch Reverse Engineering),
werden hardwareseitige Sicherheitsmaßnahmen eingesetzt.27

3.3.2 Chipkarten
Die Verwendung von Chipkarten ist weit verbreitet und findet beispielsweise im Bankwesen eine
Anwendung. Eine Chipkarte ist eine genormte Karte, welche üblicherweise aus Plastik besteht
und einen Speicher oder integrierten Schaltkreis enthält. Generell kann eine Unterscheidung
zwischen Speicher-Chipkarten und Prozessor-Chipkarten getroffen werden.28 Die
Speicherfunktionalität ist üblicherweise durch einen Magnetstreifen realisiert oder durch einen
einfachen Speicher-Chip. Leistungsfähigere Prozessor-Chipkarten verfügen zusätzlich über einen
integrierten Schaltkreis mit CPU und ein eigenes Betriebssystem.
3.4 Authentifizierung durch eine Eigenschaft einer Person
Die Identifizierung durch eine Eigenschaft einer Person ist sehr attraktiv, da eine solche
Eigenschaft (im Idealfall) nicht übertragen oder gestohlen werden kann.29 Dass ein Diebstahl in
Zukunft eventuell doch möglich ist, kann aber nicht ausgeschlossen werden und ist daher
problematisch. Im Falle einer Kompromittierung ist es nicht möglich, die Merkmale zu erneuern,
da diese Teil der Person sind. Dazu kommen datenschutzrechtliche Probleme, da es sich um
personenbezogene Daten handelt.30

3.4.1 Fingerabdruck
Der Fingerabdruck ist als Mittel zur Identifizierung sehr bekannt und wird beispielsweise zur
Identifizierung in der Kriminalistik seit langem erfolgreich eingesetzt. Die Sicherheit beruht auf
der Annahme, dass alle Menschen verschiedene Fingerabdrücke haben und dass diese nicht
kopiert werden können. Die Tatsache, dass Fingerabdrücke eindeutig sind, ist zwar nicht
bewiesen, jedoch durch die zufällige Entstehung der Abdrücke im Wachstum der Finger
ausreichend wahrscheinlich. Die Tatsache, dass Fingerabdrücke nicht kopiert werden können, ist
bereits mehrfach wiederlegt worden, und jedes neu vorgestellte Verfahren zur Überprüfung von
Fingerabdrücken wurde innerhalb kurzer Zeit gebrochen. Da jedoch für das Kopieren des
Fingerabdrucks immer Zugang zu einem Abdruck vorliegen muss (physisch oder Aufnahme hoher
Qualität), ist dies häufig weniger problematisch. Obwohl Fingerabdrücke schon lange zur
Identifizierung verwendet werden können, hat die Verwendung in den letzten Jahren durch neue
technologische Entwicklungen deutlich zugenommen. Insbesondere bei Smartphones ist ein
Fingerabdruckscanner inzwischen sehr verbreitet.

3.4.2 Iris und Stimme


Weitere Merkmale zur Identifizierung von Personen sind die Iris des Auges und die Stimme. Zur
Erkennung der Iris werden mehrere Hundert optische Merkmale erfasst, welche sich beim
Menschen in den ersten Lebensmonaten zufällig entwickeln. Für die Stimmerkennung werden
eindeutige Charakteristika der Sprache, wie Frequenzen und Amplituden, abgeglichen. Beide
Merkmale sind grundsätzlich für eine eindeutige Identifikation geeignet, finden in der Praxis
jedoch wenig Anwendung.

3.5 Mehr-Faktor-Authentifizierung
Die meisten populären Cloud-Anwendungen nutzen eine Ein-Faktor-Authentifizierung. Bedingt
durch die einfache technische Umsetzbarkeit und die Akzeptanz durch die Benutzer ist dies meist
eine Kombination aus Benutzerkennung und Passwort. In vielen Fällen ist dies bei angemessener
technischer und organisatorischer Absicherung auch ausreichend und entspricht einem
angemessenen Sicherheitsniveau. Sollte durch höhere Sicherheitsanforderungen eine zusätzliche
Absicherung benötigt werden, kann eine Kombination mehrerer Faktoren eine deutliche
Verringerung des Risikos bewirken. Werden mindestens zwei Faktoren zur Authentifizierung
eingesetzt, spricht man von einer Mehr-Faktor-Authentifizierung. Die Faktoren müssen nicht
zwingend unterschiedlich sein. Denkbar ist auch die Abfrage zweier oder mehrerer
wissensbasierter Faktoren.31
Das Ziel der Mehr-Faktor-Authentifizierung ist, die Schwachstelle nur eines Faktors mit dem
Einsatz eines oder mehrerer weiterer Faktoren auszugleichen. Eine verbreitete Kombination ist
die Verwendung eines wissensbasierten Faktors und eines zweiten Faktors in Form eines
physischen Gegenstandes. Um den Besitz des Gegenstandes nachweisen zu können, werden im
Rahmen der Authentifizierung in Informationssystemen häufig Sicherheitstoken eingesetzt. Ein
Token zeigt eine wechselnde Ziffernfolge an, die abgelesen werden muss und anschließend dem
System übermittelt wird. Bei der Authentifizierung wird sowohl eine Benutzerkennung mit
Passwort als auch die Ziffernfolge des Tokens abgefragt. Auf diese Weise ist sichergestellt, dass
der Benutzer im Besitz beider Faktoren ist. Sollte das Passwort bekannt werden, muss ein
Angreifer zusätzlich physischen Zugriff auf den Token haben. Im Gegenzug muss bei Vorliegen des
Tokens auch das Passwort erlangt werden. Reine Online-Angriffe werden durch den Einsatz des
zweiten Faktors daher effektiv verhindert.
Der Einsatz mehrerer Faktoren ist auch mit Nachteilen verbunden, weshalb der Einsatz
durchaus abgewogen werden sollte. Ist einer der Faktoren nicht verfügbar, ist eine
Authentifizierung zunächst nicht mehr möglich. Im Falle eines Tokens kann der Token entweder
vergessen worden sein oder aber entwendet, um den Zugriff gezielt zu verhindern.
Die Verwendung mehrerer Faktoren zur Authentifizierung findet teilweise Einsatz, wenn
erhöhte Sicherheitsanforderungen bestehen. In der Regel wird die Kombination von zwei Faktoren
verwendet. Die folgenden Kombinationen stellen die verbreiteten Varianten der Verknüpfung
zweier Faktoren dar.

3.5.1 Kombination aus Wissen und Besitz


Die meist genutzte Variante der Zwei-Faktor-Authentifizierung ist die Verknüpfung eines
wissensbasierten Faktors mit einem Gegenstand als Faktor. Die Verwendung dieser Alternative ist
in vereinzelten Anwendungsbereichen sehr weit verbreitet und findet zudem große Akzeptanz bei
den Benutzern. Ein bekanntes Beispiel ist die Verwendung von einer Bankkarte und zugehöriger
PIN, mit welcher sich ein Benutzer an einem Geldautomaten authentisieren kann. Ein ähnliches
Vorgehen wird bei Onlineüberweisungen verwendet, bei denen der Benutzer eine
Benutzerkennung mit Passwort übermittelt und für jede Transaktion zusätzlich eine einmalige
Transaktionsnummer (TAN) angeben muss. Der zusätzliche Aufwand dieser Methoden wird durch
die hohen Sicherheitsanforderungen bei Finanztransaktionen gerechtfertigt.

3.5.2 Kombination aus Besitz und einer Eigenschaft


Die Kombination einer Eigenschaft einer Person mit einem Gegenstand ist in bestimmten
Anwendungsbereichen weit verbreitet. Ein bekanntes Beispiel ist ein Lichtbildausweis. Bei der
Authentifizierung liegt der Ausweis mit Lichtbild physisch vor und in Verbindung mit dem
Aussehen der Person kann die Authentifizierung erfolgen. Bei der elektronischen Authentifizierung
ist es möglich, ein biometrisches Merkmal, wie beispielsweise einen Fingerabdruck, mit einem
Gerät zu verknüpfen, sodass de facto eine Mehr-Faktor-Authentifizierung vorliegt. Wird das Gerät
zur Authentifizierung an einem entfernten Service genutzt und liegt der gespeicherte Fingerabdruck
nur auf dem Gerät vor, muss sowohl das Gerät im Besitz des Benutzers sein als auch der
Fingerabdruck vorliegen.32

4 Konkretisierung möglicher Schutzmaßnahmen


Aufbauend auf den Grundlagen von (digitalen) Identitäten und der Authentifizierung folgt eine
Konkretisierung von Schutzmaßnahmen. Die hier erläuterten Maßnahmen werden in Kap.​ 5 die
Grundlage für die Entscheidungsunterstützung bilden. Durch die quantitative Analyse werden
optimale Maßnahmenkombinationen vorgeschlagen, um einen effektiven und angemessenen Schutz
von Cloud-Anwendungen zu erzielen. Hinzu kommt in Kap.​ 6 eine weiterführende Diskussion der
erzielten Ergebnisse, um zu klären, inwiefern ökonomisch sinnvolle Entscheidungen den
rechtlichen Anforderungen genügen.

4.1 Maßnahmen zur Authentifizierung


Im Folgenden werden die gängigen Authentifizierungsmethoden erläutert. Die vorgestellten
Maßnahmen können einzeln oder in Kombination eingesetzt werden, um den unbefugten Zugriff auf
ein System zu verhindern.

4.1.1 Passwort
Die Authentifizierung durch das Passwortverfahren beruht auf der Annahme, dass ein Subjekt
Kenntnis über ein Geheimnis besitzt, welches zuvor mit dem System vereinbart wurde. Die
Aufgabe des Systems ist es, die Passwörter, zumeist durch Kryptografie, vor unautorisiertem
Zugriff zu sichern. Durch Verwenden von Hashfunktionen ist ein Passwort nicht ohne erheblichen
Aufwand zu berechnen.
Auch wenn systemintern die Sicherheit weitgehend gewährleistet werden kann, so ist
weiterhin sicherzustellen, dass ein Passwort gewissen Anforderungen entspricht, um nicht durch
simple Methoden „geknackt“ zu werden. Darüber hinaus muss der Benutzer sicherstellen, dass
sein Passwort nicht durch Shoulder Surfing33 oder ähnliche Angriffe gestohlen werden kann.34

4.1.2 Personal Identification Number (PIN)


Die Personal Identification Number ist ein zumeist vierstelliger Code, der nur dem Nutzer und
dem entsprechenden Computer-Chip bekannt sein sollte. Die Authentifizierung geschieht an einem
Lesegerät, indem der Nutzer durch die Eingabe der PIN seine Identität bestätigen kann.35

4.1.3 Fingerabdruck
Die Authentifizierung durch das biometrische Merkmal Fingerabdruck beruht darauf, dass dieses
Merkmal bei jedem Menschen vorhanden, verschieden und grundsätzlich nicht zu verändern ist.
Zunächst muss ein Scan der Fingerkuppe erstellt werden. Das geschieht durch optische oder
sensorbasierte Techniken. In einem nächsten Schritt müssen störende Verzerrungen, z. B.
Verschmutzungen, durch einen Filter entfernt werden. Im Anschluss sind von einem
Erkennungssystem charakteristische Merkmale, wie Verzweigungen, Verläufe und Endpunkte der
Rillen auf der Fingerkuppe, zu analysieren. Zuletzt muss das gefundene Muster mit den im System
gespeicherten Werten abgeglichen werden. Findet das System eine bestimmte, vorher festgelegte
Anzahl an Übereinstimmungen, ist die Authentifizierung abgeschlossen.36

4.1.4 Handy TAN


Bei der Authentifizierung einer Transaktion mittels einer Handy TAN wird dem Nutzer im Verlauf
des Transaktionsprozesses eine solche per SMS gesendet, mit welcher der Geschäftsprozess
bestätigt werden kann. In der SMS befinden sich zusätzlich einige Details bezüglich der
Transaktion, um die Echtheit zu garantieren.37

4.1.5 E-Mail TAN


Der Prozess der Authentifizierung über eine E-Mail TAN folgt dem der Handy TAN. Der
Unterschied liegt nur in dem genutzten Informationskanal.

4.1.6 Hardware OTP Token


Die Authentifizierung über das Hardware Token mittels eines Einmal-Passworts (OTP) stellt eine
Zwei-Faktor-Authentifizierung dar. Auf dem entsprechenden Server ist jedes Token eindeutig mit
einem Nutzer verknüpft. Für den Vorgang der Authentifizierung gibt es verschiedene
Möglichkeiten, beispielsweise kann zwischen Server und Token eine Kommunikation stattfinden,
bei der eine Antwort auf eine Frage berechnet und verschlüsselt übermittelt wird, oder Token und
Server können gleichzeitig einen Code festlegen, welchen das Token ausgibt. Der Nutzer kann sich
dann mit seinen persönlichen Daten sowie der Kenntnis über den aktuellen Code
authentifizieren.38

4.1.7 Smartcard
Bei der Authentifizierung mittels Smartcard beweist der Nutzer zunächst seine Identität gegenüber
der Smartcard anhand einer PIN oder eines biometrischen Merkmals. Durch den Prozessor der
Smartcard wird die eingegebene PIN mit der im „Electrically Erasable Programmable Read-
Only-Memory“ (EEPROM) hinterlegten PIN verglichen. Ist die dort gespeicherte PIN
verschlüsselt, wird die eingegebene PIN mittels des im EEPROM hinterlegten
Verschlüsselungsverfahrens verschlüsselt und anschließend verglichen.
Danach findet eine weitere Authentifizierung zwischen der Smartcard und dem Lesegerät statt,
indem das Lesegerät der Smartcard eine zufällig generierte Zahl sendet, anhand welcher die Karte
mittels eines Pre-shared Secrets eine Antwort berechnet und verschlüsselt zurücksendet.
Im letzten Schritt authentifiziert sich die Smartcard gegenüber dem System anhand von
Challenge-Response-Protokollen, welche verschiedene Ausprägungen von
Authentifizierungsverfahren auf Basis von Wissen darstellen.39

4.1.8 Software OTP Token


Ein Software Token ist ein Programm, das auf einem Computer oder ähnlichen mobilen Geräten
installiert und ausgeführt wird. Die Authentifizierung kann auf den gleichen Wegen stattfinden, wie
dies bei einem Hardware Token geschieht. Der Unterschied ist der, dass hier das Token nur
virtuell zur Verfügung steht. Wenn das Einmal-Passwort berechnet ist, wird dieses üblicherweise
direkt an den Server übermittelt. Durch die virtuelle Implementierung ist diese Möglichkeit der
Authentifizierung wiederum anfälliger gegen Angriffe als ein Hardware Token, der in physischer
Form vorliegt.40

4.1.9 TAN-Liste
Eine Liste mit Transaktionsnummern wird beispielsweise im Online-Banking eingesetzt, um bei
bestimmten Transaktionen die Identität des Benutzers nachvollziehen zu können. Bei jeder
entsprechenden Transaktion muss der Nutzer eine TAN dieser Liste eingeben, die ihm von dem
zuständigen Administrator zur Verfügung gestellt wurde (sog. schlichtes PIN/TAN-Verfahren41).
Jede TAN ist außerdem nur für eine einzige Transaktion gültig. Weiterhin besteht die Möglichkeit,
für eine Transaktion eine ganz bestimmte TAN der Liste abzufragen (sog. iTAN-Verfahren42).43

4.1.10 eID (nPA)


Der elektronische Personalausweis bietet die eID-Funktion, welche das Bestätigen der Identität
bei elektronischen und internetbasierten Transaktionen erleichtert und sicherer gestaltet. Mittels
der Verwendung qualifizierter Signaturen kann eine dauerhafte Verbindung zwischen dem Besitzer
und der digitalen Identität erreicht werden. Für diese Funktion werden bestimmte Informationen,
wie Name, Titel, Herkunft, Gültigkeit und andere, verwendet. Auf dem Chip des elektronischen
Personalausweises werden biometrische Daten gespeichert, insbesondere das Gesichtsbild. Der
Fingerabdruck wird nur bei Zustimmung auf dem Ausweis gespeichert.
Die Daten können zudem nur durch solche Services gelesen werden, die ein entsprechendes
Berechtigungszertifikat besitzen. Der Besitzer kann außerdem kontrollieren, welche Daten zum
Auslesen für welchen Service zur Verfügung stehen.
Die Sicherheit soll dadurch erhöht werden, dass eine Zwei-Faktor-Authentifizierung vorliegt,
da der Benutzer die Smartcard und zudem das Wissen über die entsprechende PIN besitzen
muss.44

4.2 Möglichkeiten der Ein-Faktor-Authentifizierung


Es existieren verschiedene Maßnahmen, die für den Einsatz bei einer Ein-Faktor-Authentifizierung
geeignet sind. Diese sind auch ohne eine Kombination mit einem zweiten Faktor vergleichsweise
sicher. Dazu gehört die Authentifizierung über ein Passwort, welches durch eine Hashfunktion
verschlüsselt ist. Die nächste Möglichkeit basiert auf der PIN, welche ein Geheimnis zwischen
dem Chip und dem Nutzer darstellt. Weitere Methoden stellen das Nachweisen der Identität über
das biometrische Merkmal Fingerabdruck und das Verwenden einer Smartcard dar. Die
biometrische Identifikation, insbesondere der Fingerabdruck, wird besonders auf mobilen
Endgeräten verwendet. Bei der Smartcard findet die Authentifizierung über mehrere Stufen
zwischen dem Nutzer, der Chipkarte und dem Server statt.

4.3 Möglichkeiten der Zwei-Faktor-Authentifizierung


Bei der Zwei-Faktor-Authentifizierung gibt es verschiedene Kombinationsmöglichkeiten von
Faktoren, um eine erhöhte Sicherheit gegenüber der Ein-Faktor-Authentifizierung zu
gewährleisten. Oft wird eine Kombination aus entweder Passwort oder PIN und einem weiteren
Faktor verwendet. Dafür ist besonders die Authentifizierung über eine TAN, die entweder einer
Liste entnommen oder an die E-Mail-Adresse oder das Handy gesendet wird, geeignet. Auch
Token können in Form von Hardware oder Software als zweite Stufe der Authentifizierung genutzt
werden.45 Grundsätzlich sind auch alle weiteren Faktoren der Ein-Faktor-Authentifizierung
geeignet, als zweiter Authentifizierungskanal zu dienen.

4.4 Ergänzende Maßnahmen


Noch darüber hinaus gibt es die Möglichkeit, weitere Sicherheitsmaßnahmen und Richtlinien zu
etablieren, um fremden Zugriff auf Datenverarbeitungssysteme zu verhindern. Zum einen betreffen
diese Möglichkeiten das Verwenden von Passwörtern. Indem bei der Wahl von Passwörtern
bestimmte Vorgaben bezüglich der Sicherheitsstufe und Komplexität, aber auch bei der
Lebensdauer und Wiederholung von Passwörtern strenge Vorschriften gemacht werden, kann die
Wahrscheinlichkeit fremden Zugriffs über diesen Kanal minimiert werden.
Zum anderen kann im Datenverarbeitungssystem ein Mechanismus zum automatischen
Ausloggen und ein Single-Sign-On integriert werden. Dabei meldet sich der Nutzer einmalig im
Netzwerk an und hat anschließend Zugriff auf alle notwendigen Ressourcen, ohne sich für jede
Instanz mit einem möglicherweise schwachen Passwort neu anzumelden.
Sinnvoll können noch zwei weitere Maßnahmen sein: Auf der einen Seite sollten Prozesse im
Netzwerk verschlüsselt werden, auf der anderen Seite ist es sinnvoll, alle Netzwerkprozesse zu
protokollieren, um ungewollte Zugriffe möglicherweise erkennen zu können.

Literatur
Baier, Tobias: Persönliches digitales Identitätsmanagement. Untersuchung und Entwicklung von Konzepten und
Systemarchitekturen für die kontrollierte Selbstdarstellung in digitalen Netzen, Dissertation an der Universität Hamburg 2006.

Benantar, Messaoud: Access Control Systems, Security, Identity Management and Trust Models, New York 2006.

Beutelspacher, Albrecht/Kersten, Annette G./Pfau, Axel: Chipkarten als Sicherheitswerkzeug, Berlin Heidelberg 1991.

Borges, Georg/Schwenk, Jörg/Stuckenberg, Carl-Friedrich/Wegener Christoph: Identitätsdiebstahl und Identitätsmissbrauch im


Internet. Rechtliche und technische Aspekte, Berlin 2011.

Camp, L. Jean: Economics of identity theft. Avoidance, Causes and Possible Cures, New York 2007.

Derleder, Peter/Knops, Kai-Oliver/Bamberger, Heinz Georg: Deutsches und europäisches Bank- und Kapitalmarktrecht, 3.
Aufl., Berlin Heidelberg 2017.

Eckert, Claudia: IT-Sicherheit, Konzepte, Verfahren, Protokolle, 7. Aufl., Oldenburg 2012.

Hansen, Marit/Meints, Martin: Digitale Identitäten – Überblick und aktuelle Trends, Identity-Lifecycle, Authentisierung und
Identitätsmanagement, DuD 2006, 543–547.

Hühnlein, Detlef: Identitätsmanagement, Eine visualisierte Begriffsbestimmung, DuD 2008, 161–163.

Kappes, Martin: Netzwerk und Datensicherheit, Eine praktische Einführung, 2. überarbeitete und erweiterte Aufl., Frankfurt am
Main 2013.
Laue, Philipp/Stiemerling, Oliver: Identitäts- und Zugriffsmanagement für Cloud Computing Anwendungen, Technisch-
organisatorische Probleme, Rechtliche Risiken und Lösungsansätze, DuD 2010, 692–697.

Nitsch, Karl Wolfhart: IT-Recht, 4. Aufl., Bremen 2014.

Rohr, Matthias: Sicherheit von Webanwendungen in der Praxis. Wie sich Unternehmen schützen können – Hintergründe,
Maßnahmen, Prüfverfahren und Prozesse, Wiesbaden 2015.

Ruan, Xiaoyu: Platform Embedded Security Technology Revealed: Safeguarding the Future of Computing with Intel Embedded
Security and Management Engine, New York 2014.

Roßnagel, Heiko/Zibuschka, Jan: Single Sign On mit Signaturen, Integration von elektronischen Signaturen und Passwortsystemen,
DuD 2006, 773–777.

Schrödel, Tobias: Ich glaube, es hackt! Ein Blick auf die irrwitzige Realität der IT-Sicherheit, 3. aktualisierte und erweiterte Aufl.,
Wiesbaden 2014.

Tietz, Christian/Pelchen, Chris/Meinel, Christoph/Schnjakin, Maxim: Management digitaler Identitäten, Potsdam 2017.

Uellenbeck, Sebastian/Dürmuth, Markus/Wolf, Christopher/Holz, Thorsten: Quantifying the Security of Graphical Passwords:
The Case of Android UnlockPatterns. ACM Conference on Computer and Communications Security (CCS), Berlin, November
2013.

Fußnoten
1 Benantar (2006), S. 40.

2 Vgl. zu den verschiedenen Begriffsbestimmungen Borges et al., Identitätsdiebstahl, S. 1 ff.

3 Vgl. bereits Kap.​ 2, 3.​1.

4 Camp (2007), S. 87; Tietz et al. (2017), S. 14 f.

5 Hühnlein (2008), S. 161 f.

6 Hansen/Meints (2006), S. 545 f.

7 Hühnlein (2008), S. 162.

8 Laue/Stiemerling (2010), S. 692.


9 Baier (2006), S. 81.

10 Eckert (2012), S. 461.

11 Benantar (2006), S. 10; Camp (2007), S. 88.

12 Siehe Kap.​ 5, 2.​3.​2.​1.

13 Vgl. zur Methode Kap.​ 5, 2.​3.​1.​4.

14 Benantar (2006), S. 10.

15 Camp (2007), S. 88.

16 Hansen/Meints (2006), S. 545 f.

17 Camp (2007), S. 88.

18 Tietz et al. (2017), S. 21 ff.

19 Roßnagel/Zibuschka (2005), S. 775 f.

20 Siehe Kap.​ 5, 2.​3.​1.​4.

21 Schrödel (2014), S. 53.

22 Siehe zum Verfahren Kap.​ 2, 3.​3 und dort Abb.​ 2.​1 sowie zu möglichen Angriffen Kap.​ 2, 4.​1.​6.
23 Uellenbeck/Dürmuth/Wolf/Holz (2013), S. 1.

24 Tietz et al. (2017), S. 23.

25 Vgl. oben 3.1.

26 Ein Remote Angriff erfolgt ausschließlich über einen Fernzugriff und erfordert keine Präsenz am Ort des angegriffenen Ziels.

27 Kappes (2013), S. 49.

28 Beutelspacher/Kersten/Pfau (1991), S. 5 ff.

29 Tietz et al. (2017), S. 23.

30 Siehe zu Begriff und Bedeutung personenbezogener Daten Kap.​ 4, 5.​1 und Kap.​ 6, 2.​1.​1.​1.​1.​3.

31 Camp (2007), S. 11 ff.

32 Rohr (2015), S. 191.

33 Vgl. bereits oben 3.1; zum Begriff siehe Kap.​ 5, 2.​3.​2.​1.

34 Eckert (2012), S. 462 ff.

35 Eckert (2012), S. 575.

36 Eckert (2012), S. 490 ff.


37 Nitsch (2014), S. 160.

38 Eckert (2012), S. 467 ff.

39 Eckert (2012), S. 481, 539 ff.

40 Ruan (2014), S. 217.

41 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 35.

42 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 36.

43 Nitsch (2014), S. 159.

44 Eckert (2012), S. 569 ff.

45 Tietz et al. (2017), S. 25 f.


© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018
Georg Borges und Brigitte Werners (Hrsg.), Identitätsmanagement im Cloud Computing, https://doi.org/10.1007/978-3-662-55584-
2_4

4. Rechtliche Rahmenbedingungen des


Identitätsmangements im Cloud Computing
Alexander Golland1 und Peter Schneidereit2
(1) Landgericht Bochum, 44787 Bochum, Deutschland
(2) Luther Rechtsanwaltsgesellschaft, Service Line IP/IT, 45127 Essen, Deutschland

Alexander Golland (Korrespondenzautor)


Email: alexander.golland@rub.de

Peter Schneidereit
Email: peter.schneidereit@luther-lawfirm.com

1 Überblick
2 Zivilrecht
2.1 Vertragsrecht
2.1.1 Anwendbares Recht
2.1.1.1 Grundsätzliche Anknüpfung
2.1.1.2 Rechtswahl
2.1.1.3 Verbraucherbeteiligung
2.1.2 Vertragstypologie
2.1.2.1 Grundsatz
2.1.2.2 Hauptleistungspflichten
2.1.2.3 Zusatzvereinbarungen
2.1.2.4 Bedeutung von SLA
2.1.3 Pflichten des Cloud-Anbieters
2.1.4 Pflichten des Cloud-Nutzers
2.1.5 Allgemeine Geschäftsbedingungen (AGB)
2.1.5.1 Begriff und wirksame Einbeziehung
2.1.5.2 Zulässigkeitsgrenzen
2.1.6 Einschaltung von Unterauftragnehmern
2.2 Deliktsrecht
2.2.1 Anwendbares Recht
2.2.1.1 Rechtswahl
2.2.1.2 Objektive Anknüpfung
2.2.1.3 Sonderfall: Verletzungen des allgemeinen Persönlichkeitsrechts
2.2.2 Anspruchsgrundlagen
2.2.3 Verkehrspflichten
3 TMG
3.1 Anwendungsbereich
3.2 Vorgaben an das Identitätsmanagement
4 eIDAS-Verordnung
5 Datenschutzrecht
5.1 Verarbeitung personenbezogener Daten
5.1.1 Begrifflichkeit
5.1.2 Relevanz für das Management von Identitäten
5.1.3 Sonderfall: IP-Adressen
5.2 Räumlich anwendbares Datenschutzrecht
5.3 Gewährleistung von Datensicherheit
5.4 Besonderheiten bei der Auftragsdatenverarbeitung
5.4.1 Cloud Computing als Auftragsdatenverarbeitung
5.4.2 Rechtsfolgen
5.4.3 Auftragsverarbeitung nach der DSGVO
5.5 Spezialdatenschutz
5.5.1 Nutzungsdaten
5.5.2 Sonstige Pflichten
5.5.3 Geltung des TMG nach Anwendbarkeit der DSGVO
5.6 Schadensersatz
6 Produkt- und branchenspezifische Aspekte
6.1 Kreditwirtschaft
6.1.1 Maßgebliche Rechtsgrundlagen
6.1.2 Anwendungsbereich
6.1.2.1 Begriff des Kredit-/Finanzdienstleistungsinstituts
6.1.2.2 Umfang der Tätigkeit
6.1.2.3 Vorliegen einer wesentlichen Auslagerung
6.1.3 Pflicht zur ordnungsgemäßen Geschäftsorganisation
6.1.4 Ausblick
6.2 Sozialversicherungsträger
6.2.1 Anwendbarkeit
6.2.2 Zulässigkeit der Auslagerung in die Cloud
6.2.3 Pflicht zur Gewährleistung von Datensicherheit
6.3 Beweisrecht
6.3.1 Grundlegende Beweislastverteilung
6.3.2 Verbesserung der Beweissituation
6.3.2.1 Sekundäre Darlegungslast
6.3.2.2 Anscheinsbeweis
6.3.2.3 Umkehr der Beweislast
7 Strafrecht
7.1 Potenzieller Täterkreis
7.2 Tathandlung
7.3 Reichweite des Gehilfenbegriffs
7.4 Neuregelung
8 Öffentliches Recht
8.1 Verwaltungsgeheimnis
8.1.1 Rechtsgrundlagen
8.1.2 Allgemeines Verwaltungsgeheimnis, § 30 VwVfG
8.1.2.1 Anwendungsbereich
8.1.2.2 Geheimnisbegriff
8.1.2.3 Offenbarungsbefugnis
8.1.2.4 Rechtsfolgen von Verstößen
8.1.3 Steuergeheimnis, § 30 AO
8.1.4 Sozialgeheimnis, § 35 SGB I
8.1.5 Datengeheimnis, § 5 BDSG
8.1.6 Auswirkungen auf E-Government
8.2 Verfahrensgeheimnis
8.2.1 Grundsatz
8.2.2 Prozessuale Maßnahmen zum Schutz von Geheimnissen
8.2.2.1 Verwaltungsverfahren: § 99 Abs. 1 S. 2 VwGO
8.2.2.2 Ausschluss der Öffentlichkeit
8.2.2.2.1 Grundsatz
8.2.2.2.2 Potenzielle Ausschlussgründe
8.2.2.2.3 Verfahren
Literatur

1 Überblick
Cloud Computing wirft in zahlreichen Rechtsbereichen neuartige juristische Fragestellungen auf.
Ziel der Darstellung der rechtlichen Rahmenbedingungen ist, die das Identitätsmanagement in der
Cloud betreffenden Rechtsgrundlagen aus den unterschiedlichen Rechtsgebieten vorzustellen und
einzuordnen, bevor im Rahmen des sechsten Kapitels die Darstellung der hieraus resultierenden
Verpflichtungen in ihrer konkreten Form erfolgt.
Da Cloud-Dienste vielfach länderübergreifend erbracht werden und es sich mithin um
grenzüberschreitende Sachverhalte handelt, wird in allen Bereichen zunächst die Frage nach dem
anwendbaren Recht virulent. Während das Verhältnis von Cloud-Anbieter und Cloud-Nutzer
vorrangig von vertraglichen Normen geprägt ist, werden bei der Schädigung durch außenstehende
Dritte insbesondere deliktische Anspruchsgrundlagen relevant. Je nach Einsatzgebiet der Cloud
können sich zudem weitere Anforderungen aus branchenspezifischen Vorschriften ergeben.
Weiterhin wirken sich auch strafrechtliche Verbote und grundrechtliche Wertungen in
erheblichem Umfang auf den Bereich des Cloud Computing aus. Besonderes Gewicht kommt in
letzterem Kontext denjenigen Rahmenbedingungen zu, die aus dem Bereich des Datenschutzrechts
als Konkretisierung des Rechts auf informationelle Selbstbestimmung resultieren. Schließlich
ergeben sich aufgrund der Struktur von Cloud-Lösungen in der prozessualen Nachweisbarkeit der
anspruchsbegründenden Merkmale erhebliche Schwierigkeiten, die gleichfalls Gegenstand der
Erörterung sein sollen.

2 Zivilrecht
Im Zivilrecht stehen Rechtsfragen im Zusammenhang mit der Risikoverteilung und der Haftung für
Schäden im Vordergrund. Hier ist zu klären, welche Pflichten die Beteiligten hinsichtlich des
Identitätsmanagements treffen und welcher Beteiligte unter welchen Voraussetzungen das Risiko
einer missbräuchlichen Identifizierung zu tragen hat. Rechte und Pflichten der am
Identitätsmanagement Beteiligten können sich insofern sowohl aus Vertrag als auch, hiervon
losgelöst, aus deliktischen Normen ergeben. Schließlich ist in diesem Rahmen auch zu erörtern,
welche Auswirkungen der Einsatz konkreter Authentifizierungsmechanismen auf die prozessuale
Beweissituation hat.

2.1 Vertragsrecht
Cloud Computing-Dienste werden in der Regel auf Grundlage eines Vertrags zwischen Cloud-
Nutzer und Cloud-Anbieter erbracht. In dieser Beziehung stammen die Anforderungen an das
Identitätsmanagement folglich insbesondere aus dem Vertragsrecht. Im Folgenden werden daher
zunächst die wesentlichen vertragsrechtlichen Weichenstellungen analysiert.

2.1.1 Anwendbares Recht


Bei der Datenverarbeitung in der Cloud handelt es sich typischerweise um grenzüberschreitende
Sachverhalte: Der Sitz des Cloud-Anbieters sowie die einzelnen Rechner, auf die die Ressourcen
verteilt sind, befinden sich häufig in verschiedenen Staaten. Hinzu kommt, dass ein Zugriff auf die
Daten naturgemäß auch über Ländergrenzen hinweg erfolgen kann. Eine Ausnahme von diesem
System stellen einzelne Pilotprojekte dar, die den Schwerpunkt auf rein nationale bzw.
europäische Cloud-Lösungen1 setzen sowie Dienste, die auf ein spezielles Kundenprofil
zugeschnitten sind.2 Im Falle grenzüberschreitender Sachverhalte stellt sich die Frage, welches
nationale Recht zur Anwendung gelangt. Dies bestimmt sich im vertraglichen Bereich
grundsätzlich nach den Kollisionsnormen der Rom I-Verordnung.3
2.1.1.1 Grundsätzliche Anknüpfung
Sofern in den Vertrag keine Rechtswahlvereinbarung aufgenommen wurde, ist Art. 4 Rom I-VO
die maßgebliche Kollisionsnorm.4 Hiernach ist grundsätzlich auf den gewöhnlichen Aufenthaltsort
der die vertragscharakteristische Leistung erbringenden Partei abzustellen. Dies gilt unabhängig
davon, ob man die zugrunde liegende Cloud-Vereinbarung als Dienstleistungsvertrag i.S.d. Art. 4
Abs. 1 lit. b) Rom I-VO einordnet oder die Generalklausel des Abs. 2 anwendet.5 Da diese
Leistung vom Cloud-Anbieter erbracht wird, führt die objektive Anknüpfung jedenfalls zur
Anwendung des nationalen Rechts am Sitz des Cloud-Anbieters.6
2.1.1.2 Rechtswahl
Art. 3 Abs. 1 S. 1 Rom I-VO erlaubt den Parteien grundsätzlich auch die Auswahl des
anzuwendenden Rechts. Bei Standardverträgen – welche beim Cloud Computing regelmäßig
vorliegen7 – wird die Rechtswahl meist vom jeweiligen Cloud-Anbieter vorgenommen.8
2.1.1.3 Verbraucherbeteiligung
Besonderheiten gelten für den Vertragsschluss mit einem Verbraucher, wenn der Cloud-Anbieter
seine Tätigkeit in dem Staat ausübt, in dem der Verbraucher seinen gewöhnlichen Aufenthalt hat
oder die Tätigkeit zumindest auf diesen Staat ausgerichtet ist. Angesichts der Ubiquität des
Internets ist das Merkmal des Ausrichtens äußerst schwer zu beurteilen und wird vielfach
diskutiert. Die bloße Zugänglichkeit einer Website über das Internet reicht noch nicht für eine
Ausrichtung auf den Verbraucherstaat aus.9 Vielmehr müssen im Einzelfall weitere Anhaltspunkte
vorliegen, aus denen sich auf den Willen, mit Verbrauchern eines bestimmten Zielstaats in
Geschäftsbeziehung zu treten, schließen lässt – potenzielle Kriterien sind beispielsweise die
Nutzung einer (landesspezifischen) Top-Level-Domain, die Art der Dienstleistung oder die
Vorhaltung spezieller Informationen.10
Liegen diese Voraussetzungen vor, unterliegt der Vertrag dem Recht am gewöhnlichen
Aufenthaltsort des Verbrauchers zum Zeitpunkt des Vertragsschlusses (Art. 6 Abs. 1 Rom I-VO).
Eine Rechtswahlvereinbarung bleibt jedoch ausweislich des Art. 6 Abs. 2 S. 1 Rom I-VO
grundsätzlich auch in diesem Fall möglich.11 Wird ein anderes Recht als das nach der objektiven
Anknüpfung gemäß Art. 6 Abs. 1 Rom I-VO anzuwendende Recht gewählt, gilt indes gemäß Art. 6
Abs. 2 Rom I-VO das Günstigkeitsprinzip: Insoweit es für den Verbraucher günstiger ist, findet
jedenfalls das zwingende Recht am Aufenthaltsort des Verbrauchers Anwendung.12 Bei der
Bewertung der Günstigkeit ist auf das jeweilige Begehren des Verbrauchers abzustellen; ein
Gesamtvergleich der Rechtsordnungen ist insofern nicht geboten.13

2.1.2 Vertragstypologie
Zur weiteren Eingrenzung der maßgeblichen vertragsrechtlichen Normen ist sodann die
vertragstypologische Einordnung der Cloud-Vereinbarung vorzunehmen. Deren wesentliche
Bedeutung besteht darin, dass sich hiernach das anwendbare vertragliche Haftungsregime
bestimmt.
2.1.2.1 Grundsatz
Eine sachgerechte vertragstypologische Einordnung lässt sich nur am Maßstab der konkret
vereinbarten vertraglichen Leistung vornehmen.14 Typischerweise werden im Rahmen eines Cloud
Computing-Dienstes mehrere unterschiedliche Leistungen erbracht, sodass die singuläre
Zuordnung zu einem einzelnen gesetzlich geregelten Vertragstyp nicht möglich ist – Verträge über
die Erbringung von Cloud-Diensten sind vielmehr im Regelfall als typengemischte Verträge
anzusehen.15 Sodann findet nach herrschender Auffassung auf jede separat zu beurteilende
Einzelleistung dasjenige Vertragsrecht Anwendung, das der diesbezüglichen
vertragstypologischen Klassifizierung entspricht – sofern nicht der Schwerpunkt des Vertrags
ersichtlich in einem der tangierten Bereiche liegt.16
2.1.2.2 Hauptleistungspflichten
Das Wesen des Cloud Computing liegt in der zeitweiligen, bedarfsabhängigen Bereitstellung von
Hardware und/oder Software gegen Entgelt.17 Entsprechend handelt es sich nach überwiegender
Auffassung um einen typengemischten Vertrag mit überwiegendem mietvertraglichen Element.18
Auch der BGH hat im Falle des Application-Service-Providing (ASP), welches Parallelen zum
Cloud Computing in der Form des Software-as-a-Service (SaaS)19 aufweist,20 die Anwendung
von Mietvertragsrecht bejaht.21 Daher wird im Rahmen des SaaS stets ein wesentlicher
mietrechtlicher Schwerpunkt22 bzw. im Fall der unentgeltlichen Bereitstellung der Cloud-Leistung
eine Leihe anzunehmen sein.23 Vereinzelt wird sowohl eine direkte als auch eine analoge
Anwendbarkeit des Mietrechts abgelehnt; vielmehr sei grundsätzlich von einem Dienstvertrag
auszugehen.24
Teilweise wird dem Cloud Computing, wenn es um Infrastructure-as-a-Service (IaaS)25 in
Form der Zurverfügungstellung von Rechenleistung geht, ein dienstvertraglicher Charakter
zugeordnet.26 Dies kann jedenfalls dann nicht überzeugen, wenn etwa im Rahmen von Storage-as-
a-Service-Angeboten27 die bloße Bereitstellung von Speicherplatz gegen Entgelt vereinbart wird.
Denn auch hier liegt der Schwerpunkt der Vereinbarung eindeutig im mietvertraglichen Bereich.28
Gleiches gilt i. E. für Platform-as-a-Service (PaaS)29.30
2.1.2.3 Zusatzvereinbarungen
Wie dargestellt, beinhaltet ein Cloud-Vertrag indes oftmals zahlreiche weitere
Detailvereinbarungen. Soweit hierbei die Installation, Anpassung oder Implementierung von
Software geschuldet wird, handelt es sich um einen Werkvertrag i.S.d. § 631 BGB.31 Die
Schulung des Cloud-Nutzers im Umgang mit der jeweiligen Plattform hat dagegen überwiegend
dienstvertraglichen Charakter.32 Entsprechend der oben dargestellten Herangehensweise bei
typengemischten Verträgen33 finden auf diese Vertragsteile daher grundsätzlich die jeweils
korrespondierenden vertraglichen Regelungen Anwendung.
2.1.2.4 Bedeutung von SLA
Eine besondere Bedeutung kommt der Ausgestaltung der zwischen Cloud-Anbieter und Cloud-
Nutzer getroffenen Nutzungsvereinbarung in sogenannten Service-Level-Agreements (SLA) zu.
Diese enthalten typischerweise Ausführungen zur Leistungsbeschreibung und zu Haftungsfragen;
sind aber u. U. auch bereits für die vertragstypologische Einordnung von Relevanz.34 Denn auch
aus den SLA kann sich im Einzelfall ein Überwiegen von werk- oder dienstvertraglichen
Elementen ergeben.

2.1.3 Pflichten des Cloud-Anbieters


Die Pflichtverletzung ist zentrale Voraussetzung der vertraglichen Haftung auf Schadensersatz
nach § 280 Abs. 1 S. 1 BGB. Aufseiten des Cloud-Anbieters steht eine solche in den hier
interessierenden Schädigungsszenarien insbesondere dann im Raum, wenn es aufgrund der
Ausgestaltung der Authentisierungssysteme und der diese umgebenden IT-Infrastruktur einem
Drittschädiger möglich war, auf die fraglichen Datensätze zuzugreifen. Es stellt sich dann die
Frage, ob der Cloud-Anbieter weitergehende Sicherheitsmaßnahmen hätte ergreifen müssen, um
diesen unbefugten Zugriff zu verhindern.
Mitunter sind Pflichten zur Ergreifung konkreter Sicherheitsmaßnahmen in SLA geregelt.35 Bei
der in Cloud-Diensten erfolgenden Identifizierung besteht die Notwendigkeit zur Sicherung der
Identifizierungsinfrastruktur seitens des Cloud-Anbieters jedoch auch dann, wenn es an einer
diesbezüglichen Vereinbarung fehlt. Denn gemäß § 241 Abs. 2 BGB beinhaltet ein Vertrag stets
neben den jeweiligen Hauptleistungspflichten auch Schutzpflichten zur Rücksichtnahme auf die
sonstigen Rechtsgüter des Vertragspartners.36 Wie umfangreich die Sicherungsmaßnahmen
inhaltlich ausfallen müssen, lässt sich nicht pauschal beantworten, sondern nur auf Grundlage
einer dezidierten Risikoanalyse im Einzelfall.37 Denn der Schutzbedarf kann je nach Ausgestaltung
der konkreten Umsetzungsszenarien erheblich variieren. In diesem Rahmen ist anerkannt, dass der
Betreiber einer Online-Plattform dafür Sorge tragen muss, dass die Daten seiner Nutzer
angemessen gegen unbefugte Zugriffe von außen abgesichert sind.38 Insoweit kommt insbesondere,
einen entsprechenden Schutzbedarf vorausgesetzt, eine Pflicht zur Implementierung hinreichend
sicherer Authentifizierungsmechanismen in Betracht.39
Hat ein Identitätsmissbrauch stattgefunden, so muss der Cloud-Anbieter dafür Sorge tragen,
weitere Angriffe zu vermeiden. Der BGH hatte sich bereits mit dem Umfang der diesbezüglichen
Verkehrspflichten im Rahmen der Online-Plattform eBay zu befassen, wo ein Nutzer die unbefugte
Erstellung eines Accounts mit seinem Namen angemahnt hatte.40 Grundlegend bleibt festzuhalten,
dass dem Plattformbetreiber jedenfalls nicht zuzumuten ist, präventiv sämtliche eingestellten
Angebote auf potenzielle Rechtsverletzungen hin zu überprüfen, da dies angesichts der extrem
zahlreichen Neueinstellungen schlicht nicht mit wirtschaftlich vertretbarem Aufwand zu leisten
wäre.41

2.1.4 Pflichten des Cloud-Nutzers


Während der Cloud-Anbieter auf der einen Seite aus § 241 Abs. 2 BGB zur Sicherung der
Identifizierungsinfrastruktur verpflichtet ist, ist der Cloud-Nutzer spiegelbildlich zur Absicherung
des eigenen Anwendungsbeitrags verpflichtet.42 Er muss also hinsichtlich des nutzergesteuerten
Parts des Identifizierungsvorgangs gewährleisten, dass dieser ordnungsgemäß abläuft. Dies
impliziert, insbesondere dafür Sorge zu tragen, dass das vom Anbieter vergebene
Authentifizierungsmittel nicht in falsche Hände gerät.43 Hierdurch wird indes nicht nur die aktive
Weitergabe untersagt – der Nutzer muss vielmehr grundsätzlich auch Schutzvorkehrungen gegen
die heimliche Ausspähung der Daten durch Dritte treffen.44

2.1.5 Allgemeine Geschäftsbedingungen (AGB)


Verträge über Cloud Computing unterliegen, soweit sie unter Zugrundelegung eines
Standardvertrags geschlossen werden, der AGB-Kontrolle nach den §§ 305 ff. BGB. Die bereits
thematisierte vertragstypologische Einordnung45 der Cloud-Vereinbarung wird im Rahmen der
AGB-Kontrolle abermals relevant, soweit sie das gesetzliche Leitbild für die Beurteilung der
Zulässigkeit von Klauseln bestimmt46 und somit den Rahmen einer möglicherweise
unangemessenen Benachteiligung i.S.d. § 307 BGB vorgibt.47

2.1.5.1 Begriff und wirksame Einbeziehung


Gemäß § 305 Abs. 1 S. 1 BGB sind AGB für eine Vielzahl von Verträgen vorformulierte
Vertragsbedingungen, deren Zugrundelegung von einer Vertragspartei angestrebt wird.
Maßgeblich ist indes nicht die tatsächliche Art der Verwendung, sondern die Absicht des
Erstellers. Es genügt mithin, wenn dieser die Vertragsbedingungen für die mehrfache Verwendung
vorgesehen hat.48 Außerdem impliziert das Merkmal des „Stellens“ durch eine Vertragspartei,
dass die AGB dem Kunden einseitig auferlegt worden sein müssten.49
Die AGB werden gemäß § 305 Abs. 2 BGB nur dann Vertragsbestandteil, wenn der
verwendende Vertragspartner ausdrücklich auf die beabsichtigte Einbeziehung hingewiesen und
dem anderen Teil die Möglichkeit zur inhaltlichen Kenntnisnahme verschafft hat. Im Bereich des
Cloud Computing wird der Vertragsschluss im Regelfall online erfolgen. In diesem Rahmen
genügt es, wenn ein deutlicher Hinweis auf die AGB an einer Stelle platziert wird, die der Nutzer
nur schwerlich übersehen kann.50 Der Text der Bedingungen selbst wird dann typischerweise über
einen Link abgerufen werden können.51
2.1.5.2 Zulässigkeitsgrenzen
Aus Verbraucherschutzgesichtspunkten ist die Regelungsfreiheit in AGB nicht unbegrenzt.
Vielmehr sehen die §§ 305 ff. BGB ausdifferenzierte Zulässigkeitsgrenzen für deren Ausgestaltung
vor. Zunächst dürfen gemäß § 305 c Abs. 1 BGB keine sog. überraschenden Klauseln enthalten
sein, mit denen der Vertragspartner vernünftigerweise nicht hätte rechnen können.52 Dies soll
verhindern, dass dem Kunden im Rahmen des „Kleingedruckten“ heimlich außergewöhnliche
Belastungen auferlegt werden. Die §§ 308, 309 BGB enthalten konkrete Klauselverbote, die zum
Schutz des anderen Vertragsteils bestimmte Vereinbarungen in AGB grundsätzlich untersagen.
Ausweislich § 310 Abs. 1 S. 1 BGB finden diese Beschränkungen unmittelbar indes nur
Anwendung bei Verträgen mit Verbrauchern.53
Schließlich untersagt die Generalklausel des § 307 Abs. 1 BGB generell die unangemessene
Benachteiligung des anderen Vertragsteils. Von einer solchen ist auszugehen, wenn der Verwender
missbräuchlich eigene Interessen auf Kosten des Vertragspartners durchzusetzen versucht, ohne
dessen Interessen hinreichend zu berücksichtigen.54 Wann dies der Fall ist, lässt sich letztlich nur
anhand einer fundierten Prüfung des jeweiligen Einzelfalls unter Berücksichtigung der
Fallgruppenbildung in der Rechtsprechung55 beantworten. Es existieren einige Spezialklauseln,
die typischerweise im Umfeld des Identitätsmanagements Verwendung finden. Im Rahmen des
sechsten Kapitels wird die Vereinbarkeit dieser Vertragsbedingungen mit den oben dargestellten
Grundsätzen im Detail untersucht.56

2.1.6 Einschaltung von Unterauftragnehmern


In der Praxis kommt es häufig vor, dass der Cloud-Anbieter sich bei der Erbringung der über die
Cloud abrufbaren Leistung der Unterstützung Dritter bedient, um etwa die benötigte IT-
Infrastruktur nicht selbst vorhalten zu müssen. Es stellt sich dann die Frage, wie sich dies auf die
Verantwortlichkeiten auswirkt. Der eingeschaltete Subunternehmer wird im Regelfall als
Erfüllungsgehilfe des Cloud-Anbieters i.S.d. § 278 S. 1 BGB einzuordnen sein.57
Dementsprechend muss der Anbieter sich schuldhafte Pflichtverletzungen des Unterauftragnehmers
dergestalt zurechnen lassen, als hätte er diese selbst begangen.58

2.2 Deliktsrecht
Unabhängig davon, dass zwischen Cloud-Nutzer und Cloud-Anbieter eine vertragliche
Vereinbarung besteht, ergeben sich Pflichten hinsichtlich des Identitätsmanagements auch aus dem
Deliktsrecht. Da eine vertragliche Verbindung zwischen Schädiger und Geschädigtem insofern
gerade nicht erforderlich ist, werden die hier zu erörternden Anspruchsgrundlagen v. a. relevant,
sofern Angriffe auf das Identitätsmanagement von außenstehenden Dritten ausgehen. Aber auch im
Verhältnis zum Cloud-Nutzer können sich aufgrund der bestehenden Anspruchskonkurrenz59
grundsätzlich deliktische Ansprüche ergeben.

2.2.1 Anwendbares Recht


Wie im vertragsrechtlichen Bereich60 stellt sich aufgrund des grenzüberschreitenden Charakters
des Cloud Computing auch hinsichtlich der deliktischen Haftung zunächst die Frage des
anwendbaren Rechts. Im Falle einer Schädigung durch unerlaubte Handlung sind für dessen
Ermittlung grundsätzlich die Normen der Rom II-Verordnung61 maßgeblich. Durch das Fehlen
einer vertraglichen Vereinbarung als potenzieller Anknüpfungspunkt gestaltet sich die Bestimmung
hier i. E. deutlich schwieriger.
2.2.1.1 Rechtswahl
Art. 14 Abs. 1 Rom II-VO erlaubt auch im Bereich der deliktischen Haftung grundsätzlich eine
Rechtswahl. Allerdings sind insofern relativ strenge Anforderungen zu beachten: Gemäß Art. 14
Abs. 1 lit. a, b Rom II-VO muss die Vereinbarung entweder erst nach Eintritt des schädigenden
Ereignisses oder alternativ62 zwischen zwei Unternehmen abgeschlossen worden sein.63 Eine
bereits bei Vertragsschluss vorgenommene Rechtswahl wäre folglich gegenüber einem
Verbraucher unzulässig. Zudem kann die Rechtswahl ohnehin nicht außenstehende Dritte als
potenzielle Schädiger unmittelbar betreffen.
2.2.1.2 Objektive Anknüpfung
Gemäß Art. 4 Abs. 1 Rom II-VO dient als grundlegender Anknüpfungspunkt der Ort des
Schadenseintritts. Im Rahmen der über das Internet erfolgenden Datenverarbeitung stellt sich
zunächst die Frage, wo dieser Ort befindlich ist. Denn es liegt gerade im Wesen einer Cloud-
Leistung, dass sie grundsätzlich ortsungebunden von jedem erdenklichen Standort aus abgerufen
werden kann, an dem eine Internetanbindung besteht. Hinzu kommt, dass bei der Beschädigung von
Daten in der Cloud die Lokalisation des Belegenheitsorts der Daten im Zugriffszeitpunkt in der
Praxis häufig schwierig sein wird, weil wechselnde Server in verschiedenen Staaten bei der
Datenspeicherung zum Einsatz kommen können.64
Ein vorstellbares Schadensszenario ist insbesondere, dass es aufgrund mangelhafter
Absicherung des Identitätsmanagements zum Verlust oder der Ausspähung von Nutzerdaten in der
Cloud kommt.65 Es kann in dieser Konstellation letztlich für die Bestimmung des
Schadenseintrittsorts nur maßgeblich sein, wo sich die betroffenen Daten zum
Einwirkungszeitpunkt befanden66 – denn dies entspricht dem Ort, an dem sich der Verlust der
Daten und mithin der Eintritt des hier interessierenden Schadenspostens realisiert hat. Das
Abstellen auf den Ort, von dem die Daten abgerufen werden, kann dagegen nicht überzeugen, da
dies, wie dargestellt, im Rahmen des Cloud Computing naturgemäß gerade von jedem beliebigen
Ort aus erfolgen kann.67
Aufgrund der geschilderten praktischen Schwierigkeiten, die diese Art der objektiven
Anknüpfung im Bereich des Cloud Computing mit sich bringt, wird in der Literatur über einen
alternativen Lösungsansatz nachgedacht: Durch Anwendung der Ausweichklausel des Art. 4 Abs.
3 S. 2 Rom II-VO soll das der Cloud-Vereinbarung zuzuordnende Vertragsstatut68 auch in diesem
Kontext Anwendung finden.69 In der Folge wäre auch im Rahmen deliktischer
Anspruchsgrundlagen für die Bestimmung des territorial anwendbaren Rechts regelmäßig der Sitz
des Cloud-Anbieters maßgeblich, der die vertragscharakteristische Leistung erbringt. Die
Besonderheiten der Cloud lassen eine derart vereinheitlichende Betrachtungsweise als durchaus
sachgerecht erscheinen – wenngleich der dogmatische Ansatz über die Kopplung an das
Vertragsstatut erheblichen Zweifeln ausgesetzt bleibt, da der Schädiger an der in Rede stehenden
Vereinbarung letztlich überhaupt nicht beteiligt war. Überzeugender erscheint es daher, nach Art.
4 Abs. 3 S. 1 Rom II-VO an den Verwaltungssitz, respektive gewöhnlichen Aufenthaltsort, des
Dateninhabers anzuknüpfen.70
2.2.1.3 Sonderfall: Verletzungen des allgemeinen Persönlichkeitsrechts
Nach Art. 1 Abs. 2 lit. g Rom II-VO findet die Rom II-Verordnung keine Anwendung auf
Verletzungen der Privatsphäre und des Persönlichkeitsrechts, welche für das Identitätsmanagement
grundsätzlich besonders bedeutsam sind. Hier greift vielmehr die nationale Kollisionsnorm des
Art. 40 EGBGB. Nach Art. 40 Abs. 1 S. 1 EGBGB ist grundsätzlich dasjenige nationale Recht
anzuwenden, welches an dem Ort gilt, an dem die deliktische Handlung begangen wurde. Gemäß
Art. 40 Abs. 1 S. 2 EGBGB kann jedoch der Geschädigte ein Bestimmungsrecht ausüben, durch
das er die Anwendung des Erfolgsortsrechts erzwingt.71

2.2.2 Anspruchsgrundlagen
Im Rahmen der deliktischen Haftung fehlt es, wie gesehen,72 gerade an einer vertraglichen
Beziehung zwischen Schädiger und Geschädigtem, die Grundlage für eine Schadensersatzhaftung
sein könnte. Dementsprechend ist insofern auf den hiervon unabhängigen Katalog deliktischer
Anspruchsgrundlagen zurückzugreifen. Die zentrale deliktische Haftungsgrundlage ist § 823 Abs. 1
BGB. Diese Norm setzt jedoch auf Tatbestandsebene die Verletzung eines der in Abs. 1
enumerativ aufgezählten Rechtsgüter voraus.73
Im Zusammenhang mit dem Umgang mit Identitäten kommt insofern insbesondere das
Namensrecht aus § 12 BGB infrage, welches grundsätzlich als „sonstiges Recht“ i.S.d. § 823 Abs.
1 BGB anerkannt ist.74 Der Name hat im Wesentlichen die Funktion, die Identität einer Person zu
kennzeichnen.75 Namensschutz bedeutet dementsprechend primär Schutz der Identität.76 Der
Namensträger wird in diesem Rahmen insbesondere vor der unbefugten Verwendung seines
Namens durch Dritte geschützt.77 Handelt ein Dritter unbefugt in seinem Namen, kann er sich
folglich im Rahmen des § 823 Abs. 1 BGB um Ersatz des hieraus resultierenden Schadens
bemühen. Allerdings erscheint es wenig wahrscheinlich, dass der Betreiber einer Cloud-Plattform
Handlungen unter falschem Namen vornimmt und so das Namensrecht seiner Nutzer verletzt –
wesentlich naheliegender scheint dagegen, dass außenstehende Dritte so vorgehen, die irgendwie
an die Authentifizierungsdaten des Nutzers gekommen sind und nunmehr zum eigenen Vorteil
hiermit Missbrauch betreiben wollen. Hieraus kann wiederum nur dann ein Vorwurf gegenüber
dem Plattformbetreiber hergeleitet werden, wenn dieser das schädigende Drittverhalten hätte
verhindern können und müssen. Fraglich ist also in diesem Szenario insbesondere, ob der
Anbieter eine Verkehrspflicht verletzt hat.78 Für den Nutzer wird dies typischerweise von großer
praktischer Relevanz sein, da der Drittschädiger im Regelfall nicht ermittelt werden kann.
Neben einer Verletzung des Namensrechts kommt noch die Verletzung weiterer Rechtsgüter in
Betracht, welche nach § 823 Abs. 1 BGB schutzfähig sind. In dem oben beschriebenen Szenario
der Zugriffsverhinderung79 kann etwa ein Eingriff in das Recht des eingerichteten und ausgeübten
Gewerbebetriebs vorliegen, wenn der Angriff gezielt gegen Betriebsabläufe des betroffenen
Unternehmens gerichtet ist.80 Wird vorsätzlich ein Datenbestand ausgespäht, verändert oder
gelöscht, so begründet dies eine Strafbarkeit des Angreifers nach den §§ 202a, 303a StGB. Da
diese Schutzgesetze darstellen,81 ergibt sich dadurch ein korrespondierender
Schadensersatzanspruch aus § 823 Abs. 2 BGB. In der Literatur wird teils auch ein Recht am
eigenen Datenbestand im Sinne eines sonstigen Rechts nach § 823 Abs. 1 BGB anerkannt.82
Ebenso wie im Falle der Namensverletzung gilt in diesen Fällen, dass die Rechtsverletzung zwar
durch den Angreifer verursacht wurde, eine Haftung des Cloud-Anbieters oder auch des Cloud-
Nutzers jedoch in Betracht kommt, soweit diese ihre gegenüber Dritten obliegenden
Verkehrspflichten verletzt haben.

2.2.3 Verkehrspflichten
Grundvoraussetzung der deliktischen Haftung ist eine Verhaltensweise bzw. ein entsprechendes
Unterlassen des Schädigers, das als Anknüpfungspunkt für Ersatzansprüche des Geschädigten
dienen kann.83 Ausgangspunkt von Schäden beim cloudbasierten Identitätsmanagement ist, wie
dargestellt,84 insbesondere die unzureichende Sicherung der Infrastruktur gegen Eingriffe von
außen.85 Im Zentrum der Haftungsbegründung steht somit ein Unterlassen, welches nur unter der
weiteren Voraussetzung der Verletzung einer Verkehrspflicht einen deliktischen
Haftungstatbestand im Rahmen des § 823 Abs. 1 BGB begründen kann.86 Bei der Sicherung der
zum Einsatz gebrachten IT-Infrastruktur handelt es sich grundsätzlich um eine Verkehrspflicht.
Diese trifft sowohl den Cloud-Anbieter in Form der Sicherung der zur Verfügung gestellten
Authentifizierungsinstrumente87 als auch den Nutzer hinsichtlich der Sicherung der genutzten
Authentifizierungsmedien (bspw. Passwort oder Hardware Token).88
Die Verkehrspflichten im Bereich des Deliktsrechts entsprechen inhaltlich im Wesentlichen
den Schutzpflichten, die § 241 Abs. 2 BGB für die vertragliche Haftung statuiert.89 Entsprechend
gelten die Anforderungen, die § 241 Abs. 2 BGB im vertraglichen Bereich hinsichtlich der
Sicherung der Infrastruktur an den Cloud-Anbieter stellt,90 auch im Rahmen der deliktischen
Haftung. Auch die Verkehrspflichten des Cloud-Nutzers sind – so man vom Bestehen von
Verkehrspflichten für private Nutzer ausgeht91 – insofern deckungsgleich mit seinen vertraglichen
Schutzpflichten. Dies führt letztlich zu einem Gleichlauf der sicherheitsrechtlichen Anforderungen
an cloudbasiertes Identitätsmanagement im vertraglichen und deliktischen Bereich.

3 TMG
Durch das IT-Sicherheitsgesetz von 2015 wurden geschäftsmäßigen Anbietern von Telemedien
nach § 13 Abs. 7 TMG verschiedene Pflichten im Bereich der IT-Sicherheit auferlegt. Diese
haben, soweit dies technisch möglich und wirtschaftlich zumutbar ist, im Rahmen ihrer jeweiligen
Verantwortlichkeit für geschäftsmäßig angebotene Telemedien durch technische und
organisatorische Vorkehrungen sicherzustellen, dass kein unerlaubter Zugriff auf die für ihre
Telemedienangebote genutzten technischen Einrichtungen möglich ist und diese gegen
Verletzungen des Schutzes personenbezogener Daten und gegen Störungen, auch soweit sie durch
äußere Angriffe bedingt sind, gesichert sind. Nach § 13 Abs. 7 S. 2 TMG haben entsprechende
Maßnahmen den Stand der Technik zu berücksichtigen. § 13 Abs. 7 S. 3 TMG bestimmt, dass eine
Maßnahme zur Gewährung von IT-Sicherheit insbesondere der Einsatz eines als sicher
anerkannten Verschlüsselungssystems darstellt. Die datenschutzrechtlichen Pflichten nach TMG
werden unten92 dargestellt.

3.1 Anwendungsbereich
Die Pflicht nach § 13 Abs. 7 TMG richtet sich an Diensteanbieter, welche geschäftsmäßig
angebotene Telemedien betreiben. Am Kriterium der Geschäftsmäßigkeit besteht bei den in aller
Regel mit Gewinnerzielungsabsicht betriebenen Cloud-Diensten oftmals kein Zweifel.
Telemedien sind nach der Definition des § 1 Abs. 1 TMG elektronische Informations- und
Kommunikationsdienste, soweit sie nicht nach § 3 Nr. 24, 25 TKG dem TKG unterfallen oder als
Rundfunk nach § 2 des Rundfunkstaatsvertrages einzuordnen sind. Nach § 2 S. 1 Nr. 1 TMG ist
Anbieter dieser Dienste, wer eigene oder fremde Telemedien zur Nutzung bereithält oder den
Zugang zur Nutzung vermittelt. Der Begriff der Telemedien ist weit auszulegen93 und umfasst
grundsätzlich die unterschiedlichsten Formen von Internet-Angeboten, wie Online-Shops,94
Suchmaschinen95 oder Foren zum Meinungsaustausch.96 Ob ein Entgelt für die Nutzung anfällt, ist
insofern unerheblich.97 In der Praxis unterfallen eine Vielzahl von Cloud Computing-Diensten als
Anbieter von Informations- bzw. Kommunikationsdiensten den Vorschriften des TMG.98 Dies gilt
bereits deshalb, weil Cloud-Anwendungen regelmäßig über ein Web-Interface nutzbar sind,
welches sich nicht wesentlich von herkömmlichen Websites unterscheidet.99 Bezweifelt wird die
Anwendbarkeit des TMG in der Literatur vor allem in Bezug auf IaaS-Dienste,100 jedenfalls
sofern diese auf eine solche Funktionalität verzichten.101 Unterfällt der Cloud-Dienst nicht dem
TMG, richten sich die Pflichten des Anbieters nach den allgemeinen Vorschriften.
3.2 Vorgaben an das Identitätsmanagement
Welche konkreten Pflichten sich aus § 13 Abs. 7 TMG ergeben und insbesondere, ob und
inwieweit diese von den bisher anerkannten Pflichten abweichen, ist bisher noch kaum
Gegenstand rechtswissenschaftlicher Erörterung gewesen. Für die hiesige Untersuchung ist
insbesondere relevant, ob sich eine Verpflichtung zum Einsatz eines sicheren
Authentifizierungsverfahrens ergibt. Dies wird im Rahmen von Kap.​ 6 näher erläutert. Die
Auslegung des § 13 Abs. 7 TMG ist auch für die Haftung aufgrund ungeschriebener
Verkehrspflichten von Bedeutung. Spezialgesetzliche Pflichten zur IT-Sicherheit können die
Verkehrspflichten beeinflussen.102 So ist anerkannt, dass gesetzliche Verhaltenspflichten
jedenfalls einen Mindeststandard für deliktische Verkehrspflichten begründen.103 Zudem wird §
13 Abs. 7 TMG auch als Schutzgesetz gesehen.104 Ein Verstoß gegen § 13 Abs. 7 TMG begründet
nach dieser Ansicht somit einen Schadensersatzanspruch gem. § 823 Abs. 2 BGB.
Anders als die ungeschriebenen vertraglichen und deliktischen Pflichten kann ein Verstoß
gegen § 13 Abs. 7 Nr. 1 TMG als Ordnungswidrigkeit nach § 16 Abs. 2 Nr. 3 TMG mit einer
Geldbuße von bis zu 50.000 € geahndet werden. § 13 Abs. 7 TMG setzt somit neben möglichen
Haftungsrisiken einen weiteren Anreiz zur Herstellung ausreichender IT-Sicherheit.

4 eIDAS-Verordnung
Neuerungen auf dem Gebiet des Identitätsmanagements könnten sich durch die Verordnung (EU)
Nr. 910/2014 des Europäischen Parlaments und des Rates über elektronische Identifizierung und
Vertrauensdienste für elektronische Transaktionen im Binnenmarkt (eIDAS-VO) ergeben. Diese
ist am 17.09.2014 in Kraft getreten und entfaltet seit dem 01.07.2016 materielle Wirkung.105
Die eIDAS-VO regelt vor allem die Anerkennung ausländischer elektronischer
Identifizierungsdienste zur Authentifizierung für öffentliche Dienste. So soll etwa die eID-
Funktion des deutschen Personalausweises auch in anderen Mitgliedstaaten nutzbar sein. Welche
Bedeutung die Vorschriften für die Identifizierung im privaten Bereich haben werden, ist derzeit
kaum einzuschätzen.106 Auswirkungen auf das Identitätsmanagement im Cloud Computing sind
derzeit jedoch nicht abzusehen. Daneben trifft die eIDAS-VO auch Regelungen in Bezug auf
elektronische Signaturen. Da diese bisher nur eine geringe Verbreitung in der Praxis aufweisen,107
dürfte die Bedeutung auch insoweit vernachlässigbar sein.

5 Datenschutzrecht
Im Rahmen des Identitätsmanagements in der Cloud erfolgt in vielerlei Hinsicht Umgang mit
personenbezogenen Daten. Die rechtlichen Rahmenbedingungen hierfür ergeben sich aus dem
Datenschutzrecht, das maßgeblich im Bundesdatenschutzgesetz (BDSG) kodifiziert worden ist.
Ausweislich des § 1 dient das BDSG dem Schutz vor der Beeinträchtigung des
Persönlichkeitsrechts des Einzelnen durch den Umgang mit seinen personenbezogenen Daten.
Kernelement des Datenschutzrechts ist das sog. „Verbot mit Erlaubnisvorbehalt“. Dieses in § 4
Abs. 1 BDSG kodifizierte Prinzip besagt, dass jede Verarbeitung personenbezogener Daten einer
gesetzlichen Grundlage bedarf.
Das europäische Datenschutzrecht befindet sich derzeit im Umbruch. Am 14. April 2016 hat
das EU-Parlament nach einer intensiven rechtspolitischen Diskussion die Datenschutz-
Grundverordnung (DSGVO)108 verabschiedet, die nach ihrem Art. 91 Abs. 1 ab dem 25. Mai
2018 gilt. Als Verordnung ist die DSGVO unmittelbar anwendbar und bedarf keines
mitgliedstaatlichen Umsetzungsakts. Die DSGVO ersetzt die Datenschutzrichtlinie (DS-RL)109 und
verdrängt damit auch das in weiten Teilen auf dieser aufsetzende BDSG. Die DSGVO enthält
Öffnungsklauseln für mitgliedstaatliche Regelungen, die in Deutschland durch ein neugefasstes
Bundesdatenschutzgesetz (BDSG) umgesetzt werden, welches ebenfalls am 25. Mai 2018 in Kraft
treten wird.110

5.1 Verarbeitung personenbezogener Daten


5.1.1 Begrifflichkeit
§ 3 Abs. 1 BDSG definiert das personenbezogene Datum als Einzelangabe über persönliche oder
sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person. Entscheidend ist,
dass eine Information betroffen ist, die es erlaubt, den Bezug zu einer konkreten Person
herzustellen.111 Dies kann sowohl Angaben über die Person selbst als auch über diese lediglich
mittelbar betreffende Sachverhalte umfassen.112 Nach h.M. – dem sogenannten „relativen
Personenbezug“ – ist dabei auf die Möglichkeiten zur Identifizierung des Betroffenen aus Sicht der
datenverarbeitenden Stelle abzustellen.113 Sofern der Betroffene identifizierbar ist, bedarf es für
jeden Umgang mit dessen Daten – z. B. Erhebung, Speicherung oder Übermittlung – einer
Erlaubnisnorm.
Dieses Verbot mit Erlaubnisvorbehalt findet sich nunmehr in Art. 5 Abs. 1 lit. a und Art. 6
Abs. 1 DSGVO. Ähnlich wie § 3 Abs. 1 BDSG definiert Art. 4 Nr. 1 DSGVO personenbezogene
Daten als alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche
Person beziehen. Ergänzt wird die Definition um eine Aufzählung von
Identifizierungsmöglichkeiten, etwa die Zuordnung zu einem Namen, einer Online-Kennung oder
anderen Merkmalen, die Ausdruck der Identität des Betroffenen sind. Die Änderung der
Formulierung führt jedoch zu keinen inhaltlichen Auswirkungen.

5.1.2 Relevanz für das Management von Identitäten


Wie bereits dargelegt114 handelt es sich bei einer Identität im Wesentlichen um die Summe der
Informationen über eine Entität, welche erforderlich sind, um diese eindeutig identifizieren zu
können. Diese Einzelangaben, die in ihrer Gesamtheit die Identität des Einzelnen ausmachen,
stellen – Personenbeziehbarkeit vorausgesetzt – sämtlich personenbezogene Daten dar.115
Dementsprechend sind im Rahmen des Identitätsmanagements typischerweise personenbezogene
Daten in großem Ausmaß betroffen.116

5.1.3 Sonderfall: IP-Adressen


Im Umfeld von Online-Lösungen stellt sich die zusätzliche Besonderheit, dass Anknüpfungspunkte
für die Herleitung der Identität nicht nur aus der Verwendung des jeweiligen
Authentifizierungsmediums, sondern auch aus der IP-Adresse des konkreten Nutzers folgen.
Fraglich ist dementsprechend, ob es sich auch hierbei um ein personenbezogenes Datum handelt.
Die IP-Adresse dient der Identifikation desjenigen Rechners, der online eine Anfrage an eine
Website o. ä. stellt.117 Dabei wird zwischen dynamischen und statischen IP-Adressen
differenziert: Während erstere dem Nutzer im Laufe des Einwahlvorgangs jeweils neu zugewiesen
werden, zeichnen sich letztere durch eine mehr oder weniger konstante Zuweisung zu einem
konkreten Endnutzer aus.118
Der Personenbezug von dynamischen IP-Adressen ist umstritten. Zum Teil wird der
Personenbezug im Verhältnis zum Plattformbetreiber abgelehnt, da bei Zugrundelegung eines
subjektiven Maßstabs durch den Betreiber allein aufgrund der IP-Adresse nicht ohne Weiteres
eine personelle Zuordnung der Adresse vorgenommen werden könne.119 Die Gegenauffassung
lässt IP-Adressen unabhängig vom Grad der Verfestigung unter den Begriff des
personenbezogenen Datums fallen.120 Im Bereich des Identitätsmanagements im Cloud Computing
kann dies allerdings regelmäßig dahinstehen, da anerkanntermaßen zumindest dann, wenn der
Plattformbetreiber aufgrund zusätzlicher bei ihm hinterlegter Informationen – wie der E-Mail-
Adresse – eindeutig bestimmen kann, wem eine konkrete IP-Adresse personell zuzuordnen ist, die
Voraussetzungen eines personenbezogenen Datums vorliegen.121 Nachdem der BGH die Frage des
Personenbezugs von dynamischen IP-Adressen dem EuGH vorgelegt hatte,122 entschied dieser am
19.10.2016, dass es sich bei solchen grundsätzlich nicht um personenbezogene Daten handele,
wenn der Informationsbeschaffung ein gesetzliches Verbot entgegensteht.123 Nach Auffassung des
EuGH sind dynamische IP-Adressen – außer in den Fällen, in denen Auskunftsansprüche gegen
den Provider bestehen, etwa im Bereich der Strafverfolgung – damit nicht personenbezogen.

5.2 Räumlich anwendbares Datenschutzrecht


Für die räumliche Anwendbarkeit des Datenschutzrechts kommt es nach § 1 Abs. 5 S. 1 BDSG
zunächst darauf an, in welchem Staat die verantwortliche Stelle belegen ist. Der Begriff der
verantwortlichen Stelle ist in § 3 Abs. 7 BDSG definiert. Hiernach ist grundsätzlich jede Person
oder Stelle erfasst, die personenbezogene Daten für sich selbst erhebt, verarbeitet oder nutzt. Es
handelt sich hierbei um einen Sammelbegriff für die Adressaten des BDSG.124 Entscheidend ist
letztlich, welche Stelle über Zweck und Mittel der Datenverarbeitung entscheidet.125
Das BDSG weicht in der Regelung des § 1 Abs. 5 S. 1 stark von der DS-RL ab, die in ihrem
Art. 4 Abs. 1 lit. a maßgeblich auf den Ort der Niederlassung abstellt. Mit diesem Konflikt hatte
sich das OVG Schleswig in einer Entscheidung aus dem Jahr 2013126 zu befassen: Im
entscheidungserheblichen Sachverhalt hatte ein US-amerikanisches Unternehmen über seine
irländische Niederlassung Daten deutscher Nutzer verarbeitet und unterhielt eine weitere, nicht
datenverarbeitende Niederlassung in Deutschland. Das Gericht kommt im Rahmen einer
richtlinienkonformen Auslegung zu dem Schluss, dass in dieser Konstellation auf den Sitz der
datenverarbeitenden Niederlassung abzustellen und hier demnach irisches Datenschutzrecht
anzuwenden ist.127 Der EuGH hat in der Entscheidung „Google Spain“ klargestellt, dass es für den
Begriff der Niederlassung unerheblich ist, ob dort tatsächlich datenverarbeitende Vorgänge
stattfinden – genügen soll vielmehr bereits eine Förderung der Geschäftstätigkeit, mit der die
Datenverarbeitung insgesamt einhergeht.128 Entscheidend sei, dass die Tätigkeiten der
datenverarbeitenden Stelle und des Mutterkonzerns untrennbar miteinander verbunden sind, wobei
maßgeblich auf die wirtschaftliche Rentabilität abgestellt wird.129 In der späteren „Weltimmo“-
Entscheidung legt der EuGH den Niederlassungsbegriff ebenfalls weit aus: Einer festen
Einrichtung bedürfe es nicht zwingend; bei Unternehmen, die Leistungen ausschließlich über das
Internet anbieten, sei der Begriff der Niederlassung unter Beachtung des besonderen Charakters
der Tätigkeit und der in Rede stehenden Dienstleistungen zu bestimmen.130
Diese Entscheidungen des EuGH haben große Bedeutung für die Praxis. Namentlich die
großen Anbieter von Online-Diensten haben ihren Sitz typischerweise in den USA und verfügen in
den bedeutsamen europäischen Ländern lediglich über kleinere Niederlassungen, die bewusst
keinerlei technische Datenverarbeitung vornehmen, sondern sich lediglich mit anderen Aufgaben,
etwa Marketing, befassen. Dies reicht indes nach der Rechtsprechung des EuGH grundsätzlich
aus, um die Anwendbarkeit des jeweiligen nationalen Datenschutzrechts zu begründen.131
Mit Art. 3 DSGVO vollzieht der europäische Gesetzgeber im Bereich des räumlich
anwendbaren Rechts eine beachtliche Neuausrichtung. Während Art. 3 Abs. 1 DSGVO – ebenso
wie Art. 4 Abs. 1 lit. a DS-RL – auf die Belegenheit der datenverarbeitenden Niederlassung
abstellt, stellt Art. 3 Abs. 2 DSGVO darauf ab, ob die Datenverarbeitung im Zusammenhang damit
steht, Betroffenen in der EU Waren oder Dienstleistungen anzubieten (lit. a) oder ihr Verhalten zu
beobachten (lit. b). Art. 3 Abs. 2 DSGVO wird als Einführung des Marktortprinzips
verstanden.132 Cloud-Dienste, die sich an Nutzer in der EU richten, unterliegen damit, unabhängig
von Sitz und Niederlassung des Cloud-Anbieters, der DSGVO. Dies gilt ausweislich des
Wortlauts von Art. 3 Abs. 2 lit. a DSGVO auch für unentgeltlich erbrachte Dienste.

5.3 Gewährleistung von Datensicherheit


Gemäß § 9 S. 1 BDSG muss die verantwortliche Stelle die technischen und organisatorischen
Maßnahmen treffen, die erforderlich sind, um die Ausführung der Vorschriften des BDSG zu
gewährleisten. Dies beinhaltet im Wesentlichen die Verpflichtung zur Gewährleistung eines
hinreichenden Datensicherheitsniveaus.133 Nach § 9 S. 2 BDSG bemisst sich das Ausmaß der
hiernach erforderlichen Sicherheitsmaßnahmen am Maßstab der Verhältnismäßigkeit: Erforderlich
sind nur solche Maßnahmen, die bei Würdigung des konkreten Schutzzwecks nicht als
unverhältnismäßig anzusehen sind.134 Die Prüfung, welche konkreten Maßnahmen von der
verantwortlichen Stelle jeweils zu ergreifen sind, kann – wie im vertragsrechtlichen Bereich135 –
nur anhand einer fundierten Risikoanalyse erfolgen, die den Umständen des Einzelfalls Rechnung
trägt.136 Es lässt sich folglich kein pauschaler Maßnahmenkatalog festlegen.
Die DSGVO knüpft in ihrem Art. 32 Abs. 1 an Art. 17 DS-RL bzw. § 9 BDSG an,137 nennt
jedoch konkret die in die Risikoanalyse einzubeziehenden Kriterien. So sind ausweislich von Art.
32 Abs. 1 DSGVO der Stand der Technik, die Implementierungskosten und die Art, der Umfang,
die Umstände und die Zwecke der Verarbeitung sowie die unterschiedliche
Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten der
Betroffenen zu berücksichtigen. Nach Art. 32 Abs. 2 DSGVO sind aufseiten der Risiken
insbesondere solche zu berücksichtigen, die in Vernichtung, Verlust oder Veränderung von Daten
resultieren können. Verarbeiter müssen daher vor allem den Schutz gegen Angriffe von außen
beachten, da Bedrohungen durch Viren und Hacking spezifische Gefahren der Datenvernichtung
und des Datenverlusts mit sich bringen.138
5.4 Besonderheiten bei der Auftragsdatenverarbeitung
5.4.1 Cloud Computing als Auftragsdatenverarbeitung
Cloud Computing wird oftmals als Auftragsdatenverarbeitung i.S.d. § 11 BDSG einzustufen
sein.139 Diese Vorschrift kann einschlägig sein, wenn die Datenverarbeitung auf Weisung einer
anderen natürlichen oder juristischen Person erfolgt. Dies ist dann der Fall, wenn die
auftraggebende Stelle de facto abschließend über Zweck und Umstände der Datenverarbeitung
disponiert.140 Es darf insofern kein Ermessensspielraum beim Auftragnehmer verbleiben.141
Dieser dient vielmehr lediglich als eine Art „verlängerter Arm“142 des Auftraggebers, indem er
diesen bei der technischen Umsetzung der Datenverarbeitungsvorgänge unterstützt.
Ob diese Voraussetzungen vorliegen, ist grundsätzlich für jede Cloud-Lösung im Einzelfall
separat zu ermitteln.143 Typischerweise steht aber bei Nutzung der Cloud der Abruf
standardisierter Infrastrukturdienste im Vordergrund, der faktisch allein vom Anwender gesteuert
wird und mithin grundsätzlich der Regelung des § 11 BDSG unterfällt.144

5.4.2 Rechtsfolgen
Dies hat zunächst gemäß § 11 Abs. 1 S. 1 BDSG zur Folge, dass der Auftraggeber für die
Beachtung der datenschutzrechtlichen Vorgaben verantwortlich bleibt. Er ist folglich trotz
Zwischenschaltung des Auftragsdatenverarbeiters weiterhin verantwortliche Stelle i.S.d. § 3 Abs.
7 BDSG.145 Dies impliziert insbesondere die Verpflichtung zur Einhaltung der entsprechenden
datenschutzrechtlichen Vorgaben für den Auftraggeber selbst. Hiervon betroffen ist grundsätzlich
auch die soeben dargestellte Verpflichtung zur Gewährleistung von Datensicherheit aus § 9
BDSG.
Allerdings kommt im Rahmen des Cloud Computing naturgemäß die IT-Infrastruktur des
Auftraggebers gar nicht zum Einsatz, da dieser sich gerade der technischen Leistungsfähigkeit des
Auftragnehmers bedient. Dementsprechend hat der Auftraggeber auch keinen unmittelbaren
Einfluss auf die zu ergreifenden Sicherheitsmaßnahmen. Diesem Umstand trägt § 11 Abs. 2 BDSG
dadurch Rechnung, dass die Pflichten des Auftraggebers entsprechend angepasst werden; ihn trifft
insbesondere die Pflicht zur sorgfältigen Auswahl und Überwachung des Auftragnehmers. Dieser
ist selbst Adressat des Datenschutzrechts im Hinblick auf die technischen und organisatorischen
Maßnahmen.146

5.4.3 Auftragsverarbeitung nach der DSGVO


In Art. 28 DSGVO findet sich ebenfalls das Konstrukt der Auftragsdatenverarbeitung; dort wird
diese allerdings als „Auftragsverarbeitung“ bezeichnet. Nach Art. 4 Nr. 8 DSGVO ist der
Auftragsverarbeiter nicht für die Verarbeitung Verantwortlicher. Verantwortlich für die
Einhaltung datenschutzrechtlicher Vorschriften bleibt grundsätzlich der Auftraggeber.147 Die
DSGVO ähnelt inhaltlich in diesem Punkt stark dem BDSG.148 Die in Art. 28 DSGVO geregelte
Auftragsverarbeitung unterscheidet sich von der Auftragsdatenverarbeitung nach § 11 BDSG vor
allem durch terminologische Unterschiede, die mit keinem Bedeutungswechsel einhergehen.149
Auch nach dem Konzept der DSGVO hat demnach der Cloud-Anbieter als Auftragnehmer die
Maßnahmen zur Gewährleistung von Datensicherheit zu ergreifen (vgl. Art. 28 Abs. 1 lit. c
DSGVO). Dagegen trifft den Auftraggeber aus Art. 28 Abs. 1 DSGVO – wie bei der
Auftragsdatenverarbeitung nach § 11 Abs. 2 S. 1, 4 BDSG – eine Pflicht zur sorgfältigen Auswahl
und Überwachung.150

5.5 Spezialdatenschutz
Schließlich finden sich einige spezielle datenschutzrechtliche Vorschriften in den §§ 11 ff. TMG,
die in bestimmten Cloud-Einsatzszenarien von Relevanz sein können. Dementsprechend soll auch
dieser Aspekt der rechtlichen Rahmenbedingungen im Folgenden erläutert werden.

5.5.1 Nutzungsdaten
Das TMG regelt gemäß § 15 Abs. 1 S. 2 Nr. 1 insbesondere den Umgang mit Nutzungsdaten, die
Merkmale zur Identifikation des Nutzers enthalten. Dies meint Nutzerinformationen wie IP- oder
E-Mail-Adressen und Nutzerkennungen,151 die für die sichere Identifikation des Nutzers von
zentraler Bedeutung sind. Nach § 15 Abs. 1 S. 1 TMG darf die Erhebung und Verwendung solcher
Daten nur insoweit erfolgen, als dies für die Inanspruchnahme des Telemediums zwingend
erforderlich ist. Wann von Erforderlichkeit in diesem Sinne auszugehen ist, lässt sich nur anhand
des konkret beabsichtigten Nutzungsverhältnisses beurteilen.152

5.5.2 Sonstige Pflichten


Schließlich sind die allgemeinen Verpflichtungen aus § 13 TMG zu beachten. Nach § 13 Abs. 1 S.
1 TMG ist der Nutzer insbesondere frühzeitig in verständlicher Form über Art, Umfang und
Zweck der geplanten Datenverwendung zu unterrichten.153 Zudem sind nach § 13 Abs. 4 TMG
einige technische und organisatorische Pflichten zu beachten;154 insbesondere muss nach § 13 Abs.
4 S. 1 Nr. 2 TMG dafür gesorgt werden, dass die Daten unmittelbar nach Beendigung der Nutzung
gelöscht bzw. gesperrt werden. § 13 Abs. 2 TMG erlaubt ausdrücklich die elektronische
Einwilligung des Nutzers in die Datenverwendung, sofern diese gemäß Abs. 2 Nr. 1 „bewusst und
eindeutig“ erfolgt ist. Letzteres erscheint insbesondere dann zweifelhaft, wenn das
Einwilligungsfeld von Beginn an markiert ist und der Nutzer somit einen aktiven Opt-out
vornehmen müsste, um die Erklärung seines Einverständnisses zu verhindern.155 Empfehlenswert
erscheint es daher, insofern das Erfordernis einer aktiven Bestätigung durch den Nutzer zu
etablieren.

5.5.3 Geltung des TMG nach Anwendbarkeit der DSGVO


Im Bereich der Telemedien stellt sich das Problem, dass sowohl DSGVO als auch das TMG
Anforderungen an die Verarbeitung personenbezogener Daten normieren. Da die DSGVO als
europäische Verordnung nationalen Datenschutzvorschriften und – als lex posterior – auch älteren
unionsrechtlichen Sekundärrechtsakten vorgeht, stellt sich die Frage nach der Fortgeltung der §§
11 ff. TMG. Zur Anwendung bedürfte es einer einschlägigen Öffnungsklausel. Die ausdrücklich
normierte Öffnungsklausel des Art. 95 DSGVO erfasst die durch das TKG geregelten
Telekommunikationsdienste, nicht jedoch Telemedien, sodass hieraus keine Anwendbarkeit der §§
11 ff. TMG abgeleitet werden kann.156 Auch die Vorschrift des Art. 6 Abs. 2 DSGVO, die
mitgliedstaatliche Konkretisierungen des Art. 6 Abs. 1 lit. c und e DSGVO zulässt, erlaubt nicht
die Anwendung der §§ 11 ff. TMG.157 Daher sind die §§ 11 ff. TMG mangels Anwendbarkeit kein
Bestandteil des datenschutzrechtlichen Rahmens, sobald die DSGVO Anwendung findet.

5.6 Schadensersatz
Sofern dem Betroffenen durch die Verletzung des Datenschutzrechts ein Schaden entsteht, hat
dieser einen Anspruch gegen den Cloud-Nutzer aus der datenschutzrechtlichen Norm des § 7
BDSG. Hinsichtlich der nach § 9 BDSG erforderlichen technischen und organisatorischen
Maßnahmen ist auch der Cloud-Anbieter unmittelbar Adressat der gesetzlichen Verpflichtung.158
Bei einem Verstoß des Cloud-Anbieters gegen § 9 BDSG hat der Betroffene einen solchen
Anspruch auch gegen den Cloud-Anbieter. In diesem Szenario haften Cloud-Nutzer und Cloud-
Anbieter dem Betroffenen als Gesamtschuldner gem. § 840 Abs. 1 BGB.159
Die Haftung nach § 7 BDSG erfasst nach herrschender Ansicht nur Vermögensschäden, die
dem Betroffenen entstehen.160 Gerade bei datenschutzrechtlich relevanten Verstößen sind
Probleme dort denkbar, wo kein monetär bezifferbarer Schaden entsteht. Hier sind die
allgemeinen Schadensvorschriften der §§ 249 ff. BGB, insbesondere § 253 Abs. 2 BGB, analog
anzuwenden.161 Bei Eingriffen in das grundrechtlich geschützte allgemeine Persönlichkeitsrecht
des Betroffenen oder sein Recht auf informationelle Selbstbestimmung kommt, vorausgesetzt es
handelt sich um eine schwerwiegende Verletzung, die nicht in anderer Weise ausgeglichen werden
kann,162 ein Schadensersatzanspruch des Betroffenen aus § 823 Abs. 1 BGB i.V.m. Artt. 1 Abs. 1,
2 Abs. 1 GG in Betracht.
Anders als § 7 BDSG erfasst die DSGVO ausdrücklich auch immaterielle Schäden. Sie
gewährt dem Betroffenen, dem ein (materieller oder immaterieller) Schaden entstanden ist, einen
Schadensersatzanspruch aus Art. 82 Abs. 1 DSGVO. Art. 82 Abs. 2 Satz 1 DSGVO stellt insoweit
klar, dass sich der Anspruch jeweils gegen den Verursacher des Schadens richtet, unabhängig
davon, ob es sich dabei um einen Verantwortlichen oder einen Auftragsverarbeiter handelt. Sofern
das Cloud Computing als Auftragsverarbeitung betrieben wird,163 haftet der Cloud-Anbieter als
Auftragsverarbeiter nur dann, wenn er seinen diesbezüglichen Pflichten nicht nachgekommen ist,
die Weisungen des Auftraggebers missachtet oder gegen diese Anweisungen gehandelt hat (Art. 82
Abs. 2 Satz 2 DSGVO), was der Anspruchsberechtigte beweisen muss; hinsichtlich des
Verschuldens ist in Absatz 3 eine Beweislastumkehr zugunsten des Anspruchsberechtigten
normiert.164 Haftungsbegründende Verstöße des Auftragsverarbeiters liegen daher insbesondere
im Bereich der Missachtung der Zweckbindung der Verarbeitung sowie der Einhaltung der
technischen und organisatorischen Maßnahmen.165 Verursachen Cloud-Nutzer und Cloud-Anbieter
den Schaden gemeinsam, haften sie im Außenverhältnis dem Betroffenen als Gesamtschuldner
(Art. 82 Abs. 4 DSGVO); lediglich beim Innenausgleich sind die jeweiligen Beiträge zur
Verursachung des Schadens zu berücksichtigen (Art. 82 Abs. 5 DSGVO).

6 Produkt- und branchenspezifische Aspekte


Besondere rechtliche Anforderungen an die Gestaltung der Cloud-Plattform und des dortigen
Identitätsmanagements folgen weiterhin aus speziellen regulatorischen Vorgaben, die für
bestimmte Geschäftsbereiche Sonderregelungen aufstellen. Diese Sondervorschriften sollen im
Wesentlichen der gesteigerten Sensibilität der in diesen Bereichen typischerweise betroffenen
Datenkategorien Rechnung tragen.

6.1 Kreditwirtschaft
Zunächst sollen die Besonderheiten im Bereich der Kreditwirtschaft beleuchtet werden. Dies
meint diejenigen Konstellationen, in denen Banken oder andere Kreditinstitute Kundendaten in die
Cloud auslagern möchten. Hierzu regelt insbesondere das Kreditwesengesetz (KWG) spezifische
Rahmenbedingungen, die Einfluss auf die rechtlichen Anforderungen an das Identitätsmanagement
haben.

6.1.1 Maßgebliche Rechtsgrundlagen


§ 25b KWG n.F.166 verpflichtet Kreditinstitute, die Aktivitäten oder Prozesse auslagern, zur
Ergreifung von angemessenen Maßnahmen, um die Entstehung zusätzlicher Risiken einzudämmen.
Diese Verpflichtung leitet sich letztlich aus der grundlegenden Pflicht des Kreditinstituts aus § 25a
Abs. 1 S. 1 KWG her, für eine ordnungsgemäße Geschäftsorganisation zu sorgen.167 Ergänzend
sind die Vorgaben der Bundesfinanzaufsicht (BaFin) zur Auslagerung im Kreditsektor in den
Erläuterungen zur MaRisk168 zu beachten. Für Wertpapierdienstleistungsunternehmen ist zudem §
33 Abs. 2 WPHG beachtlich, der ausdrücklich auf § 25b KWG verweist.169

6.1.2 Anwendungsbereich
6.1.2.1 Begriff des Kredit-/Finanzdienstleistungsinstituts
Die Pflicht zur ordnungsgemäßen Geschäftsorganisation trifft gemäß § 25a Abs. 1 S. 1 KWG
grundsätzlich alle Kreditinstitute. Dieser Begriff wird in § 1 Abs. 1 S. 1 KWG näher definiert als
Unternehmen, das Bankgeschäfte zu gewerblichen Zwecken bzw. in einem gewissen Umfang
betreibt. S. 2 liefert hieran anknüpfend eine Auflistung von potenziellen Geschäften, die als solche
infrage kommen; betroffen sind insbesondere die Annahme fremder Gelder als Einlage (Nr. 1), die
Gewährung von Krediten (Nr. 2) sowie die Verwaltung von Wertpapieren (Nr. 5). Sobald diese
oder andere Bankgeschäfte in entsprechender Art und Weise durchgeführt werden, finden demnach
grundsätzlich die Regulierungen des KWG Anwendung, sodass das entsprechende Institut
Vorkehrungen treffen muss, um die enthaltenen Verpflichtungen einzuhalten.
Parallel werden über § 1 Abs. 1a KWG auch sog. Finanzdienstleistungsinstitute erfasst, die in
entsprechendem Umfang Finanzdienstleistungen erbringen, die wiederum in § 1 Abs. 1a S. 2 KWG
näher definiert werden. Hier geht es primär um Anlageberatung (Nr. 1a) und die Verwaltung von
Finanzportfolios (Nr. 3). Zusammenfassend lässt sich festhalten, dass Banken in jeglicher
Ausgestaltung, aber auch sonstige Finanzdienstleister regelmäßig dem Anwendungsbereich des
KWG unterfallen.
6.1.2.2 Umfang der Tätigkeit
Steht fest, dass Bankgeschäfte bzw. sonstige Finanzdienstleistungen erbracht werden, so ist
weiterhin auf Tatbestandsebene zu prüfen, ob dies in hinreichendem Umfang geschieht. Gemäß § 1
Abs. 1 S. 1 KWG genügt grundsätzlich bereits, dass die entsprechenden Geschäfte gewerbsmäßig
betrieben werden. Dies ist der Fall, sobald die Tätigkeit auf eine gewisse Dauer angelegt ist und
das Unternehmen mit Gewinnerzielungsabsicht handelt.170 Diese Anforderungen sind deutlich
geringer als die an einen kaufmännischen Geschäftsbetrieb nach § 1 Abs. 1 S. 1 2. Alt. KWG,
sodass letztere Alternative erheblich an Bedeutung verliert.171
Nach § 1 Abs. 1 S. 1 2. Alt. KWG ist – wie die Formulierung „oder“ indiziert – alternativ zur
Gewerbsmäßigkeit zu prüfen, ob die Tätigkeit einen in kaufmännischer Weise ausgestalteten
Geschäftsbetrieb erforderlich macht. Hierfür sind nach handelsrechtlichen Grundsätzen Art und
Umfang der betroffenen Tätigkeit relevant.172 Die BaFin hat auch insofern konkrete Vorgaben
erlassen, bis zu welcher Bagatellgrenze nicht von einem kaufmännischen Aufwandsszenario
ausgegangen werden kann.173 Zumeist wird es in der Praxis, wie angedeutet, hierauf ohnehin nicht
ankommen, da bereits gewerbsmäßiges Handeln vorliegt.
Schließlich bleibt darauf hinzuweisen, dass der parallele Betrieb von Nichtbankgeschäften –
selbst dann, wenn dieser überwiegt – die Einordnung in das bankrechtliche Regelungsregime nicht
hindert.174
6.1.2.3 Vorliegen einer wesentlichen Auslagerung
Schließlich müsste es sich um eine Auslagerung i.S.d. § 25b Abs. 1 S. 1 KWG handeln, damit die
regulatorischen Rahmenvorschriften Anwendung finden. Eine solche liegt vor, wenn ein anderes
Unternehmen mit der Wahrnehmung solcher Aktivitäten und Prozesse im Zusammenhang mit der
Durchführung von Bankgeschäften beauftragt wird, die ansonsten vom Institut selbst erbracht
würden.175 Maßgeblich ist insofern, dass der Datenempfänger eine eigene Rechtspersönlichkeit
aufweist.176 Dies wird sowohl bei klassischem IT-Outsourcing als auch bei Auslagerung in die
Cloud typischerweise der Fall sein, da der Cloud-Anbieter in aller Regel eine eigenständige
juristische Person darstellt.
Die Auslagerung müsste ausweislich des Wortlauts des § 25b Abs. 1 S. 1 KWG zudem
wesentliche Prozesse betreffen. Ob dies der Fall ist, muss das auslagernde Unternehmen selbst im
Wege einer umfassenden Risikoanalyse ermitteln.177 Hierbei sind insbesondere Art, Umfang,
Komplexität und Risikogehalt der ausgelagerten Prozesse maßgeblich.178 Da diese Analyse
naturgemäß einzelfallbezogen ausfallen muss, kann insofern keine pauschale Einordnung von
banktypischen Prozessen vorgenommen werden. Jedenfalls bei komplexen und zugleich sehr
sensiblen Bereichen, wie der internen Revision, müsste man wohl von Wesentlichkeit in obigem
Sinne ausgehen.179 Auch das Identitätsmanagement dürfte regelmäßig ein derartiges Aufgabenfeld
darstellen, sodass die Vorschriften auch insofern eingreifen.

6.1.3 Pflicht zur ordnungsgemäßen Geschäftsorganisation


Im Kern besagt die Vorschrift des § 25b Abs. 1 S. 1 KWG, dass durch geeignete Maßnahmen
sichergestellt werden muss, dass die Auslagerung die ordnungsgemäße Geschäftsorganisation des
Instituts nicht beeinträchtigt.180

6.1.4 Ausblick
Die Zweite Zahlungsdiensterichtlinie,181 welche gemäß ihrem Art. 116 am 12.01.2016 in Kraft
trat und gemäß ihrem Art. 115 Abs. 1 größtenteils bis zum 13.01.2018 in geltendes Recht
umgesetzt werden muss,182 enthält nähere Anforderungen an die Authentifizierung des Kunden
beim Online-Banking in den Artt. 97 f. Erforderlich ist gemäß Art. 97 Abs. 1 insoweit eine
„starke“ Kundenauthentifizierung, was gemäß der Definition in Art. 4 Nr. 30 eine
Authentifizierung durch mindestens zwei voneinander unabhängige Elemente der Kategorien
Wissen (bspw. Passwörter), Besitz (bspw. Token) und Inhärenz (bspw. Fingerabdruck)
erfordert,183 somit also eine Zwei-Faktor-Authentifizierung.184 Die technischen Details werden
durch die Europäische Bankaufsichtsbehörde (EBA) erarbeitet.185

6.2 Sozialversicherungsträger
6.2.1 Anwendbarkeit
Hinsichtlich der Auslagerung von Sozialdaten in die Cloud stellt sich eine datenschutzrechtliche
Besonderheit, sofern eine Auftragsdatenverarbeitung durch nicht-öffentliche Stellen erfolgt: § 80
Abs. 5 SGB X erklärt eine solche nur unter strengen zusätzlichen Voraussetzungen für zulässig.
Bei Sozialdaten handelt es sich nach § 67 Abs. 1 S. 1 SGB X um Einzelangaben über persönliche
oder sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person
(Betroffener), die von der zuständigen Stelle zur Erfüllung ihrer sozialrechtlichen Aufgaben
erhoben, verarbeitet oder genutzt werden. Soll die Verarbeitung dieser Daten nunmehr einem
Dritten übertragen werden, sind die Vorgaben des § 80 Abs. 5 SGB X zu beachten.

6.2.2 Zulässigkeit der Auslagerung in die Cloud


Gemäß § 80 Abs. 5 SGB X ist die Auftragsdatenverarbeitung der Sozialdaten nur dann zulässig,
wenn entweder bei der erhebenden Stelle sonst Störungen im Betriebsablauf auftreten könnten
(Nr. 1) oder nur ein Teil der Datenmenge übertragen wird und dies zu einer erheblichen
Kostenreduktion führt (Nr. 2). Aufgrund der Sensibilität der betroffenen Daten186 und des hohen
Gefährdungspotenzials187 sind diese Tatbestandsmerkmale grundsätzlich restriktiv auszulegen.188
Als potenzielle Störung des Betriebsablaufs ist insbesondere der drohende Ausfall von
Rechenkapazitäten anerkannt.189 Die in Nr. 2 geforderte erhebliche Kostenersparnis wird im
Regelfall gegeben sein, da der effiziente und bedarfsgerechte Abruf von IT-Ressourcen über die
Cloud typischerweise gerade der Reduktion der laufenden Kosten dienen soll.190
Als besonders problematisch hinsichtlich einer effizienten Auslagerung in die Cloud, gestützt
auf § 80 Abs. 5 Nr. 2 SGB X, erweist sich das zusätzliche Kriterium aus Nr. 2 S. 2 der Vorschrift,
wonach der überwiegende Teil der „Speicherung des gesamten Datenbestandes“ grundsätzlich
beim öffentlich-rechtlichen Auftraggeber verbleiben müsste. Dies schränkt Praktikabilität und
Nutzen einer Cloud-Lösung in diesem Bereich erheblich ein, da es typischerweise gerade darum
geht, die vollständige Datenverarbeitung auszulagern. Sofern vertreten wird, dass der verwendete
Begriff der Speicherung nur IaaS-Lösungen191 ausschließe,192 kann dem nicht gefolgt werden:
Selbstverständlich werden in technischer Hinsicht auch bei Nutzung einer SaaS-Lösung193 –
zumindest temporär – Daten vom Cloud-Anbieter gespeichert, da der Nutzer jedenfalls eigene
Datensätze in das System einspeisen muss, um dieses für seine Zwecke nutzen zu können.194 § 80
Abs. 5 Nr. 2 S. 2 2. Hs. SGB X lässt dagegen die vollständige Übermittlung an eine andere
öffentlich-rechtliche Stelle, etwa eine andere Organisationseinheit derselben Gebietskörperschaft,
grundsätzlich zu.195

6.2.3 Pflicht zur Gewährleistung von Datensicherheit


Schließlich enthält § 78a SGB X eine speziell normierte Verpflichtung des
Auftragsdatenverarbeiters zur Gewährleistung hinreichender Datensicherheit im Umgang mit
Sozialdaten. Die hieraus im Einzelnen resultierenden Verpflichtungen werden im Rahmen des
sechsten Kapitels196 näher erläutert.

6.3 Beweisrecht
Besondere Relevanz hat die Frage der Beweislastverteilung im Falle eines Schadenseintritts, der
aus einer unbefugten Identifizierung resultiert. Dies folgt aus dem Umstand, dass beim
Identitätsmissbrauch in der Cloud der genaue Geschehensablauf oft unbekannt oder zwischen den
Parteien umstritten ist.197

6.3.1 Grundlegende Beweislastverteilung


Zunächst stellt sich die grundlegende Frage, welche Partei die Beweislast für das Vorliegen eines
Identitätsmissbrauchs trägt. Grundsätzlich trägt derjenige, für den die in Rede stehenden Tatsachen
günstig sind – im Rahmen von Schadensersatzansprüchen folglich der Geschädigte –
diesbezüglich auch die Beweislast.198 Der Nutzer muss folglich nachweisen, dass die
anspruchsbegründenden Tatbestandsmerkmale des Schadensersatzanspruchs in tatsächlicher
Hinsicht vorliegen. Erforderlich ist demnach der Nachweis einer Rechtsguts- bzw.
Pflichtverletzung,199 eines kausalen Schadenseintritts sowie grundsätzlich auch des Verschuldens
des Schädigers.200
Es stellt sich sodann die Schwierigkeit, dass der Cloud-Nutzer im Regelfall keine Kenntnis
von den internen Detailabläufen beim Cloud-Anbieter haben wird. Der Identitätsinhaber kann in
der Regel nicht erfahren, welches System auf welchem Wege kompromittiert wurde. Dies
erschwert ein entsprechendes tatsächliches Vorbringen des Geschädigten erheblich. Zur Abhilfe
kommen insofern dem Grunde nach Beweiserleichterungen bis hin zu einer gänzlichen Umkehr der
Beweislast infrage.

6.3.2 Verbesserung der Beweissituation


6.3.2.1 Sekundäre Darlegungslast
Auf der Ebene möglicher Beweiserleichterungen bietet sich zunächst für den Fall, dass mangelnde
Sicherheitsvorkehrungen des Anbieters zu einem Schaden beim Cloud-Nutzer geführt haben, das
Institut der sekundären Darlegungslast an. Dieses greift u. U. dann ein, wenn eine Partei einen
erheblichen Wissensvorsprung vor der anderen hat und letztere daher zu diesem Merkmal
naturgemäß wenig vortragen kann. In dieser Konstellation genügt es nicht, wenn die Partei mit
Wissensvorsprung den Vortrag der anderen Partei einfach bestreitet – sie müsste vielmehr
vortragen, wie sich die tatsächliche Geschehenslage denn stattdessen darstellt.201 Der Cloud-
Nutzer kann typischerweise zu den vom Anbieter getroffenen Sicherheitsmaßnahmen nichts sagen,
da er diese schlicht nicht beurteilen kann. Dementsprechend muss der Cloud-Anbieter hierzu
substantiiert vortragen. Genügt die darlegungsbelastete Partei diesen Anforderungen nicht, gilt die
unsubstantiiert bestrittene Tatsache als zugestanden nach § 138 Abs. 3 ZPO.202 Es wäre sodann
vom Vorliegen unzureichender Sicherheitsmechanismen beim Cloud-Anbieter auszugehen.

6.3.2.2 Anscheinsbeweis
Dem Cloud-Anbieter wiederum wird es regelmäßig darum gehen, möglichst rechtssicher
nachweisen zu können, dass unter einer konkreten Nutzerkennung auch tatsächlich die dahinter
stehende berechtigte Person gehandelt hat. Denn anderenfalls könnte sich der Inhaber der
Nutzerkennung später darauf berufen, dass er selbst gar nicht gehandelt habe und somit zumindest
vertraglichen Vergütungsansprüchen gegen seine Person den Boden entziehen. Der Anbieter hat im
Regelfall kaum die Möglichkeit, die tatsächliche Beteiligung einer konkreten natürlichen Person
an einem Onlinevorgang aktiv nachzuweisen. Dementsprechend wäre es für ihn besonders
vorteilhaft, wenn die Rechtsfigur des Anscheinsbeweises zu seinen Gunsten eingreifen würde.
Diese nach herrschender Auffassung im Bereich der Beweiswürdigung203 zu verortende
Beweiserleichterung führt dazu, dass bei Vorliegen bestimmter Rahmenbedingungen aufgrund der
von der Lebenserfahrung gestützten Typizität der Ereignisse darauf geschlossen werden kann, dass
ein konkretes weiteres Ereignis für diese Geschehnisse ursächlich war.204 Ein besonders
populäres Beispiel entstammt dem Bankbereich, wo aus der Verwendung der originalen EC-Karte
i.V.m. der korrekten PIN darauf geschlossen wird, dass auch der tatsächlich Berechtigte gehandelt
oder zumindest diese Transaktion mitverursacht hat.205 Diesen Gedanken könnte man auf das
Identitätsmanagement übertragen, sodass bei korrekter Verwendung des jeweiligen
Authentifizierungsmediums davon ausgegangen werden könnte, dass auch tatsächlich der
dahinterstehende Nutzer gehandelt hat. Sodann läge es am Nutzer selbst, diesen Anschein zu
erschüttern.206
Ob dieser Transfer gelingt, lässt sich abermals nicht pauschal beantworten. Dies geschieht im
Rahmen von Kapitel 6 bei der Konkretisierung der rechtlichen Anforderungen.207

6.3.2.3 Umkehr der Beweislast


In Ausnahmefällen kann sich auch abseits der gesetzlich normierten Fälle das Erfordernis einer
Umkehr der Beweislast ergeben, wenn die Grundregeln zu deren Verteilung in einer konkreten
Fallgruppe zu unbefriedigenden Ergebnissen führen würden. Dies liegt typischerweise darin
begründet, dass die an sich beweisbelastete Partei den Umständen entsprechend zu den fraglichen
Tatbestandsmerkmalen keine fundierten Aussagen treffen kann und die andere Partei zugleich eine
besondere Sorgfaltspflicht trifft.208 Um die bestehenden dogmatischen Grundlagen nicht gänzlich
zu konterkarieren, ist diesbezüglich jedoch Zurückhaltung geboten. Durchgreifende
Anknüpfungspunkte im Bereich des Identitätsmanagements in der Cloud sind insofern nicht
ersichtlich.

7 Strafrecht
Wesentliche Rahmenbedingungen für das Identitätsmanagement folgen weiterhin auch aus dem
strafrechtlichen Bereich. Dies gilt insbesondere für bestimmte Berufsgruppen, die typischerweise
mit Informationen aus besonders sensiblen Lebensbereichen konfrontiert werden. Insofern steht
namentlich eine Strafbarkeit nach § 203 StGB im Raum.

7.1 Potenzieller Täterkreis


§ 203 Abs. 1 StGB nennt verschiedene Berufsgeheimnisträger, die potenzielle Täter der
Strafvorschrift sein können.209 Zu nennen sind insofern etwa Ärzte (Nr. 1), Rechtsanwälte (Nr. 3)
oder Mitarbeiter einer privaten Krankenversicherung (Nr. 6). Darüber hinaus erweitern § 203
Abs. 2 und Abs. 2a StGB den potenziellen Täterkreis auf Amtsträger und sonstige amtsnahe
Personen210 sowie Beauftragte für den Datenschutz. Schließlich erfolgt über Abs. 3 der Vorschrift
die Erstreckung des persönlichen Anwendungsbereichs auf Gehilfen211 des Geheimnisträgers
sowie die sog. Kammerrechtsbeistände.212

7.2 Tathandlung
Die Verletzung von Privatgeheimnissen erfordert die Offenbarung von Tatsachen, die nur einem
beschränkten Kreis von Personen bekannt sind und deren Geheimhaltung im berechtigten Interesse
des Betroffenen liegt.213 Offenbaren i.d.S. meint grundsätzlich die Vermittlung solcher Tatsachen,
von denen der Adressat bisher noch keine gesicherte Kenntnis hatte.214 Nun liegt der Fall bei der
Auslagerung von Daten in die Cloud etwas anders: Der Geheimnisträger verrät die Informationen
nicht aktiv, sondern verlagert lediglich die betreffenden Dateien in den Einflussbereich des
Cloud-Anbieters. Er verschafft diesem somit letztlich die Möglichkeit, sich durch eigene
Recherche Kenntnis vom Dateiinhalt und mithin vom geschützten Geheimnis zu verschaffen.
Die ganz überwiegende Auffassung lässt indes eine solche Gewährung der Möglichkeit zur
Kenntnisnahme durch Übermittlung digitaler Informationen für eine Offenbarung i.S.d. § 203 Abs.
1 StGB genügen.215 Nach der Gegenauffassung kommt in dieser Fallkonstellation allenfalls eine
Unterlassungsstrafbarkeit in Betracht.216 Letzteres wirkt wenig überzeugend, da der Schwerpunkt
des Unrechtsvorwurfs in der Übermittlung der Daten selbst liegt, welche ein aktives Tun des
Geheimnisträgers darstellt.217 Letztlich handelt es sich nur um die Detailfrage, in welcher Form
die Offenbarung vollzogen wird – es kann insofern keinen Unterschied machen, ob die Information
offen mitgeteilt oder auf einem Medium hinterlegt und übergeben bzw. unmittelbar auf ein fremdes
Medium übertragen wird. Überwiegend wird jedoch als Lösungsansatz anerkannt, dass eine
hinreichend sichere Verschlüsselung der Daten dazu führt, dass nicht mehr von einer Offenbarung
ausgegangen werden kann.218 Dieser Ansatz dürfte jedoch bei Weitem nicht alle praxisrelevanten
Fallgruppen abdecken, da etwa bei Nutzung einer SaaS-Lösung219 die Verwendung
verschlüsselter Daten schlicht nicht zu praktikablen Ergebnissen führt.220

7.3 Reichweite des Gehilfenbegriffs


Wie soeben ausgeführt, wird der Tatbestand des § 203 Abs. 1 StGB bei der Auslagerung von
Daten in die Cloud durch Berufsgeheimnisträger grundsätzlich erfüllt. Da dies im Ergebnis wenig
befriedigend erscheint, wurde bislang als alternativer Lösungsansatz an den Gehilfenbegriff des §
203 Abs. 3 S. 2 Alt. 1 StGB angeknüpft: Gehilfe in diesem Sinne ist grundsätzlich jeder, der den
Berufsgeheimnisträger bei dessen beruflicher Tätigkeit unterstützt.221 Allerdings soll dies
grundsätzlich nicht für selbstständige Unterauftragnehmer gelten, die vom Geheimnisträger mit
konkreten Einzelaufträgen betraut werden.222 Gleichwohl wird bisweilen in der Literatur
vertreten, dass ein externer IT-Dienstleister unter den Gehilfenbegriff des § 203 Abs. 3 S. 2 StGB
falle, sofern dem Auftraggeber ein rechtssicher ausgestaltetes Weisungsrecht zusteht.223 Nach
diesem Lösungsansatz läge keine Übermittlung von Informationen an Dritte, sondern lediglich die
ohne Weiteres zulässige Einschaltung eines Gehilfen vor.
Zu Recht wird diesem Ansatz von der herrschenden Auffassung entgegengehalten, dass
derartige externe Drittanbieter in keiner Weise in die Organisation des Geheimnisträgers
eingebunden sind und dementsprechend auch nicht als dem Kreis der Vertrauensträger zugehörig
behandelt werden können.224 Der Ausdehnung des potenziellen Täterkreises auf Gehilfen liegt die
Überlegung zugrunde, dass der Berufsgeheimnisträger ganz typischerweise auf Hilfspersonen
zurückgreifen wird – dies gilt nicht in gleichem Maße für externe Dienstleister, deren
Zwischenschaltung zudem aufgrund der deutlich eingeschränkten Einflussnahmemöglichkeiten
zusätzliches Gefahrenpotenzial birgt. Es kann daher nicht davon ausgegangen werden, dass es sich
bei externen Cloud-Anbietern um Gehilfen i.S.d. § 203 StGB handelt.

7.4 Neuregelung
Vor allem, um bestehende Rechtsunsicherheiten bei der Hinzuziehung externer Dienstleister durch
Berufsgeheimnisträger aufzulösen, hat die Bundesregierung ein Gesetz „zur Neuregelung des
Schutzes von Geheimnissen bei der Mitwirkung Dritter an der Berufsausübung
schweigepflichtiger Personen“ in Form eines Artikelgesetzes zur Abänderung unter anderem des
Strafgesetzbuches – und dabei hauptsächlich des § 203 StGB – erarbeitet, welches am 09.11.2017
in Kraft getreten ist.225
Der neue § 203 Abs. 3 StGB schränkt die Strafbarkeit von Berufsgeheimnisträgern ein, wenn
diese von Geheimhaltungspflichten betroffene Tatsachen an Beschäftigte226 oder externe
Dienstleister offenbaren.227 Im Gesetzesentwurf und zugrunde liegenden Referentenentwurf228
werden als potenziell erlaubte externe Dienstleister auch Cloud-Anbieter genannt.229 Die
Auslagerung an externe Dienstleister wird gemäß dem neuen § 203 Abs. 3 S. 2 StGB jedoch nur
von der Strafbarkeit ausgenommen, soweit sie „erforderlich“ ist.
Als Kompensation für die insoweit liberalisierte Geheimhaltungspflicht230 erweitert die
Neuregelung zugleich den potenziellen Täterkreis und die möglichen Tathandlungen. Danach
machen sich auch „sonstige mitwirkende Personen“, also externe Dienstleister, strafbar, wenn sie
die von § 203 StGB erfassten Geheimnisse offenbaren.231
Zudem erweitert die Neuregelung die möglichen Tathandlungen. Berufsgeheimnisträger und
mitwirkende Personen machen sich danach auch strafbar, wenn sie es unterlassen haben, von ihnen
hinzugezogene externe Dienstleister zur Geheimhaltung zu verpflichten, und diese später das
Geheimnis offenbaren.232

8 Öffentliches Recht
Auch im öffentlich-rechtlichen Sektor nimmt die Einbindung von Cloud-Lösungen eine immer
bedeutsamere Rolle ein. Maßgeblich betrifft dies insbesondere die Digitalisierung von
Verwaltungsprozessen (sog. E-Government) sowie gerichtlicher Verfahren (sog. E-Justice). Der
öffentlichen Hand sind hierbei jedoch durch die Verpflichtung zur Wahrung des Verwaltungs-
bzw. Verfahrensgeheimnisses enge Grenzen gesetzt. Im Folgenden soll herausgestellt werden, wie
sich die einschlägigen Rechtsgrundlagen insofern auswirken und welche Verpflichtungen daraus
folgen.

8.1 Verwaltungsgeheimnis
8.1.1 Rechtsgrundlagen
Ein zentrales Hemmnis für Cloud Computing im öffentlichen Bereich könnte das
Verwaltungsgeheimnis darstellen. Die Auswirkungen dieser Vorschriften auf das Cloud
Computing werden in der Literatur bisher allerdings kaum besprochen. Anknüpfungspunkt für das
allgemeine Verwaltungsgeheimnis ist § 30 VwVfG, wonach die Verfahrensbeteiligten Anspruch
darauf haben, dass die Behörde nicht unbefugt ihre Geheimnisse offenbart. Neben der im Wortlaut
deutlich angelegten Anspruchsdimension beinhaltet dies auch die allgemeine Verpflichtung der
Verwaltung, die Geheimnisse der Betroffenen nicht unbefugt offenzulegen.233 Ein solches
Offenbaren könnte grundsätzlich das Übermitteln von Daten in die Cloud darstellen. Bei dem
Verwaltungsgeheimnis handelt es sich letztlich um eine Ausprägung der Rechtsstaatlichkeit des
Verwaltungsverfahrens.234 Neben dem allgemeinen Verwaltungsgeheimnis existieren noch einige
speziellere behördliche Geheimhaltungspflichten, die für bestimmte Sachgebiete präzisierende
inhaltliche Vorgaben enthalten.235 § 1 Abs. 1 a.E. VwVfG stellt insoweit klar, dass das VwVfG
zurücktritt, sofern Rechtsvorschriften des Bundes inhaltsgleiche oder entgegenstehende
Bestimmungen enthalten. Existiert eine derartige Spezialregelung zum Umgang mit der
Geheimhaltungspflicht, tritt das allgemeine Verwaltungsgeheimnis aus § 30 VwVfG folglich als
subsidiär zurück.236 Zu nennen sind hier insbesondere das Steuergeheimnis aus § 30 AO, das
Sozialgeheimnis aus § 35 SGB I sowie das Datengeheimnis aus § 5 BDSG. Schließlich sind
zahlreiche spezialgesetzliche Detailregelungen zu beachten, die zumindest mittelbar Fragen der
Geheimhaltung tangieren.237 Die Anwendbarkeit des BDSG berührt die Vorschriften zum
Geheimnisschutz nach § 1 Abs. 3 S. 2 BDSG nicht.

8.1.2 Allgemeines Verwaltungsgeheimnis, § 30 VwVfG


8.1.2.1 Anwendungsbereich
In personeller Hinsicht umfasst der Schutzbereich des Verwaltungsgeheimnisses alle förmlich am
Verwaltungsverfahren Beteiligten und wirkt zeitlich auch über die Verfahrensbeendigung hinaus
fort.238 Nach herrschender Auffassung in der Literatur soll das Verwaltungsgeheimnis als
allgemeiner Rechtsgrundsatz zudem auf jegliches Verwaltungshandeln auch außerhalb eines
förmlichen Verfahrens Anwendung finden.239 Das Verwaltungsgeheimnis ist durch sämtliche
Behörden zu wahren, unabhängig davon, wie diese von den fraglichen Informationen Kenntnis
erlangt haben.240
8.1.2.2 Geheimnisbegriff
In sachlicher Hinsicht stellt sich die Frage, was vom Begriff des Geheimnisses in § 30 VwVfG
umfasst ist. Als Definitionsansatz wird in Anknüpfung an den strafrechtlichen Geheimnisbegriff
überwiegend vertreten, dass alle sich auf einen bestimmten Rechtsträger und dessen
Lebensverhältnisse beziehenden Tatsachen, die nur einem begrenzten Personenkreis bekannt sind
und an deren Nichtverbreitung der Rechtsträger ein berechtigtes Interesse hat, vom Schutzbereich
der Norm umfasst sein sollen.241 Es handelt sich somit um ein sehr weites Verständnis des
Geheimnisses. Der Wortlaut des § 30 VwVfG legt zudem eine Differenzierung zwischen
denjenigen Geheimnissen nahe, die zum persönlichen Lebensbereich des Betroffenen gehören und
denjenigen, die eher der betrieblichen Sphäre zuzuordnen sind. Erfasst sind dementsprechend
grundsätzlich sowohl Angaben zu den gesundheitlichen, familiären und wirtschaftlichen
Verhältnissen einer Person242 als auch diejenigen, die im Zusammenhang mit einem
Geschäftsbetrieb stehen.243
8.1.2.3 Offenbarungsbefugnis
§ 30 VwVfG untersagt nur die unbefugte Offenbarung von Geheimnissen durch Behörden. Fraglich
ist dementsprechend, wann von einer befugten Offenbarung ausgegangen werden kann, die
grundsätzlich möglich bleibt. Dies ist jedenfalls dann anzunehmen, wenn der Betroffene der
Offenbarung zuvor ausdrücklich zugestimmt hat.244 Auch insofern sind zudem vorrangige
spezialgesetzliche Befugnisnormen beachtlich, die der Verwaltung die Offenbarung gegenüber
anderen Stellen unter bestimmten Voraussetzungen gestatten.245 Schließlich kann eine Behörde im
Einzelfall selbst in Ermangelung einer solchen konkreten Rechtsgrundlage zur Offenbarung befugt
sein, sofern eine umfassende Interessenabwägung ergibt, dass dies zur Wahrung höherrangiger
Rechtsgüter der Allgemeinheit oder Einzelner erforderlich ist.246 Für den hier untersuchten
Kontext ist schließlich von besonderer Relevanz, wie die Erlaubnistatbestände des BDSG sich auf
die Offenbarungsbefugnis auswirken. Insoweit wird angenommen, dass das Vorliegen eines
Erlaubnistatbestands nach den §§ 14 ff. BDSG zugleich auch eine Offenbarungsbefugnis darstellen
soll.247 Auch von der Anwendbarkeit der Vorschriften über die Auftragsdatenverarbeitung wird
zumindest stillschweigend ausgegangen.248
Umstritten ist, ob auch die Weitergabe von Informationen innerhalb der Behörde als
Offenbarung von Geheimnissen in obigem Sinne aufzufassen ist. Für das Cloud Computing ist dies
von Relevanz, soweit die Cloud von der Behörde selbst betrieben wird (Private Cloud249). Eine
Auffassung lehnt die Anwendbarkeit des Verwaltungsgeheimnisses in diesen Fällen mit dem
Argument ab, dass sich die Geheimhaltungspflicht nur an die Behörde als solche, nicht aber an den
einzelnen Amtsträger richte.250 Die Gegenansicht hält § 30 VwVfG u. U. auch bei rein
behördeninterner Informationsübermittlung für anwendbar, da auch die Weitergabe an sachlich
nicht befasste Mitarbeiter das Geheimhaltungsinteresse des Betroffenen tangiert.251 Dies
überzeugt, da die Vorschrift ersichtlich der umfassenden Geheimhaltung zugunsten des Betroffenen
gewidmet ist und in diesem Kontext nicht ersichtlich ist, warum sachlich nicht befassten
Amtsträgern ohne Weiteres die Kenntnis von Geheimnissen vermittelt werden dürfen sollte. Die
Übermittlung von Informationen an andere Behörden kann indes gerechtfertigt sein, sofern und
soweit die Voraussetzungen der Amtshilfe vorliegen.252
8.1.2.4 Rechtsfolgen von Verstößen
Erfolgt eine unbefugte Offenbarung von Geheimnissen durch die Behörde, wirkt sich dies in
mehrfacher Hinsicht sowohl auf die handelnde Behörde als auch den verantwortlichen Amtsträger
aus: Verwaltungsverfahrensrechtlich kann sich aus dem Verstoß gegen das Verwaltungsgeheimnis
ein Verwertungsverbot ergeben, das wiederum bei gleichwohl erfolgter Berücksichtigung dieser
Informationen in der Entscheidungsfindung zur Rechtswidrigkeit des ergangenen Verwaltungsakts
führt.253 Zudem drohen dem verantwortlichen Amtsträger persönlich straf- und
disziplinarrechtliche Konsequenzen.254 Schließlich können aus dem Verstoß gegen das
Verwaltungsgeheimnis amtshaftungsrechtliche Schadensersatzansprüche des Betroffenen
erwachsen.255

8.1.3 Steuergeheimnis, § 30 AO
§ 30 Abs. 2 Nr. 1 AO fasst unter das Steuergeheimnis sämtliche Verhältnisse, die dem Amtsträger
im Rahmen eines Verwaltungs- oder Gerichtsverfahrens in Steuersachen bekannt geworden sind.
Nr. 2 fügt ausdrücklich Betriebs- und Geschäftsgeheimnisse hinzu. Der Begriff des Verhältnisses
ist auch im steuerrechtlichen Kontext sehr weit; er umfasst grundsätzlich alle persönlichen und
wirtschaftlichen Umstände, die mit einer konkreten Person in Zusammenhang stehen.256 Die
Geheimhaltungspflicht wird in personeller Hinsicht über § 30 Abs. 3 AO auf bestimmte
Berufsgruppen erweitert, die gleichfalls typischerweise häufig mit schutzwürdigen Informationen
in Berührung kommen.257
§ 30 Abs. 4 AO enthält einen eigenen ausdifferenzierten Katalog mit Zulässigkeitstatbeständen
hinsichtlich der Offenbarung von grundsätzlich vom Steuergeheimnis umfassten Tatsachen. Zu
nennen ist insbesondere § 30 Abs. 4 Nr. 1 AO, der die Offenbarung gestattet, sofern dies zur
Durchführung eines Verwaltungs- oder Gerichtsverfahrens in Steuersachen erforderlich ist. Dies
setzt allerdings einen unmittelbaren funktionalen Zusammenhang zwischen der Offenbarung und
der Durchführung des Verfahrens voraus.258 § 30 Abs. 4 Nr. 2 AO verweist im Übrigen
ausdrücklich auf Offenbarungsbefugnisse aus sonstigen gesetzlichen Befugnisnormen.259 § 87a
Abs. 1 S. 3 AO stellt eine weitere Anforderung auf: Übermittelt die Finanzbehörde Daten, welche
dem Steuergeheimnis unterliegen, sind diese mit einem geeigneten Verfahren zu verschlüsseln.

8.1.4 Sozialgeheimnis, § 35 SGB I


Weiterhin ist der Vollständigkeit halber auch das Sozialgeheimnis aus § 35 SGB I zu erwähnen.
Diese spezielle Unterkategorie des Verwaltungsgeheimnisses umfasst in sachlicher Hinsicht alle
Sozialdaten i.S.d. § 67 Abs. 1 SGB X. Insofern enthält § 80 Abs. 5 SGB X eine Spezialregelung
zum Outsourcing in die Cloud, sodass diesbezüglich auf die obigen Ausführungen verwiesen
werden kann.260

8.1.5 Datengeheimnis, § 5 BDSG


Schließlich ist das Datengeheimnis i.S.d. § 5 BDSG zu nennen, das es den „bei der
Datenverarbeitung beschäftigten Personen“ untersagt, unbefugt personenbezogene Daten zu
erheben, zu nutzen oder zu verarbeiten. Diese Geheimhaltungspflicht trifft indes nicht nur
staatliche Stellen, sondern grundsätzlich sämtliche Personen, die im Rahmen ihrer geschäftlichen
Tätigkeit mit personenbezogenen Daten umzugehen haben.261 Es ist nicht erforderlich, dass diese
Tätigkeit ein bestimmtes Ausmaß erreicht262 oder der Mitarbeiter einen bestimmten beruflichen
Status innehat.263 Untersagt ist diesem Personenkreis nicht nur die unbefugte Verarbeitung der
Daten i.S.d. § 3 Abs. 4 BDSG sowie deren unbefugte Erhebung i.S.d. § 3 Abs. 3 BDSG, sondern
auch die sonstige Nutzung; wobei letzteres als Auffangtatbestand zu verstehen ist.264 Unbefugt in
diesem Sinne ist nicht nur jede rechtswidrige Datennutzung,265 sondern bereits die interne
Überschreitung von Zugriffsbefugnissen durch den Mitarbeiter.266 Der Dienstherr muss gemäß § 5
S. 2 BDSG zu Beginn des Dienstverhältnisses den Mitarbeiter auf die Wahrung des
Datengeheimnisses verpflichten.267

8.1.6 Auswirkungen auf E-Government


Unter dem Begriff E-Government versteht man überwiegend die Abwicklung geschäftlicher
Prozesse im Zusammenhang mit Regieren und Verwalten mithilfe von Informations- und
Kommunikationstechniken über elektronische Medien.268 Die Etablierung eines hieran angelehnten
Verwaltungssystems erfordert im Wesentlichen die Anschaffung der erforderlichen Technik, die
Gestaltung dazu passender Verfahrensabläufe und die Bereitstellung geeigneter Zugänge für die
elektronische Kommunikation.269

8.2 Verfahrensgeheimnis
Spezielle Anforderungen könnten sich bei der Auslagerung von Datenverarbeitungsvorgängen in
die Cloud im Kontext gerichtlicher Entscheidungen ergeben.

8.2.1 Grundsatz
Auch im gerichtlichen Verfahren können berechtigte Geheimhaltungsinteressen der betroffenen
Parteien bestehen. Diese sehen sich indes mit gewichtigen gegenläufigen Interessen konfrontiert:
Insbesondere die grundgesetzlichen Verfahrensgrundsätze der Rechtsschutzgarantie aus Art. 19
Abs. 4 GG und des Rechts auf rechtliches Gehör aus Art. 103 Abs. 1 GG stehen einem
umfassenden Geheimnisschutz gegenüber dem Prozessgegner diametral entgegen.270 Aber auch
gegenüber der Öffentlichkeit im Allgemeinen ist der Geheimnisschutz stark eingeschränkt, da
insofern der in § 169 GVG normierte Grundsatz der Öffentlichkeit der Verhandlung gilt, der
seinerseits verfassungsrechtliche Wurzeln271 aufweist.
Ein umfassendes Verfahrensgeheimnis kann dementsprechend naturgemäß nicht anerkannt
werden.272 Gleichwohl können prozessuale Maßnahmen, die Geheimhaltungszwecken dienen,
grundsätzlich durchaus zulässige Eingriffe in die benannten Verfahrensgrundsätze darstellen.273 Im
Folgenden sollen die wesentlichen prozessualen Geheimhaltungsmechanismen als spezielle
Ausformungen des Verfahrensgeheimnisses untersucht werden.

8.2.2 Prozessuale Maßnahmen zum Schutz von Geheimnissen


8.2.2.1 Verwaltungsverfahren: § 99 Abs. 1 S. 2 VwGO
Grundsätzlich sind Behörden gemäß § 99 Abs. 1 S. 1 VwGO dazu verpflichtet, im
verwaltungsgerichtlichen Verfahren die eigenen internen Verfahrensakten beizubringen. § 99 Abs.
1 S. 2 VwGO sieht allerdings unter gewissen Umständen ein Recht zur Verweigerung der Vorlage
vor. Dies betrifft einerseits diejenigen Geheimnisse, deren Offenbarung dem Landeswohl schaden
würde; andererseits solche, deren Geheimhaltung gesetzlich oder „ihrem Wesen nach“
vorgeschrieben ist. Ein gesetzliches Geheimhaltungsgebot ist nur in seltenen Ausnahmefällen
einschlägig und betrifft insbesondere die zuvor dargestellten speziellen Ausformungen des
Verwaltungsgeheimnisses.274 Der offenere Ausnahmetatbestand, wonach eine Information ihrem
Wesen nach geheimhaltungsbedürftig sein müsste, ist einer konkretisierenden Definition kaum
zugänglich.275 Anerkanntermaßen ist aufgrund des Ausnahmecharakters der Norm insofern ein
strenger Maßstab anzulegen.276 Es müssten daher im Einzelfall bei Offenbarung der Informationen
massive Eingriffe in gewichtige Interessen der Öffentlichkeit oder privater Personen drohen.277
In verfahrensrechtlicher Hinsicht bleibt zu beachten, dass die Verweigerungsentscheidung
gemäß § 99 Abs. 1 S. 2 VwGO von der obersten Aufsichtsbehörde getroffen werden muss.278 Um
die Geheimhaltungsinteressen nicht zu konterkarieren, zugleich aber ein Mindestmaß an effektivem
Rechtsschutz zu gewähren, sieht § 99 Abs. 2 VwGO ein sog. in-camera-Verfahren279 zur
Überprüfung der behördlichen Verweigerungsentscheidung vor. Gemäß § 99 Abs. 2 S. 4 i.V.m. §
189 VwGO ist insofern ein spezieller Fachsenat zur Entscheidung berufen, der ausweislich des
Abs. 2 S. 10 der Vorschrift durch die Begründung seiner Entscheidung keine Rückschlüsse auf den
Inhalt der fraglichen Akten zulassen darf. Auch das Recht auf Akteneinsicht aus § 100 VwGO
findet gemäß § 99 Abs. 2 S. 9 VwGO insofern keine Anwendung. So wird verhindert, dass die
Verfahrensbeteiligten mittelbar doch Zugriff auf die gerade geheim zu haltenden Informationen
erlangen können.
8.2.2.2 Ausschluss der Öffentlichkeit
8.2.2.2.1 Grundsatz
§ 169 S. 1 GVG normiert den Grundsatz der Öffentlichkeit der gerichtlichen Verhandlung. Diese
und die nachfolgenden Vorschriften gelten unmittelbar für die ordentliche Gerichtsbarkeit280 und
über die Verweisungsnorm des § 55 VwGO auch im verwaltungsgerichtlichen Verfahren. Die §§
171a ff. GVG enthalten für bestimmte Konstellationen die Möglichkeit, die Öffentlichkeit vom
Verfahren auszuschließen.
8.2.2.2.2 Potenzielle Ausschlussgründe
Relevant für den hiesigen Kontext ist insbesondere der Ausschlussgrund des § 171b Abs. 1 S. 1
GVG, der u. U. den Ausschluss aufgrund der Darlegung privater Umstände zulässt, deren
öffentliche Erörterung schutzwürdige Interessen des Betroffenen beeinträchtigen würde.
Flankierend ist auf § 172 Nr. 2 GVG hinzuweisen, der ausdrücklich den Schutz von betrieblichen
Geschäftsgeheimnissen in den Kreis potenzieller Ausschlussgründe aufnimmt.
Als taugliche Umstände aus dem persönlichen Lebensbereich des Betroffenen i.S.d. § 171b
Abs. 1 S. 1 GVG kommen grundsätzlich nur sensible private Informationen infrage, wie Angaben
zum Familien- und Sexualleben oder zur religiösen Überzeugung.281 Ausweislich des § 171b Abs.
1 S. 2 GVG dürfte das öffentliche Interesse an der Offenbarung indes nicht als überwiegend
einzustufen sein. Erforderlich ist mithin eine Abwägung der schutzwürdigen Interessen des
Betroffenen gegen das Aufklärungsinteresse der Öffentlichkeit.282 Maßgeblich ist insofern
insbesondere, wie stark die Öffentlichkeit der Verhandlung die Persönlichkeitssphäre des
Betroffenen tangieren würde.283 Wird wegen einer besonders gravierenden Straftat verhandelt, so
spricht dies tendenziell eher für ein Überwiegen des Öffentlichkeitsinteresses.284 Der Ausschluss
der Öffentlichkeit kann schließlich nach § 172 Nr. 2 GVG auch aufgrund des Schutzes von
Geschäftsgeheimnissen des Betroffenen gerechtfertigt sein. Der Begriff des Geschäftsgeheimnisses
ist insofern deckungsgleich mit demjenigen des allgemeinen Verwaltungsrechts.285 Auch insofern
ist indes eine Abwägung der entgegenstehenden Interessen vorzunehmen.286
8.2.2.2.3 Verfahren
Schließlich bleibt festzuhalten, dass Entscheidungen nach § 171b GVG gemäß dessen Abs. 5
grundsätzlich unanfechtbar sind. Dies gilt indes nicht uneingeschränkt, wenn die Voraussetzungen
der Abs. 1–3 nicht erfüllt sind und die Privatsphäre mithin nicht tangiert ist287 oder gegen
Grundrechte des Betroffenen verstoßen wurde.288 In diesen Fällen steht trotz der eindeutigen
Formulierung des Wortlauts u. U. die Anfechtung der Entscheidung offen.

Literatur
Albrecht, Achim/Karahan, Davud/Lenenbach, Markus: Fachanwaltshandbuch Bank- und Kapitalmarktrecht, Bonn 2010.

Armbrüster, Christian: Haftung der Geschäftsleiter bei Verstößen gegen § 64 a VAG, VersR 2009, 1293–1304.

Bader, Johann/Ronellenfitsch, Michael: Beck'scher Online-Kommentar VwVfG, 33. Edition, Stand: 01.10.2016, München 2016.

Bamberger, Heinz Georg/Roth, Herbert: Beck’scher Online-Kommentar BGB, 41. Edition, Stand: 01.11.2016, München 2016.

Baumbach, Adolf/Hopt, Klaus J.: Handelsgesetzbuch, 37. Aufl., München 2016.

Bedner, Mark: Cloud Computing: Technik, Sicherheit und rechtliche Gestaltung, Kassel 2013.

Bergt, Matthias: Die Bestimmbarkeit als Grundproblem des Datenschutzrechts. Überblick über den Theorienstreit und
Lösungsvorschlag, ZD 2015, 365–371.

Boos C./Kroschwald, Steffen/Wicker, Magda: Datenschutz bei Cloud Computing zwischen TKG, TMG und BDSG, ZD 2013,
205–210.

Boos, Karl-Heinz/Fischer, Reinfrid/Schulte-Mattler, Hermann: Kreditwesengesetz, 5. Aufl., München 2016.

Borges, Georg: Verträge im elektronischen Geschäftsverkehr, Baden-Baden 2003.

Borges, Georg: Rechtsfragen der Haftung im Zusammenhang mit dem elektronischen Identitätsnachweis, Baden-Baden 2011.

Borges, Georg: Rechtsfragen des Phishing – Ein Überblick, NJW 2005, 3313–3117.

Borges, Georg: Identitätsmissbrauch im Online-Banking und die neue Zahlungsdiensterichtlinie (PSD2), ZBB 2016, 249–259.

Borges, Georg: Neue Ansätze zur Regulierung von IT-Sicherheit, in: van Oostrom, Samuel/Weth, Stephan (Hrsg.), Festschrift für
Maximilian Herberger, Saarbrücken 2016.

Borges, Georg/Meents, Jan Geert: Cloud Computing. Rechtshandbuch, München 2016.

Brennscheidt, Kirstin: Cloud Computing und Datenschutz, Baden-Baden 2013.


Bräutigam, Peter: SLA: In der Praxis alles klar? Optimale Konkretisierung von Umfang und Qualität geschuldeter Einzelleistungen
beim IT-Outsourcing, CR 2004, 248–254.
Buchner, Benedikt: Grundsätze und Rechtmäßigkeit der Datenverarbeitung unter der DS-GVO, DuD 2016, 155–161.

Conrad, Isabell/Fechtner, Sonja: IT-Outsourcing durch Anwaltskanzleien nach der Inkasso-Entscheidung des EuGH und dem
BGH, Urteil vom 07.02.2013. Datenschutzrechtliche Anforderungen, CR 2013, 137–148.

Däubler, Wolfgang/Klebe, Thomas/Wedde, Peter/Weichert, Thilo: BDSG, 5. Aufl., Frankfurt am Main 2016.

Dreher, Meinrad/Ballmaier, Christoph: Der Dienstleistungsvertrag bei der Auslagerung nach § 64a Abs. 4 VAG, VersR 2014, 8–
13.

Ebenroth, Thomas/Boujong, Karlheinz/Joost, Detlev/Strohn, Lutz: Handelsgesetzbuch, 3. Aufl., München 2014.

Eichenhofer, Eberhard/Wenner, Ulrich: SGB I/IV/X, München 2012.

Engels, Thomas: Datenschutz in der Cloud – Ist hierbei immer eine Auftragsdatenverarbeitung anzunehmen?, K&R 2011, 548–551.

Erbs, Georg/Kohlhaas, Max (hrsg. Häberle, Peter), Strafrechtliche Nebengesetze, Loseblatt, 210. Ergänzungslieferung, Stand:
September 2016, München 2016.

Erman, Walter: Bürgerliches Gesetzbuch, 14. Aufl., Köln 2014.

Forgó, Nikolaus/Krügel, Tina: Der Personenbezug von Geodaten. Cui bono, wenn alles bestimmbar ist?, MMR 2010, 17–23.

Gaul, Björn/Koehler, Lisa-Marie: Mitarbeiterdaten in der Computer Cloud: Datenschutzrechtliche Grenzen des Outsourcing, BB
2011, 2229–2236.

Geigel, Reinhart: Der Haftpflichtprozess, 27. Aufl., München 2015.

Geiß, Karlmann/Greiner, Hans-Peter: Arzthaftpflichtrecht, 7. Aufl., München 2014.

Gerlach, Carsten: Sicherheitsanforderungen für Telemediendienste – der neue § 13 Abs. 7 TMG, CR 2015, 581–589.

Gersdorf, Hubertus/Paal, Boris P.: Beck'scher Online-Kommentar Informations- und Medienrecht, 14. Edition, Stand: 01.11.2016,
München 2016.

Gola, Peter/Schomerus, Rudolf: Bundesdatenschutzgesetz, 12. Aufl., München 2015.

Graf, Jürgen-Peter: Beck'scher Online-Kommentar StPO mit RiStBV und MiStra, 26. Edition, Stand: 01.10.2016, München 2016.

Habersack, Mathias: Münchener Kommentar zum Bürgerlichen Gesetzbuch, Band 5, 6. Aufl., München 2013.

Hannich, Rolf: Karlsruher Kommentar StPO, 7. Aufl., München 2013.

Härting, Niko: IT-Sicherheit und Berufsrecht. Das Anwaltsgeheimnis im Zeichen von Cloud Computing, ITRB 2011, 242–243.

Hauck, Karl/Noftz, Wolfgang: Sozialgesetzbuch (SGB) V: Gesetzliche Krankenversicherung, Fortsetzungsbezug, Stand: Oktober
2015.

Heckel, Christian: Behördeninterne Geheimhaltung. Ein Beitrag zum amtsinternen Datenaustausch, NVwZ 1994, 224–225.

Heckmann, Dirk: juris Praxiskommentar Internetrecht, 4. Aufl., Saarbrücken 2014.

Heckmann, Dirk: Rechtspflichten zur Gewährleistung von IT-Sicherheit im Unternehmen, MMR 2006, 280–285.

Heidrich, Jörg/Wegener, Christoph: Sichere Datenwolken – Cloud Computing und Datenschutz, MMR 2010, 803–807.

v. Heintschel-Heinegg, Bernd: Beck‘scher Online-Kommentar StGB, 32. Edition, Stand: 01.09.2016, München 2016.
Hilber, Marc: Handbuch Cloud Computing, Köln 2014.
Hoeren, Thomas/Sieber, Ulrich/Holznagel, Bernd: Handbuch Multimedia-Recht, Loseblatt, 43. Aufl., Stand: Juli 2016, München
2016.

Jandt, Silke/Nebel, Maxi: Die elektronische Zukunft der Anwaltstätigkeit. Rechtsprobleme beim Outsourcing von Scan-
Dienstleistungen, NJW 2013, 1570–1575.

Jauernig, Othmar: BGB, Kommentar, 16. Aufl., München 2015.

Kaetzler, Joachim/Weirauch, Boris: Bankenaufsichtsrechtliche Aspekte von Outsourcingverhältnissen, BKR 2008, 265–270.

Keppeler, Lutz Martin: Was bleibt vom TMG-Datenschutz nach der DS-GVO? Lösung und Schaffung von Abgrenzungsproblemen
im Multimedia-Datenschutz, MMR 2015, 779–783.

Kilian, Wolfgang/Heussen, Benno: Computerrechts-Handbuch, 32. Aufl., München 2013.

Kindhäuser, Urs/Neumann, Ulfrid/Paeffgen, Hans-Ullrich: StGB, 4. Aufl., Baden-Baden 2013.

Klein, Friedrich: Abgabenordnung, 13. Aufl., München 2016.

Knemeyer, Franz-Ludwig: Geheimhaltungsanspruch und Offenbarungsbefugnis im Verwaltungsverfahren, NJW 1984, 2241–2248.

Koch, Robert: Haftung für die Weiterverbreitung von Viren durch E-Mails, NJW 2004, 801–807.

Koenig, Ulrich: Abgabenordnung, 3. Aufl., München 2014.

Köhler-Schute, Christiana: Cloud Computing: Flexible Services für Unternehmen – Strategien und Methoden, Lösungen und
Praxisbeispiele, juristische Fallstricke, 2. Aufl. 2013.

Kroschwald, Steffen/Wicker, Magda: Kanzleien und Praxen in der Cloud – Strafbarkeit nach § 203 StGB, CR 2012, 758–764.

Krüger, Stefan/Maucher, Svenja-Ariane: Ist die IP-Adresse wirklich ein personenbezogenes Datum?, MMR 2011, 433–439.

Krüger, Wolfgang: Münchener Kommentar zum Bürgerlichen Gesetzbuch, Band 2, 7. Aufl., München 2016.

Kühling, Jürgen/Martini, Mario: Die Datenschutz-Grundverordnung: Revolution oder Evolution im europäischen und deutschen
Datenschutzrecht?, EuZW 2016, 448–454.

Kunczik, Niclas: Namensrechtsverstoß durch Nennung als „Mitarbeiter” in Impressum, ITRB 2013, 183–184.

Lachmann, Jens-Peter: Unternehmensgeheimnisse im Zivilrechtsstreit, dargestellt am Beispiel des EDV-Prozesses, NJW 1987,
2206–2610.

Lackner, Karl/Kühl, Kristian: StGB, 28. Aufl., München 2014.

Lehmann, Michael/Giedke, Anna: Cloud Computing – technische Hintergründe für die territorial gebundene rechtliche Analyse,
CR 2013, 608–616.

Lehmann, Michael/Meents, Jan Geert: Handbuch des Fachanwalts Informationstechnologierecht, 2. Aufl., Köln 2011.

Lerch, Hana/Krause, Beate/Hotho, Andreas/Roßnagel, Alexander/Stumme, Gerd: Social Bookmarking-Systeme – die


unerkannten Datensammler, MMR 2010, 454–458.

Leupold, Andreas/Glossner, Silke: Münchener Anwaltshandbuch IT-Recht, 3. Aufl., München 2013.

Libertus, Michael: Zivilrechtliche Haftung und strafrechtliche Verantwortlichkeit bei unbeabsichtigter Verbreitung von
Computerviren, MMR 2005, 507–512.

Lippross, Otto-Gerd/Seibel, Wolfgang: Basiskommentar Steuerrecht, Loseblatt, 93. Aktualisierung, Köln 2016.
Meyerdierks, Per: Sind IP-Adressen personenbezogene Daten?, MMR 2009, 8–13.

Meyerdierks, Per: Personenbeziehbarkeit statischer IP-Adressen. Datenschutzrechtliche Einordnung der Verarbeitung durch
Betreiber von Webseiten, MMR 2013, 705–708.

Musielak, Hans-Joachim/Voit, Wolfgang: Kommentar zur Zivilprozessordnung, 13. Aufl., München 2016.

Müller-Broich, Jan D. :Telemediengesetz, Baden-Baden 2012.

Nägele, Thomas/Jacobs, Sven: Rechtsfragen des Cloud Computing, ZUM 2010, 281–292.

Niemann, Fabian/Hennrich, Thorsten: Kontrollen in den Wolken? Auftragsdatenverarbeitung in Zeiten des Cloud Computings, CR
2010, 686–692.

Niemann, Fabian/Paul, Jörg-Alexander: Bewölkt oder wolkenlos – rechtliche Herausforderungen des Cloud Computings, K&R
2009, 444–452.

Nordmeier, Carl Friedrich: Cloud Computing und Internationales Privatrecht. Anwendbares Recht bei der Schädigung von in
Datenwolken gespeicherten Daten, MMR 2010, 151–156.

Oetterich, Dirk: Auslagerung von Dienstleistungen im Widerspruch zum Berufsrecht?, DStR 2013, 2482–2484.

Ohlenburg, Anna: Geheimnisschutz im Verwaltungsprozess – Die Modifikation des § 99 II VwGO in § 138 TKG, NVwZ 2005,
15–18.

Palandt, Otto: Bürgerliches Gesetzbuch, 75. Aufl., München 2016.

Petri, Thomas: Auftragsdatenverarbeitung – heute und morgen. Reformüberlegungen zur Neuordnung des Europäischen
Datenschutzrechts, ZD 2015, 305–309.

Piltz, Carlo: Die Datenschutz-Grundverordnung. Teil 1: Anwendungsbereich, Definitionen und Grundlagen der Datenverarbeitung,
K&R 2016, 557–567.

Plath, Kai-Uwe: BDSG/DSGVO, 2. Aufl., Köln 2016.

Pohl, Dirk: Die Klassifikation des Steuergeheimnisses, BB 1995, 2093–2096.

Pohle, Jan/Ammann, Thorsten: Software as a Service – auch rechtlich eine Evolution?, K&R 2009, 625–631.

Pohle, Jan/Ammann, Thorsten: Über den Wolken … – Chancen und Risiken des Cloud Computing, CR 2009, 273–278.

Posser, Herbert/Wolff, Heinrich Amadeus: Beck'scher Online-Kommentar VwGO, 39. Edition, Stand: 01.10.2016, München 2016.

Prell, Lorenz: Das E-Government-Gesetz des Bundes. Revolution der elektronischen Verwaltung bei der Schriftformersetzung?,
NVwZ 2013, 1514, 1520.

Rammos, Thanos/Vonhoff, Hans: Cloud Computing und Sozialdatenschutz. Rechtliche Rahmenbedingungen für den Einsatz von
Cloud Computing-Diensten im Sozialleistungssektor, CR 2013, 265–272.

Rauscher, Thomas/Krüger, Wolfgang: Münchener Kommentar zur Zivilprozessordnung mit Gerichtsverfassungsgesetz und
Nebengesetzen, 4. Aufl., München 2013.

Redeker, Helmut: Cloud Computing in der öffentlichen Hand und § 203 StGB. Öffentlich-rechtliche Datenverarbeitung in der Cloud:
strafrechtliche Fragen und Lösungsmöglichkeiten, ITRB 2014, 232–234.

Redeker, Helmut: IT-Recht, 6. Aufl., München 2017.

Rosenberg, Leo/Schwab, Karl Heinz/Gottwald, Peter: Zivilprozessrecht, 17. Aufl., München 2010.

Roßnagel, Alexander: Der Anwendungsvorrang der eIDAS-Verordnung. Welche Regelungen des deutschen Rechts sind weiterhin
für elektronische Signaturen anwendbar?, MMR 2015, 359–364.
Roßnagel, Alexander: Wie zukunftsfähig ist die Datenschutz-Grundverordnung? Welche Antworten bietet sie für die neuen
Herausforderungen des Datenschutzrechts?, DuD 2016, 561–565.

Roth, Birgit/Schneider, Uwe K.: IT-Sicherheit und Haftung, ITRB 2005, 19–22.

Saenger, Ingo: ZPO, 6. Aufl., Baden-Baden 2015.

Schantz, Peter: Die Datenschutz-Grundverordnung – Beginn einer neuen Zeitrechnung im Datenschutzrecht, NJW 2016, 1841–
1847.

Schimansky, Herbert/Bunte, Hermann-Josef/Lwowski, Hans Jürgen, Bankrechts-Handbuch, 4. Aufl., München 2011.

Schmidl, Michael: Aspekte des Rechts der IT-Sicherheit, NJW 2010, 476–481.

Schoch, Friedrich/Schneider, Jens-Peter/Bier, Wolfgang: VwGO, 31. Aufl., München 2016.

Schönke, Adolf/Schröder, Horst: StGB, 29. Aufl., München 2014.

Schultze-Melling, Jyn: IT-Sicherheit in der anwaltlichen Beratung. Rechtliche, praktische und wirtschaftliche Aspekte eines
effektiven Information Security-Managements, CR 2005, 73–80.

Schulz, Carsten/Rosenkranz, Timo: Cloud Computing – Bedarfsorientierte Nutzung von IT-Ressourcen, ITRB 2009, 232–236.

Schulze, Reiner (Schriftleitung): BGB, 9. Aufl., Baden-Baden 2016.

Schuster, Fabian/Reichl, Wolfgang: Cloud Computing & SaaS: Was sind die wirklich neuen Fragen? Die eigentlichen
Unterschiede zu Outsourcing, ASP & Co liegen im Datenschutz und der TK-Anbindung, CR 2010, 38–43.

Schuster, Fabian: Rechtsnatur der Service Level bei IT-Verträgen. Wie die Gestaltung von Service Levels die Leistung, die
Gewährleistung und den Vertragstyp konkretisiert, CR 2009, 205–210.

Schütze, SGB X. Sozialverwaltungsverfahren und Sozialdatenschutz, 8. Aufl., München 2014.

Schwark, Eberhard/Zimmer, Daniel: Kapitalmarktrechts-Kommentar, 4. Aufl., München 2010.

Simitis, Spiros: BDSG, 8. Aufl., Baden-Baden 2014.

Söbbing, Thomas: Cloud und Grid Computing: IT-Strategien der Zukunft rechtlich betrachtet MMR 5/2008, XII–XIV.

Spickhoff, Andreas: Medizinrecht, 2. Aufl., München 2014.

Spindler, Gerald/Schuster, Fabian: Recht der elektronischen Medien, 3. Aufl., München 2015.

Spindler, Gerald: IT-Sicherheit – Rechtliche Defizite und rechtspolitische Alternativen, MMR 2008, 7–13.

Spindler, Gerald: Die neue EU-Datenschutz-Grundverordnung, DB 2016, 937–947.

Splittgerber, Andreas/Rockstroh, Sebastian: Sicher durch die Cloud navigieren – Vertragsgestaltung beim Cloud Computing, BB
2011, 2179–2185.

v. Staudinger, J.: Buch 1: Allgemeiner Teil 5, §§ 164–240 (Allgemeiner Teil 5), Neubearbeitung 2014, Berlin 2014.

v. Staudinger, J.: Buch 2: Recht der Schuldverhältnisse, §§ 823 E-I, 824, 825 (Unerlaubte Handlungen 1 – Teilband 2), Berlin 2009.

Stelkens, Paul/Bonk, Heinz-Joachim/Sachs, Michael: Verwaltungsverfahrensgesetz: VwVfG, 8. Aufl., München 2014.

Sujecki, Bartosz: Internationales Privatrecht und Cloud Computing aus europäischer Perspektive, K&R 2012, 312–317.

Thüsing, Gregor: Beschäftigtendatenschutz und Compliance, 2. Aufl., München 2014.


Tipke, Klaus/Kruse, Heinrich Wilhelm: Abgabenordnung, 145. Aktualisierung, Stand: August 2016, Köln 2016.

Tschentscher, Thomas/Neumann, Holger: Das telekommunikationsrechtliche Regulierungsverfahren – Verfahrensfragen,


Mißbrauchsaufsicht, Entbündelung, BB 1997, 2437–2446.

Vorwerk, Volkert/Wolf, Christian: Beck’scher Online-Kommentar ZPO, 23. Edition, Stand: 01.12.2016, München 2016.

Wabnitz, Heinz-Bernd/Janovsky, Thomas: Handbuch des Wirtschafts- und Steuerstrafrechts, 4. Aufl., München 2014.

Wenzel, Jens: Bankgeschäftsrisiken bei Gesellschaften der Realwirtschaft, NZG 2013, 161–167.

Werner, Dennis: Verkehrspflichten privater IT-Nutzer in Bezug auf die Verbreitung von Schadsoftware, Baden-Baden 2010.

Wicker, Magda: Haftet der Cloud-Anbieter für Schäden beim Cloud-Nutzer? Relevante Haftungsfragen in der Cloud, MMR 2014,
715–718.

Wicker, Magda: Vertragstypologische Einordnung von Cloud Computing-Verträgen. Rechtliche Lösungen bei auftretenden
Mängeln, MMR 2012, 783–788.

Wirth, Christian/Paul, Frederik: Organisationspflichten nach § 64 a VAG – beginnende Vereinheitlichung der


Organisationspflichten in der Finanzwirtschaft, CCZ 2010, 95–102.

Wolff, Heinrich Amadeus/Brink, Stefan: Datenschutzrecht in Bund und Ländern, München 2013.

Zöller, Richard: ZPO, 31. Aufl., Köln 2016.

Fußnoten
1 Vgl. Initiativen wie cloudgermany, http://​www.​cloudgermany.​de/​index.​de.​html (zuletzt abgerufen am 05.12.2017) oder EuroCloud,
http://​www.​eurocloud.​de/​dachverband (zuletzt abgerufen am 05.12.2017).

2 Vgl. etwa zur Trusted German Insurance Cloud der Versicherungswirtschaft http://​www.​gdv.​de/​wp-content/​uploads/​2014/​03/​
GDV-Pressemitteilung​_ ​IT-Sicherheit_​P r%C3%BCfsiegel_​Versicherungsclo​ud_​2014.​pdf (zuletzt abgerufen am 05.12.2017).

3 Verordnung (EG) Nr. 593/2008 des Europäischen Parlaments und des Rates vom 17. Juni 2008 über das auf vertragliche
Schuldverhältnisse anzuwendende Recht (Rom I), ABl. Nr. L 177, 6.

4 Nägele/Jacobs, ZUM 2010, 281, 283; Nordmeier, MMR 2010, 151, 152; Stögmüller, in: Leupold/Glossner, Teil 6 F. III. Rn. 359.

5 Vgl. zur vertragstypologischen Einordnung nach nationalem Recht unten 2.1.2.

6 Borges, in: Borges/Meents, § 3 Rn. 17; Niemann/Paul, K&R 2009, 444, 446; Nordmeier, MMR 2010, 151; Schulz/Rosenkranz,
ITRB 2009, 232, 236; Splittgerber/Rockstroh, BB 2011, 2179, 2184; Stögmüller, in: Leupold/Glossner, Teil 6 F. III. Rn. 359.
7 Vgl. nur die NIST-Definition des Cloud Computing, siehe dazu Kapitel 2, 2.​2.

8 Niemann/Paul, K&R 2009, 444, 446; vgl. auch Nordmeier, MMR 2010, 151, 152; Wicker, MMR 2014, 787, 790.

9 EuGH, NJW 2011, 505, 508; BGH, NJW 2009, 298; Borges, in: Borges/Meents, § 3 Rn. 24; Hohloch, in: Erman, Art. 6 Rom I-
VO Rn. 25a; Pfeiffer/Weller/Nordmeier, in: Spindler/Schuster, Art. 6 Rom I-VO Rn. 13 ff.; Spickhoff, in: BeckOK-BGB, Art.
6 Rom I-VO Rn. 26; zu Art. 29 EGBGB auch Borges, Elektronischer Geschäftsverkehr, S. 874 ff.

10 EuGH, NJW 2011, 505, 508 f.; Sujecki, K&R 2012, 312, 315.

11 Martiny, in: MüKo-BGB, Art. 6 Rom I-VO Rn. 41; Schulz/Rosenkranz, ITRB 2009, 232, 236; a.A. offenbar Meents, in:
Lehmann/Meents, Kapitel 7 I. IV. 1. Rn. 263 Fn. 135.

12 Magnus, in: Staudinger, Art. 6 Rom I-VO Rn. 4; Martiny, in: MüKo-BGB, Art. 6 Rom I-VO Rn. 41; A. Staudinger, in: Schulze
u. a., Art. 6 Rom I-VO Rn. 14.

13 Borges, in: Borges/Meents, § 3 Rn. 26; Pfeiffer/Weller/Nordmeier, in: Spindler/Schuster, Art. 6 Rom I-VO Rn. 22; Spickhoff,
in: BeckOK-BGB, Art. 6 Rom I-VO Rn. 32.

14 Lehmann/Giedke, CR 2013, 608, 611; Redeker, Rn. 1132; von dem Busche/Schelinski, in: Leupold/Glossner, Teil 1 C. VIII. 1.
Rn. 384; Wicker, MMR 2012, 783, 784.

15 Nägele/Jacobs, ZUM 2010, 281, 284; Pohle/Ammann, CR 2009, 273, 274 f.; Schulz/Rosenkranz, ITRB 2009, 232;
Splittgerber/Rockstroh, BB 2011, 2179.

16 Grüneberg, in: Palandt, Überbl v § 311 Rn. 25; Busche, in: MüKo-BGB, § 631 Rn. 23; von dem Busche/Schelinski, in:
Leupold/Glossner, Teil 1 B. I. 3. Rn. 42.

17 Borges/Brennscheidt, in: Borges/Schwenk, Identitätsschutz, S. 54; Pohle/Ammann, CR 2009, 273, 275.

18 Eckhardt, in: Köhler-Schute, S. 170; Niemann/Paul, K&R 2009, 444, 446; Pohle/Ammann, CR 2009, 273, 274;
Schulz/Rosenkranz, ITRB 2009, 232, 233; siehe auch Borges/Brennscheidt, in: Borges/Schwenk, Identitätsschutz, S. 54 m.w.N.
19 Vgl. Kap.​ 2, 2.​2.

20 Brennscheidt, S. 42 f.; Eckhardt, in: Köhler-Schute, S. 171; Schuster/Reichl, CR 2010, 38, 40; Splittgerber/Rockstroh, BB
2011, 2179.

21 BGH, NJW 2007, 2394.

22 Ausdrücklich von einem Gleichlauf von ASP und SaaS sprechend Sujecki, K&R 2012, 312, 316; Pohle/Ammann, K&R 2009,
625, 627; Pohle/Ammann, CR 2009, 273, 275.

23 Pohle/Ammann, CR 2009, 273, 275; Schulz/Rosenkranz, ITRB 2009, 232, 233.

24 Redeker, Rn. 1131.

25 Vgl. Kap.​ 2, 2.​2.

26 Sujecki, K&R 2012, 312, 317; Nägele/Jacobs, ZUM 2010, 281, 284; Splittgerber/Rockstroh, BB 2011, 2179.

27 Vgl. Kap.​ 2, 2.​2.

28 Nägele/Jacobs, ZUM 2010, 281, 284; Pohle/Ammann, CR 2009, 273, 275; Schulz/Rosenkranz, ITRB 2009, 232, 233.

29 Vgl. Kap.​ 2, 2.​2.

30 A.A. Sujecki, K&R 2012, 312, 317, der einen Dienstvertrag annimmt.

31 Sujecki, K&R 2012, 312, 317; Nägele/Jacobs, ZUM 2010, 281, 284; Niemann/Paul, K&R 2009, 444, 447.

32 Wicker, MMR 2012, 783, 784.


33 Siehe oben 2.1.2.1.

34 So ausdrücklich Schuster, CR 2009, 205, 206; ähnlich Bräutigam, CR 2004, 248, 250; Niemann/Paul, K&R 2009, 444, 446.

35 Eckhardt, in: Köhler-Schute, S. 172.

36 Schulze, in: Schulze u. a., § 241 BGB Rn. 5; Sutschet, in: BeckOK-BGB, § 241 BGB Rn. 89; Teichmann, in: Jauernig, § 241
BGB Rn. 3.

37 Kramer/Meints, in: Hoeren/Sieber/Holznagel, Teil 16.5 F. I. 4. Rn. 61; Schmidl, NJW 2010, 476; Schultze-Melling, CR 2005,
73, 74.

38 Heckmann, MMR 2006, 280, 283; Roth/Schneider, ITRB 2005, 19, 20; bezogen auf Compliance Schmidl, NJW 2010, 476, 478;
vgl. auch Spindler, MMR 2008, 7, 8. Allgemein zur IT-Sicherheit: Beucher/Uzerath, MMR 2013, 362, 367; Borges,
Identitätsnachweis, S. 201; Heckmann, MMR 2006, 280, 281.

39 Siehe dazu unten Kap.​ 6, 2.​1.​1.​1.

40 BGH, NJW 2008, 3714.

41 OLG Brandenburg, CR 2006, 124, 125.

42 Vgl. allgemein zur Pflicht zur Sicherung der eigenen IT-Infrastruktur Werner, S. 146 ff.

43 Vgl. zur grundsätzlich vergleichbaren Situation der Geheimhaltungspflicht hinsichtlich der von der Bank zugeteilten PIN-Nummer
BGH, BKR 2004, 493, 494; LG Ulm, Urt. v. 20.10.2010 – 1 S 81/10; AG Frankfurt, Urt. v. 16.01.2007 – 30 C 1774/06; Borges,
NJW 2005, 3313, 3314; Maihold, in: Schimansky/Bunte/Lwowski, 2. Abschnitt, 9. Kapitel, § 55 VI. 4. Rn. 106.

44 Vgl. hierzu Maihold, in: Schimansky/Bunte/Lwowski, 2. Abschnitt, 9. Kapitel, § 55 VI. 4. Rn. 130 f.

45 Vgl. hierzu oben 2.1.2.


46 Borges/Brennscheidt, in: Borges/Schwenk, Identitätsschutz, S. 54; Schulz/Rosenkranz, ITRB 2009, 232, 233; Wicker, MMR
2014, 787.

47 Niemann/Paul, K&R 2009, 444, 446; vgl. auch Wicker, MMR 2014, 787, 788.

48 BGH, NJW-RR 2002, 13, 14; Becker, in: BeckOK-BGB, § 305 BGB Rn. 24; Stadler, in: Jauernig, § 305 BGB Rn. 4.

49 Basedow, in: MüKo-BGB, § 305 Rn. 21; Schulte-Nölke, in: Schulze u. a., § 305 BGB Rn. 5.

50 BGH, NJW 2006, 2976, 2977 Rn. 16; OLG Hamburg, CR 2002, 915, 916; Roloff, in: Erman, § 305 BGB Rn. 29; Schulte-Nölke,
in: Schulze u. a., § 305 BGB Rn. 15.

51 So auch bei BGH, NJW 2006, 2976, 2977 Rn. 16.

52 Roloff, in: Erman, § 305 c BGB Rn. 2; Stadler, in: Jauernig, § 305 c BGB Rn. 2.

53 Gleichwohl können die dort normierten Grundsätze im Rahmen des § 307 Abs. 1 BGB mittelbar auch für Verträge mit
Unternehmern relevant werden, vgl. Roloff, in: Erman, § 310 BGB Rn. 7 a.E.

54 BGH, NJW 2003, 886, 887; NJW 2000, 1110, 1112; Jacobs, in: BeckOK-BGB, § 307 BGB Rn. 31; Stadler, in: Jauernig, § 307
BGB Rn. 5.

55 Vgl. hierzu die Übersicht bei Roloff, in: Erman, § 307 BGB Rn. 23.

56 Siehe Kap.​ 6, 2.​1.​3.​2.

57 Redeker, in: Hoeren/Sieber/Holznagel, Teil 12 C. VII. Rn. 404; Söbbing, MMR 5/ 2008, XII, XIII.

58 Grundmann, in: MüKo-BGB, § 278 Rn. 49; Lorenz, in: BeckOK-BGB, § 278 BGB Rn. 50.

59 Vgl. hierzu Teichmann, in: Jauernig, Vor § 823 Rn. 3; Wagner, in: MüKo-BGB, § 823 Rn. 619.
60 Vgl. hierzu oben 2.1.1.

61 Verordnung (EG) Nr. 864/2007 des Europäischen Parlaments und des Rates vom 11. Juli 2007 über das auf außervertragliche
Schuldverhältnisse anzuwendende Recht (Rom II), ABl. Nr. L 199, S. 40.

62 Spickhoff, in: BeckOK-BGB, Art. 14 Rom II-VO Rn. 4 f.

63 Vgl. hierzu Pfeiffer/Weller/Nordmeier, in: Spindler/Schuster, Art. 6 Rom II-VO Rn. 2 f.

64 Intveen/Hilber/Rabus, in: Hilber, Teil 2 III. 3. a) Rn. 180.

65 Vgl. Kap.​ 2, 5.​1.​2, 5.​1.​3.

66 Intveen/Hilber/Rabus, in: Hilber, Teil 2 III. 3. a) Rn. 180; Nordmeier, MMR 2010, 151, 154 f.; Pfeiffer/Weller/Nordmeier, in:
Spindler/Schuster, Art. 4 Rom II-VO Rn. 15.

67 So auch Stögmüller, in: Leupold/Glossner, Teil 6 F. IV. Rn. 362.

68 Vgl. hierzu bereits oben 2.1.1.

69 Nordmeier, MMR 2010, 151, 155 f.; Pfeiffer/Weller/Nordmeier, in: Spindler/Schuster, Art. 4 Rom II-VO Rn. 15; ablehnend
Spickhoff, in: BeckOK-BGB, Art. 4 Rom II-VO Rn. 35.

70 Borges, in: Borges/Meents, § 12 Rn. 21.

71 Vgl. hierzu Junker, in: MüKo-BGB, Art. 40 EGBGB Rn. 30 ff.

72 Vgl. oben 2.2.


73 Schiemann, in: Erman, § 823 BGB Rn. 1; A. Staudinger, in: Schulze u. a., § 823 BGB Rn. 2; Teichmann, in: Jauernig, § 823
BGB Rn. 1.

74 OLG München, GRUR 2002, 453; Borges, Identitätsnachweis, S. 191; Borges et al., Identitätsdiebstahl, S. 212; Kunczik, ITRB
2013, 183; A. Staudinger, in: Schulze u. a., § 823 BGB Rn. 40; Teichmann, in: Jauernig, § 823 BGB Rn. 13; Wagner, in: MüKo-
BGB, § 823 Rn. 241.

75 BVerfG, NVwZ 1982, 367; BGH, GRUR 2002, 917, 919; Bamberger, in: BeckOK-BGB, § 12 BGB Rn. 6; Müller, in:
Spindler/Schuster, § 12 BGB Rn. 28.

76 Martinek, in: jurisPK-BGB, § 12 Rn. 4.

77 BGH, NJW 1994, 245, 247; Borges et al., Identitätsdiebstahl, S. 212; Dörner, in: Schulze u. a., § 12 BGB Rn. 4; Mansel, in:
Jauernig, § 12 BGB Rn. 5; Säcker, in: MüKo-BGB, § 12 Rn. 96; Saenger, in: Erman, § 12 BGB Rn. 21.

78 Hierzu sogleich unten 2.2.3.

79 Siehe Kap.​ 2, 5.​1.​1.

80 Vgl. Mössner, in: BeckOK-BGB, § 90 BGB Rn. 8; Koch, NJW 2004, 801, 803.

81 Zu § 202a StGB: Sprau, in: Palandt, § 823 BGB Rn. 70; Wagner, in: MüKo-BGB, § 823 Rn. 423; zu § 303a StGB: Hager, in:
Staudinger, § 823 BGB Rn. G 42; Roßnagel/Schnabel, NJW 2008, 3534, 3536.

82 Siehe dazu Mössner, in: BeckOK-BGB, § 90 BGB Rn. 89 ff.

83 G. Schiemann, in: Erman, § 823 BGB Rn. 13; Wagner, in: MüKo-BGB, § 823 Rn. 53; vgl. auch Geiß/Greiner, A. II. Rn. 57.

84 Vgl. Kap.​ 2, 4.​1.

85 Vgl. Borges et al., Identitätsdiebstahl, S. 212; Borges, Identitätsnachweis, S. 183; Borges/Brennscheidt, in: Borges/Schwenk,
Identitätsschutz, S. 50.
86 Förster, in: BeckOK-BGB, § 823 BGB Rn. 100, 102; A. Staudinger, in: Schulze u. a., § 823 BGB Rn. 61.

87 Borges et al., Identitätsdiebstahl, S. 212; Wicker, MMR 2014, 715, 717; implizit auch Heckmann, MMR 2006, 280, 283.

88 Werner, S. 145; a.A. Koch, NJW 2004, 801, 806.

89 Koch, NJW 2004, 801, 806; Wagner, in: MüKo-BGB, § 823 Rn. 48 a.E.; Weller, NJW 2007, 960, 961.

90 Vgl. hierzu bereits oben 2.1.3.

91 Eine derartige Pflicht nur für Unternehmer anerkennend Libertus, MMR 2005, 507, 512.

92 Siehe 5.5.

93 Müller-Broich, § 1 TMG Rn. 6; Sieber/Liesching, MMR-Beil. 2007, 1, 4.

94 Müller-Broich, § 1 TMG Rn. 6.

95 Sieber/Liesching, MMR-Beil. 2007, 1, 4.

96 Heckmann, in: jurisPK-Internetrecht, § 1 TMG Rn. 60.

97 Martini, in: BeckOK InfoMedienR, § 1 TMG Rn. 4.

98 Bedner, S. 52; Heidrich/Wegener, MMR 2010, 803, 805; Nolte, in: Borges/Meents, § 11 Rn. 26. Für SaaS und PaaS: Borges,
in: Borges/Meents, § 8 Rn. 26. Vgl. auch BGH, NJW 2013, 3245, 3247, welcher einen Share-Hoster als Diensteanbieter i.S.d.
TMG eingestuft hat. Dagegen anscheinend danach differenzierend, ob die Cloud-Leistung nur eine „Hilfsfunktion“ für das
eigentliche Telemedium darstellt Schuster/Reichl, CR 2010, 38, 42; ihm folgend Hartung/Storm, in: Hilber, Teil 4 I. Rn. 35.
99 Boos/Kroschwald/Wicker, ZD 2013, 205, 208; Nolte, in: Borges/Meents, § 11 Rn. 29.

100 Siehe zum Begriff Kap.​ 2, 2.​2.

101 Boos/Kroschwald/Wicker, ZD 2013, 205, 208; Nolte, in: Borges/Meents, § 11 Rn. 28.

102 Borges, in: Borges/Meents, § 12 Rn. 43.

103 BGH, NJW 1987, 372, 373; BGH, NJW 2001, 2019, 2020; BGH, NJW-RR 2003, 1459, 1460; Borges, in: Borges/Meents, § 12
Rn. 43; ders., Identitätsnachweis, S. 143; Förster, in: BeckOK-BGB, § 823 BGB Rn. 339 ff; Hager, in: Staudinger, BGB, § 823
Rn. E 34. Behördliches Gebot als Mindeststandard: BayObLG, NJW-RR 2002, 1249, 1250.

104 Gerlach, CR 2015, 581, 589.

105 Roßnagel, MMR 2015, 359.

106 Für das Online-Banking: Borges, in Derleder/Knops/Bamberger, § 11 Rn. 27.

107 Borges, in Derleder/Knops/Bamberger, § 11 Rn. 366; Borges et al., Identitätsdiebstahl, S. 312; Zimmermann, in: MüKo-ZPO,
§ 371a Rn. 2.

108 Verordnung (EU) 2016/679 des Europäischen Parlaments und des Rates vom 27. April 2016 zum Schutz natürlicher Personen
bei der Verarbeitung personenbezogener Daten, zum freien Datenverkehr und zur Aufhebung der Richtlinie 95/46/EG.

109 Richtlinie 95/46/EG des Europäischen Parlaments und des Rates vom 24. Oktober 1995 zum Schutz natürlicher Personen bei
der Verarbeitung personenbezogener Daten und zum freien Datenverkehr.

110 Eingeführt durch das Gesetz zur Anpassung des Datenschutzrechts an die Verordnung (EU) 2016/679 und zur Umsetzung der
Richtlinie (EU) 2016/680 (Datenschutz-Anpassungs- und- Umsetzungsgesetz EU – DSAnpUG-EU) vom 30.06.2017, BGBl. I, S.
2097. Vgl. zur Entstehungsgeschichte den Gesetzesentwurf der Bundesregierung „Entwurf eines Gesetzes zur Anpassung des
Datenschutzrechts an die Verordnung (EU) 2016/679 und zur Umsetzung der Richtlinie (EU) 2016/680 (Datenschutz-
Anpassungs- und -Umsetzungsgesetz EU – DSAnpUG-EU)“, BR- Drucksache 110/17 vom 02.02.2017, abrufbar unter http://​
www.​bundesrat.​de/​SharedDocs/​drucksachen/​2017/​0101-0200/​110-17.​pdf?​_ ​_ ​blob=​publicationFile&​v=​5 (zuletzt abgerufen am
12.12.2017), dem der Deutsche Bundestag am 27.04.2017 (Plenarprotokoll 18/231, S. 23306, abrufbar unter http://​dipbt.​bundestag.​
de/​doc/​btp/​18/​18231.​pdf, zuletzt abgerufen am 12.12.2017) und der Deutsch Bundesrat am 12.05.2017 (Plenarprotokoll 957.
Sitzung, S. 225, abrufbar unter http://​www.​bundesrat.​de/​plpr.​html?​id=​2017-0957, zuletzt abgerufen am 12.12.2017) zugestimmt
hat. Der zugrundeliegende Referentenentwurf für ein Allgemeines Bundesdatenschutzgesetz (ABDSG) ist abrufbar unter https://​
www.​datenschutz-grundverordnung.​eu/​wp-content/​uploads/​2016/​09/​Entwurf-ABDSG-E-08.​2016.​pdf (zuletzt abgerufen am
12.12.2017).

111 Gola/Klug/Körffer, in: Gola/Schomerus, § 3 BDSG Rn. 3; Plath/Schreiber, in: Plath, § 3 BDSG Rn. 12; Schild, in:
Wolff/Brink, § 3 BDSG Rn. 27.

112 Borges et al., Identitätsdiebstahl, S. 204; Gola/Klug/Körffer, in: Gola/Schomerus, § 3 BDSG Rn. 6 f.; Weichert, in:
D/K/W/W, § 3 BDSG Rn. 19.

113 Siehe etwa Borges, in: Borges/Meents, § 6 Rn. 22; Gola/Schomerus, § 3 BDSG Rn. 10; Dammann, in: Simitis, § 3 BDSG Rn.
32; Spindler/Nink, in: Spindler/Schuster, § 11 TMG Rn. 5a; ebenso der EuGH, CR 2016, 791 Rn. 42 ff.; ausführlich zum
Streitstand Bergt, ZD 2015, 365 ff.

114 Vgl. hierzu bereits Kap.​ 2, 3.​1.

115 Forgó/Krügel, MMR 2010, 17, 22; Krüger/Maucher, MMR 2011, 433, 434; Spindler/Nink, in: Spindler/Schuster, § 11 TMG
Rn. 5 b.

116 So auch für den Fall des Identitätsdiebstahls bzw. -missbrauchs Borges et al., Identitätsdiebstahl, S. 204.

117 Meyerdierks, MMR 2009, 8, 8 f.

118 Meyerdierks, MMR 2013, 705.

119 AG München, ZUM-RD 2009, 413, 414; Gola/Klug/Körffer, in: Gola/Schomerus, § 3 BDSG Rn. 10a; Meyerdierks, MMR
2009, 8, 13; Schmitz, in: Hoeren/Sieber/Holznagel, Teil 16.2 B. III. Rn. 109; selbst für statische IP-Adressen u. U. verneinend
Meyerdierks, MMR 2013, 705, 708.

120 AG Berlin, CR 2008, 194, 195; Lüghausen, K&R 2011, 458, 461; Schild, in: Wolff/Brink, § 3 BDSG Rn. 21.

121 Lerch et al., MMR 2010, 454, 456; Plath/Schreiber, in: Plath, § 3 BDSG Rn. 21; Spindler/Nink, in: Spindler/Schuster, § 11
TMG Rn. 8.
122 Vgl. hierzu BGH, NJW 2015, 368.

123 EuGH, CR 2016, 791 Rn. 45 f.

124 Gola/Klug/Körffer, in: Gola/Schomerus, § 3 BDSG Rn. 48.

125 Weichert, in: D/K/W/W, § 3 BDSG Rn. 54.

126 OVG Schleswig, NJW 2013, 1977.

127 OVG Schleswig, NJW 2013, 1977, 1979.

128 EuGH, EuZW 2014, 541, 544 f.

129 EuGH, EuZW 2014, 541, 544 f.

130 EuGH, K&R 2015, 719 Rn. 29.

131 Problematisch ist die Frage, welches mitgliedstaatliche Recht bei mehreren Anknüpfungspunkten im räumlichen
Geltungsbereich der DS-RL Anwendung findet, siehe dazu ausführlich Borges, in: Borges/Meents, § 9 Rn. 41 ff.

132 Dammann, in: Simitis, § 1 BDSG Rn. 241; Kühling/Martini, EuZW 2016, 448, 450; Piltz, K&R 2016, 557, 559; Roßnagel,
DuD 2016, 561, 562; Schantz, NJW 2016, 1841, 1842; Spindler, DB 2016, 937, 938.

133 Borges et al., Identitätsdiebstahl, S. 205; Gola/Klug/Körffer, in: Gola/Schomerus, § 9 BDSG Rn. 1; Plath, in: Plath, § 9
BDSG Rn. 1; Wedde, in: D/K/W/W, § 9 BDSG Rn. 1.

134 Gola/Klug/Körffer, in: Gola/Schomerus, § 9 BDSG Rn. 7; Plath in: Plath, § 9 BDSG Rn. 14.
135 Vgl. hierzu oben 2.1.3.

136 Wedde, in: D/K/W/W, § 9 BDSG Rn. 25.

137 Grages, in: Plath, Art. 32 DSGVO Rn. 1.

138 Grages, in: Plath, Art. 32 DSGVO Rn. 9.

139 Haag, in: Leupold/Glossner, Teil 4 C. III. Rn. 47; Niemann/Hennrich, CR 2010, 686, 687; Thüsing/Pötters, in: Thüsing,
Beschäftigtendatenschutz und Compliance, § 15 III. Rn. 21.

140 Wedde, in: D/K/W/W, § 11 BDSG Rn. 5.

141 Borges, in Borges/Meents, § 7 Rn. 8; Gola/Klug/Körffer, in: Gola/Schomerus, § 11 BDSG Rn. 9.

142 Engels, K&R 2011, 548, 550; Spindler/Nink, in: Spindler/Schuster, § 11 BDSG Rn. 10.

143 Borges/Brennscheidt, in: Borges/Schwenk, Identitätsschutz, S. 63, Engels, K&R 2011, 548, 551; Nägele/Jacobs, ZUM 2010,
281, 290.

144 Borges, in Borges/Meents, § 7 Rn. 8; Niemann/Hennrich, CR 2010, 686, 687; Gaul/Koehler, BB 2011, 2229, 2231; vgl.
hierzu bereits Fn. 140.

145 Borges, in Borges/Meents, § 7 Rn. 3; Petri, in: Simitis, § 11 BDSG Rn. 48.

146 Borges, in Borges/Meents, § 7 Rn. 2, 124; Brennscheidt, Cloud Computing und Datenschutz, S. 87 f.; Petri, in: Simitis, § 11
BDSG Rn. 56, 97.

147 Plath, in: Plath, Art. 28 DSGVO Rn. 2.

148 Plath, in: Plath, Art. 28 DSGVO Rn. 2; wohl auch Petri, ZD 2015, 305, 306.
149 Petri, ZD 2015, 305, 306.

150 Plath, in: Plath, Art. 28 DSGVO Rn. 8.

151 Heckmann, in: JurisPK-Internetrecht, § 15 TMG Rn. 357; Spindler/Nink, in: Spindler/Schuster, § 15 TMG Rn. 2.

152 Heckmann, in: jurisPK-Internetrecht, § 15 TMG Rn. 362; Hullen/Roggenkamp, in: Plath, § 15 TMG Rn. 15; Spindler/Nink,
in: Spindler/Schuster, § 15 TMG Rn. 6.

153 Müller-Broich, § 13 TMG Rn. 1.

154 Vgl. Heckmann, in: jurisPK-Internetrecht, § 13 TMG Rn. 245 ff.

155 Vgl. hierzu Hullen/Roggenkamp, in: Plath, § 13 TMG Rn. 23.

156 So zu Art. 89 des Ratsentwurfs der DSGVO Keppeler, MMR 2015, 779, 781; zum Kommissionsentwurf Gola/Schulz, ZD
2013, 475, 477; Nebel/Richter, ZD 2012, 407, 408.

157 Zum Ratsentwurf Keppeler, MMR 2015, 779, 781.

158 Vgl. oben Fn. 146.

159 Gola/Klug/Körffer, in: Gola/Schomerus, § 7 BDSG Rn. 15.

160 Gabel, in:Taeger/Gabel, § 7 BDSG Rn. 10; Gola/Klug/Körffer, in: Gola/Schomerus, § 7 BDSG Rn. 12; Quaas, in:
Wolff/Brink, § 7 BDSG Rn. 55; Simitis, in: Simitis, § 7 BDSG Rn. 30 f.

161 Scheja/Haag, in: Leupold/Glossner, Teil 5 E. XVIII. 1. Rn. 366.


162 Sprau, in: Palandt, § 823 Rn. 124; ständige Rechtsprechung, vgl. nur BGH NJW 2005, 215.

163 Siehe dazu oben 5.4.1.

164 Quaas, in: Wolf/Brink, § 7 BDSG Rn. 8.

165 Becker, in: Plath, Art. 82 DSGVO Rn. 6.

166 Eingeführt durch das Gesetz zur Umsetzung der Richtlinie 2013/36/EU über den Zugang zur Tätigkeit von Kreditinstituten und
die Beaufsichtigung von Kreditinstituten und Wertpapierfirmen und zur Anpassung des Aufsichtsrechts an die Verordnung (EU)
Nr. 575/2013 über die Aufsichtsanforderungen an Kreditinstitute und Wertpapierfirmen (CRD IV-Umsetzungsgesetz) vom
28.08.2013, BGBl. I, S. 3395.

167 Wolfgarten, in: Boos/Fischer/Schulte-Mattler, § 25b KWG Rn. 1.

168 BaFin, Erläuterungen zur MaRisk, Fassung vom 27.10.2017, AT 9 S. 33 ff., abrufbar unter https://​www.​bafin.​de/​SharedDocs/​
Downloads/​DE/​Rundschreiben/​dl_​rs0917_​marisk_​Endfassung_​2017_​pdf_​ba.​pdf?​_ ​_ ​blob=​publicationFile&​v=​5 (zuletzt abgerufen
am 12.12.2017).

169 Vgl. hierzu Fett, in: Schwark/Zimmer/Fett, § 33 WPHG Rn. 51.

170 BGH, NJOZ 2006, 4083, 4086; Knierim, in: Wabnitz/Janovsky, 10. Kapitel D. 2. Rn. 272; Wenzel, NZG 2013, 161, 163.

171 Schäfer, in: Boos/Fischer/Schulte-Mattler, § 1 KWG Rn. 21.

172 Hopt, in: Baumbach/Hopt, § 1 HGB Rn. 23; Kindler, in: Ebenroth et al., § 1 HGB Rn. 49 ff.

173 Vgl. hierzu Häberle, in: Erbs/Kohlhaas, § 1 KWG Rn. 5; Schäfer, in: Boos/Fischer/Schulte-Mattler, § 1 KWG Rn. 25 f.

174 Schäfer, in: Boos/Fischer/Schulte-Mattler, § 1 KWG Rn. 31.


175 MaRisk, Stand 27.10.2017, AT 9.1.

176 Wolfgarten, in: Boos/Fischer/Schulte-Mattler, § 25b KWG Rn. 21.

177 Kaetzler/Weirauch, BKR 2008, 265, 268; MaRisk, Stand 27.10.2017, AT 9.2.

178 Wolfgarten, in: Boos/Fischer/Schulte-Mattler, § 25b KWG Rn. 42; sehr weitgehend „reine Hilfstätigkeiten“ per se
ausklammernd Gürtler, in: Albrecht/Karahan/Lenenbach, XIV. 5. Rn. 441.

179 Vgl. hierzu Braun/Wolfgarten, in: Boos/Fischer/Schulte-Mattler, § 25b KWG Rn. 42; Kaetzler/Weirauch, BKR 2008, 265,
268.

180 Häberle, in: Erbs/Kohlhaas, § 25a KWG Rn. 3; Kaetzler/Weirauch, BKR 2008, 265, 267; MaRisk, Stand 27.10.2017, AT 9.4;
vgl. auch Niemann/Paul, K&R 2009, 444, 451.

181 Richtlinie (EU) 2015/2366 des Europäischen Parlaments und des Rates vom 25. November 2015 über Zahlungsdienste im
Binnenmarkt, zur Änderung der Richtlinien 2002/65/EG, 2009/110/EG und 2013/36/EU und der Verordnung (EU) Nr. 1093/2010
sowie zur Aufhebung der Richtlinie 2007/64/EG, ABl. EU Nr. L 337/35 v. 23.12.2015.

182 Borges, ZBB 2016, 249, 254.

183 Borges, ZBB 2016, 249, 256.

184 Vgl. Kap.​ 3, 3.​1, 3.​5.

185 Borges, in: FS Herberger, 173, 178 ff.; Borges, ZBB 2016, 249, 256.

186 Jung, in: Eichenhofer/Wenner, § 80 SGB X Rn. 15.

187 Bieresborn, in: v. Wulffen/Schütze, § 80 SGB X Rn. 13.


188 Kritisch hierzu Rammos/Vonhoff, CR 2013, 265, 267.

189 Bieresborn, in: v. Wulffen/Schütze, § 80 SGB X Rn. 13d; Rammos/Vonhoff, CR 2013, 265, 267; Rombach, in: Hauck/Noftz, §
80 SGB X Rn. 35.

190 Rammos/Vonhoff, CR 2013, 265, 267 verweisen auf das „enorme Einsparungspotential“.

191 Siehe zum Begriff Kap.​ 2, 2.​2.

192 So anscheinend Rammos/Vonhoff, CR 2013, 265, 267.

193 Siehe zum Begriff Kap.​ 2, 2.​2.

194 Redeker, in: Hoeren/Sieber/Holznagel, Teil 12 C. VII. 5. Rn. 408.

195 BT-Drs. 12/6334, S. 11.

196 Siehe Kap.​ 6, 3.​2.​1.

197 Borges et al., Identitätsdiebstahl, S. 199.

198 Prütting, in: MüKo-ZPO, § 286 ZPO Rn. 111.

199 Vgl. zum Vertragsrecht oben 2.1.3 und zum Deliktsrecht oben 2.2.2 und 2.2.3.

200 Oetker, in: MüKo-BGB, § 249 BGB Rn. 480.

201 BGH, NJW 2008, 982, 984 Rn. 16; Bacher, in: BeckOK-ZPO, § 284 ZPO Rn. 84; Knerr, in: Geigel, 3. Teil 37. Kapitel 9 Rn.
65; Stadler, in: Musielak/Voit, § 138 ZPO Rn. 10; Wagner, in: MüKo-ZPO, § 138 ZPO Rn. 21.
202 Prütting, in: MüKo-ZPO, § 286 ZPO Rn. 103.

203 Prütting, in: MüKo-ZPO, § 286 ZPO Rn. 48; Saenger, in: Saenger, § 286 ZPO Rn. 39; a.A. Greger, in: Zöller, Vor § 284 Rn.
29.

204 BGH, NJW-RR 2014, 1115, 1116 Rn. 9; Bacher, in: BeckOK-ZPO, § 284 ZPO Rn. 94; Borges, Verträge, S. 491 ff.; ders.,
Identitätsnachweis, S. 232; Prütting, in: MüKo-ZPO, § 286 ZPO Rn. 48, 65; Rosenberg/Schwab/Gottwald, § 113 Rn. 17, 36.

205 BGH, BKR 2012, 128, 129; OLG Frankfurt, MMR 2009, 856; AG Osnabrück, NJW 1998, 688; vgl. auch Borges,
Identitätsnachweis, S. 234.

206 Vgl. hierzu Bacher, in: BeckOK-ZPO, § 284 ZPO Rn. 98; Prütting, in: MüKo-ZPO, § 286 ZPO Rn. 65.

207 Siehe Kap.​ 6, 6.​2.

208 Vgl. etwa zur Entlastungsverpflichtung des Produzenten von Wirtschaftsgütern BGH, NJW 1975, 1827, 1828; des Arztes nach
Behandlungsfehlern BGH, NJW 1969, 553, 553 f.

209 Vgl. die Aufzählung bei Lenckner/Eisele, in: Schönke/Schröder, § 203 StGB Rn. 34 ff.

210 Vgl. hierzu Lackner, in: Lackner/Kühl, § 203 StGB Rn. 7 ff.

211 Zu dieser Begrifflichkeit sogleich ausführlich unten 7.3.

212 Vgl. hierzu Cierniak/Pohlit, in: MüKo-StGB, § 203 Rn. 120.

213 Cierniak/Pohlit, in: MüKo-StGB, § 203 Rn. 11; Lackner, in: Lackner/Kühl, § 203 StGB Rn. 14; Lenckner/Eisele, in:
Schönke/Schröder, § 203 StGB Rn. 5; Kargl, in: Kindhäuser/Neumann/Paeffgen, § 203 StGB Rn. 6; Weidemann, in: BeckOK-
StGB, § 203 Rn. 4.

214 BGH, NJW 1995, 2915, 2916; Cierniak/Pohlit, in: MüKo-StGB, § 203 Rn. 48; Weidemann, in: BeckOK-StGB, § 203 Rn. 31.
215 Kargl, in: Kindhäuser/Neumann/Paeffgen, § 203 StGB Rn. 21; Lenckner/Eisele, in: Schönke/Schröder, § 203 StGB Rn. 19b;
Kroschwald/Wicker, CR 2012, 758, 760; Redeker, ITRB 2014, 232; Spickhoff, Medizinrecht, § 203–§ 205 StGB Rn. 29; implizit
auch BGH, NJW 1991, 2955, 2957; differenzierend Ramos/Vonhoff, CR 2013, 265, 269 f.; offen lassend Conrad/Fechtner, CR
2013, 137, 138.

216 Cierniak/Pohlit, in: MüKo-StGB, § 203 Rn. 52; anscheinend auch Härting, ITRB 2011, 242, 243; andeutungsweise auch
Lackner, in: Lackner/Kühl, § 203 StGB Rn. 17; Weidemann, in: BeckOK-StGB, § 203 Rn. 31 a.E.

217 So i. E. auch Kargl, in: Kindhäuser/Neumann/Paeffgen, § 203 StGB Rn. 21.

218 Kroschwald/Wicker, CR 2012, 758, 760; Lenckner/Eisele, in: Schönke/Schröder, § 203 StGB Rn. 19b; Rammos/Vonhoff, CR
2013, 265, 272; Redeker, ITRB 2014, 232.

219 Siehe zum Begriff Kap.​ 2, 2.​2.

220 Vgl. hierzu Kroschwald/Wicker, CR 2012, 758, 760.

221 Lackner, in: Lackner/Kühl, § 203 StGB Rn. 11b; Lenckner/Eisele, in: Schönke/Schröder, § 203 StGB Rn. 64.

222 Kargl, in: Kindhäuser/Neumann/Paeffgen, § 203 StGB Rn. 38a; Weidemann, in: BeckOK-StGB, § 203 Rn. 22.

223 Maisch/Seidl, DSB 2012, 127, 128 f.; Oetterich, DStR 2482, 2484; Redeker, ITRB 2014, 232, 233; einschränkend
Rammos/Vonhoff, CR 2013, 265, 271.

224 Jandt/Nebel, NJW 2013, 1570, 1575; Kroschwald/Wicker, CR 2012, 758, 762; Lenckner/Eisele, in: Schönke/Schröder, § 203
StGB Rn. 19b; i. E. auch Kargl, in: Kindhäuser/Neumann/Paeffgen, § 203 StGB Rn. 38a a.E.; Lackner, in: Lackner/Kühl, § 203
StGB Rn. 11b.

225 Gesetz zur Neuregelung des Schutzes von Geheimnissen bei der Mitwirkung Dritter an der Berufsausübung schweigepflichtiger
Personen vom 30.10.2017, BGBl. I, S. 3618.

226 Im Falle der Beschäftigten war bereits nach alter Rechtslage anerkannt, dass eine Weitergabe an sie durch den
Berufsgeheimnisträger nicht strafbar sein sollte, da sie selbst als „Gehilfen“ im Sinne des § 203 Abs. 3 S. 2 StGB bei
Geheimnisoffenbarung ihrerseits strafrechtlich sanktioniert werden, vgl. Cierniak/Pohlit in MüKo-StGB, Bd. 4, 2. Auflage 2012,
§ 203, Rn. 50 m.w.N. Eine explizite Tatbestandsausnahme existierte jedoch nicht.
227 Art. 1 Abs. 2 lit. c des Gesetzes zur Neuregelung des Schutzes von Geheimnissen bei der Mitwirkung Dritter an der
Berufsausübung schweigepflichtiger Personen (neuer § 203 Abs. 3 StGB).

228 Gesetzesentwurf der Bundesregierung, abrufbar unter https://​www.​bmjv.​de/​SharedDocs/​Gesetzgebungsver​fahren/​Dokumente/​


ReGE_​Neuregelung_​Schutzes_​von_​Geheimnissen_​bei_​Mitwirkung_​Dritter_​an_​der_​Berufsausuebung_​schweigepflichti​ger_​
Personen.​pdf_​_ ​blob=​publicationFile&​v=​2 (zuletzt abgerufen am 12.12.2017); Referentenentwurf des Bundesjustizministeriums,
abrufbar unter https://​www.​bmjv.​de/​SharedDocs/​Gesetzgebungsver​fahren/​Dokumente/​RefE_​Neuregelung_​Schutzes_​von_​
Geheimnissen_​bei_​Mitwirkung_​Dritter_​an_​der_​Berufsausuebung_​schweigepflichti​ger_​P ersonen.​pdf (zuletzt abgerufen am
12.12.2017).

229 Gesetzesentwurf der Bundesregierung, S. 18; ebenso Referentenentwurf S. 13, 18, 31.

230 Gesetzesentwurf der Bundesregierung, Begründung zu § 203 Abs. 4 StGB-E, S. 2, 24.

231 Art. 1 Abs. 2 lit. c des Gesetzes zur Neuregelung des Schutzes von Geheimnissen bei der Mitwirkung Dritter an der
Berufsausübung schweigepflichtiger Personen (neuer § 203 Abs. 4 S. 1 Alt. 1 StGB).

232 Art. 1 Abs. 2 lit. c des Gesetzes zur Neuregelung des Schutzes von Geheimnissen bei der Mitwirkung Dritter an der
Berufsausübung schweigepflichtiger Personen (neuer § 203 Abs. 4 S. 2 Nr. 1 und 2 StGB). Nicht zur Geheimhaltung verpflichtet
werden müssen externe Dienstleister, die selbst Täter nach §§ 203 Abs. 1 oder Abs. 2 StGB sein könnten (also auch
Berufsgeheimnisträger oder ihnen gleichgestellte Personen sind).

233 Herrmann, in: BeckOK-VwVfG, § 30 VwVfG vor Rn. 1.

234 Kallerhoff, in: Stelkens/Bonk/Sachs, § 30 VwVfG Rn. 1.

235 Vgl. etwa § 10 BImSchG Abs. 2, 3; § 17a GenTG oder § 22 ChemG; § 9 KWG; § 203 StGB.

236 Kallerhoff, in: Stelkens/Bonk/Sachs, § 30 VwVfG Rn. 4.

237 Vgl. die Nachweise oben in Fn. 235.

Herrmann, in: BeckOK-VwVfG, § 30 VwVfG Rn. 3.


Herrmann, in: BeckOK-VwVfG, § 30 VwVfG Rn. 3.
238

239 Herrmann, in: BeckOK-VwVfG, § 30 VwVfG Rn. 7; Kallerhoff, in: Stelkens/Bonk/Sachs, § 30 VwVfG Rn. 6; vgl. auch v.
Zeschwitz, NJW 1983, 1873, 1881.

240 Herrmann, in: BeckOK-VwVfG, § 30 Rn. 6.

241 Knemeyer, NJW 1984, 2241, 2243; ähnlich Herrmann, in: BeckOK-VwVfG, § 30 VwVfG Rn. 8; anscheinend enger
Kallerhoff, in: Stelkens/Bonk/Sachs, § 30 VwVfG Rn. 9; weiter Pohl, BB 1995, 2093, 2094.

242 Herrmann, in: BeckOK-VwVfG, § 30 VwVfG Rn. 9.

243 Tschentscher/Neumann, BB 1997, 2437, 2440 f.

244 Kallerhoff, in: Stelkens/Bonk/Sachs, § 30 VwVfG Rn. 17.

245 Vgl. etwa § 30 Abs. 4 AO oder § 99 Abs. 1 VwGO.

246 BVerwG, NJW 1970, 1760, 1761; VG Berlin, Urt. v. 14.06.1982 – 14 A 10081; Herrmann, in: BeckOK-VwVfG, § 30 VwVfG
Rn. 20; Kallerhoff, in: Stelkens/Bonk/Sachs, § 30 VwVfG Rn. 20.

247 Dix, in: Simitis, § 1 BDSG Rn. 194.

248 Vgl. Gola/Klug/Körffer, in: Gola/Schomerus, § 11 BDSG Rn. 2, welche bei Daten, die dem Steuergeheimnis unterliegen in
Bezug auf die Auftragsdatenverarbeitung auf die besonderen Anforderungen des § 30 AO verweisen.

249 Siehe zum Begriff Kap.​ 2, 2.​2.

250 Heckel, NVwZ 1994, 224, 225.

251 Kallerhoff, in: Stelkens/Bonk/Sachs, § 30 VwVfG Rn. 22; Knemeyer, NJW 1984, 2241, 2244.
252 Knemeyer, NJW 1984, 2241, 2244.

253 Herrmann, in: BeckOK-VwVfG, § 30 VwVfG Rn. 22.

254 Herrmann, in: BeckOK-VwVfG, § 30 VwVfG Rn. 23.

255 Kallerhoff, in: Stelkens/Bonk/Sachs, § 30 VwVfG Rn. 29.

256 Intemann, in: Koenig, § 30 AO Rn. 41; vgl. auch Krömker, in: Lippross/Seibel, § 30 AO Rn. 6.

257 Vgl. hierzu Krömker, in: Lippross/Seibel, § 30 AO Rn. 22.

258 BVerwG, NVwZ 1982, 503, 505; BFH, Urt. v. 07.07.2008 – II B 9/07; NVwZ 1988, 474, 476; Intemann, in: König, § 30 AO
Rn. 123; Rüsken, in: Klein, § 30 AO Rn. 71a.

259 Vgl. die Auflistung bei Drüen, in: Tipke/Kruse, § 30 AO Rn. 74 ff.

260 Vgl. hierzu bereits oben 6.2.1.

261 Schreiber, in: Plath, § 5 BDSG Rn. 7.

262 Gola/Klug/Körffer, in: Gola/Schomerus, § 5 BDSG Rn. 8.

263 Schmidt, in: Wolff/Brink, § 5 BDSG Rn. 1.

264 Ambs, in: Erbs/Kohlhaas, § 5 BDSG Rn. 4.

265 Ambs, in: Erbs/Kohlhaas, § 5 BDSG Rn. 4; Gola/Klug/Körffer, in: Gola/Schomerus, § 5 BDSG Rn. 4; Schreiber, in: Plath, § 5
BDSG Rn. 4.
266 Schmidt, in: Wolff/Brink, § 5 BDSG Rn. 6.

267 Vgl. hierzu Gola/Klug/Körffer, in: Gola/Schomerus, § 5 BDSG Rn. 10 ff.

268 Schmit, in: Stelkens/Bonk/Sachs, § 3a VwVfG Rn. 1.

269 Prell, NVwZ 2013, 1514, 1515.

270 Ohlenburg, NVwZ 2005, 15, 16; vgl. auch BVerfG, NJW 2000, 1175, 1178; Lachmann, NJW 1987, 2206, 2210.

271 Vgl. hierzu Zimmermann, in: MüKo-ZPO, § 169 GVG Rn. 3.

272 So i. E. auch Lachmann, NJW 1987, 2206, 2208.

273 So dem Grunde nach auch BVerfG, NJW 2000, 1175, 1178.

274 Rudisile, in: Schoch/Schneider/Bier, § 99 VwGO Rn. 17.

275 Posser, in: BeckOK-VwGO, § 99 Rn. 22.

276 OVG Münster, NVwZ-RR 2005, 749, 751; BayVGH, B. v. 24.10.1977 – 280 VI 76; Rudisile, in: Schoch/Schneider/Bier, § 99
VwGO Rn. 18.

277 Vgl. zur Kasuistik ausführlich Rudisile, in: Schoch/Schneider/Bier, § 99 VwGO Rn. 19 ff.

278 Vgl. hierzu Posser, in: BeckOK-VwGO, § 99 Rn. 28.

279 Ohlenburg, NVwZ 2005, 15, 16.


280 Diemer, in: KK-StPO, § 169 GVG Rn. 1.

281 Vgl. Allgayer, in: BeckOK-StPO, § 171b GVG Rn. 1; Diemer, in: KK-StPO, § 171b GVG Rn. 3; Zimmermann, in: MüKo-
ZPO, § 171b GVG Rn. 9.

282 Diemer, in: KK-StPO, § 171b GVG Rn. 4.

283 Allgayer, in: BeckOK-StPO, § 171b GVG Rn. 4.

284 Diemer, in: KK-StPO, § 171b GVG Rn. 4.

285 Vgl. hierzu bereits oben 8.1.2.2.

286 Allgayer, in: BeckOK-StPO, § 172 GVG Rn. 6; Diemer, in: KK-StPO, § 172 GVG Rn. 8; Zimmermann, in: MüKo-ZPO, § 172
GVG Rn. 7.

287 Diemer, in: KK-StPO, § 171b GVG Rn. 7.

288 Zimmermann, in: MüKo-ZPO, § 171b GVG Rn. 20.


© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018
Georg Borges und Brigitte Werners (Hrsg.), Identitätsmanagement im Cloud Computing, https://doi.org/10.1007/978-3-662-55584-
2_5

5. Quantitative Entscheidungsunterstützung für ein


sicheres Identitäts- und Zugriffsmanagement
Andreas Schilling1 und Brigitte Werners2
(1) Ruhr-Universität Bochum, Fakultät für Wirtschaftswissenschaft, 44780 Bochum, Deutschland
(2) Ruhr-Universität Bochum, Fakultät für Wirtschaftswissenschaft, 44780 Bochum, Deutschland

Andreas Schilling (Korrespondenzautor)


Email: andreas.schilling@rub.de

Brigitte Werners
Email: or@rub.de

1 Einleitung
2 Struktur des quantitativen Entscheidungsmodells
2.1 Bewertungssystem und -skala
2.2 Assets und Schutzziele
2.2.1 Kundendaten
2.2.2 Kunden-Zahlungsdaten
2.2.3 Geschäftskritische Daten
2.2.4 Sensitive (unternehmensinterne) Daten
2.2.5 Archivierte Daten
2.3 Bedrohungsszenarien
2.3.1 Externe Bedrohungen
2.3.1.1 Keylogger
2.3.1.2 Phishing
2.3.1.3 Pharming
2.3.1.4 Brute-Force-Angriff
2.3.1.5 Man-in-the-Middle-Angriff
2.3.1.6 Cross-Site-Scripting (XSS)
2.3.1.7 Trojaner
2.3.1.8 Replay-Angriff
2.3.1.9 Kopien-Angriff
2.3.2 Interne Bedrohungen
2.3.2.1 Shoulder Surfing
2.3.2.2 Dumpster Diving
2.4 Maßnahmen zur sicheren Authentifizierung (engl. safeguards)
3 Optimale Auswahl von Sicherheitsmaßnahmen für ein sicheres Identitäts- und
Zugriffsmanagement
3.1 Entscheidungssituation bei der Maßnahmenauswahl
3.2 Modelldefinition
3.3 Datengrundlage zur optimalen Maßnahmenauswahl
3.4 Auswertung und Ergebnisdiskussion
3.4.1 Mittelständisches Unternehmen (Szenario 1)
3.4.2 Kreditwirtschaft (Szenario 2)
3.4.3 Sozialleistungsträger (Szenario 3)
3.4.4 Berufsgeheimnisträger (Szenario 4)
3.4.5 Verbraucher (Szenario 5)
Literatur

1 Einleitung
Um Risiken im Cloud Computing, insbesondere bei der Identifizierung und Authentifizierung,
beurteilen zu können, müssen verschiedenste Aspekte beachtet werden.1 Ziel ist eine ganzheitliche
Berücksichtigung möglichst aller Einflussfaktoren und deren Auswirkungen auf die Sicherheit des
Gesamtsystems. Aufgrund der Komplexität der Problemstellung ist es sinnvoll, das Problem
zunächst zu strukturieren, um eine Grundlage für eine detaillierte quantitative Evaluation zu
schaffen.2
Das Identitäts- und Zugriffsmanagement im Cloud Computing ist durch eine Vielzahl
verschiedener technischer und organisatorischer Maßnahmenalternativen gekennzeichnet. In der
Praxis werden je nach Einsatzszenario und Anwendungsfall unterschiedliche Maßnahmen bzw.
Maßnahmenkombinationen (Mehr-Faktor Authentifizierung) zum Schutz vor unbefugtem Zugriff
umgesetzt.3 Oft wird bei der Auswahl nicht ausreichend berücksichtigt, welche Schäden
verhindert werden können und welche Maßnahmen im konkreten Einsatzszenario angemessen sind.
Das neu entwickelte Entscheidungsunterstützungsmodell bildet diese komplexe Situation ab und
dient dazu, für verschiedene Unternehmenstypen (Szenarien) in unterschiedlichen Situationen eine
bestmögliche Maßnahmenauswahl zu ermitteln.

2 Struktur des quantitativen Entscheidungsmodells


Die Auswahl von Sicherheitsmaßnahmen im Rahmen des Identitäts- und Zugriffsmanagements
sollte auf Grundlage der jeweiligen Gefährdungssituation und der potenziellen wirtschaftlichen
Konsequenzen von Schadensfällen erfolgen. Es muss also einerseits eine Analyse von externen
sowie internen Gefahren durchgeführt werden sowie andererseits eine Bewertung der
Unternehmens-Assets zur Abschätzung möglicher Schäden erfolgen. Beide Analysen müssen für
den Zweck der Entscheidungsunterstützung quantitative Größen produzieren, welche in ein
geeignetes Modell einfließen können. Je nach Anwendungsfall ist es möglich, dass die Daten
relativ genau (z. B. auf Grundlage historischer Daten) oder eher vage (z. B. durch
Expertenschätzungen) bestimmt werden. Eine Kombination beider Ansätze ist ebenfalls möglich.4
Wird IT-Sicherheit nicht isoliert und zweckgebunden betrachtet, reicht es im Hinblick auf die
Wirtschaftlichkeit eines Unternehmens nicht aus, nur das erreichte Sicherheitsniveau zu ermitteln.
Eine erhöhte Sicherheit bedeutet in der Regel auch größere Investitionen bzw. Kosten für
entsprechende Maßnahmen. Bei der Auswahl optimaler Maßnahmenkombinationen und dem
Vergleich von Alternativen müssen daher neben dem erreichten Sicherheitsniveau auch eine
Abwägung der hierzu erforderlichen Kosten und ein Vergleich mit dem tatsächlichen Nutzen für
das Unternehmen erfolgen.5 Der Nutzen kann über verschiedene wirtschaftliche Kenngrößen
ermittelt werden und berücksichtigt sowohl die positiven Effekte durch die Umsetzung von
Maßnahmen als auch die negativen Auswirkungen von Maßnahmen und die entstehenden Kosten.
Das im Folgenden vorgestellte Entscheidungsmodell bildet die wesentlichen Elemente ab,
welche die Sicherheit eines Cloud-basierten Systems beeinflussen. Dabei werden nur
Systemkomponenten berücksichtigt, welche im direkten Zusammenhang mit dem Identitäts- und
Zugriffsmanagement stehen.

2.1 Bewertungssystem und -skala


Die exakte Ermittlung von Parametern, wie Wahrscheinlichkeiten oder Kosten, stellt viele
Unternehmen vor enorme Herausforderungen. Zum einen fehlen häufig die nötigen Kompetenzen,
um IT-Sicherheitsaspekte detailliert zu betrachten und zum anderen sind die entstehenden Kosten
durch einen hohen Mitarbeitereinsatz meist sehr hoch. Als Lösung bietet es sich daher an, die
Genauigkeit der ermittelten Daten zu reduzieren und so den Aufwand bei der Parameterschätzung
zu verringern.6 Dies stellt eine vereinfachte Abbildung der Realität dar, welche die
Parameterbestimmung erheblich vereinfacht und dadurch deutlich weniger Aufwand verursacht. In
einer aktuellen Veröffentlichung wurde zudem nachgewiesen, dass auch vage Parameter zu guten
Ergebnissen führen. Dies ist darauf zurückzuführen, dass die grundlegenden Strukturen innerhalb
der erhobenen Daten auch bei leichten Abweichungen erhalten bleiben.7 Es ist daher sinnvoll, die
Daten mittels einer verbalen Skala auf einer höheren Aggregationsebene zu erheben. Für die
Verwendung der Daten in einem quantitativen Entscheidungsmodell werden die verbalen Werte
anschließend quantitativen Größen zugeordnet. Die Bewertung aller Parameter erfolgt daher
zunächst auf einer 7-stufigen Skala (siehe Tab. 5.1), welche bei einer Expertenschätzung zum
Einsatz kommt.
Tab. 5.1 7-stufige verbale Skala zur Bewertung von Modellparametern

Stufe 0 1 2 3 4 5 6
Verbal Null sehr gering gering eher gering eher hoch hoch sehr hoch
Symbol ◦◦◦◦◦◦ •◦◦◦◦◦ ••◦◦◦◦ •••◦◦◦ ••••◦◦ •••••◦ ••••••

2.2 Assets und Schutzziele


Die Auswirkung eines Sicherheitsvorfalls kann in der Regel immer auf ein Asset zurückgeführt
werden. Ein Asset ist üblicherweise eine technische Komponente, die für ein Unternehmen einen
gewissen Wert hat (z. B. eine Datenbank bzw. die enthaltenen Daten). Die Sicherheit jedes Assets
ist durch verschiedene Schutzziele gekennzeichnet. Es wird zwischen den Schutzzielen
Vertraulichkeit, Integrität und Verfügbarkeit unterschieden. Vertraulichkeit bedeutet, dass Daten
nicht öffentlich bekannt werden dürfen. Bei Integrität ist es möglich, dass Daten öffentlich sind, es
ist jedoch entscheidend, dass diese Daten nicht verändert werden. Die Verfügbarkeit zielt darauf
ab, dass Daten jederzeit abgerufen werden können, also stets verfügbar sind. Diese Schutzziele
können sowohl einzeln als auch in Kombination vorliegen und sind für jedes Asset getrennt zu
ermitteln.8

2.2.1 Kundendaten
Kundendaten stellen alle Informationen über einen Kunden dar, die für die jeweiligen
Geschäftsprozesse notwendig sind. Dazu zählen unter anderem der Name, die Adresse,
Telefonnummern und darüber hinaus möglicherweise auch noch persönlichere Informationen, wie
Daten über die Beschäftigung, das Alter, die Konfession, die Familie und weitere. Da es sich bei
Kundendaten um personenbezogene Daten9 handelt, sind Datenschutzaspekte hier besonders zu
berücksichtigen.

2.2.2 Kunden-Zahlungsdaten
Zu dieser Kategorie gehören all diejenigen Daten, welche zur Durchführung von Transaktionen
zwischen einem Unternehmen und einem Kunden nötig sind. Dazu zählen beispielsweise Konto-
und Kreditkarteninformationen oder Daten bezüglich anderer Zahlungsarten. Ebenso wie
Kundendaten sind Zahlungsdaten personenbezogen und daher datenschutzrechtlich besonders
relevant.

2.2.3 Geschäftskritische Daten


Unter geschäftskritischen Daten sind solche Daten zu verstehen, die eine zentrale Bedeutung für
den Fortbestand einer Unternehmung besitzen. Je nach Art hat nur ein geringer Anteil des
Personals Zugriff auf diese Daten. Dazu können insbesondere Datenbanken, Informationen über
Strategien und Planungen und andere gehören.

2.2.4 Sensitive (unternehmensinterne) Daten


Sensitive Daten sind grundsätzlich alle Daten, die unternehmensintern erhoben und verarbeitet
werden. Da alle anderen hier berücksichtigten Daten ebenfalls als sensitiv und damit
schützenswert eingestuft werden können, ergibt sich eine Schnittmenge. Mit sensitiven
(unternehmensinternen) Daten sind daher alle Daten gemeint, die keiner anderen Kategorie
zugeordnet werden können. Dazu zählen beispielsweise Daten aus Forschung und Entwicklung,
Marketingerkenntnisse, Produktspezifikationen etc.

2.2.5 Archivierte Daten


Unter archivierten Daten versteht man solche Daten, die in einer Datenbank abgelegt werden. Die
Archivierung kann besonders auf Gründe der Übersichtlichkeit zurückgeführt werden, wenn eine
sehr große Anzahl an Daten vorhanden ist. Es werden zumeist solche Daten archiviert, die eher
selten genutzt werden.

2.3 Bedrohungsszenarien
Assets werden von verschiedenen Gefahren bedroht, welche durch Schwachstellen im System zu
Sicherheitsvorfällen führen können. Es können unterschiedlichste Bedrohungen vorliegen, welche
die Assets und deren Schutzziele unterschiedlich stark gefährden. Um die Bedrohung durch
Gefahren abzuschwächen, können Sicherheitsmaßnahmen umgesetzt werden. Durch
Sicherheitsmaßnahmen wird die Bedrohung durch bestimmte Gefahren reduziert und damit die
Einhaltung der Schutzziele entsprechender Assets sichergestellt.10

2.3.1 Externe Bedrohungen


Viele Unternehmen sehen sich heute mit dem Problem des Datendiebstahls konfrontiert. Dabei gibt
es verschiedene Ansatzpunkte für einen potenziellen Angriff. Während einige relativ einfache
Varianten auf eine sehr große Anzahl an Angriffen und somit auf eher zufälligen Erfolg abzielen,
sind andere Methoden deutlich komplexer in ihrer Ausgestaltung und Durchführung und oftmals
auf den Diebstahl bestimmter Informationen ausgerichtet. Nachfolgend werden verschiedene
Formen von externen Bedrohungen bzw. Angriffen kurz erläutert.
2.3.1.1 Keylogger
Keylogger stellen eine häufig genutzte Art von Malware dar, die unbemerkt die Aktionen der
Tastatur aufzeichnen und zumeist an eine andere Instanz weiterleiten. Dabei werden sensible
Informationen, wie Passwörter und PINs, Sozialversicherungsnummern und Kreditkartennummern
gestohlen. Zumeist sind Keylogger in Webapplikationen oder Software-Treibern implementiert.
Gewöhnliche Keylogger werden für viele verschiedene Webseiten, wie bspw. solche von Finanz-
oder Informationsdienstleistern verwendet.11

2.3.1.2 Phishing
Phishing bezeichnet einen Angriff, bei dem der Angreifer über E-Mails versucht den Empfänger zu
überzeugen, freiwillig seine persönlichen Informationen preiszugeben. Dabei wird eine sehr große
Anzahl an E-Mails verschickt, um unachtsame Personen zu ködern. Dies wird erreicht, indem eine
für den Empfänger relevante Unternehmung imitiert wird. Dabei werden häufig Banken und andere
bekannte Unternehmen, wie eBay oder PayPal fingiert, da diese Dienste von einer Vielzahl von
Personen genutzt werden.12
Eine neuere Variante stellt das sogenannte „Spear-Phishing“ dar, bei welchem das Phishing
auf eine spezifische Gruppe ausgerichtet ist. Dazu werden Informationen benötigt, um Personen
einer Gruppe zuzuordnen. Dies geschieht über Software, wie zum Beispiel Keylogger. So kann ein
Sachverhalt konstruiert werden, der deutlich individueller und somit schwieriger als Phishing zu
identifizieren ist.13
2.3.1.3 Pharming
Pharming ist eine fortschrittlichere Version des Phishings, bei dem Schadsoftware auf einem
Computer installiert wird. Bei dem Versuch des Aufrufens einer Website wird stattdessen eine
Imitation dieser aufgerufen, welche dann alle Eingaben, wie zum Beispiel Passwörter oder andere
Daten, an den Angreifer übermittelt. Die Schadsoftware wird dabei bereits durch das Öffnen einer
Pharming E-Mail auf dem Rechner installiert.14
2.3.1.4 Brute-Force-Angriff
Bei einem Brute-Force-Angriff werden Passwörter gestohlen, indem der Rechner für jede Stelle
des Passworts jede mögliche Eintragung ausprobiert, bis das Passwort vollständig erraten ist. Die
Dauer hängt dabei primär von der Leistungsfähigkeit des Computers und der Passwortlänge ab.
Oftmals werden auch Datensätze, wie Wörterbücher, für einen Angriff verwendet, da einfache
Wörter oft beliebte Passwörter darstellen. Durch die Annahme, dass das Passwort aus Worten
oder zumindest Silben besteht, kann die Anzahl der zu testenden Sequenzen deutlich reduziert
werden. Dadurch kann es aber dazu kommen, dass der Angriff erfolglos bleibt, falls das Passwort
nicht in dem Datensatz vorhanden ist. Hier hängt der Erfolg des Angriffs noch zusätzlich von der
Qualität des Datensatzes ab.
2.3.1.5 Man-in-the-Middle-Angriff
Ein Man-in-the-Middle Angriff stellt eine Form von Phishing dar, bei welchem der Angreifer sich
zwischen den Nutzer und die angefragte Website positioniert. Nachrichten, die dabei für den
Nutzer bestimmt sind, werden so durch den Angreifer abgefangen und können ausgelesen und
manipuliert werden. Angriffe dieser Form sind schwierig zu entdecken, da die Website wie
gewöhnlich zu funktionieren scheint.15
2.3.1.6 Cross-Site-Scripting (XSS)
Cross-Site-Scripting stellt eine der am weitesten verbreiteten Methoden zum Datendiebstahl im
Internet dar und bezeichnet einen Angriff, bei dem Schadcode in eine sicher geglaubte Webseite
integriert wird. Dabei werden oft serverseitige Skripte verändert, die zum Beispiel
Eingabeformulare oder andere dynamische Webseiten generieren. Wenn der Nutzer die Webseite
aufruft, wird der Schadcode ausgeführt und führt zu ungewolltem Verhalten des Browsers. Der
Schaden, den ein solcher Angriff anrichten kann, richtet sich weiterhin nach den Rechten, die der
angegriffene Nutzer im System besitzt.
2.3.1.7 Trojaner
Trojanische Pferde sind zunächst relativ einfach zu programmieren und werden zumeist in den
Code von Programmen und Webanwendungen integriert. Besonders gefährdet sind Programme, auf
die jeder Nutzer zugreifen kann, also Freeware.
Der Trojaner täuscht dem Nutzer vor, die Software oder Applikation zu sein, die der Nutzer
starten möchte. Ein Web-Trojaner bspw. erscheint über dem normalen Login-Fenster, sodass der
Nutzer denkt, die Daten in dieses einzugeben, wobei der Trojaner die Daten lokal sammelt und an
den Angreifer sendet.16
2.3.1.8 Replay-Angriff
Bei einem Replay-Angriff versucht der Angreifer, in den Besitz von
Authentifizierungsinformationen zu gelangen, um sich später selbst als der rechtmäßige Besitzer
dieser Informationen bei einer weiteren Entität auszugeben.17

2.3.1.9 Kopien-Angriff
Bei dem Kopien-Angriff handelt es sich um eine eher ungewöhnliche Angriffsart, bei der eine
Kopie des Authentifizierungsmerkmals erstellt wird. Dies kann beispielsweise eine Kopie einer
TAN-Liste sein oder aber auch die Anfertigung eines synthetischen Fingerabdrucks.

2.3.2 Interne Bedrohungen


Neben Bedrohungen, die von außerhalb des Unternehmens erfolgen, gibt es auch Gefahren, die
durch Mitarbeiter oder unternehmensnahe Personen ausgeführt werden können.
2.3.2.1 Shoulder Surfing
Hierbei handelt es sich um das Beobachten von Personen bei Vorgängen, wie bspw. der
Passwort- oder PIN-Eingabe, dem Ausfüllen von Formularen und Ähnlichem. Dies kann durch
eine Person direkt ausgeführt werden oder aber durch das Verwenden von Kameras und ähnlichen
Objekten.
Zumeist geschieht Shoulder Surfing an Plätzen, an denen sich sehr viele Menschen befinden,
damit der Angreifer nicht auffällig wirkt.18
2.3.2.2 Dumpster Diving
Dumpster Diving beschreibt eine weitere Methode, in den Besitz von persönlichen Daten fremder
Personen zu gelangen, ohne auf technische Möglichkeiten zurückzugreifen. Diese Methode beruht
auf der Annahme, dass viele Menschen zu leichtfertig mit wichtigen persönlichen Daten umgehen
und diese beispielsweise in öffentlichen Abfallbehältern oder anderen Orten vermeintlich sicher
entsorgen. Der Angreifer muss diese nur aufheben und kann daraus Rückschlüsse auf den Besitzer
ziehen.19

2.4 Maßnahmen zur sicheren Authentifizierung (engl. safeguards)


Das Identitäts- und Zugriffsmanagement im Cloud Computing ist durch eine Vielzahl
verschiedener technischer Möglichkeiten gekennzeichnet. In der Praxis werden je nach
Einsatzszenario und Anwendungsfall verschiedene Maßnahmen zur Authentifizierung und
Zugriffskontrolle eingesetzt. Dies sind sowohl technische Maßnahmen (z. B. Passwörter/PINs,
Smartcards, OTP Token) als auch organisatorische Maßnahmen (z. B. Schulungen, Richtlinien).
Im dritten Kapitel wurden mehrere technische Maßnahmenalternativen vorgeschlagen, welche
sowohl einzeln als auch in Kombination eingesetzt werden können (Ein-Faktor- und Zwei-Faktor-
Authentifizierung). Außerdem wurden weitere nichttechnische Maßnahmen (Passwortregeln etc.)
aufgezeigt, welche die Gesamtsicherheit zusätzlich abrunden. Für die Modellierung wurden die
jeweiligen Abhängigkeiten (Kompatibilität und Inkompatibilität) von Maßnahmen berücksichtigt.
Um eine einheitliche Bewertung von Maßnahmen zu gewährleisten, wird im Folgenden ein
quantitatives Bewertungssystem angewendet.
Da zwischen Maßnahmen Abhängigkeiten bestehen und Maßnahmen unterschiedlich auf
Gefahren und damit auf die Einhaltung der Schutzziele wirken, ist die Auswahl von Maßnahmen
sehr komplex. Das zu entwickelnde quantitative Modell bildet diese Komplexität ab und kann
dazu eingesetzt werden, in spezifischen Situationen Maßnahmenvorschläge zu generieren. Die
ermittelten Vorschläge werden in Kap.​ 6 im Hinblick auf rechtliche Aspekte untersucht.20
Um die Bedrohung durch Gefahren abzuschwächen, können Sicherheitsmaßnahmen umgesetzt
werden. Mittels Sicherheitsmaßnahmen wird die Bedrohung durch bestimmte Gefahren reduziert
und damit die Einhaltung der Schutzziele entsprechender Assets sichergestellt. Je nach Maßnahme
können verschiedene Gefahren unterschiedlich effektiv abgeschwächt werden.21
Maßnahmen sind durch ihre Effektivität (oder auch Erfolgswahrscheinlichkeit zur
Verhinderung von Gefahren) gekennzeichnet. Hinzu kommt eine Verknüpfung von Maßnahmen und
Gefahren, da nicht jede Maßnahme gleichermaßen gegen alle Gefahren wirkt. Es ist daher für jede
Maßnahme zu prüfen, welche Gefahren bei einer Umsetzung betroffen sind. Neben der Verbindung
zu Gefahren bestehen möglicherweise auch Abhängigkeiten und/oder Inkompatibilitäten zwischen
Maßnahmen, welche korrekt identifiziert werden müssen. Abschließend sind verschiedene
Maßnahmen mit unterschiedlichen Kosten im Falle einer Umsetzung verbunden. Diese Aspekte
werden bei der Modelldefinition und bei der Erstellung der Datenbasis entsprechend
berücksichtigt.

3 Optimale Auswahl von Sicherheitsmaßnahmen für ein sicheres


Identitäts- und Zugriffsmanagement
Zur optimalen Auswahl von Maßnahmen bzw. Maßnahmenkombinationen ist eine quantitative
Analyse erforderlich. Im Folgenden wird zunächst auf die Entscheidungssituation eingegangen und
die Modellstruktur definiert. Dabei werden die Ergebnisse aus diesem und den vorherigen
Kapiteln berücksichtigt.

3.1 Entscheidungssituation bei der Maßnahmenauswahl


Bei der hier betrachteten Entscheidungssituation gilt es, unter Berücksichtigung mehrerer
Einschränkungen eine optimale Maßnahmenkombination zu ermitteln. Grundsätzlich ist zu
beachten, dass die Güte verschiedener Maßnahmenkombinationen unterschiedlich gemessen
werden kann. Dabei können die anfallenden Kosten entscheidend sein, die Einfachheit der Nutzung
oder aber die erreichte Sicherheit. In dem hier vorgestellten Ansatz wird Sicherheit primär über
den erwarteten Schaden abgebildet, welcher unter Berücksichtigung der umgesetzten Maßnahmen
eintreten könnte. Weitere Faktoren, wie z. B. die Kosten zur Umsetzung, werden durch
Restriktionen berücksichtigt. Neben einem begrenzten Budget für Maßnahmen sind dies
beispielsweise Maßnahmeninkompatibilitäten oder Maßnahmenabhängigkeiten. Eine verbale
Formulierung des entsprechenden Modells lautet wie folgt:

Minimiere: Erwartete Schadenshöhe


unter Brücksichtigung von: Maximalen Budgets
Maximaler Maßnahmenanzahl
Maßnahmeninkompatibilitäten
Maßnahmenabhängigkeiten
Gefahrenabhängigkeiten
Das Ziel bei der Optimierung ist die Minimierung der erwarteten Schadenshöhe, welche aus
Assets, möglichen Gefahren und umgesetzten Maßnahmen abgeleitet wird. Hinzu kommen mehrere
Restriktionen, die mögliche Maßnahmenkombinationen einschränken und so den Lösungsraum
definieren.
Um eine optimale Maßnahmenkombination zu bestimmen, müssen zunächst die erforderlichen
Daten ermittelt werden. Wie oben22 bereits erläutert, wird zur Schätzung von Parametern zunächst
eine verbale Skala verwendet. Liegen die Schätzungen vor, werden diese über einen
Umrechnungsschlüssel in quantitative Größen umgerechnet. Die Umrechnung erfolgt gemäß Tab.
5.2 in absolute oder relative Werte, je nachdem ob es sich um geschätzte monetäre Größen oder
Wahrscheinlichkeiten handelt.
Tab. 5.2 7-stufige Skala mit verbalen und quantitativen Bewertungen von Modellparametern

Stufe 0 1 2 3 4 5 6
Verbal Null sehr gering gering eher gering eher hoch hoch sehr hoch
Rel. Werte23 0 1/12 3/12 5/12 7/12 9/12 11/12

Abs. Werte24 0 1 2 4 8 16 32
Symbol ◦◦◦◦◦◦ •◦◦◦◦◦ ••◦◦◦◦ •••◦◦◦ ••••◦◦ •••••◦ ••••••

Durch dieses Vorgehen ist es möglich, mehrere Datenbasen zu verwenden, um


unterschiedliche Situationen zu vergleichen. Im weiteren Verlauf wird von dieser Möglichkeit
Gebrauch gemacht, um zum einen die verschiedenen Szenarien zu untersuchen und zum anderen
mehrere Budgetvorgaben je Szenario zu vergleichen.
Die so ermittelten Daten gehen anschließend als Input in das Optimierungsmodell ein. Das
Modell selbst definiert die Struktur des Problems und kann mit einem Solver gelöst werden. Bei
der Lösung wird dann eine Maßnahmenkombination ermittelt, welche optimal hinsichtlich des
Zielkriteriums ist und gleichzeitig alle Restriktionen einhält. Auch wenn diese Lösung
mathematisch optimal ist, d. h. eine Verbesserung nicht möglich ist, ist es ggf. sinnvoll bzw.
wünschenswert, diese Lösung zu verändern oder mit anderen Lösungen zu vergleichen. Dies ist
insbesondere dann der Fall, wenn eine Lösung Eigenschaften aufweist, die im Modell nicht
abgebildet sind. Insbesondere die Frage der Angemessenheit einer Lösung ist nur schwer
quantifizierbar (Kosten-Nutzen-Verhältnis). Ebenso ist die Frage, ob rechtliche
Rahmenbedingungen erfüllt sind, stets individuell zu klären. Bei dieser Lösungsevaluation werden
daher ggf. Parameteranpassungen durchgeführt oder weitere Restriktionen eingefügt, um bisher
nicht berücksichtigte Aspekte zu integrieren. Das Optimierungsmodell nimmt dem
Entscheidungsträger daher die Entscheidung nicht vollständig ab, sondern ist als Werkzeug zu
verstehen, welches im Entscheidungsprozess unterstützen kann. Die beschriebene Vorgehensweise
ist in Abb. 5.1 visualisiert.
Abb. 5.1 Vorgehen zur Einbettung des Optimierungsmodells in den Entscheidungsprozess

3.2 Modelldefinition
Zur Formulierung des quantitativen Optimierungsmodells werden in Tab. 5.3 zunächst die
verwendeten Indizes und Mengen, Parameter sowie die Entscheidungsvariablen definiert. Da über
die Auswahl von Maßnahmen entschieden wird, ist Variable von zentraler Bedeutung.
Die Variable gibt an, welche Maßnahmen unter Berücksichtigung der Inputdaten ausgewählt
werden sollten, um den erwarteten Schaden maximal zu reduzieren. Die Ergebnisse der
Optimierung können als Entscheidungs- und Diskussionsgrundlage im Entscheidungsprozess
genutzt werden. Nach der Modelldefinition folgt eine ökonomische und technische Diskussion der
Ergebnisse, welche in Kap.​ 6 durch eine Diskussion der rechtlichen Anforderungen ergänzt wird.
Tab. 5.3 Bedeutung verwendeter Indizes, Mengen, Parameter und Entscheidungsvariablen

Indizes und Mengen


P Menge von Assets (Index p)
Q Menge von Schutzzielen (Index q)
I Menge von Gefahren (Index i)
T p,q Menge von Gefahren, die Schutzziel q von Asset p bedrohen,

Vi Menge von Maßnahmen, bei deren Umsetzung Gefahr i auftritt


Ki Menge von Sicherheitsmaßnahmen, die gegen Gefahr i wirken (Index k)
Parameter
Gesamtwert von Asset p,

z p,q Relevanz von Schutzziel q für Asset p

Wahrscheinlichkeit, dass Gefahr i auftritt (ohne Maßnahmen),

e i,k Erfolgswahrscheinlichkeit von Maßnahme

Initiale Kosten zur Umsetzung von Maßnahme k für Unternehmen,

Kosten pro Mitarbeiter bei Umsetzung von Maßnahme

Kosten pro Kunde bei Umsetzung von Maßnahme

NU Mitarbeiterzahl im Kontakt mit digitaler Cloud-Infrastruktur,

NK Kundenzahl im digitalen Kontakt mit dem Unternehmen,

Initiales Unternehmensbudget für Maßnahmen,

Unternehmensbudget für Maßnahmen,

BK Kundenbudget für Maßnahmen,

M Maximale Maßnahmenanzahl,
Kompatibilität von Maßnahme k 1 zu Maßnahme k 2,

(Harte) Abhängigkeit einer Maßnahme k 1 von Maßnahme

(Weiche) Abhängigkeit einer Maßnahme k 1 von Maßnahme

Entscheidungsvariablen
sk Auswahl von Maßnahme

ti Wahrscheinlichkeit, dass Gefahr i auftritt, unter Berücksichtigung der ausgewählten Maßnahmen,

Im Folgenden wird das mathematische Optimierungsmodell definiert und anschließend auf die
Bedeutung und die technischen Details der Zielfunktion sowie der Restriktionen eingegangen.
min

(1)
s.d.:

(2)

(3)

(4)

(5)
(6)
(7)

(8)

(9)
(10)

(11)
(12)
Die Zielfunktion (1) des Modells dient der Bewertung des potenziell auftretenden Schadens.
Zur Erläuterung wird die Zielfunktion wie folgt in mehrere Teile gegliedert:
(13)

Dazu wird der potenzielle Schaden je Asset und Schutzziel summiert und mit der
Wahrscheinlichkeit eines Sicherheitsvorfalls multipliziert (III). Dies entspricht der erwarteten
Schadenshöhe nach Auswahl von Maßnahmen. Zur Bestimmung des potenziellen Schadens an
Asset p bei Kompromittierung von Schutzziel q wird der Assetwert je Schutzziel als Basis mit
dem Faktor [0,1] multipliziert. Der Parameter z p,q gibt an, welche Relevanz Schutzziel q für
Asset p besitzt. Dadurch ist der Schaden an Asset p bei Kompromittierung von Schutzziel q
prozentual durch z p,q begrenzt. Dabei ist zu beachten, dass die Summe von über alle

Schutzziele den Wert des Assets nicht übersteigen kann. Es gilt .


Der Schaden an einem Asset tritt nur ein, wenn eine Gefahr tatsächlich auftritt. Zur Berechnung
des erwarteten Schadens wird der potenzielle Schaden daher mit der Wahrscheinlichkeit, dass ein
Sicherheitsvorfall eintritt, multipliziert. Diese Wahrscheinlichkeit korrespondiert mit dem
Ereignis, dass mindestens eine Gefahr eintritt und alle umgesetzten Sicherheitsmaßnahmen
versagen (II). Der Parameter t i gibt an, mit welcher Wahrscheinlichkeit Gefahr i auftritt und wird
multipliziert mit der Wahrscheinlichkeit , dass alle umgesetzten
Sicherheitsmaßnahmen versagen (I).
In den Restriktionen (2)–(4) werden die Budgets für Unternehmen und Kunden begrenzt. Für
Unternehmen wird dabei zwischen einmalig anfallenden Kosten bei Einrichtung einer
Maßnahme und fortlaufenden Kosten bei andauerndem Betrieb der Maßnahme unterschieden.
Restriktion (5) begrenzt die Anzahl der umzusetzenden Maßnahmen auf M.
Um die Kompatibilität bzw. Inkompatibilität von Maßnahmen abzubilden, wird Parameter
eingeführt. Ist , können Maßnahme und nicht gleichzeitig umgesetzt werden.
Durch kann daher die Inkompatibilität zweier Maßnahmen beschrieben werden.25
Eine direkte Abhängigkeit einer Maßnahme k1 von Maßnahme k2 ist durch Parameter in
Restriktion (7) definiert. Bei kann Maßnahme k1 nur ausgewählt werden, wenn auch
Maßnahme k2 ausgewählt wurde. Eine solche direkte Form der Abhängigkeit wird auch als harte
Abhängigkeit bezeichnet. Eine schwächere Form der Abhängigkeit liegt vor, wenn die Umsetzung
von Maßnahme k1 von der Umsetzung mindestens einer Maßnahme aus einer Menge von
Maßnahmenalternativen bedingt ist. Dies wird durch Parameter in Restriktion (8) festgelegt.
Es gilt, dass Maßnahme k1 nur ausgewählt werden kann, wenn , d. h. mindestens eine
weiche Abhängigkeit, erfüllt ist.26
Die Struktur des Problems sieht vor, dass Gefahren grundsätzlich durch Maßnahmen
abgeschwächt werden. In vielen Fällen werden aber auch neue Gefahren durch die Umsetzung von
Maßnahmen hervorgerufen. Zur Modellierung wird zu jeder Gefahr i die Menge V i eingeführt,
welche angibt, von welchen Maßnahmen das Auftreten von Gefahr i abhängig ist. In Restriktion
(9) wird für alle Gefahren, die unabhängig von Maßnahmen sind , die tatsächliche
Auftrittswahrscheinlichkeit t i einer Gefahr auf gesetzt. Tritt Gefahr i nur dann auf, wenn eine
oder mehrere Maßnahmen ausgewählt sind, ist die tatsächliche Auftrittswahrscheinlichkeit t i = 0,
wenn die entsprechenden Maßnahmen nicht ausgewählt sind. Die Abhängigkeit der Variable t i
von s k wird durch Hinzufügen von Restriktion (10) modelliert. Die Restriktion wird nur
hinzugefügt, wenn eine Abhängigkeit der Gefahr i von mindestens einer Maßnahme besteht .
Durch Multiplikation in der rechten Seite von Restriktion (10) mit s k wird t i nur bei umgesetzter
Maßnahme k auf gezwungen. Ist s k = 0, gilt , weshalb t i durch die Minimierung in der
Zielfunktion immer 0 ist.
Durch die Tatsache, dass im Modell das Eintreten von Gefahren von der Umsetzung von
Maßnahmen abhängt, muss immer mindestens eine Maßnahme ausgewählt werden. Der Zugriff auf
ein betrachtetes System muss also geschützt werden. Wird ein System nicht geschützt, d. h. es sind
keine Maßnahmen ausgewählt, die angegriffen werden können, so kann im Modell auch kein
Schaden entstehen, eine Lösung ohne Maßnahmen dominierte daher jede Lösung mit Maßnahmen.
Ein System ohne jegliche Maßnahmen wird in dieser Analyse nicht berücksichtigt und daher durch
Restriktion (11) ausgeschlossen. Abschließend gibt Restriktion (12) vor, dass die Auswahl von
Maßnahmen binär ist, d. h. eine Maßnahme wird entweder ausgewählt (s k = 1) oder nicht (s k =
0).

3.3 Datengrundlage zur optimalen Maßnahmenauswahl


Zur Entscheidungsunterstützung bei der optimalen Auswahl von Maßnahmen zur Authentifizierung
bei Cloud-basierten Systemen müssen zunächst relevante Daten erhoben werden. Ein Großteil der
Informationen wurde in vorherigen Kapiteln strukturiert und erfasst. Im Folgenden werden fünf
beispielhafte Einsatzszenarien für Cloud Computing betrachtet, welche im zweiten Kapitel27
detailliert beschrieben sind:
Szenario 1: Mittelständisches Unternehmen
Szenario 2: Kreditwirtschaft
Szenario 3: Sozialleistungsträger
Szenario 4: Berufsgeheimnisträger
Szenario 5: Verbraucher
Jedes Szenario ist durch verschiedene rechtliche und ökonomische Rahmenbedingungen
charakterisiert und weist daher unterschiedliche Schadensszenarien auf. In der folgenden Analyse
wird insbesondere geprüft, welche Maßnahmen in den betrachteten Szenarien notwendig sind und
welche Konsequenzen sich bei der Umsetzung verschiedener Alternativen ergeben.
Bei der Auswahl von Maßnahmen zur Authentifizierung ist die Anzahl der Nutzer von
entscheidender Bedeutung. Je nach Maßnahme ergeben sich nutzerabhängige Kosten, welche
entweder vom Unternehmen selbst oder vom Kunden getragen werden müssen. Zur angemessenen
Berücksichtigung ist jedes Szenario durch ein vorgegebenes typisches Verhältnis von Mitarbeiter-
und Kundenzahlen charakterisiert. In Tab. 5.4 ist die Anzahl der Mitarbeiter und Kunden auf der
verwendeten 7-stufigen Bewertungsskala angegeben. Es ist zu erkennen, dass z. B. im Szenario
Kreditwirtschaft deutlich mehr Kunden und Mitarbeiter Zugang zur Cloud-Infrastruktur des
Unternehmens haben, als beispielweise bei einem mittelständischen Unternehmen oder bei
Berufsgeheimnisträgern.
Tab. 5.4 Übersicht berücksichtigter Szenarien und jeweiliger Schätzung der Mitarbeiter und Kundenzahlen, die Kontakt mit der
Cloud-Infrastruktur haben

Szenario Name Mitarbeiterzahl (N U ) Kundenzahl (N K )


1 Mittelständisches Unternehmen ••◦◦◦◦ •••◦◦◦
2 Kreditwirtschaft ••••◦◦ ••••••
3 Sozialleistungsträger •••◦◦◦ •••••◦
4 Berufsgeheimnisträger •◦◦◦◦◦ ••••◦◦
5 Verbraucher •◦◦◦◦◦ •◦◦◦◦◦

Bei der Auswahl von Maßnahmen ist der limitierende Faktor immer das verfügbare Budget.
Gibt es keine Budgetvorgaben, kann die beste Maßnahmenkombination ausgewählt werden und
eine detaillierte Analyse der Wirtschaftlichkeit ist nicht erforderlich. Eine solche Situation liegt
allerdings in den allermeisten Fällen nicht vor und es liegt im Interesse des Unternehmens, die
Kosten möglichst gering zu halten. Gleiches gilt für Kunden, die möglicherweise eine geringe
Zahlungsbereitschaft haben. Bei der Auswahl von Maßnahmen muss also genauestens abgewogen
werden, welche Kosten auftreten und wer diese trägt. In Tab. 5.5 sind vier Budgetvorgaben
abgetragen, welche die Höhe der Kosten für Unternehmen und Kunden begrenzen. Die Vorgaben
spiegeln also die Bereitschaft zur Investition in IT-Sicherheit wider. Im Folgenden wird eine
Vorgabe mit sehr hoher (BV 1) Bereitschaft und eine mit eher hoher (BV 2) Bereitschaft
untersucht. Zusätzlich sind in der dritten Vorgabe eher geringe Kosten für das Unternehmen
zulässig und geringe Kosten für den Kunden (BV 3). Schließlich wird der Fall abgedeckt, dass
das Unternehmen eine hohe Bereitschaft hat, der Kunde jedoch eine geringe (BV 4).
Tab. 5.5 Übersicht der berücksichtigten Budgetvorgaben für Unternehmen und Kunden

Budgetvorgabe Initiales Unternehmensbudget Unternehmensbudget für Kundenbudget für Maßnahmen


( ) Maßnahmen ( ) (B K )

BV 1 •••••• •••••• ••••••


BV 2 ••••◦◦ ••••◦◦ ••••◦◦
BV 3 •••◦◦◦ •••◦◦◦ •••◦◦◦
BV 4 •••••◦ •••••◦ ••◦◦◦◦

Ergänzend zu den Budgetvorgaben sind jeder Maßnahme entsprechende Kosten zugeordnet,


die bei Umsetzung der Maßnahme anfallen. Eine Übersicht der Kosten je Maßnahme ist in Tab.
5.6 angegeben.

Tab. 5.6 Initiale und fortlaufende Kosten für Unternehmen und Kunden bei Umsetzung von Maßnahmen

Maßnahme Initiale Kosten ( ) Kosten pro Mitarbeiter ( ) Kosten pro Kunde ( )

Passwort •◦◦◦◦◦ •◦◦◦◦◦ ◦◦◦◦◦◦


PIN •◦◦◦◦◦ •◦◦◦◦◦ ◦◦◦◦◦◦
Fingerabdruck •••••◦ •••••◦ •••••◦
Handy TAN •••◦◦◦ ••◦◦◦◦ •◦◦◦◦◦
E-Mail TAN ••◦◦◦◦ •◦◦◦◦◦ ◦◦◦◦◦◦
Hardware OTP Token ••••◦◦ •••••◦ •••••◦
Smartcard •••••• ••••◦◦ ••••◦◦
Software OTP Token •••◦◦◦ ••◦◦◦◦ ••◦◦◦◦
TAN-Liste •••◦◦◦ •◦◦◦◦◦ ◦◦◦◦◦◦
eID (nPA) •••••◦ •••••◦ •••••◦

Zur geeigneten Auswahl von Maßnahmen werden zunächst die zu schützenden Assets ermittelt
und bewertet. Nur so kann ein angemessenes Verhältnis zwischen Aufwand und Nutzen erreicht
werden. In die Berechnung fließen daher die in Tab. 5.7 gelisteten Assets ein. Je nach Szenario
sind diesen Assets unterschiedliche Bedeutungen zugeordnet.

Tab. 5.7 Übersicht der berücksichtigten Assets mit Bewertung der Bedeutung im jeweiligen Szenario (entspricht )

Szenarien
Assets 1 2 3 4 5
Private Kundendaten ••••◦◦ •••••• •••••◦ •••••• ◦◦◦◦◦◦
Kunden-Zahlungsdaten •••••◦ •••••◦ •••◦◦◦ •••◦◦◦ ◦◦◦◦◦◦
Geschäftskritische Daten •••••◦ •••••• ••••◦◦ ••••◦◦ ◦◦◦◦◦◦
Sensitive (unternehmensinterne) Daten •••••◦ •••••◦ ••••◦◦ •••••• •••••◦
Archivierte Daten •••◦◦◦ ••••◦◦ •••◦◦◦ ••••◦◦ ••◦◦◦◦

Die Sicherheit eines Assets ist unterteilt in die Schutzziele Vertraulichkeit, Integrität und
Verfügbarkeit.28 Je nach Asset haben die Schutzziele eine andere Bedeutung für die Sicherheit des
Assets. So hat die Vertraulichkeit von Zahlungsdaten eine sehr hohe Bedeutung, wohingegen die
Verfügbarkeit von archivierten Daten weniger kritisch ist. Die vollständige Bewertung ist in Tab.
5.8 angegeben.
Tab. 5.8 Schutzziele mit Bewertung der Relevanz für die Sicherheit der berücksichtigten Assets (entspricht z p,q )

Szenarien
Assets Vertraulichkeit Integrität Verfügbarkeit
Private Kundendaten •••••◦ ••••◦◦ ••••◦◦
Kunden-Zahlungsdaten •••••• •••••◦ ••••◦◦
Geschäftskritische Daten •••••◦ •••••◦ ••••••
Sensitive (unternehmensinterne) Daten •••••• •••••◦ •••••◦
Archivierte Daten ••••◦◦ ••••◦◦ •◦◦◦◦◦

Die Sicherheit der Schutzziele wird durch das Eintreten von Gefährdungen bedroht. Je nach
Szenario sind bestimmte Gefahren wahrscheinlicher bzw. weniger wahrscheinlich. Die
vollständige Zuordnung der Eintrittswahrscheinlichkeit aller berücksichtigten Gefahren zu den
Einsatzszenarien ist in Tab. 5.9 angegeben.

Tab. 5.9 Übersicht von Gefahren mit Bewertung der Auftrittswahrscheinlichkeit im jeweiligen Szenario (entspricht )

Szenarien
Gefahren 1 2 3 4 5
Keylogger ••••◦◦ •••◦◦◦ •••◦◦◦ •••◦◦◦ •••◦◦◦
Phishing ••••◦◦ •••••• ••••◦◦ •••◦◦◦ ••◦◦◦◦
Pharming ••◦◦◦◦ •••••◦ ••◦◦◦◦ ••◦◦◦◦ ••◦◦◦◦
Brute-Force-Angriff •••••◦ •••••• •••••◦ •••••◦ ••••••
Man-in-the-Middle-Angriff •••◦◦◦ ••••◦◦ ••◦◦◦◦ ••◦◦◦◦ ••◦◦◦◦
Übernahme des E-Mail Accounts ••••◦◦ •••◦◦◦ •••◦◦◦ ••••◦◦ ••••◦◦
Diebstahl des Mobiltelefons •••◦◦◦ •••◦◦◦ •••◦◦◦ ••••◦◦ ••••◦◦
Schadsoftware auf dem Mobiltelefon ••◦◦◦◦ ••◦◦◦◦ ••◦◦◦◦ ••••◦◦ •••••◦
Diebstahl des Hardware OTP Token ••◦◦◦◦ ••◦◦◦◦ ••◦◦◦◦ ••◦◦◦◦ ••◦◦◦◦
Shoulder Surfing •••◦◦◦ ••••◦◦ ••◦◦◦◦ ••◦◦◦◦ •••◦◦◦
Dumpster Diving ••◦◦◦◦ •◦◦◦◦◦ •◦◦◦◦◦ •••◦◦◦ ••◦◦◦◦
Trojaner •••◦◦◦ •••◦◦◦ •••◦◦◦ •••◦◦◦ ••••◦◦
Diebstahl der Smartcard ••◦◦◦◦ •••◦◦◦ ••◦◦◦◦ ••◦◦◦◦ ••◦◦◦◦
Replay Angriff ••◦◦◦◦ ••••◦◦ ••◦◦◦◦ •◦◦◦◦◦ ••◦◦◦◦
Kopien Angriff •◦◦◦◦◦ ••◦◦◦◦ •◦◦◦◦◦ •••◦◦◦ ••◦◦◦◦

Durch die Umsetzung von Sicherheitsmaßnahmen wird die Auftrittswahrscheinlichkeit von


Gefahren verringert. Dies setzt voraus, dass die Maßnahme wirksam gegen die entsprechende
Gefahr ist. Ob und wie effektiv eine Maßnahme gegen eine Gefahr wirkt, ist in Tab. 5.10
abzulesen. Eine grafische Repräsentation der Verknüpfung ist zusätzlich in Abb. 5.2
veranschaulicht. Je nachdem, welche Maßnahmen ausgewählt werden, werden andere Gefahren
abgeschwächt. In Abb. 5.2 sind exemplarisch die Maßnahmenkombination Passwort + TAN-Liste
ausgewählt (grau hinterlegt). Die gestrichelten Pfeile geben an, welche Gefahren bei dieser
Kombination betroffen sind.
Abb. 5.2 Grafische Darstellung der Verknüpfung von Maßnahmen und Gefahren. Eine gerichtete Kante von einer Maßnahme zu
einer Gefahr zeigt an, dass diese Maßnahme gegen die entsprechende Gefahr wirkt. Die Maßnahmen TAN-Liste und Passwort sind
exemplarisch ausgewählt

Tab. 5.10 Wirksamkeit von Maßnahmen gegen Gefahren (entspricht e i,k )

Gefahren I Maßnahmen Passwort PIN Finger- Handy E-Mail Hardware OTP Smartcard Software TAN- eID
abdruck TAN TAN Token OTP Token Liste (nPA)
Keylogger ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••• ◦◦◦◦◦◦ ••••◦◦ •••••• •••••◦ •••••◦ •••••◦ ••••••
Phishing ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••• ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••• •••••◦ •••••• ◦◦◦◦◦◦ ••••••
Pharming ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••• ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••• •••••◦ •••••• ••••◦◦ ••••••
Brute-Force-Angriff ••◦◦◦◦ •◦◦◦◦◦ •••••◦ ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••• •••••◦ •••••◦ •••••◦ •••••◦
Man-in-the-Middle-Angriff ◦◦◦◦◦◦ ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••◦ ◦◦◦◦◦◦ •••••◦ ••••◦◦ •••••◦ ◦◦◦◦◦◦ ◦◦◦◦◦◦
Übernahme des E- ◦◦◦◦◦◦ ◦◦◦◦◦◦ ••••• •••••• ◦◦◦◦◦◦ •••••• •••••• •••••◦ •••••◦ ••••••
MailAccounts ◦

Diebstahl des Mobiltelefons ••••◦◦ ••••◦◦ •••••◦ ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••• •••••• ◦◦◦◦◦◦ •••••• •••••◦
Schadsoftware auf dem ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••◦ ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••• •••••• ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••◦
Mobiltelefon
Diebstahl des Hardware ••••◦◦ ••••◦◦ •••••• •••••• •••••• ◦◦◦◦◦◦ •••••• •••••• •••••• ••••••
OTP Token
Shoulder Surfing ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••• •••••◦ ••••◦◦ •••••• •••••◦ •••••◦ ◦◦◦◦◦◦ ••••••

Dumpster Diving ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••• •••••◦ ••••◦◦ •••••• •••••◦ •••••◦ ••••◦◦ ••••••
Trojaner ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••• ••••◦◦ ◦◦◦◦◦◦ •••••• ••••• •••••◦ •••••◦ ••••••

Diebstahl der Smartcard ••••◦◦ ••••◦◦ •••••• •••••• •••••• •••••• ◦◦◦◦◦◦ •••••• •••••• ••••••
Replay Angriff ◦◦◦◦◦◦ ◦◦◦◦◦◦ ◦◦◦◦◦◦ •••••◦ ••••◦◦ •••••• •••••◦ •••••◦ •••••◦ ••••••
Kopien Angriff ••••◦◦ ••••◦◦ ••••◦◦ •••••◦ •••••◦ •••••• •••••◦ •••••• ◦◦◦◦◦◦ •••••◦

Durch die Struktur des Problems treten einzelne Gefahren teilweise durch die Umsetzung von
Maßnahmen auf. Beispielsweise ist das Verlieren eines Hardware OTP Token nur dann
problematisch bzw. möglich, wenn ein entsprechender Token bei der Authentifizierung zum
Einsatz kommt. Von welchen Maßnahmen eine Gefahr abhängt, ist in Menge V i definiert. In Abb.
5.3 ist durch eine gerichtete Kante visualisiert, von welchen Maßnahmen Gefahren abhängig sind.
Abb. 5.3 Grafische Darstellung der Abhängigkeiten von Gefahren von Maßnahmen. Eine gerichtete Kante von einer Gefahr zu
einer Maßnahme zeigt an, dass diese Gefahr nur bei Umsetzung der Maßnahme auftritt

Bei der Umsetzung von Maßnahmen gilt es zu beachten, dass bestimmte Maßnahmen nur in
Kombination eingesetzt werden können und andere Kombinationen ausgeschlossen sind. Ist eine
Maßnahme nur bei gleichzeitiger Umsetzung einer anderen Maßnahme einsetzbar, liegt eine harte
Abhängigkeit vor. Dies ist nur bei dem Einsatz von eID (nPA) der Fall, wo bei der Verwendung
die Eingabe einer PIN erforderlich ist. Weitere harte Abhängigkeiten liegen bei den hier
berücksichtigten Maßnahmen nicht vor.
Im Gegensatz zu direkten harten Abhängigkeiten, die zwingend erfüllt werden müssen, können
zudem weiche Abhängigkeiten vorliegen. Hier kann eine Maßnahme nur ausgewählt werden, wenn
mindestens eine weiche Abhängigkeit erfüllt ist. Diese Form der Abhängigkeit wird
beispielsweise dazu verwendet, dass die alleinige Nutzung von auf Besitz basierenden Faktoren
ausgeschlossen ist. Es ist also nicht möglich, eine Authentifizierung durch Hardware OTP Token
und Smartcard zu implementieren. Stattdessen muss ein Faktor, basierend auf einem Gegenstand
(Besitz) immer in Kombination mit einem Faktor, basierend auf dem Wissen einer Person
(Passwort oder PIN), verwendet werden. Die entsprechenden weichen Abhängigkeiten sind in
Abb. 5.4 dargestellt.
Abb. 5.4 Grafische Darstellung weicher Abhängigkeiten von Maßnahmen. Hat eine Maßnahme ausgehende Kanten, muss
mindestens eine Maßnahme an einem Zielknoten ausgewählt sein, damit die Maßnahme ausgewählt werden kann

3.4 Auswertung und Ergebnisdiskussion


3.4.1 Mittelständisches Unternehmen (Szenario 1)
Ein mittelständisches Unternehmen ist durch eine relativ kleine Anzahl an Mitarbeitern und häufig
auch durch einen kleinen Kundenkreis charakterisiert. Die Bedeutung der Assets für ein
mittelständisches Unternehmen ist relativ gleichmäßig verteilt und als überwiegend hoch zu
bewerten (Kunden-Zahlungsdaten, geschäftskritische Daten und sensitive Daten). Weitere
Bewertungen können Tab. 5.7 entnommen werden.
Generell sind alle berücksichtigten Gefahren für ein mittelständisches Unternehmen relevant,
jedoch mit unterschiedlichem Gewicht. Besonders kritisch sind Brute-Force-Angriffe und unter
Berücksichtigung der Nutzergruppe ggf. Keylogger, Phishing oder die Übernahme von E-Mail
Accounts (sofern eine entsprechende Maßnahme eingesetzt wird).
Unter Berücksichtigung dieser Rahmenbedingungen kann mit dem eingeführten quantitativen
Entscheidungsmodell eine optimale Maßnahmenkombination zur Zwei-Faktor-Authentifizierung
ermittelt werden. Eine Übersicht der Ergebnisse ist in Abb. 5.5 visualisiert.

Abb. 5.5 Verhältnis von Sicherheit zu Kosten bei optimaler Maßnahmenauswahl für ein mittelständisches Unternehmen (Szenario
1) für vier Budgetvorgaben

Je nach Budgetvorgabe ergeben sich verschiedene Maßnahmenkombinationen, welche


unterschiedliche Sicherheitsniveaus zur Folge haben. Für Budgetvorgabe 1 (hohe Budgets) lässt
sich eine akzeptable Sicherheit zu vergleichsweise hohen Kosten realisieren. Dazu ist die Abfrage
eines Passworts in Kombination mit einem Hardware OTP Token erforderlich. Diese
Maßnahmenkombination führt zu relativ hohen Kosten, da die Hardware Token für alle
Mitarbeiter angeschafft werden müssen. Wenn Kunden dieselbe Authentifizierung durchlaufen
sollen, müssen diese ebenfalls mit Token ausgestattet werden oder diese ggf. selbst anschaffen. Es
ist daher fraglich, ob diese Kombination in diesem Szenario umsetzbar ist, wenngleich sie zur
höchsten hier erreichbaren Sicherheit führt.
Eine Alternative ist der Einsatz eines Passworts in Kombination mit einem Software OTP
Token. Diese Maßnahmenkombination ist in den Budgetvorgaben 2 und 4 realisierbar, da der
größere Kostenfaktor beim Unternehmen anfällt, welches die Maßnahmen implementiert. Durch
den Einsatz eines Software OTP Token wird ein solides Sicherheitsniveau zu deutlich geringeren
Kosten erreicht. Insbesondere die Kunden werden stark entlastet, da Software OTPs, z. B. auf
einem Smartphone, häufig mit geringem Aufwand eingerichtet werden können.
Für Budgetvorgabe 3 (eher geringe Budgets), kann keine der zuvor vorgeschlagenen
Maßnahmenkombinationen umgesetzt werden. Unter Berücksichtigung dieser starken
Budgetrestriktionen ist ein Passwort mit E-Mail TAN daher die beste Option. Im direkten
Vergleich zu den hier diskutierten Alternativen führt dies jedoch zu einer geringen Sicherheit, da
für die Übermittlung der TAN dasselbe Medium wie bei dem primären Kommunikationskanal
(Internet) mit einem vergleichsweise unsicheren Protokoll (E-Mail) verwendet wird. Die Kosten
zur Umsetzung sind zwar geringer, allerdings nur in geringem Maße, da ein ähnlich hoher
Implementierungsaufwand erforderlich ist.

3.4.2 Kreditwirtschaft (Szenario 2)


Im zweiten Szenario werden Unternehmen der Kreditwirtschaft betrachtet. Diese haben
üblicherweise eine sehr große Kundenzahl, welche zunehmend digital im Kontakt mit dem
Unternehmen steht. Dazu kommt eine eher große Anzahl von Mitarbeitern, die eine häufig sehr
komplexe IT-Infrastruktur mit vielen verschiedenen Anwendungen nutzen. Besonders kritisch sind
im Szenario Kreditwirtschaft die privaten Kundendaten und geschäftskritische Daten.
Zu den sehr kritischen Gefahren zählen in diesem Szenario insbesondere Phishing und Brute-
Force-Angriffe. Zudem sind Pharming und häufig auch Shoulder Surfing und Man-in-the-Middle-
Angriffe problematisch. Insbesondere Phishing ist sehr häufig und nutzt die inhomogene
Kundenbasis aus, welche daher zum Teil anfällig für diese Bedrohung ist.
Zum Schutz bietet es sich bei hohen Budgets (BV 1) an, eine starke Zwei-Faktor-
Authentifizierung mit Passwort oder PIN und Hardware OTP Token einzurichten. Wie in Abb. 5.6
zu erkennen ist, führt dies zu einer hohen Sicherheit bei ebenfalls hohen Kosten. Ein ebenfalls
akzeptables Sicherheitsniveau kann durch den Einsatz von PIN und eID (nPA) erreicht werden.
Die Kosten für beide Maßnahmenkombinationen sind vergleichbar. Bei einer hohen Verbreitung
von eID ist diese Maßnahme daher vorzuziehen. Ob dies für die Kunden des Unternehmens
zutrifft, ist individuell zu prüfen. Ist die Verbreitung gering, ist der Einsatz als problematisch
einzustufen.

Abb. 5.6 Verhältnis von Sicherheit zu Kosten bei optimaler Maßnahmenauswahl für ein Unternehmen der Kreditwirtschaft
(Szenario 2) für vier Budgetvorgaben

Eine Alternative mit deutlich besserem Kosten/Nutzen-Verhältnis ist der Einsatz von
Passwort/PIN mit Software OTP Token. Diese Kombination ist in BV 2 und BV 4 realisierbar.
Unter Berücksichtigung dieser Vorgaben ist eine Authentifizierung mit Passwort/PIN und TAN-
Liste ebenfalls realisierbar. Diese Form der Authentifizierung weist allerdings eine deutlich
geringere Sicherheit auf. Der initiale Implementierungsaufwand ist geringer, dafür kann die
Authentifizierung allerdings nicht rein digital abgewickelt werden, da ein regelmäßiger Versand
von TAN-Listen erfolgt. Bei eher geringen Budgets kann auf Passwort/PIN mit E-Mail TAN
zurückgegriffen werden. Die Problematik dieses Authentifizierungsverfahrens wurde bereits bei
den Ergebnissen zu Szenario 1 diskutiert.

3.4.3 Sozialleistungsträger (Szenario 3)


Im dritten Szenario werden die Anforderungen von Sozialleistungsträgern untersucht.
Sozialleistungsträger weisen typischerweise eine eher geringe Mitarbeiterzahl auf, bei einer
vergleichsweise hohen Kundenzahl. Im Bezug auf die Sicherheit von IT-Ressourcen ist die
Erhaltung der Vertraulichkeit von privaten Kundendaten besonders kritisch. Dazu kommen in
diesem Szenario sensitive (interne) Daten sowie geschäftskritische Daten, die es zu schützen gilt.
In diesem Szenario stellen Brute-Force-Angriffe eine erhöhte Gefahr dar, da häufig schwache
Passwörter gewählt werden, welche z. B. zum Teil durch einfache Angriffe (z. B. Rainbow
Tables) überwunden werden können. Zudem sind insbesondere Phishing und ggf. die Übernahme
von E-Mail Accounts, Keylogger und der Diebstahl des Mobiltelefons mögliche Schwachstellen
(sofern entsprechende Maßnahmen eingesetzt werden).
Unter Berücksichtigung hoher Budgets (BV 1) bietet sich in diesem Szenario der Einsatz einer
Zwei-Faktor-Authentifizierung mit Passwort und Hardware OTP Token an. Wie in Abb. 5.7 zu
erkennen ist, lässt sich in diesem Fall eine sehr hohe Sicherheit gewährleisten, die das
Schadenspotenzial deutlich begrenzt. Bedingt durch das Umfeld, in dem Sozialleistungsträger
operieren, und die hohen Kosten dieser Maßnahmenkombination ist diese Variante allerdings nur
schwer umsetzbar. Eine Alternative mit einem vergleichbaren Sicherheitsniveau und
vergleichbaren Kosten ist der Einsatz von PIN mit eID (nPA). Gerade für Sozialleistungsträger ist
diese Maßnahmenkombination sinnvoll, da eine große Anzahl von Kunden Zugriff erhalten muss,
welche je nach Verbreitungsgrad des nPA mit eID bereits über die Grundvoraussetzungen zur
Teilnahme am Authentifizierungsverfahren verfügen.
Abb. 5.7 Verhältnis von Sicherheit zu Kosten bei optimaler Maßnahmenauswahl für Sozialleistungsträger (Szenario 3) für vier
Budgetvorgaben

Bei geringem Verbreitungsgrad von eID oder stärkeren Kostenrestriktionen (BV 2 und 4)
bietet sich der Einsatz von Software OTP Token mit Passwort/PIN an. Bei einer hohen
Verbreitung mobiler Endgeräte bei den Kunden bietet dieses Verfahren eine hohe Sicherheit zu
deutlich reduzierten Kosten. Ob die notwendige Verbreitung vorliegt, ist zu prüfen. Dies könnte,
bedingt durch die Altersstruktur der Kundengruppe, problematisch sein, da ältere Menschen häufig
nicht über aktuelle mobile Endgeräte verfügen und so nicht problemlos an dem Verfahren
teilnehmen können. Gleiches gilt für den Einsatz von E-Mail TAN, welcher unter
Berücksichtigung von Budgetvorgabe 3 umsetzbar ist. Alternativ ist ein Verfahren mit TAN-Liste
denkbar, welches allerdings nicht im Rahmen der Vorgabe von BV 3 realisierbar ist.

3.4.4 Berufsgeheimnisträger (Szenario 4)


Berufsgeheimnisträger sind verpflichtet, besondere Sorgfalt im Umgang mit Kundendaten zu
wahren und die Geheimhaltung zu gewährleisten. Zudem sind sensitive (unternehmensinterne)
Daten als kritisch einzustufen, wenn diese im Zusammenhang zu Kundendaten stehen. Unternehmen
oder Personen dieses Szenarios haben häufig eine sehr geringe Mitarbeiterzahl und im Vergleich
eine eher hohe Kundenzahl. Typische Beispiele für Berufsgeheimnisträger sind Ärzte, Anwälte,
Wirtschaftsprüfer, Amtsträger oder Steuerberater. Kritische Gefahren sind in diesem Szenario
Brute-Force-Angriffe auf schwache Passwörter oder PINs sowie die Übernahme von E-Mail
Accounts, Schadsoftware auf Mobiltelefonen oder der Diebstahl des Mobiltelefons (sofern
entsprechende Maßnahmen eingesetzt werden).
Um einen ausreichenden Schutz zu gewährleisten, ist die Umsetzung einer Zwei-Faktor-
Authentifizierung mit Passwort und Hardware OTP Token erforderlich, welche in Budgetvorgabe
1 realisierbar ist. In den restriktiveren Budgetvorgaben 2 und 4 lässt sich die Authentifizierung mit
Passwort/PIN und Software OTP Token umsetzen, welche in diesem Szenario jedoch deutlich
weniger Sicherheit bietet, wie in Abb. 5.8 erkennbar ist. Durch die besonders hohen
Anforderungen zum Schutz der Daten ist es daher vorzuziehen, einen Hardware OTP Token oder
ggf. eID einzusetzen.

Abb. 5.8 Verhältnis von Sicherheit zu Kosten bei optimaler Maßnahmenauswahl für Berufsgeheimnisträger (Szenario 4) für vier
Budgetvorgaben

In Budgetvorgabe 3 mit einer sehr starken Kostenbeschränkung ist allenfalls eine


Maßnahmenkombination mit Passwort/PIN und E-Mail TAN einsetzbar, welche jedoch eine
nochmals deutlich reduzierte Sicherheit bietet. Ob entsprechende Maßnahmenkombinationen den
rechtlichen Anforderungen an Berufsgeheimnisträger genügen, wird in Kap.​ 6 eingehend
diskutiert.

3.4.5 Verbraucher (Szenario 5)


Im letzten Szenario werden Verbraucher betrachtet. Hier gilt es zu unterscheiden, ob ein
Verbraucher eine existierende Cloud nutzt bzw. nutzen möchte oder selbst eine Cloud einrichtet.
Im ersten Fall kann nur bedingt auf die Authentifizierungsmechanismen Einfluss genommen
werden. Die hier diskutierten Alternativen sind in diesem Fall als Anforderungen zu verstehen,
die ein Verbraucher an ein bestehendes Cloud-Angebot hat. Im zweiten Fall der selbst gehosteten
oder fremd gehosteten, aber selbst betriebenen Cloud ist der Verbraucher selbst für die
Einrichtung der Authentifizierung verantwortlich. Da im Modell eine Beziehung zwischen
Unternehmen und Kunden vorgesehen ist, werden in diesem Fall beide Seiten vom Verbraucher
repräsentiert. Das bedeutet auch, dass die Kosten zur Umsetzung von Maßnahmen vollständig vom
Verbraucher getragen werden.
Die in diesem Szenario relevanten Assets, also die schützenswerten Daten, sind sensitive
Daten des Verbrauchers und ggf. archivierte Daten (siehe Tab. 5.8). Für Verbraucher sind Brute-
Force-Angriffe und Schadsoftware auf dem Mobiltelefon als kritisch einzustufen. Je nachdem,
welche Maßnahmen umgesetzt werden, sind auch Trojaner, die Übernahme des E-Mail Accounts
und ein Diebstahl des Mobiltelefons wahrscheinliche Bedrohungen (siehe Tab. 5.9).
Ähnlich wie in den bisher betrachteten Szenarien ist ein Passwort mit Hardware OTP Token
die sicherste Maßnahmenkombination für Verbraucher (BV 1) (siehe Abb. 5.9). Bei geringerem
Budget bietet sich eine Authentifizierung mit Passwort und TAN-Liste an, welche durch die
physische TAN-Liste effektiven Schutz gegen reine Cyberangriffe bietet. Ob diese Form der
Authentifizierung für selbst gehostete Clouds praktikabel ist, bleibt individuell abzuwägen.
Alternativ kann hier auch ein Passwort mit Software OTP Token eingesetzt werden, welches zu
einer vergleichbaren Sicherheit bei ähnlichen Kosten führt.

Abb. 5.9 Verhältnis von Sicherheit zu Kosten bei optimaler Maßnahmenauswahl für Verbraucher (Szenario 5) für vier
Budgetvorgaben

Eine Authentifizierung mit Passwort und E-Mail TAN ist ebenfalls denkbar und führt zu einer
weiteren geringfügigen Reduktion der Kosten, verglichen mit Passwort/TAN-Liste oder
Passwort/Software OTP Token. Wie in Abb. 5.9 erkennbar, fällt die Sicherheit allerdings deutlich
ab. Dies ist darauf zurückzuführen, dass die Kommunikation nur über einen Kommunikationskanal
(Internet) abgewickelt wird. Durch den geringen Kostenunterschied ist daher, je nach
Schutzbedarf, eine Lockerung der Budgetvorgabe empfehlenswert, um die Umsetzung einer
Authentifizierung mit Passwort/TAN-Liste oder Passwort/Software OTP Token zu ermöglichen.

Literatur
Brody, Richard G/Elizabeth Mulig/Valerie Kimball: Phishing, Pharming And Identity Theft, in: Academy of Accounting and
Financial Studies Journal, Heft 11, 2007, S. 43–56.

Dotzler, Florian: Datenschutzrechtliche Aspekte und der Einsatz biometrischer Systeme in Unternehmen: eine exemplarische
Betrachtung von Systemen auf der Grundlage des biometrischen Merkmals Tippverhalten, Köln 2010.

Eckert, Claudia: IT-Sicherheit. Konzepte – Verfahren – Protokolle, 7., überarbeitete und erweiterte Aufl., Oldenbourg, 2012.

Fogie, Seth/Grossman, Jeremiah/Hansen, Robert/Rager, Anton/Petkov, Petko D.: XSS Attacks: Cross Site Scripting Exploits
and Defense, Burlington 2007.

Jakobsson, Markus/Myers, Steven: Phishing and Countermeasures, Understanding the Increasing Problem of Electronic Identity
Theft, New Jersey 2007.
Konradt, Christian/Schilling, Andreas/Werners, Brigitte: Phishing: An economic analysis of cybercrime perpetrators, in:
Computers & Security, Vol. 58 (2016), p. 39–46, DOI: https://​doi.​org/​10.​1016/​j.​cose.​2015.​12.​001 (zuletzt abgerufen am 12.12.2017).

Long, Johnny: No Tech Hacking: A Guide to Social Engineering, Dumpster Diving and Shoulder Surfing, Burlington 2008.

Schilling, Andreas: A framework for secure IT operations in an uncertain and changing environment, Computers & Operations
Research, Heft 85 (2017), S. 139–153. DOI: https://​doi.​org/​10.​1016/​j.​cor.​2017.​04.​008 (zuletzt abgerufen am 12.12.2017).

Schilling, Andreas/Werners, Brigitte: Optimal selection of IT security safeguards from an existing knowledge base, European
Journal of Operational Research, Heft 248(1) (2016), S. 318–327. DOI: https://​doi.​org/​10.​1016/​j.​ejor.​2015.​06.​048(zuletzt abgerufen
am 12.12.2017).

Schilling, Andreas/Werners, Brigitte: Optimizing information security investments with limited budget, in: Lübbecke, Marco/Koster,
Arie/Letmathe, Peter/Madlener, Reinhard/Peis, Britta/Walther, Grit (Hrsg.): Operations Research Proceedings 2014, Basel 2016, S.
493–499.

Schilling, Andreas/Werners, Brigitte: Optimal Information Security Expenditures Considering Budget Constraints, PACIS 2015
Proceedings, Paper 251, Singapur 2015, S. 1–14.

Schilling, Andreas/Werners, Brigitte: A Quantitative Threat Modeling Approach to Maximize the Return on Security Investment in
Cloud Computing, in: Endicott-Popovsky, B. (Hrsg.): Proceedings of the International Conference on Cloud Security Management
ICCSM, Reading, UK 2013, S. 68–78.

Werner, Jorge/Merkle Westphall, Carla/Becker Westphall, Carlos: Cloud identity management: A survey on privacy strategies,
in: Computer Networks, Vol. 122, 20 July 2017, Pages 29–42, https://​doi.​org/​10.​1016/​j.​comnet.​2017.​04.​030, abrufbar unter http://​
www.​sciencedirect.​com/​science/​article/​pii/​S138912861730166​4 (zuletzt abgerufen am 12.12.2017).
[Crossref]

Fußnoten
1 Werner/Westphall/Westphall (2017).

2 Schilling/Werners (2013), S. 68 ff.

3 Siehe Kap.​ 2 und 3.

4 Schilling/Werners (2016), S. 320 f.; Schilling (2017), S. 141 ff.

5 Schilling/Werners (2014).

6 Schilling/Werners (2016); Schilling (2017).

7 Schilling/Werners (2015), S. 10 ff.


8 Eckert, Claudia (2012), S. 7 ff.

9 Siehe zum Begriff Kap.​ 4, 5.​1.​1.

10 Schilling/Werners (2013), S. 70 ff.

11 Jakobsson/Myers (2007), S. 116.

12 Simulationen zur ökonomischen Bewertung von Bedrohungen durch Phishing finden sich etwa bei Konradt/Schilling/Werners
(2016).

13 Brody/Mulig/Kimball (2007), S. 45 ff.

14 Brody/Mulig/Kimball (2007), S. 47 ff.

15 Jakobsson/Myers (2007), S. 36 f.

16 Jakobsson/Myers (2007), S. 116.

17 Dotzler (2010), S. 102.

18 Long (2011), S. 28 ff.

19 Long (2011), S. 2 ff.

20 Siehe Kap.​ 6, 5.

21 Schilling/Werners (2016), S. 321 f.


22 Siehe 2.1.

23 Mögliche Werte in Menge S 1.

24 Mögliche Werte in Menge S 2.

25 Vgl. Schilling (2017), S. 151 f.

26 Vgl. Schilling (2017), S. 151 f.

27 Kap.​ 2, 2.​1.

28 Siehe oben 2.2.


© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018
Georg Borges und Brigitte Werners (Hrsg.), Identitätsmanagement im Cloud Computing, https://doi.org/10.1007/978-3-662-55584-
2_6

6. Konkretisierung rechtlicher Anforderungen an das


Identitätsmanagement im Cloud Computing
Torben Kriegesmann1 und Peter Schneidereit2
(1) Landgericht Essen, 45130 Essen, Deutschland
(2) Luther Rechtsanwaltsgesellschaft, Service Line IP/IT, 45127 Essen, Deutschland

Torben Kriegesmann (Korrespondenzautor)


Email: torben.kriegesmann@rub.de

Peter Schneidereit
Email: peter.schneidereit@luther-lawfirm.com

1 Ausgangssituation
2 Branchenübergreifende Anforderungen an das Identitätsmanagement in der Cloud
2.1 Allgemeine Anforderungen
2.1.1 Pflichten des Cloud-Anbieters
2.1.1.1 Pflicht zur Implementierung sicherer Authentifizierungssysteme
2.1.1.1.1 Pflichten des Anbieters nach TMG
2.1.1.1.1.1 Authentifizierungssysteme als verpflichtende technisch-organisatorische Maßnahme
2.1.1.1.1.2 Technische Möglichkeit und wirtschaftliche Zumutbarkeit
2.1.1.1.1.3 Bestimmung des Schutzbedarfs
2.1.1.1.1.4 Konkret erforderliche Maßnahmen
2.1.1.1.2 Pflichten des Anbieters nach allgemeinen Vorschriften
2.1.1.2 Sonstige organisatorische Pflichten zur Herstellung kontextual angemessener IT-
Sicherheit
2.1.1.3 Pflicht zur Aufklärung des Cloud-Nutzers
2.1.1.4 Pflichten bei erkanntem Identitätsmissbrauch
2.1.2 Pflichten des Cloud-Nutzers
2.1.2.1 Sicherung der IT-Infrastruktur
2.1.2.2 Sicherung des Authentifizierungsmediums
2.1.2.2.1 Grundsatz
2.1.2.2.2 Verbot der Weitergabe des Authentifizierungsmediums
2.1.2.3 Weitergehende Schutzvorkehrungen
2.1.2.4 Pflicht zur Nutzung sicherer Authentisierungsmechanismen
2.1.2.4.1 Ausgangspunkt
2.1.2.4.2 Reichweite der Pflichten im Einzelfall
2.1.2.4.3 Sonderfall Verbraucher
2.1.3 Vertragliche Konkretisierung und Abdingbarkeit
2.1.3.1 Grundsatz
2.1.3.2 AGB-rechtliche Besonderheiten
2.1.3.2.1 Konkretisierung der Geheimhaltungspflicht
2.1.3.2.2 Haftungsregelungen
2.1.3.2.2.1 Grundlegende Zulässigkeitsgrenzen
2.1.3.2.2.2 Haftung für einfache Fahrlässigkeit
2.1.3.2.2.3 Festlegung einer Haftungsobergrenze
2.2 Besondere datenschutzrechtliche Anforderungen
2.2.1 Pflichten des Cloud-Anbieters
2.2.1.1 Grundsatz
2.2.1.2 Konkret erforderliche Einzelmaßnahmen
2.2.1.3 Pflicht zur Implementierung sicherer Authentifizierungssysteme
2.2.1.4 Verhältnis zu allgemeinen Verkehrspflichten
2.2.2 Pflichten des Cloud-Nutzers
2.2.2.1 Pflicht zur sorgfältigen Auswahl
2.2.2.2 Pflicht zur Überwachung
2.2.2.3 Pflicht zur Dokumentation
2.2.2.4 Praktische Umsetzung durch Zertifizierung
3 Branchenspezifische Anforderungen
3.1 Kreditwirtschaft
3.1.1 Grundsatz
3.1.2 Anforderungen an Authentifizierungsmechanismen
3.2 Sozialversicherungsträger
3.2.1 Grundsatz
3.2.2 Anforderungen an Authentifizierungssysteme
3.3 Berufsgeheimnisträger
3.3.1 Grundsatz
3.3.2 Anforderungen an Authentifizierungssysteme
4 Besondere Anforderungen an Verwaltung und Justiz
4.1 Anforderungen an E-Government
4.2 Anforderungen an E-Justice
5 Rechtliche Bewertung der optimalen Sicherheitsmaßnahmen nach
5.1 Mittelständische Unternehmen
5.1.1 Anforderungen bei geringem Schutzbedarf
5.1.2 Anforderungen bei hohem und sehr hohem Schutzbedarf
5.1.3 Anforderungen bei durchschnittlichem Schutzbedarf
5.2 Kreditwirtschaft
5.3 Sozialversicherungsträger
5.4 Berufsgeheimnisträger
6 Weitere rechtliche Implikationen des Identitätsmanagements im Überblick
6.1 Rechtsscheinhaftung
6.1.1 Ausgangspunkt
6.1.2 Voraussetzungen
6.1.2.1 Rechtsscheintatbestand
6.1.2.2 Zurechenbarkeit
6.2 Beweisrecht
6.2.1 Ausgangssituation
6.2.2 Anscheinsbeweis im Bankrecht
6.2.3 Anwendung auf Cloud-Plattformen
7 Fazit
Literatur

1 Ausgangssituation
Im vierten Kapitel wurden die rechtlichen Rahmenbedingungen des Identitätsmanagements in der
Cloud dargelegt. Im Rahmen des sechsten Kapitels geht es nunmehr darum, diese zu
konkretisieren. Es stellt sich insbesondere die Frage, zu welchen konkreten Maßnahmen die zuvor
erörterten Rechtsgrundlagen die am Identitätsmanagement Beteiligten verpflichten. Zur
Beantwortung dieser Frage werden zunächst die generellen Anforderungen an Cloud-Anbieter und
Nutzer näher erläutert. Dies betrifft insbesondere die sich aus TMG und BDSG ergebenden
Pflichten. Sodann wird auf branchenspezifische Anforderungen für die Kreditwirtschaft, die
Sozialversicherungs- und Berufsgeheimnisträger eingegangen.
Besonderes Gewicht kommt den in Kap.​ 5 herausgearbeiteten, unter ökonomischen
Gesichtspunkten als sinnvoll einzustufenden, Sicherheitsmaßnahmen für konkrete Einsatzfelder zu.
Im Rahmen der nunmehr anzustellenden rechtlichen Analyse soll untersucht werden, ob bzw.
inwieweit diese aus wirtschaftlicher Sicht empfehlenswerten Sicherheitsvorkehrungen auch den
rechtlichen Anforderungen an ein sicheres Identitätsmanagement genügen. Hierbei ist v. a. zu
prüfen, ob, auf welche Weise und in welchem Umfang diese Sicherheitsmaßnahmen ggf. erweitert
werden müssten, um die Gewährleistung eines rechtskonformen Identitätsmanagements in der
Cloud sicherzustellen. Im Rahmen dieser Untersuchung wird insbesondere zu würdigen sein, wie
sich die Besonderheiten in bestimmten Cloud-Anwendungsszenarien inhaltlich auf die konkreten
rechtlichen Anforderungen auswirken.
Schließlich werden im hiesigen Kontext auch sonstige rechtliche Anforderungen konkretisiert,
die in Kap.​ 4 eingeführt wurden; so etwa in den Bereichen Verwaltung und Justiz. Auch die
Anforderungen an eine rechtssichere Beweisführung unter Zuhilfenahme von potenziellen
Beweiserleichterungen sowie die Möglichkeit einer Rechtsscheinhaftung sind Gegenstand der
Erörterung. Abschließend soll eine zusammenfassende Gesamtwürdigung erfolgen, in welcher die
Erreichbarkeit, Umsetzung und Durchsetzbarkeit eines rechtssicheren Identitätsmanagements für
den Bereich des Cloud Computing bewertet wird.
2 Branchenübergreifende Anforderungen an das
Identitätsmanagement in der Cloud
Einige der im vierten Kapitel dargestellten rechtlichen Rahmenbedingungen gelten für nahezu alle
Cloud-Sachverhalte. Hierbei handelt es sich insbesondere um das Vertrags- und Deliktsrecht
sowie das Recht der Telemedien. Ebenfalls zu beachten sind hier die datenschutzrechtlichen
Anforderungen.

2.1 Allgemeine Anforderungen


2.1.1 Pflichten des Cloud-Anbieters
Wie im Rahmen des vierten Kapitels dargestellt,1 trifft den Cloud-Anbieter nach § 241 Abs. 2
BGB grundsätzlich eine vertragliche Schutzpflicht dahingehend, zur Absicherung des
Identitätsmanagements die erforderlichen IT-Sicherheitsmaßnahmen zu ergreifen. Weitere
rechtliche Anforderungen ergeben sich auch aus den deliktischen Verkehrspflichten.2 Deren Inhalt
und Umfang entsprechen allerdings weitestgehend den vertraglichen Schutzpflichten aus § 241
Abs. 2 BGB.3 Dementsprechend werden die deliktischen Verkehrspflichten und die vertraglichen
Schutzpflichten im Folgenden gemeinsam dargestellt. Weitere Pflichten ergeben sich insbesondere
aus § 13 Abs. 7 TMG. Da § 13 TMG, wie in Kap.​ 4 ausgeführt, auf nahezu alle Cloud Computing-
Anbieter anwendbar ist4 und unabhängig davon gilt, ob der Dienstanbieter personenbezogene
Daten verarbeitet oder branchenspezifischen Anforderungen unterliegt, sind die sich aus dieser
Norm ergebenen Pflichten für die vorliegende Untersuchung von besonderer Relevanz. Dies gilt
umso mehr, als § 13 Abs. 7 TMG sowohl für die vertraglichen,5 als auch für die deliktischen6
Pflichten Mindeststandards setzt.
2.1.1.1 Pflicht zur Implementierung sicherer Authentifizierungssysteme
Ein Kernelement des Identitätsmanagements ist die Implementierung sicherer
Authentifizierungssysteme. Im Folgenden soll dargestellt werden, inwieweit den Cloud-Anbieter
die Pflicht trifft, dem Cloud-Nutzer sichere Verfahren zur Identifikation anzubieten. Am Ende
dieses Abschnitts wird anhand der gewonnenen Erkenntnisse eine rechtliche Bewertung der in
Kap.​ 5 durchgeführten Untersuchung vorgenommen.7 Bereichsspezifische Anforderungen an
Authentifizierungssysteme werden in den jeweiligen gesonderten Abschnitten erörtert.8
In der Praxis nimmt ein großer Teil der Online-Angebote, etwa E-Mail-Dienste, eine
Authentifizierung der Nutzer lediglich anhand eines Abgleichs von Nutzername und Passwort, also
mit einer Ein-Faktor-Authentifizierung,9 vor. Dieses Verfahren sieht sich in der Praxis zahlreichen
Angriffen ausgesetzt und bietet daher nur eine geringe Sicherheit.10 Einige Anbieter bieten
sicherere Formen der Authentifizierung, etwa unter Einsatz von Hardware Token, optional an. Die
Nutzung ist dann jedoch neben dem zusätzlichen Aufwand auch häufig mit zusätzlichen Kosten für
den Nutzer verbunden, da dieser die notwendige technische Infrastruktur beschaffen muss.11
Eine explizite gesetzliche Pflicht des Cloud-Anbieters oder gar ein Anspruch des Cloud-
Nutzers auf Einsatz bestimmter Authentifizierungsverfahren besteht, sofern nicht ausnahmsweise
vertraglich vereinbart, nicht. Im Einzelfall kann eine solche Pflicht jedoch aus den Schutz- und
Verkehrspflichten des Cloud-Anbieters hergeleitet werden. Bei Verletzung der Schutz- und
Verkehrspflichten bestehen unter Umständen Schadensersatz- oder Unterlassungsansprüche gegen
den Cloud-Anbieter. Im Folgenden sollen zunächst Pflichten zur Implementierung sicherer
Authentifizierungssysteme nach den Vorgaben des TMG und anschließend nach den allgemeinen
vertrags- und deliktsrechtlichen Anforderungen untersucht werden.
2.1.1.1.1 Pflichten des Anbieters nach TMG
Nach § 13 Abs. 4 Nr. 3 TMG hat ein Diensteanbieter durch technische und organisatorische
Vorkehrungen sicherzustellen, dass der Nutzer Telemedien gegen die Kenntnisnahme Dritter
geschützt in Anspruch nehmen kann. Teilweise wurde aus dieser Norm die Pflicht zum Einsatz von
Authentifizierungsmechanismen, wie dem Abgleich von Nutzername und Passwort, abgeleitet.12
Ohne Einsatz eines solchen Authentifizierungsverfahrens wäre es Dritten bei vielen Angeboten
ohne weiteres möglich, die Nutzung des Dienstes durch eine Person auszuspähen. Näher diskutiert
wurde eine solche Pflicht, soweit ersichtlich, jedoch nicht. Insbesondere enthält § 13 Abs. 4 Nr. 3
TMG keinen Maßstab anhand dessen sich beurteilen ließe, zu welchen konkreten Maßnahmen der
Diensteanbieter verpflichtet ist. Teilweise wird insoweit auf die Vorschrift des § 109 TKG
verwiesen, welche zur Konkretisierung herangezogen werden könne und auf „erforderliche“
Maßnahmen und Vorkehrungen abstellt, die den Stand der Technik berücksichtigen sollen. Eine
Neuerung bringt insoweit das 2015 verabschiedete IT-Sicherheitsgesetz, welches in § 13 Abs. 7
TMG eine Pflicht zur Gewährleistung von IT-Sicherheit durch geschäftsmäßige Anbieter von
Telemedien statuiert hat.
2.1.1.1.1.1 Authentifizierungssysteme als verpflichtende technisch-organisatorische
Maßnahme
Nach § 13 Abs. 7 S. 1 TMG sind Anbieter geschäftsmäßiger Telemedien verpflichtet, durch
technische und organisatorische Maßnahmen sicherzustellen, dass kein unerlaubter Zugriff auf die
für ihre Angebote genutzten technischen Einrichtungen möglich ist. Da die von § 13 Abs. 7 TMG
geschützten „technischen Einrichtungen“ nicht nur die physischen Datenverarbeitungsanlagen,
sondern auch die Software mit einbeziehen,13 lässt sich aus dem Gebot des Zugriffsschutzes auch
ein Gebot der Nutzung von Authentifizierungsmedien ableiten,14 sofern dies im Einzelfall möglich
und zumutbar ist. Diese Deutung scheint auch der Absicht des Gesetzgebers zu entsprechen. So
kann nach den Gesetzgebungsmaterialien bei personalisierten Telemedien das „Angebot eines
sicheren und dem jeweiligen Schutzbedarf angepassten Authentifizierungsverfahrens“ eine
Vorkehrung nach § 13 Abs. 7 S. 1 TMG sein.15
Wenn der Gesetzgeber in der Begründung von einem „Angebot“ sicherer
Authentifizierungsverfahren spricht, legt dies nahe, dass es dem Betreiber von Telemedien
grundsätzlich gestattet ist, seinen Nutzern optional auch weniger sichere oder gar völlig unsichere
Verfahren anzubieten. Dieses oben erwähnte Modell der optionalen Sicherheit ist damit nach dem
TMG grundsätzlich zulässig. Der Nutzer kann selbst wählen, ob ihm ein höherer Komfort bzw. ein
geringerer Preis oder aber eine höhere Sicherheit wichtiger ist. Müsste der Nutzer dagegen immer
auf sichere Verfahren zurückgreifen, da der Anbieter zu deren Einsatz verpflichtet wäre, würde
dies im Ergebnis einen Wohlfahrtsverlust bedeuten: Obwohl im Einzelfall ökonomisch ineffizient
und nicht erforderlich,16 müsste der Nutzer die Nachteile von sicheren Authentifizierungsverfahren
in Kauf nehmen. Gleichwohl können sowohl der Cloud-Anbieter als auch der Cloud-Nutzer zur
Verhinderung der Verletzung von Rechten Dritter unter Umständen verpflichtet sein, auf sichere
Verfahren zurückzugreifen. Dies kommt etwa in Betracht, wenn der Nutzer personenbezogene
Daten Dritter in der Cloud verarbeitet.17
§ 13 TMG regelt die Pflicht zur Nutzung von Authentifizierungssystemen nach bisherigem
Verständnis somit doppelt; sowohl in Abs. 4 als auch in Abs. 7 sind die Authentifizierungssysteme
als technisch-organisatorische Sicherheitsmaßnahmen angelegt. Anders als § 13 Abs. 4 Nr. 3
TMG beschränkt § 13 Abs. 7 TMG das Gebot jedoch nicht auf den Schutz der Nutzer.18 Somit
kann sich eine Pflicht zum Einsatz sicherer Authentifizierungssysteme auch bezüglich der
Authentifizierung der eigenen Mitarbeiter ergeben. Im Hinblick auf die weitergehende und
speziellere Regelung des § 13 Abs. 7 TMG ist ein Rückgriff auf § 13 Abs. 4 damit insoweit nicht
mehr erforderlich.
2.1.1.1.1.2 Technische Möglichkeit und wirtschaftliche Zumutbarkeit
Die Pflicht zur Nutzung eines sicheren Authentifizierungsverfahrens steht nach § 13 Abs. 7 TMG
unter der Prämisse der technischen Möglichkeit und wirtschaftlichen Zumutbarkeit. Erforderlich
ist somit eine Interessenabwägung im Einzelfall, die auf eine Verhältnismäßigkeitsprüfung
hinausläuft. So soll auch nach den Gesetzgebungsmaterialien das nach § 13 Abs. 7 TMG gebotene
Schutzniveau je nach Umfang der Datenverarbeitung und Sensibilität der verarbeiteten Daten
unterschiedlich sein.19 Damit wird die Bestimmung des erforderlichen
Authentifizierungsverfahrens im Ergebnis auf ähnliche Weise vorgenommen, wie im
Datenschutzrecht und den bereichsspezifischen Vorschriften. Auch hier wird wesentlich auf die
Sensibilität der verarbeiteten Daten abgestellt.20 Neben der Sensibilität der Daten und dem
Umfang der Datenverarbeitung ist, auch wenn die Gesetzgebungsmaterialien dies nicht explizit
erwähnen, ebenfalls das Missbrauchsrisiko in die Abwägung mit einzubeziehen.21 Dieses fällt mit
hoher Sensibilität der Daten bzw. hohem Umfang der Datenverarbeitung zwar regelmäßig, aber
nicht notwendig, zusammen. So kann bei Daten, deren Geheimhaltung für den Betroffenen
lebenswichtige Bedeutung hat, im Einzelfall dennoch ein relativ geringes Missbrauchsrisiko
bestehen.
Zudem ist es nach § 13 Abs. 7 S. 2 TMG erforderlich, dass die getroffenen Maßnahmen den
Stand der Technik berücksichtigen. Eine pauschale Pflicht, Maßnahmen nach dem Stand der
Technik zu ergreifen, statuiert § 13 Abs. 7 TMG somit nicht. Dem Zusatz kommt damit im Grunde
genommen keine eigenständige Bedeutung zu22: Schutzmaßnahmen, die den Stand der Technik
nicht einmal berücksichtigen, sind weitgehend wirkungslos und somit bei hohem Schutzbedarf
kaum geeignet, unbefugten Zugriff zu verhindern. Hinreichend sichere und dem Stand der Technik
entsprechende Authentifizierungsmechanismen sollen nach den Gesetzgebungsmaterialien
jedenfalls solche nach den aktuellen und veröffentlichten technischen Richtlinien des BSI23 sein.24
Diesen kommt damit im Ergebnis norminterpretierende Wirkung zu, was zumindest im Hinblick
auf die Rechtssicherheit zu begrüßen ist. Das BSI ist jedoch bisher sehr zögerlich in der
Empfehlung von im Einzelfall geeigneten Verfahren. So formuliert das BSI etwa, dass bei hohem
bis sehr hohem Schutzbedarf eine Zwei-Faktor Authentisierung eingesetzt werden sollte.25
Unklar ist der Bezugspunkt des Kriteriums der wirtschaftlichen Zumutbarkeit. Hier stellt sich
die Frage, ob die wirtschaftliche Zumutbarkeit in Bezug auf den konkreten Diensteanbieter zu
ermitteln ist, ob also dessen wirtschaftliche Leistungsfähigkeit eine absolute Grenze für die
Implementierung von Authentifizierungsverfahren darstellt. Diese Deutung legt die
Gesetzesbegründung nahe, wonach entscheidend ist, ob die Maßnahmen für den konkreten
Diensteanbieter wirtschaftlich zumutbar sind.26 Dies erscheint zunächst misslich. Bei bestimmten,
besonders schutzbedürftigen Daten darf der gebotene Schutz nicht unterschritten werden, weil
einem Unternehmen im Einzelfall keine finanziellen Ressourcen zur Herstellung ausreichender IT-
Sicherheit zur Verfügung stehen. Derartige, zumindest auf den ersten Blick begründete,
Befürchtungen sind jedoch erheblich zu relativieren, wenn § 13 Abs. 7 TMG im Gesamtkontext
der Vorschriften zur IT-Sicherheit betrachtet wird. Verarbeitet der Cloud-Anbieter
personenbezogene Daten, so hat er die besonderen Anforderungen des § 9 BDSG zu beachten,
welcher eine derartige Privilegierung von finanzschwachen Unternehmen nicht kennt.27
Verarbeitet der Cloud-Anbieter dagegen Daten, die zwar keinen Personenbezug aufweisen, aber
besondere wirtschaftliche Relevanz für den Cloud-Nutzer haben, so werden in der Regel
besondere vertragliche Schutzpflichten bestehen. Somit entsteht durch eine restriktive Auslegung
des § 13 Abs. 7 TMG keine Schutzlücke. § 13 Abs. 7 TMG bestimmt vielmehr einen
Mindeststandard. Wird sogar dieser Mindeststandard unterschritten, droht den Unternehmen nach
§ 16 Abs. 2 Nr. 3 TMG ein Bußgeld, während bei Verletzung von ggfs. strengeren vertraglichen
oder datenschutzrechtlichen Schutzpflichten zudem Haftungsrisiken bestehen.
Die wirtschaftliche Zumutbarkeit darf jedoch im Rahmen des Identitätsmanagements nicht auf
die Frage beschränkt bleiben, ob der Cloud-Anbieter die Kosten für die Implementierung eines
bestimmten Authentifizierungsverfahrens tragen kann. Vielmehr ist hier ebenso zu berücksichtigen,
ob dessen Kunden eine ausreichende Toleranz gegenüber der Einführung solcher Verfahren haben.
Zu denken ist hier vor allem an Anbieter, die sich an Verbraucher richten, beispielsweise
Anbieter von E-Mail-Diensten oder sozialen Netzwerken. Überzogene Anforderungen könnten
dazu führen, dass die Kunden auf andere Anbieter ausweichen, die den deutschen Anforderungen
nicht unterliegen oder gar gänzlich von der Nutzung des Angebots absehen. Gleichzeitig darf die
Trägheit des Kundenstamms kein Argument sein, zum Schutz Dritter zwingend erforderliche
Sicherheitsmaßnahmen zu unterlassen.

2.1.1.1.1.3 Bestimmung des Schutzbedarfs


Das TMG gibt keinen Hinweis, wann ein Datum als „sensibel“ und aus diesem Grund als
besonders schutzbedürftig gilt, womit erhöhte Anforderungen für den Cloud-Anbieter verbunden
sind. Insoweit ist zunächst zu beachten, dass erhöhte Anforderungen an die Authentifizierung nicht
bereits dann bestehen, wenn das Unternehmen in irgendeiner Form besonders sensible Daten
verarbeitet. Die erhöhten Anforderungen gelten vielmehr nur soweit, wie der Nutzer oder die
Mitarbeiter des Cloud-Anbieters nach erfolgter Authentifizierung und Autorisierung Zugriff auf
die sensiblen Daten erhalten. Somit können etwa die Anforderungen an die Authentifizierung von
Mitarbeitern auseinanderfallen, wenn diese Zugriffsrechte in unterschiedlichem Ausmaß
innehaben. Es ist damit denkbar, dass ein Unternehmen verpflichtet ist, für bestimmte Mitarbeiter
eine Zwei-Faktor Authentifizierung vorzusehen, bei anderen Mitarbeitern oder Kunden dagegen
auf eine Authentifizierung mittels Nutzername/Passwort zurückgreifen kann.
Um die Rechtsanwendung zu erleichtern, bietet es sich in Bezug auf die sensiblen Daten an,
zwischen verschiedenen Schutzklassen zu unterscheiden.28 Im Folgenden soll zwischen geringem,
durchschnittlichem, hohem und sehr hohem Schutzbedarf differenziert werden. Bei der Frage, in
welche Kategorie ein Datum einzuordnen ist, ist insbesondere zu berücksichtigen, ob der
Gesetzgeber den besonderen Schutz in bestimmten Normen anerkannt hat.
Von Bedeutung für den Schutzbedarf von Daten ist zunächst deren Personenbezug. Einen
praxistauglichen Leitfaden für die Feststellung des Schutzbedarfs personenbezogener Daten bietet
das Schutzklassenkonzept der AG „Rechtsrahmen des Cloud Computing“ im BMWi-geförderten
Programm „Trusted Cloud“.29 Aus der Tatsache, dass ein Datum personenbezogen ist, ergibt sich
nicht ohne Weiteres ein hoher Schutzbedarf. Ein solcher wäre aufgrund der Weite des Begriffs
ansonsten der Regelfall. Entscheidend ist vielmehr darauf abzustellen, ob die Daten eine
erhebliche Aussagekraft über die Persönlichkeit und Lebensumstände des Betroffenen haben bzw.
entsprechende Schlüsse zulassen und ob sich die Verwendung der Daten zu Lasten des Betroffenen
auswirken kann bzw. im Extremfall eine Gefährdung für Leib und Leben darstellt.30 Je nach
Aussagekraft der Daten kann danach ein geringer bis sehr hoher Schutzbedarf bestehen. Das
Datenschutzrecht kennt zudem „besondere Arten personenbezogener Daten“ welche nach § 3 Abs.
9 Datenschutzrecht als Angaben über die rassische und ethnische Herkunft, politischen Meinungen,
religiösen oder philosophischen Überzeugungen, Gewerkschaftszugehörigkeit, Gesundheit oder
das Sexualleben definiert werden und besonderen Schutz genießen (künftig: Art. 9 DSGVO). Die
Verarbeitung solcher Daten impliziert unmittelbar einen erhöhten Schutzbedarf. Davon abgesehen
besteht ein hoher bis sehr hoher Schutzbedarf immer dann, wenn branchenspezifische Vorgaben
zum Schutz der Daten bestehen. Wenn der Gesetzgeber in einem Sonderfall den besonderen Schutz
von Daten anerkannt hat, ist diese Wertung auf § 13 Abs. 7 TMG zu übertragen.
Da § 13 Abs. 7 TMG keine datenschutzrechtliche Vorschrift ist,31 kann sich die Sensibilität
eines Datums insbesondere auch unabhängig von seiner Personenbezogenheit ergeben. So
genießen etwa Betriebs- und Geschäftsgeheimnisse besonderen Schutz gegen ihren Verrat nach §
17 UWG. Die Sensibilität eines Datums kann sich also nicht nur aus seiner
persönlichkeitsrechtlichen, sondern auch aus seiner wirtschaftlichen Bedeutung ergeben.
Die Missbrauchsgefahr, welche neben der Sensibilität der Daten das entscheidende
Abwägungskriterium darstellt, kann nicht systematisch aus anderen Normen hergeleitet werden,
sondern ist im Regelfall empirisch zu bestimmen: So ist insbesondere dann von einer erheblichen
Missbrauchsgefahr auszugehen, wenn es in vergleichbaren Fällen bereits zu Missbrauch mit nicht
nur unerheblichen Schäden gekommen ist.32 Fehlt es an entsprechenden Erfahrungswerten, so
indizieren hohe Sensibilität der Daten sowie ein hoher Umfang der Datenverarbeitung eine
erhebliche Missbrauchsgefahr.
Gerade bei an Verbraucher adressierten Angeboten wird der Cloud-Anbieter häufig keine
Kenntnis darüber haben, ob besonders sensible Daten verarbeitet werden bzw. ob im Einzelfall
eine hohe Missbrauchsgefahr besteht. Zu denken ist etwa an einen E-Mail-Anbieter, welcher den
Inhalt der Mails seiner Kunden auf eigenen Servern speichert. Gerade bei einem privaten E-Mail-
Dienst muss der Provider davon ausgehen, Gesundheitsdaten oder ähnlich schutzbedürftige
Informationen zu verarbeiten. Sofern entsprechende erkennbare Anhaltspunkte bestehen, muss der
Diensteanbieter somit die erhöhten Anforderungen erfüllen. Im unternehmerischen Bereich hängt
der zu fordernde Schutzumfang in derartigen Fällen wesentlich davon ab, ob der Cloud-Nutzer den
Cloud-Anbieter auf die besondere Schutzbedürftigkeit der Daten hingewiesen hat, da diese für den
Cloud-Anbieter noch schwieriger zu erkennen sein dürfte.
2.1.1.1.1.4 Konkret erforderliche Maßnahmen
Je größer der Schutzbedarf ist, desto höhere Anforderungen sind an das
Authentifizierungsverfahren zu stellen. Allgemein ist festzuhalten, dass ab einem hohen
Schutzbedarf eine Zwei-Faktor-Authentifizierung33 einzusetzen ist. Eine detailliertere
Auseinandersetzung findet sich am Ende des Abschnitts, wo unter Berücksichtigung der
datenschutzrechtlichen, telemedienrechtlichen sowie vertraglichen und deliktischen
Anforderungen für konkrete Szenarien rechtliche Vorgaben herausgearbeitet werden.34
2.1.1.1.2 Pflichten des Anbieters nach allgemeinen Vorschriften
Über die soeben dargestellten Anforderungen des § 13 Abs. 7 TMG hinaus stellt sich die Frage,
ob Cloud-Anbieter nach allgemeinen vertraglichen und deliktischen Grundsätzen
deckungsgleichen Pflichten unterliegen oder ob sich insoweit Abweichungen ergeben. Dies ist in
zweierlei Hinsicht relevant: Zum einen ist, wie oben dargestellt,35 im Einzelfall insbesondere im
Rahmen von IaaS-Dienstleistungen denkbar, dass ein Cloud-Anbieter nicht dem TMG unterfällt.
Zum anderen könnten weiterreichende vertragliche und deliktische Pflichten § 13 Abs. 7 TMG in
der Praxis, jedenfalls für die hier untersuchten Fallgestaltungen, bedeutungslos machen.36
Abseits branchenspezifischer Anforderungen sowie Anforderungen des Datenschutzrechts
werden Pflichten zur Implementierung sicherer Authentifizierungssysteme allerdings nur selten
diskutiert. Wie dargestellt, bestehen vertragliche und deliktische Verkehrspflichten ausschließlich
unter der Prämisse der Zumutbarkeit.37 Da insoweit eine Interessenabwägung im Einzelfall
vorzunehmen ist, ist es schwierig, bezüglich der einzusetzenden Authentifizierungssysteme
konkrete und allgemeingültige Mindeststandards zu formulieren. So wird in der Literatur etwa
pauschal angenommen, dass eine vertrags- und deliktsrechtliche Pflicht bestehe, aus Sicht eines
objektiven Dritten ausreichend sichere Vorkehrungen zu treffen.38 Vereinzelt finden sich jedoch
auch weitergehende Stellungnahmen. Jedenfalls in Bereichen, in denen eine hohe
Missbrauchsgefahr besteht, soll eine Pflicht zur Ablösung der tradierten Authentisierung mittels
Nutzername/Passwort naheliegen.39 Ohne Bezugnahme auf eine konkrete Rechtsgrundlage
empfiehlt auch das BSI für das Cloud Computing zumindest im Rahmen „sicherheitskritische[r]
Anwendungsbereiche“ eine Zwei-Faktor-Authentisierung.40 In der Regel wird davon auszugehen
sein, dass die deliktischen Pflichten keine höheren, aber auch keine geringeren Anforderungen
aufstellen als § 13 Abs. 7 TMG. Auch insoweit ist eine Interessenabwägung im Einzelfall geboten.
Das gleiche gilt für die vertraglichen Pflichten, sofern die Parteien insoweit nichts Abweichendes
vereinbart haben. Allerdings können deliktische Verkehrssicherungspflichten sowie auch
vertragliche Schutzpflichten auch dann bestehen, wenn sie einer Partei finanziell nicht zumutbar
sind. Es kommt hier darauf an, ob die im jeweiligen Bereich herrschende Verkehrsauffassung die
Maßnahmen für zulässig hält.41 Es ist nicht davon auszugehen, dass der Gesetzgeber für solche
Fälle durch § 13 Abs. 7 TMG das Schutzniveau herabsenken wollte. Im Einzelfall ist somit
denkbar, dass sich aus den allgemeinen Vorschriften strengere Anforderungen ergeben als aus § 13
Abs. 7 TMG. Insoweit sollte jedoch Zurückhaltung geboten sein.
2.1.1.2 Sonstige organisatorische Pflichten zur Herstellung kontextual angemessener IT-
Sicherheit
Welche Maßnahmen zum Erreichen eines angemessenen IT-Sicherheitsniveaus konkret
erforderlich sind und wie umfangreich diese ausfallen müssen, lässt sich nicht pauschal festlegen.
Um den Gegebenheiten des jeweiligen tatsächlichen Hintergrunds hinreichend Rechnung
tragen zu können, muss vielmehr eine umfassende Risikoanalyse im Einzelfall erfolgen, die die
insofern vorliegenden Rahmenbedingungen auswertet.42 Nur so lässt sich ermitteln, wie
ausgeprägt das IT-Sicherheitsniveau im jeweiligen Anwendungsfall tatsächlich ausfallen muss, um
die sich stellenden spezifischen Gefahren adäquat aufzufangen.
Maßgebliche Kriterien des in diesem Rahmen anzustellenden Abwägungsvorgangs sind
insbesondere Ausmaß und Bekanntheit der drohenden Gefahr sowie die Wahrscheinlichkeit des
Eintritts eines Schadens einerseits und das Ausmaß des Vermeidungsaufwands für den Anbieter
andererseits.43 Bei einer cloudbezogenen Risikoanalyse müssen zudem die spezifischen Risiken,
die sich aus diesem Geschäftsmodell ergeben, besonders gewürdigt werden.44 Denn durch die
Ansammlung großer Datenmengen, die noch dazu ortsunabhängig online abrufbar sind, wird ein
auf Hacker und sonstige Angreifer besonders attraktiv wirkendes Angriffsziel geschaffen. Diesem
Umstand muss durch eine Anpassung des IT-Sicherheitsniveaus Rechnung getragen werden.
Ganz elementare Schutzvorkehrungen, wie die Errichtung einer Firewall und die Installation
einer Antivirensoftware, sollten in diesem Kontext selbstverständlich sein.45 Außerdem erscheint
auch die Etablierung einer ausgereiften Verschlüsselungstechnik, eines Monitoring-Systems und
einer sachgerechten Notfallstrategie unabdingbar.46 Derart grundlegende IT-
Sicherheitsvorkehrungen dürfen bei einem geschäftsmäßigen Cloud-Anbieter vorausgesetzt
werden. Es erscheint insofern kein Szenario denkbar, in dem der ermittelte Schutzbedarf derart
gering ausfallen könnte, dass diese elementaren Maßnahmen obsolet würden. Über diese
Grundanforderungen hinaus können sich weitere Pflichten ergeben, etwa die Durchführung
besonderer Mitarbeiter-Schulungen zur Vermeidung von Angriffen über Social-Engineering oder
die physische Sicherung der Serverräume durch Wachpersonal.
2.1.1.3 Pflicht zur Aufklärung des Cloud-Nutzers
Fraglich ist weiterhin, ob und ggf. in welchem Umfang der Cloud-Anbieter den Cloud-Nutzer über
im Rahmen des Identitätsmanagements bestehende Risiken aufklären muss. Diese Überlegung
drängt sich unter dem Gesichtspunkt auf, dass im digitalen Umfeld häufig Identitätsmissbrauch
betrieben wird.
Derartige Informationspflichten sind bisher insbesondere im Banksektor hinsichtlich der
Gefahren bei der Nutzung von Online-Banking-Plattformen anerkannt.47 Allerdings spielt hierbei
insbesondere die Erwägung eine Rolle, dass das Online-Banking grundsätzlich den unmittelbaren
Transfer von Finanzmitteln ermöglicht und mithin insofern besonders gefahrgeneigt ist.
Im hiesigen Kontext geht es indes v. a. um das Identitätsmanagement im Rahmen
typischerweise weit weniger risikobehafteter Cloud-Plattformen. Es stellt sich daher die Frage,
ob die obige Sichtweise auf diese Angebote übertragen werden kann. Insbesondere insoweit
Online-Handelsplattformen betroffen sind, wird man indes auch in diesem Kontext eine generelle
Informationspflicht hinsichtlich der wesentlichen potenziellen Nutzungsrisiken annehmen
müssen.48 Denn der Missbrauch von Nutzerkonten hat hier zwar nicht notwendig den Transfer von
Geld zur Folge; der Nutzer der Plattform sieht sich aber unter Umständen erheblichen Forderungen
des vermeintlichen Vertragspartners ausgesetzt. Außerdem können unter Umständen vom Nutzer
hinterlegte Zahlungsmethoden missbraucht werden, sodass auch insofern zunächst eine erhebliche
Belastung des Anwenders eintritt, deren Revisibilität zudem nicht in allen Fällen gegeben sein
wird. Da die Information über die zentralen Anwendungsrisiken dem Anbieter schließlich auch
keine unzumutbaren Aufwendungen abverlangt, ist vom generellen Bestehen einer dahingehenden
Informationspflicht auszugehen.
Unklar ist schließlich noch der Umfang dieser Verpflichtung. Auch dieser Aspekt wurde
bisher insbesondere im bankrechtlichen Kontext diskutiert.49 Im Wesentlichen dürfte es im
Bereich sonstiger Online-Plattformen genügen, wenn der Nutzer vom Anbieter auf besonders
praxisrelevante Anwendungsrisiken und die wirksamsten Schutzmaßnahmen hiergegen
hingewiesen wird.50 Diese sind im Einzelfall je nach eingesetztem Authentifizierungsverfahren
verschieden. Macht der Cloud-Anbieter etwa von E-Mail TAN Gebrauch, so ist es von
essenzieller Bedeutung, dass er den Cloud-Nutzer darüber aufklärt, dass die Sicherheit
entscheidend von der Sicherheit des E-Mail-Kontos abhängt.
2.1.1.4 Pflichten bei erkanntem Identitätsmissbrauch
In offen gestalteten Online-Plattformen, wie etwa eBay, besteht die Gefahr, dass Unbefugte unter
fremdem Namen auftreten und ggfs. rechtswirksame Handlungen tätigen. Dieser
Identitätsmissbrauch kann durch sichere Authentifizierungssysteme nicht verhindert werden, da die
Täter nicht notwendig ein Profil des Betroffenen verwenden, sondern ein neues Profil des
gleichen Namens erstellen. Es stellt sich die Frage, inwieweit der Cloud-Anbieter verpflichtet ist,
solche Angriffe, welche das Namens- und das Persönlichkeitsrecht des Betroffenen verletzen, zu
verhindern.
Das Ausmaß der diesbezüglichen Verpflichtungen bestimmt sich primär am Maßstab der
Zumutbarkeit.51 Jedenfalls zumutbar ist zunächst, eine durch den Betroffenen angezeigte
Rechtsverletzung zeitnah zu beenden, indem etwa das unbefugt in fremdem Namen erstellte
Benutzerkonto aus dem System entfernt wird. Hierüber hinaus muss jedoch in gewissem Umfang
auch dafür Sorge getragen werden, dass vergleichbare Rechtsverletzungen in Zukunft unterbleiben.
Ein geeignetes Mittel zur technischen Umsetzung dieser Vorgabe können insbesondere Wortfilter
darstellen, die die nochmalige unbefugte Verwendung der missbrauchten Identität verhindern.52
Eine präventive Kontrolle sämtlicher neuer Einträge auf potenziellen Identitätsmissbrauch wurde
von der Rechtsprechung dagegen zu Recht abgelehnt. Der dafür erforderliche Aufwand stünde
nicht im Verhältnis zum Nutzen und würde das Geschäftsmodell des Plattformbetreibers ernstlich
bedrohen.

2.1.2 Pflichten des Cloud-Nutzers


Den Cloud-Nutzer trifft die Verpflichtung, die in seinem Verantwortungsbereich befindlichen
Komponenten des Authentifizierungsverfahrens hinreichend abzusichern.53 Dies betrifft sowohl
die grundlegende Sicherung des eingesetzten Endgeräts als auch den verantwortungsvollen
Umgang mit dem ihm zugewiesenen Authentifizierungsmedium. Darüber hinaus ist der Cloud-
Nutzer unter Umständen verpflichtet, nur solche Cloud-Angebote zu verwenden, die ein sicheres
Authentifizierungsverfahren anbieten.
Weiterhin wurde im vierten Kapitel aufgezeigt, dass auch den Cloud-Nutzer im Rahmen des
Identitätsmanagements gewisse Schutz- und Verkehrspflichten treffen. Je nach Einzelfall kommen
verschiedenste Pflichten in Betracht.
Zunächst können Pflichten des Cloud-Nutzers aus dem Verhältnis zum Cloud-Anbieter
entstehen. Diese betreffen insbesondere den verantwortungsvollen Umgang mit denjenigen
Versatzstücken des Authentifizierungsverfahrens, die sich in dessen Verantwortungsbereich
befinden. Zu denken ist hier insbesondere an die Pflicht zur sicheren Aufbewahrung der
eingesetzten Authentifizierungsmedien.54
Weiterhin ergeben sich Pflichten des Cloud-Nutzers aus dem Verhältnis zu seinen Kunden
bzw. Dritten gegenüber. Wenn der Cloud-Nutzer in der Cloud eigene Angebote platziert, die er
wiederum seinen Kunden zur Verfügung stellt, ist er in einer dem Cloud-Anbieter vergleichbaren
Position. Insbesondere ist hier denkbar, dass der Cloud-Nutzer – wie auch der Cloud-Anbieter –
verpflichtet ist, seinen Kunden sichere Authentifizierungsverfahren anzubieten.
2.1.2.1 Sicherung der IT-Infrastruktur
Fraglich ist zunächst, ob der Cloud-Nutzer korrespondierend zu der Systemsicherungspflicht des
Anbieters seinerseits dafür Sorge tragen muss, dass das zur Nutzung des Dienstes verwendete
Endgerät ein hinreichendes IT-Sicherheitsniveau aufweist. Dies wird im Grundsatz von der
überwiegenden Auffassung selbst bei nicht geschäftsmäßig tätigen Personen bejaht.55 Gerade im
rein privaten Verwendungskontext sind die Anforderungen insofern aber nicht überzustrapazieren.
Zumindest grundlegende Sicherheitsvorkehrungen, wie die Verwendung aktueller
Antivirensoftware,wird man indes durchaus auch in der privaten Nutzungsumgebung verlangen
können.56 Hinsichtlich der Etablierung einer umfassenden Firewall wird zum Teil einschränkend
vertreten, dass die aktive Errichtung einer solchen zwar nicht verlangt werden könne; zugleich
aber eine aktive Firewall auch nicht deaktiviert werden dürfe.57 Die bisher in der Literatur
vertretenen Auffassungen zur Einschränkung der Nutzerpflichten hinsichtlich der Aktualisierung
von Antivirensoftware und der grundsätzlichen Errichtung einer Firewall sind auf die heutige
Ausgangssituation allerdings wohl nur noch eingeschränkt übertragbar.
Die meisten Antivirenprogramme führen eine regelmäßige Aktualisierung im Hintergrund
durch, ohne dass es insofern einer aktiven Einflussnahme durch den Nutzer bedarf. Auch die
abschirmende Wirkung einer Firewall ist heute dem durchschnittlichen IT-Anwender im Regelfall
in den Grundzügen bekannt. Dementsprechend sind Einschränkungen in diesen ganz grundlegenden
Bereichen der IT-Sicherheit nach aktuellem Verständnis nicht mehr gerechtfertigt. Es ist daher
davon auszugehen, dass private Nutzer eine aktuelle Antivirensoftware und eine umfassende
Firewall in ihr System integrieren müssen.
Ist der Cloud-Nutzer selbst Unternehmer, so treffen diesen grundsätzlich im Rahmen der
Zumutbarkeit im Einzelfall die gleichen Pflichten zur Sicherung der IT-Infrastruktur wie den
Cloud-Anbieter.
2.1.2.2 Sicherung des Authentifizierungsmediums
Weiterhin genügt es nicht, wenn der Cloud-Nutzer nur für die Sicherheit seiner IT-Infrastruktur
sorgt. Darüber hinaus muss er auch mit dem ihm anvertrauten Authentifizierungsmerkmal sorgfältig
umgehen und insbesondere dessen Vertraulichkeit wahren.
2.1.2.2.1 Grundsatz
Diese Verpflichtung entstammt abermals originär dem Bankensektor, wo die zur Geldabhebung
benötigte PIN der eigenen EC-Karte streng geheim zu halten ist. Dies folgt dort bereits aus dem in
neuerer Zeit ins Gesetz eingefügten § 675 l BGB; wobei die vertraglichen Rahmenbedingungen
diese Verpflichtung im Regelfall nochmals ausdifferenzieren und konkretisieren.58
Nichts anderes gilt im Wesentlichen bei sonstigen Authentifizierungsmerkmalen, wie
Passwörtern, die einem konkreten Nutzer Zugang zur jeweiligen Plattform gewähren – auch dort
wird regelmäßig eine vertragliche Schutzpflicht zur Geheimhaltung dieses Kennworts
angenommen.59 Dementsprechend ist der Cloud-Nutzer dem Grunde nach dazu verpflichtet, das
zugewiesene Authentifizierungsmerkmal geheim zu halten.
2.1.2.2.2 Verbot der Weitergabe des Authentifizierungsmediums
Fraglich ist insofern, welche konkreten Verpflichtungen sich hieraus für den Cloud-Nutzer
ergeben. Ohne Weiteres wird die Pflicht ersichtlich, das Authentifizierungsmerkmal nicht aktiv an
Dritte zu verraten – dies impliziert der Begriff der „Geheimhaltung“ gewissermaßen als
Kerngegenstand.60 Der Cloud-Nutzer darf daher seine Authentifizierungsdaten in keiner Form
weitergeben.

2.1.2.3 Weitergehende Schutzvorkehrungen


Würde sich das Ausmaß der Verpflichtung bereits hierin erschöpfen, wäre eine effiziente
Geheimhaltung indes nicht gewährleistet. Dementsprechend müssen dem Nutzer zumindest in
gewissem Umfang auch aktive Schutzmaßnahmen bzw. das Unterlassen besonders gefahrträchtiger
Verhaltensweisen abverlangt werden.
So ist etwa für den bankrechtlichen Sektor anerkannt, dass das Kennwort nicht im
unmittelbaren Umfeld des einzusetzenden Authentifizierungsmediums niedergeschrieben werden
darf.61 Dies meint primär den Fall, in dem die niedergeschriebene PIN unmittelbar an die EC-
Karte angefügt worden ist. Die Situation bei sonstigen Cloud-Diensten ist anders, da diese
typischerweise lediglich ein internetfähiges Endgerät und kein konkretes zusätzliches
Authentifizierungsmedium voraussetzen. Notiert der Nutzer sich sodann beispielsweise sein
Passwort auf einem Zettel am heimischen Bildschirm, muss er grundsätzlich nicht damit rechnen,
dass sich Dritte rechtswidrig Zutritt zur Wohnung verschaffen und dieses ausspähen. In diesem
Verhalten wäre folglich grundsätzlich keine Pflichtverletzung des Nutzers zu sehen.62 Auch viele
weitere für die Verwendung von EC-Karten diskutierten Fallgruppen63 spielen in der Praxis der
Authentifizierung bei einem regulären Cloud-Dienst allenfalls eine untergeordnete Rolle.
Sofern allerdings die Abschottung des Kennworts gegen unbefugte Einblicke von Dritten
gefordert wird,64 kann dies in den hier interessierenden Anwendungsszenarien durchaus von
Relevanz sein. Dies gilt insbesondere, sofern die Nutzung der Cloud-Plattform über ein mobiles
Endgerät erfolgt, das in der Öffentlichkeit verwendet wird und mithin grundsätzlich auch von
Außenstehenden eingesehen werden könnte. Auch diesbezüglich ist jedoch darauf zu achten, dass
die Anforderungen, gerade an private Cloud-Nutzer, nicht überstrapaziert werden. Dies gilt umso
mehr vor dem Hintergrund, dass die dargestellten Verhaltenspflichten aufgrund der Gefahr einer
unbefugten Verwendung der EC-Karte entwickelt wurden – die Zugangsberechtigung zu Cloud-
Diensten wird im Regelfall ein deutlich geringfügigeres Schadenspotenzial implizieren, sodass
insofern nicht in gleichem Maß strenge Anforderungen gestellt werden können.
2.1.2.4 Pflicht zur Nutzung sicherer Authentisierungsmechanismen
2.1.2.4.1 Ausgangspunkt
Während den Cloud-Anbieter, wie oben beschrieben, die Pflicht trifft, im Rahmen des Zumutbaren
sichere Authentifizierungssysteme zu nutzen, stellt sich die Frage, ob auch eine korrespondierende
Pflicht des Cloud-Nutzers besteht, ausschließlich solche Cloud-Dienste zu verwenden, die sichere
Verfahren anbieten, bzw. ein solches Verfahren, sollte es lediglich optional und ggfs. gegen
Aufpreis angeboten werden, auch zu nutzen. Diese Frage wurde in der Rechtswissenschaft bisher
kaum gestellt.
Wie ein Blick auf das Datenschutzrecht zeigt, liegt eine Pflicht des Cloud-Nutzers zum Einsatz
sicherer Authentisierungsmedien aber durchaus nahe. Erfolgt die Nutzung eines Cloud-Dienstes im
Wege der Auftragsdatenverarbeitung, so ist der Cloud-Nutzer nach § 11 Abs. 2 S. 4 BDSG dazu
verpflichtet, die Einhaltung der technisch-organisatorischen Maßnahmen durch den Cloud-
Anbieter sicherzustellen (künftig: Verpflichtung zur Einhaltung der Maßnahmen nach Art. 28 Abs.
3 lit. c DSGVO). Der Pflichtenkreis des Cloud-Nutzers endet somit keineswegs mit der Sicherung
der eigenen IT-Infrastruktur bzw. dem ordnungsgemäßen Umgang mit den durch den Cloud-
Anbieter zur Verfügung gestellten Authentisierungsmedien.
Im Datenschutzrecht besteht gleichwohl eine Besonderheit: Dieses ist nur einschlägig, wenn
der Cloud-Nutzer fremde personenbezogene Daten verarbeitet. Äquivalent dazu kommt eine
Pflicht zur Nutzung sicherer Authentifizierungsmedien nur in Betracht, wenn der Cloud-Nutzer
Daten verarbeitet, deren Ausspähung oder Verlust für Dritte Nachteile bedeuten würde.
2.1.2.4.2 Reichweite der Pflichten im Einzelfall
Eine Pflicht zur Nutzung sicherer Authentifizierungsmechanismen kann sich für den Cloud-Nutzer,
ebenso wie für den Cloud-Anbieter, insbesondere aus vertraglichen Schutzpflichten und
deliktischen Verkehrspflichten ergeben.
Dabei ist zu berücksichtigen, dass die Nutzung von sicheren Authentifizierungsmechanismen
für den Cloud-Nutzer üblicherweise mit weitaus geringerem Aufwand verbunden ist als für den
Cloud-Anbieter. Während der Cloud-Anbieter das Verfahren von Grund auf implementieren muss,
kann der Cloud-Nutzer auf die Infrastruktur des Cloud-Anbieters zurückgreifen. Dennoch muss
auch der Cloud-Nutzer bei einer Zwei-Faktor-Authentisierung größeren Aufwand betreiben: So
müssen etwa Hardware Token angeschafft und ggfs. Mitarbeiter geschult werden. Zudem ist mit
der höheren Sicherheit ein Komfortverlust verbunden. Insbesondere für Verbraucher, aber auch
für Unternehmer, die verschiedenste Internetdienste nutzen, bedeutet es unter Umständen spürbare
Zeiteinbußen, sich bei jedem einzelnen Anbieter „sicher“ einzuloggen. Weiterhin muss auch die
Marktsituation beachtet werden: Existieren nur wenige oder gar keine Anbieter, die ein
bestimmtes Sicherheitsverfahren anbieten, so wird es dem Cloud-Nutzer häufig nicht zumutbar
sein, ein solches Verfahren anzuwenden.
Insoweit sind jedoch absolute Grenzen zu ziehen: Bietet kein anderes Verfahren im Hinblick
auf die Sensibilität der Daten und das Missbrauchsrisiko ausreichende Sicherheit, so kann es dem
Cloud-Nutzer im Einzelfall auch vollständig verwehrt sein, auf Cloud-Lösungen zurückzugreifen,
will er nicht riskieren, sich schadensersatzpflichtig zu machen.
Insgesamt kann auf die für den Cloud-Anbieter geltenden Anforderungen am Ende dieses
Abschnitts verwiesen werden.65 Im Zweifelsfall sind an den Cloud-Nutzer aufgrund der
geringeren Implementierungskosten allerdings höhere Anforderungen zu stellen.
2.1.2.4.3 Sonderfall Verbraucher
Anders liegt dies, soweit der Cloud-Nutzer Verbraucher ist, also die Cloud nicht überwiegend im
Rahmen seiner gewerblichen oder selbstständigen beruflichen Tätigkeit nutzt. Insoweit ist die
Wertentscheidung des Gesetzgebers zu beachten, Verbraucher in wesentlichen Punkten von
Pflichten zur IT-Sicherheit zu befreien. So knüpft § 13 Abs. 7 TMG an gewerbliche Anbieter an
und auch das BDSG nimmt die private Nutzung gem. § 1 Abs. 2 Nr. 3 von seinem
Anwendungsbereich aus (künftig: Art. 2 Abs. 2 lit. c DSGVO). Diese Wertentscheidung muss auch
und gerade im Rahmen der Nutzung von Authentisierungsverfahren berücksichtigt werden. Wäre
der Verbraucher dazu verpflichtet, bei erhöhtem Schutzbedarf der Daten von einer Nutzung von
Diensten, welche keine Zwei-Faktor-Authentifizierung einsetzen, abzusehen, würde dies zu
erheblicher Rechtsunsicherheit führen. Im Gegensatz zu gewerblich Tätigen kann dem Verbraucher
nicht zugemutet werden, sich für die tägliche Internet-Nutzung Rechtsbeistand zu suchen.
Ökonomisch erscheint es sinnvoller, insoweit den Anbietern die Pflicht aufzuerlegen, die
Sicherheit der verarbeiteten Daten zu gewährleisten.
Dieser Wertung scheint auch der BGH zu folgen. So hat dieser in seinem bekannten Halzband-
Urteil eine Haftung des Nutzers einer Internet-Plattform für eine über sein Konto begangene
Rechtsverletzung darauf gestützt, dass der Inhaber seine Authentisierungsmedien (Passwort) nicht
sorgfältig verwahrt hatte.66 Eine Pflichtverletzung durch die Nutzung eines Dienstes, der keine
Zwei-Faktor-Authentifizierung anbot, zog der BGH dagegen nicht einmal in Betracht.

2.1.3 Vertragliche Konkretisierung und Abdingbarkeit


2.1.3.1 Grundsatz
Der Diskussion über Ausgestaltung und Ausmaß der Sicherungspflichten des Cloud-Anbieters
bzw. Cloud-Nutzers kann teils entgangen werden, indem in den Nutzungsbedingungen des Cloud-
Dienstes explizit vereinbart wird, welche Pflichten die Parteien diesbezüglich treffen. Es stellt
sich sodann die Frage nach der AGB-rechtlichen Zulässigkeit dieser Regelungspraxis. Die
Konkretisierung der Pflichten im Verhältnis zwischen Cloud-Anbieter und Cloud-Nutzer wirkt
indes nur relativ, also zwischen den Parteien. Gegenüber Dritten stellen sich die Fragen nach dem
Ausmaß der Pflichten auch bei vertraglicher Konkretisierung im bipolaren Verhältnis im gleichen
Ausmaß.
2.1.3.2 AGB-rechtliche Besonderheiten
Vielen Cloud-Lösungen werden in der Praxis die vom Cloud-Anbieter standardmäßig
bereitgestellten Vertragsbedingungen zugrunde gelegt, die sich am Maßstab der AGB-rechtlichen
Zulässigkeitsgrenzen messen lassen müssen.67 Es ist dementsprechend zu untersuchen, ob bzw.
unter welchen Voraussetzungen die im Zusammenhang mit dem Identitätsmanagement und den
hieraus resultierenden Verpflichtungen typischerweise eingesetzten Klauseln diesen Grundsätzen
entsprechen.
2.1.3.2.1 Konkretisierung der Geheimhaltungspflicht
Eine generelle Risikozuweisung hinsichtlich potenziellem Identitätsmissbrauchs an den Nutzer
findet sich in den Vertragstexten von Online-Anbietern typischerweise nicht und dürfte wohl auch
mit dem Verbot einer unangemessenen Benachteiligung aus § 307 Abs. 1 S. 1 BGB nicht in
Einklang zu bringen sein.68 Ganz überwiegend finden sich in der Praxis stattdessen
ausdifferenzierte Detailregelungen zum Umfang der Geheimhaltungspflichten.69
Sofern insofern keine unzumutbar hohen Anforderungen an den Nutzer gestellt werden,
begegnet eine detaillierte Konkretisierung der, wie dargestellt,70 ohnehin bestehenden
Verpflichtung zur Geheimhaltung keinen durchgreifenden rechtlichen Bedenken. Es wird so
vielmehr ein erheblicher Beitrag zur Rechtssicherheit geleistet, von dem auch der Cloud-Nutzer
letztlich profitiert.
2.1.3.2.2 Haftungsregelungen
Zumindest mittelbar von Relevanz für das Identitätsmanagement sind die Vorschriften der Online-
Plattform zur Haftung von Cloud-Anbieter und Cloud-Nutzer. Denn die Haftung für zu Unrecht
unter einer bestimmten Nutzerkennung vorgenommene Handlungen nimmt in der Praxis
typischerweise einen großen Stellenwert ein. Dies betrifft einen der zentralen Anwendungsfälle
von Identitätsmissbrauch in der Cloud.

2.1.3.2.2.1 Grundlegende Zulässigkeitsgrenzen


Um die eigene Haftung weitestmöglich zu begrenzen, sehen kommerzielle Anbieter typischerweise
in ihren Allgemeinen Geschäftsbedingungen (AGB) ausdifferenzierte Haftungsregelungen vor.
Hierbei ist jedoch genauestens auf die Einhaltung der gesetzlichen Vorgaben zu achten.
Im Allgemeinen darf zunächst gemäß § 276 Abs. 3 BGB die Haftung für vorsätzliches
Verhalten nicht ausgeschlossen werden. Gemäß § 309 Nr. 7 lit. a und b BGB gilt dasselbe
hinsichtlich Gesundheitsbeeinträchtigungen und grober Fahrlässigkeit.71 Diese grundlegenden
Grenzen jeder Haftungsbeschränkung in AGB sollten sich eindeutig im Vertragstext
widerspiegeln, was üblicherweise jedoch auch beachtet wird.
2.1.3.2.2.2 Haftung für einfache Fahrlässigkeit
Selbst im Rahmen der dem Grunde nach zulässigen Haftungsbeschränkung für einfache
Fahrlässigkeit hat die Rechtsprechung eine erhebliche Einschränkung etabliert:72 Es darf auch
insofern kein Haftungsausschluss vereinbart werden, wenn dadurch vertragswesentliche
Rechtspositionen des Vertragspartners ausgehöhlt würden. Deshalb darf hinsichtlich sog.
Kardinalpflichten, also der grundlegenden, den Vertrag prägenden Leistungspflichten, keine
Haftungsbeschränkung bei einfach fahrlässigem Fehlverhalten enthalten sein. Vom Begriff der
Kardinalpflichten umfasst sind jedenfalls die vertraglichen Hauptleistungspflichten. Erfasst sind
darüber hinaus jedoch auch sonstige (Schutz-)Pflichten des Anbieters, bei deren Verletzung dem
Nutzer großer Schaden droht und gegen die er sich selbst nicht hinreichend schützen kann.73
Gerade sofern sensible Daten verarbeitet werden, scheidet eine Haftungsbegrenzung für fahrlässig
verursachte Mängel in der IT-Sicherheit damit regelmäßig aus.
Zu beachten ist weiterhin, dass eine Haftungsfreistellung für einfache Fahrlässigkeit, die
dieser Vorgabe der Rechtsprechung Rechnung tragen will, nicht einfach explizit
„Kardinalpflichten“ ausnehmen kann – dies wäre zu unbestimmt und für den Anwender nicht ohne
Weiteres verständlich im Sinne des § 307 Abs. 1 S. 2 BGB. Es sind insofern vielmehr detaillierte
Erläuterungen geboten, was mit diesem Begriff inhaltlich gemeint sein soll.74
2.1.3.2.2.3 Festlegung einer Haftungsobergrenze
Praxisüblich ist die AGB-rechtliche Beschränkung auf vertragstypisch vorhersehbare Schäden,
was von der Rechtsprechung grundsätzlich auch in dieser Form gebilligt wird.75 Soll dagegen eine
konkret bezifferte Haftungsobergrenze festgesetzt werden, ist dringend darauf zu achten, dass diese
nicht geringer ausfällt als der vertragstypisch zu erwartende Schaden.76

2.2 Besondere datenschutzrechtliche Anforderungen


2.2.1 Pflichten des Cloud-Anbieters
Dem Datenschutzrecht kommt besondere Bedeutung im Bereich der IT-Sicherheit zu. Gemäß § 9
BDSG haben Stellen, die selbst oder im Auftrag personenbezogene Daten erheben, verarbeiten
oder nutzen, diejenigen technischen und organisatorischen Maßnahmen zu treffen, die erforderlich
sind, um die Ausführung der Vorschriften des BDSG zu gewährleisten (künftig Art. 32 DSGVO).
Die Pflicht nach § 9 BDSG richtet sich grundsätzlich an die verantwortliche Stelle.77 Im Falle der
Auftragsdatenverarbeitung ist Adressat der Pflichten nach § 11 Abs. 4 BDSG dagegen der
Auftragnehmer78 (künftig Art. 32 Abs. 1 DSGVO). Der Auftraggeber hat die Erfüllung dieser
Pflichten im Rahmen seiner eigenen Auswahl- und Kontrollpflicht sicherzustellen. Da Cloud
Computing regelmäßig als ADV ausgestaltet ist, ist der Cloud-Anbieter als Auftragnehmer zur
Gewährleistung von Datensicherheit nach § 9 BDSG verpflichtet.79 Fraglich ist, welche
Maßnahmen hiernach ergriffen werden müssen.
2.2.1.1 Grundsatz
Die Regelung des § 9 BDSG enthält im Wesentlichen die Verpflichtung zur Gewährleistung eines
hinreichenden Datensicherheitsniveaus.80 Hierdurch soll ein angemessener Schutz der Daten der
Betroffenen vor Verlust bzw. Missbrauch durch Dritte gewährleistet werden. Eine beispielhafte81
Aufzählung von zu ergreifenden Sicherheitsmaßnahmen findet sich in der Anlage zu § 9 S. 1
BDSG.
§ 9 S. 2 BDSG enthält die Maßgabe, dass nur solche Maßnahmen erforderlich sind, deren
Aufwand in einem angemessenen Verhältnis zum angestrebten Schutzzweck steht (ebenso Art. 32
Abs. 1 DSGVO). Diese aus dem verfassungsrechtlichen Grundsatz der Verhältnismäßigkeit
abgeleitete Einschränkung führt im Ergebnis dazu, dass nicht stets ein optimales, sondern lediglich
ein dem jeweiligen Einzelfall angemessenes Schutzniveau sichergestellt werden muss.82 Zur
Ermittlung des konkret erforderlichen Sicherheitsbedarfs ist – letztlich wie im Bereich der
vertraglichen und deliktischen Haftung83 – eine Risikoanalyse durchzuführen,84 die insbesondere
die Sensibilität der betroffenen Datensätze sowie den Grad der Gefährdung würdigt.85 Aber auch
Ort, Inhalt und Art der angestrebten Datenverarbeitung sind hier ggf. von Relevanz.86
Abschließend bleibt zu erwägen, ob der Aufwand, den eine konkrete Einzelmaßnahme erfordert,
angesichts der ermittelten Risikolage unverhältnismäßig erscheint.87 Dies ist grundsätzlich dann
der Fall, wenn der ermittelte Schutzbedarf einen derart hohen Aufwand nicht zu rechtfertigen
vermag.
Anders als nach § 13 Abs. 7 TMG88 ist dabei nicht erforderlich, dass die konkret
erforderliche Maßnahme dem Anbieter auch wirtschaftlich zumutbar ist. Entscheidend ist, ob der
Aufwand in einem angemessenen Verhältnis zum angestrebten Schutzzweck steht.89 Unzureichende
finanzielle Ausstattung einer verantwortlichen Stelle darf nicht dazu führen, dass die
angemessenen Schutzmaßnahmen nicht vorgenommen werden müssen.90

2.2.1.2 Konkret erforderliche Einzelmaßnahmen


Es wird üblicherweise nicht trennscharf zwischen technischen und organisatorischen Maßnahmen
differenziert, sondern pauschalisierend ein weites Begriffsverständnis angelegt, das alle im
konkreten Einzelfall zur Zielerreichung notwendigen Maßnahmen abdeckt.91 Typische
Schutzmaßnahmen sind – gerade angesichts des in heutiger Zeit massiven Bedrohungsausmaßes –
etwa die Einrichtung eines effektiven Virenschutzes,92 die Bereitstellung personeller Ressourcen,
wie die Nominierung eines Datenschutzbeauftragten93 oder die physische und softwarebasierte
Zugangssicherung der IT-Ressourcen.94 Konkret in Bezug auf das Identitätsmanagement ist zu
fordern, dass die Zahl der Mitarbeiter mit Zugriff auf personenbezogene Daten klar begrenzt
wird.95 Dadurch wird die Gefahr von Identitätsmissbräuchen verringert und die Aufklärung
erleichtert.96 Aus denselben Gründen sollten auch Zugangsversuche protokolliert werden.97
Auch und gerade in diesem Kontext gilt, dass kaum einmal eine Risikoanalyse ein derart
geringes Bedrohungspotenzial ergeben wird, dass derart grundlegende Sicherheitsvorkehrungen
entbehrlich werden.98 Sind besonders sensible Daten, die für potenzielle Angreifer von großem
Interesse sind, betroffen, dürften darüber hinaus regelmäßig noch deutlich striktere
Schutzmaßnahmen99 indiziert sein. Ob und in welchem Umfang dies der Fall ist, lässt sich nicht
pauschal, sondern nur anhand der konkreten Risikoanalyse für das betroffene Unternehmen
beantworten.
Anzumerken ist, dass die Gewährleistung von IT-Sicherheit stets ein dynamischer Prozess
ist100 – ein zu einem bestimmten Zeitpunkt als sicher qualifiziertes System hat diesen Status nicht
für unbegrenzte Zeit erlangt. Die schnelle technische Fortentwicklung im IT-Bereich hat vielmehr
zur Folge, dass stets aktualisierte Überprüfungen durchzuführen sind, ob insbesondere die
technischen Vorkehrungen noch genügen. Anpassungsbedarf kann sich zudem auch aus geänderten
Umständen im Geschäftsmodell der verarbeitenden Stelle ergeben.

2.2.1.3 Pflicht zur Implementierung sicherer Authentifizierungssysteme


Von besonderer Relevanz für die hier untersuchte Frage sind die nach der Anlage zu § 9 BDSG
erforderlichen Zugangskontrollen (künftig Art. 32 Abs. 1 lit. c DSGVO). Im Wege der
Zugangskontrolle muss sichergestellt werden, dass die Datenverarbeitungssysteme nicht von
Unbefugten benutzt werden. Anerkannt ist, dass sich aus der Zugangskontrolle Anforderungen an
die Authentifizierung ergeben.101 Um das angemessene Sicherheitsniveau zu bestimmen, ist
insoweit eine Interessenabwägung im Einzelfall vorzunehmen.102 Weiter gehende Stellungnahmen
finden sich allerdings nur selten. So wird häufig lediglich beispielhaft auf eine Sicherung durch
Passwortschutz oder Chipkarten verwiesen.103 Vermehrt finden sich aber auch Stimmen, die
jedenfalls bei Daten mit hohem Schutzbedürfnis eine Zwei-Faktor-Authentifizierung fordern.104
Dieser Forderung ist zuzustimmen: Die datenschutzrechtlichen Anforderungen an
Authentifizierungsverfahren bestimmen sich nach dem Einzelfall und stimmen somit im
Wesentlichen mit den vertraglichen oder deliktischen überein. Dabei stellt allerdings, wie oben
angemerkt,105 die finanzielle Leistungsfähigkeit des Cloud-Anbieters im Datenschutzrecht gerade
keine absolute Grenze dar.
§ 9 BDSG steht dabei auch dem oben beschriebenen Modell der optionalen Sicherheit106
entgegen: Verarbeitet die verantwortliche Stelle sensible personenbezogene Daten, kann sie deren
Schutz nicht davon abhängig machen, ob der Cloud-Nutzer gewillt ist, Komforteinbußen oder
zusätzliche Kosten in Kauf zu nehmen. Die angemessenen Sicherheitsmaßnahmen müssen
verpflichtend sein. Dies gilt nach bisherigem Verständnis selbst dann, wenn lediglich
personenbezogene Daten des Cloud-Nutzers verarbeitet werden. Das BDSG kennt eine
Einwilligung in die Verarbeitung von Daten (§ 4a BDSG), eine Einwilligung in das Treffen
unzureichender technisch-organisatorischer Maßnahmen ist dagegen nicht vorgesehen.107 Würde
der Cloud-Nutzer, der selbst bewusst auf sichere Authentifizierungssysteme verzichtet hat, jedoch
entsprechende Schadensersatzansprüche (etwa § 7 BDSG, § 823 Abs. 2 BGB) geltend machen, so
läge in der Regel ein erhebliches Mitverschulden i.S.d. § 254 BGB bzw. ein Verstoß gegen Treu
und Glauben nach § 242 BGB vor.

2.2.1.4 Verhältnis zu allgemeinen Verkehrspflichten


Der dargestellte Verlauf der Ermittlung des bestehenden Schutzbedarfs und der Ergreifung
entsprechender Sicherheitsmaßnahmen weist große Parallelen zur Bestimmung des Umfangs
bestehender vertraglicher Schutzpflichten bzw. deliktischer Verkehrspflichten auf.108 Zwar ist der
Inhalt von Verkehrspflichten im Rahmen von § 823 Abs. 1 BGB grundsätzlich autonom zu
ermitteln.109 Jedoch wird angenommen, dass spezielle gesetzliche Verhaltenspflichten zugleich
eine deliktische Verkehrspflicht in Form eines Mindeststandards begründen.110
Dementsprechend werden die allgemeinen deliktischen Verkehrspflichten inhaltlich
maßgeblich durch § 9 BDSG geprägt, sofern der Anwendungsbereich des BDSG eröffnet ist.111 Es
ist daher in diesen Fällen bei der Prüfung des Umfangs bestehender Verkehrspflichten auf die
soeben zu § 9 BDSG entwickelten Grundsätze zu rekurrieren.

2.2.2 Pflichten des Cloud-Nutzers


Wie in Kap.​ 4 angedeutet, enthält § 11 Abs. 2 BDSG spezielle Verpflichtungen des Auftraggebers,
der sich eines externen Dienstleisters zur Durchführung des Identitätsmanagements bedient
(künftig: Art. 28 Abs. 1 DSGVO). Da die Datenverarbeitung ausgelagert wird, kann der
Auftraggeber insofern naturgemäß nur kontrollierend tätig werden. Die Pflicht zur Auswahl und
Kontrolle bezieht sich dabei auf die durch den Auftragnehmer zu treffenden technischen und
organisatorischen Maßnahmen: Der Cloud-Nutzer muss also sicherstellen, dass der Cloud-
Anbieter seinen soeben dargestellten Pflichten auch tatsächlich nachkommt (die DSGVO regelt
eine laufende Kontrollpflicht dagegen nicht explizit - wohl ohne dieses Kriterium suspendieren zu
wollen). Im Folgenden soll dargestellt werden, in welchem Umfang in diesem Rahmen Auswahl-
und Kontrollverpflichtungen bestehen und wie diesen rechtlichen Anforderungen in praktikabler
Art und Weise nachgekommen werden kann.
2.2.2.1 Pflicht zur sorgfältigen Auswahl
Gemäß § 11 Abs. 2 S. 1 BDSG ist der Auftraggeber zunächst verpflichtet, den mit der
Datenverarbeitung betrauten Auftragnehmer sorgfältig auszuwählen. Hierbei ist insbesondere
darauf zu achten, dass bei Einschaltung des jeweiligen Auftragnehmers mit hinreichender
Wahrscheinlichkeit davon ausgegangen werden kann, dass dieser die erforderlichen technischen
Sicherheitsvorkehrungen auch tatsächlich umsetzt.112

2.2.2.2 Pflicht zur Überwachung


Besonders problematisch gestaltet sich im Falle der Auftragsdatenverarbeitung in der Cloud das
zusätzliche Erfordernis aus § 11 Abs. 2 S. 4 BDSG: Der Auftraggeber muss den Auftragnehmer
nicht nur sorgfältig auswählen, sondern die Einhaltung des gebotenen Sicherheitsstandards auch
kontinuierlich überprüfen. Dies erscheint schwierig, da der Cloud-Anwender eine derartige
Kontrolle typischerweise fachlich und praktisch nicht ohne Weiteres selbst durchführen können
wird.113 Gleichwohl muss er seiner Verpflichtung gerecht werden.
2.2.2.3 Pflicht zur Dokumentation
Schließlich trifft den Auftraggeber gemäß § 11 Abs. 2 S. 5 BDSG die Verpflichtung, seine
Kontrolltätigkeit entsprechend zu dokumentieren. Dies wird im Regelfall die schriftliche
Fixierung der gefundenen Ergebnisse erfordern.114 Inhaltlich sollte grundsätzlich erfasst sein, was
auf welchem Wege überprüft worden und zu welchem Ergebnis dieses Verfahren gelangt ist.115
2.2.2.4 Praktische Umsetzung durch Zertifizierung
Wie bereits angedeutet, fällt dem Auftraggeber die Erfüllung dieser Pflichten typischerweise sehr
schwer. Denn er verfügt im Regelfall – sofern er überhaupt in zumutbarer Art und Weise Zutritt zu
den relevanten Räumlichkeiten erlangen kann – nicht über die erforderliche Fachkenntnis, um die
komplexe Sicherheitsstruktur des Auftragnehmers umfassend bewerten zu können.116 Die Erfüllung
seiner Verpflichtungen ist vom Auftraggeber diesbezüglich kaum zu erwarten.
Zur Auflösung dieser Problematik wird vorgeschlagen, dem Auftraggeber die Erfüllung seiner
Auswahl- und Kontrollpflichten durch die Einschaltung eines zertifizierten Auftragnehmers zu
gestatten.117 Die Kontrolle des Auftragnehmers erfolgt hierbei durch einen spezialisierten
Drittanbieter, der die Einhaltung des erforderlichen Schutzniveaus durch die Erteilung eines
Zertifikats bestätigt.118 In der Folge könnte der Auftraggeber den eigenen, für ihn im Regelfall
sonst unerfüllbaren Verpflichtungen Rechnung tragen, indem er die Vorlage eines sachgerechten
Zertifikats und dessen stetige Aktualisierung vom Auftragnehmer verlangt. So kann der
Auftraggeber seine Pflichten in pragmatischer und effizienter Weise erfüllen, und die dargestellten
praktischen Schwierigkeiten entfallen.

3 Branchenspezifische Anforderungen
3.1 Kreditwirtschaft
3.1.1 Grundsatz
Im Rahmen der Anforderungen an die Kreditwirtschaft ist zwischen verschiedenen
Fallgestaltungen zu unterscheiden. Wie in Kap.​ 4 erörtert, sind Kreditinstitute aufgrund von § 25b
Abs. 1 S. 1 KWG dazu verpflichtet, dafür Sorge zu tragen, dass die Auslagerung von Prozessen in
die Cloud die nach § 25a Abs. 1 KWG gebotene, ordnungsgemäße Geschäftsorganisation des
Instituts nicht beeinträchtigt. § 25b KWG ist anzuwenden, wenn das Kreditinstitut Aktivitäten und
Prozesse an ein externes Unternehmen auslagert. Sobald das Kreditinstitut dagegen eine
unternehmensinterne „Private Cloud“ betreibt, wie dies in der Praxis durchaus üblich ist, gelten
die zusätzlichen Anforderungen des § 25b KWG nicht.
Die Erfüllung der Pflichten nach § 25b KWG kann das Kreditinstitut sicherstellen, indem ein
angemessenes und wirksames Risikomanagement – unter fortgesetzter Berücksichtigung der
auszulagernden Prozesse – aufrechterhalten wird.119 Außerdem ist ein schriftlicher
Auslagerungsvertrag zu schließen, der insbesondere die genaue Spezifizierung der ausgelagerten
Tätigkeit und die Kontroll- und Weisungsbefugnisse des auslagernden Instituts festschreibt.120
Durch diese Maßnahmen wird der Auslagerungsprozess in die ordnungsgemäße
Geschäftsorganisation integriert.

3.1.2 Anforderungen an Authentifizierungsmechanismen


Weiterhin bestehen aufgrund der Sensibilität der verarbeiteten Daten, namentlich der Kontodaten
der Kunden, erhöhte Anforderungen an den Einsatz von Authentifizierungsmechanismen.
Untersucht worden sind entsprechende Pflichten vor allem im Hinblick auf das Online-Banking.
Die in diesem Rahmen gewonnenen Erkenntnisse können auch auf das Outsourcing sonstiger
Prozesse121 in die Cloud übertragen werden, soweit ebenso sensible Daten betroffen sind. Strenge
Anforderungen an die Authentifizierung von Cloud-Diensten sind auch bei einer internen Private
Cloud zu fordern. Auch hier bestehen erhebliche Missbrauchsrisiken.
Im Rahmen des Online-Banking ist anerkannt, dass die Banken verpflichtet sind, hinreichend
sichere Authentifizierungsverfahren einzusetzen.122 Diese Pflicht ergibt sich zunächst aus der
Pflicht zur Implementierung eines angemessenen und wirksamen Risikomanagements nach § 25a
Abs. 1 S. 3 KWG, welche durch die von der BaFin herausgegebenen Mindestanforderungen für
das Risikomanagement (MaRisk) weiter konkretisiert wird.123 Die Pflicht folgt weiterhin aus den
vertraglichen Vereinbarungen mit dem Kunden124 sowie aus § 675m BGB.125 Die speziellen
Anforderungen des Kreditwesens sind gegenüber den Anforderungen aus § 13 Abs. 7 TMG lex
specialis und somit vorrangig anzuwenden.126 Zudem gehen die Pflichten nach § 13 Abs. 7 TMG
nicht über die speziell an die Kreditwirtschaft adressierten Pflichten hinaus.127
Obwohl sich die Rechtsprechung bereits mehrfach mit der Thematik zu befassen hatte, besteht
allerdings auch im Bereich des Online-Banking noch keine abschließende Klarheit, welche
Authentifizierungsmaßnahmen geboten sind. Zentrale Bedeutung kommt insoweit einem Urteil des
KG zu, welches entschied, dass die Verwendung des PIN/TAN-Verfahrens im Jahr 2010 einen
Sorgfaltsverstoß des Kreditinstituts darstellte, der ein Mitverschulden bei Missbrauchsfällen,
etwa durch Phishing-Angriffe, begründete.128 Auch im Schrifttum hat sich diese Auffassung
durchgesetzt.129 In der Praxis findet das PIN/TAN Verfahren nunmehr kaum noch Anwendung.130
Soweit in der Literatur zu den erforderlichen Maßnahmen Stellung genommen wird, wird
teilweise auf die IT-Grundschutzkataloge des BSI131 als Richtlinien für die technische
Ausgestaltung verwiesen.132 Damit bestehen gewisse Parallelen zu den nach § 13 Abs. 7 TMG
gebotenen Schutzpflichten. Allerdings ist aufgrund des hohen Schutzbedürfnisses der verarbeiteten
Daten, wie auch im Datenschutzrecht, davon auszugehen, dass die gebotenen
Authentifizierungsmechanismen nicht anhand der wirtschaftlichen Leistungsfähigkeit des konkreten
Unternehmens ermittelt werden dürfen. Da bei Bankdaten ein besonders hohes Schadenspotenzial
und ein besonders hohes Missbrauchsrisiko gegeben sind, sind die Anforderungen entsprechend
hoch anzusetzen.

3.2 Sozialversicherungsträger
3.2.1 Grundsatz
§ 78a SGB X enthält, wie im vierten Kapitel133 aufgezeigt, eine speziell normierte Verpflichtung
des Auftragsdatenverarbeiters zur Gewährleistung hinreichender Datensicherheit. Der wesentliche
Unterschied zur entsprechenden allgemeinen datenschutzrechtlichen Verpflichtung134 liegt in der
negativen Formulierung des § 78a S. 2 SGB X, wonach Maßnahmen nur dann nicht erforderlich
sind, wenn der Aufwand außer Verhältnis zum angestrebten Schutzzweck steht. § 9 S. 2 BDSG
normiert dagegen positiv, wann Maßnahmen erforderlich sein sollen.
Hierin wird zum Teil lediglich eine Umkehr der Beweislast gesehen, sodass der
Datenverarbeiter sich dahingehend exkulpieren müsste, dass eine konkrete Maßnahme im
Einzelfall gerade nicht als erforderlich angesehen werden musste.135 Sehr weitgehend erscheint
die hiervon abweichende Interpretation, dass aufgrund des Wortlauts die Unangemessenheit einer
„in Frage kommenden“ Maßnahme die Ausnahme darstellen müsse.136 Denn der Katalog
potenzieller Schutzmaßnahmen ist uferlos, sodass es wenig sinnvoll erscheint, pauschal die
Angemessenheit aller denkbaren Maßnahmen vorauszusetzen. Allerdings wird man der
Gesetzesformulierung in der Tat die Absicht einer gewissen Verschärfung des Schutzstandards
nicht absprechen können, die wohl der besonderen Sensibilität der betroffenen Datensätze
geschuldet ist.
Dementsprechend ist in Zweifelsfällen in der Abwägung dem besonders gewichtigen
Schutzzweck der Vorrang einzuräumen und somit die strengere von zwei eng beieinander
liegenden potenziellen Sicherungsmaßnahmen noch als erforderlich einzustufen. Ob sich daraus
für die Praxis Unterschiede ergeben ist fraglich, da im Kontext der Sozialdaten ohnehin besonders
sensible Daten verarbeitet werden und regelmäßig auch ein hohes Missbrauchsrisiko bestehen
dürfte.

3.2.2 Anforderungen an Authentifizierungssysteme


In Bezug auf Sozialversicherungsträger wird vertreten, dass eine Authentifizierung mittels
Nutzername/Passwort bzw. Softzertifikaten aufgrund der hohen Sensibilität unzulässig ist.137 Dem
ist zuzustimmen. Die hohe Bedeutung der verarbeiteten Daten führt dazu, dass strenge
Anforderungen an die einzusetzenden Authentifizierungsverfahren zu stellen sind.

3.3 Berufsgeheimnisträger
3.3.1 Grundsatz
Nach der bisherigen herrschenden Auffassung hinsichtlich der Auslegung der
Tatbestandsmerkmale des § 203 StGB machten sich Berufsgeheimnisträger in den meisten
Fallkonstellationen strafbar, wenn sie ihren Datenbestand in die Cloud auslagerten.138
Möglich war allenfalls eine Entbindung von der Geheimhaltungspflicht durch alle Betroffenen,
um der Strafbarkeit zu entgehen.139 Dies erschien indes im Praxiseinsatz kaum umsetzbar. Durch
die gesetzliche Neuregelung140 ist die Auslagerung in die Cloud daher grundsätzlich nicht mehr
strafbar. Allerdings muss eine solche Auslagerung jeweils „erforderlich“ sein, sodass zumindest
ein strafrechtliches Restrisiko verbleibt. Die Erforderlichkeit der Auslagerung könnte etwa dann
entfallen, wenn eine Cloud technisch so implementiert ist, dass die Geheimnisse an mehr Personen
als notwendig offenbart werden. Der Gesetzgeber nennt dazu das Beispiel einer unverschlüsselten
externen Speicherung von Daten,141 wie sie auch in einer Cloud erfolgen könnte.

3.3.2 Anforderungen an Authentifizierungssysteme


Geht man von der Zulässigkeit des Outsourcings aus, so ergeben sich im Bereich der
Berufsgeheimnisträger keine wesentlichen Besonderheiten. Da in aller Regel sehr sensible Daten
verarbeitet werden, müssen Berufsgeheimnisträger besonders sichere Authentifizierungsverfahren
einsetzen. Hier ist nach Berufsgruppe und Art der Daten zu differenzieren. Im Einzelfall ist
durchaus denkbar, dass Daten höchster Schutzbedürftigkeit verarbeitet werden, was den Einsatz
eines Hardware OTP Tokens142 erforderlich machen würde.

4 Besondere Anforderungen an Verwaltung und Justiz


4.1 Anforderungen an E-Government
Bei der Digitalisierung von Verwaltungsprozessen stellen sich insbesondere datenschutzrechtliche
Herausforderungen, da zwangsläufig besonders umfassende, zentrale Datenbestände generiert
werden müssen, die noch dazu u. U. die Bildung von Persönlichkeitsprofilen erlauben.143
Unzureichender Datenschutz stellt einen wesentlichen Hemmfaktor für das Bürgervertrauen in E-
Government dar.144 Dementsprechend ist großes Gewicht darauf zu legen, dem erhöhten
Risikopotenzial durch eine korrespondierende Anhebung des IT-Sicherheitsniveaus zu begegnen.
Außerdem muss den im Rahmen von Kap.​ 4 umfassend dargestellten allgemeinen und ggf.
speziellen Geheimniswahrungspflichten Rechnung getragen werden, die in digitale
Verwaltungsprozesse hineinwirken. So müssen Geheimnis- und Datenschutz etwa bei der im
Rahmen von E-Government eingeführten elektronischen Aktenführung risikobezogen
berücksichtigt werden.145 Die besagten Geheimhaltungspflichten können hierbei insbesondere
dazu führen, dass die elektronische Akteneinsicht versagt werden muss.146 In Bezug auf
Authentifizierungssysteme ergeben sich keine Unterschiede im Vergleich zu den
datenschutzrechtlichen Anforderungen.147

4.2 Anforderungen an E-Justice


Die umfangreichen Geheimhaltungspflichten im Rahmen des E-Justice wurden in Kap.​ 4
beschrieben. Der Einsatz von digitalen Inhalten auf dem Gebiet der E-Justice birgt besondere
Risiken für den Datenschutz.148 Zum Teil wird sogar davon ausgegangen, dass die Maßstäbe für
das erforderliche IT-Sicherheitsniveau im Rahmen von E-Justice noch höher liegen als im E-
Government, da in hohem Maß besonders sensible Daten betroffen sind und andernfalls das
Vertrauen der Bevölkerung in das rechtsstaatliche Verfahren beeinträchtigt werden könnte.149
Auch für die richterliche Unabhängigkeit birgt E-Justice zusätzliche Risiken, soweit konkrete
Vorgaben für die Durchführung fachlicher Verfahren vorgesehen sind.150
Dementsprechend ist auch in diesem Rahmen dem erhöhten Schutzbedarf durch eine
entsprechende Intensivierung der Sicherheitsmaßnahmen Rechnung zu tragen. Um dies umsetzen zu
können, wird teils sogar die Einrichtung eines eigenständigen „Justiz-Netzes“ für unabdingbar
gehalten, das externen Stellen den Zugriff auf die Datensätze gänzlich versagt.151 Auch der
ständigen Verfügbarkeit der relevanten Datensätze soll besonderes Gewicht beigemessen
werden.152 Unabhängig davon, ob die Einbindung von Cloud-Lösungen künftig für zulässig
erachtet werden sollte, wären jedenfalls besonders hohe Anforderungen an die
Authentifizierungssysteme zu stellen. Insoweit könnte nichts anderes gelten als im
Bankensektor.153 Je nach Verfahrensgegenstand sind auch höhere Anforderungen denkbar, etwa
wenn lebensgefährdende Informationen im Rahmen eines Strafverfahrens enthalten sind. Pauschale
Aussagen zum erforderlichen Sicherheitsniveau sind insofern kaum möglich.

5 Rechtliche Bewertung der optimalen Sicherheitsmaßnahmen nach


Kap.​ 5
In Kap.​ 5 wurde für verschiedene Szenarien unter Kosten-Nutzen-Gesichtspunkten ermittelt,
welche Authentifizierungssysteme optimalerweise eingesetzt werden sollten. Die Untersuchung
wurde in Abhängigkeit verschiedener Budgetvorgaben (BV), welche die Bereitschaft des
Unternehmens und seiner Kunden, in IT-Sicherheit zu investieren, widerspiegeln, vorgenommen.
Die vier BV wurden oben154 erläutert. Dieser Abschnitt ist der Frage gewidmet, ob diese den
soeben erarbeiteten, konkretisierten rechtlichen Anforderungen genügen.
Zunächst soll dabei die Fallgruppe des Betriebs einer Cloud durch ein mittelständisches
Unternehmen in den Blick genommen werden. Da hier keine besonderen branchenspezifischen
Anforderungen bestehen, bildet das mittelständische Unternehmen einen geeigneten Ausgangspunkt
für die Untersuchung. Die Anforderungen an die Implementierung von Authentifizierungssystemen
im Bereich der Kreditwirtschaft, der Sozialleistungsträger und der Berufsgeheimnisträger werden
aufgrund der insoweit zu beachtenden branchenspezifischen Anforderungen separat dargestellt.155
Dagegen folgt keine separate Darstellung der in Kap.​ 5 ebenfalls untersuchten Gruppe des
Betriebs einer Cloud-Lösung durch Verbraucher.156 Aus rechtlicher Sicht ist es, in Bezug auf die
gebotenen Sicherheitsmaßnahmen im Identitätsmanagement, unerheblich, ob ein Verbraucher oder
ein mittelständisches Unternehmen einen Cloud-Dienst anbietet. In beiden Fällen kommt es
entscheidend auf die finanzielle Zumutbarkeit der Maßnahmen sowie die Missbrauchsgefahr an.
Die in diesem Abschnitt gefundenen Ergebnisse gelten daher für Verbraucher gleichermaßen. In
der Praxis dürfte ein Verbraucher ohnehin nur äußerst selten als Cloud-Anbieter auftreten.

5.1 Mittelständische Unternehmen


Im Fall der mittelständischen Unternehmen ist bei BV 1 eine Authentifizierung mittels Hardware
OTP Token optimal, bei BV 2 und 4 eine Authentifizierung mittels Software OTP Token und bei
BV 3 eine Authentifizierung mittels E-Mail TAN.157 Bei der Untersuchung, ob diese
Sicherheitsmaßnahmen ausreichend sind, ist nach dem Schutzbedürfnis158 im Einzelfall zu
differenzieren. Die größten Bedrohungen für das Identitätsmanagement mittelständischer
Unternehmen stellen Brute-Force-Angriffe, Keylogger, Phishing und, bei Nutzung von E-Mail
TAN, die Übernahme von E-Mail-Konten dar.159

5.1.1 Anforderungen bei geringem Schutzbedarf


Zunächst ist zu klären, welche Anforderungen bei geringem Schutzbedarf bestehen. Das BSI hält,
wie oben gezeigt,160 eine Zwei-Faktor-Authentifizierung nur bei hohem bis sehr hohem
Schutzbedarf für erforderlich. Bei geringem Schutzbedarf scheint der Verzicht auf eine Zwei-
Faktor-Authentifizierung auch angemessen: Sofern die Daten keinen hohen Schutzbedarf haben,
sind sie für professionelle Angreifer weitgehend uninteressant, sodass ein Passwortschutz trotz
seiner zahlreichen Schwachstellen eine ausreichende Sicherheit gewährleistet. Die Pflicht zur
Implementierung aufwendigerer Verfahren wäre aufgrund des geringen Angriffsrisikos und des
geringen Schadenspotenzials unverhältnismäßig. Dies gilt unabhängig von der BV des
Unternehmens. Somit sind bei geringem Schutzbedarf alle in Kap.​ 5 als optimal gekennzeichneten
Maßnahmen ausreichend, da sie alle einen höheren Schutz bieten, als die insoweit ausreichende
Identifizierung mittels Nutzername/Passwort. Abweichungen zwischen den Anforderungen aus
Vertrag, Delikt, TMG und BDSG ergeben sich insoweit nicht.

5.1.2 Anforderungen bei hohem und sehr hohem Schutzbedarf


Bei hohem Schutzbedarf der Daten ist entsprechend der Stellungnahme des BSI eine Zwei-Faktor-
Authentifizierung zu verwenden.161 Ungeklärt ist bislang, ob hier auf ein bestimmtes Verfahren
zurückgegriffen werden muss, oder ob etwa auch Zwei-Faktor-Authentifizierungen mit
verhältnismäßig geringer Sicherheit, wie E-Mail TAN, ausreichend wären. Der Einsatz von E-
Mail TAN ist nach der Untersuchung in Kap.​ 5 in BV 3, also bei eher geringem
Unternehmensbudget, das optimale Authentifizierungsverfahren. Insoweit ist anzumerken, dass bei
etwa 60 % höheren Kosten der Einsatz von Software OTP Token die Sicherheit erheblich erhöhen
würde.162 Aufgrund der geringen Implementierungskosten eines E-Mail TAN-Systems wären die
Sicherheitskosten dann immer noch vergleichsweise gering.
Insoweit wird das Kriterium der wirtschaftlichen Zumutbarkeit des § 13 Abs. 7 TMG
besonders relevant. Geht man entsprechend des hier vertretenen Verständnisses163 davon aus, dass
die wirtschaftliche Zumutbarkeit die wirtschaftliche Leistungsfähigkeit eines einzelnen
Unternehmens im Blick hat, wird man Kleinstunternehmen gestatten müssen, auf das eher
unsichere E-Mail TAN-System zurückzugreifen. Im Einzelfall werden die Kosten für den Einsatz
von Software OTP Token hier nicht zumutbar sein. Der Einsatz eines reinen
Nutzername/Passwort-Systems ist dagegen bei hohem und sehr hohem Schutzbedarf selbst für
kleine Unternehmen unzulässig.
Wie oben dargestellt,164 kennt § 9 BDSG keine an die wirtschaftliche Leistungsfähigkeit des
einzelnen Unternehmens anknüpfende absolute Grenze. Wird der Cloud-Dienst durch unsichere
Authentifizierungsverfahren für Angreifer attraktiv, bzw. kam es sogar bereits zu Angriffen, kann
ein Kleinstunternehmer sich nicht darauf berufen, dass der Einsatz eines sichereren Verfahrens
ihm wirtschaftlich nicht zumutbar sei. Insoweit stellt das Gesetz den Schutz des informationellen
Selbstbestimmungsrechts der Betroffenen über die Interessen kleiner Unternehmen. Aufgrund der
im Vergleich zu Software OTP Token geringen Sicherheit ist daher der Einsatz von
Nutzername/Passwort sowie E-Mail TAN bei hohem Schutzbedarf der Daten unzulässig. Das
Missbrauchsrisiko ist insoweit zu hoch.
Bei sehr hohem Schutzbedarf, also insbesondere Daten, deren Bekanntgabe den Betroffenen an
Leib und Leben gefährden würde, ist der Einsatz der sichersten marktüblichen
Authentifizierungssysteme zu fordern. Hier muss der Cloud-Anbieter somit die Identifizierung
mittels Hardware OTP Token ermöglichen.

5.1.3 Anforderungen bei durchschnittlichem Schutzbedarf


Am schwierigsten ist die Frage nach zulässigen Authentifizierungsmechanismen zu beantworten,
wenn der Schutzbedarf weder außergewöhnlich hoch noch außergewöhnlich gering ist. Hier
kommt es in besonderem Maß auf die Gegebenheiten des Einzelfalls an, sodass sich pauschale
Aussagen kaum treffen lassen. Nach § 13 Abs. 7 TMG ist insoweit erneut die wirtschaftliche
Zumutbarkeit für das konkrete Unternehmen entscheidend: Gerade Anbietern mit höherem Budget
ist es im Regelfall zumutbar, trotz der hohen Kosten zumindest das Angebot einer Zwei-Faktor-
Authentifizierung zu implementieren, wenn Angriffe auf ihre Systeme nicht abwegig erscheinen.
Der ausschließliche Einsatz von Zwei-Faktor-Authentifizierungen wird dagegen im Regelfall nicht
geboten sein. Hier ist insbesondere auch die auf potenzielle Kunden abschreckende Wirkung zu
beachten. Werden die Sicherheitsmaßstäbe zu hoch angesetzt, so kann dies eine erdrosselnde
Wirkung für die Unternehmen zur Folge haben. Mittelständler und Kleinstunternehmen können
dagegen grundsätzlich Nutzername und Passwort einsetzen. Insoweit bestehen daher keine
Bedenken gegen den Einsatz der nach Kap.​ 5 optimalen Authentifizierungsmechanismen.

5.2 Kreditwirtschaft
Nunmehr ist für das Kreditwesen zu beurteilen, ob der Einsatz der in Kap.​ 5 als optimal
angesehenen Authentifizierungsverfahren rechtlich zulässig ist. Realisierbar wären je nach BV der
Einsatz eines Hardware Tokens bzw. des neuen Personalausweises; ein Software OTP Token
sowie E-Mail TAN bei geringem Budget.165 Sowohl der Einsatz von Software OTP Token als
auch E-Mail TAN stoßen insoweit auf Bedenken: Aufgrund der extrem hohen Missbrauchsgefahr
erscheint der Einsatz eines Hardware OTP Tokens bzw. eines Authentifizierungsverfahrens mit
gleichartiger Sicherheit zwingend geboten. Bei weniger sicheren Verfahren steht zu befürchten,
dass Missbräuche nicht auf Ausnahmefälle reduziert werden können. Dem Unternehmen ist es
insoweit verwehrt, sich auf fehlende finanzielle Ausstattung zu berufen.

5.3 Sozialversicherungsträger
Nach Kap.​ 5 166 sind je nach BV Hardware bzw. Software OTP Token zulässig. Eine Abweichung
findet sich nur in BV 3, wo auf den Einsatz von E-Mail TAN verwiesen wird. Insoweit ist, wie im
Falle des Kreditwesens, von den untersuchten Verfahren nur der Einsatz des Hardware OTP
Tokens zulässig. Die anderen Systeme bieten keine dem Schutzbedarf der Daten angemessene
Sicherheit.

5.4 Berufsgeheimnisträger
Aufgrund der Vielzahl der denkbaren Fallgestaltungen ist es kaum möglich, die in Kap.​ 5
gefundenen Ergebnisse167 rechtlich zu bewerten. Jedenfalls unzulässig ist der in BV 3 empfohlene
Einsatz von PIN. Gegen den in den anderen BV als optimal gekennzeichneten Einsatz von
Hardware und Software OTP Tokens bestehen dagegen keine grundlegenden Bedenken. Je nach
Art der verarbeiteten Daten wird der Einsatz eines Software OTP Tokens jedoch unzulässig sein.

6 Weitere rechtliche Implikationen des Identitätsmanagements im


Überblick
Zwei weitere Faktoren, die zumindest mittelbar auf das Identitätsmanagement im Cloud Computing
ausstrahlen können, sind die Rechtsscheinhaftung und das Beweisrecht. Die Rechtsscheinhaftung
entscheidet darüber, ob der Nutzer durch Erklärungen Dritter unter seinem Namen berechtigt und
verpflichtet wird, während sich im Rahmen des Beweisrechts die Frage stellt, welche Faktoren
bekannt sein müssen, um im Prozess nachweisen zu können, dass ein bestimmter Nutzer tatsächlich
eine Erklärung abgegeben hat.

6.1 Rechtsscheinhaftung
6.1.1 Ausgangspunkt
Gibt ein Unbefugter auf einer Cloud-Plattform unter fremdem Namen rechtserhebliche Erklärungen
ab, so stellt sich die Frage, ob der tatsächliche Namensinhaber durch diese Erklärungen berechtigt
und verpflichtet wird. Denkbar wäre etwa, dass der Berechtigte seine Authentifizierungsmedien,
etwa ein Passwort, unsorgfältig verwahrt und so einem Dritten ermöglicht, auf seinen Account
zuzugreifen. Dieser könnte dann etwa über den Account des Berechtigten Verträge abschließen.
Wer im Rechtsverkehr den Anschein erweckt, dass ein Unbefugter als sein berechtigter
Stellvertreter auftritt, wird unter bestimmten Voraussetzungen so behandelt, als hätte er dem
vermeintlichen Vertreter tatsächlich eine Vollmacht erteilt (Rechtsscheinvollmacht).168 Diese
Wertung wird auch auf den Fall ausgedehnt, dass ein Unberechtigter sich als Namensinhaber
ausgibt, also unter fremdem Namen handelt.169 Auch in dieser Konstellation ist denkbar, dass der
„Vertretene“ einen Rechtsschein gesetzt hat und die von dem Unberechtigten getätigten
rechtserheblichen Erklärungen für und gegen sich gelten lassen muss.

6.1.2 Voraussetzungen
Gemeinhin wird zwischen zwei Arten der Rechtsscheinvollmacht, der Duldungs- und der
Anscheinsvollmacht, differenziert.170 Eine Duldungsvollmacht ist gegeben, „wenn der Vertretene
es willentlich geschehen lässt, dass ein anderer für ihn wie ein Vertreter auftritt, und der
Geschäftspartner dieses Dulden nach Treu und Glauben dahin versteht und auch verstehen darf,
dass der als Vertreter Handelnde zu den vorgenommenen Erklärungen bevollmächtigt ist.“171 Die
Duldungsvollmacht setzt also Kenntnis des Namensinhabers vom Handeln des Unbefugten voraus.
In Fällen des Identitätsmissbrauchs, in denen eine solche Kenntnis regelmäßig nicht gegeben oder
jedenfalls nicht nachzuweisen ist, kommt der Duldungsvollmacht damit nur untergeordnete
Bedeutung zu.172
Eine Anscheinsvollmacht wird dagegen bereits angenommen, „wenn der Vertretene das
Handeln des Scheinvertreters nicht kennt, er es aber bei pflichtgemäßer Sorgfalt hätte erkennen
und verhindern können, und wenn der Geschäftspartner annehmen durfte, der Vertretene kenne und
billige das Handeln des Vertreters.“173 Es muss also ein Rechtsscheintatbestand vorliegen, der
dem tatsächlichen Namensinhaber zurechenbar ist.174 Da die Anscheinsvollmacht somit keine
Kenntnis, sondern lediglich einen Sorgfaltsverstoß voraussetzt, ist sie im Rahmen des
Identitätsmissbrauchs von höherer praktischer Relevanz.
6.1.2.1 Rechtsscheintatbestand
Ein Rechtsscheintatbestand ist dann gegeben, wenn der Erklärungsgegner gutgläubig auf einen
Vertrauenstatbestand vertraut hat und dies kausal für eine Disposition des Erklärungsgegners
war.175 Ein solcher Vertrauenstatbestand kann insbesondere in der Nutzung von
Authentisierungsmedien liegen.176
Insbesondere die Rechtsprechung macht das Vorliegen des Rechtsscheintatbestands häufig
davon abhängig, ob ein „starkes“ Authentisierungsmedium verwendet wird. So wurde eine
Rechtsscheinhaftung bei einer Authentisierung mittels Nutzername/Passwort abgelehnt,177 beim
smartTANplus-Verfahren178 dagegen bejaht. Da im Falle der Nutzung von Nutzername/Passwort
angesichts der vielfachen Missbrauchsmöglichkeiten nicht zuverlässig zu sagen sei, dass es sich
bei dem Handelnden um den tatsächlichen Inhaber eines Kontos handele, komme eine
Rechtsscheinhaftung insoweit nur dann in Betracht, wenn der Missbrauch von einer gewissen
Dauer und Häufigkeit sei.179
Häufig wird eine Rechtsscheinhaftung im Falle der Authentisierung mittels
Nutzername/Passwort jedoch bejaht, wenn der Nutzer das Passwort bewusst weitergegeben hat.180
Diese Ansicht setzt voraus, dass trotz unsicherer Authentifizierungssysteme ein
Rechtsscheintatbestand gegeben ist. So wird denn auch in der Literatur ausdrücklich vertreten,
dass die Stärke des Authentifizierungssystems für das Vorliegen des Rechtsscheintatbestands nicht
entscheidend ist.181 Dies wird überzeugend mit der Anreizstruktur der Rechtsscheinhaftung
begründet: Eine potenziell denkbare Anscheinsvollmacht setzt für den Nutzer einen Anreiz
dahingehend, die Weitergabe von Passwörtern zu unterlassen.182 Somit besteht in der Nutzung von
Authentifizierungsverfahren ein Rechtsscheintatbestand, unabhängig davon, ob ein Verfahren
genutzt wird, welches gegen Missbräuche zuverlässig gesichert ist.
6.1.2.2 Zurechenbarkeit
Ähnlich wie bei der Bestimmung des Pflichtenkreises im Rahmen des Vertrags- und Deliktsrechts
wird die Zurechenbarkeit des Rechtsscheins zum Namensinhaber am Maßstab der Zumutbarkeit
beurteilt. Ein Rechtsschein ist dem Namensinhaber zurechenbar, wenn es diesem zumutbar war,
das Auftreten unter seinem Namen zu verhindern.183 Dies wird in Rechtsprechung und Literatur
jedenfalls für den Fall bejaht, dass der „Vertretene“ Authentisierungsmedien bewusst
weitergegeben hat.184 Dagegen stellt nach der Rechtsprechung des BGH eine unsorgfältige
Verwahrung der Authentisierungsmedien, anders als im Deliktsrecht, keinen ausreichenden
Sorgfaltsverstoß dar.185 Der BGH begründet dies mit der spezifischen Risikoverteilung im
Vertragsrecht. Das Risiko einer fehlenden Vertretungsmacht trage grundsätzlich der
Geschäftsgegner und nicht der Geschäftsherr.186 An die Zumutbarkeit im Rahmen der
Rechtsscheinhaftung sind somit strengere Maßstäbe zu stellen als an die Zumutbarkeit im Rahmen
der Verkehrspflichten. Im Online-Banking wurde die Rechtsscheinhaftung auch dann bejaht, wenn
der Kunde die auf dem Display eines TAN-Generators angezeigten, transaktionsbezogenen
Überweisungsdaten nicht überprüft und so eine Manipulation übersieht.187 Außerhalb des Online-
Banking dürfte dieser Fallgruppe eher geringe Bedeutung zukommen. Im Ergebnis ist die
Zurechenbarkeit letztlich dann zu bejahen, wenn der Geschäftsherr bewusst das Risiko des
Missbrauchs eingeht bzw. sich vor der Erkenntnis des Risikos verschließt.188
Außerhalb von transaktionsbasierten Authentifizierungssystemen ist dies hauptsächlich
denkbar, wenn der Namensinhaber seine Authentifizierungsmedien Dritten zur Verfügung stellt.
Eine Rechtsscheinhaftung des Kontoinhabers kommt damit nur in Ausnahmefällen in Betracht. Für
das Identitätsmanagement im Cloud Computing kommt ihr damit nur eine untergeordnete
Bedeutung zu.

6.2 Beweisrecht
6.2.1 Ausgangssituation
In beweisrechtlicher Hinsicht stellt sich, wie im Rahmen des vierten Kapitels aufgezeigt,189
insbesondere die Frage, unter welchen Voraussetzungen die Verwendung eines nutzerbezogenen
Authentifizierungsmediums einen Anscheinsbeweis dahingehend zu begründen vermag, dass auch
tatsächlich der dahinterstehende Nutzer die Handlung vorgenommen bzw. zumindest ermöglicht
hat. Eine dahingehende Beweiserleichterung würde die Durchsetzung von etwaigen
Ersatzansprüchen für den Plattformbetreiber erheblich erleichtern. Wie dargelegt, setzt ein
Anscheinsbeweis das Bestehen eines Erfahrungssatzes dahingehend voraus, dass eine Erklärung,
die über eine Cloud-Plattform unter Einsatz eines Authentifizierungssystems abgegeben wurde,
nach der Lebenserfahrung vom Inhaber des Authentisierungsinstruments stammt.190

6.2.2 Anscheinsbeweis im Bankrecht


Ausgangspunkt der hiesigen Betrachtung soll ein grundsätzlich durchaus vergleichbarer
Anwendungsfall sein, in dem die Rechtsprechung das Eingreifen eines Anscheinsbeweises bereits
anerkannt hat: Wird eine EC-Karte im Original unter Verwendung der korrekten PIN eingesetzt, so
spricht grundsätzlich ein Beweis des ersten Anscheins dafür, dass auch tatsächlich der berechtigte
Karteninhaber die Transaktion initiiert oder zumindest durch vorangehendes Fehlverhalten
ermöglicht hat.191 Denn anders lässt sich das ordnungsgemäße Durchlaufen des Abhebevorgangs
zunächst nicht erklären. Es obliegt sodann dem Karteninhaber, darzulegen, dass im jeweiligen
Einzelfall ein atypischer Geschehensablauf vorlag, sodass insoweit ausnahmsweise doch nicht
vom ordnungsgemäßen Ablauf des Abhebungsvorgangs ausgegangen werden kann.192

6.2.3 Anwendung auf Cloud-Plattformen


Wie oben angedeutet, werden im Rahmen vieler Cloud-Anwendungen lediglich eine
Nutzerkennung und ein dazugehöriges Passwort vergeben, die dem Anwender fortan erlauben, sich
einzuloggen und den Dienst zu nutzen. Im Falle einer Authentifizierung mittels
Nutzername/Passwort wird das Eingreifen eines Anscheinsbeweises zugunsten einer berechtigten
Nutzung indes überwiegend abgelehnt.193 Gleiches gilt auch für die Nutzung des iTAN-
Verfahrens.194 Die Annahme eines Anscheinsbeweises für die Abgabe einer Erklärung setzt
voraus, dass solche Missbrauchsmöglichkeiten ausgeschlossen werden können, die bekannt sind
und im Einzelfall realistisch erscheinen.195 Je wahrscheinlicher ein Identitätsmissbrauch aufgrund
von Angriffsmöglichkeiten gegen das eingesetzte Authentifizierungsverfahren ist, desto weniger
kann von einem Erfahrungssatz ausgegangen werden, welcher einen Anscheinsbeweis zu
begründen vermag.196 Die Angriffsvarianten, die auf die unbefugte Kenntniserlangung von einem
Passwort gerichtet sind, sind vielfältig und entwickeln sich ständig fort. Selbst bei äußerst
sorgsamer Vorgehensweise des Anwenders ist nicht ausgeschlossen, dass etwa durch Datenlecks
bei großen Anbietern Informationen an Dritte gelangt sind. Daher besteht kein allgemeingültiger
Erfahrungssatz, dass derjenige, der unter einem lediglich passwortgeschützten Nutzerkonto
eingeloggt ist, auch tatsächlich der Inhaber dieses Kontos ist.
Dagegen wird, v. a. im Kontext des Online-Banking, bei verbesserten transaktionsbasierten
Authentisierungsmedien ein Anscheinsbeweis der Urheberschaft der Erklärung des Kunden
angenommen.197 Dieser Anscheinsbeweis ist dreifach alternativ198: Eine Autorisierung des
Zahlungsvorgangs begründet den Anschein, der Kunde habe diese selbst vorgenommen, seine
persönlichen Sicherheitsmerkmale bewusst weitergegeben oder durch unsorgfältige Kontrolle zum
Missbrauch beigetragen.199 Da im Cloud Computing im Regelfall keine Kontrolle von
Transaktionsdaten vorgenommen wird, kommt hier ein Anscheinsbeweis dahingehend in Betracht,
dass der Nutzer selbst Urheber der Erklärung ist oder seine Authentifizierungsmedien
weitergegeben hat. Soweit keine besonderen Umstände vorliegen, ist ein solcher
Anscheinsbeweis bei der Nutzung einer Zwei-Faktor-Authentifizierung zu bejahen. Dies gilt nicht
für den Fall der E-Mail TAN, da deren Sicherheit mit der Sicherheit des E-Mail-Kontos des
Nutzers verknüpft ist, welches in der Regel lediglich über ein Passwort geschützt ist.
Liegt ein Erfahrungssatz vor, der einen Anscheinsbeweis begründet, kann dieser erschüttert
werden, wenn die ernsthafte Möglichkeit eines anderen Geschehensablaufs besteht.200 Dies ist
vom Anspruchsgegner darzulegen und zu beweisen.201 Eine Erschütterung kommt insbesondere in
Betracht, wenn der Kunde einräumt, nicht sorgfältig mit den Authentisierungsmedien umgegangen
zu sein, etwa indem er diese an einen Dritten weitergegeben hat.202 Freilich kommen dann
Schadensersatzansprüche203 sowie eine Rechtsscheinhaftung in Betracht.

7 Fazit
Die Ermittlung der rechtlichen Anforderungen an das Identitätsmanagement in der Cloud gestaltet
sich aufgrund der Vielzahl der denkbaren Fallkonstellationen äußerst diffizil. Insbesondere zur
Zulässigkeit des Einsatzes bestimmter Authentifizierungsverfahren finden sich bisher nur wenige
Stellungnahmen in Rechtsprechung und Literatur. Es ist davon auszugehen, dass sich dies in naher
Zukunft, nicht zuletzt durch die Einführung des § 13 Abs. 7 TMG durch das IT-Sicherheitsgesetz,
ändern wird.
Als Ergebnis der Untersuchung hat sich gezeigt, dass branchenspezifische Anforderungen
jedenfalls in den hier untersuchten Bereichen wenig Mehrwert bringen, da sie keine spezifischeren
Schutzpflichten enthalten als die allgemeinen Gesetze. Erstrebenswert erscheint insoweit die
Etablierung einheitlicher Schutzstandards, die nicht nach Branchen, sondern nach Sensibilität der
Daten und Missbrauchsrisiko differenzieren. § 9 BDSG und § 13 Abs. 7 TMG stellen einen ersten
Schritt in diese Richtung dar, haben jedoch keinen lückenlosen Anwendungsbereich.
Abseits dieser Fragestellung hat sich gezeigt, dass die Implementierung von aus rechtlicher
Sicht gebotenen Authentifizierungsverfahren die Anbieter in der Regel vor keine unzumutbaren
Kosten stellt. Schwierig ist die Situation zum einen für Kleinstunternehmer und zum anderen für
Unternehmen, die sich vorrangig an Verbraucher mit geringer Toleranz für eingeschränkte
Nutzbarkeit richten. Um den Komfort für die Nutzer möglichst wenig einzuschränken, empfiehlt
sich ein ausgeklügeltes Zugriffsmanagement, um sicherzustellen, dass diese nicht auf sensible
Kundendaten zugreifen können, sofern sie sich nur mittels Nutzername/Passwort anmelden.

Literatur
Bamberger, Heinz Georg/Roth, Herbert: Beck’scher Online-Kommentar BGB, 41. Edition, Stand: 01.11.2016, München 2016.

Baumbach, Adolf/Lauterbach, Wolfgang/Albers, Jan/Hartmann, Peter: Zivilprozessordnung, 74. Aufl., München 2016.

Biallaß, Isabelle Désirée: Anmerkung zu OLG Hamm, Urteil vom 16. November 2006 – 28 U 84/06, ZUM 2007, 397–399.

Boos, Karl-Heinz/Fischer, Reinfrid/Schulte-Mattler, Hermann: Kreditwesengesetz, 5. Aufl., München 2016.

Borges, Georg/Meents, Jan Geert: Cloud Computing. Rechtshandbuch, München 2016.

Borges, Georg/Schwenk, Jörg/Stuckenberg, Carl-Friedrich/Wegener Christoph: Identitätsdiebstahl und Identitätsmissbrauch im


Internet. Rechtliche und technische Aspekte, Berlin 2011.

Borges, Georg: Cloud Computing und Datenschutz. Zertifizierung als Ausweg aus einem Dilemma, DuD 2012, 165–169.

Borges, Georg: Der neue Personalausweis und der elektronische Identitätsnachweis, NJW 2010, 3334–3339.

Borges, Georg: Haftung für Identitätsmissbrauch im Online-Banking, NJW 2012, 2385–2389.

Borges, Georg: Rechtliche Aspekte der Internetportale für Heilberufe. Zugang, Beweis, Datensicherung, Baden-Baden 2007.

Borges, Georg: Rechtsfragen der Haftung im Zusammenhang mit dem elektronischen Identitätsnachweis, Baden-Baden 2011.

Borges, Georg: Rechtsfragen der Internet-Auktion, 2. Aufl., Baden-Baden 2014.

Borges, Georg: Rechtsfragen des Phishing – Ein Überblick, NJW 2005, 3313–3117.

Borges, Georg: Rechtsscheinhaftung im Internet, NJW 2011, 2400–2403.

Brennscheidt, Kirstin: Cloud Computing und Datenschutz, Baden-Baden 2013.

BSI, Eckpunktepapier Sicherheitsempfehlungen für Cloud Computing, abrufbar unter: https://​www.​bsi.​bund.​de/​SharedDocs/​


Downloads/​DE/​BSI/​P ublikationen/​Broschueren/​Eckpunktepapier-Sicherheitsempfe​hlungen-CloudComputing-Anbieter.​pdf?​_ ​_ ​blob=​
publicationFile&​v=​6 (zuletzt abgerufen am 13.12.2017).

Bunte, Herrmann-Josef, AGB-Banken, 4. Aufl., München 2015.

Däubler, Wolfgang/Klebe, Thomas/Wedde, Peter/Weichert, Thilo: BDSG, 5. Aufl., Frankfurt am Main 2016.

Derleder, Peter/Knops, Kai-Oliver/Bamberger, Heinz Georg, Deutsches und europäisches Bank- und Kapitalmarktrecht, 3.
Aufl., Berlin Heidelberg 2017.
Dienstbach, Paul H./Mühlenbrock, Tobias: Haftungsfragen bei Phishing-Angriffen. Zugleich Kommentar zu LG Köln, K&R
2008, 151–155.

Dieselhorst, Jochen: Beweislast für Schutzmaßnahmen gegen Rechtsverletzungen, ITRB 2009, 52.

Gaycken, Sandro/Karger, Michael: Entnetzung statt Vernetzung. Paradigmenwechsel bei der IT-Sicherheit, MMR 2011, 3–8.

Gerlach, Carsten: Sicherheitsanforderungen für Telemediendienste – der neue § 13 Abs. 7 TMG, CR 2015, 581–589.

Gola, Peter/Schomerus, Rudolf: Bundesdatenschutzgesetz, 12. Aufl., München 2015.

Habersack, Mathias: Münchener Kommentar zum Bürgerlichen Gesetzbuch, Band 5, 6. Aufl., München 2013.

Hannemann, Ralf/Schneider, Andreas/Weigl, Thomas: MaRisk, 4. Aufl., Stuttgart 2013.

Hecht, Florian: Verantwortlichkeit für Benutzerkonten im Internet. Zugleich Kommentar zu BGH, Urteil vom 11.03.2009 – I ZR
114/06, K&R 2009, 401 ff., K&R 2009, 462–464.

Heckmann, Dirk: juris Praxiskommentar Internetrecht, 4. Aufl., Saarbrücken 2014.

Heiderhoff, Bettina/Zmij, Grzegorz: Law of E-Commerce in Poland and Germany, München 2005.

Heidrich, Joerg/Forgó, Nikolaus/Feldmann, Thorsten: Heise Online Recht, Hannover 2009.

Hennrich, Thorsten: Compliance in Clouds. Datenschutz und Datensicherheit in Datenwolken, CR 2011, 546–552.

Herresthal, Carsten: Haftung bei Account-Überlassung und Account-Missbrauch im Bürgerlichen Recht, K&R 2008, 705–711.

Herzog, Felix/Achtelik, Olaf: Geldwäschegesetz, 2. Aufl., München 2014.

Hoeren, Thomas/Sieber, Ulrich/Holznagel, Bernd: Handbuch Multimedia-Recht, Loseblatt, 43. Aufl., Stand: Juli 2016, München
2016.

Hoffmann, Helmut: Die Entwicklung des Internet-Rechts bis Mitte 2004, NJW 2004, 2569–2576.

Hossenfelder, Martin: Pflichten von Internetnutzern zur Abwehr von Malware und Phishing in Sonderverbindungen, Baden-Baden
2013.

Jandt, Silke/Nebel, Maxi: Die elektronische Zukunft der Anwaltstätigkeit. Rechtsprobleme beim Outsourcing von Scan-
Dienstleistungen, NJW 2013, 1570–1575.

Jauernig, Othmar: BGB, 16. Aufl., München 2015.

Karper, Irene: Sorgfaltspflichten beim Online-Banking — Der Bankkunde als Netzwerkprofi? Zur möglichen Neubewertung des
Haftungsmaßstabs, DuD 2006, 215–219.

Kind, Michael/Werner, Dennis: Rechte und Pflichten im Umgang mit PIN und TAN, CR 2006, 353–360.

Kment, Martin: Verwaltungsrechtliche Instrumente zur Ordnung des virtuellen Raums. Potenziale und Chancen durch E-
Government, MMR 2012, 220–225.

Köbrich, Thomas: Pishing 2.0 – Ein Überblick über die zivilrechtlichen Streitstände, VuR 2015, 9–14.

Koch, Robert: Haftung für die Weiterverbreitung von Viren durch E-Mails, NJW 2004, 801–807.

Kremer, Sascha: Leistungsketten in der Auftragsdatenverarbeitung. Anforderungen an die Einbeziehung von (Unter-
)Unterauftragnehmern nach dem BDSG, ITRB 2014, 60–66.
Kroschwald, Steffen/Wicker, Magda: Kanzleien und Praxen in der Cloud – Strafbarkeit nach § 203 StGB, CR 2012, 758–764.
Krüger, Wolfgang: Münchener Kommentar zum Bürgerlichen Gesetzbuch, Band 2, 7. Aufl., München 2016.

Laue, Philip/Stiemerling, Oliver: Identitäts- und Zugriffsmanagement für Cloud Computing Anwendungen. Technisch-
organisatorische Probleme, Rechtliche Risiken und Lösungsansätze, DuD 2010, 692–697.

Leible, Stefan/Sosnitza, Olaf: Versteigerungen im Internet, 2004.

Leistner, Matthias: Störerhaftung und mittelbare Schutzrechtsverletzung, GRUR-Beil. 2010, 1–32.

Libertus, Michael: Zivilrechtliche Haftung und strafrechtliche Verantwortlichkeit bei unbeabsichtigter Verbreitung von
Computerviren, MMR 2005, 507–512.

Linardatos, Dimitrios: Die Rechtscheinhaftung im Zahlungsdiensterecht– Zugleich eine Anm. zu LG Darmstadt, Urt. v. 28.08.2014
– 28 O 36/14, BKR 2015, 96–100.

Lochter, Manfred/Schindler, Werner: Missbrauch von PIN-gestützten Transaktionen mit ec- und Kreditkarten aus Gutachtersicht,
MMR 2006, 292–297.

Luz, Günther/Neus, Werner/Schaber, Mathias/Schneider, Peter/Wagner, Claus-Peter/Weber, Max: KWG, 3. Aufl., Stuttgart
2015.

Mueller, Ulf/Bohne, Michael: Providerverträge, München 2005.

Müller-Brockhausen, Michael: Haftung für den Missbrauch von Zugangsdaten im Internet, Baden-Baden 2014.

Müller-Broich, Jan D. : Telemediengesetz, Baden-Baden 2012.

Noack, Ulrich/Kremer, Sascha: Online-Auktionen: „ebay-Recht“ als Herausforderung für den Anwalt, AnwBl 2004, 602–604.

Palandt, Otto: Bürgerliches Gesetzbuch, 75. Aufl., München 2016.

Petersen, Christin: Einheitlicher Ansprechpartner und Datenschutz, LKV 2010, 344–349.

Plath, Kai-Uwe: BDSG, 2. Aufl., Köln 2016.

Püls, Joachim: Die digitale Verschwiegenheitspflicht: Datenschutz und Datensicherheit im Notariat, DNotZ-Sonderheft 2012, 120–
132.

Rammos, Thanos/Vonhoff, Hans: Cloud Computing und Sozialdatenschutz. Rechtliche Rahmenbedingungen für den Einsatz von
Cloud Computing-Diensten im Sozialleistungssektor, CR 2013, 265–272.

Rauscher, Thomas/Krüger, Wolfgang: Münchener Kommentar zur Zivilprozessordnung mit Gerichtsverfassungsgesetz und
Nebengesetzen, 4. Aufl., München 2013.

Redeker, Helmut: Cloud Computing in der öffentlichen Hand und § 203 StGB. Öffentlich-rechtliche Datenverarbeitung in der Cloud:
strafrechtliche Fragen und Lösungsmöglichkeiten, ITRB 2014, 232–234.

Rössel, Markus: Filterpflichten in der Cloud. Vom Wortfilter der Sharehoster zum Crawler für Linkportale, CR 2013, 229–236.

Roßnagel, Alexander: Auf dem Weg zur elektronischen Verwaltung – Das E-Government-Gesetz, NJW 2013, 2710–2716.

Roßnagel, Alexander: Recht der Telemediendienste, München 2013.

Roth-Neuschild, Birgit: Cloud Way out. Exit-Strategien bei Nutzung von Cloud Services, ITRB 2013, 213–217.

Schimansky, Herbert/Bunte, Hermann-Josef/Lwowski, Hans Jürgen: Bankrechts-Handbuch, 4. Aufl., München 2011.

Schliesky, Utz: Auswirkungen des E-Government auf Verfahrensrecht und kommunale Verwaltungsstrukturen, NVwZ 2003, 1322–
1328.
Schmidl, Michael: Aspekte des Rechts der IT-Sicherheit, NJW 2010, 476–481.

Schmidt, Karsten: Münchener Kommentar zum Handelsgesetzbuch, 3. Aufl., München 2014.

Schreibauer, Marcus/Spittka, Jan: IT-Sicherheitsgesetz: neue Anforderungen für Unternehmen, ITRB 2015, 240–245.

Schröder, Christian/Haag, Nils Christian: Neue Anforderungen an Cloud Computing für die Praxis, ZD 2011, 147.

Schultze-Melling, Jyn: IT-Sicherheit in der anwaltlichen Beratung. Rechtliche, praktische und wirtschaftliche Aspekte eines
effektiven Information Security-Managements, CR 2005, 73–80.

Schulze, Reiner (Schriftleitung): BGB, 9. Aufl., Baden-Baden 2016.

Schütze, Bernd: SGB X. Sozialverwaltungsverfahren und Sozialdatenschutz, 8. Aufl., München 2014.

Selzer, Annika: Die Kontrollpflicht nach § 11 Abs. 2 Satz 4 BDSG im Zeitalter des Cloud Computing. Alternativen zur Vor-Ort-
Kontrolle des Auftragnehmers durch den Auftraggeber, DuD 2013, 215–219.

Simitis, Spiros: BDSG, 8. Aufl., Baden-Baden 2014.

Spindler, Gerald: Haftungsrisiken und Beweislast bei ec-Karten. Urteilsanmerkung zu BGH, Urteil vom 05.10.2004 – XI ZR
210/03, BB 2004, 2766–2769.

Spindler, Gerald/Schuster, Fabian: Recht der elektronischen Medien, 3. Aufl., München 2015.

v. Staudinger, J.: Buch 1: Allgemeiner Teil 5, §§ 164–240 (Allgemeiner Teil 5), Neubearbeitung 2014, Berlin 2014.

Taeger, Jürgen/Gabel, Detlev: Kommentar zum BDSG und den einschlägigen Vorschriften des TMG und TKG, 2. Aufl., Frankfurt
a.M. 2013.

Thüsing, Gregor: Beschäftigtendatenschutz und Compliance, 2. Aufl., München 2014.

Umnuß, Karsten: Corporate Compliance Checklisten. Rechtliche Risiken im Unternehmen erkennen und vermeiden, 2. Aufl.,
München 2012.

Vorwerk, Volkert/Wolf, Christian: Beck’scher Online-Kommentar ZPO, 23. Edition, Stand: 01.12.2016, München 2016.

Weichert, Thilo: Cloud Computing und Datenschutz, DuD 2010, 679–687.

Weller, Marc-Philippe: Die Haftung von Fußballvereinen für Randale und Rassismus, NJW 2007, 960–964.

Werner, Dennis: Verkehrspflichten privater IT-Nutzer in Bezug auf die Verbreitung von Schadsoftware, Baden-Baden 2010.

Wolff, Heinrich Amadeus/Brink, Stefan: Datenschutzrecht in Bund und Ländern, München 2013.

Fußnoten
1 Vgl. Kap.​ 4, 2.​1.​3.

2 Vgl. Kap.​ 4, 2.​2.​3.

3 Siehe Borges, in: Borges, Internet-Auktion, S. 402; Koch, NJW 2004, 801, 806; Libertus, MMR 2005, 507, 511; Wagner, in:
MüKo-BGB, § 823 Rn. 48 a.E.; Weller, NJW 2007, 960, 961; differenzierend Hossenfelder, S. 93 f.
4 Siehe Kap.​ 4 3.​1.

5 Djeffal, MMR 2015, 716, 719.

6 Siehe Kap.​ 4, 3.​2.

7 Siehe unten 5.

8 Siehe unten 3.1.2, 3.2.2, 3.3.2.

9 Siehe zum Begriff Kap.​ 3, 4.​2.

10 Siehe dazu oben Kap.​ 5, 2.​3.​1.

11 Siehe etwa bei Amazon Web Services https://​aws.​amazon.​com/​iam/​details/​mfa/​ (zuletzt abgerufen am 12.12.2017). Teilweise
bieten aber auch große Internetdienste, wie etwa eBay, die Nutzung sicherer Authentifizierungssysteme nicht einmal optional an,
siehe http://​pages.​ebay.​de/​help/​account/​securing-account.​html (zuletzt abgerufen am 12.12.2017).

12 Jandt/Schaar/Schulz, in: Roßnagel, Recht der Telemediendienste, § 13 TMG Rn. 109; Schmitz, in: Hoeren/Sieber/Holznagel,
Teil 16.2. F. III. Rn. 241; wohl auch: Müller-Broich, Telemediengesetz, § 13 TMG Rn. 7.

13 Gerlach, CR 2015, 581, 582.

14 Djeffal, MMR 2015, 715, 718 ff.; Gerlach, CR 2015, 581, 583; Höltge, ITRB 2016, 47. Im Ergebnis auch
Schreibauer/Spittka, ITRB 2015, 240, 243; wohl auch Schmidt, ITRB 2016, 116, 117.

15 BT-Drs. 18/4096, S. 34.

16 Vgl. die Untersuchung in Kap.​ 5, die nahelegt, dass in verschiedenen Szenarien verschiedene Authentifizierungssysteme
eingesetzt werden sollten.
17 Vgl. zum Szenario Kap.​ 2, 5.​5 und zur rechtlichen Einordnung unten 2.1.2.4.1 und Kap.​ 7, 5.​3.

18 Vgl. Djeffal, MMR 2015, 715, 720.

19 BT-Drs. 18/4096, S. 34 f.

20 So zu erforderlichen Authentisierungssystemen nach § 9 BDSG: Borges, Identitätsnachweis, S. 186; ders., Heilberufe, S. 75


(zur Parallelvorschrift des § 78a SGB X); Brennscheidt, S. 91. Allgemein zur Datensicherung nach § 9 BDSG: Ernestus, in:
Simitis, § 9 BDSG Rn. 27; Däubler, in: D/K/W/W, § 9 BDSG Rn. 25.

21 So auch Schmidt, ITRB 2016, 116, 117. Vgl. zu § 9 BDSG: Borges, Identitätsnachweis, S. 186; Borges et al.,
Identitätsdiebstahl, S. 298; Brennscheidt, S. 91.

22 So im Ergebnis auch Schmidt, ITRB 2016, 116, 117.

23 Abrufbar unter: https://​www.​bsi.​bund.​de/​DE/​P ublikationen/​TechnischeRichtl​inien/​technischerichtl​inien_​node.​html (zuletzt


abgerufen am 13.12.2017). Zur Authentisierung und Authentifizierung bei Nutzung von eID-Karten: https://​www.​bsi.​bund.​de/​DE/​
Publikationen/​TechnischeRichtl​inien/​tr03124/​index_​htm.​html; https://​www.​bsi.​bund.​de/​DE/​P ublikationen/​TechnischeRichtl​inien/​
tr03130/​tr-03130.​html (jeweils zuletzt abgerufen am 13.12.2017).

24 BT-Drs. 18/4096, S. 35.

25 Siehe etwa BSI, IT-Grundschutzkataloge, M 4.133, abrufbar unter: https://​www.​bsi.​bund.​de/​DE/​Themen/​ITGrundschutz/​


ITGrundschutzKat​aloge/​Inhalt/​_ ​content/​m/​m04/​m04133.​html; BSI, IT-Grundschutzkataloge, M 4.392, abrufbar unter: https://​
www.​bsi.​bund.​de/​DE/​Themen/​ITGrundschutz/​ITGrundschutzKat​aloge/​Inhalt/​_ ​content/​m/​m04/​m04392.​html (jeweils zuletzt
abgerufen am 13.12.2017).

26 BT-Drs. 18/4096, S. 34.

27 Siehe dazu unten 2.2.1.3.

28 Siehe Kompetenzzemtrum Trusted Cloud, Arbeitspapier Nr. 9 – Schutzklassen in der Datenschutz-Zertifizierung, S. 13 ff.,
abrufbar unter: http://​www.​aktionsprogramm-cloud-computing.​de/​media/​content/​150402_​Arbpapier_​Nr_​9_​Schutzklassen_​
Datenschutz_​gesamt_​RZ_​Ansicht_​EZ.​pdf (zuletzt abgerufen am 13.12.2017).

29 Siehe Kompetenzzemtrum Trusted Cloud, Arbeitspapier Nr. 9 – Schutzklassen in der Datenschutz-Zertifizierung (Fn. 28), S. 13
ff.

30 Vgl. Kompetenzzemtrum Trusted Cloud, Arbeitspapier Nr. 9 – Schutzklassen in der Datenschutz-Zertifizierung (Fn. 28), S. 13
ff.

31 Gerlach, CR 2015, 581.

32 Borges et al., Identitätsdiebstahl, S. 299.

33 Siehe zum Begriff Kap.​ 3, 3.​1 und 3.​5.

34 Siehe unten 5.

35 Siehe dazu Kap.​ 4, 3.

36 Insoweit wäre zu fragen, ob § 13 Abs. 7 TMG nicht nur einen Mindest- sondern auch einen Höchststandard in Bezug auf das
erforderliche Sicherheitsniveau statuieren möchte. Grundsätzlich können deliktische Verkehrspflichten im Einzelfall höhere
Anforderungen aufstellen als spezialgesetzliche Normen, vgl. dazu Borges, Identitätsnachweis, S. 143 f.

37 Siehe dazu oben Kap.​ 4, 2.​1.​3, 2.​2.​3.

38 Laue/Stiemerling, DuD 2010, 692, 695.

39 So etwa Borges, in: Borges, Internet-Auktion, S. 403 zu Internet-Auktionshäusern.

40 BSI, Eckpunktepapier Sicherheitsempfehlungen für Cloud Computing, S. 43.

LG Karlsruhe, Urt. v. 14.06.2013, 6 O 310/12, BeckRS 2013, 10817 Rn. 53.


LG Karlsruhe, Urt. v. 14.06.2013, 6 O 310/12, BeckRS 2013, 10817 Rn. 53.
41

42 Kramer/Meints, in: Hoeren/Sieber/Holznagel, Teil 16.5 F. I. 4. Rn. 61; Schmidl, NJW 2010, 476; Schultze-Melling, CR 2005,
73, 74; vgl. zum Umfang der korrespondierenden deliktischen Verkehrspflicht auch Borges, Identitätsnachweis, S. 194; Werner,
S. 147.

43 Hossenfelder, S. 83.

44 Gaycken/Karger, MMR 2011, 3, 8; Hennrich, CR 2011, 546, 548.

45 Rath/von Barby, in: Umnuß, Kapitel 7 B. I. Rn. 9.

46 Roth-Neuschild, ITRB 2013, 213, 216.

47 Borges, NJW 2012, 2385, 2388; ders., Identitätsnachweis, S. 198 f.; ders., in: Borges, Internet-Auktion, S. 401; Borges et al.,
Identitätsdiebstahl, S. 295; Berger, in: Jauernig, Anm zu §§ 675 k-675m BGB Rn 3; Maihold, in: Schimansky/Bunte/Lwowski, 2.
Abschnitt § 55 III. 4. Rn. 55.

48 Borges, Identitätsnachweis, S. 200; ders., in: Borges, Internet-Auktion, S. 401; Borges et al., Identitätsdiebstahl, S. 297.

49 Vgl. hierzu Borges, Identitätsnachweis, S. 199 f.

50 Borges, in: Borges, Internet-Auktion, S. 401.

51 BGH, NJW 2008, 3714, 3715 Rn. 17; OLG Brandenburg, MMR 2006, 107, 108; Borges, Identitätsnachweis, S. 195; ders., in:
Borges, Internet-Auktion, S. 399; Dieselhorst, ITRB 2009, 52.

52 Borges, in: Borges, Internet-Auktion, S. 399; vgl. zur Haftung für die Verletzung sonstiger Rechtsgüter auch BGH, MMR 2013,
185, 187; NJW 2004, 3102, 3105; Heckmann, jurisPR-ITR 11/2012 Anm. 3; Rössel, CR 2013, 229; Sesing, in: Borges, Internet-
Auktion, S. 343.

53 Vgl. Kap.​ 4, 2.​1.​4.


54 LG Köln, MMR 2007, 337.

55 Hossenfelder, S. 180; vgl. hinsichtlich der Nutzung von Online-Banking auch Borges, Identitätsnachweis, S. 160; zu
bestehenden Verkehrspflichten des Nutzers ebenso Borges et al., Identitätsdiebstahl, S. 272; Borges, in: Borges, Internet-
Auktion, S. 405; Werner, S. 145.

56 Borges, Identitätsnachweis, S. 161; Borges et al., Identitätsdiebstahl, S. 274; Hossenfelder, S. 180; hinsichtlich der Pflicht zur
Aktualisierung einschränkend Dienstbach/Mühlenbrock, K&R 2008, 151, 154.

57 Borges, in: Borges, Internet-Auktion, S. 406; Werner, S. 163; a.A. Bunte, AGB-Banken, 4. Teil V. B. Nr. 7 Rn. 79;
Hossenfelder, S. 180, die eine Errichtungspflicht grundsätzlich bejahen.

58 So etwa bei LG Frankfurt, Urt. v. 26.09.2005 – 2/25 O 614/03; LG Berlin, Urt. v. 11.08.2009 – 37 O 4/09; AG Frankfurt, Urt.l v.
16.01.2007 – 30 C 1774/06; vgl. hierzu auch Bunte, 4. Teil II. B. I. 2. Rn. 70; Haertlein, in: MüKo-HGB, Recht des
Zahlungsverkehrs, E. II. 3. Rn. E 60; vgl. zu diesem Aspekt außerdem sogleich unten.

59 Vgl. hierzu BGH, GRUR 2009, 597, 598, Rn. 18; Borges, NJW 2005, 3313, 3315; Haase/Hawellek, Heise Online-Recht,
Kapitel VI. 2.4 Rn. 11; Leistner, GRUR-Beil. 2010, 1, 6.

60 So i. E. auch KG Berlin, Urt. v. 20.06.2013 – 8 U 233/12.

61 BGH, NJW 2004, 3623; LG Berlin, NJW-RR 2011, 352, 353; AG Frankfurt, BKR 2003, 514, 517; vgl. auch Lochter/Schindler,
MMR 2006, 292, 296 Rn. 33: „Dass das Notieren der PIN auf der Karte oder das Mitführen einer Notiz im Klartext grob
fahrlässig ist, versteht sich von selbst“.

62 So auch für den bankrechtlichen Sektor Maihold, in: Schimansky/Bunte/Lwowski,2. Abschnitt 9. Kapitel § 55 VI. 4. Rn. 130;
Spindler, BB 2004, 2766, 2767; ähnlich BGH, CR 2001, 77, 78; strenger Casper, in: MüKo-BGB, § 675 l Rn. 14, der eine Art
„Kodierung“ fordert.

63 Vgl. hierzu überblicksartig Bunte, 3. B. I. 2. Nr. 6 IV. Rn. 70 ff.; Haertlein, in: MüKo-HGB, Recht des Zahlungsverkehrs, E. II.
3. Rn. E 56 ff.; Maihold, in: Schimanski/Bunte/Lwowski, § 54 VI. 4. Rn. 73 ff.

64 So etwa LG Halle, Urt. v. 27.10.2000 – 14 O 97/00; AG Charlottenburg, Urt. v. 16.12.2002 – 202 C 177/02; Haertlein, in:
MüKo-HGB, Recht des Zahlungsverkehrs, E. II. 3. Rn. E 61.
65 Siehe 5.

66 Siehe BGHZ 180, 134.

67 Vgl. hierzu Kap.​ 4, 2.​1.​5.

68 Gleichfalls skeptisch Borges et al., Identitätsdiebstahl, S. 230.

69 Vgl. zum bankrechtlichen Kontext Borges, Identitätsnachweis, S. 159; zu Online-Handelsplattformen Borges et al.,
Identitätsdiebstahl, S. 228.

70 Vgl. oben 2.1.2.2.

71 Vgl. hierzu Stadler, in: Jauernig, § 309 BGB Rn. 8 f.; Schulte-Nölke, in: Schulze u. a., § 309 BGB Rn. 24 f.

72 BGH, NJW 2002, 673, 674; NJW 1990, 761, 764.

73 Wurmnest, in: MüKo-BGB, § 307 Rn. 72.

74 BGH, NJW-RR 2005, 1496, 1505.

75 BGH, DNotZ 2013, 354, 365 f.; NJW-RR 1989, 953, 956; NJW 1985, 3016, 3018; vgl. auch Mueller/Bohne, § 6 Nr. 1;
Wurmnest, in: MüKo-BGB, § 309 Nr. 7 Rn 30.

76 OLG Hamm, Urt. v. 09.12.2004 – 21 U 58/04.

77 Siehe Kap.​ 4, 5.​3.

78 Vgl. auch Kap.​ 4, 5.​4.​2 sowie die Nachweise dort in Fn. 146.
79 Borges, in: Borges/Meents, § 7 Rn. 124; Brennscheidt, S. 87; Kremer, ITRB 2014, 60, 62. Vgl. auch Fallgruppen der
internationalen Auftragsdatenverarbeitung, Handreichung des Düsseldorfer Kreises zur rechtlichen Bewertung, 19.04.2007, S. 15.

80 Gola/Klug/Körffer, in: Gola/Schomerus, § 9 BDSG Rn. 1; Karg, in: Wolff/Brink, § 9 BDSG Rn. 1; Plath, in: Plath, § 9 BDSG
Rn. 1.

81 Gola/Klug/Körffer, in: Gola/Schomerus, § 9 BDSG Rn. 1; Wedde, in: D/K/W/W, § 9 BDSG Rn. 29.

82 Ernestus, in: Simitis, § 9 BDSG Rn. 23.

83 Vgl. hierzu oben 2.1.1.

84 Wedde, in: D/K/W/W, § 9 Rn. 19.

85 Schultze-Melling, in: Taeger/Gabel, § 9 BDSG Rn. 25; vgl. auch Kompetenzzemtrum Trusted Cloud, Arbeitspapier Nr. 9 –
Schutzklassen in der Datenschutz-Zertifizierung (Fn. 28), S. 13 f.

86 Ernestus, in: Simitis, § 9 BDSG Rn. 27.

87 Karg, in: Wolff/Brink, § 9 BDSG Rn. 105.

88 Vgl. oben 2.1.1.1.1.2.

89 Ernestus, in: Simitis, § 9 BDSG Rn. 38.

90 So auch Ernestus, in: Simitis, § 9 BDSG Rn. 40.

91 Ernestus, in: Simitis, § 9 BDSG Rn. 20; Karg, in: Wolff/Brink, § 9 BDSG Rn. 68 f.; Wedde, in: D/K/W/W, § 9 BDSG Rn 17.
92 Gola/Klug/Körffer, in: Gola/Schomerus, § 9 BDSG Rn. 19; Kramer/Meints, in: Hoeren/Sieber/Holznagel, Teil 16.5
Datensicherheit Rn. 69.

93 Plath, in: Plath, § 9 BDSG Rn. 12.

94 Ernestus, in: Simitis, § 9 BDSG Rn. 22.

95 Wedde, in: D/K/W/W, § 9 BDSG Rn. 47.

96 Wedde, in: D/K/W/W, § 9 BDSG Rn. 47.

97 Ernestus, in: Simitis, § 9 BDSG Rn. 97 ff.; Wedde, in: D/K/W/W, § 9 BDSG Rn. 47.

98 Eine gesetzliche Ausnahme gilt insoweit für die Bestellung des Datenschutzbeauftragten, wenn höchstens 9 Personen mit der
Datenverarbeitung befasst sind, vgl. § 4f BDSG.

99 Vgl. etwa die modulare, nicht abschließende Darstellung von Sicherheitsmaßnahmen im IT-Grundschutz-Katalog des BSI,
abrufbar unter https://​www.​bsi.​bund.​de/​DE/​Themen/​ITGrundschutz/​ITGrundschutzKat​aloge/​Inhalt/​_ ​content/​kataloge.​html (zuletzt
abgerufen am 13.12.2017) sowie das Schutzklassenkonzept der Trusted Cloud Zertifizierung: Kompetenzzemtrum Trusted Cloud,
Arbeitspapier Nr. 9 – Schutzklassen in der Datenschutz-Zertifizierung (Fn. 28), S. 13 f.

100 Karg, in: Wolff/Brink, § 9 BDSG Rn. 70.

101 Borges, Identitätsmissbrauch, S. 186; ders., Heilberufe S. 70 ff.; Borges et al., S. 206 f.; Brennscheidt, S. 91;
Gola/Klug/Körffer, in: Gola/Schomerus, § 9 BDSG Rn. 23; Plath, in: Plath, § 9 BDSG Rn. 35.

102 Borges, Identitätsmissbrauch, S. 187.

103 Ernestus, in: Simitis, § 9 BDSG Rn. 96 ff; Gola/Klug/Körffer, in: Gola/Schomerus,§ 9 BDSG Rn. 23; Plath, in: Plath, § 9
BDSG Rn. 35.

104 Siehe bereits Borges, Heilberufe, S. 83.


105 Siehe 2.2.1.1.

106 Siehe 2.1.1.1.1.1.

107 Lotz/Wendler, CR 2016, 31, 35 möchten die Möglichkeit der Einwilligung auch auf die technisch-organisatorischen Maßnahmen
ausdehnen. Diese Ansicht hat jedoch für die hier untersuchte Konstellation nur geringe Relevanz: Selbst wenn ihr gefolgt werden
sollte, dürfte eine Abbedingung des § 9 BDSG in der Praxis keine merklichen Auswirkungen haben. Zum einen wäre es meist
unwirtschaftlich, die Daten der Einwilligenden und der Ablehnenden unterschiedlich zu behandeln. Zum anderen wäre eine solche
Einwilligung in AGB regelmäßig als unangemessene Benachteiligung sowie als überraschende Klausel zu bewerten (a.A. wohl
Lotz/Wendler, CR 2016, 31, 35).

108 Vgl. hierzu oben 2.1.1.

109 BGH, NJW 2008, 3775, 3777; NJW-RR 2003, 1459, 1460; NJW 1987, 372, 373; Borges, Identitätsnachweis, S. 142.

110 BGH, NJW-RR 2003, 1459, 1460; NJW 1987, 372, 373; Borges, Identitätsnachweis, S. 143; Förster, in: BeckOK-BGB, § 823
Rn. 339; Hager, in: Staudinger, § 823 Rn. E 34.

111 Vgl. allgemein zu den Verkehrspflichten Kap.​ 4, 2.​2.​3.

112 Gola/Klug/Körffer, in: Gola/Schomerus, § 11 BDSG Rn. 20; Spindler/Nink, in: Spindler/Schuster, § 11 BDSG Rn. 18;
Thüsing/Granetzny, in: Thüsing, § 16 IV. 2. Rn. 29.

113 Borges/Brennscheidt, in: Borges/Schwenk, Identitätsschutz, S. 65 f.; Brennscheidt, S. 103 f.

114 Spoerr, in: Wolff/Brink, § 11 BDSG Rn. 94.

115 Spoerr, in: Wolff/Brink, § 11 BDSG Rn. 94.

116 Borges, DuD 2012, 165, 166.


117 Borges, DuD 2012, 165, 166; ders., in: Borges/Meents, § 7 Rn. 77 ff.; Golland, DSB 2014, 213; Schröder/Haag, ZD 2011,
147, 149; Selzer, DuD 2013, 215, 218 f.; Weichert, DuD 2010, 679, 683.

118 Borges, DuD 2012, 165, 166.

119 Warius, in: Herzog/Achtelik, § 9 GWG Rn. 122.

120 Wolfgarten, in: Boos/Fischer/Schulte-Mattler, § 25b KWG Rn. 69.

121 Siehe dazu IBM, Cloud Computing for Banking, S. 4, abrufbar unter: http://​www-935.​ibm.​com/​services/​multimedia/​Cloud_​
Computing_​for_​Banking_​_ ​Janvier_​2013.​pdf (zuletzt abgerufen am 13.12.2017).

122 Siehe nur LG Nürnberg-Fürth, Urt. v. 28.04.2008, 10 O 11391/07, BeckRS 2008, 26304; Borges, in:
Derleder/Knops/Bamberger, § 11 Rn. 342; Borges et al., S. 296; Karper, DuD 2006, 215, 217; Kind/Werner, CR 2006, 353,
357.

123 Braun, in: Boos/Fischer/Schulte-Mattler, KWG, § 25a Rn. 696; vgl. zu den Regelungen der MaRisk bereits Kap.​ 4, 6.​1.​1 und 6.​
1.​2.

124 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 342; Kind/Werner, CR 2006, 353, 358; Recknagel, S. 195 f.

125 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 342.

126 In diese Richtung Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 347.

127 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 347.

128 KG, MMR 2011, 338, 339; siehe dazu Borges, NJW 2012, 2385, 2388.

129 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 343; Schulte am Hülse/Klabunde, MMR 2010, 84, 88; Spindler,
Verantwortlichkeit von IT-Herstellern, Nutzern und Intermediären, Studie im Auftrag des BSI, S. 214; Willershausen, in:
jurisPR-BKR, 10/2011, Anm. 4.
130 Köbrich, VuR 2015, 9.

131 Siehe Fn. 99.

132 Hannemann/Schneider/Weigl, AT 7.2 Tz. 2; Hellstern, in: Luz/Neus/Schaber/Schneider/Wagner/Weber, § 25a Rn. 104.

133 Siehe Kap.​ 4, 6.​2.​3.

134 Vgl. hierzu oben 2.2.1.1.

135 So wohl Rammos/Vonhoff, CR 2013, 265, 269.

136 So aber Bieresborn, in: v. Wulffen/Schütz, § 78a SGB X Rn 7.

137 Borges, Heilberufe, S. 83.

138 Vgl. hierzu Kap.​ 4, 7.​2.

139 Kroschwald/Wicker, CR 2012, 758, 763.

140 Vgl. hierzu Kap.​ 4, 7.​4.

141 Vgl. das Beispiel im Gesetzesentwurf der Bundesregierung, Begründung, S. 37. Dieses wird zwar zur Änderung der
Bundesrechtsanwaltsordnung (neuer § 43e BRAO) angeführt. Dieser wurde allerdings parallel zu § 203 StGB ausgestaltet und
stellt ebenso auf eine „Erforderlichkeit“ der Auslagerung ab. Insofern ist anzunehmen, dass diese Wertung des Gesetzesgebers
auch auf die Änderung bei § 203 StGB übertragbar ist.

142 Siehe zur Technik Kap.​ 3, 4.​1.​6.


143 Schliesky, NVwZ 2003, 1322, 1325 f.; vgl. auch Petersen, LKV 2010, 344, 345.

144 Kment, MMR 2012, 220, 221.

145 Roßnagel, NJW 2013, 2710, 2714.

146 Der Landesbeauftragte für den Datenschutz Niedersachsen (Hrsg.), Datenschutzgerechtes eGovernment, 2002, S. 67.

147 Siehe oben 2.2.1.3.

148 Vgl. zur Digitalisierung der Grundbücher in Polen MMR-Aktuell 2010, 311222.

149 Bernhardt/Heckmann, in: jurisPK-Internetrecht, Kapitel 6 A. II. 2. Rn. 25; vgl. auch Püls, DNotZ-Sonderheft 2012, 120, 130.

150 Bund-Länder-Kommission für Datenverarbeitung und Rationalisierung in der Justiz, CR 2009, S5, S11; sogar eher auf eine
inhaltliche Beeinflussung abstellend Bernhardt/Heckmann, in: jurisPK-Internetrecht, Kapitel 6 A. II. 2. Rn. 30.

151 Bernhardt/Heckmann, in: jurisPK-Internetrecht, Kapitel 6 A. II. 2. Rn. 26.

152 Bund-Länder-Kommission für Datenverarbeitung und Rationalisierung in der Justiz,CR 2009, S5, S11.

153 Vgl. oben 3.1.2.

154 Siehe Kap.​ 5, 3.​3.

155 Siehe unten 5.2, 5.3, 5.4.

156 Ausgegangen wird hier vom Verbraucherbegriff des § 13 BGB. Danach ist Verbraucher jede natürliche Person, die ein
Rechtsgeschäft zu Zwecken abschließt, die überwiegend weder ihrer gewerblichen noch ihrer selbständigen beruflichen Tätigkeit
zugerechnet werden können.
157 Siehe Kap.​ 5, 3.​4.​1.

158 Siehe zur Ermittlung des Schutzbedarfs von Daten oben 2.1.1.1.1.3.

159 Siehe Kap.​ 5 g, 3.​4.​1.

160 Siehe oben 2.1.1.1.1.2.

161 Siehe oben 2.1.1.1.1.2.

162 Siehe Kap.​ 5, 3.​4.​1.

163 Siehe oben 2.1.1.1.1.2.

164 Siehe oben 2.2.1.1 und 2.2.1.3.

165 Siehe Kap.​ 5, 3.​4.​2.

166 Siehe Kap.​ 5, 3.​4.​3.

167 Siehe Kap.​ 5, 3.​4.​4.

168 Ellenberger, in: Palandt, § 172 BGB Rn. 18.

169 BGH, NJW 2011, 2421, 2422; Borges, Identitätsnachweis, S. 133; ders., NJW 2011, 2400, 2401 ff.; ders., in:
Derleder/Knops/Bamberger, § 11 Rn. 294; Ellenberger, in: Palandt, § 172 BGB Rn. 18; Linardatos, BKR 2015, 96, 98.

170 Siehe zu abweichenden Ansichten in der Literatur Schilken, in: Staudinger, § 167 BGB Rn. 31.
171 BGH, NJW 2011, 2421, 2422; ähnlich bereits BGH, NJW 2002, 2325, 2327; NJW 2007, 987, 988.

172 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 293.

173 BGH, NJW 2011, 2421, 2422; ähnlich bereits BGH, NJW 2006, 1971, 1972; NJW 2007, 987, 989.

174 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 296.

175 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 297; ders., NJW 2011, 2400, 2401; ders., in: Borges, Internet-Auktion, S.
390 f. Siehe auch Canaris, S. 491.

176 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 298.

177 BGH, NJW 2011, 2421, 2422; OLG Köln, NJW 2006, 1676, 1677; LG Bonn, MMR 2002, 255, 257; LG Bonn, CR 2004, 218
220. Siehe auch Herresthal, K&R 2008, 705, 706; Kuhn, S. 217 f.; Rieder, S. 309.

178 LG Darmstadt, BKR 2014, 480, 482.

179 BGH, NJW 2011, 2421, 2422.

180 LG Aachen, CR 2007, 605; AG Saarbrücken, BeckRS 2008, 07470; Herresthal, K&R 2008, 705, 708; Hoffmann, in:
Leible/Sosnitza, Rn. 177.

181 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 298; ders., NJW 2011, 2400, 2402; ders., in: Borges, Internet-Auktion, S. 390
f.

182 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 300; ders., in: Borges, Internet-Auktion, S. 390 f.

183 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 302; ders., NJW 2011, 2400, 2401 f.; ders., in: Borges, Internet-Auktion, S.
392.
184 OLG Schleswig, CR 2011, 52; Brückner, S. 91; Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 304; Borges et al., S. 256;
Herresthal, K&R 2008, 705, 708; Müller-Brockhausen, S. 157.

185 BGH, NJW 2011, 2421, 2423 Rn. 19.

186 BGH, NJW 2011, 2421, 2423 Rn. 20.

187 LG Darmstadt, BKR 2014, 480, 482.

188 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 303.

189 Siehe Kap.​ 4, 6.​3.​2.​2.

190 Siehe Borges, in: Borges, Internet-Auktion, S. 411.

191 BGH, MMR 2004, 812, 814; BKR 2012, 128, 129; OLG Frankfurt, MMR 2009, 856; LG Würzburg, BKR 2011, 526, 527; AG
Hannover, CR 1997, 742, 743; AG Osnabrück, NJW 1998, 688; vgl. hierzu auch Borges, Identitätsnachweis, S. 234.

192 Vgl. hierzu BGH, NJW 2013, 1092, 1095; Bacher, in: BeckOK-ZPO, § 284 ZPO Rn. 98; Prütting, in: MüKo-ZPO, § 286 ZPO
Rn. 65.

193 OLG Köln, MMR 2002, 813, 814; OLG Hamm, NJW 2007, 611; OLG Bremen, MMR 2012, 593, 594; siehe auch Biallaß,
ZUM 2007, 397, 398; Borges, NJW 2005, 3313, 3317; ders., in: Borges, Internet-Auktion, S. 412 f.; ders., Identitätsnachweis, S.
239; Borges et al., S. 310 f.; Hartmann, in: Baumbach/Lauterbach/Albers/Hartmann, Anh. § 286 ZPO Rn. 101; Hecht, K&R
2009, 462, 464; Heiderhoff, in: Heiderhoff/Zmij, S. 97, 105 f.; Hoffmann, NJW 2004, 2569, 2571; Neubauer/Steinmetz, in:
Hoeren/Sieber/Holznagel, Teil, 14 B. V. 1. Rn. 59; Noack/Kremer, AnwBl 2004, 602, 604; Roßnagel/Hornung, DöV 2009, 301,
303, Fn. 22; Wiebe, in: Spindler/Wiebe, Kap.​ 4 Rn. 61.

194 Borges, in: Borges, Internet-Auktion, S. 411; Casper, in: MüKo-BGB, § 675w Rn. 20; Köbrich, VuR 2015, 9, 12; Maihold, in:
Schimansky/Bunte/Lwowski, § 55 Rn. 85.

195 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 392.


196 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 382.

197 Borges, in: Borges, Internet-Auktion, S. 411; ders., Identitätsnachweis, S. 237; für das eTAN- und mTAN-Verfahren ebenso
LG Köln, NJW 2014, 3735, 3736 (mTAN); MüKo-BGB-Casper, § 675w Rn. 20; strenger Maihold, in:
Schimansky/Bunte/Lwowski, § 55 Rn. 85; für das mTAN, SmartTAn plus und SmartTAN optic-Verfahren Köbrich, VuR 2015,
9, 12.

198 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 391.

199 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 391.

200 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 393.

201 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 393.

202 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 394; vgl. Borges, Identitätsnachweis, S. 242 zum Anscheinsbeweis bei der
Verwendung der elektronischen Signatur sowie Borges, NJW 2010, 3334, 3338 zum Anscheinsbeweis bei der Verwendung des
elektronischen Identitätsnachweises.

203 Borges, in: Derleder/Knops/Bamberger, § 11 Rn. 394; Borges, Identitätsnachweis, S. 242; ders., NJW 2010, 3334, 3338.
© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018
Georg Borges und Brigitte Werners (Hrsg.), Identitätsmanagement im Cloud Computing, https://doi.org/10.1007/978-3-662-55584-
2_7

7. Zusammenfassung der Ergebnisse


Torben Kriegesmann1 und AndreasAndreas SchillingSchilling2
(1) Landgericht Essen, 45130 Essen, Deutschland
(2) Ruhr-Universität Bochum, Fakultät für Wirtschaftswissenschaft, 44780 Bochum, Deutschland

Torben Kriegesmann (Korrespondenzautor)


Email: torben.kriegesmann@rub.de

AndreasAndreas SchillingSchilling
Email: andreas.schilling@rub.de

1 Einsatz-, Bedrohungs- und Schadensszenarien


1.1 Zugriffsmanagement
1.2 Bedrohungs- und Angriffsszenarien
1.3 Schadensszenarien
2 Schutzmaßnahmen zur sicheren Identifizierung und Authentifizierung für Cloud-basierte
Systeme
2.1 Grundprinzipien der Authentifizierung
2.2 Faktor-basierte Authentifizierung
2.3 Mehr-Faktor-Authentifizierung
3 Rechtliche Rahmenbedingungen des Identitätsmanagements im Cloud Computing
3.1 Überblick
3.2 Vertragsrecht
3.3 Deliktsrecht
3.4 Datenschutzrecht
3.5 Branchenspezifische und strafrechtliche Aspekte
3.6 Beweisrecht
4 Quantitative Entscheidungsunterstützung für ein sicheres Identitäts- und Zugriffsmanagement
4.1 Problemstellung und Entscheidungssituation
4.2 Modellstruktur
4.3 Modellimplementierung und Auswertung
5 Konkretisierung rechtlicher Anforderungen an das Identitätsmanagement im Cloud Computing
5.1 Überblick
5.2 Anforderungen an den Cloud-Anbieter
5.3 Anforderungen an den Cloud-Nutzer
5.4 Branchenspezifische Anforderungen
5.5 Beweisrechtliche Aspekte

1 Einsatz-, Bedrohungs- und Schadensszenarien


Im Fokus der Untersuchung standen das Cloud Computing durch kleine und mittelständische
Unternehmen, die in der Cloud erfolgende Datenverarbeitung durch Unternehmen der
Kreditwirtschaft, durch Sozialversicherungsträger und durch Berufsgeheimnisträger sowie Cloud-
basierte Dienste, die sich unmittelbar an Verbraucher richten. Dabei handelt es sich um typische
Anwendungsszenarien für Cloud Computing, die sich nicht nur hinsichtlich der Art der zu
erwartenden Schäden, sondern auch hinsichtlich der rechtlichen Rahmenbedingungen
unterscheiden.

1.1 Zugriffsmanagement
Zunächst wurden die relevanten Authentisierungsmethoden dargestellt.1 Das Zugriffsmanagement
ist der Schlüsselaspekt für die Identifizierung in der Cloud, da hiervon die möglichen
Bedrohungs- und somit auch Schadensszenarien abhängig sind. Vorherrschend ist immer noch die
Authentisierung via Benutzername und Passwort. Inzwischen bieten mehrere Cloud-Anbieter
zusätzlich optional eine Zwei-Faktor-Authentisierung an, welche die Sicherheit erheblich erhöhen
kann. Dies kann etwa durch Verwendung von Einmalpasswörtern, von Smartcards oder des
elektronischen Identitätsnachweises (eID) geschehen. Auch neue Verfahren, wie beispielsweise
Single-Sign-On (SSO), werden vermehrt eingesetzt.

1.2 Bedrohungs- und Angriffsszenarien


Die möglichen Bedrohungsszenarien wurden anhand des jeweiligen Konzepts der
Zugriffsgestaltung untersucht.2 Bei Angriffen durch Außenstehende ist zwischen den
vergleichsweise einfach durchzuführenden Angriffen auf Systeme, in denen die Authentisierung
mittels Benutzername und Passwort erfolgt, und Angriffen auf Systeme, die sich einer Zwei-
Faktor-Authentisierung bedienen, zu differenzieren. Bei letzteren kommt es allein auf die
Ausgestaltung des Zugriffsmanagements an; insoweit ist irrelevant, ob Ziel eines Angriffs ein
Beteiligter einer klassischen Client-Server-Kommunikation oder ein Teil eines Cloud-Netzwerks
ist.

1.3 Schadensszenarien
Die Schadensszenarien wurden anhand der zu untersuchenden Einsatzgebiete beleuchtet.3 Je nach
Einsatzgebiet sind unterschiedliche Schäden, insbesondere durch Identitätsmissbrauch, möglich:
Beim Einsatz im Unternehmen tritt zunächst das Problem des (temporären) Betriebsausfalls in den
Vordergrund. Die Verfügbarkeit hat unmittelbaren Einfluss auf den Unternehmenserfolg sowohl
des Cloud-Nutzers als auch das Cloud-Anbieters. Weiterhin besteht in allen Szenarien durch den
unberechtigten Zugriff das Risiko des Datenverlusts sowie des Verlusts der Vertraulichkeit der
Daten. Betroffen sind im Regelfall v. a. der Cloud-Nutzer und dessen Kunden, deren Daten in der
Cloud gespeichert waren. Ein denkbares Szenario ist etwa die Industriespionage, aber auch das
Bekanntwerden sensibler personenbezogener Daten wie im Falle des in den Medien bekannt
gewordenen iCloud-Hacks.4 Weitere denkbare Szenarien sind beispielsweise die Abgabe
rechtserheblicher Erklärungen unter fremdem Namen sowie die unberechtigte Abbuchung von
Geldbeträgen im Kreditwesen. Erfolgreiche Angriffe auf das Identitäts- und Zugriffsmanagement
gehen zudem häufig mit Imageschäden für die involvierten Unternehmen einher.

2 Schutzmaßnahmen zur sicheren Identifizierung und


Authentifizierung für Cloud-basierte Systeme
Bei allen Zugriffen auf Ressourcen im Cloud Computing muss die Identität der zugreifenden
Personen geprüft und der Zugriff authentifiziert werden. Entsprechende Maßnahmen und Verfahren
zur Feststellung der Identität sind daher von zentraler Bedeutung für den sicheren Betrieb von
Informationssystemen. In diesem Buch waren ausschließlich Authentifizierungsmaßnahmen und -
verfahren berücksichtigt, welche auf Identitätsbezeichnern und Attributen natürlicher Personen
basieren, da relevante Identitäten ausschließlich digitale Abbilder realer Identitäten sind.

2.1 Grundprinzipien der Authentifizierung


Ein wesentlicher Bestandteil des Identitätsmanagements ist die Identifizierung, Authentisierung
und Authentifizierung von Personen in Informationssystemen.5 Dies bedeutet, dass eine Person
zunächst ihre Identität angibt (Identifizierung) und um Berechtigungsnachweise ergänzt
(Authentisierung). Anschließend versucht ein Kommunikationspartner, diese anhand der
Berechtigungsnachweise zu bestätigen (Authentifizierung). Nur wenn es möglich ist, die Identität
einer Person eindeutig festzustellen und zu verifizieren, kann der Zugriff auf Ressourcen
freigegeben und reguliert werden (Autorisierung). Zu diesem Zweck ist jeder Person mindestens
eine digitale Identität zugeordnet, welche mit konkreten Zugriffsberechtigungen verknüpft werden
kann. Als Vorstufe der Zugriffskontrolle (engl. access control) ist die zuverlässige Identifizierung
und Authentifizierung einer Person zwingend erforderlich.

2.2 Faktor-basierte Authentifizierung


Die Identifizierung bzw. die Authentifizierung von Nutzern kann allgemein unter Verwendung von
drei verschiedenen Faktoren erfolgen.6 Zur Erhöhung der Sicherheit können unterschiedliche
Attribute eines Faktors mehrfach abgefragt werden oder Faktoren beliebig kombiniert werden. Ist
eine erhöhte Sicherheit gefordert, wird häufig eine Authentifizierung unter Verwendung von zwei
Faktoren verwendet (Zwei-Faktor-Authentifizierung7).
Der erste Faktor zur Identifizierung einer Person basiert auf dem Wissen der Person
(„Something you know“). Die verschiedenen wissensbasierten Attribute können unterschiedlich
stark ausgeprägt sein, müssen aber zwingend mindestens ein Element beinhalten, welches nur dem
Nutzer bekannt ist. Die Sicherheit dieser Authentifizierungsmethode hängt maßgeblich von der
Geheimhaltung und der Komplexität des geheimen Attributs ab. In der Praxis wird diese Methode
vielfach verwendet, insbesondere durch Nutzung von Passwörtern. Bei Analysen von Passwörtern
in Produktivsystemen zeigt sich allerdings regelmäßig, dass keine ausreichende
Passwortkomplexität verwendet wird und der Zugriff zu den Systemen durch Brute-Force-
Angriffe8 erlangt werden kann.
Der zweite Faktor beinhaltet alle Attribute, die unmittelbarer Teil der Person sind, also
beispielsweise biologische Eigenschaften der Person betreffen („Something you are“). Dies sind
vornehmlich biometrische Attribute, wie ein Fingerabdruck oder die Iris des Auges. Möglich sind
aber auch temporäre Attribute, wie der aktuelle Aufenthaltsort. Im Falle biometrischer Attribute
ist prinzipiell eine eindeutige Identifizierung einer Person möglich. Es existieren allerdings
praxistaugliche Angriffsmethoden, welche z. B. einen Fingerabdruck replizieren können.
Der dritte Faktor basiert auf Gegenständen, die sich im Besitz einer Person befinden
(„Something you have“). Die Authentifizierung basiert ausschließlich auf dem Besitz des
Gegenstandes, weshalb die eindeutige Identifizierung einer Person nur bedingt möglich ist. Wenn
der Gegenstand in den Besitz eines Angreifers gelangt, nimmt der Angreifer de facto die Identität
des ursprünglichen Besitzers an. Für den Zugriff zu Informationssystemen reicht dieser Faktor als
alleiniges Authentifizierungsmerkmal daher meist nicht aus. Dennoch finden beispielsweise API9-
Schlüssel Verwendung bei Service-Anbietern, bei denen die Kenntnis des Schlüssels ausreicht,
um Zugriff auf den Service zu erlangen.

2.3 Mehr-Faktor-Authentifizierung10
Die meisten populären Cloud-Anwendungen nutzen eine Ein-Faktor-Authentifizierung. Bedingt
durch die einfache technische Umsetzbarkeit und die Akzeptanz durch die Benutzer ist dies meist
eine Kombination aus Benutzerkennung und Passwort (Wissen). In vielen Fällen ist dies bei
geeigneter technischer und organisatorischer Absicherung auch ausreichend und entspricht einem
angemessenen Sicherheitsniveau, wie die folgenden Ausarbeitungen zeigen. Wird durch höhere
Sicherheitsanforderungen eine zusätzliche Absicherung benötigt, kann eine Kombination mehrerer
Faktoren eine deutliche Verringerung des Risikos bewirken. Werden mindestens zwei Faktoren
zur Authentifizierung eingesetzt, spricht man von einer Mehr-Faktor-Authentifizierung.
Es hat sich gezeigt, dass in der praktischen Umsetzung fast ausschließlich eine Ein-Faktor-
Authentifizierung eingesetzt wird. In den meisten Fällen sind keine Passwortrichtlinien umgesetzt,
sodass in vielen Fällen keine ausreichende Sicherheit gewährleistet ist. In einigen kritischeren
Anwendungen, wie beispielsweise bei dem Infrastruktur-Service Amazon Web Services (AWS),
ist optional eine Zwei-Faktor-Authentifizierung möglich, jedoch nicht vorgeschrieben. Auch
digitale Zertifikate (Besitz und ggf. Wissen) oder API-Schlüssel (Besitz) finden teilweise
Verwendung.

3 Rechtliche Rahmenbedingungen des Identitätsmanagements im


Cloud Computing
3.1 Überblick
Welche Maßnahmen des Identitätsmanagements aus ökonomischer Sicht zu treffen sind, kann nur in
Abhängigkeit der rechtlichen Anforderungen bestimmt werden. Rechtliche Anforderungen an das
Identitätsmanagement ergeben sich – in Abhängigkeit von den Einsatzszenarien – aus
verschiedensten Rechtsgebieten. Zu beachten sind insbesondere das Vertrags- und Deliktsrecht,
wie auch das Datenschutzrecht und das Recht der Telemedien. Daneben gelten spezielle
Anforderungen für das Cloud Computing im Bereich des Kredit- und (Sozial-
)Versicherungswesens. In Bezug auf Berufsgeheimnisträger ist weiterhin der strafrechtlich
ausgestaltete Schutz von Privatgeheimnissen zu beachten.

3.2 Vertragsrecht
Im Verhältnis zwischen Cloud-Anbieter und Cloud-Nutzer kann sich eine Haftung für
Pflichtverletzungen im Rahmen des Identitätsmanagements insbesondere aus dem zwischen den
Parteien geschlossenen Vertrag über die Erbringung des Cloud-Dienstes ergeben.11
Da Cloud Computing-Dienstleistungen häufig grenzüberschreitend erbracht werden, stellt sich
zunächst die Frage, welches Recht auf die in diesem Rahmen geschlossenen Verträge anwendbar
ist.12 Innerhalb der EU müssen die Gerichte diese Frage nach der Rom I-VO13 entscheiden.
Danach ist auf den Vertrag zwischen Cloud-Nutzer und Cloud-Anbieter gem. Art. 4 Abs. 2 Rom I-
VO das Recht am Ort der Hauptniederlassung des Cloud-Anbieters maßgeblich. In der Praxis
werden die Parteien allerdings ohnehin meist gem. Art. 3 Rom I-VO eine Rechtswahlklausel
vereinbaren und das anwendbare Recht so vertraglich festlegen. Eine Abweichung kann sich
ergeben, soweit der Cloud-Nutzer Verbraucher ist. Ist der Cloud-Dienst auf Verbraucher mit
gewöhnlichem Aufenthalt in einem bestimmten Staat ausgerichtet oder übt der Cloud-Anbieter
dort seine Tätigkeit aus, gilt gem. Art. 6 Abs. 1 lit. b Rom I-VO das Recht des Staates, in dem der
Verbraucher ansässig ist. Zwar ist auch insoweit eine Rechtswahl zulässig, doch darf durch sie
gem. Art. 6 Abs. 2 Rom I-VO nicht vom zwingenden Verbraucherschutzrecht dieses Staates
abgewichen werden.
Soweit die Parteien keine besonderen Abreden getroffen haben, kommt hinsichtlich der
Anforderungen im Rahmen des Identitätsmanagements den vertraglichen Nebenpflichten nach §
241 Abs. 2 BGB besondere Bedeutung zu.14 § 241 Abs. 2 BGB statuiert eine
Rücksichtnahmepflicht in Bezug auf die Rechte, Rechtsgüter und Interessen der jeweils anderen
Partei. Insbesondere ergibt sich aus § 241 Abs. 2 BGB eine Pflicht des Cloud-Anbieters zur
Gewährleistung eines hinreichenden IT-Sicherheitsniveaus. Der Cloud-Anbieter muss zumutbare
Maßnahmen ergreifen, um die Daten seiner Kunden vor Verlust und unbefugtem Fremdzugriff zu
schützen. Welche Maßnahmen konkret zu ergreifen sind, kann nicht pauschal beantwortet werden,
sondern richtet sich nach dem Einzelfall. Danach ist eine umfassende Risikoanalyse vorzunehmen,
bei der insbesondere die Wahrscheinlichkeit und Durchführbarkeit potenzieller Angriffe und die
Sensibilität und Quantität der betroffenen Datenbestände zu berücksichtigen sind. Spiegelbildlich
ist der Cloud-Nutzer verpflichtet, ihm vom Cloud-Anbieter zur Verfügung gestellte
Authentisierungsmedien sicher zu verwahren und nicht an Dritte weiterzugeben. Verwendet der
Cloud-Nutzer den Cloud-Dienst, um Daten seiner Kunden zu verarbeiten, so ist er wiederum
seinen Kunden gegenüber vertraglich verpflichtet, einen Cloud-Dienst auszuwählen, der ein
hinreichendes Sicherheitsniveau gewährleistet.

3.3 Deliktsrecht
Pflichten, sowohl des Cloud-Nutzers als auch des Cloud-Anbieters, im Zusammenhang mit dem
Identitätsmanagement können sich auch unabhängig von etwaigen vertraglichen Beziehungen aus
dem Deliktsrecht, also der Haftung für unerlaubte Handlungen, ergeben.15 Dies ist insbesondere
relevant, wenn der Geschädigte eines Angriffs keinen Vertrag mit dem Cloud-Nutzer oder Cloud-
Anbieter geschlossen hat.
Auch im Deliktsrecht stellt sich zunächst das Problem des anwendbaren Rechts.16
Maßgeblicher Anknüpfungspunkt ist insoweit gem. Art. 4 Abs. 1 Rom II-VO der Erfolgsort, also
der Ort, an welchem ein Schaden eingetreten ist. Im Rahmen des Cloud Computing wirft die
Bestimmung des Erfolgsorts erhebliche Probleme auf, da Daten in der Cloud häufig auf
verschiedenen Servern in verschiedenen Ländern gespeichert werden und somit kaum zu
lokalisieren ist, wo ein Schaden tatsächlich eingetreten ist. Insoweit werden in der
rechtswissenschaftlichen Literatur verschiedene Ansätze vertreten. Überzeugend erscheint die
Lösung, auf das Vertragsstatut abzustellen, soweit das Verhältnis zwischen Cloud-Anbieter und
Cloud-Nutzer betroffen ist. In Bezug auf Dritte sollte auf das Recht am gewöhnlichen
Aufenthaltsort des Geschädigten abgestellt werden.
Führen die soeben beschriebenen Grundsätze zur Anwendung deutschen Deliktsrechts,17 so
setzt ein Schadensersatzanspruch des Geschädigten eine Verletzung von absoluten Rechten, etwa
des Eigentums, von Immaterialgüterrechten oder Persönlichkeitsrechten, oder aber die Verletzung
eines Schutzgesetzes, insbesondere die Verletzung strafrechtlicher oder datenschutzrechtlicher
Normen, voraus. Da der Cloud-Anbieter durch die Ansammlung eines Datenbestandes eine
Gefahrenquelle eröffnet, v. a. indem er ein potenzielles Angriffsziel für Kriminelle schafft, ist er
im Wege der sog. Verkehrssicherungspflichten im Rahmen des Zumutbaren dazu verpflichtet, der
Verletzung der soeben genannten Rechtsgüter, auch durch Dritte, vorzubeugen.
Verkehrssicherungspflichten entsprechen in ihrem Inhalt dabei weitgehend den vertraglichen
Schutzpflichten nach § 241 Abs. 2 BGB. Insbesondere erfordern sie die Gewährleistung eines
hinreichenden IT-Sicherheitsniveaus. Weiterhin zu beachten sind die Anforderungen des durch das
IT-Sicherheitsgesetz eingefügten § 13 Abs. 7 TMG.18 Dieser legt Diensteanbietern im Internet, als
welche Cloud-Anbieter in aller Regel zu qualifizieren sind, die Pflicht auf, durch technische und
organisatorische Maßnahmen, welche den Stand der Technik berücksichtigen müssen,
sicherzustellen, dass kein unerlaubter Zugriff auf die von ihnen genutzten technischen
Einrichtungen möglich ist.

3.4 Datenschutzrecht
Weiterhin ist das Datenschutzrecht, welches den Umgang mit personenbezogenen Daten regelt,
Quelle von Pflichten im Rahmen des Identitätsmanagements.19 Auch hier stellt sich zunächst mit
besonderer Dringlichkeit die Frage nach dem anwendbaren Recht.20 Der EuGH hat die
Anwendbarkeit europäischen Datenschutzrechts und damit auch des deutschen BDSG auf
Unternehmen mit Sitz in Drittstaaten mit seiner Entscheidung zu Google Spain von 2014 gegenüber
dem früheren Verständnis erheblich ausgeweitet, was auch und gerade für Anbieter von Cloud-
Diensten von besonderer Bedeutung ist. Abzustellen ist maßgeblich darauf, ob das
datenverarbeitende Unternehmen über eine Niederlassung innerhalb Deutschlands verfügt. Dabei
wird die Anwendbarkeit des BDSG grundsätzlich bereits dann begründet, wenn die
Datenverarbeitung durch die Stelle im Drittstaat im Rahmen der Tätigkeiten der deutschen
Niederlassung erfolgt, eine Datenverarbeitung durch die Niederlassung selbst ist dagegen nicht
erforderlich. Erbringt die deutsche Niederlassung etwa ausschließlich Werbetätigkeiten, die mit
der Datenverarbeitung im Drittstaat jedoch in einem sachlichen Zusammenhang stehen, sind die
Vorgaben deutschen Datenschutzrechts zu beachten. Verfügt die datenverarbeitende Stelle über
keine Niederlassung im Inland, ist das BDSG gleichwohl anwendbar, wenn eine Erhebung,
Verarbeitung oder Nutzung von Daten in Deutschland stattfindet.
Cloud Computing erfolgt im Regelfall im Rahmen einer sog. Auftragsdatenverarbeitung i.S.d.
§ 11 BDSG bzw. Auftragsverarbeitung i.S.d. Art. 28 DSGVO mit Beginn der Geltung der
Datenschutz-Grundverordnung am 25. Mai 2018.21 In dieser Konstellation tritt der Cloud-Nutzer
als verantwortliche Stelle und somit als primärer Adressat datenschutzrechtlicher Pflichten auf.
Die Datenverarbeitung des Cloud-Anbieters wird dem Cloud-Nutzer dabei als eigene zugerechnet.
Der Cloud-Anbieter bleibt nach § 11 Abs. 4 BDSG jedoch unmittelbarer Adressat der in § 9
BDSG geregelten Anforderungen in Bezug auf technisch-organisatorische Maßnahmen zum Schutz
personenbezogener Daten. Für das Identitätsmanagement sind hier insbesondere die Aspekte der
Zutritts-, Zugangs- und Zugriffskontrolle (Anlage zu § 9 BDSG) relevant. Der Cloud-Nutzer ist
verpflichtet, einen Cloud-Anbieter auszuwählen, der die Gewähr bietet, diesen Pflichten
nachkommen zu können und die Einhaltung dieser Pflichten regelmäßig zu überwachen. In der
Praxis kann dieser Pflicht insbesondere durch das Einsehen von entsprechenden Zertifikaten des
Cloud-Anbieters nachgekommen werden. Hat der Cloud-Anbieter seinen Sitz außerhalb von
EU/EWR, besteht nach jedenfalls bisher herrschender Auffassung nicht die Möglichkeit einer
Auftragsdatenverarbeitung. In diesem Fall ist nicht nur der Cloud-Nutzer, sondern auch der Cloud-
Anbieter verantwortliche Stelle und somit unmittelbarer Adressat sämtlicher
datenschutzrechtlicher Anforderungen. Zudem bedarf die Übermittlung personenbezogener Daten
vom Cloud-Nutzer an den Cloud-Anbieter einer gesetzlichen Ermächtigung oder einer
Einwilligung der Betroffenen.

3.5 Branchenspezifische und strafrechtliche Aspekte


Im Kontext der Kreditwirtschaft enthält der neu geschaffene § 25b KWG die Vorgabe, dass
Kreditinstitute bei der Auslagerung von Prozessen angemessene Maßnahmen zu treffen haben, um
die Entstehung zusätzlicher Risiken einzudämmen.22 Die Auslagerung im Wege des Cloud
Computing darf die ordnungsgemäße Geschäftsorganisation des Instituts folglich im Ergebnis nicht
beeinflussen. Im Wesentlichen erfordert dies die Gewährleistung eines angemessenen und
wirksamen Risikomanagements und die Einräumung umfassender Weisungs- und Kontrollrechte
durch ein vertragliches Regelungswerk. Für den Versicherungssektor besteht eine vergleichbare
Vorschrift in § 64a Abs. 4 VAG.
Besondere Schwierigkeiten bereitet das Cloud Computing durch Sozialversicherungsträger.23
Nach § 80 Abs. 5 Nr. 2 S. 2 SGB X muss der überwiegende Teil der „Speicherung des gesamten
Datenbestandes“ grundsätzlich beim öffentlich-rechtlichen Auftraggeber verbleiben. Dies schränkt
Praktikabilität und Nutzen einer Cloud-Lösung erheblich ein.
Strafrechtlich ist § 203 StGB, der für bestimmte Berufsgruppen, etwa Ärzte, die Offenbarung
von Geheimnissen unter Strafe stellt, zu beachten.24 Insoweit wurde bislang vertreten, dass die
Weitergabe von entsprechenden Daten an den Cloud-Anbieter den Tatbestand dieser Norm erfüllt.
In der Rechtswissenschaft wurden hierzu verschiedene Lösungsansätze diskutiert, wie die
restriktive Auslegung des Tatbestands, die Verschlüsselung der Daten oder eine Änderung der
entsprechenden Berufsordnungen. Bei allen Ansätzen ist indes äußerst zweifelhaft, ob diese die
Strafbarkeit tatsächlich suspendieren können.
Die Neuregelung des § 203 StGB soll das Problem lösen.25 Seit ihrem in Kraft Treten am
09.11.2017 ist die Nutzung von Cloud Computing jedenfalls nicht mehr grundlegend von
Rechtsunsicherheit bedroht. Die Nutzung von Cloud Computing ist danach jedoch lediglich dann
legal, wenn sie „erforderlich“ ist. Damit trägt der einzelne Berufsgeheimnisträger weiterhin das
Risiko, dass die Nutzung einer Cloud insgesamt oder hinsichtlich ihrer technischen Ausgestaltung
als nicht erforderlich eingestuft wird.

3.6 Beweisrecht
Der Einsatz bestimmter Technologien im Rahmen des Identitätsmanagements hat auch
beweisrechtliche Konsequenzen.26 Insoweit stellt sich insbesondere die Frage, ob auf das Institut
des Anscheinsbeweises zurückgegriffen werden kann.27 Der Anscheinsbeweis ermöglicht in
bestimmen Fällen Beweiserleichterungen zugunsten einer Partei. So kann im Wege des
Anscheinsbeweises aufgrund von nach der Lebenserfahrung typischen Geschehensabläufen vom
Vorliegen bestimmter Tatsachen auf das Vorliegen eines Geschehensablaufes geschlossen werden.
Ein solcher Anscheinsbeweis wird etwa im Banksektor hinsichtlich der Autorisierung eines
Abbuchungsvorgangs angenommen. Kam eine EC-Karte mit korrekter PIN zum Einsatz, so spricht
ein Anscheinsbeweis dafür, dass die Abbuchung durch den berechtigten Karteninhaber
vorgenommen wurde oder dieser seine Sorgfaltspflichten im Umgang mit der Karte verletzt hat.
Derartige Beweiserleichterungen kommen auch im Rahmen der Online-Identifizierung in Betracht.

4 Quantitative Entscheidungsunterstützung für ein sicheres


Identitäts- und Zugriffsmanagement
Ein wesentliches Teilergebnis dieser Untersuchung ist ein Modell zur Entscheidungsunterstützung
bei der Frage nach den im Rahmen des Identitätsmanagements zu ergreifenden Maßnahmen. Dies
erfordert eine ganzheitliche Berücksichtigung aller Einflussfaktoren und deren Auswirkungen auf
die Sicherheit des Gesamtsystems. Aufgrund der Komplexität der Problemstellung wurde zunächst
die Entscheidungssituation strukturiert und so eine Grundlage für detaillierte quantitative
Auswertungen geschaffen.28

4.1 Problemstellung und Entscheidungssituation


Das Identitäts- und Zugriffsmanagement im Cloud Computing ist durch eine Vielzahl
verschiedener technischer Alternativen gekennzeichnet. In der Praxis werden je nach
Einsatzszenario und Anwendungsfall unterschiedliche Maßnahmen zum Schutz vor unberechtigtem
Zugriff umgesetzt.29 Dies können technische Maßnahmen sein, wie Hardware Token, digitale
Zertifikate, Verbindungsverschlüsselung, Passwortrichtlinien oder auch organisatorische
Maßnahmen, wie Schulungen zur Stärkung der „Awareness“ im Zusammenhang mit nicht
technischen Angriffen. Oft wird bei der Auswahl nicht ausreichend berücksichtigt, welche
Schäden so verhindert werden können und welche Maßnahmen im konkreten Einsatzszenario
angemessen sind.
Die Auswahl von Sicherheitsmaßnahmen im Rahmen des Identitäts- und Zugriffsmanagements
sollte auf Grundlage der jeweiligen Gefährdungssituation und der potenziellen wirtschaftlichen
Konsequenzen von Schadensfällen erfolgen. Es ist also einerseits eine Analyse von externen
sowie internen Gefahren30 sowie andererseits eine Bewertung der Unternehmens-Assets31 zur
Abschätzung möglicher Schäden notwendig. Beide Analysen produzieren für den Zweck der
Entscheidungsunterstützung quantitative Größen, welche in ein Modell einfließen können.
Grundsätzlich ist es je nach Anwendungsfall möglich, dass die Daten relativ genau (z. B. auf
Grundlage historischer Daten) oder eher vage (z. B. durch Expertenschätzungen) bestimmt
werden. Um mögliche Abweichungen von realen Ausprägungen und die hohe Unsicherheit
externer Einflüsse im Bereich der IT-Sicherheit geeignet zu berücksichtigen, wurde eine vage
Bewertungsskala zur Parametererfassung gewählt.32
Wird IT-Sicherheit nicht isoliert und zweckgebunden betrachtet, reicht es im Hinblick auf die
Wirtschaftlichkeit eines Unternehmens nicht aus, nur das erreichte Sicherheitsniveau zu ermitteln.
Eine erhöhte Sicherheit bedeutet in der Regel auch größere Investitionen bzw. Kosten für
entsprechende Maßnahmen. Bei der Auswahl optimaler Maßnahmenkombinationen und dem
Vergleich von Alternativen sollte daher neben der Bestimmung des erreichten Sicherheitsniveaus
auch eine Abwägung der hierzu erforderlichen Kosten erfolgen.33
Basierend auf den in den obigen Ausführungen dargestellten Erkenntnissen wurden mehrere
technische Maßnahmenalternativen vorgeschlagen, welche sowohl einzeln als auch in
Kombination eingesetzt werden können (Ein-Faktor-und Zwei-Faktor-Authentifizierung).
Außerdem wurden weitere nicht-technische Maßnahmen ermittelt, welche die Gesamtsicherheit
zusätzlich abrunden. Für die Modellierung wurden zudem die jeweiligen Abhängigkeiten
(Kompatibilität und Inkompatibilität) von Maßnahmen ermittelt.34

4.2 Modellstruktur
Die Auswirkung eines Sicherheitsvorfalls kann immer auf ein bestimmtes Asset zurückgeführt
werden.35 Ein Asset ist üblicherweise eine technische Komponente, die für ein Unternehmen einen
gewissen Wert hat (z. B. eine Datenbank bzw. die enthaltenen Daten). Die Sicherheit jedes Assets
ist durch verschiedene Schutzziele gekennzeichnet. Es wird zwischen den Schutzzielen
Vertraulichkeit, Integrität und Verfügbarkeit unterschieden. Vertraulichkeit bedeutet, dass Daten
nicht öffentlich bekannt werden dürfen. Bei Integrität ist es möglich, dass Daten öffentlich sind, es
ist jedoch entscheidend, dass diese Daten nicht verändert werden. Die Verfügbarkeit zielt darauf
ab, dass Daten jederzeit abgerufen werden können, also stets verfügbar sind. Diese Schutzziele
können sowohl einzeln als auch in Kombination vorliegen und sind für jedes Asset getrennt zu
ermitteln.
Assets werden von Gefahren bedroht, welche durch Schwachstellen im System zu
Sicherheitsvorfällen führen können. Es können unterschiedlichste Gefahren vorliegen, welche die
Assets und deren Schutzziele unterschiedlich stark bedrohen. Um die Bedrohung durch Gefahren
abzuschwächen, können Sicherheitsmaßnahmen umgesetzt werden. Durch Sicherheitsmaßnahmen
wird die Bedrohung durch bestimmte Gefahren reduziert und damit die Einhaltung der Schutzziele
entsprechender Assets sichergestellt. Je nach Maßnahme können verschiedene Gefahren
unterschiedlich effektiv abgeschwächt werden.

4.3 Modellimplementierung und Auswertung


Das entwickelte Optimierungsmodell wurde mithilfe der Standardsoftware Xpress Optimization
Suite implementiert. Zur Optimierung wird das mmxslp Solver-Modul zur Lösung nichtlinearer
Optimierungsprobleme eingesetzt. Die benötigten Daten werden über ein eigens implementiertes
Tool in einem Webbrowser erfasst und in einer SQLite-Datenbank gespeichert.
Unter Verwendung des implementierten Entscheidungsunterstützungssystems wurde eine
umfangreiche Analyse durchgeführt. Dazu wurden zu den fünf definierten Anwendungsszenarien
(IT-Outsourcing mittelständischer Unternehmen, Kreditwirtschaft, Sozialleistungsträger,
Berufsgeheimnisträger und Verbraucher)36 zunächst quantitative Größen entsprechend der
Modellelemente ermittelt.37 Dazu zählen unter anderem eine Bewertung der jeweiligen Assets, die
Anzahl der Nutzer des Systems und die unterschiedlichen Gefährdungslagen. Da eine exakte
Bewertung nicht durchgängig möglich ist, wurden vordefinierte Skalen zur Quantifizierung
verwendet. Dies hat den Vorteil, dass der Aufwand bei der Bestimmung der Parameter gering
gehalten werden kann, eine Entscheidung durch klar abgegrenzte Skalenwerte aber dennoch
möglich ist. Dass dieses Vorgehen geeignet ist und zu guten Ergebnissen führt, konnte in einer
aktuellen Veröffentlichung38 gezeigt werden.
Zusätzlich zu den fünf Anwendungsszenarien wurden mehrere Budgetszenarien entwickelt.39
Ein Budgetszenario (BS) definiert für verschiedene Kostengrößen maximale Budgets, welche bei
der Optimierung eingehalten werden müssen. Da grundsätzlich viele verschiedene
Maßnahmenkombinationen möglich sind, ist es sinnvoll, die Analyse auf einige wenige, aber
repräsentative Budgetszenarien zu begrenzen. Die definierten Budgetszenarien geben jeweils
folgende Budgetgrenzen für Unternehmen und Kunden vor:
BS 1: Unternehmen: sehr hohes Budget, Kunden: sehr hohes Budget
BS 2: Unternehmen: mittleres Budget, Kunden: mittleres Budget
BS 3: Unternehmen: eher geringes Budget, Kunden: geringes Budget
BS 4: Unternehmen: hohes Budget, Kunden: geringes Budget
Für jedes dieser Szenarien wurden optimale Maßnahmenempfehlungen sowie alternative
Maßnahmenvorschläge ermittelt.40 Dabei ergeben sich für die verschiedenen Anwendungs- und
Budgetszenarien unterschiedliche Ergebnisse. Auffällig ist, dass die in der Praxis verbreitete
Authentifizierung mittels einer Ein-Faktor-Authentifizierung aus ökonomischer Sicht nur äußerst
selten geboten ist. Zumindest eine vergleichsweise schwache Zwei-Faktor-Authentifizierung unter
Nutzung von E-Mail TAN ist in aller Regel ökonomisch umsetzbar. Sofern hohe Budgets zur
Verfügung stehen oder ein besonders hoher Schutzbedarf gegeben ist, sollte auf vergleichsweise
sichere Methoden der Zwei-Faktor-Authentifizierung, wie Hardware OTP Token, zurückgegriffen
werden.

5 Konkretisierung rechtlicher Anforderungen an das


Identitätsmanagement im Cloud Computing
5.1 Überblick
Oben wurde beschrieben,41 aus welchen rechtlichen Grundlagen sich Anforderungen an die IT-
Sicherheit im Allgemeinen und das Identitätsmanagement im Besonderen ergeben. Im weiteren
Verlauf wurden diese unter Berücksichtigung der optimalen Maßnahmenempfehlungen
konkretisiert.42

5.2 Anforderungen an den Cloud-Anbieter


Aus Vertrags-, Delikts-, Datenschutz- und Telemedienrecht ergeben sich für den Cloud-Anbieter
zunächst allgemeine Anforderungen an die IT-Sicherheit.43 So muss der Cloud-Anbieter etwa eine
Firewall und eine Antivirensoftware einrichten sowie eine Verschlüsselungstechnik, ein
Monitoring-System und eine sachgerechte Notfallstrategie implementieren.44 Welche konkreten
Maßnahmen darüber hinaus erforderlich sind, etwa Sicherheitskontrollen am Serverstandort, kann
nur in Abhängigkeit vom jeweiligen Nutzungsszenario beurteilt werden.
Einen Schwerpunkt der Untersuchung stellte die Frage dar, inwieweit der Cloud-Anbieter zur
Implementierung hinreichend sicherer Authentifizierungssysteme verpflichtet ist.45 Insoweit hat
sich ergeben, dass im Grundsatz sowohl vertragliche als auch deliktische Pflichten zur
Implementierung bestehen. Die allgemeinen vertraglichen und deliktischen Grundsätze werden
dabei von Spezialvorschriften beeinflusst, maßgeblich § 9 BDSG sowie dem durch das IT-
Sicherheitsgesetz neu eingeführten § 13 Abs. 7 TMG. Wie bei den sonstigen Anforderungen an die
IT-Sicherheit gilt aber auch bei Authentifizierungssystemen, dass sich pauschale Aussagen
bezüglichen des erforderlichen Schutzniveaus verbieten. Vielmehr ist eine Abwägung nach
unterschiedlichen Schutzbedürfnissen angezeigt.
Die Untersuchung zeigt zunächst auf, anhand welcher Kriterien Cloud-Anbieter im Einzelfall
feststellen können, welcher Schutzbedarf besteht. Ausgehend von bisherigen Ansätzen in Theorie
und Praxis kann hier je nach Anwendungsszenario zwischen verschiedenen Stufen des
Schutzbedarfs unterschieden werden.46 Entscheidende Bedeutung bei der Ermittlung des
Schutzbedarfs kommt dabei der Sensibilität der verarbeiteten Daten sowie der Missbrauchsgefahr
im konkreten Anwendungsfall zu. Insbesondere wenn es in der Vergangenheit in vergleichbaren
Fällen bereits zu Missbrauchsfällen kam, ist von einem gesteigerten Schutzbedürfnis auszugehen.
Sodann galt zu untersuchen, welche konkreten Maßnahmen je nach Schutzbedarf getroffen
werden müssen. Insoweit wurden die in den verschiedenen Budgetszenarien aus ökonomischer
Sicht empfohlenen Anforderungen einer rechtlichen Prüfung unterworfen.47 Diskrepanzen
zwischen ökonomischem Ideal und rechtlicher Gebotenheit traten dabei dann auf, wenn hoher
Schutzbedarf mit niedrigem Unternehmensbudget zusammentraf. Hier setzt insbesondere das
Datenschutzrecht Mindeststandards: Soweit personenbezogene Daten verarbeitet werden, darf ein
angemessenes Sicherheitsniveau nicht unterschritten werden. Dies gilt unabhängig von der
finanziellen Situation des Cloud-Anbieters. Bei sensiblen personenbezogenen Daten muss daher
eine Zwei-Faktor-Authentifizierung entsprechender Sicherheit genutzt werden. Soweit keine
sensiblen Daten verarbeitet werden, ist hingegen auch die tradierte Authentifizierung mittels
Abgleich von Nutzername und Passwort zulässig. Auch abseits des Datenschutzrechts wird es dem
Anbieter eines Cloud-Dienstes allerdings zuzumuten sein, hinreichend sichere Verfahren
zumindest anzubieten und auf die Gefahren der Nutzung von Verfahren wie Nutzername/Passwort
hinzuweisen.

5.3 Anforderungen an den Cloud-Nutzer


Neben dem Cloud-Anbieter ist auch der Cloud-Nutzer Adressat rechtlicher Anforderungen in
Bezug auf das Identitätsmanagement.48 Diesen treffen, unabhängig davon, ob er Verbraucher oder
Unternehmer ist, gewisse organisatorische Pflichten, wie die Verwendung eines aktuellen
Virenschutzes oder einer Firewall. Konkret in Bezug auf das Identitätsmanagement ist der Cloud-
Nutzer, sofern er personenbezogene Daten Dritter verarbeitet, dazu verpflichtet, ausschließlich
Cloud-Dienstleistungen zu nutzen, die ein für seine Situation angemessenes
Authentifizierungsverfahren implementiert haben. Gleiches gilt, soweit die Daten nicht
personenbezogen sind, aber aus anderen Gründen, etwa hoher wirtschaftlicher Bedeutung, eine
vergleibare Sensibilität aufweisen.
Schließlich wurde untersucht, inwiefern es zulässig ist, vertragliche Pflichten des Cloud-
Nutzers in AGB zu konkretisieren.49 Möglich ist vor allem eine Konkretisierung der
Geheimhaltungspflichten des Nutzers in Bezug auf die Authentifizierungsmedien. Bezüglich der
Vereinbarungen von Haftungsbeschränkungen bestehen jedoch enge rechtliche Grenzen,
insbesondere darf die Haftung für Vorsatz, grob fahrlässiges Verhalten und Verletzungen von
Leben, Körper und Gesundheit nicht eingeschränkt werden. Darüber hinaus dürfen durch einen
Haftungsausschluss für einfache Fahrlässigkeit keine vertragswesentlichen Rechtspositionen des
Nutzers ausgehöhlt werden.

5.4 Branchenspezifische Anforderungen


Je nach Branche des Cloud-Anbieters hat dieser noch weiter gehende branchenspezifische
Anforderungen zu beachten.50 Zu nennen sind hier insbesondere die Kreditwirtschaft,
Sozialversicherungsträger und Berufsgeheimnisträger. Bezogen auf die IT-Sicherheit ergeben sich
insoweit im Grundsatz keine abweichenden Ergebnisse. Die branchenspezifischen Anforderungen
implizieren jedoch das Bestehen eines hohen Schutzbedarfs, sodass regelmäßig eine sichere
Zwei-Faktor-Authentifizierung eingesetzt werden muss.

5.5 Beweisrechtliche Aspekte


Beweisrechtlich ist insbesondere relevant, ob die Verwendung eines nutzerbezogenen
Authentisierungsverfahrens einen Anscheinsbeweis dahingehend zu begründen vermag, dass auch
tatsächlich der dahinterstehende Nutzer die Handlung vorgenommen bzw. zumindest eigens
ermöglicht hat.51 Im Falle der Authentisierung mit Nutzername/Passwort wird das Eingreifen eines
Anscheinsbeweises zugunsten einer berechtigten Nutzung indes überwiegend abgelehnt. So
bestehe aufgrund der zahlreichen Missbrauchsmöglichkeiten kein allgemeingültiger
Erfahrungssatz, dass derjenige, der unter einem lediglich passwortgeschützten Nutzerkonto
eingeloggt ist, auch tatsächlich der Inhaber dieses Kontos ist. Eine andere Beurteilung kann sich
nach dem Verständnis dieser Auffassung bei solchen Maßnahmen ergeben, welche gegenüber
Nutzername/Passwort ein deutlich erhöhtes Sicherheitsniveau aufweisen.
Fußnoten
1 Kap.​ 3, 3 und 4.

2 Kap.​ 2, 4.

3 Kap.​ 2, 5.

4 Vgl. nur diese Meldungen vom 25.04.2016 und 10.02.2017, abrufbar unter https://​www.​heise.​de/​mac-and-i/​meldung/​Apple-ID-
und-iCloud-Gezieltes-Phishing-mit-Textnachricht-3183878.​html und https://​www.​pcspezialist.​de/​blog/​2017/​02/​10/​apple-icloud-
zugriff/​ (zuletzt abgerufen am 18.12.2017).

5 Kap.​ 3, 2.

6 Kap.​ 3, 3.

7 Kap.​ 3, 3.​1.

8 Siehe zur Methode Kap.​ 5, 2.​3.​1.​4.

9 „Application programming interface“.

10 Kap.​ 3, 3.​5.

11 Vgl. Kap.​ 4, 2.​1.

12 Siehe hierzu Kap.​ 4, 2.​1.​1.

13 Verordnung (EG) Nr. 593/2008 des Europäischen Parlaments und des Rates vom 17. Juni 2008 über das auf vertragliche
Schuldverhältnisse anzuwendende Recht.
14 Vgl. Kap.​ 4, 2.​1.​3 und 2.​1.​4. sowie Kap.​ 6, 2.​1.

15 Vgl. Kap.​ 4, 2.​2.

16 Siehe hierzu Kap.​ 4, 2.​2.​1.

17 Vgl. hierzu ausführlich Kap.​ 4, 2.​2.​2 und 2.​2.​3 sowie Kap.​ 6, 2.​1.

18 Siehe Kap.​ 4, 3.​2 und Kap.​ 6, 2.​1.​1.​1.​1.

19 Vgl. Kap.​ 4, 5.

20 Siehe hierzu Kap.​ 4, 5.​2.

21 Siehe hierzu ausführlich Kap.​ 4, 5.​4 und Kap.​ 6, 2.​2.

22 Siehe hierzu Kap.​ 4, 6.​1 und Kap.​ 6, 3.​1.

23 Vgl. dazu Kap.​ 4, 6.​2 und Kap.​ 6, 3.​2.

24 Vgl. Kap.​ 4, 7 und Kap.​ 6, 5.​4.

25 Siehe hierzu Kap.​ 4, 7.​4.

26 Siehe Kap.​ 4, 6.​3 und Kap.​ 6, 6.​2.

27 Vgl. Kap.​ 4, 6.​3.​2.​2.


28 Siehe Kap.​ 5.

29 Siehe Kap.​ 3, 4.

30 Siehe Kap.​ 5, 2.​3.

31 Siehe Kap.​ 5, 2.​2.

32 Siehe Kap.​ 5, 2.​1.

33 Siehe Kap.​ 5, 3.

34 Siehe Kap.​ 5, 3.​4.

35 Siehe hierzu ausführlich Kap.​ 5, 2.​2.

36 Vgl. Kap.​ 2, 2.​1.

37 Siehe Kap.​ 5, 2.​2, 2.​3, 2.​4.

38 Schilling/Werners (2015), S. 10 ff. (siehe das Literaturverzeichnis zu Kap.​ 5).

39 Siehe Kap.​ 5, 3.​3.

40 Siehe Kap.​ 5, 3.​4.

41 Siehe Kap.​ 4.
42 Siehe Kap.​ 6.

43 Siehe Kap.​ 6, 2.​1.​1.

44 Siehe Kap.​ 6, 2.​1.​1.​2.

45 Siehe Kap.​ 6, 2.​1.​1.​1.

46 Siehe Kap.​ 6, 2.​1.​1.​1.​1.​3.

47 Siehe Kap.​ 6, 5.

48 Siehe Kap.​ 6, 2.​1.​2.

49 Siehe Kap.​ 4, 2.​1.​5 und Kap.​ 6, 2.​1.​3.​2.

50 Siehe Kap.​ 6, 3.

51 Siehe Kap.​ 6, 6.​2.