Freigeben über

Sicherheit für AKS

  • Artikel

Dieser Artikel führt Sie durch Aspekte der AKS-Sicherheitsgovernance (Azure Kubernetes Service), die vor der Implementierung einer Lösung bedacht werden müssen.

Der Schwerpunkt des Artikels liegt auf der Implementierung von Lösungen mit Azure und Open-Source-Software. Die von Ihnen getroffenen Entscheidungen beim Erstellen einer Zielzone auf Unternehmensniveau können Ihre Governance teilweise vorab definieren. Informationen zu den Prinzipien der Governance finden Sie unter Sicherheitsgovernance und -compliance auf Unternehmensniveau.

Angriffsflächen

Berücksichtigen Sie die folgenden fünf Angriffsflächen, wenn Sie eine Sicherheitsstrategie für Kubernetes-Cluster erstellen:

  • Entwickeln
  • Registrierung
  • Cluster
  • Node
  • Application

In diesem Artikel werden die größten Risiken und die entsprechenden Gegenmaßnahmen für jede Kategorie erörtert.

Sicherheit

Bei der Buildsicherheit geht es um die ordnungsgemäße Verwendung von DevSecOps mit Containerimages.

Größte Risiken

Eine schlecht geplante Imagekonfiguration kann später zu Sicherheitsrisiken führen. Ein Beispiel hierfür wären Container, die mit umfassenderen Berechtigungen ausgeführt werden als erforderlich. Die Container können auch so konfiguriert werden, dass unterschiedliche Netzwerkzugriffe zugelassen werden, was das System gefährden kann. Wenn die zulässigen Systemaufrufe nicht auf diejenigen beschränkt werden, die für den sicheren Betrieb von Containern erforderlich sind, kann sich das Risiko durch kompromittierte Container erhöhen.

Weitere Sicherheitsrisiken können dadurch entstehen, dass Containern der Zugriff auf ein vertrauliches Verzeichnis des Hosts oder die Änderung der Speicherorte ermöglicht wird, die die grundlegende Funktion des Hosts steuern.

Nicht autorisierte Container sind nicht geplante Container in einer Umgebung. Sie können entstehen, wenn Entwickler*innen ihren Code in Testumgebungen testen. Diese Container wurden möglicherweise nicht gründlich auf Sicherheitsrisiken überprüft oder sind nicht ordnungsgemäß konfiguriert. Diese Sicherheitsrisiken können Angreifern einen Einstiegspunkt eröffnen.

Die Verwendung von Basisimages, die nicht aus vertrauenswürdigen Quellen stammen oder nicht über aktuelle Sicherheitsupdates verfügen, kann auch zu Sicherheitsrisiken in den Containern führen, die diese Images für Buildprozesse verwenden.

Gegenmaßnahmen

Bei der Buildsicherheit geht es um die Implementierung von DevSecOps, um die Sicherheitstests früher im Lebenszyklus durchzuführen (Shift-left-Testing) und die meisten Probleme zu beheben, bevor die Pipeline heruntergefahren wird. Es geht nicht darum, die gesamte Verantwortung den Entwicklern aufzubürden, sondern dass diese gemeinsam mit den Betreibern die Verantwortung übernehmen. Entwickler können dann Sicherheitsrisiken und Konformitätsprobleme erkennen und beheben, gegen die sie auch wirklich etwas ausrichten können.

Sie können eine Pipeline erstellen, die Builds überprüft und fehlschlagen lässt, weil sie eine oder 10 kritische Sicherheitsrisiken aufweist. Es kann aber sinnvoller sein, die Ebene darunter zu betrachten. Sie können beginnen, den Zuständigkeitspunkt basierend auf dem Herstellerstatus zu segmentieren.

Legen Sie einen Schwellenwert auf der Statusebene des Sicherheitsrisikos fest. Alle Ereignisse mit den Status Offen, Wird nicht korrigiert oder Zurückgestellt werden in der Pipeline weitergereicht, wo SecOps sich die Risiken ansehen kann, so wie es auch heute schon der Fall ist. Ein Sicherheitsrisiko mit dem Status Fehlerbehebung durch Anbieter verfügbar ist etwas, das auf Entwicklerseite behoben werden kann. Karenzzeiten geben Entwickler*innen die notwendige Zeit, um Sicherheitsrisiken zu beheben.

