Blog

Accessibility APIs

Den Anfang machte Adem Cifcioglu mit einem Vortrag über die Accessibility APIs. Zunächst erläuterte er ausführlich den Accessibility Tree, der sich folgendermaßen aufbaut:

1. Name
2. Roles
3. States
4. Properties
5. Relationship

In einem solchen Baum sind die Inhalte eines Elements, die Attribute und assoziierten Elemente sowie die ARIA-Attribute enthalten. Nicht enthalten sind jedoch Elemente wie button, checkbox, img etc. Zudem können Elemente versteckt werden mit aria-hidden="true".

Semantik

Hidde de Vries erläuterte, dass HTML keine Aussagen über das Aussehen der Seite trifft sondern vielmehr die Bedeutung festlegt. Dabei wird die Semantik in HTML in Elementen, Attributen und Werten festgelegt: <elements attributes="value">. Auch macht HTML keine Aussage darüber, wie bestimmte Elemente verwendet werden sollen. So kann z.B. das Ausfüllen eines Formulars erfolgen, indem der Browser bekannte Felder automatisch ausfüllt oder aber andere unterstützende Technologien wie Spracheingabe etc. genutzt werden. Dabei gibt es jedoch mehrere Möglichkeiten, dieselbe Semantik auszudrücken, z.B. <button> oder <div role="button">. Weitere Informationen, wie ihr HTML-Semantiken nutzen könnt, findet ihr in der Spezifikation. Und einige Beispiele, wie ihr HTML nicht nutzen solltet, sind in HTMHell gesammelt worden.

Zudem können Listen ihre Semantik verlieren, wenn list-style-type: none festgelegt wird; s.a. "Fixing" Lists. Andere CSS-Anweisungen, wie z.B. text-transform: uppercase werden von manchen Screen-Reader wie abbr interpretiert. Weitere CSS-Anweisungen, die Screen-Reader beeinflussen findet ihr in CSS Can Influence Screenreaders.

Hidde de Vries beendet seinen Vortrag mit einem Zitat der Open UI-Organisation:

«We hope to make it unnecessary to reinvent built-in UI controls»

– Open UI

Weitere Ziele von Open UI sind:

• Komponentennamen von Dokumenten, wie sie heute bereits existieren
• Eine gemeinsame Sprache für die Beschreibung von Benutzeroberflächen und Designsystemen
• Browser-Standards für Komponenten von Webanwendungen

ARIA-Standard

Gerard K. Cohen gab eine Einführung in Accessible Rich Internet Applications (ARIA) und zeigte, wie die ARIA-Spezifikation verwendet werden kann um um passgenaue Komponenten zu erstellen. Dabei warnte er zu Beginn seines Vortrags vor den Gefahren, die ARIA mit sich bringen kann. So kam z.B. WebAIM nach der Analyse von einer Millionen Websites im Februar 2021 zum Ergebnis:

»Auf Homepages mit ARIA wurden im Durchschnitt 41% mehr Fehler entdeckt als auf solchen ohne ARIA!«

Der Standard ist jedoch mit 70 ARIA-Rollen und 29 interaktiven (Widget)-Rollen nicht gerade einfach zu überblicken:

WAI-ARIA Taxonomy

Hinzu kommt noch, dass ARIA-Rollen von sich aus keine Interaktionen bieten sondern nur Zustände und Eigenschaften beschreibt, die dann verwendet werden können um selbst Interaktionen zu definieren.

Daher riet er dringend an, die fünf ARIA-Regeln einzuhalten:

1. Verwendet ARIA nicht, wenn ihr stattdessen HTML verwenden könnt.

2. Ändert nicht die ursprüngliche Semantik, also z.B. nicht

   <a href=“#” role=“button”>Menu</a>
   

3. Alle interaktiven ARIA-Rollen müssen mit der Tastatur bedienbar sein.

4. Verwendet nicht role="presentation" oder aria-hidden="true" für sichtbare, fokusierbare Elemente.

5. Alle interaktiven Elemente müssen einen zugänglichen Namen haben.

Schließlich wies er noch auf die Hinweise im Abschnitt Browser and Assistive Technology Support hin:

»Es ist wichtig, die Interoperabilität von Hilfstechnologien zu testen, bevor der Code … in der Produktion verwendet wird.«

Auch verwies er noch auf einen anderes Zitat aus Mobile and Touch Support:

»Derzeit gibt dieser Leitfaden nicht an, welche Beispiele mit mobilen Browsern oder Touch-Interfaces kompatibel sind. Während einige der Beispiele spezifische Funktionen enthalten, die die Unterstützung für mobile und berührungsempfindliche Oberflächen verbessern, werden einige ARIA-Funktionen nicht von allen mobilen Browsern unterstützt. Darüber hinaus gibt es noch keinen standardisierten Ansatz für die Bereitstellung von Touch-Interaktionen, die in allen mobilen Browsern funktionieren.«

Live Regions

Ugi Kutluoglu erläuterte, welche Probleme Live Regions lösen und welche Missverständnisse es auszuräumen gilt. Im Wesentlichen handelt es sich bei ihnen um DOM-Knoten, die für Benachrichtigungen vorgesehen sind und die meist über JavaScript Screen-Reader steuern.

Eine Live Region lässt sich einfach irgendwo im DOM bereitstellen bevor Inhalte hinzugefügt werden:

<div id=”myLiveRegion” class=”visually-hidden”> </div>

<div aria-live=”polite” aria-relevant=”text” aria-atomic=”true” id=”myLiveRegion”>
    <span>Now playing</span>
    <span id=”song”>Van Morrison - Celtic New Year</span>
</div>

Häufige Fehler sind

• der Versuch, eine Sprachschnittstelle zu erstellen
• die Annahme, dass alles bekannt annonciert wird
• die Annahme, dass ganze Sektionen live werden
• konkurrierende Live-Regionen
• Versuche den Status von Live Regions zu übermitteln
• zu viele Updates in zu kurzer Zeit

Um diese Fehler analysieren zu können, stellte er diverse Debugging-Werkzeuge vor:

• Fügt einen Break bei Änderungen des Teilbaums hinzu, um zu sehen, was wann und durch welches Skript hinzugefügt wird

• Mutation Observer

  (()=>{
      const target = document.querySelector('body');
      const observer = new MutationObserver(function(mutations) {
          mutations.forEach((mutation) => {
              console.log(mutation.addedNodes, mutation.removedNodes, mutation.attributeName)
          });
       });
      observer.observe(target, {childList: true,attributes: true,subtree: true});
  })();
  

• NerdeRegion Extension

High contrast mode

Kilian Valkhof stellte gleich zu Beginn klar, dass dieser Modus nicht unmittelbar zu höheren Kontrasten führt sondern vielmehr die Anzahl der Farben reduziert und die Farben von den Betrachtenden ausgewählt werden können. Dies erleichtert Personen mit Sehschwäche, Farbenblindheit und Lichtempfindlichkeit, aber auch bei hellem Sonnenlicht etc., insgesamt ca. 4% derjenigen, die sich eine Website anschauen wollen.

Nach dem Auswählen einer Option zeigt die High contrast-Seite von Windows eine Vorschau an.

element {
  forced-colors-adjust: none;
}

element:focus {
  outline-color: transparent;
  box-shadow: 0 0 0 2px orangered;
}

Farbkontrast und WCAG

Im Vortrag von Todd Libby ging es dann wirklich um Farbkontraste und wie WCAG 2.0 Erfolgskriterien erfüllt werden können. Dies verdeutlichte er an einigen Erfolgskriterien (engl.: Success criteria):

Success Criterion 1.4.6 Contrast (Enhanced) (AAA)

Die visuelle Darstellung von Text und Textbildern hat ein Kontrastverhältnis von mindestens 7:1 mit Ausnahme der folgenden Punkte:

• Großer Text und Bilder von großflächigem Text haben ein Kontrastverhältnis von mindestens 4,5:1
• Beiläufiger Text und Bilder von Text, die Teil einer inaktiven Komponente der Benutzeroberfläche sind oder die reine Dekoration sind oder die für niemanden sichtbar sind oder die Teil eines Bildes sind, das signifikante andere visuelle Inhalte enthält, haben keine Kontrastanforderungen.
• Logotypen, also Text, der Teil eines Logos oder Markennamens ist, muss keinen Kontrast aufweisen.

Success Criterion 1.4.11 Non-text Contrast (AA)

Die visuelle Darstellung der folgenden Komponenten soll ein Kontrastverhältnis von mindestens 3:1 zu benachbarten Farben aufweisen:

Komponenten der Benutzeroberfläche

Visuelle Informationen, die erforderlich sind, um Komponenten und Zustände der Benutzeroberfläche zu identifizieren, außer bei inaktiven Komponenten oder wenn das Aussehen der Komponente vom Benutzeragenten bestimmt und nicht vom Autor geändert wird.

Grafische Objekte

Teile von Grafiken, die zum Verständnis des Inhalts erforderlich sind, es sei denn, eine bestimmte Darstellung von Grafiken ist für die zu vermittelnde Information wesentlich.

Bedauerlicherweise gehören Farbkontraste auch noch 2021 zu den häufigsten Fehlern auf Websites in Bezug auf Zugänglichkeit:

86,4 % der Homepages enthielten kontrastarmen Text, im Durchschnitt 31 Instanzen pro Homepage.

– WebAIM Million – 2021 Update

Dabei gibt es etliche Werkzeuge, mit denen Farbkontraste überprüft werden können:

