Open Source

Kriterien für sichere und nachhaltige Software

Open Source
Am besten könnt ihr bei quelloffener Software überprüfen, wie sicher eure Daten vor unberechtigten Zugriffen sind.
Virtual Private Network
Meist ist dies die Basis für den Zugriff auf ein Firmennetzwerk von außen. Vertraut jedoch nicht blindlings den oft falschen Versprechungen von VPN-Anbietern sondern nutzt quelloffene Programme wie OpenVPN oder WireGuard.
Fernwartungssoftware
Mit Remotely gibt es eine gute OpenSource-Alternative zu TeamViewer oder AnyDesk.
Konfiguration

Kontrolliert auch bei Open-Source-Software, ob die Standard-Einstellungen wirklich datenschutzfreundlich sind:

So erstellt zum Beispiel Jitsi Meet externe Verbindungen zu gravatar.com und protokolliert mit dem Logging-Level INFO viel zu viele Informationen. Frühere Jitsi-Apps banden auch die Tracker Google CrashLytics, Google Firebase Analytics und Amplitude ein. Betreibt, wenn möglich, eigene STUN-Server, sonst wird meet-jit-si-turnrelay.jitsi.net verwendet.

Verschlüsselungsmethoden

Hier solltet ihr unterscheiden zwischen der Transportverschlüsselung – idealerweise Ende-zu-Ende – und der Verschlüsselung von gespeicherten Daten.

Die Synchronisierungssoftware Syncthing nutzt beispielsweise sowohl TLS als auch Perfect Forward Secrecy, um die Kommunikation zu schützen.

Ihr solltet informiert werden, wenn sich der Fingerprint eines Schlüssels ändert.

Metadaten
Achtet darauf, dass Kommunikationssoftware Metadaten vermeidet oder zumindest schützt; sie können sehr viel über das Leben der Nutzer aussagen.
Audits
Auch die Sicherheitsrisiken von quelloffener Software lassen sich nur von Fachleuten erkennen. Nutzt Software, die einen Sicherheits-Audit erfolgreich bestanden hat.
Tracker

Smartphone-Apps binden häufig sehr viele Tracker ein, die ohne das Wissen der Nutzer*innen Daten an Dritte wie Google oder Facebook weitergeben. εxodus Privacy ist eine Website, die Android-Apps analysiert und anzeigt, welche Tracker in einer App eingebunden sind.

Kontrolliert auch, ob die von einer App angeforderten Berechtigungen zur geplanten Nutzung passen. Es ist zum Beispiel unverständlich, warum Messenger wie Signal, Telegram und WhatsApp zwingend die Eingabe der eigenen Telefonnummer verlangen.

Malvertising

Vermeidet Apps, die Werbung einbinden und damit die Gefahr von Werbung mit Schadcode bergen. Darüberhinaus können Trackingunternehmen über eingebundene Werbung die Aktivitäten der Nutzer*innen auswerten und vermarkten.

Es gibt zahlreiche Tools wie uBlock Origin für Firefox, Blokada für Android und iOS oder AdGuard Pro für iOS, die die Auslieferung von Werbung und den Abfluss persönlicher Daten unterbinden. Mit HttpCanary für Android-Apps und Charles Proxy für iOS-Apps können Nutzer selbst untersuchen, wie sich Apps verhalten, sofern die App-Entwickler nicht auf Certificate-Pinning zurückgreifen. Die Burp Suite schneidet deutlich mehr als nur Datenpakete mit und kann auch Certificate-Pinning umgehen.

Dezentrale Datenspeicherung
Am sichersten ist es, wenn Daten dezentral gespeichert werden. Falls dies nicht möglich ist, sind föderierte Systeme, wie zum Beispiel die E-Mail-Infrastruktur, zentralen vorzuziehen.
Finanzielle Transparenz
Falls hinter quelloffener Software Unternehmen stehen, sollten diese ihre Finanzen und finanziellen Interessen an der Software transparent darstellen. Ein gutes Beispiel ist in dieser Hinsicht Delta Chat.
Verfügbarkeit
Ist eine Android-App beispielsweise nur über Googles Play Store oder auch über den datenschutzfreundlicheren F-Droid Store.
Datensparsamkeit
Prüft bei der Auswahl von Software nicht nur, ob sie alle funktionalen Anforderungen erfüllt, sondern auch, ob sie nur die notwendigen Daten speichert.
Datensynchronisation
Daten einer Software sollten zwischen mehreren Geräten abgeglichen werden können, ohne dass ein zentraler Server zur Vermittlung dafür benötigt wird. So synchronisieren wir beispielsweise unsere KeePass-Datenbank direkt zwischen unseren Geräten mit Syncthing und nicht über WebDAV oder Nextcloud. Dadurch werden die Passwort-Daten nirgends zwischengespeichert, sondern nur dort gespeichert, wo sie auch gebraucht werden.
Backup
Damit alle relevanten Daten auch sicher über die gesamte Nutzungsdauer verfügbar sind, sollten Sicherungskopien erstellt werden. Diese sollten an einem sicheren Ort liegen, der auch rechtlich zulässig ist. Auch sollte die Sicherung automatisch erfolgen und die Backups verschlüsselt werden.

