Sicherheitsüberlegungen für unternehmenskritische Workloads in Azure

Sicherheit ist eines der grundlegenden Entwurfsprinzipien und auch ein wichtiger Entwurfsbereich, der innerhalb des unternehmenskritischen Architekturprozesses als erstklassiges Anliegen behandelt werden muss.

Da der Hauptfokus eines unternehmenskritischen Designs auf der Maximierung der Zuverlässigkeit liegt, damit die Anwendung leistungsfähig und verfügbar bleibt, konzentrieren sich die Sicherheitsüberlegungen und Empfehlungen, die in diesem Entwurfsbereich angewendet werden, auf die Verringerung von Bedrohungen mit der Fähigkeit, die Verfügbarkeit zu beeinträchtigen und die Allgemeine Zuverlässigkeit zu beeinträchtigen. Erfolgreiche DDoS-Angriffe (Denial-Of-Service) haben beispielsweise einen schwerwiegenden Einfluss auf die Verfügbarkeit und Leistung. Wie eine Anwendung diese Angriffsvektoren wie SlowLoris entschärft, wirkt sich auf die Gesamtsicherheit aus. Daher muss die Anwendung vollständig vor Bedrohungen geschützt werden, die direkt oder indirekt die Zuverlässigkeit der Anwendung beeinträchtigen sollen, um wirklich unternehmenskritisch zu sein.

Es ist auch wichtig zu beachten, dass es häufig erhebliche Kompromisse gibt, die mit einem gehärteten Sicherheitsstatus verbunden sind, insbesondere in Bezug auf Leistung, operative Agilität und in einigen Fällen Zuverlässigkeit. Beispielsweise führt die Einbeziehung von Inline-Netzwerk-Virtual Appliances (NVA) für Firewallfunktionen der nächsten Generation (NGFW), wie z. B. deep packet inspection, zu einer erheblichen Leistungseinbuße, zu einer zusätzlichen betrieblichen Komplexität und einem Zuverlässigkeitsrisiko, wenn Skalierbarkeits- und Wiederherstellungsvorgänge nicht eng mit denen der Anwendung übereinstimmen. Es ist daher von entscheidender Bedeutung, dass zusätzliche Sicherheitskomponenten und -methoden, die zur Verringerung wichtiger Bedrohungsvektoren dienen, auch zur Unterstützung des Zuverlässigkeitsziels einer Anwendung entwickelt werden, was einen wichtigen Aspekt der in diesem Abschnitt vorgestellten Empfehlungen und Überlegungen bilden wird.

Wichtig

Dieser Artikel ist Teil der Azure Well-Architected unternehmenskritische Workloadreihe . Wenn Sie mit dieser Reihe nicht vertraut sind, empfehlen wir Ihnen, mit einer unternehmenskritischen Workload zu beginnen?

Mission-Critical Open Source Projekt

Die Referenzimplementierungen sind Teil eines Open Source Projekts, das auf GitHub verfügbar ist. Die Coderessourcen übernehmen ein Zero Trust-Modell, um den Sicherheitsentwurf und den Implementierungsansatz zu strukturieren und zu leiten.

Ausrichtung auf das Zero Trust-Modell

Das Microsoft Zero Trust-Modell bietet einen proaktiven und integrierten Ansatz für die Anwendung von Sicherheit auf allen Ebenen einer Anwendung. Die Leitprinzipien von Zero Trust sind bestrebt, jede Transaktion explizit und kontinuierlich zu überprüfen, die geringsten Berechtigungen geltend zu machen, Intelligenz zu nutzen und erweiterte Erkennung zu nutzen, um auf Bedrohungen nahezu in Echtzeit zu reagieren. Im Mittelpunkt steht letztendlich die Beseitigung von Vertrauen innerhalb und außerhalb von Anwendungsperimetern und die Erzwingung der Überprüfung für alle Versuche, eine Verbindung mit dem System herzustellen.

Überlegungen zum Entwurf

Beginnen Sie bei der Bewertung des Sicherheitsstatus der Anwendung mit diesen Fragen als Grundlage für jede Betrachtung.

• Kontinuierliche Sicherheitstests zur Überprüfung von Entschärfungen für wichtige Sicherheitsrisiken.

  • Werden Sicherheitstests im Rahmen automatisierter CI/CD-Prozesse durchgeführt?
  • Wenn nicht, wie oft werden spezifische Sicherheitstests durchgeführt?
  • Werden die Testergebnisse an einem gewünschten Sicherheitsstatus und Bedrohungsmodell gemessen?

• Sicherheitsstufe in allen niedrigeren Umgebungen.

  • Haben alle Umgebungen innerhalb des Entwicklungslebenszyklus den gleichen Sicherheitsstatus wie die Produktionsumgebung?

• Authentifizierungs- und Autorisierungskontinuität im Fehlerfall.

  • Wenn Authentifizierungs- oder Autorisierungsdienste vorübergehend nicht verfügbar sind, kann die Anwendung weiterhin ausgeführt werden?

• Automatisierte Sicherheitskonformität und -behebung.

  • Können Änderungen an den Schlüsselsicherheitseinstellungen erkannt werden?
  • Werden Antworten zur Behebung nicht konformer Änderungen automatisiert?

