Architektur eines regulierten AKS-Clusters für PCI-DSS 3.2.1 (Teil 2 von 9)

In diesem Artikel wird eine Referenzarchitektur für einen AKS-Cluster (Azure Kubernetes Service) beschrieben, in dem eine mit Payment Card Industry Data Security Standard (PCI-DSS 3.2.1) konforme Workload ausgeführt wird. Bei dieser Architektur geht es in erster Linie um die Infrastruktur und nicht um die PCI-DSS 3.2.1-Workload.

Dieser Artikel ist Teil einer Serie. Die Einführung finden Sie hier.

Die Empfehlungen und Beispiele stammen aus der folgenden zugehörigen Referenzimplementierung:

Unter GitHub: AKS-Baselinecluster (Azure Kubernetes Service) für regulierte Workloads wird die regulierte Infrastruktur veranschaulicht. Diese Implementierung bietet eine Microserviceanwendung. Sie ist enthalten, damit Sie sich mit der Infrastruktur vertraut machen können, und dient zur Veranschaulichung der Netzwerk- und Sicherheitskontrollen. Die Anwendung stellt keine echte PCI-DSS-Workload dar und implementiert auch keine solche.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Diese Netzwerkarchitektur basiert auf einer Hub-Spoke-Topologie. Das virtuelle Hubnetzwerk umfasst die Firewall zum Steuern des ausgehenden Datenverkehrs, Gatewaydatenverkehr aus lokalen Netzwerken sowie ein drittes Netzwerk für den SRE-Clusterzugriff (Site Reliability Engineer, Sitezuverlässigkeits-Entwickler). Es gibt zwei virtuelle Spoke-Netzwerke. Ein Spoke enthält den AKS-Cluster, bei dem es sich um eine Komponente der Datenumgebung des Karteninhabers (Cardholder Data Environment, CDE) handelt, und fungiert als Host für die PCI-DSS-Workload. Der andere Spoke dient zum Erstellen von VM-Images für den kontrollierten SRE-Zugriff auf die Umgebung.

Komponenten

Hier sind die Hauptkomponenten dieser Architektur angegeben. Sollten Sie mit diesen Diensten nicht vertraut sein, finden Sie unter Verwandte Azure-Dienste Links zur jeweiligen Produktdokumentation.

Azure Firewall

Die Firewallinstanz schützt den ausgehenden Netzwerkdatenverkehr. Ohne diese Sicherheitsebene kann der Datenfluss mit einem böswilligen Drittanbieterdienst kommunizieren, der vertrauliche Unternehmensdaten herausfiltern könnte.

Azure Bastion

Von der Baselinearchitektur wurde zwar ein Subnetz für Azure Bastion, aber nicht die Ressource an sich bereitgestellt. Diese Architektur fügt Azure Bastion im Subnetz hinzu und bietet sicheren Zugriff auf eine Jumpbox.

Azure Image Builder

In einem gesonderten virtuellen Netzwerk bereitgestellt, erstellt es VM-Images mit grundlegender Sicherheit und Konfiguration. In dieser Architektur ist die Komponente so angepasst, dass sichere Knotenimages mit vorinstallierten Verwaltungstools wie Azure CLI, kubectl und Flux CLI erstellt werden.

Azure Virtual Machine Scale Sets für Jumpbox-Instanzen

Das Spoke-Netzwerk verfügt über zusätzliche Computeressourcen für eine Jumpbox. Diese Skalierungsgruppe ist als gesteuerter Zugriffspunkt zum bedarfsgerechten Ausführen von Tools für den AKS-Cluster (beispielsweise kubectl) vorgesehen.

Azure Application Gateway mit integrierter Web Application Firewall (WAF)

Von Azure Application Gateway wird ein Layer 7-Lastenausgleich durchgeführt. WAF schützt eingehenden Datenverkehr vor gängigen Angriffen auf Webdatenverkehr. Die Instanz verfügt über eine öffentliche IP-Konfiguration am Front-End, das die Benutzeranforderungen empfängt.

Azure Kubernetes Service (AKS)

