An dieser Stelle finden Sie Informationen und Downloads zum Programmeinsatzverfahren.

Bei macsi handelt es sich um eine Client-Server Anwendung. Der Client läuft im Browser des Anwenders (Frontend) und stellt Anfragen an den Server (Backend). Der wiederum ermittelt mit Hilfe der zugrunde liegenden Datenbank die vom Frontend angeforderten Daten und liefert sie zurück. Jeder Übertragung zwischen Front- und Backend wird ein Token (eine definierte Kette aus Zeichen) mitgegeben, das bei der Anmeldung des Users vom Backend erstellt wird und u.a. den anfragenden User und die Sparkasse, zu der die angefragten Daten gehören müssen, verschlüsselt enthält. Diese Token sind in ihrer Gültigkeitsdauer beschränkt und müssen bei längeren Sitzungen regelmäßig vom Frontend erneuert werden. Gültige Token werden in der Datenbank gespeichert, bei Ablauf oder Abmeldung des Users aus der Datenbank gelöscht, und bei jedem Zugriff auf Gültigkeit geprüft. Somit kann zum einen das Backend jederzeit sicherstellen, dass nur Daten an das Frontend gegeben werden, auf die der angemeldete User zugreifen darf und die zu der Sparkasse, die dem User zugeordnet ist, gehören. Zum anderen kann selbst ein gestohlenes Token nicht nach Ablauf oder Abmeldung des berechtigten Users von einem Angreifer verwendet werden, um auf die Anwendung zuzugreifen.

Die produktive Anwendung wird bei axilaris auf einem Managed Server gehostet. Banking-Partner hat keinen Root-Zugriff auf dem Server sondern kann dort ausschließlich die gehostete Anwendung verwalten. Sicherheitsmaßnahmen, die den Server selbst und/oder das Rechenzentrum betreffen (Zugriffsschutz, Ausfallkonzept etc pp.) werden von axilaris gewährleistet, nicht von Banking-Partner. Axilaris ist dafür entsprechend zertifiziert.

Des Weiteren ist bei allen Anforderungen zu beachten, dass es sich bei macsi um eine Anwendung mit niedrigen Schutzbedarf handelt, da keinerlei personenbezogene Daten verwaltet werden. Alle Kundendaten werden pseudonymisiert gespeichert, so dass durch Dritte keine Rückschlüsse auf echte Personen erfolgen können. Allein dadurch fallen diverse Sollmaßnahmen als nicht relevant weg.

macsi verfügt über ein sehr fein definiertes Rechtemanagement, das Berechtigungen nach lesend und schreibend unterscheidet. Da in jeder Sparkasse ein User mit Administrationsrechten ausgestattet ist, die es erlauben, eigene User mit vorgefertigten Kombinationen von Rechten ("Rollen") anzulegen, erfolgt die Rechtevergabe sparkassenintern. Jede Sparkasse ist also selbst dafür verantwortlich, welcher Rechte ihre User erhalten. Durch die Einschränkung der Rollen, die einem Sparkassenadmin zur Verfügung stehen, ist sichergestellt, dass User der Sparkassen ausschließlich Daten ihres Hauses sehen.

Das impliziert natürlich auch die Trennung von Administrations- und Userrechten. Bei der Anlage einer neuen Sparkasse wird ein Sparkassen-User mit Administrationsrechten angelegt. Dieser kann neue User anlegen, aber seine eigenen Rechte nicht ändern. Er kann jedoch User mit Administrations- und Anwendungsrechten anlegen. Das liegt dann aber wieder in der Verantwortung der Sparkasse.

Reine Testaufgaben sind grundsätzlich nicht vorhanden, da Tests in einer anderen macsi-Instanz, nämlich auf dem von Domain Factory gehosteten Testserver stattfinden. Auf diesem befinden sich reine Testdaten.

Es gibt keine Gruppenaccounts. Die Accounts sind personenbezogen.