Zusammen mit der Bewertung des Sicherheitsrisikos erfolgt die Konformitätsbewertung. Wenn beispielsweise zugelassen wird, dass ein Image als Root ausgeführt wird, oder SSH verfügbar gemacht wird, ist in den meisten Unternehmen der Compliancestatus nicht mehr erfüllt. Dieses Problem sollte während des Buildvorgangs behoben werden, nicht erst bei der Bereitstellung.

In der Regel überprüfen Sie Ihre Images anhand des Docker CIS-Benchmarks. Wenn Sie diese Arten von Flows verwenden, unterbrechen Sie die Entwicklung nicht, wenn Sie eine Sicherheitswartung einführen, aber Sie können den Sicherheitsstatus Ihres Unternehmens insgesamt inline verbessern.

Die Verwendung eines Tools, das diese Funktionen ermöglicht, ist wichtig, um die richtige Strategie für Ihr Unternehmen effektiv zu implementieren. Herkömmliche Tools können Sicherheitsrisiken in Containern häufig nicht erkennen, was zu einem falschen Gefühl der Sicherheit führt. Um Ihr Containerökosystem ordnungsgemäß zu schützen, sind Tools erforderlich, die den pipelinebasierten Buildansatz und die unveränderliche und deklarative Natur von Containertechnologien berücksichtigen.

Diese Tools sollten die folgenden Eigenschaften aufweisen:

  • Integrationsfähigkeit über die gesamte Lebensdauer der Images – vom anfänglichen Buildprozesses über die Registrierung bis hin zur Laufzeit.
  • Einblick in Sicherheitsrisiken auf allen Ebenen des Images erhalten, einschließlich der Basisebene des Images, des Anwendungsframeworks und individueller Software.
  • Richtlinienbasierte Erzwingung mit der richtigen Granularität, sodass Ihre Organisation für jede Phase des Build- und Bereitstellungsprozesses Qualitätsprüfpunkte (Quality Gates) erstellen kann.

Registrierungssicherheit

Bei der Registrierungssicherheit geht es um:

  • Kontrolle von Abweichungen vom Build
  • Verhindern von Push-/Pullvorgängen infizierter Images
  • Signieren von Images

Größte Risiken

Images enthalten häufig geschützte Informationen, einschließlich des Quellcodes einer Organisation. Wenn Verbindungen mit Registrierungen nicht ordnungsgemäß gesichert sind, kann der Inhalt eines Images Vertraulichkeitsrisiken bergen, die so schwerwiegend sind wie bei jeder anderen Form von Datenübertragung in Ihrer Organisation. Veraltete Images mit anfälligen veralteten Versionen in der Registrierung können das Sicherheitsrisiko erhöhen, wenn sie versehentlich bereitgestellt werden.

Sicherheitsrisiken können auch durch unzureichende Authentifizierungs- und Autorisierungseinschränkungen bei Containerregistrierungen entstehen. Diese Registrierungen können vertrauliche proprietäre Ressourcen in den Images enthalten.

Beim Erstellen und Bereitstellen von Inhalten ist die Verteilung dieser Inhalte einer der vielen Angriffsvektoren. Wie stellen Sie sicher, dass Inhalte, die zur Verteilung bereitgestellt werden, dieselben Inhalte sind, die an einen vorgesehenen Endpunkt übermittelt werden?

Gegenmaßnahmen

Richten Sie Bereitstellungsprozesse ein, um sicherzustellen, dass Entwicklungstools, Netzwerke und Containerruntimes nur über verschlüsselte Kanäle mit Registrierungen verbunden sind. Stellen Sie auch sicher, dass Inhalte aus vertrauenswürdigen Quellen stammen. So reduzieren Sie durch die Verwendung veralteter Images entstehende Risiken:

  • Entfernen Sie unsichere, anfällige Images, die nicht mehr aus Containerregistrierungen heraus verwendet werden sollen.
  • Erzwingen Sie den Zugriff auf Images durch unveränderliche Namen, die bestimmte Imageversionen angeben, die verwendet werden müssen. Sie können diese Konfiguration mithilfe des Tags latest oder einer bestimmten Version der Images implementieren. Ein Tag garantiert keine Aktualität. Richten Sie daher einen Prozess ein, der sicherstellt, dass der Kubernetes-Orchestrator die neuesten eindeutigen Versionsnummern verwendet oder dass das Tag latest die neueste Version angibt.