Die Hostinginfrastruktur, die ein wichtiger Bestandteil der Datenumgebung des Karteninhabers (Cardholder Data Environment, CDE) ist. Der AKS-Cluster wird als privater Cluster bereitgestellt. Der Kubernetes-API-Server ist daher nicht über das öffentliche Internet verfügbar, und für den API-Server bestimmter Datenverkehr ist auf Ihr privates Netzwerk beschränkt.

ACR-Aufgaben

Ermöglicht automatisiertes Erstellen und Verwalten von Containerimages.

Azure Key Vault

Speichert und verwaltet für Clustervorgänge erforderliche Geheimnisse (beispielsweise Zertifikate und Verschlüsselungsschlüssel).

Clusterkonfiguration

Im Anschluss finden Sie einige wichtige Unterschiede zur Baselinearchitektur:

Knotenpoolsegmentierung

In dieser Architektur verfügt der Cluster über zwei Benutzerknotenpools und einen Systemknotenpool. Die Computeauswahl für die Knotenpools bleibt gleich wie in der Baselinearchitektur. Anders als in der Baselinearchitektur befindet sich jeder Knotenpool in einem dedizierten Subnetz, um eine zusätzliche Netzwerkisolationsgrenze zwischen Computeebenen zu bieten.

Für PCI-DSS 3.2.1 müssen die Vorgänge und die Konnektivität der PCI-Workload von anderen Workloads isoliert sein.

• Innerhalb des Geltungsbereichs: Die PCI-Workload, die Umgebung, in der sie sich befindet, sowie Vorgänge.

• Außerhalb des Geltungsbereichs: Andere Workloads, die möglicherweise Dienste gemeinsam nutzen, aber von den Komponenten innerhalb des gültigen Bereichs isoliert sind.

Die zentrale Strategie besteht darin, für die nötige Trennung zu sorgen. Hierzu empfiehlt es sich, die Komponenten, die sich innerhalb des Geltungsbereichs befinden, und die Komponenten, die sich außerhalb des Geltungsbereichs befinden, jeweils in separaten Clustern bereitzustellen. Der Nachteil der Verwendung mehrerer Cluster sind die höheren Kosten für die zusätzliche Infrastruktur und der Wartungsaufwand. In dieser Implementierung werden der Einfachheit halber alle Komponenten in einem gemeinsam genutzten Cluster platziert. Das Modell mit nur einem Cluster erfordert eine Strategie für eine strenge clusterinterne Segmentierung. Unabhängig davon, wie Sie die Trennung implementieren, sollten Sie beachten, dass sich Komponenten, die sich außerhalb des Geltungsbereichs befinden, im Zuge der Weiterentwicklung Ihrer App zu Komponenten entwickeln können, die sich innerhalb des Geltungsbereichs befinden.

In der Referenzimplementierung demonstrieren wir die Vorgehensweise bei Verwendung eines gemeinsam genutzten Clusters und stellen dazu eine Microserviceanwendung in einem einzelnen Cluster bereit. Die Workloads innerhalb des Geltungsbereichs und die Workloads außerhalb des Geltungsbereichs sind in zwei separaten Benutzerknotenpools segmentiert. Die Anwendung verfügt über zwei Gruppen von Diensten: Eine Gruppe verfügt über Pods innerhalb des Geltungsbereichs, die andere befindet sich außerhalb des Geltungsbereichs. Beide Gruppen sind auf zwei Benutzerknotenpools verteilt. Durch die Verwendung von Kubernetes-Taints werden Pods innerhalb des Geltungsbereichs und Pods außerhalb des Geltungsbereichs auf separaten Knoten bereitgestellt und nutzen niemals denselben virtuellen Computer oder denselben IP-Adressraum des Netzwerks.

Eingangscontroller

In der Baselinearchitektur wurde Traefik für die Eingangsdatensteuerung verwendet. In dieser Referenzarchitektur verwenden wir stattdessen Nginx. Diese Änderung zeigt, dass diese Komponente geändert werden kann, um die Anforderungen Ihrer Workloads zu erfüllen.

Privater Kubernetes-API-Server