• contrast ratio
• Who can use
• Contrast Checker
• Colour Contrast Checker
• Randoma11y
• Button Contrast Checker

Es sind auch etliche Browser-Erweiterungen verfügbar:

• WAVE
• axe
• NoCoffee vision simulator
• Lighthouse

Und auch ganze Farbpaletten lassen sich testen:

• Contrast Grid
• Accessible color palette builder
• tanaguru contrast finder
• A11y Color Palette

Zum Schluss gab er noch den Tipp, dass Farbverhältnisse zwar die Mindestkontraste einhalten sollten, gleichzeitig jedoch zu starke Kontraste im Text zu einer verschwommenen Wahrnehmung führen können.

Accessible SVGs

Heather Migliorisi berichtete über skalierbare Vektorgrafiken (SVG), die sich immer mehr zum bevorzugten Grafikformat im Web entwickeln. Dies wirkt sich auch auf die Hilfetechnologien aus. Ihr 2021 aktualisierter Artikel Accessible SVGs beschreibt detailliert die Themen ihres Vortrags, sodass wir ihn hier nicht selbst zusammenfassen müssen. Sie empfahl jedoch ein paar zusätzliche Quellen:

• Carie Fisher: Creating Accessible SVGs
• Sara Soueidan: Accessible Icon Buttons
• An alt Decision Tree
• Sarah Higley: Quick Tips for High Contrast Mode
• Melanie Richards: CurrentColor SVG in forced colors modes
• Val Head: Designing With Reduced Motion For Motion Sensitivities

Bewegung inklusiv gestalten

Val Head hob dabei vor allem auf die Bevorzugung reduzierter Bewegungen ab:

Auch ein Großteil der verwendeten Browser unterstützt die Media Query prefers-reduced-motion:

Implementiert werden kann die Media-Query sowohl in CSS als auch in Javascript:

@media (prefers-reduced-motion: reduce) {
}

const motionQuery = window.matchMedia('(prefers-reduced-motion)');

if (motionQuery.matches) {
    document.documentElement.classList.add('reduced-motion');
}

motionQuery.addListener(handleReduceMotionChanged);
handleReduceMotionChanged();

Anschließend zeigte sie, wie Interface-Animationen entsprechend gestaltet werden können. Unter anderem zeigte sie Animation with reduced-motion von Marcy Sutton.

Weitere Informationen zur Bevorzugung von reduzierten Bewegungen erhaltet ihr in ihrem Buch Designing Interface Animation, im WebKit-Artikel Responsive Design for Motion und in ihrem Artikel Designing With Reduced Motion For Motion Sensitivities.

Meldet euch

In unseren Schulungen geben wir eine praktische Einführung in die passenden Technologien für barrierearme Websites. Und gerne erstellen wir euch auch ein individuelles Angebot für die Entwicklung eures Style Guides oder eures Frontends, in die die wir die neuesten Erkenntnisse integrieren.

Ich rufe euch auch gerne zurück!

Jetzt anfragen

Zum Weiterlesen

• DataHub: Popular metadata architectures explained
• DataHub: Powering LinkedIn’s Metadata
• DataOps Unleashed Driving DataOps Culture with LinkedIn DataHub

DevOps-Kultur

Ein wesentlicher Aspekt von DevOps-Kultur ist die gemeinsame Verantwortung für das System. Leicht verliert ein Entwicklungsteam das Interesse an Betrieb und Wartung, wenn es einem anderen Team zum Betrieb übergeben wird. Wenn jedoch das Entwicklungsteam die Verantwortung für den Betrieb eines Systems über die gesamte Lebensdauer teilt, kann es die Probleme des Betriebspersonals besser nachvollziehen und auch Wege zur Vereinfachung von Bereitstellung und Wartung finden, z.B. durch die Automatisierung von Bereitstellungen (→ Release, → Deploy, ) und verbessertes Monitoring (→ Metriken, → Incident Management, → Statusseite). Wenn umgekehrt das Betriebsteam die Verantwortung für ein System teilt, arbeiten sie enger mit dem Entwicklungsteam zusammen, das dann auch die betrieblichen Anforderungen besser versteht.

Um eine Kultur der geteilten Verantwortung zu unterstützen sind organisatorische Veränderungen erforderlich. Entwicklung und Betrieb sollten keine Silos sein. Für den Betrieb Verantwortliche sollten frühzeitig in das Entwicklungsteam eingebunden werden. Die Zusammenarbeit zwischen Entwicklung und Betrieb hilft bei der Zusammenarbeit. Übergaben und Freigaben entmutigen hingegen, behindern eine gemeinsame Verantwortung und fördern Schuldzuweisungen.

DevOps-Änderung

Um effektiv zusammenarbeiten zu können, müssen Entwicklungs- und Betriebsteam in der Lage sein, Entscheidungen zu treffen und Änderungen vorzunehmen. Dazu gehört Vertrauen in diese autonomen Teams, den nur dann wird sich ihr Umgang mit Risiken ändern und ein Umfeld geschaffen, das frei von Versagensängsten ist.

Um die Zusammenarbeit von Entwicklungsteam und Betriebspersonal zu fürdern und das System selbst kontinuierlich zu verbessern, ist Feedback essentiell. Dabei kann die Art des Feedbacks die Dauer und die Häufigkeit sehr unterschiedlich sein:

• Das Überprüfen der eigenen Code-Änderungen sollte sehr häufig erfolgen und daher nur wenige Sekunden benötigen
• Ob sich eine Komponente in alle anderen integrieren lässt, kann jedoch mehrere Stunden dauern und wird daher deutlich seltener ausgeführt werden.
• Auch die Überprüfung von nicht-funktionale Anforderungen wie Zeitverhalten, Ressourcenverbrauch, Wartbarkeit etc. kann auch schon mal einen ganzen Tag dauern.
• Die Antwort des Teams auf eine technische Frage sollte nicht erst nach Stunden oder gar Wochen erfolgen.
• Die Zeit, bis neue Team-Mitglieder produktiv werden, kann Wochen oder auch Monate dauern.
• Ein neuer Service sollte innerhalb weniger Tage produktiv werden können.
• Fehler in Produktivsystemen zu finden ist jedoch häufig erst nach einem oder mehreren Tagen erfolgreich.
• Eine erste Bestätigung durch die Zielgruppe, dass eine produktive Änderung angenommen wird, sollte nach wenigen Wochen möglich sein.

Dabei dürfte sich von selbst erklären, dass Feedbackschleifen häufiger durchgeführt werden wenn sie kürzer sind. Frühe und häufige Validierung wird auch die spätere Analyse und Nacharbeit reduzieren. Auch einfach zu interpretierende Feedback-Schleifen reduzieren die Aufwände erheblich.

Etsy erfasst nicht nur, ob die Verfügbarkeit und die Fehlerrate von Komponenten den eigenen Ansprüchen genügt, sondern auch in welchem Umfang eine Funktionsänderung von der Zielgruppe angenommen wird: sollte eine Änderung sich als wertlos herausstellen wird sie wieder entfernt, wodurch die technische Schulden reduziert werden können.

Developer Experience

Developer Experience (DX), die Konzepte aus der UX-Optimierung auf Erfahrungen in Entwicklungsteams anwendet, kann hier eine gute Ergänzung sein um die kulturelle Ebene besser aus Sicht des Entwicklungsteams zu erfassen. In Developer Experience: Concept and Definition unterscheiden Fabian Fagerholm und Jürgen Münch die folgenden drei Aspekte:

So könnte der Tag für Mitglieder des Entwicklungsteams in einer wenig effektiven Umgebung aussehen:

1. Der Tag beginnt mit einer Reihe von Problemen in der Produktion.
   1. Da es keine aggregierten Auswertungen gibt, wird der Fehler in verschiedenen Log-Dateien und Monitoring-Services gesucht.
   2. Schließlich wird das Problem im Auslagern des Arbeitsspeichers in eine Swap-Datei vermutet und das Betriebsteam um mehr Arbeitsspeicher gebeten.
2. Nun ist endlich Zeit zu schauen, ob es Rückmeldungen vom QA-Team gab zu der neu implementierten Funktion.
3. Dann ist auch schon das erste von mehreren Statusmeetings.
4. Endlich könnte mit dem Entwickeln begonnen werden, wenn nur schon der Zugang zur erforderlichen API bereitgestellt worden wäre. Stattdessen werden nun Telefonate mit dem Team geführt, das die Zugänge für die API bereitstellt um nicht erst nach mehreren Tagen mit der Arbeit beginnen zu können.

Wir könnten noch viele weitere Blockaden aufzählen; letztendlich beenden die Mitglieder des Entwicklungsteams ihren Arbeitstag frustriert und demotiviert. Alles dauert länger als es sollte, und der Tag besteht aus nicht enden wollenden Hindernisse und Bürokratie. Die Mitglieder des Entwicklungsteams fühlen sich nicht nur ineffektiv und unproduktiv. Wenn sie diese Arbeitsweise irgendwann akzeptieren, breitet sich bei ihnen erlernte Hilflosigkeit aus.

In einer solchen Umgebung versuchen Unternehmen meist, die Produktivität zu messen und die leistungsschwächsten Team-Mitglieder zu erkennen indem sie die Anzahl der Code-Änderungen und erfolgreich bearbeiteten Tickets messen. In solchen Unternehmen werden meiner Erfahrung nach die besten Fachkräfte gehen; es gibt keinen Grund für sie, in einer ineffektiven Umgebung zu verharren, wenn innovative digitale Unternehmen nach starken technischen Talenten suchen.

