Umsetzung des BSI APP.4.4 und SYS.1.6 Bausteins mit Aqua Security

Vom Bundesamt für Sicherheit in der Informationstechnik (BSI) werden verschiedene IT-Grundschutz-Bausteine zu Verfügung gestellt, die elementare Bestandteile in der IT-Grundschutz-Methodik darstellen. Darin werden wesentliche Anforderungen und Empfehlungen einzelner oder komplexer Systeme und Prozesse aufgeführt.

Die BSI APP.4.4 Kubernetes (Edition 2022) und SYS.1.6 Container (Edition 2022) Bausteine sind zum aktuellen Zeitpunkt noch nicht final verfügbar und liegen als Community Drafts vor. Diese können innerhalb von vier Wochen kommentiert werden, bevor sie anschließend durch eine neue Version ersetzt werden. Nachdem die Drafts so einen mehrstufigen Redaktionsprozess durchlaufen haben, werden sie final in der jährlichen Edition des IT-Grundschutz-Kompendiums veröffentlicht.

IT-Grundschutz-Bausteine sind im Status eines Drafts noch nicht zertifizierungsrelevant, dennoch macht es Sinn sich frühzeitig damit auseinanderzusetzen, wie die enthaltenen Anforderungen erfüllt werden können. In diesem Artikel werden genau die Anforderungen der beiden Bausteine vorgestellt, bei deren Umsetzung die Cloud Native Security Plattform von Aqua Security helfen kann.

APP.4.4 Kubernetes

Ziel des APP.4.4 Kubernetes Bausteins ist der Schutz von Informationen, die in Kubernetes-Clustern verarbeitet, angeboten oder darüber übertragen werden. Dieser ist immer mit dem SYS.1.6 Container Baustein zusammen anzuwenden, welcher im darauffolgenden Abschnitt behandelt wird. Nachfolgend sind jene spezifischen Anforderungen des Bausteins aufgeführt, die sich mit Hilfe von Aqua Security umsetzen lassen.

A2 „Planung der Automatisierung mit CI/CD“

Wenn eine Automatisierung des Betriebs von Anwendungen in Kubernetes mithilfe von CI/CD stattfindet, DARF diese NUR nach einer geeigneten Planung erfolgen. Die Planung MUSS den gesamten Lebenszyklus von Inbetrieb- bis Außerbetriebnahme inklusive Betrieb, Überwachung und Updates umfassen. Das Rollen- und Rechtekonzept MUSS Teil der Planung sein.

Aqua kann bereits in der CI/CD-Pipeline eingreifen und Images auf voreingestellte Kriterien überprüfen, bevor diese zur Ausführung gebracht werden. Wenn an dieser Stelle von Aqua Abweichungen festgestellt werden, dann kann dies auditiert und das Image als „non-compliant“ markiert werden. In einem weiteren Schritt können „non-compliant“ Images an der Ausführung gehindert werden.

A3 „Identitäts- und Berechtigungsmanagement bei Kubernetes“

Kubernetes und alle anderen Anwendungen der Management Plane MÜSSEN jede Aktion eines Benutzers oder, im automatisierten Betrieb, einer entsprechenden Software authentifizieren und autorisieren, unabhängig davon, ob die Aktionen über einen Client, eine Weboberfläche oder über eine entsprechende Schnittstelle (API) erfolgt. Administrative Handlungen DÜRFEN NICHT anonym erfolgen.

Jeder Benutzer DARF NUR die unbedingt notwendigen Rechte erhalten. Berechtigungen ohne Einschränkungen MÜSSEN sehr restriktiv vergeben werden.

Nur ein kleiner Kreis von Personen SOLLTE berechtigt sein, Prozesse der Automatisierung zu definieren. Nur ausgewählte Administratoren SOLLTEN in Kubernetes das Recht erhalten, Freigaben für Festspeicher (Persistent Volumes) anzulegen oder zu ändern.

