Mehr Raum für die Wissenschaft - dfn.de · Bei hochvolumigen Amplification-Angriffen auf...

Deutsches Forschungsnetz | DFN Mitteilungen Ausgabe 91 | Mai 2017

www.dfn.de

Mitteilungen

Mehr Raum für die WissenschaftDie Initiative Eduroam off Campus

10 Jahre DFN-AAIEin Universalschlüssel zum Erfolg

Das Domain Name System im X-WiNBeständigkeit im Wandel

http://www.dfn.de

2 | DFN Mitteilungen Ausgabe 90 | November 2016

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

Gestaltung: Labor3 | www.labor3.com

Druck: Druckerei Rüss, Potsdam

© DFN-Verein 05/2017

Fotonachweis:

Titel © studo58 / iStockphoto

Seite 6/7 © SEASTOCK / iStockphoto

Seite 40/41 © sephoto / photocase.de

mailto:[email protected]

http://www.dfn.de

http://www.labor3.com

3DFN Mitteilungen Ausgabe 91 |

Ein Blick zurück und ein Wort des Dankes – der Anfang der DFN-AAI.

Anfang der 90er-Jahre hatten wir in der UB Freiburg ein Problem: Der Betrieb der Regionalen Daten-

bankinformation ReDI erforderte einen sicher authentifizierten Zugang um die lizenzpflichtigen

Inhalte der Verlage nur denen anzubieten, die auch Lizenzen zur Nutzung hatten. IP-Adresskont-

rolle war nicht sicher und Verlage und die teilnehmenden Einrichtungen in Baden-Württemberg

hatten alle unterschiedliche Zugangssysteme. Nur mit einem einheitlichen, möglichst internatio-

nal eingeführten System war dies lösbar. Unser Blick fiel auf Shibboleth, das zum damaligen Zeit-

punkt schon in einigen Ländern weltweit, u. a. auch in der Schweiz, etabliert war. Ein Förderantrag

beim BMBW wurde im Jahr 2005 bewilligt. Was lag näher, als ein Besuch in Zürich bei SWITCH, dort

lief das System schon seit einiger Zeit. Bei diesem Besuch wurde uns klar, dass wir eine lokale Ein-

führung des Systems für einzelne Systeme wohl kaum realisieren könnten: Eine nationale Föde-

ration als Grundlage des Authentifizierungsdienstes benötigte auch einen nationalen Mitspieler.

Nach dem Vorbild der Schweiz fragten wir beim DFN-Verein an und fanden ein offenes Ohr. Ein ge-

meinsames Projekt wurde Mitte des Jahres 2005 definiert. Die UB übernahm den technischen Teil

der Implementierung, der DFN-Verein die vertraglichen Arbeiten zum Aufbau der Föderation. Mar-

keting und Schulungen wurden gemeinsam angegangen. Fortan reisten Ulrich Kähler und ich zu

Universitäten und Forschungseinrichtungen und trommelten für die Föderation und Shibboleth.

Im Kielwasser kam Bernd Oberknapp mit seinem Team Hannah Born, Franck Borel und Jochen

Lienhard und bot Schulungen zur Implementierung des Systems an. Als größtes Hemmnis erwies

sich an vielen Orten ein unzureichendes Identity Management System.

Parallel dazu wurde vom Einkaufskonsortium der Bibliotheken Baden-Württembergs mit den Ver-

lagen verhandelt und die Einführung von Shibboleth zunächst empfohlen und später vertraglich

festgeschrieben. Damit stieg die Motivation bei allen Teilnehmern, bei der DFN-AAI mitzumachen.

Schon 2 Jahre nach dem gemeinsamen Projektstart, als die DFN-AAI im Herbst 2007 den Produktiv-

betrieb aufnahm, waren 14 Einrichtungen und 4 internationale Verlage aktiv dabei.

Rückblickend war dieses gemeinsame Projekt mit dem DFN-Verein für mich das spannendste,

schönste und erfolgreichste Projekt meiner Dienstzeit. Ich möchte allen Beteiligten – auch den

hier nicht genannten – ganz herzlich für die Zusammenarbeit in dieser Aufbauphase danken. Zehn

Jahre nach dem Start ist die DFN-AAI heute eine nicht mehr wegzudenkende Institution und ich

wünsche allen weiterhin viel Erfolg.

Ato Ruppert

Dipl. Phys. Johann A. Ruppert

Bibliotheksdirektor i. R.

4 | DFN Mitteilungen Ausgabe 91 | Mai 2017

16

4

7

10

13

11

14

12

2

5

2

15 16

3

6

1

8

Unsere Autoren dieser Ausgabe im Überblick

1 Henry Kluge, DFN-Verein ([email protected]); 2 Dr. Stefan Piger, DFN-Verein (piger@

dfn.de); 3 Christian Meyer, DFN-Verein ([email protected]); 4 Torsten Kersting, DFN-

Verein ([email protected]); 5 Prof. Dr. Helmut Reiser, Leibniz-Rechenzentrum-LRZ

([email protected]); 6 Rolf Borgeest, Landesamt für Digitalisierung, Breitband

und Vermessung ([email protected]); 7 Dr. Leonie Schäfer, DFN-Verein

([email protected]); 8 Helga Spitaler (GÉANT), [email protected]; 9 Audrey

Gerber (Inter-University Computation Center); 10 Dr. Jakob Tendel, DFN-Verein

([email protected]) 11 Wolfgang Pempe, DFN-Verein ([email protected]); 12 Detlef

Krummel, Georg-Eckert-Institut ([email protected]); 13 Susanne Weinmann,

Max-Planck-Gesellschaft ([email protected]); 14 Jens Syckor, TU

Dresden ([email protected]); 15 Florian Klein, Forschungsstelle Recht

im DFN ([email protected]); 16 Lennart Sydow, Forschungsstelle Recht im DFN

([email protected])

9















5DFN Mitteilungen Ausgabe 91 |

Wissenschaftsnetz

Beständigkeit im Wandel – das Domain Name

System im X-WiN

von Henry Kluge .............................................................................. 8

Der Erneuerung letzter Akt:

Eine neue Aggregations-Plattform für das X-WiN

von Stefan Piger ............................................................................ 14

DFNFernsprechen: Die Zukunft ist IP

von Christian Meyer .................................................................... 20

Einfach sicher Abstimmen:

DFN-Terminplaner jetzt auch mit DFN-AAI

von Torsten Kersting ................................................................... 24

Eduroam off Campus und BayernWLAN – eine

Win-win-Kooperation

von Helmut Reiser, Rolf Borgeest ........................................... 26

International

GÉANT weiterhin auf Erfolgskurs

von Leonie Schäfer ........................................................................ 32

Breakneck Network speed to deliver new

energy paradigms

von Helga Spitaler, Audrey Gerber ......................................... 34

Kurzmeldungen ............................................................................ 36

Forschung

GeRDI - Generic Research Data Infrastructure:

Forschungsdaten übergreifend vernetzen

von Jakob Tendel ........................................................................... 38

Sicherheit

10 Jahre DFN-AAI – ein Universalschlüssel

zum Erfolg

von Wolfgang Pempe .................................................................. 42

Sicherheit durch Clientmanagementsysteme

am von Beispiel OPSI & Communityprojekt

‚opsi4institutes‘ (o4i)

von Detlef Krummel ..................................................................... 48

Windows 10 – wie man die Datenkrake bändigt

von Susanne Weinmann, Jens Syckor ................................... 54

Sicherheit aktuell ......................................................................... 57

Recht

Wo ein Wille ist, darf auch ein Link sein

von Florian Klein ........................................................................... 58

Meldung machen!

von Lennart Sydow ...................................................................... 61

DFN-Verein

Übersicht über die Mitgliedseinrichtungen

und Organe des DFN-Vereins ................................................... 64

Inhalt

| DFN Mitteilungen Ausgabe 91 | Mai 2017 | WISSENSCHAFTSNETZ6

7WISSENSCHAFTSNETZ | DFN Mitteilungen Ausgabe 91 |

WissenschaftsnetzBeständigkeit im Wandel – das Domain Name

System im X-WiN

von Henry Kluge

Der Erneuerung letzter Akt:

Eine neue Aggregations-Plattform

für das X-WiN

von Stefan Piger


von Christian Meyer

Einfach sicher Abstimmen:

DFN-Terminplaner jetzt auch mit DFN-AAI

von Torsten Kersting

Eduroam off Campus und BayernWLAN – eine

Win-win-Kooperation

von Helmut Reiser, Rolf Borgeest

8 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | WISSENSCHAFTSNETZ

Beständigkeit im Wandel – das Domain Name System im X-WiN

Text: Henry Kluge (DFN-Verein)

Das Domain Name System (DNS) ist wohl unbestreitbar einer der wichtigsten Dienste

in IP-basierten Netzwerken. Nicht nur für die Übersetzung der Domainnamen in IP-Ad-

ressen beim Aufruf von Webseiten oder bei der E-Mail-Kommunikation, sondern eben-

falls für die Vermittlung von VoIP-Anrufen und für Verzeichnisdienste wie Microsofts

Active Directory ist die Funktionsfähigkeit des DNS eine zwingende Voraussetzung.

Diese Abhängigkeit von der DNS-Infrastruktur ist den wenigsten Anwendern und auch

nicht allen IT-Verantwortlichen so deutlich bewusst, da der Umgang mit den vom DNS

bereitgestellten „human-readable“ Namen als selbstverständlich angesehen wird.

Foto © cinoby / iStockphoto


Motivation – warum?

Im aktuellen X-WiN und den Vorgängerge-

nerationen des Wissenschaftsnetzes spiel-

te das Domain Name System schon immer

eine große Rolle, auch wenn es anders als

andere Dienste nie im direkten Rampen-

licht stand. Neben der Anmeldung und Ver-

waltung von Domains im Rahmen des DFN-

Internet-Dienstes betreibt der DFN-Verein

schon seit vielen Jahren eine DNS-Serverin-

frastruktur. Mittels dieser Server wird An-

wendern die Möglichkeit gegeben, die von

ihnen auf den eigenen primären Systemen

verwalteten DNS-Domains bzw. Zonen über

sogenannte Secondary Name Server hoch-

verfügbar abzusichern. Als weitere Dienst-

leistung werden im X-WiN Recursive Na-

meserver angeboten.

2015 war für den DFN-

Verein der Zeitpunkt

gekommen, sich mit der

DNS-Infrastruktur neu

auseinanderzusetzen.

Diese, auch als DNS Cache Server oder Re-

solver bekannten Systeme, ermöglichen

eine direkte Abfrage von DNS-Informati-

onen. Auch wenn die DNS-Grundstruktur

über die letzten Jahrzehnte sehr stabil war,

ist es wie bei anderen Diensten notwen-

dig und sinnvoll, die aktuelle Implementie-

rung in einem sich verändernden Umfeld

zu prüfen und auf neue Anforderungen zu

reagieren. Im Jahr 2015 war für den DFN-

Verein der Zeitpunkt gekommen, sich mit

dieser Fragestellung auseinanderzusetzen.

Ausgangslage – woher?

Konkrete Auslöser für die Beschäftigung

mit diesem Thema waren zum einen die

in die Jahre gekommene Server-Hardware

der DNS-Server und zum anderen die deut-

liche Zunahme an DoS-Vorfällen, auch auf

DNS-Infrastrukturen. Auch wenn die vor-

rangig genutzten SUN T1000 Server von der

Leistung grundsätzlich noch ausreichend

waren, so ist doch trotz vorhandener War-

tungsverträge ein Ende der Lebenszeit die-

ser soliden und bewährten Systeme abseh-

bar. Viel stärker machte sich jedoch ein

Nachteil der ursprünglich sehr sinnvollen

Verteilung von insgesamt 14 DNS-Servern in

der Fläche bemerkbar (siehe Abbildung 1).

Eine Konsolidierung der

DNS-Infrastruktur sollte

angegangen werden.

Bei hochvolumigen Amplification-Angriffen

auf DNS-Server in der äußeren Peripherie

kam es zu spürbaren Beeinträchtigungen

von Anwendern, deren Datenverkehr über

die gleiche Router-Kette geführt wurde,

da auf dieser durch den Angriffsverkehr

nicht mehr die volle Netzwerkbandbreite

zur Verfügung stand. Darüber hinaus sind

in der derzeit genutzten Server-Hardware

nur Netzwerkschnittstellen mit 1 Gbit/s

einsetzbar. Weitere Themen, die mit ei-

ner Konsolidierung der DNS-Infrastruk-

tur angegangen werden sollten, waren

die vollständige Unterstützung von IPv6

und DNSSEC sowie die komplette Trennung

der autoritativen und rekursiven Funktio-

nen. Der letzte Punkt ist insbesondere bei

der standardkonformen Implementierung

von DNSSEC wichtig, da sonst „lokal“ ge-

haltene Zonen nicht durch den Recursor

validiert werden können.

Zielarchitektur – wohin?

Nach einer umfassenden Analyse der Aus-

gangslage wurde eine Architektur entwi-

ckelt, die sowohl die bekannten Anforde-

rungen berücksichtigt als auch auf zukünf-

tige Ansprüche vorbereitet ist.

Zur Sicherstellung der im folgenden auf-

geführten Ziele wurden Eckpunkte für ei-

ne Umsetzung definiert:

1. Vereinfachung von Betrieb und

Administration durch Reduktion

der Serverinstanzen.

Nur noch 3 Secondary

Server und 3 Recursive

Name Server.

Abbildung 1: DNS-Infrastruktur im X-WiN im Jahr 2015

Secondary NS

Recursive NS


2. Sicherstellung eines langfristigen

Supports durch einheitliche HW- und

SW-Plattform.

Betrieb als Virtual Machines (VM)

auf der Server-Infrastruktur des

DFN-Vereins an dafür ausge-

wiesenen Serverstandorten.

3. Erhöhung der Stabilität und Sicher-

heit durch Trennung von Funktionen.

Separierung von Authoritative

Name Server und Recursive

Name Server.

4. Besserer Schutz vor DoS-Vorfällen

durch optimale Platzierung im X-WiN.

Anbindung per 10 Gbit/s an den

Standorten Erlangen, Hannover

und Berlin in direkter Nähe zur

DoS-Mitigations-Infrastruktur.

Aus reiner DNS-Perspektive wäre es mit

dem besonderen Fokus auf die Verbindun-

gen in die „Außenwelt“ natürlich beson-

ders wünschenswert auch an dem „Pee-

ring-Standort“ Frankfurt/M. (FRA) mit ei-

ner Infrastruktur präsent zu sein. Bei der

Auswahl der DFN-Serverstandorte konn-

te dieser Kernnetzknoten allerdings nicht

berücksichtigt werden, da ein wirtschaftli-

cher Serverbetrieb von eigener Hardware

in kommerziellen Collocations, wie in die-

sem Fall bei der Firma interxion, für den

DFN-Verein nicht darstellbar war.

Grundsätzlich ist es bei Bedarf jedoch re-

lativ einfach möglich, durch die Nutzung

der Virtualisierung, sowohl an den defi-

nierten Serverstandorten als auch an an-

deren SuperCore-Standorten, die Anzahl

der Instanzen zu erhöhen. In diesem Zu-

sammenhang wird vom DFN-Verein auch

die Weiterentwicklung der „klassischen“

Router zu Systemen mit erweiterten netz-

nahen Funktionen im Auge behalten. Bes-

tes Beispiel für die erfolgreiche Nutzung

solcher Konzepte sind die Virtual Service

Module (VSM) in den SuperCore-Routern

für die Realisierung des DoS-Schutzes im

Wissenschaftsnetz.

Als wichtigste Anforderung an die neue Um-

gebung galt es jedoch, die im täglichen Be-

trieb bewiesene Stabilität und Robustheit

des Gesamtsystems zu erhalten. Gerade

beim Einsatz einer Virtualisierung im DNS-

Umfeld gab es im DFN-Verein noch keine

praktischen Erfahrungen und somit einen

notwendigen Klärungsbedarf zur techni-

schen Umsetzbarkeit. Aus diesem Grund

war es besonders wichtig der Umsetzungs-

phase einen angemessenen Vorbereitungs-

und Testzeitraum voranzustellen.

Vorbereitung – wie?

Neben den rein technischen Fragestellun-

gen, wie z. B. welche Hard- und Software-

Plattform notwendig und sinnvoll einsetz-

bar ist, wurden ebenfalls die betrieblichen

Abläufe und eingesetzten Tools auf den

Prüfstand gestellt. Hier war es unter ande-

rem das Ziel, durch den Einsatz von Konfi-

gurationswerkzeugen wie „Ansible“, eine

standardisierte und flexibel anpassbare

Dienstumgebung für die DNS-Infrastruk-

tur bereitzustellen. Auch ein zentrales Re-

pository für alle verwalteten Secondary-

Zonen, zurzeit mehr als 18.000 Zone Files,

sollte in diesem Zuge eingeführt werden.

Die Rahmenparameter zur konkreten Um-

setzung auf der HW-Ebene wurden durch

die eingesetzte DELL-Blade-Server Umge-

bung grundsätzlich definiert. Pro Server-

st andort wurden exklusiv für die Nutzung

durch DNS-Dienste initial jeweils zwei DELL

M630-Blade-Module (2 x Intel Xeon E5-2620,

24 GB RAM) und 10 Gbit/s Interfaces vor-

gesehen und beschafft. Für die Virtuali-

sierung wird die auch für andere Diens-

te im DFN-Verein standardmäßig verwen-

dete Kernel-Based Virtual Machine (KVM)

Architektur auf einem Linux-Hostsystem

eingesetzt.

Bei der Auswahl der eigentlichen DNS-Ser-

ver Software wurden alternative Lösungen

für die Implementierung der DNS-Funkti-

onen wie z. B. PowerDNS, unbound und

Knot geprüft, allerdings zugunsten des ISC

BIND verworfen. Hauptgründe hierfür wa-

ren die guten jahrelangen Erfahrungen mit

ISC BIND im DFN-Verein und der erwarte-

Abbildung 2: Zielarchitektur DNS-Infrastruktur im X-WiN

Secondary NS

Recursive NS


te Mehraufwand für die Einführung eines

neuen Produkts inklusive des damit ver-

bundenen potenziellen Stabilitätsrisikos.

Weiterhin bestand aufgrund der bekann-

ten und prognostizierten Performancean-

forderungen keine Notwendigkeit spezi-

alisierte und auf einzelne Funktionen op-

timierte Softwarelösungen einzusetzen.

Durch die strikte Funktionstrennung ist

der Austausch einzelner Server bei zukünf-

tigen und unter Umständen höheren An-

forderungen problemlos möglich.

Neben der bereits oben erwähnten Robust-

heit des Gesamtsystems gegenüber DoS-

Vorfällen stand der Einsatz der im Folgen-

den aufgeführten spezifischen Sicherheits-

funktionen im Fokus:

• Minimal-Installation und Härtung

des Betriebssystems,

• Separierung von Produktions – und

Management-Interfaces,

• Einsatz von Host-ACL auf jedem

System,

• Einsatz eines separaten Build-

Systems zur Erstellung der

BIND-SW-Pakete,

• Einsatz spezifischer BIND Funktio-

nen wie z. B. Response Rate Limiting

[BIND RRL].

Zum Abschluss der Vorbereitungsphase

wurden in einer Testumgebung unter

Nutzung der vorgesehenen Hardware

umfangreiche betriebliche und funktio-

nale Tests durchgeführt. Auch ein finaler

Performancetest mit der frei verfügba-

ren Testsoftware DNSPerf der Firma No-

minum [DNSPerf] zeigte die volle Einsatz-

fähigkeit innerhalb einer Virtual Machine-

Umgebung. Selbst die in der Testumgebung

generierten Anfrageraten von mehreren

hunderttausend DNS-Requests pro Sekun-

de führten zu keinerlei Einschränkungen

bei der mittleren Antwortzeit oder der

Stabilität der Systeme. Diese Ergebnisse

liegen um den Faktor 100 über der maxi-

mal erwarteten Belastung unter norma-

len Produktionsbedingungen.

Mit der Definition der Systemumgebung

und dem Nachweis der Leistungsfähigkeit

waren die Grundlagen für die Planung und

Umsetzung der einzelnen Phasen einer

Konsolidierung der DNS-Infrastruktur im

X-WiN gegeben.

Umsetzungsphase –

a long run ...

Die nächste große Herausforderung inner-

halb des Gesamtprojekts war nun die Auf-

stellung eines Migrationsplans, der die Um-

setzung der angestrebten Ziele in kurzer

Zeit ermöglichte, ohne aber für die Nutzer

der DNS-Dienste spürbare negative Aus-

wirkung zu haben.

Dieser Gesamtplan wurde zunächst in 3

Hauptphasen unterteilt:

1. Migration der Funktionalitäten der

vorhandenen DNS-Server DNS-1,

DNS-2 und DNS-3 in Virtual Machines

der neuen Serverinfrastruktur.

2. Migration aller weiteren DNS-Ser-

ver Virtual Machines auf die neue

Serverinfrastruktur.

3. Konsolidierung aller Secondary-

Zonen auf die DNS-Server DNS-1,

DNS-2 und DNS-3.

Phase 1 – Etablierung der ersten DNS-

Server als virtuelle Instanzen

Oberstes Ziel dieser ersten Phase war es,

die während der Tests gesammelten Er-

fahrungen unter Produktionsbedingungen

zu bestätigen und eventuell notwendigen

Änderungsbedarf zu identifizieren. Hier-

für wurde als Pilot die DNS-Recursor Funk-

tionalität des Servers DNS-3 in eine sepa-

rate VM als RES-3 unter Beibehaltung der

IP-Konfiguration am Standort Erlangen

migriert. Trotz einiger kleiner Fehler, die

schnell behoben werden konnten, verlief

die Migration weitestgehend reibungslos

und wie erwartet.

Als nächster Schritt stand die VM-Migration

des autoritativen Teils (Secondary Zones)

Abbildung 3: Umsetzung DNS-Konsolidierung Phase 1

Secondary NS

Recursive NS


des DNS-3 an. Auch hier wurde die Funk-

tionsfähigkeit des Systems in der neuen

Umgebung innerhalb des geplanten War-

tungsfensters vollständig hergestellt. Nach

der Einbindung in die Monitoring-Umge-

bung wurden die beiden Systeme inten-

siv auf eventuelle Auffälligkeiten und

Abweichungen zur vorherigen Betriebs-

umgebung geprüft.

Nachdem sichergestellt war, dass alle DNS-

Funktionen auf den Servern DNS-3 und RES-

3 ohne Einschränkung verfügbar waren,

wurden die verbleibenden Umzüge der

Authoritativen Server DNS-1 und DNS-2

sowie der DNS-Recursor RES-1 und RES-

2 durchgeführt. Die erwartete Stabilität

und Performance konnte auch für diese

Server von Beginn an vollständig erbracht

werden und somit die erste Phase erfolg-

reich abgeschlossen werden (siehe Abbil-

dung 3, S. 11).

Phase 2 – vollständiger Umzug in die

Virtual Machine Umgebung

Inhalt der zweiten Phase ist die Migration

der restlichen 10 DNS-Server in die VM-Um-

gebung (siehe Abbildung 4). Hier ist neben

der Außerbetriebnahme der SUN-Server die

Vorbereitung zur Übernahme der Seconda-

ry Zonen auf die DNS-Server DNS-1, DNS-2

und DNS-3 das Hauptziel. Die Verteilung

der VM-Umgebung auf nur 3 Serverstand-

orte stellt hier eine zusätzliche Herausfor-

derung dar. In der bisherigen Konstellati-

on wurden viele Domains auf geografisch

verteilten DNS-Servern abgestützt. Für die-

se musste sichergestellt werden, dass sie

auf unterschiedliche VM migriert werden,

dann aber nicht im selben Serverstandort

betrieben werden. Zusätzlich erzeugte die

hohe Anzahl von Domains durch diese Rah-

menbedingung einen nicht zu vernachläs-

sigenden Aufwand.

Da diese DNS-Server zum überwiegenden

Teil mit hostspezifischen Parametern kon-

figuriert sind und nur eine kurze weitere

„Lebenszeit“ haben werden, wird dessen

Konfiguration weitestgehend 1 : 1 auf der

VM abgebildet. Hier kommt aus Migrations-

ʃ Information zur Migration durch DFN-Verein per E-Mail an

zuständigen Zonen-Admin beim Anwender:

• Listung der betroffenen Domains und der zukünftigen

Secondary Name Server

ʃ Freischaltung des Zonentransfers für die neuen DNS-Server auf

dem Primary Server:

• Info an [email protected]

ʃ Konfigurieren des neuen Secondary Servers:

• Info an Anwender

ʃ Anpassung des Zonenfiles auf dem Primary Server:

• alte NS-Records entfernen

• neue NS-Records (DNS-1, DNS-2 oder DNS-3) einfügen

ʃ Anpassung der Delegierung (NS-Records) in den übergeordneten

Zonen durch den DFN-Verein.

ʃ Abschließende Prüfung der Funktionalität (Zonentransfer,

erfolgreiche Auflösung etc.).

ʃ Weiterbetrieb der Zone auf den alten DNS-Servern für noch

mindestens eine TTL wegen Ausaltern der Cachings auf externen

Recursor/Cache-Servern.

Die Detailinformationen (IP-Adressen, Hostname, Standorte) zu den für

Anwender des DFNInternet-Dienstes nutzbaren Secondary Name Servern

und Recursor/Cache-Servern können über die E-Mail-Adresse hostmaster@

dfn.de oder per Telefon unter +49 30 884299 9910 angefragt werden.

STANDARDABLAUF DER MIGRATION VON DOMAINS/ ZONES AUF SECONDARY NAME SERVER

Die folgend aufgeführten Funktionen und Services werden aufgrund

der Konsolidierung zum aufgeführten Zeitpunkt eingestellt:

ʃ Backup-MX-Funktionalität zum Spooling von E-Mails

• Einstellung mit der Außerbetriebnahme der DNS-Server

ab 30.06.2017 bis spätestens 30.06.2018

ʃ Smarthost bzw. SMTP-Relay-Server zur Weiterleitung von E-Mails

• Einstellung zum 30.06.2018

• es erfolgt eine separate Kontaktierung der Nutzer zur Abstimmung

eines Zeitplans bezüglich der Umstellung

EINSTELLUNG VON FUNKTIONEN UND SERVICES



sicht erschwerend hinzu, dass auch noch

weitere nicht DNS-spezifische Funktionen

und Services auf den Systemen laufen. Die-

se nicht vertraglich definierten Dienste

werden im Rahmen der Migration einge-

stellt (siehe oranger Kasten).

Phase 3 – Migration aller Secondary

Zones zum Sollzustand

In der abschließenden dritten Phase er-

folgt der Umzug aller auf den in der zwei-

ten Phase migrierten DNS-Servern konfigu-

rierten Secondary Zones auf die DNS-Ser-

ver DNS-1, DNS-2 und DNS-3 und damit die

Herstellung des Zielzustands. Dieser Teil

der Migration ist aus operativer Sicht wei-

testgehend unkritisch, jedoch administra-

tiv und zeitlich mit dem größten Aufwand

verbunden. Als Standardverfahren ist vor-

gesehen, die zuständigen Verwalter der

betroffenen Domains einzeln und gezielt

per E-Mail zu kontaktieren und nach einem

Standardablauf die genutzten Secondary-

Server umzustellen (siehe blauer Kasten).

Da diese Umstellungen unabhängig von

der VM-Migration der DNS-Server durchge-

führt werden können, wurde damit bereits