In der Baselinearchitektur wurde der AKS-Cluster im öffentlichen Modus bereitgestellt. Das bedeutet, dass die gesamte Kommunikation mit dem von AKS verwalteten Kubernetes-API-Server über das öffentliche Internet abgewickelt wird. Dies ist in dieser Architektur nicht zulässig, da Systemkomponenten bei PCI-DSS 3.2.1 nicht öffentlich verfügbar sein dürfen. In dieser regulierten Architektur wird der Cluster als privater Cluster bereitgestellt. Der für den Kubernetes-API-Server bestimmte Netzwerkdatenverkehr wird auf Ihr privates Netzwerk beschränkt. Der API-Server wird über einen privaten Endpunkt im Netzwerk des Clusters verfügbar gemacht. Durch die Verwendung von Netzwerksicherheitsgruppen und anderen integrierten Features wird die Sicherheit noch weiter verbessert. Die Features werden unter Netzwerkkonfiguration beschrieben.

Podsicherheit

Verwenden Sie zur Beschreibung der Sicherheitsanforderungen Ihrer Workload relevante Einstellungen vom Typ securityContext für Ihre Container. Dies schließt Grundeinstellungen wie fsGroup, runAsUser / runAsGroup und das Festlegen von allowPrivilegeEscalation auf „false“ ein (sofern nicht erforderlich). Machen Sie sich mit dem Definieren und Entfernen von Linux-Funktionen und dem Definieren Ihrer SELinux-Optionen in seLinuxOptions vertraut.

Verweisen Sie in Ihren Bereitstellungsmanifesten nach Möglichkeit nicht anhand von Tags auf Images. Verwenden Sie stattdessen die tatsächliche Image-ID. Dadurch lassen sich Containerüberprüfungsergebnisse zuverlässig dem tatsächlichen Inhalt zuordnen, der in Ihrem Cluster ausgeführt wird. Über Azure Policy können Sie erzwingen, dass der Imagename das Image-ID-Muster im zulässigen regulären Ausdruck enthält. Diese Anleitung gilt auch bei Verwendung der Dockerfile-Anweisung FROM.

Netzwerkkonfiguration

Die Hub-Spokes werden alle in separaten virtuellen Netzwerken mit jeweils eigenem privatem Adressraum bereitgestellt. Standardmäßig ist zwischen zwei virtuellen Netzwerken kein Datenverkehr zulässig. Zur Implementierung der Segmentierung werden innerhalb des Netzwerks Subnetze erstellt.

Eine Kombination aus verschiedenen Azure-Diensten und -Features und nativen Kubernetes-Konstrukten sorgt für die nötige Kontrolle. Hier finden Sie einige der Optionen, die in dieser Architektur verwendet werden:

Subnetzsicherheit über Netzwerksicherheitsgruppen (NSGs)

Es gibt mehrere NSGs zur Steuerung des ein- und ausgehenden Clusterdatenverkehrs. Hier sind einige Beispiele:

• Die Clusterknotenpools werden in dedizierten Subnetzen platziert. Für jedes Subnetz sind NSGs vorhanden, die jeglichen SSH-Zugriff auf virtuelle Knotencomputer blockieren und Datenverkehr aus dem virtuellen Netzwerk zulassen. Datenverkehr aus den Knotenpools wird auf das virtuelle Netzwerk beschränkt.

• Der gesamte eingehende Datenverkehr aus dem Internet wird von Azure Application Gateway abgefangen. Durch NSG-Regeln wird beispielsweise Folgendes sichergestellt:

  • Nur eingehender HTTPS-Datenverkehr wird zugelassen.
  • Datenverkehr aus der Azure-Steuerungsebene ist mithilfe von Diensttags zulässig. Weitere Informationen finden Sie unter Erlauben des Zugriffs auf einige Quell-IP-Adressen.

• In den Subnetzen mit Azure Container Registry Agent wird durch NSGs nur der erforderliche ausgehende Datenverkehr zugelassen. Beispielsweise wird Datenverkehr für Azure Key Vault, Microsoft Entra ID, Azure Monitor und andere Dienste zugelassen, mit denen die Containerregistrierung kommunizieren muss.