• Geheimnisüberprüfung, um Geheimnisse zu erkennen, bevor Code verpflichtet wird, um geheime Lecks durch Quellcoderepositorys zu verhindern.

  • Ist die Authentifizierung für Dienste möglich, ohne dass Anmeldeinformationen als Teil des Codes vorhanden sind?

• Sichern Sie die Softwarelieferkette.

  • Ist es möglich, common vulnerabilities and Exposures (CVEs) innerhalb von genutzten Paketabhängigkeiten nachzuverfolgen?
  • Gibt es einen automatisierten Prozess zum Aktualisieren von Paketabhängigkeiten?

• Lebenszyklus von Data Protection-Schlüsseln.

  • Können dienstseitig verwaltete Schlüssel für den Schutz der Datenintegrität verwendet werden?
  • Wenn kundenseitig verwaltete Schlüssel erforderlich sind, wie ist der sichere und zuverlässige Schlüssellebenszyklus?

• CI/CD-Tools sollten Microsoft Entra Dienstprinzipale mit ausreichendem Zugriff auf Abonnementebene erfordern, um den Zugriff auf Steuerungsebene für Azure-Ressourcenbereitstellungen auf alle betrachteten Umgebungsabonnements zu erleichtern.

  • Wenn Anwendungsressourcen in privaten Netzwerken gesperrt sind, gibt es einen privaten Datenebenenkonnektivitätspfad, damit CI/CD-Tools Bereitstellungen und Wartungen auf Anwendungsebene durchführen können?
    • Dies führt zu zusätzlicher Komplexität und erfordert eine Sequenz innerhalb des Bereitstellungsprozesses durch die erforderlichen privaten Build-Agents.

Entwurfsempfehlungen

• Erzwingen Sie mithilfe von Azure Policy Sicherheits- und Zuverlässigkeitskonfigurationen für alle Dienste, und stellen Sie sicher, dass jede Abweichung von der Steuerungsebene zum Konfigurationszeitpunkt entweder korrigiert oder unterbunden wird, um Bedrohungen, die Szenarien mit „böswilligen Administratoren“ zuzuordnen sind, zu entschärfen.

• Verwenden Sie Microsoft Entra Privileged Identity Management (PIM) in Produktionsabonnements, um den dauerhaften Zugriff der Steuerungsebene auf Produktionsumgebungen zu widerrufen. Dadurch wird das Risiko, das von Szenarien mit "böswilligen Administratoren" ausgeht, durch zusätzliche "Checks and Balances" erheblich reduziert.

• Verwenden Sie verwaltete Azure-Identitäten für alle Dienste, die die Funktion unterstützen, da dies das Entfernen von Anmeldeinformationen aus dem Anwendungscode erleichtert und den operativen Aufwand der Identitätsverwaltung für die Kommunikation zwischen Diensten beseitigt.

• Verwenden Sie Microsoft Entra rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) für die Datenebenenautorisierung mit allen Diensten, die die Funktion unterstützen.

• Verwenden Sie Microsoft Identity Platform Authentifizierungsbibliotheken von Erstanbietern im Anwendungscode, um sie in Microsoft Entra ID zu integrieren.

• Erwägen Sie die sichere Tokenzwischenspeicherung, um eine eingeschränkte, aber verfügbare Benutzeroberfläche zu ermöglichen, wenn die ausgewählte Identitätsplattform nicht oder nur teilweise für die Anwendungsautorisierung verfügbar ist.

  • Wenn der Anbieter keine neuen Zugriffstoken ausstellen kann, aber dennoch vorhandene überprüft, können die Anwendung und die abhängigen Dienste ohne Probleme ausgeführt werden, bis ihre Token ablaufen.
  • Tokenzwischenspeicherung wird in der Regel automatisch von Authentifizierungsbibliotheken (z. B. MSAL) verarbeitet.

• Verwenden Sie Infrastructure-as-Code (IaC) und automatisierte CI/CD-Pipelines, um Updates für alle Anwendungskomponenten zu steuern, auch bei Fehlern.

  • Stellen Sie sicher, dass CI/CD-Tooldienstverbindungen als kritische vertrauliche Informationen geschützt und nicht direkt für Serviceteams verfügbar sind.
  • Wenden Sie granulare RBAC auf CD-Produktionspipelines an, um durch böswillige Administratoren verursachte Risiken zu minimieren.
  • Erwägen Sie die Verwendung manueller Genehmigungsgates in Produktionsbereitstellungspipelines, um risiken von "böswilligen Administratoren" weiter zu minimieren und zusätzliche technische Sicherheit für alle Produktionsänderungen zu bieten.
    • Zusätzliche Sicherheitsgates können in Bezug auf die Agilität einen Kompromiss darstellen und sollten sorgfältig bewertet werden, wobei berücksichtigt wird, wie die Agilität auch mit manuellen Gates beibehalten werden kann.

