BSI-Anforderungen: APP.4.4 Kubernetes und SYS.1.6 Containerisierung

Auf dieser Seite finden Sie die oben genannten Anforderungslisten des Bundesamtes für die Sicherheit in der Informationstechnik, die ich zur besseren Übersicht in einer Tabelle zusammengefasst habe.

Beide Anforderungslisten sind ein Teil des freiverfügbaren IT -Grundschutz-Kompendiums. Das IT-Grundschutz-Kompendium ist ein wertvoller Beitrag zur Verbesserung der IT-Sicherheit.

Download-Links (Edition 2023):

Organisatorische Maßnahmen 

 

 APP.4.4 Kubernetes

SYS.1.6 Containerisierung

Basis-Anforderungen  

 APP.4.4. A1 Planung der Separierung der Anwendungen

 SYS.1.6. A1 Planung des Container-Einsatzes

Vor der Inbetriebnahme MUSS geplant werden, wie die in den Pods betriebenen Anwendungen und deren unterschiedlichen Test- und Produktions-Betriebsumgebungen separiert werden. Auf Basis des Schutzbedarfs der Anwendungen MUSS die Planung festlegen, welche Architektur der Namespaces, Meta-Tags, Cluster und Netze angemessen auf die Risiken eingeht und ob auch virtualisierte Server und Netze zum Einsatz kommen sollen.

Die Planung MUSS Regelungen zu Netz-, CPU- und Festspeicherseparierung enthalten. Die Separierung SOLLTE auch das Netzzonenkonzept und den Schutzbedarf beachten und auf diese abgestimmt sein.

Anwendungen SOLLTEN jeweils in einem eigenen Kubernetes-Namespace laufen, der alle Programme der Anwendung umfasst. Nur Anwendungen mit ähnlichem Schutzbedarf und ähnlichen möglichen Angriffsvektoren SOLLTEN einen Kubernetes-Cluster teilen.

Bevor Container eingesetzt werden, MUSS zunächst das Ziel des Container-Einsatzes (z. B. Skalierung, Verfügbarkeit, Wegwerf-Container zur Sicherheit oder CI/CD) festgelegt werden, damit alle sicherheitsrelevanten Aspekte der Installation, des Betriebs und der Außerbetriebnahme geplant werden können. Bei der Planung SOLLTE auch der Betriebsaufwand berücksichtigt werden, der durch Container-Einsatz oder Mischbetrieb entsteht. Die Planung MUSS angemessen dokumentiert werden.

   

 APP.4.4. A2 Planung der Automatisierung mit CI/CD

SYS.1.6.A2 Planung der Verwaltung von Containern

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 Entwicklung, Tests, Betrieb, Überwachung und Updates umfassen. Das Rollen- und Rechtekonzept sowie die Absicherung von Kubernetes Secrets MÜSSEN Teil der Planung sein.

Die Verwaltung der Container DARF NUR nach einer geeigneten Planung erfolgen. Diese Planung MUSS den gesamten Lebenszyklus von Inbetrieb- bis Außerbetriebnahme inklusive Betrieb und Updates umfassen. Bei der Planung der Verwaltung MUSS berücksichtigt werden, dass der Ersteller eines Containers aufgrund der Auswirkungen auf den Betrieb in Teilen wie ein Administrator zu betrachten ist.

Start, Stopp und Überwachung der Container MUSS über die eingesetzte Verwaltungssoftware erfolgen.

   

 APP.4.4.A3 Identitäts- und Berechtigungsmanagement bei Kubernetes 

SYS.1.6.A3 Sicherer Einsatz containerisierter IT-Systeme

Kubernetes und alle anderen Anwendungen der Control 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.

Bei containerisierten IT-Systemen MUSS berücksichtigt werden, wie sich eine Containerisierung auf die betriebenen IT-Systeme und Anwendungen auswirkt, dies betrifft insbesondere die Verwaltung und Eignung der Anwendungen.