• Das Subnetz mit der Jumpbox ist für Verwaltungsvorgänge vorgesehen. Die NSG-Regel im Subnetz der Jumpbox lässt nur SSH-Zugriff von Azure Bastion im Hub sowie eingeschränkte ausgehende Verbindungen zu. Jumpboxes verfügen nicht über universellen Internetzugriff und werden sowohl durch die Subnetz-NSG als auch durch Azure Firewall gesteuert.

Wenn nach und nach Workloads, Systemsicherheits-Agents und andere Komponenten bereitgestellt werden, können Sie weitere NSG-Regeln hinzufügen, um die Art des zulässigen Datenverkehrs zu definieren. Der Datenverkehr muss innerhalb dieser Subnetzgrenzen bleiben. Jeder Knotenpool befindet sich in seinem eigenen Subnetz. Beobachten Sie daher die Datenverkehrsmuster, und wenden Sie dann spezifischere Regeln an.

Sicherheit zwischen Pods mit Netzwerkrichtlinien

Bei dieser Architektur wird versucht, die Zero Trust-Prinzipien von Microsoft möglichst umfassend zu implementieren.

Beispiele für das Konzept von Zero Trust-Netzwerken werden in der Implementierung innerhalb der benutzerseitig bereitgestellten Namespaces a0005-i und a0005-o veranschaulicht. Auf jeden Workload-Namespace muss eine restriktive Netzwerkrichtlinie angewendet werden. Die Richtliniendefinitionen hängen von den Pods ab, die in diesen Namespaces ausgeführt werden. Berücksichtigen Sie Bereitschaft, Aktualität und Starttests, und lassen Sie Metriken zu, die vom Log Analytics-Agent gesammelt werden. Standardisieren Sie ggf. die Ports für Ihre Workloads, um eine konsistente Netzwerkrichtlinie und Azure Policy-Instanz für zulässige Containerports bereitstellen zu können.

In bestimmten Fällen ist dies für die Kommunikation innerhalb des Clusters nicht möglich. Ein Zero Trust-Netzwerk kann nicht von allen benutzerseitig bereitgestellten Namespaces verwendet werden. (Dies gilt beispielsweise für cluster-baseline-settings.)

TLS-Verschlüsselung

Die Baselinearchitektur bietet TLS-verschlüsselten Datenverkehr bis zum Eingangsdatencontroller im Cluster, die Kommunikation zwischen Pods ist jedoch unverschlüsselt. In dieser Architektur wird TLS auf Datenverkehr zwischen Pods ausgedehnt – einschließlich Überprüfung der Zertifizierungsstelle (Certificate Authority, CA). TLS wird durch ein Dienst-Mesh bereitgestellt, das mTLS-Verbindungen und die Überprüfung erzwingt, bevor die Kommunikation zugelassen wird.

In der Implementierung wird mTLS verwendet. mTLS-Unterstützung kann mit oder ohne Dienst-Mesh implementiert werden. Achten Sie bei Verwendung eines Meshs darauf, dass es mit dem Zertifikataussteller Ihrer Wahl kompatibel ist. In dieser Implementierung wird Open Service Mesh verwendet.

Vom Eingangsdatencontroller in dieser Implementierung wird ein Platzhalterzertifikat verwendet, um Standarddatenverkehr zu verarbeiten, wenn eine Eingangsressource kein bestimmtes Zertifikat enthält. Dies ist möglicherweise akzeptabel. Sollte Ihre Organisationsrichtlinie jedoch keine Platzhalterzertifikate zulassen, müssen Sie Ihren Eingangsdatencontroller ggf. so anpassen, dass kein Platzhalterzertifikat verwendet wird.

Azure Key Vault-Netzwerkeinschränkungen

Alle Geheimnisse, Schlüssel und Zertifikate werden in Azure Key Vault gespeichert. Key Vault übernimmt Aufgaben der Zertifikatverwaltung wie etwa die Rotation. Die Kommunikation mit Key Vault erfolgt über Azure Private Link. Der Key Vault zugeordnete DNS-Eintrag befindet sich in einer privaten DNS-Zone, sodass er nicht über das Internet aufgelöst werden kann. Dies erhöht zwar die Sicherheit, hat aber auch einige Einschränkungen zur Folge.

