Bearbeiten

Freigeben über

Sicherheitsüberlegungen zu hochgradig sensiblen IaaS-Apps in Azure

Azure Disk Encryption
Azure Firewall
Azure-Schlüsseltresor
Microsoft Defender für Cloud
Azure Virtual Network

Es gibt eine Vielzahl von Sicherheitsüberlegungen im Zusammenhang mit der Bereitstellung von Infrastructure-as-a-Service (IaaS) -Apps in Azure. Dieser Artikel baut auf Referenzarchitekturen für VM-basierte Workloads und Hybridnetzwerkinfrastrukturen auf; der Schwerpunkt liegt auf der Sicherheit für höchst sensible IaaS-Workloads in Azure, basierend auf Grundlagen der Azure-Sicherheit.

Siehe auch Virtuelle Azure-Computer – Sicherheitsübersicht und Bewährte Sicherheitsmethoden für IaaS-Workloads in Azure.

Virtuelle Azure-Computer

Die Computeplattform von Azure basiert auf der Virtualisierung von Computern. Ein Hypervisor wird auf der physischen Hardware jedes Azure-Knotens bzw. Netzwerkendpunkts ausgeführt. Er erstellt eine variable Anzahl von Hyper-V-Gast-VMs (virtuellen Computern) im Knoten. Der gesamte Benutzercode wird auf den VMs ausgeführt. Grundlegende Anweisungen zum Bereitstellen von Azure-VMs finden Sie unter Ausführen eines virtuellen Linux-Computers in Azure und Ausführen eines virtuellen Windows-Computers in Azure. Die meisten Bereitstellungsprozesse sind für die beiden Betriebssysteme identisch, betriebssystemspezifische Tools wie die Datenträgerverschlüsselung können sich jedoch unterscheiden.

Sie können Microsoft Defender für Cloud für die VM-Patchverwaltung und zum Bereitstellen und Überwachen von Antischadsoftwaretools verwenden. Alternativ dazu können Sie auch eigene Patch- und Antischadsoftware-Tools oder Tools von Drittanbietern verwalten. Dies kommt beim Erweitern oder Migrieren vorhandener Infrastrukturen zu Azure häufig vor.

Microsoft bietet im Rahmen der Azure-Plattform grundlegenden verteilten Denial-of-Service (DDoS) -Schutz. In Apps mit öffentlichen Endpunkten kann Standard-Azure DDoS Protection für zusätzlichen Schutz verwendet werden. Allerdings verfügen höchst sensible Workloads in der Regel über keine öffentlichen Endpunkte, und es kann nur von bestimmten Standorten aus über ein virtuelles privates Netzwerk (VPN) oder über geleaste Verbindungen darauf zugegriffen werden.

n-schichtige Architekturen

Viele IaaS-Anwendungen bestehen aus mehreren Schichten, wie z. B. einer Webschicht, einer Unternehmensschicht und einer Datenschicht, die auf mehreren VMs gehostet werden. Wichtige Aspekte der Bereitstellung von n-schichtigen App-Architekturen auf Azure-VMs:

  • Hochverfügbarkeit (HA). Apps mit Hochverfügbarkeit müssen über 99,9 % der Zeit verfügbar sein. Durch das Platzieren von n-schichtigen VMs in verschiedenen Azure-Verfügbarkeitszonen wird Hochverfügbarkeit sichergestellt, da Verfügbarkeitszonen ein oder mehrere Rechenzentren abdecken und Resilienz aufgrund der Abwehr des Ausfalls von Rechenzentren gegeben ist. Regionen, die keine Verfügbarkeitszonen unterstützen, können Verfügbarkeitsgruppen verwenden, die VMs auf mehrere isolierte Hardwareknoten verteilen.
  • Lastenausgleich: Lastenausgleichsmodule verteilen den Datenverkehr auf VMs, um einen Lastenausgleich vorzunehmen und die Resilienz bei Ausfall einer VM sicherzustellen. Sie benötigen keine Lastenausgleichsmodule, wenn die Anwendung den Lastenausgleich verwaltet und dem Aufrufer die einzelnen VMs bekannt sind.
  • Virtuelle Netzwerke. Virtuelle Netzwerke und Subnetze segmentieren Ihr Netzwerk, wodurch die Sicherheitsverwaltung vereinfacht und erweitertes Routing ermöglicht wird.
  • Domain Name System (DNS) . Mit Azure DNS wird ein hoch verfügbarer und sicherer DNS-Dienst bereitgestellt. Mit einer privaten Zone in Azure DNS können Sie benutzerdefinierte Domänen in Ihren virtuellen Netzwerken verwenden.