• Definieren Sie einen geeigneten Sicherheitsstatus für alle untergeordneten Umgebungen, um sicherzustellen, dass wichtige Sicherheitsrisiken behoben entschärft werden.

  • Wenden Sie nicht den gleichen Sicherheitsstatus wie die Produktion an, insbesondere im Hinblick auf die Exfiltration von Daten, es sei denn, die gesetzlichen Anforderungen sehen die Notwendigkeit vor, dies zu tun, da dies die Agilität der Entwickler erheblich beeinträchtigen wird.

• Aktivieren Sie Microsoft Defender for Cloud (zuvor Azure Security Center genannt) für alle Abonnements, die Ressourcen für eine unternehmenskritische Workload enthalten.

  • Verwenden Sie Azure Policy, um Compliance zu erzwingen.
  • Aktivieren Sie Azure Defender für alle Dienste, die die Funktion unterstützen.

• Nutzen Sie DevSecOps , und implementieren Sie Sicherheitstests in CI/CD-Pipelines.

  • Testergebnisse sollten anhand eines konformen Sicherheitsstatus gemessen werden, um Freigabegenehmigungen zu informieren, sei es automatisiert oder manuell.
  • Wenden Sie Sicherheitstests als Teil des CD-Produktionsprozesses auf jedes Release an.
    • Wenn Sicherheitstests bei jeder Version die betriebliche Agilität gefährden, stellen Sie sicher, dass ein geeigneter Sicherheitstestrhythmus angewendet wird.

• Aktivieren Sie die Überprüfung von Geheimnissen und Abhängigkeiten im Quellcoderepository.

Bedrohungsmodellierung

Die Bedrohungsmodellierung bietet einen risikobasierten Ansatz für das Sicherheitsdesign, bei dem identifizierte potenzielle Bedrohungen verwendet werden, um geeignete Sicherheitsminderungen zu entwickeln. Es gibt viele mögliche Bedrohungen mit unterschiedlichen Eintrittswahrscheinlichkeiten, und in vielen Fällen können Bedrohungen auf unerwartete, unvorhersehbare und sogar chaotische Weise verkettet werden. Diese Komplexität und Unsicherheit ist der Grund, warum herkömmliche, auf Technologieanforderungen basierende Sicherheitsansätze für unternehmenskritische Cloudanwendungen weitgehend ungeeignet sind. Erwarten Sie, dass der Prozess der Bedrohungsmodellierung für eine unternehmenskritische Anwendung komplex und unnachgiebig ist.

Um diese Herausforderungen zu bewältigen, sollte ein mehrstufiger Ansatz zur Tiefenverteidigung angewendet werden, um Ausgleichsminderungen für modellierte Bedrohungen zu definieren und zu implementieren, wobei die folgenden Verteidigungsebenen berücksichtigt werden.

1. Die Azure-Plattform mit grundlegenden Sicherheitsfunktionen und -kontrollen.
2. Die Anwendungsarchitektur und das Sicherheitsdesign.
3. Integrierte, aktivierte und bereitstellungsfähige Sicherheitsfeatures, die auf sichere Azure-Ressourcen angewendet werden können.
4. Anwendungscode und Sicherheitslogik.
5. Betriebsprozesse und DevSecOps.

Hinweis

Beachten Sie bei der Bereitstellung innerhalb einer Azure-Zielzone, dass eine zusätzliche Bedrohungsminderungsschicht durch die Bereitstellung zentralisierter Sicherheitsfunktionen von der Zielzonenimplementierung bereitgestellt wird.

Überlegungen zum Entwurf

STRIDE bietet ein einfaches Risikoframework zum Bewerten von Sicherheitsbedrohungen über wichtige Bedrohungsvektoren hinweg.

• Gefälschte Identität: Identitätswechsel von Personen mit Autorität. Beispiel: Ein Angreifer, der die Identität eines anderen Benutzers mit dem -
  • Identität
  • Authentifizierung
• Manipulationseingabe: Änderung der an die Anwendung gesendeten Eingaben oder Die Verletzung von Vertrauensgrenzen zum Ändern des Anwendungscodes. Beispielsweise ein Angreifer, der SQL-Einschleusung verwendet, um Daten in einer Datenbanktabelle zu löschen.
  • Datenintegrität
  • Überprüfen
  • Blocklisting/Allowlisting
• Ablehnung der Aktion: Fähigkeit, bereits ergriffene Aktionen zu widerlegen, und die Fähigkeit der Anwendung, Beweise zu sammeln und die Rechenschaftspflicht zu fördern. Beispielsweise das Löschen kritischer Daten ohne die Möglichkeit, einen böswilligen Administrator zurückverfolgen zu können.
  • Überwachung/Protokollierung
  • Signieren
• Offenlegung von Informationen: Zugriff auf eingeschränkte Informationen. Ein Beispiel wäre ein Angreifer, der Zugriff auf eine eingeschränkte Datei erhält.
  • Verschlüsselung
  • Datenexfiltration
  • Man-in-the-Middle-Angriffe
• Denial-of-Service: Schädliche Anwendungsunterbrechung, um die Benutzererfahrung zu beeinträchtigen. Beispielsweise ein DDoS-Botnetangriff wie Slowloris.
  • DDoS
  • Botnets
  • CDN- und WAF-Funktionen