Zur Rückkehr von Richard Stallman in den Vorstand der Free Software Foundation

Cusy unterstützt seit vielen Jahren freie und Open-Source-Projekte, auch solche, die von der Free Software Foundation (FSF) verwaltet werden. In Anbetracht der Umstände, unter denen Richard Stallman 2019 zurückgetreten war, ist Cusy entsetzt, dass er nun wieder in den Vorstand der FSF zurückgekehrt ist. Infolgedessen werden wir an keiner von der FSF ausgerichteten Veranstaltungen mehr teilnehmen. Darüber hinaus haben viele Cusy-Mitarbeiter mitgeteilt, dass auch sie nicht länger vorhaben, an von der FSF geleiteten oder unterstützten Veranstaltungen teilzunehmen.

Im Jahr 2019 sah sich Stallman gezwungen, aufgrund des öffentlichen Drucks infolge seiner umstrittenen Äußerungen zum Kinderhandel-Skandal um Jeffrey Epstein von seinem Vorstandsposten bei der FSF sowie seiner Tätigkeit am MIT zurückzutreten. Damals hofften wir, dass die durch seinen Rücktritt geschaffene Gelegenheit von der Free Software Foundation genutzt wird, um sich zu einer diversen und inklusiven Organisation zu wandeln. Leider hat die FSF nur wenige Schritte in diese Richtung unternommen. Die Rückkehr Richard Stallmans machte nun unsere Hoffnungen vorerst zunichte und auch die vorläufige Erklärung des Verwaltungsrats klingt für uns wenig glaubwürdig.

Seine Rückkehr in den Vorstand der Free Software Foundation durfte Stallman selbst verkünden:

Einige von Ihnen werden sich darüber freuen, und einige werden vielleicht enttäuscht sein, aber wer weiß. Auf jeden Fall ist es so, und ich habe nicht vor, ein zweites Mal zurückzutreten.

– Richard Stallman at LibrePlanet 2021 [1]

Auf ihrer Website betont die FSF jedoch:

Freie Software ist nur so erfolgreich wie die Gemeinschaften, die sie erstellen, benutzen, unterstützen und für sie eintreten.

Es ist überdeutlich, dass sich die FSF grundlegend und dauerhaft ändern muss, um das verspielte Vertrauen der Bewegung freier Software wiedererzuerlangen und um ihrem satzungsgemäßen, gemeinnützigen Auftrag zu entsprechen.


[1]«Some of you will be happy at this, and some might be disappointed but who knows. In any case, that’s how it is and I’m not planning to resign a second time.» (Video).

Sicherheitslücken und weitere unkalkulierbare Risiken bei Microsoft – Zeit, zu Open Source zu wechseln

Zehntausende Microsoft Exchange-Server in Deutschland sind über das Internet angreifbar und mit hoher Wahrscheinlichkeit bereits mit Schadsoftware infiziert. Doch auch Microsoft 365 und die Azure Cloud kämpfen mit massiven Problemen. Abhilfe könnten hier passende OpenSource-Alternativen bieten.

Mehrere kritische Sicherheitslücken bei Microsoft Exchange-Servern

Das Bundesamt für Sicherheit in der Informationstechnologie (BSI) wertet die aktuellen Schwachstellen in MS Exchange als geschäftskritische IT-Bedrohungslage mit massiven Beeinträchtigungen des Regelbetriebs [1]. Damit jedoch nicht genug:

»Exchange-Server besitzen in vielen Infrastrukturen standardmäßig (teilweise ungerechtfertigt) sehr hohe Rechte im Active Directory. Es ist denkbar, dass weitergehende Angriffe mit den Rechten eines übernommenen Exchange-Servers potenziell mit geringem Aufwand auch die gesamte Domäne kompromittieren können. Zu berücksichtigen ist zudem, dass die Schwachstelle ebenfalls aus dem lokalen Netz ausnutzbar wäre, sofern beispielsweise ein Angreifer über einen infizierten Client auf Outlook Web Access Zugriff erhält.«

– BSI: Mehrere Schwachstellen in MS Exchange, 17.03.2021

Das Computer Emergency Response Team der Bundesverwaltung (CERT-Bund) hält bei einem aus dem Internet erreichbaren Outlook Web Access-Server (OWA) eine Kompromittierung ab dem 26. Februar für wahrscheinlich [2]. Wenn Admins nun die Sicherheitspatches einspielen, werden zwar die bekannten Sicherheitslücken geschlossen, nicht jedoch eine mögliche Kompromitierung beseitigt. Zusätzlich muus also geschaut werden, ob Server in der Domäne bereits Ziel eines solchen Angriffs geworden sind und z.B. bereits Hintertüren geöffnet wurde.

Auch heute noch sollen ca. 12.000 von 56.000 Exchange-Servern mit offenem OWA in Deutschland für ProxyLogon [3] verwundbar sein und weitere 9.000 Exchange-Server in den letzten zwei Wochen offline genommen oder der Zugriff auf OWA aus dem Internet unterbunden worden sein [4]:

Exchange-Server mit offenem OWA in Deutschland. Verwundbarkeit für ProxyLogon (CVE-2021-26855 et al.). Stand: 16.03.2021

Quelle: CERT-Bund

Erst vor einem Monat warnte das CERT-Bund, dass auch ein Jahr nach Veröffentlichung des Sicherheitsupdates noch immer 31–63% der Exchange-Server in Deutschland mit offen aus dem Internet erreichbarem OWA für die kritische Schwachstelle CVE-2020-0688 verwundbar waren [5].

Probleme auch bei Microsoft 365 und Azure Cloud

Mehrere Dienste von Microsoft sind am Abend des 15. März 2021 ausgefallen. Verursacht wurden die Probleme durch einen automatisiert gelöschten Schlüssel im Azure Active Directory (AAD). Damit konnten sich Nutzer*innen stundenlang nicht mehr anmelden. Dies betraf auch andere Dienste, die auf der Azure Cloud aufsetzen, u.a. Microsoft Teams, XBox Streams und Microsoft Dynamics. Bereits im September 2020 und Februar 2019 gab es mehrstündige Ausfälle von Microsoft Cloud-Diensten, die ebenfalls auf Fehler im Azure Active Directory Service (AAD) zurückzuführen waren [6].

Das waren jedoch keinesfalls die einzigen Probleme bei Microsoft 365 und der Azure Cloud: Laut einer Studie von Sapio Research im Auftrag von Vectra AI [7] bei 1.112 IT-Sicherheitsentscheider*innen in Unternehmen, die Office 365 nutzen und mehr als tausend Mitarbeiter haben, können Angreifer*innen in den meisten Unternehmen Office-365-Konten übernehmen.

Anlass für die Studie war, dass Fernarbeit infolge der globalen Corona-Pandemie normal geworden ist und Unternehmen schnell in die Cloud gewechselt sind. Häufig wurde dabei zu Office 365 gewechselt. Mit 258 Millionen Benutzer*innen sind sie jedoch auch zu einem verlockenden Ziel für Cyberangriffe geworden. Demnach haben in den letzten 12 Monaten

  • 82% ein erhöhtes Sicherheitsrisikos ihres Unternehmens festgestellt
  • 70% Kontoübernahmen von autorisierten Benutzer*innen festgestellt, wobei durchschnittlich sieben Konten gekapert wurden
  • 58% eine größer werdende Kluft zwischen den Fähigkeiten von Angreifer*innen und Verteidiger*innen festgestellt.

Die meisten Befragten sehen mit der Verlagerung von Daten in die Cloud eine wachsende Bedrohung. Vor allem die Aufwände beim Absichern der Infrastruktur wurden zunächst unterschätzt.

Microsoft vs. Datenschutz

Schließlich fordern nun auch der Landesbeauftragte für Datenschutz in Mecklenburg-Vorpommern und der dortige Rechnungshof von der Landesregierung, ab sofort keine Microsoft-Produkte mehr zu verwenden:

»Betroffen sind davon unter anderem Produkte der Firma Microsoft. Eine rechtskonforme Nutzung dieser Produkte allein auf der Basis von Standarddatenschutzklauseln sei aber aufgrund der vom EuGH aufgestellten Grundsätze nicht möglich. Ohne weitere Sicherungsmaßnahmen würden personenbezogene Daten an Server mit Standort in den USA übermittelt.«

– Pressemitteilung des Landesbeauftragten für Datenschutz und Informationsfreiheit Mecklenburg-Vorpommern, 17.03.2021 [8]

Tatsächlich kommt diese Forderung jedoch nicht überraschend: Die Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder hat bereits 2015 auf diese Gefahren hingewiesen [9].

Folgerichtig schließt der Landesrechnungshof Mecklenburg-Vorpommern, dass nicht rechtskonform einzusetzende Software nicht wirtschaftlich betrieben werden kann.

Ausblick

Die Nachrichten der letzten Tage verdeutlichen, dass Microsoft weder sicher noch zuverlässig betrieben werden kann selbst wenn die Betriebskosten deutlich erhöht würden. Schlussendlich dürften die Microsoft-Services in Europa nicht rechtskonform zu nutzen sein. Mit OpenSource-Alternativen könnte wieder mehr Transparenz, Sicherheit und digitaler Souveränität erreicht werden. So begannen wir letztes Jahr, eine große deutsche Forschungseinrichtung bei den Alternativen zu Microsoft 365 zu beraten: Microsoft-Alternativen – Migration zu OpenSource-Technologien. Dabei ersetzen wir die Microsoft-Produkte schrittweise, über mehrere Jahre hinweg, durch OpenSource-Produkte.

Update: 13. April 2021

Es gibt schon wieder Schwachstellen in Microsoft Exchange Server, für die Microsoft im Rahmen ihres Patchdays auch Updates für Exchange Server veröffentlicht hat [10]. Dieses solte unverzüglich eingespielt werden. Das BSI wertet dies als eine Sicherheitslücke mit verstärkter Beobachtung von Auffälligkeiten unter temporärer Beeinträchtigung des Regelbetriebs [11].

