Sicherheitskonzepte für Microservices

<Artikel ist gerade in Überarbeitung bzw. Restrukturierung>

Dieser Artikel erläutert in den ersten beiden Absätzen die Notwendigkeit zum Aufbau eines Sicherheitskonzeptes für Mikroservice-Architekturen. Im dritten Absatz werden aus dem klassischen Vorgehen die elementaren Aspekte für ein Microservice-Sicherheits-Konzept abgeleitet. Im vierten und fünften Absatz wird ein praktischer Mix aus dynamischen Sicherheitsprozessen und stabilen Sicherheits-Lösungen beschrieben. In der Zusammenfassung wird auf bewährte Sicherheits-Prinzipien eingegangen welche die Aspekte des hier beschriebenen Sicherheits-Konzeptes rechtfertigen.

1 Was sind Microservices

Microservices stehen monolithischer Software entgegen, da sie jede Funktion unabhängig anbieten können und somit unabhängig voneinander entwickelt werden können. Während in einer monolithischen Software Frontend, Businesslogik und Datenschicht in einer Anwendung vereint werden, bieten Microservice-Architekturen die bieten die Möglichkeit der logischen Aufteilung entweder in Abhängigkeit von benötigten Backendsystemen oder in Abhängigkeit von den zu beliefernden Frontends (Mobile Apps, Browser, andere Geschäftsanwendungen). Microservices erlauben nicht nur die Kommunikation zum Frontend (auch Konsument) oder zu Datenbanken, sondern auch die Kommunikationen untereinander wie man es auch als Interprozess-Kommunikation (IPC) kennt. Damit steigt offensichtlich die Komplexität einer Mikroservices-Architektur im Vergleich zur monolithischen Anwendung. Gleichzeitig bieten Microservices jedoch die Möglichkeit der besseren Aufteilung zur Programmierung als auch der Skalierung im Betrieb. Sie sind robuster, weil weniger Abhängigkeiten untereinander vorhanden sind, können schneller im Markt eingeführt werden und sind grundsätzlich offener was die Anpassbarkeit an neue Anforderungen oder neue Konsumenten betrifft.

Auf einem Vortrag des Red Hat Summit 2017 wurden acht Herausforderungen einer Mikroservice-Architektur identifiziert. Die folgenden vier Herausforderungen zeigen wie wichtig ein Sicherheits-Konzept für Entwickler und Betreiber von Microservices ist:

  • Entwicklungsaufwand bei verteilten Teams: verschiedenste Kulturen von Menschen als auch von Programmierumgebungen (Java, Go, etc.) müssen auf eine einheitliche Kommunikation untereinander hinarbeiten. Das bietet hohes Potential für unterschiedliche Sicherheitsstandards und -Lösungen und erhöht die Anzahl potentieller Sicherheitsschwachstellen
  • Schnelle Versionswechsel notwendig: die hohe Anzahl von Versionen und Zwischenversionen erfordert eine gute Planung zum Rollback oder dem Backout nach misslungenen Changes
  • Pipelineaufbau und Produktion: Zielumgebungen sind vielerorts vorhanden und müssen als gegeben hingenommen werden, dadurch ist es schwierig klassische Sicherheitsanforderungen in virtuelle und hoch dynamische Umgebungen einzubauen
  • Viele Protokolle: die Bereitschaft der einzelnen Microservices Statusmeldungen auf die Konsole auszugeben ist eine für Entwickler sehr wichtige Debug-Möglichkeit. Damit werden u.U. sensible Daten ausgegeben die in der Produktionsumgebung automatisch auf ELK oder ähnliche Protokoll-Systeme laufen. Zugriffe durch viele Personen auf diese Daten müssen eingeschränkt oder überwacht werden können.

2 Was ist ein Sicherheit-Konzept

Ein IT-Sicherheits-Konzept liefert abgestimmte Maßnahmen für einen Betrieb, ein Produkt oder auch eine Software. Das Bundesamt für Sicherheit in der Informationstechnik beschreibt in einer Zusammenfassung von 2019 ein Sicherheitskonzept als Dokument, welches die Behandlung von IT-Risiken beschreibt. Es legt also fest wie genau der Betreiber, Entwickler oder Unternehmer mit Informationssicherheit umgehen wird. Es stellt ein für alle Beteiligten verbindliches Rahmenwerk dar, welches beachtet und umgesetzt werden muss. Wer die darin beschriebenen Prinzipien mißachtet oder gegen sie verstößt, handelt fahrlässig.