• Rechteerweiterung: Zugriff auf privilegierte Anwendungen durch Autorisierungs-Exploits. Beispielsweise ein Angreifer, der eine URL-Zeichenfolge bearbeitet, um Zugriff auf vertrauliche Informationen zu erhalten.
  • Remoteausführung von Code
  • Authorization
  • Isolation

Entwurfsempfehlungen

• Ordnen Sie innerhalb jedes Sprints Entwicklungsbudget zu, um potenzielle neue Bedrohungen zu bewerten und Risikominderungen umzusetzen.

• Es sollten bewusste Anstrengungen unternommen werden, um sicherzustellen, dass Sicherheitsminderungen innerhalb eines gemeinsamen Technischen Kriteriums erfasst werden, um die Konsistenz für alle Anwendungsdienstteams zu fördern.

• Beginnen Sie mit einer Bedrohungsmodellierung auf Dienstebene, und vereinheitlichen Sie das Modell, indem Sie das Threadmodell auf Anwendungsebene konsolidieren.

Schutz vor Netzwerkangriffen

Die Verhinderung des unbefugten Zugriffs auf eine unternehmenskritische Anwendung und die darin enthaltenen Daten ist für die Aufrechterhaltung der Verfügbarkeit und die Sicherung der Datenintegrität von entscheidender Bedeutung.

Überlegungen zum Entwurf

• Zero Trust geht von einem verletzten Zustand aus und überprüft jede Anforderung, als stamme sie aus einem unkontrollierten Netzwerk.

  • Bei einer erweiterten Zero-Trust-Netzwerkimplementierung werden Mikrosegmentierung und verteilte ein-/ausgehende Mikroperimeter verwendet.

• Der Zugriff auf Azure PaaS-Dienste erfolgt in der Regel über öffentliche Endpunkte. Azure bietet Funktionen, mit denen öffentliche Endpunkte gesichert oder sogar vollständig privat eingerichtet werden können.

  • Azure Private Link/Private Endpunkte bieten dedizierten Zugriff auf eine Azure PaaS-Ressource über private IP-Adressen und private Netzwerkkonnektivität.
  • Virtual Network Dienstendpunkte bieten Zugriff auf Dienstebene von ausgewählten Subnetzen auf ausgewählte PaaS-Dienste.
  • Virtual Network Injection bietet dedizierte private Bereitstellungen für unterstützte Dienste, z. B. App Service über eine App Service-Umgebung.
    • Der Datenverkehr auf Verwaltungsebene fließt weiter über öffentliche IP-Adressen.

• Bei unterstützten Diensten behandelt Azure Private Link Verwendung privater Azure-Endpunkte Risiken der Datenexfiltration, die mit Dienstendpunkten verbunden sind, z. B. ein böswilliger Administrator, der Daten in eine externe Ressource schreibt.

• Wenn Sie den Netzwerkzugriff auf Azure PaaS-Dienste mithilfe privater Endpunkte oder Dienstendpunkte einschränken, ist ein sicherer Netzwerkkanal erforderlich, damit Bereitstellungspipelines sowohl auf die Azure-Steuerungsebene als auch auf die Datenebene von Azure-Ressourcen zugreifen können, um die Anwendung bereitzustellen und zu verwalten.

  • Private selbstgehostete Build-Agents, die als Azure-Ressource in einem privaten Netzwerk bereitgestellt werden, können als Proxy verwendet werden, um CI/CD-Funktionen über eine private Verbindung auszuführen. Für Build-Agents sollte ein separates virtuelles Netzwerk verwendet werden.
    • Konnektivität mit den privaten Build-Agents über CI/CD-Tools ist erforderlich.
  • Ein alternativer Ansatz besteht darin, die Firewallregeln für die Ressource on-the-fly innerhalb der Pipeline zu ändern, um eine Verbindung von einer öffentlichen IP-Adresse des Azure DevOps-Agents zuzulassen, wobei die Firewall nach Abschluss der Aufgabe entfernt wird.
    • Dieser Ansatz gilt jedoch nur für eine Teilmenge von Azure-Diensten. Dies ist beispielsweise für private AKS-Cluster nicht möglich.
  • Zum Ausführen von Entwickler- und Verwaltungsaufgaben für den Anwendungsdienst können Jumpboxen verwendet werden.

• Der Abschluss von Verwaltungs- und Wartungsaufgaben ist ein weiteres Szenario, das eine Konnektivität mit der Datenebene von Azure-Ressourcen erfordert.

• Dienst Connections mit einem entsprechenden Microsoft Entra Dienstprinzipal kann in Azure DevOps verwendet werden, um RBAC über Microsoft Entra ID anzuwenden.

• Diensttags können auf Netzwerksicherheitsgruppen angewendet werden, um die Konnektivität mit Azure PaaS-Diensten zu vereinfachen.

• Anwendungssicherheitsgruppen erstrecken sich nicht über mehrere virtuelle Netzwerke.

• Die Paketerfassung in Azure Network Watcher ist auf einen maximalen Zeitraum von fünf Stunden beschränkt.