Über Black- und Whitelisting können Nutzer und Gruppen definiert werden, die sich beim Host System authentifizieren dürfen. Zusätzlich ist es möglich Nutzeraktivitäten sowie Kommandozeileneingaben auf dem Host System zu auditieren.

A4 „Separierung von Pods“

Der Betriebssystem-Kernel der Nodes MUSS über Isolationsmechanismen zur Beschränkung von Sichtbarkeit und Ressourcennutzung der Pods untereinander verfügen (vgl. Linux Namespaces und cgroups). Die Trennung MUSS dabei mindestens Prozess-IDs, Inter-Prozess-Kommunikation, Benutzer-IDs, Dateisystem und Netz inklusive Hostname umfassen.

Ein- und ausgehende Netzwerkaktivitäten lassen sich durch Firewall Policies in Aqua jeweils für alle Hosts bzw. für alle Container einschränken, um eine grobe Grundlage zu schaffen. Dies kann dann weiter im Detail für bestimmte Hosts oder Container verfeinert werden.

A7 „Separierung der Netze bei Kubernetes“

Die Netze für die Administration der Nodes, der Management Plane sowie die einzelnen Netze der Anwendungsdienste SOLLTEN separiert werden.

Es SOLLTEN NUR die für den Betrieb notwendigen Netzports der Pods in die dafür vorgesehenen Netze freigegeben werden. Bei mehreren Anwendungen auf einem Kubernetes-Cluster SOLLTEN zunächst alle Netzverbindungen zwischen den Namespaces untersagt und nur benötigte Netzverbindungen gestattet sein (Whitelisting). Die zur Administration der Nodes, der Runtime und von Kubernetes inklusive seiner Erweiterungen notwendigen Netzports SOLLTEN NUR aus dem Administrationsnetz und von Pods, die diese benötigen, erreichbar sein.

Nur ausgewählte Administratoren SOLLTEN in Kubernetes berechtigt sein, das CNI zu verwalten und Regeln für das Netz anzulegen oder zu ändern.

Mit Hilfe von Firewall Policies kann ein- und ausgehender Netzwerkverkehr über definierte Ports eingeschränkt werden. Es ist auch möglich grundsätzlich alle Netzverbindungen zwischen Namespaces zu blockieren und nur einzelne Verbindungen wieder zu erlauben. Weiterhin kann durch Policies definiert werden, welcher User auf welche Ressourcen zugreifen darf.

A13 „Automatisierte Auditierung der Konfiguration“

Es SOLLTE ein automatisches Audit der Einstellungen der Nodes, von Kubernetes und der Pods der Anwendungen gegen eine definierte Liste der erlaubten Einstellungen und gegen standardisierte Benchmarks erfolgen.

Kubernetes SOLLTE die aufgestellten Regeln im Cluster durch Anbindung geeigneter Werkzeuge durchsetzen.

Erlaubte Einstellungen werden in Aqua über Policies definiert und auf Hosts und Container angewendet. Mit Policies lassen sich auf Host Systemen standardisierte Benchmarks, wie Docker CIS, Kubernetes CIS und Linux CIS durchführen. Durch die Integration des Open Policy Agents ist es möglich, weitere benutzerdefinierte Regeln anzulegen. Außerdem kann man Hosts benutzerdefinierte Compliance Checks in Form von Skripten durchlaufen lassen. Wenn Aqua eine Abweichung zu diesen Vorgaben erkennt, wird dies automatisch auditiert und betroffene Hosts bzw. Container werden auf Wunsch als „non-compliant“ markiert. Auf diese Weise können nicht erlaubte Aktionen gestoppt oder die generelle Ausführung verhindert werden.

A18 „Verwendung von Mikro-Segmentierung“