Ein solcher Leitfaden orientiert sich in der Regel an bereits existierenden Sicherheitsstandards wie zum Beispiel der ISO 27001 oder dem Grundschutzkatalog des BSI. Ein Sicherheitskonzept enthält (1) eine Bestandsanalyse, (2) eine Strukturuntersuchung, (3) die Beschreibung des notwendigen Schutzbedarfs sowie (4) eine Darstellung der abgeleiteten Sicherheitsmaßnahmen. Sicherheitskonzepte die sich an den Grunschutzkatalogen des BSI orientieren, können vereinfacht auf sog. Grundschutz-Profile zurück greifen. Sie enthalten Standardmaßnahmen, die aus dem Katalog abgeleitet werden nachdem die Strukturuntersuchung durchgeführt worden ist. Sicherheitskonzepte die sich an einem Sicherheitsstandard (wie ISO 27001) orientieren, beschreiben eher einen kontinuierlichen Prozess zur Sicherstellung der IT-Sicherheit.

3 Vorgehen zur Erstellung eines Sicherheitskonzeptes für Microservices

Mircoservices stellen, wie oben beschrieben, eine neue Art der Entwicklung und dem Betrieb von Software dar. Weil sie einer starken Veränderung unterliegen (Amazon lieferte in 2019 laut einer Aussage von DZone jede Sekunde eine neue Version aus) können keine statischen Sicherheitsanforderungen aus einem Katalog ausgewählt werden. Vielmehr muss ein Mix aus (a) dynamischen Sicherheitsprozessen und (b) stabilen Sicherheits-Lösungen aufgebaut werden. Zu den klassischen Sicherheitsprozessen gehören zweifelsohne das Sicherheits-Management, Identitäts-Management, Asset-Management, Patch-, Change-, Release- und Vulnerability-Management als auch Sensibilisierung, Schulung und sichere Softwareentwicklung. Mit stabilen Sicherheitsfunktionen sind hier Security-Logging (SIEM), Security-Scanning (statische Code-Scans, Penetrationstests), Identity- und Access-Service, Verschüsselung, Zertifikats-Service oder Signatur gemeint.

Diese Dynamik erfordert daher den Aufbau eines agilen Sicherheits-Konzeptes, welches einerseits auf bewährte Sicherheits-Prinzipien aufbaut und andererseits den schnellen Einbau von Sicherheitsmaßnahmen nach Feststellung von IT-Risiken ermöglicht. Außerdem wird eine Erfassung und Klassifizierung der zu verarbeitenden Daten benötigt, als auch ein Leitfaden für  Konsumenten des Gesamtsystems, die Softwareentwicklung, die Integration und dem Deployment in Produktion benötigt.  In Anlehnung an die oben genannten typischen Inhalte sollte ein Sicherheits-Konzept für Microservices daher folgende vier Aspekte enthalten:

  1. Agiles Sicherheits-Management (Bestands-Management)
  2. Agiles Risiko-Management (Strukturuntersuchung)
  3. Klassifizierungs-Schema für Daten (zur Definition des Schutzbedarfes)
  4. Sicherheits-Model für Identity-Management, Umgang mit Daten, Microservice-Entwicklung, -Transition, -Betrieb, und -Datenverarbeitung (abgeleitete Sicherheitsmaßnahmen)

Der Aufbau dieser Punkte erfordert die Einbeziehung von erfahrenen Sicherheits-Managern, Entwicklern, Architekten und Administratoren. Daher wird es schwierig für einen Sicherheits-Experten alleine ein Sicherheits-Konzept für Microservices ohne seine Integration in die agile Entwicklung und den Betrieb zu erstellen. Im Folgenden werden daher einige Erfahrungswerte aus ähnlichen Projekten unterteilt in (a) dynamische Sicherheitsprozesse und (b) bewährte Sicherheits-Lösungen im Kapitel „Neue Anforderungen“ zusammen gefasst.

4 Klassische Sicherheitsprozesse

<Aufbau immer wie folgt: Was ist die Überschrift, was davon muss im Sicherheitskonzept für MS aufgenommen werden, wie wird es zum „Leben“ erweckt“>

Sicherheits-Management

Risiko-Management

Identity-Management

Man unterscheidet zwischen der Identifikation von Konsumenten und der Autorisierung ihrer Anfragen. In diesem Zusammenhang ist es für denjenigen, der Daten durch Microservices heraus gibt (Datenowner), entscheidend wie der Konsument sicher authentisiert wird bzw. wie genau Backend-Services (welche Zugriffe auf Datenbanken durchführen) eingehende Anfragen validieren und verifizieren.