im Oktober 2016 begonnen. Hier konnten

dank der aktiven Mitarbeit der Anwender

mehrere tausend Zonen in die neue Um-

gebung umgezogen werden.

Status, Zeitplanung und (vorläufiges) Fazit – wie lange noch?

Mit dem Erscheinen dieser Ausgabe der

DFN-Mitteilungen befindet sich die Konso-

lidierung der DNS-Infrastruktur im X-WiN

mitten in der zweiten Phase, also der Virtu-

alisierung der SUN-Systeme. Nach aktueller

Zeitplanung, die auch direkt mit dem Pro-

jekt zur Migration der Aggregationsplatt-

form zusammenhängt (siehe auch Artikel

S. 14), soll diese Phase bis zum 30.06.2017

abgeschlossen sein.

Aus Sicht der Anwender ist die dritte Phase

besonders relevant, da sie direkt davon be-

troffen sind. Für die vollständige Migration

aller Secondary-Zones auf die verbleiben-

den DNS-Server DNS-1, DNS-2 und DNS-3 ist

der 30.06.2018 als Zieldatum festgesetzt.

Deshalb an dieser Stelle der Aufruf zur

Kenntnisnahme dieser „Deadline“ und der

damit verbundenen Bitte zur Unterstüt-

zung der Migration, um auch in Zukunft

dem DFN-Verein die effiziente und quali-

tativ hochwertige Erbringung von DNS-

Diensten im Sinne einer „Beständigkeit

im Wandel“ zu ermöglichen. M

Links & Quellen

[BIND RRL] ISC Knowledge Base - https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html

[DNSPerf] Nominum DNSPerf - http://www.nominum.com/measurement-tools/

Abbildung 4: Umsetzung DNS-Konsolidierung Phase 2

Secondary NS

Recursive NS

https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html

http://www.nominum.com/measurement-tools/


Der Erneuerung letzter Akt: Eine neue Aggregations-Plattform für das X-WiNDie Runderneuerung des X-WiN geht in die letzte Phase. Nach der Modernisierung

der DWDM-Technik für die Optische-Plattform und der Router des IP-SuperCore

werden nun als vorerst letzter Schritt die Router der IP-Aggregations-Plattform

ausgetauscht.

Text: Stefan Piger (DFN-Verein)

Foto © nesharm / iStockphoto


Die Aggregations-Router stellen für die große Mehr-

heit der Teilnehmer am DFNInternet-Dienst die Schnitt-

stelle zwischen ihrer Teilnehmeranbindung und dem

Kernnetz des X-WiN dar. Wie der Name „Aggregations-

Plattform“ bereits suggeriert, nehmen diese Router als

wesentliche Aufgabe die Bündelung der Teilnehmer-

Verkehre in Richtung des X-WiN Kernnetz wahr. Dane-

ben stellen sie Layer-2- und Layer-3-VPN-Infrastruktu-

ren bereit und dienen als lokale Ethernet-Switches.

Die derzeitige Aggregations-Plattform wurde in den

Jahren 2005 – 2008 mit mehr als 50 Geräten vom Typ Cis-

co 7609 und 7609-S ausgestattet und seitdem nur wenig

verändert betrieben. Da der Hersteller für diese Sys-

teme absehbar keine technische Unterstützung oder

Aktualisierungen der Betriebssoftware mehr gewähr-

leistet, müssen die Geräte nun ausgetauscht werden.

Der Auslöser für die Modernisierung zum jetzigen Zeit-

punkt ist somit in erster Linie die Aufrechterhaltung

der betrieblichen Sicherheit des X-WiN. Darüber hin-

aus bietet sich aber auch die Chance, die Leistungsfä-

higkeit der Aggregations-Plattform sowohl funktio-

nal als auch in Bezug auf die Übertragungskapazität

signifikant zu erhöhen und damit das X-WiN für neue

Herausforderungen zu rüsten.

Neue Architektur der IP-Plattform

des X-WiN

Die Notwendigkeit, die Aggregations-Plattform zu mo-

dernisieren, bot auch die Gelegenheit, die Architektur

der derzeitigen IP-Plattform des X-WiN zu überdenken

und sie an die aktuellen Erfordernisse anzupassen.

So wurde mit der Einführung des X-WiN dessen IP-

Backbone mit voller Internet Routing Tabelle an je-

dem Kernnetzknoten betrieben. Dadurch konnten

lokal auf jedem System der Aggregations-Plattform

DFNInternet-Dienste und zudem auf Wunsch des Teil-

nehmers immer auch die komplette globale Internet

Routing Tabelle bereitgestellt werden.

Dieses Konzept musste bereits im Laufe des Jahres

2013 an vielen Standorten aufgeweicht werden, da die

Internet Routing Tabelle absehbar auf über 512.000

IPv4-Routen anwachsen würde und diese nicht mehr

vollständig in den eingesetzten Systemen vom Typ

Cisco 7609 abbildbar sein würde.

Um unkontrollierte Speicherüberläufe und damit den

Verlust von Routen zu vermeiden, wurden durch das

DFN-NOC ab diesem Zeitpunkt die Zahl der Routen

auf den Aggregations-Routern reduziert. Hierfür wur-

den nur noch die vollständigen Routing-Informatio-

nen des X-WiN und seiner Teilnehmer sowie die der

globalen NREN-Community vorgehalten, um für die-

se Ziele weiterhin ein optimales Routing zu ermögli-

chen. Alle weiteren spezifischen Routen über die IP-

Upstreams wurden nur noch auf den Systemen des

SuperCore vorgehalten und den Aggregations-Syste-

men per Default-Route annonciert. Für einzelne An-

wender, die eine volle Routing-Tabelle benötigten, war

es möglich, mit dem punktuellen Einsatz von Aggre-

gations-Systemen mit neueren Route-Prozessoren

(RSP720), diese Anforderung zu erfüllen.

Ein weitaus gravierenderes Problem entstand durch

das vermehrte Aufkommen volumetrischer Distributed-

Denial-of-Service (DoS) Vorfälle, die Zielsysteme durch

Überfluten mit großen Mengen von IP-Verkehr für le-

gitime Nutzer unerreichbar machen.

In der aktuellen Architektur des X-WiN IP-Backbone

werden diese Angriffe ohne Beschränkungen in der

genutzten Datenrate bis zum Übergang von der Aggre-

gations-Plattform zur Teilnehmeranbindung weiterge-

leitet. Dort wird schließlich der Verkehr auf die Band-

breite entsprechend der gewählten DFNInternet-

Abbildung 1: Architektur von DFNInternet-Teilnehmeranbindungen im X-WiN – heute

KR

DUI

BON BIR

Teilnehmeranbindung (physisch)Kernnetz (100 Gbit/s)

Kernnetz (20 Gbit/s)

DUI HAN

FRA


Kategorie beschränkt. Dies kann bei entsprechendem Volumen

des Angriffs die Ketten der Aggregations-Plattform überlasten

und damit auch weitere, nicht direkt angegriffene Anwender

stark beeinträchtigen. Im X-WiN wurden bereits DoS-Vorfälle mit

Datenraten beobachtet, die die typische Dimensionierung der

Anbindungen von Aggregations-Systemen in den X-WiN Ketten

von 10 – 20 Gbit/s weit überschritten.

Zur Verdeutlichung des Problems soll hier ein Ausschnitt aus

dem X-WiN IP-Backbone mit einem exemplarischen Teilnehmer

herangezogen werden (vgl. Abbildung 1).

Dargestellt ist ein Teilnehmer, der an den X-WiN Kernnetzkno-

ten an der Universität Duisburg-Essen (DUI) und an der Univer-

sität Bonn (BON) angebunden ist. An diesen Kernnetzknoten

wird auch der DFNInternet-Dienst bereitgestellt. Die Router der

Aggregations-Plattform in den Kernnetzknoten DUI und BON

wiederum sind in einer Kette mit einer Kapazität von 20 Gbit/s

mit dem Router am Kernnetzknoten BIR angebunden. Die Ket-

te terminiert am IP-SuperCore an den Kernnetzknoten DUI und

FRA. Im SuperCore stehen Bandbreiten von 100 – 200 Gbit/s je

Spange zur Verfügung.

Wird nun auf den dargestellten Teilnehmer ein DoS-Angriff ausge-

führt, der über den Knoten FRA aus dem SuperCore in die Aggre-

gations-Plattform geleitet wird, so traversiert dieser Angriffsver-

kehr erst den Kernnetzknoten BIR bevor er am Kernnetzknoten

BON auf die Teilnehmeranbindung geleitet wird. Hat der Angriffs-

verkehr eine Datenrate größer als die aktuell freie Übertragungs-

kapazität auf der Strecke FRA-BIR-BON, so beeinträchtigt er die

Qualität aller DFNInternet-Dienste, die an diesen Kernnetzkno-

ten terminieren. Diese Einschränkung bleibt bestehen, bis das

DFN-NOC geeignete Gegenmaßnahmen einleiten kann oder der

Angriff beendet wird.

Die zukünftige Architektur der IP-Plattform des X-WiN muss nun

die dargestellten Probleme adressieren, ohne für die Teilneh-

mer am DFNInternet-Dienst signifikante Einschränkungen nach

sich zu ziehen.

Die grundlegende Änderung betrifft den Ort, an dem DFNInter-

net-Dienste realisiert werden. Künftig werden diese nicht mehr

lokal auf dem Aggregations-Router konfiguriert, sondern direkt

auf den Router-Systemen des SuperCore. Dazu wird der Verkehr

des jeweiligen DFNInternet-Dienstes zwischen dem die Teilneh-

meranbindung terminierenden Aggregations-Router und dem

den jeweiligen DFNInternet-Dienst erbringenden Su perCore-

Router in einem Tunnel (IP/MPLS Pseudowire) geführt. Auf dem

SuperCore-Router wird er dann auf einer logischen Schnittstel-

le (sog. Pseudowire Headend) terminiert und nachfolgend glo-

bal geroutet (Abbildung 2).

Durch die Verlagerung der IP-Übergabeschnittstelle auf die leis-

tungsfähigen SuperCore Router können alle Teilnehmer am DFN-

Internet-Dienst künftig die volle Internet Routing Tabelle erhalten.

Auch werden in Richtung Teilnehmer fließende Verkehre künf-

tig am Übergang vom SuperCore in die Ketten der Aggregations-

Plattform auf die Datenrate der durch den Teilnehmer gewähl-

ten DFNInternet-Kategorie beschränkt. Dadurch wird eine Über-

lastung der jeweiligen Kette durch DoS-Vorfälle auf einen Teil-

nehmer effektiv verhindert.

Die neue Architektur erzeugt gegenüber dem aktuellen Modell

allerdings auch Mehraufwände insbesondere bei der initialen

Konfiguration von DFNInternet-Diensten und beim Fehlerma-

nagement. Diese Mehraufwände konnten jedoch durch eine ver-

stärkte Automatisierung von Konfigurationsvorgängen auf ein

beherrschbares Maß beschränkt werden.

Weiterhin erzeugt die neue Architektur geringfügige zusätzliche

Latenzen bei Kommunikationsbeziehungen zwischen Anwendern

in der gleichen Aggregations-Kette. Verursacht wird dies durch den

zusätzlichen Weg, den jedes IP-Paket zum nächsten SuperCore-

Router und wieder zurücknehmen muss. Die Auswirkungen dieses

Effekts werden allerdings durch den in 2015 erfolgten Ausbau des

SuperCore von vier auf acht Router-Systeme und der damit einherge-

henden Verkürzung der Aggregations-Ketten deutlich abgemildert.

Um diese Verbesserung optimal nutzen zu können, sollten

alle doppelt angebundenen Teilnehmer die beiden Verbindun-

gen ihrer Teilnehmeranbindung in einer aktiv/aktiv Konfigura-

Teilnehmeranbindung (physisch)

Teilnehmeranbindung (logisch)



KR

Abbildung 2: Architektur von DFNInternet-Teilnehmeranbindungen im

X-WiN – künftig

DUI

BON BIR

DUI HAN

FRA


tion nutzen. Beratungen und Dokumentationen zu

evtl. erforderlichen Umstellungen bietet das DFN-

NOC an.

Insgesamt erwartet der DFN-Verein, dass die neue

Architektur den IP-Backbone des X-WiN und insbe-

sondere den DFNInternet-Dienst erheblich robuster

gegenüber neuen Herausforderungen machen wird

und dies bei Erhalt der gewohnten Leistungsfähigkeit

und Verfügbarkeit.

Auswahlkriterien für eine neue

Aggregations-Plattform im X-WiN

Nachdem die Architektur des künftigen IP-Backbone

feststand, konnten die Anforderungen an die hierfür

erforderlichen Systeme spezifiziert werden. Gesucht

wurde eine Plattform, die mit den an das X-WiN ge-

stellten Anforderungen wachsen kann und durch den

Hersteller über einen ähnlich langen Zeitraum unter-

stützt und weiterentwickelt wird, wie es bei den Gerä-

ten der aktuellen Aggregations-Plattform der Fall ist.

Wie bisher wird eine grundlegende Anforderung die

Fähigkeit zum Routing von IPv4 und IPv6 sowie die

Unterstützung der im X-WiN verwendeten Routing-

Protokolle sein. Durch die neue Architektur des IP-

Backbone entfällt aber die Notwendigkeit, die volle

Internet Routing Tabelle halten zu können.

Unverändert sollten die neuen Systeme Funktionen

und Technologien bereitstellen, mit denen die für die

zukünftige Architektur von Teilnehmeranbindungen

notwendigen Layer-2-Kanäle als auch VPN-Infrastruk-

turen auf Layer-2 und Layer-3 für die Teilnehmer am

X-WiN abgebildet werden können.

Zusätzlich zu den bisher angebotenen Punkt-zu-

Punkt-Verbindungen auf Layer-2 sollten nun auch

Multi-Punkt-Verbindungen auf Layer-2 unterstützt

werden. Auch das transparente Tunneln von VLAN-

Trunks der Teilnehmer durch das X-WiN stand auf der

Anforderungsliste, um Kopplungen von RZ-Infrastruk-

turen künftig besser unterstützen zu können.

Durch die erheblich gestiegene Zahl von Teilnehmer-

diensten, aber insbesondere durch das permanent

steigende übertragene Datenvolumen im X-WiN (in

2016 25 % Steigerung zum Vorjahr), waren auch An-

forderungen an eine deutliche Steigerung der aggre-

gierten Systemkapazität überaus wichtig.

Aus diesen Gründen war nicht nur wie aktuell auch

die Unterstützung einer großen Anzahl von Fast-Ether-

net und Gigabit-Ethernet-Schnittstellen notwendig,

sondern auch die Option, die Zahl der nutzbaren

10-Gigabit-Schnittstellen erheblich zu erhöhen.

Foto © alexey_ds / iStockphoto


Schließlich mussten die Systeme auch eine begrenzte Anzahl von

100-Gigabit-Ethernet-Schnittstellen unterstützen, um eine pers-

pektivische Aufrüstung der Aggregations-Ketten zu ermöglichen.

Ein weiterer essenzieller Aspekt bei der Auswahl der Aggrega-

tions-Plattform, war die Unterstützung eines effizienten Mana–

gements und Monitorings der eingesetzten Systeme sowie die

möglichst nahtlose Integration in die bestehenden Prozesse der

DFN-Geschäftsstelle.

Ein weiteres Kriterium war die erhebliche Reduktion der Leistungs-

aufnahme gegenüber den heute eingesetzten Systemen. Auch

sollte der, durch diese benötigte Einbauraum in den Datenschrän-

ken der Kernnetzknoten, deutlich geringer sein als heute.

Die neue Aggregations-Plattform

Nachdem die Auswahlkriterien feststanden, konnte die Aus-

schreibung für die neue Plattform vorbereitet und im zweiten

Halbjahr 2016 veröffentlicht werden. Das Ergebnis der Ausschrei-

bung war für den DFN-Verein unter technischen und wirtschaft-

lichen Gesichtspunkten sehr positiv. Der Zuschlag erfolgte kurz

vor Weihnachten 2016.

Das erfolgreiche Angebot beinhaltet Router-Systeme des Typs

Cisco ASR907. Die Geräte erfüllen alle geforderten Eigenschaf-

ten und sind nach ersten Tests im Labor des DFN-NOC gut für

den geplanten Einsatzzweck geeignet.

Ein wesentliches Kriterium bei der Beschaffung der neuen Aggre-

gations-Plattform war, dass die neue technische Plattform eine

ähnlich lange Betriebsdauer erreichen wird wie deren Vorgän-

gerplattform. Bei den nun beschafften Systemen handelt es sich

um ein noch sehr junges Produkt, dessen Markteinführung erst

Ende 2015 erfolgte. Damit ist die technische Weiterentwicklung

sowohl in Bezug auf die Funktionalität als auch auf die techni-

sche Leistungsfähigkeit für einen längeren Zeitraum abschätz-

bar und durch entsprechende Herstelleraussagen bestätigt.

Abbildung 3: Phasen der Migration auf die neue Aggregations-Plattform

1

2

0

4

12

5

6

7

8

910

11

10 GE

2 x 10 GE

5 x 10 GE

100 GE

MUE BIE HAN

BRE

EWE

AAC

DUI

BON BIR

DORBOC

KAISAA FZK STU AUG

GSI HEI

WUE

GAR FHM

REG

GOE

KAS

MAR

GIE

FRB

FRA

BRA MAG POT ZIB

HAM

KIE

DES

TUBFFO

GRE

ROS

DRE

CHE

CHE

HUB LEI

ADH

LAP

BAY

ILM

ERL

JEN

3

13

HAM

HAN

FRA

TUB

ERL

GAR

LAPDUI


Planung für die Migration auf die neue

Aggregations-Plattform

Als Vorbereitung für den Einsatz der neuen Aggrega-

tions-Plattform wurden bereits seit Anfang 2016 um-

fangreiche Vorarbeiten geleistet. Erheblichen Anteil

an diesen hatten Maßnahmen an den Kernnetzkno-

ten, um die neuen Systeme parallel zu den Bestands-

systemen einbauen und in Betrieb nehmen zu kön-

nen. Ziel dieser Arbeiten war es, die Unterbrechungs-

zeiten bei der Migration der Teilnehmeranbindungen

so gering wie möglich zu halten.

Weitere Maßnahmen betrafen die seit den Anfangs-

tagen des X-WiN an den Kernnetzknoten betriebenen

Server-Systeme, die nicht für lokale Betriebsaufgaben

wie dem Netzmanagement und der Qualitätssicherung

der Netzperformance benötigt werden. So wurden

etwa Systeme für den VC- und Eduroam-Dienst sowie

DNS-Server (siehe Artikel S. 8) an Kernnetzknoten au-

ßerhalb des SuperCore betrieben. In der neuen Archi-

tektur der IP-Plattform können diese Server-Dienste

nicht mehr an der Aggregations-Plattform betrieben

werden, sodass sie an die zentralen Server-Stand orte

des X-WiN migriert werden mussten. Diese Server-

Standorte befinden sich an den SuperCore-Standor-

ten in Erlangen, Hannover und Berlin.

Die Migration auf die neuen Aggregations-Systeme

wird grundsätzlich an jedem Kernnetzknoten in drei

Arbeitsschritten erfolgen:

1. Im ersten Schritt wird das betreffende System

in einer Laborumgebung komplett zusammen-

gebaut, getestet und vom DFN-NOC mit einer

initialen Konfiguration versehen. Nachfolgend

wird das System verpackt und an den vorgese-

henen Kernnetzknoten verschickt.

2. Im zweiten Schritt wird das System am Kern-

netzknoten eingebaut, in Betrieb genommen

sowie in den IP-Backbone und die Monitoring-

systeme des X-WiN integriert.

3. Im dritten Schritt werden alle Teilnehmeran-

bindungen vom Bestandssystem auf den neu-

en Aggregations-Router migriert. Nachfolgend

wird das Bestandssystem abgebaut und vom

Kernnetzknoten abtransportiert.

Aus Effizienzgründen für die Logistik und um den Paral-

lelbetrieb von neuen und Bestandssystemen in der

gleichen Aggregations-Kette kurz zu halten, werden

alle Standorte in einer Aggregations-Kette in einem

zusammenhängenden Zeitraum abgearbeitet. Insge-

samt wurden 14 dieser Zeiträume definiert, die in Ab-

bildung 3 mit den Ziffern 0 – 13 dargestellt sind. Da-

bei wurden die Standorte für die ersten Migrationen

so ausgewählt, dass der gewählte Ansatz verifiziert

werden und mit den ersten Erfahrungen für die nach-

folgenden Arbeiten optimiert werden kann.

Mit den Arbeiten wurde zu Beginn des zweiten Quar-

tals 2017 begonnen.

Fazit

Eine Ära geht zu Ende: Nach mehr als 10 Jahren im

Einsatz wird die letzte noch aus den Anfängen des

X-WiN stammende Plattform ersetzt. Bis Ende des

Jahres sind damit alle Plattformen des X-WiN erneu-

ert und entsprechen dem aktuellen Stand der Technik.

Die neue Aggregations-Plattform eröffnet dem DFN-

Verein neue Anwendungsszenarien speziell bei der

Kooperation zwischen den Teilnehmereinrichtungen.

Zudem bietet sie erhebliche Kapazitätsreserven, die

ihren langjährigen Einsatz realistisch erscheinen

lassen.

Die neue Architektur des IP-Backbone bringt den glei-

chen Leistungsumfang für alle DFNInternet-Diens-

te und erhöht gleichzeitig die Robustheit des X-WiN

gegen DoS-Vorfälle.

Mit dem geplanten Abschluss der Migrationsarbeiten

bis Ende 2017 steht die neue Aggregations-Plattform

rechtzeitig für die ab Mitte 2018 geplante Leistungs-

steigerung von DFNInternet bereit. M



Text: Christian Meyer (DFN-Verein)

Mit dem Umstieg von ISDN auf rein IP-basierte Telekommunikation

kommt der DFN-Verein seiner Vision der Konvergenz der Netze

einen großen Schritt näher. Dabei bilden die für Wissenschaft und

Forschung konzipierten VoIP-Anschlussarten die Grundlage für

den Umstieg auf die nächste Kommunikationstechnologie.

Foto © ozgurdonmaz / iStockphoto


Hintergrund

Der Dienst DFNFernsprechen bietet den

Teilnehmern seit seinem Beginn im Jahre

1998 die Möglichkeit der Telekommunika-

tion über unterschiedliche Anschlussar-

ten. Dabei bedient sich das Dienstange-

bot stets der Möglichkeiten der aktuellen

Marktlage, um ein für Forschung und Wis-

senschaft zugeschnittenes Portfolio be-

reitzustellen. Innerhalb dieser fast 20 Jah-

re war eine der technischen Grundlagen

des Dienstes immer die leitungsvermittel-

te Festnetztechnik sowohl in analoger als

auch in digitaler Ausführung. Als analoge

Anschlüsse kommen dabei sogenannte N1-

Anschlüsse mit einem Nutzkanal zum Ein-

satz, bei den digitalen ISDN-Anschlüssen

finden N2-Basisanschlüsse (in den Betriebs-

arten Mehrgeräte- und Anlagenanschlüs-

se) mit zwei Nutzkanälen und N30-Primär-

multiplexanschlüsse (kurz PMX-Anschluss,

auch S2M-Anschluss) mit 30 Nutzkanälen

Verwendung.

Die Entwicklung der DFN-Dienste wird von

der Vision einer Konvergenz bisher unter-

schiedlicher Kommunikationssysteme und

-netze bestimmt (Datennetze, Fernsprech-

netze, Mobilfunknetze usw.). Ein wichti-

ger Integrationsfaktor ist dabei das Inter-

netprotokoll, weil es global verbreitet ist

und – zumindest prinzipiell – in allen Net-

zen und für nahezu alle Dienste und An-

wendungen genutzt werden kann. Als ein

Schritt in Richtung Konvergenz bietet der

DFN-Verein deswegen seit 2005 neben der

klassischen Telefonie auch die Möglichkeit

der IP-basierten Telefonie (Voice-over-IP,

kurz VoIP) sowie entsprechende Übergän-

ge zwischen den Technologien an.

Neugeräte werden nicht

mehr vertrieben, die Kosten

für Wartung und Support

bestehender Installationen

steigen.

Auch im globalen Umfeld der kommerziel-

len Netzbetreiber nimmt das Internetpro-

tokoll für die Telekommunikation einen

stark wachsenden Stellenwert ein, um da-

mit die bisherige ISDN-Technologie abzu-

lösen. Alle Netzbetreiber haben diesbezüg-

lich Pläne angekündigt oder sind in der Um-

setzung entsprechender Maßnahmen. Im

Privatkundenbereich hat die Deutsche Te-

lekom 2012 begonnen, IP-basierte Produkte

einzuführen und bestehende Anschlüsse

damit zu ersetzen. 2015 folgte dann auch

im Geschäftskundenbereich die Ankündi-

gung, bis Ende 2018 alle bestehenden ISDN-

Anschlüsse in IP-basierte Anschlüsse um-

zuwandeln und ISDN abzuschalten. Dabei

betrifft die Abkehr von ISDN nicht nur die

Betreiber der Netze, sondern auch die Her-

steller von Telefonanlagen der klassischen

Vermittlungstechnik: Neugeräte werden

nicht mehr vertrieben, die Kosten für War-

tung und Support bestehender Installati-

onen steigen. Außerdem ist in der Ersatz-

teilversorgung mit Ausfällen zu rechnen.

Für den Dienst DFNFernsprechen hat der

DFN-Verein die Grundlagen geschaffen, um

den teilnehmenden Einrichtungen einen

reibungslosen Übergang der Kommunika-

tionsinfrastruktur von klassischer zu IP-ba-

sierter Technologie zu ermöglichen. Durch

die letzte Ausschreibung des Dienstes

DFNFernsprechen wurden VoIP-basierte

Anschlussarten etabliert, die als Nachfol-

ger der bisherigen ISDN-Anschlüsse zum

Einsatz kommen. Dabei handelt es sich um

Anschlüsse, die auf das Wissenschaftsnetz

X-WiN aufsetzen. Das bedeutet, dass die

für die Telekommunikation erforderliche

Datenübertragung dieser Anschlüsse über

das Wissenschaftsnetz erfolgt. Es werden

folglich keine zusätzlichen Anschlusslei-

tungen bei den Teilnehmern benötigt.

VoIP-Centrex-Anschluss

Die bisher eingesetzten Basis- oder Primär-

multiplexanschlüsse können auf einen so-

genannten VoIP-Centrex-Anschluss umge-

stellt werden. Diese Anschlussart bietet die

Möglichkeit, alle Funktionen einer Telefon-

anlage zu nutzen, ohne selbst eine Anlage

dafür betreiben zu müssen. Der Betrieb der

mandantenfähigen Anlage erfolgt zentral

im Wissenschaftsnetz. Teilnehmer benöti-

gen hierfür lediglich entsprechende VoIP-

Endgeräte im lokalen Netz. Diese werden

bei Inbetriebnahme automatisch provisi-

oniert und sind dann sofort einsatzbereit.

Jede aktive Nebenstelle wird in einem mo-

natlichen Überlassungsentgelt abgerech-

net. Dieses Überlassungsentgelt beinhal-

tet sowohl die Bereitstellung des Dienstes

und seiner Leistungsmerkmale als auch

Wartung und Support des Anschlusses so-

wie alle zukünftigen Softwareversionen

für Anlage und Endgeräte. Weitere Über-

lassungs- oder Bereitstellungsentgelte fal-

len nicht an. Kompatible Endgeräte kön-

