Überlegungen zur Compliance bei Containern und Kubernetes

Wenn Sie Container ausführen, haben Sie wahrscheinlich über potenzielle Sicherheitsrisiken nachgedacht. Möglicherweise haben Sie nur einen DevOps-Ansatz für Ihre Workflows eingeführt, oder Sie verfügen über eine gut etablierte CI/CD-Pipeline, möchten aber Ihre sensiblen Daten schützen.

RBAC (Role-based Access Control) ist die Standardmethode zum Verwalten der Autorisierung für Kubernetes-API-Endpunkte. Die RBAC-Konfiguration Ihres Kubernetes-Clusters steuert, welche Subjekte welche Verben auf welchen Ressourcentypen in welchen Namespaces ausführen können. RBAC schreibt jedoch nicht vor, wie Sie Ihre Rollen konfigurieren müssen. Hier kommen Compliance-Frameworks ins Spiel.

In vielen Branchen ist die Erfüllung von Compliance-Anforderungen ein notwendiger Bestandteil der Geschäftstätigkeit. Anfangs können Bedenken in Bezug auf die Compliance eine Hürde für den Aufbau und die Ausführung containerisiertercloudnativer Anwendungen darstellen. Doch Frameworks und Technologien entwickeln sich schnell weiter, um eine umfassende Compliance in einer cloudnativen Umgebung zu ermöglichen. Die wichtigsten für containerisierte Anwendungen relevante Compliance-Frameworks sind:

• CIS-Benchmarks für Kubernetes und Docker
• NIST SP 800-190
• PCI
• HIPAA

Bei der Compliance geht es letztendlich darum, die Sicherheit Ihrer Anwendungen zu gewährleisten. Die Einhaltung von Compliance-Anforderungen kann jedoch eine größere Herausforderung darstellen als die einfache Sicherung der Anwendung. Denn sie verlangen den Nachweis gegenüber Dritten, dass die Anwendungen kontinuierlich sicher sind. Dazu gehört auch das Verfolgen und Führen von Aufzeichnungen, um die kontinuierliche Einhaltung zu belegen.

Obwohl Compliance kostspielig ist, kann die Nichteinhaltung von Compliance-Standards noch teurer werden. Die durchschnittlichen Kosten für Bußgelder im Zusammenhang mit Compliance-Verstößen sind fast dreimal so hoch wie die durchschnittlichen Kosten für die Einhaltung von Compliance-Anforderungen.

Compliance-Standards spielen eine große Rolle beim Festlegen von Richtlinien für die Sicherheits-Governance in Unternehmen. Statt Richtlinien von Grund auf neu zu erstellen, können Unternehmen Compliance-Frameworks als Ausgangspunkt für ihre eigenen internen Richtlinien verwenden. Dies gilt auch für Unternehmen, die nicht verpflichtet sind, die Richtlinien eines bestimmten Frameworks zu erfüllen.

Die Frameworks

CIS-Benchmarks: Die CIS-Benchmarks wurden vom Center for Internet Security entwickelt und bieten Best Practices für Container, insbesondere solche, die die Docker-Runtime und Kubernetes verwenden. Sie sind jedoch für keine Branche bindend.

NIST 800-190: Das NIST-Framework (National Institute of Standards and Technology) für Containersicherheit ist eines von vielen Frameworks für die Compliance von Cybersicherheit, die vom National Institute of Standards and Technology veröffentlicht wurden. Alle US-Bundesbehörden und Regierungsauftragnehmer müssen die Anforderungen von NIST 800-190 erfüllen.

PCI: Das PCI-Framework (Payment Card Industry) wurde im Rahmen einer Partnerschaft von fünf großen Kreditkartenunternehmen entwickelt und deckt Organisationen ab, die Zahlungsinformationen speichern, verarbeiten und übertragen.

HIPAA: Die technologischen Sicherheitsvorkehrungen der HIPAA-Vorschriften bestimmen, wie Organisationen, die individuell identifizierbare elektronisch geschützte Gesundheitsdaten sammeln, verarbeiten oder übermitteln.