Das Beziehen von TLS-Zertifikaten für den HTTP-Listener aus Key Vault-Instanzen, die mit Private Link verfügbar gemacht werden, wird von Azure Application Gateway nicht unterstützt. Daher wird Key Vault hier in einem Hybridmodell bereitgestellt. Für Verbindungen mit entsprechender Unterstützung wird zwar weiterhin Private Link verwendet, es wird jedoch auch öffentlicher Zugriff für die Application Gateway-Integration zugelassen. Sollte dieser Hybridansatz für Ihre Bereitstellung nicht geeignet sein, verlagern Sie den Zertifikatverwaltungsprozess in Application Gateway. Dies führt zwar zu zusätzlichem Verwaltungsaufwand, die Key Vault-Instanz ist dann allerdings vollständig isoliert. Weitere Informationen finden Sie unter:

• Funktionsweise der Integration
• Erstellen eines Anwendungsgateways mit TLS-Terminierung mithilfe der Azure CLI

DDoS-Schutz

Wenn Sie über virtuelle Netzwerke mit öffentlichen IP-Adressen verfügen, aktivieren Sie Azure DDoS-Netzwerkschutz. In dieser Referenzarchitektur ist dem Subnetz mit dem Application Gateway eine öffentliche IP-Adresse zugeordnet, sodass es für DDoS Protection infrage kommt.

Azure DDoS-Netzwerkschutz schützt die Infrastruktur und die Workload vor betrügerischen Massenanforderungen. Solche Anforderungen können zu Dienstunterbrechungen führen oder einen anderen, parallel stattfindenden Angriff verschleiern. Azure DDoS-Netzwerkschutz ist mit erheblichen Kosten verbunden und wird in der Regel für viele Workloads amortisiert, die zahlreiche IP-Adressen umfassen. Arbeiten Sie mit Ihrem Netzwerkteam zusammen, um die Abdeckung für Ihre Workloads zu koordinieren.

Identitäts- und Zugriffsverwaltung

Definieren Sie Rollen, und legen Sie geeignete Zugriffssteuerung gemäß den Anforderungen der jeweiligen Rolle fest. Verknüpfen Sie Rollen mit Kubernetes-Aktionen, und verwenden Sie dabei einen möglichst engen Geltungsbereich. Vermeiden Sie Rollen, die mehrere Funktionen umfassen. Wenn eine Person mehrere Rollen innehat, weisen Sie ihr alle Rollen zu, die für die entsprechenden Aufgaben relevant sind. Ist eine Person also direkt für den Cluster und den Workload zuständig, erstellen Sie Ihre Kubernetes-Clusterrollen (ClusterRole) so, als würde es sich um verschiedene Personen handeln. Weisen Sie der einzelnen Person anschließend alle relevanten Rollen zu.

Minimieren Sie ständigen Zugriff – insbesondere bei Konten mit hohen Auswirkungen (beispielsweise SRE/Ops-Interaktionen mit Ihrem Cluster). Die AKS-Steuerungsebene unterstützt sowohl Microsoft Entra ID Privileged Access Management (PAM) Just-in-Time (JIT) als auch bedingte Zugriffsrichtlinien, die eine zusätzliche Ebene der erforderlichen Authentifizierungsüberprüfung für privilegierten Zugriff auf Grundlage der von Ihnen erstellten Regeln bereitstellen.

Weitere Informationen zur Verwendung von PowerShell zum Konfigurieren des bedingten Zugriffs finden Sie unter New-MgIdentityConditionalAccessPolicy, Get-MgIdentityConditionalAccessPolicy und Remove-MgIdentityConditionalAccessPolicy.

Datenträgerverschlüsselung

Berücksichtigen Sie beim Entwerfen der Verschlüsselung für ruhende Daten Speicherdatenträger, virtuelle Computer für AKS-Agent-Knoten, andere virtuelle Computer sowie temporäre Datenträger und Betriebssystemdatenträger.

Speicherdatenträger

