Für die Umsetzung hat Novaloop sich an den state-of-the-art Technologien aus dem Cloud Native Ökosystem orientiert. Die folgende Liste ist nicht abschliessend und fokussiert hauptsächlich auf die Konfigurations- und Deploymentaspekte der Plattform. Technologien zur Implementierung weiterer operativer Aspekte wie Logging, Monitoring und Backup wurden hier bewusst weggelassen.

Orchestrierung

Für die Orchestrierung von Containern wurde die Open-Source-Lösung Kubernetes aus dem Hause Google verwendet. Out-of-the-box genügen die Kubernetes Installationen nicht den hohen Sicherheitsanforderungen für den Betrieb einer eHealth Lösung.

Eine konsequente Anwendung von "Principle of Least Privilege" für Zugriffe von Personen und Systemen sind zentral. Die Umsetzung erfolgte durch die von Kubernetes zur Verfügung stehenden Boardmitteln:

• Role-based access control
• Pod Security Policy
• Network Security Policy

Continuous Delivery

Für das kontinuierliche Deployment und die Environment-spezifischen Konfigurationen der Infrastruktur- und Softwareartefakte hat Novaloop sich am Prinzip von GitOps orientiert. Bei GitOps werden alle für das Deployment notwendige Konfigurationen in ein oder mehrere Git Repositories abgespeichert. Daraus ergeben sich u.a. folgende Vorteile:

• Alle Konfigurationen sind stets versioniert und nachvollziehbar abgespeichert
• Die Verwendung von Entwicklerzentrierten Freigabeprozessen wie z.B. dem Pull-Request können auch für Infrastruktur bzw. Environmentspezifische Konfigurationen angewendet werden
• Der (Soll-)Zustand des Systems ist stets im Git nachvollziehbar abgelegt und versioniert. Tritt ein Gap zwischen dem Ist-Zustand auf dem System und dem Soll-Zustand in Git auf, wird entsprechend alarmiert, oder automatisch abgeglichen (deployed).

Für die Kompositionen der Kubernetes Deployment-Manifeste werden die Werkzeuge Kustomize und Helm verwendet. Aus Gründen der besseren Lesbarkeit wurde Kustomize für die Kompositionen der Softwareartefakte für den Workload verwendet. Helm wurde ausschliesslich für Infrastrukturkomponenten wie z.B. HashiCorp Vault verwendet. In der Regel bieten bereits viele Open-Source Softwareanbieter ihre Konfiguration in Form von Helm-Charts an.

Service Mesh

Die speziell im eHealth-Bereich sehr hohen Anforderungen an die Netzwerksicherheit reduzieren die Effizienz in der Auslieferung. Nicht-funktionale Aspekte wie die Transportverschlüsselung und das damit verbundene Zertifikatsmanagement sind keine trivialen Aufgaben für ein Entwicklerteam. In früher eingesetzten Lösungen, musste die Transportverschlüsselung und das Zertifikatshandling direkt im Applikationscode implementiert und gepflegt werden. Eine zentrale Verwaltung für die Transportverschlüsselung gab es nicht. Dieses Know-how musste also in jedem Entwicklungsteam vorhanden sein.

Abhilfe schaffen hier Service Meshes, welche die früher dezentralen Konfigurationen pro Team obsolet machen und zentral durch ein System/Plattform-Team verwaltet werden können. Dies führt einerseits zu einem Effizienzgewinn, andererseits können damit allfällige Sicherheitsprobleme zentral mitigiert werden. Ein bekanntes Problem ist beispielsweise, dass die Validierung der Trust-Chain im Applikationsstack aus praktischen Gründen deaktiviert wird. Die Deaktivierung führt dazu, dass die Anwendung alle Endpunkte, auch nicht vertrauenswürdige, zulässt. In einem Service Mesh können diese Verbindungen zentral kontrolliert und sicher enforced werden.

Sicherheit funktioniert nach dem Zwiebelschalen-Prinzip und muss auf mehreren Ebenen greifen. Dies gilt auch für die Transportsicherung innerhalb der Plattform. Komponenten dürfen sich gegenseitig nur dann erreichen, wenn das von einem konkreten Anwendungsfall in der Lösung verlangt wird. Die aufeinanderliegenden Ebenen (Bottom-Up) sind:

Wird eine Ebene kompromittiert, schützt die nächste darunterliegende Ebene. Dieses Sicherheitskonzept nennt sich "Zero-Trust-Modell".

Passwort- und Zertifikatsverwaltung

Der korrekte Umgang mit Passwörtern und Zertifikaten ist nicht trivial. Die Prozesse für die Verwaltung von sensitiven Informationen unterscheiden sich idealerweise nicht zwischen den verschiedenen Stages (Dev, Test, Prod). Der Umgang mit den Day-2 Prozessen rundum Passwörter und Zertifikaten lassen sich damit bereits in den Entwicklungsteams etablieren und kontinuierlich anwenden.

HashiCorp Vault bietet für die Speicherung von sensitiven Informationen einen sicheren Key-Value Store an. Passwörter werden bei einem Init-Deployment einer Umgebung automatisch erzeugt und in den Key-Value Store abgelegt. Die Logik für die Passwortverteilung wird deklarativ in einer YAML-Definition beschrieben (GitOps). Die Passwörter werden via Init-Container in Form eines verschlüsselten in-memory volumes der verschiedenen Applikationscontainer zur Verfügung gestellt.

Für die Herausgabe von internen X.509 Zertifikate wird HashiCorp Vault PKI verwendet. Die erstmalige Herausgabe, sowie das Rotieren von Zertifikaten, geschieht via API-Calls und ist vollständig automatisiert. Dies ist eine wichtige Voraussetzung für die Einführung von kurzlebigen (short-lived) Zertifikaten. Auf umständliche und fehleranfällige Widerrufsprozesse (CRL, OCSP) kann für internen Traffic daher verzichtet werden. Die Gültigkeitsdauer eines Zertifikates kann z.B. auf 15min beschränkt werden.