Sicherheitsüberlegungen für unternehmenskritische Workloads in Azure

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

Da der Hauptfokus eines unternehmenskritischen Designs darauf liegt, die Zuverlässigkeit zu maximieren, damit die Anwendung weiterhin leistungsfähig und verfügbar bleibt, konzentrieren sich die sicherheitsrelevanten Überlegungen und Empfehlungen, die in diesem Entwurfsbereich angewendet werden, auf die Reduzierung von Bedrohungen mit der Fähigkeit, die Verfügbarkeit zu beeinträchtigen und die Gesamtzuverlässigkeit zu behindern. So sind beispielsweise erfolgreiche Denial-Of-Service (DDoS)-Angriffe bekannt, die katastrophale Auswirkungen auf Verfügbarkeit und Leistung haben. Wie eine Anwendung diese Angriffsvektoren verringert, z. B. SlowLoris, wirkt sich auf die Gesamtsicherheit aus. Daher muss die Anwendung vollständig vor Bedrohungen geschützt werden, die darauf abzielen, die Zuverlässigkeit der Anwendung direkt oder indirekt zu kompromittieren, um wirklich unternehmenskritisch zu sein.

Es ist auch wichtig zu beachten, dass häufig erhebliche Kompromisse mit einem gehärteten Sicherheitsstatus verbunden sind, insbesondere in Bezug auf Leistung, betriebliche Flexibilität und in einigen Fällen Zuverlässigkeit. Beispielsweise führt die Einbeziehung von Inline network Virtual Appliances (NVA) für NGFW-Funktionen (Next-Generation Firewall, z. B. deep packet inspection) zu einer erheblichen Leistungseinbuße, zu einer zusätzlichen Betriebskomplexität und zu einem Zuverlässigkeitsrisiko, wenn Skalierbarkeits- und Wiederherstellungsvorgänge nicht eng mit der der Anwendung übereinstimmen. Daher ist es wichtig, dass zusätzliche Sicherheitskomponenten und -praktiken, mit denen wichtige Bedrohungsvektoren abgemildert werden sollen, auch entwickelt werden, um das Zuverlässigkeitsziel einer Anwendung zu unterstützen, das einen wichtigen Aspekt der Empfehlungen und Überlegungen bildet, die in diesem Abschnitt vorgestellt werden.

Ausrichtung mit dem 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 geringste Berechtigung zu bestätigen, Intelligenz zu verwenden und erweiterte Erkennung auf Bedrohungen in nahezu Echtzeit zu reagieren. Es ist letztendlich darauf ausgerichtet, Vertrauen innerhalb und außerhalb von Anwendungsperimetern zu beseitigen und die Überprüfung für alles zu erzwingen, was versucht, eine Verbindung mit dem System herzustellen.

Überlegungen zum Entwurf

Wenn Sie den Sicherheitsstatus der Anwendung bewerten, beginnen Sie mit diesen Fragen als Grundlage für jede Prüfung.

• Kontinuierliche Sicherheitstests zur Überprüfung von Gegenmaßnahmen für wichtige Sicherheitsrisiken.

  • Werden Sicherheitstests als Teil automatisierter CI/CD-Prozesse durchgeführt?
  • Wenn nicht, wie oft werden spezifische Sicherheitstests durchgeführt?
  • Werden Testergebnisse anhand eines gewünschten Sicherheitsstatus- und Bedrohungsmodells gemessen?

• Sicherheitsstufe in allen Niedrigeren Umgebungen.

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

• Authentifizierungs- und Autorisierungskontinuität im Falle eines Fehlers.

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

• Automatisierte Sicherheitscompliance und Wartung.

  • Können Änderungen an wichtigen Sicherheitseinstellungen erkannt werden?
  • Werden Antworten auf die Behebung nicht konformer Änderungen automatisiert?

• Geheimes Scannen, um geheime Schlüssel zu erkennen, bevor Code verpflichtet wird, geheime Lecks über Quellcoderepositorys zu verhindern.

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