Sichern und Wiederherstellen

Zum Schutz vor menschlichen Fehlern, dem bösartigen Löschen von Daten und Ransomware sollten Sie mindestens Ihre VMs der Datenschicht sichern. Mit Azure Backup können Sie verschlüsselte VMs sichern und wiederherstellen, wenn der Zugriff auf die Verschlüsselungsschlüssel in Azure Key Vault gegeben ist.

In der Webschicht und der Unternehmensschicht können Sie Autoskalierungsregeln für VM-Skalierungsgruppen verwenden, um gefährdete VMs automatisch zu vernichten und komplett neue VM-Instanzen aus einem Basisimage bereitzustellen.

Computeisolation

Auf jedem Azure-Knoten oder Netzwerkendpunkt stellen der Hypervisor und ein spezielles Stammbetriebssystem sicher, dass Gast-VMs nicht auf den physischen Hostserver zugreifen können und dass der Benutzercode nur auf Gast-VMs ausgeführt wird. Durch diese Isolation wird verhindert, dass Benutzer RAW-Zugriff zum Lesen, Schreiben und Ausführen auf das System erhalten, und das Risiko der gemeinsamen Verwendung von Ressourcen wird gemindert. Azure schützt über den Hypervisor und einen erweiterten Algorithmus zur VM-Platzierung gegen alle bekannten Seitenkanalangriffe und Noisy Neighbors (Beeinträchtigung durch andere Dienste). Weitere Informationen finden Sie unter Computeisolation.

Bei hochgradig sensiblen Workloads können Sie mit isolierten VMs oder dedizierten Hosts zusätzlichen Schutz vor Seitenkanalangriffen hinzufügen.

Isolierte VMs

Isolierte VMs sind große VMs, die für einen bestimmten Hardwaretyp isoliert und für einen einzelnen Kunden bestimmt sind. Durch die Verwendung einer großen isolierten VM wird sichergestellt, dass Ihr virtueller Computer in der jeweiligen Serverinstanz als einziger ausgeführt wird. Sie können die Ressourcen dieser isolierten virtuellen Computer weiter unterteilen, indem sie die Azure-Unterstützung für geschachtelte virtuelle Computer verwenden.

Die Mindestgröße einer isolierten VM beläuft sich auf 64 virtuelle CPU-Kerne und 256 GiB Arbeitsspeicher. Diese VMs sind weitaus größer als die meisten n-schichtigen Anwendungen erfordern, und daher können Sie große Kosten verursachen. Um den Mehraufwand an Kosten zu mindern, können Sie mehrere App-Ebenen auf einem einzigen virtuellen Computer mit einer geschachtelten Virtualisierung oder in unterschiedlichen Prozessen oder Containern ausführen. Für die Resilienz müssen Sie dennoch verschiedene VMs in Verfügbarkeitszonen bereitstellen und Appliances für eine demilitarisierte Zone (DMZ) auf separaten VMs ausführen. Das Kombinieren mehrerer Apps in einer Infrastruktur aus wirtschaftlichen Gründen kann auch den Richtlinien für die Abgrenzung von Apps widersprechen.

Da die Azure-Funktionen für Regionen mit der Zeit ausgeweitet werden, kann Azure auch Isolationsgarantien für bestimmte VM-Größen aufheben; dies wird mit einem Vorlauf von einem Jahr angekündigt.

Dedizierte Azure-Hosts

Azure Dedicated Host ist die bevorzugte Lösung für Computeisolation in Bezug auf höchst sensible Workloads. Ein dedizierter Host ist ein physischer Server, der für einen Kunden zum Hosten mehrerer VMs reserviert ist. Neben dem Isolieren von VMs können Sie mit dedizierten Hosts die Wartung und VM-Platzierung steuern, um die Beeinträchtigung durch andere Dienste zu vermeiden.