Die National Institute of Standards and Technology Special Publication 800-190 (NIST 800-190) bietet ein Framework, um einige der spezifischen Herausforderungen im Zusammenhang mit der Sicherheit von containerisierten Anwendungen zu verstehen und zu erfahren, was Unternehmen tun müssen, um das Sicherheitsprofil der Anwendung zu verbessern.

Die NIST-Richtlinien betreffen US-Regierungsbehörden sowie deren Auftragnehmer. Doch auch andere Unternehmen möchten möglicherweise die NIST 800-190-Richtlinien befolgen, sowohl um die allgemeine Sicherheit zu verbessern, als auch um die Einhaltung anderer Compliance-Frameworks wie PCI und HIPAA zu erleichtern.

Die Risiken

NIST 800-190 weist auf häufige Ursachen für Sicherheitslücken in containerisierten Anwendungen hin, darunter:

• Beschädigte Images
• Fehlkonfigurationen bei Container-Images
• Nicht vertrauenswürdige Container-Images
• Fehlerhaft gemanagte Secrets
• Fehlkonfigurationen bei Zugriffskontrollen
• Sicherheitslücken im Betriebssystem
• Unnötig große Angriffsflächen

Ebenso wird bei NIST 800-190 die Notwendigkeit betont, dass Unternehmen die Sicherheit für containerisierte Anwendungen anders angehen als für herkömmliche Anwendungen. Containerisierte Anwendungen haben andere Risikofaktoren als virtuelle Maschinen und erfordern andere Sicherheitsmaßnahmen.

NIST 800-190 verlangt, dass Organisationen:

• speziell entwickelte Tools verwenden, um Schwachstellen während des gesamten Image-Lebenszyklus zu beseitigen, von der Entwicklung über die Bereitstellung bis zur Laufzeit.
• sicherstellen, dass Images den Best Practices für die Konfiguration entsprechen.
• Secrets durch Speichern außerhalb des Images schützen, Kubernetes zum Verwalten von Secrets verwenden, den Zugriff auf Secrets auf die Container beschränken, die sie unbedingt benötigen, sowie Secrets im Ruhezustand und bei der Übertragung verschlüsseln.
• beim Push oder Pull aus der Registry eine sichere Verbindung nutzen.
• sicherstellen, dass Container immer die neueste Image-Version verwenden.
• den Netzwerkverkehr segmentieren, um zumindest sensible von nicht sensiblen Netzwerken zu isolieren.
• Kubernetes verwenden, um Knoten sicher einzuführen, und eine Bestandsaufnahme der Knoten und ihrer Konnektivitätszustände zu führen.
• von Containern ausgehenden Datenverkehr kontrollieren.
• die kontinuierliche Einhaltung von Standards für Container-Laufzeitkonfigurationen wie den CIS-Benchmarks sicherstellen.
• Sicherheitskontrollen durchführen, um Bedrohungen und potenzielle Angriffe auf Container- und Infrastrukturebene zu erkennen.
• ein gehärtetes, containerspezifisches Betriebssystem mit einer möglichst kleinen Angriffsfläche verwenden.
• Manipulationen des Host-Dateisystems verhindern, indem sichergestellt wird, dass Container so wenig Berechtigungen wie möglich haben, um wie geplant zu funktionieren.

Selbst Organisationen, die die NIST 800-190-Anforderungen nicht erfüllen müssen, sollten sie als nützliches Framework zur Verbesserung des Sicherheitsstatus der Organisation betrachten. Diese Anforderungen stellen sicher, dass Unternehmen während der gesamten Entwicklungs-, Bereitstellungs- und Laufzeitphase die Sicherheit bedenken und die speziellen Sicherheitsanforderungen jeder Phase berücksichtigen.