Der Arbeitstag in einer hocheffektiven Arbeitsumgebung könnte hingegen so aussehen:

1. Der Tag beginnt mit dem Blick auf das Projektmanagement-Tool des Teams, z.B. ein sog. Kanban-Board. Anschließend gibt es ein kurzes Standup-Meeting nach sich jedes Team-Mitglied im Klaren ist, woran es heute arbeiten wird.
2. Das Team-Mitglied stellt fest, dass die Entwicklungsumgebung automatisch aktuelle Bibliotheken erhalten hat, die auch bereits in die Produktion übernommen wurden da alle CI/CD-Pipelines grün waren.
3. Als nächstes werden die Änderungen in die eigene Entwicklungsumgebung übernommen und mit den ersten inkrementellen Code-Änderungen begonnen, die durch Komponententests schnell validiert werden können.
4. Beim nächsten Feature wird der Zugang zur API eines Dienstes benötigt, der von einem anderen Team verantwortet wird. Der Zugang kann über ein zentrales Service-Portal beantragt werden, sich ergebende Fragen werden schnell in einem Chat-Raum beantwortet.
5. Nun kann störungsfrei mehrere Stunden intensiv an dem neuen Feature gearbeitet werden.
6. Nachdem das Feature implementiert und alle Komponententests bestanden wurden, wird in automatisierten Tests überprüft, ob sich die Komponente auch weiterhin in alle anderen Komponenten integriert.
7. Sind alle Continuous-Integration-Pipelines grün, werden die Änderungen schrittweise für die vorgesehenen Zielgruppen in der Produktion freigegeben und dabei die Betriebskennzahlen überwacht.

Jedes Mitglied eines solchen Entwicklungsteams kann an einem Tag schrittweise Fortschritte machen und zufrieden mit dem Erreichten den Arbeitstag beenden. In einem solchen Arbeitsumfeld können die Arbeitsziele einfach und effizient erreicht werden und es gibt wenig Reibungsverluste. Die meiste Zeit verbringen die Team-Mitglieder damit, wertvolles zu schaffen. Produktiv zu sein motiviert die Mitglieder des Entwicklungsteams. Ohne Reibung haben sie Zeit, kreativ zu denken und sich einzusetzen. Hier konzentrieren sich die Unternehmen darauf, ein effektives technisches Umfeld bereitzustellen.

Meldet euch

Wir beraten euch gerne und erstellen ein passgenaues Angebot für eine gelingende DevOps-Transformation.

Veit Schiele

Telefon: +49 30 22430082

E-Mail schreiben

Ich rufe euch auch gerne zurück!

Jetzt anfragen

Allgemein

• Wie sicher ist die Software?

• Wie gut sind die Daten vor unberechtigten Zugriffen geschützt?

• Die Sicherheit von quelloffener Software lässt sich am zuverlässigsten prüfen.

• Falls hinter einer quelloffenen Software ein Unternehmen steht, sollte dieses seine Finanzen und seine finanziellen Interessen an der Software transparent darstellen. Ein gutes Beispiel ist in dieser Hinsicht Delta Chat.

• Prüft bei der Auswahl von Software nicht nur, ob sie alle funktionalen Anforderungen erfüllt, sondern auch, ob sie datensparsam ist.

• Über welche Kanäle ist eine Software verfügbar?

  Ist eine Android-App beispielsweise nur über Googles Play Store oder auch über den datenschutzfreundlicheren F-Droid Store erhältlich?

• Verwendet die Software sichere Verschlüsselungsmethoden?

  Zu unterscheiden ist hier zwischen der Transportverschlüsselung – idealerweise Ende-zu-Ende – und der Verschlüsselung von gespeicherten Daten.

  Die Synchronisierungssoftware Syncthing nutzt beispielsweise sowohl Transport Layer Security (TLS) als auch Perfect Forward Secrecy (PFS) um die Passwortdaten zu schützen.

• Falls sich der Fingerprint eines Schlüssels ändert, sollte die Software die User darüber informieren.

• Achtet bei Kommunikationssoftware darauf, dass sei Metadaten vermeidet oder zumindest schützt; sie können sehr viel über das Leben der User aussagen.

Video-Konferenzen

• Kontrolliert auch bei Open-Source-Software, wie datenschutzfreundlich die Standardeinstellungen 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.

Virtual Private Network (VPN)

• Ein Virtual Private Network ist die Basis für den Zugriff auf das Firmennetzwerk von außen.
• Vertrauen Sie nicht blindlings den Versprechungen von VPN-Anbietern.
• Nutzt quelloffene Programme wie OpenVPN oder WireGuard.

Fernwartungssoftware

• Auch für Fernwartungssoftware gibt es Open-Source-Lösungen wie Remotely, deren Quellcode im Gegensatz zu TeamViewer oder AnyDesk auf GitHub einsehbar ist.
• Auch die Sicherheitsrisiken von quelloffener Software lassen sich nur von Fachleuten erkennen.
• Nutzt Software, die einen Sicherheits-Audit erfolgreich bestanden hat.

Mobile Apps

• Smartphone-Apps binden häufig sehr viele Tracker ein, die ohne das Wissen der User 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, 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.

• Vermeidet Apps, die Werbung einbindet.

  Dies birgt die Gefahr von Malvertising, also der Auslieferung von Werbung mit Schadcode. Darüberhinaus können Trackingunternehmen über die eingebundene Werbung die Aktivitäten der User 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 User 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.

Datensicherung und -synchronisation

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

• Können alle relevanten Daten auch sicher über die gesamte Nutzungsdauer gespeichert werden?

• Kann ein Backup aller relevanten Daten erstellt werden?

• Liegen diese Backups an einem sicheren Ort?

• Und wer ist für die Backup-Daten rechtlich zuständig?

• Erfolgt die Sicherung der relevanten Daten automatisch?

• Sind die Backups verschlüsselt?

• Können Daten einer Software zwischen mehreren Geräten abgeglichen werden, ohne dass ein zentraler Server zur Vermittlung dafür nötig ist? So synchronisieren wir bei Cusy z.B. 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.

Ist Remote Work ein Produktivitäts- und Innovationskiller?

• 24 Prozent des Managements sehen die Produktivität gefährdet.
• Nur noch 30 Prozent des Managements glauben, dass sie innovativ sind; im Jahr zuvor waren es noch 40 Prozent.

Bezüglich der Produktivität im Home-Office sind die Ergebnisse der Studien widersprüchlich. Laut der Microsoft-Studie scheint die Befürchtung unbegründet, dass die Produktivität sinken könne. Die meisten Team-Mitglieder konnten sich im Home-Office trotz der häuslichen Ablenkung besser konzentrieren. Für fast ein Viertel des Managements war es jedoch schwierig, die Produktivität zu kontrollieren und zu steuern. Diese Widersprüche lassen sich eventuell mit einem traditionellen Führungsmodell erklären, das die Anwesenheit am Arbeitsplatz mit Produktivität gleichsetzt. Wenn ihr Team in der Ferne arbeitet, mit E-Mail und Chat kommuniziert, ist die Arbeitszeit weniger gut zu kontrollieren. Übertriebenes Mikromanagement ist jedoch auch keine Lösung. Mehr als 60 Prozent des Managements geben an, dass sie Delegation und Förderung der Eigenverantwortung in Remote-Teams nicht beherrschen. Jedoch ist nicht nur für das Management das Messen und Fördern der Zusammenarbeit schwierig; auch die Team-Mitglieder sehen hier Probleme:

• fast ein Drittel fühlt sich weniger produktiv, wenn sie in großen Gruppen arbeiten
• fast ein Viertel hat Schwierigkeiten, rechtzeitig Informationen von Kollegen zu erhalten
• fehlende Schulungen verschärfen die Probleme noch weiter

Sowohl Team-Mitglieder als auch das Management äußern, nicht auf die Arbeit aus der Ferne vorbereitet zu sein, sowohl in Bezug auf geeignete Werkzeuge als auch auf Soft-Skills, wie Einfühlungsvermögen und Delegation von Verantwortung. Nur 41 Prozent der Team-Mitglieder seien nach Angaben des Managements für Telearbeit geschult.

Die Umfrageergebnisse legen nahe, dass Team-Mitglieder sich subjektiv als zu wenig produktiv empfinden und dies durch längere Arbeitszeiten zu kompensieren versuchen. Dies kann zu Burnout führen, zumal das Management den psychischen Zustand einzelner Team-Mitglieder aus der Ferne schlechter beurteilen kann. Für fast 30 Prozent der befragten Team-Mitglieder ist es bei Remote-Work schwieriger geworden, eine nachhaltige Work-Life-Balance aufrechtzuerhalten, und über die Hälfte fühlt sich erschöpft und nicht in der Lage, ihre Work-Life-Balance richtig zu managen.

Geht im Home-Office der Teamgeist verloren?

Wenn das Team nicht mehr im Büro zusammenkommt, kann der Teamgeist schnell verloren gehen, die Beziehungen schwächer werden und das gegenseitige Vertrauen sinken. Für fast 40 Prozent des Managements und fast 50 Prozent der Team-Mitglieder ist es eine Herausforderung, aus der Ferne zu arbeiten und den Zusammenhalt im Team und das Zugehörigkeitsgefühl aufrechtzuerhalten. Mehr als einem Drittel des Managements fällt es schwer, durch die physische Trennung den persönlichen Kontakt zu Team-Mitgliedern aufrechtzuerhalten.

