Sichere Windows-Container

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016

Container können ihre reduzierte Imagegröße aufgrund der Tatsache bieten, dass der Host ihnen eingeschränkten Zugriff auf verschiedene Ressourcen gewährt. Wenn der Container weiß, dass der Host die Funktionalität bereitstellen kann, die zum Ausführen eines bestimmten Satzes von Aktionen erforderlich ist, muss der Container die entsprechende Software nicht in sein Basisimage einschließen. Das Ausmaß der gemeinsamen Ressourcennutzung kann jedoch erhebliche Auswirkungen auf die Leistung und Sicherheit des Containers haben. Wenn zu viele Ressourcen gemeinsam genutzt werden, könnte die Anwendung auch einfach als Prozess auf dem Host ausgeführt werden. Wenn zu wenige Ressourcen gemeinsam genutzt werden, lässt sich der Container nicht mehr von einem virtuellen Computer unterscheiden. Beide Konfigurationen lassen sich auf viele Szenarien anwenden, aber die meisten Benutzer, die Container verwenden, entscheiden sich in der Regel für einen Mittelweg.

Die Sicherheit eines Windows-Containers leitet sich aus dem Grad der gemeinsamen Verwendung ab, die mit seinem Host stattfindet. Die Sicherheitsgrenze eines Containers wird durch die Isolationsmechanismen bestimmt, die den Container vom Host trennen. Vor allem definieren diese Isolationsmechanismen, welche Prozesse im Container mit dem Host interagieren können. Wenn der Entwurf eines Containers die Interaktion mit dem Host durch einen Prozess mit erhöhten Rechten (Administrator) zulässt, betrachtet Microsoft diesen Container nicht als im Besitz einer stabilen Sicherheitsgrenze.

Windows Server-Container im Vergleich mit Linux-Containern

Prozessisolierte Windows Server-Container und Linux-Container haben ein ähnliches Maß an Isolation gemeinsam. Bei beiden Containertypen muss der Entwickler davon ausgehen, dass jeder Angriff, der über einen Prozess mit erhöhten Rechten auf dem Host ausgeführt werden kann, auch über einen Prozess mit erhöhten Rechten im Container ausgeführt werden kann. Beide arbeiten mithilfe der grundlegenden Funktionen, die von ihren jeweiligen Hostkerneln angeboten werden. Die Containerimages werden mit Binärdateien im Benutzermodus erstellt, die die vom Hostkernel bereitgestellten APIs verwenden. Der Hostkernel bietet für jeden Container, der im Benutzerbereich ausgeführt wird, die gleichen Funktionen für Ressourcenisolation und Verwaltung. Wenn die Sicherheit des Kernels beeinträchtigt ist, gilt dies auch für jeden Container, der diesen Kernel verwendet.

Die grundlegende Auslegung von Linux- und Windows-Servercontainern opfert Sicherheit zugunsten von Flexibilität. Windows Server- und Linux-Container bauen auf den grundlegenden Komponenten auf, die vom Betriebssystem bereitgestellt werden. Dies bietet die Flexibilität, Ressourcen und Namespaces zwischen Containern gemeinsam zu nutzen, erhöht jedoch die Komplexität, was die Tür zur Ausnutzung öffnet. Ganz allgemein gesagt betrachten wir den Kernel nicht als ausreichende Sicherheitsgrenze für gefährdete Workloads mit mehreren Mandanten.

Kernelisolation mit durch einen Hypervisor isolierten Containern

Durch einen Hypervisor isolierte Container bieten ein höheres Maß an Isolation als prozessisolierte Windows Server- oder Linux-Container und werden als robuste Sicherheitsgrenze angesehen. Durch einen Hypervisor isolierte Container bestehen aus einem Windows Server-Container, der von einer extrem schlanken VM umschlossen ist und zusammen mit dem Hostbetriebssystem über den Microsoft-Hypervisor ausgeführt wird. Der Hypervisor bietet Isolation auf Hardwareebene, die eine äußerst stabile Sicherheitsgrenze zwischen dem Host und anderen Containern umfasst. Selbst wenn ein Exploit aus dem Windows Server-Container heraus gelangen könnte, wäre er in der vom Hypervisor isolierten VM eingeschlossen.