Der Payment Card Industry Data Security Standard (PCI DSS) wurde 2004 von Visa, MasterCard, American Express, Discover und JCP aufgestellt, um einen branchenweiten Standard für Sicherheit und Datenschutz zu setzen. Die Standards wurden seit ihrer ersten Veröffentlichung viele Male aktualisiert, um mit den technologischen Veränderungen Schritt zu halten. Die Standards gelten für die gesamte Karteninhaberdatenumgebung, also für die Personen, Prozesse und Technologien, die Karteninhaberdaten speichern, verarbeiten oder übertragen. Technologisch umfasst dies sowohl Hard- als auch Software.

Die Einhaltung der PCI-Anforderungen ist nicht einfach und kostet Unternehmen durchschnittlich 5,5 Millionen US-Dollar pro Jahr. Die Nichteinhaltung ist jedoch mit durchschnittlichen jährlichen Kosten von 14,8 Millionen US-Dollar aufgrund von Strafen viel teurer. Mit den richtigen Prozessen und Tools muss die PCI-Compliance keine große Herausforderung sein.

PCI DSS hat zwölf Anforderungen, die sechs allgemeineren Zielen zugeordnet sind. Sie sind:

Erstellen und Pflegen eines sicheres Netzwerksystems

1. Installieren und Pflegen einer Firewall-Konfiguration zum Schutz der Karteninhaberdaten
2. Keine Verwendung von durch Hersteller bereitgestellte Standardwerten für Systemkennwörter und andere Sicherheitsparameter

Schutz von Karteninhaberdaten

1. Schutz gespeicherter Karteninhaberdaten
2. Verschlüsselte Übertragung von Karteninhaberdaten über offene, öffentliche Netzwerke

Sicherstellen der Wartung von Schwachstellenmanagement-Programmen

1. Schutz aller Systeme vor Malware und Exploits sowie regelmäßige Aktualisierung der Antivirensoftware
2. Entwicklung und Wartung sicherer Systeme und Anwendungen
3. Implementierung starker Zugriffskontrollmaßnahmen

Beschränkung des Zugriffs auf Karteninhaberdaten durch Unternehmen nach dem Need-to-know-Prinzip

1. Identifizieren und Authentifizieren des Zugriffs auf Systemkomponenten
2. Einschränkung des physischen Zugriffs auf Karteninhaberdaten

Regelmäßiges Überwachen und Testen der Netzwerke

1. Verfolgung und Überwachung des gesamten Zugriffs auf Netzwerkressourcen und Karteninhaberdaten
2. Regelmäßiges Testen von Sicherheitssystemen und -prozessen

Sicherstellen der Einhaltung von Richtlinien zur Informationssicherheit

1. Pflegen einer Richtlinie, die Informationssicherheit für alle Beschäftigten berücksichtigt

PCI-Compliance für containerisierte Anwendungen

Es gibt mehrere Anforderungen in Bezug auf jedes der oben genannten sechs von PCI skizzierten Ziele, die direkt für Container- und Kubernetes-Umgebungen relevant sind. Bewerten Sie Ihre Container- und Kubernetes-Sicherheitstools, um sicherzustellen, dass sie die folgenden Anforderungen erfüllen:

1.12 Aktuelles Netzwerkdiagramm, das alle Verbindungen zwischen der Karteninhaberdatenumgebung (Cardholder Data Environment, CDE) und anderen Netzwerken identifiziert, einschließlich aller drahtlosen Netzwerke.

1.1.4 Eine obligatorische Firewall an jeder Internetverbindung und zwischen jeder demilitarisierten Zone (DMZ) und der internen Netzwerkzone.

1.2 Einrichtung von Firewall- und Router-Konfigurationen, die Verbindungen zwischen nicht vertrauenswürdigen Netzwerken und allen Systemkomponenten in der Karteninhaberdatenumgebung einschränken.

1.2.1 Beschränkung des ein- und ausgehenden Datenverkehrs auf das für die Karteninhaberdatenumgebung erforderliche Maß und explizite Verweigerung jeglichen anderen Datenverkehrs.