nen über eine Rahmenvereinbarung be-

schafft werden.

Die zentrale Telefonanlage arbeitet höchst-

verfügbar, sie ist an zwei verschiedenen

Standorten mit dem Wissenschaftsnetz ge-

koppelt. Die Verbindungen der Endgeräte

mit der Telefonanlage erfolgen standard-

mäßig verschlüsselt, wobei die Signalisie-

rung einer Verbindung zertifikatbasiert per

Transport Layer Security (TLS) und der ei-

gentliche Medienstrom mit dem Secure

Real-Time Transport Protocol (SRTP) ver-

schlüsselt werden.

Auch in der Qualität der Audioübertra-

gung wurde eine Verbesserung im Ver-

gleich zur klassischen Telefonie erreicht.

So kommt neben dem Sprach-Codec G.711,

der bei ISDN angewendet wurde, nun auch

der breitbandige Sprach-Codec G.722 zum

Einsatz.

Die VoIP-Centrex-Telefonanlage ist über ein

sogenanntes SIP-Trunking-Verfahren ver-

schlüsselt mit einer zentralen VoIP-Platt-

form verbunden. Diese Plattform dient der

Vermittlung der IP-basierten Kommuni-

kation innerhalb der teilnehmenden Ein-

richtungen als auch in alle öffentlichen

Telefonnetze. Entsprechend den Sicher-

heitsanforderungen der über den DFN-

Verein organisierten Einrichtungen wird

auch für die VoIP-Plattform ein optimier-

tes Redundanzkonzept eingesetzt: sie ist


an zwei Standorten mit jeweils zwei tras-

sendisjunkten redundanten Zugangslei-

tungen in das Wissenschaftsnetz einge-

bunden und wird an jedem Standort re-

dundant betrieben.

VoIP-Anschluss

Für Einrichtungen, die auf den Betrieb einer

eigenen Telekommunikationsinfrastruktur

(kurz TK-Anlage) nicht verzichten wollen,

besteht die Möglichkeit, selbst zwischen

dieser TK-Anlage und der VoIP-Plattform

das SIP-Trunking-Verfahren einzusetzen,

um die Konnektivität in das öffentliche Te-

lefonnetz herzustellen. Diese als VoIP-An-

schluss bezeichnete Verbindungsart setzt

voraus, dass die eingesetzte TK-Anlage IP-

fähig ist, über die Kompatibilität zum SIP-

Trunking verfügt und die entsprechende

Schnittstellenbeschreibung erfüllt. Ist das

nicht der Fall, steht die Einrichtung vor

der Aufgabe, die eigene Infrastruktur da-

für zu befähigen. Je nach örtlichen Gege-

benheiten bzw. Anforderungen reicht das

Spek trum dabei von der Beschaffung zu-

sätzlicher Software bzw. Softwarelizen-

zen über die Beschaffung von Gateways

oder Routern bis zur Neubeschaffung der

gesamten Systemumgebung. Damit ein-

her geht eine vollständige Bedarfsanalyse

der In stallation, die sowohl die zentral be-

nötigten Komponenten als auch die End-

geräte in seiner Gesamtheit umfasst. Vie-

le der Leistungsmerkmale, die bisher im

ISDN-Netz bereitgestellt wurden, werden

bei VoIP-Anschlüssen von der eingesetz-

ten Telefonanlage umgesetzt. Auch hier

muss vor Neubeschaffung einer IP-Anla-

ge eine entsprechende Prüfung erfolgen.

Ist für den VoIP-Anschluss eine Verschlüs-

selung geplant, muss die Einrichtung zu-

sätzliche Mittel zur Beschaffung entspre-

chenden Equipments (sogenannter Border-

elemente bzw. Session Border Controller)

einplanen. Auch hierbei werden die Proto-

kolle TLS und SRTP eingesetzt. Für die Ver-

schlüsselung der Signalisierung über TLS

werden Zertifikate der DFN-PKI eingesetzt.

Auch vormals als Analoganschluss reali-

sierte Installationen können auf die bei-

den oben beschriebenen IP-basierten An-

schlussarten umgestellt werden, sofern

darüber eine Kommunikation ohne Son-

deranwendungen erfolgt. Viele analoge

Geräte (z. B. Fax, Türklingelanlagen, etc.)

können mit sogenannten Digital-Analog-

Wandlern (kurz D/A-Wandler) auf IP-Um-

gebungen umgesetzt werden. Für analoge

Sonderanwendungen speziell im Notrufbe-

reich ist immer eine Spannungsversorgung

notwendig, weshalb die klassischen ana-

logen Anschlüsse über eine Fernspeisung

spannungsversorgt sind. Um die Konnekti-

vität auch in diesen Sonderinstallationen

zu gewährleisten, bieten die Telekommuni-

kationsprovider entsprechende Ersatzpro-

dukte an. Diese Anschlüsse werden über

eine eigene Anschlussleitung versorgt.

Besonderes Augenmerk –

Strategien zur Migration

Die Grundlage zur Nutzung der IP-basier-

ten Telekommunikationsanschlüsse von

DFNFernsprechen ist der Zugang zum Wis-

senschaftsnetz X-WiN. Vor dem Beginn ei-

ner Anschlussmigration müssen Teilneh-

mer deswegen prüfen, inwieweit dieser Zu-

gang aktiv ist und ob die Kapazitäten da-

für zur Verfügung stehen. Aus Gründen der

Ausfallsicherheit ist ein redundanter Zu-

gang zum Wissenschaftsnetz empfehlens-

wert. Gerade für verteilte Einrichtungen

ist es wichtig zu prüfen, ob alle Standorte

über Netzkonnektivität verfügen und das

interne LAN für VoIP vorbereitet ist. Beide

VoIP-Anschlussarten sind in der Lage, mit

einem Anschluss die gesamte Einrichtung

zu versorgen. Es ist mit einem Anschluss

sogar möglich, den Betrieb einer eigenen

TK-Anlage in redundanter Ausführung über

Abbildung 1: VoIP-Centrex-Anschluss (oben) und

VoIP-Anschluss (unten). Bei beiden Anschlussar-

ten erfolgt die Datenübertragung über das Wis-

senschaftsnetz X-WiN. Im Gegensatz zum VoIP-

Anschluss benötigt ein VoIP-Centrex-Anschluss

keine lokale Telefonanlage. Diese wird zentral im

Wissenschaftsnetz bereitgestellt.

SIP Trunk

SIP Trunk

Breakout

BreakinVoIP-TK-Anlage

VoIP-Centrex

X-WiN

VoIP-Plattform

ÖffentlicheTelefonnetze

teilnehmendeEinrichtung

teilnehmendeEinrichtung

IP

IP

IP

IP

IP

IP


verschiedene Standorte aufzuspannen, um

die Verfügbarkeit zu erhöhen. Für Standor-

te ohne Möglichkeit der X-WiN-Konnekti-

vität müssen Einrichtungen zukünftig auf

Standardprodukte der Telekommunikati-

onsprovider zurückgreifen.

Für die technische Umstel-

lung eines bestehenden

ISDN-Anschlusses zu einem

VoIP-basierten Anschluss

wurden Migrationsprozesse

etabliert.

Für Teilnehmer von DFNFernsprechen, die

bisher noch keine der VoIP-basierten An-

schlussarten nutzen, ist die formale Rege-

lung über eine neue Dienstvereinbarung

notwendig. Für die technische Umstellung

eines bestehenden ISDN-Anschlusses zu

einem VoIP-basierten Anschluss wurden

Migrationsprozesse etabliert. Diese ge-

währleisten einen sanften Produktwech-

sel und ermöglichen eine Portierung der

bestehenden Rufnummer. Für einen An-

schlusswechsel können der zu migrieren-

de klassische Anschluss und der gewählte

VoIP-basierte Anschluss parallel betrieben

werden, ausgehende Verbindungen sind

dabei über beide Anschlüsse möglich. Da-

mit ist gewährleistet, dass die Einrichtung

alle notwendigen Maßnahmen durchfüh-

ren kann, bevor die Migration abgeschlos-

sen ist. Sie ist dann abgeschlossen, wenn

die Rufnummer des ISDN-Anschlusses zum

neuen Anschluss portiert und der ISDN-An-

schluss gekündigt wurde. Für Einrichtun-

gen, die eine neue Rufnummer benötigen,

entfällt der Schritt der Rufnummernportie-

rung. Die Migration ist in diesem Fall mit

Kündigung des ISDN-Anschlusses beendet.

IT-Sicherheit in der

Telekommunikation

Bei der Umstellung auf IP-basierte Telekom-

munikation ist zu beachten, dass die beim

Teilnehmer eingesetzte Infrastruktur im lo-

kalen Netzwerk der Einrichtung betrieben

wird und demzufolge auch den geltenden

IT-Sicherheitskriterien unterliegt. So stel-

len vor allem lokal betriebene Telefonan-

lagen, welche nicht mit adäquaten Maß-

nahmen abgesichert werden, ein großes Si-

cherheitsrisiko dar. Mit der Bereitstellung

eines VoIP-Anschlusses für eine lokale Te-

lefonanlage ist diese zur Herstellung welt-

weiter Kommunikationsverbindungen be-

fähigt. Sind nun die grundlegenden Schrit-

te zur Absicherung nicht erfolgt, ist die An-

lage potenziell gefährdet für IT-Angriffe,

mit dem Ziel des Gebührenmissbrauchs.

Dabei werden hochpreisige Verbindungen

zu meist internationalen Mehrwertdiens-

ten hergestellt, die zu Lasten des betrof-

fenen Teilnehmers gehen.

Für den sicheren Betrieb einer lokalen

Telefonanlage muss eine fachkundige Be-

treuung sichergestellt werden. Planung,

In stallation, Administration und Instand-

haltung von TK-Systemen erfordern für die

jeweilige Aufgabe spezifische Kompeten-

zen. Potenziell sicherheitsrelevante Arbei-

ten sollten nur durch Fachkräfte bzw. ge-

schultes Personal erbracht werden. Bei Be-

darf sollten teilnehmende Einrichtungen

deswegen auf entsprechende Dienstleis-

ter zugehen.

Bei VoIP-Centrex-Anschlüssen ist die Ab-

sicherung der Anlage herstellerseitig um-

gesetzt, da der Betrieb und die Betreuung

der Systemumgebung zentral erfolgen. Teil-

nehmer müssen nur noch die Telefone im

eigenen Netz platzieren.

Fazit

Mit dem Umstieg auf rein IP-basierte Te-

lekommunikation kommt der DFN-Verein

seiner Vision der Konvergenz der Netze ei-

nen großen Schritt näher. Die beiden für

Wissenschaft und Forschung konzipierten

Anschlussarten „VoIP-Centrex-Anschluss“

und „VoIP-Anschluss“ bilden die Grundlage

für den Umstieg von ISDN auf die nächste

Kommunikationstechnologie. Dabei sol-

len optimierte Migrationsprozesse den

Teilnehmern helfen, einen reibungslosen

Wechsel auf die gewünschte Anschlussart

durchzuführen.

Da die für die Kommunikationsübertra-

gung erforderliche Netzinfrastruktur glo-

bal verfügbar und nicht mehr von spezi-

ellen Leitungsnetzen abhängig ist, kann

für die IP-basierte Telekommunikation ei-

ne entfernungsunabhängige Abrechnung

vorgenommen werden. Gemäß der Aussa-

ge „Die Welt ist ein Dorf“ können beispiels-

weise auch internationale Verbindungen

als Ortsverbindung abgerechnet werden.

Damit ergibt sich für die Teilnehmer ein

reales Einsparpotenzial bei dem Umstieg

auf einen IP-basierten Anschluss. M

ABSICHERUNG IT-BASIERTER

TELEKOMMUNIKATIONS-

ANLAGEN

Grundlegende Schutzmaßnahmen

sind z. B.

ʃ der Einsatz von Firewall-

Absicherungen oder

Zugriffsbeschränkungen,

ʃ regelmäßige Pflege der TK-Soft-

ware und Installation aktueller

Betriebssoftware,

ʃ Änderung der Standardpass-

wörter des Systems, Passwort-

sicherung oder Deaktivierung

der Voice-Boxen,

ʃ Absicherung durchwahlfähiger

Nebenstellen.

Der DFN-Terminplaner ist ein einfaches

aber wirksames Werkzeug, Terminfindungs-

prozesse zu vereinfachen. Über eine Web-

schnittstelle können online beliebig viele

Termin-Alternativen für ein Meeting zur Ab-

stimmung gegeben werden. Das Ergebnis

wird in Form einer Tabelle ausgegeben, die

in übersichtlicher Weise den Mehrheits-

willen und die eigenen Präferenzen des

Abstimmenden wiedergibt.

Bei der Gestaltung der Bedienoberfläche

wurde besonderer Wert daraufgelegt, dass

der Dienst nicht nur technik-affine Men-

schen anspricht, sondern auch darüber

hinaus intuitiv zu bedienen ist. So kann

in der neuen Version auf einen Blick er-

fasst werden, welche Abstimmungen vom

Nutzer erstellt wurden und an welchen

Abstimmungen dieser teilgenommen hat.

Um eine Abstimmung zu erstellen, muss

sich der Nutzer anmelden. Dies ist nun auch

mit der Authentifizierungs- und Autorisie-

rungs-Infrastruktur des DFN-Vereins (DFN-

AAI) möglich.

Die Anmeldung erfolgt dann über den Iden-

tity Provider der Heimateinrichtung. Dies

hat auch den Vorteil, dass keine zusätzli-

chen Zugangsdaten erforderlich sind, son-

dern die Zugangsdaten verwendet werden

können, mit denen die Nutzer bei ihrer Hei-

mateinrichtung registriert sind. Außerdem

kann dadurch eine Kalendersoftware ein-

gebunden werden, die automatisch prüft,

welche Zeitfenster dem Ersteller zur Verfü-

gung stehen. Dafür wird optional, über die

Heimateinrichtung, auf die eingebundene

URL zugegriffen und der Kalender des Nut-

zerprofils überprüft. So sieht der Nutzer

auf einen Blick, welche Termin alternativen

zur Verfügung stehen.

Einmal angemeldet gibt der Ersteller ein-

fach mehrere dieser Terminalternativen,

über die abgestimmt werden soll, in eine

Eingabemaske ein. Des Weiteren kann der

Nutzer eine Beschreibung sowie ein Ab-

laufdatum für seine Abstimmung eingeben

sowie die Art der Abstimmung auswählen.

Neben den klassischen Terminabstimmun-

gen können so auch andere Vorschläge ab-

gestimmt werden (z. B. Kurs- oder Raum-

Einfach sicher Abstimmen:DFN-Terminplaner jetzt auch mit DFN-AAI

Text: Torsten Kersting (DFN-Verein)

Den optimalen Termin für das nächste Team-Meeting, die nächste Videokonferenz oder Vor-

standssitzung zu finden raubt oft eine Menge kostbarer Zeit. Der DFN-Terminplaner unter-

stützt Nutzer seit 2009 bei diesem Vorgang und bietet eine einfache Lösung, um den Prozess

der Terminabstimmung rapide zu verkürzen. Seit Dezember 2016 ist der Dienst in einer neuen

Version verfügbar und bringt einige sehnsüchtig erwartete Funktionen mit.


Abbildung 1: Anmeldung per DFN-AAI

belegung). Nun kann der Nutzer zwischen zwei ver-

schiedenen Antwortalternativen wählen. Zum einen

kann er Termine oder Vorschläge zur Auswahl stel-

len, aus denen sich der Teilnehmer den oder die pas-

senden auswählt und diese bestätigt, zum anderen

kann er dem Teilnehmer die Möglichkeit geben, zu

jedem Termin/Vorschlag eine individuelle Wertung

abzugeben (z. B. ja, nein, vielleicht). Im letzten Schritt

kann der Nutzer die erstellte Abstimmung dann ver-

öffentlichen und Teilnehmer zu der Abstimmung ein-

laden. Auch hier gibt es Verbesserungen in der neuen

Version. Es ist nun möglich, Gruppen auf Grundlage

vorangegangener Abstimmungen zu erstellen. Außer-

dem kann die Abstimmung in die eigene Webseite ein-

gebunden werden.

Indem der DFN-Terminplaner auf eine zwangsläufi-

ge Registrierung der Teilnehmer verzichtet, eignet

sich der DFN-Terminplaner auch für Abstimmungen

zwischen Teilnehmern, welche sich nicht registrieren

möchten. Einzig der Ersteller der Abstimmung muss

sich registrieren, die eingeladenen Teilnehmer kön-

nen auch anonym an der Abstimmung teilnehmen.

Die Abstimmungen sind durch die technischen Pa-

rameter des DFN-Terminplaners zu einem gewissen

Grade geschützt, da die URL eine zufällige Zeichen-

kette enthält und die Webseite per https zu erreichen

ist, sodass die Verbindung dorthin durch ein Zertifi-

kat verschlüsselt wird.

Generell wird Datenschutz beim DFN-Terminplaner

großgeschrieben. Bereits beim Erstellen einer Abstim-

mung ist die Angabe eines Ablaufdatums zwingend

erforderlich, damit keine Daten länger als nötig auf

dem Server liegen. Vier Wochen nach Ablauf der Ab-

stimmung werden alle Eingaben die Abstimmung be-

treffend gelöscht. Die Eingaben der Nutzer werden

in keiner Weise an Dritte weitergegeben oder vom

System für andere Vorgänge als für die Erstellung

der Ergebnistabelle genutzt. Dies ist wohl einer der

Hauptgründe für die monatlich rund 250.000 Nutzer

des Dienstes, denn es gibt bisher keine kommerziel-

le Lösung, die ein ähnliches Datenschutzniveau auf-

weisen kann. M


Abbildung 2: Startseite und Übersicht

Abbildung 3: Abstimmung erstellen und Vorschau

Hier können Sie den neuen DFN Terminplaner 3.0 ausprobieren:

https://abstimmung.dfn.de

https://abstimmung.dfn.de


Eduroam off Campus und BayernWLAN – eine Win-win-Kooperation

Text: Helmut Reiser (Leibniz-Rechenzentrum), Rolf Borgeest (Bayerisches Landesamt für

Digitalisierung, Breitband und Vermessung; BayernWLAN Zentrum)

Innerhalb der wissenschaftlichen Community ist eduroam ein Erfolgsmodell. Mit der Initi-

ative Eduroam off Campus (EoC) wird eduroam auch außerhalb des „Biotops Hochschule“

für reisende Wissenschaftler und Studierende zur Verfügung gestellt. In Kooperation mit

BayernWLAN ist dies nun in ganz Bayern möglich.

Abbildung 1: weltweite Verbreitung von eduroam


EoC Entwicklung

Als Authentisierungsinfrastruktur für ei-

nen weltweiten Netzzugang ist eduroam

eine absolute Erfolgsgeschichte. Die Nut-

zer der teilnehmenden Einrichtungen kön-

nen sich mit den Zugangsdaten ihrer Hei-

mateinrichtung sicher im Netz einer Gast-

einrichtung authentisieren und erhalten

dort dann Zugang zum Netz bzw. Internet.

Innerhalb der Universitäten, Hochschulen

und forschungsnahen Einrichtungen hat

sich eduroam zum De-Fakto-Standard für

den Netzzugang reisender Wissenschaft-

ler und Studierender entwickelt. Die Abbil-

dung 1 stellt die weltweite Verbreitung des

Dienstes dar. Jede Nadel auf dieser Karte

steht dabei für ein Land, in dem eduroam

unterstützt wird.

Im Jahr 2011 gründete der Verein ZKI (Zen-

tren für Kommunikation und Informati-

onsverarbeitung e. V.) die Kommission Edu-

roam off Campus (EoC) mit dem Ziel, die

räumlichen Beschränkungen von eduroam

auf Campusbereiche aufzuheben und edu-

roam auch außerhalb des „Biotops Hoch-

schule“ zu verbreiten.

Letztendlich beschränkte

sich das Interesse

großer Provider auf

die Realisierung

wirtschaftlicher Vorteile.

Zuerst wurde mit vielen Providern großer

WLAN- und Netzinfrastrukturen gespro-

chen und versucht, diese für die Idee von

EoC zu begeistern. Die Gespräche waren

immer sehr freundlich, doch letztendlich

beschränkte sich das Interesse der großen

Provider auf eine schnelle Realisierung

wirtschaftlicher Vorteile. Da aber weder

EoC, ZKI noch der DFN-Verein – der EoC

von Anfang an voll unterstützte – die Mit-

tel dafür hatten und haben, verliefen al-

le diese Gespräche in den Jahren 2011 und

2012 im Sande.

eduroam verlässt den Campus

– Beispiel Ingolstadt

Nachdem die großen Provider nicht bereit

waren, auf einer kooperativen Basis EoC

zu unterstützen, konnten kleinere, regio-

nale Provider für die Idee gewonnen wer-

den. So konnte die Stadt Ingolstadt, die

ein City-Netz plante, Anfang 2013 für die

Idee begeistert werden.

Für einen Provider, dessen Ziel es ist, ein of-

fenes WLAN anzubieten, ist es nicht immer

nachvollziehbar, warum er auf seinen Ac-

cess Points eine weitere SSID ausstrahlen

sollte, die noch dazu zugangsbeschränkt

ist. Die Provider verstanden jedoch, dass

reisenden Wissenschaftlern eine offene

City-WLAN-SSID weder bekannt ist, noch

dass sie dieser per se vertrauen können.

Bei eduroam ist das Vertrauensverhältnis

durch die sichere Authentisierung gege-

ben. Als Universitäts- und Hochschulstadt

kam für Ingolstadt ein weiteres Argument

hinzu: Die Stadt wollte mit Eduroam off

Campus „ihren Uni- und Hochschul-Cam-

pus in die Innenstadt hinein verlängern.“

Die Hürden für eine schnelle Umsetzung

von EoC in Ingolstadt lagen jedoch weni-

ger in der technischen Umsetzung, als viel-

mehr in den organisatorischen und juristi-

schen Fragen, welche das Projekt aufwarf.

Letztendlich gründete der Marketingver-

band für die Innenstadt eine haftungsbe-

schränkte Unternehmergesellschaft, die

das Risiko der Betreiberhaftung minimie-

ren sollte, und selbst wiederum einen tech-

nischen Betreiber für das City-WLAN be-

auftragte. Die Stadt förderte das Projekt

finanziell. Nachdem diese Hürden genom-

men waren, konnten die ersten beiden EoC

Access Points im Oktober 2013 in Betrieb

gehen.

Damit war sowohl eine technische als auch

organisatorische Blaupause geschaffen,

mit der auch andere City-Netz-Betreiber

schnell technisch beraten, sowie organi-

satorisch unterstützt werden konnten.

Im April 2014 folgte mit den Stadtwerken

München der erste große City-Netz Be-

treiber, der eduroam auf allen seinen Ac-

cess Points zusätzlich ausstrahlte. Im No-

vember 2014 wurde begonnen, alle Busse

und Straßenbahnen des öffentlichen Per-

sonennahverkehrs in Augsburg mit EoC

Access Points auszustatten. Bei den Bus-

sen konnte sofort begonnen werden, die

Straßenbahnen folgten nach einer bahn-

rechtlichen Genehmigung im Jahr 2015.

Im selben Jahr aktivierte der City-Netz Be-

treiber KomRo in Rosenheim eduroam auf

all seinen Access Points, weitere Installa-

tionen durch andere City-Netz Provider

folgten.

EoC Technik

In der Diskussion mit Providern stehen

häufig erst einmal juristische und orga-

nisatorische Fragen im Vordergrund. Im

zweiten Schritt kommen dann auch Fra-

gen nach der technischen Umsetzung und

nach den Voraussetzungen, die der Provi-

der mitbringen muss.

Die wichtigsten technischen Grundvoraus-

setzungen sind zum einen Multi-SSID fähi-

ge Access Points. Ansonsten kann die zu-

sätzliche SSID eduroam nicht ausgestrahlt

werden. Zum anderen muss das Protokoll

802.1X implementiert sein, das für die edu-

roam-Authentisierung verwendet wird.

Über dieses Protokoll fordert der WLAN-

Client beim Access Point den Zugang zum

Netz. Um die Anmeldung an die Heimat-

einrichtung weiterzuleiten, wird als Ou-

i Die Bezeichnung eduroam ist ein eingetragenes Warenzeichen

(Trademark) der GÉANT Association, deren Rechte der DFN-Verein in

Deutschland vertritt.


ter-ID kennung@heimateinrichtung oder

eine sogenannte anonyme Outer-ID ano-

nymous@heimateinrichtung verwendet.

Der Access Point führt die Authentisie-

rung nicht selbst durch, sondern vermit-

telt die Verbindung zu einem Radius-Ser-

ver der Heimateinrichtung. Dieser prüft die

Zugangsdaten des Nutzers und authenti-

siert diesen. Der Access Point erhält dann

vom authentisierenden Radius-Server ein

„Ok“ oder eben „Nicht-Ok“ sowie ggf. wei-

tere Informationen über den Status des

Nutzers (z. B. Mitarbeiter, Student, etc.).

Aber wie weiß der Access Point welcher

Radius-Server für die Heimateinrichtung

zuständig ist? Dazu gibt es einen hierarchi-

schen Verbund von Radius-Servern, die die-

se Frage beantworten können. In Deutsch-

land betreibt der DFN-Verein den Top-

Level Radius Server für die Domain .de, d. h.,

wenn die Heimateinrichtung in Deutsch-

land liegt, kennt der DFN-Radius-Server

die Adresse des verantwortlichen Radius-

Servers. Liegt die Einrichtung nicht in

Deutschland, kennt er den Top-Level Radius

Server des Gastlandes und der Access Point

kann diesen wiederum nach dem zustän-

digen Radius-Server fragen (siehe Abbil-

dung 2).

Mit dieser Information gestattet der Access

Point dem Client eine verschlüsselte Ver-

bindung zum Radius-Server der Heimatein-

richtung aufzubauen. Die eigentlichen Zu-

gangsdaten des Nutzers werden erst über

diesen verschlüsselten Kanal übermittelt.

Selbst ein böswilliger Betreiber ist nicht

in der Lage, das Passwort mitzulesen, da

dieses durch die Ende-zu-Ende Verschlüs-

selung geschützt wird (siehe Abbildung 3).

Verwendet der Nutzer eine anonyme Outer-

ID, werden sowohl Passwort als auch Be-

nutzerdaten als Inner-ID nur über den,

durch die Heimateinrichtung verschlüs-

selten, Kanal übertragen. Der Provider

kennt nur die Einrichtung aus der der Nut-

zer kommt, hat aber keine Informationen

über dessen Benutzerkennung.

Toplevel Radius Server

[email protected]

LRZ

Organisation A

Org. B.


[email protected]

Verschlüsselter Kanal;Ende zu Ende

reiser ist o.k.

LRZ

Organisation A

Org. B.


[email protected]

LRZ

Organisation A

Org. B.


[email protected]

Verschlüsselter Kanal;Ende zu Ende

reiser ist o.k.

LRZ

Organisation A

Org. B.

Internet

Internet

Abbildung 2: Verbund von Radius-Servern

Abbildung 3: Verschlüsselte Übertragung von Authentisierungsinformationen





Damit ein EoC-Provider am Radius-Verbund

teilnehmen kann, muss er einen Radsec-

Proxy betreiben, für den eine Musterkon-

figuration vorliegt. Dieser Proxyserver si-

chert die hierarchische Kommunikation der

Radiusserver durch Zertifikate ab. Um die-

sen Proxy in den Radius-Server-Verbund

