20 Jahre Forschungsstelle Recht - dfn.de · DFN Mitteilungen Ausgabe 94 | 3 Erstklassige Forschung und Digitalisierung gehen miteinander einher. Was jedoch bedeutet Digi - talisierung

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

http://www.dfn.de

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

mailto:[email protected]

http://www.dfn.de

http://www.labor3.com

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

([email protected]).




















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

6 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | WISSENSCHAFTSNETZ

7WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 94 |

WissenschaftsnetzVom zarten Pflänzchen zum Mammutbaum –

10 Jahre eduroam

von Ralf Paffrath


von Jakob Tendel

Kurzmeldungen


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.


„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


„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


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


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

https://www.eduroam.org/eduroam-news-2


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


Einrichtung RadSec Client/Server

Konföderation RADIUS/RadSec Client/Server GEANT

(Kon)föderation RADIUS/RadSec Client/Server International



…

…

…




WlanController/APProtokolle: EAP-TTLS/PEAP, etc.

Auth-Path: RADIUS over TCP, TLS abgesichert


DFN

Föderation RADIUS Server DFN-Verein


Konföderation RADIUS Server GEANT

(Kon)föderation RADIUS Server International





WlanController/AP

Protokolle: EAP-TTLS/PEAP, etc.


DFN

Föderation RadSec Client/Server DFN-Verein



Konföderation RADIUS/RadSec Client/Server GEANT

(Kon)föderation RADIUS/RadSec Client/Server International



…

…

…




WlanController/APProtokolle: EAP-TTLS/PEAP, etc.

Auth-Path: RADIUS over TCP, TLS abgesichert


mailto:@einrichtung.de






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


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 %


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:


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

http://fasterdata.es.net/


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/

http://fasterdata.es.net/

https://cs.lbl.gov/news-media/news/2017/esnets-petascale-dtn-project-speeds-up-data-transfers-between-leading-hpc-centers/

https://www.switch.ch/de/stories/big_science_data/


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

https://www.conf.dfn.de/

https://terminplaner4.dfn.de

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.


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


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


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.


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:

https://github.com/esper-hub/esper


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.


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?


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


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%


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

https://blog.pki.dfn.de/2018/06/tipps-fuer-die-domain-freischaltung

https://doku.tid.dfn.de/de:aai:incidentresponse

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


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


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


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


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

42 | DFN Mitteilungen Ausgabe 94 | Dezember 2018 | RECHT

RECHT | DFN Mitteilungen Ausgabe 94 | 43

RechtFragen ohne Ende –

20 Jahre Forschungsstelle Recht im DFN

von Annette Rülke mit Thomas Hoeren


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.“


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-


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/



https://www.dfn.de/rechtimdfn/


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)


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-


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


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


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.


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-


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.


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

www.hochschulverwaltung.de


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

https://dl.gi.de

http://www.dfn.de


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)


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.


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


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.


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


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

65

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/

https://www.dfn.de/publikationen/

Documents

20 Jahre Forschungsstelle Recht - dfn.de · DFN Mitteilungen Ausgabe 94 | 3 Erstklassige Forschung und Digitalisierung gehen miteinander einher. Was jedoch bedeutet Digi - talisierung