Entwurfsempfehlungen

• Beschränken Sie den Zugriff auf öffentliche Netzwerke auf das absolute Minimum, das erforderlich ist, damit die Anwendung ihren Geschäftszweck erfüllt, um die Angriffsfläche von außen zu verringern.

  • Verwenden Sie Azure Private Link, um private Endpunkte für Azure-Ressourcen einzurichten, die eine sichere Netzwerkintegration erfordern.
  • Verwenden Sie gehostete private Build-Agents für CI/CD-Tools, um Azure-Ressourcen bereitzustellen und zu konfigurieren, die durch Azure Private Link geschützt werden.
    • Von Microsoft gehostete Agents können keine direkte Verbindung mit im Netzwerk integrierten Ressourcen herstellen.

• Öffnen Sie beim Umgang mit privaten Build-Agents niemals einen RDP- oder SSH-Port direkt für das Internet.

  • Verwenden Sie Azure Bastion, um sicheren Zugriff auf Azure Virtual Machines bereitzustellen und administrative Aufgaben für Azure PaaS über das Internet auszuführen.

• Verwenden Sie einen DDoS-Standardschutzplan, um alle öffentlichen IP-Adressen innerhalb der Anwendung zu schützen.

• Verwenden Sie Azure Front Door mit Web Application Firewall-Richtlinien, um globale HTTP/S-Anwendungen, die mehrere Azure-Regionen umfassen, bereitzustellen und zu schützen.

  • Verwenden Sie die Header-ID-Validierung, um Endpunkte öffentlicher Anwendungen zu sperren, sodass sie nur Datenverkehr akzeptieren, der von der Azure Front Door-Instanz stammt.

• Wenn zusätzliche Anforderungen an die Inline-Netzwerksicherheit, z. B. umfassende Paketüberprüfung oder TLS-Überprüfung, die Verwendung von Azure Firewall Premium- oder Network Virtual Appliance (NVA) vorgeschrieben sind, stellen Sie sicher, dass es für maximale Hochverfügbarkeit und Redundanz konfiguriert ist.

• Wenn Anforderungen für die Paketerfassung bestehen, verwenden Sie Network Watcher Pakete, die trotz des eingeschränkten Erfassungsfensters erfasst werden sollen.

• Verwenden Sie Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen, um den Anwendungsdatenverkehr in Mikrosegmenten zu segmentieren.

  • Filtern Sie den Datenverkehr innerhalb einer Anwendung nicht mithilfe einer Sicherheitsappliance.
  • Erwägen Sie die Verwendung von Azure Policy zum Erzwingen bestimmter NSG-Regeln immer Anwendungssubnetzen zugeordnet sind.

• Aktivieren Sie NSG-Datenflussprotokolle und speisen Sie diese in Traffic Analytics ein, um Erkenntnisse zu internen und externen Datenverkehrsflüssen zu gewinnen.

• Verwenden Sie Azure Private Link/Private Endpunkte( sofern verfügbar), um den Zugriff auf Azure PaaS-Dienste innerhalb des Anwendungsentwurfs abzusichern. Informationen zu Azure-Diensten, die Private Link unterstützen, finden Sie unter Verfügbarkeit von Azure Private Link.

• Wenn kein privater Endpunkt verfügbar ist und Datenexfiltrationsrisiken akzeptabel sind, verwenden Sie Virtual Network Dienstendpunkte, um den Zugriff auf Azure PaaS-Dienste aus einem virtuellen Netzwerk zu sichern.

  • Aktivieren Sie VNET-Dienstendpunkte nicht standardmäßig in allen Subnetzen, da dadurch Kanäle zur Datenexfiltration in erheblichem Maß verursacht werden.

• Greifen Sie in Hybridanwendungsszenarien auf Azure PaaS-Dienste lokal über ExpressRoute mit privatem Peering zu.

Hinweis

Beachten Sie bei der Bereitstellung innerhalb einer Azure-Zielzone, dass die Netzwerkkonnektivität mit lokalen Rechenzentren durch die Implementierung der Zielzone bereitgestellt wird. Ein Ansatz ist die Verwendung von ExpressRoute, die mit privatem Peering konfiguriert ist.

Schutz der Datenintegrität

Verschlüsselung ist ein wichtiger Schritt zur Sicherstellung der Datenintegrität und letztendlich eine der wichtigsten Sicherheitsfunktionen, die angewendet werden können, um eine Vielzahl von Bedrohungen zu minimieren. Dieser Abschnitt enthält daher wichtige Überlegungen und Empfehlungen im Zusammenhang mit Verschlüsselung und Schlüsselverwaltung, um Daten ohne Beeinträchtigung der Anwendungszuverlässigkeit zu schützen.

Überlegungen zum Entwurf

• Azure Key Vault verfügt über Transaktionslimits für Schlüssel und Geheimnisse, wobei die Drosselung pro Tresor innerhalb eines bestimmten Zeitraums angewendet wird.