zu integrieren, bedarf es eines DFN-Zerti-

fikates. Dies stellt das DFN-CERT für EoC-

Provider kostenlos zur Verfügung.

Die Voraussetzungen

für die Teilnahme an

EoC sind relativ einfach

zu erfüllen.

Der EoC-Provider muss die Regeln und

Richtlinien für Integration in den Radius-

Verbund und für den Betrieb der eduroam-

Technik einhalten. Diese Regeln werden

in einer eduroam-Service-Provider-Verein-

barung festgehalten, die der EoC-Provider

kostenfrei mit dem DFN-Verein abschließt.

Die Voraussetzungen für die Teilnahme

an EoC sind relativ einfach zu erfüllen, da

die eduroam-Richtlinien dem Service Pro-

vider keine fundamentalen Einschränkun-

gen auferlegen und die technische Reali-

sierung auch für kleine Provider in weni-

gen Tagen umsetzbar ist.

BayernWLAN

Der bayerische Finanz- und Heimatminis-

ter Dr. Markus Söder hatte im November

2014 die Versorgung von ganz Bayern mit

freiem WLAN angekündigt. Staatliche Be-

hörden, Kommunen und touristische Ziele

sollen mit WLAN ausgestattet werden. Die

Neuausschreibung der staatlichen Kom-

munikationsinfrastruktur in den Jahren

2015 und 2016 (BayKom) wurde daher um

ein Los „Freies WLAN“ bzw. „BayernWLAN“

erweitert. Bis zum Jahr 2020 sollen 20.000

BayernWLAN Hotspots (Access Points) re-

alisiert werden.

Das BayernWLAN ist frei, unbegrenzt und

ohne Anmeldung nutzbar. Der Jugend-

schutz wird durch Filter sichergestellt.

BayernWLAN ist überall unter der SSID

@BayernWLAN erreichbar.

eduroam verlässt den Campus – bayernweit

Das Leibniz-Rechenzentrum (LRZ) der Bay-

erischen Akademie der Wissenschaften be-

riet den Freistaat bei der Ausschreibung

von BayernWLAN. Schon früh entstand die

Idee, die bestehenden WLAN-Netze an ca.

40 Hochschulen in Bayern mit mehreren

tausend Access Points auch für die Aus-

strahlung von BayernWLAN zu nutzen.

Im Gegenzug schlugen die Hochschulen

vor, eduroam auf den neu entstehenden

BayernWLAN Hotspots mit auszustrahlen.

Schließlich stand der folgende entscheiden-

de Satz in den Ausschreibungsunterlagen:

„Die SSID eduroam wird auf allen Hotspots

ausgestrahlt.“ Damit verpflichtete sich je-

der an der Ausschreibung teilnehmende

Provider, auf den BayernWLAN Hotspots

eduroam vollumfänglich zu unterstützen.

BayernWLAN auf dem Campus

Im Rahmen der Ausschreibung wurde um-

gekehrt auch ein Kooperationsmodell mit

Freischaltung BayernWLAN

an der Universität Bayreuth

am 02.12.2016

Foto: © Peter Kolb


den bayerischen Universitäten und Hoch-

schulen entwickelt, dass diesen die Mög-

lichkeit gibt, auf den universitären Infra-

strukturen und Access Points selbst auch

BayernWLAN auszustrahlen und damit ein

offenes WLAN zur Verfügung zu stellen.

Diese Idee scheint zunächst dem Prinzip

der geschlossenen Benutzergruppe inner-

halb des DFN-Vereins zu widersprechen.

Das Kooperationsmodell kann jedoch um-

gesetzt werden, indem der BayernWLAN

Verkehr vom wissenschaftlichen Verkehr

getrennt wird und statt über den X-WiN

Anschluss einer Einrichtung über einen

anderen Internetanschluss in das Inter-

net geleitet wird.

Der BayernWLAN Provider liefert einen Ser-

vice Aggregation Router (SAR), an dem der

BayernWLAN-Verkehr der Access Points der

Hochschule übergeben wird. Für kleinere

Einrichtungen kann dies durch die direkte

Übergabe eines VLANs erfolgen. Für größe-

re Einrichtungen wurde ein Konzept erar-

beitet, bei dem die WLAN-Controller den

BayernWLAN-Verkehr per GRE-Tunnel an

den SAR übergeben und von dort ins Re-

chenzentrum des Providers tunneln.

Interessant an diesem Konzept ist, dass die

gesamte Abwicklung im BayernWLAN über

den Provider erfolgt, d. h. insbesondere,

dass ein Nutzer, der sein Gerät innerhalb

der Hochschule mit dem Bayern WLAN ver-

bindet, nicht etwa eine Adresse aus dem

Hochschulnetz, sondern eine IP-Adres-

se des EoC-Providers erhält. Damit liegt

auch die Bearbeitung von vermeintlichen

Missbrauchsfällen oder etwaigen Sicher-

heitsvorfällen im BayernWLAN nicht bei

der Hochschule, sondern beim Provider.

Dieses Konstrukt wird in der Leistungsbe-

schreibung der Ausschreibung als „Hotspot

Ü“ für DatenÜbernahme bezeichnet. Das

bayerische Finanzministerium übernimmt

die Kosten für Hotspot Ü und zusätzliche

Internetanschlüsse der Hochschulen voll-

ständig und kann im Gegenzug die Hot-

spots der Hochschulen für die Ausstrah-

lung von BayernWLAN nutzen. Die Hoch-

schulen ihrerseits öffnen sich damit der

Öffentlichkeit und haben unter anderem

den Vorteil, ein ständiges Gäste-WLAN z. B.

bei Tagungen, anbieten zu können.

Der Hotspot Ü wurde noch während der

Ausschreibungsphase am Wissenschafts-

zentrum in Straubing pilotiert. Dabei zeig-

te sich, dass das Konzept einfach zu reali-

sieren ist, und ein offenes WLAN gerne ge-

nutzt wird. Der Pilot wird seit Dezember

2015 auf den Access Points des Leibniz-

Rechenzentrums in Straubing betrieben

und es kam bisher zu keinerlei Problemen.

Der betriebliche Aufwand, nach der Ins-

tallation, ist absolut zu vernachlässigen.

Umsetzung

Vodafone erhielt im März 2016 den Zuschlag

für die Realisierung des BayernWLAN. Im

Juni 2016 begann die Migrationsphase, in

der Vodafone die für eduroam notwen dige

Infrastruktur aufbaute und erste Piloten

realisierte. Seit November 2016 ist Bayern-

WLAN im Regelbetrieb und alle regulären

Hotspots des BayernWLAN strahlen neben

BayernWLAN auch eduroam aus.

Im Rahmen der Ausschreibung wurde ein

Abrufrecht für alle staatlichen Behörden

sowie für die Kommunen in Bayern ge-

schaffen. Damit können Behörden z. B.

touristisch interessante Orte, aber auch

Bereiche in Gemeinden mit BayernWLAN

und eduroam versorgen. So kann der rei-

sende Wissenschaftler oder Student bei-

spielsweise am Schloss Neuschwanstein,

aber auch in den Wartebereichen der Fi-

nanzämter oder auch in kleineren Gemein-

den eduroam nutzen.

Die Kommunen profitieren von den attrak-

tiven Konditionen des Rahmenvertrags.

Zusätzlich übernimmt der Freistaat Bay-

ern die Ersteinrichtung von BayernWLAN

ʃ https://www.eduroam.org/where/

ʃ BayernWLAN Zentrum Straubing,

http://www.ldbv.bayern.de/breitband/bayernwlan.html

ʃ Vodafone BayernWLAN Karte

https://www.wlan-bayern.de/#/map/

ʃ https://www.wlan-bayern.de/

WEITERFÜHRENDE LINKS

Abbildung 4: Logo des BayernWLAN

https://www.eduroam.org/where/

http://www.ldbv.bayern.de/breitband/bayernwlan.html

https://www.wlan-bayern.de/#/map/

https://www.wlan-bayern.de/


Hotspots an je zwei Standorten mit bis zu

5.000 € je Kommune. Das BayernWLAN Zen-

trum unterstützt die Abrufberechtigten

beim Aufbau von BayernWLAN.

Der Hotspot Ü kann auch von anderen Be-

zugsberechtigten genutzt werden, die be-

reits eigene WLAN-Infrastrukturen betrei-

ben. Damit kann z. B. eine Kommune ihr

City-Netz aus eigenen Access Points ins

BayernWLAN integrieren und BayernWLAN

auf eigener Infrastruktur anbieten. Die

Stadt Ingolstadt nimmt mit ihren Access

Points als Hotspot Ü am BayernWLAN teil.

Der Stadt ist es jedoch wichtig, auch wei-

terhin eduroam auszustrahlen. So schließt

sich der Kreis vom ersten EoC-Provider

Deutschlands zum kooperativen landes-

weiten EoC-Netz in Bayern.

Das BayernWLAN erfreut sich großer Be-

liebtheit, insbesondere auch bei kleineren

Gemeinden und darf schon heute, wenige

Monate nach Start des Regelbetriebs, als

voller Erfolg gewertet werden. So sind

Mitte April über 4.000 Hotspots an mehr

als 400 Standorten in Betrieb.

Bislang wird BayernWLAN an 12 Hochschul-

standorten, u. a. an den Universitäten Bam-

berg, Bayreuth und der Hochschule Augs-

burg, mit fast 2.500 Access Points ausge-

strahlt. Weitere 21 Standorte befinden sich

in Vorbereitung. Das bayerische Finanzmi-

nisterium und das Wissenschaftsministeri-

um haben ein Programm angekündigt, mit

dessen Hilfe die Hochschulen ihre WLAN-

Netze auf weitere für die Öffentlichkeit

inte ressante Bereiche ausdehnen können.

Zusammenfassung

Im Rahmen der Eduroam off Campus Initi-

ative wurde sowohl ein organisatorischer

als auch ein technischer Rahmen geschaf-

fen, der es für Provider verschiedenster

Größe ermöglicht auf ihren Access Points

auch eduroam anzubieten. Aus den kleinen

Anfängen in Ingolstadt hat sich mittler-

weile eine breite Unterstützung durch ver-

schiedenste Provider ergeben.

Mit der Ausschreibung eines landeswei-

ten BayernWLAN hat EoC die Campus-

Bereiche nun großflächig verlassen. Die

Ausstrahlung des BayernWLAN über die be-

reits bestehenden WLAN Netze der Hoch-

schulen ist für den Freistaat Bayern eine

kostengünstige Möglichkeit, zusätzliche

Access Points – auch in besonders attrak-

tiven innerstädtischen Lagen mit technik-

affinen jungen Nutzern – zu erschließen.

Die Hochschulen wiederum profitieren von

der Ausstrahlung des Wissenschaftsnet-

zes eduroam im BayernWLAN. Die gewon-

nenen Erfahrungen und dabei entwickel-

ten Konzepte könnten auch von anderen

Bundesländern sowie weiteren Providern

genutzt werden, um Forschung und Leh-

re auch außerhalb des Campus zu unter-

stützen. M

Eingang des Leibniz-Rechenzentrums bei Nacht. Foto: @ Christoph Rehbach.

32 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | INTERNATIONAL

Das Ziel der GÉANT-Projekte ist es, den Stand der Technik

in den Bereichen Networking und Service Innovation vor-

anzutreiben. Das GÉANT-Netzwerk verbindet heute Euro-

pas Forschungsnetze (NRENs) mit Geschwindigkeiten von

bis zu 500 Gbit/s und erreicht weltweit Forschungsnetze

in mehr als der Hälfte aller Länder. Es bietet das Maß an

Kapazität und Verlässlichkeit, dass die Nutzer von For-

schungs- und Bildungsnetzen weltweit benötigen.

Das aktuelle GÉANT-Projekt GN4-2 startete im Mai 2016 mit

einer Laufzeit von 32 Monaten zusammen mit 38 Partner-

ländern. Im April 2017 unterschrieb Albanien als neuer Part-

ner den Kooperationsvertrag mit GÉANT. Ein Vertrag mit Aser-

baidschan ist ebenfalls in Vorbereitung. GN4-2 verfügt über

ein Budget von 96 Mio. Euro, bestehend aus 59 Mio. Euro

Förderung durch die EU und 27 Mio. Euro Eigenanteil der

beteiligten Partner.

Eine gute Informationsquelle über Forschungs- und Bildungs-

netze in Europa und der Welt bietet das GÉANT Kompendi-

um. Die Umfragen für die Ausgabe 2017 wurden gerade ab-

geschlossen, die neue Ausgabe des Kompendiums wird für

Mitte des Jahres erwartet.

Das aktuelle GÉANT-Projekt GN4-2 beinhaltet die folgen-

den drei Schwerpunkte:

1. die Weiterentwicklung und den Betrieb

des pan-europäischen Forschungs- und

Bildungsnetzes,

2. die Entwicklung und Bereitstellung eines

Portfolios innovativer, föderierter

Dienstleistungen wie Konnektivität, Trust

and Identity, Cloud, Echtzeit-Zusammenarbeit

und Mediendienste,

3. die Durchführung kollaborativer

Forschungsprogramme.

Es werden jedoch nicht nur technische Schwerpunkte ge-

setzt. Einen wichtigen Aspekt bildet auch die Förderung der

Community aus Forschern und Forschungsnetzen. Highlights

bilden das GÉANT-Symposium, welches für Oktober 2017 in

Budapest geplant ist, sowie die jährlich stattfindende TNC

Konferenz (vormals TERENA Networking Conference). Die TNC

ist die größte und angesehenste europäische Konferenz der

Forschungs- und Bildungsnetze mit jährlich über 650 Teilneh-

mern. Organisator der TNC Konferenzen ist GÉANT.

Des Weiteren bietet das GÉANT-Community-Programm mit

seinen Task Forces (TFs) und Special Interest Groups (SIGs)

viele Möglichkeiten der Beteiligung an den aktuellen Projek-

ten von GÉANT. Zu Beginn des Jahres wurde das Portfolio des

GÉANT-Community-Programms um drei neue Arbeitsgruppen

erweitert. Die Task Force for Research Engagement Develop-

GÉANT weiterhin auf Erfolgskurs

Text: Leonie Schäfer (DFN-Verein)

Das europäische Wissenschaftsnetz GÉANT präsentiert sich mit seinen EU-geförderten Projekten seit nunmehr 15 Jahren als ein herausragendes, positives Beispiel für eine europaweite Zusammenarbeit.

33INTERNATIONAL | DFN Mitteilungen Ausgabe 91 |

ment (TF-RED) und spezielle Interessengruppen für Transnatio-

nal Education (SIG-TNE) sowie Cloudy Interoperable Software

Stacks (SIG-CISS) haben ihre Arbeit aufgenommen, planen Tref-

fen und laden Interessierte ein, sich zu beteiligen.

Aktuell nähert sich das GN4-2 Projekt seinem ersten großen

Meilenstein, dem Halbjahresreview mit der EU-Kommission im

Oktober diesen Jahres. Hier geht es unter anderem auch darum,

den bestmöglichen Status „Exzellent“ aus den vier vergangenen

Reviews zu halten. Parallel dazu finden bereits Vorbereitungen

für Phase 3 des Projekts, GN4-3, statt. Auch in Zukunft also wird

GÉANT, im Zusammenspiel mit den anderen großen Forschungs-

Infrastrukturen in Europa, ein wichtiger Baustein in der europä-

ischen Forschungslandschaft bleiben. M

October 2016

GÉANT and partner networks enabling user collaboration across the globe

At the Heart of Global Research and Education Networking

This document is produced as part of the GÉANT Speci�c Grant Agreement GN4-2 (No. 731122), that has received funding from the European Union’s 2020 research and innovation programme under the GÉANT2020 Framework Partnership Agreement (No.653998).

In addition to GN4-2, the following projects have received funding from the European Union: AfricaConnect2, CAREN3, TEIN4 and Asi@Connect (DG DEVCO); EaPConnect and EUMEDCONNECT3 (DG NEAR).

The content of this document is the sole responsibility of GÉANT and can under no circumstances be regarded as re�ecting the position of the European Union.

GÉANT CoverageRedCLARA NetworkEUMEDCONNECT3 NetworkTEIN NetworkAfricaConnect2: UbuntuNet Alliance,WACREN & ASRENCAREN NetworkEaPConnect NetworkOther R&E Networks

: ACE & TransPAC

Dark Shading: Connected to regional networkLight Shading: Eligible to connect to regional network

www.geant.org

10 Gbps backup>1 Gbps<10 Gbps≤1 Gbps

10 GbpsMultiples of 10 Gbps100 Gbps

Multiple 100 Gbps links

Funded by the European Union

ANA

Karte: GÉANT

GÉANT 2002 GÉANT 2010 GÉANT 2016

October 2016

GÉANT and partner networks enabling user collaboration across the globe

At the Heart of Global Research and Education Networking

This document is produced as part of the GÉANT Speci�c Grant Agreement GN4-2 (No. 731122), that has received funding from the European Union’s 2020 research and innovation programme under the GÉANT2020 Framework Partnership Agreement (No.653998).

In addition to GN4-2, the following projects have received funding from the European Union: AfricaConnect2, CAREN3, TEIN4 and Asi@Connect (DG DEVCO); EaPConnect and EUMEDCONNECT3 (DG NEAR).

The content of this document is the sole responsibility of GÉANT and can under no circumstances be regarded as re�ecting the position of the European Union.

GÉANT CoverageRedCLARA NetworkEUMEDCONNECT3 NetworkTEIN NetworkAfricaConnect2: UbuntuNet Alliance,WACREN & ASRENCAREN NetworkEaPConnect NetworkOther R&E Networks

: ACE & TransPAC

Dark Shading: Connected to regional networkLight Shading: Eligible to connect to regional network

www.geant.org

10 Gbps backup>1 Gbps<10 Gbps≤1 Gbps

10 GbpsMultiples of 10 Gbps100 Gbps

Multiple 100 Gbps links

Funded by the European Union

ANA

http://www.geant.org


Breaking records in the land of

the rising sun

Each of ITER's early, non-nuclear plasmas

will generate an estimated 1 terabyte of

experimental data – the equivalent of

a full commercial hard disk. When ITER

goes nuclear, some ten years after ente-

ring operation, this volume might be mul-

tiplied by fifty. The project’s Remote Ex-

perimentation Centre (REC) in Rokkasho,

Japan, a duplicate of ITER's control room

on-site, allows scientists in Japan to par-

ticipate remotely in ITER experiments by

storing the experimental data accumula-

ted over time and ensuring the massive

database is instantly accessible to resear-

chers. A huge amount of data that needs

to be transferred at speeds that current

networking technologies simply could not

deliver – until last autumn. The capacity to

transfer this data to Japan at a pace com-

Breakneck Network speed to deliver new energy paradigmsText: Helga Spitaler (GÉANT), Audrey Gerber (IUCC)

Ambitious goals require ambitious

technologies. The ITER (“Way" in

Latin) is one of today’s most ambi-

tious global energy projects and

has the potential to change the

methods and economic models

of energy production and con-

sumption. The ITER project, head-

quartered in southern France, is a

collaboration between 35 nations

to build the world's largest toka-

mak, a magnetic fusion device

designed to prove the feasibility of

fusion as a largescale and carbon-

free source of energy based on the

same principle that powers the sun

and the stars. This work is crucial to

advancing fusion science and will

serve as a foundation of the fusion

power plants of tomorrow. When

ITER starts running plasma shots,

operators all over the world need

to crunch the same huge amounts

of data collected by the tokamak's

diagnostics systems at the same

time as those in the on-site control

room. The challenge: finding a way

to transfer data as fast as possible

to a site half a world away.

Pipe Fabrication in the US for the Tokamak Cooling Water System Foto © iter.org


patible with that of the tokamak's expe-

riments – approximately one pulse every

30 to 60 minutes – was demonstrated in

early September by information techno-

logy specialists from ITER and their coun-

terparts at three Japanese institutes: the

National Institute for Quantum and Ra-

diological Science and Technology (QST),

the National Institute for Fusion Science

(NIFS) and the National Institute of Infor-

matics (NII) in cooperation with the Euro-

pean agency for ITER. The demonstrated

repeat transfer of 1 terabyte of data within

30 minutes and some 50 terabytes of data

per day is the largest level inter-continen-

tal high speed data transfer between two

sites in the world. At an average speed of

7.9 Gigabits per second (Gbps), this is some

1,600 times faster than the average global

broadband connection.

Collaboration and new Technologies push the limits of possible

The record-breaking speed was made pos-

sible by the implementation of a super-fast

protocol, the Massively Multi- Connection

File Transfer Protocol-MMCFTP (see box)

over a direct link recently established bet-

ween the GÉANT network and the 5th ge-

neration of the SINET network (SINET 5),

developed and operated by NII. The direct

20 Gbps connection between Japan and

Europe has reduced the physical distance

of data travels by one-third; in fact previ-

ously the data had to travel via the Uni-

ted States. In addition, by constructing a

dedicated virtual private network (L2VPN)

between Rokkasho and ITER, the collabo-

ration between GÉANT and RENATER, the

operator of the national Research and Edu-

cation network in France, has created a

stable, highlysecure broadband network.

Infusing new energy into european-japanese research collaboration

Over 50 million researchers, academics and

students across Europe and Japan will be

able to benefit from this direct connection

and technology. In addition to the ITER pro-

ject, this capacity boost will answer the

increasing data transfer requirements of

collaborative research between Europe

and Japan on other projects, such as the

Large Hadron Collider (LHC) at CERN and

the worldwide e-VLBI radio-astronomy net-

work. This unique collaboration within the

international networking community ena-

bles scientists to redefine and push the

limits of research and discovery. M

THE PROTOCOL BEHIND THE SPEED

The Massively Multi-Connection File Transfer Protocol (MMCFTP) de-

veloped by Japan’s NII overcomes the limitations of standard TCP/

IP protocol. With TCP/IP, data is only sent after an acknowledgment

is received, to confirm that each packet sent is correct. Over long di-

stances, this takes a very long time so that data transfer speed for

large amounts of data decreases dramatically. MMCFTP is one of the

world's fastest protocols for transferring data over long distances.

Using MMCFTP, the data file is split, creating multiple connections si-

multaneously and balancing the amount that is sent over each con-

nection to maintain a steady speed. MMCFTP was adopted for the

nuclear fusion field so the full capability of the network connection

could be exploited. The use for other data-intensive experimentation

is limited only by the imagination.

Kurzmeldungen

APAN43 – Launch von Asi@Connect

Die NREN Community feierte auf der Asi-

atisch-Pazifischen Networking Konferenz

(APAN43) in Neu-Delhi den Start des EU-geför-

derten Projekts Asi@Connect. Asi@Connect

ist das Nachfolgeprojekt zu TEIN4, der jüngs-

ten Phase der TEIN-Initiative. Es unterstützt

derzeit 24 Länder durch die Bereitstellung

eines regionalen Hochleistungs-Internet-

Backbones für F&E-Kooperationen im asi-

atisch-pazifischen Raum. Asi@Connect ist

Partner des europäischen GÉANT-Netzwerks

und verbindet die Länder der Region mit

NRENs weltweit.

Der DFN-Verein nahm an APAN43 teil mit

dem Ziel, die Zusammenarbeit mit dem indi-

schen National Knowledge Network (NKN)

zu fördern und Kontakte zu NRENs aus dem

asiatisch-pazifischen Raum weiter auszu-

bauen. Das National Knowledge Network

(NKN) betreibt das indische Forschungsnetz

sowohl für Forschungseinrichtungen und

Universitäten als auch für die indischen Mi-

nisterien. Seit Mitte letzten Jahres verfügt

NKN über eine eigene 10G-Verbindung von

Mumbai nach Amsterdam, mit einem Peering

zu GÉANT. Eine Fortführung der Verbindung

zum CERN in der Schweiz und zu Internet2

in den USA ist in Vorbereitung.

Indien verfügt als einer der BRIC-Staaten

über ein großes Potenzial an gut ausge-

bildeten Forschern und Wissenschaftlern,

nicht nur im IT-Bereich. In der Wirtschaft

bestehen bereits enge Kooperationen zwi-

schen deutschen und indischen Firmen

und Niederlassungen. Die neue 10G-Ver-

bindung von NKN zu GEANT bietet eine

gute Grundlage, diese Zusammenarbeit

auch im wissenschaftlichen Bereich wei-

ter zu stärken. M

EU unterzeichnet Verträge für BELLA

Die Bestrebungen zur Finanzierung für das Projekt BELLA (Buil-

ding Europe Link to Latin America) konnten im Dezember 2016 er-

folgreich abgeschlossen werden. Mit BELLA wird es Forschungs-

netzen in Lateinamerika und Europa ermöglicht, ein Drittel des

Übertragungsspektrums auf einem direkten Unterseekabel über

einen Zeitraum von 25 Jahren zu nutzen. Mit gegenwärtiger Tech-

nik könnten damit bereits heute mehrere 100G-Verbindungen be-

leuchtet werden. Innerhalb der nächsten 25 Jahre dürften sogar

noch einige Leistungssprünge zu erwarten sein.

Am 14. Dezember 2016 unterzeichnete GÉANT den noch fehlen-

den Vertrag mit DG GROWTH, dem Direktorat der Europäischen

Kommission für Binnenmarkt, Industrie, Unternehmertum und

KMU. Zusammen mit den Vereinbarungen mit dem Direktorat

für Internationale Zusammenarbeit und Entwicklung (DG DEV-

CO) sowie mit dem Direktorat für Kommunikationsnetze, Inhal-

te und Technologien (DG CONNECT), sind jetzt die insgesamt 25

Mio. Euro gesichert, die für die Finanzierung von BELLA erfor-

derlich sind.

Dem Bau des Unterseekabels steht somit hoffentlich nichts mehr

im Wege. Das Vergabeverfahren zur Bestimmung des Anbieters

wurde in 2016 begonnen; derzeit läuft die Ausgestaltung des Ver-

trages mit einer Kabelgesellschaft. Das Auslaufen des Kabelle-

gers – so der Fachausdruck für das Schiff mit den ca. 9.000 km

Unterseekabel an Bord – ist für 2018 beabsichtigt. Die Betriebs-

aufnahme der ersten beiden 100G-Verbindungen zwischen Bra-

silien und Portugal wird in 2019 erwartet. M


Text: Leonie Schäfer (DFN-Verein)

DFN-Workshop „GÉANT IaaS-Vergabeverfahren“

Die europäische Forschungsnetzorganisation GÉANT hat im Jahr

2016 ein Vergabeverfahren für „Infrastructure-as-a-Service“-Diens-

te (IaaS) durchgeführt. Dadurch wurde eine Voraussetzung ge-

schaffen, dass der DFN-Verein IaaS-Dienste mit für die Wissen-

schaft maßgeschneiderten Nutzungsbedingungen in die DFN-

Cloud aufnehmen kann.

Der DFN-Verein lud am Vortag der 66. DFN-Betriebstagung am

20. März 2017 in Berlin zum DFN-Workshop „GÉANT IaaS-Verga-

beverfahren“ ein, um die Ergebnisse des Vergabeverfahrens vor-

zustellen sowie die Umsetzung in Deutschland zu diskutieren.

Vor allem sollten die Teilnehmer über die besonderen Konditio-

nen des Vergabeverfahrens informiert werden. Im Anschluss an

die Präsentationen hatten die über 70 interessierten Teilnehmer

des Workshops die Gelegenheit, sich die einzelnen IaaS Angebo-

te direkt von den Dienstanbietern vorstellen zu lassen.

Ziel der Veranstaltung war es außerdem, Interessenten frühzei-

