Aktuell in CR

beAgate – Technischer Hintergrund und rechtliche Aspekte des beA-Ausfalls im Dezember 2017 (Möllers/Vogelgesang, CR 2018, 124)

Zum 1.1.2018 sollte die passive Nutzungspflicht des besonderen elektronischen Anwaltspostfachs für alle Anwälte gelten. Über die Weihnachtsfeiertage zwang allerdings ein Sicherheitsproblem die Bundesrechtsanwaltskammer zur Abschaltung der gesamten beA-Infrastruktur. Der Beitrag schildert zunächst die Ereignisse um die Abschaltung (I.) und erläutert sodann den technischen Hintergrund (II.). In rechtlicher Hinsicht wird das Schicksal der passiven Nutzungspflicht erläutert (III.). Schließlich werden die Alternativen der technischen Lösungsansätze mit ihren Vor- und Nachteilen aufgezeigt (IV.) und die Vorgaben zum State-of-the-Art für die Programmierung und den Umgang mit Zertifikaten ausgelotet (V.).

Inhaltsverzeichnis

 

  1. Zeitlicher Ablauf
  2. Technischer Hintergrund
    1. Software aus zwei Komponenten
    2. Kommunikation
    3. Problematische Einbindung der Inhalte über bealocalhost.de
      1. Erster gescheiterter Lösungsansatz
      2. Zweiter gescheiterter Lösungsansatz
  3. Passive Pflicht zur Nutzung des beA
  4. Technische Lösungsansätze
    1. Der „Plex“-Ansatz
    2. Kommunikation über den beA-Server
    3. Weitere Ansätze
      1. Programmierschnittstelle
      2. Autarke Software
  5. Zum technischen State-of-the-Art
    1. Programmiergrundsätze
    2. Umgang mit Zertifikaten
    3. Externe Sicherheitsüberprüfung

 

I. Zeitlicher Ablauf

Am 22.12.2017 teilte die BRAK mit, dass das beA aufgrund vereinzelt auftretender Verbindungsprobleme „am 23. und 24. Dezember sowie an den Weihnachtsfeiertagen für Wartungsarbeiten vom Netz“ genommen werde. Dies hatte zur Folge, dass ab diesem Zeitpunkt Nachrichten weder an das beA gesendet noch vom beA abgeholt werden konnten. Am gleichen Tag informierte die BRAK in einem Sondernewsletter darüber, dass ein für die beA-Anwendung notwendiges Zertifikat ab dem 22.12.2017 nicht mehr gültig sei. Um das beA weiterhin nutzen zu können sei es erforderlich, dass alle Anwälte vor der nächsten Nutzung des Systems ein zusätzliches – für den Kommunikationsaufbau zwischen Browser und beA-Anwendung notwendiges – Zertifikat installieren. Eine Installationsanleitung für das Zertifikat wurde von der Kammer ebenfalls online gestellt. Die Installation dieses Zertifikats nach dieser Anleitung öffnete allerdings eine Sicherheitslücke für jede andere Kommunikation über das Web und zwar unabhängig von der beA-Nutzung.

Aufgrund des gravierenden Sicherheitsrisikos riet die BRAK in ihrem Sondernewsletter vom 27.12.2017 allen betroffenen Anwälten dringend zu einer Deinstallation. Eine entsprechende Anleitung stellte sie online. Die Anleitung zur Installation des Zertifikats vom 22.12.2017 wurde zeitgleich von der Webseite der BRAK gelöscht.

In diesem Sondernewsletter gab die BRAK ebenfalls bekannt, dass das beA auch weiterhin offline bleiben müsse, da der Technologieentwickler des beA-Systems trotz intensiver Arbeiten das Zugangs- bzw. Verbindungsproblem bislang nicht habe lösen können. Die BRAK werde daher das beA-System erst wieder bereitstellen, wenn der technologische Dienstleister die Störungen vollständig behoben und einen sicheren Zugang gewährleistet hat.