Es MUSS anhand des Schutzbedarfs der Anwendungen geprüft werden, ob die Anforderungen an die Isolation und Kapselung der containerisierten IT-Systeme und der virtuellen Netze sowie der betriebenen Anwendungen hinreichend erfüllt sind. In diese Prüfung SOLLTEN die Betriebssystem- eigenen Mechanismen mit einbezogen werden. Für die virtuellen Netze nimmt der Host die Funktion einer Netzkomponente wahr, die Bausteine der Teilschichten NET.1 Netze und NET.3 Netzkomponenten MÜSSEN entsprechend berücksichtigt werden. Logische und Overlay-Netze MÜSSEN ebenfalls betrachtet und modelliert werden. Weiterhin MÜSSEN die eingesetzten containerisierten IT-Systeme den Anforderungen an die Verfügbarkeit und den Datendurchsatz genügen.

Im laufenden Betrieb SOLLTEN die Performance und der Zustand der containerisierten IT-Systeme überwacht werden (sogenannte Health Checks).
   

 APP.4.4.A4 Separierung von Pods

SYS.1.6.A4 Planung der Bereitstellung und Verteilung von Images

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.

Der Prozess zur Bereitstellung und Verteilung von Images MUSS geplant und angemessen dokumentiert werden.
   

 APP.4.4.A5 Datensicherung im Cluster 

SYS.1.6.A5 Separierung der Administrations- und Zugangsnetze bei Containern

Es MUSS eine Datensicherung des Clusters erfolgen. Die Datensicherung MUSS umfassen:

  • Festspeicher (Persistent Volumes),
  • Konfigurationsdateien von Kubernetes und den weiteren Programmen der Control Plane,
  • den aktuellen Zustand des Kubernetes-Clusters inklusive der Erweiterungen,
  • Datenbanken der Konfiguration, namentlich hier etcd,
  • alle Infrastrukturanwendungen, die zum Betrieb des Clusters und der darin befindlichen Dienste notwendig sind und
  • die Datenhaltung der Code und Image Registries.

Es SOLLTEN auch Snapshots für den Betrieb der Anwendungen betrachtet werden. Snapshots DÜRFEN die Datensicherung NICHT ersetzen.

Die Netze für die Administration des Hosts, die Administration der Container und deren Zugangsnetze MÜSSEN dem Schutzbedarf angemessen separiert werden. Grundsätzlich SOLLTE mindestens die Administration des Hosts nur aus dem Administrationsnetz möglich sein.
   
 

SYS.1.6.A6 Verwendung sicherer Images

 

Es MUSS sichergestellt sein, dass sämtliche verwendeten Images nur aus vertrauenswürdigen Quellen stammen. Der Ersteller der Images 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.

   
 

 SYS.1.6.A7 Persistenz von Protokollierungsdaten der Container

 

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

   
 

 SYS.1.6.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.
   

 Standard-Anforderungen

 APP.4.4.A6 Initialisierung von Pods

 SYS.1.6.A9 Eignung für Container-Betrieb

Sofern im Pod zum Start eine Initialisierung z.B. einer Anwendung erfolgt, SOLLTE diese in einem eigenen Init-Container stattfinden. Es SOLLTE sichergestellt sein, dass die Initialisierung alle bereits laufenden Prozesse beendet. Kubernetes SOLLTE NUR bei erfolgreicher Initialisierung die weiteren Container starten

Die Anwendung bzw. der Dienst, der im Container betrieben werden soll, SOLLTE für den Container- Betrieb geeignet sein. Dabei SOLLTE berücksichtigt werden, dass Container häufiger für die darin ausgeführte Anwendung unvorhergesehen beendet werden können. Die Ergebnisse der Prüfung nach SYS.1.6.A3 Sicherer Einsatz containerisierter IT-Systeme SOLLTE nachvollziehbar dokumentiert werden.

   

 APP.4.4.A7 Separierung der Netze bei Kubernetes

 SYS.1.6.A10 Richtlinie für Images und Container-Betrieb

Die Netze für die Administration der Nodes, der Control 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 Kubernetes-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.

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.
   

 APP.4.4.A8 Absicherung von Konfigurationsdateien bei Kubernetes

 SYS.1.6.A11 Nur ein Dienst pro Container

Die Konfigurationsdateien des Kubernetes-Cluster, inklusive aller Erweiterungen und Anwendungen SOLLTEN versioniert und annotiert werden.