Die Pods SOLLTEN auch innerhalb eines Kubernetes-Namespace nur über die notwendigen Netzports miteinander kommunizieren können. Es SOLLTEN Regeln innerhalb des CNI existieren, die alle bis auf die für den Betrieb notwendigen Netzverbindungen innerhalb des Kubernetes-Namespace unterbinden. Diese Regeln SOLLTEN Quelle und Ziel der Verbindungen genau definieren und dafür mindestens eines der folgenden Kriterien nutzen: Service-Name, Metadaten (“Labels”), die Kubernetes Service Accounts oder zertifikatsbasierte Authentifizierung.

Es ist möglich die Kommunikation von Pods über ein- und ausgehende Ports mit Hilfe einer Policy zu beschränken. Dies kann auch auf einzelne Kubernetes-Namespaces angewendet werden, um damit eine entsprechende Mikro-Segmentierung zu erreichen.

SYS.1.6 Containerisierung

Ziel des SYS.1.6 Containerisierung Bausteins ist der Schutz von Informationen, die in, von oder mit Containern verarbeitet, angeboten oder darüber übertragen werden. Der Baustein behandelt, wie Container grundsätzlich abgesichert werden können.

A6 „Verwendung sicherer Images“

Es MUSS sichergestellt sein dass sämtliche verwendeten Images nur aus vertrauenswürdigen Quellen stammen. Digitale Signaturen MÜSSEN jedes Image gegen Veränderung absichern und der Ersteller MUSS eindeutig identifizierbar sein. Die Quelle MUSS danach ausgewählt werden, dass der Ersteller des Images die enthaltene Software regelmäßig auf Sicherheitsprobleme prüft, diese behebt und dokumentiert sowie dies seinen Kunden zusichert.

Die verwendete Version von Basis-Images DARF NICHT abgekündigt (“deprecated”) sein. Es MÜSSEN eindeutige Versionsnummern angegeben sein. Wenn ein Image mit einer neueren Versionsnummer verfügbar ist, MUSS im Rahmen des Patch- und Änderungsmanagement geprüft werden, ob und wie dieses ausgerollt werden kann.

Images können in Aqua auf Vulnerabilities gescannt werden. Die Vulnerabilities werden nach Severity sortiert aufgelistet und zu jedem Eintrag gibt es zusätzliche Informationen. Auf Basis der meisten Vulnerabilities, die von Aqua gefunden wurden, können sofort automatisch Policies generiert werden, die einen Exploit der Schwachstelle verhindern.

A7 „Persistenz von Protokollierungsdaten der Container“

Die Speicherung der Protokollierungsdaten der Container MUSS außerhalb des Containers, mindestens auf dem Container-Host, erfolgen.

In Aqua lassen sich Policies definieren, mit denen Nutzeraktivitäten des Betriebssystems, sowie alle Prozess- und Netzwerkaktivitäten und Kommandozeileineingaben in Containern auditiert werden können. Diese Informationen können an unterschiedliche Log Management Tools weitergeleitet werden.

A8 „Sichere Speicherung von Zugangsdaten bei Containern“

Zugangsdaten MÜSSEN so gespeichert und verwaltet werden, dass nur berechtigte Personen und Container darauf zugreifen können. Insbesondere MUSS sichergestellt sein, dass Zugangsdaten nur an besonders geschützten Orten und nicht in den Images liegen. Die von der Verwaltungssoftware des Container-Dienstes bereitgestellten Verwaltungsmechanismen für Zugangsdaten SOLLTEN eingesetzt werden.

Mindestens die folgenden Zugangsdaten MÜSSEN sicher gespeichert werden: Passwörter jeglicher Accounts, API-Keys für von der Anwendung genutzte Dienste, Schlüssel für symmetrische Verschlüsselungen sowie private Schlüssel bei Public-Key-Authentisierung. Hierbei SOLLTEN besonders die vom Ersteller vorgegebenen Zugangsdaten betrachtet werden.

Mit Hilfe von Policies lassen sich Sicherheitslücken in Images vor der Ausführung auch durch Integration des Image Scans in CI/CD Pipelines erkennen. Aqua kann die Dateistruktur von Images nach sensiblen Daten wie Passwörtern und Schlüsseln durchsuchen. Das Ergebnis kann von Aqua auditiert werden bzw. als Folge kann das jeweilige Image als „non-compliant“ markiert werden. Zusätzlich kann die Ausführung von „non-compliant“ Images verhindert werden.