Der Zugriff auf Registrierungen, die vertrauliche Images enthalten, sollte Authentifizierung und Autorisierung erfordern. Für den gesamten Schreibzugriff sollte auch eine Authentifizierung erforderlich sein. Ihre Richtlinie könnte Entwickler*innen beispielsweise das Pushen von Images nur an die spezifischen Repositorys erlauben, für die sie verantwortlich sind.

Der Zugriff auf diese Registrierungen sollte im Verbund und über Zugriffsrichtlinien auf Geschäftsbereichsebene erfolgen. Sie können Ihre CI/CD-Pipeline beispielsweise so konfigurieren, dass Images erst dann in Repositorys gepusht werden, nachdem sie die Compliancebewertung und Qualitätskontrolltests zur Überprüfung auf Sicherheitsrisiken bestanden haben.

Containerregistrierungen – die jetzt als Artefaktregistrierungen angesehen werden – werden zunehmend zu einem primären Mittel zum Bereitstellen beliebiger Inhaltstypen (d. h. nicht nur von Containerimages). Jede Cloud stellt eine Registrierung mit Open-Source-Projekten und Anbieterprodukten bereit, die lokal oder privat von Cloudanbietern gehostet werden können. Inhalte werden innerhalb und über Registrierungen hinweg vom ersten Build bis zur Produktionsbereitstellung heraufgestuft.

Wie können Sie die Integrität der Inhalte gewährleisten – also sicherstellen, dass die Inhalte, die in der Registrierung gespeichert wurden, dieselben sind, die aus der Registrierung abgerufen werden? Eine Lösung zum Signieren von Images stellt sicher, dass Bereitstellungen nur von vertrauenswürdigen Registrierungen stammen und vertrauenswürdige Inhalte bereitstellen.

Clustersicherheit

Bei der Clustersicherheit geht es um:

  • Authentifizierung und Autorisierung:
  • Netzwerksicherheit.
  • Sicherheitsrisiken und Konformitätsverwaltung

Größte Risiken

Manchmal wird ein einzelner Kubernetes-Cluster verwendet, um verschiedene Anwendungen auszuführen, die von verschiedenen Teams mit unterschiedlichen Zugriffsebenenanforderungen verwaltet werden. Wenn der Zugriff für Personen ohne Beschränkungen oder nur gemäß ihren Anforderungen gewährt wird, könnte ein böswilliger oder unvorsichtiger Benutzer Workloads kompromittieren, auf die er Zugriff hat, sowie andere Ressourcen im Cluster.

Ein weiteres Sicherheitsrisiko kann entstehen, wenn Autorisierung und Authentifizierung durch das eigene Benutzerverzeichnis des Clusters verwaltet werden. Ein Authentifizierungsverzeichnis auf Organisationsebene wird häufig strenger kontrolliert. Da diese Konten über hohe Berechtigungen verfügen und häufiger verwaist sind, steigt die Wahrscheinlichkeit eines kompromittierten Kontos.

Ein solches Szenario kann zu cluster- oder sogar systemweiten Sicherheitsrisiken führen. In Containervolumes gespeicherte Daten werden von Orchestratoren verwaltet, die Zugriff auf die Daten haben müssen, unabhängig davon, auf welchem Knoten diese gehostet werden.

Herkömmliche Netzwerkfilter können aufgrund einer Netzwerküberlagerung, die zur Verschlüsselung von Daten während der Übertragung dient, eine Sicherheitslücke aufweisen. Dieses Design erschwert die Überwachung des Datenverkehrs innerhalb des Clusters, sodass möglicherweise spezielle Vorkehrungen zur Überwachung von Kubernetes-Clustern erforderlich sind.

Datenverkehr aus verschiedenen Anwendungen, die denselben Cluster gemeinsam nutzen, kann unterschiedliche Vertraulichkeitsstufen aufweisen, z. B. eine öffentliche Website und eine interne Anwendung, die kritische vertrauliche Geschäftsprozesse ausführt. Die gemeinsame Nutzung desselben virtuellen Netzwerks innerhalb des Clusters kann zur Kompromittierung vertraulicher Daten führen. Angreifer*innen könnten beispielsweise das im Internet verfügbar gemachte freigegebene Netzwerk nutzen, um interne Anwendungen anzugreifen.