Das Onboarding neuer Team-Mitglieder ist unter Home-Office-Bedingungen besonders schwierig. Obwohl viele Unternehmen gut dokumentierte Onboarding-Routinen haben, ist der informelle persönliche Kontakt nicht zu unterschätzen. Remote wird das Onboarding und Coaching neuer Team-Mitglieder daher zu einer besonderen Herausforderung. Darunter kann auf Dauer die Unternehmenskultur leiden, da neue Team-Mitglieder dann andere Werte und Arbeitsweisen entwickeln.

Wie kann die Zusammenarbeit aus der Ferne aussehen?

Zunächst erfordert das Arbeiten im Home-Office ein Umdenken beim Management. Den Team-Mitgliedern muss sehr viel mehr Raum für Eigenverantwortung und Selbstorganisation gelassen werden. Agile Arbeitsmethoden, wie sie in der Softwareentwicklung schon seit Jahren praktiziert werden, und Lean Management könnten als Blaupause für eine neue Arbeitsorganisation dienen. Elemente agiler Praktiken sind tägliche Stand-up-Meetings – wobei das Stehen soll die Sitzungen kurz und prägnangt halten soll. Die täglichen Selbstverpflichtungen ermöglichen den Team-Mitgliedern eine bessere Einschätzung der potenziellen Herausforderungen und der Koordination zeitaufwändiger Probleme. Bei der Sprint-Planung werden die Ziele für die nächsten Wochen gemeinsam festgelegt. Dabei ist das Kanban-Boards ein wertvolle Werkzeuge nicht nur für die Planung sondern auch den Sprint-Fortschritt sichtbar zu machen.

Kanban-Board

Diese Methoden und Werkzeuge lassen sich problemlos in die digitale Arbeitswelt des Home-Offices übertragen.

Wie lassen sich Remote Teams führen?

Die Boston Consulting Group (BCG) bezeichnet in ihrer Studie [4] die Remote-Führungskraft der Zukunft als inspirierend, fürsorglich und einfühlsam. Sie stellt die Eigenverantwortung der Team-Mitglieder in den Mittelpunkt und fördert Empowerment und Teamarbeit. In ihrer Studie stellt BCG jedoch fest, dass die Entwicklung einer fürsorglichen Führung noch nicht überall Wirklichkeit geworden ist. 69 Prozent der befragten Führungskräfte gaben an, dass es zu ihren Aufgaben gehört, Teams zu befähigen und Hindernisse aus dem Weg zu räumen. Ein Drittel glaubt jedoch, dass sie ihren Teams Ziele nicht klar kommunizieren. Und ein Viertel gibt zu, dass sie ihre Teams nicht ermutigen, selbst neue Perspektiven zu entwickeln. Dem Management ist durchaus bewusst, dass Telearbeit besondere Anforderungen stellt. Auf die Frage, welche Fähigkeiten sie noch nicht beherrschen, hoben mehr als 60 Prozent die Schaffung einer starken Teamkultur hervor. 57 Prozent gaben an, dass sie Verantwortung nur schlecht delegieren können und Schwierigkeiten haben, ihre Team-Mitglieder in die Lage zu versetzen, die zugeteilten Aufgaben zu erledigen. Diese Kompetenzlücke ist möglicherweise noch größer, als es dem Management bewusst ist. Die befragten Team-Mitglieder betrachten den Führungsstil ihres Managements nämlich noch kritischer:

• Nur ein Drittel der Team-Mitglieder ist der Meinung, dass ihr Management Misserfolge toleriert.
• Nur die Hälfte hat das Gefühl, dass ihr Management ihnen die nötigen Informationen und Kompetenzen gibt, damit sie ihre Arbeit machen können.
• Ebenfalls die Hälfte der Team-Mirglieder gibt an, dass das Management sie bei wichtigen Entscheidungen nicht um ihre Meinung bittet.
• Und eine Mehrheit sagt, dass ihr Management keine sichere Umgebung schafft, in der sie ihre Meinung äußern können.

Es ist also noch einiges zu tun, um offene Informations- und Feedback-Prozesse in den Unternehmen zu etablieren. Die Unternehmen werden in ihre Führungskräfte investieren müssen, damit diese in der Lage sind, die neuen Remote-Werte wie Eigenverantwortung, Verantwortlichkeit, Vertrauen und Empathie zu vermitteln und zu stärken.

Die blinden Flecken der Studie

Die Studien von Microsoft und dem Leibniz-Zentrum für Europäische Wirtschaftsforschung (ZEW) zeichnen ein differenziertes Bild der Erfahrungen, die Menschen im Home-Office gemacht haben. Die Boston Consulting Group (BCG) ergänzt dieses Bild um detaillierte Vorschläge für eine Strukturierung neuer Arbeitsmodelle und einer neuen Führungskultur im digitalen Zeitalter. Es gibt aber auch blinde Flecken. Fragen, die die unternehmenseigene IT-Abteilung, die Aufgaben der eigenen IT-Mitarbeiter und damit die digitale Souveränität des Unternehmens betreffen, werden ebenso ausgeklammert wie Fragen einer nachhaltigen Entwicklung der eigenen IT-Infrastruktur. Da zu Beginn der Pandemie ganz schnell Entscheidungen getroffen werden mussten, haben viele Unternehmen vermutlich zur nächstbesten Cloud-Lösung gegriffen, ohne zu bedenken, ob dies langfristig zu verantworten ist. Durch die Nutzung von Cloud-Lösungen entstehen neue Abhängigkeiten, die die digitale Souveränität eines Unternehmens schmälern können. Die Führungskräfte in den IT-Abteilungen der Unternehmen stehen momentan vor einer besonders großen Herausforderung. Wenn sie auf die von großen Konzernen angebotenen Cloud-Lösungen setzen, arbeiten sie im Grunde daran, ihre eigene Abteilung im Großen und Ganzen überflüssig zu machen. Setzen Sie stattdessen auf On-premise-Lösungen müssen sie gegenüber der Geschäftsführung den erhöhten Personalbedarf und unter Umständen Verzögerungen durch eigene Anpassungsleistungen rechtfertigen. Die Souveränität über die eigenen Daten und die Nachhaltigkeit der eigenen IT sind fürs Management oft eine abstrakte Größe, die sich erst dann mit Leistungskennzahlen messen lässt, wenn die Abhängigkeit des Unternehmens von einem einzigen Cloudanbieter so groß geworden ist, dass die Risiken, die sich daraus für das Unternehmen ergeben, nicht mehr zu übersehen sind. In der Regel ist es dann aber zu spät, um ohne erneute Investitionen umzuschwenken. Immer mehr Unternehmen werden sich dieser Gefahr aber bewusst. Sobald die Pandemie im Sommer letzten Jahres etwas abklang, haben die Unternehmen von ihren Beschöftigten wieder mehr Präsenz im Büro eingefordert. Der Grund für diesen schnellen Ausstieg aus dem Home-Office war sicher nicht nur die Furcht vor dem Verlust von Produktivität, Innovation und Teamgeist. Viele Unternehmen werden es bereut haben, beim überstürzten Wechsel ins Home-Office zur erstbesten Cloud-Lösung gegriffen zu haben. Was sollen die IT-Verantwortlichen in den Unternehmen jetzt tun? Wie kann Remote-Work auch auf Dauer gelingen, ohne dass die Kontrolle über die eigenen Daten verloren geht?

Auf dem Weg zu einer nachaltigen IT

Das neue Management-Paradigma muss natürlich durch eine entsprechende technische Infrastruktur unterstützt werden. Dazu gehören einerseits technische Werkzeuge wie eine sinnvolle Ausstattung mit mobilen und stationären Geräten, Kollaborationssoftware wie Videokonferenzen und andere Kommunikations-Tools, Software für Projekt- und Workflow-Management sowie Lernlösungen und soziale Netzwerke für den informellen Austausch. Andererseits benötigen Remote-Worker eine leistungsfähige, technologische Infrastruktur für Berechnungen und Speicherung.

In dieser Hinsicht wirkte Corona wie ein Katalysator und beschleunigte die Entwicklung. Die Zahl der täglich Aktiven auf Kollaborationsplattformen hat sich mehr als verdreifacht. Dreißig mal so viele Personen nahmen täglich an Videokonferenzen teil. Der Absatz von Notebooks für Unternehmen stieg im zweiten Quartal 2020 um mehr als 70 Prozent gegenüber dem gleichen Quartal 2019 [5].

Um sicherzustellen, dass die Vorteile der hybriden Arbeit ihre potenziellen Nachteile überwiegen, sollten Unternehmen einen kohärenten und gut organisierten Weg in die Zukunft der Arbeit einschlagen. Dazu ist eine übergreifende Strategie erforderlich, die die IT-Verantwortlichen in den Unternehmen von ihrer Geschäftsführung einfordern sollten.

Vendor Lock-in und Unterfinanzierung vermeiden