A10 „Richtlinie für Images und Container-Betrieb“

Es SOLLTE eine Richtlinie erstellt und angewendet werden, die die Anforderungen an den Betrieb der Container und die erlaubten Images festlegt. Die Richtlinie SOLLTE auch Anforderungen an den Betrieb und die Bereitstellung der Images enthalten.

Richtlinien können in Aqua über Policies definiert und auf Images angewendet werden. Eine Policy kann durch eine Reihe an Tests konfiguriert werden, die ein Image erfüllen muss, um als compliant zu gelten. Werden beim Scannen von Images Abweichungen der Richtlinie festgestellt, kann das von Aqua auditiert werden und diese Images als „non-compliant“ markieren. Die Ausführung von „non-compliant“ Images kann von Aqua blockiert werden.

A12 „Verteilung sicherer Images“

Es SOLLTE angemessen dokumentiert werden, welche Quellen für Images als vertrauenswürdig klassifiziert wurden und warum. Zusätzlich SOLLTE der Prozess angemessen dokumentiert werden, wie Images bzw. die im Image enthaltenen Softwarebestandteile aus vertrauenswürdigen Quellen bezogen und schließlich für den produktiven Betrieb bereitgestellt werden.

Die verwendeten Images SOLLTEN über Metadaten verfügen, die die Funktion und die Historie des Images nachvollziehbar machen.

Aqua erlaubt es dem Anwender verschiedene Image Registries als Quelle für Images einzubinden und an dieser Stelle benutzerdefinierten Informationen zur jeweiligen Registry zu dokumentieren. Wenn Images von einer dieser Quellen bezogen werden, dann ist innerhalb der Aqua Console ersichtlich, woher genau die jeweiligen Images stammen. Zu jedem Image sind außerdem weitere Metadaten einsehbar, wie beispielsweise Version, OS, Erstelldatum oder die Größe des Images.

A13 „Freigabe von Images“

Alle Images für den produktiven Betrieb SOLLTEN wie Softwareprodukte einen Test- und Freigabeprozess gemäß des Bausteins OPS.1.1.6 Software-Test und Freigaben durchlaufen.

Durch das Markieren von Images mit unerfüllten Policies als „non-compliant“ und einer weiteren Policy, welche „non-compliant“-markierte Images blockiert, lässt sich der automatische Freigabeprozess realisieren.

A16 „Administrativer Fernzugriff auf Container“

Administrative Zugriffe von einem Container auf den Container-Host und umgekehrt SOLLTEN wie administrative Fernzugriffe betrachtet werden. Aus einem Container DARF KEIN administrativer Fernzugriff auf den Container-Host erfolgen.

Aqua bietet die Möglichkeit dies sowohl über ein generelles Verbot von exekutivem Zugriff auf Container im Scope der Policy, als auch granular in Form von Service Definitionen und Firewall-Regeln umzusetzen.

A17 „Ausführung von Containern ohne Privilegien“

Die Container-Runtime und alle instanziierten Container SOLLTEN nur von einem nichtprivilegierten System-Account ausgeführt werden, der keine erweiterten Rechte für den Container Dienst bzw. das Betriebssystem des Host-Systems verfügt oder diese Rechte erlangen kann. Die Container-Runtime SOLLTE durch zusätzliche Maßnahmen gekapselt werden, etwa durch Verwendung der Virtualisierungs-Erweiterungen von CPUs.

Sofern Container ausnahmsweise Aufgaben des Host-Systems übernehmen sollen, SOLLTEN die Privilegien auf dem Host-System auf das erforderliche Minimum begrenzt werden. Ausnahmen SOLLTEN angemessen dokumentiert werden.

Mit entsprechend konfigurierten Policies können Containern blockiert werden, die über erweiterte Rechte verfügen, als „root“-User laufen oder Zugriff auf das Host Netzwerk haben.

