Beim Azure Well-Architected Framework handelt es sich um eine Reihe von Leitsätzen, die für die Beurteilung einer Lösung über die Qualitätssäulen der Architekturexzellenz verwendet werden können:
Mit diesem Artikel wird diese Reihe beendet. Die Einführung finden Sie hier.
In diesem Leitfaden dieser Reihe werden Well-Architected-Prinzipien in allen Entwurfsoptionen eingebracht. In diesem Artikel werden die betreffenden Optionen zusammengefasst. Die Implementierung GitHub: AKS-Baselinecluster (Azure Kubernetes Service) für regulierte Workloads veranschaulicht die jeweils zutreffenden Prinzipien.
Für PCI-DSS 3.2.1-Workloads ist eine gut strukturierte Lösung absolut unabdingbar. Obwohl die Ausrichtung der Infrastruktur an PCI-Anforderungen von entscheidender Bedeutung ist, endet die Konformität nicht bei der Hostinginfrastruktur. Ohne Berücksichtigung der Qualitätspfeiler, insbesondere der Sicherheit, kann dadurch die Konformität gefährdet werden. Gut strukturierte Lösungen kombinieren sowohl die Infrastruktur- als auch die Workloadperspektive, um die hohen Anforderungen zu erfüllen, die zum Erreichen konformer Ergebnisse erforderlich ist.
Sicherheit
Befolgen Sie die grundlegenden Anleitungen unter Prinzipien für den Sicherheitsentwurf. In diesen Abschnitten finden Sie eine Übersicht über bewährte Methoden für eine regulierte Umgebung.
Governance
Die Governanceimplementierung wird durch die Konformitätsanforderungen in PCI-DSS 3.2.1 bestimmt. Dies wirkt sich auf die technischen Steuerelemente für die Aufrechterhaltung der Segmentierung, den Zugriff auf Ressourcen, die Erkennung von Sicherheitsrisiken und vor allem den Schutz von Kundendaten aus.
Strategie der Unternehmenssegmentierung
Um eine vollständige Isolation aufrechtzuerhalten, wird die Bereitstellung der regulierten Infrastruktur in einem eigenständigen Abonnement empfohlen. Wenn Sie über mehrere Abonnements verfügen, die aus Konformitätsgründen erforderlich sind, sollten Sie diese in einer Verwaltungsgruppenhierarchie gruppieren, die die relevanten Azure-Richtlinien einheitlich auf Ihre Abonnements im jeweiligen Bereich anwendet. Wenden Sie die entsprechenden Azure-Richtlinien im Abonnement auf Abonnementebene an, um die weitgehenden Richtlinien zu erfassen, die für alle Cluster in der Datenumgebung des Karteninhabers (Cardholder Data Environment, CDE) gelten sollten. Wenden Sie die entsprechenden Azure-Richtlinien auf Ressourcengruppenebene an, um Richtlinien zu erfassen, die für eine bestimmte Clusterinstanz gelten. Diese Richtlinien bilden die zentralen Leitlinien einer Zielzone.
Isolieren Sie die PCI-Workload (im Bereich) in Bezug auf Vorgänge und Konnektivität von anderen Workloads (außerhalb des Bereichs). Sie können die Isolation realisieren, indem Sie separate Cluster bereitstellen. Sie können auch Segmentierungsstrategien verwenden, um für eine Trennung zu sorgen. Die Cluster können beispielsweise separate Knotenpools verwenden, sodass Workloads niemals einen virtuellen Knotencomputer gemeinsam nutzen.
Durchsetzung von Richtlinien
Erzwingen Sie Sicherheitskontrollen, indem Sie Azure-Richtlinien aktivieren. In dieser regulierten Architektur können Sie beispielsweise eine Fehlkonfiguration der Datenumgebung des Karteninhabers verhindern. Sie können eine Azure-Richtlinie anwenden, die keine Zuteilung von öffentlichen IP-Adressen für VM-Knoten zulässt. Solche Zuteilungen werden erkannt und gemeldet oder blockiert.
Informationen zu Richtlinien, die Sie für AKS aktivieren können, finden Sie unter Integrierte Azure Policy-Definitionen für Azure Kubernetes Service.
Azure umfasst mehrere integrierte Richtlinien für die meisten Dienste. Entsprechende Informationen finden Sie unter Integrierte Azure Policy-Richtliniendefinitionen. Wenden Sie die Richtlinien je nach Bedarf an.
Überwachung der Konformität
Die Konformität muss systematisch überwacht und verwaltet werden. Es werden regelmäßige Konformitätsnachweise durchgeführt. Wenn Sie wissen, ob Ihre Cloudressourcen konform sind, können Sie sich auf Nachweise und Überwachung vorbereiten.
Nutzen Sie das Dashboard für die Einhaltung gesetzlicher Bestimmungen in Microsoft Defender für Cloud. Durch die kontinuierliche Überwachung des Dashboards können Sie den Konformitätsstatus Ihrer Workload nachverfolgen.
Netzwerksicherheit
In einer Hub-Spoke-Topologie ermöglicht die Verwendung separater virtueller Netzwerke für die einzelnen Entitäten eine grundlegende Segmentierung des Netzwerkbedarfs. Jedes Netzwerk wird weiter in Subnetze segmentiert.
Der AKS-Cluster bildet den Kern der CDE. Es sollte nicht über öffentliche IP-Adressen zugänglich sein, und die Konnektivität muss abgesichert werden. Typische ein- und ausgehende CDE-Datenflüsse können wie folgt kategorisiert werden:
- Eingehender Datenverkehr an den Cluster.
- Ausgehender Datenverkehr aus dem Cluster.
- Clusterinterner Datenverkehr zwischen Pods.
Um die Anforderungen einer regulierten Umgebung zu erfüllen, wird der Cluster als privater Cluster bereitgestellt. In diesem Modus wird der Datenverkehr zum und aus dem öffentlichen Internet eingeschränkt. Selbst die Kommunikation mit dem von AKS verwalteten Kubernetes-API-Server ist privat. Die Sicherheit wird durch strenge Netzwerkkontrollen und IP-Firewallregeln weiter verbessert.
- Netzwerksicherheitsgruppen (NSGs) ermöglichen eine sichere Kommunikation zwischen Ressourcen in einem Netzwerk.
- Azure Firewall ermöglicht die Filterung des Datenverkehrs zwischen Cloudressourcen, dem Internet und lokalen Umgebungen.
- Die Integration von Azure Application Gateway in Azure Web Application Framework ermöglicht die Filterung des gesamten eingehenden Datenverkehrs aus dem Internet, der von Azure Application Gateway empfangen wird.
- Kubernetes NetworkPolicy bietet die Möglichkeit, nur bestimmte Pfade zwischen den Pods im Cluster zuzulassen.
- Azure Private Link ermöglicht Verbindungen zu anderen PaaS-Diensten (Platform-as-a-Service) von Azure, z. B. Azure Key Vault und Azure Container Registry, für operative Aufgaben.
Vorhandene Überwachungsprozesse stellen sicher, dass der Datenverkehr erwartungsgemäß fließt sowie Anomalien erkannt und gemeldet werden.
Weitere Informationen zur Netzwerksicherheit finden Sie unter Netzwerksegmentierung.
Datensicherheit
PCI-DSS 3.2.1 schreibt vor, dass alle Karteninhaberdaten (Cardholder Data, CHD) niemals unverschlüsselt sind, sei es während der Übertragung noch im Speicher.
Da sich diese Architektur und die Implementierung auf die Infrastruktur und nicht auf die Workload konzentrieren, wird die Datenverwaltung nicht veranschaulicht. Nachstehend sind einige Empfehlungen für eine gute Architektur aufgeführt.
Ruhende Daten
Die Daten müssen mit standardisierten Verschlüsselungsalgorithmen verschlüsselt werden.
- Speichern Sie keine Daten in der CDE.
- Verschlüsseln Sie Daten außerhalb der Speicherebene.
- Schreiben Sie nur verschlüsselte Daten auf das Speichermedium.
- Speichern Sie die Schlüssel nicht auf der Speicherebene.
Alle Daten in Azure Storage werden mit sicheren Kryptografieverfahren ver- und entschlüsselt. Hierbei werden selbstverwaltete Verschlüsselungsschlüssel bevorzugt.
Wenn Sie Daten vorübergehend speichern müssen, gelten die gleichen Überlegungen für diese Daten. Es wird dringend empfohlen, die hostbasierte Verschlüsselung von AKS zu aktivieren. Sie können die Verschlüsselung temporärer Daten mit integrierten Azure-Richtlinien erzwingen.
Informieren Sie sich bei der Auswahl einer Speichertechnologie über die Features für die Datenaufbewahrung. Stellen Sie sicher, dass alle Daten sicher entfernt werden, wenn die konfigurierte Zeit abläuft.
Der Standard schreibt außerdem vor, dass keine vertraulichen Authentifizierungsdaten gespeichert werden. Achten Sie darauf, dass die Daten nicht in Protokollen, Dateinamen, Cache und anderen Daten verfügbar gemacht werden.
Daten während der Übertragung
Die gesamte Kommunikation mit Entitäten, die mit der CDE interagieren, muss über verschlüsselte Kanäle erfolgen.
- In die CDE darf nur HTTPS-Datenverkehr fließen. In dieser Architektur verweigert Azure Application Gateway den gesamten Datenverkehr über Port 80.
- Vorzugsweise sollten Sie Daten nicht außerhalb der CDE verschlüsseln und entschlüsseln. Andernfalls sollten Sie die betreffende Entität als Teil der CDE betrachten.
- Sorgen Sie in der CDE mit mTLS für eine sichere Kommunikation zwischen Pods. Sie können zu diesem Zweck ein Dienstmesh implementieren.
- Lassen Sie nur sichere Verschlüsselungsverfahren sowie TLS 1.2 oder höher zu.
Identity
Befolgen Sie beim Entwurf von Zugriffsrichtlinien die folgenden Sicherheitsprinzipien:
- Beginnen Sie mit Zero-Trust Richtlinien. Machen Sie bei Bedarf Ausnahmen.
- Erteilen Sie die geringsten Berechtigungen, d. h. lediglich ausreichende Berechtigungen, um eine Aufgabe zu erledigen.
- Minimieren Sie den ständigen Zugriff.
Die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes verwaltet die Berechtigungen für die Kubernetes-API. AKS unterstützt diese Kubernetes-Rollen. AKS ist vollständig mit Microsoft Entra ID integriert. Sie können den Rollen Microsoft Entra-Identitäten zuweisen und auch andere Funktionen nutzen.
Zero-Trust-Zugriff
Kubernetes-RBAC, Azure-RBAC und Azure-Dienste implementieren standardmäßig die Einstellung Alles verweigern. Setzen Sie diese Einstellung mit Vorsicht außer Kraft, und lassen Sie einen Zugriff nur auf Entitäten zu, auf die ein Zugriff notwendig ist. Ein weiterer Bereich für die Zero-Trust-Implementierung ist das Deaktivieren des SSH-Zugriffs auf die Clusterknoten.
Geringste Berechtigungen
Sie können verwaltete Identitäten für Azure-Ressourcen und -Pods verwenden und diese auf die erwarteten Aufgaben beschränken. Azure Application Gateway muss beispielsweise über Berechtigungen zum Abrufen von Geheimnissen (TLS-Zertifikaten) aus Azure Key Vault verfügen, darf aber keine Berechtigungen zum Ändern von Geheimnissen haben.
Minimieren des ständigen Zugriffs
Minimieren Sie den ständigen Zugriff durch Just-in-Time-Gruppenmitgliedschaft in Microsoft Entra. Stärken Sie die Kontrolle mit Richtlinien für bedingten Zugriff in Microsoft Entra ID. Diese Option unterstützt viele Anwendungsfälle, z. B. die mehrstufige Authentifizierung, die Einschränkung der Authentifizierung auf Geräte, die vom Microsoft Entra-Mandanten verwaltet werden, oder die Blockierung atypischer Anmeldeversuche.
Verwaltung von Geheimnissen
Speichern Sie Geheimnisse, Zertifikate, Schlüssel und Kennwörter außerhalb der CDE. Sie können native Kubernetes-Geheimnisobjekte oder einen verwalteten Schlüsselspeicher wie Azure Key Vault verwenden. Die Verwendung eines verwalteten Speichers vereinfacht Verwaltungsaufgaben für Geheimnisse, z. B. Schlüsselrotation und Zertifikatsverlängerung.
Achten Sie darauf, dass für den Zugriff auf den Schlüsselspeicher eine Kombination von Netzwerkkontrollen und Zugriffssteuerungen verwendet wird. Wenn verwaltete Identitäten aktiviert sind, muss sich der Cluster selbst bei Key Vault authentifizieren, um Zugriff zu erhalten. Außerdem darf die Konnektivität zum Schlüsselspeicher nicht über das öffentliche Internet erfolgen. Verwenden Sie ein privates Netzwerk, z. B. Private Link.
Optimaler Betrieb
Befolgen Sie die grundlegenden Anleitungen unter Prinzipien für optimalen Betrieb. In diesen Abschnitten finden Sie eine Übersicht über bewährte Methoden für eine regulierte Umgebung.
Trennung von Rollen
Das Durchsetzen einer klaren Aufgabentrennung ist für regulierte Umgebungen von entscheidender Bedeutung. Sorgen Sie dafür, dass Rollen und Zuständigkeiten basierend auf den Anforderungen der Workload und der Interaktion mit der CDE definiert werden. Beispielsweise kann u. U. eine Rolle als Infrastrukturoperator oder Site Reliability Engineer (SRE) für Vorgänge im Zusammenhang mit dem Cluster und abhängigen Diensten erforderlich sein. Die Rolle ist für die Aufrechterhaltung der Sicherheit, Isolation, Bereitstellung und Beobachtbarkeit verantwortlich. Formalisieren Sie die betreffenden Definitionen, und entscheiden Sie, welche Berechtigungen diese Rollen benötigen. SREs verfügen beispielsweise über hohe Clusterzugriffsrechte, benötigen aber lediglich Lesezugriff auf Workloadnamespaces.
Workloadisolation
Für PCI-DSS 3.2.1 müssen die Vorgänge der PCI-Workload von anderen Workloads isoliert sein. In dieser Implementierung sind Workloads im Bereich und Workloads außerhalb des Bereichs in zwei separaten Benutzerknotenpools segmentiert. Anwendungsentwickler für Workloads im Bereich und Entwickler für Workloads außerhalb des Bereichs können u. U. über unterschiedliche Berechtigungen verfügen. Außerdem gibt es getrennte Qualitätsgates. Beispielsweise muss im Bereichscode für Konformität und deren Nachweis gesorgt werden, während dies für Code außerhalb des Bereichs nicht erforderlich ist. Außerdem müssen separate Buildpipelines und Releaseverwaltungsprozesse vorhanden sein.
Betriebsmetadaten
Die Anforderung 12 des PCI-DSS 3.2.1-Standards schreibt vor, dass Informationen zum Workloadbestand und eine Dokumentation der Zugriffe von Mitarbeitern gepflegt werden. Es wird dringend empfohlen, Azure-Tags zu verwenden, da Sie Umgebungsinformationen Azure-Ressourcen, Ressourcengruppen und Abonnements zuordnen können.
Pflegen Sie Informationen zu genehmigten Lösungen, die Teil der Infrastruktur und Workload sind. Dazu gehört eine Liste von VM-Images, Datenbanken und Drittanbieterlösungen Ihrer Wahl, die Sie in die CDE übernehmen. Sie können diesen Prozess sogar automatisieren, indem Sie einen Dienstkatalog erstellen. Er ermöglicht eine Self-Service-Bereitstellung, indem die betreffenden Lösungen in einer bestimmten Konfiguration verwendet werden, die dem laufenden Plattformbetrieb gerecht wird.
Einblick
Um die Einhaltung von Anforderung 10 zu erfüllen, ist ein Einblick in die CDE wichtig. Aktivitätsprotokolle enthalten Informationen zu Vorgängen im Zusammenhang mit der Konto- und Geheimnisverwaltung, der Verwaltung von Diagnoseeinstellungen, der Serververwaltung und anderen Ressourcenzugriffsvorgängen. Alle Protokolle werden mit Datum, Uhrzeit, Identität und anderen ausführlichen Informationen erstellt. Speichern Sie Protokolle bis zu einem Jahr, indem Sie Richtlinien für die Datenaufbewahrung und -archivierung in Azure Monitor-Protokollen konfigurieren.
Stellen Sie sicher, dass nur Rollen auf Protokolle zugreifen können, die die Protokolle wirklich benötigen. Log Analytics und Microsoft Sentinel unterstützen verschiedene rollenbasierte Zugriffssteuerungen zum Verwalten des Zugriffs auf Überwachungsprotokolle.
Reaktion und Korrektur
Die Azure-Überwachungsdienste Azure Monitor und Microsoft Defender for Cloud können Benachrichtigungen oder Warnungen generieren, wenn sie anormale Aktivitäten erkennen. Diese Warnungen enthalten Kontextinformationen wie Schweregrad, Status und Aktivitätszeit. Für generierte Warnungen muss eine Korrekturstrategie vorhanden sein, und der Fortschritt muss überprüft werden. Es wird empfohlen, Daten in einer SIEM-Lösung (Security Information and Event Management) zu zentralisieren, da die Integration von Daten einen umfangreichen Warnungskontext bereitstellen kann.
In der Ansicht Sicherheitswarnungen in Microsoft Defender für Cloud haben Sie Zugriff auf alle Warnungen, die Microsoft Defender für Cloud bei Ihren Ressourcen erkennt. Verwenden Sie einen Selektierungsprozess, um das Problem zu beheben. Arbeiten Sie mit Ihrem Sicherheitsteam zusammen, um zu verstehen, wie relevante Warnungen den Workloadbesitzern zur Verfügung gestellt werden.
Effiziente Leistung
Befolgen Sie die grundlegenden Anleitungen unter Prinzipien der Leistungseffizienz. In diesen Abschnitten finden Sie eine Übersicht über bewährte Methoden für eine regulierte Umgebung.
Skalierung
Durch Beobachtung, wie sich die Umgebung an veränderliche Anforderungen anpasst, kann das erwartete Laufzeitverhalten der Umgebung bei hoher Auslastung eingeschätzt werden. Die automatische Skalierung von Ressourcen in der Workload minimiert die Benutzerinteraktion in der CDE. Ein zusätzlicher Sicherheitsvorteil ist die stets kleinere Angriffsfläche. Sie können den Vorteil maximieren, indem Sie Ressourcen nutzen, die eine Scale-to-Zero-Strategie unterstützen. AKS unterstützt beispielsweise das Herunterskalieren der Benutzerknotenpools auf 0. Weitere Informationen finden Sie unter Skalieren von User-Knotenpools auf 0 (null).
Partitionierung
Die Partitionierung ist ein wichtiger Faktor für die Leistungseffizienz in regulierten Workloads. Diskrete Komponenten ermöglichen eine klare Definition der Verantwortung und sind für präzise Steuerungen hilfreich, z. B. Netzwerkrichtlinien. Ähnlich wie bei jeder Segmentierungsstrategie isoliert die Partitionierung Komponenten und steuert den Einfluss des Wirkradius auf unerwartete Fehler oder die Kompromittierung von Systemen.
Shared Nothing-Architektur
Die Shared Nothing-Architektur soll Konflikte zwischen kollokierten Workloads beseitigen. Außerdem ist dies eine Strategie zum Beseitigen von Single Points of Failure. In einer regulierten Umgebung müssen Komponenten durch logische oder physische Grenzen isoliert werden. Dies entspricht der Shared Nothing-Architektur, was zu Skalierbarkeitsvorteilen führt. Darüber hinaus ermöglicht sie die Ausrichtung auf relevante Sicherheitskontrollen und strengere Überwachungsfunktionen der verschiedenen Komponenten.
Einfache Workloads
Die Komplexität von Workloads ist schwer zu dokumentieren und zu überwachen. Bemühen Sie sich aufgrund der Leistungsvorteile und der leichteren Überwachung gesetzlicher Anforderungen um Einfachheit. Überdenken Sie Entscheidungen für Optionen, die mehr Funktionen als nötig bieten, da dadurch die Angriffsfläche und die Möglichkeit von Missbrauch oder Fehlkonfiguration steigt.
Zuverlässigkeit
Die Zuverlässigkeit regulierter Umgebungen muss vorhersagbar sein, damit sie zu Überwachungszwecken konsistent erklärt werden kann. Befolgen Sie die grundlegenden Anleitungen in der Beschreibung der Zuverlässigkeitsprinzipien. In diesen Abschnitten finden Sie eine Übersicht über bewährte Methoden für eine regulierte Umgebung.
Wiederherstellungsziele und Notfallwiederherstellung
Aufgrund der sensiblen Natur der Daten, die in regulierten Workloads verarbeitet werden, müssen unbedingt Wiederherstellungsziele und Recovery Point Objectives (RPOs) definiert werden. Inwieweit ist ein Verlust von Karteninhaberdaten akzeptabel? Für Wiederherstellungsmaßnahmen in der CDE gelten ebenfalls Anforderungen des Standards. Gehen Sie davon aus, dass Fehler auftreten, und sorgen Sie dafür, dass ein klarer Wiederherstellungsplan für solche Fehler vorhanden ist, der die jeweiligen Rollen, Zuständigkeiten und Datenzugriffsberechtigungen berücksichtigt. Live-Site-Probleme sind keine Rechtfertigung, von Bestimmungen abzuweichen. Dies ist besonders wichtig in einer umfassenden Notfallwiederherstellungssituation. Sorgen Sie dafür, dass eine klare Dokumentation für die Notfallwiederherstellung vorhanden ist, die die Anforderungen erfüllt und unerwartete Zugriffe auf CDE oder CHD minimiert. Überprüfen Sie nach der Wiederherstellung immer die Schritte des Wiederherstellungsprozesses, um sicherzustellen, dass kein unerwarteter Zugriff vorgekommen ist. Dokumentieren Sie geschäftliche Begründungen für diese Vorkommen.
Wiederherstellung
Durch Hinzufügen von Resilienz- und Wiederherstellungsstrategien zu Ihrer Architektur kann verhindert werden, dass Ad-hoc-Zugriffe auf die CDE nötig werden. Das System sollte sich beim definierten RPO selbst wiederherstellen können, ohne dass ein direkter menschlicher Eingriff erforderlich ist. Auf diese Weise können Sie eine unnötige Offenlegung von Karteninhaberdaten vermeiden, selbst für befugte Personen mit Notfallzugriff. Der Wiederherstellungsprozess muss überprüfbar sein.
Berücksichtigung von Sicherheitsrisiken
Überprüfen Sie Sicherheitsrisiken, da sie ursächlich für Workloaddowntime und Datenverluste sein können. Investitionen in die Sicherheit wirken sich auch auf die Zuverlässigkeit der Workload aus.
Betriebsprozesse
Die Zuverlässigkeit gilt auch für alle Betriebsprozesse in und neben der CDE. Klar definierte, automatisierte und getestete Prozesse für Aufgaben wie Imageerstellung und Jumpboxverwaltung tragen zu einer gut strukturierten Lösung bei.
Kostenoptimierung
Befolgen Sie die grundlegenden Anleitungen unter Grundsätze der Kostenoptimierung.
Durch die Konformitätsanforderungen und strengen Sicherheitskontrollen entsteht ein Zielkonflikt mit den Kosten. Es wird empfohlen, mit dem Preisrechner erste Schätzungen zu erstellen.
Nachstehend finden Sie eine übergeordnete Darstellung der Kostenauswirkungen der wichtigsten Ressourcen, die von dieser Architektur verwendet werden.
Die Haupttreiber sind die Skalierungsgruppen für virtuelle Computer, die die Knotenpools bilden, und Azure Firewall. Ein weiterer Kostenaspekt ist Log Analytics. Abhängig vom jeweils ausgewählten Plan fallen auch höhere Kosten für Microsoft Defender für Cloud an.
Sie müssen sich im Klaren sein, wie sich der Preis eines Diensts zusammensetzt. Azure protokolliert die gemessene Nutzung. Die folgende Abbildung enthält Detailinformationen zu Azure Firewall für diese Architektur.
Die Kosten für einige Ressourcen, z. B. Azure Firewall, können auf mehrere Geschäftseinheiten oder Anwendungen verteilt werden. Eine andere Möglichkeit zum Optimieren der Kosten kann das Hosten eines mehrinstanzenfähigen Clusters in einer Organisation sein, um die Dichte durch Workloaddiversität zu maximieren. Diese Vorgehensweise wird für regulierte Workloads allerdings nicht empfohlen. Priorisieren Sie Konformität und Segmentierung immer gegenüber Kostenvorteilen.
Um die Budgeteinschränkungen einzuhalten, können Sie die Kosten unter anderem beeinflussen, indem Sie die Azure Application Gateway-Infrastruktur anpassen, die Anzahl der Instanzen für die automatische Skalierung festlegen und die Protokollausgabe reduzieren, sofern das von PCI-DSS 3.2.1 vorgeschriebene Überwachungsprotokoll noch erfüllt wird. Bewerten Sie die betreffenden Optionen immer gegenüber Zielkonflikten mit anderen Aspekten des Entwurfs, die eine Erfüllung der SLA ermöglichen, Etwa, ob weiterhin eine geeignete Skalierung möglich ist, um Spitzen im Datenverkehr zu bewältigen.
Wenden Sie bei der Erstellung von Azure-Ressourcengruppen Tags an, damit diese in Hinblick auf die Kosten nachverfolgt werden können. Verwenden Sie Kostenverwaltungstools wie Azure Advisor und Microsoft Cost Management, um Kosten nachzuverfolgen und zu analysieren.
Erwägen Sie die Aktivierung AKS-Kostenanalyse für die granulare Kostenzuordnung von Clusterinfrastrukturen durch Kubernetes spezifische Konstrukte.