Update: 23. Juli 2021

In der Pressemitteilung äußert sich die Landesbeauftragte für den Datenschutz Niedersachsen, Barbara Thiel, weeiterhin kritisch zum Einsatz von Microsoft 365:

»Wir haben bislang keine entsprechende Anordnung oder Untersagung ausgesprochen, Richtig ist allerdings, dass wir den Einsatz dieser Produkte als sehr kritisch einschätzen. … Aufgrund der beschriebenen Gesamtsituation kann ich von einem Einsatz von Office 365 nachwie vor aus datenschutzrechtlicher Sicht nur dringend abraten.«

– Pressemitteilung der Landesbeauftragten für den Datenschutz Niedersachsen, Barbara Thiel, 22.07.2021 [12]

Auswahl der richtigen NoSQL-Datenbank

Relationale Datenbanken dominierten lange die Softwareindustrie und sind mit Mechanismen wie Redundanz, Transaktionskontrolle und Standardschnittstellen sehr ausgereift. Sie konnten jedoch zunächst nur mäßig auf höhere Anforderungen an Skalierbarkeit und Performance reagieren. So kam ab Anfang 2010 verstärkt der Begriff NoSQL auf um neuartige Datenbanken zu beschreiben, die diesen Anforderungen besser genügten.

NoSQL-Datenbanken sollten die folgenden Probleme lösen:

  • Überbrücken der internen Datenstruktur der Anwendung und der relationalen Datenstruktur der Datenbank
  • Abkehr von der Integration verschiedenster Datenstrukturen in ein einheitliches Datenmodell
  • Die wachsende Anzahl an Daten erforderte zunehmend Cluster zur Datenspeicherung

Aggregierte Datenmodelle

Die relationale Datenbankmodellierung unterscheidet sich erheblich von den Arten von Datenstrukturen, die Anwendungsentwickler verwenden. Die Verwendung der von Entwickler*innen modellierten Datenstrukturen zur Lösung verschiedener Problemdomänen hat zu einer Abkehr von der relationalen Modellierung hin zu aggregierten Modellen geführt. Der größte Teil davon wird von Domain Driven Design angetrieben. Ein Aggregat ist eine Sammlung von Daten, mit denen wir als Einheit interagieren. Diese Aggregate bilden die Grenzen für ACID-Operationen, wobei die Schlüsselwerte, Dokumente und Column Family als Formen einer aggregatorientierten Datenbank angesehen werden können.

Aggregate erleichtern der Datenbank die Verwaltung der Datenspeicherung auf einem Cluster, da sich die Dateneinheit jetzt auf jedem Computer befinden kann. Aggregatorientierte Datenbanken funktionieren am besten, wenn die meisten Dateninteraktionen mit demselben Aggregat durchgeführt werden, z.B. wenn ein Profil mit allen Details abgerufen werden muss. Es ist besser, das Profil als Aggregationsobjekt zu speichern, und diese Aggregate zu verwenden, um Profildetails abzurufen.

Distributionsmodelle

Aggregatorientierte Datenbanken erleichtern die Verteilung von Daten, da der Verteilungsmechanismus nur das Aggregat verschieben muss und sich nicht um verwandte Daten kümmern muss, da alle verwandten Daten im Aggregat selbst enthalten sind. Dabei gibt es im Wesentlichen zwei Arten der Datenverteilung:

Sharding
Sharding verteilt unterschiedliche Daten auf mehrere Server, sodass jeder Server als einzige Quelle für eine Teilmenge von Daten fungiert.
Replikation

Replikation kopiert Daten über mehrere Server hinweg, sodass jedes Datum an mehreren Stellen gefunden werden kann. Die Replikation erfolgt in zwei Formen:

Die Master-Slave-Replikation macht einen Knoten zur autorisierenden Kopie, die Schreibvorgänge verarbeitet, während Slaves mit dem Master synchronisiert werden und möglicherweise Lesevorgänge verarbeiten.

Die Peer-to-Peer-Replikation ermöglicht Schreibvorgänge auf jeden Knoten. Die Knoten koordinieren sich um ihre Kopien der Daten zu synchronisieren.

Die Master-Slave-Replikation verringert zwar die Wahrscheinlichkeit von Aktualisierungskonflikten, aber die Peer-to-Peer-Replikation vermeidet das Schreiben allerVorgänge auf einen einzelnen Server, wodurch ein einzelner Fehlerpunkt vermieden wird. Ein System kann eine oder beide Techniken verwenden.

CAP-Theorem

In verteilten Systemen sind die folgenden drei Aspekte wichtig:

  • Konsistenz (engl.: Consistency)
  • Verfügbarkeit (engl.: Availability)
  • Ausfalltoleranz (engl.: Partition tolerance)

Eric Brewer hat das CAP-Theorem aufgestellt, das besagt, dass wir in jedem verteilten System nur zwei der drei Optionen auswählen können. Viele NoSQL-Datenbanken versuchen, Optionen bereitzustellen, bei denen ein Setup gewählt werden kann, die Datenbank entsprechend dein Anforderungen aufzusetzen. Wenn ihr beispielsweise Riak als verteilte Schlüssel-Werte-Datenbank betrachtet, gibt es im Wesentlichen die drei Variablen