• Sichern der Softwarelieferkette.

  • Ist es möglich, allgemeine Sicherheitsrisiken und Expositionen (CVEs) innerhalb von genutzten Paketabhängigkeiten nachzuverfolgen?
  • Gibt es einen automatisierten Prozess zum Aktualisieren von Paketabhängigkeiten?

• Lebenszyklus von Datenschutzschlüsseln.

  • Können vom Dienst verwaltete Schlüssel zum Schutz der Datenintegrität verwendet werden?
  • Wenn vom Kunden 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 die Ebene der Ebene für Azure-Ressourcenbereitstellungen für alle als Umgebungsabonnements betrachteten zu erleichtern.

  • Wenn Anwendungsressourcen in privaten Netzwerken gesperrt sind, gibt es einen privaten Konnektivitätspfad für datenebenen, sodass CI/CD-Tools Bereitstellungen und Wartungen auf Anwendungsebene ausfü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 in Produktionsabonnements Microsoft Entra Privileged Identity Management (PIM), um dauerhaften Zugriff auf Steuerungsebene auf Produktionsumgebungen zu widerrufen. Dadurch wird das Risiko durch zusätzliche "Prüfungen und Saldos" durch "böswillige Administratorszenarien" erheblich reduziert.

• Verwenden Sie Azure Managed Identities für alle Dienste, die die Funktion unterstützen, da sie das Entfernen von Anmeldeinformationen aus Dem Anwendungscode erleichtert und die operative Belastung der Identitätsverwaltung für die Dienst- und Dienstkommunikation entfernt.

• Verwenden Sie die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Microsoft Entra für die Autorisierung auf Datenebene mit allen Diensten, welche diese Funktionalität unterstützen.

• Verwenden Sie Microsoft Identity Platform-Authentifizierungsbibliotheken von Drittanbietern innerhalb des Anwendungscodes, um sie in Microsoft Entra ID zu integrieren.

• Erwägen Sie die zwischenspeicherung sicherer Token, um eine beeinträchtigte, aber verfügbare Erfahrung zu ermöglichen, wenn die ausgewählte Identitätsplattform nicht verfügbar ist oder nur teilweise für die Anwendungsautorisierung verfügbar ist.

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

• Verwenden Sie Infrastructure-as-Code (IaC) und automatisierte CI/CD-Pipelines, um Updates für alle Anwendungskomponenten zu steuern, einschließlich unter Ausfallbedingungen.

  • 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.
  • Ziehen Sie die Verwendung manueller Genehmigungsgates in Produktionsbereitstellungspipelines in Betracht, um "schädliche Administratorrisiken" weiter zu mindern und zusätzliche technische Sicherheit für alle Produktionsänderungen bereitzustellen.
    • Zusätzliche Sicherheitstore können in Bezug auf Agilität zu einem Kompromiss kommen und sollten sorgfältig bewertet werden, wobei berücksichtigt wird, wie Flexibilität auch bei manuellen Toren gehalten 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 Datenexfiltration, es sei denn, die gesetzlichen Anforderungen erfordern dies, da dies die Flexibilität der Entwickler erheblich beeinträchtigt.

• 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-Richtlinie, 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 sicherheitsrelevante Tests jede Version die betriebliche Flexibilität gefährden, stellen Sie sicher, dass eine geeignete Sicherheitstest-Kadenz angewendet wird.

• Aktivieren Sie geheime Überprüfung und Abhängigkeitsüberprüfung im Quellcode-Repository.

Threat Modeling

Die Bedrohungsmodellierung bietet einen risikobasierten Ansatz für das Sicherheitsdesign, wobei identifizierte potenzielle Bedrohungen verwendet werden, um geeignete Sicherheitsminderungen zu entwickeln. Es gibt viele mögliche Bedrohungen mit unterschiedlichen Wahrscheinlichkeiten des Auftretens, und in vielen Fällen können Bedrohungen auf unerwartete, unvorhersehbare und sogar chaotische Weise verkettet werden. Diese Komplexität und Unsicherheit ist, warum herkömmliche technologiebasierte 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 layered Defense-in-Depth-Ansatz angewendet werden, um Ausgleichsminderungen für modellierte Bedrohungen zu definieren und zu implementieren, wobei die folgenden defensiven Ebenen berücksichtigt werden.