Bei der Umsetzung einer Remote-Work-Strategie sollten die IT-Verantwortlichen immer wieder an ihre Führungskräfte appellieren, nicht in die Falle der Unterinvestition zu tappen. Die BCG-Umfrage zeigt, dass Unternehmen sehr unterschiedliche Beträge für Remote-Working-Technologie ausgeben. Der Durchschnitt liegt zwar bei 533 € pro Mitarbeiter, aber mehr als ein Viertel gibt weniger als 100 € pro Mitarbeiter aus und nur 20 Prozent mehr als 750 €. Unternehmen, die sich von den wirtschaftlichen Auswirkungen der Pandemie erholen müssen, könnten versucht sein, als erstes die Kosten zu senken. Dabei sind Management und Angestellte gleichermaßen besorgt über zu geringe Investitionen – nur 43 Prozent der Angestellten, die Remote arbeiten, haben das Gefühl, dass ihr Unternehmen ihnen alle für die Arbeit erforderlichen Tools zur Verfügung stellen, und nur 27 Prozent des Managements sind der Meinung, dass sie über alle Technologien verfügen, um ihre Teams zu managen. In jedem Fall sollten Unternehmen daran interessiert sein, Vendor Lock-ins beim Aufbau ihrer Remote-Work-Infrastruktur weitestgehend zu vermeiden. Sie sollten darauf achten, dass die eingesetzten Lösungen ihren individuellen Anforderungen entsprechend angepasst werden können. Sie müssen also erweiterbar sein. Erweiterbarkeit kann am einfachsten durch die Verwendung offener Datenformate und offener Schnittstellen erreicht werden. Nur offene, anpassbare und erweiterbare Lösungen gewährleisten das notwendige Maß an Nachhaltigkeit, das Unternehmen von einer größeren Investition erwarten. Unternehmen, die ihren Angestellten Home-Office-Arbeitsplätze anbieten, sollten ferner sicherstellen, dass sie in jedem Fall die Souveränität über ihre Daten behalten. Unter diesem Gesichtspunkt verbietet sich im Grunde die Nutzung von Cloudlösungen großer US-Konzerne wie Amazon, Microsoft oder Google, selbst dann, wenn diese auf dem Papier die Einhaltung der europäischen Datenschutz-Grundverordung (EU-DSGVO) versprechen. Open-Source-Software, offene Schnittstellen und Datenformate gewährleisten nicht nur mehr Datensouveränität und Nachhaltigkeit, mit ihnen können auch Geschäftsprozesse realisiert werden, die wirklich zum Unternehmen passen. Für die vielfältigen vernetzten Services sollten IT-Dienstleister ausgesucht werden, mit denen eine Zusammenarbeit auf Augenhöhe möglich ist, anstatt unternehmenskritische Dienste an global agierende Konzerne auszulagern.

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

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]

Meldet euch

Ich berate euch gerne und erstelle ein passgenaues Angebot für die Migration von Microsoft 365 zu OpenSource-Alternativen.

Ich rufe euch auch gerne an!

Jetzt anfragen

Kein Wachstum ohne Vertrauen

Die International Data Corporation (IDC) beschäftigte sich in ihrem European Data Market Monitoring Tool Report [2] mit der Frage, welche Auswirkungen ein Klima des Vertrauens auf die euroopäische Datenwirtschaft hat. Sie bilden drei unterschiedliche Szenarien ab, wobei sie als bedeutendsten Faktor die politischen Rahmenbedingungen, genauer Datenschutz und Privatsphäre, den gemeinsamen digitale Markt und Offenheit, Standardisierung und Interoperabilität von Daten sehen. Sie erwarten das größte Wachstum bei einer weltweit gültigen DSGVO. So wird klar: Nicht die Daten sind das Öl des digitalen Zeitalters, nein, es ist das Vertrauen.

Einschneidend – die Corona-Warn-App

Als mit der Coronapandemie die Bundesregierung und das Robert-Koch-Institut die Einführung einer Contact-Tracing-App beschlossen, rückte der Datenschutz in das Bewusstsein der breiten Bevölkerung: viele fürchteten, als COVID-19-Patienten stigmatisiert zu werden, wenn diese Information an staatliche Stellen weitergegeben würde. Ein verbreitetes Misstrauen der Bevölkerung gegen die Corona-Warn-App hätte den Erfolg der Maßnahme im Keim erstickt. Denn um Ansteckungsketten wirksam zu unterbrechen, müssen möglichst viele Menschen eine Tracing-App benutzen. So stellte sich plätzlich eine völlig neue Frage: Wie können wir die Software so gestalten, dass ausreichend viele Menschen der App vertrauen und sie tagtäglich benutzen?

Im April veröffentlichte der Chaos Computer Club zehn Prüfsteine für die Beurteilung von Contact-Tracing-Apps [3]. Zu den gesellschaftlichen Anforderungen gehören für den CCC Zweckgebundenheit, Freiwilligkeit und Diskriminierungsfreiheit, die Wahrung der Privatsphäre sowie Transparenz und Prüfbarkeit. Die technischen Anforderungen sind der Verzicht auf eine zentrale Entität, der vertraut werden muss, Datensparsamkeit, Anonymität, keine Verkettung mit persönlichen Daten, Bewegungs- und Kontaktprofilen sowie die Vertraulichkeit der Kommunikation. Bundesregierung und RKI taten das einzig Richtige: sie hörten auf den Rat der Datenschützer und entschieden sich – entgegen der ursprünglichen Planung – für ein solches dezentrales und anonymes Verfahren. Das Vertrauen in die Corona-Warn-App endet erwartungsgemäß an den Grenzen der Betriebssysteme. Wer die technische Infrastruktur kontrolliert, hat die Macht. Und es erscheint immer noch fragwürdig, ob und wie europäische Datenschutzstandards jemals gegenüber den US-Konzernen durchgesetzt werden können.

Transparenz und Offenheit

Um in informierter Weise beurteilen zu können, ob ein Programm seinen Zweck erfüllt und keine versteckten Funktionen besitzt, muss der Quellcode öffentlich zugänglich sein. Um volle Transparenz zu gewährleisten, muss nicht nur der Quellcode des Programms öffentlich einsehbar sein, sondern auch sämtliche Bibliotheken, Protokolle und Schnittstellen, die ein Programm nutzt. Die gesamte Softwarearchitektur sollte dazu auf dem Open-Source-Modell aufbauen.

Privacy by Design, Dezentralität und Datenhoheit

Wenn die ersten beiden Forderungen erfüllt sind, kann die Öffentlichkeit entscheiden, ob ein Softwaresystem Privacy by Design bietet oder nicht. Eine vertrauenswürdige Software muss von Anfang an die Privatsphäre der Nutzer*innen schützen.

Kein blindes Vertrauen mehr

Jahrzehntelang haben die Nutzer*innen Software-Herstellern und Dienste-Anbietern blind vertraut. Dies ist heute anders:

Software muss sich unser Vertrauen verdienen. Die Zukunft gehört deshalb den transparenten Open-Source-Entwicklungsmodellen, die Privacy by Design und umfassenden Datenschutz gewährleisten.

– Veit Schiele, Gründer und Geschäftsführer der Cusy GmbH

Dokumentation erstellen und verwalten

Das GitLab Wiki kann als Dokumentationssystem verwendet werden. Wiki-Seiten können über eine benutzerfreundliche Weboberfläche oder Git für fortgeschrittene Benutzer*innen erstellt und verwaltet werden. Ein vollständiger Verlauf ist über die Versionsverwaltung mit Git gewährleistet.

Prozesse definieren und durchsetzen

GitLab bietet verschiedene Werkzeuge zum Durchsetzen von Prozessen, Standards, Überprüfungen und Genehmigungen:

• Genehmigungen für Merge-Requests können verwendet werden um die Überprüfung von Änderungen vor dem Zusammenführen zu erzwingen.
• Mit geschützten Entwicklungszweigen können Regeln zum Erstellen, Verschieben und Löschen festgelegt werden.
• Das Anforderungsmanagement kann über Issues, Labels und Relationen strukturiert ermöglicht werden wobei die Prozesse nachvollziehbar durchgesetzt und überprüft werden können.

Softwarevalidierung nach ISO 13485

Für die Validierung der QM-Software müssen Verfahren zur Bewertung erstellt werden. GitLab erleichtert dies über Vorlagen, innerhalb der ihr Formulare und andere Dateien hochladen sowie Aufgabenlisten und vieles mehr erstellen könnt. Alle Aktionen, auch das Ändern der Beschreibung oder Kommentieren, werden protokolliert.

Aufgabenlisten und Kanban-Boards bieten eine einfache Möglichkeit zum Organisieren der Validierung.

Prozesssteuerung

Softwareentwicklungspläne und -prozesse könnt ihr mit dem GitLab Wiki erstellten, verwalten und referenzieren. Es kann als umfassendes Dokumentationssystem verwendet werden um Eure Pläne und Prozesse nahtlos während des gesamten Lebenszyklus der Softwareentwicklung referenzieren und integrieren zu können.

Anforderungsmanagement

Für System-, Entwicklungs- und Kundenforderungen können Vorlagen erstellt und einfach in den Entwicklungsprozess einbezogen werden. Aufgabenlisten und Kanban-Boards bieten sowohl Developers wie auch Reviewers einfache Möglichkeiten, Aufgaben planen und nachverfolgen zu können.

Zur Durchsetzung von Anforderungen und Coding-Standards könnt ihr mit Merge Reuqests ein Genehmigungsverfahren verwenden, das nur berechtigten Prüfer*innen das Zusammenführen der gemachten Änderungen erlaubt. Mithilfe geschützter Zweige könnt ihr detaillierte Berechtigungen festlegen, wer wo Änderungen vornehmen darf.

GitLab als Service-Desk konfiguriert erlaubt die Interaktion mit Kund*innen und externen Stakeholdern um Feedback von ihnen zu erhalten und mit ihnen interagieren zu können.

Rückverfolgbarkeit