Zugangsrechte auf die Verwaltungssoftware der Konfigurationsdateien SOLLTEN minimal vergeben werden. Zugriffsrechte für lesenden und schreibenden Zugriff auf die Konfigurationsdateien der Control Plane SOLLTEN besonders sorgfältig vergeben und eingeschränkt sein.

Jeder Container SOLLTE jeweils nur einen Dienst bereitstellen.

   

 APP.4.4.A9 Nutzung von Kubernetes Service-Accounts

 SYS.1.6.A12 Verteilung sicherer Images

Pods SOLLTEN NICHT den "default"-Service-Account nutzen. Dem "default"-Service-Account SOLLTEN keine Rechte eingeräumt werden. Pods für unterschiedliche Anwendungen SOLLTEN jeweils unter eigenen Service-Accounts laufen. Berechtigungen für die Service-Accounts der Pods der Anwendungen SOLLTEN auf die unbedingt notwendigen Rechte beschränkt werden.

Pods, die keinen Service-Account benötigen, SOLLTEN diesen nicht einsehen können und keinen Zugriff auf entsprechende Token haben.

Nur Pods der Control Plane und Pods, die diese unbedingt benötigen, SOLLTEN privilegierte Service-Accounts nutzen.

Programme der Automatisierung SOLLTEN jeweils eigene Token erhalten, auch wenn sie aufgrund ähnlicher Aufgaben einen gemeinsamen Service-Account nutzen.

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. Digitale Signaturen SOLLTEN jedes Image gegen Veränderung absichern.

   

 APP.4.4.A10 Absicherung von Prozessen der Automatisierung

 SYS.1.6.A13 Freigabe von Images

Alle Prozesse der Automatisierungssoftware, wie CI/CD und deren Pipelines, SOLLTEN nur mit unbedingt notwendigen Rechten arbeiten. Wenn unterschiedliche Benutzergruppen über die Automatisierungssoftware die Konfiguration verändern oder Pods starten können, SOLLTE dies für jede Gruppe durch eigene Prozesse durchgeführt werden, die nur die für die jeweilige Benutzergruppe notwendigen Rechte besitzen.

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.
   

 APP.4.4.A11 Überwachung der Container

 SYS.1.6.A14 Aktualisierung von Images

In Pods SOLLTE jeder Container einen Health Check für den Start und den Betrieb („readiness“ und „liveness“) definieren. Diese Checks SOLLTEN Auskunft über die Verfügbarkeit der im Pod ausgeführten Software geben. Die Checks SOLLTEN fehlschlagen, wenn die überwachte Software ihre Aufgaben nicht ordnungsgemäß wahrnehmen kann. Für jede dieser Kontrollen SOLLTE eine dem im Pod betriebenen Dienst angemessene Zeitspanne definieren. Auf Basis dieser Checks SOLLTE Kubernetes die Pods löschen oder neu starten.

Bei der Erstellung des Konzeptes für das Patch- und Änderungsmanagement gemäß OPS.1.1.3 Patch- und Änderungsmanagement SOLLTE entschieden werden, wann und wie die Updates der Images oder der betriebenen Software bzw. des betriebenen Dienstes ausgerollt werden. Bei persistenten Containern SOLLTE geprüft werden, ob in Ausnahmefällen ein Update des jeweiligen Containers geeigneter ist, als den Container vollständig neu zu provisionieren.

 APP.4.4.A12 Absicherung der Infrastruktur-Anwendungen

SYS.1.6.A15 Limitierung der Ressourcen pro Container

Sofern eine eigene Registry für Images oder eine Software zur Automatisierung, zur Verwaltung des Festspeichers, zur Speicherung von Konfigurationsdateien oder ähnliches im Einsatz ist, SOLLTE deren Absicherung mindestens betrachten:

  • Verwendung von personenbezogenen und Service-Accounts für den Zugang,
  • verschlüsselte Kommunikation auf allen Netzports,
  • minimale Vergabe der Berechtigungen an Benutzer und Service Accounts,
  • Protokollierung der Veränderungen und
  • regelmäßige Datensicherung.