Standardmäßig werden Azure Storage-Datenträger im Ruhezustand mit von Microsoft verwalteten Schlüsseln verschlüsselt. Wenn Sie nicht kurzlebige Betriebssystemdatenträger verwenden oder herkömmliche Datenträger hinzufügen, empfiehlt es sich, kundenseitig verwaltete Schlüssel zur Steuerung der Verschlüsselungsschlüssel zu verwenden. Verschlüsseln Sie außerhalb der Speicherebene, und schreiben Sie nur verschlüsselte Daten auf das Speichermedium. Achten Sie außerdem darauf, dass sich die Schlüssel nie in direkter Nachbarschaft zur Speicherebene befinden. Weitere Informationen finden Sie unter Bring Your Own Key (BYOK) mit Azure-Datenträgern.

BYOK kann ggf. auch für alle anderen Datenträger verwendet werden, die mit dem Cluster interagieren – etwa Ihre Jumpboxes hinter Azure Bastion. Wenn Sie sich für BYOK entscheiden, sind die SKU-Optionen für virtuelle Computer und regionale Verfügbarkeit eingeschränkt, da dieses Feature nicht für alle SKUs oder Regionen unterstützt wird.

VM-Hosts

Es empfiehlt sich, die Verschlüsselung auf dem Host zu aktivieren. Dadurch werden der VM-Host und alle temporären Betriebssystemdatenträger (oder auf einem VM-Host zwischengespeicherte Datenträger) verschlüsselt. Weitere Informationen finden Sie unter Verschlüsselung auf dem Host: End-to-End-Verschlüsselung für Ihre VM-Daten.

Mithilfe der hostbasierten Verschlüsselung wird dieses Feature auf die Daten ausgeweitet, die auf dem VM-Host Ihrer AKS-Agent-Knoten gespeichert sind. Ähnlich wie bei BYOK kann dieses Feature dazu führen, dass nicht alle VM-SKUs und Regionen zur Auswahl stehen.

Diese Features können über Azure Policy erzwungen werden.

Clustersicherungen (Zustand und Ressourcen)

Wenn Ihre Workload clusterinternen Speicher erfordert, benötigen Sie einen stabilen und sicheren Prozess für die Sicherung und Wiederherstellung. Für die Sicherung und Wiederherstellung von PersistentVolumeClaim können Dienste wie Azure Backup (für Azure-Datenträger und Azure Files) verwendet werden. Es ist von Vorteil, wenn das Sicherungssystem native Kubernetes-Ressourcen unterstützt. Sie können Ihre primäre Methode, durch die der Cluster mit einem bekannten Zustand abgeglichen wird, mit dem Sicherungssystem für kritische Systemwiederherstellungstechniken ergänzen. Dies kann beispielsweise bei der Drifterkennung sowie bei der Katalogisierung von Systemzustandsänderungen auf Kubernetes-Ressourcenebene hilfreich sein.

Bei Sicherungsprozessen müssen die Daten in der Sicherung danach klassifiziert werden, ob sie aus dem Cluster stammen oder clusterextern sind. Wenn sich die Daten im Geltungsbereich von PCI-DSS 3.2.1 befinden, erweitern Sie Ihre Konformitätsgrenzen, um den Lebenszyklus und das außerhalb des Clusters befindliche Ziel der Sicherung einzuschließen. Sicherungen können einen Angriffsvektor darstellen. Berücksichtigen Sie beim Entwerfen Ihrer Sicherung geografische Einschränkungen, die Verschlüsselung ruhender Daten, Zugriffssteuerungen, Rollen und Zuständigkeiten, Überwachung, Gültigkeitsdauer und Manipulationsschutz.

Von clusterinternen Sicherungssystemen wird erwartet, dass sie mit hohen Berechtigungen betrieben werden. Bewerten Sie das Risiko und den Nutzen der Verwendung eines Sicherungs-Agents in Ihrem Cluster. Überschneidet sich die Agent-Funktion mit einer anderen Verwaltungslösung im Cluster? Welche Tools sind mindestens erforderlich, um diese Aufgabe zu bewältigen, ohne die Angriffsfläche zu vergrößern?

Azure Policy-Aspekte