Dedizierte Hosts

Für dedizierte Hosts gelten dieselbe Mindestgröße und auch viele Überlegungen zum Festlegen der Größe wie für isolierte VMS. Ein dedizierter Host kann jedoch VMs hosten, die sich in verschiedenen virtuellen Netzwerken befinden, sodass Richtlinien zur Abgrenzung von Anwendungen eingehalten werden. Sie sollten DMZ-VMs weiterhin auf einem anderen Host ausführen, um Seitenkanalangriff von einer gefährdeten VM in der DMZ zu verhindern.

Verschlüsselung

Die Datenverschlüsselung ist ein wichtiger Aspekt der Sicherung von Workloads. Bei der Verschlüsselung werden Informationen codiert, sodass sie nur von autorisierten Empfängern mit einem Schlüssel oder Zertifikat decodiert werden können. Die Verschlüsselung umfasst die Datenträgerverschlüsselung für die Verschlüsselung ruhender Daten und Transport Layer Security (TLS) für die Verschlüsselung von Daten während der Übertragung über Netzwerke.

Azure-Schlüsseltresor

Sie können Verschlüsselungsschlüssel und Zertifikate schützen, indem Sie sie in Azure Key Vault, einer HSM-Cloudlösung (Hardwaresicherheitsmodul) speichern, die für Federal Information Processing Standards (FIPS) 140-2 Level 2 validiert wurde. Informationen zu bewährten Methoden, bei denen nur autorisierten Anwendungen und Benutzern Zugriff auf Key Vault gewährt wird, finden Sie unter Sicherer Zugriff auf einen Schlüsseltresor.

Zum Schutz von Schlüsseln in Key Vault können Sie das vorläufige Löschen aktivieren. Dadurch wird sichergestellt, dass gelöschte Schlüssel wiederhergestellt werden können. Zusätzlichen Schutz erhalten Sie, indem Sie einzelne Schlüssel in einer verschlüsselten Datei sichern, mit der Sie die Schlüssel wiederherstellen können, möglicherweise in einer anderen Azure-Region in derselben Geografie.

Wird SQL Server auf einer VM gehostet, können Sie mit dem SQL Server-Connector für Microsoft Azure Key Vault Schlüssel für Transparent Data Encryption (TDE) , Verschlüsselung auf Spaltenebene und Sicherungsverschlüsselung abrufen. Einzelheiten hierzu finden Sie unter Konfigurieren der Azure Key Vault-Integration für SQL Server auf virtuellen Azure-Computern.

Azure Disk Encryption

Azure Disk Encryption verwendet die externe Schlüsselschutzvorrichtung BitLocker, um Volumeverschlüsselung für das Betriebssystem und die Datenträger von Azure-VMs bereitzustellen. Azure Disk Encryption kann in Azure Key Vault integriert werden, damit Sie die Verschlüsselungsschlüssel und Geheimnisse für Datenträger besser steuern und verwalten können. Jede VM generiert eigene Verschlüsselungsschlüssel und speichert sie in Azure Key Vault. Informationen zum Konfigurieren von Azure Key Vault für die Aktivierung von Azure Disk Encryption finden Sie unter Erstellen und Konfigurieren eines Schlüsseltresors für Azure Disk Encryption.

Bei höchst sensiblen Workloads sollten Sie außerdem einen Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) als zusätzliche Sicherheitsebene verwenden. Wenn ein KEK angegeben wird, verwendet Azure Disk Encryption diesen Schlüssel, um Verschlüsselungsgeheimnisse vor dem Schreiben in Key Vault zu umschließen. Sie können einen KEK in Azure Key Vault generieren. Sicherer ist es jedoch, einen Schlüssel im lokalen HSM zu generieren und ihn in Azure Key Vault zu importieren. Dieses Szenario wird häufig als Bring Your Own Key (BYOK) bezeichnet. Da die importierten Schlüssel die HSM-Grenze nicht überschreiten können, wird durch das Generieren des Schlüssels in Ihrem HSM sichergestellt, dass Sie die vollständige Kontrolle über die Verschlüsselungsschlüssel haben.