Die Rückverfolgung lässt sich über Labels und Relationen zwischen Problemen über den gesamten Lebenszyklus der Softwareentwicklung aufrechtzuerhalten. Labels erlauben nicht nur Aufgaben und Merge Requests erleichtern, auch kann durch Abonnieren einzelner Labels die Benachrichtigung gewährleistet werden.

Mit dem Aktivitätslog bleibt nachvollziehbar, wann welche Änderungen von wem vorgenommen wurden.

Risikomanagement

Jede Code-Änderung kann mit Statischer Code-Analyse automatisch auf Sicherheitslücken überprüft werden. Nach einem Scan wird direkt am Merge Request ein Bericht generiert, sodass die Rückverfolgbarkeit gewährleistet bleibt.

Wenn Risiken erkannt wurden, können die Bemühungen zur Beseitigung der Risiken mit Issues geplant und dokumentiert werden.

Richtlinienverwaltung

Einzuhaltende Regeln und Richtlinien können definiert werden, sowohl interne Unternehmensrichtlinien als auch auf rechtlichen oder regulatorischen Rahmenbedingungen beruhende Richtlinien wie DSGVO, SOC2, PCI-DSS, SOX, HIPAA, ISO, COBIT, FedRAMP usw. GitLab stellt hierfür folgende Funktionen zur Verfügung:

Feingranulare Benutzerrollen und Berechtigungen

GitLab unterstützt fünf verschiedene Rollen mit unterschiedlichen Berechtigungen

Compliance-Einstellungen

Für verschiedene Projekte können unterschiedliche Compliance-Richtlinien festgelegt werden.

Inventar

Alle Aktionen werden inventarisiert.

Automatisieren der Compliance-Workflows

Sobald die Richtlinien und Regeln festgelegt sind, können die Prozesse automatisiert werden, z.B. durch

Projektvorlagen

Projektvorlagen mit bestimmten Prüfprotokollen und Prüfpfaden, wie z.B. bei HIPAA, können erstellt werden.

Projekt-Label

Je nach Richtlinie lassen sich unterschiedlich Label für Projekte und Aufgaben vordefinieren.

Audit-Management

Compliance-Audits erfordern die Nachvollziehbarkeit verschiedener Ereignisse wie z.B. Benutzeraktionen, Änderungen an den Berechtigungen oder Genehmigungen.

Welchen Nutzen haben Software-Reviews?

Software-Reviews führen zu deutlich weniger Fehlern. Laut einer Untersuchung an 12-Tsd. Projekten durch Capers Jones [1] reduzieren sich diese

• bei Requirements Reviews um 20–50%
• bei Top-level Design Reviews um 30–60%
• bei detaillierten funktionellen Design Reviews um 30–65%
• bei detaillierten logischen Design Reviews um 35–75%

Die Studie kommt zu dem Ergebnis:

Schlechte Code-Qualität ist bis zum Ende der Code-Phase billiger; danach ist hohe Qualität billiger.

Dabei geht die Studie noch von einem klassischen Wasserfall-Modell aus von Anforderungen über Software-Architektur zunächst zu Code, dann zu Tests und Betrieb. Bei agiler Software-Entwicklung wiederholt sich dieser Prozess jedoch in vielen Zyklen, sodass wir beim Entwickeln der Software die meiste Zeit damit verbringen, die vorhandene Code-Basis zu ändern oder zu ergänzen. Daher müssen wir nicht nur die Änderungsanforderungen verstehen sondern auch den bereits vorhandenen Code. EIne bessere Code-Qualität erleichtert uns, die Funktionen unserer Anwendung zu verstehen und zu erkennen, wie die Änderungen sinnvoll umgesetzt werden. Wenn Code gut in separate Module unterteilt ist, kann ich mir viel schneller einen Überblick verschaffen als bei einer großen monolithischen Code-Basis. Weiter kann ich bei einer klaren Benennung schneller verstehen, was verschiedene Teile des Codes bewirken ohne ins Detail gehen zu müssen. Je schneller ich den Code verstehe und die gewünschte Änderung umsetzen kann, umso weniger Zeit benötige ich für die Umsetzung. Verschärfend kommt hinzu, dass sich die Wahrscheinlichkeit erhöht, dass ich einen Fehler mache. Um solche Fehler zu finden und zu beheben geht weitere Zeit verloren. Diese zusätzlichen Zeitaufwände werden üblicherweise als technische Schulden verbucht.

Umgekehrt kann ich vielleicht einen schnellen Weg finden, um eine gewünschte Funktion bereitzustellen, die jedoch den über die vorhandenen Modulgrenzen hinausgeht. Eine solche quick and dirty-Implementierung erschwert jedoch in den kommenden Wochen und Monaten die Weiterentwicklung. Auch bei agiler Software-Entwicklung ohne angemessene Code-Qualität können die Fortschritte nur am Anfang schnell sein, je länger kein Review stattfindet umso zäher wird die Weiterentwicklung sein. In vielen Diskussionen mit erfahrenen Kolleg*innen war die Einschätzung, dass bereits nach wenigen Wochen regelmäßige Reviews und Refactorings zu einer höheren Produktivitiät führen.

Welche Review-Arten lösen welche Probleme?

Es gibt unterschiedliche Möglichkeiten ein Review durchzuführen. Diese sind abhängig vom Zeitpunkt und den Zielen des Reviews.

Die Norm IEEE 1028 [2] legt die folgenden fünf Review-Arten fest:

Walkthroughs

Mit dieser statischen Analysetechnik entwickeln wir Szenarien und machen Probeläufe um z.B. Anomalien in den Anforderungen sowie alternative Implementierungsmöglichkeiten zu finden. Sie dienen uns zum besseren Verständnis des Problems, sie müssen jedoch nicht zu einer Entscheidung führen.

Technische Reviews

Diese fachlichen Prüfungen führen wir durch, um z.B. in Diskussionen alternative Software-Architekturen zu bewerten, Fehler zu finden oder technische Probleme zu lösen und zu einer (Konsens-)Entscheidung zu kommen.

Inspektionen

Diese formale Review-Technik nutzen wir z.B. um schnell Widersprüche in den Anforderungen, falsche Modulzuordnungen, ähnliche Funktionen o.ä. zu finden und diese möglichst frühzeitig beseitigen zu können. Häufig führen wir solche Inspektionen beim Pair-Programming durch wodurch zusätzlich noch weniger erfahrene Entwickler*innen schnell und praktisch geschult werden.

Audits

Häufig erstellen wir vor der Inbetriebnahme einer Kundensoftware in den Betrieb eine Bewertung ihres Software-Produkts in Bezug auf Kriterien wie Walk-Through-Berichte, Software-Architektur, Code- und Security-Analyse sowie Testverfahren.

Management-Reviews

Diese systematische Bewertung von Entwicklungs- oder Beschaffungsprozessen verwenden wir um einen Überblick über den Projektfortschritt zu erhalten und mit etwaigen Zeitplänen abzugleichen.

Kundenstimmen

»Vielen Dank für die gute Arbeit. Wir sind sehr zufrieden mit dem Ergebnis!«

– Niklas Kohlgraf, Projektmanagement, pooliestudios GmbH

Meldet euch

Lasst euch noch heute zu Software-Reviews von cusy beraten:

Ich rufe euch auch gerne zurück!

Jetzt anfragen

Meldet euch

Auch wenn ihr noch nicht Kunde von uns seid, berate Ich euch gerne und erstelle ein passgenaues Angebot für die Migration eurer Atlassian-Server.

Ich rufe euch auch gerne an!

Jetzt anfragen

Vorteile

Die Vorteile von GitLab CI/CD gegenüber Jenkins sind:

Nahtlose Integration

Das in GitLab integrierte CI/CD bietet einen vollständigen DevOps-Workflow, der sich nahtlos in das GitLab-Ökosystem einfügt.

Bessere Sichtbarkeit

Die bessere Integration führt auch zu mehr Transparenz über Pipelines und Projekte hinweg, sodass Teams fokusiert bleiben können.

Niedrigere Betriebskosten

Jenkins erfordert erhebliche Aufwände in Wartung und Konfiguration. GitLab hingegen bietet Code-Review und CI/CD in einer einzelnen Anwendungen.

Erste Schritte

Migrationen von Jenkins zu GitLab müssen jedoch nicht beängstigend sein. Viele Projekte wurden bereits von Jenkins zu GitLab CI/CD gewechselt, und es stehen etliche Hilfsmittel bereit um den Übergang zu erleichtern, z.B.:

• Jenkins-Dateien in GitLab CI/CD ausführen

  Eine kurzfristige Lösung, die Teams bei der Migration von Jenkins auf GitLab CI/CD verwenden können, ist die Verwendung von Docker, um eine Jenkins-Datei in GitLab CI/CD auszuführen, während nach und nach die Syntax aktualisiert wird. Dies behebt zwar nicht die externen Abhängigkeiten, bietet jedoch bereits eine bessere Integration in das GitLab-Projekt.

• Auto DevOps verwenden

  Möglicherweise kann Auto DevOps zum Erstellen, Testen und Bereitstellen Eurer Anwendungen verwendet werden, ohne dass eine spezielle Konfiguration erforderlich ist. Eine der aufwändigeren Aufgaben der Jenkins-Migration kann das Konvertieren der Pipelines von Groovy zu YAML sein; Auto DevOps bietet jedoch vordefinierte CI/CD-Konfigurationen, die in vielen Fällen eine passende Standard-Pipeline erstellen. Auto DevOps bietet weitere Funktionen wie Sicherheits-, Leistungs- und Codequalitätstests. Schließlich könnt ihr einfach die Vorlagen ändern wenn ihr weitere Anpassungen benötigt.