In der Regel verfügen die angewendeten Azure-Richtlinien über keine Einstellungen zur Workloadoptimierung. In der Implementierung kommt die Initiative Eingeschränkte Sicherheitsstandards für Kubernetes-Clusterpods bei Linux-basierten Workloads zum Einsatz, eine der integrierten Richtlinieninitiativen. Diese Initiative lässt keine Optimierung der Einstellungen zu. Es empfiehlt sich unter Umständen, diese Initiative zu exportieren und die Werte für Ihre spezifische Workload anzupassen. Sie können alle Gatekeeper-bezogenen Azure-Richtlinien vom Typ deny in einer benutzerdefinierten Initiative und alle Azure-Richtlinien vom Typ audit in einer anderen Initiative zusammenfassen. Dadurch werden Blockaktionen und reine Informationsrichtlinien voneinander getrennt.

Schließen Sie die Namespaces kube-system und gatekeeper-system ggf. in Ihre Richtlinien vom Typ audit ein, um die Transparenz zu verbessern. Wenn Sie diese Namespaces in Richtlinien vom Typ deny einschließen, tritt unter Umständen ein Clusterfehler aufgrund einer nicht unterstützten Konfiguration auf.

Die Datenverschlüsselung kann durch Festlegen einiger Azure Policy-Warnungen erzwungen werden. So können Sie beispielsweise BYOK mit einer Warnung erzwingen, durch die Cluster erkannt werden, die in der Clusterressource nicht über diskEncryptionSetID verfügen. Eine andere Richtlinie kann verwendet werden, um zu erkennen, ob die hostbasierte Verschlüsselung für agentPoolProfiles aktiviert ist. In der Referenzimplementierung werden keine Datenträger im Cluster verwendet, und der Betriebssystemdatenträger ist kurzlebig. Beide Beispielrichtlinien sind als Erinnerung an das Sicherheitsfeature gedacht. Die Richtlinien sind nicht auf block, sondern auf audit festgelegt.

Verwalten von Images

Verwenden Sie für Ihre Workloads Basisimages ohne Distribution. Diese Images tragen zur Minimierung der Angriffsfläche bei, da ergänzende Images wie Shells und Paket-Manager entfernt werden. Einer der Vorteile ist eine geringere CVE-Trefferquote.

Azure Container Registry unterstützt Images, die der Spezifikation für das Imageformat der Open Container Initiative (OCI) entsprechen. In Verbindung mit einem Zugangscontroller, der die Validierung von Signaturen unterstützt, kann so sichergestellt werden, dass Sie nur Images ausführen, die Sie mit Ihren privaten Schlüsseln signiert haben. Es gibt Open-Source-Lösungen wie SSE Connaisseur oder IBM Portieris, die diese Prozesse integrieren.

Schützen Sie Containerimages und andere OCI-Artefakte, da sie das geistige Eigentum der Organisation enthalten. Verwenden Sie kundenseitig verwaltete Schlüssel, und verschlüsseln Sie den Inhalt Ihrer Registrierungen. Standardmäßig werden die Daten im Ruhezustand mit dienstseitig verwalteten Schlüsseln verschlüsselt. Kundenseitig verwaltete Schlüssel sind jedoch manchmal zur Einhaltung gesetzlicher Bestimmungen erforderlich. Speichern Sie den Schlüssel in einem verwalteten Schlüsselspeicher wie Azure Key Vault. Da Sie den Schlüssel selbst erstellen und besitzen, sind Sie für Vorgänge im Zusammenhang mit dem Schlüssellebenszyklus verantwortlich – einschließlich Rotation und Verwaltung. Weitere Informationen finden Sie unter Verschlüsseln der Registrierung mithilfe eines kundenseitig verwalteten Schlüssels.

Operativer Zugriff auf den Kubernetes-API-Server

Sie können für den Cluster ausgeführte Befehle einschränken. Dazu müssen Sie nicht unbedingt einen Jumpbox-basierten Betriebsprozess erstellen. Wenn Sie über eine IT-Automatisierungsplattform mit IAM-Gate verfügen, können Sie die vordefinierten Aktionen verwenden, um die Art der Aktionen zu steuern und zu überwachen.

Build-Agents