Weder Windows Server-Container noch Linux-Container bieten etwas, was von Microsoft als robuste Sicherheitsgrenze angesehen wird, und sollten nicht in möglicherweise gefährdeten Szenarien mit mehreren Mandanten verwendet werden. Ein Container muss auf einen dedizierten virtuellen Computer beschränkt sein, um zu verhindern, dass ein nicht autorisierter Containerprozess mit dem Host oder anderen Mandanten interagiert. Die Isolation durch einen Hypervisor ermöglicht diesen Grad an Trennung und bietet gleichzeitig mehrere Leistungsvorteile gegenüber herkömmlichen VMs. Daher wird dringend empfohlen, in möglicherweise gefährdeten Szenarien mit mehreren Mandanten durch Hypervisoren isolierte Container als Container der Wahl zu verwenden.

Kriterien für die Sicherheitswartung von Containern

Microsoft ist bestrebt, alle Exploits und Fluchtmöglichkeiten zu patchen, die die festgelegte Isolationsgrenze eines beliebigen Windows-Containertyps durchbrechen. Allerdings werden nur Exploits, die eine Sicherheitsgrenze durchbrechen, gemäß dem MSRC-Prozess (Microsoft Security Response Center) behandelt. Nur durch einen Hypervisor isolierte Container bieten eine Sicherheitsgrenze, prozessisolierte Container jedoch nicht. Die einzige Möglichkeit, einen Programmfehler für das Durchbrechen eines prozessisolierten Containers zu erstellen, besteht, wenn ein nicht mit Administratorrechten ausgeführter Prozess Zugriff auf den Host erhalten kann. Wenn ein Exploit einen Administratorprozess zum Ausbruch aus dem Container verwendet, betrachtet Microsoft dies als nicht sicherheitsrelevanten Programmfehler und patcht ihn gemäß dem normalen Wartungsvorgang. Wenn ein Exploit einen Prozess ohne Administratorrechte verwendet, um eine Aktion auszuführen, die eine Sicherheitsgrenze durchbricht, untersucht Microsoft dies gemäß den festgelegten Kriterien für die Sicherheitswartung.

Wann ist eine mehrmandantenfähige Workload gefährdet?

Umgebungen mit mehreren Mandanten liegen vor, wenn mehrere Workloads in einer gemeinsam genutzten Infrastruktur und auf gemeinsam genutzten Ressourcen ausgeführt werden. Wenn eine oder mehrere Workloads, die in einer Infrastruktur ausgeführt werden, nicht vertrauenswürdig sind, gilt die mehrmandantenfähige Umgebung als gefährdet. Sowohl Windows Server- als auch Linux-Container nutzen den Hostkernel gemeinsam, sodass jeder Exploit, der für einen einzelnen Container ausgeführt wird, sich auf alle anderen Workloads auswirken kann, die in der gemeinsam genutzten Infrastruktur ausgeführt werden.

Sie können Maßnahmen ergreifen, um die Wahrscheinlichkeit zu verringern, dass ein Exploit auftritt, z. B. mithilfe von Podsicherheitsrichtlinien, AppArmor und RBAC (rollenbasierte Zugriffssteuerung), aber diese bieten keinen garantierten Schutz vor einem Angreifer. Es empfiehlt sich, in allen mehrmandantenfähigen Szenarien unsere bewährten Methoden für die Clusterisolation zu befolgen.

Verwendung der Benutzerkonten ContainerAdmin und ContainerUser

Windows Server-Container bieten zwei Standardbenutzerkonten, ContainerUser und ContainerAdministrator, die jeweils einem eigenen spezifischen Zweck dienen. Mit dem ContainerAdministrator-Konto können Sie den Container für administrative Zwecke verwenden: Installieren von Diensten und Software (z. B. Aktivieren von IIS innerhalb eines Containers), Vornehmen von Konfigurationsänderungen und Erstellen neuer Konten. Diese Aufgaben sind für eine Reihe von IT-Szenarien wichtig, wie sie beispielsweise in benutzerdefinierten, lokalen Bereitstellungsumgebungen ausgeführt werden.