1. Die Azure-Plattform mit grundlegenden Sicherheitsfunktionen und -steuerelementen.
2. Die Anwendungsarchitektur und das Sicherheitsdesign.
3. Sicherheitsfeatures, die integriert, aktiviert und bereitgestellt werden können, die auf sichere Azure-Ressourcen angewendet werden.
4. Anwendungscode und Sicherheitslogik.
5. Operative Prozesse und DevSecOps.

Überlegungen zum Entwurf

STRIDE bietet ein einfaches Risikoframework zur Bewertung von Sicherheitsbedrohungen über wichtige Bedrohungsvektoren hinweg.

• Gefälschte Identität: Identitätswechsel von Personen mit Autorität. Beispiel: Ein Angreifer, der einen anderen Benutzer imitiert, indem er seine -
  • Identität
  • Authentifizierung
• Manipulationseingabe: Änderung der an die Anwendung gesendeten Eingabe oder die Verletzung von Vertrauensgrenzen zum Ändern von Anwendungscode. Beispiel: Ein Angreifer, der SQL Injection verwendet, um Daten in einer Datenbanktabelle zu löschen.
  • Datenintegrität
  • Überprüfen
  • Blocklisting/Allowlisting
• Ablehnung der Aktion: Fähigkeit, bereits ausgeführte Maßnahmen zu widerlegen, und die Fähigkeit der Anwendung, Beweise zu sammeln und rechenschaftspflicht zu machen. Beispielsweise das Löschen kritischer Daten ohne die Möglichkeit, einen böswilligen Administrator zu verfolgen.
  • Überwachung/Protokollierung
  • signatur-
• Offenlegung von Informationen: Zugriff auf eingeschränkte Informationen erhalten. Ein Beispiel wäre ein Angreifer, der Zugriff auf eine eingeschränkte Datei erhält.
  • Verschlüsselung
  • Daten-Exfiltration
  • Man-in-the-Middle-Angriffe
• Denial of Service: Böswillige Anwendungsunterbrechungen, 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 erhalten. Beispiel: Ein Angreifer, der eine URL-Zeichenfolge manipuliert, um Zugriff auf vertrauliche Informationen zu erhalten.
  • Remoteausführung von Code
  • Autorisierung
  • Isolation

Entwurfsempfehlungen

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

• Bewusste Anstrengungen sollten angewendet werden, um sicherzustellen, dass Sicherheitsminderungen in einem gemeinsamen Technischen Kriterium erfasst werden, um die Konsistenz in allen Anwendungsdienstteams zu fördern.

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

Netzwerkangriffsschutz

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 sicherheitsverstößen Zustand aus und überprüft jede Anforderung so, als ob sie aus einem nicht kontrollierten Netzwerk stammt.

  • 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.
  • Virtuelle Netzwerkdienstendpunkte bieten Zugriff auf Dienstebene von ausgewählten Subnetzen auf ausgewählte PaaS-Dienste.
  • Virtual Network Injection stellt dedizierte private Bereitstellungen für unterstützte Dienste bereit, 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 mit Azure Private Endpoints Datenexfiltrationsrisiken, die mit Dienstendpunkten verbunden sind, z. B. ein böswilliger Administrator, der Daten in eine externe Ressource schreibt.