Schützen Sie Komponenten, die den Cluster selbst ausführen, vor Sicherheitsrisiken und Konformitätsproblemen. Stellen Sie sicher, dass Sie die neueste verfügbare Version von Kubernetes ausführen, um die Wartung effektiv nutzen zu können.

Gegenmaßnahmen

Für den Benutzerzugriff auf den Kubernetes-Cluster sollte ein Zugriffsmodell mit den geringsten Rechten verwendet werden. Gewähren Sie Benutzern Zugriff nur, um bestimmte Aktionen auf bestimmten Hosts, Containern und Images auszuführen, die für ihre Aufgaben erforderlich sind. Testteammitglieder sollten nur eingeschränkten oder keinen Zugriff auf Container in der Produktion haben. Benutzerkonten mit clusterweitem Zugriff sollten strikt kontrolliert und möglichst wenig eingesetzt werden.

Verwenden Sie sichere Authentifizierungsmethoden wie eine Multi-Faktor-Authentifizierung, um den Zugriff auf diese Konten zu sichern. Ein Organisationsbenutzerverzeichnis sollte verwendet werden, um Cluster per einmaligem Anmelden zu verwalten – im Gegensatz zu clusterspezifischen Benutzerkonten, für die möglicherweise keine gleichwertigen Richtlinien und Kontrollmechanismen existieren.

Verwenden Sie Verschlüsselungsmethoden, mit denen Container unabhängig von dem Host, auf dem die Container ausgeführt werden, ordnungsgemäß auf Daten zugreifen können. Diese Verschlüsselungstools sollten den nicht autorisierten Zugriff auf Daten durch andere Container verhindern, und zwar auch innerhalb desselben Knotens, der keinen Zugriff darauf haben sollte.

Konfigurieren Sie Kubernetes-Cluster so, dass der Netzwerkdatenverkehr nach Vertraulichkeitsstufe in separate virtuelle Netzwerke oder Subnetze aufgeteilt wird. Eine anwendungsbasierte Segmentierung kann auch sinnvoll sein, oft reicht es aber aus, Netzwerke einfach anhand von Vertraulichkeitsstufen zu definieren. Zumindest sollten virtuelle Netzwerke für Kundenanwendungen von den Netzwerken getrennt implementiert werden, in denen interne Anwendungen mit vertraulichem Datenverkehr ausgeführt werden.

Sie können „Taints und Toleranzen“ verwenden, um Bereitstellungen für bestimmte Knotengruppen anhand von Vertraulichkeitsstufen zu isolieren. Vermeiden es, hochvertrauliche Workloads auf demselben Knoten zu hosten, auf dem sich auch weniger vertrauliche Workloads befinden. Die Verwendung separat verwalteter Cluster stellt eine Option mit höherer Sicherheit dar.

Segmentieren Sie Container nach Verwendungszweck, Vertraulichkeit und Threadstatus, um zusätzlichen Schutz für vertrauliche Workloads einzurichten. Werden Container auf diese Weise segmentiert, ist es für Angreifer*innen, die sich Zugriff auf ein Segment verschafft haben, viel schwieriger, auch Zugriff auf andere Segmente zu erhalten. Diese Konfiguration bietet zudem den Vorteil, dass Restdaten wie Caches oder Volumebereitstellungen anhand der Vertraulichkeitsstufe isoliert werden.

Kubernetes-Cluster sollten wie folgt konfiguriert werden:

  • Stellen Sie eine sichere Umgebung für Anwendungen bereit, die in den Clustern ausgeführt werden.
  • Stellen Sie sicher, dass Knoten dem Cluster auf sichere Weise hinzugefügt werden.
  • Richten Sie permanente Identitäten ein, um die Sicherheit während des gesamten Lebenszyklus sicherzustellen.
  • Bereitstellen von genauen Liveinformationen zum Zustand des Clusters, einschließlich des Netzwerks und der darin enthaltenen Knoten.

Es muss einfach sein, einen kompromittierten Knoten zu isolieren und aus dem Cluster zu entfernen, ohne die Leistung des Clusters zu beeinträchtigen. AKS macht dies einfach.