Das ContainerUser-Konto ist für alle anderen Szenarien vorgesehen, für die keine Administratorberechtigungen in Windows erforderlich sind. Wenn der Benutzer in Kubernetes beispielsweise ContainerAdministrator ist und Hostvolumes in den Pod eingebunden werden dürfen, kann der Benutzer den SSH-Ordner einbinden und einen öffentlichen Schlüssel hinzufügen. Ein ContainerUser könnte dieses Beispiel nicht ausführen. Es handelt sich um ein eingeschränktes Benutzerkonto, das ausschließlich für Anwendungen konzipiert ist, die nicht mit dem Host interagieren müssen. Es wird dringend empfohlen, Ihre Anwendung bei der Bereitstellung eines Windows Server-Containers in einer Umgebung mit mehreren Mandanten unter dem ContainerUser-Konto auszuführen. In einer Umgebung mit mehreren Mandanten ist es immer am besten, das Prinzip der geringstmöglichen Berechtigungen zu befolgen, denn wenn ein Angreifer die Sicherheit Ihrer Workload beschädigt, ist so die Wahrscheinlichkeit geringer, dass die gemeinsam genutzte Ressource und die benachbarten Workloads ebenfalls beeinträchtigt werden. Das Ausführen von Containern mit dem ContainerUser-Konto verringert die Wahrscheinlichkeit stark, dass die Umgebung als Ganzes kompromittiert wird. Dies bietet jedoch immer noch keine stabile Sicherheitsgrenze. Wenn die Sicherheit hohe Priorität hat, sollten Sie daher durch Hypervisoren isolierte Container verwenden.

Um das Benutzerkonto zu ändern, können Sie die USER-Anweisung in Ihrer Dockerdatei verwenden:

USER ContainerUser

Alternativ können Sie einen neuen Benutzer erstellen:

RUN net user username ‘<password>’ /ADD
USER username

Windows-Dienste

Mit Microsoft Windows-Diensten, früher als NT-Dienste bekannt, wird das Erstellen von ausführbaren Anwendungen mit langer Laufzeit ermöglicht, die in eigenen Windows-Sitzungen ausgeführt werden. Diese Dienste können automatisch gestartet werden, wenn das Betriebssystem gestartet wird, oder angehalten und neu gestartet werden, und sie zeigen keine Benutzeroberfläche an. Dienste können auch im Sicherheitskontext eines bestimmten Benutzerkontos ausgeführt werden, bei dem es sich nicht um einen angemeldeten Benutzer oder das Standardcomputerkonto handelt.

Beim Containerisieren und Sichern einer Workload, die als Windows-Dienst ausgeführt wird, sind einige zusätzliche Dinge zu beachten. Erstens wird der ENTRYPOINT der Container nicht die Workload sein, da der Dienst als Hintergrundprozess ausgeführt wird. In der Regel handelt es sich bei ENTRYPOINT um ein Tool wie Dienstmonitor (oder Protokollmonitor). Zweitens wird das Sicherheitskonto, unter dem die Workload arbeitet, vom Dienst konfiguriert, nicht durch die USER-Anweisung in der Dockerfile. Sie können überprüfen, unter welchem Konto der Dienst ausgeführt wird, indem Sie Get-WmiObject win32_service -filter "name='<servicename>'" | Format-List StartName ausführen.

Wenn Sie z. B. eine IIS-Webanwendung mit dem ASP.NET (Microsoft-Artefaktregistrierung)-Image hosten, lautet der ENTRYPOINT des Containers "C:\\ServiceMonitor.exe", "w3svc". Dieses Tool kann verwendet werden, um den IIS-Dienst zu konfigurieren und dann den Dienst zu überwachen, um sicherzustellen, dass er ausgeführt und beendet wird, wodurch der Container gestoppt wird, wenn der Dienst aus irgendeinem Grund beendet wird. Standardmäßig wird der IIS-Dienst und damit die Webanwendung unter einem Konto mit geringen Berechtigungen im Container ausgeführt. Das Dienstüberwachungstool erfordert jedoch Administratorrechte zum Konfigurieren und Überwachen des Diensts.