1.3.2 Beschränkung des eingehenden Internetverkehrs auf IP-Adressen innerhalb der DMZ.

1.3.4 Verhinderung von unbefugtem ausgehendem Datenverkehr von der Karteninhaberdatenumgebung zum Internet.

1.3.5 Ausschließliche Zulassung „etablierter" Verbindungen in das Netzwerk.

2.1 Konsequentes Ändern der vom Anbieter bereitgestellten Standardeinstellungen sowie Entfernen oder Deaktivieren nicht erforderlicher Standard-Accounts vor der Einrichtung eines Systems im Netzwerk.

2.2 Entwicklung von Konfigurationsstandards für alle Systemkomponenten. Es muss sichergestellt werden, dass diese Standards alle bekannten Sicherheitslücken schließen und mit den branchenweit anerkannten Standards für die Systemhärtung übereinstimmen.

2.2.1 Implementieren einer primären Funktion pro Server, um zu verhindern, dass gleichzeitig Funktionen, die unterschiedliche Sicherheitsstufen erfordern, auf demselben Server vorhanden sind. (Beispielsweise müssen Webserver, Datenbankserver und DNS auf separaten Servern implementiert werden.)

2.2.2 Ausschließliche Aktivierung erforderlicher Services, Protokolle, Daemons usw., die für die Funktion des Systems erforderlich sind.

2.2.3 Implementierung zusätzlicher Sicherheitsfunktionen für alle erforderlichen Services, Protokolle oder Daemons, die als unsicher gelten.

2.2.5 Entfernen aller nicht erforderlicher Funktionen wie Skripte, Treiber, Funktionen, Subsysteme, Dateisysteme und nicht erforderlicher Webserver.

2.3 Verschlüsselung aller Nicht-Konsolen-Verwaltungszugriffe mit starker Kryptographie.

2.4 Durchführung einer Bestandsaufnahme der Systemkomponenten, die in den Geltungsbereich von PCI DSS fallen.

3.6.2 Sichere Verteilung von kryptografischen Schlüsseln.