Definieren Sie Container Runtime-Konfigurationsstandards, um die Compliance automatisch sicherzustellen. Azure bietet viele Richtlinien, die diesen Prozess vereinfachen, zudem können Benutzer*innen auch eigene Richtlinien erstellen. Verwenden Sie die Azure-Sicherheitsfunktionen, um die Konfigurationseinstellungen in der gesamten Umgebung kontinuierlich zu bewerten und aktiv zu erzwingen.

Stellen Sie sicher, dass Sicherheitsrisiken der Kubernetes-Komponenten automatisch behoben werden. Verwenden Sie separate Umgebungen für Entwicklung, Test und Produktion mit jeweils eigenen Kontrollmechanismen und rollenbasierter Zugriffssteuerung (Role-Based Access Control, RBAC) für die Containerverwaltung. Ordnen Sie sämtliche Vorgänge der Containererstellung einzelnen Benutzeridentitäten zu, und protokollieren Sie diese Vorgänge, damit sie überprüft werden können. Diese Konfiguration trägt dazu bei, das Risiko von autorisierter Containern zu verringern.

Knotensicherheit

Bei der Knotensicherheit geht es um:

  • Laufzeitschutz
  • Sicherheitsrisiken und Konformitätsverwaltung

Größte Risiken

Ein Workerknoten verfügt über privilegierten Zugriff auf alle Komponenten auf dem Knoten. Angreifer*innen können jeden Dienst, der über das Netzwerk zugänglich ist, als Einstiegspunkt nutzen, sodass der Zugriff auf den Host von mehreren Punkten aus die Angriffsfläche erheblich vergrößern kann. Je größer die Angriffsfläche ist, desto größer ist die Wahrscheinlichkeit, dass Angreifer*innen sich Zugriff auf den Knoten und sein Betriebssystem verschaffen können.

Darüber hinaus verfügen containerspezifische Betriebssysteme (wie jene, die in AKS-Knoten verwendet werden) über weniger Angriffsfläche, da sie keine Bibliotheken enthalten, die es regulären Betriebssystemen ermöglichen, Datenbanken und Webserver direkt auszuführen. Die Verwendung eines gemeinsam genutzten Kernels führt dazu, dass Container, die in derselben Umgebung ausgeführt werden, eine größere Angriffsfläche bieten als Container auf separaten VMs. Dies ist auch dann der Fall, wenn containerspezifische Betriebssysteme verwendet werden, die auf AKS-Knoten ausgeführt werden.

Hostbetriebssysteme stellen grundlegende Systemkomponenten bereit, die Sicherheitsrisiken und Konformitätsrisiken aufweisen können. Da es sich hierbei um Low-Level-Komponenten handelt, können sich ihre Sicherheitsrisiken und ihre Konfiguration auf alle gehosteten Container auswirken. AKS schützt Benutzer*innen, indem sichergestellt wird, dass diese Sicherheitsrisiken über regelmäßige Betriebssystemupdates auf den in AKS ausgeführten Knoten behoben werden und dass der Compliancestatus des Workerknotens beibehalten wird.

Zu umfangreiche Benutzerzugriffsrechte können auch zu Sicherheitsrisiken führen, wenn sich Benutzer*innen zur Verwaltung der Container direkt bei den Knoten anmelden anstatt über die AKS-Steuerungsebene. Durch die direkte Anmeldung kann es sein, dass der Benutzer Änderungen an Anwendungen vornehmen kann, auf die er eigentlich keinen Zugriff haben sollte.

Außerdem können schädliche Container zu Manipulationen am Dateisystem des Hostbetriebssystems führen. Wenn ein Container beispielsweise ein vertrauliches Verzeichnis in das Hostbetriebssystem einbinden darf, könnte diese Container Änderungen an den Dateien vornehmen. Die Änderungen könnten sich auf die Sicherheit anderer Container auswirken, die auf dem Host ausgeführt werden.

Gegenmaßnahmen

Beschränken Sie den Knotenzugriff durch Einschränkung des SSH-Zugriffs.

Die Verwendung eines containerspezifischen Betriebssystems auf AKS-Knoten reduziert in der Regel die Angriffsfläche, da andere Dienste und Funktionen deaktiviert sind. Sie verfügen auch über schreibgeschützte Dateisysteme und verwenden standardmäßig andere Methoden zur Clusterhärtung.