Es werden die Daten von verschiedenen Sparkassen in derselben Datenbank gehalten. Die Anwendung unterscheidet aber strikt danach, welcher User welcher Sparkasse zugeordnet ist und prüft bei jedem Zugriff, ob es sich um Daten "seiner" Sparkasse handelt. Jeder User kann nur einer Sparkasse zugeordnet werden. Da Banking-Partner Mitarbeiter üblicher Weise mehrere Sparkassen betreuen, kann ihnen Zugriff auf mehrere Sparkassen gewährt werden. Es findet allerdings auch hier eine ständige Überwachung der gerade bearbeiteten Daten statt, sodass niemals Daten verschiedener Mandanten gemischt werden. Das ist dadurch gewährleistet, dass bei jeder Kommunikation das Token, das bei der Anmeldung vom Backend erzeugt wurde, vom Frontend mitgegeben wird. In diesem Token sind sowohl der User mit seinen Rechten als auch die Sparkasse, auf die er zugreift, verschlüsselt. Sollte ein User berechtigt sein, die Daten mehrerer Sparkassen zu verwalten (das betrifft ausschließlich Banking-Partner-User), so wird bei jedem Sparkassenwechsel ein neues Token erzeugt und das alte gelöscht, so dass immer die aktuelle Sparkasse in dem Token verschlüsselt ist.

Jeder User muss sich mit seiner eMail-Adresse als Benutzernamen und einem frei zu vergebenden Passwort am System anmelden, bevor er im System arbeiten oder Daten einsehen kann. Die Anwendung selbst ist dabei nur aus dem FI-Netz erreichbar. Dies wird durch eine entsprechende Firewall beim Hoster axilaris sichergestellt.

Wird ein User angelegt, so wird ihm ein Initialpasswort an seine eMail-Adresse zugesandt. Dieses Passwort muss bei der ersten Anmeldung geändert werden. Vor Änderung des Initialpassworts kann nicht in macsi gearbeitet werden. Eine separate Bestätigung des Erhalts der Passwortmail muss durch den User nicht erfolgen. Das ist bei dem vorliegenden Schutzbedarf und den weiteren Maßnahmen der Zugriffsbeschränkung (Firewall, eingeschränkter Userkreis, kein User legt sich selbst an) auch nicht erforderlich.

Die Anforderungen an die Passwörter sind hinreichend dokumentiert (8 Zeichen Minimum, mindestens eine Ziffer, ein Klein- und ein Großbuchstabe). Da eine Anmeldung ausschließlich aus einem definierten Netzbereich erfolgen kann und ausschließlich pseudonymisierte Daten verwaltet werden, sind diese Anforderungen ausreichend. Ein regelmäßiger Passwortwechsel ist nicht erforderlich, da er eher dazu führt, dass unsichere Passwörter verwendet werden. Auch das BSI rät mittlerweile davon ab (Seite 4, unten).

Passwörter werden in einer separaten Tabelle der Datenbank als gesalzene Hashes gespeichert, aus denen das Passwort selbst nicht wieder hergeleitet werden kann. Dieses Verfahren ist als Standard-Verfahren in der IT etabliert und sicher. Eine Authentifizierung über den LDAP der FI ist grundsätzlich möglich, dazu fehlt macsi aber die Möglichkeit, mit dem LDAP zu kommunizieren.

Zum Login wird vom Frontend eine gängige Maske vorgehalten, in der der Username sichtbar und das Passwort verdeckt eingegeben wird. Fehlerhafte Authentisierungen werden in der Datenbank geloggt und dem User lediglich eine Information angezeigt, dass der Anmeldeversuch nicht erfolgreich war. Es erfolgt kein Hinweis auf den fehlerhaften Teil (Loginname, Passwort). Ein User wird nach dem 4. Fehlversuch automatisch gesperrt und muss wieder freigeschaltet werden. Davor kann er über einen "Passwort vergessen"-Button ein neues Passwort anfordern, das ihm wie das Initialpasswort an seine bekannte eMail-Adresse zugestellt wird. Auch dieses generierte Passwort muss umgehend geändert werden. Außerdem besteht die Möglichkeit einer Passwort-Recovery, über die eine temporär gültige Zifferkombination an die bekannte eMail des Users geschickt wird. Über diese Zahl kann der Zugang wieder freigeschaltet werden. Danach ist das Passwort umgehend neu zu setzen.

Alle Daten werden zwischen dem Browser des Users (Frontend) und dem bei axilaris gehosteten Backend über eine sichere HTTPS-Verbindung, mit TLS verschlüsselt, übertragen. Das notwendige Zertifikat kann über den Browser eingesehen werden und ist jeweils nur ein Jahr gültig.

Die Übertragung kann nur so sicher sein, wie der eingesetzte Browser, daher liegt der Großteil der Übertragungssicherheit auf Seiten des Users. Veraltete Browser (Internet Explorer) werden von der Anwendung abgewiesen. Eine zusätzliche Überprüfung der Versionsnummern des eingesetzten Browsers ist wenig zielführend, da insbesondere die ESR-Versionen von Firefox in der Versionsnummer der "regulären" Version deutlich hinterherhinken, sich aber auf demselben Patchlevel befinden. Außerdem ist der Zugriff auf die Anwendung über die Firewall nur aus dem FI-Netz möglich.