Best Practices

• Fangt klein an!

  Die oben angegebenen Erste Schritte erlauben Euch, inkrementelle Änderungen vorzunehmen. So könnt ihr kontinuierlich Fortschritte in eurem Migrationsprojekt erzielen.

• Nutzt die Werkzeuge effektiv!

  Mit Docker und Auto DevOps stehen Euch Werkzeuge zur Verfügung, die den Übergang vereinfachen.

• Kommuniziert transparent und verständlich!

  Haltet das Team über den Migrationsprozess auf dem Laufenden und teilt den Projektfortschritt mit. Strebt auch klare Jobnamen an und gestaltet Eure Konfiguration so, dass sie einen möglichst guten Überblick gibt. Schreibt ggf. Kommentare für Variablen und schwer verständlichen Code.

Meldet euch

Ich berate euch gerne und erstelle ein passgenaues Angebot für die Migration eurer Jenkins-Pipeline zu GitLab CI/CD.

Ich rufe euch auch gerne an!

Jetzt anfragen

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:

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.

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.

Paukenschlag mit Ansage

Während der Uraufführung der Symphonie Nr. 94 im Jahr 1792 weckte Haydn das verwöhnte Londoner Publikum im Andante des zweiten Satzes an einer besonders leisen Stelle mit einem lauten Paukenschlag plötzlich aus seinem Dämmerschlaf. Seitdem trägt das Musikstück den Beinamen ›Paukenschlagsymphonie‹.

Musikliebhaber, die heute in ein Haydn-Konzert gehen, sind natürlich vorbereitet, sodass der Effekt verpufft. Überraschungsmomente in der Kunst nutzen sich schnell ab. In der IT-Branche ist das offensichtlich nicht so, denn der Paukenschlag, mit dem der EuGH kürzlich das Privacy Shield kippte, scheint Politik und Wirtschaft völlig unvorbereitet getroffen zu haben. Dabei hat es schon einmal geknallt, als das oberste europäische Gericht vor fünf Jahren den Vorgänger vom Privacy Shield, das Safe-Harbour-Abkommen, für ungültig erklärt hatte.

Der neue Paukenschlag kam mit langer Ansage. Denn als am 12. Juli 2016 Privacy Shield in Kraft trat, warnten Datenschützer davor, sich auf dieses Abkommen zu verlassen. Im Cusy-Blog schlossen wir uns damals den Bedenken der Datenschützer an: »Man kann also davon ausgehen, dass Datenschützer auch gegen ›Privacy Shield‹ vor dem Europäischen Gerichtshof klagen werden. Eine dauerhafte Rechtssicherheit für Unternehmen, die personenbezogene Daten in die USA transferieren, zeichnet sich erst einmal nicht ab.«

Standardvertragsklauseln keine sichere Alternative

Während der EuGH den Privacy-Shield ins Nirwana beförderte, stellte er im gleichen Urteil fest, »dass die Prüfung des Beschlusses 2010/87 über Standardvertragsklauseln anhand der Charta der Grundrechte der Europäischen Union nichts ergeben hat, was seine Gültigkeit berühren könnte.« Unternehmen, die Daten ihrer Kunden in die USA transferieren, können also mit ihren Geschäftspartnern auch weiterhin Standardvertragsklauseln abschließen.

Allerdings, so betont Dr. Ingemar Kartheuser in der Legal Tribune Online, könnten die betroffenen Kunden und Mitarbeiter dieser Unternehmen »sich im Zweifelsfall an die zuständige lokale Datenschutzbehörde wenden, die unter Umständen US-Datentransfer des betreffenden Unternehmens untersagen könnte.« Susanne Dehmel aus der Bitkom-Geschäftsleitung befürchtet laut Spiegel Online sogar, dass die Praxis der Standardvertragsklauseln ins Wanken gerät.

Rechtssicherheit gibt es nur, wenn persönliche Daten in Europa bleiben

Allerorten wird nun die Rechtsunsicherheit beklagt, die sich für deutsche Unternehmen aus dem Urteil ergeben. Dabei ist eine solide und nachhaltige Lösung dieser Frage offensichtlich und naheliegend. Die Daten europäischer Bürger sollten in europäischen Rechenzentren gespeichert werden, solange ihre Verarbeitung in den USA (z.B. bei der Buchung eines Hotels) nicht zwingend erforderlich ist.

Der dritte Paukenschlag in ein paar Jahren sollte jedenfalls niemanden mehr überraschen. Ganz egal, unter welchem klingenden Namen die EU-Kommission einen Nachfolger für den Nachfolger aus dem Hut zaubert, ihn wird das gleiche Schicksal ereilen wie Safe Harbour und Privacy Shield, denn die grundsätzlichen Auffassungen von Datenschutz klaffen diesseits und jenseits des Atlantiks immer noch weit auseinander.

In der Politik scheint diese Erkenntnis auch langsam angekommen zu sein. So empfiehlt Bundesjustizministerin Christine Lambrecht, wie Spiegel Online berichtet, europäischen Unternehmen, Daten europäischer Bürger auf europäischen Servern zu speichern.

Update 24. August 2020

Der Landesbeauftragte für den Datenschutz und die Informationsfreiheit Baden Württemberg hat heute die Orientierungshilfe: Was jetzt in Sachen internationaler Datentransfer? (LfDI-BW-Orientierungshilfe-zu-Schrems-II.pdf) vorgelegt:

Im Zentrum des weiteren Vorgehens des LfDI Baden-Württemberg wird die Frage stehen, ob es neben dem von Ihnen gewählten Dienstleister/Vertragspartner nicht auch zumutbare Alternativangebote ohne Transferproblematik gibt.

Entwickler-Tools as a Service – datenschutzkonform aus Deutschland

Da durch moderne DevOps-Methoden Entwicklung und Betrieb immer enger zusammenwachsen, ist es ratsam, nicht erst im Produktivbetrieb von Software über den Datenschutz nachzudenken, sondern die gesamte agile Entwicklungs-Pipeline datenschutzkonform aufzustellen.

Cusy bietet seiner Kundschaft eine datenschutzkonforme Entwicklungs- und Betriebsplattform für den gesamten Lebenszyklus ihrer Anwendungen. Die Plattform ist modular aufgebaut, ermöglicht Privacy by Design und lässt sich flexibel skalieren. Agile Softwareteams profitieren von einer sofort einsetzbaren, vollständigen Tool-Chain: vom ersten Entwurf über das Projektmanagement und die Code-Verwaltung bis hin zum Deployment und dem Produktivbetrieb. Alle Daten, sowohl personenbezogene Daten von Kunden und Mitarbeitern als auch Geschäftsgeheimnisse, werden sicher und zuverlässig in einem deutschen Rechenzentrum gespeichert.

Cusy DevOps Toolchain

Meldet euch

Lasst euch noch heute bei der datenschutzkonformen Ausrichtung eurer IT von cusy beraten, damit ihr seelenruhig abwarten könnt, wie die Konkurrenz auch beim dritten Paukenschlag noch heftig zusammenzuckt.

Wir rufen euch auch gerne an!

Jetzt anfragen

Datenbank-Berechtigungen

Eines der wesentlichen Ergebnisse ist, dass die Datenbank-Berechtigungen viel zu weitgehend sind, und ein erfolgreicher Angreifer auf alle Daten zugreifen, diese löschen usw. könnte. Den Einwand, dass ein Angreifer nie soweit kommen dürfe widerlegt er mit der Erfahrung, dass dies leider immer wieder passiere.

Das PostgreSQL-Login per Superuser postgres sollte daher immer nur über Unix-Domain-Sockets und über localhost erlaubt sein. Der Zugang mit Peer-Authentifizierung in der pg_hba.conf-Datei ist hingegen ok:

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             postgres                                peer
host    all             all             10.23.42.1/24           scram-sha-256

Da die Anwendung einen Datenbank-Superuser erhält, jedoch keine Datenbank konfiguriert wird, wird diese wohl automatisch angelegt. Dies hieße jedoch, dass der Prozess als Superuser ausgeführt werden müsste – eine ganz schlechte Idee. Die Datenbank sollte vom DBA mit Superuser-Rechten angelegt und anschließend so konfiguriert werden, dass sich nicht jeder (PUBLIC) damit verbinden kann:

CREATE DATABASE cwa;
REVOKE ALL ON cwa FROM PUBLIC;

Damit kann sich nur noch der Superuser mit der Datenbank cwa verbinden.

Falls eine Tabelle, wie z.B. V1__createTables.sql jedoch zunächst normal angelegt wurde, d.h. PUBLIC alle Rechte hat, sollten diese entzogen werden mit:

REVOKE ALL ON diagnosis_key FROM PUBLIC;
REVOKE ALL ON diagnosis_key FROM current_user;

Anschließend könnt ihr eine Rolle cwa_users mit den beiden Nutzern cwa_reader und cwa_inserter erstellen um zwischen lesenden und schreibenden Zugriffen unterscheiden zu können:

CREATE ROLE cwa_users;
CREATE USER cwa_reader IN ROLE cwa_users PASSWORD '…';
CREATE USER cwa_inserter IN ROLE cwa_users  PASSWORD '…';