Die Azure-Plattform wendet über Nacht automatisch Betriebssystem-Sicherheitspatches auf die Linux-Knoten an. Wenn ein Betriebssystem-Sicherheitsupdate für Linux einen Neustart des Hosts erfordert, erfolgt der Neustart nicht automatisch. AKS bietet Mechanismen zum Neustarten, um diese spezifischen Patches anzuwenden.

Microsoft Defender for Servers kann auf AKS-Knoten unter Linux und Windows nicht verwendet werden, da ihre Betriebssysteme von Microsoft verwaltet werden. Wenn sich in dem Abonnement, in dem AKS bereitgestellt wurde, keine weiteren VMs befinden, können Sie Microsoft Defender for Servers gefahrlos deaktivieren.

Wenn die Umgebung einschließlich der für Zielzonen auf Unternehmensebene empfohlenen Azure-Richtlinien bereitgestellt wurde, können Sie einen Ausschluss für die Richtlinienzuweisung in der Verwaltungsgruppe konfigurieren, die Microsoft Defender for Servers automatisch aktiviert, um unnötige Kosten zu vermeiden.

Anwendungssicherheit

Bei der Anwendungssicherheit geht es um:

  • Laufzeitschutz
  • Sicherheitsrisiken und Konformitätsverwaltung

Größte Risiken

Images sind Dateien, die alle Komponenten enthalten, die zum Ausführen einer Anwendung erforderlich sind. Wenn zum Erstellen der Images die neuesten Versionen dieser Komponenten verwendet werden, weisen sie zu Erstellungszeitpunkt möglicherweise keine bekannten Sicherheitsrisiken auf, dies kann sich jedoch schnell ändern.

Sie müssen diese Dateien immer mit den neuesten Versionen aktualisieren, da Paketentwickler*innen ständig neue Sicherheitsrisiken identifizieren. Erstellen Sie Containerupdates früher im Prozess, indem Sie die zum Erstellen der Container verwendeten Images aktualisieren. Dies unterscheidet sich von herkömmlichen Anwendungen, die in der Regel auf dem Host aktualisiert werden.

In das Image können auch schädliche Dateien eingebettet sein, die dann zum Angriff auf andere Container oder Komponenten des Systems verwendet werden können. Container von Drittanbietern können ebenfalls ein möglicher Angriffsvektor sein. Möglicherweise sind nicht alle Details bekannt, und die Container könnten Datenlecks verursachen. Es ist auch möglich, dass die Container nicht mit den erforderlichen Sicherheitsupdates aktualisiert wurden.

Ein weiterer Angriffsvektor ist das Einbetten von Geheimnissen wie Kennwörtern und Verbindungszeichenfolgen direkt in ein Imagedateisystem. Ein solches Vorgehen kann ein Sicherheitsrisiko verursachen, da jede Person, die Zugriff auf das Image hat, auch auf diese Geheimnisse zugreifen kann.

Es kann auch Fehler in den Anwendungen selbst geben, z. B. Anwendungen, die anfällig für websiteübergreifende Skripts oder SQL-Einschleusungen sind. Wenn Fehler vorhanden sind, kann die Sicherheitslücke ausgenutzt werden, um nicht autorisierten Zugriff auf vertrauliche Informationen in anderen Containern oder sogar auf dem Hostbetriebssystem zu ermöglichen.

Die AKS-Containerruntime erleichtert die Überwachung auf Sicherheitsrisiken mithilfe der verschiedenen Sicherheitstools, die in Azure verfügbar sind. Weitere Informationen finden Sie unter Einführung in Microsoft Defender for Kubernetes.

Sie sollten auch den ausgehenden Netzwerkdatenverkehr an Container kontrollieren, um sicherzustellen, dass Container keinen Datenverkehr über Netzwerke mit unterschiedlichen Vertraulichkeitsstufen (beispielsweise Umgebungen, die sichere Daten hosten) oder an das Internet senden können. Azure vereinfacht diese Steuerung mit seinen verschiedenen Netzwerk- und AKS-Sicherheitsfunktionen.