A18 „Accounts der Anwendungsdienste“

Die System-Accounts innerhalb eines Containers SOLLTEN keine Berechtigungen auf dem Host System haben. Wo aus betrieblichen Gründen diese Berechtigung notwendig ist, SOLLTE diese nur für unbedingt notwendige Daten gelten. Der Account im Container, der für diesen Datenaustausch notwendig ist, SOLLTE im Host-System bekannt sein.

Über Black- und Whitelisting können Nutzer und Gruppen definiert werden, welche sich beim Host System authentifizieren dürfen, bzw. welchen die Authentifizierung verweigert wird.

A21 „Erweiterte Sicherheitsrichtlinien“

Erweiterte Richtlinien SOLLTEN die Berechtigungen der Container einschränken. Die Richtlinien SOLLTEN mindestens folgende Zugriffe einschränken: eingehende und ausgehende Netzverbindungen, Dateisystem-Zugriffe und Kernel-Anfragen (Syscalls).

Die Runtime SOLLTE die Container so starten, dass der Kernel des Host-Systems alle nicht von der Richtlinie erlaubten Aktivitäten der Container verhindert (z. B. durch die Einrichtung lokaler Paketfilter oder durch Entzug von Berechtigungen) oder zumindest Verstöße geeignet meldet.

Richtlinien können in Aqua über Policies definiert und auf Container angewendet werden. In einer Policy kann festgelegt werden, welche Aktivitäten in einem Container zur Laufzeit erlaubt sind. Dies kann entweder nur auditiert werden, ein Container kann bestimmte Aktionen zur Laufzeit nicht ausführen oder er wird erst gar nicht zur Ausführung gebracht. Auf diese Weise lassen sich beispielsweise Dateisystem-Zugriffe, Netzwerkverbindungen und Kernel-Anfragen einschränken.

A23 „Unveränderlichkeit der Container“

Nicht-persistente Container SOLLTEN ihr Dateisystem während der Laufzeit nicht verändern können.

Durch Policies kann der Schreibzugriff auf ausgewählte Verzeichnisse zur Laufzeit verboten werden. Dabei lassen sich einzelne bzw. durch einen Wildcard Syntax viele Verzeichnisse auf einmal definieren. Außerdem kann verhindert werden, dass Programme ausgeführt werden, die sich nicht bereits im ursprünglichen Image befanden, wie es in der Image Registry existiert.

A25 „Hostbasierte Angriffserkennung“

Das Verhalten der Container und der darin betriebenen Anwendungen bzw. Diensten SOLLTE überwacht werden. Abweichungen von einem normalen Verhalten SOLLTEN bemerkt und gemeldet werden. Die Meldungen SOLLTEN im zentralen Prozess zur Behandlung von Sicherheitsvorfällen angemessen behandelt werden.

Das zu überwachenden Verhalten SOLLTE mindestens umfassen: Netzverbindungen, erstellte Prozesse, Dateisystem-Zugriffe und Kernel-Anfragen (Syscalls).

Aqua kann für die Sicherheit von Workloads und Infrastruktur zur Laufzeit sorgen. Basierend auf vordefinierten Richtlinien wird automatisch entschieden, ob Workloads zur Ausführung kommen dürfen oder nicht. Weiterhin werden auf der gleichen Grundlage bestimmte Laufzeitaktivitäten von Workloads und Hosts überwacht, eingeschränkt und/oder blockiert.

Fazit

Die Cloud Native Security Plattform von Aqua Security ist ein sehr mächtiges Werkzeug, wenn es um die Sicherheit im Kubernetes und Container Umfeld geht. In diesem Artikel wurden die Anforderungen der beiden BSI Bausteine SYS.1.6 und APP.4.4 zu Kubernetes und Containerisierung vorgestellt, bei denen Aqua mit der Umsetzung helfen kann und welche Mittel dafür in Aqua genutzt werden können.