Durch HSM geschützte Verschlüsselung

Weitere Informationen zu durch HSM geschützten Schlüsseln finden Sie unter Generieren und Übertragen von HSM-geschützten Schlüsseln für Azure Key Vault.

Verschlüsselung von Netzwerkdatenverkehr

Netzwerkprotokolle wie HTTPS verschlüsseln Daten während der Übertragung mit Zertifikaten. Für den Datenverkehr vom Client zur Anwendung wird normalerweise ein Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle verwendet. Interne Apps können ein Zertifikat von einer internen Zertifizierungsstelle oder einer öffentlichen Zertifizierungsstelle wie DigiCert oder GlobalSign verwenden. Bei der Kommunikation zwischen Schichten wird im Allgemeinen ein von einer internen Zertifizierungsstelle ausgestelltes Zertifikat oder ein selbstsigniertes Zertifikat verwendet. Azure Key Vault akzeptiert alle diese Zertifikattypen. Weitere Informationen zum Erstellen verschiedener Zertifikattypen finden Sie unter Methoden für die Zertifikaterstellung.

Azure Key Vault kann als Zertifizierungsstelle für selbstsignierte Zertifikate für den Datenverkehr zwischen Schichten fungieren. Die Key Vault-VM-Erweiterung ermöglicht das Überwachen und automatische Aktualisieren bestimmter Zertifikate auf VMs, je nach Anwendungsfall mit dem oder ohne den privaten Schlüssel. Informationen zum Verwenden der Key Vault-VM-Erweiterung finden Sie unter Key Vault-VM-Erweiterung für Linux und Key Vault-VM-Erweiterung für Windows.

Key Vault kann auch Schlüssel für Netzwerkprotokolle speichern, in denen keine Zertifikate verwendet werden. Benutzerdefinierte Workloads können das Schreiben einer benutzerdefinierten Skripterweiterung erfordern, die einen Schlüssel aus Key Vault abruft und ihn für die Verwendung durch Anwendung speichert. Apps können auch mit der verwalteten Identität einer VM Geheimnisse direkt aus Key Vault abrufen.

Netzwerksicherheit

Netzwerksicherheitsgruppen (NSGs) filtern den Datenverkehr zwischen Ressourcen in virtuellen Azure-Netzwerken. NSG-Sicherheitsregeln erlauben oder verweigern den Netzwerkdatenverkehr zu oder von Azure-Ressourcen basierend auf IP-Adressen und Ports. In der Standardeinstellung blockieren NSGs eingehenden Datenverkehr aus dem Internet, lassen jedoch ausgehende Verbindungen von VMS in das Internet zu. Um unbeabsichtigten ausgehenden Datenverkehr zu verhindern, fügen Sie eine benutzerdefinierte Regel mit der kleinstmöglichen Priorität 4096 hinzu, um den gesamten eingehenden und ausgehenden Datenverkehr zu blockieren. Anschließend können Sie Regeln mit höherer Priorität hinzufügen, um bestimmten Datenverkehr zuzulassen.

NSGs erstellen Flusseinträge für vorhandene Verbindungen und erlauben oder verweigern die Kommunikation je nach dem Verbindungsstatus des Flusseintrags. Durch einen Flusseintrag kann eine NSG zustandsbehaftet sein. Wenn Sie beispielsweise eine Sicherheitsregel für Datenverkehr in ausgehender Richtung an eine beliebige Adresse über Port 443 angeben, ist es nicht erforderlich, für die Antwort eine Eingangssicherheitsregel anzugeben. Sie müssen nur dann eine Eingangssicherheitsregel angeben, wenn die Kommunikation extern initiiert wird.

Die meisten Azure-Dienste ermöglichen es Ihnen, ein Diensttag für virtuelle Netzwerke anstelle einer NSG zu verwenden. Ein Diensttag stellt eine Gruppe von IP-Adresspräfixen eines Azure-Diensts dar und trägt dazu bei, die Komplexität häufiger Aktualisierungen der Netzwerksicherheitsregel zu minimieren. Mithilfe eines Azure Key Vault-Diensttags kann ein virtueller Computer Zertifikate, Schlüssel und Geheimnisse aus Azure Key Vault abrufen.