Unterschied zwischen Validieren und Verifizieren

Validieren bedeutet Wirksamkeit prüfen (extern), Signatur wird validiert

Verifizieren bedeutet Wahrheit prüfen (intern)

Verifizieren eines Tokens bedeutet zunächst die Struktur zu bestätigen, dann die Signatur zu validieren

dann werden die Ansprüche überprüft

Token-Introspection-Endpoint am IDP nutzen für die Validierung (RFC 7662)

Patch-Management

Signing Containers durch die Pipeline

Zero-Day Verwundbarkeiten vermeiden durch Patch-Forward

Vulnerability-Management

Change-Management

Security-Logging

(https://blog.openshift.com/security-vulnerability-scanning-container-images/ )

5 Neue Anforderungen auf Basis bewährter Sicherheits-Lösungen

<Welche Sicherheitslösungen (sofern vorhanden) sollten die Zielgruppen weshalb einbauen>

An Entwickler

Push security left

Credential-Schutz: Vault

Dependency Management

Input-Validierung

Sicherheits-Protokollierung

Löschkonzept (DSGVO) (Data life cycle)

An Architektur

Unterscheidung verschiedene Microservices:

  • BFF
  • Backend

Call von Gateway, trusted, kein weiterer Tokenprüfung

Call nicht vom Gateway, Security Event erzeugen

Mit UI / Ohne UI

 

Kommunikation mit der „alten Welt“: Datenbanken

 

Andere oder neue Konsumenten (Internet oder Intranet)

 

Andere und neue Lieferanten bzw. Services (Internet oder eigenem Netzwerk)

An den Betrieb

Worauf sollte der Betrieb achten

(Pipeline Aufbau, Betrieb auf Virtueller Umgebung oder Hardware)

Pipeline: Updates für Libraries regelmäßig einbauen -> Produktion

Scanning: Quellen, Libraries, Images

Kritikalität eines Services – Asset-Management

Vault zur Verfügung stellen

Zusammenhang mit API-GW (3Scale, Kong, WSO2)

AuthN/ AuthZ mit Rezertifizierung

Für Konsumenten (oder Nutzer) mit hohen/erweiterten Rechten muss starke Authentifizierung eingeführt werden (multi, oder 2FA)

Incident-Analysten im CERT, SIRT nutzen SIEM SW

6 Zusammenfassung

Die vier wichtigen Aspekte für den Aufbau eines Sicherheits-Konzeptes für Microservices sind: (1) agiles Sicherheits- und (2)  Risiko-Management, (3) Datenklassifizierung und das daraus abgeleitete (4) Sicherheits-Modell für alle Stakeholder.

Mehrere Sicherheitsebenen (security in depth) werden durch horizontale Einbeziehung aller Schritte beginnend beim Design, der Entwicklung, der Intergration, dem Build und dem Betrieb sowie vertikalen Maßnahmen von der Datenerfassung, -Verarbeitung und Speicherung eingezogen.

Auch neu zu verarbeitende Daten müssen klassifiziert werden sodass Ihr Schutzbedarf Einfluss auf die Auswahl der folgenden Sicherheitsmaßnahmen haben kann.

Implizit entsteht daraus eine Art Threat-Matrix, bzw. ein Sicherheits-Modell, welches von Entwicklern, Architekten und dem Betrieb in das Gesamtprodukt eingezogen wird.

Durch die Datenklassifizierung und die angemessene Authentisierung von Konsumenten und der Autorisierung von Anfragen entsteht an den Übergabepunkten wie einem API-Gateway oder den Endpoints (REST) von Microservices eine klare Vertrauensgrenze (Trust-Boundary).

Ebenso durch die Datenklassifizierung werden vertrauliche Daten erkannt und können durch Sicherheits-Lösungen (Vault) geschützt werden.

Daten die über-altern oder nicht mehr benötigt werden, müssen gelöscht oder anonymisiert werden. Konsumenten und ihre Berechtigungen müssen regelmäßig überprüft werden. Eingesetzte Libraries werden nach Feststellung von Schwachstellen aktualisiert, und damit der data life cycle sicher gestellt.

Konsumenten und Nutzer werden ordentlich angelegt, verwaltet, identifiziert und in Rollen verteilt. So können eingehende Anfragen (Requests/REST-Calls) ordentlich autorisiert werden.

Als erkennende Maßnahme wird direkt in der Software sogenannte Ereignis-Protokollierung eingebaut. Das ermöglich eine permanente Überwachung während dem Betrieb durch Incident-Analysten auf auffällige Ereignisse.

 

Schreiben Sie einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.