Standardmäßig konzentrieren sich Kubernetes-Planer darauf, die Staffelung zu erhöhen und die Dichte von Workloads zu maximieren, die auf Knoten ausgeführt werden. Container könnten Pods mit unterschiedlichen Vertraulichkeitsstufen auf ein und demselben Knoten platzieren, nur weil dieser Host über die meisten verfügbaren Ressourcen verfügt. Dieses Szenario kann zu Sicherheitsvorfällen führen, wenn Angreifer*innen den Zugriff auf öffentliche Workloads nutzen, um Container anzugreifen, die vertraulichere Prozesse auf demselben Host ausführen. Ein kompromittierter Container kann auch zur Überprüfung des Netzwerks verwendet werden, um andere Sicherheitsrisiken zu finden, die der Angreifer ausnutzen kann.

Gegenmaßnahmen

Speichern Sie Geheimnisse niemals in Anwendungscode oder Dateisystemen. Geheimnisse sollten in Schlüsselspeichern gespeichert und zur Laufzeit nach Bedarf für Container bereitgestellt werden. Mit AKS kann sichergestellt werden, dass nur Container, die Zugriff auf bestimmte Schlüssel benötigen, auch Zugriff darauf haben und dass diese Geheimnisse nicht auf dem Datenträger gespeichert werden. Beispielsweise kann Azure Key Vault diese Geheimnisse sicher speichern und bei Bedarf im AKS-Cluster bereitstellen. Es kann ganz einfach sichergestellt werden, dass diese Geheimnisse sowohl im Speicher als auch während der Übertragung verschlüsselt werden.

Vermeiden Sie die Verwendung nicht vertrauenswürdiger Images und Registrierungen, und stellen Sie sicher, dass nur Images aus vertrauenswürdigen Gruppen in ihren Clustern ausgeführt werden dürfen. Berücksichtigen Sie für einen mehrstufigen Ansatz Folgendes:

  • Regeln Sie zentral, welche Images und Registrierungen genau als vertrauenswürdig eingestuft werden.
  • Identifizieren Sie jedes Image einzeln anhand einer kryptografischen Signatur.
  • Etablieren Sie Richtlinien, die sicherstellen, dass alle Hosts nur Images ausführen, die aus der genehmigten Gruppe stammen.
  • Validieren Sie diese Signaturen vor der Ausführung.
  • Überwachen und aktualisieren Sie diese Images und Registrierungen, wenn sich Sicherheitsrisiken und Konfigurationsanforderungen ändern.

Es sollten sichere Computingprofile verwendet werden, um Container einzuschränken, und sie sollten zur Laufzeit zugeordnet werden. Es können benutzerdefinierte Profile erstellt und an Containerlaufzeiten übergeben werden, um ihre Funktionen weiter einzuschränken. Stellen Sie mindestens sicher, dass Container mit den Standardprofilen ausgeführt werden. Erwägen Sie die Verwendung benutzerdefinierter, Profile mit strikteren Einschränkungen für Container, in denen Anwendungen mit hohem Risiko ausgeführt werden.

Tools können mithilfe von Lernen durch Verhalten automatisch Profile für Anwendungen erstellen und Anomalien erkennen. Sie können Lösungen von Drittanbietern verwenden, um Anomalien zur Laufzeit zu erkennen. Anomalien können Ereignisse wie die folgenden umfassen:

  • Ungültige oder unerwartete Prozessausführung oder Systemaufrufe
  • Änderungen an geschützten Konfigurations- und Binärdateien
  • Schreibvorgänge mit unerwarteten Speicherorten und Dateitypen
  • Erstellen unerwarteter Netzwerklistener
  • An unerwartete Netzwerkziele gesendeter Datenverkehr
  • Speicherung und Ausführung von Schadsoftware

Microsoft Defender für Kubernetes investiert derzeit in diesen Bereich.

Bei der Ausführung von Containern sollten sich ihr Stammdateisystem im schreibgeschützten Modus befinden, um Schreibvorgänge in definierten Verzeichnissen zu isolieren, die von diesen Tools leicht überwacht werden können. Mit dieser Konfiguration sind Container widerstandsfähiger gegenüber Kompromittierungen, da Sie mögliche Manipulationen auf diese bestimmten Speicherorte einschränken können. Sie können problemlos vom Rest der Anwendung getrennt werden.

Überlegungen zum Entwurf

