Sicherheitsrisikoverwaltung für Azure Kubernetes Service (AKS)
Die Verwaltung von Sicherheitsrisiken umfasst das Erkennen, Bewerten, Mindern und Melden von Sicherheitsrisiken, die in den Systemen und der Software einer Organisation vorhanden sind. Die Verwaltung von Sicherheitsrisiken ist eine gemeinsame Verantwortung zwischen Ihnen und Microsoft.
In diesem Artikel wird beschrieben, wie Microsoft Sicherheitsrisiken und Sicherheits-Updates (auch als Patches bezeichnet) für Azure Kubernetes Service(AKS)-Cluster verwaltet.
Entdecken von Sicherheitsrisiken
Microsoft identifiziert und patcht Sicherheitsrisiken und fehlende Sicherheits-Updates für die folgenden Komponenten:
AKS-Container-Images
Worker-Knoten des Ubuntu-Betriebssystems 18.04 und 22.04: Canonical stellt Microsoft Betriebssystem-Builds zur Verfügung, für die alle verfügbaren Sicherheits-Updates angewendet werden.
Worker-Knoten des Windows Server 2022-Betriebssystems: Das Windows Server-Betriebssystem wird jeden zweiten Dienstag im Monat gepatcht. SLAs sollten dem jeweiligen Support-Vertrag und Schweregrad entsprechen.
Knoten des Azure Linux-Betriebssystems: Azure Linux bietet AKS mit Betriebssystem-Builds, für die alle verfügbaren Sicherheits-Updates angewendet werden.
AKS-Container-Images
Während die Cloud Native Computing Foundation (CNCF) den Großteil des in AKS ausgeführten Codes besitzt und verwaltet, übernimmt Microsoft die Verantwortung für die Erstellung der Open-Source-Pakete, die wir in AKS bereitstellen. Diese Verantwortung schließt den vollständigen Besitz des Build-, Scan-, Signierungs-, Validierungs- und Hotfix-Prozesses sowie die Kontrolle über die Binärdateien in Container-Images ein. Da wir für die Erstellung der Open-Source-Pakete verantwortlich sind, die in AKS bereitgestellt werden, können wir eine Software-Lieferkette über die Binärdatei einrichten und die Software nach Bedarf patchen.
Microsoft ist im breiteren Kubernetes-Ökosystem aktiv, um die Zukunft des cloudnativen Computing in der breiteren CNCF-Community mitzugestalten. Diese Arbeit gewährleistet nicht nur die Qualität jedes Kubernetes-Releases für die Welt, sondern ermöglicht es AKS auch, neue Kubernetes-Releases für mehrere Jahre schnell in die Produktion zu bringen. In einigen Fällen mehrere Monate im Voraus vor anderen Cloud-Anbietern. Microsoft arbeitet mit anderen Branchenpartnern in der Kubernetes-Sicherheitsorganisation zusammen. Beispielsweise empfängt, priorisiert und patcht das Security Response Committee (SRC) unter Embargo stehende Sicherheitsrisiken, bevor sie der Öffentlichkeit bekannt gegeben werden. Diese Verpflichtung stellt sicher, dass Kubernetes für alle sicher ist und es AKS ermöglicht, Sicherheitsrisiken schneller zu patchen und darauf zu reagieren, um unsere Kunden zu schützen. Zusätzlich zu Kubernetes hat sich Microsoft dazu verpflichtet, Vorabbenachrichtigungen über Software-Risiken für Produkte wie Envoy, Container Runtimes und viele andere Open-Source-Projekte zu erhalten.
Microsoft überprüft Container-Images mithilfe einer statischen Analyse, um Sicherheitsrisiken und fehlende Updates in Kubernetes und von Microsoft verwalteten Containern zu ermitteln. Wenn Korrekturen verfügbar sind, beginnt der Scanner automatisch mit dem Update- und Release-Prozess.
Zusätzlich zur automatisierten Überprüfung erkennt und aktualisiert Microsoft Sicherheitsrisiken, die für Scanner unbekannt sind, wie folgt:
Microsoft führt eigene Überwachungen, Penetrationstests und Erkennungen von Sicherheitsrisiken auf allen AKS-Plattformen durch. Spezialisierte Teams innerhalb von Microsoft und vertrauenswürdige Drittanbieter von Sicherheitsdienstleistungen führen ihre eigene Angriffsforschung durch.
Microsoft arbeitet aktiv mit der Community für Sicherheitsforschung über mehrere Programme zur Belohnung für Sicherheitsrisiken zusammen. Ein dediziertes Microsoft Azure Bounty-Programm bietet signifikante Belohnungen für das höchste Cloud-Sicherheitsrisiko, das jedes Jahr gefunden wird.
Microsoft arbeitet mit anderen Branchen- und Open-Source-Software-Partnern zusammen, die Sicherheitsrisiken, Sicherheitsforschung und Updates vor der öffentlichen Bekanntgabe des Sicherheitsrisikos teilen. Ziel dieser Zusammenarbeit ist es, große Teile der Internetinfrastruktur zu aktualisieren, bevor das Sicherheitsrisiko der Öffentlichkeit bekannt gegeben wird. In einigen Fällen trägt Microsoft gefundene Sicherheitsrisiken zu dieser Community bei.
Microsofts Zusammenarbeit im Bereich der Sicherheit erfolgt auf vielen Ebenen. Manchmal erfolgt dies formal über Programme, bei denen sich Organisationen registrieren, um Vorabbenachrichtigungen über Software-Risiken für Produkte wie Kubernetes und Docker zu erhalten. Die Zusammenarbeit erfolgt auch informell, da wir uns in vielen Open-Source-Projekten wie Linux-Kernel, Container Runtimes, Virtualisierungstechnologie und anderen engagieren.
Workerknoten
Linux-Knoten
Die nächtlichen kanonischen Betriebssystemsicherheitsupdates sind in AKS standardmäßig deaktiviert. Um sie explizit zu aktivieren, verwenden Sie bitte den unmanagedKanal.
Wenn Sie den unmanagedKanal verwenden, werden nächtliche kanonische Sicherheitsupdates auf das Betriebssystem auf dem Knoten angewendet. Das Knotenimage, das zum Erstellen von Knoten für Ihr Cluster verwendet wird, bleibt unverändert. Wenn Ihrem Cluster ein neuer Linux-Knoten hinzugefügt wird, wird das ursprüngliche Image zum Erstellen des Knotens verwendet. Dieser neue Knoten empfängt alle Sicherheits- und Kernel-Updates, die während der automatischen Überprüfung jede Nacht verfügbar sind, wird jedoch erst gepatcht, bis alle Überprüfungen und Neustarts abgeschlossen sind. Sie können das Knotenimageupgrade verwenden, um nach Knotenimages zu suchen und diese zu aktualisieren, die von Ihrem Cluster verwendet werden. Weitere Informationen zu Upgrades für Knotenimages finden Sie unter Upgrade für AKS-Knotenimages (Azure Kubernetes Service).
Für AKS-Cluster, die einen anderen Kanal als unmanaged verwenden, ist der unbeaufsichtigte Upgradeprozess deaktiviert.
Windows Server-Knoten
Für Windows Server-Knoten werden die neuesten Updates von Windows Update nicht automatisch ausgeführt und angewendet. Planen Sie Upgrades des Windows Server-Knoten-Pools in Ihrem AKS-Cluster passend zum regulären Windows Update-Release-Zyklus und Ihrem eigenen Update-Verwaltungsprozess. Während dieses Upgrades werden Knoten erstellt, die das neueste Windows Server-Image und die neuesten Windows Server-Patches ausführen und die älteren Knoten entfernen. Weitere Informationen zu diesem Prozess finden Sie unter Durchführen eines Upgrades für einen Knotenpool in AKS.
Klassifizieren von Sicherheitsrisiken
Microsoft investiert umfangreich in die Sicherheitshärtung des gesamten Stapels, einschließlich Betriebssystem, Container, Kubernetes und Netzwerkebenen. Außerdem werden gute Standardwerte festgelegt und sicherheitsgehärtete Konfigurationen und verwalteten Komponenten bereitgestellt. Zusammen tragen diese Anstrengungen dazu bei, die Auswirkungen und die Wahrscheinlichkeit von Sicherheitsrisiken zu verringern.
Das AKS-Team klassifiziert Sicherheitsrisiken entsprechend dem Kubernetes-Sicherheitsrisikobewertungssystem. Klassifizierungen berücksichtigen viele Faktoren, einschließlich AKS-Konfiguration und Sicherheitshärtung. Aufgrund dieses Ansatzes und der Investitionen, die AKS in die Sicherheit tätigt, können sich die Klassifizierungen des AKS-Sicherheitsrisikos von anderen Klassifizierungsquellen unterscheiden.
In der folgenden Tabelle werden Kategorien für den Schweregrad der Sicherheitsrisiken beschrieben:
| Schweregrad | Beschreibung |
|---|---|
| Kritisch | Ein Sicherheitsrisiko, das von einem nicht authentifizierten Remote-Angreifer in allen Clustern leicht ausgenutzt werden kann und zu einer vollständigen Systemkompromittierung führt. |
| High | Ein Sicherheitsrisiko, das für viele Cluster leicht ausgenutzt werden kann und zu einem Verlust der Vertraulichkeit, Integrität oder Verfügbarkeit führt. |
| Medium | Ein Sicherheitsrisiko, das für einige Cluster ausgenutzt werden kann, bei dem der Verlust von Vertraulichkeit, Integrität oder Verfügbarkeit durch die allgemeinen Konfigurationen, die Schwierigkeiten des Exploits selbst, den erforderlichen Zugriff oder die Benutzerinteraktion begrenzt wird. |
| Niedrig | Alle anderen Sicherheitsrisiken. Die Ausnutzung ist unwahrscheinlich oder die Folgen der Ausnutzung sind begrenzt. |
Aktualisieren von Sicherheitsrisiken
AKS patcht allgemeine Sicherheitslücken und Schwachstellen (Common Vulnerabilities and Exposures, CVEs), für die jede Woche eine Herstellerkorrektur stattfindet. CVEs ohne Korrektur warten auf die Herstellerkorrektur bevor sie behoben werden können. Die korrigierten Containerimages werden im nächsten entsprechenden VHD-Build (Virtual Hard Disk) zwischengespeichert, der auch die aktualisierten gepatchten CVEs für Ubuntu/Azure Linux/Windows enthält. Solange Sie die aktualisierte VHD ausführen, sollten Sie keine Container-Image-CVEs mit einem Hersteller-Fix ausführen, der über 30 Tage alt ist.
Für die betriebssystembasierten Sicherheitsrisiken in der VHD nutzt AKS standardmäßig auch VHD-Updates für Knotenimages, sodass Sicherheitsupdates mit wöchentlichen Knotenimagereleases bereitgestellt werden. Unbeaufsichtigte Upgrades sind deaktiviert, sofern Sie nicht zu nicht verwalteten Upgrades wechseln. Dies wird nicht empfohlen, da das Release global ist.
Zeitachse des Update-Releases
Das Ziel von Microsoft ist es, erkannte Sicherheitsrisiken innerhalb eines Zeitraums zu mindern, der den mit ihnen verbundenen Risiken angemessen ist. Die Microsoft Azure FedRAMP High Provisional Authorization to Operate (P-ATO) umfasst AKS im Überwachungsbereich und wurde autorisiert. FedRAMP Continuous Monitoring Strategy Guide und die FedRAMP Low, Moderate und High Security Control-Baselines erfordern die Behebung bekannter Sicherheitsrisiken innerhalb eines bestimmten Zeitraums entsprechend ihrem Schweregrad. Wie in FedRAMP RA-5d angegeben.
Bekanntmachen von Sicherheitsrisiken und Updates
In der Regel macht Microsoft die Veröffentlichung neuer Patch-Versionen für AKS nicht allgemein bekannt. Microsoft überwacht und überprüft allerdings fortwährend verfügbare CVE-Patches, um diese möglichst schnell in AKS zu unterstützen. Wenn ein kritischer Patch gefunden oder eine Benutzeraktion erforderlich ist, veröffentlicht und aktualisiert Microsoft CVE-Problemdetails auf GitHub.
Meldung von Sicherheitsproblemen
Sie können ein Sicherheitsproblem an das Microsoft Security Response Center (MSRC) melden, indem Sie einen Bericht zu Sicherheitsrisiken erstellen.
Wenn Sie lieber einen Bericht übermitteln möchten, ohne sich beim Tool anzumelden, senden Sie eine E-Mail an secure@microsoft.com. Verschlüsseln Sie Ihre Nachricht nach Möglichkeit mit unserem PGP-Schlüssel, indem Sie ihn von der „PGP-Schlüssel“-Seite des Microsoft Security Response Center herunterladen.
Sie sollten innerhalb von 24 Stunden eine Antwort erhalten. Sollten Sie dies aus irgendeinem Grund nicht durchführen, senden Sie uns eine E-Mail, um sicherzustellen, dass wir Ihre ursprüngliche Nachricht erhalten haben. Weitere Informationen finden Sie unter Microsoft Security Response Center.
Fügen Sie die folgenden angeforderten Informationen ein (soweit Sie angeben können), um uns zu helfen, die Art und den Umfang des möglichen Problems besser zu verstehen:
- Art des Problems (z. B. Pufferüberlauf, Einschleusung von SQL-Befehlen, Cross-Site-Scripting usw.)
- Vollständige Pfade der Quelldateien im Zusammenhang mit der Manifestation des Problems
- Der Speicherort des betroffenen Quellcodes (Tag/Verzweigung/Commit oder direkte URL)
- Jegliche spezielle Konfiguration, die zum Reproduzieren des Problems erforderlich ist
- Schritt-für-Schritt-Anweisungen zum Reproduzieren des Problems
- Proof of Concept oder Exploit-Code
- Auswirkungen des Problems, einschließlich einer Beschreibung, wie ein Angreifer möglicherweise das Sicherheitsrisiko ausnutzt.
Diese Informationen helfen uns, Ihr gemeldetes Sicherheitsproblem schneller zu selektieren.
Wenn Sie einen Fehler aufgrund einer Belohnung melden, können umfassendere Berichte zu einer höheren Belohnung beitragen. Weitere Informationen zu unseren aktiven Programmen finden Sie unter Microsoft Bug Bounty Program.
Richtlinie
Microsoft folgt dem Prinzip der Koordinierten Offenlegung von Sicherheitsrisiken.
Nächste Schritte
Weitere Informationen finden Sie in der Übersicht zum Durchführen eines Upgrades für Azure Kubernetes Service-Cluster und -Knoten-Pools.