r
Anzahl der Knoten, die auf eine Leseanforderung antworten sollen, bevor sie als erfolgreich angesehen wird
w
Anzahl der Knoten, die auf eine Schreibanforderung antworten sollen, bevor sie als erfolgreich angesehen wird
n
Anzahl der Knoten, auf denen die Daten repliziert werden, auch Replikationsfaktor genannt

In einem Riak-Cluster mit 5 Knoten können wir die Werte für r, w und n so anpassen, dass das System sehr konsistent ist indem wir r = 5 und w = 5 setzen. Damit haben wir jedoch den Cluster für Netzwerkpartitionen anfällig gemacht, da kein Schreibvorgang möglich ist wenn nur ein Knoten nicht antwortet. Wir können denselben Cluster für Schreib- oder Lesevorgänge hoch verfügbar machen, indem wir r = 1 und w = 1 setzen. Jetzt kann jedoch die Konsistenz beeinträchtigt werden, da einige Knoten möglicherweise nicht über die neueste Kopie der Daten verfügen. Das CAP-Theorem besagt, dass ihr, wenn ihr eine Netzwerkpartition erhaltet, die Verfügbarkeit von Daten gegen die Konsistenz von Daten abwägen müsst. Auch die Haltbarkeit kann gegen die Latenz abgewogen werden, insbesondere wenn ihr Fehler mit replizierten Daten überstehen möchtet.

Häufig benötigtet ihr bei relationalen Datenbanken kaum ein Verständnis für diese Anforderungen; nun werden diese wieder wichtig. So dürftet ihr gewöhnt gewesen sein, in relationalen Datenbanken Transaktionen zu verwenden. In NoSQL-Datenbanken stehen euch diese jedoch nicht mehr zur Verfügung und ihr müsst selbst überlegen, wie diese implementiert werden sollen. Muss das Schreiben transaktionssicher sein? Oder ist es auch akzeptabel, dass mal Daten verlorengehen? Schließlich kann manchmal auch ein externer Transaktionsmanager wie ZooKeeper hilfreich sein.

Verschiedene Arten von NoSQL-Datenbanken

NoSQL-Datenbanken können grob in vier Typen eingeteilt werden:

Schlüssel-Werte-Datenbanken

Schlüssel-Werte-Datenbanken sind aus API-Sicht die einfachsten NoSQL-Datenspeicher. Der Client kann entweder den Wert für den Schlüssel abrufen, einen Wert für einen Schlüssel eingeben oder einen Schlüssel aus dem Datenspeicher löschen. Der Wert ist ein Blob, den der Datenspeicher nur speichert, ohne sich darum zu kümmern oder zu wissen, was sich darin befindet. Es liegt ausschließlich in der Verantwortung der Anwendung, zu verstehen, was gespeichert wurde. Da Schlüssel-Werte-Datenbanken immer den Primärschlüsselzugriff verwenden, weisen sie im Allgemeinen eine hohe Leistung auf und können leicht skaliert werden.

Einige der beliebtesten Schlüsselwertdatenbanken sind

Riak KV
Home | GitHub | Docs
Redis
Home | GitHub | Docs
Memcached
Home | GitHub | Docs
Berkeley DB
Home | GitHub | Docs
Upscaledb
Home | GitHub | C API Docs

Ihr müsst sie sorgfältig auswählen da es große Unterschiede zwischen ihnen gibt. Während Riak z.B. die Daten persistent speichert ist dies bei Memcached üblicherweise nicht der Fall.

Dokumentendatenbanken

Diese Datenbanken speichern und rufen Dokumente ab, bei denen es sich um XML, JSON, BSON usw. handeln kann. Diese Dokumente sind hierarchische Baumdatenstrukturen, die aus Karten, Sammlungen und Skalarwerten bestehen können. Dokumentendatenbanken bieten umfangreiche Abfragesprachen und Konstrukte wie Datenbanken, Indizes usw., die einen einfacheren Übergang von relationalen Datenbanken ermöglichen.

Einige der beliebtesten Dokumentendatenbanken sind

MongoDB
Home | GitHub | Docs
CouchDB
Home | GitHub | Docs
RavenDB
Home | GitHub | Docs
Elasticsearch
Home | GitHub | Docs
eXist
Home | GitHub | Docs

Column Family Stores

Diese Datenbanken speichern Daten in Column Families als Zeilen, die einem Zeilenschlüssel zugeordnet sind. Sie sind hervorragend geeignet für Gruppen verwandter Daten, auf die häufig zusammen zugegriffen wird. Dies können beispielsweise alle Profilinformationen einer Person sein, nicht jedoch deren Aktivitäten.

Zwar kann jede Column Family mit der Zeile in einer RDBMS-Tabelle verglichen werden, in dem der Schlüssel die Zeile identifiziert und die Zeile aus mehreren Spalten besteht; aber in Column Family Stores müssen die verschiedene Zeilen nicht dieselben Spalten haben.