Pipeline-Agents müssen sich außerhalb des Geltungsbereichs für den regulierten Cluster befinden, da Buildprozesse Bedrohungsvektoren darstellen können. Buildprozesse beispielsweise funktionieren häufig mit nicht getesteten und nicht vertrauenswürdigen Komponenten.

Kubernetes wird zwar häufig als Infrastruktur für elastische Build-Agents verwendet, dieser Prozess darf jedoch nicht innerhalb der Runtimegrenzen der regulierten Workload ausgeführt werden. Ihre Build-Agents dürfen keinen direkten Zugriff auf den Cluster haben. Gewähren Sie Build-Agents beispielsweise nur Netzwerkzugriff auf Azure Container Registry, um Containerimages, Helm-Charts und Ähnliches zu pushen. Verwenden Sie dann GitOps für die Bereitstellung. Build- und Releaseworkflows sollten generell keinen direkten Zugriff auf Ihre Kubernetes-Cluster-API (oder auf die zugehörigen Knoten) haben.

Überwachen von Vorgängen

Clusterinterne Aktivitäten

Bei den clusterinternen Pods vom Typ omsagent, die in kube-system ausgeführt werden, handelt es sich um den Sammlungs-Agent von Log Analytics. Sie erfassen Telemetriedaten, lesen Protokolle vom Typ stdout und stderr für Container aus und sammeln Prometheus-Metriken. Sie können die Sammlungseinstellungen optimieren, indem Sie die ConfigMap-Datei container-azm-ms-agentconfig.yaml aktualisieren. In dieser Referenzimplementierung ist die Protokollierung für kube-system und alle Ihre Workloads aktiviert. Standardmäßig ist kube-system von der Protokollierung ausgeschlossen. Passen Sie den Protokollsammlungsprozess an, um ausgewogene Kostenziele, SRE-Effizienz beim Überprüfen von Protokollen sowie die Erfüllung von Complianceanforderungen zu erreichen.

Sicherheitsüberwachung

Verwenden Sie Defender für Container in Microsoft Defender für Cloud, um Sicherheitsempfehlungen anzuzeigen und zu implementieren sowie um Sicherheitswarnungen für Ihre Containerressourcen anzuzeigen. Aktivieren Sie Microsoft Defender-Pläne für verschiedene Komponenten der Datenumgebung des Karteninhabers.

Integrieren Sie Protokolle, um Daten effizient überprüfen, analysieren und abfragen zu können. Azure bietet mehrere Optionen. Sie können AKS-Diagnoseprotokolle aktivieren und diese an einen Log Analytics-Arbeitsbereich senden, der Teil von Azure Monitor ist. Eine weitere Option ist die Integration von Daten in SIEM-Lösungen (Security Information & Event Management) wie Microsoft Sentinel.

Alle Log Analytics-Arbeitsbereiche sind auf einen Aufbewahrungszeitraum von 90 Tagen festgelegt, wie dies für den Standard erforderlich ist. Richten Sie ggf. fortlaufenden Export für die längerfristige Speicherung ein. Speichern Sie keine vertraulichen Informationen in Protokolldaten, und stellen Sie sicher, dass der Zugriff auf archivierte Protokolldaten den selbem Zugriffssteuerungsmaßnahmen wie aktuelle Protokolldaten unterliegen.

Eine vollständige Perspektive finden Sie im Onboardingleitfaden für Microsoft Defender für Cloud Enterprise. In diesem Leitfaden werden Registrierung, Datenexporte in Ihre SIEM-Lösungen, das Reagieren auf Warnungen sowie die Workflowautomatisierung behandelt.

Verwandte Azure-Dienste

Im Anschluss finden Sie Links zur Featuredokumentation einiger zentraler Komponenten dieser Architektur:

• Azure Kubernetes Service (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• Azure Virtual Machine Scale Sets
• Azure Application Gateway mit integrierter Web Application Firewall (WAF)
• Azure Container Registry Tasks
• Azure Key Vault

Nächste Schritte

Installieren und Verwalten einer Firewallkonfiguration zum Schützen der Daten von Kreditkartenbesitzern Verwenden Sie keine vom Anbieter angegebenen Standardwerte für Systemkennwörter und andere Sicherheitsparameter.