• Azure Key Vault bietet eine Sicherheitsgrenze, da Zugriffsberechtigungen für Schlüssel, Geheimnisse und Zertifikate auf Tresorebene gelten.

  • Mit Zuweisungen von Schlüsseltresor-Zugriffsrichtlinien können separate Berechtigungen für Schlüssel, Geheimnisse oder Zertifikate gewährt werden.
    • Präzise Berechtigungen auf Objektebene für einen bestimmten Schlüssel, ein geheimnis oder ein Zertifikat sind jetzt möglich.

• Nachdem eine Rollenzuweisung geändert wurde, gibt es eine Latenz von bis zu 10 Minuten (600 Sekunden), bis die Rolle angewendet wird.

  • Es gibt eine Beschränkung von 2.000 Azure-Rollenzuweisungen pro Abonnement.

• Azure Key Vault zugrunde liegenden Hardwaresicherheitsmodule (HSMs) verfügen über eine FIPS 140-Validierung.

  • Ein dediziertes azure Key Vault managed HSM ist für Szenarien verfügbar, die fips 140-2 Level 3-Konformität erfordern.

• Azure Key Vault bietet Hochverfügbarkeit und Redundanz, um die Verfügbarkeit aufrechtzuerhalten und Datenverluste zu vermeiden.

• Während eines Regionsfailovers kann es einige Minuten dauern, bis für den Key Vault-Dienst ein Failover ausgeführt wird.

  • Während eines Failovers befindet sich Key Vault in einem schreibgeschützten Modus, sodass es nicht möglich ist, Schlüsseltresoreigenschaften wie Firewallkonfigurationen und -einstellungen zu ändern.

• Wenn private Verbindung zum Herstellen einer Verbindung mit Azure Key Vault verwendet wird, kann es bis zu 20 Minuten dauern, bis die Verbindung während eines regionalen Failovers wiederhergestellt wurde.

• Eine Sicherung erstellt einen Zeitpunkt Momentaufnahme eines Geheimnisses, Schlüssels oder Zertifikats als verschlüsseltes Blob, das außerhalb von Azure nicht entschlüsselt werden kann. Um verwendbare Daten aus dem Blob zu erhalten, muss sie in einem Key Vault innerhalb desselben Azure-Abonnements und derselben Azure-Geografie wiederhergestellt werden.

  • Geheimnisse können während einer Sicherung verlängert werden, was zu einem Konflikt führt.

• Mit dienstseitig verwalteten Schlüsseln führt Azure Schlüsselverwaltungsfunktionen aus, z. B. Rotation, wodurch der Umfang der Anwendungsvorgänge reduziert wird.

• Gesetzliche Kontrollen können die Verwendung von kundenseitig verwalteten Schlüsseln für die Dienstverschlüsselungsfunktionalität vorsehen.

• Wenn Datenverkehr zwischen Azure-Rechenzentren verschoben wird, wird die MACsec-Datenverknüpfungsebenenverschlüsselung auf der zugrunde liegenden Netzwerkhardware verwendet, um die Übertragung von Daten außerhalb der physischen Grenzen zu schützen, die nicht von Microsoft oder im Auftrag von Microsoft kontrolliert werden.

Entwurfsempfehlungen

• Nutzen Sie nach Möglichkeit dienstseitig verwaltete Schlüssel zum Schutz von Daten, damit Sie keine Verschlüsselungsschlüssel verwalten und keine betrieblichen Vorgänge wie Schlüsselrotation durchführen müssen.

  • Verwenden Sie kundenseitig verwaltete Schlüssel nur, wenn hierfür eine klare gesetzliche Anforderung besteht.

• Verwenden Sie Azure Key Vault als sicheres Repository für alle Geheimnisse, Zertifikate und Schlüssel, wenn zusätzliche Verschlüsselungsmechanismen oder kundenseitig verwaltete Schlüssel berücksichtigt werden müssen.

  • Stellen Sie Azure Key Vault mit Richtlinien für vorläufiges und endgültiges Löschen bereit, damit Aufbewahrungsschutz für gelöschte Objekte aktiviert werden kann.
  • Verwenden Sie die HSM-unterstützte Azure Key Vault-SKU für Anwendungsproduktionsumgebungen.

• Stellen Sie einen separaten Azure-Key Vault instance innerhalb jedes regionalen Bereitstellungsstempels bereit, um Fehlerisolation und Leistungsvorteile durch Lokalisierung zu erzielen und die Skalierungsgrenzwerte eines einzelnen Key Vault instance zu navigieren.

  • Verwenden Sie einen dedizierten Azure-Key Vault instance für globale Anwendungsressourcen.

• Befolgen Sie ein Modell mit den geringsten Berechtigungen, indem Sie die Autorisierung zum endgültigen Löschen von Geheimnissen, Schlüsseln und Zertifikaten auf spezielle benutzerdefinierte Microsoft Entra Rollen beschränken.

• Stellen Sie sicher, dass Verschlüsselungsschlüssel und zertifikate, die in Key Vault gespeichert sind, gesichert sind, und stellen Sie eine Offlinekopie bereit, falls Key Vault nicht mehr verfügbar ist.

• Verwenden Sie Key Vault Zertifikate, um die Zertifikatbeschaffung und -signatur zu verwalten.