tig miteinander zu vernetzen und gemeinsam Handlungsschrit-

te zu erarbeiten, welche notwendig sind, um ein bereits beste-

hendes Dienstangebot an Einrichtungen durch kommerzielle

IaaS-Dienste zu ergänzen. Während des Workshops und in des-

sen Folge wurde von potenziellen Anwendern eine noch detail-

liertere Betrachtung der Regelungen und Mechanismen des Be-

schaffungs- und Datenschutzrechts im Kontext des Vergabever-

fahrens erbeten, an der nun gemeinsam gearbeitet wird.

Die Folien vom Workshop und weitere Informationen zur Um-

setzung des Vergabeverfahrens finden Sie unter:

https://www.dfn.de/dfn-cloud/weiterentwicklung/ M

EaPConnect – das erste Drittel

Das EU-Projekt EaPConnect startete am 1. Juli 2015 mit sechs

Partnern aus den EaP-Ländern, einer Laufzeit von 5 Jahren und

einer Fördersumme von 13 Mio. Euro.

Nach Ablauf des ersten Projekt-Drittels fand in Brüssel am 9. März

2017 das erste EaPConnect Review-Meeting statt. Die sechs EAP

Projekt-Partner (Moldawien, Belarus, Ukraine, Aserbaidschan,

Georgien und Armenien), die vier assoziierten Partner (SurfNET,

DFN, LITNET und PSNC), sowie GÉANT als Projektmanager, prä-

sentierten erste Ergebnisse.

Das Projekt stößt innerhalb der EU Kommission auf großes Inter-

esse. So waren zu dem Review-Meeting nicht nur Repräsentanten

der beiden verantwortlichen Generaldirektionen (DG) European

Neighbourhood, Policy and Enlargement (DG NEAR) und Com-

munications Networks, Content and Technology (DG CONNECT)

anwesend, sondern auch Teilnehmer der DG Forschung (RTD),

DG Education and Culture (DG EAC) und des European External

Action Services (EEAS).

Ziel des Review-Meetings war es, die Relevanz, Effizienz, Effek-

tivität und Nachhaltigkeit des Projekts zu beurteilen und kon-

krete Empfehlungen zur Optimierung des Projektverlaufs zu ge-

ben. Die Projektergebnisse wurden sehr positiv aufgenommen,

über eine Verlängerung der aktuellen Laufzeit von 5 Jahren wird

bereits nachgedacht. M

Workshop „Business Models for NRENs“

Das Thema „Business Models for NRENs“ beschäftigte im Januar

die Partner des Projekts EaPConnect. 22 Teilnehmer aus 13 ver-

schiedenen Ländern diskutierten im Rahmen eines Workshops

in Berlin zwei Tage Geschäftsmodelle verschiedener NRENs in

Europa. Ziel des Workshops war es, Geschäftsmodelle zu ver-

gleichen, geeignete Modelle als Grundlage für die Entwicklung

eigener Lösungen heranzuziehen und Strategien für Nachhal-

tigkeit zu erarbeiten. Der Workshop wurde durch den DFN-

Verein organisiert und fand in der Geschäftsstelle in Berlin statt. M

Foto © DFN-Verein


https://www.dfn.de/dfn-cloud/weiterentwicklung/

38 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | FORSCHUNG

GeRDI - Generic Research Data Infrastructure: Forschungsdatenübergreifend vernetzen

Forschungsdaten dauerhaft, nachnutzbar und sicher

speichern zu können, ist in Deutschland noch lange

nicht für jeden Wissenschaftler möglich. Nur wenige

Universitäten betreiben einen eigenen Forschungs-

datenspeicher und diese bereits existierenden Daten-

speicher sind kaum miteinander vernetzt. Dadurch ist

eine disziplinübergreifende Nutzung von Forschungs-

daten in Deutschland bislang nicht möglich. Das Pro-

jekt GeRDI will dies ändern und eine Infrastrukturtech-

nologie entwickeln, welche das systematische inter-

disziplinäre Auffinden und Verarbeiten publizierter

Forschungsdatensätze ermöglicht. Damit wird Wis-

senschaftlern die Suche nach bereits existierenden

Forschungsdaten über die Grenzen der Forschungs-

disziplinen und deren getrennten Datenveröffentli-

chungsstrukturen hinweg erleichtert.

Text: Jakob Tendel (DFN-Verein)

Ende 2016 startete mit GeRDI

(Generic Research Data Infrastruc-

ture) ein Projekt mit dem Ziel,

eine vernetzte Forschungsdaten-

Infrastruktur zu entwickeln und

aufzubauen. Dafür sollen existie-

rende und zukünftige Forschungs-

datenspeicher virtuell verknüpft

werden, um Wissenschaftlern in

ganz Deutschland die Möglichkeit

zu geben, disziplinübergreifend

Forschungsdaten zu recherchie-

ren und nachnutzen zu können.

Arbeitstreffen in Berlin (Foto DFN-Verein)

39FORSCHUNG | DFN Mitteilungen Ausgabe 91 |

Zum Ende des Jahres 2016 nahm der DFN-

Verein auf nationaler Ebene neben vier wei-

teren Einrichtungen aus der Deutschen F&L

Gemeinde seine Aufgaben im DFG Projekt

GeRDI auf.

GeRDI hat den Anspruch, auch den soge-

nannten Long Tail zu bedienen – also Nut-

zer mit moderaten Datenmengen und oh-

ne großen bereits existierenden Organi-

sationsgrad der zugehörigen Fachcom-

munities. Insgesamt kann mit GeRDI ein

wesentlicher und modellhafter Beitrag

dazu geleistet werden, dass Hochschu-

len und außeruniversitäre Forschungs-

einrichtungen die Aufgabe der Verwal-

tung von Forschungsdaten aktiv anneh-

men und mitgestalten können. Mit den

angestrebten Ergebnissen stellt das Pro-

jekt die Anschlussfähigkeit des deutschen

Wissenschaftssystems an aktuelle euro-

päische und internationale Entwicklun-

gen (European Open Science Cloud) sicher.

Die erste Phase von GeRDI ist auf drei Jahre

angesetzt. Während dieser Zeit sollen nach

aktuellen Planungen Prototypen für eine

Forschungsdaten-Suchmaschine und eine

Daten-Management-Umgebung konzipiert,

aufgebaut und evaluiert werden. Das Inter-

face der GeRDI Umgebung soll den Anwen-

der nicht nur beim Auffinden existierender

Forschungsdaten unterstützen, sondern

über Schnittstellen auch bei der Überfüh-

rung der Daten in Zwischenspeicher und

Analysesysteme, bis hin zur Veröffentli-

chung der Ergebnisdaten in spezifischen

Daten-Repositorien. Die Ausrichtung von

GeRDI soll es ermöglichen, Forschungsda-

ten über Disziplin- und Fächergrenzen hin-

aus miteinander kombinieren zu können.

Drei Pilotsysteme befinden sich in Dres-

den, Kiel und München und speichern in-

terdisziplinäre Forschungsdaten, u. a. aus

den Lebenswissenschaften, Meereswissen-

schaften und Wirtschaftswissenschaften.

Bei den Standorten handelt es sich um drei

unterschiedliche Einrichtungstypen: eine

Universität, ein Höchstleistungsrechen-

zentrum und eine außeruniversitäre For-

schungseinrichtung. In Phase II des Projek-

tes soll die entwickelte Lösung im größe-

ren Maßstab ausgerollt werden.

Das Projekt GeRDI wird von der DFG in

der ersten Projektphase mit ca. 3 Millio-

nen Euro gefördert. Der DFN-Verein über-

nimmt im Projekt Verantwortung für die

Erarbeitung eines nachhaltigen Trainings-

konzeptes, welches die speziell in GeRDI

entwickelten Systeme dokumentiert, und

die Einsatzformen für die Endanwender

verständlich und praxisorientiert nutzbar

macht. Das Material wird so präsentiert,

dass es sich am Informationsbedarf der

Nutzer orientiert und die Evolution des

Systems als Ganzes begleitet. Zusätzlich

soll der DFN-Verein ein nachhaltiges Be-

triebs- und Finanzierungs konzept für die

Zeit nach der Projektförderung erarbeiten.

Diese Arbeiten hängen naturgemäß von

der letztendlich ausgewählten Systemar-

chitektur und den beteiligten Partnerein-

richtungen ab.

Die Partner des DFN-Vereins im Projekt sind:

• ZBW – Leibniz Informationszentrum

Wirtschaft

• CAU – Christian-Albrechts-

Universität zu Kiel

• LRZ – Leibniz-Rechenzentrum

der Bayerischen Akademie der

Wissenschaften

• TUD – Technische Universität

Dresden

Als Partner für Fallstudien im Rahmen der

Entwicklungsarbeiten wurden Vertreter

aus den Bereichen Wirtschaftswissen-

schaft, Umweltwissenschaft und Ozea-

nografie gewonnen.

Im Januar 2017 fand das erste zweitägige

Arbeitstreffen in Berlin statt, bei dem die

Vorstellungen hinsichtlich Zielsetzung,

Projektrahmen, technischer Werkzeuge

und Lösungsansätze abgestimmt wurden.

Ebenso wurden gemeinsam die Endnutzer-

Befragungen zur konkreten Bedarfsermitt-

lung in den teilnehmenden User-Communi-

ties vorbereitet. Diese Erhebungen in den

Fachcommunities bilden die Grundlage für

die Definition der benötigten generischen

und fachspezifischen Funktionalitäten des

GeRDI Systems und werden auch im Lau-

fe der Entwicklungsarbeit regelmäßig zur

Präzisierung der Entwicklungsziele heran-

gezogen. So wird gewährleistet, dass die

im Laufe des Projekts entwickelte Lösung

sich auch an den Anforderungen der zu-

künftigen Anwender orientiert. M

Arbeitstreffen in Berlin (Foto DFN-Verein)

40 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | SICHERHEIT

41SICHERHEIT | DFN Mitteilungen Ausgabe 91 |

Sicherheit10 Jahre DFN-AAI – ein Universalschlüssel zum Erfolg

von Wolfgang Pempe

Sicherheit durch Clientmanagementsysteme am Beispiel von

OPSI & Communityprojekt ‚opsi4institutes‘ (o4i)

von Detlef Krummel


von Susanne Weinmann, Jens Syckor

Sicherheit aktuell

von Ralf Gröper


10 Jahre DFN-AAI – ein Universalschlüssel zum Erfolg

Text: Wolfgang Pempe (DFN-Verein)

Seit den bescheidenen Anfängen im Jahr 2007 hat sich die DFN-AAI mittlerweile zu einer der

weltweit größten Föderationen entwickelt und erfreut sich einer sehr aktiven und kompetenten

Nutzerschaft, nicht nur an den Heimateinrichtungen, sondern auch in der internationalen

Wissenschaftscommunity. Neben dem eigentlichen Föderationsbetrieb wurde das Dienstportfolio

im Laufe der Jahre durch zahlreiche angelagerte Dienstleistungen erweitert. So steht mit der

Teilnahme an eduGAIN insbesondere wissenschaftlichen Forschungsverbünden die Möglichkeit

zur Verfügung, föderationsübergreifend AAI-basierte Strukturen zu etablieren und zu nutzen.

Neue Herausforderungen ergeben sich insbesondere hinsichtlich des Datenschutzes und der

sich abzeichnenden Änderung des zugrundeliegenden Standards.

Foto © Eskemar / iStockphoto


Was ist (DFN-)AAI?

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 (i. d. R. Nutzername und Passwort), bei

internen und externen Diensten anzumel-

den (Authentifizierung) und – entsprechen-

de Berechtigungen vorausgesetzt (Autori-

sierung) – diese zu nutzen. Die hierfür er-

forderliche Infrastruktur, AAI (= Authenti-

cation and Authorization Infrastructure),

wird traditionell im Rahmen nationaler

Föderationen realisiert und in der Regel

von den jeweiligen Forschungsnetzwer-

ken betrieben. Im Fall der Bundesrepublik

Deutschland ist dies der DFN-Verein. Da-

neben existieren aber auch einige kleine-

re Föderationen, die sich zur Nutzung be-

stimmter, zentraler Dienste zusammenge-

funden haben, z. B. E-Learning-Plattformen.

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, E-Learning-Plattformen,

wissenschaftliche Dienste, etc.) registriert

sind. Weiterhin existieren mit sogenann-

ten Attribute Authorities externe Attribut-

quellen, anhand derer ein SP zusätzliche,

i. d. R. projektspezifische Nutzerdaten ab-

rufen kann, die nicht von der Heimatein-

richtung gepflegt werden. Bezeichnet wer-

den solche Instanzen (IdP, SP, Attribute Au-

thorities) auch als Entities. Bei den in den

Metadaten hinterlegten Informationen

handelt es sich sowohl um administrati-

ve (Organisation, Kontaktdaten) als auch

um technische Daten (Service-Endpunk-

te, Zertifikate, etc.), die zur Kommunikati-

on der Entities untereinander erforderlich

sind. Als Standard hat sich hier flächende-

ckend SAML (Security Assertion Markup

Language) durchgesetzt. Die Aufgabe der

jeweiligen Föderation ist es, diese Daten-

sätze zu pflegen, aktuell zu halten und

sicherzustellen, dass innerhalb der Föde-

ration ein sicherer und vertrauenswürdi-

ger Austausch von Informationen stattfin-

det. Das technische Rückgrat einer solchen

Föde ration bilden somit die vom Föderati-

onsbetreiber signierten Metadaten (siehe

Abbildung 1).

Wie alles begann

Die Motivation, eine AAI für die deutsche

Hochschul- und Forschungscommunity

zu schaffen, geht auf das vom BMBF ge-

förderte AAR-Projekt (Authentifizierung,

Autorisierung und Rechteverwaltung)

zu rück, das 2005 startete. Das wichtigste

Ziel des Projekts war es, den Web-SSO-Zu-

griff auf lizenzierte elektronische Inhalte

(Journals, Datenbanken, Bücher, etc.) zu er-

möglichen, der gegenüber den herkömm-

lichen Methoden des Zugriffschutzes (IP-

Kontrolle, VPN, Proxies) deutliche Vorteile

bietet. So ermöglicht die auf AAI-Attribute

gestützte Autorisierung eine zuverlässige-

re und differenziertere Kontrolle des Zu-

griffs auf lizenzierte Inhalte als ein IP-ba-

sierter Zugang, bei dem nur der Standort

des jeweiligen Rechners oder Terminals

eine Rolle spielt. Darüber hinaus besteht

beim IP-Verfahren auch keine zuverlässi-

ge Möglichkeit zur personalisierten Nut-

zung von Diensten, da keine von der Hei-

mateinrichtung bestätigten Nutzerdaten,

also keine Attribute übertragen werden.

Die treibende Kraft war seinerzeit die Uni-

versitätsbibliothek Freiburg, die sich auch

heute noch am Betrieb der DFN-AAI Hotline

beteiligt. Nach umfangreichen technischen

und organisatorischen Vorarbeiten sowie

zahlreichen Workshops, Schulungen und

sonstigen Informationsveranstaltungen,

wurde die DFN-AAI im Herbst 2007 schluss-

endlich in den Regelbetrieb überführt und

steht den DFN-Nutzern seitdem als soge-

nannter Mehrwertdienst zur Verfügung.

Was weiterhin geschah

Die treibende Kraft während der Anfangs-

phase der DFN-AAI waren die Hochschulbib-

liotheken. Folgerichtig handelte es sich bei

einem Großteil der seinerzeit in der DFN-

AAI verfügbaren Dienste bzw. SP um Ange-

bote wissenschaftlicher Verlage und Fach-

datenbanken. Nachdem die Möglichkeiten

und Vorzüge der AAI bekannt geworden wa-

ren, kamen jedoch schnell weitere Arten

10 Jahre DFN-AAI – ein Universalschlüssel zum Erfolg

Abbildung 1: Schematische Darstellung der Funktionsweise SAML-basierter Kommunikation.

SP = Service ProviderIdP = Identity Provider

IdM / Nutzer-verzeichnis

Heimateinrichtung

NutzerIn

Dienst

Metadaten

Anwendung

SAML2Security AssertionMarkup Language

Browser


von Diensten hinzu: Verteilung lizenzier-

ter Software (z. B. Microsoft DreamSpark),

hochschulinterne Dienste (lokale SP) so-

wie verschiedene E-Learning Plattformen.

War der Betrieb der lokalen AAI-Kompo-

nenten in vielen Fällen ursprünglich eine

Domäne der Hochschulbibliotheken, so

änderte sich dies im Laufe der Zeit. Spä-

testens mit dem Aufkommen föderierter

(also AAI-fähiger) HPC-, Speicher-, Kommu-

nikations- (Webconferencing) und Cam-

pus-Dienste, entwickelten auch die Hoch-

schulrechenzentren ein Interesse an dem

Betrieb AAI-relevanter Komponenten und

lokaler Dienste. Anfang März 2017 waren

in der DFN-AAI 644 lokale SP an 80 Einrich-

tungen registriert.

In den letzten Jahren etablierten sich als

weitere Akteure verschiedene Landespro-

jekte und -initiativen wie bwIDM, die Vir-

tuelle Hochschule Bayern (VHB), Nds-AAI,

SaxID, Kultusministerien und andere mehr,

die ihre Dienste jeweils auf Landesebene

verfügbar machen wollen.

Mit internationalen Forschungsverbün-

den und –infrastrukturen, die ihre Diens-

te föderationsübergreifend anbieten und

nutzen wollen, ist der DFN-AAI seit einigen

Jahren eine weitere wichtige Zielgruppe

erwachsen, die mit ihren Bedürfnissen die

traditionelle AAI vor neue Herausforderun-

gen stellt – mehr dazu unter „Wie geht es

weiter?“ auf Seite 46. Als Beispiele seien

hier CLARIN (Sprachressourcen), DARIAH

(Geisteswissenschaften), ELIXIR (Life Sci-

ence) und LIGO (Gravitationswellen-For-

schung) genannt.

Was bietet die DFN-AAI?

Außer der reinen Verwaltung der Föderati-

onsmetadaten bietet die DFN-AAI mittler-

weile einige weitere Dienstleistungen an:

Ausgelagerter IdP:

Für Einrichtungen, denen die Ressourcen

zum Betrieb eines eigenen IdP fehlen, bie-

tet der DFN-Verein einen Hosting-Service

an, d. h. der IdP wird vom DFN betrieben,

verbindet sich aber mit dem Nutzerver-

zeichnis/IdM der jeweiligen Einrichtung.

Derzeit werden 28 solcher IdP-Instanzen

auf DFN-eigenen virtuellen Maschinen be-

trieben. Dies sind mehr als 10 % aller pro-

duktiven Identity Provider in der DFN-AAI.

Discovery Services:

Ein Discovery Service (auch „WAYF“ ge-

nannt: Where Are You From) dient der Ein-

richtungs- und somit IdP-Auswahl am SP.

Der DFN-Verein betreibt mehrere zentrale

Instanzen: DFN-AAI (-Advanced), DFN-AAI-

Basic, DFN-AAI-Test und DFN-AAI-Basic +

eduGAIN. Auf Wunsch werden auch pro-

jektspezifische WAYF-Instanzen zur Ver-

fügung gestellt.

Entity Attribute:

Bei Entity Attributen handelt es sich um

eine Erweiterung (Extension) der SAML2-

Metadaten, die es ermöglicht, einzelne En-

tities flexibel zu Gruppen zusammenzufas-

sen, die bestimmte Eigenschaften teilen,

z. B. die Zugehörigkeit zu einem bestimm-

ten Projekt oder die Einhaltung bestimmter

Datenschutz- oder Sicherheitsstandards

wie des GÉANT Data Protection Code of

Conduct for Service Providers oder des

Security Incident Response Trust Frame-

work for Federated Identity (Sirtfi). Anhand

der Attributnamen und -werte lassen sich

sowohl Metadaten filtern als auch Attribut-

freigaben an Gruppen von Service Provi-

dern definieren. Ein besonders häufig ver-

wendetes Entity Attribut stellt die soge-

nannte Entity Category dar, die beliebig

viele Werte annehmen kann.

Föderationsübergreifende AAI via

eduGAIN:

Mit den an eduGAIN teilnehmenden Föde-

rationen (43 Föderationen, Stand 03/2017)

werden seit 2012 Metadaten ausgetauscht,

sodass Teilnehmern der DFN-AAI prinzi piell

auch Dienste aus anderen Föderationen

zur Verfügung stehen. Im Gegenzug kön-

nen Nutzer aus anderen Föderationen auf

Service Provider in der DFN-AAI zugreifen,

sofern dies von den Dienstbetreibern ge-

wünscht wird (Opt-In) – siehe Abbildung 2.

Lokale Metadaten:

Heimateinrichtungen haben die Möglich-

keit, in der Metadatenverwaltung die Op-

tion „lokale Metadaten“ zu aktivieren. Da-

mit wird ein separater Metadatensatz ge-

neriert, in den ausschließlich der IdP der

Einrichtung sowie lokale Dienste/SP auf-

genommen werden. Einige Universitäten

betreiben mittlerweile dutzende solcher

lokalen Service Provider.

Testumgebung:

Die DFN-AAI Testföderation dient der

Überprüfung der Konfiguration und der

Funktionsfähigkeit von neu zu registrie-

renden Entities. Hierzu betreibt der DFN-

Verein mehrere Test-SP und -IdP. Nur wenn

die Kommunikation mit diesen Testin-

stanzen erfolgreich war, wird ein IdP/SP

in die Produktivumgebung der DFN-AAI

aufgenommen.

Verlässlichkeitsklassen:

Anhand bestimmter Merkmale des Identity

Managements an den Heimateinrichtun-

gen werden Identity Provider der Verläss-

lichkeitsklasse „Advanced“ oder „Basic“ zu-

geordnet. Auf technischer Ebene erfolgt die

Differenzierung über zwei entsprechende

Metadatensätze. SP-Betreiber können ent-

scheiden, welchen davon sie verwenden.

Virtuelle Subföderationen:

Anhand von Entity Categories, die nach ei-

nem festgelegten Prozedere in die Födera-

tionsmetadaten eingetragen werden, kön-

nen SP-Instanzen diejenigen IdP aus den

Metadaten herausfiltern, die Zugriff auf

den jeweiligen Dienst erhalten sollen. Ein

IdP kann anhand eines solchen Merkmals

die Attributfreigabe an Gruppen von Ser-

vice Providern steuern. Diese Funktiona-

lität ist vor allem interessant für Landes-

dienste bzw. -Projekte wie bwIDM, Nds-

AAI oder die Virtuelle Hochschule Bayern.

Wiki:

Seit Sommer 2015 wird die bestehende On-

line-Dokumentation der DFN-AAI schritt-

weise in ein Wiki übertragen (https://wiki.

aai.dfn.de), auf das Mitglieder der Commu-

https://wiki.aai.dfn.de

https://wiki.aai.dfn.de


nity auf Wunsch Schreibzugriff erhalten.

Auf diese Weise konnten zahlreiche Spezi-

alfälle dokumentiert werden, die nachzu-

stellen das Team der DFN-AAI selber nicht

in der Lage gewesen wäre.

Workshops:

Seit Bestehen der DFN-AAI wurden insge-

samt 16 Workshops zu überwiegend tech-

nischen Themen veranstaltet. Seit 2015

finden in Zusammenarbeit mit der FU Ber-

lin regelmäßig Workshops statt, die sich

mit Themen rund um den Shibboleth IdP

befassen.

Wieviel und wie oft?

Um ein Gefühl für die quantitative Entwick-

lung der DFN-AAI zu erhalten, lohnt sich am

ehesten ein Blick auf die Anzahl der produk-

tiven IdP- und SP-Instanzen, die seit 2010

regelmäßig erfasst werden – siehe hierzu

das folgende Diagramm. Ende 2007, also

kurz nach dem offiziellen Start der DFN-

AAI waren 14 Dienstvereinbarungen mit

Heimateinrichtungen sowie SP-Verträge

mit vier Anbietern abgeschlossen. Seitdem

hat sich Zahl der in der DFN-AAI registrier-

ten Service Provider weitestgehend linear

weiterentwickelt, wobei die Entwicklung

seit 2016 noch zugenommen hat. Deutlich

stärker ausgeprägt ist dieser Trend bei den

lokalen SP-Instanzen. Bei den IdP-Installa-

tionen hingegen ist seit Ende 2015 ein ge-

wisser Sättigungsprozess zu beobachten.

Dies liegt an der mittlerweile vorhandenen

großen Abdeckung – es kommen vor allem