• Beim Einschränken des Netzwerkzugriffs auf Azure PaaS-Dienste mit privaten Endpunkten oder Dienstendpunkten ist ein sicherer Netzwerkkanal erforderlich, um sowohl auf die Azure-Kontrollebene als auch auf die Datenebene von Azure-Ressourcen zuzugreifen, um die Anwendung bereitzustellen und zu verwalten.

  • Private selbst gehostete Build-Agents , die in einem privaten Netzwerk bereitgestellt werden, da die Azure-Ressource als Proxy zum Ausführen von CI/CD-Funktionen über eine private Verbindung verwendet werden kann. Ein separates virtuelles Netzwerk sollte für Build-Agents verwendet werden.
    • Es ist eine Verbindung mit den privaten Build-Agents von CI/CD-Tools erforderlich.
  • Ein alternativer Ansatz besteht darin, die Firewallregeln für die Ressource direkt in der Pipeline zu ändern, um eine Verbindung von einer öffentlichen IP-Adresse eines Azure DevOps-Agents zuzulassen, wobei die Firewall nach Abschluss der Aufgabe anschließend entfernt wird.
    • Dieser Ansatz gilt jedoch nur für eine Teilmenge von Azure-Diensten. Dies ist beispielsweise für private AKS-Cluster nicht machbar.
  • Zum Ausführen von Entwickler- und Administrativen Aufgaben auf den Anwendungsdienst-Sprungfeldern kann verwendet werden.

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

• Dienstverbindungen mit einem entsprechenden Microsoft Entra-Dienstprinzipal können 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 erleichtern.

• 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 für die Anwendung erforderlich ist, um ihren Geschäftszweck zu erfüllen, um die externe Angriffsfläche zu reduzieren.

  • 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 den privaten Azure-Link geschützt sind.
    • Von Microsoft gehostete Agents können keine direkte Verbindung mit integrierten Netzwerkressourcen 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 virtuelle Azure-Computer zu ermöglichen und administrative Aufgaben in Azure PaaS über das Internet auszuführen.

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

• 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 Inline-Netzwerksicherheitsanforderungen, z. B. deep packet inspection oder TLS inspection, die Verwendung von Azure Firewall Premium oder Network Virtual Appliance (NVA) vorgeschrieben werden, stellen Sie sicher, dass sie für maximale Hohe Verfügbarkeit und Redundanz konfiguriert ist.

• Wenn Paketerfassungsanforderungen vorhanden sind, verwenden Sie Network Watcher-Pakete, um trotz des eingeschränkten Aufnahmefensters zu erfassen.

• Verwenden Sie Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen zum Mikrosegment-Anwendungsdatenverkehr.

  • Filtern Sie den Datenverkehr innerhalb einer Anwendung nicht mithilfe einer Sicherheitsappliance.
  • Erwägen Sie die Verwendung von Azure-Richtlinien zum Erzwingen bestimmter NSG-Regeln, die immer mit Anwendungssubnetzen verknüpft 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 private Endpunkte nicht verfügbar sind und Datenexfiltrationsrisiken akzeptabel sind, verwenden Sie Virtuelle Netzwerkdienstendpunkte, um den Zugriff auf Azure PaaS-Dienste innerhalb eines virtuellen Netzwerks 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.

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 zu schützen, ohne die Anwendungszuverlässigkeit zu beeinträchtigen.

Überlegungen zum Entwurf

• Azure Key Vault verfügt über Transaktionsbeschränkungen für Schlüssel und geheime Schlüssel, 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.
    • Granulare Berechtigungen auf Objektebene für einen bestimmten Schlüssel, geheimen Schlüssel oder Zertifikat sind jetzt möglich.

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

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

• Azure Key Vault zugrunde liegende Hardwaresicherheitsmodule (HSMs) verfügen über eine FIPS 140-Überprüfung.

  • Ein dediziertes vom Azure Key Vault verwaltetes HSM ist für Szenarien verfügbar, die FIPS 140-2 Level 3 Compliance erfordern.

• Azure Key Vault bietet hohe Verfügbarkeit und Redundanz, um die Verfügbarkeit zu gewährleisten und Datenverluste zu verhindern.

• Während eines Regionsfailovers kann es einige Minuten dauern, bis der Key Vault-Dienst fehlschlägt.

  • Während eines Failoverschlüsseltresors befindet sich im schreibgeschützten Modus, sodass es nicht möglich ist, Schlüsseltresoreigenschaften wie Firewallkonfigurationen und -einstellungen zu ändern.

• Wenn eine private Verknüpfung 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 erneut hergestellt wird.

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

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