Eine weitere Möglichkeit zum Steuern der Netzwerksicherheit besteht im Routing von Datenverkehr für virtuelle Netzwerke und der Tunnelerzwingung. Azure erstellt automatisch Systemrouten und weist die Routen allen Subnetzen eines virtuellen Netzwerks zu. Sie können zwar keine Systemrouten erstellen oder entfernen, aber einige Systemrouten mit benutzerdefinierten Routen überschreiben. Mit benutzerdefiniertem Routing können Sie Datenverkehr über ein virtuelles Netzwerkgerät (Network Virtual Appliance, NVA) wie eine Firewall oder einen Proxy weiterleiten oder unerwünschten Datenverkehr löschen; dies hat den gleichen Effekt wie das Blockieren des Datenverkehrs mit einer Netzwerksicherheitsgruppe.

Sie können NVAs wie Azure Firewall verwenden, um Netzwerkdatenverkehr zuzulassen, zu blockieren oder zu untersuchen. Azure Firewall ist ein verwalteter Plattform-Firewalldienst mit Hochverfügbarkeit. Sie können auch NVAs von Drittanbietern aus dem Azure Marketplace bereitstellen. Informationen dazu, wie Sie die Hochverfügbarkeit dieser NVAs sicherstellen, finden Sie unter Bereitstellen hochverfügbarer virtueller Netzwerkgeräte.

Anwendungssicherheitsgruppen

Zum Filtern von Datenverkehr zwischen Anwendungsschichten innerhalb eines virtuellen Netzwerks verwenden Sie Anwendungssicherheitsgruppen (ASGs). Mit ASGs können Sie die Netzwerksicherheit als Erweiterung einer Anwendungsstruktur konfigurieren und VMs gruppieren sowie auf Grundlage dieser Gruppen Netzwerksicherheitsrichtlinien definieren. Sie können Ihre Sicherheitsrichtlinie nach Bedarf wiederverwenden, ohne dass Sie explizite IP-Adressen manuell pflegen müssen.

Anwendungssicherheitsgruppen

Da ASGs auf eine Netzwerkschnittstelle und nicht auf ein Subnetz angewendet werden, ermöglichen sie die Mikrosegmentierung. Sie können genau steuern, welche VMs miteinander kommunizieren können und sogar den Datenverkehr zwischen VMs in derselben Schicht blockieren. Dies erleichtert es, eine VM in die Quarantäne zu verschieben, indem Sie ASGs von der betreffenden VM entfernen.

Hybridnetzwerke

Hybridarchitekturen verbinden lokale Netzwerke mit öffentlichen Clouds wie Azure. Es gibt mehrere Möglichkeiten, lokale Netzwerke mit in Azure ausgeführten Anwendungen zu verbinden:

  • Öffentlicher Endpunkt über das Internet. Sie können sich auf Identitäten, Transport Level Security (HTTPS) und das Anwendungsgateway stützen, um die Anwendung zu schützen, möglicherweise in Verbindung mit einer Firewall. Bei höchst sensiblen Workloads wird jedoch davon abgeraten, einen öffentlichen Endpunkt über das Internet verfügbar zu machen.
  • Azure oder VPN-Gateway eines Drittanbieters. Sie können ein lokales Netzwerk über ein Azure-VPN-Gateway mit Azure verbinden. Der Datenverkehr wird weiterhin über das Internet übertragen, jedoch über einen verschlüsselten Tunnel, der TLS verwendet. Sie können ein Gateway eines Drittanbieters auch auf einer VM ausführen, wenn bestimmte Anforderungen vom Azure-VPN-Gateway nicht unterstützt werden.
  • ExpressRoute: ExpressRoute-Verbindungen nutzen eine dedizierte private Verbindung über einen Drittanbieter für die Konnektivität. Die private Verbindung erweitert das lokale Netzwerk auf Azure und bietet Skalierbarkeit sowie eine zuverlässige Vereinbarung zum Service Level (SLA).
    • ExpressRoute mit VPN-Failover. Diese Option verwendet unter normalen Bedingungen ExpressRoute, aber im Fall eines Konnektivitätsverlusts in der ExpressRoute-Leitung erfolgt ein Failover auf eine VPN-Verbindung.
    • VPN über ExpressRoute. Diese Option ist am besten für höchst sensible Workloads geeignet. Expressroute bietet eine private Leitung mit Skalierbarkeit und Zuverlässigkeit, und VPN stellt eine zusätzliche Schutzebene dar, welche die verschlüsselte Verbindung in einem bestimmten virtuellen Azure-Netzwerk abschließt.