AKS bietet verschiedene Schnittstellen zu anderen Azure-Diensten wie Microsoft Entra ID, Azure Storage und Azure Virtual Network. Die Nutzung dieser Dienste erfordert in der Planungsphase besondere Aufmerksamkeit. AKS erhöht außerdem die Komplexität, sodass Sie in Betracht ziehen müssen, die gleichen Sicherheits-, Governance- und Konformitätsmechanismen und -kontrollen wie für die restliche Infrastrukturumgebung anzuwenden.

Hier sind einige weitere Anregungen für die AKS-Sicherheitsgovernance und -Compliance:

  • Wenn Sie AKS-Cluster in einem Abonnement erstellen, das gemäß den Best Practices für eine Zielzone auf Unternehmensebene bereitgestellt wurde, machen Sie sich mit den Azure-Richtlinien vertraut, die die Cluster erben. Weitere Informationen finden Sie unter Policies included in Azure landing zones reference implementations (Referenzimplementierungen für in Azure-Zielzonen integrierte Richtlinien).
  • Legen Sie fest, ob der Zugriff auf die Steuerungsebene des Clusters über das Internet (Standardeinstellung; empfohlen werden IP-Einschränkungen), nur innerhalb Ihres privaten Netzwerks in Azure oder lokal als privater Cluster möglich sein soll. Wenn Ihre Organisation Best Practices für Zielzonen auf Unternehmensebene befolgt, verfügt die Verwaltungsgruppe Corp über eine zugeordnete Azure Policy-Richtlinie, die die Festlegung von Clustern als „privat“ erzwingt. Weitere Informationen finden Sie unter Policies included in Azure landing zones reference implementations (Referenzimplementierungen für in Azure-Zielzonen integrierte Richtlinien).
  • Führen Sie mithilfe des integrierten Linux-Sicherheitsmoduls AppArmor eine Evaluierung durch, um die Aktionen für Container zu beschränken – zum Beispiel auf Lese-, Schreib-, Ausführungs- oder Systemfunktionen wie das Einbinden von Dateisystemen. Beispielsweise verfügen alle Abonnements über Azure-Richtlinien, die Pods in allen AKS-Clustern daran hindern, Container mit Berechtigungen zu erstellen. Weitere Informationen finden Sie unter Policies included in Azure landing zones reference implementations (Referenzimplementierungen für in Azure-Zielzonen integrierte Richtlinien).
  • Führen Sie mithilfe von seccomp (sicheres Computing) eine Evaluierung auf Prozessebene durch, um die Prozessaufrufe zu beschränken, die Container ausführen können. Beispielsweise verwendet die Azure Policy, die als Teil der generischen Implementierung von Zielzonen auf Unternehmensebene in der Zielzonen-Verwaltungsgruppe angewendet wird, um die Containerrechteausweitung auf den Stamm zu verhindern, seccomp über Azure-Richtlinien für Kubernetes.
  • Legen Sie fest, ob der Zugriff auf Ihre Containerregistrierung über das Internet oder nur innerhalb eines bestimmten virtuellen Netzwerks möglich sein soll. Das Deaktivieren des Internetzugriffs in einer Containerregistrierung kann negative Auswirkungen auf andere Systeme haben, die öffentliche Konnektivität für den Zugriff benötigen. Beispiele hierfür sind Continuous Integration-Pipelines oder Microsoft Defender for Image Scanning. Weitere Informationen finden Sie unter Herstellen einer privaten Verbindung mit einer Containerregistrierung über Azure Private Link.
  • Legen Sie fest, ob Ihre private Containerregistrierung von mehreren Zielzonen gemeinsam verwendet wird oder ob Sie für jedes Zielzonenabonnement eine dedizierte Containerregistrierung bereitstellen möchten.
  • Erwägen Sie zur Erkennung von Bedrohungen die Verwendung einer Sicherheitslösung wie Microsoft Defender für Kubernetes.
  • Ziehen Sie in Betracht, Ihre Containerimages auf Sicherheitsrisiken zu überprüfen.
  • Erwägen Sie die Deaktivierung von Microsoft Defender for Servers im AKS-Abonnement, wenn keine Nicht-AKS-VMs vorhanden sind, um unnötige Kosten zu vermeiden.

Entwurfsempfehlungen

Wichtig

Die Imageüberprüfung durch Microsoft Defender for Cloud ist nicht mit Container Registry-Endpunkten kompatibel. Weitere Informationen finden Sie unter Herstellen einer privaten Verbindung mit einer Containerregistrierung über Private Link.