• Mit dienstverwalteten Schlüsseln führt Azure Schlüsselverwaltungsfunktionen wie Drehung durch, wodurch der Umfang der Anwendungsvorgänge reduziert wird.

• Gesetzliche Kontrollen können die Verwendung von vom Kunden verwalteten Schlüsseln für die Dienstverschlüsselungsfunktion festlegen.

• Wenn der Datenverkehr zwischen Azure-Rechenzentren wechselt, wird die MACsec-Datenverknüpfungsebenenverschlüsselung auf der zugrunde liegenden Netzwerkhardware verwendet, um Daten außerhalb der physischen Grenzen zu sichern, die nicht von Microsoft oder im Auftrag von Microsoft gesteuert 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 vom Kunden verwaltete Schlüssel nur, wenn hierfür eine klare behördliche Anforderung erforderlich ist.

• Verwenden Sie Azure Key Vault als sicheres Repository für alle geheimen Schlüssel, Zertifikate und Schlüssel, wenn zusätzliche Verschlüsselungsmechanismen oder vom Kunden 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 hsM-gesicherte Azure Key Vault-SKU für Anwendungsproduktionsumgebungen.

• Stellen Sie eine separate Azure Key Vault-Instanz innerhalb jedes regionalen Bereitstellungsstempels bereit, und stellen Sie Fehlerisolation und Leistungsvorteile durch Lokalisierung bereit und navigieren Sie in den Skalierungsgrenzwerten, die von einer einzelnen Key Vault-Instanz auferlegt werden.

  • Verwenden Sie eine dedizierte Azure Key Vault-Instanz für globale Anwendungsressourcen.

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

• Stellen Sie sicher, dass Verschlüsselungsschlüssel und zertifikate, die im Key Vault gespeichert sind, gesichert werden, und stellen Sie eine Offlinekopie im unwahrscheinlichen Fall bereit, dass Key Vault nicht verfügbar ist.

• Verwenden Sie Key Vault-Zertifikate zum Verwalten der Zertifikatbeschaffung und -signatur.

• 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 Verwendung 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-Richtlinie bietet ein Framework zum Erzwingen von Sicherheits- und Zuverlässigkeitsgrundwerten, um sicherzustellen, dass die Einhaltung einer gängigen technischen Kriterien für eine unternehmenskritische Anwendung fortgesetzt wird. Genauer gesagt bildet Azure Policy einen wichtigen Bestandteil der Azure Resource Manager (ARM)-Kontrollebene, indem RBAC ergänzt wird, indem eingeschränkt wird, welche Aktionen autorisierte Benutzer ausführen können, und kann verwendet werden, um wichtige Sicherheits- und Zuverlässigkeitskonventionen in allen genutzten Plattformdiensten durchzusetzen.

In diesem Abschnitt werden daher wichtige Überlegungen und Empfehlungen zur Verwendung von azure Policy driven Governance für eine unternehmenskritische Anwendung untersucht, um sicherzustellen, dass Sicherheits- und Zuverlässigkeitskonventionen kontinuierlich durchgesetzt werden.

Überlegungen zum Entwurf

• Azure-Richtlinie bietet einen Mechanismus, um die Compliance zu fördern, indem Sicherheits- und Zuverlässigkeitskonventionen erzwungen werden, z. B. die Verwendung privater Endpunkte oder die Verwendung von Verfügbarkeitszonen.

• Azure-Richtlinie kann verwendet werden, um automatisierte Verwaltungsaktivitäten wie Bereitstellung und Konfiguration voranzutreiben.

  • Registrierung des Ressourcenanbieters.
  • Überprüfung und Genehmigung einzelner Azure-Ressourcenkonfigurationen.

• Der Azure-Richtlinienzuweisungsbereich bestimmt die Abdeckung, und der Speicherort von Azure-Richtliniendefinitionen informiert die Wiederverwendbarkeit von benutzerdefinierten Richtlinien.

• Azure Policy hat mehrere Grenzwerte, z. B. die Anzahl der Definitionen in einem bestimmten Bereich.