Weitere Empfehlungen zur Entscheidung zwischen den verschiedenen Typen von Hybridkonnektivität finden Sie unter Auswählen einer Lösung zum Herstellen einer Verbindung zwischen einem lokalen Netzwerk und Azure.

Bereitstellen einer DMZ

Das Herstellen einer Verbindung zwischen einer lokalen Umgebung und Azure eröffnet lokalen Benutzern den Zugriff auf Azure-Anwendungen. Ein Umkreisnetzwerk oder eine demilitarisierte Zone (DMZ) bietet zusätzlichen Schutz für höchst sensible Workloads.

Bei einer Architektur wie der in Netzwerk-DMZ zwischen Azure und einem lokalen Rechenzentrum beschriebenen werden alle DMZ- und Anwendungsdienste im selben virtuellen Netzwerk bereitgestellt, mit NSG-Regeln und benutzerdefinierten Routen zum Isolieren der DMZ und der Anwendungssubnetze. Mit dieser Architektur kann das Verwaltungssubnetz über das öffentliche Internet für die Verwaltung von Apps zugänglich gemacht werden, selbst wenn das lokale Gateway nicht verfügbar ist. Bei höchst sensiblen Workloads sollten Sie das Umgehen des Gateways jedoch nur in einem Break Glass-Szenario (Notfallzugriff) gestatten. Eine bessere Lösung besteht in der Verwendung von Azure Bastion. Hier wird der Zugriff direkt aus dem Azure-Portal ermöglicht, wobei die Offenlegung öffentlicher IP-Adressen beschränkt wird.

Sie können auch den JIT-VM-Zugriff (Just-In-Time) für die Remoteverwaltung nutzen und die Offenlegung öffentlicher IP-Adressen beschränken. Mit JIT-VM-Zugriff blockiert eine NSG standardmäßig Ports für die Remoteverwaltung wie RDP (Remote Desktop Protocol) und SSH (Secure Shell) . Auf Anforderung aktiviert der JIT-VM-Zugriff den Port für einen bestimmten Zeitraum und möglicherweise nur für eine bestimmte IP-Adresse oder einen bestimmten IP-Adressbereich. Der JIT-Zugriff funktioniert auch für VMs, die ausschließlich private IP-Adressen verfügen. Sie können den Datenverkehr zu einer VM mit Azure Bastion blockieren, bis der JIT-VM-Zugriff aktiviert wird.

Zum Bereitstellen weiterer Anwendungen können Sie eine Hub-Spoke-Netzwerktopologie in Azure verwenden, wobei sich die DMZ im virtuellen Hub-Netzwerk befindet, während sich die Anwendungen in den virtuellen Spoke-Netzwerken befinden. Das virtuelle Hub-Netzwerk kann ein VPN- und/oder ExpressRoute-Gateway, eine Firewall-NVA, Verwaltungshosts, eine Identitätsinfrastruktur und andere gemeinsame Dienste einschließen. Die virtuellen Netzwerke werden über Peering virtueller Netzwerke mit dem Hub verbunden. Ein virtuelles Azure-Netzwerk lässt kein transitives Routing zwischen Spokes über den Hub zu. Der Datenverkehr zwischen Spokes ist nur über die Firewall-Appliances im Hub möglich. Durch diese Architektur werden Anwendungen effektiv voneinander isoliert.

Bereitstellung in mehreren Regionen