Jeder User wird bei erfolgreicher Anmeldung über seinen letzten erfolgreichen Login informiert und der Fehlerzähler wird zurückgesetzt. Fehlerhafte Logins werden in einer separaten Tabelle der Datenbank dauerhaft geloggt und können jederzeit von berechtigten Banking-Partner-Nutzern eingesehen werden. Erfolgreiche Authentifizierungen werden ebenfalls zur Nachverfolgung protokolliert, aber nach 30 Tagen wieder gelöscht.

Nach einer gewissen Zeit der Inaktivität erfolgt ein automatischer Logout. Dieser ist im Regelfall auf 30 Minuten eingestellt, während der Zeitmessung auf 120 Minuten. Jeder User ist selbst dafür verantwortlich, seinen Bildschirm bei Abwesenheit zu sperren und so unberechtigte Zugriffe zu unterbinden.

Neben der oben beschriebenen Protokollierung der Anmeldungen werden in einer weiteren Protokoll-Tabelle der Datenbank relevante User-Events (z.B. Start und Ende von Berechnungen, Import von Daten, Fehlersituationen etc.) gespeichert. Die reinen Informationsprotokolle werden wie die erfolgreichen Anmeldungen nach 30 Tagen gelöscht. Dauerhaft gespeichert werden alle Fehlersituationen wie z.B. fehlerhafte Imports.

Daneben gibt es noch ein rein internes Log, das nicht in der Datenbank gespeichert wird, sondern in Form von täglichen Log-Dateien. Diese Logs enthalten nur für die Entwickler relevante Daten und Ereignisse und werden nach einem Monat überschrieben.

Es werden die Logs ausschließlich vom Programm mit vorgefertigtem Text gefüllt, Userinput wird grundsätzlich weder direkt in die Datenbank (SQL-Injection) noch in Logs (log4j-Lücke) geschrieben, so dass weder Gefahr durch SQL-Injection noch durch die berüchtigte Log4j-Lücke besteht.

Das Produktivsystem ist bei axilaris gehostet. Es handelt sich hier um einen von axilaris verwalteten Server ("managed server") mit Cent OS als Betriebssystem, auf dem Banking-Partner keine administrativen Rechte jenseits der Verwaltung der macsi-Komponenten (Datenbank, Front- und Backend, jeweils in einem separaten Docker-Container) besitzt. Daher ist für die Rechenzentrumssicherheit mit allem, was dazu gehört (Backuplösung, Schadsoftwareschutz, Zugangskontrollen, Ausfallsicherheit) ausschließlich axilaris verantwortlich. axilaris ist entsprechend zertifiziert. Remote-Zugriff auf den Server ist nur mit einem personalisierten (Open-)VPN-Zugang sowie ssh-Zugriff über Schlüsseltausch möglich. Das ist der derzeit sicherste Standard für den Remotezugriff.

macsi nutzt selbstverständlich vorhandene Softwarekomponenten. Der Aufbau des Backends und die eingesetzten Java-Libraries sind im innerhalb der Programmdokumentation ausführlich beschrieben. Zur Sicherheit der vom Backend benutzten Libraries wird der Dependabot von Git Hub eingesetzt, der über Sicherheitsrisiken der verwendeten Libraries informiert. Eine komplette Übersicht aller verwendeten Abhängigkeiten findet sich in der angehängten bom.xml. Es kommen ausschließlich freie Lizenzen zum Einsatz. Alle Lizenzen finden sich im Wortlaut im Anhang lizenzen.zip.

Das Frontend ist in JavaScript mit dem Javascript Framework Ember.js programmiert. Ember.js ist ein clientseitiges JavaScript-Webframework zur Erstellung von Single-Page-Webanwendungen und basiert auf dem MVVM-Pattern. Das User-Interface ist mit Bootstrap erstellt. Bootstrap ist ein freies Frontend-CSS-Framework. Es enthält auf HTML und CSS basierende Gestaltungsvorlagen wie z.B.: Typografie, Formulare, Buttons, Tabellen, Grid-Systeme. Um die Qualität und Sicherheit der Software zu gewährleisten, wird das Frontend regelmäßig manuell getestet. Das Frontend nutzt nginx als Server und ist im Wiki des Frontendrepositories entsprechend beschrieben. Die notwendige nginx-Umgebung und Konfiguration ist in einem separaten Repository hinterlegt. Zum Einsatz kommt hier ebenfalls ausschließlich freie Software.