Abbildung 2: An eduGAIN beteiligte Föderationen (Quelle: https://technical.edugain.org/, Stand März 2017)

eduGAIN

Voting-only

Candidate

Abbildung 3: Entwicklung der produktiven IdP- und SP-Instanzen seit 2010

0

100

200

300

400

500

600

700

09.0

9.20

10

09.0

1.20

11

09.0

5.20

11

09.0

9.20

11

09.0

1.20

12

09.0

5.20

12

09.0

9.20

12

09.0

1.20

13

09.0

5.20

13

09.0

9.20

13

09.0

1.20

14

09.0

5.20

14

09.0

9.20

14

09.0

1.20

15

09.0

5.20

15

09.0

9.20

15

09.0

1.20

16

09.0

5.20

16

09.0

9.20

16

09.0

1.20

17

IdP SP lokale SP

https://technical.edugain.org/


noch kleinere Einrichtungen hinzu. Anfang

März 2017 waren 232 IdP, 351 SP sowie 644

lokale SP an insgesamt 80 Einrichtungen

registriert (siehe S. 45, Abbildung 3).

Die Anzahl der registrierten IdP und SP

sagt jedoch nichts über die tatsächliche

Nutzung dieser Entities aus. Im Fall der

DFN-AAI lassen sich hierzu keine absolu-

ten Angaben machen, da es sich um eine

sogenannte Mesh Federation handelt, bei

der die Kommunikation direkt zwischen

den beteiligten Entities erfolgt, während

bei einer Hub-and-Spoke Federation die

gesamte Kommunikation über einen zen-

tralen, von der betreffenden Föderation

betriebenen Proxy, den sogenannten Hub

gelenkt wird. Insofern können hier nur ei-

nige Beispiele angeführt werden, die unge-

fähre Rückschlüsse auf das Nutzungsver-

halten der Teilnehmer erlauben. Der vom

DFN-Verein betriebene zentrale Discovery

Service, der von etwa 17 Prozent der SP

genutzt wird, erfährt derzeit (März 2017,

Semesterferien) ca. 5000 Zugriffe pro Tag,

die sich sehr unterschiedlich auf die jewei-

ligen SP-Instanzen verteilen. So entfallen

ca. 4400 Anmeldungen auf die zehn am häu-

figsten genutzten Service Provider. Was

die Anzahl der Logins pro teilnehmendem

IdP angeht, so liefert eine kürzlich durch-

geführte inoffizielle Erhebung unter den

IdP-Administratoren ein sehr heterogenes

Bild. So meldete eine der Berliner Univer-

sitäten knapp 3000 Anmeldungen pro Tag

bei externen Diensten sowie bis zu 45.000

bei lokalen SP-Instanzen, während am an-

deren Ende der Skala einige kleinere Ein-

richtungen mit Login-Zahlen rangieren,

die im dreistelligen Bereich liegen – pro

Monat. Als entscheidende Faktoren er-

weisen sich hierbei das Vorhandensein

bzw. die Zahl der lokalen SP, die Notwen-

digkeit, auf (föderierte) Landesdienste zu-

zugreifen sowie der Umstand, ob und in

welchem Umfang die jeweilige Bibliothek

über Web-SSO/SAML auf lizenzierte Inhal-

te zugreift oder hierfür noch ein IP-basier-

tes Verfahren nutzt.

Wie geht es weiter?

Mit fortschreitender Entwicklung des

Dienstes ergeben sich auch neue Heraus-

forderungen, die der DFN-AAI u. a. aufgrund

der Masse an zu verarbeitenden Metada-

ten, neuen Nutzergruppen und Anforde-

rungen sowie des technischen Fortschritts

erwachsen.

Mit zunehmender internationaler Beteili-

gung an eduGAIN wächst mit der Zahl der

teilnehmenden Entities – derzeit ca. 2300

IdP und 1500 SP – auch das Volumen der

Metadaten-Dateien, die es föderationsin-

tern zu verteilen und zu verarbeiten gilt.

Manche IdP- und SP-Installationen haben

Schwierigkeiten, solch große XML-Dateien

zu verarbeiten. Da das Konzept, statische

Metadaten-Dateien als Grundlage für die

Kommunikation zwischen IdP und SP zu

verwenden, nicht beliebig skaliert, wer-

den derzeit alternative Verfahren evalu-

iert, die ein vergleichbares Maß an Sicher-

heit und Vertrauen bieten, z. B. das Meta-

data Query Protocol (MDQ).

Die SP der Content Provider der ersten

Stunde (und auch spätere) verlangen zur

Autorisierung üblicherweise keine perso-

nenbezogenen Daten, sondern lediglich

ein sogenanntes Entitlement oder alter-

nativ eine Information über den Status

des Endnutzers (student, member, facul-

ty, etc.), die ‚Affiliation‘. Insofern spielt es

auch i. d. R. datenschutzrechtlich keine Rol-

le, ob ein solcher SP innerhalb Deutsch-

lands, der EU oder z. B. in den USA betrie-

ben wird. Seit einiger Zeit setzen interna-

tionale Forschungsinfrastrukturen und

-projekte vermehrt auf föderierten Zu-

gang zu ihren Diensten, die ein völlig an-

deres Attributprofil erfordern. Nicht nur

der guten wissenschaftlichen Praxis we-

gen, sondern auch um das Mapping zwi-

schen dem bei der jeweiligen Heimatein-

richtung angemeldeten Nutzer und etwai-

gen dienst-/projekt-spezifischen Nutzerda-

ten herzustellen, wird neben Angaben zu

Personennamen, Heimateinrichtung und

E-Mail-Adresse, ein global gültiger, eindeu-

tiger Identifier benötigt. Da es sich hierbei

um datenschutzrechtlich relevante perso-

nenbezogene Daten handelt, scheuen sich

IdP-Administratoren häufig davor, die At-

tributfreigabe für solche Dienste zu kon-

figurieren, auch wenn der betreffende IdP

zusätzlich eine explizite Freigabe der zu

übertragenden Attribute durch den End-

nutzer ermöglicht (User Consent). Meist ist

die lokale Nutzerschaft solcher Dienste auf

ein einziges Institut beschränkt, was die

hochschulinterne Lobbyarbeit erschwert.

Für den europäischen Rechtsraum wurde

vor einigen Jahren der GÉANT Data Pro-

tection Code of Conduct for Service Provi-

ders in EU/EEA (CoCo) eingeführt, zu des-

sen Einhaltung sich Service Provider ver-

pflichten können – als vertrauensbildende

Maßnahme gegenüber den Heimateinrich-

tungen. Diese Selbstverpflichtung wird in

den Metadaten über eine Entity Catego-

ry (s. o.) ausgedrückt, deren Vergabe von

den jeweiligen Föderationsbetreibern ge-

regelt wird und anhand derer IdP-seitig die

Attributfreigabe gesteuert werden kann.

Dienste, die beispielsweise in den USA be-

trieben werden, sind jedoch aufgrund des

Geltungsbereichs der aktuell gültigen EU-

Datenschutzrichtlinie von dieser Maßnah-

me ausgeschlossen. Der Versuch, mit der

Research and Scholarship Entity Category

die Datenfreigabe an forschungsrelevante

Service Provider zu vereinheitlichen und

zu erleichtern, war bislang nur mäßig er-

folgreich, u. a. weil hier keine Aussagen

bzgl. des Datenschutzes gemacht werden.

Derzeit ruhen große Hoffnungen auf der

momentan in Arbeit befindlichen Version

2 des CoCo, der die Vorgaben der ab 2018

in Kraft tretenden EU-Datenschutz-Grund-

verordnung umsetzt und auch die Übertra-

gung personenbezogener Daten in Dritt-

staaten behandeln wird.

Wie eingangs erwähnt beruhen die techni-

schen Komponenten und das Format der

Metadaten aller großen Föderationen auf

SAML bzw. SAML2. Seit einigen Jahren wird

mit OpenID Connect ein konkurrierender

Standard als Alternative zu SAML2 gehan-


delt. OpenID Connect gilt als übersichtli-

cher (JSON anstatt XML), weniger komplex

und flexibler als SAML, insbesondere was

die Unterstützung von Nutzungsszenari-

en ohne Browser (Non-Web-SSO) angeht –

ein großer Vorteil bei der Implementierung

für mobile Endgeräte (Apps). Mit Google,

Microsoft und anderen Konzernen findet

dieser Standard eine mächtige Lobby, die

die Entwicklung und Verbreitung von Open-

ID Connect und ergänzenden Standards

vorantreibt.

In der Praxis beschränken sich OpenID Con-

nect Installationen bislang auf geschlos-

sene, lokale Kontexte, werden also inner-

halb einer bestimmten Infrastruktur betrie-

ben, in der ein Vertrauensverhältnis zwi-

schen den einzelnen Komponenten über

den jeweiligen organisatorischen und tech-

nischen Kontext definiert wird. Um eine

auf OpenID Connect beruhende Föderati-

on zu etablieren, sind zusätzliche Maßnah-

men zu definieren (Signatur-Hie rarchien

u. a. m.), die über den eigentlichen Stan-

dard hinausgehen und deren Spezifikati-

on sich aktuell noch in der Entwurfsphase

befindet. Mit OpenID Connect Federation

wird auf Föderationsebene eine ähnliche

Komplexität erreicht, wie sie derzeit mit

SAML2 gegeben ist.

Der DFN-Verein verfolgt die Entwicklung

von OpenID Connect seit einigen Jahren

und wird zunächst eine Testinstallation zur

Verfügung stellen. Auch wenn derzeit noch

nicht absehbar ist, ob und wann Open ID

Connect sinnvoll auf Föderationsebene

eingesetzt werden kann, wird derzeit die

Möglichkeit evaluiert, im Rahmen der DFN-

AAI Bridging-Elemente zur Verfügung zu

stellen, die es ermöglichen, als Proxy lo-

kale OpenID Connect Installationen (auf

Hochschul- oder Projektebene) an die DFN-

AAI anzuschließen.

Ein weiterer Punkt, der besonderer Auf-

merksamkeit bedarf, ist das Sicherstel-

len eines störungsfreien Betriebs. Nach-

dem es im Oktober 2016 aufgrund eines

mit der Metadatenverwaltung inkompati-

blen OpenSSL-Upgrades zu einer ca. 4-stün-

digen Störung in der DFN-AAI gekommen

war, wurden neben den unverzüglich ein-

geleiteten technischen Maßnahmen zur

Behebung dieser Art von Störung, in den

folgenden Monaten weitere Schritte un-

ternommen, die sicherstellen sollen, dass

sich solche und ähnliche Vorfälle zukünf-

tig nicht wiederholen. Anfang 2017 ging ei-

ne neue Version der DFN-AAI Metadaten-

verwaltung in Betrieb, bei der zusätzliche

Sicherheitsmechanismen implementiert

wurden. Im Laufe des Jahres 2017 sollen

die Teile des Programmcodes der Metada-

tenverwaltung, die noch auf die Anfänge

der DFN-AAI zurückgehen, einem schritt-

weisen Code Review unterzogen werden.

Was bleibt

… ist ein Dank an die geschätzte Nutzer-

schaft – für 10 Jahre Treue, spannende Dis-

kussionen auf diversen Veranstaltungen

und der aai-users Liste, viele hilfreiche

Beiträge zur Online-Dokumentation so-

wie zahlreiche Anregungen und Verbes-

serungsvorschläge. Wir, das Team der DFN-

AAI, freuen uns darauf, den Dienst auch in

den kommenden Jahren gemeinsam mit

der Community weiter zu entwickeln. M

• DFN-AAI Portal

https://www.aai.dfn.de

• eduGAIN

http://www.edugain.org

• GÉANT Data Protection Code of Conduct for Service Providers in EU/EEA

https://www.aai.dfn.de/der-dienst/datenschutz/data-protection-code-

of-conduct/

• OpenID Connect

http://openid.net/connect/

• SAML (= Security Assertion Markup Language)

https://www.oasis-open.org/committees/tc_home.php?wg_

abbrev=security

• Sirtfi (Security Incident Response Trust Framework for Federated Iden-

tity)

https://wiki.refeds.org/display/SIRTFI/SIRTFI+Home

• Verlässlichkeitsklassen in der DFN-AAI

https://www.aai.dfn.de/der-dienst/verlaesslichkeitsklassen/

REFERENZEN

https://www.aai.dfn.de

http://www.edugain.org

https://www.aai.dfn.de/der-dienst/datenschutz/data-protection-code-of-conduct/



http://openid.net/connect/

https://www.oasis-open.org/committees/tc_home.php?wg_

https://wiki.refeds.org/display/SIRTFI/SIRTFI+Home

https://www.aai.dfn.de/der-dienst/verlaesslichkeitsklassen/


Sicherheit durch Clientmanagement-systeme am Beispiel von OPSI & Com-munityprojekt „opsi4institutes“ (o4i)

Text: Detlef Krummel (Georg-Eckert-Institut)

Etwa 36 % der erfolgreichen Cyberangriffe erfolgen über ungenügend aktualisierte Clients

und Server. Um dies zu verhindern, ist der Einsatz eines Clientmanagementsystems sinnvoll.

Das Communityprojekt „opsi4institutes“ (o4i) koordiniert und verteilt die zeitaufwendigen

Aktualisierungsarbeiten der Softwarepakete auf mehrere wissenschaftliche Einrichtungen

im Deutschen Forschungsnetz.

Eine DFN-Mailingliste informiert herstellerunabhängig und strukturiert über vorliegende

Updates von mehr als 150 Softwareprodukten.

Foto © whitemay / iStockphoto


Das Georg-Eckert-Institut – Leibniz-Institut

für internationale Schulbuchforschung (GEI)

ist seit seiner Gründung im Jahr 1975 im Be-

reich der Bildungsmedienforschung tätig.

In Braunschweig werden an zwei Stand-

orten in einer virtualisierten Server- und

Storageumgebung mit hohem Linuxanteil

seit 2010 ca. 170 Clients mit einem Client-

managementsystem verwaltet.

Clientsicherheit

In größeren Struktureinheiten, wie sie an

Universitäten und Hochschulen oft vor-

handen sind, betreut ein Rechenzentrum

die Sicherheit rund um die zentralen In-

frastrukturen (Server, Firewall, LAN etc.).

Die Mitarbeiter-Clients werden im Allge-

meinen erst in den nachgeordneten Insti-

tuten/Fakultäten/Abteilungen gemanagt.

Die Sicherheit der verwendeten Clients ist

entscheidend, eine Kompromittierung wür-

de einen „Angriff von innen“ mit Benutzer-

rechten nach sich ziehen. Laut der Cyber-

Sicherheitsumfrage 2015 des Bundesamtes

für Sicherheit in der Informationstechnik

(BSI) sind 36 % der primären Einfallstore

auf nicht eingespielte Patches1 zurückzu-

führen (siehe Abbildung 1).

Hierbei ist bei Anwendungsprogrammen

die fachliche Unterscheidung zwischen

Hotfix, Bugfix und Update, im nachfolgen-

den zusammenfassend Aktualisierung ge-

nannt, im Massenbetrieb nicht praxisre-

levant. Der erforderliche Rechercheauf-

wand, ob eine Aktualisierung sicherheits-

technischer oder funktionaler Natur ist,

ist selten vertretbar. Daher werden übli-

cherweise alle Arten von Aktualisierungen

an die Clients verteilt. Kommerzielle und

OpenSource-Produkte unterscheiden sich

kaum in der Häufigkeit der angebotenen

Aktualisierungen.

Clientmanagementsysteme

In Einrichtungen mit mehr als 50 Clients

werden die Softwareinstallationen und

Aktualisierungen meist zentral durch die

IT bereitgestellt. Hierbei werden zum Bei-

spiel verschiedene kommerzielle Produkte

wie SCCM (Microsoft), ACMP (Aargon), Empi-

rum (Matrix42) oder Baramundi, aber auch

OpenSource-Produkte wie OPSI (uib), WP-

KG, FAI, m23 und OCS Inventory NG, zum

Einsatz gebracht. Die meisten dieser Pro-

dukte sind modular aufgebaut. Die Grund-

funktionalitäten eines Clientmanagement-

systems umfassen im Allgemeinen:

• Betriebssystem-Installation

Windows, teilweise Linux

• Installation, De-Installati-

on und Aktualisieren von

Anwendungsprogrammen

• Software-Inventarisierung,

Hardware-Inventarisierung

In der zeitlichen Gesamtbetrachtung

nimmt die Funktion „Aktualisieren von

Anwenderprogrammen“ aufgrund ihrer

Häufigkeit den Löwenanteil beim Client-

management in Anspruch.

Die Grafik Lebenszyklus Paket auf S. 50

(Abbildung 2) zeigt vier Schritte, welche

als „Lebenszyklus eines Softwarepaketes“

betrachtet werden können. Dieser Zyklus

wird schleifenartig erstmalig bei der In-

stallation und immer wieder bei Aktuali-

sierungen durchlaufen.

Meist unabhängig von einem Clientmanag-

mentsystem werden Windows-Betriebs-

systeme und Microsoft-Programme üblicher -

weise durch einen lokalen WSUS aktualisiert.

Update-Benachrichtigungs-

service (o4i-Notify)

Unabhängig vom konkret eingesetzten

Clientmanagementsystem muss der ver-

antwortliche Administrator auf irgendei-

ne Art und Weise erfahren, dass eine Aktu-

alisierung für das jeweilige Produkt beim

Hersteller zur Verfügung steht. Für die all-

gemein und hauptsächlich verwendeten

Anwendungen wie Firefox, Java, Flash etc.

stellt dies kein Problem dar, das DFN-Cert

und Fachportale wie www.heise.de berich-

ten über Security-Fixes und Updates. Bei

den unzähligen Tools und wissenschaftli-

chen Anwendungen ist dies nicht der Fall,

hier seien beispielhaft PSPP, NotePad++, Zo-

tero, OpenVPN, VLC und TexMaker genannt.

Abbildung 1: Primäre Einfallstore, Quelle: Bild BSI-Magazin 2016–01

bisher unbekannte Schwachstellen ohne verfügbare Paches (sogenannte 0-Day-Lücken)

unbeabsichtigtes Fehl-verhalten von Mitarbeitern

nicht eingespielte Pachtes

Fehlkonfigurationen von Systemen

Primäre Einfallstore

42,2 %

42,2 %

31,8 %

35,9 %

http://www.heise.de


Des Weiteren ist zu beachten, dass sich die

Gesamtanzahl der zu betreuenden Soft-

wareprodukte schnell aufsummiert. Denn

Softwareprodukte müssen neben den üb-

licherweise vorhandenen Organisations-

einheiten Verwaltung, Bibliothek und IT,

auch in den forschenden Abteilungen/

Fakultäten (Sozialwissenschaften, Archi-

tektur, Physik usw.) sowie gegebenenfalls

auch bei den Softwareentwicklungsteams

betreut werden. Deren Anwendungspro-

gramme ergeben in Summe zusammen

mit den „Hilfs-Anwendungen“ wie z. B.

dotNET, Java, PDF und Zip/Arj unter Um-

ständen einen 60 bis 100 Produkte umfas-

senden Softwarepool.

Aus den statistischen Daten der letzten 23

Monate (ab 5/2015) des nachfolgend be-

schriebenen Update-Benachrichtigungs-

services kann abgeleitet werden, das bei

80 gemanagten Softwareprodukten monat-

lich zwischen 40 und 60 Aktualisierungen

durchzuführen sind. Das sind 2 – 3 Aktuali-

sierungen pro Werktag (siehe Abbildung 3).

Um sich zeitnah über die Aktualisierungen

von Softwareprodukten verschiedener Her-

steller informieren zu können, muss ein Ad-

ministrator sich üblicherweise in diverse

Mailverteiler eintragen, Webseiten beob-

achten, sich teilweise in Foren einschrei-

ben oder gar RSS-Feeds abonnieren. Jeder

Softwarehersteller hat seine eigenen Vor-

stellungen und dies verursacht einen er-

heblichen Zeitaufwand in den IT-Abteilun-

gen. Manuell ist das Update-Monitoring

bei mehr als 30 Produkten kaum leistbar,

vor allem nicht täglich.

Zur Unterstützung von Administratoren

wurde ein Service2 programmiert, welcher

individuell für jedes einzelne Softwarepro-

dukt die Original-Quelle des Herstellers au-

tomatisch prüft. Im Wesentlichen parsen

via Cron täglich aufgerufene Skripte die

dort genannte Versionsnummer, den aktu-

0

20

40

60

80

100

120

140

160

180

05.2

015

07.2

015

09.2

015

11.2

015

01.2

016

03.2

016

05.2

016

07.2

016

09.2

016

11.2

016

01.2

017 neues SW-Monitoring

Summe Update Msg

Summe SW-Produkte

Abbildung 3: o4i_DFN-Notify (neue SW-Produkte,

Summe SW, Summe Update-Msg)

Abbildung 2: Lebenszyklus Paket

1. Software-Download & lokale Test-Installation

2. Paketierung & Test-Rollout

3. Rollout auf die ClientsMonitoring des Rollouts

täglicher Update-Check via Cron & normierte E-Mail-Benachrichtigung (o4i-Notify)

Erst-Paketierung bzw. pro Software-Update

Lebenszyklus Paket

4. Prüfen Herstellerweb-site auf Update/Fixes


ellen Dateinamen und Download-Link. Die-

se Informationen werden mit der letzten

lokal gespeicherten Softwareversion des

Produktes verglichen. Im Falle einer vor-

liegenden Aktualisierung wird eine struk-

turierte E-Mail versendet, die sich gut via

SIEVE o .ä. filtern lässt:

(Code-Block) FROM: [email protected]: [opsipackage]-{$PAKETNAME} Update gefunden! [$alteVersion]->[$neueVersion]MAILBODY: Sie finden ein Update der Software {$PAKETNAME} Version [$DOWNLOAD_VERSION] unter $DOWNLOAD_LINK.

Dieser stetig wachsende Update-Benachrich-

tigungsservice (o4i-Notify) umfasst derzeitig

ca. 150 Produkte, eine Liste wird monatlich

aktualisiert online3 bereitgestellt. Die zum

Versand der Update-Benachrichtigungen

verwendete Mailingliste „opsi4instituts-

[email protected]“ ist frei abonnierbar

(SubScribe/UnSubScribe) und besitzt auch

ein durchsuchbares Listenarchiv4.

OpenSource-Clientmanage-mentsystem „OPSI“.

Das in Deutschland weit verbreitete5 Open-

Source-Clientmanagementsystem OPSI

wird seit 1995 von der Firma UIB aus Mainz

entwickelt. Die aktuell 15 Mitarbeiter finan-

zieren sich durch Projekte, Supportverträ-

ge, Paket-Abonnements, Schulungen/Work-

shops und Ko-Finanzierungsbeiträge für

(neue) Erweiterungen (z. B. Lizenzmanage-

ment, UEFI-Support, WAN-Support, WIM-

Capture, User Roles, Directory Connector).

Der „OPSI-Kern“ und die bereits fertig finan-

zierten Erweiterungen (Treeview, Software-

Kiosk-Mode, Shutdown-On-Demand, User-

profile-Management, Dynamic-Depot) sind

OpenSource unter AGPLv3. Der freie Sup-

port erfolgt unter Beteiligung einer großen

User-Community über ein aktives Herstel-

lerforum6 (ca. 3.300 User, 32.000 dt. Foren-

beiträge, ca. 8.600 Beiträge von UIB). Es exis-

tieren auch angrenzende Communitypro-

jekte wie der „opsi-PackageBuilder“ als gra-

fische, Phython-basierte Oberfläche zum

Paket-Patchmanagement und eine Andro-

id-App „OPSI-Admin“ zur mobilen Anwen-

dung inkl. QR-Code-Scan des Inventarisie-

rungsetikettes. Als Beispiel für die effizien-

te Arbeitsweise von OPSI ist nachfolgend

die Erzeugung eines Updatepaketes und

dessen Rollout auf die Clients einer Litera-

turverwaltung mit fünf einfachen Schrit-

ten, welche weniger als fünf Minuten be-

nötigen, dargestellt:

(Code-Block)# cd /home/opsipro-ducts/Paketerstellung/dfn_mendeley-desktop# wget http://desktop-download.mendeley.com/download/Mendeley-Desktop-1.17.7-win32.exe -O CLIENT_DATA/Mendeley-Desk-top-1.17.7-win32.exe# vi OPSI/control (Versions-nummer eintragen, hier die 1.17.7)# opsi-makeproductfile# opsi-package-manager --in-stall dfn_mendeley-desk-top_1.17.7-1.opsi –setup

Auf eine funktionelle API mit ca. 400 Metho-

den wird durch die javabasierte Administra-

tionsoberfläche „opsi-ConfigEd“, via JSON-

Webservice und über ein CLI-Programm

„opsi-admin“ (scriptbar!) zugegriffen.

0

20

40

60

80

100

120

04.2

015

06.2

015

08.2

015

10.2

015

12.2

015

02.2

016

04. 2

016

06.2

016

08.2

016

10.2

016

12.2

016

02.2

017

Summe Einrichtungen

Summe Admins

Abbildung 4: o4i, wissenschaftliche Einrichtungen

und teilnehmende Admins


mailto:[email protected]%E2%80%9C


http://desktop-download.mendeley.com/




Beispielsweise aktiviert ein einfaches, zu

jedem Monatsersten via Cron aufgerufe-

nes Shellscript ein regelmäßiges Software-

Audit bei allen gemanagten Clients:

(Code-Block)#!/bin/bashPATH=/sbin:/bin/:/usr/sbin/:/usr/binOPSICLI="opsi-admin -ds method"for client in $($OPSICLI getClientIds_list | sort ) ; do$OPSICLI setProductActionRequest swaudit $client setupdone

Die bereits genannte Erweiterung „Soft-

ware-Kiosk-Mode“ ermöglicht dem norma-

len, nicht administrativen Benutzer sich

selbstständig auf seinen PC/Laptop vom

Administrator freigegebene Anwendungs-

pakete zu installieren. Die Installation er-

folgt mit den Vorgaben des Administrators

und wird somit in das Clientmanagement

integriert (weitere Aktualisierungen, gege-

benenfalls die Blockierung einer Clientli-

zenz aus dem Pool usw.).

Im OPSI werden auch dezentrale Software-

Depotserver in anderen LAN-Segmenten

(Außenstelle), Schnittstellen zu Nagios/

Icinga sowie auch Funktionalitäten in Rich-

tung ITIL (kix4otrs) unterstützt.

Neben der Windows-OS-Installation und

dem Anwendungs-Patchmanagement, ist

die Unterstützung von diversen Linux-Dis-

tributionen als OS-Installation und Anwen-

dungs-Paketmanagement (Erweiterung

„Linux-Agent“) im wissenschaftlichen Um-

feld sehr interessant.

Communityprojekt „OPSI 4

Institutes“ (o4i)

Ausgehend von der Zusammenarbeit der

zwei Leibniz-Institute „gei.de“ und „wzb.

eu“ hat sich seit Februar 2015 eine stetig

wachsende Community von Administra-

toren gebildet, die OPSI als Clientmanage-

mentsystem einsetzen.

Das Projekt war von Anfang an nicht nur

auf die Leibniz-Gemeinschaft beschränkt,

sondern umfasste auch Einrichtungen an-

derer Wissenschaftsorganisationen (Max-

Planck, Fraunhofer, Helmholtz) sowie

Universitäten, Uni-Kliniken, Hochschulen

und Fachhochschulen (siehe Abbildung 4,

Seite 51).

Ausgehend von der initialen Mailingliste

„‚[email protected]“ hat sich

ein Portfolio von Diensten entwickelt.

Nachfolgend ist eine Übersicht über das

Portfolio und somit auch die Struktur von

„o4i“ dargestellt (siehe Abbildung 5).

Als Wissensbasis rund um „opsi4institu-

tes“ dient ein WIKI. Hier sind neben den

opsi-Paket-Beschreibungen auch Informati-

onen zu den teilnehmenden wissenschaft-

lichen Einrichtungen und deren Ansprech-

partnern sowie Informationen zu Services

und auch diverse HowTo's enthalten.

Das zentrale o4i-Paket-Repository7 mit ak-

tuell 78 betriebsfertigen opsi-Paketen ist

öffentlich verfügbar (Stand 3/2017). Der zu-

sätzliche „non-public“-Zweig des Reposi-

torys enthält 14 Pakete mit Distributions-

einschränkungen und ist nur „o4i“-Mitglie-

dern zugänglich.

Beide Zweige werden durch die verant-

wortlichen Paket-Maintainer fortlaufend

aktualisiert. Der Upload in das Reposi tory

ist durch Zertifikate der DFN-PKI abgesi-

Notify-Servicelistserv.dfn.de/sympa/info/

opsi4instituts-notify

Mailinglistenlistserv.dfn.de/sympa/info/

opsi4instituts

ZusammenarbeitXMPP:[email protected].

edu

Repository https://opsi.wzb.eu

WIKI https://opsi.wzb.eu/wiki

Code- Repository https://github.com/

opsi4instituts

Abbildung 5: Services



https://opsi.wzb.eu/wiki

https://opsi.wzb.eu

https://github.com/


chert. Der zusätzliche Aufwand für einen

OPSI-Administrator, um ein eigenes Pa-

ket dem o4i-Repository zur Verfügung zu

stellen, ist recht klein (ca. 10 min). Entspre-

chend des Communitygedankens sind im-

mer gern weitere Maintainer willkommen,

auch als Neben-Maintainer zur Urlaubs-

vertretung. Es wird angestrebt, die OPSI-

Scripte der betreuten Anwendungspakete

bei GITHUB zu hosten, um die collaborati-

ve Paketerstellung zu ermöglichen.

Für den direkten Erfahrungsaustausch

steht der vom KIT.edu bereitgestellte per-

sistente Chatroom opsi4instituts@confe-

rence.kit.edu zur Verfügung, welcher offen

über XMPP erreichbar ist.

Synchronisation mit dem

o4i-Paketrepository

Das Clientmanagementsystem OPSI ent-

hält das Programm ‚opsi-product-updater‘

mit dem die systemeigenen Updates vom

UIB-Repsitory und die lokale Paketsynchro-

nisation mit dezentralen Softwaredepots

realisiert werden. Der Befehl ‚opsi-product-

updater‘ wird üblicherweise mittels Cron

zyklisch aufgerufen.

Durch das Eintragen des o4i-Repository´s

in die Konfigurationsdatei „/etc/opsi/opsi-

product-updater.conf“ ist es möglich, sein

lokales Depot mit den stetig aktualisier-

ten Paketen zu befüllen:

(Code-Block) [repository_dfn]active = trueopsiDepotId =baseUrl = https://opsi.wzb.eudirs = /excludes = lib,dfn_srware-ironautoInstall = trueautoUpdate = trueautoSetup = trueonlyDownload = false

Die Konfigurationsoptionen „autoInstall“

und „autoUpdate“ installieren neue Pa kete

des o4i-Repository in das lokale OPSI-De-

pot bzw. aktualisieren bereits vorhande-

ne lokale Pakete.

Mit der Option „autoSetup=true“ wird ein

hoher Automatisierungseffekt erreicht.

Beim Eintreffen von Paketupdates vom

o4i-Repository werden sofort bei den Cli-

ents, welches dieses Softwarepaket ins-

talliert haben, dieses automatisch auf Se-

tup/Update gestellt.

Damit hat nur ein verantwortlicher Main-

tainer den Arbeitsaufwand bei der Pake-

taktualisierung, in den an o4i angeschlos-

senen wissenschaftlichen Einrichtungen

werden deren Clients ohne lokalen Admi-

nistrationsaufwand automatisch aktuali-

siert! Hier kommt der Einsatz von Open-

Source im wissenschaftlichen Umfeld so-

wie eine aktive Community institutsüber-

greifend voll zum Tragen.

Fazit

Ein nicht vollständig aktualisierter Client,

d. h. Betriebssystem und Anwendungs-

programme, ist nachweislich eine erheb-

liche Sicherheitslücke. Durch den Einsatz

von Clientmanagement-Systemen wird

sig nifikant die Sicherheit der gesamten IT-

Umgebung verbessert.

Die Verfügbarkeit von Aktualisierungen

muss zeitnah den Administratoren bekannt

sein, hierfür steht mit o4i-Notify ein her-

stellerunabhängiger und freier Update-

Benachrichtigungsservice zur Verfügung.

OPSI ist als OpenSource-Clientmanage-

mentsystem sehr effizient und durch Er-

weiterungen ausbaubar.

Die Zusammenarbeit zwischen den wissen-

schaftlichen Einrichtungen beim Einsatz

von OPSI wird durch das Communitypro-

jekt „opsi4instituts“ koordiniert und durch

die dadurch entstehende Arbeitsverteilung

deutlich effektiver. Mein Dank geht an die-

ser Stelle an all die anderen Kollegen, die

durch ihre unermüdliche Arbeit zum Ge-

lingen des Projektes beitragen.

Am 18. und 19. Mai 2017 fand eine Kon-

ferenz zum Einsatz des Clientmanage-

mentsystems OPSI in wissenschaftlichen

Einrichtungen im Georg-Eckert-Institut in

Braunschweig statt. M

1 https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/

Magazin/BSI-Magazin_2016_01.pdf

2 https://opsi.wzb.eu/wiki/index.php/Update-Notify/Public

3 http://www.gei.de/fileadmin/gei.de/bilder/abteilungen/difi/

opsi4instituts/o4i_DFN-Notify.pdf

4 https://www.listserv.dfn.de/sympa/arc/opsi4instituts-notify

5 http://uib.de/de/opsi/opsi-map/

6 https://forum.opsi.org

7 https://opsi.wzb.eu/?C=M;O=D

REFERENZEN




https://opsi.wzb.eu

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/

https://opsi.wzb.eu/wiki/index.php/Update-Notify/Public

http://www.gei.de/fileadmin/gei.de/bilder/abteilungen/difi/

https://www.listserv.dfn.de/sympa/arc/opsi4instituts-notify

http://uib.de/de/opsi/opsi-map/

https://forum.opsi.org

https://opsi.wzb.eu/?C=M


Hintergrund

Bereits vor der Veröffentlichung von Win-

dows 10 im August 2015 gab es zahlreiche

Berichte zur angestrebten, umfangreichen

Datensammlung durch das Betriebssys-

tem. Häufig war von einer „Datenkrake“

die Rede. Tatsächlich benötigt das geän-

derte Geschäftsmodell, das Platzieren per-

sonalisierter Werbung, umfangreiche In-

formationen über die Nutzer von Windows

10, um für diese dann optimal ausgewählte

Werbeinhalte bereitzustellen. Dieser Um-

stand veranlasste das Team um den IT-

Sicherheitsbeauftragten der Max-Planck-

Gesellschaft, sich eingehender mit dem

Thema zu befassen und das Betriebssys-

tem ausführlich zu testen.

Aufgrund der Fülle an Informationen und

Konfigurationsmöglichkeiten wurde be-

reits früh ein Austausch mit anderen Ein-

richtungen angestrebt. Daraus gewonnene

Erkenntnisse wurden schließlich im Herbst

2015 auf der jährlichen Tagung des Arbeits-

kreises Informationssicherheit der deut-

schen Forschungseinrichtungen (AKIF) ver-

öffentlicht. Aufgrund des großen Interes-

ses hat sich schließlich eine Arbeitsgrup-

pe gebildet, welche ihre Ergebnisse und

Erfahrungen aus verschiedenen Tests und

auch mit verschiedenen Einsatzszenarien

in einem Dokument zusammengefasst hat.

Dieses wurde allen Forschungseinrichtun-

gen und Hochschulen als Orientierungs-

hilfe zur Verfügung gestellt hat.


Text: Susanne Weinmann (Max-Planck-Gesellschaft), Jens Syckor (TU Dresden)

Mit Windows 10 beschreitet Microsoft neue Wege. Weg vom klassischen, statischen Betriebssystem

hin zum dynamischen Windows-as-a-Service, welches nur noch als Plattform für Apps, Cloud-Anwen-

dungen, Spiele und andere Dienste, wie z. B. Office 365, verwendet wird. Im Gegensatz zu bisherigen

Betriebssystemen wie Windows XP oder Windows 7 wird Windows 10 stetig weiterentwickelt. Die

dadurch wegfallenden Einnahmen aus dem Verkauf von Betriebssystemen sollen auf einem ande-

ren Weg erreicht werden: ähnlich wie bei Apple oder Google wird auf den Nutzer zugeschnittene

Werbung platziert. Dies erfordert jedoch Informationen über den Nutzer, welche auf verschiedenste

Arten generiert werden. Im folgenden Artikel wird auf diesen Umstand eingegangen und versucht

darzulegen, wie man diese Datensammlung zumindest minimieren kann.

Foto © JeDo / fotolia.com


Die Orientierungshilfe zur datenarmen Konfiguration von Windows 10

Ziel des Dokuments ist es, Hochschulen

und Forschungseinrichtungen zu entlas-

ten, welche aufgrund mangelnder Res-

sourcen, aber auch wegen unzureichen-

der Kenntnisse (da der Fokus z. B. auf an-

deren Betriebssystemen liegt) nicht selbst

die Möglichkeit haben, solch umfangrei-

che Tests und Recherchen durchzuführen.

Im Gegensatz zu vorherigen Windows-

Betriebssystemen werden neue Features

nicht mehr als Service Pack oder sogar kom-

plett neues Betriebssystem ausgeliefert,

sondern über regelmäßige Updates. Die-

se erscheinen unabhängig von den nor-

malen monatlichen Updates zweimal jähr-

lich. Das bedeutet, dass möglicherweise

zweimal jährlich auch komplett neue Fea-

tures verfügbar sind, über die es noch kei-

ne Erkenntnisse gibt. Entsprechend groß

ist der Aufwand für den Test und den Be-

trieb von Windows 10.

Zu den kritisch bewerteten

Features und Diensten

zählt beispielsweise

der neue Browser Edge.

Der Fokus der Orientierungshilfe liegt auf

Features und Diensten, welche besonders

viele Daten sammeln. Dabei werden zum ei-

nen Informationen zu deren Funktionalität

gegeben sowie Empfehlungen zur Konfigu-

ration gemacht, und alles, soweit möglich

und sinnvoll, mithilfe von Screenshots do-

kumentiert. Hervorzuheben ist dabei auch

die Sammlung von Windows-Gruppenricht-

linien und PowerShell-Skripten, die für die

Administratoren von zentral verwalteten

Geräten wichtig ist.

Zu den kritisch bewerteten Features und

Diensten zählen bspw. Cortana, der neue

Browser Edge, das Taskleisten-Suchfeld,

die Werbe-ID, Windows Update sowie die

Telemetriedaten. Ein weiterer kritischer

KLEINES JUBILÄUM – GROSSE THEMEN

Am 29. und 30. November 2016 fand die 5. DFN-Konferenz Datenschutz im

Hotel Grand Elyssée in Hamburg statt. Die Konferenz mit 170 Teilnehmern

stand dabei ganz im Zeichen der kommenden Veränderungen durch die

EU-Datenschutz-Grundverordnung, die ab dem 25.05.2018 in allen Mitglied-

staaten der Europäischen Union unmittelbar gelten wird.

Das Thema Datenschutz hat in den vergangenen Jahren zunehmend an Ge-

wicht gewonnen. Im Auftrag des DFN-Vereins veranstaltet das DFN-CERT

deshalb seit 2012 jährlich eine DFN-Konferenz Datenschutz. Mit der Veran-

staltung kommt der DFN-Verein dem Bedarf von Forschungs- und Wissen-

schaftseinrichtungen an rechtlicher Unterstützung bei der praktischen

Umsetzung von Datenschutz nach. Die DFN-Konferenz Datenschutz

richtet sich ausdrücklich, aber nicht ausschließlich an Hochschulen sowie

Forschungs- und Wissenschaftseinrichtungen. So ist die Tagung im Grand

Elysée Hotel in Hamburg inzwischen für viele Einrichtungen im DFN-

Verein, aber auch für andere Teilnehmer zu einem wichtigen feststehen-

den Termin geworden.

Mit der DFN-Konferenz Datenschutz verfolgt der DFN-Verein zwei Ziele:

Zum einen sollen sich die Teilnehmer untereinander persönlich kennen-

lernen und austauschen können. Hierzu bietet die zweitägige Konferenz

durch einen entsprechend gestalteten Tagungsablauf, wie unter ande-

rem einer Abendveranstaltung im Gröninger Braukeller, ausgezeichnet

Gelegenheit. Zum anderen werden in der Konferenz aktuelle Themen aus

dem Bereich des Datenschutzes – insbesondere auch in ihrer Relevanz für

Hochschulen, Forschungs- und Wissenschaftseinrichtungen – aufgegriffen.

Von Datenschutzexperten, Vertretern der Datenschutzaufsichtsbehörden

und Praktikern werden sie in sechs auf die Praxis bezogenen Vorträgen im

Detail beleuchtet. Hierbei werden verschiedene Sichtweisen deutlich, die

das Verständnis von Anwendungsproblemen erleichtern und helfen, ent-

sprechende Lösungsstrategien zu entwickeln.

Für die DFN-Konferenz Datenschutz konnten in der Vergangenheit hoch-

rangige Expert(inn)en aus der Praxis als Referent(inn)en für Vorträge ge-

wonnen werden. Neben dem ehemaligen Bundesdatenschutzbeauftrag-

ten, den Landesdatenschutzbeauftragten aus mehreren Bundesländern

und unabhängigen Rechtsexperten, sind dabei auch Datenschutz- und Si-

cherheitsbeauftragte großer und kleiner Einrichtungen aus Wissenschaft

und Forschung zu Wort gekommen.

Die 6. DFN-Konferenz Datenschutz wird am 28./29. November 2017 statt-

finden. Das ausführliche Programm wird im Spätsommer auf den Websei-

ten der DFN-CERT-Services GmbH veröffentlicht (https://www.dfn-cert.de/).

Wenn Sie eine E-Mail an [email protected] senden, weisen wir Sie ger-

ne auf das Erscheinen des Programms hin. Mit Erscheinen des Programms

wird auch die Möglichkeit zur Anmeldung eröffnet. Wir freuen uns auf Ihre

Teilnahme.

https://www.dfn-cert.de/



Punkt ist, dass bisherige Updates teilweise Einstellungen zurück-

gesetzt oder geändert haben. Das hat zur Folge, dass das kom-

plette System nach einem Update dahin gehend geprüft wer-

den muss, ob bereits vorgenommene Einstellungen beibehal-

ten wurden oder nicht.

Insgesamt ist festzustellen, dass Windows 10 in seiner bisheri-

gen Form nicht das Prinzip „Privacy by Design“ verfolgt. Es ist

nötig, umfangreiche Konfigurationen vorzunehmen, um zumin-

dest in weiten Teilen das Prinzip „Privacy by Default“ zu erfüllen.

Wie geht es weiter?

Aufgrund der stetigen Weiterentwicklung von Windows 10 ist

auch die Orientierungshilfe ein dynamisches Dokument, wel-

ches einem laufenden Aktualisierungsprozess unterliegt. Die je-

weils aktuelle Fassung findet sich unter: https://www.it-sicher-

heit.mpg.de/Orientierungshilfe_Windows10.pdf

Kommunikationsverhalten von Windows 10

Welche Verkehrsbeziehungen etabliert Windows 10 zu Microsoft

und wie lässt sich dieses Kommunikationsverhalten durch eine

datenarme Konfiguration anhand der Orientierungshilfe mini-

mieren? Diesen Fragestellungen hat sich ein Team der TU Dres-

den gestellt und sie in einer speziell entwickelten Umgebung

untersucht (siehe Abbildung 1).

In diesem Setup wurde Windows 10 als „Black-Box“ betrachtet,

d. h. die Kommunikation wurde aus dem Client-Betriebssystem

heraus über eine vorkonfigurierte Netzwerkumgebung geleitet

und mittels eines Protokollierungssystems (Syslog) ausgewertet.

Es wurden verschiedene Szenarien entworfen und analysiert,

die unterschiedliche Konfigurationseinstellungen zur datenar-

men Konfiguration beinhalteten. Die Auswertung des Kommu-

nikationsverhaltens erfolgte dabei immer ohne Benutzerinter-

aktion im Betriebssystem.

Windows 10 wird von Microsoft in verschiedenen Editionen an-

geboten, die einen unterschiedlichen Funktionsumfang aufwei-

sen. Im Setup wurden zwei vom Funktionsumfang sehr unter-

schiedliche Editionen untersucht: Windows 10 Education und

Windows 10 Enterprise LTSB. Education war zum Zeitpunkt der

Untersuchung funktional vergleichbar zur Edition Enterprise,

d. h. dem Angebot für Unternehmen. Enterprise LTSB (Long-Term

Servicing Branch) ist eine spezielle Edition, die hauptsächlich für

„Mission-Critical-Umgebungen“ konzipiert ist und deshalb keine

Funktionalitäten enthält, die seitens Microsoft einem sehr dy-

namischen Veränderungsprozess unterliegen, wie z. B. Cortana

oder der Browser Edge. LTSB wird daher von Microsoft lediglich

mit Sicherheits- und Stabilitätsupdates versorgt. Weiterhin hat

LTSB einen Support-Zeitraum von 10 Jahren.

Im Ergebnis der Untersuchungen wurde festgestellt, dass die

Edition Education im Vergleich zu LTSB in jedem Szenario ein

deutlich erhöhtes Kommunikationsverhalten aufweist (minimal

49 Kommunikationsziele bei Education, 14 bei LTSB 2015). Das

geringste Kommunikationsverhalten war außerdem nur nach-

weisbar, wenn administrative Konfigurationsmöglichkeiten ver-

wendet worden sind. Bei einer nutzergeführten Konfiguration

war das Kommunikationsverhalten im Vergleich zur administ-

rativen Konfiguration immer auf einem erhöhten Niveau. Wei-

terhin wurde festgestellt, dass bereits während der Installation

und Erstkonfiguration des Betriebssystems Kommunikationsbe-

ziehungen zu Microsoft aufgebaut worden sind.

Zusammenfassend konnte das geringste Kommunikationsver-

halten beim Einsatz von Windows 10 Enterprise LTSB mit der voll-

umfänglichen datenarmen Konfiguration nach der AKIF-Orien-

tierungshilfe erzielt werden. M

NutzerIn/Browser

Internet

Syslog-ServerWindows 10

Firewall

Abbildung 1: Versuchsaufbau der TU Dresden

https://www.it-sicherheit.mpg.de/Orientierungshilfe_Windows10.pdf

https://www.it-sicherheit.mpg.de/Orientierungshilfe_Windows10.pdf


Sicherheit aktuellRedaktion: Ralf Gröper (DFN-Verein), Texte: Jürgen Brauckmann, Martin Waleczek (DFN-CERT)

Lebenszyklus von Windows-Produkten und

Produktsicherheit

Mit dem End-of-Life (genauer: End of extended Support) von Win-

dows Vista am 11. April 2017 wird Windows-Benutzern wieder ein-

mal bewusst gemacht, dass auch Microsoft-Systeme nicht für alle

Zeiten sicher sein werden. So hat Microsoft zwar bereits im März

auf die Veröffentlichung der letzten ShadowBrokers-Dokumente

reagiert, gegen drei der beschriebenen Exploits (namentlich

„EnglishmanDentist“, „EsteemAudit“ und „ExplodingCan“) wird

aber auch in Zukunft kein Sicherheitsupdate veröffentlicht. Die-

se Exploits betreffen laut Microsoft nur veraltete Software, Win-

dows XP und Vista dürften darunter fallen. Ähnlich verfährt der

Softwarehersteller auch mit einer aktiv ausgenutzten Schwach-

stelle (CVE-2017-7269) im immer noch sehr verbreiteten Webser-

ver Microsoft Internet Information Services (IIS) 6.0. Aktuelle Si-

cherheitsrichtlinien bezüglich Software-Updates sollten daher

immer auch möglicherweise notwendige Software-Upgrades auf

länger unterstützte Produkte berücksichtigen, auch wenn das

finanziell schmerzhaft sein kann.

Quellen: https://blogs.technet.microsoft.com/msrc/2017/04/14/

protecting-customers-and-evaluating-risk/, https://threatpost.

com/publicly-attacked-microsoft-iis-zero-day-unlikely-to-be-

patched/124641/ M

ʜοϺ0ɡ арһɩѕϲһëS Р h іSh i nɡ üßê μΝІϹοĐē-Ď0МÁ i NS

Punycode (RFC 3492) bietet die Möglichkeit, Unicode-Zeichen

mit dem für Internet-Hostnamen verwendeten ASCII-Datensatz

zu beschreiben. So wird aus „böse.de“ beispielsweise „xn--bse-

sna.de“, es wird also die Möglichkeit für Sonderzeichendomains

geschaffen (Internationalized Domain Names, IDN). Einige

Browser rendern Unicode-Zeichen in der Adresszeile, so dass

beispielsweise für den Zugang zur Domain „xn--80ak6aa92e.

com“ auch „appIe.com“ (mit „I“ statt „ l “) verwendet werden

kann. Diese einfache Möglichkeit für Phishing-Angriffe (Homo-

graphischer Angriff) wurde von Google im letzten Release des

Browsers Chrome für „non-IDN Domains“ behoben. Die Entwick-

ler von Firefox haben noch keine allgemeine Lösung für das

Problem gefunden und stellen aktuell den eigens verwendeten

IDN-Algorithmus zur Diskussion. Quellen: https://www.ietf.org/

rfc/rfc3492.txt, https://www.xudongz.com/blog/2017/idn-

phishing/, https://wiki.mozilla.org/IDN_Display_Algorithm M

DFN-PKI unterstützt Certification Authority

Authorization (CAA)

Seit Anfang 2013 gibt es den RFC 6844 „Certification Authority

Authorization“ (CAA). CAA spezifiziert einen gleichnamigen Re-

source Record zur Ablage im DNS, mit dem ein Domain-Inha-

ber festlegen kann, welche Zertifizierungsstelle (CA) für seine

Domain Zertifikate ausgeben darf. Das CA/Browser-Forum ver-

pflichtet zukünftig jede CA, ab spätestens September 2017 die-

se CAA Resource Records auszuwerten und zu beachten. In der

DFN-PKI wird dieser Mechanismus zum Sommer 2017 unterstützt

werden. Weitere Informationen zur Einrichtung von CAA für Ih-

re Domains finden Sie unter https://blog.pki.dfn.de/2017/03/rfc-

6844-certification-authority-authorization-caa/ M

SHA-1 Kollisionen und deren Bedeutung für die

DFN-PKI

Wissenschaftler vom CWI Amsterdam und von Google haben ei-

ne Forschungsarbeit veröffentlicht, in der praktisch vorgeführt

wird, wie Kollisionen für den Hashalgorithmus SHA-1 berech-

net werden können. Dabei ist es gelungen, zwei PDF-Dokumen-

te so zu konstruieren, dass sie denselben Hashwert besitzen.

Die Auswirkungen für die DFN-PKI sind nach unserer Einschät-

zung gering, denn noch ist niemand in der Lage, sogenannte

Pre-Image-Angriffe durchzuführen. Dies bedeutet, dass es noch

nicht möglich ist, zu einem bestehenden alten Zertifikat ein zwei-

tes, „Gefälschtes“ mit identischer Signatur, aber anderen Da-

ten zu berechnen. Daraus folgt: Der neue Angriff ändert noch

nichts an der Sicherheit von bestehenden Zertifikaten der DFN-

PKI, selbst wenn sie mit SHA-1 signiert sein sollten. Weitere In-

formationen finden Sie unter https://blog.pki.dfn.de/2017/02/

sha-1-kollisionen-und-deren-bedeutung-fuer-die-dfn-pki/ M

Wenn Sie Fragen oder Kommentare zum Thema

„Sicherheit im DFN“ haben, schicken Sie bitte eine

E-Mail an [email protected].

KONTAKT

https://blogs.technet.microsoft.com/msrc/2017/04/14/protecting-customers-and-evaluating-risk/

https://blogs.technet.microsoft.com/msrc/2017/04/14/protecting-customers-and-evaluating-risk/

https://www.ietf.org/

https://www.xudongz.com/blog/2017/idn-phishing/

https://www.xudongz.com/blog/2017/idn-phishing/

https://wiki.mozilla.org/IDN_Display_Algorithm

https://blog.pki.dfn.de/2017/03/rfc-6844-certification-authority-authorization-caa/

https://blog.pki.dfn.de/2017/03/rfc-6844-certification-authority-authorization-caa/

https://blog.pki.dfn.de/2017/02/


https://blog.pki.dfn.de/2017/02/

https://threatpost.com/publicly-attacked-microsoft-iis-zero-day-unlikely-to-be-patched/124641/



58 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | RECHT

Wo ein Wille ist, darf auch ein Link seinOLG München zur Beweislast für das Vorliegen einer Rechtsverletzung beim Framing

Text: Florian Klein (Forschungsstelle Recht im DFN)

In letzter Zeit sind immer wieder Gerichtsentscheidungen zur Haftung für das Verlinken urheber-

rechtlich geschützter Inhalte ergangen. Darin wurden solche Verlinkungen unter bestimmten

Umständen als Rechtsverletzungen eingestuft, für die der Linksetzer zur Verantwortung gezogen

werden kann. In der Praxis ist es dabei von großer Bedeutung, wer vor Gericht wofür die Beweislast

trägt. Das Oberlandesgericht (OLG) München hat nun in diesem Zusammenhang mit Urteil

vom 25.08.2016 (Az. 6 U 1092/11) klargestellt, dass die fehlende Zustimmung zur Veröffentlichung

des verlinkten Werkes vom Rechteinhaber zu beweisen ist, der den Linksetzer wegen einer

Rechts verletzung in Anspruch nimmt.

Foto © czekma13 / iStockphoto

59RECHT | DFN Mitteilungen Ausgabe 91 |

I. Aktuelle Rechtsprechung zur

Linkhaftung

Der Einsatz von Links ist ein unverzicht-

barer Bestandteil für die schnelle und ef-

fektive Nutzung des Internets. Eine Unter-

art der Linksetzung ist das Framing, bei

dem der verlinkte Inhalt in einem speziel-

len Rahmen („Frame“) auf der verlinken-

den Webseite eingebunden wird, sodass

für den Internetnutzer der Eindruck ent-

steht, der Inhalt befinde sich auf der ver-

linkenden Webseite. Besonders beliebt ist

dieses Vorgehen zur Einbettung fremder

Bilder und Videos. Aus rechtlicher Sicht

können mit dem Setzen von Links jedoch

Probleme verbunden sein, wenn auf rechts-

verletzende Inhalte verlinkt wird, da sich

dann die Frage stellt, inwiefern der Links-

etzer für diese Rechtsverletzungen haftet,

die ursprünglich von den Betreibern der

verlinkten Seiten begangen wurden.

Jedenfalls aus urheberrechtlicher Sicht

schien seit dem „Paperboy“-Urteil des Bun-

desgerichtshofs (BGH) im Jahr 2003 (Urt. v.

17.07.2003, Az. I ZR 259/00) geklärt zu sein,

dass das bloße Setzen eines Links weder ei-

ne Vervielfältigung noch eine sogenannte

öffentliche Zugänglichmachung darstellt

und deshalb unbedenklich ist. Davon kann

in letzter Zeit jedoch nicht mehr allgemein

ausgegangen werden. Im Oktober 2014 ent-

schied der Europäische Gerichtshof (Eu-

GH) im Hinblick auf das Framing öffentlich

zugänglicher Drittinhalte, dass darin kei-

ne erlaubnispflichtige öffentliche Wieder-

gabe liege, soweit das betreffende Werk

weder für ein neues Publikum noch nach

einem speziellen technischen Verfahren

wiedergegeben wird, das sich von dem-

jenigen der ursprünglichen Wiedergabe

unterscheidet (siehe dazu Hinrichsen, „Al-

les bleibt im Rahmen!“, in: DFN-Infobrief

Recht 12/2014). Daraufhin konkretisier-

te der BGH diese Vorgabe dahingehend,

dass eine Wiedergabe für ein neues Publi-

kum insbesondere dann gegeben sein soll,

wenn die ursprüngliche Veröffentlichung

des Werkes ohne Erlaubnis des Rechtein-

habers erfolgte (Urt. v. 09.07.2015, Az. I ZR

46/12). Dies betrifft insbesondere die Fälle,

in denen jemand eigenmächtig und rechts-

widrig ein fremdes Werk im Internet hoch-

geladen hat. Ein „neues Publikum“ zeichne

sich nämlich gerade dadurch aus, dass es

sich um ein Publikum handelt, an das der

Urheberrechtsinhaber nicht dachte, als er

die ursprüngliche öffentliche Wiedergabe

erlaubte. Fehlt es aber von vornherein an

einer Erlaubnis für die ursprüngliche Ver-

öffentlichung, erfolgt die Wiedergabe im

Internet stets gegenüber einem neuen Pu-

blikum. Eine solche öffentliche Wiederga-

be bedarf – vorbehaltlich besonderer ge-

setzlicher Ausnahmen – der Erlaubnis des

Rechteinhabers. Aus diesem Grund kann

das Verlinken auf rechtswidrig veröffent-

lichte, urheberrechtlich geschützte Inhal-

te eine Rechtsverletzung darstellen, für

die der Linksetzer haften muss. Über das

Framing hinaus hat der EuGH dies mittler-

weile auch ausdrücklich für einfache Links

entschieden. Einschränkend verlangt er je-

doch, dass der Linksetzer weiß oder wis-

sen muss, dass die Veröffentlichung des

verlinkten Werkes auf der Ursprungsseite

im Internet ohne Erlaubnis des Rechtsin-

habers erfolgte. Nur wenn der Linksetzer

mit Gewinnerzielungsabsicht handelt, be-

steht eine besondere Prüfungspflicht des

Linksetzers im Hinblick auf die Rechtmä-

ßigkeit der verlinkten Inhalte, was zusätz-

lich eine Vermutung für seine Kenntnis ei-

ner etwaigen Rechtswidrigkeit begründet

(siehe hierzu ausführlich Strobel, „Links,

Links, Links und immer noch nicht der rech-

te Weg?“ in: DFN-Infobrief Recht 11/2016).

Eine erste Umsetzung dieser Vorgaben des

EuGH hat kürzlich schon das LG Hamburg

vorgenommen (Beschl. v. 18.11.2016, Az.

310 O 402/16, siehe dazu Sydow, „Ereig-

nisreicher Jahresabschluss im Urheber-

recht“, in: DFN-Infobrief Recht 1/2017).

Die Quintessenz dieser überwiegend höchst-

richterlichen Entscheidungen ist, dass Link-

setzer sowohl beim Framing als auch bei der

einfachen Verlinkung eine urheberrecht-

liche Haftung befürchten müssen, wenn

auf Inhalte verlinkt wird, die rechtswidrig

zugänglich gemacht worden sind.

II. Die Entscheidung des

Gerichts

Die hier zu erörternde Entscheidung fällt

zeitlich zwischen die letztgenannte Ent-

scheidung des EuGH und die des BGH und

beschäftigt sich mit der Haftung für die

Linksetzung durch Framing.

1. Sachverhalt

Ausgangspunkt des Verfahrens vor dem

OLG München war, dass der Beklagte im

Sommer 2010 das bei YouTube im Febru-

ar 2010 veröffentliche Video „Die Realität“

zum Thema Wasserverschmutzung per Fra-

ming in seine Internetpräsenz eingebun-

den hatte. Inhaber der Rechte an diesem

Video war der Kläger. Dieser behauptete,

dass das Video ohne sein Zutun bei You-

Tube von dem – vom Kläger mit der Her-

stellung beauftragten – Produzenten des

Videos veröffentlicht wurde, der jedoch

nicht mehr über die nötigen Rechte dafür

verfügte, nachdem er diese an den Kläger

übertragen hatte. Somit sah der Kläger in

der Verlinkung des Videos eine Urheber-

rechtsverletzung und machte deshalb ge-

genüber dem Beklagten einen Anspruch

auf Schadensersatz und Erstattung der Ab-

mahnkosten geltend.

2. Urteil

Im Ergebnis lehnen die Richter sämtliche An-

sprüche des Klägers ab, weil sie eine Rechts-

verletzung als nicht bewiesen erachten. In

Anlehnung an die Vorgaben des BGH stellt

das OLG München noch einmal fest, dass

eine Rechtsverletzung (in Form einer Ver-

letzung eines sogenannten „unbenannten

Rechts der öffentlichen Wiedergabe eines

Werks in unkörperlicher Form“) voraus-

setzt, dass die Wiedergabe gegenüber ei-

ner neuen Öffentlichkeit, das heißt einer

unbestimmten Zahl potenzieller Adressaten

und „recht vielen Personen“, erfolgt. Dies

sei erfüllt, wenn der Link auf ein im Internet

ohne Zustimmung des Berechtigten einge-

stelltes Werk führt. Denn entscheidend ist

dabei, dass das Publikum, welches durch die

Verlinkung mittels Framings adressiert wird

und welches identisch mit dem Publikum ist,


welchem durch das erstmalige (rechtswidri-

ge) Veröffentlichen im Internet ein Zugang

eröffnet wurde, von vornherein nicht von der

Willensbildung des Berechtigten erfasst ist.

Somit kommt es maßgeblich darauf an, ob

die ursprüngliche Veröffentlichung des Vi-

deos auf YouTube ohne Zustimmung des

Rechteinhabers erfolgte. Da im Zivilpro-

zess grundsätzlich der Kläger die Tatsachen

darlegen und beweisen muss, die seinen

Anspruch begründen, geht das OLG Mün-

chen davon aus, dass das Fehlen der Zu-

stimmung von dem Kläger und nicht etwa

von dem Beklagten zu beweisen ist. Aus

juristischer Sicht wird hierbei unterschie-

den zwischen der Tatbestandsebene und

der Rechtfertigungsebene. Tatsachen, die

auf der Rechtfertigungsebene relevant wer-

den, sind in der Regel von dem Beklagten

zu beweisen, solche auf Tatbestandsebe-

ne vom Kläger. Die Zustimmung zur Veröf-

fentlichung soll in dieser Konstellation der

Haftung für Links auf fremde Inhalte jedoch

nicht erst die Rechtswidrigkeit dieser Hand-

lung beseitigen, sondern schon den Tatbe-

stand ausschließen. Die fehlende Zustim-

mung ist deshalb ein den Tatbestand be-

gründendes Merkmal und muss vom Kläger

bewiesen werden. Ein Sonderfall einer Be-

weislastumkehr oder einer Beweiserleich-

terung liege ebenfalls nicht vor.

Im konkreten Fall gelang es dem Kläger je-

doch nicht zu beweisen, dass er der erstma-

ligen Veröffentlichung des Videos „Die Rea-

lität“ auf YouTube nicht zugestimmt hatte.

Der Kläger habe zu keinem Zeitpunkt – auch

nicht nach Erlangung der Kenntnis von der

Veröffentlichung – seinen entgegenstehen-

den Willen dokumentiert, was zum Beispiel

durch ein Löschungsverlangen gegenüber

dem Produzenten hätte geschehen können,

der den Upload bei YouTube vorgenommen

hatte. Dazu kam, dass der Kläger das streit-

gegenständliche Video schon im Frühjahr

2010 selbst per Videoframe auf seiner Web-

seite eingebunden hatte und diese Verlin-

kung auch im Jahr 2016 noch Bestand hatte.

Diese Umstände stellten sich als gewichtige

Indizien dafür dar, dass eine Zustimmung

des Klägers für die Veröffentlichung des Vi-

deos auf YouTube vorlag. Umstände, die die-

se Einschätzung widerlegen könnten, konn-

te der Kläger nicht darlegen. Mithin ging das

Gericht davon aus, dass der nötige Beweis

für das Fehlen der Zustimmung nicht er-

bracht war, sodass das Video durch die fra-

mende Verlinkung durch den Beklagten kei-

nem neuen Publikum zugänglich gemacht

wurde. Dies bedeutete wiederum, dass es an

einer erlaubnispflichtigen Wiedergabehand-

lung fehlte und keine Rechtsverletzung vor-

lag, die Voraussetzung für einen Schaden s-

ersatzanspruch gewesen wäre.

III. Fazit und Konsequenzen für

die Hochschulpraxis

Das Urteil des OLG München zeigt, dass der

Themenbereich Linkhaftung in Bewegung ist.

Gerade aus urheberrechtlicher Sicht drohen

Linksetzern neue Risiken. Wer auf Inhalte ver-

linkt, die urheberrechtswidrig, also insbeson-

dere ohne Zustimmung des Rechteinhabers,

veröffentlicht worden sind, kann schnell in

die Haftungsfalle tappen. Eine gewisse Ein-

schränkung ergibt sich durch die Kriterien

des EuGH, der bei Akteuren ohne Gewinner-

zielungsabsicht verlangt, dass diese wuss-

ten oder zumindest wissen mussten, dass die

ursprüngliche Veröffentlichung rechtswid-

rig gewesen ist. Dennoch ist auch für Hoch-

schulen Vorsicht angezeigt, wenn auf Inhal-

te verlinkt werden soll, die Urheberrechts-

schutz genießen. Es gibt gute Gründe, bei

Hochschulen nicht von einem Handeln mit

Gewinnerzielungsabsicht auszugehen und

deshalb keine gesteigerten Prüfungspflich-

ten anzunehmen, gesichert ist dies jedoch

bisher nicht. Bestehen Zweifel an der Recht-

mäßigkeit der Inhalte, sollte von einer Verlin-

kung möglichst Abstand genommen werden.

Immerhin ist aber durch das Verdikt aus

München klargestellt, dass die Beweislast

für die Rechtswidrigkeit der Veröffentli-

chung des verlinkten Inhalts bei dem Rechte-

inhaber liegt, der Ansprüche geltend ma-

chen will. Davon erfasst ist insbesondere

das Fehlen einer Zustimmung zur Veröffent-

lichung. Allerdings muss man sich bewusst

machen, dass dem Urteil eine besondere

Konstellation zugrunde lag, in der einige

Anhaltspunkte dafür bestanden, dass ei-

ne Zustimmung zur Veröffentlichung des

Videos erteilt worden war, was die Darle-

gungslast für das Fehlen einer Zustimmung

deutlich erhöhte. Dem OLG München ist hier

beizupflichten, dass eine Einbindung des be-

anstandeten Videos auf der eigenen Web-

seite durch den Rechteinhaber durchaus

ein starkes Indiz dafür ist, dass die Veröf-

fentlichung nicht ohne sein Einverständ-

nis erfolgt ist. Solche Fälle werden tenden-

ziell aber eher die Ausnahme bilden, wenn

geschützte Inhalte von Dritten veröffent-

licht werden. Dennoch lässt sich dem Ur-

teil entnehmen, dass Rechteinhaber gehal-

ten sind, Rechtsverletzungen direkt beim

jeweiligen Webseitenbetreiber zu beanstan-

den und dies zu dokumentieren, wenn ein

Vorgehen gegen Linksetzer erwünscht ist.

Ein solches Vorgehen gegen den tatnähe-

ren Akteur wird häufig auch interessenge-

recht sein, da eine Rechtsverletzung besser

abgestellt werden kann, wenn sie direkt an

der Wurzel bekämpft wird. Das Löschen der

rechtswidrigen Inhalte beim Content-Anbie-

ter führt zugleich dazu, dass Links fortan ins

Leere gehen und keine weitere Verbreitung

der geschützten Inhalte bewirken können.

Das Fehlen eines solchen Vorgehens kön-

nen Hochschulen somit vorbringen, wenn

sie wegen einer Linksetzung in Anspruch ge-

nommen werden sollen. Je nach Einzelfall

werden aber noch weitere Umstände dazu

kommen müssen, um von einer Erlaubnis

des Rechteinhabers ausgehen zu können.

Da Hochschulen sich zudem auch in der Po-

sition der Rechteinhaber befinden können,

sollten sie entsprechende Löschungsverlan-

gen an die jeweiligen Webseitenbetreiber

richten, wenn nachfolgend eine Rechtsver-

folgung gegen Linksetzer beabsichtigt ist.

Dennoch sollte man sich stets auch die Fra-

ge stellen, ob ein Vorgehen gegen Linksetzer

neben der Inanspruchnahme der Content-

Provider sinnvoll und den Aufwand wert

ist, da angesichts der vielen zu berücksich-

tigenden Umstände durchaus Prozessrisiken

bestehen. M


Meldung machen!Neue Melde- und Benachrichtigungspflichten nach der Datenschutz-Grundverordnung

Text: Lennart Sydow (Forschungsstelle Recht im DFN)

Durch die Verabschiedung der Datenschutz-Grundverordnung (DS-GVO) kommen auf datenverar-

beitende Stellen neue und geänderte Verpflichtungen zu, die diese ab Mai 2018 einhalten müssen.

Dazu gehören auch weitgehende Melde- und Benachrichtigungspflichten. Datenverarbeitende

Stellen müssen dafür die erforderlichen Vorkehrungen treffen und neue Abläufe vorsehen.

I. Besondere Pflichten bei Datenschutz verletzungen

Die DS-GVO bringt zahlreiche Neuerungen und Änderungen der

Pflichten der verantwortlichen Stellen im Hinblick auf Datenver-

arbeitungsvorgänge mit sich (siehe dazu auch Sydow, Neues Daten-

schutzrecht = neue Sicherheit für Daten? Die erforderlichen Maß-

nahmen datenverarbeitender Stellen nach der DS-GVO, DFN-Infob-

rief Recht 09/2016, S. 6 ff.). Während insgesamt noch nicht eindeu-

tig beurteilt werden kann, ob die neu formulierten Vorschriften in

der praktischen Anwendung erheblich von der bisherigen Rechts-

lage abweichen werden, sind für den Bereich der Melde- und

Foto

© t

un

aly

/ iSt

ock

ph

oto


Benachrichtigungspflichten bereits jetzt erhebliche Änderun-

gen zu erkennen.

Die DS-GVO sieht im Fall von Datenschutzverletzungen vor, dass

diese zum einen an die zuständige Aufsichtsbehörde zu melden

sind (Art. 33 DS-GVO) und zum anderen gegebenenfalls auch die

Betroffenen benachrichtigt werden müssen (Art. 34 DS-GVO). Ei-

ne Verletzung des Schutzes personenbezogener Daten, die die

genannten Verpflichtungen auslöst, ist nach Art. 4 Nr. 12 DS-GVO

„eine Verletzung der Sicherheit, die zur Vernichtung, zum Verlust

oder zur Veränderung, ob unbeabsichtigt oder unrechtmäßig,

oder zur unbefugten Offenlegung von beziehungsweise zum un-

befugten Zugang zu personenbezogenen Daten führt, die über-

mittelt, gespeichert oder auf sonstige Weise verarbeitet wur-

den“. In all diesen Fällen des Verlusts der Kontrolle über Zugang

und Verwendung personenbezogener Daten greifen die Melde-

und Benachrichtigungspflichten der datenverarbeitenden Stel-

le ein. Dabei ist es unbeachtlich, ob die Datenpanne durch Drit-

te veranlasst (wie z. B. bei einem Hacking-Angriff) oder intern

verursacht wurde.

Bereits nach bisher geltendem Recht in Deutschland existiert mit

§ 42a BDSG eine Meldepflicht bei Datenschutzverstößen. Diese

besteht aber zum einen nur für Fälle, in denen besonders sen-

sible Daten der aufgeführten Kategorien betroffen sind, und gilt

zudem nur für nichtöffentliche Stellen. Öffentliche Stellen un-

terliegen der genannten Regelung nur ausnahmsweise, soweit

sie als Unternehmen am Wettbewerb teilnehmen. Öffentliche

Einrichtungen und Behörden (wie z. B. auch Hochschulen) wa-

ren damit von dieser Verpflichtung bisher nicht betroffen. Dies

ändert sich mit Geltungsbeginn der DS-GVO, die diesbezüglich

keine Unterscheidung macht und auch für datenverarbeitende

öffentliche Stellen solche Verpflichtungen einführt.

Da die Aufsichtsbehörden die Möglichkeit haben, bei Verstößen

gegen diese Vorschriften gemäß Art. 83 Abs. 4 DS-GVO Geldbu-

ßen bis zu 10 000 000 Euro gegen die verantwortliche Stelle zu

verhängen, ist die Einhaltung dieser Informationspflichten für

datenverarbeitende Stellen von hoher Bedeutung.

II. Meldung an die Aufsichtsbehörden nach Art. 33 DS-GVO

Kommt es nach Geltungsbeginn der DS-GVO zu einer der genann-

ten Verletzungen des Datenschutzes, ist die datenverarbeitende

Stelle nach Art. 33 DS-GVO verpflichtet, die zuständige Aufsichts-

behörde darüber zu informieren. Dies kann lediglich unterblei-

ben, wenn die Verletzung voraussichtlich „nicht zu einem Risiko

für die Rechte und Freiheiten natürlicher Personen führt.“ Wann

dies der Fall ist, ist nicht genauer erläutert. Ansonsten hat die

Meldung unverzüglich und möglichst innerhalb von 72 Stunden

zu erfolgen. Eventuelle Verzögerungen sind gegenüber der Auf-

sichtsbehörde zu begründen. Ob die Verletzung „unverzüglich“

gemeldet wurde, ist von den Umständen des Einzelfalls abhän-

gig, wobei insbesondere die Art und die Schwere der Verletzung

und die möglichen Folgen zu berücksichtigen sind, wie sich aus

Erwägungsgrund 87 zur DS-GVO ergibt.

Die Meldung an die Aufsichtsbehörden muss gemäß Art. 33 Abs.

3 DS-GVO zumindest eine Beschreibung der entstandenen Verlet-

zung, deren wahrscheinliche Folgen und die vorgesehenen Ge-

genmaßnahmen und soweit wie möglich auch genauere Angaben

über Kategorie und Anzahl der betroffenen Daten und Personen

beinhalten. Werden Daten im Auftrag verarbeitet oder Auftrags-

datenverarbeiter eingesetzt, so ist zudem der Auftragsverarbei-

ter im Falle von Datenschutzverletzungen dazu verpflichtet, die-

se unverzüglich an den Verantwortlichen zu melden.

Diese Meldepflicht wird von einer Dokumentationspflicht be-

züglich aller Datenschutzverletzungen und damit verbundenen

Fakten, Auswirkungen und Abhilfemaßnahmen begleitet (Art. 33

Abs. 5 DS-GVO).

III. Benachrichtigung der Betroffenen nach

Art. 34 DS-GVO

Wenn eine Datenschutzverletzung voraussichtlich ein „hohes

Risiko für die persönlichen Rechte und Freiheiten“ der betrof-

fenen Person mit sich bringt, ist die verantwortliche Stelle ge-

mäß Art. 34 Abs. 1 DS-GVO auch dazu verpflichtet, die betroffe-

nen Personen unverzüglich zu benachrichtigen. Für diese Ver-

pflichtung besteht also eine höhere Hürde als für die Meldung

an die Aufsichtsbehörden.

Diese Schwelle in Form eines hohen Risikos für die persönlichen

Rechte und Freiheiten der betroffenen Personen führt zu einem

zweistufigen Modell der Informationsverpflichtungen bei Daten-

schutzverletzungen, bei dem die Meldung an die Aufsichtsbe-

hörde den (nur ausnahmsweise entfallenden) Regelfall darstellt

und die Benachrichtigung der Betroffenen nur in Situationen er-

forderlich ist, in denen diese Risikoschwelle überschritten wird.

Ergänzt wird dieses System durch die Möglichkeit der Aufsichts-

behörde, vom Verantwortlichen zu verlangen, eine Benachrich-

tigung vorzunehmen, wenn aus ihrer Sicht ein solches „hohes

Risiko“ besteht und die verantwortliche Stelle zwar eine Verlet-

zung gemeldet, bisher aber die Betroffenen nicht benachrichtigt

hat. Die Einschätzung der Aufsichtsbehörde dürfte daher in vie-

len Fällen den datenverarbeitenden Stellen die Beurteilung der

Situationen erleichtern, wenn auch nicht gänzlich abnehmen.


Dass die Benachrichtigung der Betroffenen deutlich seltener er-

forderlich ist als die Meldung an die Aufsichtsbehörden wird zu-

dem noch durch die Rückausnahmen des Art. 34 Abs. 3 DS-GVO

verstärkt. Danach ist eine Benachrichtigung ausdrücklich nicht

erforderlich, wenn geeignete Sicherheitsvorkehrungen getrof-

fen wurden, durch welche die Daten für unbefugte Personen un-

zugänglich gemacht wurden (z. B. durch geeignete Verschlüsse-

lung) oder durch andere Maßnahmen sichergestellt ist, dass das

hohe Risiko für die Rechte und Freiheiten der betroffenen Per-

sonen nicht mehr besteht.

Die Verpflichtung zur Individualbenachrichtigung kann zudem

auch dann entfallen, wenn der Aufwand dafür unverhältnismä-

ßig hoch wäre (z. B. aufgrund einer besonders hohen Anzahl be-

troffener Personen). Anstelle der Benachrichtigung kann dann

„eine öffentliche Bekanntmachung oder ähnliche Maßnahme“

gewählt werden, wenn diese vergleichbar wirksam ist.

Soweit die Benachrichtigung nach diesen Grundsätzen erforder-

lich ist, muss sie ebenfalls zumindest eine Beschreibung der ent-

standenen Verletzung, deren wahrscheinliche Folgen und die Be-

nennung vorgesehener Gegenmaßnahmen enthalten. Wichtig

ist dabei, dass die Benachrichtigung in (für den Betroffenen) kla-

rer und einfacher Sprache die Art der Verletzung erklären muss.

IV. Fazit und Auswirkungen für Hochschulen

und Forschungseinrichtungen

Für Hochschulen und Forschungseinrichtungen als öffentliche

datenverarbeitende Stellen werden mit Geltungsbeginn der DS-

GVO Melde- und Benachrichtigungspflichten bestehen, die nach

bisher geltender Rechtslage nicht existierten. Die jeweiligen Stel-

len müssen sich daher gänzlich neu auf diese Informationspflich-

ten einstellen und ihre Vorgehensweise bezüglich der Erkennung

von Datenschutzverletzungen und des gegebenenfalls erforder-

lichen Tätigwerdens anpassen. Die zuständigen Mitarbeiter müs-

sen erkennen, wann eine Verletzung des Datenschutzes im Sinne

der DS-GVO vorliegt, wobei im Zweifelsfall eine Meldung an die

Aufsichtsbehörde erfolgen sollte. Zudem müssen die zuständi-

gen Mitarbeiter Kenntnis davon haben, welche Informationen

zu übermitteln sind und auf diese auch zugreifen können. Auch

die Dokumentation der Datenschutzverletzungen und der Ab-

hilfemaßnahmen muss geregelt werden. Der reibungslose Ab-

lauf des Vorgehens im Falle einer Datenschutzverletzung muss

sichergestellt werden, insbesondere im Hinblick auf die Frist

von 72 Stunden, innerhalb derer eine Meldung zu ergehen hat.

Es ist daher zu empfehlen, schon vor Geltungsbeginn der DS-GVO

ein Konzept für die Einführung der erforderlichen Abläufe mit

dem Datenschutzbeauftragten der jeweiligen Institution und

den Mitarbeitern der betroffenen Bereiche zu erstellen. Soweit

dies möglich ist, sollten auch Datensicherheitsmaßnahmen er-

griffen werden, die das Risiko für die von der Verarbeitung be-

troffenen Personen mindern (wie z. B. die Verschlüsselung von

Daten). Hierdurch könnte eine Benachrichtigungspflicht im Ein-

zelfall entfallen.

Eine gewisse Unsicherheit verbleibt bei der Einschätzung, wann

eine Meldung an die Aufsichtsbehörden unterbleiben kann, da

kein Risiko für natürliche Personen besteht. Aufgrund der erheb-

lichen Sanktionsandrohung sollte aber in Zweifelsfällen immer

zumindest die Aufsichtsbehörde informiert werden. M

Sydow, Vereinheitlichung des EU-Datenschutzrechts?,

Die Datenschutz-Grundverordnung als anwendbares

Recht für die DFN-Mitglieder, DFN-Infobrief Recht

05/2016, S. 2 ff.

Leinemann, Alles neu macht der Mai!?, Grundsätze für

die Verarbeitung personenbezogener Daten nach der

Datenschutz-Grundverordnung, DFN-Infobrief Recht

06/2016, S. 8 ff.

Leinemann, Vergiss mein nicht..., Das Recht auf Lö-

schung gemäß Art. 17 Datenschutz-Grundverordnung,

DFN-Infobrief Recht 08/2016, S. 2 ff.

Sydow, Neues Datenschutzrecht = neue Sicherheit

für Daten?, Die erforderlichen Maßnahmen datenver-

arbeitender Stellen nach der DS-GVO, DFN-Infobrief

Recht 09/2016, S. 6 ff.

Leinemann, Etwas Altes, etwas Neues…, Die Rechte

der Betroffenen nach der Datenschutz-Grundverord-

nung, DFN-Infobrief-Recht 10/2016, S. 11 ff.

Leinemann, Kommt Zeit, kommt Rat, Kurzmitteilung

zum Stand der gegenwärtigen Entwicklungen im Hin-

blick auf die neue EU-Datenschutz-Grundverordnung,

DFN-Infobrief Recht 02/2017, S.7ff

Weiterführende Hinweise zur Daten-schutz-Grundverordnung

64 | DFN Mitteilungen Ausgabe 91 | Mai 2017 | DFN-VEREIN

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.

Übersicht über die Mitgliedseinrichtungen und Organe des DFN-Vereins (Stand: 05/2017)

65DFN-VEREIN | DFN Mitteilungen Ausgabe 91 |

Die Organe des DFN-Vereins sind:

die Mitgliederversammlung

der Verwaltungsrat

der Vorstand

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 11. 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. Ulrike Gutheil

(Ministerium für Wissenschaft, Forschung und Kultur, Brandenburg)

Dir. u. Prof. Dr. Siegfried Hackel

(Physikalisch-Technische Bundesanstalt Braunschweig)

Dr.-Ing. habil. Carlos Härtel

(GE Global Research)

Prof. Dr.-Ing. Ulrich Lang

(Universität zu Köln)

Prof. Dr. Joachim Mnich

(Deutsches Elektronen-Synchrotron Hamburg)

Prof. Dr. Peter Schirmbacher

(Humboldt-Universität zu Berlin)

Prof. Dr. Horst Stenzel

(Technische Hochschule Köln)

Prof. Dr.-Ing. Ramin Yahyapour

(Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen)

Dr. Harald Ziegler

(Friedrich-Schiller-Universität Jena)

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:

Martin Wimmer

(Universität Regensburg)

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. Ulrike Gutheil

Stellv. Vorsitzende

Dr. Rainer Bockholt

Stellv. Vorsitzender

Der Vorstand wird beraten von einem Technologie-Ausschuss (TA),

einem Betriebsausschuss (BA) und einem Ausschuss für Recht

und Sicherheit (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.


Aachen Fachhochschule Aachen

Rheinisch-Westfälische Technische Hochschule Aachen (RWTH)

Aalen Hochschule Aalen

Albstadt Hochschule Albstadt-Sigmaringen (FH)

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

BBB Management GmbH

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

Deutsche Telekom AG Laboratories

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)

T-Systems International GmbH

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 Fachhochschule Rheinland-Westfalen-Lippe

Hochschule Bochum

Hochschule für Gesundheit

Ruhr-Universität Bochum

Technische Hochschule Georg Agricola für Rohstoff,

Energie und Umwelt zu Bochum

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)

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 Clausthaler Umwelttechnik-Institut GmbH (CUTEC)

Technische Universität Clausthal-Zellerfeld

Coburg Hochschule für angewandte Wissenschaften, Fachhochschule Coburg

Cottbus Brandenburgische Technische Universität Cottbus-Senftenberg

Darmstadt European Space Agency (ESA)

Evangelische Hochschule Darmstadt

GSI Helmholtzzentrum für Schwerionenforschung GmbH

Hochschule Darmstadt

Merck KGaA

Technische Universität Darmstadt

T-Systems International GmbH

Deggendorf Hochschule für angewandte Wissenschaften,

Fachhochschule Deggendorf

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

67DFN-VEREIN | DFN Mitteilungen Ausgabe 91 |

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-Harburg

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 und Universitätsbibliothek

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

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

Fachinformationszentrum Karlsruhe (FIZ)

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 Fachhochschule 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 Philosophie München

Hochschule München (FH)

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 Stiftungsfachhochschule 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, Fachhochschule

Oldenburg Carl von Ossietzky Universität Oldenburg

Landesbibliothek Oldenburg

Osnabrück Hochschule Osnabrück (FH)

Universität Osnabrück

Paderborn Fachhochschule der Wirtschaft Paderborn

Universität Paderborn

Passau Universität Passau

Peine Deutsche Gesellschaft zum Bau und Betrieb von Endlagern

für Abfallstoffe mbH

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

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

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

Mehr Raum für die Wissenschaft - dfn.de · Bei hochvolumigen Amplification-Angriffen auf...

Documents

Transcript of Mehr Raum für die Wissenschaft - dfn.de · Bei hochvolumigen Amplification-Angriffen auf...