Für jeden Container SOLLTEN Ressourcen auf dem Host-System, wie CPU, flüchtiger und persistenter Speicher sowie Netzbandbreite, angemessen reserviert und limitiert werden. Es SOLLTE definiert und dokumentiert sein, wie das System im Fall einer Überschreitung dieser Limitierungen reagiert.
   

  Anforderungen bei erhöhtem Schutzbedarf

 

 APP.4.4.A13 Automatisierte Auditierung der Konfiguration

 SYS.1.6.A16 Administrativer Fernzugriff auf Container

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.

Administrative Zugriffe von einem Container auf den Container-Host und umgekehrt SOLLTEN prinzipiell wie administrative Fernzugriffe betrachtet werden. Aus einem Container SOLLTEN KEINE administrativen Fernzugriffe auf den Container-Host erfolgen. Applikations-Container SOLLTEN keine Fernwartungszugänge enthalten. Administrative Zugriffe auf Applikations-Container SOLLTEN immer über die Container-Runtime erfolgen.

   

 APP.4.4.A14 Verwendung dedizierter Nodes

SYS.1.6.A17 Ausführung von Containern ohne Privilegien

In einem Kubernetes-Cluster SOLLTEN die Nodes dedizierte Aufgaben zugewiesen bekommen und jeweils nur Pods betreiben, welche der jeweiligen Aufgabe zugeordnet sind.

Bastion Nodes SOLLTEN alle ein- und ausgehenden Datenverbindungen der Anwendungen zu anderen Netzen übernehmen.

Management Nodes SOLLTEN die Pods der Control Plane betreiben und sie SOLLTEN nur die Datenverbindungen der Control Plane übernehmen.

Sofern eingesetzt, SOLLTEN Speicher-Nodes nur die Pods der Festspeicherdienste im Cluster betreiben.

Die Container-Runtime und alle instanziierten Container SOLLTEN nur von einem nicht- privilegierten 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.

   

 APP.4.4.A15 Trennung von Anwendungen auf Node- und Cluster-Ebene

 SYS.1.6.A18 Accounts der Anwendungsdienste

Anwendungen mit einem sehr hohen Schutzbedarf SOLLTEN jeweils eigene Kubernetes-Cluster oder dedizierte Nodes nutzen, die nicht für andere Anwendungen bereitstehen.

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 und Systemzugriffe gelten. Der Account im Container, der für diesen Datenaustausch notwendig ist, SOLLTE im Host-System bekannt sein.

   

 APP.4.4.A16 Verwendung von Operatoren

SYS.1.6.A19 Einbinden von Datenspeichern in Container

Die Automatisierung von Betriebsaufgaben in Operatoren SOLLTE bei besonders kritischen Anwendungen und den Programmen der Control Plane zum Einsatz kommen.

Die Container SOLLTEN NUR auf die für den Betrieb notwendigen Massenspeicher und Verzeichnisse zugreifen können. Nur wenn Berechtigungen benötigt werden, SOLLTEN diese explizit vergeben werden. Sofern die Container-Runtime für einen Container lokalen Speicher einbindet, SOLLTEN die Zugriffsrechte im Dateisystem auf den Service-Account des Containers eingeschränkt sein. Werden Netzspeicher verwendet, so SOLLTEN die Berechtigungen auf dem Netzspeicher selbst gesetzt werden.

   

 APP.4.4.A17 Attestierung von Nodes

 SYS.1.6.A20 Absicherung von Konfigurationsdaten

Nodes SOLLTEN eine kryptografisch und möglichst mit einem TPM verifizierte gesicherte Zustandsmeldung an die Control Plane senden. Die Control Plane SOLLTE NUR Nodes in den Cluster aufnehmen, die erfolgreich ihre Unversehrtheit nachweisen konnten.

Die Beschreibung der Container-Konfigurationsdaten SOLLTE versioniert erfolgen. Änderungen SOLLTEN nachvollziehbar dokumentiert sein.

   

 APP.4.4.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.

Alle Kriterien, die als Bezeichnung für diese Verbindung dienen, SOLLTEN so abgesichert sein, dass sie nur von berechtigten Personen und Verwaltungs-Diensten verändert werden können.

 
   

 

 Anforderungen bei erhöhtem Schutzbedarf

 APP.4.4.A19 Hochverfügbarkeit von Kubernetes

 SYS.1.6.A21 Erweiterte Sicherheitsrichtlinien

