Upload
ngohuong
View
214
Download
0
Embed Size (px)
Citation preview
Mit
teil
un
gen
A
usg
abe
94 |
Dez
emb
er 2
018
mitteilungen
Deutsches Forschungsnetz | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | www.dfn.de
#love2eduroamVom zarten Pfl änzchen zum Mammutbaum
DFN-AAI in der PraxisCampus Single Sign-On
leichtgemacht
20 Jahre Forschungsstelle RechtFragen ohne Ende
Impressum
Herausgeber: Verein zur Förderung
eines Deutschen Forschungsnetzes e. V.
DFN-Verein
Alexanderplatz 1, 10178 Berlin
Tel.: 030 - 88 42 99 - 0
Fax: 030 - 88 42 99 - 370
Mail: [email protected]
Web: www.dfn.de
ISSN 0177-6894
Redaktion: Nina Bark, Maimona Id
Gestaltung: Labor3 | www.labor3.com
Druck: Druckerei Rüss, Potsdam
© DFN-Verein 12/2018
Fotonachweis:
Titelfoto: Renate Schildheuer / Offenbach
Seite 6/7 © rcaucino / photocase.de
Seite 42/43 © imamember / iStock
3DFN Mitteilungen Ausgabe 94 |
Erstklassige Forschung und Digitalisierung gehen miteinander einher. Was jedoch bedeutet Digi-
talisierung und welche Konzepte sind mit ihr gemeinsam zu denken? Aus der ständigen Weiter-
entwicklung der Datentechnik und der Vernetzung folgt die Notwendigkeit einer andauernden
Anpassung der vielfältigen rechtlichen Anforderungen und einer Ausdifferenzierung in der Recht-
sprechung. Diese komplexen Vorgaben fest im Blick zu haben, ist für die Hochschullandschaft un-
erlässlich. Um die künftigen rechtlichen Rahmenbedingungen aktiv mitgestalten zu können, hat
insbesondere die vorausschauende Begleitung von Gesetzesvorhaben große Bedeutung.
Durch die Einrichtung der Forschungsstelle Recht vor 20 Jahren wurde ein bedeutender Grundstein
gelegt, die notwendigen Prozesse zur Lösung der aufgeworfenen Rechtsprobleme zu bündeln, die
Ergebnisse zu publizieren und gezielt dazu beizutragen, dass relevante Fragestellungen öffentlich
diskutiert werden. Heute ist die Forschungsstelle Recht nicht nur unverzichtbarer Bestandteil des
DFN-Vereins, sondern auch verlässlicher Experte für Gesetzgebungsverfahren des Bundes. Der DFN-
Verein und seine Mitgliedseinrichtungen können sich auf ihre Kernthemen fokussieren, rechtliche
Fragen in Bezug auf die Nutzung des Deutschen Forschungsnetzes (DFN) an eine zentrale Anlauf-
stelle richten und die gut begründeten Empfehlungen der Forschungsstelle Recht deutschlandweit
auf gleichem Niveau umsetzen. Die Interaktion und Kommunikation zwischen den Stakeholdern des
DFN-Vereins kann damit im Mittelpunkt bleiben und erstklassige Forschung unterstützen – wäh-
rend die Regeln zur Verwendung des DFN-Vereins durch die Forschungsstelle Recht für alle Nutzer
des DFN gewinnbringend im Blick behalten und gestaltet werden.
Auch die künftige Entwicklung des DFN als rechnergestütztes Kommunikations- und Informa-
tionssystem für die öffentlich geförderte Forschung und Lehre kann durch die Forschungsstel-
le Recht rechtlich flankiert werden. Seien es Konzepte zur innovationsfreundlichen Gestaltung
bestehender Nutzungsbedingungen und Benutzungsordnungen, Klärung von Fragen zur rechts-
verträglichen Gestaltung technischer Maßnahmen bis hin zur Minimierung haftungsrechtlicher
Risiken des DFN-Vereins.
Es soll der bestmögliche Rechtsrahmen für Anwender des DFN sichergestellt werden – und dies
auch in 20 Jahren. Die Bedeutung der Forschungsstelle Recht für die Mitgliedseinrichtungen des
DFN-Vereins wird künftig mit den wachsenden Herausforderungen der Digitalisierung weiter zu-
nehmen.
Daher gilt an dieser Stelle all jenen, die an der Schaffung (und Unterstützung) der Forschungs-
stelle Recht an der Universität Münster beteiligt waren, mein Dank für die in den vergangen 20
Jahren geleistete Arbeit.
Christian Zens
Christian Zens
Kanzler an der
Friedrich-Alexander-Universität
Erlangen-Nürnberg
Stellvertretender
Vorstandsvorsitzender
im DFN-Verein
4 | DFN Mitteilungen Ausgabe 94 | Dezember 2018
4
8 10
12
16
13 15
17 19
14
2
6
11
18 20 21
3 5
7
1
9
Unsere Autoren dieser Ausgabe im Überblick
1 Ralf Paffrath, DFN-Verein ([email protected]); 2 Maimona Id, DFN-Verein ([email protected]); 3 Dr. Jakob Tendel,
DFN-Verein ([email protected]); 4 Nina Bark, DFN-Verein ([email protected]); 5 Dustin Frisch, Hochschule Fulda
([email protected]); 6 Sven Reißmann, Hochschule Fulda ([email protected]);
7 Christian Pape, Hochschule Fulda ([email protected]); 8 Sebastian Rieger,
Hochschule Fulda ([email protected]); o. Abb. Shikha Shahi, atsec information
security GmbH ([email protected]); o. Abb. Matthias Hofherr, atsec information security GmbH
([email protected]); 9 Dr. Silke Meyer, DFN-Verein ([email protected]); o. Abb. Reimer Karlsen-Masur,
DFN-CERT ([email protected]); 10 Heike Ausserfeld,DFN-Verein ([email protected]); 11 Hauke
Heseding, Karlsruher Institut für Technologie, KIT (hauke.heseding@kit edu), 12 Robert Bauer, KIT
(robert.bauer@kit edu); 13 Martina Zitterbart, KIT (zitterbart@kit edu); 14 Steffen Hofmann, FU Berlin
([email protected]); 15 Wolfgang Pempe, DFN-Verein ([email protected]); 16 Annette Rülke,
DFN-Verein ([email protected]); 17 RA Dr. Jan K. Köcher, DFN-CERT ([email protected]); 18 Christine
Legner-Koch, DFN-Verein ([email protected]); 19 Armin Strobel, Forschungsstelle Recht im DFN
5DFN Mitteilungen Ausgabe 94 |
Wissenschaftsnetz
Vom zarten Pflänzchen zum Mammutbaum –
10 Jahre eduroam
von Ralf Paffrath ............................................................................. 8
Campus Edge für Big Data
von Jakob Tendel ............................................................................ 14
Kurzmeldungen ............................................................................ 19
International
BELLA – Eine Brücke für die Wissenschaft
von Nina Bark ................................................................................ 20
Sicherheit
Internet of Things: Sicherheit kein Ding
der Unmöglichkeit
von Dustin Frisch, Sven Reißmann,
Christian Pape, Sebastian Rieger ............................................ 22
Sicherheits-Kennzahlen: So scheitert die
Theorie nicht an der Praxis
von Shikha Shahi, Matthias Hofherr ...................................... 28
Sicherheit aktuell ......................................................................... 32
Campus
SDN Cockpit: Teaching Networks with Networks
von Hauke Heseding, Robert Bauer,
Martina Zitterbart ........................................................................ 33
DFN-AAI lokal Single Sign-On an der
Hochschule leichtgemacht
von Steffen Hofmann, Wolfgang Pempe ............................. 38
Interview
Fragen ohne Ende – 20 Jahre Forschungsstelle
Recht im DFN
Interview mit Thomas Hoeren ................................................. 44
Recht
Das Netz und die Justiz
von Christine Legner-Koch ........................................................ 46
EU-Datenschutz-Grund verordnung – und die
Welt dreht sich weiter
von Jan K. Köcher .......................................................................... 48
Frei – aber nicht grenzenlos!
von Armin Strobel ......................................................................... 52
DFN-Verein
DFN unterwegs ............................................................................. 55
DFN live ............................................................................................ 56
Überblick DFN-Verein ................................................................. 59
Mitgliedereinrichtungen .......................................................... 61
Inhalt
7WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 94 |
WissenschaftsnetzVom zarten Pflänzchen zum Mammutbaum –
10 Jahre eduroam
von Ralf Paffrath
Campus Edge für Big Data
von Jakob Tendel
Kurzmeldungen
8 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | WISSENSCHAFTSNETZ
Vom zarten Pflänzchen zum Mammutbaum – 10 Jahre eduroam
Text: Ralf Paffrath (DFN-Verein)
Frei nach Shakespeare „Wo es Euch beliebt“, titelten die DFN-Mitteilungen im November 2003 im ersten Artikel zum damals neu geplanten Pilotprojekt DFNRoaming. Ziel des Piloten war es, für den reisenden Wissenschaftler einen einfachen und sicheren Netzzugang in das Deut-sche Forschungsnetz zu ermöglichen. Von der Vision eines Roamingdienstes war die Rede – Realität ist es heute. eduroam, die Internationalisierung des Dienstes DFNRoaming, feiert in diesem Jahr sein 10-jähriges Bestehen.
9WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 94 |
„Ich reise viel im Rahmen meiner Arbeit, hauptsächlich zu
akademischen Einrichtungen in ganz Europa, um an
Konferenzen teilzunehmen, Vorträge zu halten oder mich
mit Kooperationspartnern zu treffen. Obwohl mein Job
nichts mit IT, Marketing oder anderen typischen „digitale
Nomaden“-Berufen zu tun hat, fühle ich mich manchmal
wie einer. Mein Büro, der Laptop, ist immer bei mir. edu-
roam ist ein zuverlässiger Begleiter auf meinen Reisen, so-
dass ich meine tägliche Arbeit außerhalb meiner Heimatin-
stitution erledigen kann. Keine langen Anmeldeformulare,
keine multiplen Passwörter, einfach auf Verbinden klicken
und loslegen. Und ein netter Bonus - in Städten wie Valetta
auf Malta, wo sich Universitätsgebäude im Zentrum der
Stadt befinden, kann ich sogar in einem Café in der Nähe
sitzen und meine E-Mails abarbeiten.“
Dr. Luiza Bengtsson, Biochemikerin und Projektkoordinatorin im Open Science Projekt ORION am Max-Delbrück-Centrum für Moleku-lare Medizin in der Helmholtz-Gemeinschaft (MDC)
DFNRoaming – die Suche nach dem Standard
Mit dem Ausbau des Wissenschaftsnetzes,
der Etablierung immer höherer Bandbreiten
und der weltweiten Zunahme von mobilen
Endgeräten wuchs der Wunsch der Mitglied-
seinrichtungen nach einem Roamingdienst
im Wissenschaftsnetz. So wurde die DFN-
Geschäftsstelle durch ein Votum der Mit-
gliederversammlung im Jahr 2003 beauf-
tragt, einen solchen Dienst im Deutschen
Forschungsnetz aufzubauen. Wissenschaft-
ler, die von A nach B reisen, sollten einen
unkomplizierten, sicheren Netzzugang zum
Wissenschaftsnetz erhalten.
Der DFN-Verein ist seit seiner Gründung
im Jahre 1984 in internationale Aktivitäten
und Entwicklungen eingebunden. So hiel-
ten die Strategen in der DFN-Geschäftsstel-
le nicht nur national nach einem geeigne-
ten Verfahren zur Realisierung des Diens-
tes Ausschau. Die Rahmenbedingungen um
einen Roamingdienst im Wissenschafts-
netz erfolgreich zu etablieren waren un-
ter anderem: Skalierbarkeit, Sicherheit und
Robustheit. Es sollte nicht irgendein pro-
prietäres Verfahren zum Einsatz kommen.
Die international agierende Task Force-Mo-
bility (TF-Mobility), eine Gruppe von Exper-
ten aus verschiedenen europäischen For-
schungsnetzen, befasste sich seit gerau-
mer Zeit mit unterschiedlichen Authen-
tifizierungsverfahren. Generell standen
2003 folgende Authentifizierungsverfah-
ren zur Auswahl: IEEE 802.1X, Captive Por-
tal- und VPN-Server Lösung. Captive Por-
tals sind Zugangsverfahren auf der Basis
von WEB-Servern, wie man sie noch heu-
te unter anderem in Hotels vorfindet. Auf-
grund der Skalierbarkeit und Sicherheit
setzte sich sowohl auf internationaler Ebe-
ne als auch im Deutschen Forschungsnetz
das IEEE 802.1X Protokoll durch. Nur mit
dem international standardisierten Pro-
tokoll, eingebunden in eine RADIUS (Re-
mote Authentication Dial-In User Server)
Infrastruktur, konnten alle drei Forderun-
gen nach Skalierbarkeit, Sicherheit und Ro-
bustheit erfüllt werden.
Bestehende Bausteine nutzen
Das Protokoll IEEE 802.1X bietet unter an-
derem zwei Tunnelverfahren: EAP-TTLS
und PEAP. Beide Verfahren ermöglichen
eine passwortgestützte Authentifizierung
der Nutzer. Damit die Passwörter und die
Kennungen sicher übertragen werden kön-
nen, bekommt der RADIUS Server ein Ser-
ver-Zertifikat. Wenn nun die Anfrage ei-
nes eduroam Nutzers beim RADIUS Server
der Heimateinrichtung aufschlägt, antwor-
tet dieser in der Regel mit seinem Server-
Zertifikat, welches unter anderem den öf-
fentlichen Schlüssel des RADIUS Servers
enthält. Der eduroam Supplikant (802.1X
Klientensoftware) verwendet den vom
Radius Server gesendeten öffentlichen
Schlüssel und verschlüsselt damit die edu-
roam Kennung und das Passwort. Bevor der
öffentliche Schlüssel zur Verschlüsselung
der sensiblen Daten (Passwort und Ken-
nung) verwendet wird, muss der RADIUS
Server der Heimateinrichtung verifiziert
werden. Bleibt diese Prüfung aus, kann
der Nutzer nicht sicher sein, welchem
RADIUS Server er seine eduroam Kennung
und Passwort zusendet. Daher muss je-
der eduroam Supplikant so konfiguriert
werden, dass das Server-Zertifikat des RA-
DIUS Servers validiert wird. Um eduroam
sicher zu konfigurieren, muss das Root-
CA-Zertifikat des RADIUS Server-Zertifi-
kats auf dem jeweiligen Gerät installiert
und für das Netzwerkinterface, in der Re-
gel das WLAN, aktiviert sein. Für die Ver-
wendung der Zertifikate konnte die bereits
„Diesen Sommer war ich für längere Zeit in
Cambridge (Massachusetts) und auf dem
Gelände der Harvard University. Da hat mir
eduroam sehr geholfen. Ich musste nur den
Laptop aufklappen und schon hatte ich ein
sicheres Netz. Unkomplizierter geht es
nicht.“
Annette Rülke, Juristin in der DFN-Geschäftsstellein Berlin
Foto
© D
FN
Foto © Anyess von Bock
10 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | WISSENSCHAFTSNETZ
„Als stellvertretender Vorsitzender des DFN-Vereins habe ich
für eduroam kräftig die Werbetrommel gerührt. Mein Credo
war, Kollegen, bitte implementiert eduroam so bald wie mög-
lich, irgendwann wird der Dienst stark nachgefragt. Ich war
jedoch überzeugt, dass eduroam nur funktionieren kann, wenn
es eine kritische Masse erreicht. Zu Beginn war das Projekt ein
ganz zartes Pflänzchen. Ich erinnere mich, dass die Community
der Hochenergiephysiker als erste den Dienst „adoptierte“.
Dann bekam das Pflänzchen eine Eigendynamik. Heute ist es
schon so, dass die Nutzer regelrecht auf die Barrikaden gehen,
wenn eduroam einmal ausfällt. Mein Aha-Erlebnis hatte ich
seinerzeit in Budapest: Ich stand vor der Uni-Bibliothek als
mein Handy in der Hosentasche vibrierte, es hatte WLAN
gefunden. Ich wunderte mich. Als das Gleiche in der Nähe der
juristischen Fakultät passierte, schaute ich nach – und tatsäch-
lich, eduroam war in Europa angekommen.“
Prof. Dr. Bernhard Neumair, geschäftsführender Direktor des Steinbuch Centre for Computing (SCC) und ehemaliger stellvertretender Vorsitzen-der des DFN-Vereins
lange vorher etablierte Public Key Infra-
structure des DFN-Vereins (DFN-PKI) mit-
einbezogen werden. So waren im Grun-
de alle benötigten Bausteine für den Auf-
bau eines Roamingdienstes vorhanden:
• das IEEE 802.1X Protokoll,
• die Idee zum Aufbau einer RADIUS
Infrastruktur
• die DFN-PKI
• und die beiden Tunnelverfahren
EAP-TTLS und PEAP.
DFNRoaming, eine gute Idee ist die eine Sache, Überzeu-gungsarbeit eine andere
Nun hieß es, die Hochschulen und For-
schungseinrichtungen in Deutschland für
dieses gemeinsam verwendete Zugangs-
verfahren zu gewinnen. Der damalige de-
signierte Geschäftsführer Jochem Pattloch
reiste dafür zusammen mit anderen Kol-
legen von einer Mitgliedseinrichtung zur
anderen, um für die Teilnahme am neu ge-
planten Dienst zu werben. Dabei gab es
auch kritische Reaktionen, Fragen nach
dem Mehrwert und der Sicherheit. Auch
Fragen zur technischen Machbarkeit und
zur Aufwandsabschätzung prägten oft die
Gespräche. Für das noch junge Protokoll
IEEE 802.1X gab es in den Jahren 2003 und
2004 wenig Hardware-Implementierungen
und einige Einrichtungen hatten gerade ih-
re Investitionen zum Aufbau eines WLANs
getätigt. Um möglichst viele Einrichtungen
von Anfang an einzubeziehen, bot die DFN-
Geschäftsstelle zusätzlich die sogenann-
ten Captive Portal-/VPN-Server-Verfahren
als Migrationslösungen hin zu IEEE 802.1X
an, da diese zum Teil die gleiche RADIUS Au-
thentifizierungsinfrastruktur nutzten. Im
Rahmen der Migrationslösung wurden „of-
fene“ WLANs angeboten, die durch ein Cap-
tive Portal- oder VPN-Server abgesichert
wurden. Letztendlich gab es jedoch eine
Reihe größerer Einrichtungen, die Interes-
se daran hatten IEEE 802.1X einzusetzen.
In den darauffolgenden Jahren wurden die
Verfahren Captive Portal-/VPN-Server dann
sukzessive zurückgefahren.
Eine Erfolgsgeschichte mit Hindernissen
Am 1. April 2004 fiel dann der Startschuss
für den DFNRoamingdienst im Pilotbe-
trieb. DFNRoaming startete mit fünf Ein-
richtungen, bis Ende 2005 waren es 26
Ein rich tungen.
Bis Ende 2006 kamen nur 14 weitere Einrich-
tungen hinzu, insgesamt nutzten bis Ende
2006 nur 40 Einrichtungen den Dienst. Die
verzögerte Teilnahme lag zum Teil an den
in den Einrichtungen bereits vorhandenen
Lösungen. Aber auch Sicherheitsbedenken
und ein angeblich hoher Aufwand im Auf-
bau einer IEEE 802.1X-Umgebung wurden
als Gründe genannt. Die DFN-Geschäfts-
stelle versuchte mit Schulungen, Konfigu-
rationsbeispielen, Mailinglisten sowie auch
der Bereitstellung von IP-Adressraum die
Einrichtungen zu unterstützen.
Der Dienst wurde von Anfang an in interna-
tionale Aktivitäten eingebunden. So wur-
de für den Dienst DFNRoaming bereits zu
Beginn die SSID eduroam ausgestrahlt. Da-
durch gehörten das deutsche und das nie-
0
100
200
300
400
500
600
700
800
01/05
07/05
01/06
07/06
01/07
07/07
01/08
07/08
01/09
07/09
01/10
07/10
01/11
07/11
01/12
07/12
01/13
07/13
01/14
07/14
01/15
07/15
01/16
07/16
01/17
07/17
Abbildung 1: Einrichtungen in eduroam
Foto © KIT
11WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 94 |
derländische Forschungsnetz (SURFnet) zu
den ersten, die die SSID ausstrahlten.
In den Jahren 2006 und 2007 wurde dann
unter der Beteiligung von Dr. Jürgen Rau-
schen als damaliger Mitarbeiter der DFN-
Geschäftsstelle die eduroam Policy erar-
beitet. Bereits ein Jahr später wurde edu-
roam der offizielle Roamingdienst der eu-
ropäischen Forschungsnetze. Ab diesem
Zeitpunkt nahmen immer mehr deutsche
Einrichtungen und auch weitere europäi-
sche Forschungsnetze an dem Dienst teil.
Aber auch weltweit wurde die europäische
Idee schnell ein großer Erfolg.
DFNRoaming/eduroam richtig konfigurieren, dank Konfigurationsassistenten
Mit dem Ausbau der Mobilfunknetze nahm
auch die Gerätevielfalt in eduroam zu. Wa-
ren es anfangs noch hauptsächlich Lap-
tops, die die Gerätelandschaft des Diens-
tes prägten, kamen in den darauffolgenden
Jahren in zunehmendem Maße Smartpho-
nes und Tablets als neue mobile Endgeräte
hinzu. Um die Nutzer und Administratoren
in der wachsenden, heterogenen Geräte-
Umgebung zu unterstützen und eine einfa-
che und sichere Konfigurationsmöglichkeit
für die gängigen Endgeräte zu schaffen,
wurde 2011 die Konfigurationsplattform
CAT (Configuration Assistent Tool) entwi-
ckelt. Neben der internationalen Konfigu-
rationsplattform cat.eduroam.org unter-
hielt der DFN-Verein eine eigene nationale
Konfigurationsplattform cat.eduroam.de
für seine Mitglieder.
Wie bereits beschrieben, werden eduroam-
Nutzer grundsätzlich in ihrer Heimatein-
richtung authentifiziert. Um die Authen-
tifizierung in der Heimateinrichtung zu
ermöglichen, ist die Konfiguration eines
RADIUS Servers erforderlich. Die meisten
Einrichtungen bieten ihren Nutzern die bei-
den gängigen Tunnelverfahren EAP-TTLS
und PEAP an. Der Konfigurationsassistent
CAT ist ein weiterer Baustein, um eduroam
einfacher und sicherer zu gestalten. Er er-
möglicht den Nutzern die sichere Konfigu-
ration der Root-CA auf den gängigen Be-
triebssystemen. Mithilfe des Konfigurati-
onsassistenten können Administratoren
die Nutzerprofile ihrer eigenen Einrich-
tung anpassen und Nutzer können diese
Profile für die Konfiguration ihrer Geräte
herunterladen.
Mittlerweile wurde der Konfigurationsas-
sistent zur Version zwei weiterentwickelt
und die Verbreitung der DFN-AAI ist wei-
ter gestiegen. Die Authentifizierung- und
Autorisierungs-Infrastruktur des DFN-Ver-
eins wird als Zugangsvoraussetzung für
die internationale Plattform cat.eduroam.
org verwendet. Aufgrund dieser Entwick-
lungen beschloss die DFN-Geschäftsstel-
le im Frühjahr 2018, keinen eigenen Kon-
figurationsassistenten mehr anzubieten
und die Einrichtungen schrittweise durch
eine „sanfte“ Migration zu cat.eduroam.
org umzuziehen.
EoC – Eduroam off Campus
Schon früh wurde erkannt, dass eduroam
auch außerhalb des Einzugsbereichs der
Hochschulen und Forschungseinrichtun-
gen funktionieren kann. In den Jahren nach
2008 startete der DFN-Verein erste Versu-
che, die räumlichen Grenzen von eduroam
zu erweitern. Mehrfach wurde mit den gro-
ßen Internet Service Providern darüber ge-
sprochen, den Dienst auch in den Städten
anzubieten. Ziel war es, den reisenden Wis-
senschaftlern und den Studierenden auch
an öffentlichen Plätzen wie Bibliotheken,
Rathäusern oder Bahnhöfen einen siche-
ren und vertraulichen Dienst anzubieten.
Nachdem die großen Provider sich nicht
für dieses Vorhaben begeistern konnten,
gründete der Verein ZKI (Zentrum für Kom-
munikation und Informationsverarbeitung
e. V.) im Jahr 2011 die Kommission Eduroam
off Campus (EoC). Mit deren Hilfe konnten
kleinere, regionale Provider für die Idee
gewonnen werden. So konnte die Stadt
Ingolstadt, die ein City-Netz plante, An-
fang 2013 für die Idee begeistert werden.
Langsam kamen weitere Standorte hinzu.
2016 konnte der bisher größte Standort
gewonnen werden. Mit der Kooperation
der Initiative BayernWLAN und eduroam
wird die SSID eduroam bis 2020 auf über
40.000 Hotspots im gesamten Bundesland
Bayern ausgestrahlt.
„Glaube versetzt bekanntlich Berge. Im Fall von eduroam
gab es am Anfang die bloße Idee eines akademischen
Roamingdienstes. Jeder in der Community war gefragt,
einen Stein zu bewegen, ohne zu wissen, ob die Mühe sich
am Ende auszahlt. Da ging es um das Vertrauen in die
Zukunftsfähigkeit dieses Dienstes, aber auch um die
Entscheidung jedes Einzelnen, in diese Idee zu investieren
und mit gutem Beispiel voranzugehen. Ausschlaggebend
für den heutigen Erfolg von eduroam ist aus meiner Sicht,
dass von Anfang an nachhaltige Organisationsstrukturen
geschaffen wurden, die heute das Rückgrat des internatio-
nalen Kooperationsprojektes bilden. Wir haben
gemeinsam zehntausende Steine bewegt und erreicht,
dass fast bis in den letzten Winkel der Erde eduroam
genutzt wird. Das zeigt, dass es sich als Gemeinschaft
lohnt, in Vorhaben zu investieren, die ganz klein
beginnen.“
Jochem Pattloch, DFN-Geschäftsführer
Foto © DFN
12 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | WISSENSCHAFTSNETZ
VON DER RADIUS ZUR RADSEC INFRASTRUKTUR
RADIUS (Remote Authentication Dial-In User Server) bezeichnet
ein Client/Server Transport Protokoll für die Authentifizierung,
Autorisierung und das Accounting von Nutzern bei Einwahlver-
bindungen. In eduroam wird das RADIUS Protokoll grundsätzlich
für den Transport von 802.1X-Anfragen verwendet. Die RADIUS
Client/Server sind in einer Hierarchie angeordnet. Zu Beginn des
DFNRoamingdienstes im Jahr 2004 baute der DFN-Verein eine
reine RADIUS Infrastruktur auf, jede Einrichtung konfigurierte
einen RADIUS Client/Server, dieser wurde dann in die RADIUS-
Hierarchie des DFN-Vereins integriert (siehe Abbildung 2).
Damit die RADIUS Client/Server miteinander kommunizieren
durften, mussten sogenannte „Secrets“ ausgetauscht werden.
Die Secrets sind letztendlich Passwörter, die im Klartext in den
RADIUS Client/Server Konfigurationsdateien enthalten sind.
Schnell wurde offensichtlich, dass eine reine RADIUS Client/Ser-
ver In frastruktur einige Probleme mit sich bringt. Zum einen das
Klartext Passwort, welches im günstigsten Fall nur durch die
Admin-Nutzungsrechte auf den RADIUS Client/Server geschützt
ist. Zum anderen offenbarte sich durch den Anstieg der Nutzer-
zahlen und der Anzahl der RADIUS Client/Server, dass manche
Text: Maimona Id (DFN-Verein)
eduroam macht einfach glücklich. Wer kennt es nicht, das warme Gefühl? Unterwegs im Ausland: der Blick auf das Smartphone
oder Laptop und die Gewissheit, eduroam ist zuverlässig mit dabei. Eben wie zuhause. Kein Wunder, denn mit den heimischen
Zugangsdaten haben reisende Wissenschaftler und Studierende die Möglichkeit, vom einfachen, kostenlosen und vor
allem sicheren drahtlosen Zugang in die Wissenschaftsnetze sowohl über die Heimateinrichtung als auch über andere wissen-
schaftliche Einrichtungen zu profitieren. Und das ganz automatisch, ohne zusätzliche Anmeldung oder einen umständlichen
Gast-Account.
Weltweite disziplinübergreifende Kooperationen, zumeist in
großen Forschungskonsortien, nehmen immer mehr zu. Und
auch die Bereitschaft zur Mobilität gehört heute zum norma-
len Arbeitsleben von Wissenschaftlerinnen und Wissenschaft-
lern. Mit dem internationalen akademischen Roamingnetz-
werk eduroam können sie problemlos online arbeiten wo und
wann immer sie wollen. Durch den steten Fortschritt digita-
ler Kommunikations- und Informationstechnologien rückt die
Welt der Wissenschaft immer näher zusammen. Dank der in-
novativen Authentifizierung- und Autorisierungs-Infrastruk-
tur (DFN-AAI) ist das Vertrauen der eduroam-Nutzer auf in ihrer
Heimateinrichtung gespeicherte sensible Daten zuzugreifen,
groß. Echte Alternativen gibt so gut wie keine. Die technischen
Anforderungen, um Besucher mit einem lokalen sicheren In-
ternetzugang zu versorgen, können für Hochschulen und For-
schungseinrichtungen sehr aufwendig sein: Die Bereitstellung
temporärer Accounts für einzelne Personen oder Gäste-WLAN
sind zeitaufwendig und teuer. Ein Vorteil für die Institutio-
nen: Der eduroam-Zugang zum Netz benötigt keinen zusätz-
lichen Support und personelle Ressourcen. In vielen Ländern
ist eduroam längst nicht mehr nur auf Universitätsgelände be-
schränkt. Zahlreiche Hotspots auf Flughäfen oder Bahnhöfe
in Universitätsstädten bieten mittlerweile eduroam als einfa-
chen und skalierbaren Zugangsservice an. In England und in
den Beneluxstaaten werden Dienste ähnlich eduroam zuneh-
mend für den Öffentlichen Dienst genutzt.
Das Aushängeschild der weltweiten National Research and
Education Networks (NRENs) zählt mittlerweile registrierte
Nutzerinnen und Nutzer in 90 Ländern der Erde. Das zentral-
asiatische Tadschikistan ist einer der jüngsten Zugänge. Das
Trans-Eurasian Information Network (TEIN) meldete beispiels-
weise die erfolgreiche Einführung von eduroam in den asiati-
schen Ländern Bhutan, Indonesien, Malaysia, Nepal, Pakistan,
Philippinen und Sri Lanka. Weitere Staaten in der Asien-Pazifik-
Region sollen folgen. Laut dem eduroam-Statistikreport 2017
wurden im vergangenen Jahr 3,6 Milliarden nationale (d. h. in-
nerhalb verschiedener Einrichtungen eines Landes) Authentifi-
zierungen sowie mehr als 834 Millionen internationale (länder-
übergreifende) Authentifizierungen registriert. Das bedeutet
einen Zuwachs von 18 Prozent innerhalb der nationalen Regis-
trierungen sowie 21 Prozent bei den internationalen.
Und so lautet denn das Motto der GÉANT-Kollegen in diesem
Jahr „Share your love of eduroam“. Mit einer groß angeleg-
ten Social Media-Kampagne feiert das europäische Partner-
netzwerk mit den nationalen Wissenschaftsnetzen weltweit
den 10. Geburtstag des ehemals kleinen Dienstes, der heute
zu den erfolgreichsten und bekanntesten Diensten zählt. Un-
ter dem Hashtag #love2eduroam können Nutzer an den WLAN-
Hotspots Fotos von sich posten und so ihre Zugehörigkeit zur
großen eduroam-Community zeigen. Ein Ende der Erfolgsge-
schichte ist nicht in Sicht.
Weitere News zu eduroam finden Sie hier:
https://www.eduroam.org/eduroam -news-2
13WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 94 |
RADIUS Client/Server Software sogenann-
te „timeouts“ produzieren, die dazu füh-
ren, dass 802.1X-Anfragen nicht weiterge-
leitet werden. Dadurch kam es in manchen
Einrichtungen zu Wartezeiten bei der Au-
thentifizierung der Nutzer. In den Jahren
vor 2009 wurde ein neuer Standard, maß-
geblich durch eine Initiative von Stefan
Winter (RESTENA) eingebracht, der dann
2009 durch die IETF ratifiziert wurde. Der
DFN-Verein hatte bereits 2007 damit be-
gonnen den neuen Standard im Dienst
DFNRoaming/eduroam zu erproben. Im
selben Jahr wurde eine „standalone“-
Variante des RadSec Protokolls unter der
Open-Source-Software radsecproxy veröf-
fentlicht. Der radsecproxy verbindet die
beiden Welten „RADIUS over UDP“ mit
„RADIUS over TCP“. Die RADIUS Hierarchie
des Dienstes DFNRoaming/eduroam wur-
de um einen weiteren Baustein ergänzt.
Der bisherige Föderations-RADIUS Client/
Server des DFN-Vereins wurde durch den
radsecproxy Client/Server ausgetauscht.
Einrichtungen konnten nun auf Wunsch
eine abgesicherte TLS-Verbindung von ih-
rer Einrichtung bis hin zum Föderations-
RadSec Client/Server aufbauen. Viele Ad-
ministratoren begrüßten dieses Angebot,
da es nun möglich war, den Instituts-RA-
DIUS Client/Server, der zum Teil über Ba-
ckend-Datenbanken den Zugriff auf per-
sonenbezogene Daten ermöglichte, bes-
ser zu schützen, indem der RADIUS Client/
Server aus der DM-Zone nach „innen“ ins
Produktionsnetz gezogen wurde. Der rad-
secproxy wurde in die DM-Zone gestellt.
Der Einsatz des radsecproxys war nur durch
die DFN-PKI möglich. Die Uplinks von den
radsecproxys in der Einrichtung zu dem Fö-
derations-RadSec Client/Servern wurden
durch DFN-PKI Client/Server Zertifikate
etabliert. Bis Ende 2017 wurde die Anbin-
dung der eduroam Identity Provider über
das RadSec Protokoll für die Einrichtungen
im DFN verpflichtend. Seit dem 1. Januar
2018 verfügt der DFN-Verein als eines von
nur wenigen Forschungsnetzen weltweit
über eine funktionierende RadSec Infra-
struktur in eduroam (siehe Abbildung 3). M
Abbildung 2: schematischer Aufbau der eduroam Infrastruktur 2004
Abbildung 3: schematischer Aufbau der eduroam Infrastruktur 2008 bis 2018
DFN
Föderation RADIUS Server DFN-Verein
EinrichtungRADIUS Server
Konföderation RADIUS Server GEANT
(Kon)föderation RADIUS Server International
eduroam IdP/SPfür internationale/nationale Nutzer
Einrichtung RADIUS Server
Auth-Path: RADIUS over UDP, abgesichert mit Secret im Klartext
Netzverkehr authentifi-zierter eduroam Nutzer
WlanController/AP
Protokolle: EAP-TTLS/PEAP, etc.
SmartPhone, Tablet, LaptopAnmeldung mittels Realm: @einrichtung.de
DFN
Föderation RadSec Client/Server DFN-Verein
EinrichtungRADIUS Server
Einrichtung RadSec Client/Server
Konföderation RADIUS/RadSec Client/Server GEANT
(Kon)föderation RADIUS/RadSec Client/Server International
eduroam IdP/SPfür internationale/nationale Nutzer
Einrichtung RADIUS Server
…
…
…
Einrichtung RadSec Client/Server
Auth-Path: RADIUS over UDP, abgesichert mit Secret im Klartext
Netzverkehr authentifi-zierter eduroam Nutzer
WlanController/APProtokolle: EAP-TTLS/PEAP, etc.
Auth-Path: RADIUS over TCP, TLS abgesichert
SmartPhone, Tablet, LaptopAnmeldung mittels Realm: @einrichtung.de
DFN
Föderation RADIUS Server DFN-Verein
EinrichtungRADIUS Server
Konföderation RADIUS Server GEANT
(Kon)föderation RADIUS Server International
eduroam IdP/SPfür internationale/nationale Nutzer
Einrichtung RADIUS Server
Auth-Path: RADIUS over UDP, abgesichert mit Secret im Klartext
Netzverkehr authentifi-zierter eduroam Nutzer
WlanController/AP
Protokolle: EAP-TTLS/PEAP, etc.
SmartPhone, Tablet, LaptopAnmeldung mittels Realm: @einrichtung.de
DFN
Föderation RadSec Client/Server DFN-Verein
EinrichtungRADIUS Server
Einrichtung RadSec Client/Server
Konföderation RADIUS/RadSec Client/Server GEANT
(Kon)föderation RADIUS/RadSec Client/Server International
eduroam IdP/SPfür internationale/nationale Nutzer
Einrichtung RADIUS Server
…
…
…
Einrichtung RadSec Client/Server
Auth-Path: RADIUS over UDP, abgesichert mit Secret im Klartext
Netzverkehr authentifi-zierter eduroam Nutzer
WlanController/APProtokolle: EAP-TTLS/PEAP, etc.
Auth-Path: RADIUS over TCP, TLS abgesichert
SmartPhone, Tablet, LaptopAnmeldung mittels Realm: @einrichtung.de
14 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | WISSENSCHAFTSNETZ
Campus Edge für Big Data
Text: Jakob Tendel (DFN-Verein)
Eine bandbreitenstarke Datenübertragung erfordert Netzwerksysteme, die inklusive
der Endpunkte für eine gute Performance geeignet und konfiguriert sind. Die koordi-
nierte und konsequente Anwendung einiger gängiger Best Practices kann bereits für
eine erhebliche Durchsatzoptimierung sorgen. Mit der Entflechtung der Forschungs-
Anwendungen von der alltäglichen Nutzung des Campusnetzwerks, können störende
Wechselwirkungen vermieden werden. Ein Lösungsansatz beinhaltet die Schaffung
eines Hochleistung-Netzsegments, der ScienceDMZ, mit möglichst direktem Anschluss
zum Forschungsnetz zusammen mit dem Einsatz von optimierter Hardware in Data
Transfer Nodes (DTN) in der DMZ.
Foto © claudiarndt / photocase.de
15WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 94 |
Um räumlich verteilte, datenintensive
Anwendungen beispielsweise in der Kli-
ma-, Genom, oder Erdbeobachtungs-For-
schung praktikabel zeitnah zu betreiben,
sind durchschnittliche Datenraten im Gi-
gabit- bis Multi-10-Gigabitbereich für ein-
zelne Verbindungen („Flows“) notwendig.
Die Forschungsnetze sind für den Durch-
satz großer Datenströme über große Ent-
fernungen konsequent optimiert. Im regu-
lären LAN- und Internetbereich ist dies je-
doch ein eher unübliches und daher von
gängigen Hard- und Softwarelösungen
nicht immer standardmäßig optimal un-
terstütztes Verkehrsmuster. Die Endsyste-
me einer Übertragung und deren Lokalnet-
ze im Campus benötigen deshalb für den
Anwendungsbereich adäquate Einstellun-
gen, um auf leistungsfähigen Wide Area
Networks (WAN) nicht zur Durchsatzbrem-
se zu werden. Potenzielle Ursachen sind für
diesen Zweck nicht optimierte Software
und Hardware sowie eine schädliche Wech-
selwirkung mit Paketverlust.
Ein regelmäßig beobachteter Effekt bei
der Übertragung von Daten über eine gro-
ße Distanz ist eine mit steigender Entfer-
nung stark nachlassende Datenübertra-
gungsrate, während im lokalen Netzwerk
die theo retisch zu erreichende Datenrate
meist zufriedenstellend erreicht werden
kann. Performance-Tuning erfordert trotz
Verfügbarkeit von Netzwerkprotokollen
mit Steueralgorithmen und Autotuning
nach wie vor die bewusste Betrachtung
des beabsichtigten Einsatzbereichs, um
die Systemkonfiguration und Software-Pa-
rameter mit ihren zahlreichen teils gegen-
sätzlichen Effekten optimal abzustimmen.
Systeme ohne explizit optimierte Einstel-
lungen sind oft nicht in der Lage, die volle
Leistung des WAN auszunutzen.
Um ideale Bedingungen für große Datenra-
ten herzustellen, muss neben den Host-Sys-
temen am Endpunkt auch die Netzwerkinf-
rastruktur auf dem Übertragungspfad den
Anforderungen an eine verlustfreie Über-
tragung starker Flows gewachsen sein. Je-
de Netzwerkkomponente oder Middlebox
(z. B. stateful Firewalls oder IDS/IPS) stellt
eine potenzielle Fehlerquelle oder einen
Engpass dar. Idealerweise enthält der Pfad
durch das Netzwerk davon so wenige wie
möglich. Besonderes Augenmerk gilt auch
der Dimensionierung der Router-Puffer, die
selbst beim Zusammenfluss mehrerer star-
ker Flows auf einem Sende-Interface in der
Lage sein müssen, den Datenfluss zu be-
wältigen. Dies ist bei „kleinen“ LAN Rou-
tern und Switches nicht immer gegeben.
TCP und die Ursachen für Paketverlust
Paketverlust bedeutet, dass eines der Pa-
kete der TCP-Verbindung den Empfänger
nicht erreicht hat. Aufgrund der Eigen-
schaften von TCP (siehe Kasten), wird Pa-
ketverlust aber als solcher erkannt und
kann bis zu einer gewissen kritischen Pa-
ketverlustrate durch eine schnelle Wieder-
holung der Übertragung (fast retransmit)
kompensiert werden. Oberhalb der kriti-
schen Rate interpretiert der TCP-Algorith-
mus den Paketverlust als Signal für eine
Überlastung auf der Leitung und regelt
die gesamte Übertragungsrate teils dras-
tisch herunter. Die Abhängigkeit dieser
Prozesse von der Streckenlänge („Round-
Trip-Time“ RTT) bedeutet, dass die mögli-
che Übertragungsgeschwindigkeit mit der
Entfernung sinkt (Abb. 1). Im Zusammen-
spiel mit suboptimal konfigurierten Sys-
Den meisten Verfahren zur Übertragung von Datensätzen über Computer-
Netzwerke liegt das TCP-Protokoll (engl. "Transmission Control Protocol")
zugrunde, essentieller Bestandteil der Familie der Internet-Protokolle zur
paketvermittelten Kommunikation. Es stellt mittels automatischer Mecha-
nismen zur Synchronisierung und Bestätigung (SYN-SYN/ACK-ACK Drei-
Wege Handschlag) zwischen zwei Endpunkt-Systemen eine Verbindung für
den zuverlässigen Austausch von Datenpaketen her.
TCP-PROTOKOLL
Abbildung 1: Datendurchsatz vs. Latenz (RTT)
0
2
4
6
8
10
12
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90
Dat
enra
te [
Gb
ps]
RTT [ms] No Loss Loss
LAN
Stadt
RegionStaat
International Kontinental
kein Paketverlust
Paketverlust 0,0046 %
16 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | WISSENSCHAFTSNETZ
temen verursacht ein Paketverlust je nach
RTT der Verbindung massive Einbrüche in
der Übertragungsrate. Detailliert beschrie-
ben ist dieser Zusammenhang in [Da13].
Von einem modernen Campusnetz wird
erwartet, dass es Forscherinnen und
Forscher unterstützt und gleichzeitig
die Rolle eines Firmennetzwerks für Be-
schäftigte und Studierende erfüllt. Dies
macht aber den Einsatz diverser Kompo-
nenten und Praktiken für IT-Sicherheit
und -Management aus dem Bereich
Enterprise-IT notwendig, die im Wis-
senschaftsbetrieb wenig wirksam oder
gar hinderlich sind. Dazu gehören zum
Beispiel Firewalls, Intrusion Detection,
VPN Gateways, Proxys oder NAT. Alle ak-
tiven Komponenten, besonders solche,
die Deep-Packet-Inspection (DPI) durch-
führen, sind mächtige Flaschenhälse für
starke Flows von Wissenschaftsdaten.
Sie können in vielen Fällen auch neue
Unregelmäßigkeiten oder Paketverlus-
te im Datenfluss verursachen, wenn sie
durch ihre parallele Architektur einzelne
extrem starke Flows bei der Verarbei-
tung zerteilen.
Zu Deep-Packet-Inspection auf Wissen-
schaftsdaten ergibt sich, dass die hohen
potenziellen Verluste im Durchsatz in
den meisten Fällen den geringen Sicher-
heits-Mehrwert nicht lohnen, da die von
DPI gesuchten Datentypen mit mögli-
chen Schadinhalten in Wissenschafts-
daten nicht üblicherweise vorkommen,
bzw. sich durch Offline-Methoden bes-
ser finden lassen.
Lösungsansatz: ScienceDMZ
Zur Vermeidung multipler hops (Sprünge
zwischen einzelnen Netzknoten) durch ein
viel beschäftigtes Campusnetz voller hete-
rogener Anwendungen und Infrastruktur,
sieht der Lösungsansatz – analog zu einer
Webserver-DMZ – die Einrichtung einer spezi-
alisierten Netz-Enklave (ScienceDMZ [Da13])
mit möglichst direktem Anschluss an das
Forschungsnetz vor. In der ScienceDMZ
befinden sich dedizierte und optimierte
Übertragungs-Server (Data Transfer Node-
DTN), die ungestört die Fernübertragung
der Forschungsdaten übernehmen. Dabei
wird der Sicherheit im erforderlichen Um-
fang Rechnung getragen, jedoch mit an-
deren Methoden und Metriken als in der
Unternehmens-IT Praxis. Die genaue Aus-
gestaltung des Anschlusses an das WAN ist
Teil der Sicherheitsstrukturen und soll de-
dizierte Verbindungen mit bekannten und
ausreichend vertrauenswürdigen Gegen-
stellen ermöglichen, um auf den Einsatz
einer stateful Firewall auf dem Pfad für
Wissenschaftsdaten verzichten zu können.
Die ScienceDMZ gleicht einem Baukas-
ten von Best Practices und ist ein bereits
mehrfach bewährtes Designmuster für
Campusinfrastruktur insbesondere an Ein-
richtungen mit einem Bedarf an schnel-
lem Austausch von Forschungsdaten. Da-
zu gehören beispielsweise nationale For-
schungslabore mit Physik-, Material-, und
HPC-Forschung an weit verteilten Stand-
orten; aber auch Universitäten und Insti-
tutionen, an denen systematisch mit gro-
ßen Datensätzen geforscht wird. Die Sci-
enceDMZ ist flexibel skalierbar und ermög-
licht je nach den lokalen Gegebenheiten
und Bedarfen eine passende Lösung (Fas-
Abbildung 2: ScienceDMZ - Grundform
Enterprise Router/FirewallBorder Router
ScienceDMZRouterDTN mit High-Speed
Massenspeicher
CampusLAN
Security Policies
WAN
perfSONAR
perfSONAR
perfSONAR
„Sauberer“,
performanter
WAN Pfad
Kurzer Pfad aus
dem LAN zu
DMZ Ressourcen
ʃ Eine skalierbare und erweiterbare Netzwerkplattform ohne Paketver-
lust, speziell optimiert für die Übertragung umfangreicher Wissen-
schaftsdaten.
ʃ Dem tatsächlich notwendigen Sicherheitsniveau angemessene Siche-
rungsmaßnahmen, damit performante Anwendungen nicht unnötig
eingeschränkt werden.
ʃ Eine effektive Anbindung lokaler Ressourcen an die Weitverkehrsnetze.
ʃ Mechanismen zur laufenden Messung der Netzperformance mittels
PerfSONAR; man kann nur optimieren, was man messen kann.
DIE SCIENCE DMZ BIETET:
17WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 94 |
terData Knowledge Base: http://fasterda-
ta.es.net/).
Die Bausteine des DMZ-Ansatzes
Die einfachste Ausführung der ScienceDMZ
(Abb. 2) besteht aus einem separaten Netz-
bereich außerhalb der Campus Firewall und
ist durch einen dedizierten DMZ-Router
an den Border-Router angeschlossen. In
der DMZ befinden sich ein spezialisier-
ter Server (DTN) zur Datenübertragung
sowie eine perfSONAR-Box zur Messung
der Netzperformance. Die DTN kann di-
rekt über lediglich zwei Router mit dem
WAN kommunizieren. Die Forscher im Cam-
pus-LAN haben über den kurzen Pfad zur
DTN wegen der niedrigen Latenz kaum
Performance-Einbußen.
Traditionelle Werkzeuge der Netzwerksi-
cherheit wie Firewalls und andere Middle-
boxen erzielen ihre Wirkung größtenteils
durch die Analyse von Web-Traffic auf akti-
ve Schadinhalte. Im Wissenschaftskontext
werden aber große Datensätze ohne aktive
Inhalte und über sehr wenige Anwendun-
gen und Ports bewegt. Eine aktive Analy-
se bringt also wenig tatsächlichen Sicher-
heitsmehrwert und kann darüber hinaus
wie beschrieben schädlich auf die Daten-
rate wirken. Deswegen wird die Sicherheit
der DMZ mit mehreren ineinandergreifen-
den Maßnahmen, ohne den Einsatz einer
aktiven Analyse, auf dem Datenpfad sicher-
gestellt. Zum einen bedarf es geeigneter
Security Policies auf dem DMZ Router, zum
anderen sind die DTN-Systeme gehärtet
und nicht für eine interaktive Bedienung
durch Anwender konfiguriert. So arbeiten
die DTN mit stark eingeschränktem Umfang
an nach außen hin offenen Schnittstellen
und Protokollen. Die Managementfunkti-
onen lassen sich auf den lokalen Netzbe-
reich beschränken oder werden gänzlich
separat geführt.
Der Einzug von 100Gbit Technik vom Back-
bone in die Standortanbindung stellt so-
wohl eine Chance als auch eine Herausfor-
derung dar. Es ist derzeit technisch und fi-
nanziell nicht praktikabel, oder gar sinn-
voll, ein Campusnetzwerk durchgehend
100G-fähig zu machen. Es spricht also ein
weiterer Faktor dafür, die Anwendungen
mit herausragendem Bedarf in der Nähe
des WAN-Anschlusses anzusiedeln und so
das restliche Campusnetz von der Unter-
stützung dieser Anforderung zu befreien.
Durch diese Entflechtung der Netzinfra-
struktur profitieren auch Anwendungen
im restlichen Campus von der reduzierten
Beanspruchung ihrer Netzwerksegmente.
Die IT-Sicherheit im restlichen Campus
kann erhöht werden, weil Sonderregeln
und Löcher in der Firewall zurückgenom-
men werden können und sich insgesamt
die Angriffsfläche reduziert. So wird dem
Bedarf der wissenschaftlichen Anwendun-
gen an Performance Rechnung getragen,
ohne die Sicherheit zu vernachlässigen.
Um Lastverteilung und Ausfallsicherheit zu
gewährleisten, lässt sich die ScienceDMZ
durch eine Parallelisierung vieler Netzkom-
ponenten und Pfade skalieren (siehe Abb.
3). Mehrere DTN übernehmen die Daten-
übertragung und können dabei auf ein ge-
meinsames Dateisystem zugreifen. So wer-
den keine großen Datenströme ins Cam-
pusnetz geführt, sondern verbleiben gleich
im Kontext der Massenspeicher.
Integriert und effizient – die Datenportal-Infrastruktur
Für datenintensive Forschung an verteilten
Standorten verlangen Forschungscommu-
nitys zunehmend integrierte und effiziente
Umgebungen und IT-Infrastrukturen. Die-
se Forderung nach Integration beinhaltet
zunehmend auch geeignete Softwaresys-
teme zur Datenlogistik und -bearbeitung
im Kontext eines Forschungsdatenportals.
Aufbauend auf der ScienceDMZ lässt sich
eine Realisierung dieses Konzepts bewerk-
stelligen, welche die vormals in einem Web/
Daten-Server vereinten Funktionen der An-
fragesteuerung, Datenübertragung und Au-
torisation/Koordination aufteilt [Ch18].
Restrisiko IT-Sicherheit
Kritisch zu betrachten ist an der Sci-
enceDMZ insbesondere die zentrale For-
derung, auf aktive Komponenten der Enter-
Abbildung 3: Eine ScienceDMZ in einer HPC Einrichtung [Da13]
Enterprise Router/FirewallBorder Router
CampusLAN
FS/SANDTN-Cluster
mit Anbindung an zentrales Dateisystem
CampusLAN
WAN
perfSONAR
perfSONAR
perfSONAR
CampusLAN
ScienceDMZRouter
18 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | WISSENSCHAFTSNETZ
prise IT-Sicherheit zu verzichten. Ein An-
schluss von Netzwerkinfrastruktur an das
Forschungsnetz/Internet ohne Einsatz ei-
ner stateful Firewall bedarf einer genau-
eren Untersuchung der Wirksamkeit der
alternativen Sicherheitsmaßnahmen so-
wie einer Analyse der zu übertragenden
Datentypen in Bezug auf Schutzklassen.
Eine differenzierte Abwägung des Risi-
ko-Nutzen-Verhältnisses ist in jedem Fall
durchzuführen. Die Umsetzung kann in ei-
nigen Einrichtungen eine Revision der Si-
cherheitsrichtlinien und eine engere Ko-
operation zwischen Forschungs-IT, Sicher-
heitsbeauftragten und Datenschutzbeauf-
tragten erfordern. Selbst wenn die Lösung
technisch praktikabel und aus Sicht der
Forscher wünschenswert ist, kann es or-
ganisatorische Hürden zu überwinden ge-
ben. Reale Beispiele haben jedoch gezeigt,
dass es sich sehr lohnen kann.
Das Ziel – optimale Leistungs-fähigkeit im laufenden Betrieb
In der heutigen Zeit der BigData-Forschung
ist eine effektive Ausnutzung der vorhan-
denen Infrastruktur mindestens genauso
wichtig wie ständige Leistungssteigerun-
gen. Das Ziel muss sein, die optimale Leis-
tungsfähigkeit der Infrastruktur für die an-
spruchsvollsten Anwendungen aus der Wis-
senschaft spürbar und praktisch nutzbar
zu machen, ohne dadurch den täglichen
Betrieb der Brot-und-Butter-Anwendungen
im Campus zu beeinträchtigen. Es emp-
fiehlt sich die Entflechtung dieser zwei un-
terschiedlichen Anwendungsbereiche auf
Netzarchitekturebene, sodass sich die in-
tensive Optimierung für die Übertragungs-
leistung auf einen überschaubaren und ab-
sicherbaren Netzbereich beschränkt. Die
vorgestellten Best Practices sind jeweils
für sich gesehen keine Innovation, entfal-
ten jedoch gerade in Kombination, wie bei
der ScienceDMZ, in vielen dokumentierten
Fällen bereits eine sehr positive Wirkung.
Die größere Herausforderung bei der Um-
setzung ist meist nicht technischer, son-
dern organisatorischer Natur. Die Erfah-
rung vieler Einrichtungen zeigt jedoch
auch, dass dieser Aufwand die Dienstqua-
lität sowohl für die Wissenschaft als auch
für die alltäglichen Nutzer des Campusnet-
zes spürbar verbessert und neue Möglich-
keiten schaffen kann. MAbbildung 4: Modern Research Data Portal [Ch18]
Firewall
Border Router
Portal-ServerScienceDMZRouter
DTN-Clusterper API vom Portal gesteuert
FS/SAN
CampusLAN WAN
perfSONAR
perfSONAR
perfSONAR
Data
Browsing
LITERATURVERZEICHNIS
[Ch18] Chard K, et al.: The Modern Research Data Portal: a design pattern
for networked, data-intensive science., 2018, PeerJ Computer Science 4:e144
doi: 10.7717/peerj-cs.144
[Da13] Dart, E., et al: The Science DMZ: A network design pattern for data-in-
tensive science, 2013 SC - International Conference for High Performance
Computing, Networking, Storage and Analysis (SC), Denver, CO, 2013, pp. 1-10.
doi: 10.1145/2503210.2503245
ESnet Fasterdata Knowledge Base http://fasterdata.es.net/
Petascale DTN Project, https://cs.lbl.gov/news-media/news/2017/esnets-pe-
tascale-dtn-project-speeds-up-data-transfers-between-leading-hpc-centers/
SWITCH Stories: Wissen verwalten im Zeitalter von Big Data, https://www.
switch.ch/de/stories/big_science_data/
19WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 94 |
Kurzmeldungen
DFNconf – Der neue Konferenzdienst ist da!
Im Oktober 2018 wurde das neue Portal https://www.conf.dfn.
de/ für den Dienst DFNconf freigeschaltet. Über die neue Konfe-
renzplattform können Nutzer wie bisher ad hoc und ohne vorhe-
rige Reservierung von Ressourcen Video- und Webkonferenzen
durchführen. Voraussetzung für die Nutzung ist der Abschluss
einer Dienstvereinbarung mit dem DFN-Verein. Nach Freischal-
tung der Einrichtung für den Dienst können Nutzer direkt auf
das Dienstportal zugreifen und sich als Veranstalter registrie-
ren. Die Anmeldung zum Dienst (Log-in) erfolgt über das Single
Sign-On durch die DFN-AAI. Gäste beispielsweise aus der Indus-
trie oder internationale Gesprächspartner können ohne vorhe-
rige Registrierung zu Meetings eingeladen werden.
Veranstalter sind in der Lage, Meetingräume anzulegen, zu ver-
walten und Einladungen an die entsprechenden Teilnehmer vor-
zubereiten. Für bestimmte Anwendungsszenarien gibt es vorkon-
figurierte Meetingprofile, die für die Erstellung der Meetingräu-
me verwendet werden können. Außerdem besteht die Möglich-
keit, MCU-Konferenzen (Multipoint Control Unit-Konferenzen)
der alten DFNVC-Plattform für die weitere Verwendung unter
DFNconf in die neue Plattform zu migrieren. Natürlich kann über
das neue Portal auch auf die alte Infrastruktur in gewohnter Wei-
se zugegriffen werden.
Mit DFNconf können auf die Anforderungen der DFN-Nutzer zu-
geschnittene Konferenzen durchgeführt werden. Erreichbar ist
der Dienst über standardisierte webbasierte Lösungen, SIP- und
H.323-basierte VC-Systeme, mobile Endgeräte mit entsprechen-
der Software-App oder über eine Telefoneinwahl. Der browser-
basierte Zugang erfolgt über eine Meeting URL, die über Win-
dows, MacOS, Linux, iOS oder Android aufrufbar ist. Für den
Zugang per SIP oder H.323 kommen VC-Raumsysteme oder VC-
Clients zum Einsatz.
Das Dienstangebot des Webkonferenzdienstes über Adobe Con-
nect ist Teil des Dienstes DFNconf und wird in seiner bisherigen
Form weiterhin angeboten. M
Brandneue Version des DFNTerminplaners ist online!
Seit dem 1. Oktober 2018 ist eine neue Version des DFNTermin-
planers verfügbar. Die aktuelle Software des DFNTerminplaners
4.0 bietet dem Nutzer ein modernes Nutzerinterface und eine
vereinfachte Bedienbarkeit. So ist eine Anmeldung mit einem
Nutzerkonto nicht mehr nötig, Zugang erhalten Personen ein-
zig durch die Angabe ihrer E-Mail-Adresse. Zusätzlich gibt es ei-
nen Zugang für die Administratoren einer Abstimmung sowie die
Möglichkeit, die Abstimmung anonym durchzuführen oder mit
einem Passwort zu beschränken. Teilnehmer können jetzt abge-
gebene Stimmen bearbeiten oder auch stellvertretend abstim-
men. Der neue DFNTerminplaner 4.0 wird alle vorherigen Versi-
onen schrittweise ablösen. Informationen zu allen neuen Funk-
tionen finden Sie auf den Seiten des DFN-Vereins.
Den DFNTerminplaner 4.0 finden Sie unter:
https://terminplaner4.dfn.de M
20 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | INTERNATIONAL
In den kommenden 25 Jahren soll das
Projekt BELLA (Building the Europe Link
with Latin America) die Zusammenar-
beit der europäischen und lateiname-
rikanischen Forschungs- und Bildungs-
einrichtungen sichern. BELLA sorgt für
einen transatlantischen Datenaus-
tausch zwischen den Kontinenten,
um konstant Hochgeschwindigkeits-
kapazitäten zu schaffen. Dafür wur-
de ein langfristiges, uneingeschränk-
tes Mitnutzungsrecht für Frequenzen
auf einem direkten Unterseekabel zwi-
schen den beiden Regionen gesichert.
Die damalige europäische Dachorgani-
sation DANTE und das lateinamerika-
nische Forschungsnetz RedCLARA wur-
den erstmals 2003 im Rahmen des von
der EU finanzierten ALICE-Projekts mit-
einander verbunden. Seitdem sind die
Verbindungsgeschwindigkeiten immer wieder immens gestie-
gen, von 622 auf aktuell 10 Gigabit pro Sekunde, wobei die Ver-
bindungen stets über die USA geführt werden mussten. Bisher
gibt es jedoch keinen physisch direkten Weg zwischen Südame-
rika und Europa, der den erwarteten Bedarf an einem transatlan-
tischen Datenaustausch hinsichtlich Kapazität und Kosteneffizi-
enz decken kann. Dies soll sich in 2020 durch die Inbetriebnahme
eines direkten Unterseekabels, welches
die Firma EllaLink realisieren wird, än-
dern. Mit der Bereitstellung von einem
Drittel des optischen Spektrums auf dem
Unterseekabel wird der Datenaustausch
direkt zwischen den beiden Kontinenten
stattfinden, was nicht nur die Latenz um
bis zu 60 Prozent reduziert und den Da-
tenschutz verbessert, sondern auch ei-
ne kostengünstige und - was noch wich-
tiger ist - skalierbare Konnektivität mit
deutlich höheren Geschwindigkeiten als
bisher ermöglicht. Das ist wichtig, denn
die wissenschaftlichen Kooperationen
zwischen den beiden Kontinenten wer-
den in den kommenden Jahren deutlich
ausgebaut. Neben astronomischen For-
schungen wird auch durch Programme
wie Copernicus – das Erdbeobachtungs-
programm der EU – die Bedeutung der
BELLA-Konnektivität weiter steigen.
Von der Planung bis zum Kabel
BELLA baut auf den Ergebnissen des ELLA-Projekts (Feasibility
Study for a direct Europe Link with Latin America), geleitet durch
das italienische Forschungsnetz GARR, auf. ELLA stellte fest, dass
Investitionen zur Nutzung von Spektrum anstatt wie bisher fes-
BELLA – Eine Brücke für die Wissenschaft
Text: Nina Bark (DFN-Verein)
Die ersten Beobachtungen einer Kilonova oder die Entdeckung des ersten Objekts
interstellaren Ursprungs zeigen, wie wertvoll internationale Kooperationen vor
allem auf dem Gebiet der Astronomie heute sind. Diese Zusammenarbeit benötigt
eine moderne, zuverlässige und sichere Infrastruktur weltweit. Ein Ziel, an dem die
Gemeinschaft der Forschungsnetze stetig arbeitet. Mit dem Projekt BELLA wurde
ein wichtiger Schritt getan, um eben diesem Ziel wieder ein großes Stück näher
zu kommen.
Nordatlantischer Ozean
Französisch-Guayana
Brasilien
Südatlantischer Ozean
Abbildung 1: Karte EllaLink-Unterseekabel
Sines
Fortaleza
Praia Grande
21INTERNATIONAL | DFN Mitteilungen Ausgabe 94 |
ter Kapazitäten auf einem Unterseekabel,
technische und wirtschaftliche Vorteile ge-
genüber den bisherigen Lösungen bieten.
Derzeit gibt es unter anderem eine Ver-
bindung zwischen London und São Paulo,
welche jedoch bereits zu 80 Prozent aus-
gelastet ist und nicht weiter ausgebaut
werden kann. Auch die Verbindungskosten
sind sehr hoch, da es wenig Anbieter und
dadurch auch wenig Wettbewerb für die-
se Strecke gibt. Durch die überzeugenden
Erkenntnisse aus dem ELLA-Projekt war
es der Europäischen Kommission mög-
lich, Mittel bereitzustellen, um ein neues
transatlantisches Kabel zwischen den bei-
den Regionen finanziell zu unterstützen.
Das Unterseekabel wird voraussichtlich
2019 realisiert und 2020 in Betrieb genom-
men. Die Firma EllaLink wird dazu ein Schiff
von Sines in Portugal nach Fortaleza und
dann nach Praia Grande in Brasilien schi-
cken. Auf dem Kabel werden 45 optische
Kanäle bereitgestellt, welche jeweils mit
mindestens 100 Gigabit pro Sekunde im-
plementiert werden können. Durch wei-
tere technologische Entwicklungen soll
es außerdem möglich sein, ohne größe-
ren finanziellen Aufwand auf höhere Ka-
pazitäten aufzurüsten. So können durch
die Einbeziehung von Transpondern zur
Implementierung von zwei Wellenlängen
auf dem Seekabelsystem, zusätzliche Wel-
lenlängen aktiviert werden. Außerdem ist
die Möglichkeit vorgesehen, Telekommu-
nikationsausrüstung an den Landestati-
onen in Europa und Brasilien zu hosten.
Die Organisation hinter dem Projekt
Die Finanzierung von BELLA erfolgt durch
die europäischen sowie die lateinamerika-
nischen Forschungsnetze. Drei Direktora-
te der Europäischen Kommission sind je-
weils in drei integrale und voneinander
abhängige Bestandteile von BELLA invol-
viert. DG-CONNECT (Directorate-General for
Communications Networks, Content and
Technology) unterstützt den Bau des Un-
terseekabels, DG-DEVCO (Directorate-Gene-
ral for International Cooperation and De-
velopment) ermöglicht die Fertigstellung
der terrestrischen Glasfasernetzwerkin-
frastruktur von RedCLARA. Die Nachhal-
tigkeit des RedCLARA-Backbone bei Ge-
schwindigkeiten von 100 Gigabit pro Se-
kunde und mehr musste gewährleistet
werden, um den lateinamerikanischen For-
schungsnetzen einen nahtlosen Zugang
zur transatlantischen BELLA-Konnektivi-
tät mit GÉANT zu ermöglichen. Die Verbes-
serung des RedCLARA-Backbones stellt si-
cher, dass die Vorteile, die durch die hö-
heren Kapazitäten entstehen, bedarfso-
rientiert auf die Region in Lateinamerika
verteilt werden. Das DG-GROWTH (Directo-
rate-General for Internal Market, Industry,
Entrepreneurship and SMEs) unterstützt
eine direkte Verbindung für die ESA zum
Raumfahrtzentrum Guayana.
Die Gesamtfinanzierung des BELLA-Pro-
gramms beläuft sich auf rund 40 Millio-
nen Euro, davon 25 Millionen Euro von der
Europäischen Union und 15 Millionen Eu-
ro von der Gemeinschaft lateinamerika-
nischer Forschungsnetze. Darüber hin-
aus stellen die lateinamerikanischen For-
schungsnetze Sachleistungen über die na-
tionale Infrastruktur im Wert von rund 25
Millionen Euro bereit.
Beantragt wurde BELLA durch ein Konsor-
tium aus regionalen Forschungs- und Bil-
dungsnetzen: GÉANT und RedCLARA sowie
durch die nationalen Wissenschaftsnetze
von Brasilien, Chile, Kolumbien, Ecuador,
Frankreich, Deutschland, Italien, Portugal
und Spanien. Das Konsortium koordiniert
in erster Linie die sich ergänzenden und
voneinander abhängigen Ziele von BELLA
(uneingeschränktes Mitnutzungsrecht auf
dem noch zu verlegenden Unterseekabel
und Aufbau des Backbones in Lateiname-
rika). Der erste große Meilenstein wurde
bereits erreicht, das umfangreiche Verga-
beverfahren konnte im Sommer 2018 mit
einem Zuschlag an EllaLink abgeschlos-
sen werden. Die weiteren Arbeiten konzen-
trieren sich nun auf die Implementierung
des Unterseekabels, dessen Inbetriebnah-
me und Anbindung an GÉANT und RedCLA-
RA sowie den Ausbau der lateinamerika-
nischen Forschungsnetze. M
Transatlantic Connectivity
DG CONNECT DG GROWTH DG DEVCO LA NRENs
RedCLARA Backbone
Consortium
Abbildung 2: Organigramm BELLA
22 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | SICHERHEIT
Laut dem Wirtschaftsverband NCTA (The
Internet & Television Association) kann da-
von ausgegangen werden, dass die Anzahl
der mit dem Internet verbundenen Gerä-
te bis zum Jahr 2020 auf 50 Milliarden an-
steigen wird. Grund dafür ist vor allem
die rasant wachsende Zahl sogenannter
Smart Devices im Kontext des Internet der
Dinge (Internet of Things, IoT). Bestehen-
de Geräte wie etwa Türschlösser, Lampen
oder Waschmaschinen werden hierbei um
„smarte“ Funktionen erweitert, um sie aus
der Ferne steuern und überwachen zu kön-
nen. Um diese smarten Funktionen zu im-
plementieren, werden kleine eingebettete
Systeme in die Geräte eingebaut, die zum
Beispiel die Anbindung an ein drahtloses
Netz ermöglichen.
Die Firmware dieser Systeme dient einer-
seits der Anbindung spezifischer Hardware
(Sensoren und Aktoren) und übernimmt
andererseits die Kommunikation mit der
Außenwelt, zum Beispiel durch die Verbin-
dung mit einem WLAN-Netz. Die Funktio-
nen der eingebetteten Systeme werden
häufig als unveränderlich angenommen
und die Geräte über Jahre ohne Überwa-
chung und Wartung betrieben. Beispielhaft
sei hier ein Lichtschalter genannt, für den
wohl die wenigsten Menschen regelmäßig
nach Funktions- oder Sicherheitsupdates
suchen werden. Veränderte Anforderun-
gen an die Funktionalität und Sicherheit
(zum Beispiel als Reaktion auf neue Angrif-
fe) oder das Beheben von Fehlern in der
ursprünglichen Software führen jedoch in
der Realität dazu, dass die Geräte schließ-
lich doch angepasst werden müssen. Dies
erfolgt in der Regel durch Firmware-Up-
dates, wofür die Systeme eine geeignete
Schnittstelle bieten müssen. In aller Re-
gel erfordern diese Schnittstellen einen
direkten physischen Zugriff auf das Sys-
Internet of Things: Sicherheit kein Ding der Unmöglichkeit
Text: Dustin Frisch, Sven Reißmann, Christian Pape, Sebastian Rieger (Hochschule Fulda)
Themen wie Smart Home und Industrie 4.0 führen derzeit zu einem starken Zuwachs
an vernetzten Endgeräten im Bereich Internet of Things (IoT). Diese kostengünstigen
und häufig in großer Stückzahl ausgerollten kleinen Embedded Systems stellen durch
ihren jahrelangen Betrieb ohne Wartung und Sicherheitsupdates ein hohes Daten-
schutzrisiko und aufgrund ihrer großen Verbreitung auch ein Sicherheitsrisiko für
das gesamte Internet dar. Verschiedene in den letzten Jahren aufgetretene Angriffe,
die speziell IoT-Endgeräte im Visier hatten (zum Beispiel das Mirai-Botnet) zeigen
deutlich das Sicherheitsrisiko in diesem Bereich. Mithilfe eines nachhaltigen, stabilen
Verfahrens zur Bereitstellung von kryptografisch gesicherten Over-the-Air
Firmware-Updates kann das Sicherheitsrisiko gesenkt werden.
Illustratio
nen
© m
acrovecto
r / iStock
23SICHERHEIT | DFN Mitteilungen Ausgabe 94 |
tem, was insbesondere bei einer großen
Anzahl und der resultierenden räumlichen
Verteilung von Endgeräten kaum realisier-
bar ist. Abhilfe bieten hier Schnittstellen,
die ohne physischen Zugriff ein Over-the-
Air (OTA) Update aus der Ferne erlauben.
Sofern die Geräte über eine Netzanbindung
verfügen, bieten OTA-Updates die Möglich-
keit, neue Firmware-Versionen und Konfi-
gurationen automatisiert auf eine große
Anzahl verteilter Endgeräte auszurollen.
Die Automatisierung kann dabei – im Sin-
ne einer Continuous Delivery (CD) – Tests
und Prozesse für die fehlertolerante Aus-
lieferung der Firmware beinhalten. Hier-
bei können Updates zunächst automati-
siert auf Testgeräten eingespielt und über-
prüft werden. Sicherheitsupdates können
priorisiert im laufenden Betrieb ausgerollt
werden, während Funktionsupdates ver-
zögert verteilt werden, etwa sobald das
Endgerät zeitweise nicht verwendet wird.
Über das Netz kann zusätzlich eine Über-
wachung des Endgeräts und der Firmwa-
re-Updates erfolgen, um sicherzustellen,
dass alle Updates erfolgreich waren und
sich ein jedes Endgerät im gewünschten
Zustand befindet.
Stand der Technik
Kostengünstige und WLAN-fähige Pro-
grammable Logic Controller (PLC), wie der
ESP8266 des Herstellers espressif, haben
sich in vielen heute verfügbaren IoT- und
Smart-Home-Endgeräten etabliert. Dies be-
stätigen neben den kommerziell verfügba-
ren Produkten auch zahlreiche Veröffent-
lichungen, die auf diesem PLC basieren.
Firmware-Update-Mechanismen werden in
diesen Veröffentlichungen jedoch häufig
nicht thematisiert, was unter anderem der
Tatsache geschuldet ist, dass solche Gerä-
te aufgrund ihrer eingeschränkten Funkti-
on nach wie vor nicht als vollwertige Com-
puter, sondern als unveränderliche Kom-
ponenten betrachtet werden. Die Bedeu-
tung regelmäßiger Sicherheitsupdates für
aktuelle IT-Infrastrukturen, gerade in Be-
zug auf IoT, ist jedoch ungebrochen hoch.
Vereinzelt existieren bereits Veröffentli-
chungen für dezentrale Software-Updates
in IoT-Umgebungen, jedoch sind diese Lö-
sungen für kleine Mikrocontroller mit ge-
ringen Ressourcen nicht anwendbar. Dia-
gnose- und Update-Systeme speziell für
Embedded Software bzw. Mikrocontroller
wurden zum Beispiel für Electronic Control
Units in Fahrzeugen entwickelt. In diesem
Rahmen existieren auch Ansätze für die
Verwendung sicherer Firmware-Updates
in der Automobilindustrie. Auch Konzep-
te für Over-the-Air-Updates bei ESP8266-
PLCs wurden in anderen Arbeiten bereits
beschrieben. Die genannten Ansätze sind
allerdings nicht fehlertolerant im laufen-
den Betrieb möglich, erfordern in der Re-
gel ein separates Gateway und sichern nur
teilweise die Integrität und Authentizität
von übermittelten Updates.
ESPer – Sichere OTA-Firmware-Updates für IoT-Endgeräte
Mitglieder des in Fulda ansässigen Hack-
space Magrathea Laboratories e. V. (mag.
lab) haben in Kooperation mit Forschern
der Hochschule Fulda das Projekt ESPer
entwickelt. ESPer stellt ein Proof of Con-
cept (PoC) dar, das die genannten Defizite
in Bezug auf die Sicherheit von ESP8266-ba-
sierten IoT-Endgeräten verbessert. Neben
der kryptografischen Sicherung von Au-
thentizität und Integrität der Firmware-
Updates beinhaltet ESPer auch ein Kon-
zept für einen robusten und fehlertole-
ranten Update-Prozess.
Auf der ESP8266 MCU (Mikrocontroller
Unit) basierende Mikrocontroller-Boards
haben meist das gleiche Layout: Die MCU
ist verbunden mit einem Flash-Speicher,
der den Bootloader, die Firmware und an-
dere Anwendungsdaten speichert. Unab-
hängig von der Größe des angebundenen
Flash-Speichers erlaubt das Memory Map-
ping der MCU jeweils nur eine 1 MB Memo-
ry Page aus dem Flash abzubilden. Daher
• Neue Firmware-Releases müssen automatisch und ohne manuelle
Interaktion auf die Endgeräte ausgerollt werden.
• Der Update-Prozess muss fehlertolerant sein, so dass ein Endgerät
auch nach einem fehlgeschlagenen Update weiterhin funktioniert.
• Firmware-Updates müssen über die WLAN-Verbindung während des
regulären Betriebs möglich sein, ohne die Funktion des Geräts wesent-
lich zu beeinträchtigen.
• Der Update-Prozess muss über nicht vertrauenswürdige WLAN-Netze
und das Internet sicher möglich sein.
• Zur Erleichterung der Verwaltung und Überwachung von Endgeräten
sollen für den Update-Prozess relevante Informationen von den End-
geräten abrufbar sein.
DIE FOLGENDEN ANFORDERUNGEN WURDEN AN DAS DESIGN
UND DIE ENTWICKLUNG VON ESPer GESTELLT.
24 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | SICHERHEIT
muss der für die Firmware gewählte Be-
reich an Blockgrenzen von jeweils einem
Megabyte ausgerichtet werden. Da die
Firmware, die während eines Update he-
runtergeladen werden muss, zudem grö-
ßer als der freie Memory Heap Space sein
kann, müssen die empfangenen Daten di-
rekt bzw. ohne Zwischenspeicherung in
den Flash-Speicher geschrieben werden.
Dies führt jedoch mit hoher Wahrschein-
lichkeit zu Fehlern, da die Memory Mapped
Flash Pages, die während des Updates be-
schrieben werden, einen Programmcode
enthalten, der zur gleichen Zeit vom Mi-
krocontroller aktiv ausgeführt wird. Um
dieses Problem zu verhindern wurde bei
ESPer der Flash-Speicher in zwei Hälften
geteilt, wobei zwei ROM Slots entstehen,
die unterschiedliche Firmware-Versionen
beinhalten können (siehe Abbildung 1). Ei-
ne davon wird aktuell ausgeführt, die an-
dere kann durch den Download eines Firm-
ware-Updates überschrieben werden. Ne-
ben den zwei Firmware ROM Slots bietet
der Flash-Speicher Platz für den Bootloa-
der und dessen Konfiguration. Um ein ein-
heitliches Alignment des Programmcodes
und vereinfachtes Debugging zu erreichen,
wurde der zweite ROM Slot um die Größe
des Bootloaders verschoben (Padding). Die
8192 Byte große Lücke kann für das per-
sistente Speichern von Anwendungsdaten
über Firmware-Updates hinweg genutzt
werden. Der zusätzliche ROM Slot dient
gleichzeitig als Sicherungsmechanismus:
Schlägt ein Update fehl oder wird unter-
brochen, bleibt die vorherige Firmware-
Version in dem „aktiv ausgeführten“ Slot
intakt und kann ohne Ausfall des Endge-
räts weiterverwendet werden.
Einen besonders wichtigen Aspekt bei der
Durchführung von OTA-Updates stellt die
Sicherstellung von Authentizität und Inte-
grität der Firmware und damit der Schutz
vor Angriffen auf den Update-Prozess dar.
Unter keinen Umständen dürfen die Ge-
räte während des Update-Prozesses ei-
ner möglichen Manipulation ausgesetzt
sein. Für die Gewährleistung dieser For-
derung existieren zwar durchaus robuste
Schutzmechanismen, jedoch erschweren
oder verbieten die begrenzten Ressourcen
von IoT-Geräten in der Regel deren Anwen-
dung. Der ESP8266 Mikrocontroller kann
zum Beispiel mit seiner 80 MHz - 160 MHz
CPU weder die Rechenleistung für aufwen-
dige kryptografische Operationen zur Ver-
fügung stellen, noch bietet der in zwei Be-
reiche geteilte RAM (64 kB Befehlsspeicher
und 96 kB Datenspeicher) den dafür nöti-
gen Platz. Gängige Verfahren wie Trans-
port Layer Security (TLS) bzw. das darauf
aufbauende HTTPS sind somit nicht für die
sichere Übermittlung der Firmware geeig-
net, da schon allein die Bereitstellung der
zugehörigen X.509-Zertifikate die verfüg-
baren Ressourcen übersteigen würde.
Um trotzdem Manipulationen und Fehler
bei der Übertragung der Firmware auf das
Endgerät zu verhindern, berechnet der Up-
date-Prozess bei ESPer eine Hashsumme
der übermittelten Firmware und prüft die-
se anhand einer mit dem Update übertrage-
nen digitalen Signatur. Hierfür werden der
Hash-Algorithmus SHA-256 und ein Elliptic
Curve Cipher basierend auf Curve25519 ver-
wendet. Dadurch werden derzeitig emp-
fohlene Sicherheitsverfahren für die Signa-
tur von Software eingehalten. Die digitale
Signatur wird während des Build-Prozesses
mithilfe des privaten Schlüssels erzeugt
und als Metainformation zum Update be-
reitgestellt. Als Gegenstück dazu nutzen
die Mikrocontroller den in die Firmware
eingebrannten zugehörigen öffentlichen
Schlüssel für die Überprüfung der digita-
len Signatur nach dem Empfang des Up-
dates. Wie bereits erläutert, muss die neue
Firmware direkt auf den Flash-Speicher ge-
schrieben werden. Entsprechend wird der
SHA-256 Hash kontinuierlich während des
Downloads und dem Schreibvorgang auf
den Flash-Speicher ermittelt. Nachdem
der Download erfolgreich beendet wur-
de, wird der Hash-Wert anhand der digi-
talen Signatur verifiziert. Sofern die Über-
prüfung erfolgreich ist, wird die Bootloa-
der-Konfiguration geändert und die neue
Firmware aktiviert. Andernfalls bleibt die
alte Firmware des Endgeräts aktiv und der
Neustart entfällt.
Implementierung von ESPer
ESPer wurde für die Realisierung von siche-
ren und fehlertoleranten OTA Firmware-
Updates von IoT-Geräten entwickelt. Bei
der Implementierung des PoC wurde be-
wusst auf leichtgewichtige freie Software
gesetzt. Das unter einer Open-Source-Li-
zenz bereitgestellte Framework Sming –
das selbst wiederum auf dem Open Source
Software Development Kit (SDK) für den
Abbildung 1: Layout des Flash-Speichers zur Verwendung von zwei separaten ROM Slots
First ROM
0x000000 0x080000 0x1000000x002000 0x082000
Bootloader
Pa
dd
ing
fo
r a
lig
nm
ent
Second ROM
25SICHERHEIT | DFN Mitteilungen Ausgabe 94 |
ESP8266 basiert - stellt dabei die Grundlage
für ESPer dar. Es bietet Unterstützung für
viele Softwarekomponenten und eine Abs-
traktionsschicht für den einfachen Zugriff
auf Hardwarekomponenten der MCU, wie
GPIO-Ports und das WLAN-Modul.
Um die zentrale Verwaltung und Überwa-
chung der verwendeten Endgeräte zu er-
möglichen, sendet jedes Endgerät Statusin-
formationen an ein vordefiniertes MQTT-To-
pic (Message Queuing Telemetry Transport),
sobald es mit dem Netzwerk verbunden ist.
Neben Informationen zum Typ des Endge-
räts, der Chip- und Flash-ID, werden auch
Details zum Bootloader, dem SDK und der
derzeit verwendeten Firmware-Version
übermittelt. Außerdem werden relevante
Angaben zur Bootloader-Konfiguration – et-
wa der von der aktuell laufenden Firmwa-
re verwendete ROM-Bereich sowie der zum
Beispiel nach einem erfolgreichen Update
abweichende vom Boot-Prozess standard-
mäßig verwendete ROM-Bereich – weiter-
geleitet. Dadurch können Administratoren
gezielt Endgeräte mit veralteter Firmware
ermitteln, um zum Beispiel fehlende oder
fehlgeschlagene Updates zu identifizieren.
Für die Umsetzung wurde zunächst eine
Test-Infrastruktur geschaffen, in der das
Build-System für die Firmware, das Soft-
ware-Repository mit dem zugehörigen
Source Code, sowie die IoT-Geräte und de-
ren Controller zusammengefasst sind. Die
Topologie ist in Abbildung 2 dargestellt.
Das verwendete Build-System erlaubt die
Konfiguration von Basisparametern für al-
le Endgeräte, unabhängig von deren Typ
oder Funktion. Dazu gehören etwa WLAN-
Zugriffsparameter und MQTT-Verbindungs-
einstellungen, aber auch einheitliche Code-
Fragmente für den Bezug von OTA-Updates.
Mithilfe eines Continuous Integration (CI)
Systems werden bei Änderungen am Sour-
ce Code automatisch neue Releases der
Software erzeugt und entsprechende Firm-
ware-Images veröffentlicht. Ebenso besitzt
das Build-System einen privaten Schlüs-
sel für die Erzeugung kryptografischer Sig-
naturen, der zur Erzeugung von Signatur-
Dateien für jedes Firmware-Image heran-
gezogen wird.
Die Deployment-Infrastruktur stellt die
Firmware-Images über HTTP bereit und löst
die Aktualisierung der Geräte aus. Ein in
der installierten Firmware der eingebette-
ten Systeme integrierter Update-Mechanis-
mus lädt, validiert und installiert die Firm-
ware auf das IoT-Gerät. Alle mit ESPer aus-
gestatteten IoT-Geräte prüfen regelmäßig
die Verfügbarkeit neuer Firmware-Versio-
nen und führen bei Bedarf einen automa-
tisierten Update-Prozess durch. Darüber
hinaus ist ein manueller Start des Update-
Prozesses jederzeit möglich.
Sowohl das vorgestellte ESPer Framework
als auch das Build-System als solches, un-
terstützen die Erzeugung von Firmware
für unterschiedliche Geräteklassen. Dabei
kontrolliert das Framework den Lebens-
zyklus der Firmware sowie die zugehörige
Konfiguration. Zu diesem Zweck definiert
das Framework eine simple Schnittstelle,
welche durch alle Geräteklassen implemen-
tiert werden muss. Dies wird erreicht, in-
Home Assistant
Deployment-InfrastrukturAccess Point
MQTT Broker
Firmware Repository
Signed Firmware
Status Update Trigger
ROM 0/1
Public Key
ESP1
Public Key
ESPn
Source Repository
Private Key
ESPer
Build-System
Continuous Integration System
Abbildung 2: Verwendete Netztopologie und Systemarchitektur
26 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | SICHERHEIT
dem eine Instanz von Device erzeugt und
zurückgegeben wird, welche selber wie-
derum Instanzen des Typs Feature ent-
hält. Während die Feature-API es erlaubt
Funktionalität durch Polymorphismus zur
Laufzeit zu vereinheitlichen, wird bei der
Device-Erzeugung Polymorphismus zum
Übersetzungszeitpunkt eingesetzt, um so-
wohl die Speicherverwaltung zu vereinfa-
chen, als auch virtuelle Funktionstabellen
an dieser Stelle zu vermeiden.
Bei der Entwicklung kann jede Geräteklasse
separat übersetzt werden, indem der Gerä-
tetyp als Übersetzungsziel an das Makefi-
le übergeben wird. Durch die zusätzliche
Angabe des Schlüsselwortes flash kann da-
rüber hinaus der Aktualisierungsprozess
für eine spezifische Firmware einer Gerä-
teklasse ausgelöst werden. Zusätzlich wer-
den Konstanten aus der Build-Umgebung
direkt in die resultierenden Firmware-Da-
teien geschrieben. Neben den WLAN-Zu-
gangsdaten, den MQTT-Topics und weite-
ren konfigurierbaren Parametern, stehen
der Gerätetyp und die Firmware-Version in
Form solcher Konstanten zur Verfügung.
Darüber hinaus wird auch der öffentliche
Schlüssel zur Verifizierung der Firmware-
Signaturen als Objekt-Datei gegen jedes
Firmware-Image gelinkt. Dies erlaubt die
Nutzung all dieser Informationen im Quell-
text ohne Einschränkungen, obwohl diese
erst zur Übersetzungszeit konfigurierbar
bzw. bekannt sind.
Der ESP-01s ist lediglich mit 1 MB Flash-
Speicher ausgestattet, wobei dieser als
einzelner kompletter Adressbereich zur
Verfügung steht (siehe Beschreibung
des Flash-Layouts in Abbildung 2). Daher
kann der zweite ROM Slot nicht die glei-
che Start-Adresse wie der erste ROM Slot
nutzen. Da die Firmware ohne einen dy-
namischen Linking-Mechanismus ausge-
führt wird und der ESP keinen positionsun-
abhängigen Code unterstützt, ist es nö-
tig, dass die Adressierung je nach Offset
der Firmware im ROM angepasst wird. Aus
diesem Grund werden durch zwei Linker-
Skripte die zwei Ausprägungen der Firm-
ware erstellt, je nach Zielposition inner-
halb des Speichers. Die zwei resultieren-
den Firmware-Images werden beide von
der Deployment-Infrastruktur zur Verfü-
gung gestellt. Welches Firmware-Image
schließlich heruntergeladen und instal-
liert wird, hängt vom Ziel-Slot ab.
Der Erstellungsprozess erzeugt neben den
zwei Firmware-Images auch die dazuge-
hörigen Dateien mit den Metainformati-
onen. Für deren Erzeugung wird die aktu-
elle Versionsnummer der Firmware in eine
Datei geschrieben. Nach der Fertigstellung
werden die Signaturen der beiden Firm-
ware-Dateien erzeugt und der jeweiligen
Dateien mit Metainformationen entspre-
chend angehängt. Nach der erfolgreichen
Erzeugung der Firmware und der dazuge-
hörigen Dateien (Metainformationen) für
alle Geräteklassen, werden diese auf den
Repository-Server kopiert, wo sie mittels
HTTP/1.1 zur Verfügung gestellt werden.
Der Repository-Server selbst wird in der
Konfigurationsdatei des Projekts angege-
ben und gilt für die Geräte als Quelle für
Aktualisierungen.
Der eigentliche Aktualisierungsvorgang be-
steht aus vier Phasen: Prüfung auf Aktuali-
sierungen, Reprogrammierung des Geräts,
Berechnung und Verifizierung der digitalen
Signaturen der zu installierenden Firmwa-
re und schließlich - im Falle der erfolgrei-
chen Aktualisierung – Neukonfiguration
des Boot-Prozesses zur Nutzung der neu-
en Firmware. Um die IoT-Geräte über die
Verfügbarkeit neuer Firmware-Versionen
zu informieren, hält der Update-Server für
jede Geräteklasse eine Datei mit den Me-
tainformationen zur letzten verfügbaren
Firmware-Version bereit. Die Metainforma-
tionen enthalten sowohl die Versionsnum-
mer als auch die digitalen Signaturen bei-
der Firmware-Dateien. Diese Informationen
werden durch den Update-Server mithilfe
von HTTP/1.1 als ${DEVICE}.version zur Ver-
fügung gestellt (wobei ${DEVICE} jeweils
durch die Geräteklasse substituiert wird).
Jedes Gerät fragt regelmäßig den durch die
UPDATER_URL spezifizierten Update-Server
nach der verfügbaren Firmware-Version.
Dabei werden die Metainformationen her-
untergeladen und die Versionsnummer mit
der aktuell installierten Version verglichen.
Falls sich diese unterscheiden wird der ei-
gentliche Aktualisierungsprozess initiiert.
Sofern Fehler beim Download auftreten,
wird der Versuch beim nächsten Überprü-
fungsintervall wiederholt. Darüber hinaus
existiert mit ${MQTT_REALM}/update ein
spezielles MQTT-Topic, welches jedes Gerät
direkt nach dem Boot-Vorgang abonniert.
Sobald eine Nachricht auf diesem Kanal
eintrifft, überprüft das empfangende Gerät
sofort ob Aktualisierungen vorliegen. Dies
erlaubt sowohl ein schnelleres Ausrollen
von Aktualisierungen als auch effiziente
manuelle Wartungsarbeiten. Die Vereinheit-
lichung des initialen Installationsprozesses
mit dem Update-Prozess bietet Vorteile in
Bezug auf die Wartbarkeit und sie hilft Fehler
im Aktualisierungsprozess zu vermeiden.
27SICHERHEIT | DFN Mitteilungen Ausgabe 94 |
Der Update-Server stellt die Firmware-Da-
teien analog zu den Metainformationen zur
Verfügung. Durch Ergänzung des Pfades
mit .rom{0,1} kann somit auf das Firmwa-
re-Image für den ersten bzw. zweiten ROM
Slot zugegriffen werden. Die gewählte Da-
tei wird dann entsprechend über HTTP/1.1
GET vom Update-Server heruntergeladen.
Die Firmware wird in Teilstücken vom Up-
date-Server heruntergeladen. Dabei wird
zunächst die SHA256 Checksumme aktuali-
siert, bevor das Teilstück in den Flash-Spei-
cher geschrieben wird. Nach dem erfolg-
reichen Schreiben wird mit dem nächsten
Teilstück fortgefahren. Bei erfolgreichem
Abschluss des Vorgangs wird der resultie-
rende Hashwert gegen die Signatur des
Firmware-Images geprüft. Dazu wird der
kryptografisch signierte Hashwert aus
den Metainformationen gegen den Cur-
ve25519 öffentlichen Schlüssel der instal-
lierten Firmware geprüft. Nur wenn die
Checksummen mit der gegebenen Signa-
tur übereinstimmen wird die Firmware als
valide angenommen und der Aktualisie-
rungsprozess fortgesetzt. Als Bootloader
wird rBoot verwendet, da dieser im genutz-
ten Sming Framework integriert ist und
unterschiedliche ROM Slots booten kann.
Zur Konfiguration muss eine rBoot-spezi-
fische Struktur an eine definierte Stelle im
Flash geschrieben werden. Diese Struktur
enthält die Ziel-Offsets für alle bekannten
ROM Slots und die Nummer des ROM Slots
der während des Bootvorgangs verwendet
werden soll. Um diesen nach einer erfolg-
reichen Aktualisierung zu wechseln, wird
die Struktur angepasst und ein Neustart
des Geräts initiiert. Falls die kryptografi-
sche Signatur nicht validiert werden kann,
wird die aktuelle Konfiguration beibehal-
ten und der Neustart entfällt. Ein weiterer
Update-Versuch wird dann nach Ablauf des
eingestellten Intervalls oder durch erneute
Signalisierung eines verfügbaren Updates
unternommen.
Fazit und Ausblick
Mit ESPer wurde ein Konzept für die Erzeu-
gung und fehlertolerante Verteilung von
kryptografisch gesicherten Over-the-Air-
Updates für IoT-Endgeräte basierend auf
dem ESP8266 Mikrocontroller umgesetzt.
Die entwickelte Proof of Concept Imple-
mentierung ist essentieller Bestandteil des
Home-Automation Development und De-
ployment im Hackspace Magrathea Labo-
ratories. Alle Endgeräte, die in dieser Um-
gebung die ESPer-Firmware verwenden,
wurden mehrfach erfolgreich und ohne
Probleme im laufenden Betrieb aktuali-
siert, ohne dass eine manuelle Interven-
tion erforderlich war. Während des Up-
dates war die Funktion der Geräte nicht
eingeschränkt und sie konnten bis zum
Zeitpunkt des Updates wie gewohnt ver-
wendet werden. Hierbei wurden auch Än-
derungen an der Netzkonfiguration und
wichtige Stabilitätsupdates am Netzwerk-
Stack durchgeführt.
Durch die Entwicklung des vorgestellten
Frameworks, sowie den automatisierten
Build- und Update-Prozess, wird eine ein-
heitliche Umgebung für die sichere Vertei-
lung von Firmware-Updates auf IoT-End-
geräten bereitgestellt. Dadurch konnten
der Entwicklungsprozess vereinfacht, Än-
derungen im Quellcode schneller in abhän-
gige Module und Funktionen übernommen
und eine zeitnahe Verteilung auf die End-
geräte im Sinne einer Continuous Delivery
erzielt werden. Der Proof of Concept zeigt,
dass ein unkomplizierter OTA-Update-Pro-
zess für Endgeräte im Bereich IoT und damit
eine Erhöhung der Stabilität und Sicher-
heit in der Praxis durchaus realisierbar ist.
Glaubt man dem zu Beginn genannten Ar-
tikel bezüglich des Wachstums der Anzahl
vernetzter Endgeräte, so scheint eine für
die breite Masse geeignete Lösung zur In-
stallation von Firmware-Updates dringend
nötig. Hier sind die Hersteller der Geräte
gefragt, aber auch die Nutzer, die – etwa
beim Einsatz von IoT in Unternehmensin-
frastrukturen – durchaus Einfluss auf die
Entwicklung nehmen können.
Auch im Projekt ESPer sind für die Zukunft
noch eine Reihe von Verbesserungen vor-
stellbar. Unter anderem soll zukünftig die
Funktionalität und Sicherheit des Frame-
works in Bezug auf die Verifikation der In-
tegrität der Firmware während des Boot-
Vorgangs erweitert werden, um Manipula-
tionen oder defekte Firmware-Images zu
erkennen. Zusätzlich wird die Aufnahme
des Endgerätetyps in die digitale Signa-
tur in Betracht gezogen, um Fehlzuordnun-
gen der Firmware zu nicht unterstützten
Endgeräten zu verhindern. Darüber hin-
aus ist die Erweiterung der Statusinfor-
mationen und die Entwicklung einer Web-
Anwendung für das Monitoring der IoT-In-
frastruktur in der Umsetzung. Das Projekt
ESPer wurde auf GitHub der Öffentlichkeit
zur Verfügung gestellt, um so auch die Un-
terstützung und das Feedback der Open-
Source-Gemeinde zu erlauben. M
ESPer Projekt und Quellcode - https://github.com/esper-hub/esper
Publikationen:
D. Frisch, S. Reißmann, C. Pape, S. Rieger (2017). An Over the Air Update
Mechanism for ESP8266 Microcontrollers. The Twelfth International Con-
ference on Systems and Networks Communications. IARIA.
D. Frisch, S. Reißmann, C. Pape, S. Rieger (2018). Realisierung von sicheren
Over-the-Air Updates für ESP8266-basierte IoT-Geräte. 11. DFN-Forum Kom-
munikationstechnologien. GI.
REFERENZEN / WEBLINKS:
28 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | SICHERHEIT
Sicherheits-Kennzahlen: So scheitert die Theorie nicht an der Praxis
Text: Shikha Shahi, Matthias Hofherr (atsec information security GmbH)
Foto © Neville Mountford-Hoare / iStock
Das Thema „Kennzahlen“ im Kontext Informationssicherheit sorgt immer wieder für
Probleme in der Praxis. Erkenntnisse aus der Implementierung eines Informations-
sicherheits-Managementsystems, welche Ansätze funktionieren und was es für
mögliche Problemstellen gibt, sind daher unverzichtbar. Eine Vorgehensweise auf
Basis der GQM-Methodik (Goal-Question-Metric) bietet eine gute Möglichkeit,
Kennzahlen praxisnah und zielgruppenorientiert einzusetzen.
29SICHERHEIT | DFN Mitteilungen Ausgabe 94 |
Das Thema „Messung von Kennzahlen“ be-
gleitet Informationssicherheits-Spezialis-
ten schon seit Jahrzehnten. Die einschlägi-
gen Sicherheitsstandards fordern die Er-
hebung geeigneter KPIs (Key Performance
Indicator), um Auskunft über den Zustand ei-
nes Informationssicherheits-Management-
systems (ISMS) zu geben und Wirksamkeits-
analysen von umgesetzten Maßnahmen
durchzuführen. Zum Thema „Security-KPIs“
gibt es unzählige Whitepaper und theore-
tische Lösungsansätze, die auf dem Papier
durchaus interessant klingen, in der Pra-
xis dann aber zu wünschen übriglassen.
Mit ISO/IEC 27004:2016 gibt es seit Kurzem
zumindest einen Standard, der im Gegen-
satz zu seinem extrem theoretisch ange-
hauchten Vorgänger eine gewisse Praxis-
nähe aufweist und auch halbwegs sinnvoll
im Alltag genutzt werden kann.
Bei all den theoretischen Lösungen tritt
in der Praxis sehr schnell Ernüchterung
ein, wenn es an die tatsächliche Umset-
zung geht. Gerade Unternehmen, die sich
nicht nur „grob in Anlehnung an“ einen Si-
cherheitsstandard wie zum Beispiel der
ISO/IEC 27001 aufstellen, sondern diesen
tatsächlich zertifizierungsfähig umsetzen
müssen, tun sich hier schwer. Die erste Re-
aktion ist meistens „wir haben nichts zu
messen“, gefolgt von „lasst uns NAGIOS
auslesen, da stehen unendlich viele Verfüg-
barkeitszahlen“. In Erst-Zertifizierungen
weist der Auditor dann vorsichtig darauf
hin, dass solche Zahlen nicht zielführend
sind, was über die folgenden Jahre in einem
Katz-und-Maus-Spiel zwischen Auditor und
geprüftem Unternehmen endet. Das ist
für beide Seiten sehr selten zufrieden-
stellend.
Kennzahlen, Metriken, KPIs – Was ist das?
In der Literatur findet man unterschiedli-
che Definitionen für Kennzahlen, KPIs und
Metriken. Hier sprechen wir von „Metri-
ken“ und „Kennzahlen“, wobei wir unter
„Metrik“ letztendlich nur die Erhebung
von direkt messbaren Werten verstehen.
Eine „Kennzahl“ ist für uns der nächste
Schritt, nämlich die Definition von Zielen/
Zielwerten auf Basis der erhobenen Metri-
ken, verbunden mit der Prüfung der Zieler-
reichung. „KPI“ ist für uns als Synonym zu
„Kennzahl“ zu verwenden.
Zielgruppen der Kennzahlen
Bei der Erstellung von Kennzahlen ist ein
wichtiger Aspekt die Klärung, wer denn ei-
gentlich die Zielgruppen der Kennzahlen
sind – im Folgenden kurz Stakeholder ge-
nannt. Der primäre Zweck von Kennzahlen
ist ja nicht, etwaige Auditoren glücklich
zu machen, sondern bestimmten Stake-
holdern in der Organisation Fakten an die
Hand zu geben, um einen Überblick zum
Status der Informationssicherheit zu erhal-
ten. Bei einem von ISO/IEC 27001 getriebe-
nen Ansatz ist die Leitung der Organisati-
on zwangsweise eine Zielgruppe. Wer ge-
nau „die Leitung“ bzw. „das Management“
ist, hängt vom ISMS ab, ist aber letztend-
lich die oberste Führungsebene innerhalb
dieses Bereiches.
Je nach Größe der Organisation und Ver-
teilung der Aufgaben kann es allerdings
auch auf Leitungsebene mehrere Stake-
holder geben, die es zu identifizieren gilt.
Dies lässt sich nur in Interviews mit den
Beteiligten auf Leitungsebene herausfin-
den. Grundsätzlich gilt, dass keine Kenn-
zahl erhoben werden sollte, für die es nicht
auch mindestens einen Stakeholder gibt.
Neben den Stakeholdern auf Leitungsebe-
ne sind zusätzlich auch Zielgruppen auf der
taktischen Ebene zu identifizieren. Wäh-
rend die Leitungsebene eher zusammenge-
fasste Kennzahlen und eine Themenüber-
sicht benötigt, sind auf der taktischen Ebe-
ne detaillierte Kennzahlen, teils auch mit
sehr technischem Hintergrund, relevant.
Vorgehensweise / Einführung von Kennzahlen
Die Abstimmung relevanter Kennzahlen ist,
selbst wenn man die Stakeholder eindeu-
tig identifiziert hat, eine Herausforderung.
Ein allgemeines, ungerichtetes Brainstor-
ming mit den Zielgruppen hat sich hier in
der Praxis weniger bewährt. Getrieben aus
den Anforderungen der ISO/IEC 27001, Si-
cherheitsziele auf verschiedenen Ebenen
zu definieren, hat sich bei uns in den letz-
ten Jahren die Nutzung des GQM-Ansatzes
erfolgreich etabliert. Kurz zusammenge-
fasst bedeutet GQM (Goal-Question-Met-
ric), dass aus Sicherheitszielen Fragen ab-
geleitet werden, die dann durch Metriken
beantwortet werden.
Dies sorgt dafür, dass sich alle Kennzah-
len einer Organisation auf Sicherheitszie-
len abbilden lassen. Relevante Stakehol-
der, die Adressaten der Kennzahlen sind,
werden so in den Prozess integriert. Aus-
gangsbasis ist die Definition der strategi-
schen Sicherheitsziele, daraus folgt dann
eine Ableitung der taktischen Sicherheits-
Dies tut man, um
ʃ einen Überblick zu erhalten, welchen Reifegrad ein ISMS hat,
ʃ neue Sicherheitsmaßnahmen auf Basis objektiv messbarer Werte
festzulegen,
ʃ die Wirksamkeit von neuen Sicherheitsmaßnahmen zu belegen,
ʃ Kapitel 9 „Performance evaluation“ aus ISO/IEC 27001 zu folgen und
erfolgreich zertifiziert zu werden.
WOZU WERDEN KENNZAHLEN ERHOBEN?
30 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | SICHERHEIT
ziele. Bei den taktischen Sicherheitszielen
bilden die Kernprozesse aus ISO/IEC 27001
einen guten Startpunkt, da diese bei dem
Wunsch, ein ISMS nach dieser Norm zu be-
treiben, sowieso nicht optional sind. Die-
se werden ergänzt um die spezifischen,
taktischen Ziele der eigenen Organisati-
on. Die Erarbeitung der genauen Ziele er-
folgt unter Einbeziehung der oben disku-
tierten Stakeholder, da sich für jedes Ziel
entsprechend auch eine interessierte/ver-
antwortliche Partei finden sollte.
Basierend auf den identifizierten Zielen
werden dann zusammen mit den Stake-
holdern für das jeweilige Ziel Fragen for-
muliert. Deren Beantwortung hilft dem
Stakeholder zu verstehen, wie nahe die
Erreichung des Ziels ist. Aus den Fragen
werden Vorschläge für Kennzahlen abgelei-
tet, die mit dem Stakeholder abgestimmt
werden. Dies wird solange iteriert, bis die
Stakeholder die jeweiligen Kennzahlen als
ausreichende Antworten zu ihren Fragen
betrachten.
In der Praxis hat sich gezeigt, dass der An-
satz über Fragen gerade auf Leitungsebene
sehr gut funktioniert. Auf der taktischen
Ebene, speziell im IT-Umfeld, neigen die
Gesprächspartner eher dazu, gleich di-
rekt Metriken aus den Zielen abzuleiten
und den Fragen-Teil zu überspringen. Dies
stellt allerdings kein Problem dar, da das
finale Ziel die Erhebung der Kennzahlen
ist. Wenn schon konkrete Vorstellungen
zu den Kennzahlen vorliegen, dann lassen
sich umgekehrt daraus auch problemlos
die Fragen ableiten, die damit beantwor-
tet werden sollen.
Zusammengefasst sorgt der GQM-Ansatz
unter Einbindung der Stakeholder dafür,
dass es letztendlich nur Kennzahlen in der
Organisation gibt, für die sich jemand zu-
ständig fühlt und an denen ein Stakeholder
Interesse hat. Der Ansatz über die Stake-
holder sorgt auch dafür, dass sowohl tak-
tische als auch strategische Kennzahlen,
und zwar jeweils für die richtigen Zielgrup-
pen, erhoben werden. Dies verhindert des-
interessiertes „Abnicken“ der Kennzahlen.
Typen von Kennzahlen
Bei der Anwendung des GQM-Ansatzes soll-
te man sich bewusst sein, welche Arten
von Kennzahlen grundsätzlich überhaupt
einsetzbar sind. Die einfachste Basis sind
hier Standard-Kennzahlen, bei denen in be-
stimmten Abständen ein Wert („Metrik“) ge-
messen und im Verlauf der Zeit analysiert
wird. Diese Kennzahlen sind idealerweise
automatisiert aus bestehenden Datenbe-
ständen zu erheben und damit einfach zu
beschaffen. Sie können sowohl aus tech-
nischen Messungen als auch aus Prozess-
Metriken abgleitet werden.
Eine weitere Option ist die Verwendung
von Kennzahlen auf Basis eines Reife-
grad-Modells, womit der Reifegrad von
Prozessen bewertet wird. Die Reifegrad-
Messung für Prozesse ist aus Referenz-
modellen wie CMMI (Capability Maturity
Model Inte gration) oder SPICE (Soft-
ware Process Improvement and Capabi-
lity Determina tion, ISO/IEC 15504-5) hin-
länglich bekannt. Für sicherheitsrelevante
Prozesse muss ein generisches Modell zur
Prozessbewertung um spezifische Anfor-
derungen pro Prozess angereichert wer-
den, da generische Prozessvorgaben allei-
ne nicht aussagekräftig sind. Dies schränkt
die einfache Nutzung in der Praxis etwas
ein, da vorher ein komplettes Reifegrad-
Modell für die sicherheitsrelevanten Pro-
zesse definiert werden muss. Es gibt zwar
bereits einige Ansätze zur Bewertung von
Reifegraden, diese sind in der Praxis al-
lerdings kaum verbreitet und auch nicht
vollständig. Der Hauptnutzen von Kenn-
zahlen auf Basis eines Reifegrad-Modells
liegt in der Einführung eines ISMS oder
beispielsweise bei einem Umstellungs-
projekt des Datenschutzes von Bundes-
datenschutzgesetz (BDSG) auf EU-Daten-
schutz-Grundverordnung (DSGVO). Mit der
Betrachtung von Reifegraden lässt sich der
Projektfortschritt gut dokumentieren und
nachverfolgen.
Eine weitere Kategorie von Kennzahlen
sind die sogenannten Meta-Metriken. Da-
bei handelt es sich um Metriken, die aus
anderen Metriken abgleitet werden. Diese
sind weniger auf taktischer Ebene als für
strategische Kennzahlen relevant. Gera-
de bei Kennzahlen auf Leitungsebene ist
eine Verdichtung notwendig, um mit ver-
gleichsweise wenigen Kennzahlen einen
Überblick über das gesamte ISMS zu ge-
ben. Ein Beispiel für eine einfache Meta-
Metrik ist die Verdichtung des Reifegrads
der einzelnen Sicherheitsprozesse durch
Geschäftsführung
Betrieb
Strategisch
Taktisch
Monatlich
erstellte
ScorCards
Goal Ques tion
Metric (GQM)
ÜBERSICHT KENNZAHLEN-PROZESS
Abbildung 1
31SICHERHEIT | DFN Mitteilungen Ausgabe 94 |
Mittelwertbildung zu einer Kennzahl, die
den Gesamt-Reifegrad aller ISMS-Prozes-
se widerspiegelt.
Output und Kommunikation von Kennzahlen
Kennzahlen, die nicht ausgewertet wer-
den, helfen niemandem. Daher muss für
die Kennzahlen eine Kommunikations-
und Auswertungsstrategie erstellt wer-
den. Hier hat sich anstatt endloser Zah-
lenkolonnen eine grafische Auswertung
bewährt. Diese ist mit klassischen Dash-
board-Lösungen realisierbar, was aber für
die meisten Unternehmen rein aus der In-
formationssicherheit getrieben zu viel des
Guten ist - sofern nicht ohnehin schon ent-
sprechende Dashboard-Tools eingesetzt
werden. Stattdessen hat sich in der Pra-
xis gerade bei kleinen und mittleren Un-
ternehmen die Nutzung von ScoreCards
bewährt. Ziel einer ScoreCard ist es, einem
Stakeholder zu seinem Themengebiet die
relevanten Kennzahlen so aufzubereiten,
dass sie möglichst „auf einen Blick“ zu er-
kennen sind.
Fazit
Sicherheitsrelevante Kennzahlen wer-
den immer ein Thema sein, das auf den
jeweiligen Anwender zugeschnitten wer-
den muss. Das beschriebene Vorgehens-
modell GQM sorgt für einen strukturier-
ten Ansatz zur Erhebung der notwendigen
Kennzahlen. Dabei handelt es sich aber
nicht um einen „Katalog-Ansatz“, bei dem
sich aus einem Katalog von Kennzahlen ei-
ne Sammlung zusammenstellen lässt und
dann direkt mit der Messung begonnen
werden kann. Eine intensive Diskussion
mit dem jeweiligen Stakeholder ist immer
die Grundlage für jede einzelne Kennzahl.
Der GQM-Ansatz hat den Vorteil, dass er
sowohl für große als auch für kleine Orga-
nisationen funktioniert. Ebenso funktio-
niert er bei allen unterschiedlichen Arten
von Organisationen, von Bildungseinrich-
tungen bis zu internationalen Großunter-
nehmen, da jede dieser Organisationen ei-
gene, individuelle Sicherheitsziele hat und
auch nur für diese Ziele Kennzahlen erho-
ben werden. Hier gibt es keinen „Grund-
schutz-Katalog der Sicherheitskennzah-
len“, der verpflichtend umzusetzen ist. M
Abbildung 3: Auszug ScoreCard
Stufe 1
• Geringfügige Prozesse
• Keine Lösung für Schwach- stellenanalysen
• Kein Meldesystem
Stufe 2
• Eine festgelegte Reihe von Pro - zessen und Ver- fahren
• Schwachstellen-analyse ist durchgeführt
• Regelmäßige Scans
Stufe 3
• Detailliert beschriebene Verfahren
• Zuverlässige Lösung
• Meldesystem
• Ticketsystem
Stufe 4
• Auswertung ist durchgeführt
• Statistische Daten
• Festgelegte Metriken
• Bewertung erfolgt über Berichte
Stufe 5
• Teil des KVPs (Kontinuierlicher Verbesserungs-prozess)
• Software zur Bedrohungsana-lyse
• Threat Intelli-gence System im Einsatz
VEREINFACHTES REIFEGRAD-MODELL FÜR EINEN
SCHWACHSTELLEN-MANAGEMENT-PROZESS
ISMS KPI SCORECARD
Abbildung 2
Nr. KPI Fre-quenz
Ziel-wert
An-sprech-partner
2017 Q3
2017 Q4
2018 Q1
2018 Q2
Verlauf Aktuell Bewer-tung
1. Prozentsatz der Mitarbeiter, die innerhalb der ersten Arbeitswo-che eine ISMS erhalten haben
Viertel-jährlich
90% QM 92% 92% 78% 78%
2. Zahl der Informationssicherheits-vorfälle pro Quartal
Viertel-jährlich
0 QM 4 2 3 4
3. Prozentsatz der Mitarbeiter, die an der jährlichen ISMS-Schulung teilgenommen haben.
Jährlich 100% QM 100% 100% 100% 100%
100%
50%
0%
4
2
0
100%
50%
0%
32 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | SICHERHEIT
Sicherheit aktuellText: Silke Meyer (DFN-Verein), Reimer Karlsen-Masur (DFN-CERT), Heike Ausserfeld (DFN-Verein)
Erfahrungen und Hinweise zum neuen Verfah-
ren der Domain-Freischaltung in der DFN-PKI
Seit dem 1. August 2018 sind die neuen Verfahren zur Domain-
Freischaltung in der DFN-PKI in Betrieb. Die Umstellung war auf-
grund von Vorgaben in den Baseline Requirements des CA/Brow-
ser Forums notwendig. Seit diesem Zeitpunkt ist zur Validierung
von Domains nur noch ein E-Mail-Challenge-Response-Verfahren
möglich. Auch alle bisher eingetragenen Domains mussten mit
dem neuen Verfahren „revalidiert“ werden. Mit Unterstützung der
Java RA-Oberfläche konnte diese Umstellung reibungslos durch-
geführt werden, sodass bis Mitte September dieses Jahres ins-
gesamt wieder 7097 Domains für die Ausstellung von Serverzer-
tifikaten freigeschaltet wurden. Die übrigen 2314 Domains wa-
ren bis zu diesem Zeitpunkt noch nicht wieder freigeschaltet.
Tipps und Hinweise für die sich während der Umstellung erge-
benen Fragen und Probleme finden Sie in unserem Blog: https://
blog.pki.dfn.de/2018/06/tipps-fuer-die-domain-freischaltung M
Teilnahme an der Sirtfi-Compliance – Security
Incident Response in der DFN-AAI
Der DFN-Verein und DFN-CERT arbeiten gemeinsam an der Um-
setzung des Sirtfi-Frameworks für die DFN-AAI. Sirtfi (sprich: „cer-
tify“) steht für „Security Incident Response Trust Framework for
Federated Identity“. Es beschreibt einen geregelten Umgang mit
Sicherheitsvorfällen in Föderationen wie etwa dem Identitäts-
diebstahl bei einem Identity Provider (IdP) oder dem unbefugten
Zugriff auf (personenbezogene) Nutzerdaten bei einem Service
Provider (SP). Allen Föderationsteilnehmern wird empfohlen, ih-
re Sirtfi-Compliance zu prüfen und ggf. selbst zu erklären, indem
sie in den AAI-Metadaten ein zusätzliches Entity Attribut veröf-
fentlichen. In der DFN-AAI ist der Verbreitungsgrad dieser Selbst-
verpflichtung derzeit sehr gering: Nicht einmal fünf Prozent der
über 700 IdP und SP tragen das entsprechende Entity Attribut.
Unabhängig von Sirtfi sollten alle Föderationsteilnehmer für die
von ihnen betriebenen IdP/SP-Instanzen in der DFN-AAI Metada-
tenverwaltung einen Security-Kontakt hinterlegen, damit sie im
Falle eines Sicherheitsvorfalls benachrichtigt werden können.
Dies sollte eine Funktionsadresse sein, keine persönliche E-Mail-
Adresse. Föderationsteilnehmer, die bereits so weit sind, ihre
eigene Compliance zu bestätigen, können sich das Entity Attri-
but geben lassen.
Weitere Informationen finden Sie im DFN Trust & Identity
Wiki unter:
https://doku.tid.dfn.de/de:aai:incidentresponse M
Java in der DFN-PKI
Oracle nimmt zurzeit erhebliche Veränderungen an seiner Ja-
va Implementierung vor. Diese Anpassungen haben auch Aus-
wirkungen auf die Java RA-Oberfläche der DFN-PKI. So wird Ja-
va WebStart mit den bekannten JNLP-Dateien abgeschafft, die
Lizenz von Oracle Java wird sich ändern und es müssen interne
Mechanismen umgestellt werden. Teilweise geschieht dies in ei-
ner Art, die sowohl rückwärts als auch vorwärts inkompatibel
ist (Initialisierung von PKCS11).
Die DFN-PKI wird die Java RA-Oberfläche im Herbst 2018 umstel-
len. Die Java RA-Oberfläche wird dann als komplettes Java-Archiv
zusammen mit plattformspezifischen Start-Skripten zum Her-
unterladen angeboten, der Download-Link dafür wird noch be-
kannt gegeben. Da es in Java keinen eingebauten Update-Mecha-
nismus für Anwendungen mehr geben wird, welchen Java Web-
Start bisher ganz bequem geliefert hat, wird die Java RA-Oberflä-
che selbst auf neue Versionen prüfen und gegebenenfalls zum
Herunterladen einer Aktualisierung auffordern. Die Systemvo-
raussetzung wird nun OpenJDK ab Version 11 sein. Die derzeit
existierende Java WebStart-Version der RA-Oberfläche, die un-
ter Oracle Java 8 lauffähig ist, wird noch bis ca. Mitte 2019 zur
Verfügung stehen. M
Wenn Sie Fragen oder Kommentare zum Thema
„Sicherheit im DFN“ haben, schicken Sie bitte eine
E-Mail an [email protected]
KONTAKT
33CAMPUS | DFN Mitteilungen Ausgabe 94 |
Der Trend geht hin zu Netzen, deren Funktionalitäten zunehmend in Software realisiert werden:
den software-basierten Netzen. Durch deren einfache Programmierbarkeit lassen sich schnell und
flexibel neue Dienste erstellen, erproben und ausrollen. Davon profitiert das Lehrkonzept „teaching
networks with networks“. Studierende können in virtualisierten Netzen auf einfache Art komplett in
Software mit komplexen Konzepten wie Routingalgorithmen experimentieren. Damit die Einstiegs-
hürden möglichst gering sind, verbirgt das Werkzeug SDN Cockpit unnötige Details, wie etwa Virtua-
lisierungslösungen vor den Studierenden, und erlaubt es ihnen damit, sich auf die Lösung der gestell-
ten Aufgabe zu konzentrieren.
SDN Cockpit: Teaching Networks with Networks
Text: Hauke Heseding, Robert Bauer, Martina Zitterbart (Karlsruher Institut für Technologie, KIT)
Foto © DFN
X-WINer-Award 2018
34 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | CAMPUS
Das Konzept softwarebasierter Netze
(Software Defined Networking, SDN [1])
basiert auf einer klaren Trennung zwischen
Daten- und Kontrollebene. Die Kontroll-
funktionalität eines Netzes wird dabei an
einer logisch zentralisierten Stelle gebün-
delt: dem SDN Controller. Die daraus re-
sultierende Architektur ist in Abbildung
1 skizziert. Die Datenebene besteht aus
einfach gestalteten SDN Switches, die über
eine standardisierte Schnittstelle program-
miert werden können (z. B. über OpenFlow
[2]). Sie sind für die Weiterleitung von Pa-
keten verantwortlich. Der logisch zentra-
le SDN Controller ist in der Kontrollebene
angesiedelt. Er ist mit den von ihm kon-
trollierten Switches verbunden und über-
nimmt Standardaufgaben wie etwa die
Erkennung der Netztopologie. Er bietet
außerdem den SDN-Applikationen (Apps)
eine Programmierschnittstelle an, die
eine abstrakte Sicht auf das Netz sowie
eine Reihe hilfreicher Funktionen zur
Verfügung stellt. Über Letztere lassen
sich zum Beispiel die Weiterleitungsre-
geln der Switches anpassen. Mittels der
Apps können in Software Funktionalitäten
der Kontrollebene implementiert werden.
Zusammen mit Virtualisierungslösungen
(z. B. mininet [3]) können „eigene“ Netze re-
alisiert und erprobt werden, ohne in die
Infrastruktur bestehender Netze eingrei-
fen zu müssen.
Teaching Networks with Networks
SDN ist bestens für die Umsetzung des Lehr-
konzepts „teaching networks with networks“
geeignet. Ohne dedizierte Hardware-Netz-
infrastruktur können so praxisnahe Erfah-
rungen über SDN-Konzepte sowie zu kom-
plexen Problemstellungen moderner Netze
(z. B. Routing, Angriffserkennung) gesammelt
werden. Studierende können unterschiedli-
che Lösungskonzepte bei der Programmie-
rung von Apps erproben und insgesamt ein
„Gefühl“ für die Komplexität und die Zusam-
menhänge in Netzen entwickeln.
Soweit, so gut. Allerdings zeigt sich in der
Praxis sehr schnell, dass für die tatsäch-
liche Umsetzung der Einsatz zahlreicher
unterstützender Werkzeuge erforderlich
ist, z. B. für die Generierung von Netztopo-
logien. Der Umgang mit diesen leistungs-
fähigen aber komplexen Werkzeugen wie
mininet und SDN Controller Ryu [4] erfor-
dert einiges an Einarbeitung, ist aber ei-
gentlich für das Verständnis von SDN so-
wie die Umsetzung von Algorithmen der
Kontrollebene nicht notwendig. Unsere
Erfahrungen haben gezeigt, dass sie die
Einstiegshürde unnötig erhöhen und von
den eigentlichen Lernzielen ablenken. Das
Potenzial softwarebasierter Netze kommt
so zunächst nicht voll zum Zug.
An dieser Stelle setzt SDN Cockpit an, in-
dem es einerseits die Komplexität dieser
Werkzeuge vor den Studierenden verbirgt
und andererseits eine Reihe nützlicher Mo-
dule (Benutzeroberfläche, Verkehrsanaly-
se) integriert sowie die automatisierte Eva-
luierung einer implementierten App ermög-
licht. Studierenden wird damit ein kom-
fortables Werkzeug an die Hand gegeben,
mit dem sie sich auf die eigentliche Pro-
blemstellung konzentrieren können, oh-
ne sich in weitere komplexe Werkzeuge
einarbeiten zu müssen.
SDN Cockpit – das Konzept
Die Architektur von SDN Cockpit (Abbil-
dung 2) umfasst eine Reihe externer Werk-
zeuge zur Emulation software-basierter
Netze sowie SDN Cockpit-Module, mit de-
ren Hilfe diese Werkzeuge gesteuert sowie
die Abläufe im Netz ausgewertet und in ei-
ner Benutzeroberfläche dargestellt wer-
den. SDN Cockpit bietet nach außen zwei
Schnittstellen an: das Frontend für die Stu-
dierenden und das Backend für die Tutoren.
Das Lernen mit SDN Cockpit erfolgt sze-
nario-basiert. Ein Szenario umfasst eine
Netztopologie, Datenströme sowie die zu
lösende Aufgabe. Zur Erstellung eines Sze-
narios verwendet ein Tutor oder ein fortge-
schrittener Studierender das Backend, mit
dessen Hilfe er eine Netztopologie und die
darin auftretenden Datenströme modelliert.
Zusätzlich formuliert er die Aufgabenstel-
lung, die im Wesentlichen eine Beschreibung
des gewünschten Netzverhaltens darstellt.
Die Aufgabe der Studierenden besteht da-
rin, über das Frontend eine App zu imple-
mentieren, die die Aufgabenstellung im
vorgegebenen Szenario erfüllt. Hierbei
steht es ihnen frei, ihre bevorzugte Ent-
wicklungsumgebung zu verwenden. SDN
SDN Switch
DATENEBENE
KONTROLLEBENE
SDN Controller
APP APP APP
Abbildung 1: SDN-Architektur
35CAMPUS | DFN Mitteilungen Ausgabe 94 |
Cockpit macht an dieser Stelle bewusst
keine Einschränkungen, um auch hier Ein-
stiegshürden zu vermeiden.
Die korrekte Funktionsweise der App wird
durch eine automatisierte Erfolgskontrolle
überprüft. Dazu wird die App auf dem Sze-
nario ausgeführt und die von ihr gesteuer-
ten Datenströme mit dem gewünschten
Netzverhalten verglichen. Beobachtete
Abweichungen werden über die Benut-
zeroberfläche zurückgemeldet.
Zusammenfassend ergeben sich die we-
sentlichen Eigenschaften von SDN Cockpit:
ʃ Flexibilität: die Möglichkeit der Er-
stellung vielfältiger Szenarien.
ʃ Leichte Handhabung: Einstiegshür-
den im Umgang mit softwarebasier-
ten Netzen werden möglichst
gering gehalten.
ʃ Realitätsnähe: Apps sind direkt in
realen Netzen anwendbar.
Szenarien und automatisierte Erfolgskontrolle
Für die Erzeugung der Szenarien wird die
Backend-Schnittstelle von SDN Cockpit ge-
nutzt. Diese verwendet eine Konfigurati-
onsdatei, in der die Beschreibung der ge-
wünschten Netztopologie hinterlegt wird.
Außerdem können dort Datenströme an-
hand ihrer Charakteristika (Startzeitpunkt,
Dauer, Paketrate, u. a.) beschrieben sowie
deren Quelle und Ziel bestimmten Endsys-
temen im Netz zugeordnet werden. Durch
die Vielzahl der Parameter in Kombination
mit den Beschreibungsmöglichkeiten für
Topologien, kann ein breites Spektrum an
Szenarien abgedeckt werden.
Die Konfigurationsdatei enthält alle In-
formationen, die für eine automatisierte
Erfolgskontrolle notwendig sind. Es wer-
den hierzu in SDN Cockpit intern die fol-
genden Schritte durchlaufen:
1. Generierung des virtuellen Netzes, pas-
send zur Topologiebeschreibung. Hier-
für wird mininet eingesetzt.
2. Die Kontrolle des Netzes wird von
dem SDN Controller Ryu übernom-
men. Die Programmierschnittstelle
von Ryu wird in SDN Cockpit unver-
ändert übernommen. Die realisierten
Apps sind somit problemlos in SDN-
Netzen mit Ryu-Controllern einsetzbar.
3. Die Datenströme werden mithilfe
des Verkehrsgenerators „trafgen“ er-
zeugt. So werden Pakete generiert,
die in gleicher Form in realen Netzen
auftreten. Zeitgleich wird das tatsäch-
lich beobachtete Verhalten der Daten-
ströme für eine spätere Auswertung
aufgezeichnet.
4. Die Verkehrsanalyse führt einen Ab-
gleich des gewünschten und beobach-
teten Netzverhaltens durch und mel-
det das Ergebnis am Frontend.
Die aufgeführten Schritte werden vom
Watchdog-Modul gestartet, sobald Ände-
rungen an der App gespeichert werden.
Basierend auf den Rückmeldungen der au-
tomatisierten Erfolgskontrolle können die
Studierenden ihre App so Schritt für Schritt
verbessern. Besteht eine App die Erfolgs-
kontrolle, ist davon auszugehen, dass das
darin umgesetzte Konzept auf vergleichba-
re Szenarien in der Praxis anwendbar ist.
Beispiel Loadbalancing
Abbildung 3 stellt ein Szenario dar, in dem
Datenströme, die von Nutzersystemen ge-
sendet werden, auf vier gleichartige Ser-
ver verteilt werden sollen. Es dient dazu,
Studierenden zwei Konzepte zu vermit-
teln: den Einsatz von Monitoring-Mecha-
nismen sowie reaktive Flow-Programmie-
rung. Letztere bezeichnet eine SDN-spezi-
fische Behandlung von Datenströmen, bei
der eine App neu auftretende Datenströ-
me analysiert und individuelle Weiterlei-
tungsregeln für diese programmiert.
In der Konfigurationsdatei des Szenarios
legt der Tutor zunächst die Endsysteme
(Server, Nutzersysteme) und SDN Switches
fest. Er beschreibt außerdem, wie diese
Abbildung 2: SDN Cockpit-Modul-Architektur
Verkehrs-generatorWatchdog
SDN COCKPIT
Studierende
Tutor
pro
gra
mm
iere
n
Ba
cken
d
beobachten
auswertenrückmelden
erstellen
ausführen
überwachen
Fro
nte
nd
Verkehrs-analyse
Benutzer-oberfläche
Netz-emulator
SDN6 Controller
Verkehr
Topologie
Aufgaben-stellung
APP
Szenario
!Externes Werkzeug
SDN Cockpit-Modul
Eingabe/Konfiguration
36
miteinander verbunden sind, indem er ei-
ne Liste der verbindenden Links erstellt.
SDN Cockpit gestattet es, die Datenströ-
me der Nutzersysteme zufällig generieren
zu lassen (Startzeitpunkt sowie IP-Quell-
adresse). Für die Erfolgskontrolle spezifi-
ziert der Tutor, wie groß der Anteil der ge-
wünschten Datenströme an jedem Server
ist (25 Prozent) und welche Toleranzen ak-
zeptabel sind.
Die Datenströme in diesem Szenario wer-
den anhand ihrer IP-Quelladressen identifi-
ziert. Da eine Weiterleitung anhand dieser
Adressen erfolgt und sie zufällig gewählt
werden, sind die für eine gleichmäßige Ver-
teilung benötigten Weiterleitungsregeln
nicht vorhersagbar. Einen festen Regelsatz
einzuprogrammieren würde dazu führen,
dass ein oder mehrere Server zu viele Daten
empfangen würden. Studierende müssen
ihre App daher so konzipieren, dass diese
das Netzverhalten überwacht und dyna-
misch darauf reagiert. Sie können hierzu
auf die abstrakte Sicht des Netzes zurück-
greifen, die der SDN Controller anbietet.
Über die Programmierschnittstelle von Ryu
können Monitoring-Informationen mithil-
fe von FlowStatsRequests für jeden SDN
Switch periodisch abgefragt werden. Die-
se geben Aufschluss über die Datenmenge,
die zu jedem Server gesendet wurde. An-
hand dieser Informationen kann die App
entscheiden, wohin der nächste Daten-
strom weitergeleitet werden muss. Hier-
für wählt sie den Server mit der niedrigs-
ten empfangenen Datenmenge. Die indi-
viduelle Behandlung des nächsten Daten-
stroms erfolgt, indem die App zunächst
dessen IP-Quelladresse ausliest. Der SDN
Controller stellt die dafür benötigten Me-
thoden bereit. Anschließend kann sie Wei-
terleitungsregeln zum ausgewählten Ser-
ver auf Basis dieser Adresse programmie-
ren (reaktive Flow-Programmierung). Insge-
samt kann so eine gleichmäßige Verteilung
innerhalb der Toleranzen zu jedem Zeit-
punkt gewährleistet werden.
| DFN Mitteilungen Ausgabe 94 | Dezember 2018 | CAMPUS
SDN-NETZ
25%
25%
25%
25%
SDN Switch
Datenströme
Nutzersysteme
Die App soll eine gleichmäßige Verteilung der Datenströme erzielen
Server 1
SDN Controller
Server 2
Server 3
Server 4
Abbildung 3: Beispielszenario Loadbalancing
Abbildung 4: SDN Cockpit-Benutzeroberfläche
1. Beschreibung der Topologie und der Aufgabenstellung
4 Informationen zum Ausfüh- rungszustand des Szenarios
5. Kommandozeile zur direkten Inter-
aktion mit dem SDN-Netz während des Ablaufs eines Szenarios
2. Ausgabe der App, um deren Ausführung zu überwachen
3. Zeitlicher Ablauf der gesende-
ten Datenströme sowie das Ergebnis der Verkehrsanalyse
37CAMPUS | DFN Mitteilungen Ausgabe 94 |
SDN Cockpit stellt die in Abbildung 4 dar-
gestellte Benutzeroberfläche zur Verfü-
gung. Diese ist in fünf Bereiche gegliedert.
Indem sowohl der zeitliche Ablauf aller ge-
sendeten Datenströme, als auch die Ausga-
ben der App den Studierenden angezeigt
werden, können sie die Entscheidungen ih-
rer App zur Laufzeit nachvollziehen. Soll-
ten diese fehlerhaft sein, dann gibt die Ver-
kehrsanalyse Aufschluss darüber, welche
Server zu viele, beziehungsweise zu weni-
ge Daten erhalten haben. Werden etwa 85
Prozent aller Datenströme zu einem ein-
zigen Server weitergeleitet, dann wird für
diesen die Anzahl tatsächlich empfange-
ner und erwarteter Pakete angegeben. Au-
ßerdem wird angezeigt, dass die Differenz
außerhalb der akzeptierten Toleranz liegt.
SDN Cockpit bewertet somit automatisiert
die App anhand dieser nachvollziehbaren
Indikatoren.
Erfahrungen
SDN Cockpit wurde am KIT in den Veranstal-
tungen V1 bis V4 (siehe Tabelle 1) erprobt.
Die Rückmeldungen der Teilnehmerinnen
und Teilnehmer fielen in allen Fällen über-
wiegend positiv aus.
Die Akzeptanz von SDN Cockpit zeigt unter
anderem der direkte Vergleich zwischen
V0 und V2. V0 griff direkt auf Werkzeuge
wie mininet und Ryu zurück – keiner der
Studierenden löste die abschließende, frei-
willige Aufgabe. Die Einstiegshürde wur-
de für diesen Zweck als zu hoch bewertet.
In V2 stand SDN Cockpit zur Verfügung: 65
Prozent der teilnehmenden Studierenden
lösten erfolgreich die freiwillige Aufgabe.
In V1 bis V3 erhöhte sich der Anspruch der
Aufgabenstellungen. Es zeigte sich, dass
SDN Cockpit für komplexere Aufgaben sehr
gut einsetzbar ist.
Auch die Teilnehmer von V4 bewerteten
die Nutzung von SDN Cockpit als positiv.
Hier stand im Vordergrund, einer Gruppe
von Netzadministratoren „hands-on expe-
rience“ mit SDN zu vermitteln. Für diesen
Nutzerbereich sind weitere Veranstaltun-
gen geplant.
In V3 wurde eine anonyme Umfrage durch-
geführt, in der die Teilnehmer verschie-
dene Aspekte von SDN Cockpit bewerten
konnten. Die Umfrage ist online verfügbar.
tinyurl.com/sdncockpit-eval2018
Auf die Frage, ob die Entwicklung von Apps
durch den Einsatz von SDN Cockpit ver-
einfacht wurde, antworteten elf der zwölf
Befragten mit einer sehr positiven Wer-
tung (6 oder 7 auf einer Skala von 1 bis 7).
Ähnlich positiv wird die Nutzung von SDN
Cockpit anstelle der direkten Nutzung der
Werkzeuge mininet/Ryu/trafgen bewertet.
Obwohl diese Zahlen aufgrund der ge-
ringen Stichprobengröße und der Unter-
schiede in den einzelnen Veranstaltungen
nicht als repräsentativ bezeichnet werden
können, zeigt sich doch deutlich, dass SDN
Cockpit akzeptiert und als Vereinfachung
angesehen wird.
Open Source
github.com/kit-tm/sdn-cockpit
Die aktuelle Version von SDN Cockpit ist
als Open-Source-Projekt frei verfügbar
und erweiterbar. Ebenso finden sich dort
Szenarien für Aufgabenstellungen unter-
schiedlicher Komplexität (z. B. Policy-ba-
siertes Routing, Angriffe auf die Netzinfra-
struktur oder Service Function Chaining). M
Veranstaltung Teiln. Zielstellung
V0 Praktikum SDN (SS 17) 13 Vertiefung von SDN-Kenntnissen (ohne SDN Cockpit) (4 aufeinander aufbauende Aufgaben, letzte freiwillig)
V1 Vorlesung Telematik (WS 17/18) 10+ Freiwilliges Homework
V2 Praktikum Praxis der Telematik (WS 17/18)
17 Vertiefung von SDN-Kenntnissen (3 aufeinander aufbauende Aufgaben, letzte freiwillig)
V3 Praktikum Software-basierte Netze (SS 18)
14 Vermittlung von Detailkenntnissen (16 Aufgaben mit steigendem Schwierigkeitsgrad)
V4 Interner Workshop mit dem Projekt bwNet100G+ (WS 17/18)
5 Netzadministratoren grundlegende SDN-Konzepte vermitteln
Tabelle 1: Einsatz von SDN Cockpit am Karlsruher Institut für Technologie
[1] Kreutz, D., Ramos, F. M., Ve-
rissimo, P. E., Rothenberg, C. E.,
Azodolmolky, S., & Uhlig, S. (2015).
Software-defined networking: A
comprehensive survey. Procee-
dings of the IEEE, 103(1), 14-76.
[2] Open Network Foundation,
OpenFlow Specification V1.3.1, Palo
Alto, CS, USA, 2012
[3] Lantz, B., Heller, B., & McKeown,
N. (2010). A network in a laptop:
rapid prototyping for software-
defined networks. In Proceedings
of the 9th ACM SIGCOMM Work-
shop on Hot Topics in Networks (p.
19). ACM
[4] Ryu SDN Framework. https://
osrg.github.io/ryu/, 2018. (Zugegrif-
fen am 31.08.2018).
LITERATUR
38
DFN-AAI und Single Sign-On
Technisch gesehen geht es bei der DFN-
AAI um eine bestimmte Spielart des web-
basierten Single Sign-On (Web-SSO). Die-
ses Verfahren erlaubt es Anwendern, sich
mit den Benutzer-Credentials, mit denen
sie bei ihrer Heimateinrichtung registriert
sind (in der Regel Nutzername und Pass-
wort), bei internen und externen Diens-
ten anzumelden (Authentifizierung) und
– entsprechende Berechtigungen voraus-
gesetzt (Autorisierung) – diese zu nutzen.
Die hierfür erforderliche Infrastruktur, AAI
(Authentication and Authorization Infra-
structure), wird traditionell im Rahmen na-
tionaler Föderationen realisiert und in der
Regel von den jeweiligen Forschungsnet-
zen betrieben, in Deutschland ist dies der
DFN-Verein.
Die technische Grundlage für solche Infra-
strukturen bildet der Austausch von Meta-
daten, in denen die Identity Provider (IdP)
der an der AAI teilnehmenden Heimator-
ganisationen (Bildungs- und Forschungs-
einrichtungen) und die Service Provider
(SP) der teilnehmenden Dienstanbieter
(Content-Provider, eLearning-Plattformen,
wissenschaftliche Dienste, etc.) registriert
sind. Bei den in den Metadaten hinterleg-
ten Informationen handelt es sich sowohl
um administrative (Organisation, Kontakt-
daten) als auch um technische Daten (Ser-
vice-Endpunkte, Zertifikate, etc.), die zur
Kommunikation der Entities (IdP, SP) un-
tereinander erforderlich sind. Als Standard
hat sich hier flächendeckend SAML (Secu-
rity Assertion Markup Language) durchge-
setzt. Die Aufgabe der jeweiligen Föderati-
on ist es, diese Datensätze zu pflegen, ak-
tuell zu halten und sicherzustellen, dass
innerhalb der Föderation ein sicherer und
vertrauenswürdiger Austausch von Infor-
mationen stattfindet. Das technische Rück-
grat einer solchen Föderation bilden somit
die vom Föderationsbetreiber aggregier-
ten, validierten und signierten Metadaten.
AAI auf Hochschulebene an der Freien Universität Berlin
Die Entwicklung des Identitätsmanage-
mentsystems und die Einführung einer
AAI an der Freien Universität Berlin sind
sicherlich vergleichbar zu vielen anderen
Hochschulen.
Den Anfang bildete ein schnell wachsendes
Angebot an personalisierten Webdiensten
für Studierende und Beschäftigte. Für die
| DFN Mitteilungen Ausgabe 94 | Dezember 2018 | CAMPUS
DFN-AAI lokal – Single Sign-On an der Hochschule leichtgemachtDie DFN-AAI bietet teilnehmenden Einrichtungen zusätzlich zur Teilnahme an der
nationalen Föderation die Möglichkeit, eine eigene, hochschulseitige AAI-Infrastruktur
zu betreiben. Die hierfür erforderlichen lokalen Metadaten können über die DFN-AAI
Metadatenverwaltung gepflegt werden.
Text: Steffen Hofmann (FU Berlin), Wolfgang Pempe (DFN-Verein)
An der FU Berlin entschloss man sich 2005 zur Einrichtung eines zentralen Identitätsmanagementsystems
39CAMPUS | DFN Mitteilungen Ausgabe 94 |
Anmeldung wurden zunächst lokale dienst-
spezifische Benutzerkennungen verwen-
det. Die Verwaltung dieser Anmeldedaten
erfolgte vom Aufwand und von der Quali-
tät her unterschiedlich gut. Auch für den
1st-Level-Support stellten die diversen Be-
nutzerkennungen eine wahre Herausfor-
derung dar. Es entstand der Wunsch nach
einem Identitätsmanagementsystem für
die gesamte Hochschule, in dem die Be-
nutzernamen und Passwörter sowie wei-
tere Identitätsdaten zentral verwaltet wer-
den. An der Freien Universität Berlin ent-
schloss man sich 2005 im Fahrwasser der
Einführung von SAP Student Lifecycle Ma-
nagement zur Einrichtung eines zentra-
len Identitätsmanagementsystems. Für
die Authentifizierung, Autorisierung und
Provisionierung von Identitätsdaten wur-
den LDAP-Zugriffe (Lightweight Directory
Access Protocol) angeboten. Diese Maß-
nahme reduzierte zwar erfolgreich die
Supportanfragen und die Anzahl der ver-
schiedenen Benutzerkennungen, aber die
Nutzer mussten sich bei jeder Anwendung
erneut anmelden. Außerdem werden bei
diesem Systemaufbau Benutzername und
Passwort zunächst an den jeweiligen Web-
server geschickt, der diese sensiblen Da-
ten dann für die Authentifizierung an LDAP
weiterleitet. Mit dem zunehmenden Erfolg
des zentralen Identitätsmanagementsys-
tems kamen dann auch immer mehr Web-
anwendungen hinzu, deren Wartung und
Pflege, bedingt durch zum Beispiel zeitlich
befristete Projekte, schwer gewährleistet
werden konnten. Allmählich erhöhte sich
das Sicherheitsrisiko durch die direkt mit
LDAP dezentral verwendeten Anmeldeda-
ten. Hinzu kamen Systeme aus Verbund-
projekten, die außerhalb der Hochschule
standen, aber gerne die intern geschütz-
ten LDAP-Server nutzen wollten. Da die-
se externen Anwendungen außerhalb der
Kontrolle der Hochschule liegen, musste
die direkte Anbindung an LDAP aufgrund
diverser Sicherheitsbedenken abgelehnt
werden. Eine Rückkehr zu den dienstspe-
zifischen Anmeldedaten war keine Opti-
on, weil der Prozess der Zentralisierung
mühsam und langwierig war und die hoch-
schulweite einheitliche Kennung durchaus
komfortabel sowohl für die Benutzer als
auch für den Support war und ist.
Mit dem Web-Single Sign-On via SAML lie-
ßen sich die genannten Probleme lösen.
Die Benutzerkennung muss am Identity
Provider pro festgelegten Zeitintervall nur
einmal angegeben werden, um dann an
den verschiedenen teilnehmenden Web-
anwendungen, also den Service Providern
authentifiziert zu werden. Der Benutzer-
name und das Passwort durchlaufen nur
den Identity Provider zu den LDAP-Servern
und ansonsten sorgen XML-Nachrichten,
sogenannte Assertions, sowie Cookies da-
für, dass die Nutzer als authentifiziert aus-
gewiesen werden. Die Metadaten, die die
Basis der Vertrauensstellung zwischen den
Providern darstellen und unter anderem
Zertifikate für die Verschlüsselung und Si-
gnaturen enthalten, wurden an der Freien
Universität Berlin direkt in einer XML-Da-
tei per Hand gepflegt. Auch externe Ser-
vice Provider wurden zunächst in die hoch-
schulinternen Metadaten aufgenommen
und konnten so an der AAI teilnehmen. Es
wuchs aber auch zunehmend der Bedarf,
dass auch Benutzerkennungen anderer
Hochschulen und wissenschaftlicher Ein-
richtungen für Service Provider an der Frei-
en Universität Berlin genutzt werden kön-
nen. Auch Verlage entwickelten ein großes
Interesse, weg von der IP-basierten Authen-
tifizierung zur SAML-Authentifizierung um-
zustellen. Es wurden zwischen den Betrei-
bern von Identity und Service Providern
munter Metadatensätze ausgetauscht.
Hinsichtlich des Datenschutzes und der
Schemata für die zu übertragenden Attri-
bute wie Anzeigename, E-Mail etc. bestand
ein hoher Kommunikationsaufwand. Die
Qualität und Aktualität der Zertifikate, die
elementar für die Sicherheit in einer SAML-
Infrastruktur sind, differierten sehr stark.
Mit der Einführung der DFN-AAI im Jahr
2007 wurde zum Glück ein bundesweites
Rahmenwerk und die notwendige Infra-
struktur geschaffen. Die Freie Universi-
tät unterschrieb 2007 als zweite deutsche
Hochschule den Vertrag zur Teilnahme an
der DFN-AAI. Der Identity Provider sowie
ausgewählte Service Provider wurden in
die Metadaten der DFN-AAI-Föderation auf-
genommen und damit in Deutschland nutz-
bar. In den Anfängen der DFN-AAI wurden
XML-Dateien mit den Metadatensätzen an
SP = Service ProviderIdP = Identity Provider
IdM / Nutzer-verzeichnis
Heimateinrichtung
NutzerIn
Dienst
Metadaten
Anwendung
SAML2Security AssertionMarkup Language
Browser
Schematische Darstellung der Funktionsweise SAML-basierter Kommunikation
40 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | CAMPUS
die AAI-Hotline geschickt. Zugelassen wa-
ren und sind bis heute nur Zertifikate mit
bestimmten Mindestvoraussetzungen und
von bestimmten vertrauenswürdigen Aus-
stellern wie der DFN-PKI. Für die Aktuali-
tät der Zertifikate waren die teilnehmen-
den Einrichtungen selbst verantwortlich.
Metadatenverwaltung des DFN-Vereins
2008 führte der DFN-Verein eine Onlinean-
wendung zur Pflege der AAI-Metadaten für
die verschiedenen bundesweiten Föderatio-
nen ein. Neben den eigentlichen elementa-
ren Metainformationen lassen sich hierüber
auch Titel und Beschreibungen zu den Provi-
dern sowie Kontaktdaten zu den Betreibern
pflegen. Über auslaufende oder nicht mehr
sichere Zertifikate werden die Betreiber per
E-Mail informiert und auch Folgezertifika-
te für einen Zertifikatswechsel lassen sich
einfach hinzufügen. Über ein Ampelsystem
wird übersichtlich angezeigt, ob bei einem
Provider Daten angepasst werden müssen.
Parallel zu den hochschulübergreifenden
Providern mussten zunächst aber noch die
hochschulinternen lokalen Teilnehmer per
Hand gepflegt und überwacht werden.
Seit Herbst 2010 ermöglicht die Metada-
tenverwaltung des DFN-Vereins die Erstel-
lung und Pflege eines lokalen Metadaten-
satzes pro teilnehmender Einrichtung. Die-
ses Aggregat enthält neben dem IdP der
Einrichtung alle lokalen Service Provider
– das heißt solche, die nur einrichtungsin-
tern genutzt werden. Dadurch, dass diese
Service Provider lediglich den Identity Pro-
vider der jeweiligen Einrichtung „kennen“
und die lokalen SP nicht nach außen, das
heißt zur Föderation hin, sichtbar sind, ist
eine missbräuchliche bzw. irrtümliche Nut-
zung solcher Dienste durch Außenstehen-
de ausgeschlossen. Als zusätzliche Maß-
nahme lässt sich der Zugriff auf die loka-
len Metadaten auf bestimmte IP-Berei-
che einschränken. Die Freie Universität
Berlin übertrug 2010 die rund 130 lokalen
Service Provider und Instanzen von Iden-
tity Providern in die zentrale Metadaten-
verwaltung der DFN-AAI und pflegt diese
seitdem ausschließlich über dieses kom-
fortable Werkzeug.
Die Anforderungen an die lokalen Meta-
daten sind dieselben wie an die der DFN-
AAI Produktivföderation. Es kommen also
dieselben Validierungsregeln und Zertifi-
kat-Checks zum Einsatz, sodass zum Bei-
spiel die Betreiber lokaler Service Provider
ebenfalls rechtzeitig über demnächst ab-
laufende Zertifikate in Kenntnis gesetzt
werden. Auf diese Weise werden die SP-
Verantwortlichen auch auf Punkte hin-
gewiesen, die zwar vom Standard nicht
zwingend vorgeschrieben sind, die aber
für die User Experience und die Interope-
rabilität mit dem Heimat-IdP durchaus re-
levant sind, zum Beispiel die Deklaration
der vom SP benötigten Attribute.
Sollte jemals der Bedarf entstehen, einen
lokalen SP auch Angehörigen anderer Ein-
richtungen zugänglich zu machen, so ist
dies mit wenigen Mausklicks und einem
kleinen Eingriff in die SP-Konfiguration
schnell erledigt.
Aktuell (Mitte September 2018) nehmen et-
wa die Hälfte der 266 aktiv an der DFN-AAI
teilnehmenden Einrichtungen diese Opti-
on wahr. Diese 131 Einrichtungen betrei-
ben insgesamt 894 lokale SP, also beina-
he doppelt so viele SP wie in der DFN-AAI
Produktivföderation (472).
Freie Universität Berlin: Zentraleinrichtung für Datenverarbeitung (ZEDAT)
Foto © Bettina Fink
41CAMPUS | DFN Mitteilungen Ausgabe 94 |
Nächste Schritte und Ausblick
Ein zentrales Identitätsmanagementsys-
tem an einer Hochschule kann das Pro-
blem der diversen Benutzerkennungen lö-
sen. SAML verringert deutlich die Anzahl
der Eingaben der Anmeldedaten und ent-
schärft die Sicherheitsprobleme, die durch
andere Infrastrukturen wie mit der mehr-
fachen Direktanbindung an LDAP entste-
hen. Bei einer zentralen Benutzerkennung
reicht es einem Angreifer in der Regel aus,
an den Benutzernamen und das Passwort
zu gelangen, um einen Zugriff auf diverse
Systeme zu erhalten. Bei Bankgeschäften
werden daher schon seit Jahren zweite Fak-
toren wie Transaktionsnummern für die Au-
thentifizierung eingesetzt. Meist kommt
das Prinzip Wissen (beispielsweise Benut-
zername/Passwort) und Besitz (zum Bei-
spiel Hardwaretoken) zum Einsatz. Viele
Hochschulen in Deutschland erweitern
deshalb ihre Identity Provider um eine
Zwei-Faktor-Authentifizierung (2FA).
Neben 2FA ist noch ein zweiter Trend zu
beobachten. Viele Apps in Smartphones
verwenden im Hintergrund REST-Servi-
ces, bei denen in der Regel leichtgewich-
tige JSON-Nachrichten (JavaScript Object
Notation) sowie HTTP-Header und keine
komplexen XML-Nachrichten ausgetauscht
werden. Passend hierzu wird seit 2006 das
Protokoll OAuth (Open Authorization) ent-
wickelt. Basierend auf der OAuth-Version
2.0 wird mit der Spezialisierung dieses Pro-
tokolls eine Authentifizierungsschicht an-
geboten, die vergleichbare Funktionalitä-
ten zu SAML 2.0 anbietet. Die Rede ist von
OpenID Connect (OIDC). OIDC wird aktuell
als Ablöse von SAML 2.0 gehandelt. Ver-
mutlich werden SAML 2.0 und OIDC in den
nächsten Jahren in friedlicher Koexistenz
neben- und miteinander leben. So soll der
Shibboleth SAML Identity Provider in den
nächsten Versionen eine Erweiterung er-
halten, die die parallele Verwendung der
beiden Standards ermöglicht. M
0
100
200
300
400
500
600
700
800
900
1000
09
.09
.10
09
.03
.11
09
.09
.11
09
.03
.12
09
.09
.12
09
.03
.13
09
.09
.13
09
.03
.14
09
.09
.14
09
.03
.15
09
.09
.15
09
.03
.16
09
.09
.16
09
.03
.17
09
.09
.17
09
.03
.18
09
.09
.18
Produktive Entities in der DFN - AAI
IdP SP lokale SP
0
100
200
300
400
500
600
700
800
900
10000
9.0
9.1
0
09
.03
.11
09
.09
.11
09
.03
.12
09
.09
.12
09
.03
.13
09
.09
.13
09
.03
.14
09
.09
.14
09
.03
.15
09
.09
.15
09
.03
.16
09
.09
.16
09
.03
.17
09
.09
.17
09
.03
.18
09
.09
.18
Produktive Entities in der DFN - AAI
IdP SP lokale SP
Entwicklung lokale SP seit 2010 – zum
09.09.2018 waren 894 lokale SP an 131
Einrichtungen registriert
RECHT | DFN Mitteilungen Ausgabe 94 | 43
RechtFragen ohne Ende –
20 Jahre Forschungsstelle Recht im DFN
von Annette Rülke mit Thomas Hoeren
Das Netz und die Justiz
von Christine Legner-Koch
EU-Datenschutz-Grund verordnung – und die
Welt dreht sich weiter
von Jan K. Köcher
Frei – aber nicht grenzenlos!
von Armin Strobel
44 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | INTERVIEW
Fragen ohne Ende – 20 Jahre Forschungsstelle Recht im DFN
Seit 20 Jahren forschen Juristinnen
und Juristen der Forschungsstelle
Recht im DFN zu rechtlichen Frage-
stellungen rund um die Nutzung des
Deutschen Forschungsnetzes und
seiner Dienste. Mit ihren Handlungs-
empfehlungen und Stellungnahmen
zu aktuellen Gesetzesvorhaben
geben sie der DFN-Community wert-
volle Hilfestellungen bei der Umset-
zung der Ergebnisse in die Praxis.
Im Gespräch verrät Prof. Dr. Thomas
Hoeren, Leiter des DFN-Projekts an
der Westfälischen Wilhelms-Uni-
versität in Münster, wie alles anfing
und worin die aktuellen Herausfor-
derungen bestehen.
Foto © Peter Grewer
Lieber Herr Hoeren, 20 Jahre Forschungsstelle Recht, müsste
da inzwischen nicht alles Rechtliche zum Netz geklärt sein?
Das Gegenteil ist der Fall. Wir haben noch immer sehr viele of-
fene Rechtsfragen zu Netzthemen, mehr denn je. Und ein Ende
ist auch nicht in Sicht.
Sehen Sie sich allein in
Deutschland – von Eu-
ropa ganz zu schwei-
gen – die Rechtspre-
chung an. Da hatten wir
vor 20 Jahren gerade
mal um die 20 Urteile. Heute sind wir jährlich im vierstelligen
Bereich. Schon die schiere Menge an Informationen und The-
men überfordert viele Mitarbeiter in den Einrichtungen. Kom-
plexität und Widersprüchlichkeiten kommen erschwerend
hinzu. Und hier hat die Forschungsstelle Recht im DFN nach
wie vor die wichtige Aufgabe, Informationen zu strukturieren,
zu filtern, zu bewerten und sie dann so einfach verständlich
wie möglich für die Teilnehmer am Deutschen Forschungsnetz
aufzubereiten.
Sie sprachen gerade von der Zeit vor 20 Jahren. Da wurde die
Forschungsstelle Recht als ein etwas ungewöhnliches Projekt
gegründet. Wie kam das zustande?
Mitte der 90er Jahre lehrte ich noch an der Uni Düsseldorf. Das
Thema Internetrecht war damals noch jung, aber hochinter-
„Viele offene Rechts-
fragen – und ein Ende ist
nicht in Sicht.“
45INTERVIEW | DFN Mitteilungen Ausgabe 94 |
essant, und ich hatte mich damit schon länger beschäftigt. In
diese Zeit fiel ein wichtiges strafrechtliches Verfahren, der Fall
„CompuServe“. Strafrechtliche Verfahren sind immer sehr hei-
kel, denn sie betreffen ja ganz direkt einzelne Personen. Im
Fall des Internetdienstanbieters CompuServe handelte es sich
um den damaligen Geschäftsführer, der wegen der Verbrei-
tung pornografischer Schriften angeklagt war. Die entschei-
dende Frage im Verfahren war, ob er als Geschäftsführer eines
Einwahldienstes für im Netz abrufbare strafbare Inhalte ver-
antwortlich gemacht werden konnte. Dass diese Inhalte über
jeden anderen Einwahldienst auch abrufbar waren - was dann
schlussendlich zu einem Freispruch für ihn führte - ließ bei al-
len Netzdienstleistern, auch beim DFN-Verein, die Alarmglo-
cken schrillen. In dieser aufgeheizten Situation kam der dama-
lige Geschäftsführer des DFN-Vereins Klaus-Eckart Maass auf
mich zu und bat um eine rechtliche Einschätzung zu den gene-
rellen Verantwortlichkeiten im Netz. Dabei wurde sehr schnell
klar, dass eine kontinuierliche Auseinandersetzung mit recht-
lichen Fragen rund um die Netznutzung dringend gebraucht
wurde. Hieraus entstand zunächst eine Zusammenarbeit in
kleinerem Umfang, etwas später die Forschungsstelle Recht.
Wie haben sich die Themen im Laufe der Jahre
entwickelt?
Man kann die Entwicklungsgeschichte in drei Phasen eintei-
len. Wir begannen mit ganz grundlegenden Fragen, insbeson-
dere dazu, welches Recht im Web überhaupt Anwendung fin-
det und an welcher Stel-
le Gesetze geschaffen
werden mussten. Als
Vorreiter für ganz Eu-
ropa war seinerzeit der
damalige Bundesminis-
ter für Bildung, Wissen-
schaft, Forschung und Technologie Jürgen Rüttgers sehr ak-
tiv. In der zweiten Phase war uns klar, dass das Internet kein
rechtsfreier Raum ist, und wir fragten uns, wie denn nun die
Gesetze anzuwenden sind. Vieles war in dieser Zeit schon klug
gelöst worden, aber die Politik griff und greift in den letzten
Jahren an vielen Stellen wieder verändernd ein und wir müs-
sen in der jetzigen dritten Phase neu über Recht und Rechts-
anwendung nachdenken. Vieles wird dadurch kompliziert,
dass wir europaweit denken müssen und dass die Aktivitäten
amerikanischer Firmen wie Google und Facebook Grundlage
vieler maßgeblicher Entscheidungen sind, die auch Hochschul-
oder Forschungseinrichtungen betreffen.
Was sind denn zurzeit die drängendsten Fragen?
Es gibt mehrere Fragen, die die Institutionen im Augenblick
besonders umtreiben: Eine ist das Datenschutzrecht. Die Ein-
führung der EU-Datenschutz-Grundverordnung im Mai 2018
führte zu sehr viel Unklarheit. Die Einrichtungen wissen oft
nicht einmal, was denn nun für sie eigentlich gilt. Selbst die
Aufsichtsbehörden, die es wissen sollten, geben widersprüch-
liche Auskünfte. Das macht es nicht einfacher. Ein anderes
großes Thema sind immer noch die Haftungsfragen beispiels-
weise bei der Bereitstellung von Plattformen. Insbesonde-
re bei den Angeboten von fremden Inhalten gibt es sehr viel
Verunsicherung.
In der Forschungsstelle Recht arbeiten besonders viele junge
Wissenschaftlerinnen und Wissenschaftler. Wie wirkt sich
das auf die Arbeit aus?
Das ist ein Segen. In unserem Alter kennen wir vieles ja gar
nicht mehr. Ständig gibt es etwas Neues und das muss ich
mir dann von den Kolleginnen und Kollegen, für die das alles
selbstverständlich ist, erklären lassen. Das führt zu ganz groß-
artigen neuen Ideen und Themen. Und gerade der personelle
Wechsel – die meisten Juristinnen und Juristen bleiben für
zwei bis drei Jahre bis kurz vor der Promotion – bringt immer
wieder neue Kreativität in die Gruppe.
Eine letzte persönliche Frage: Nach 20 Jahren Forschungsstel-
le Recht, haben Sie da noch Lust auf weitere Jahre?
Ein ganz klares Ja. Wenn Sie die unglaubliche Resonanz sehen,
die wir bekommen, gerade auch auf unsere Vortragsveranstal-
tungen, da kann die Bedeutung der Forschungsstelle Recht
gar nicht hoch genug
eingeschätzt werden.
Und das Schöne an der
Arbeit ist, dass sich Aka-
demisches und Praxis
so wunderbar ergän-
zen. Die Forschungsstel-
le Recht forscht im wahrsten Sinne des Wortes. Ideengeber für
unsere Themen sind oft die wirklich drängenden praktischen
Fragen aus den Hochschulen und Forschungseinrichtungen.
Diese gegenseitigen Impulse sind etwas ganz Besonderes und
das macht die Arbeit in der Forschungsstelle Recht für mich
heute und auch in der Zukunft extrem spannend.
Das Interview führte Annette Rülke
„Uns war klar, dass das
Internet kein rechtsfreier
Raum ist.“
„Ideengeber für Themen
sind praktische Fragen aus
den Einrichtungen.“
46 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | RECHT
Der Arbeitgeber überprüft mithilfe eines sogenannten Keyloggers, ob und
wie oft ein Mitarbeiter den dienstlichen PC privat nutzt. Er stellt im kon-
kreten Fall fest, dass die Privatnutzung in der Arbeitszeit stattfindet. Der
Beschäftigte erhält daraufhin eine außerordentliche Kündigung, da die Pri-
vatnutzung nicht gestattet war. Der Arbeitnehmer lässt die Wirksamkeit
der Kündigung durch eine Klage vor dem Arbeitsgericht überprüfen. Die-
ses stellt fest, dass die Kündigung unwirksam ist, da der Arbeitgeber gegen
datenschutzrechtliche Regelungen verstoßen hat und somit die gewonne-
nen Erkenntnisse im arbeitsrechtlichen Verfahren nicht als Beweismittel
dienen können.
In einer Berliner U-Bahn-Station verunglückt ein 15-jähriges Mädchen. Die
Eltern möchten Näheres über die Umstände ihres Todes erfahren und erhof-
fen sich von der Einsichtnahme in den Facebook-Account ihrer Tochter wei-
tere Informationen. Diese verwehrt ihnen Facebook jedoch. Über mehrere
Instanzen fordern sie den Zugang zum Konto, mit dem Ergebnis, dass das
Landgericht einen Anspruch bejaht, das Kammergericht ihn jedoch mit Ver-
weis auf das Telekommunikationsgeheimnis ablehnt. Der Bundesgerichts-
hof hebt das Urteil schließlich wieder auf und bestätigt einen erbrechtli-
chen Anspruch auf digitale Kommunikationsinhalte.
Diese Sachverhalte zeigen, welche rechtlichen Fragen durch die Nutzung
des Internets entstehen und wie wichtig es ist, dafür verbindliche Lösun-
Das Netz und die Justiz
Die technische Entwicklung des
Internets hat unser Leben grund-
legend verändert, wirft Fragen
auf und sorgt für neue juristische
Fälle, die es zuvor einfach nicht
gab. Besteht ein erbrechtlicher
Anspruch auf digitale Kommuni-
kationsinhalte? Kann die Privat-
nutzung des Dienst-PCs mithilfe
eines Keyloggers durch den Ar-
beitgeber rechtlich nachgewie-
sen werden? Das Internetrecht
als Schnittmenge aller Rechtsge-
biete, die im Netz Anwendung fin-
den, muss Lösungen für all diese
Fragen finden und dabei verbind-
liche Regelungen treffen. Dafür
bietet die Forschungsstelle Recht
im DFN Lehr- und Forschungs-
einrichtungen einen einmaligen
Service an.
Foto © Luis Cerdeira / Stocksy
Text: Christine Legner-Koch (DFN-Verein)
47RECHT | DFN Mitteilungen Ausgabe 94 |
gen zu finden. Seit nunmehr 20 Jahren betreibt und fördert die
Forschungsstelle Recht mit fünf bis sechs juristischen Mitarbei-
terinnen und Mitarbeitern Grundlagenforschung rund um den
Einsatz von Informations- und Kommunikationstechnologien.
Anwendung unterschiedlicher Rechtsgebiete
Das Internetrecht entspricht einer Teilmenge verschiedener
Rechtsgebiete. Es setzt sich unter anderem aus dem Telekom-
munikationsrecht, Datenschutzrecht, Informationsrecht, IT-Haf-
tungsrecht, Strafrecht und Urheberrecht zusammen, wobei das
Datenschutzrecht auch in andere Gebiete, wie zum Beispiel das
Arbeitsrecht, mit einfließt. Aufgrund des stetigen technischen
Fortschritts im digitalen Bereich und der damit verbundenen
rechtlichen Neuerungen ist die Rechtsprechung hier einem lau-
fenden Wandel unterworfen. In Zeiten der Digitalisierung beein-
flusst das unser tägliches Leben und bedarf deshalb verbindli-
cher Regeln: So mussten beispielsweise die rechtlichen Vorga-
ben im Datenschutzrecht in den vergangenen Jahren erweitert
und verschärft werden, um ausreichenden Schutz zu gewähr-
leisten. Seit dem Inkrafttreten der EU-Datenschutz-Grundverord-
nung wird Hochschulen und Forschungseinrichtungen eine er-
weiterte Dokumentationspflicht auferlegt, die Auskunftsrechte
von Personen wurden gestärkt und die Rolle des behördlichen
Datenschutzbeauftragten hat sich entscheidend gewandelt.
Die Publikationen und Services der Forschungs-stelle Recht im Überblick
Zu den Aufgaben der Forschungsstelle Recht gehörte von Anfang
an die rechtliche Einordnung und Bewertung neuartiger techni-
scher Kommunikations- und Datenverarbeitungsmöglichkeiten.
Die Fragestellungen dazu stammen direkt aus der Praxis und sind
Gegenstand der Forschung. So sind Rechenzentren beispielswei-
se Angriffsfläche für Straftaten. In Betracht kommen das Ausspä-
hen von Daten (§ 202a StGB), Datenveränderung (§ 303a StGB),
Computerbetrug (263a StGB) oder Fälschung beweiserheblicher
Daten (§ 269 StGB). Oftmals bestehen Auskunftsansprüche von
Strafverfolgungsbehörden. Für den Umgang mit diesen rechtli-
chen Problemen hat die Forschungsstelle Recht Handlungsemp-
fehlungen erarbeitet, die auf der Internetseite des DFN-Vereins
jederzeit nachgelesen werden können. Dabei erfolgt eine stetige
Auswertung neuer Beiträge aus Literatur und Rechtsprechung.
Änderungen in der Gesetzgebung werden ebenso einbezogen
und durch Vorträge, den DFN-Infobrief und im Falle konkreter
Anfragen vermittelt.
Die Forschungsstelle Recht erarbeitet monatlich drei Beiträge
für den Infobrief Recht, die auf der Webseite des DFN-Vereins
elektronisch zum Download zur Verfügung gestellt werden. Die
Beiträge enthalten aktuelle Entscheidungen und Gesetzesän-
derungen, die im Internetrecht relevant sind und insbesonde-
re für Hochschulen und wissenschaftliche Einrichtungen von
Bedeutung sind. Dazu gehören beispielsweise die Abschaffung
der Störerhaftung für WLAN-Betreiber, die Frage, ob IP-Adressen
als personenbezogene Daten einzuordnen sind sowie die Ände-
rungen im Urheberrechtsgesetz durch das Urheberrechts-Wis-
sensgesellschafts- Gesetz. Diese und andere Themen sorgten in
den vergangenen Jahren unter Juristen für Diskussionen. Für in-
teressierte Leserinnen und Leser gibt es außerdem einen jährli-
chen Sammelband des Infobriefs Recht, der sämtliche Beiträge
des Vorjahres zusammenfasst und als Printausgabe erscheint.
Vorträge und Schulungsveranstaltungen finden beispielswei-
se auf der Betriebstagung, dem Forum Rechtsfragen, bei dem
Rechtsseminar der Mitgliederversammlung sowie auf dem Kanz-
lerforum statt. Auch dabei werden aktuelle Themen der Recht-
sprechung und Gesetzgebung behandelt. Schließlich findet eine
ständige Erweiterung und Anpassung der Online-Dokumente im
Webauftritt des DFN-Vereins statt. Hier werden Leitfäden, Hand-
lungsempfehlungen, Stellungnahmen, Mustertexte, Hintergrund-
informationen sowie Basisdokumente zur Verfügung gestellt.
In den vergangenen Jahren wurden etwa 100 bis 120 rechtliche
Anfragen pro Jahr bearbeitet. Der Umfang und die Komplexität
der einzelnen Anfragen variieren deutlich, teilweise sind es kurze
telefonische Stellungnahmen, in anderen Fällen ist dagegen eine
umfangreichere Ausarbeitung erforderlich. Dabei kann oftmals
auf die Ergebnisse der Grundlagenforschung der Forschungsstel-
le Recht zurückgegriffen werden. Eine Rechtsberatung im Einzel-
fall kann von der Forschungsstelle Recht nicht geleistet werden.
Der Service der Forschungsstelle Recht hat sich über einen Zeit-
raum von 20 Jahren etabliert und stellt für Hochschulen und wis-
senschaftliche Einrichtungen eine wertvolle Unterstützung dar.
Da durch die technischen Entwicklungen weiterhin zahlreiche
ungelöste rechtliche Probleme aufgeworfen werden, hat die Ar-
beit der Forschungsstelle Recht auch zukünftig zur Klärung be-
stehender Rechtsfragen einen hohen Stellenwert. M
Foto © Luis Cerdeira / Stocksy
Für rechtliche Anfragen an die Forschungsstelle
Recht ist die E-Mail-Adresse: [email protected] zu nutzen.
Bei Interesse am Infobrief Recht oder am Bezug
des Sammelbandes ist der DFN-Verein unter der
E-Mail -Adresse [email protected] der richtige
Ansprechpartner. Weitere Informationen zum Thema
Recht im DFN, erhalten Sie unter folgender Adresse:
https://www.dfn.de/rechtimdfn/
48 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | RECHT
EU-Datenschutz-Grundver-ordnung – und die Welt dreht sich weiterSeit Mai dieses Jahres gilt die EU-Datenschutz-Grundverordnung (DSGVO). Welche
Herausforderungen aber auch Chancen sich dadurch insbesondere für die Hochschu-
len in der Praxis ergeben, erklärt Datenschutzexperte Dr. Jan K. Köcher vom DFN-CERT
in einem ersten Resümee. Seit Jahren berät er Unternehmen, Behörden, Hochschulen
und Forschungseinrichtungen bei der Initialisierung, Durchführung und Weiterent-
wicklung von Datenschutzprojekten.
Foto © XtravaganT / Adobe Stock
Text: Jan K. Köcher (DFN-CERT)
49RECHT | DFN Mitteilungen Ausgabe 94 |
Es sei vorab erwähnt, dass die Welt für
die Hochschulen auch nach dem 25. Mai
2018 nicht untergegangen ist. Was wur-
den nicht alles für Thesen im Vorfeld des
Geltungsbeginns der EU-Datenschutz-
Grundverordnung an virtuelle Türen ge-
schlagen. Man könne Daten nur noch mit
einer Einwilligung verarbeiten, eine nicht
rechtzeitige Auskunft ziehe einen horren-
den immateriellen Schadensersatz nach
sich, es müsse bei einem Studienortwech-
sel stets die Datenübertragbarkeit in ei-
nem gängigen elektronischen Format si-
chergestellt werden, und, und, und ... Die
Weltuntergangspropheten überboten sich
gegenseitig mit apokalyptischen Vorher-
sagen für den Lehr- und Forschungsstand-
ort Deutschland. Nichts von dem ist bisher
eingetreten. Das ist auch nicht verwunder-
lich, weil sich bei nüchterner Betrachtung
gar nicht so viel an den Voraussetzungen
für die Verarbeitung personenbezogener
Daten an Hochschulen verändert hat. Vie-
le Voraussetzungen, die jetzt als Änderun-
gen wahrgenommen werden, existierten
auch bisher schon und wurden oft nicht,
oder zumindest nicht ausreichend, beach-
tet. Auch bisher benötigte man für die Ver-
arbeitung von personenbezogenen Daten
eine Rechtsgrundlage, musste einen ange-
messenen Schutz mit geeigneten techni-
schen und organisatorischen Maßnahmen
sicherstellen, im öffentlichen Verfahrens-
verzeichnis die Betroffenen über die Verar-
beitungen und deren Umfang informieren
und die Ausübung der Betroffenenrechte
ermöglichen.
Durch die Aufmerksamkeit für die DSGVO
sind somit eigentlich nur die bereits beste-
henden und teils erfolgreich verdrängten
Pflichten ins Bewusstsein zurückgekehrt.
Auch wenn nicht unmittelbar Bußgelder
für Datenschutzverstöße drohen, können
erhebliche Datenschutzverstöße die Repu-
tation der betreffenden Hochschule beein-
trächtigen. Dies ist ein empfindlicher Nach-
teil, wenn man bedenkt, dass die Hoch-
schulen untereinander im Wettbewerb um
Forschungsgelder und die besten Studie-
renden stehen. Zudem ist es kein Geheim-
nis, dass Drittmittelgeber schon aufgrund
ihrer eigenen Pflichten deutlich genauer
darauf achten, welche Standards bei der
Forschung mit personenbezogenen Daten
eingehalten werden.
Institutionen sollten deshalb nüchtern ei-
ne Bestandsaufnahme des Istzustands vor-
nehmen und bei Mängeln diese planvoll an-
gehen. Panik ist ebenso unangemessen wie
das Ignorieren von Datenschutzanforde-
rungen. Es gilt Strukturen zu schaffen, die
den vernünftigen Umgang mit personenbe-
zogenen Daten mit modernen Methoden
in Forschung und Lehre in Einklang brin-
gen. An dieser Stelle sei noch einmal deut-
lich gemacht, dass weder die Grundrechte
der Lehr- und Forschungsfreiheit noch das
Grundrecht auf Datenschutz Vorrang ge-
nießen. Dieser Wink richtet sich vornehm-
lich an die Forschenden und Lehrenden,
die den Datenschutz hier und da bislang
als etwas betrachtet haben, was sie mal ir-
gendwann angehen können, wenn etwas
Zeit übrig ist. Statt den Datenschutz als
Bremse oder gar Feind zu betrachten, bie-
tet sich eine Integration des Datenschut-
zes in Forschungsvorhaben an. Innovati-
on bedeutet eben auch, dass die Auswir-
kungen neuer Methoden, Techniken und
Verfahren auf den Menschen mit betrach-
tet werden. Wie bereits erwähnt werden
künftig auch die Mittelgeber aufgrund
eigener Verpflichtungen ein verstärktes
Augenmerk darauf haben, wie es um Si-
cherheit und Datenschutz an der jewei-
ligen Hochschule bestellt ist und dies ge-
gebenenfalls sogar zum Vergabekriteri-
um machen.
Es soll aber nicht verschwiegen werden,
dass es auch Veränderungen mit Rele-
vanz für die Hochschulen durch die DS-
GVO gibt. Veränderungen, die insbeson-
dere die Strukturen der Hochschulen vor
so große Herausforderungen stellen, dass
zur Erfüllung der Anforderungen ein Da-
tenschutzmanagement erforderlich ist,
das die planvolle Umsetzung mit einem
notwendigen System zur kontinuierlichen
Verbesserung verbindet. Da nicht alle Ver-
änderungen in diesem Rahmen im De-
tail vorgestellt werden können, werden
im folgenden fünf elementare Bereiche
herausgegriffen.
Nachweispflichten – vollstän-dige Dokumenta tionen sind dringend notwendig
Es reicht nicht mehr nur aus, dass der Da-
tenschutz eingehalten wird. Auf Anfor-
derung durch die Datenschutzaufsichts-
behörde stehen Verantwortliche in der
Pflicht, nachzuweisen, dass die daten-
schutzrechtlichen Anforderungen einge-
halten werden. Dies ergibt sich aus Art. 5
Abs. 2 und Art. 24 Abs. 1 DSGVO. Vorausset-
zung für diesen Nachweis ist, eine geeigne-
te Dokumentation anzulegen und zu pfle-
gen. Aus dieser muss hervorgehen, welchen
Zwecken sie dient, welche personenbezo-
genen Daten durch wen und wie lange ver-
arbeitet werden und wie die Verarbeitung
geschützt wird. Die initiale Anlage der Do-
kumentation ist jedoch nur eine Moment-
aufnahme, die für die Erfüllung der Nach-
weispflicht wenig Wert ist, wenn nicht die
ständige Anpassung an Veränderungen ge-
währleistet wird. Dies kann nur mit einem
entsprechenden Managementansatz zur
kontinuierlichen Verbesserung gewährleis-
tet werden. Die meisten Hochschulen ver-
fügen noch über kein entsprechendes Da-
tenschutzmanagement. Oftmals ist noch
nicht einmal eine vollständige und aussa-
gekräftige Dokumentation von Verarbei-
tungen und Schutzmaßnahmen vorhanden,
obwohl es auch bisher schon eine Pflicht
zur Führung von Verfahrensverzeichnis-
sen mit vergleichbaren Angaben gab. Im
Falle des Vorhandenseins der bisherigen
Verfahrensverzeichnisse, müssten diese
nur entsprechend den inhaltlichen Anfor-
derungen aus der DSGVO angepasst wer-
den und ein Managementsystem etabliert
werden. Durch die vielfach bestehenden
Mängel bei der Dokumentation kommt
der initiale Aufwand der Ersterstellung
der Dokumentationen jedoch hinzu. Die-
ser ist nicht unerheblich und wird bei ei-
50 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | RECHT
ner angespannten Personalsituation nicht
ohne Weiteres abbildbar sein. An diesem
Aufwand wird aber kein Weg vorbeiführen,
weil wesentliche Pflichten aus der DSGVO
nur mit einer entsprechenden Dokumen-
tation erfüllbar sind.
Überwachen statt umsetzen – die Rolle des behördlichen Datenschutzbeauftragten
Mit Geltung der DSGVO ist der behördliche
Datenschutzbeauftragte der Hochschule
nicht mehr für die Umsetzung des Daten-
schutzes zuständig. Der behördliche Da-
tenschutzbeauftragte soll die Umsetzung
des Datenschutzes überwachen und kann
somit nicht selbst derjenige sein, der den
Datenschutz umsetzt. Anderenfalls würde
er seine eigene Umsetzung überwachen.
Da er in diesem Fall nicht sonderlich ob-
jektiv wäre, verträgt sich jede Lösung, die
in einer Person Umsetzung und Kontrol-
le vereinen möchte, nicht mit den rechtli-
chen Anforderungen der DSGVO. Die über-
wachende Funktion schließt jedoch nicht
aus, dass der behördliche Datenschutzbe-
auftragte beratend tätig wird. Die Gesamt-
verantwortung und die Aufgabe der Um-
setzung der Datenschutzanforderungen
liegen bei der Hochschulleitung. Es müssen
somit auf dieser Ebene die strukturellen
und organisatorischen Voraussetzungen
für eine flächendeckende Einhaltung des
Datenschutzes geschaffen werden. Da die
Verarbeitung von personenbezogenen Da-
ten immer an einen fachlichen Zweck ge-
bunden ist, bietet sich die Delegation der
Pflichten auf die fachlich für eine Verarbei-
tung verantwortlichen Personen an. Dies
ist jedoch zum Scheitern verurteilt, wenn
keine weiteren strukturellen Maßnahmen
zur Unterstützung dieser Personen ergrif-
fen werden. Neben einer zentralen Instanz
mit rechtlichem und technischem Know-
how bietet sich die dezentrale Unterstüt-
zung mit Datenschutzkoordinatoren an,
die entsprechend im Datenschutz fortge-
bildet sind und zugleich die fachlichen An-
forderungen des jeweiligen Bereichs ken-
nen. Daneben muss eine Unterstützung mit
Informationen, Vorlagen, Checklisten und
Standardisierungen erfolgen. Auch der Ein-
satz von Tools kann hierbei hilfreich sein.
Das berechtigte Sicherheitsin-teresse – ein Schwachpunkt?
Für die Verarbeitung personenbezogener
Daten wird im Regelfall eine Rechtsgrund-
lage benötigt. Beispielsweise in den Be-
reichen Studierenden-, Prüfungs-, Lehr-
oder Forschungsverwaltung verarbei-
tet die Hochschule personenbezogene
Daten im Rahmen ihrer Aufgabenwahr-
nehmung im öffentlichen Interesse. Die
Rechtsgrundlage ergibt sich somit zumeist
aus Art. 6 Abs. 1 e) DSGVO zusammen mit
dem Landesdatenschutzgesetz und spe-
ziellen Vorgaben zur Datenverarbeitung
aus den Hochschulgesetzen, Hochschuld-
atenschutzverordnungen oder Hochschul-
ordnungen und -satzungen. Die Einwilli-
gung aus Art. 6 Abs. 1 a) DSGVO oder eine
Verarbeitung zur Durchführung eines Ver-
trags aus Art. 6 Abs. 1 b) DSGVO sind somit
die Ausnahme, weshalb das Recht auf Da-
tenübertragbarkeit aus Art. 20 DSGVO fast
keine Rolle spielt.
Die Einwilligung ist relativ häufig bei For-
schungsvorhaben mit personenbezogenen
Daten anzutreffen. Über die genannten Be-
reiche hinaus sind Hochschulen durch die
Wettbewerbssituation im Hochschulmar-
keting tätig und es werden personenbezo-
gene Daten zu berechtigten Sicherheits-
interessen verarbeitet. Dies sind Aktivitä-
ten, die nicht unmittelbar zur Aufgaben-
erfüllung dienen, sondern diese fördern.
Nähme man nun an, dass Art. 6 Abs. 1 f) DS-
GVO, der eine Verarbeitung aufgrund eines
berechtigten Interesses zulässt, auf Hoch-
schulen generell nicht anwendbar ist, be-
kommt man bei der Rechtfertigung der da-
mit erfolgenden Verarbeitung von perso-
nenbezogenen Daten Probleme. Dabei be-
schränkt sich der Ausschluss in § 6 Abs. 1 f)
DSGVO auf Verarbeitungen, die von Behör-
den in Erfüllung ihrer (behördlichen) Auf-
gaben vorgenommen werden. Dies macht
insofern Sinn, weil sich Behörden für die
Wahrnehmung ihrer behördlichen Aufga-
ben stets auf eine Befugnisnorm stützen
müssen und somit gar kein Raum für ein
Handeln aufgrund eines berechtigten Inte-
resses besteht. Ein genereller Ausschluss
der Anwendung auf Hochschulen würde
aber den falschen Schluss bedeuten, dass
Hochschulen stets behördlich handeln. Bei
dieser Sichtweise müsste man dann aber
den Sinn von Art. 6 Abs. 1 e) DSGVO hinter-Foto © Pavel Ignatov / Adobe Stock
51RECHT | DFN Mitteilungen Ausgabe 94 |
fragen und warum nicht auch dort auf die
Wahrnehmung einer behördlichen Aufgabe
abgestellt wird. Zwar könnte man versu-
chen, die fraglichen Verarbeitungen perso-
nenbezogener Daten auch über Art. 6 Abs.
1 e) DSGVO zu legitimieren. Der Schwach-
punkt liegt aber dort und in den weiteren
Bestimmungen der Hochschul- und Landes-
datenschutzgesetze darin, dass eine Ab-
wägung zwischen z. B. einem berechtigten
Sicherheitsinteresse und der Grundrechte
der durch diese Maßnahme Betroffenen
nicht vorgesehen ist. Dies ist jedoch gera-
de der Kern des Art. 6 Abs. 1 f) DSGVO. Es
spricht somit vieles dafür, dass der Art. 6
Abs. 1 f) DSGVO für solche Fälle außerhalb
der Wahrnehmung behördlicher Aufgaben
und der explizit geregelten Aufgaben der
Hochschulen Anwendung findet und sich
ein Pauschalausschluss von Art. 6 Abs. 1 f)
DSGVO verbietet.
Das Recht auf Auskunft – eine Herausforderung für die Hochschulen
Eine weitere neue Baustelle ist das Recht
auf Auskunft aus Art. 15 DSGVO. Das Recht
auf Auskunft selbst gab es auch bisher in
den deutschen Datenschutzgesetzen. Neu
ist jedoch, dass die betroffene Person eine
kostenlose Kopie aller personenbezogenen
Daten verlangen kann. Sie muss deshalb
grundsätzlich nicht kooperieren, sondern
kann einfach eine Kopie ihrer Daten verlan-
gen. Dazu gehören prinzipiell erst einmal
auch technische Protokolldaten mit Perso-
nenbezug und auch Daten in Backups. Was
in einem Unternehmen vielleicht noch mit
einer Unternehmenssoftware umsetzbar
ist, wird für Hochschulen aufgrund ihrer
inhomogenen Systemlandschaft und der
Anzahl der Mitglieder, Angehörigen und
Ehemaligen zu einer großen Herausforde-
rung. Denn grundsätzlich hat man nur ei-
nen Monat Zeit für die Erfüllung des Aus-
kunftsverlangens. Wenn Daten potenziell
in hunderten von Systemen vorhanden sein
können, sind die Grenzen des Leistbaren
bald erreicht. Zwar sieht die DSGVO im zu-
gehörigen Erwägungsgrund (63) vor, dass
eine Kooperationspflicht des Betroffenen
bei einer großen Menge von Informatio-
nen besteht. Der Begriff der großen Menge
lässt sich jedoch nicht für eine sinnvolle
Anwendung präzisieren. Auch haben die
Länder teils Ausnahmen in Bezug auf Pro-
tokolldaten und lediglich aufbewahrte Da-
ten bestimmt. Hier ist jedoch noch nicht
klar, inwieweit diese Regelungen mit der
DSGVO in Einklang stehen.
Meldepflicht Art. 33 – Sicherheitsvorfälle mit Datenschutzrelevanz
Durch Art. 33 DSGVO wurde eine neue Mel-
depflicht an die Aufsichtsbehörden bei Da-
tenschutzvorfällen eingeführt, die auch die
Hochschulen betrifft. Hierbei geht es um
Sicherheitsvorfälle, bei denen personen-
bezogene Daten betroffen sind. Die Mel-
depflicht besteht aber nur dann, wenn vo-
raussichtlich ein Risiko für die betroffe-
nen Personen existiert. In diesem Fall muss
der Vorfall binnen 72 Stunden an die zu-
ständige Aufsichtsbehörde gemeldet wer-
den. Für Hochschulen bringt dies erhebli-
che organisatorische Anforderungen mit
sich, zumal in der Regel keine 24/7 Bereit-
schaft vorhanden sein wird. Die Abschät-
zung möglicher Folgen eines Vorfalls ist in
der Regel ebenfalls nicht banal und erfor-
dert gegebenenfalls Expertenwissen, das
nicht rund um die Uhr an sieben Tagen die
Woche ad hoc verfügbar ist. Eine Lösung
wäre, einen Vorfall generell zu melden und
auf die Prüfung zu verzichten. Darüber hi-
naus müssen jedoch Melde- und Entschei-
dungswege definiert werden, die eine Er-
kennung, Beurteilung und korrekte Mel-
dung gewährleisten.
Trotz des Eingangsstatements steht so-
mit in den nächsten Jahren noch einiges
an Arbeit an. Über das Land verteilt gibt
es einige Initiativen auf Hochschulebe-
ne, die sich diesen Herausforderungen
annehmen. Es besteht somit die berech-
tigte Hoffnung, dass sich in naher Zeit in
immer mehr Bereichen Best Practices he-
rausbilden werden. M
Foto © lbusca / iStock
52 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | RECHT
Freie Lizenzen können die Nutzung urheberrechtlich geschützter Werke merklich verein-
fachen. Aufgrund der kostenfreien Bereitstellung der Inhalte stellt sich aber immer wieder
die Frage, ob dem Urheber ein Schadensersatzanspruch für den Fall der Verletzung seiner
Rechte am Werk zusteht. Das Oberlandesgericht Köln (OLG Köln) hat mit seinem Urteil vom
13. April 2018 (Az.: 6 U 131/17) diese Frage im Einklang mit der vorherigen Rechtsprechung
beantwortet. Freie Lizenzen schließen Rechtsansprüche im Fall der Rechtsverletzung nicht
aus, jedoch kann der Schadensnachweis im Einzelfall problematisch sein.
Foto © rawpixel/unsplash.com
Text: Armin Strobel (Forschungsstelle Recht im DFN)
Frei – aber nicht grenzenlos!Die Frage nach Schadensersatz bei der Verletzung einer Creative Commons-Lizenz – ein
Urteil des OLG Köln.
53RECHT | DFN Mitteilungen Ausgabe 94 |
I. Freie Lizenzen und die Berechnung des Schadensersatzes
Die Nutzung von urheberrechtlich geschützten Werken erfolgt in
der Regel auf Grundlage einer Lizenzierung. Dabei ist der Begriff
der Lizenz unglücklich gewählt. Das deutsche Recht kennt den
Lizenzierungsbegriff in der Form nicht, sondern spricht lediglich
von der Einräumung von Nutzungsrechten. Nichtsdestotrotz hat
sich in der Umgangssprache aber auch in der Fachliteratur der Li-
zenzbegriff eingebürgert. Die Formulierung kann daher verwen-
det werden, wenn die dahinterstehende Bedeutung bekannt ist.
Im Rahmen der Lizenzierungspraxis erfreuen sich Creative Com-
mons-Lizenzen (CC-Lizenzen) und andere freie Lizenztypen immer
größerer Beliebtheit.[1] Interessenten können dank ihrer Hilfe
ohne langwierige und komplizierte Verhandlungen über die Ein-
räumung von Nutzungsrechten mit dem Rechteinhaber und ohne
an die teilweise strikten Vorgaben von gesetzlichen Erlaubnissen
gebunden zu sein, urheberrechtlich geschützte Werke nutzen.
Das bedeutet aber nicht, dass an die Nutzung so lizenzierter Wer-
ke keinerlei Bedingungen geknüpft sind. Bei freien Lizenzen han-
delt es sich vielmehr um vorgefertigte Lizenzvorgaben, die regeln,
unter welchen Bedingungen ein urheberrechtlich geschütztes
Werk verwendet werden darf. Werden diese Bedingungen erfüllt,
ist keine gesonderte Erlaubnis des Rechteinhabers erforderlich
und das geschützte Werk kann im Rahmen der erlaubten Gren-
zen verwendet werden. Mit anderen Worten: Freie Lizenzen ver-
einfachen lediglich die Rechteeinräumung bei urheberrechtlich
geschützten Werken, machen diese aber nicht obsolet.
Ein Verstoß gegen die Lizenzbedingungen führt damit aber au-
tomatisch zum Wegfall der Rechteeinräumung und damit zu ei-
ner Rechtsverletzung im Sinne des Urheberrechts.
Wird eine solche festgestellt, hat der Rechteinhaber nach § 97
Abs. 2 Urheberrechtsgesetz (UrhG) die Möglichkeit, Schadenser-
satz geltend zu machen. Sind alle Anspruchsvoraussetzungen er-
füllt, stellt sich die Frage, wie der genaue Betrag des Schadenser-
satzes bestimmt werden soll. Hierfür sieht das Urheberrecht die
sogenannte „dreifache Schadensberechnung“ vor. Ersatzfähig ist
hiernach als erste Möglichkeit der dem verletzten Rechteinhaber
„konkret entstandene Schaden“ einschließlich des entgangenen
Gewinns. Alternativ kann der Rechteinhaber vom Verletzer des-
sen „Verletzergewinn“ – also den Gewinn, den der Verletzer auf-
grund der unrechtmäßigen Verwendung des geschützten Werks
erwirtschaftet hat – herausverlangen. Da die Bestimmung der
genauen Summe nach den beiden ersten Möglichkeiten gewisse
Unsicherheiten aufweist, ist die Berechnung des Schadens nach
der sogenannten „Lizenzanalogie“ am verbreitetsten. Hiernach
hat der Verletzer dasjenige zu zahlen, was vernünftige Partei-
en bei Abschluss eines Lizenzvertrages in Kenntnis der wahren
Rechtslage und der Umstände des konkreten Einzelfalls als an-
gemessene Lizenzgebühr vereinbart hätten.
Stellt der Rechteinhaber sein Werk mittels einer freien Lizenz
quasi kostenlos zur Verfügung, stellt sich jedoch die Frage, ob
ihm überhaupt ein Schaden entstanden ist, wenn jemand das
Werk nutzt, ohne die Lizenzbedingungen einzuhalten. Falls die-
se Frage bejaht werden kann, stellt sich die Folgefrage, wie hoch
der Betrag dann ist.
II. Sachverhalt
Mit dieser Frage musste sich kürzlich auch das OLG Köln in sei-
nem Urteil auseinandersetzen. Geklagt hatte ein Fotograf, der
ein Bild unter einer CC-Lizenz auf der Internetseite wikimedia.org
veröffentlichte. Die verwendete CC-Lizenz erlaubt es interessier-
ten Nutzern das Bild kostenlos sowohl für kommerzielle als auch
nicht-kommerzielle Zwecke zu nutzen. Lediglich eine Verlinkung
auf die Veröffentlichung bei wikimedia.org als auch die Nennung
des Fotografen als Urheber wird dabei vorausgesetzt. Der Be-
klagte nutzte das Bild auf seiner eigenen Webseite jedoch oh-
ne eine entsprechende Verlinkung und nur mittels unzureichen-
der Kenntlichmachung der Urheberschaft des Bildes. Aufgrund
dieser Umstände verlangt der Kläger nun Schadensersatz von
dem Beklagten.
III. Entscheidung des OLG Köln
Das OLG Köln hat dieses Anspruchsverlangen in der Berufungsin-
stanz im Ergebnis abgelehnt. Dabei bejaht es die grundsätzliche
Urheberrechtsverletzung durch die fehlende Verlinkung und die
fehlende Urheberbenennung durch den Webseitenbetreiber, der
das Bild nutzte. Die Pflicht zur Verlinkung des genutzten Werks
auf wikimedia.org ergebe sich dabei aus den Lizenzbedingun-
gen der CC-Lizenz. Gleiches gelte für die Pflicht, den Urheber zu
nennen, wobei sich diese Pflicht zusätzlich aus § 13 S. 1 UrhG er-
gebe. Aus der Sicht des Gerichts ist damit letztlich nur fraglich,
ob daraus auch ein Schadenersatzanspruch folge. Das ist nur zu
bejahen, wenn dem Rechteinhaber durch die rechtswidrige Nut-
zung des Bildes auch ein Schaden entstanden ist.
Da der Rechteinhaber die Zahlung einer angemessenen Lizenz-
gebühr verlangt (Lizenzanalogie, siehe oben), kann er nur das
verlangen, was vernünftige Parteien bei Abschluss eines Lizenz-
vertrags in Kenntnis der wahren Rechtslage und den Umständen
des konkreten Einzelfalls als angemessene Lizenzgebühr verein-
bart hätten. Das Gericht setzt den objektiven Wert eines Werks,
das unter einer solchen CC-Lizenz zur Verfügung gestellt wird,
jedoch auf null Euro an. Es sei nicht ersichtlich, warum die Par-
teien eine weitergehende, entgeltliche Lizenzierung vereinba-
54 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | RECHT
ren sollten, um das Werk zu nutzen, wenn die Nutzung für die
kommerzielle und nicht-kommerzielle Nutzung freigegeben ist.
Eine entsprechende Vereinbarung liefe lediglich darauf hinaus,
dass die Verlinkung – die von der CC-Lizenz noch vorausgesetzt
wird – nicht mehr zu erfolgen habe. Für eine wirtschaftliche Be-
zifferung dieser Erleichterung gegenüber der CC-Lizenz, die für
die Berechnung des Schadens zugrunde gelegt hätte werden
können, wurde jedoch nichts vorgetragen.
Darüber hinaus bestehe zwar die Möglichkeit, eine fiktive Lizenz
durch das Gericht zu schätzen, jedoch setzt das Gericht auch im
Rahmen dieser Schätzung den wirtschaftlichen Wert mit null an.
Der Fotograf hat das Lichtbild kostenfrei zur Verfügung gestellt
und lediglich die Verlinkung auf die Wikimedia-Seite verlangt. Eine
Werbewirkung für Folgeaufträge, die als wirtschaftliche Grund-
lage der fiktiven Lizenz herangezogen werden könnte, könne
nach Ansicht des Gerichts daraus nicht abgeleitet werden. Eine
solche Wirkung ließe sich vielmehr nur annehmen, wenn man
auf die eigene Homepage verlinken lässt, auf der auch entgeltli-
che Leistungen angeboten werden. Die verlangte Verlinkung auf
eine fremde Webseite, die nur kostenfreie Fotos bereithält, wei-
se daher keinen wirtschaftlichen Wert auf, der aufgrund einer
Rechtsverletzung als Schaden geltend gemacht werden könnte.
Mit einer ähnlichen Argumentation lehnt das Gericht auch einen
Schaden durch die fehlerhafte Urheberbenennung ab. Auch in-
soweit verneint es einen wirtschaftlichen Wert. Zwar kann der
Nennung des Urhebers grundsätzlich ein wirtschaftlicher Wert
beigemessen werden, jedoch muss im Einzelfall geprüft werden,
ob ein solcher tatsächlich angenommen werden könne. Bejaht
werden könne dies beispielsweise, wenn dem Urheber durch die
fehlende Nennung Folgeaufträge entgingen. Das Gericht nimmt
jedoch an, dass dem Urheber im konkreten Fall keine Folgeauf-
träge mit wirtschaftlichem Wert entgangen sind. Der Fotograf
habe zu wenig vorgetragen, was darauf schließen ließe. Eine ent-
geltliche Lizenzierungspraxis von anderen Werken sei nach Auf-
fassung des Gerichts nicht erkennbar. Lediglich die kostenfreie
Bereitstellung weiterer Bilder bei wikimedia.org lasse sich er-
kennen. Ein Schaden ergebe sich auf diese Weise jedoch nicht.
Da im konkreten Fall somit weder die fehlende Verlinkung noch
die fehlerhafte Urheberbenennung einen wirtschaftlichen Wert
aufwiesen, erleide der Urheber auch keinen Schaden durch die
Rechtsverletzung. Mangels Schaden sei jedoch auch ein Anspruch
auf Schadensersatz ausgeschlossen.
IV. Fazit und Konsequenzen für Hochschulen und Forschungseinrichtungen
Die Entscheidung des OLG Köln fügt sich in eine Reihe weiterer
Entscheidungen hinsichtlich des Umgangs mit freien Lizenzen
ein. Es bestätigt zunächst die grundsätzliche Möglichkeit, auch
bei der Lizenzierung von urheberrechtlich geschützten Werken
mit freien Lizenztypen einen Schadensersatzanspruch geltend
zu machen. Die Tatsache der kostenfreien Bereitstellung führt
nicht automatisch zu einem Anspruchsausschluss. Wie bei je-
dem Schadensersatzanspruch muss aber auch der Nachweis ei-
nes Schadens erbracht werden. Dieser Nachweis ist bei freien
Lizenzen praktisch schwieriger zu erbringen. Das OLG Köln hat
insoweit ein Beispiel ausgeurteilt, das deutlich macht, wann der
Nachweis nicht ausreichend erbracht wurde. Der allgemeine Ver-
weis auf entgangene Folgeaufträge reicht insoweit nicht aus.
Dieser Umstand muss vielmehr belegt werden, was beispiels-
weise durch den Nachweis einer entgeltlichen Lizenzierungs-
praxis neben der unentgeltlichen Verbreitung mittels freier Li-
zenzen erfolgen könnte.
Da das Gericht die Revision nicht zugelassen hat, stellt das Urteil
die abschließende Entscheidung im konkreten Fall dar.
Für Forschungseinrichtungen lassen sich hieraus zweierlei Kon-
sequenzen ziehen:
• Zum einen können sie als Rechteinhaber urheberrechtlich
geschützte Werke unter einer freien Lizenz bereitstellen, oh-
ne den Verlust von Rechtsansprüchen befürchten zu müssen.
Der Nachweis eines Schadens kann im Einzelfall allerdings
Schwierigkeiten bereiten.
• Zum anderen sollten Forschungseinrichtungen als Nutzer ei-
nes Werks, das unter einer freien Lizenz veröffentlicht wur-
de, die konkreten Bedingungen exakt einhalten. Bei einem
Verstoß droht die Geltendmachung von Ersatzansprüchen
durch den Rechteinhaber. Sollte es zu einer Geltendmachung
kommen, sollten die Forschungseinrichtungen dem Begeh-
ren aber nicht vorschnell nachkommen, sondern genau prü-
fen, ob dem Rechteinhaber tatsächlich ein solcher Anspruch
zusteht. Kann beispielsweise der Nachweis eines Schadens
nicht erbracht werden, droht den Einrichtungen keine Haf-
tung. Bei der Beurteilung entsprechender Sachverhalte sollte
aber stets juristischer Rat hinzugezogen werden. M
[1] Zu der bisherigen rechtlichen Beurteilung von
freien Lizenzen siehe:
Mörike, Der Preis der Freiheit, DFN-Infobrief Recht
04/2017
Ochsenfeld, Ohne Preis keinen Schaden, DFN-Infobrief
Recht 12/2016
Klein, Die Grenzen der Freiheit, DFN-Infobrief Recht
07/2016
LITERATUR
55DFN-VEREIN | DFN Mitteilungen Ausgabe 94 |
DFN unterwegsDer Begriff Netz ist schon Teil unseres Namens. Und gut vernetzt sind auch unsere Mitarbei-
terinnen und Mitarbeiter – weit über die Grenzen unserer technischen Infrastruktur. Wo wir
überall unterwegs sind, zeigen wir hier.
... das Frühjahrstreffen des ZKI Arbeits-
kreises Verzeichnisdienste an der Uni-
versität Stuttgart am 22. und 23. März
Beim Frühjahrstreffen des ZKI Arbeitskrei-
ses Verzeichnisdienste in Stuttgart wurden
die Themen Anbindung von Quellsystemen,
Lösungen und Prozesse für das Zurückset-
zen von Passwörtern sowie die Problema-
tik der Anbindung von Unikliniken an das
Hochschul-Identity Management behan-
delt. Als weiterer Schwerpunkt wurden die
datenschutzrechtlichen Aspekte der Attri-
butfreigabe im Rahmen der AAI in Hinblick
auf die EU-DSGVO behandelt. Hierzu hielt
Wolfgang Pempe gemeinsam mit Matthi-
as Mörike und Armin Strobel von der For-
schungsstelle Recht im DFN einen Vortrag.
Dabei konnten sie sowohl die technischen
Rahmenbedingungen als auch die juristi-
schen Hintergründe beleuchten.
... der GÉANT Workshop "Geschäftsmodel-
le für West-Balkan-NRENs" am 26. Septem-
ber in Podgorica (Montenegro)
Wie unterschiedlich so ein Forschungsnetz
aufgebaut sein kann, zeigten die auf der
Veranstaltung vorgestellten Geschäfts-
modelle. Präsentiert wurden die Modelle
der griechischen, slowenischen und kroa-
tischen Forschungsnetze. Leonie Schäfer
erklärte außerdem das Geschäftsmodell
des Deutschen Forschungsnetzes, das bei
den Teilnehmern großen Anklang fand. Be-
sonders beeindruckend fanden die Teilneh-
mer den Status als ein von Regierung und
Ministerien unabhängiger Verein. Die Teil-
nehmer des Workshops waren Vertreterin-
nen und Vertreter der Forschungsnetze von
Montenegro, Mazedonien, Bulgarien und
Albanien. Als Beobachter nahm außerdem
ein Vertreter des Kosovo teil. In der darauf-
folgenden Diskussion stellte sich heraus,
dass Modelle, die NRENs als eigene juris-
tische Person mit enger Anbindung an re-
levante Ministerien sehen, für den West-
Balkan besonders praktikabel sind.
... die Konferenz DI4R 2018 vom 9. bis 11.
Oktober in Lissabon
Auf der Konferenz präsentierte Leonie
Schäfer das Programm „Enlighten Your Re-
search“ (EYR). Der DFN-Verein koordiniert
in Zusammenarbeit mit GÉANT und SURF-
net die regionalen Programme EYR-India-
2Europe und EYR@EAP. EYR-India2Europe
hat das Ziel, die Zusammenarbeit der eu-
ropäischen und indischen Nutzer-Commu-
nities und die generelle Nutzung der indi-
schen und europäischen Forschungsnetze
zu fördern. EYR@EaP fördert Forschungs-
projekte mit Netznutzung in den osteuro-
päischen Nachbarländern der EU.
Das Programm stieß auf großes Interes-
se, besonders im Hinblick auf die geplan-
te Vertiefung in der Zusammenarbeit der
europäischen e-Infrastrukturen im Rahmen
der European Open Science Cloud (EOSC).
Wolfgang Pempe, verantwortlich für die
DFN-AAI, ist einer der reisefreudigsten
Mitarbeiter. Seine Highlights in diesem
Jahr waren bisher ...
Dr. Leonie Schäfer ist für den DFN-Ver-
ein vor allem international unterwegs.
Ihre Highlights in diesem Jahr waren ...
56 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | DFN-VEREIN
DFN live: Wissen teilen, Erfahrungen weitergebenDer DFN-Verein lebt von der Expertise und Erfahrung seiner Mitglieder und Nutzer des Deutschen
Forschungsnetzes. Mit zahlreichen Veranstaltungen, Tutorien, Tagungen und Workshops bietet
der DFN-Verein ein Forum für einen lebendigen Austausch und Wissenstransfer.
Mitgliederversammlung
Eine der Stärken des DFN-Vereins ist das breite Mandat
der Mitglieder. Mit über 300 institutionellen Mitgliedern
engagieren sich die überwiegende Mehrzahl der deut-
schen Hochschulen und Forschungseinrichtungen sowie
forschungsnahe Unternehmen der gewerblichen Wirt-
schaft am DFN-Verein.
Die Vertreter der Mitglieder treffen sich zweimal jähr-
lich, um die Zukunft des DFN-Vereins zu gestalten. Die
76. Mitgliederversammlung fand am 4. und 5. Juni 2018
in der Berlin-Brandenburgischen Akademie der Wissen-
schaften in Berlin statt. Zur Vorabendveranstaltung lud
der DFN-Verein interessierte Teilnehmer auf den Cam-
pus des Europäischen Energieforums (EUREF) ein. Hier
konnte frei nach dem Motto „Innovation trifft Tradition“
das historische Gasometer bestiegen sowie der Campus,
als Symbol der Energiewende in Deutschland, besichtigt
werden. Noch weiter in die Zukunft führte uns Prof. Dr.
Christian Herta von der Hochschule für Technik und Wirt-
schaft Berlin. In seinem Vortrag zum Thema Deep Lear-
ning zeigte er, dass künstliche Intelligenz schon lange
keine Science-Fiction mehr ist.
Die nächste Mitgliederversammlung findet am 4. und
5. Dezember 2018 in Bonn statt.
TERMIN
Gasometerbesichtigung. Campus des Europäischen Energieforums (EUREF)
Foto © Maimona Id / DFN-Verein
... und das Herbsttreffen des ZKI Ar-
beitskreises Verzeichnisdienste an der
Heinrich-Heine-Universität Düsseldorf
am 12. und 13. September
Das Schwerpunktthema des Herbstreffens
lautete „digitale Identitäten“. Neben Vor-
trägen u. a. zu ORCID (Open Researcher
and Contributor ID) und dem europäischen
digitalen Studierendenausweis, referier-
te Wolfgang Pempe hier zum Thema edu-
ID. Hierbei wurden die bereits existieren-
den Implementierungen auf Föderations-
ebene in Schweden und der Schweiz vor-
gestellt sowie deren Anwendbarkeit auf
die DFN-AAI.
... der Workshop AAI und Shibboleth an
der Fachhochschule Dortmund am 28.
und 29. August
Neben dem technischen Support im Rah-
men der DFN-AAI-Hotline führt das Team der
DFN-AAI auf Anfrage auch Schulungsveran-
staltungen vor Ort durch. Zum Workshop in
Dortmund hatten sich 15 Angehörige nord-
rhein-westfälischer Hochschulrechenzen-
tren eingefunden, um sich von Silke Mey-
er und Wolfgang Pempe zunächst mit den
Grundlagen der AAI, Web-basiertem Single
Sign-on und den zugrunde liegenden Stan-
dards vertraut machen zu lassen. Im prakti-
schen Teil konnten die Teilnehmerinnen und
Teilnehmer selber einen Shibboleth Identity
Provider installieren sowie anschließend
anhand einiger Übungsaufgaben typische
Wartungsarbeiten und Konfigurationsschrit-
te durchführen.
57DFN-VEREIN | DFN Mitteilungen Ausgabe 94 |
Betriebstagungen
Zur Unterstützung der Betriebsverantwortlichen in
den Mitgliedseinrichtungen wird zweimal jährlich
für je zwei Tage eine Betriebstagung durchgeführt.
Hier treffen sich mit Betriebsfragen beauftragte Mit-
arbeiter, Vertreter der Mitgliedsorganisationen und
andere an den Fachthemen des DFN-Vereins Interes-
sierte zum Erfahrungsaustausch und zur Weiterbil-
dung. Dabei sollen Fragen, die sich aus dem Einsatz
von DFN-Diensten ergeben, geklärt, die Netzverant-
wortlichen über neue Entwicklungen informiert und
Einsteiger geschult werden.
Thema waren in diesem Jahr vor allem die vielen neu-
en Entwicklungen in den DFN-Diensten. So wurde der
neue Dienst DFNconf vorgestellt, der kurz nach der
Veranstaltung in Betrieb genommen wurde. Für die
zahlreichen Fragen zu den Neuerungen standen Mit-
arbeiter des DFN-Vereins den Teilnehmern Rede und
Antwort. In den einzelnen Foren wurden weitere ak-
tuelle Themen aus unterschiedlichen Bereichen vor-
gestellt und diskutiert. Und auch beim abendlichen
Austausch in entspannter Runde setzten sich die an-
geregten Diskussionen fort.
14. Tagung der DFN-Nutzergruppe
Hochschulverwaltung
„Campus digital? Aber sicher!“ ist das Motto der diesjährigen Ta-
gung der DFN-Nutzergruppe Hochschulverwaltung. Organisiert
wird die Veranstaltung durch den DFN-Verein in Zusammenar-
beit mit der Universität Ulm. Vortragende aus Forschung, Ver-
waltung und Wirtschaft beschäftigen sich mit hochaktuellen
Fragen zu Informationssicherheit, Datenaufbewahrung und
Softwarebeschaffung/-management. Der Schwerpunkt dieser
Tagung liegt in den vielfältigen Anforderungen der Digitalisie-
rungsentwicklungen und bietet damit einen Ausblick auf rechtli-
che Aspekte ebenso wie auf konkrete Anwendungsbereiche wie
bspw. die E-Rechnung.
In der 1991 gegründeten DFN-Nutzergruppe Hochschulverwal-
tung werden bundesweit Informationen über Themenbereiche
aus der Informations-, Kommunikations- und Medientechnik in
direkten Bezug zu Themen der Hochschuladministration gesetzt.
Die Informationen und Ergebnisse werden alle zwei Jahre auf
einer Tagung den Hochschulen vorgestellt.
Die nächste DFN-Betriebstagung findet am 19. und 20. März
2019 im Seminaris CampusHotel Berlin statt.
TERMIN
Seminaris CampusHotel Berlin Foto © Nina Bark / DFN-Verein
Die 14. Tagung der DFN-Nutzergruppe Hochschulverwal-
tung findet am 6. bis 8. Mai 2019 im Stadthaus in Ulm
statt. Weitere Informationen zur Arbeit der Nutzergrup-
pe und zu den Tagungen finden Sie unter: www.hoch-
schulverwaltung.de
TERMIN
Stadthaus Ulm Foto © Martin Duckek
58 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | DFN-VEREIN
DFN-Forum
Kommunikationstechnologien
Über Ruhm, Ehre und ein Preisgeld von 1.000 Euro
durfte sich Hauke Heseding vom Institut für Telema-
tik des Karlsruher Instituts für Technologie (KIT) freu-
en. Im Rahmen des 11. DFN-Forums Kommunikations-
technologien am 27. und 28. Juni in Günzburg nahm
der Informatiker den X-WiNner-Award 2018 entgegen,
der sich insbesondere an Nachwuchswissenschaftle-
rinnen und –wissenschaftler richtet. Der Beitrag von
Hauke Heseding und seinen Mitautoren steht in die-
ser Ausgabe in der Rubrik Campus.
Unter dem Motto „verteilte Systeme im Wissenschafts-
bereich“ hatten die Universität Ulm, die Zentren für
Kommunikation und Informationsverarbeitung in For-
schung und Lehre e. V. (ZKI), die Gesellschaft für Infor-
matik e. V. und der DFN-Verein in das idyllisch auf ei-
ner Anhöhe gelegene Wissenschaftszentrum Schloss
Reisensburg geladen. Das Forum Kommunikations-
technologien ist eine Plattform zur Darstellung und
Diskussion neuer Forschungs- und Entwicklungser-
gebnisse aus dem Bereich Telekommunikation und
Informationstechnologien. Das Forum findet einmal
jährlich statt und bietet Nachwuchswissenschaftlern
die Möglichkeit, ihre Forschungsergebnisse zu prä-
sentieren. Neben hochkarätigen Beiträgen jüngster
Forschungs- und Entwicklungsergebnisse, standen
auch der persönliche Erfahrungs- und Wissensaus-
tausch der Teilnehmerinnen und Teilnehmer, die so-
wohl aus universitären als auch außeruniversitären
Einrichtungen kamen, im Fokus der Veranstaltung.
Die Beiträge zum 11. DFN-Forum Kommunikations-
technologien sind in der Digitalen Bibliothek der Ge-
sellschaft für Informatik (GI) nachzulesen:
https://dl.gi.de
Aktuelle Informationen rund um das Deutsche Forschungsnetz
und seine Veranstaltungen erhalten Sie auch regelmäßig in
unserem Newsletter.
Den DFN-Newsletter können Sie unter www.dfn.de abonnieren.
X-WiNner Hauke Heseding (3. v. li.) mit Dr. Rainer Bockholt, Prof. Dr. Bernhard Neumair und
Prof. Dr. Paul Müller (v. li.), Foto © Maimona Id
Das 12. DFN-Forum Kommunikationstechnologien findet am
14. und 15. Mai 2019 an der Otto-von-Guericke-Universität
Magdeburg statt.
TERMIN
59DFN-VEREIN | DFN Mitteilungen Ausgabe 94 |
Laut Satzung fördert der DFN-Verein die Schaffung der Vo r-
aussetzungen für die Errichtung, den Betrieb und die Nutzung
eines rechnergestützten Informations- und Kommunikations-
systems für die öffentlich geförderte und gemeinnützige For-
schung in der Bundesrepublik Deutschland. Der Satzungszweck
wird verwirklicht insbesondere durch Vergabe von Forschungs-
aufträgen und Organisation von Dienstleistungen zur Nutzung
des Deutschen Forschungsnetzes.
Als Mitglieder werden juristische Personen aufgenommen, von
denen ein wesentlicher Beitrag zum Vereinszweck zu erwarten
ist oder die dem Bereich der institutionell oder sonst aus öffent-
lichen Mitteln geförderten Forschung zuzurechnen sind. Sitz des
Vereins ist Berlin.
Die Geschäftsstelle
Geschäftsstelle
Standort Berlin (Sitz des Vereins)
DFN-Verein e. V.
Alexanderplatz 1
D-10178 Berlin
Telefon: +49 (0)30 884299-0
Geschäftsstelle
Standort Stuttgart
DFN-Verein e. V.
Lindenspürstraße 32
D-70176 Stuttgart
Telefon: +49 (0)711 63314-0
Fotos © jackijack / fotolia
Überblick DFN-Verein (Stand: 11/2018)
60 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | DFN-VEREIN
Die Organe
Mitgliederversammlung
Die Mitgliederversammlung ist u. a. zuständig für die Wahl der
Mitglieder des Verwaltungsrates, für die Genehmigung des Jah-
reswirtschaftsplanes, für die Entlastung des Vorstandes und für
die Festlegung der Mitgliedsbeiträge. Derzeitiger Vorsitzender der
Mitgliederversammlung ist Prof. Dr. Gerhard Peter, HS Heilbronn.
Verwaltungsrat
Der Verwaltungsrat beschließt alle wesentlichen Aktivitäten des
Vereins, insbesondere die technisch-wissenschaftlichen Arbei-
ten und berät den Jahreswirtschaftsplan. Für die 12. Wahlperio-
de sind Mitglieder des Verwaltungsrates:
Dr. Rainer Bockholt
(Rheinische Friedrich-Wilhelms-Universität Bonn)
Prof. Dr. Hans-Joachim Bungartz
(Technische Universität München)
Prof. Dr. Gabi Dreo Rodosek
(Universität der Bundeswehr München)
Prof. Dr. Rainer W. Gerling
(Max-Planck-Gesellschaft München)
Dr.-Ing. habil. Carlos Härtel
(GE Global Research)
Prof. Dr. Odej Kao
(Technische Universität Berlin)
Prof. Dr.-Ing. Ulrich Lang
(Universität zu Köln)
Prof. Dr. Joachim Mnich
(Deutsches Elektronen-Synchrotron Hamburg)
Dr. Karl Molter
(Hochschule Trier)
Dr.-Ing. Christa Radloff
(Universität Rostock)
Prof. Dr.-Ing. Ramin Yahyapour
(Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen)
Christian Zens
(Friedrich-Alexander-Universität Erlangen-Nürnberg)
Dr. Harald Ziegler
(Heinrich-Heine-Universität Düsseldorf)
Der Verwaltungsrat hat als ständige Gäste
einen Vertreter der Hochschulrektorenkonferenz:
Prof. Dr. Monika Gross
(Präsidentin der Beuth Hochschule für Technik Berlin)
einen Vertreter der Hochschulkanzler:
Christian Zens
(Kanzler der Friedrich-Alexander-Universität Erlangen-Nürnberg)
einen Vertreter der Kultusministerkonferenz:
Jürgen Grothe
(SMWK Dresden)
den Vorsitzenden der jeweils letzten Mitgliederversammlung:
Prof. Dr. Gerhard Peter
(Hochschule Heilbronn)
den Vorsitzenden des ZKI:
Hartmut Hotzel
(Bauhaus-Universität Weimar)
Vorstand
Der Vorstand des DFN-Vereins im Sinne des Gesetzes wird aus
dem Vorsitzenden und den beiden stellvertretenden Vorsitzen-
den des Verwaltungsrates gebildet. Derzeit sind dies:
Prof. Dr. Hans-Joachim Bungartz
Vorsitz
Dr. Rainer Bockholt
Stellv. Vorsitzender
Christian Zens
Stellv. Vorsitzender
Der Vorstand wird beraten vom Strategischen Beirat, einem Be-
triebsausschuss (BA) und einem Ausschuss für Recht und Sicher-
heit (ARuS).
Der Vorstand bedient sich zur Erledigung laufender Aufgaben ei-
ner Geschäftsstelle mit Standorten in Berlin und Stuttgart. Sie
wird von einer Geschäftsführung geleitet. Als Geschäftsführer
wurden vom Vorstand Dr. Christian Grimm und Jochem Pattloch
bestellt.
61DFN-VEREIN | DFN Mitteilungen Ausgabe 94 |
Die Mitgliedereinrichtungen
Aachen Fachhochschule Aachen
Rheinisch-Westfälische Technische Hochschule Aachen (RWTH)
Aalen Hochschule Aalen
Amberg Ostbayerische Technische Hochschule Amberg-Weiden
Ansbach Hochschule für angewandte Wissenschaften, Fachhochschule Ansbach
Aschaffenburg Hochschule Aschaffenburg
Augsburg Hochschule für angewandte Wissenschaften, Fachhochschule Augsburg
Universität Augsburg
Bad Homburg Dimension Data Germany AG & Co. KG
Bamberg Otto-Friedrich-Universität Bamberg
Bayreuth Universität Bayreuth
Berlin Alice Salomon Hochschule Berlin
Berliner Institut für Gesundheitsforschung/Berlin Institut of Health
Beuth Hochschule für Technik Berlin – University of Applied Sciences
Bundesamt für Verbraucherschutz und Lebensmittelsicherheit
Bundesanstalt für Materialforschung und -prüfung
Bundesinstitut für Risikobewertung
Campus Berlin-Buch GmbH
Deutsche Telekom AG Laboratories
Deutsche Telekom IT GmbH
Deutsches Herzzentrum Berlin
Deutsches Institut für Normung e. V. (DIN)
Deutsches Institut für Wirtschaftsforschung (DIW)
Evangelische Hochschule Berlin
Forschungsverbund Berlin e. V.
Freie Universität Berlin (FUB)
Helmholtz-Zentrum Berlin für Materialien und Energie GmbH
Hochschule für Technik und Wirtschaft – University of Applied Sciences
Hochschule für Wirtschaft und Recht
Humboldt-Universität zu Berlin (HUB)
International Psychoanalytic University Berlin
IT-Dienstleistungszentrum
Konrad-Zuse-Zentrum für Informationstechnik (ZIB)
Museum für Naturkunde
Robert Koch-Institut
Stanford University in Berlin
Stiftung Deutsches Historisches Museum
Stiftung Preußischer Kulturbesitz
Technische Universität Berlin (TUB)
Umweltbundesamt
Universität der Künste Berlin
Wissenschaftskolleg zu Berlin
Wissenschaftszentrum Berlin für Sozialforschung gGmbH (WZB)
Biberach Hochschule Biberach
Bielefeld Fachhochschule Bielefeld
Universität Bielefeld
Bingen Technische Hochschule Bingen
Bochum ELFI Gesellschaft für Forschungsdienstleistungen mbH
Evangelische Hochschule Rheinland-Westfalen-Lippe
Hochschule Bochum
Hochschule für Gesundheit
Ruhr-Universität Bochum
Technische Hochschule Georg Agricola
Bonn Bundesinstitut für Arzneimittel und Medizinprodukte
Bundesministerium des Innern
Bundesministerium für Umwelt, Naturschutz, Bau u. Reaktorsicherheit
Deutsche Forschungsgemeinschaft (DFG)
Deutscher Akademischer Austauschdienst e. V. (DAAD)
Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
Deutsches Zentrum für Neurodegenerative Erkrankungen e. V.
Helmholtz-Gemeinschaft Deutscher Forschungszentren e. V.
ITZ Bund
Rheinische Friedrich-Wilhelms-Universität Bonn
Borstel FZB, Leibniz-Zentrum für Medizin und Biowissenschaften
Brandenburg Technische Hochschule Brandenburg
Braunschweig DSMZ – Deutsche Sammlung von Mikroorganismen und Zellkulturen
GmbH
Helmholtz-Zentrum für Infektionsforschung GmbH
Hochschule für Bildende Künste Braunschweig
Johann-Heinrich von Thünen-Institut, Bundesforschungs-
institut für Ländliche Räume, Wald und Fischerei
Julius Kühn-Institut Bundesforschungsinstitut für Kulturpflanzen
Physikalisch-Technische Bundesanstalt (PTB)
Technische Universität Carolo-Wilhelmina zu Braunschweig
Bremen Hochschule Bremen
Hochschule für Künste Bremen
Jacobs University Bremen gGmbH
Universität Bremen
Bremerhaven Alfred-Wegener-Institut, Helmholtz-Zentrum für Polar- und
Meeresforschung (AWI)
Hochschule Bremerhaven
Stadtbildstelle Bremerhaven
Chemnitz Technische Universität Chemnitz
TUCed – Institut für Weiterbildung GmbH
Clausthal Technische Universität Clausthal-Zellerfeld
Coburg Hochschule für angewandte Wissenschaften, Fachhochschule Coburg
Cottbus Brandenburgische Technische Universität Cottbus-Senftenberg
Darmstadt Deutsche Telekom IT GmbH
European Space Agency (ESA)
Evangelische Hochschule Darmstadt
GSI Helmholtzzentrum für Schwerionenforschung GmbH
Hochschule Darmstadt
Merck KGaA
Technische Universität Darmstadt
Deggendorf Technische Hochschule
Dortmund Fachhochschule Dortmund
Technische Universität Dortmund
62 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | DFN-VEREIN
Dresden Evangelische Hochschule Dresden
Helmholtz-Zentrum Dresden-Rossendorf e. V.
Hannah-Arendt-Institut für Totalitarismusforschung e. V.
Hochschule für Bildende Künste Dresden
Hochschule für Technik und Wirtschaft
Leibniz-Institut für Festkörper- und Werkstoffforschung Dresden e. V.
Leibniz-Institut für Polymerforschung Dresden e. V.
Sächsische Landesbibliothek – Staats- und Universitätsbibliothek
Technische Universität Dresden
Dummersdorf Leibniz – Institut für Nutztierbiologie (FBN)
Düsseldorf Hochschule Düsseldorf
Heinrich-Heine-Universität Düsseldorf
Information und Technik Nordrhein-Westfalen (IT.NRW)
Kunstakademie Düsseldorf
Robert-Schumann-Hochschule
Eichstätt Katholische Universität Eichstätt-Ingolstadt
Emden Hochschule Emden/Leer
Erfurt Fachhochschule Erfurt
Universität Erfurt
Erlangen Friedrich-Alexander-Universität Erlangen-Nürnberg
Essen RWI – Leibniz-Institut für Wirtschaftsforschung e. V.
Universität Duisburg-Essen
Esslingen Hochschule Esslingen
Flensburg Europa-Universität Flensburg
Hochschule Flensburg
Frankfurt/M. Bundesamt für Kartographie und Geodäsie
Deutsche Nationalbibliothek
Deutsches Institut für Internationale Pädagogische Forschung
Frankfurt University of Applied Science
Johann Wolfgang Goethe-Universität Frankfurt am Main
Philosophisch-Theologische Hochschule St. Georgen e. V.
Senckenberg Gesellschaft für Naturforschung
Frankfurt/O. IHP GmbH – Institut für innovative Mikroelektronik
Stiftung Europa-Universität Viadrina
Freiberg Technische Universität Bergakademie Freiberg
Freiburg Albert-Ludwigs-Universität Freiburg
Evangelische Hochschule Freiburg
Katholische Hochschule Freiburg
Freising Hochschule Weihenstephan
Friedrichshafen Zeppelin Universität gGmbH
Fulda Hochschule Fulda
Furtwangen Hochschule Furtwangen – Informatik, Technik, Wirtschaft, Medien
Garching European Southern Observatory (ESO)
Gesellschaft für Anlagen- und Reaktorsicherheit gGmbH
Leibniz-Rechenzentrum d. Bayerischen Akademie der Wissenschaften
Gatersleben Leibniz-Institut für Pflanzengenetik und Kulturpflanzenforschung (IPK)
Geesthacht Helmholtz-Zentrum Geesthacht Zentrum für Material- und
Küstenforschung GmbH
Gelsenkirchen Westfälische Hochschule
Gießen Technische Hochschule Mittelhessen
Justus-Liebig-Universität Gießen
Göttingen Gesellschaft für wissenschaftliche Datenverarbeitung mbH (GwDG)
Verbundzentrale des Gemeinsamen Bibliotheksverbundes
Greifswald Ernst-Moritz-Arndt-Universität Greifswald
Friedrich-Loeffler-Institut, Bundesforschungsinstitut für
Tiergesundheit
Hagen Fachhochschule Südwestfalen, Hochschule für Technik und Wirtschaft
FernUniversität in Hagen
Halle/Saale Leibniz-Institut für Wirtschaftsforschung Halle e. V.
Martin-Luther-Universität Halle-Wittenberg
Hamburg Bundesamt für Seeschifffahrt und Hydrographie
Deutsches Elektronen-Synchrotron (DESY)
Deutsches Klimarechenzentrum GmbH (DKRZ)
DFN – CERT Services GmbH
HafenCity Universität Hamburg
Helmut-Schmidt-Universität, Universität der Bundeswehr
Hochschule für Angewandte Wissenschaften Hamburg
Hochschule für Bildende Künste Hamburg
Hochschule für Musik und Theater Hamburg
Technische Universität Hamburg
Universität Hamburg
Xantaro Deutschland GmbH
Hameln Hochschule Weserbergland
Hamm SRH Hochschule für Logistik und Wirtschaft Hamm
Hannover Bundesanstalt für Geowissenschaften und Rohstoffe
Hochschule Hannover
Gottfried Wilhelm Leibniz Bibliothek – Niedersächsische
Landesbibliothek
Gottfried Wilhelm Leibniz Universität Hannover
HIS Hochschul-Informations-System GmbH
Hochschule für Musik, Theater und Medien
Landesamt für Bergbau, Energie und Geologie
Medizinische Hochschule Hannover
Technische Informationsbibliothek
Stiftung Tierärztliche Hochschule
Heide Fachhochschule Westküste, Hochschule für Wirtschaft und Technik
Heidelberg Deutsches Krebsforschungszentrum (DKFZ)
European Molecular Biology Laboratory (EMBL)
NEC Laboratories Europe GmbH
Ruprecht-Karls-Universität Heidelberg
Heilbronn Hochschule für Technik, Wirtschaft und Informatik Heilbronn
Hildesheim Hochschule für angewandte Wissenschaft und Kunst
Fachhochschule Hildesheim / Holzminden / Göttingen
Stiftung Universität Hildesheim
Hof Hochschule für angewandte Wissenschaften Hof – FH
Idstein Hochschule Fresenius gGmbH
Ilmenau Technische Universität Ilmenau
Ingolstadt DiZ – Zentrum für Hochschuldidaktik d. bayerischen Fachhochschulen
Hochschule für angewandte Wissenschaften FH Ingolstadt
Jena Ernst-Abbe-Hochschule Jena
Friedrich-Schiller-Universität Jena
Leibniz-Institut für Photonische Technologien e. V.
63DFN-VEREIN | DFN Mitteilungen Ausgabe 94 |
Leibniz-Institut für Alternsforschung – Fritz-Lipmann-Institut e. V. (FLI)
Jülich Forschungszentrum Jülich GmbH
Kaiserslautern Hochschule Kaiserslautern
Technische Universität Kaiserslautern
Karlsruhe Bundesanstalt für Wasserbau
FIZ Karlsruhe - Leibnitz-Institut für Informationsinfrastruktur
Karlsruher Institut für Technologie – Universität des Landes Baden-
Württemberg und nationales Forschungszentrum in der Helmholtz-
Gemeinschaft (KIT)
FZI Forschungszentrum Informatik
Hochschule Karlsruhe – Technik und Wirtschaft
Zentrum für Kunst und Medientechnologie
Kassel Universität Kassel
Kempten Hochschule für angewandte Wissenschaften, Fachhochschule Kempten
Kiel Christian-Albrechts-Universität zu Kiel
Fachhochschule Kiel
Institut für Weltwirtschaft an der Universität Kiel
Helmholtz-Zentrum für Ozeanforschung Kiel (GEOMAR)
ZBW – Deutsche Zentralbibliothek für Wirtschaftswissenschaften –
Leibniz-Informationszentrum Wirtschaft
Koblenz Hochschule Koblenz
Köln Deutsche Sporthochschule Köln
Hochschulbibliothekszentrum des Landes NRW
Katholische Hochschule Nordrhein-Westfalen
Kunsthochschule für Medien Köln
Rheinische Fachhochschule Köln gGmbH
Technische Hochschule Köln
Universität zu Köln
Konstanz Hochschule Konstanz Technik, Wirtschaft und Gestaltung (HTWG)
Universität Konstanz
Köthen Hochschule Anhalt
Krefeld Hochschule Niederrhein
Kühlungsborn Leibniz-Institut für Atmosphärenphysik e. V.
Landshut Hochschule Landshut – Hochschule für angewandte Wissenschaften
Leipzig Deutsche Telekom, Hochschule für Telekommunikation Leipzig
Helmholtz-Zentrum für Umweltforschung – UFZ GmbH
Hochschule für Grafik und Buchkunst Leipzig
Hochschule für Musik und Theater „Felix Mendelssohn Bartholdy“
Hochschule für Technik, Wirtschaft und Kultur Leipzig
Leibniz-Institut für Troposphärenforschung e. V.
Mitteldeutscher Rundfunk
Universität Leipzig
Lemgo Hochschule Ostwestfalen-Lippe
Lübeck Technische Hochschule Lübeck
Universität zu Lübeck
Ludwigsburg Evangelische Hochschule Ludwigsburg
Ludwigshafen Fachhochschule Ludwigshafen am Rhein
Lüneburg Leuphana Universität Lüneburg
Magdeburg Hochschule Magdeburg-Stendal (FH)
Leibniz-Institut für Neurobiologie Magdeburg
Mainz Hochschule Mainz
Johannes Gutenberg-Universität Mainz
Katholische Hochschule Mainz
Universität Koblenz-Landau
Mannheim Hochschule Mannheim
GESIS – Leibniz-Institut für Sozialwissenschaften e. V.
TÜV SÜD Energietechnik GmbH Baden-Württemberg
Universität Mannheim
Zentrum für Europäische Wirtschaftsforschung GmbH (ZEW)
Marbach a. N. Deutsches Literaturarchiv
Marburg Philipps-Universität Marburg
Merseburg Hochschule Merseburg (FH)
Mittweida Hochschule Mittweida
Mülheim an der
Ruhr
Hochschule Ruhr West
Müncheberg Leibniz-Zentrum für Agrarlandschafts- u. Landnutzungsforschung e. V.
München Bayerische Staatsbibliothek
Hochschule für angewandte Wissenschaften München
Hochschule für Philosophie München
Fraunhofer Gesellschaft zur Förderung der angewandten Forschung e. V.
Helmholtz Zentrum München Deutsches Forschungszentrum für
Gesundheit und Umwelt GmbH
ifo Institut – Leibniz-Institut für Wirtschaftsforschung e. V.
Katholische Stiftungshochschule München
Ludwig-Maximilians-Universität München
Max-Planck-Gesellschaft
Technische Universität München
Universität der Bundeswehr München
Münster Fachhochschule Münster
Westfälische Wilhelms-Universität Münster
Neubranden-
burg
Hochschule Neubrandenburg
Neu-Ulm Hochschule für Angewandte Wissenschaften, Fachhochschule Neu-Ulm
Nordhausen Hochschule Nordhausen
Nürnberg Kommunikationsnetz Franken e. V.
Technische Hochschule Nürnberg Georg Simon Ohm
Nürtingen Hochschule für Wirtschaft und Umwelt Nürtingen-Geislingen
Nuthetal Deutsches Institut für Ernährungsforschung Potsdam-Rehbrücke
Oberwolfach Mathematisches Forschungsinstitut Oberwolfach gGmbH
Offenbach/M. Deutscher Wetterdienst (DWD)
Offenburg Hochschule Offenburg
Oldenburg Carl von Ossietzky Universität Oldenburg
Landesbibliothek Oldenburg
Osnabrück Hochschule Osnabrück
Universität Osnabrück
Paderborn Fachhochschule der Wirtschaft Paderborn
Universität Paderborn
Passau Universität Passau
Peine Bundesgesellschaft für Endlagerung mbH (BGE)
Pforzheim Hochschule Pforzheim – Gestaltung, Technik, Wirtschaft und Recht
Potsdam Fachhochschule Potsdam
Helmholtz-Zentrum, Deutsches GeoForschungsZentrum – GFZ
64 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | DFN-VEREIN
Hochschule für Film und Fernsehen „Konrad Wolf“
Potsdam-Institut für Klimafolgenforschung (PIK)
Universität Potsdam
Regensburg Ostbayerische Technische Hochschule Regensburg
Universität Regensburg
Reutlingen Hochschule Reutlingen
Rosenheim Hochschule für angewandte Wissenschaften – Fachhochschule
Rosenheim
Rostock Leibniz-Institut für Ostseeforschung Warnemünde
Universität Rostock
Saarbrücken Cispa Helmholtz-Zentrum i.G.
Universität des Saarlandes
Salzgitter Bundesamt für Strahlenschutz
Sankt Augustin Hochschule Bonn Rhein-Sieg
Schenefeld European X-Ray Free-Electron Laser Facility GmbH
Schmalkalden Hochschule Schmalkalden
Schwäbisch
Gmünd
Pädagogische Hochschule Schwäbisch Gmünd
Schwerin Landesbibliothek Mecklenburg-Vorpommern
Siegen Universität Siegen
Sigmaringen Hochschule Albstadt-Sigmaringen
Speyer Deutsche Universität für Verwaltungswissenschaften Speyer
Straelen GasLINE Telekommunikationsnetzgesellschaft deutscher
Gasversorgungsunternehmen mbH & Co. Kommanditgesellschaft
Stralsund Hochschule Stralsund
Stuttgart Cisco Systems GmbH
Duale Hochschule Baden-Württemberg
Hochschule der Medien Stuttgart
Hochschule für Technik Stuttgart
Universität Hohenheim
Universität Stuttgart
Tautenburg Thüringer Landessternwarte Tautenburg
Trier Hochschule Trier
Universität Trier
Tübingen Eberhard Karls Universität Tübingen
Leibniz-Institut für Wissensmedien
Ulm Hochschule Ulm
Universität Ulm
Vechta Universität Vechta
Private Hochschule für Wirtschaft und Technik
Wadern Schloss Dagstuhl – Leibniz-Zentrum für Informatik GmbH (LZI)
Weimar Bauhaus-Universität Weimar
Hochschule für Musik FRANZ LISZT Weimar
Weingarten Hochschule Ravensburg-Weingarten
Pädagogische Hochschule Weingarten
Wernigerode Hochschule Harz
Weßling T-Systems Solutions for Research GmbH
Wiesbaden Hochschule RheinMain
Statistisches Bundesamt
Wildau Technische Hochschule Wildau (FH)
Wilhelmshaven Jade Hochschule Wilhelmshaven / Oldenburg / Elsfleth
Wismar Hochschule Wismar
Witten Private Universität Witten / Herdecke gGmbH
Wolfenbüttel Ostfalia Hochschule für angewandte Wissenschaften
Herzog August Bibliothek
Worms Hochschule Worms
Wuppertal Bergische Universität Wuppertal
Kirchlische Hochschule Wuppertal/Bethel
Würzburg Hochschule für angewandte Wissenschaften – Fachhochschule
Würzburg-Schweinfurt
Julius-Maximilians-Universität Würzburg
Zittau Hochschule Zittau / Görlitz
Zwickau Westsächsische Hochschule Zwickau
Mit
teil
un
gen
A
usg
abe
94 |
Dez
emb
er 2
018
DFN mitteilungen
bieten Hintergrundwissen zu Themen
aus der Welt der Kommunikationsnetze
und des DFN-Vereins
DFN infobrief recht
informiert über aktuelle Entwicklungen
und Fragen des Medien- und Informa-
tionsrechtes
DFN newsletter
liefert neueste Informationen rund
um das Deutsche Forschungsnetz
Alle Publikationen können Sie hier abonnieren:
https://www.dfn.de/publikationen/