Für Geschäftskontinuität und Notfallwiederherstellung muss Ihre Anwendung möglicherweise in mehreren Azure-Regionen bereitgestellt werden, wodurch Datenresidenz und Datensicherheit beeinträchtigt werden.

Regionspaare

Bei einem Azure-Gebiet handelt es sich um einen definierten Bereich der Erde, der mindestens eine Azure-Region mit einem oder mehreren Rechenzentren enthält. Jede Azure-Region ist mit einer anderen Region innerhalb desselben geografischen Gebiets in einem Regionspaar gepaart. Regionen in Regionspaaren werden nicht gleichzeitig aktualisiert, und wenn eine Katastrophe beiden Regionen auftritt, wird eine der Regionen mit Priorität zuerst wieder online geschaltet. Für die Geschäftskontinuität sollten Sie höchst sensible Apps bei der Bereitstellung in mehreren Regionen mindestens in Regionspaaren bereitstellen.

Weitere Einzelheiten hierzu finden Sie unter Geschäftskontinuität und Notfallwiederherstellung: Azure-Regionspaare. Im Whitepaper Sicherheit und Compliance bei der Speicherung von Benutzerdaten mit Azure werden die Datenresidenz und zu erfüllende Anforderungen hinsichtlich der Datenresidenz erläutert.

Replikation zwischen Regionen

In IaaS-Architekturen ist die Anwendung für das Replizieren der Daten zwischen Regionen zuständig. Im gängigsten Replikationsszenario werden in das Datenbankserverprodukt integrierte Datenbank-Replikationstechnologien verwendet, z. B. SQL Server-AlwaysOn-Verfügbarkeitsgruppen, Oracle Data Guard, oder MySQL-Replikation.

Das Einrichten der Replikation zwischen IaaS-Datenbankservern ist kompliziert, und Sie müssen Anforderungen der Geschäftskontinuität berücksichtigen. Azure-Datenbankdienste wie Azure SQL-Datenbank, Azure Database for MySQL und Azure Cosmos DB vereinfachen die regionsübergreifende Replikation, erfüllen jedoch u. U. nicht die Sicherheitsanforderungen für hochgradig sensible Workloads.

Weitere Informationen und Anleitungen zu SQL Server- und Oracle-Bereitstellungen in mehreren Regionen finden Sie in folgenden Artikeln:

Regionsübergreifendes Peering

Sie können die sichere Kommunikation zwischen virtuellen Netzwerken in verschiedenen Regionen durch das globale Peering virtueller Netzwerke ermöglichen. Das globale Peering funktioniert genauso wie das Peering innerhalb einer Region. Der Datenverkehr zwischen Regionen wird über den Microsoft-Backbone ausgeführt, er durchläuft nicht das Internet und ist von anderem Datenverkehr isoliert. Eine höhere Sicherheit erzielen Sie, wenn Sie VPN-NVAs in beiden Regionen bereitstellen und benutzerdefinierte Routen verwenden, um den Datenverkehr zwischen Regionen über die NVAs zu erzwingen, ähnlich wie beim Bereitstellen einer DMZ.

Routing für Failoverdatenverkehr

Mit öffentlichen Endpunkten können Sie Traffic Manager oder Azure Front Door verwenden, um Datenverkehr an die aktive Region oder die nächstgelegene Region in einer Aktiv/Aktiv-Failoverkonfiguration weiterzuleiten. Allerdings erfordern sowohl Traffic Manager als auch Azure Front Door zum Überwachen der Verfügbarkeit öffentliche Endpunkte, und deren entsprechende DNS-Einträge sind öffentlich. Bei höchst sensiblen Workloads besteht eine alternative Lösung darin, DNS lokal bereitzustellen und die Einträge für das Failover in die aktive Region zu ändern.

Verwaltung und Governance

Das Sichern Ihrer höchst sensiblen IaaS-Apps erfordert mehr als lediglich das Bereitstellen der richtigen Architekturen und das Implementieren von Netzwerksicherheitsregeln. Da Cloudumgebungen leicht geändert werden können, muss unbedingt sichergestellt werden, dass Änderungen nur mit bestimmten Berechtigungen und innerhalb der Vorgaben der Sicherheitsrichtlinien vorgenommen werden können. Sie müssen beispielsweise verhindern, dass böswillige Akteure eine Netzwerksicherheitsregel ändern können, um Datenverkehr aus dem Internet zuzulassen.