Der Betrieb SOLLTE so aufgebaut sein, dass bei Ausfall eines Standortes die Cluster und damit die Anwendungen in den Pods entweder ohne Unterbrechung weiterlaufen oder in kurzer Zeit an einem anderen Standort neu anlaufen können.

Für den Wiederanlauf SOLLTEN alle notwendigen Konfigurationsdateien, Images, Nutzdaten, Netzverbindungen und sonstige für den Betrieb benötigten Ressourcen inklusive der zum Betrieb nötigen Hardware bereits an diesem Standort verfügbar sein.

Für den unterbrechungsfreien Betrieb des Clusters SOLLTEN die Control Plane von Kubernetes, die Infrastruktur-Anwendungen der Cluster sowie die Pods der Anwendungen anhand von Standort-Daten der Nodes über mehrere Brandabschnitte so verteilt werden, dass der Ausfall eines Brandabschnitts nicht zum Ausfall der Anwendung führt.

Erweiterte Richtlinien SOLLTEN die Berechtigungen der Container einschränken. Mandatory Access Control (MAC) oder eine vergleichbare Technik SOLLTE diese Richtlinien erzwingen. 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.

   

 APP.4.4.A20 Verschlüsselte Datenhaltung bei Pods

 SYS.1.6.A22 Vorsorge für Untersuchungen

Die Dateisysteme mit den persistenten Daten der Control Plane (hier besonders etcd) und der Anwendungsdienste SOLLTEN verschlüsselt werden.

Um Container im Bedarfsfall für eine spätere Untersuchung verfügbar zu haben, SOLLTE ein Abbild des Zustands nach festgelegten Regeln erstellt werden.
   

 APP.4.4.A21 Regelmäßiger Restart von Pods

SYS.1.6.A23 Unveränderlichkeit der Container

Bei einem erhöhten Risiko für Fremdeinwirkung und einem sehr hohen Schutzbedarf SOLLTEN Pods regelmäßig gestoppt und neu gestartet werden. Kein Pod SOLLTE länger als 24 Stunden laufen. Dabei SOLLTE die Verfügbarkeit der Anwendungen im Pod sichergestellt sein.

Container SOLLTEN ihr Dateisystem während der Laufzeit nicht verändern können. Dateisysteme SOLLTEN nicht mit Schreibrechten eingebunden sein.
   
 

SYS.1.6.A24 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).
   
 

SYS.1.6.A25 Hochverfügbarkeit von containerisierten Anwendungen

 

Bei hohen Verfügbarkeitsanforderungen der containerisierten Anwendungen SOLLTE entschieden werden, auf welcher Ebene die Verfügbarkeit realisiert werden soll (z. B. redundant auf der Ebene des Hosts).

   
 

SYS.1.6.A26 Weitergehende Isolation und Kapselung von Containern

 

Wird eine weitergehende Isolation und Kapselung von Containern benötigt, dann SOLLTEN folgende Maßnahmen nach steigender Wirksamkeit geprüft werden:

  • feste Zuordnung von Containern zu Container-Hosts,
  • Ausführung der einzelnen Container und/oder des Container-Hosts mit Hypervisoren,
  • feste Zuordnung eines einzelnen Containers zu einem einzelnen Container-Host.

 

Organisatorische Maßnahmen /  Technische Lösungen

Es lässt sich schnell feststellen, dass die BSI-Bausteine in zwei Gruppen aufgeteilt werden können: organisatorische und technische Maßnahmen. Unter anderem gibt es Maßnahmen, die beiden Gruppen zuzuordnen sind.

Zu den organisatorischen Maßnahmen zählen: die Strukturen, Prozesse und Richtlinien, die innerhalb einer Organisation eingerichtet werden, um die Sicherheit von IT-Systemen und Informationen zu gewährleisten.

Die technischen Maßnahmen erfordern die Implementierung von entsprechenden Software-Lösungen und Sicherheitsmechanismen.