Die BRAK beabsichtigt für die Wiederinbetriebnahme des beA derzeit einen zweiphasigen Prozess. In einem ersten Schritt will die BRAK die neue Client Security zum Herunterladen bereitstellen. Anschließend soll dann nach einer angemessenen Frist das beA wieder aktiv geschaltet werden. Konkrete Termine sollen rechtzeitig auf der Homepage der BRAK, der beA-Homepage und über Newsletter mitgeteilt werden.

Am 26.1.2018 veröffentlichte der Rechtsanwalt Carsten Hoenig eine E-Mail, in der ein neuer Lösungsansatz von Atos skizziert wurde. Demnach sei eine aktualisierte Version der Software verfügbar und einsatzbereit.

Im Rahmen des am selben Tag von der BRAK durchgeführten Dialogs beAthon wurde eine weitere, schwerwiegende Sicherheitslücke der alten Client Security öffentlich. Infolgedessen veröffentlichte die BRAK eine Pressemitteilung, in der sie dringend die Deinstallation oder Deaktivierung der installierten Software auf allen betroffenen Anwalts-PCs empfiehlt. Die Lücke sei jedoch in der neuen Version der Client Security bereits behoben. Markus Drenger hatte die Lücke bereits im Dezember der BRAK gemeldet. Diese wusste eigenen Angaben zufolge jedoch nicht um die von der Lücke ausgehenden Gefahr.

II. Technischer Hintergrund

Neben den Komponenten, welche auf Seiten der BRAK bzw. dem von ihr beauftragten Dienstleister Atos installiert sind und die „Server-Seite“ des beA darstellen, besteht die Software aus zwei miteinander interagierenden Bausteinen.

1. Software aus zwei Komponenten

Ein Teil wird in Form einer Webseite von Atos ausgeliefert und im Webbrowser (beispielsweise Firefox) des Anwalts angezeigt. Diese Komponente übernimmt die Anzeige des Postfachs sowie die Kommunikation mit dem beA-Webserver für den Austausch verschlüsselter beA-Nachrichten.

Parallel dazu installiert der Anwalt das Programm beA Client Security, welches den Datenaustausch mit der beA-Karte über das an den Rechner angeschlossene Lesegerät vornimmt.

2. Kommunikation

Um die Komponenten möglichst einfach zu halten und auf weitere Software wie etwa Browser-Add-Ons verzichten zu können, kommunizieren die Webkomponente und die Client Security über das reguläre HTTPS-Protokoll, welches auch für den Datenaustausch zwischen Webbrowser und beA-Webserver verwendet wird. Die Client Security startet hierzu einen lokalen Webserver auf dem Anwalts-PC.

Atos hat im Vorfeld die Domain bealocalhost.de registriert, welche auf die IP-Adresse 127.0.0.1 verweist – also den eigenen Rechner des Nutzers. Die beA-Webseite verweist dann auf Inhalte von dieser Domain – bealocalhost.de –, welche vom auf demselben Rechner laufenden Webserver der Client Security bedient werden können. Dieses Prinzip ist in Abbildung 1 dargestellt.

3. Problematische Einbindung der Inhalte über bealocalhost.de

Der bisher beschriebene Teil der Lösung stellt noch kein Sicherheitsrisiko dar. Problematisch ist aber die Einbindung der Inhalte des lokalen Webservers über die Domain bealocalhost.de. Da das beA selbst – also die Webseite bea-brak.de – per HTTPS verschlüsselt ausgeliefert wird, können nicht ohne weiteres Inhalte über unverschlüsselte Verbindungen nachgeladen werden. Dazu zählen auch Verbindungen zur Client Security über die Domain bealocalhost.de. Gängige Browser würden sonst die Verbindung blockieren und ggf. eine Warnung anzeigen.


Hier geht's direkt zum Aufsatz in juris PartnerModul IT-Recht:
Login für registrierte Kunden

Weiterlesen im CR Schnupperabo:
hier

Verlag Dr. Otto Schmidt vom 15.02.2018 10:09

zurück zur vorherigen Seite