Einige der beliebtesten Column Family Stores sind

Cassandra
Home | GitHub | Docs
HBase
Home | GitHub | Docs
Hypertable
Home | GitHub | Docs

Cassandra kann als schnell und einfach skalierbar beschrieben werden, da Schreibvorgänge über den Cluster verteilt sind. Der Cluster verfügt nicht über einen Masterknoten, sodass Lese- und Schreibvorgänge von jedem Knoten im Cluster ausgeführt werden können.

Graphdatenbank

In Graphdatenbanken könnt ihr Entitäten mit bestimmten Eigenschaften und Beziehungen zwischen diesen Entitäten speichern. Entitäten werden auch als Knoten bezeichnet. Stellt euch einen Knoten als Instanz eines Objekts in einer Anwendung vor; Beziehungen können dann als Kanten bezeichnet werden, die ebenfalls Eigenschaften haben können und gerichtet sind.

Graph-Modelle
Labeled-Property-Graph
In einem Labeled-Property-Graph können sowohl Knoten als auch Kanten Eigenschaften (engl.: Properties) besitzen.
Resource Description Framework (RDF)
Im RDF werden Graphen mit Hilfe von Triplen repräsentiert. Ein Triple besteht aus drei Elementen in der Form Knoten-Kante-Knoten Subjekt --Prädikat-> Objekt, die als Ressourcen in Form einer weltweit eindeutigen URI oder als anonyme Ressource definiert werden. Um innerhalb einer Datenbank verschiedene Graphen verwalten zu können, werden diese als Quads gespeichert wobei ein Quad jedes Triple um eine Referenz auf den zugehörigen Graphen erweitert. Aufbauend auf RDF wurde mit RDF-Schema ein Vokabular entwickelt, um schwache Ontologien zu formalisieren und darüber hinaus mit der Web Ontology Language auch vollständig entscheidbare Ontologien beschreiben.
Algorithmen

Wichtige Algorithmen zur Abfrage von Knoten und Kanten sind:

Breitensuche, Tiefensuche
Breitensuche (engl.: breadth-first search, BFS) ist ein Verfahren zum Durchlaufen der Knoten eines Graphen verwendet. Im Gegensatz zur Tiefensuche (engl.: depth-first search, DFS) werden zunächst alle Knoten beschritten, die vom Ausgangsknoten direkt erreichbar sind. Erst danach werden Folgeknoten beschritten.
Kürzester Pfad
Pfad zwischen zwei unterschiedlichen Knoten eines Graphen, welcher minimale Länge bezüglich einer Kantengewichtsfunktion hat.
Eigenvektor
In der linearen Algebra ein vom Nullvektor verschiedener Vektor, dessen Richtung durch die Abbildung nicht verändert wird. Ein Eigenvektor wird also nur skaliert und der Skalierungsfaktor wird als Eigenwert der Abbildung bezeichnet.
Abfragesprachen
Blueprints
eine Java-API für Eigenschaftsgraphen, die zusammen mit verschiedenen Graphdatenbanken verwendet werden kann.
Cypher
eine Abfragesprache entwickelt von Neo4j.
GraphQL
eine SQL-artige Abfragesprache
Gremlin
eine Open-Source-Graphen-Programmiersprache, die mit verschiedenen Graphdatenbanken (Neo4j, OrientDB) genutzt werden kann.
SPARQL
vom W3C spezifizierte Abfragesprache für RDF-Datenmodelle.
Abgrenzung zu relationalen Datenbanken

Wenn wir Graphen in relationalen Datenbanken speichern wollen, geschieht dies meist nur für spezifische Bedingungen, z.B. für die Beziehungen zwischen Menschen. Das Hinzufügen weiterer Beziehungsarten ist dann normalerweise mit vielen Schemaänderungen verbunden.

In Graphdatenbanken ist das Durchlaufen der Verknüpfungen oder Beziehungen sehr schnell, da die Beziehung zwischen Knoten nicht erst zur Abfragezeit berechnet werden muss.

Einige der beliebtesten Graphdatenbanken sind

Neo4j
Home | GitHub | Docs
InfiniteGraph
Home

Auswahl der NoSQL-Datenbank

Allen NoSQL-Datenbanken ist gemein, dass sie kein bestimmtes Schema erzwingen. Im Gegensatz zu relationalen Datenbanken mit starkem Schema müssen Schemaänderungen nicht zusammen mit dem Quellcode, der auf diese Änderungen zugreift, gespeichert werden. Schemalose Datenbanken können Änderungen im implizierten Schema tolerieren, sodass sie keine Downtime zur Migration benötigen; sie sind daher vor allem bei Systemen, die 24/7 zur Verfügung stehen sollen, sehr beliebt.

Wie wählen wir nun aber unter so vielen NoSQL-Datenbanken die richtige aus? Im Folgenden können wir Ihnen nur einige allgemeine Kriterien nennen:

Schlüssel-Werte-Datenbanken
sind im Allgemeinen nützlich zum Speichern von Sessions, Benutzerprofilen und Einstellungen. Wenn jedoch Beziehungen zwischen den gespeicherten Daten abgefragt oder mehrere Schlüssel gleichzeitig bearbeitet werden sollen, würden wir Schlüsselwertdatenbanken vermeiden.
Dokumentendatenbanken
sind im Allgemeinen nützlich für Content-Management-Systeme und E-Commerce-Anwendungen. Wir würden die Verwendung von Dokumentdatenbanken jedoch vermeiden, wenn komplexe Transaktionen benötigt odermehrere Vorgänge oder Abfragen für unterschiedliche Aggregatstrukturen gestellt werden sollen.
Column Family Stores
sind im Allgemeinen nützlich für Content-Management-Systeme und für hohe Schreibvolumen wie z.B. bei der Protokollaggregation. Wir würden die Verwendung von Datenbanken für Column Family Stores vermeiden, die sich in der frühen Entwicklung befinden und deren Abfragemuster sich noch ändern können.
Graphdatenbanken
eignen sich sehr gut für Problembereiche, in denen wir Daten wie soziale Netzwerke, Geodaten, Routing-Informationen sowie Empfehlungssystem miteinander verbunden werden sollen.

Fazit

Der Aufstieg der NoSQL-Datenbanken führte nicht zum Niedergang der relationalen Datenbanken. Sie können gut nebeneinander existieren. Häufig werden unterschiedliche Datenspeichertechnologien verwendet um die Daten passend zu ihrer Struktur und erforderlichen Abfrage zu speichern.

Microsoft-Alternativen – Migration zu OpenSource-Technologien

Für eine große deutsche Forschungsgesellschaft entwickeln wir eine Migrationsstrategie von Microsoft 365 zu OpenSource-Technologien. Dabei geht es einerseits darum, die digitale Sourveränität zurückzuerhalten und andererseits erhöhte Sicherheitsanforderungen zu erfüllen. Dies soll nun unter Verwendung freier und quelloffener Software (FLOSS) erreicht werden. Insgesamt ähnelt das Projekt dem Microsoft Alternatives-Projekt (MAlt) des CERN und dem Projekt Phoenix von Dataport.

Die Grundsätze des Projekts sind:

  • Allen Mitarbeiter*innen soll der gleiche Service geboten werden
  • Vendor lock-ins sollen vermieden werden um das Risiko der Abhängigkeit zu verringern
  • Die Daten sollen weitestgehend im Besitz der Forschungsgesellschaft bleiben

Dabei evaluieren wir für viele Services alternative Lösungen, implementieren Prototypen und Pilotprojekte.

Produktgruppe Service Product to evaluate Status
Identitäts- und Zugriffsmanagement LDAP OpenLDAP 🏭 Produktion
Personal Information Management E-Mail Zimbra 🚦 Evaluation
Kalender Zimbra 🚦 Evaluation
Kontakte Zimbra 🚦 Evaluation
Kollaboration Dateiaustausch NextCloud 🏭 Produktion
Office-Integration NextCloud 🚦 Evaluation
Direktnachrichten/ Chat Mattermost 🏭 Produktion
Videokonferenzen Jitsi Meet 🏭 Produktion
Suche Suchmaschine OpenSearch 🚦 Evaluation
Frontend/ Visualisierung OpenSearch Dashboards 🚦 Evaluation
Authentifizierung/ Zugriffskontrolle Open Distro Security 🚦 Evaluation
Nächste-Nachbarn Klassifikation Open Distro KNN 🚦 Evaluation
Projektmanagement Aufgaben/Meilensteine GitLab 🚦 Evaluation
Zeiterfassung gitlabtime 🚦 Evaluation
Dokumentation GitLab Wiki 🚦 Evaluation
Compliance-Management Richtlinienverwaltung, Audit-Management GitLab Compliance Management 🚦 Evaluation
Forschungssoftware [1], [2] Paketmanager Spack 🏭 Produktion
IDE JupyterHub 🏭 Produktion
Entwicklungsumgebungen Jupyter Kernels 🏭 Produktion
Software-Versionierung Git 🏭 Produktion
Datenversionierung DVC 🏭 Produktion
Erhebung und Speicherung von Daten Intake 🛫 Pilot
Tabellenkalkulation ipysheet 🏭 Produktion
Geodaten PostGIS 🏭 Produktion
Kartographische Daten OpenStreetMap 🏭 Produktion
DevOps GitLab CI/CD Pipeline 🛫 Pilot
Dokumentation Sphinx 🏭 Produktion

Hosting-Strategie

Innerhalb der Forschungsgesellschaft gibt es im wesentlichen drei verschiedene Hosting-Varianten:

Gesellschaftsweite Infrastruktur
Infrastruktur, die institutsübergreifend von einem Großteil der Forschungsprojekte und Verwaltungen genutzt wird, soll von der zentralen IT der Forschungsgesellschaft bereitgestellt werden.
Institutsweite Infrastruktur
Infrastruktur, die für die speziellen Forschungsbereiche eines Instituts benötigt werden oder die IT-Unterstützung vor-Ort benötigen, sollen von der IT des jeweiligen Instituts bereitgestellt werden.
Betriebs- und Georedundanz
Diese werden im Wesentlichen durch Institutskooperationen oder durch Kooperationen einzelner Institute mit der IT der Forschungsgesellschaft hergestellt. Technologisch werden hierfür Floating IPs und das Virtual Router Redundancy Protocol (VRRP) verwendet wobei die Entscheidungen auf Basis von BGP-Announcements getroffen werden.