SYS.1.6.

 Organisatorische Maßnahmen   Technische Lösungen 
 SYS.1.6.A1 Planung des Container-Einsatzes (B)   SYS.1.6.A5 Separierung der Administrations- und Zugangsnetze bei Containern (B) 
 SYS.1.6.A2 Planung der Verwaltung von Containern (B)   SYS.1.6.A7 Persistenz von Protokollierungsdaten der Container (B)
 SYS.1.6.A3 Sicherer Einsatz containerisierter IT-Systeme (B)   SYS.1.6.A8 Sichere Speicherung von Zugangsdaten bei Containern (B)
 SYS.1.6.A4 Planung der Bereitstellung und Verteilung von Images (B)    SYS.1.6.A9 Eignung für Container-Betrieb (S)
 SYS.1.6.A6 Verwendung sicherer Images (B)  SYS.1.6.A10 Richtlinie für Images und Container-Betrieb (S) (O+T)
 SYS.1.6.A15 Limitierung der Ressourcen pro Container (S)   SYS.1.6.A11 Nur ein Dienst pro Container (S) (O+T)
 SYS.1.6.A17 Ausführung von Containern ohne Privilegien (S)  SYS.1.6.A12 Hoher Schutzbedarf (S)
 SYS.1.6.A19 Einbinden von Datenspeichern in Container (S)  SYS.1.6.A13 Freigabe von Images (S)
 SYS.1.6.A21 Erweiterte Sicherheitsrichtlinien (H)  SYS.1.6.A14 Aktualisierung von Images (S)
 SYS.1.6.A23 Unveränderlichkeit der Container (H)  SYS.1.6.A16 Administrativer Fernzugriff auf Container (S) (O+T)
 SYS.1.6.A24 Hostbasierte Angriffserkennung (H)  SYS.1.6.A18 Accounts der Anwendungsdienste (S)
 SYS.1.6.A26 Weitergehende Isolation und Kapselung von Containern (H)  SYS.1.6.A20 Absicherung von Konfigurationsdaten (S)
 SYS.1.6.A22 Vorsorge für Untersuchungen (H)
 SYS.1.6.A25 Hochverfügbarkeit von containerisierten Anwendungen (H)

 

APP.4.4

Auch diese Aufteilung kann je nach Interpretation und Anwendungsfall variieren.

 Organisatorische Maßnahmen   Technische Lösungen 
 APP.4.4.A1 Planung der Separierung der Anwendungen (B)   APP.4.4.A4 Separierung von Pods (B)
 APP.4.4.A2 Planung der Automatisierung mit CI/CD (B)   APP.4.4.A6 Initialisierung von Pods (S)
 APP.4.4.A3 Identitäts- und Berechtigungsmanagement bei Kubernetes (B)   APP.4.4.A8 Absicherung von Konfigurationsdateien bei Kubernetes (S)
 APP.4.4.A5 Datensicherung im Cluster (B)  APP.4.4.A11 Überwachung der Container (S)
 APP.4.4.A7 Separierung der Netze bei Kubernetes (S)  APP.4.4.A12 Absicherung der Infrastruktur-Anwendungen (S)
 APP.4.4.A9 Nutzung von Kubernetes Service-Accounts (S)  APP.4.4.A14 Verwendung dedizierter Nodes (H)
 APP.4.4.A10 Absicherung von Prozessen der Automatisierung (S)  APP.4.4.A16 Verwendung von Operatoren (H)
 APP.4.4.A13 Automatisierte Auditierung der Konfiguration (H)  APP.4.4.A18 Verwendung von Mikro-Segmentierung (H)
 APP.4.4.A15 Trennung von Anwendungen auf Node- und Cluster-Ebene (H)  APP.4.4.A20 Verschlüsselte Datenhaltung bei Pods (H)
 APP.4.4.A17 Attestierung von Nodes (H)
 APP.4.4.A19 Hochverfügbarkeit von Kubernetes (H)
 APP.4.4.A21 Regelmäßiger Restart von Pods (H)

 

  • (B) - Basis Anforderungen
  • (S) - Standard-Anforderungen
  • (O+T) - Organisatorisch-Technische Maßnahmen/Lösungen
  • (H) - hoher Schutzbedarf

 

 

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern (Tracking Cookies). Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.