• Führen Sie einen automatisierten Prozess für die Rotation von Schlüsseln und Zertifikaten ein.

  • Automatisieren Sie den Prozess zur Verwaltung und Verlängerung von Zertifikaten mit öffentlichen Zertifizierungsstellen, um die Verwaltung zu erleichtern.
    • Legen Sie Warnungen und Benachrichtigungen fest, um automatisierte Zertifikatverlängerungen zu ergänzen.

• Überwachen Sie die Nutzung von Schlüsseln, Zertifikaten und Geheimnissen.

  • Definieren sie Warnungen für unerwartete Nutzung in Azure Monitor.

Richtlinienbasierte Governance

Sicherheitskonventionen sind letztendlich nur dann wirksam, wenn sie konsistent und ganzheitlich über alle Anwendungsdienste und Teams hinweg durchgesetzt werden. Azure Policy stellt ein Framework zum Erzwingen von Sicherheits- und Zuverlässigkeitsbaselines bereit, um die kontinuierliche Einhaltung gemeinsamer Technischer Kriterien für eine unternehmenskritische Anwendung sicherzustellen. Genauer gesagt bildet Azure Policy einen wichtigen Bestandteil der Arm-Steuerungsebene (Azure Resource Manager) und ergänzt RBAC durch Einschränkung der Aktionen, die autorisierte Benutzer ausführen können, und kann verwendet werden, um wichtige Sicherheits- und Zuverlässigkeitskonventionen für genutzte Plattformdienste zu erzwingen.

In diesem Abschnitt werden daher wichtige Überlegungen und Empfehlungen im Zusammenhang mit der Verwendung von Azure Policy gesteuerter Governance für eine unternehmenskritische Anwendung erläutert, um sicherzustellen, dass Sicherheits- und Zuverlässigkeitskonventionen kontinuierlich erzwungen werden.

Überlegungen zum Entwurf

• Azure Policy stellt einen Mechanismus zur Förderung der Konformität bereit, indem Sicherheits- und Zuverlässigkeitskonventionen erzwungen werden, z. B. die Verwendung privater Endpunkte oder die Verwendung von Verfügbarkeitszonen.

Hinweis

Beachten Sie bei der Bereitstellung innerhalb einer Azure-Zielzone, dass die Erzwingung zentralisierter Baselinerichtlinienzuweisungen wahrscheinlich in der Implementierung für Zielzonenverwaltungsgruppen und Abonnements angewendet wird.

• Azure Policy können verwendet werden, um automatisierte Verwaltungsaktivitäten wie Bereitstellung und Konfiguration zu steuern.

  • Ressourcenanbieterregistrierung.
  • Validierung und Genehmigung einzelner Azure-Ressourcenkonfigurationen.

• Azure Policy Zuweisungsbereich schreibt die Abdeckung vor, und der Speicherort von Azure Policy Definitionen informiert über die Wiederverwendbarkeit benutzerdefinierter Richtlinien.

• Azure Policy weist mehrere Grenzwerte auf, z. B. die Anzahl von Definitionen in einem bestimmten Bereich.

• Es kann einige Minuten dauern, bis die Ausführung von DINE-Richtlinien (Deploy If Not Exist) erfolgt.

• Azure Policy ist ein wichtiger Faktor für die Erstellung von Complianceberichten und die Sicherheitsüberwachung.

Entwurfsempfehlungen

• Ordnen Sie gesetzliche und Complianceanforderungen Azure Policy-Definitionen zu.

  • Wenn es beispielsweise Anforderungen an die Datenresidenz gibt, sollte eine Richtlinie angewendet werden, um verfügbare Bereitstellungsregionen einzuschränken.

• Definieren Sie allgemeine Technische Kriterien, um sichere und zuverlässige Konfigurationsdefinitionen für alle verwendeten Azure-Dienste zu erfassen, und stellen Sie sicher, dass diese Kriterien Azure Policy Zuweisungen zugeordnet sind, um die Konformität zu erzwingen.

  • Wenden Sie beispielsweise eine Azure Policy an, um die Verwendung von Verfügbarkeitszonen für alle relevanten Dienste zu erzwingen, um zuverlässige regionsinterne Bereitstellungskonfigurationen sicherzustellen.

Die Unternehmenskritische Referenzimplementierung enthält eine vielzahl von Sicherheits- und Zuverlässigkeitsrichtlinien zum Definieren und Erzwingen eines beispiels gängigen Technischen Kriterien.

• Überwachen Sie die Dienstkonfigurationsabweichung im Verhältnis zu den allgemeinen Technischen Kriterien mithilfe von Azure Policy.

Für unternehmenskritische Szenarien mit mehreren Produktionsabonnements unter einer dedizierten Verwaltungsgruppe priorisieren Sie Zuweisungen im Verwaltungsgruppenbereich.

• Verwenden Sie nach Möglichkeit integrierte Richtlinien, um den betrieblichen Aufwand für die Pflege benutzerdefinierter Richtliniendefinitionen zu minimieren.