• Es kann mehrere Minuten dauern, bis die Bereitstellungsrichtlinien (If Not Exist, DINE) ausgeführt werden.

• 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-Richtlinienzuweisungen zugeordnet sind, um compliance zu erzwingen.

  • Wenden Sie beispielsweise eine Azure-Richtlinie an, um die Verwendung von Verfügbarkeitszonen für alle relevanten Dienste zu erzwingen, um zuverlässige Konfigurationen für die Bereitstellung innerhalb der Region sicherzustellen.

Die Mission Critical-Referenzimplementierung enthält eine Vielzahl von Sicherheits- und Zuverlässigkeitsrichtlinien, um ein Beispiel für allgemeine technische Kriterien zu definieren und zu erzwingen.

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

Bei unternehmenskritischen Szenarien mit mehreren Produktionsabonnements unter einer dedizierten Verwaltungsgruppe priorisieren Sie Zuordnungen 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 auf geeignetem Verwaltungsgruppenbereich bereitgestellt werden, um die Wiederverwendung in allen eingeschlossenen Umgebungsabonnements zu ermöglichen, um die Wiederverwendung von Richtlinien in produktions- und niedrigeren Umgebungen zu ermöglichen.

  • Verwenden Sie beim Ausrichten der Anwendungsroadmaps mit azure-Roadmaps verfügbare Microsoft-Ressourcen, um zu untersuchen, ob wichtige benutzerdefinierte Definitionen als integrierte Definitionen integriert werden könnten.

• Verwenden Sie Azure-Richtlinie, 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 microsoft Mission-Critical Support abonniert hat, stellen Sie sicher, dass das angewendete Taggingschema einen aussagekräftigen Kontext bietet, um die Supporterfahrung mit tiefem 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 innerhalb des globalen Speicherkontos archiviert werden, zusammen mit Betriebsdaten für die langfristige Aufbewahrung.

In einer Azure-Zielzone werden auch Microsoft Entra-Aktivitätsprotokolle in den zentralen Log Analytics-Arbeitsbereich der zentralen Plattform aufgenommen. Es muss in diesem Fall ausgewertet werden, wenn microsoft Entra-ID noch im globalen Log Analytics-Arbeitsbereich erforderlich ist.

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

IaaS-spezifische Überlegungen bei der Verwendung virtueller Computer

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

Überlegungen zum Entwurf

• Bilder werden nach der Bereitstellung nicht automatisch aktualisiert.
• Updates werden nicht automatisch installiert, um VMs auszuführen.
• Bilder und einzelne VMs werden in der Regel nicht sofort ausgehärtet.

Entwurfsempfehlungen

• Lassen Sie keinen direkten Zugriff über das öffentliche Internet auf virtuelle Computer zu, indem Sie Zugriff auf SSH, RDP oder andere Protokolle gewähren. Verwenden Sie Immer Azure Bastion und Jumpboxes mit eingeschränktem Zugriff auf eine kleine Gruppe von Benutzern.
• Beschränken Sie die direkte Internetverbindung mithilfe von Netzwerksicherheitsgruppen, (Azure)-Firewall oder Anwendungsgateways (Ebene 7), um Datenverkehr zu filtern und einzuschränken.
• Bei mehrstufigen Anwendungen sollten Sie verschiedene Subnetze verwenden und Netzwerksicherheitsgruppen verwenden, um den Zugriff zwischeneinander einzuschränken.
• Priorisieren Sie nach Möglichkeit die Verwendung der Public Key-Authentifizierung. Speichern Sie geheime Schlüssel an einem sicheren Ort wie Azure Key Vault.
• Schützen Sie virtuelle Computer mithilfe von Authentifizierung und Zugriffssteuerung.
• Wenden Sie dieselben Sicherheitspraktiken an, wie für unternehmenskritische Anwendungsszenarien beschrieben.

Befolgen und anwenden Sie Sicherheitspraktiken für unternehmenskritische Anwendungsszenarien, wie oben beschrieben, falls zutreffend, sowie die bewährten Methoden für Die Sicherheit für IaaS-Workloads in Azure.

Nächster Schritt

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