Nun erhält die Rolle cwa_users zunächst CONNECT-Rechte und dann cwa_reader Lese- und cwa_inserter Hinzufügen-Rechte:

GRANT CONNECT ON DATABASE to cwa_users;
GRANT SELECT ON diagnosis_key TO cwa_reader;
GRANT INSERT ON diagnosis_key TO cwa_inserter;

Der cwa_reader-User kann jedoch damit zunächst alle Daten auf einmal lesen. Da dies jedoch nicht erforderlich ist, kann dieser Angriffspunkt durch eine Funktion beschnitten werden:

CREATE OR REPLACE FUNCTION get_key_data(in_id UUID)
    RETURNS JSONB
    AS 'SELECT key_data FROM diagnosis_key WHERE id = in_id;'
    LANGUAGE sql SECURITY DEFINER SET search_path = :schema, pg_temp;

Anschließend wird die Funktion cwa_owner zugewiesen, cwa_reader und cwa_inserter die Berechtigungen entzogen und schließlich die Ausführung der Funktion cwa_reader erlaubt:

ALTER FUNCTION get_key_data(UUID) OWNER TO cwa_owner;
REVOKE ALL ON FUNCTION get_key_dataUUID) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION get_key_data(UUID) TO cwa_reader;

Damit kann cwa_reader also nur noch einen einzelnen Datensatz lesen.

id

Interessant in der Tabellen-Definition ist auch, dass die id als bigserial realisiert ist. Eine hochzählende Zahl könnte jedoch von Angreifern erraten werden. Daher dürfte der UUIDv4-Datentyp besser geeignet sein. Zur UUIDv4-Generierung kommt entweder die uuid-ossp-Erweiterung oder für PostgreSQL≥9.4 auch die pgcrypto-Erweiterung infrage, also entweder:

CREATE EXTENSION "uuid-ossp";
CREATE TABLE diagnosis_key (
  id uuid primary key default uuid_generate_v4() NOT NULL,
  …
);

oder:

CREATE EXTENSION "pgcrypto";
CREATE TABLE diagnosis_key (
  id uuid primary key default gen_random_uuid() NOT NULL,
  …
);

Zeitstempel

In der Tabellen-Definition von V1__createTables.sql werden Datum und Zeit in submission_timestamp als bigint, also als Zahl, gespeichert, und dies obwohl es auch einen TIMESTAMP-Datentyp gibt. Dies hätte den Vorteil, dass mit ihnen auch gerechnet werden kann, also z.B.:

SELECT age(submission_timestamp);
SELECT submission_timestamp - '1 day'::interval;

Außerdem könnten die Daten nach einer bestimmten Zeit gelöscht werden, z.B. nach dreißig Tagen mit:

DELETE FROM diagnosis_key WHERE age(submission_timestamp) > 30;

Das Löschen kann noch beschleunigt werden, wenn für jeden Tag mit der PostgreSQL-Erweiterung pg_partman eine eigene Partition erstellt wird.

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:
  • Mattermost Chat
  • Jitsi-Videokonferenzen
  • GitLab DevOps-Pipeline
• 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.

Wir rufen euch auch gerne an!

Jetzt anfragen

… für eure Büroarbeit

• Jitsi statt Google Hangout, Zoom oder Microsoft Teams
• Mattermost statt Slack
• Nextcloud und OnlyOffice statt Google Docs, Google Sheets, Google Slides, Google Calendar und Google Drive

… für eure Website

• Elasticsearch statt Google Suche
• Matomo statt Google Analytics
• TextCaptcha oder Securimage statt Google reCAPTCHA
• Eigener OpenStreetMap-Server und Leaflet statt Google Maps auf Websites
• Fonts selbst ausliefern mit Make Google Fonts local und Google-Webfonts Helper statt Google Fonts

… für eure Apps

• OSMand statt Google Maps
• ELK-Stack statt Google Crashlytics

Zum Weiterlesen

Telearbeit und Mobiles Arbeiten

Information des Bundesbeauftragten für den Datenschutz und die Informationsfreiheit (BfDI), Januar 2019

Top Tips for Cybersecurity when Working Remotely

Artikel der European Union Agency for Cybersecurity (ENISA), März 2020

Home-Office? – Aber sicher!

Information des Bundesamts für Sicherheit in der Informationstechnik (BSI), März 2020

Fachliche Qualität

Die fachliche Qualität der meisten Apps ist nur selten erkennbar und dürfte, wenn die wenigen Überprüfungen zugrundegelegt werden, meist sehr gering sein. Dies ist umso problematischer, wenn Apps versprechen, auf Wechselwirkungen und doppelte Verordnungen ähnlich wirkender Medikamente hinzuweisen. Für Kunden, die sich darauf verlassen, dass ihre App sie schon auf Gefahren, z.B. bei ihren Selbst­medikations­wünschen hinweisen wird, dürften massiv gefährdet sein.

Nutzergruppen

Die bereits existierenden Apps machen auch ganz selten Angaben zu ihren Nutzergruppen, weder zur

• Eignung für spezifische Erkrankungen/Leiden
• Eignung für Geschlecht, spezielle Altersgruppen (bzw. -bereiche) etc.
• Eignung für bestimmte Gesundheitsberufe bzw. Berufsgruppen und Settings: klinisch, ambulant, zu Hause, …
• Eignung bei physiologischen und körperlichen Beeinträchtigungen, auch nicht die Unterstützung für TalkBack für Android und VoiceOver für iPhone.
• Unterstützung länderspezifischer Arzneimittel und Packungsgrößen

Datenschutz

Auch der Umgang mit Nutzerdaten ist meist mangelhaft. Die Datenschutzerklärungen lassen Kunden meist im Unklaren, was mit ihren Angaben geschieht. Dies ist umso problematischer, da über 80% der Apps Daten an Infrastrukturanbieter wie Google, Facebook etc. übertragen. Noch nicht einmal die verschlüsselte Übertragung von Nutzerdaten war immer gewährleistet, dies vor allem dann nicht, wenn Daten per E-Mail übertragen werden. Die wenigen unabhängigen Testverfahren dürften hier kaum zu einer Klärung beitragen, da sie sich meist auf die Selbstauskunft verlassen.

Wie können die Gräben überwunden werden?

Notebooks erfreuen sich bei Data Scientists rasch wachsender Beliebtheit und werden zum De-facto-Standard für rapid Prototyping und explorative Analysen. Vor allem Netflix hat jedoch ein umfangreiches Ökosystem von zusätzlichen Tools und Services erstellt, wie z.B. Genie und Metacat. Diese Tools vereinfachen die Komplexität und unterstützen einen breiteren Anwenderkreis von Analysten über Wissenschaftler bis hin zu Informatikern. Im Allgemeinen hängt jede dieser Rollen von verschiedenen Tools und Sprachen ab. Oberflächlich betrachtet scheinen die Workflows unterschiedlich, wenn nicht komplementär zu sein. Auf einer abstrakteren Ebene jedoch haben diese Workflows mehrere überlappende Aufgaben:

Datenexploration

tritt früh in einem Projekt auf

Dies kann das Anzeigen von Beispieldaten, die statistische Profilerstellung sowie die Datenvisualisierung umfassen

Datenaufbereitung

iterative Aufgabe

kann das Bereinigen, Standardisieren, Transformieren, Denormalisieren und Aggregieren von Daten umfassen

Datenvalidierung

wiederkehrende Aufgabe

kann das Anzeigen von Beispieldaten, das Ausführen von Abfragen zur statistischen Profilerstellung und aggregierten Analyse sowie das Visualisieren von Daten umfassen

Produkterstellung

tritt spät in einem Projekt auf

Dies kann das Bereitstellen von Code für die Produktion, Schulungsmodelle und das Planen von Workflows umfassen

Ein JupyterHub kann hier schon gute Dienste leisten um diese Aufgaben möglichst einfach und überschaubar zu gestalten. Dabei ist es skalierbar und reduziert die Anzahl der Tools erheblich.

Um zu verstehen, warum Jupyter-Notebooks für uns so überzeugend sind, heben wir noch einmal ihre Kernfunktionalitäten hervor:

• Ein Messaging-Protokoll zum Prüfen und Ausführen von sprachunabhängigem Code
• Ein bearbeitbares Dateiformat zum Beschreiben und Erfassen von Code, Code-Ausgabe und Markdown-Notes
• Eine webbasierte Benutzeroberfläche zum interaktiven Schreiben und Ausführen von Code sowie zur Datenvisualisierung

Logging

Um Notebooks nicht nur für Rapid Prototyping sondern auch dauerhaft produktiv verwenden zu können, müssen bestimmte Prozesseereignisse protokolliert werden, sodass z.B. Fehler einfacher diagnostiziert und der Gesamtprozess überwacht werden kann. Hierfür kann in IPython Notebboks das logging-Modul der Python-Standardbibliothek oder loguru verwendet werden, s.a. Jupyter-Tutorial: Logging.

Tests

Es gab schon früher einige Ansätze, mit denen sich Notebooks automatisiert testen ließen, z.B. nbval, aber erst mit ipytest wurde das Schreiben von Tests für Notebooks deutlich vereinfacht, siehe auch Jupyter-Tutorial: ipytest.

Re­sü­mee

In den letzten Jahren förderten wir die enge Zusammenarbeit von Software Engineers mit Data Scientists um zu skalierbarem, wartbarem und produktionsfähigem Code zu gelangen. Gemeinsam haben wir Lösungen gefunden, die produktionsreife Modelle auch für Machine Learning-Projekte bereitstellen können.