6.1 Einrichtung eines Prozesses zur Erkennung von Sicherheitslücken, indem seriöse externe Quellen für sicherheitsrelevante Informationen verwendet werden und neu entdeckten Sicherheitslücken eine Risikoeinstufung (z. B. als „hoch", „mittel" oder „niedrig") zugewiesen wird.

6.2 Schutz aller Systemkomponenten und Softwareprogrammen vor bekannten Schwachstellen durch Installieren der entsprechenden vom Hersteller bereitgestellten Sicherheitspatches. Kritische Sicherheitspatches müssen innerhalb eines Monats nach der Veröffentlichung installiert werden.

6.4.1 Trennen von Entwicklungs-/Testumgebungen von Produktivumgebungen und Erzwingen der Trennung mit Zugriffstools.

6.4.2 Aufgabentrennung zwischen Entwicklungs-/Test- und Produktivumgebung.

6.5.1 Injection-Fehler, insbesondere bei SQL-Injection. OS Command Injection-, LDAP- und XPath-Injection-Fehler sowie andere Injection-Fehler sind ebenfalls zu berücksichtigen.

6.5.3 Unsichere kryptografische Speicherung.

6.5.4 Unsichere Kommunikation.

6.5.6 Alle Schwachstellen mit „hohem Risiko", die im Schwachstellenerkennungsprozess identifiziert wurden (wie in PCI-DSS-Anforderung 6.1 definiert).

10.2.5 Implementierung automatisierter Audit-Trails für alle Systemkomponenten, um die Verwendung und Änderungen von Identifizierungs- und Authentifizierungsmechanismen – unter anderem bei Erstellung neuer Accounts und Erweiterung von Berechtigungen – sowie alle Änderungen, Hinzufügungen oder Löschungen von Konten mit Root- oder administrativen Berechtigungen zu rekonstruieren.

11.2.1 Durchführen vierteljährlicher interner Schwachstellen-Scans. Beheben von Schwachstellen und wiederholte Durchführung von Scans, um zu überprüfen, ob alle Schwachstellen mit „hohem Risiko" gemäß dem Schwachstellenranking des Unternehmens (gemäß Anforderung 6.1) behoben wurden. Die Scans müssen von qualifiziertem Personal durchgeführt werden.

11.5 Bereitstellung eines Mechanismus zur Erkennung von Änderungen (z. B. Tools zur Überwachung der Dateiintegrität), um das Personal auf unbefugte Änderungen (einschließlich Änderungen, Hinzufügungen und Löschungen) kritischer Systemdateien, Konfigurationsdateien oder Inhaltsdateien aufmerksam zu machen. Konfiguration der Software, um kritische Dateivergleiche mindestens wöchentlich durchzuführen.

11.5.1 Implementierung eines Prozesses, um auf alle Warnungen zu reagieren, die von der Änderungserkennungslösung generiert werden.

Mit dem Health Information Portability and Accountability Act von 1996 wurde das HIPAA-Compliance-Framework geschaffen, um den Schutz von Patientendaten in Bezug auf alle Gesundheitsakten zu regeln. Die 2003 hinzugefügte „Security Rule" regelt digitale Patientenakten. Jede Organisation, die individuell identifizierbare elektronisch geschützte Gesundheitsdaten (ePHI) verarbeitet, muss die HIPAA-Anforderungen erfüllen. Dazu gehören Anwendungen, die unmittelbar von Gesundheitsdienstleistern für die Pflege, die Kommunikation sowie für die Abrechnung verwendet werden.

Die Hauptherausforderung für die HIPAA-Compliance besteht darin, dass das Sicherheits-Framework nur allgemeine Leitlinien und keine spezifischen Informationen zur Einhaltung dieser Richtlinien in Containern und Kubernetes bereitstellt. Darüber hinaus ist der Unterschied zwischen geschützten und nicht geschützten Gesundheitsdaten oft weniger offensichtlich als beispielsweise bei Kreditkarteninformationen, die gemäß PCI-Compliance geschützt werden müssen.

Neben den Gesundheitsdienstleistern selbst müssen alle Organisationen, die Dienstleistungen wie die Speicherung oder Abrechnung für Gesundheitsdienstleister erbringen, die HIPAA-Anforderungen erfüllen, wenn die von ihnen erbrachten Dienstleistungen den Umgang mit elektronisch geschützten Gesundheitsdaten (ePHI) beinhalten.

Die Standards der HIPAA-Sicherheitsregeln sind in administrative, physische und technische Schutzmaßnahmen unterteilt. Die technischen Schutzmaßnahmen, die sich auf die IT-Infrastruktur beziehen, umfassen folgende Standards:

• Zugangskontrolle
• Audits
• Integrität
• Authentifizierung
• Übertragungssicherheit

Die HIPAA-Sicherheitsregeln enthalten keine Einzelheiten dazu, wie Unternehmen ePHI schützen sollten, und gelten nicht spezifisch für containerisierte Anwendungen. Der beste Ausgangspunkt für die Arbeit an der Einhaltung der HIPAA-Compliance ist oft die Anwendung des NIST SP 800-190-Frameworks, das Richtlinien und Best Practices für die Container-Sicherheit bereitstellt. Im Gegensatz zu HIPAA bietet NIST SP 800-190 ein spezifisches Framework für Container. Daher lässt sich die Compliance leichter nachweisen. Die Erfüllung der HIPAA-Anforderungen erfordert jedoch die Implementierung zusätzlicher Datentrennungskontrollen, um ePHI zu schützen und von anderen Datentypen getrennt zu halten.

HIPAA verlangt auch, dass Unternehmen nicht nur Daten, sondern auch Konfigurationsdateien sichern, damit die Anwendung vollständig wiederhergestellt werden kann, um eine kontinuierliche Compliance nachzuweisen.