• Wenn benutzerdefinierte Richtliniendefinitionen erforderlich sind, stellen Sie sicher, dass Definitionen im geeigneten Verwaltungsgruppenbereich bereitgestellt werden, um die Wiederverwendung über alle umfassenden Umgebungsabonnements hinweg zu ermöglichen, um die Wiederverwendung von Richtlinien in Produktionsumgebungen und niedrigeren Umgebungen zu ermöglichen.

  • Wenn Sie die Anwendungsroadmap an Azure-Roadmaps ausrichten, verwenden Sie die verfügbaren Microsoft-Ressourcen, um zu untersuchen, ob wichtige benutzerdefinierte Definitionen als integrierte Definitionen integriert werden können.

Hinweis

Erwägen Sie bei der Bereitstellung innerhalb einer Azure-Zielzone die Bereitstellung benutzerdefinierter Azure Policy Definitionen innerhalb des Bereichs der Stammverwaltungsgruppe zwischen Unternehmen, um die Wiederverwendung in allen Anwendungen innerhalb des umfassenderen Azure-Bestandes zu ermöglichen. In einer Zielzonenumgebung werden bestimmte zentralisierte Sicherheitsrichtlinien standardmäßig innerhalb höherer Verwaltungsgruppenbereiche angewendet, um die Sicherheitskonformität für den gesamten Azure-Bestand zu erzwingen. Beispielsweise sollten Azure-Richtlinien angewendet werden, um Softwarekonfigurationen automatisch über VM-Erweiterungen bereitzustellen und eine konforme basisfähige VM-Konfiguration zu erzwingen.

• Verwenden Sie Azure Policy, um ein einheitliches Taggingschema in der gesamten Anwendung zu erzwingen.
  • Bestimmen Sie erforderliche Azure-Tags, und nutzen Sie den Modus zum Anfügen von Richtlinien, um die Nutzung zu erzwingen.

Wenn die Anwendung beim Microsoft Mission-Critical Support abonniert ist, stellen Sie sicher, dass das angewendete Taggingschema einen aussagekräftigen Kontext bietet, um die Supporterfahrung mit fundiertem Anwendungsverständnis zu erweitern.

• Exportieren sie Microsoft Entra Aktivitätsprotokolle in den globalen Log Analytics-Arbeitsbereich, der von der Anwendung verwendet wird.
  • Stellen Sie sicher, dass Azure-Aktivitätsprotokolle im globalen Speicherkonto zusammen mit betriebsbezogenen Daten für die langfristige Aufbewahrung archiviert werden.

In einer Azure-Zielzone werden Microsoft Entra Aktivitätsprotokolle auch im Log Analytics-Arbeitsbereich der zentralen Plattform erfasst. In diesem Fall muss ausgewertet werden, ob im globalen Log Analytics-Arbeitsbereich weiterhin Microsoft Entra ID erforderlich sind.

• Integrieren Sie Sicherheitsinformationen und Ereignisverwaltung in Microsoft Defender for Cloud (zuvor Azure Security Center genannt).

IaaS-spezifische Überlegungen bei der Verwendung von Virtual Machines

In Szenarien, in denen die Verwendung von IaaS-Virtual Machines erforderlich ist, müssen einige Besonderheiten berücksichtigt werden.

Überlegungen zum Entwurf

• Images werden nach der Bereitstellung nicht automatisch aktualisiert.
• Updates werden nicht automatisch auf ausgeführten VMs installiert.
• Images und einzelne VMs werden in der Regel nicht standardmäßig gehärtet.

Entwurfsempfehlungen

• Gewähren Sie keinen direkten Zugriff über das öffentliche Internet auf Virtual Machines, indem Sie Zugriff auf SSH, RDP oder andere Protokolle gewähren. Verwenden Sie immer Azure Bastion und Jumpboxen mit eingeschränktem Zugriff auf eine kleine Gruppe von Benutzern.
• Schränken Sie die direkte Internetkonnektivität mithilfe von Netzwerksicherheitsgruppen, (Azure)-Firewall oder Application Gateways (Ebene 7) ein, um ausgehenden Datenverkehr zu filtern und einzuschränken.
• Erwägen Sie für Anwendungen mit mehreren Ebenen die Verwendung verschiedener Subnetze und verwenden Sie Netzwerksicherheitsgruppen, um den Zugriff zwischen ihnen einzuschränken.
• Priorisieren Sie nach Möglichkeit die Verwendung der Authentifizierung mit öffentlichem Schlüssel. Speichern Sie Geheimnisse an einem sicheren Ort wie Azure Key Vault.
• Schützen Sie VMs mithilfe von Authentifizierung und Zugriffssteuerung.
• Wenden Sie die gleichen Sicherheitsmethoden an, die für unternehmenskritische Anwendungsszenarien beschrieben werden.

Befolgen und anwenden Sie sicherheitsmethoden für unternehmenskritische Anwendungsszenarien, wie oben beschrieben, und wenden Sie diese an, sofern zutreffend, sowie die bewährten Sicherheitsmethoden für IaaS-Workloads in Azure.

Nächster Schritt

Überprüfen Sie die bewährten Methoden für betriebsbezogene Verfahren für unternehmenskritische Anwendungsszenarien.

Betriebsprozeduren