Zum Bereitstellen von Workloads in Azure benötigen Sie mindestens ein Verwaltungskonto. Das Sichern von Verwaltungskonten ist unerlässlich, um Ihre Workloads zu schützen. Weitere Informationen finden Sie unter Schützen des privilegierten Zugriffs für hybride Bereitstellungen und Cloudbereitstellungen in Microsoft Entra ID.

Verwenden Sie die Ressourcen in Ihrem Verwaltungssubnetz, um den Zugriff auf die App-Ebene nur Personen zu gewähren, die diese Schicht verwalten müssen. Sie können z. B. Microsoft Identity Manager mit Microsoft Entra ID verwenden. Bei cloudnativen Szenarios ist jedoch Microsoft Entra Privileged Identity Management (PIM) zu bevorzugen.

Es gibt eine Reihe weiterer Möglichkeiten zum Steuern von Azure-Rollen und -Richtlinien:

  • Mit der rollenbasierten Zugriffssteuerung in Azure (Azure RBAC) für Azure-Ressourcen können Sie Benutzern integrierte oder benutzerdefinierte Rollen zuweisen, sodass sie nur über die tatsächlich erforderlichen Berechtigungen verfügen. Sie können Azure RBAC mit PIM kombinieren, um einen überwachten Genehmigungsworkflow zu implementieren, der Berechtigungen für einen begrenzten Zeitraum heraufstuft.
  • Richtlinien erzwingen Unternehmensregeln, Standards und SLAs. Azure Policy ist ein Azure-Dienst, der Richtlinien erstellt, zuweist und verwaltet und die Konformität Ihrer Ressourcen in Bezug auf die Richtlinie bewertet.
  • In Azure Blueprints werden Rollenzuweisungen, Richtlinienzuweisungen und Bereitstellungsvorlagen kombiniert, um eine Gruppe von replizierbaren Azure-Ressourcen zu definieren, welche die Standards, Muster und Anforderungen einer Organisation implementieren und für deren Einhaltung sorgen. Blaupausen sind eine deklarative Möglichkeit zum Orchestrieren der Bereitstellung von Ressourcenvorlagen und anderen Artefakten. Sie können selbst Blaupausen erstellen oder vorhandene Blaupausen nutzen. Die Blaupause ISO 27001: Gemeinsame Dienste stellt beispielsweise einen Hub für gemeinsame Dienste bereit, den Sie entsprechend den Anforderungen Ihrer Organisation ändern und ergänzen können.

Überwachung

Microsoft Defender für Cloud bietet Überwachung und Warnungen, mit deren Hilfe Sie die Sicherheit Ihrer Umgebung gewährleisten können. Der kostenlose Dienst sucht automatisch nach Sicherheitsrisiken, z. B. nach fehlenden Betriebssystempatches, Sicherheitsfehlkonfiguration und Mängeln der grundlegenden Netzwerksicherheit. Mit der kostenpflichtigen Standardversion erhalten Sie zusätzliche Features wie Verhaltensanalyse, Adaptives Erhöhen des Netzwerkschutzes und JIT-VM-Zugriff. Eine vollständige Liste der Features finden Sie unter Funktionsabdeckung für Computer. Defender für Cloud bietet außerdem Bedrohungsschutz für andere Ressourcen wie Azure Key Vault.

Sie können Azure Monitor für die weiterführende Überwachung und Analyse verwenden. Zum Überwachen von Identität und Zugriff können Sie Microsoft Entra-Aktivitätsprotokolle an Azure Monitor weiterleiten. Außerdem können Sie VMs, Netzwerke und Azure Firewall überwachen sowie importierte Protokolle mit der Protokollabfrage-Funktion analysieren. Sie können Azure Monitor mit Ihrer Security Information and Event Management (SIEM)-Instanz integrieren; dies kann ein SIEM eines Drittanbieters oder Microsoft Sentinel sein.