[1]

Für die Infrastruktur, auf der die Forschungssoftware entwickelt wird, gibt es ausführliche Dokumentationen, die unter der BSD-3-Clause-Lizenz veröffentlicht sind:

[2]Hier stellt das geplante einheitliche API eine deutliche Vereinfachung dar; siehe auch Announcing the Consortium for Python Data API Standards.

Leuphana-Universität Lüneburg: IT-Infrastruktur für Hackathons

Was ist ein Hackathon?

Das Wort Hackathon setzt sich zusammen aus den beiden Worten Hack und Marathon. Es ist eine kollaborative IT-Veranstaltung mit dem Ziel, gemeinsam Prototypen zu spezifischen Themen oder Problemen herzustellen.

Über die thematische Ausrichtung eines Hackathons können Bezüge zu den Lebenswelten der Teilnehmer*innen hergestellt werden. Sie erfahren, wie Probleme gemeinsam mit technischen Mitteln gelöst werden können. Häufig wurden Hackathons jedoch auch veranstaltet um kreativ Lösungswege zu finden. Schließlich führen sie auch zu einer Vernetzung der Teilnehmer*innen, auch wenn diese aktuell nur online möglich ist.

Nach dem erfolgreichen Hackathon der Bundesregierung WirVsVirus u.a. zusammen mit Code for Germany und Prototype Fund haben auch andere für sich Hackathons als geeignetes Veranstaltungsformat gefunden, so beispielsweise auch das Hochschulforum Digitalisierung mit ihrem SemesterHack.

Für den Lüneburg Hackathon 2020 mit bis zu 500 Teilnehmer*innen konzipierten wir nicht nur die IT-Infrastruktur sondern auch die Event-Begleitung mit folgenden Phasen:

  1. Setup mit 24h
  2. 14-tägiger Vorlauf mit 9h
  3. 3-tägiger Event mit 36h
  4. 14-tägiger Nachlauf mit 5h

Im Wesentlichen sahen wir die drei große Herausforderungen:

  • in kurzer Zeit uns eng mit den Veranstalter*innen der Leuphana-Universität Lüneburg abzustimmen
  • eine einfache Integration der verwendeten IT-Komponenten:
  • Jitsi als hochverfügbaren Cluster-Service bereitzustellen, mit dem die 500 Teilnehmer*innen gleichzeitig kommunizieren können

Wie läuft ein Hackathon ab?

Der typische Ablauf eines Online-Hackathons kann dann z.B. so aussehen:

  1. Begrüßung der Teilnehmer*innen und Kennenlernen im Mattermost Chat
  2. Vorstellung des Formats und Agenda des Hackathons mit Jitsi-Videokonferenz und Screensharing
  3. Kurze Impulsvorträge zu den wichtigsten Tools, Daten und thematischen Schwerpunkten
  4. Brainstorming mit GitLab Kanban-Boards
  5. Gruppenbildung mit jeweils eigenen Kanban-Boards, Git-Repositories, Mattermost-Channels und ggf. Entwicklungsumgebungen auf Basis von Jupyter Notebooks.
  6. Präsentationen mit Jitsi-Videokonferenzen und ggf. Jupyter Notebooks im Präsentationsmodus

Welche Hackathons gibt es in Deutschland?

Jugend hackt
Ihr Motto ist Mit Code die Welt verbessern und soll einen verantwortungsbewussten Umgang mit Technik fördern um Lösungen für gesellschaftspolitische Fragen zu finden. Es ist ein nicht-gwinnorientiertes Programm der gemeinnützigen Vereine Open Knowledge Foundation Deutschland e.V. und mediale pfade.org.
Coding da Vinci
Seit 2014 vernetzt Coding da Vinci technikaffine und kulturbegeisterte Communities mit deutschen Kulturinstitutionen, um offene Kulturdaten zu erhalten.
Science Hack Day Berlin
Der Science Hack Day Berlin wird von Freiwilligen aus den Bereichen Wissenschaft, Design, IT, Ingenieurwesen und Kommunikation organisiert.
Wikimedia Hackathon
Die Wikimedia Hackathons werden veranstaltet um um die technologische Infrastruktur von Wikipedia und anderen Wikimedia-Projekten, insbesondere der ihnen zugrunde liegenden MediaWiki-Plattform zu verbessern.

Falls ihr nun selbst einen Hackathon veranstalten möchtet, so kann Cusy auch euch mit der passenden IT-Infrastruktur und Support unterstützen.

Meldet euch

Ich berate euch gerne und erstelle ein passgenaues Angebot für IT-Infrastruktur und Support bei einem Hackathon.

Portrait Veit Schiele
Veit Schiele
Telefon: +49 30 22430082

Wir rufen euch auch gerne an!

Jetzt anfragen