Azure-Leitfaden für die sichere Isolierung

Microsoft Azure ist eine Hyperskalen-Plattform für mehrinstanzenfähige Clouddienste, die Ihnen Den Zugriff auf eine funktionsreiche Umgebung bietet, die die neuesten Cloudinnovationen wie künstliche Intelligenz, Maschinelles Lernen, IoT-Dienste, Big Data Analytics, intelligente Edges und vieles mehr bietet, um Ihnen zu helfen, Effizienz zu steigern und Einblicke in Ihre Vorgänge und Leistung zu gewinnen.

Eine mehrinstanzenfähige Cloudplattform impliziert, dass mehrere Kundenanwendungen und -daten auf derselben physischen Hardware gespeichert werden. Azure verwendet logische Isolation, um Ihre Anwendungen und Daten von anderen Kunden zu trennen. Dieser Ansatz stellt den Umfang und die wirtschaftlichen Vorteile von mehrinstanzenfähigen Clouddiensten bereit und verhindert gleichzeitig zuverlässig, dass andere Kunden auf Ihre Daten oder Anwendungen zugreifen können.

Azure begegnet dem wahrgenommenen Risiko der gemeinsamen Nutzung von Ressourcen, indem eine vertrauenswürdige Grundlage für die Sicherstellung mehrinstanzenfähiger, kryptografisch sicherer, logisch isolierter Clouddienste unter Verwendung eines gemeinsamen Satzes von Prinzipien bereitgestellt wird:

1. Benutzerzugriffssteuerungen mit Authentifizierung und Identitätstrennung
2. Isoliertes Compute für die Verarbeitung
3. Netzwerkisolation, einschließlich Datenverschlüsselung während der Übertragung
4. Speicherisolation mit Verschlüsselung ruhender Daten
5. Prozesse für Sicherheitsgarantien, die in den Dienstentwurf eingebettet sind, um logisch isolierte Dienste ordnungsgemäß zu entwickeln

Multi-Tenancy in der öffentlichen Cloud verbessert die Effizienz durch Multiplexing von Ressourcen zwischen unterschiedlichen Kunden zu niedrigen Kosten; dieser Ansatz führt jedoch zu dem wahrgenommenen Risiko, das mit der Ressourcenteilung verbunden ist. Azure behebt dieses Risiko, indem eine vertrauenswürdige Grundlage für isolierte Clouddienste mit einem mehrschichtigen Ansatz bereitgestellt wird, der in Abbildung 1 dargestellt ist.

Abbildung 1: Azure-Isolationsansätze

Nachfolgend finden Sie eine kurze Zusammenfassung der Isolationsansätze.

• Benutzerzugriffssteuerungen mit Authentifizierung und Identitätstrennung – Alle Daten in Azure, unabhängig vom Typ oder Speicherort, sind einem Abonnement zugeordnet. Ein Cloud-Tenant kann als dedizierte Instanz von Microsoft Entra ID angesehen werden, die Ihrer Organisation zugewiesen wird und die sie besitzt, wenn Sie sich für einen Microsoft-Clouddienst registrieren. Der Identitäts- und Zugriffsstapel hilft beim Erzwingen der Isolation zwischen Abonnements, einschließlich des Einschränkens des Zugriffs auf Ressourcen innerhalb eines Abonnements nur auf autorisierte Benutzer.

• Computeisolation – Azure bietet Ihnen sowohl logische als auch physische Computeisolation für die Verarbeitung. Logische Isolation wird über Folgendes implementiert:

  • Hypervisorisolation für Dienste, die kryptografisch bestimmte Isolation mithilfe separater virtueller Computer und verwendung der Azure Hypervisor-Isolation bereitstellen.
  • Drawbridge-Isolation innerhalb eines virtuellen Computers (VM) für Dienste, die kryptografisch bestimmte Isolation für Workloads bereitstellen, die auf demselben virtuellen Computer ausgeführt werden, indem die von Drawbridge bereitgestellte Isolation verwendet wird. Diese Dienste stellen kleine Verarbeitungseinheiten mithilfe von Kundencode bereit.
  • Die kontextbasierte Benutzerisolation für Dienste, die ausschließlich aus von Microsoft gesteuerten Code und Kundencode bestehen, darf nicht ausgeführt werden.
    

  Zusätzlich zur robusten logischen Computeisolation, die für alle Azure-Mandanten verfügbar ist, können Sie, wenn Sie eine physische Computeisolation wünschen, Azure Dedicated Host oder isolierte virtuelle Computer verwenden, die auf Serverhardware bereitgestellt werden, die einem einzelnen Kunden zugeordnet sind.

• Netzwerkisolation – Azure Virtual Network (VNet) trägt dazu bei, sicherzustellen, dass Ihr privater Netzwerkdatenverkehr logisch vom Datenverkehr getrennt ist, der zu anderen Kunden gehört. Dienste können mit öffentlichen IPs oder privaten (VNet)-IPs kommunizieren. Die Kommunikation zwischen Ihren virtuellen Computern bleibt in einem VNet privat. Sie können Ihre VNets über VNet-Peering - oder VPN-Gateways verbinden, abhängig von Ihren Konnektivitätsoptionen, einschließlich Bandbreite, Latenz und Verschlüsselungsanforderungen. Sie können Netzwerksicherheitsgruppen (Network Security Groups, NSGs) verwenden, um die Netzwerkisolation zu erreichen und Ihre Azure-Ressourcen vor dem Internet zu schützen, während Sie auf Azure-Dienste zugreifen, die öffentliche Endpunkte aufweisen. Sie können Virtual Network-Diensttags verwenden, um Netzwerkzugriffssteuerungen für Netzwerksicherheitsgruppen oder Azure Firewall zu definieren. Ein Diensttag steht für eine Gruppe von IP-Adresspräfixen aus einem bestimmten Azure-Dienst. Microsoft verwaltet die vom Dienst-Tag erfassten Adresspräfixe und aktualisiert den Dienst-Tag automatisch, wenn sich die Adressen ändern, wodurch die Komplexität häufiger Updates von Netzwerksicherheitsregeln reduziert wird. Darüber hinaus können Sie private Verknüpfungen verwenden, um über einen privaten Endpunkt in Ihrem VNet auf Azure PaaS-Dienste zuzugreifen, um sicherzustellen, dass der Datenverkehr zwischen Ihrem VNet und dem Dienst über das globale Microsoft-Backbone-Netzwerk übertragen wird, wodurch die Notwendigkeit beseitigt wird, den Dienst für das öffentliche Internet verfügbar zu machen. Schließlich bietet Azure Optionen zum Verschlüsseln von Daten während der Übertragung, einschließlich TLS-End-to-End-Verschlüsselung des Netzwerkdatenverkehrs mit TLS-Beendigung mithilfe von Key Vault-Zertifikaten, VPN-Verschlüsselung mit IPsec und Azure ExpressRoute-Verschlüsselung mit MACsec-Unterstützung (Customer-Managed Keys, CMK).

• Speicherisolation – Um die kryptografische Sicherheit der logischen Datenisolation sicherzustellen, nutzt Azure Storage ruhende Datenverschlüsselung mithilfe erweiterter Algorithmen mit mehreren Verschlüsselungen. Dieser Prozess basiert auf mehreren Verschlüsselungsschlüsseln und Diensten wie Azure Key Vault und Microsoft Entra ID, um sicheren Schlüsselzugriff und zentrale Schlüsselverwaltung sicherzustellen. Die Azure Storage-Dienstverschlüsselung stellt sicher, dass Daten automatisch verschlüsselt werden, bevor sie in Azure Storage gespeichert und vor dem Abruf entschlüsselt werden. Alle in Azure Storage geschriebenen Daten werden über die 256-Bit-AES-Verschlüsselung von FIPS 140 verschlüsselt , und Sie können Key Vault für vom Kunden verwaltete Schlüssel (CMK) verwenden. Die Azure Storage-Dienstverschlüsselung verschlüsselt die Seitenblobs, die Azure Virtual Machine-Datenträger speichern. Darüber hinaus kann die Azure Disk-Verschlüsselung optional verwendet werden, um Azure Windows- und Linux IaaS Virtual Machine-Datenträger zu verschlüsseln, um die Speicherisolation zu erhöhen und die kryptografische Sicherheit Ihrer in Azure gespeicherten Daten zu gewährleisten. Diese Verschlüsselung umfasst verwaltete Datenträger.

• Sicherheitssicherungsprozesse und -praktiken – Die Azure-Isolationsüberprüfung wird weiter durch die interne Verwendung des Security Development Lifecycle (SDL) von Microsoft und andere starke Sicherheitssicherungsprozesse erzwungen, um Angriffsflächen zu schützen und Bedrohungen zu mindern. Microsoft hat branchenführende Prozesse und Tools etabliert, die ein hohes Vertrauen in die Azure-Isolationsgarantie bieten.

Im Einklang mit dem Modell für gemeinsame Verantwortung in Cloud Computing variiert die Abgrenzung der Verantwortung zwischen Ihnen und Clouddienstanbietern je nach Cloud-Dienstmodell, während Sie Workloads aus Ihrem lokalen Rechenzentrum in die Cloud migrieren. Mit dem IaaS-Modell (Infrastructure as a Service) endet beispielsweise die Verantwortung von Microsoft auf der Hypervisor-Ebene, und Sie sind für alle Ebenen oberhalb der Virtualisierungsebene verantwortlich, einschließlich der Aufrechterhaltung des Basisbetriebssystems in Gast-VMs. Sie können Azure-Isolationstechnologien verwenden, um die gewünschte Isolationsstufe für Ihre Anwendungen und Daten zu erreichen, die in der Cloud bereitgestellt werden.

In diesem Artikel enthalten Call-Out-Felder wichtige Überlegungen oder Aktionen, die als Teil Ihrer Verantwortung angesehen werden. Sie können beispielsweise Azure Key Vault verwenden, um Ihre geheimen Schlüssel zu speichern, einschließlich Verschlüsselungsschlüsseln, die unter Ihrer Kontrolle bleiben.

Dieser Artikel enthält technische Anleitungen zur Behebung allgemeiner Sicherheits- und Isolationsbedenken, die für die Cloudakzeptanz relevant sind. Außerdem werden Designprinzipien und Technologien untersucht, die in Azure zur Verfügung stehen, um Ihre Ziele für die sichere Isolation zu erreichen.

Identitätsbasierte Isolation

Microsoft Entra ID ist ein Identitätsrepository und ein Clouddienst, der Authentifizierung, Autorisierung und Zugriffssteuerung für Ihre Benutzer, Gruppen und Objekte bereitstellt. Microsoft Entra-ID kann als eigenständiges Cloudverzeichnis oder als integrierte Lösung mit vorhandenem lokalen Active Directory verwendet werden, um wichtige Unternehmensfeatures wie Verzeichnissynchronisierung und einmaliges Anmelden zu ermöglichen.

Jedes Azure-Abonnement ist einem Microsoft Entra-Mandanten zugeordnet. Mithilfe der rollenbasierten Azure-Zugriffssteuerung (Azure RBAC) können Benutzern, Gruppen und Anwendungen aus diesem Verzeichnis Zugriff auf Ressourcen im Azure-Abonnement gewährt werden. Beispielsweise kann ein Speicherkonto in einer Ressourcengruppe platziert werden, um den Zugriff auf dieses bestimmte Speicherkonto mithilfe der Microsoft Entra-ID zu steuern. Azure Storage definiert eine Reihe integrierter Azure-Rollen, die allgemeine Berechtigungen umfassen, die für den Zugriff auf BLOB- oder Warteschlangendaten verwendet werden. Eine Anforderung an Azure Storage kann entweder mit Ihrem Microsoft Entra-Konto oder dem Speicherkontoschlüssel autorisiert werden. Auf diese Weise können nur bestimmte Benutzer auf Daten in Azure Storage zugreifen.

Zero Trust-Architektur

Alle Daten in Azure sind unabhängig vom Typ oder Speicherort einem Abonnement zugeordnet. Ein Cloud-Tenant kann als dedizierte Instanz von Microsoft Entra ID angesehen werden, die Ihrer Organisation zugewiesen wird und die sie besitzt, wenn Sie sich für einen Microsoft-Clouddienst registrieren. Die Authentifizierung beim Azure-Portal erfolgt über die Microsoft Entra-ID mithilfe einer Identität, die entweder in Microsoft Entra-ID erstellt oder mit einem lokalen Active Directory verbunden ist. Der Identitäts- und Zugriffsstapel hilft beim Erzwingen der Isolation zwischen Abonnements, einschließlich des Einschränkens des Zugriffs auf Ressourcen innerhalb eines Abonnements nur auf autorisierte Benutzer. Diese Zugriffsbeschränkung ist ein übergeordnetes Ziel des Zero Trust-Modells, das davon ausgeht, dass das Netzwerk kompromittiert ist und eine grundlegende Umstellung vom Umkreissicherheitsmodell erfordert. Bei der Auswertung von Zugriffsanforderungen sollten alle anfordernden Benutzer, Geräte und Anwendungen als nicht vertrauenswürdig betrachtet werden, bis ihre Integrität im Einklang mit den Zero Trust-Entwurfsprinzipien überprüft werden kann. Microsoft Entra ID bietet die zuverlässige, adaptive, standardbasierte Identitätsüberprüfung, die in einem Zero Trust-Framework erforderlich ist.

Microsoft Entra ID

Die Trennung der Konten, die zum Verwalten von Cloudanwendungen verwendet werden, ist für die logische Isolation von entscheidender Bedeutung. Die Kontoisolation in Azure wird mithilfe der Microsoft Entra-ID und seiner Funktionen erreicht, um eine differenzierte azure-rollenbasierte Zugriffssteuerung (Azure RBAC) zu unterstützen. Jedes Azure-Konto ist einem Microsoft Entra-Mandanten zugeordnet. Benutzer, Gruppen und Anwendungen aus diesem Verzeichnis können Ressourcen in Azure verwalten. Sie können über das Azure-Portal, azure-Befehlszeilentools und Azure-Verwaltungs-APIs geeignete Zugriffsrechte zuweisen. Jeder Azure AD-Mandant ist eindeutig und von anderen Azure AD-Instanzen getrennt. Eine Microsoft Entra-Instanz wird logisch durch Sicherheitsgrenzen isoliert, um zu verhindern, dass Kundendaten und Identitätsinformationen sich vermischen. Dies stellt sicher, dass Benutzer und Administratoren einer Microsoft Entra-ID weder böswillig noch versehentlich auf Daten in einer anderen Microsoft Entra-Instanz zugreifen oder diese kompromittieren können. Die Microsoft Entra-ID wird physisch isoliert auf dedizierten Servern ausgeführt, die logisch zu einem dedizierten Netzwerksegment isoliert sind und in denen Paketfilterung auf Hostebene und Windows-Firewalldienste zusätzlichen Schutz vor nicht vertrauenswürdigem Datenverkehr bieten.

Microsoft Entra ID implementiert umfangreiche Datenschutzfeatures, einschließlich Mandantenisolation und Zugriffssteuerung, Datenverschlüsselung während der Übertragung, Geheimschlüsselverschlüsselung und -verwaltung, Verschlüsselung auf Datenträgerebene, erweiterte kryptografische Algorithmen, die von verschiedenen Microsoft Entra-Komponenten verwendet werden, Datenbetriebsüberlegungen für den Insider-Zugriff und vieles mehr. Detaillierte Informationen finden Sie in einem Whitepaper zu Microsoft Entra Data Security Considerations.

Die Mandantenisolation in Microsoft Entra ID umfasst zwei primäre Elemente.

• Verhindern von Datenlecks und Zugriff über Mandanten hinweg, was bedeutet, dass Daten, die zu Mandant A gehören, von Benutzern in Mandanten B ohne explizite Autorisierung durch Mandant A nicht abgerufen werden können.
• Ressourcenzugriffsisolation über Mandanten hinweg, was bedeutet, dass Vorgänge, die von Mandant A ausgeführt werden, keinen Einfluss auf den Zugriff auf Ressourcen für Mandanten B haben können.

Wie in Abbildung 2 dargestellt, erfordert der Zugriff über die Microsoft Entra-ID eine Benutzerauthentifizierung über einen Sicherheitstokendienst (Security Token Service, STS). Das Autorisierungssystem verwendet Informationen zum Vorhandensein und aktivierten Status des Benutzers über die Verzeichnisdienste-API und Azure RBAC, um zu bestimmen, ob der angeforderte Zugriff auf die Microsoft Entra-Zielinstanz für den Benutzer in der Sitzung autorisiert ist. Abgesehen von der tokenbasierten Authentifizierung, die direkt an den Benutzer gebunden ist, unterstützt Microsoft Entra ID die logische Isolation in Azure durch:

• Microsoft Entra-Instanzen sind diskrete Container und es gibt keine Beziehung zwischen ihnen.
• Microsoft Entra-Daten werden in Partitionen gespeichert, und jede Partition verfügt über einen vordefinierten Satz von Replikaten, die als bevorzugte primäre Replikate betrachtet werden. Die Verwendung von Replikaten bietet eine hohe Verfügbarkeit von Microsoft Entra-Diensten zur Unterstützung der Identitätstrennung und logischen Isolation.
• Der Zugriff ist in Microsoft Entra-Instanzen nicht erlaubt, es sei denn, der Administrator der Microsoft Entra-Instanz gewährt ihn mittels Partnerverbund oder der Einrichtung von Benutzerkonten aus anderen Microsoft Entra-Instanzen.
• Physischer Zugriff auf Server, die den Microsoft Entra-Dienst und direkten Zugriff auf die Back-End-Systeme von Microsoft Entra ID umfassen, ist auf ordnungsgemäß autorisierte Microsoft-Betriebsrollen mit dem Just-In-Time (JIT)-Verwaltungssystem für privilegierten Zugriff beschränkt.
• Microsoft Entra-Benutzer haben keinen Zugriff auf physische Ressourcen oder Speicherorte, und daher ist es nicht möglich, die logischen Azure RBAC-Richtlinienprüfungen zu umgehen.

Abbildung 2. Microsoft Entra – logische Mandantenisolation

Zusammenfassend verwendet Azures Ansatz zur logischen Mandantenisolation Identitäten, die über die Microsoft Entra-ID verwaltet werden, als erste logische Kontrollgrenze für die Bereitstellung des Zugriffs auf Ressourcen und autorisierung auf Mandantenebene über Azure RBAC.

Datenverschlüsselungsschlüsselverwaltung

Azure verfügt über umfassende Unterstützung, um Ihre Daten mithilfe der Datenverschlüsselung zu schützen, einschließlich verschiedener Verschlüsselungsmodelle:

• Serverseitige Verschlüsselung, die dienstverwaltete Schlüssel, vom Kunden verwaltete Schlüssel in Azure oder vom Kunden verwaltete Schlüssel auf kundengesteuerter Hardware verwendet.
• Clientseitige Verschlüsselung, mit der Sie Schlüssel lokal oder an einem anderen sicheren Ort verwalten und speichern können.

Die Datenverschlüsselung bietet Isolationsüberprüfungen, die direkt an den Verschlüsselungsschlüsselzugriff (Kryptografieschlüssel) gebunden sind. Da Azure starke Verschlüsselungschiffre für die Datenverschlüsselung verwendet, können nur Entitäten mit Zugriff auf kryptografische Schlüssel Zugriff auf Daten haben. Durch das Löschen oder Widerrufen kryptografischer Schlüssel werden die entsprechenden Daten unzugänglich gerendert. Weitere Informationen zur Datenverschlüsselung während der Übertragung werden im Abschnitt " Netzwerkisolation " bereitgestellt, während die ruhende Datenverschlüsselung im Abschnitt " Speicherisolation " behandelt wird.

Azure ermöglicht es Ihnen, die doppelte Verschlüsselung für ruhende und übertragene Daten zu erzwingen. Mit diesem Modell können zwei oder mehr Verschlüsselungsebenen vor Kompromittierungen jeder Verschlüsselungsebene geschützt werden.

Azure Key Vault (ein Dienst zur sicheren Verwaltung kryptografischer Schlüssel)

Der ordnungsgemäße Schutz und die Verwaltung kryptografischer Schlüssel ist für die Datensicherheit unerlässlich. Azure Key Vault ist ein Clouddienst zum sicheren Speichern und Verwalten von geheimen Schlüsseln. Der Key Vault-Dienst unterstützt zwei Ressourcentypen, die im restlichen Abschnitt beschrieben werden:

• Vault unterstützt software- und HSM-geschützte Geheimnisse, Schlüssel und Zertifikate.
• Verwaltetes HSM unterstützt nur HSM-geschützte kryptografische Schlüssel.

Wenn Sie zusätzliche Sicherheit für Ihre vertraulichsten Kundendaten benötigen, die in Azure-Diensten gespeichert sind, können Sie sie mit Ihren eigenen Verschlüsselungsschlüsseln verschlüsseln, die Sie im Key Vault steuern.

Der Key Vault-Dienst bietet eine Abstraktion über die zugrunde liegenden HSMs. Es stellt eine REST-API bereit, um die Dienstverwendung aus Cloudanwendungen und der Authentifizierung über Die Microsoft Entra-ID zu ermöglichen, damit Sie die Authentifizierung, Notfallwiederherstellung, hohe Verfügbarkeit und Flexibilität zentralisieren und anpassen können. Key Vault unterstützt kryptografische Schlüssel verschiedener Typen, Größen und Kurven, einschließlich RSA- und Elliptic Curve-Schlüsseln. Mit verwalteten HSMs steht auch Unterstützung für symmetrische AES-Schlüssel zur Verfügung.

Mit Key Vault können Sie Verschlüsselungsschlüssel in HSMs importieren oder generieren, um sicherzustellen, dass Schlüssel niemals die HSM-Schutzgrenze verlassen und um Szenarien für die Verwendung eigener Schlüssel (BYOK) zu unterstützen, wie in Abbildung 3 dargestellt.

Abbildung 3. Azure Key Vault-Unterstützung für die Bereitstellung Ihres eigenen Schlüssels (BYOK)

Schlüssel, die innerhalb der Key Vault-HSMs generiert werden, können nicht exportiert werden: Es gibt keine Klartextversion des Schlüssels außerhalb der HSMs. Diese Bindung wird vom zugrunde liegenden HSM erzwungen. Die BYOK-Funktionalität ist für Schlüsseltresore und für verwaltete HSMs verfügbar. Die Methoden zum Übertragen von HSM-geschützten Schlüsseln in Key Vault variieren je nach dem zugrunde liegenden HSM, wie in der Onlinedokumentation erläutert.

Key Vault bietet eine robuste Lösung für die Verwaltung des Verschlüsselungsschlüssellebenszyklus. Bei der Erstellung wird jeder Schlüsseltresor oder jedes verwaltete HSM automatisch mit dem Microsoft Entra-Mandanten verknüpft, der das Abonnements besitzt. Jeder Benutzer, der versucht, Inhalte aus einem Schlüsseltresor oder verwaltetem HSM zu verwalten oder abzurufen, muss ordnungsgemäß authentifiziert und autorisiert sein:

• Die Authentifizierung richtet die Identität des Anrufers (Benutzer oder Anwendung) ein.
• Autorisierung bestimmt, welche Vorgänge der Aufrufer ausführen kann, basierend auf einer Kombination aus azure role-based access control (Azure RBAC) und Key Vault Access Policy oder verwaltetem HSM local RBAC.

Die Microsoft Entra-ID erzwingt die Mandantenisolation und implementiert robuste Maßnahmen, um den Zugriff durch nicht autorisierte Parteien zu verhindern, wie zuvor im Abschnitt "Microsoft Entra ID " beschrieben. Der Zugriff auf einen Schlüsseltresor oder ein verwaltetes HSM wird über zwei Ebenen gesteuert – Verwaltungsebene und Datenebene – und beide verwenden Microsoft Entra ID für die Authentifizierung.

• Mithilfe der Verwaltungsebene können Sie den Schlüsseltresor oder das verwaltete HSM selbst verwalten, z. B. Schlüsseltresor oder verwaltete HSMs erstellen und löschen, Schlüsseltresor- oder verwaltete HSM-Eigenschaften abrufen und Zugriffsrichtlinien aktualisieren. Zur Autorisierung verwendet die Verwaltungsebene Azure RBAC mit Schlüsseltresoren und mit verwalteten HSMs.
• Mit der Datenebene können Sie mit den Daten arbeiten, die in Ihren Schlüsseltresoren und verwalteten HSMs gespeichert sind, einschließlich Hinzufügen, Löschen und Ändern Ihrer Daten. Bei Tresoren können gespeicherte Daten Schlüssel, geheime Schlüssel und Zertifikate enthalten. Bei verwalteten HSMs sind gespeicherte Daten nur auf kryptografische Schlüssel beschränkt. Zur Autorisierung verwendet die Datenebene die Key Vault-Zugriffsrichtlinie und Azure RBAC für Datenebenenvorgänge mit Schlüsseltresoren oder das lokale RBAC für verwaltete HSMs mit verwalteten HSMs.

Wenn Sie einen Key Vault oder verwaltetes HSM in einem Azure-Abonnement erstellen, wird er automatisch dem Microsoft Entra-Mandanten des Abonnements zugeordnet. Alle Aufrufer auf beiden Ebenen müssen sich in diesem Mandanten registrieren und sich für den Zugriff auf den Schlüsseltresor oder das verwaltete HSM authentifizieren.

Sie steuern Zugriffsberechtigungen und können detaillierte Aktivitätsprotokolle aus dem Azure Key Vault-Dienst extrahieren. Azure Key Vault protokolliert die folgenden Informationen:

• Alle authentifizierten REST-API-Anforderungen, einschließlich fehlgeschlagener Anforderungen
  • Vorgänge im Schlüsseltresor, z. B. Erstellen, Löschen, Festlegen von Zugriffsrichtlinien usw.
  • Vorgänge zu Schlüsseln und geheimen Schlüsseln im Schlüsseltresor, einschließlich a) Erstellen, Ändern oder Löschen von Schlüsseln oder geheimen Schlüsseln und b) Signieren, Überprüfen, Verschlüsseln von Schlüsseln usw.
• Nicht authentifizierte Anforderungen, z. B. Anforderungen, die kein Bearertoken besitzen, falsch formatiert oder abgelaufen sind oder ein ungültiges Token aufweisen.

Sie können auch die Azure Key Vault-Lösung in Azure Monitor verwenden, um Key Vault-Protokolle zu überprüfen. Um diese Lösung zu verwenden, müssen Sie die Protokollierung der Key Vault-Diagnose aktivieren und die Diagnose an einen Log Analytics-Arbeitsbereich weiterleiten. Bei dieser Lösung ist es nicht erforderlich, Protokolle in Azure Blob Storage zu schreiben.

Tresor

Tresore bieten eine mehrinstanzenfähige, kostengünstige, einfach bereitzustellende Zonenresilienz (sofern verfügbar) und hoch verfügbare Schlüsselverwaltungslösung, die für die meisten gängigen Cloudanwendungsszenarien geeignet ist. Tresore können geheime Schlüssel, Schlüssel und Zertifikate speichern und schützen. Sie können entweder softwaregeschützt (Standardebene) oder HSM-geschützt (Premium-Ebene) sein. Einen Vergleich zwischen den Standard- und Premium-Stufen finden Sie auf der Azure Key Vault-Preisseite. Softwaregeschützte Geheimschlüssel, Schlüssel und Zertifikate werden von Azure geschützt, wobei Branchenstandardalgorithmen und Schlüssellängen verwendet werden. Wenn Sie zusätzliche Sicherheiten benötigen, können Sie Ihre Geheimnisse, Schlüssel und Zertifikate in Schränken schützen, die durch mehrinstanzenfähige HSMs geschützt sind. Die entsprechenden HSMs werden gemäß dem FIPS 140-Standard überprüft und verfügen über eine allgemeine Sicherheitsstufe 2-Bewertung, die Anforderungen für physische Manipulationsnachweise und rollenbasierte Authentifizierung enthält.

Tresore ermöglichen die Unterstützung für vom Kunden verwaltete Schlüssel (CMK), wo Sie Ihre eigenen Schlüssel in HSMs steuern und diese verwenden können, um Ruhedaten für viele Azure-Dienste zu verschlüsseln. Wie bereits erwähnt, können Sie in HSMs Verschlüsselungsschlüssel importieren oder generieren, um sicherzustellen, dass die Schlüssel niemals die HSM-Grenze verlassen. Dies unterstützt Szenarien des Bring Your Own Key (BYOK).

Key Vault kann das Anfordern und Erneuern von Zertifikaten in Tresoren verarbeiten, einschließlich TLS-Zertifikaten (Transport Layer Security), sodass Sie Zertifikate von unterstützten öffentlichen Zertifizierungsstellen registrieren und automatisch erneuern können. Die Unterstützung von Key Vault-Zertifikaten bietet die Verwaltung Ihrer X.509-Zertifikate, die auf Schlüsseln basieren und ein automatisches Erneuerungsfeature bereitstellen. Der Zertifikatbesitzer kann ein Zertifikat über Azure Key Vault oder durch Importieren eines vorhandenen Zertifikats erstellen. Sowohl selbstsignierte als auch generierte Zertifikate der Zertifizierungsstelle werden unterstützt. Darüber hinaus kann der Key Vault-Zertifikatbesitzer sichere Speicherung und Verwaltung von X.509-Zertifikaten ohne Interaktion mit privaten Schlüsseln implementieren.

Wenn Sie einen Schlüsseltresor in einer Ressourcengruppe erstellen, können Sie den Zugriff mithilfe der Microsoft Entra-ID verwalten, wodurch Sie zugriff auf einer bestimmten Bereichsebene gewähren können, indem Sie die entsprechenden Azure-Rollen zuweisen. Um beispielsweise einem Benutzer Zugriff zum Verwalten von Schlüsseltresoren zu gewähren, können Sie dem Benutzer für einen bestimmten Bereich eine vordefinierte Teilnehmerrolle für den Schlüsseltresor zuzuweisen, einschließlich Abonnement, Ressourcengruppe oder bestimmter Ressource.

Verwaltetes HSM

Verwaltetes HSM bietet ein Single-Tenant, vollständig verwaltetes, hochverfügbares, zonensicheres (sofern verfügbar) HSM als Dienst zum Speichern und Verwalten Ihrer kryptografischen Schlüssel. Dies eignet sich am besten für Anwendungen und Verwendungsszenarien, in denen Schlüsseln mit hohem Wert verwendet werden. Es hilft Ihnen auch, die strengsten Sicherheits-, Compliance- und gesetzlichen Anforderungen zu erfüllen. Verwaltetes HSM verwendet FIPS 140 Level 3-validierte HSMs , um Ihre kryptografischen Schlüssel zu schützen. Jeder verwaltete HSM-Pool ist eine isolierte Einzelmandanteninstanz mit eigener Sicherheitsdomäne , die von Ihnen gesteuert und kryptografisch von Instanzen getrennt wird, die zu anderen Kunden gehören. Kryptografische Isolation basiert auf der Intel Software Guard Extensions (SGX)-Technologie, die verschlüsselten Code und Daten bereitstellt, um die Kontrolle über kryptografische Schlüssel sicherzustellen.

Wenn ein verwaltetes HSM erstellt wird, stellt der Antragsteller auch eine Liste der Datenebenenadministratoren bereit. Nur diese Administratoren können auf die verwaltete HSM-Datenebene zugreifen , um wichtige Vorgänge auszuführen und Rollenzuweisungen auf datenebenen zu verwalten (verwaltetes HSM-lokales RBAC). Das Berechtigungsmodell für die Verwaltungs- und Datenebene verwendet dieselbe Syntax, Berechtigungen werden jedoch auf unterschiedlichen Ebenen erzwungen, und Rollenzuweisungen verwenden unterschiedliche Geltungsbereiche. Auf Verwaltungsebene wird Azure RBAC von Azure Resource Manager durchgesetzt, während auf der Datenebene vom verwalteten HSM selbst die lokale RBAC des verwalteten HSM durchgesetzt wird.

Wie bereits erwähnt, unterstützt verwaltetes HSM das Importieren von Schlüsseln , die in Ihren lokalen HSMs generiert wurden, und stellt sicher, dass die Schlüssel niemals die HSM-Schutzgrenze verlassen, auch bekannt als Bring Your Own Key (BYOK)- Szenario. Verwaltetes HSM unterstützt die Integration in Azure-Dienste wie Azure Storage, Azure SQL-Datenbank, Azure Information Protection und andere. Eine vollständigere Liste der Azure-Dienste, die mit verwaltetem HSM arbeiten, finden Sie unter Datenverschlüsselungsmodelle.

Mit verwaltetem HSM können Sie die etablierten Azure Key Vault-API- und Verwaltungsschnittstellen verwenden. Sie können die gleichen Anwendungsentwicklungs- und Bereitstellungsmuster für alle Ihre Anwendungen unabhängig von der Schlüsselverwaltungslösung verwenden: multitenant vault oder single-tenant managed HSM.

Computeisolation

Die Microsoft Azure-Computeplattform basiert auf der Computervirtualisierung. Dieser Ansatz bedeutet, dass Ihr Code – unabhängig davon, ob er in einer PaaS-Workerrolle oder einem virtuellen IaaS-Computer bereitgestellt wird – in einem virtuellen Computer ausgeführt wird, der von einem Windows Server Hyper-V Hypervisor gehostet wird. Auf jedem physischen Azure-Server, auch als Knoten bezeichnet, gibt es einen Typ 1-Hypervisor , der direkt über die Hardware ausgeführt wird und den Knoten in eine variable Anzahl virtueller Gastcomputer (VMs) unterteilt, wie in Abbildung 4 dargestellt. Jeder Knoten verfügt über eine spezielle Host-VM, die auch als Stamm-VM bezeichnet wird, die das Hostbetriebssystem ausführt – eine angepasste und gehärtete Version des neuesten Windows-Servers, die entfernt wird, um die Angriffsfläche zu reduzieren und nur diese Komponenten einzuschließen, die zum Verwalten des Knotens erforderlich sind. Die Isolation der Stamm-VM von den Gast-VMs und den Gast-VMs voneinander ist ein wichtiges Konzept in der Azure-Sicherheitsarchitektur, das die Grundlage der Azure-Computeisolation bildet, wie in der Microsoft-Onlinedokumentation beschrieben.

Abbildung 4. Isolation von Hypervisor, Stamm-VM und Gast-VMs

Physische Server, die VMs hosten, werden in Clustern gruppiert und unabhängig von einer skalierten und redundanten Plattformsoftwarekomponente namens Fabric Controller (FC) verwaltet. Jeder FC verwaltet den Lebenszyklus von VMs, die in seinem Cluster ausgeführt werden, einschließlich Bereitstellung und Überwachung der Integrität der Hardware unter ihrer Kontrolle. Beispielsweise ist der FC dafür verantwortlich, VM-Instanzen auf fehlerfreien Servern neu zu erstellen, wenn festgestellt wird, dass ein Server fehlgeschlagen ist. Außerdem ordnet sie Infrastrukturressourcen zu Mandantenworkloads zu und verwaltet die unidirektionale Kommunikation vom Host zu virtuellen Computern. Die Aufteilung der Rechnerinfrastruktur in Cluster isoliert Fehler auf FC-Ebene und verhindert, dass bestimmte Fehlerklassen andere Server außerhalb des Clusters, in dem sie auftreten, beeinflussen.

Der FC ist das Gehirn der Azure-Computeplattform und der Host-Agent ist sein Proxy, der Server in die Plattform integriert, sodass der FC die von Ihnen und Azure Cloud Services verwendeten virtuellen Computer bereitstellen, überwachen und verwalten kann. Die Hypervisor-/Hostbetriebssystem-Kopplung verwendet jahrzehntelange Erfahrung von Microsoft in der Betriebssystemsicherheit, einschließlich sicherheitsorientierter Investitionen in Microsoft Hyper-V , um eine starke Isolation von Gast-VMs zu ermöglichen. Die Hypervisorisolation wird weiter unten in diesem Abschnitt erläutert, einschließlich der Sicherheitsvorkehrungen für stark definierte Sicherheitsgrenzen, die vom Hypervisor durchgesetzt werden, der umfassenden Abwehr von Exploits und zuverlässiger Prozesse für Sicherheitsgarantien.

Netzwerkisolation für die Verwaltung

Es gibt drei virtuelle lokale Netzwerke (VLANs) in jedem Computehardwarecluster, wie in Abbildung 5 dargestellt:

• Haupt-VLAN verbindet nicht vertrauenswürdige Kundenknoten,
• Fabric Controller-VLAN (FC), das vertrauenswürdige FCs und unterstützende Systeme enthält, und
• Geräte-VLAN, das vertrauenswürdige Netzwerk- und andere Infrastrukturgeräte enthält.

Die Kommunikation ist vom FC VLAN an das Haupt-VLAN zulässig, kann aber nicht vom Haupt-VLAN an das FC VLAN initiiert werden. Die Brücke vom FC VLAN zum Haupt-VLAN wird verwendet, um die Gesamtkomplexität zu reduzieren und die Zuverlässigkeit/Resilienz des Netzwerks zu verbessern. Die Verbindung wird auf verschiedene Arten gesichert, um sicherzustellen, dass Befehle vertrauenswürdig und erfolgreich weitergeleitet werden:

• Die Kommunikation von einem FC an einen Fabric Agent (FA) ist unidirektional und erfordert eine gegenseitige Authentifizierung über Zertifikate. Die FA implementiert einen TLS-geschützten Dienst, der nur auf Anforderungen des FC reagiert. Es kann keine Verbindungen mit dem FC oder anderen privilegierten internen Knoten initiieren.
• Der FC behandelt Antworten des Agentendiensts so, als wären sie nicht vertrauenswürdig. Die Kommunikation mit dem Agent ist weiter auf eine Reihe autorisierter IP-Adressen beschränkt, indem Firewallregeln für jeden physischen Knoten und Routingregeln an den Grenzgateways verwendet werden.
• Die Drosselung wird verwendet, um sicherzustellen, dass die VMs von Kunden das Netzwerk nicht überlasten und Verwaltungsbefehle nicht geroutet werden.

Auch die Kommunikation vom Haupt-VLAN zum Geräte-VLAN ist blockiert. Selbst wenn ein Knoten mit Kundencode kompromittiert ist, kann er dadurch keine anderen Knoten in den FC- oder Geräte-VLANs angreifen.

Diese Steuerelemente stellen sicher, dass der Zugriff der Verwaltungskonsole auf den Hypervisor immer gültig und verfügbar ist.

Abbildung 5. VLAN-Isolation

Der Hypervisor und das Host-Betriebssystem stellen Netzwerkpaketfilter bereit, die sicherstellen, dass nicht vertrauenswürdige VMs keinen gefälschten Datenverkehr generieren oder nicht an sie adressierten Datenverkehr empfangen können, den Datenverkehr direkt zu geschützten Infrastrukturendpunkten leiten oder unangemessenen Broadcast-Datenverkehr senden/empfangen. Der Datenverkehr wird standardmäßig blockiert, wenn eine VM erstellt wird, und der FC-Agent konfiguriert dann den Paketfilter, um Regeln und Ausnahmen hinzuzufügen, um autorisierten Datenverkehr zuzulassen. Ausführlichere Informationen zur Netzwerkdatenverkehrisolation und zur Trennung des Mandantendatenverkehrs finden Sie im Abschnitt "Netzwerkisolation ".

Verwaltungskonsole und Verwaltungsebene

Die Azure Management Console und Management Plane befolgen strenge Sicherheitsarchitekturprinzipien der geringsten Berechtigungen, um die Mandantenverarbeitung zu sichern und zu isolieren:

• Management Console (MC) – Der MC in Azure Cloud besteht aus der Azure-Portal-GUI und den Azure Resource Manager-API-Ebenen. Sie verwenden beide Benutzeranmeldeinformationen, um alle Vorgänge zu authentifizieren und zu autorisieren.
• Management Plane (MP) – Diese Ebene führt die tatsächlichen Verwaltungsaktionen aus und besteht aus dem Compute Resource Provider (CRP), Fabric Controller (FC), Fabric Agent (FA) und dem zugrunde liegenden Hypervisor, der über einen eigenen Hypervisor-Agent für die Dienstkommunikation verfügt. Diese Ebenen verwenden alle Systemkontexte, die mit den minimal erforderlichen Berechtigungen ausgestattet sind, um ihre Aufgaben auszuführen.

Der Azure FC weist Mandanten Infrastrukturressourcen zu und verwaltet unidirektionale Kommunikationen vom Hostbetriebssystem zu Gast-VMs. Der VM-Platzierungsalgorithmus des Azure FC ist hoch entwickelt und fast unmöglich vorherzusagen. Die FA befindet sich im Hostbetriebssystem und verwaltet Mandanten-VMs. Die Zusammenstellung von Azure-Hypervisor, Hostbetriebssystem, FA und Kunden-VMs stellt einen Computeknoten dar, wie in Abbildung 4 dargestellt. FCs verwalten FAs, obwohl FCs außerhalb von Computeknoten vorhanden sind – separate FCs sind zum Verwalten von Compute- und Speicherclustern vorhanden. Wenn Sie die Konfigurationsdatei Ihrer Anwendung während der Ausführung im MC aktualisieren, kommuniziert der MC über CRP mit dem FC, und der FC kommuniziert mit der FA.

CRP ist der Front-End-Dienst für Azure Compute, der konsistente Compute-APIs über Azure Resource Manager verfügbar macht, wodurch Sie virtuelle Computerressourcen und Erweiterungen über einfache Vorlagen erstellen und verwalten können.

Die Kommunikation zwischen verschiedenen Komponenten (z. B. Azure Resource Manager zu und von CRP, CRP zu und von FC, FC zu und von Hypervisor-Agent) funktionieren alle auf verschiedenen Kommunikationskanälen mit unterschiedlichen Identitäten und unterschiedlichen Berechtigungssätzen. Dieser Entwurf folgt gängigen Modellen mit geringsten Rechten, um sicherzustellen, dass eine Kompromittierung einer einzelnen Ebene mehr Aktionen verhindert. Separate Kommunikationskanäle stellen sicher, dass die Kommunikation keine Ebene in der Kette umgehen kann. Abbildung 6 veranschaulicht, wie mc und MP sicher innerhalb der Azure-Cloud für Hypervisor-Interaktionen kommunizieren, die von der OAuth 2.0-Authentifizierung eines Benutzers an die Microsoft Entra-ID initiiert werden.

Abbildung 6. Interaktion der Verwaltungskonsole und der Verwaltungsebene für einen sicheren Verwaltungsfluss

Alle Verwaltungsbefehle werden über RSA-signiertes Zertifikat oder JSON-Webtoken (JWT) authentifiziert. Authentifizierungs- und Befehlskanäle werden über TLS (Transport Layer Security) 1.2 verschlüsselt, wie im Abschnitt "Datenverschlüsselung im Transit " beschrieben. Serverzertifikate werden verwendet, um TLS-Konnektivität mit den Authentifizierungsanbietern bereitzustellen, bei denen ein separater Autorisierungsmechanismus verwendet wird, z. B. Microsoft Entra ID oder Datacenter Security Token Service (dSTS). dSTS ist ein Tokenanbieter wie Die Microsoft Entra-ID, die vom Microsoft-Rechenzentrum isoliert und für die Kommunikation auf Dienstebene verwendet wird.

Abbildung 6 zeigt den Verwaltungsfluss, der einem Benutzerbefehl entspricht, um einen virtuellen Computer zu beenden. Die in Tabelle 1 aufgelisteten Schritte gelten für andere Verwaltungsbefehle auf die gleiche Weise und verwenden denselben Verschlüsselungs- und Authentifizierungsfluss.

Tabelle 1. Managementprozess unter Einbeziehung verschiedener MC- und MP-Komponenten

Befehle, die über alle Schritte des in diesem Abschnitt identifizierten Prozesses generiert und an den FC und fa auf jedem Knoten gesendet werden, werden in ein lokales Überwachungsprotokoll geschrieben und an mehrere Analysesysteme für die Datenstromverarbeitung verteilt, um die Systemintegrität zu überwachen und Sicherheitsereignisse und -muster nachzuverfolgen. Die Nachverfolgung umfasst Ereignisse, die erfolgreich verarbeitet wurden, und Ereignisse, die ungültig waren. Ungültige Anforderungen werden von den Angriffserkennungssystemen verarbeitet, um Anomalien zu erkennen.

Implementierungsoptionen für logische Isolation

Azure bietet eine Isolation der Rechenverarbeitung durch einen mehrschichtigen Ansatz, einschließlich:

• Hypervisorisolation für Dienste, die kryptografisch bestimmte Isolation mithilfe separater virtueller Computer und verwendung der Azure Hypervisor-Isolation bereitstellen. Beispiele: App Service, Azure Container Instances, Azure Databricks, Azure Functions, Azure Kubernetes Service, Azure Machine Learning, Cloud Services, Data Factory, Service Fabric, Virtual Machines, Virtual Machine Scale Sets.
• Drawbridge-Isolation innerhalb einer VM für Dienste, die kryptografisch bestimmte Isolation für Workloads bereitstellen, die auf demselben virtuellen Computer ausgeführt werden, indem sie die von Drawbridge bereitgestellte Isolation verwenden. Diese Dienste stellen kleine Verarbeitungseinheiten mithilfe von Kundencode bereit. Um die Sicherheitsisolation zu gewährleisten, führt Drawbridge einen Benutzerprozess zusammen mit einer leichten Version des Windows-Kernels (Bibliotheksbetriebssystem) innerhalb eines Pic-Prozesses aus. Ein Pic-Prozess ist ein gesicherter Prozess ohne direkten Zugriff auf Dienstleistungen oder Ressourcen des Hostsystems. Beispiele: Automatisierung, Azure-Datenbank für MySQL, Azure-Datenbank für PostgreSQL, Azure SQL-Datenbank, Azure Stream Analytics.
• Die kontextbasierte Benutzerisolation für Dienste, die ausschließlich aus von Microsoft gesteuerten Code und Kundencode bestehen, darf nicht ausgeführt werden. Beispiele: API-Verwaltung, Anwendungsgateway, Microsoft Entra ID, Azure Backup, Azure Managed Redis, Azure DNS, Azure Information Protection, Azure IoT Hub, Azure Key Vault, Azure Portal, Azure Monitor (einschließlich Log Analytics), Microsoft Defender für Cloud, Azure Site Recovery, Containerregistrierung, Content Delivery Network, Event Grid, Event Hubs, Load Balancer, Service Bus, Storage, Virtual Network, VPN Gateway, Datenverkehrs-Manager.

Diese logischen Isolationsoptionen werden im restlichen Abschnitt erläutert.

Hypervisorisolation

Die Hypervisorisolation in Azure basiert auf der Microsoft Hyper-V-Technologie, durch die die Hypervisor-basierte Isolation in Azure von jahrzehntelanger Microsoft-Erfahrung in der Betriebssystemsicherheit und Investitionen in die Hyper-V-Technologie für die Isolation virtueller Computer profitieren kann. Sie können unabhängige Bewertungsberichte von Drittanbietern zu Hyper-V-Sicherheitsfunktionen überprüfen, einschließlich der Berichte des Common Criteria Evaluation and Validation Scheme (CCEVS) der National Information Assurance Partnership (NIAP), wie zum Beispiel den Bericht, der im Februar 2021 veröffentlicht wurde und hier besprochen wird.

Das Ziel der Evaluierung (TOE) bestand aus Microsoft Windows Server, Microsoft Windows 10 Version 1909 (November 2019 Update) und Microsoft Windows Server 2019 (Version 1809) Hyper-V ("Windows"). ToE erzwingt die folgenden Sicherheitsrichtlinien, wie im Bericht beschrieben:

• Sicherheitsüberwachung – Windows hat die Möglichkeit, Überwachungsdaten zu sammeln, Überwachungsprotokolle zu überprüfen, Überwachungsprotokolle vor Überlauf zu schützen und den Zugriff auf Überwachungsprotokolle einzuschränken. Überwachungsinformationen, die vom System generiert werden, umfassen das Datum und die Uhrzeit des Ereignisses, die Benutzeridentität, die dazu führte, dass das Ereignis generiert wurde, und andere ereignisspezifische Daten. Autorisierte Administratoren können Überwachungsdatensätze überprüfen, durchsuchen und sortieren. Autorisierte Administratoren können das Überwachungssystem auch so konfigurieren, dass potenziell überprüfbare Ereignisse einbezogen oder ausgeschlossen werden, die basierend auf vielen Merkmalen überwacht werden. Im Rahmen dieser Bewertung decken die Schutzprofilanforderungen das Generieren von Überwachungsereignissen, die autorisierte Überprüfung gespeicherter Überwachungsdatensätze und die Bereitstellung eines sicheren Speichers für Überwachungsereigniseinträge ab.
• Kryptografieunterstützung – Windows bietet überprüfte kryptografische Funktionen, die Verschlüsselung/Entschlüsselung, kryptografische Signaturen, kryptografische Hashing und Zufallszahlengenerierung unterstützen. Windows implementiert diese Funktionen zur Unterstützung der IPsec-, TLS- und HTTPS-Protokollimplementierung. Windows stellt außerdem sicher, dass seine Gast-VMs Zugriff auf Entropiedaten haben, sodass virtualisierte Betriebssysteme die Implementierung einer starken Kryptografie sicherstellen können.
• Benutzerdatenschutz – Windows stellt bestimmte Computerdienste Gast-VMs zur Verfügung, implementiert jedoch Maßnahmen, um sicherzustellen, dass der Zugriff auf diese Dienste angemessen gewährt wird und dass diese Schnittstellen nicht zu nicht autorisierten Datenlecks zwischen Gast-VMs und Windows oder zwischen mehreren Gast-VMs führen.
• Identifikation und Authentifizierung – Windows bietet verschiedene Methoden der Benutzerauthentifizierung, die X.509-Zertifikate enthält, die für vertrauenswürdige Protokolle erforderlich sind. Windows implementiert Kennwortstärkemechanismen und stellt sicher, dass übermäßige fehlgeschlagene Authentifizierungsversuche mithilfe von Methoden, die brute force Guessing (Kennwort, PIN) unterliegen, zu sperrungsverhalten führen.
• Sicherheitsverwaltung – Windows umfasst mehrere Funktionen zum Verwalten von Sicherheitsrichtlinien. Der Zugriff auf administrative Funktionen wird durch administrative Rollen sichergestellt. Windows verfügt außerdem über die Fähigkeit, die Trennung von Verwaltungs- und Betriebsnetzwerken zu unterstützen und die Datenfreigabe zwischen Gast-VMs zu untersagen.
• Schutz der TOE-Sicherheitsfunktionen (TOE Security Functions, TSF) – Windows implementiert verschiedene Selbstschutzmechanismen, um sicherzustellen, dass sie nicht als Plattform verwendet werden kann, um nicht autorisierten Zugriff auf daten zu erhalten, die auf einer Gast-VM gespeichert sind, dass die Integrität sowohl des TSF als auch seiner Gast-VMs verwaltet wird und dass Gast-VMs ausschließlich über gut dokumentierte Schnittstellen aufgerufen werden.
• TOE Access – Im Kontext dieser Auswertung ermöglicht Windows einem autorisierten Administrator, das System so zu konfigurieren, dass vor dem Anmeldedialogfeld ein Anmeldebanner angezeigt wird.
• Vertrauenswürdiger Pfad/Kanäle – Windows implementiert IPsec-, TLS- und HTTPS-vertrauenswürdige Kanäle und Pfade für die Remoteverwaltung, die Übertragung von Überwachungsdaten in die Betriebsumgebung sowie die Trennung von Verwaltungs- und Betriebsnetzwerken.

Weitere Informationen finden Sie im Zertifizierungsbericht von Drittanbietern.

Die kritische Hypervisorisolation wird über Folgendes bereitgestellt:

• Stark definierte Sicherheitsgrenzen, die vom Hypervisor erzwungen werden
• Abwehr in der Tiefe exploitiert Abmilderungen
• Starke Sicherheitssicherungsprozesse

Diese Technologien werden im restlichen Abschnitt beschrieben. Sie ermöglichen Azure Hypervisor, starke Sicherheitsvorkehrungen für die Mandantentrennung in einer mehrinstanzenfähigen Cloud zu bieten.

Stark definierte Sicherheitsgrenzen

Ihr Code wird auf einer Hypervisor-VM ausgeführt und profitiert von Hypervisor erzwungenen Sicherheitsgrenzen, wie in Abbildung 7 dargestellt. Azure Hypervisor basiert auf der Microsoft Hyper-V-Technologie . Er teilt einen Azure-Knoten in eine variable Anzahl von Gast-VMs mit separaten Adressräumen auf, in denen sie ein Betriebssystem (Betriebssystem) und Anwendungen laden können, die parallel zum Hostbetriebssystem ausgeführt werden, das in der Stammpartition des Knotens ausgeführt wird.

Abbildung 7. Computeisolation mit Azure Hypervisor (siehe Online-Glossar der Begriffe)

Der Azure-Hypervisor fungiert wie ein Mikrokernkern und übergibt alle Hardwarezugriffsanforderungen von Gast-VMs mithilfe eines Virtualisierungsdienstclients (VSC) an das Hostbetriebssystem zur Verarbeitung mithilfe einer gemeinsam genutzten Speicherschnittstelle namens VMBus. Das Hostbetriebssystem vermittelt die Hardwareanforderungen mithilfe eines Virtualisierungsdienstanbieters (VSP), der verhindert, dass Benutzer direkten Lese-/Schreib-/Ausführungszugriff auf das System erhalten und das Risiko der Freigabe von Systemressourcen mindert. Die privilegierte Stammpartition, auch als Hostbetriebssystem bezeichnet, hat direkten Zugriff auf die physischen Geräte/Peripheriegeräte auf dem System, z. B. Speichercontroller, GPUs, Netzwerkadapter usw. Das Hostbetriebssystem ermöglicht Gastpartitionen, die Verwendung dieser physischen Geräte freizugeben, indem virtuelle Geräte für jede Gastpartition verfügbar sind. Ein Betriebssystem, das in einer Gastpartition ausgeführt wird, hat also Zugriff auf virtualisierte Peripheriegeräte, die von VSPs bereitgestellt werden, die in der Stammpartition ausgeführt werden. Diese darstellungen virtueller Geräte können eine von drei Formen annehmen:

• Emulierte Geräte – Das Hostbetriebssystem kann ein virtuelles Gerät mit einer Schnittstelle verfügbar machen, die mit dem identisch ist, was von einem entsprechenden physischen Gerät bereitgestellt wird. In diesem Fall würde ein Betriebssystem in einer Gastpartition dieselben Gerätetreiber wie bei der Ausführung auf einem physischen System verwenden. Das Hostbetriebssystem emuliert das Verhalten eines physischen Geräts auf der Gastpartition.
• Para-virtualisierte Geräte – Das Hostbetriebssystem kann virtuelle Geräte mit einer virtualisierungsspezifischen Schnittstelle verfügbar machen, indem die VMBus-geteilte Speicher-Schnittstelle zwischen dem Hostbetriebssystem und dem Gast verwendet wird. In diesem Modell verwendet die Gastpartition Gerätetreiber, die speziell für die Implementierung einer virtualisierten Schnittstelle entwickelt wurden. Diese para virtualisierten Geräte werden manchmal als "synthetische" Geräte bezeichnet.
• Hardwarebeschleunigte Geräte – Das Hostbetriebssystem kann tatsächliche Hardwareperipheriegeräte direkt für die Gastpartition verfügbar machen. Dieses Modell ermöglicht eine hohe E/A-Leistung in einer Gastpartition, da die Gastpartition direkt auf Hardwaregeräteressourcen zugreifen kann, ohne das Hostbetriebssystem zu durchlaufen. Azure Accelerated Networking ist ein Beispiel für ein hardwarebeschleunigtes Gerät. Die Isolation in diesem Modell wird mithilfe von Speicherverwaltungseinheiten für die Eingabeausgabe (E/A MMUs) erreicht, um Adressraum bereitzustellen und die Isolation für jede Partition zu unterbrechen.

Virtualisierungserweiterungen in der Host-CPU ermöglichen dem Azure-Hypervisor, die Isolation zwischen Partitionen zu erzwingen. Die folgenden grundlegenden CPU-Funktionen bieten die Hardwarebausteine für die Hypervisorisolation:

• Adressübersetzung auf zweiter Ebene – Der Hypervisor steuert, auf welche Speicherressourcen eine Partition zugreifen darf, indem Seitentabellen der zweiten Ebene verwendet werden, die von der Speicherverwaltungseinheit (MEMORY Management Unit, MMU) der CPU bereitgestellt werden. Die MMU der CPU verwendet die Adressübersetzung auf zweiter Ebene unter Hypervisor-Kontrolle, um den Schutz für Arbeitsspeicherzugriffe durchzusetzen, die von Folgendem durchgeführt werden:
  • CPU beim Ausführen unter dem Kontext einer Partition.
  • E/A-Geräte, auf die direkt von Gastpartitionen zugegriffen wird.
• CPU-Kontext – Der Hypervisor verwendet Virtualisierungserweiterungen in der CPU, um Berechtigungen und CPU-Kontext einzuschränken, auf die zugegriffen werden kann, während eine Gastpartition ausgeführt wird. Der Hypervisor verwendet diese Einrichtungen auch zum Speichern und Wiederherstellen des Zustands beim Freigeben von CPUs zwischen mehreren Partitionen, um die Isolation des CPU-Zustands zwischen den Partitionen sicherzustellen.

Der Azure-Hypervisor nutzt diese Prozessoreinrichtungen umfassend, um die Isolation zwischen Partitionen bereitzustellen. Die Entstehung spekulativer Seitenkanalangriffe hat potenzielle Schwächen in einigen dieser Prozessorisolationsfunktionen identifiziert. In einer mehrmandantenfähigen Architektur umfasst jeder VM-Angriff über verschiedene Mandanten hinweg zwei Schritte: das Platzieren einer angreifergesteuerten virtuellen Maschine auf demselben Host wie eine der Opfer-VMs und dann das Durchbrechen der logischen Isolationsgrenze, um einen Seitenkanalangriff durchzuführen. Azure bietet Schutz vor beiden Bedrohungsvektoren, indem ein erweiterter VM-Platzierungsalgorithmus verwendet wird, der Speicher- und Prozesstrennung zur logischen Isolierung erzwingt, und sicheres Netzwerkdatenverkehrsrouting mit kryptografischer Sicherheit beim Hypervisor. Wie im später im Artikel, im Abschnitt "Exploitation von Schwachstellen in Virtualisierungstechnologien beschrieben, wurde der Azure-Hypervisor so konzipiert, dass er eine robuste Isolation direkt innerhalb des Hypervisors bereitstellt, die hilft, viele komplexe Seitenkanalangriffe zu mildern.

Die vom Azure Hypervisor definierten Sicherheitsgrenzen bieten die Basis-Isolationselemente für eine starke Segmentierung von Code, Daten und Ressourcen zwischen potenziell böswilligen Mandanten auf gemeinsam genutzter Hardware. Diese Isolationsprimitiven werden verwendet, um Szenarien für die mehrinstanzenfähige Ressourcenisolation zu erstellen, einschließlich:

• Isolation des Netzwerkdatenverkehrs zwischen potenziell feindlichen Gästen – Virtual Network (VNet) bietet eine Isolation des Netzwerkdatenverkehrs zwischen Mandanten als Teil des grundlegenden Entwurfs, wie weiter unten im Abschnitt "Trennung des Mandantennetzwerkdatenverkehrs " beschrieben. VNet bildet eine Isolationsgrenze, an der die VMs innerhalb eines VNets nur miteinander kommunizieren können. Beliebiger Datenverkehr an einen virtuellen Computer von innerhalb des VNet oder einem externen Absender, ohne dass die richtige Richtlinie konfiguriert ist, wird vom Host gelöscht und nicht an den virtuellen Computer übermittelt.
• Isolation für Verschlüsselungsschlüssel und kryptografisches Material – Sie können die Isolationsfunktionen mit der Verwendung von Hardwaresicherheitsmanagern oder spezialisierten Schlüsselspeichern weiter erweitern, z. B. das Speichern von Verschlüsselungsschlüsseln in FIPS 140 validierten Hardwaresicherheitsmodulen (HSMs) über Azure Key Vault.
• Planung von Systemressourcen – Das Azure-Design umfasst die garantierte Verfügbarkeit und Segmentierung von Compute, Arbeitsspeicher, Speicher sowie direkten und para virtualisierten Gerätezugriff.

Der Azure-Hypervisor erfüllt die sicherheitsrelevanten Ziele in Tabelle 2.

Tabelle 2. Sicherheitsziele von Azure Hypervisor

Defense-in-Depth-Ausnutzungsminderungen

Um das Risiko einer Sicherheitskompromittierung weiter zu verringern, hat Microsoft in zahlreiche Defense-in-Depth-Maßnahmen in der Azure-Systemsoftware, -Hardware und -Firmware investiert, um Azure-Kunden eine starke reale Isolationsgarantie zu bieten. Wie bereits erwähnt, basiert die Azure Hypervisor-Isolation auf der Microsoft Hyper-V-Technologie , die Es Azure Hypervisor ermöglicht, von jahrzehntelanger Microsoft-Erfahrung in betriebssystemsicherheit und Investitionen in Hyper-V Technologie für die Isolation virtueller Computer zu profitieren.

Nachfolgend sind einige wichtige Entwurfsprinzipien aufgeführt, die von Microsoft zum Sichern von Hyper-V übernommen wurden:

• Verhindern von Problemen auf Entwurfsebene, die auswirkungen auf das Produkt haben
  • Jede Änderung, die in Hyper-V eingeht, unterliegt der Entwurfsüberprüfung.
• Beseitigen häufiger Verwundbarkeitsklassen mit sichererem Programmieren
  • Einige Komponenten wie der VMSwitch verwenden einen formal bewährten Protokollparser.
  • Viele Komponenten verwenden gsl::span anstelle von rohen Zeigern, wodurch die Möglichkeit von Pufferüberläufen und/oder Speicherzugriffen außerhalb des zulässigen Bereichs verhindert wird. Weitere Informationen finden Sie in der Dokumentation zur Richtlinienunterstützungsbibliothek (GSL ).
  • Viele Komponenten verwenden intelligente Zeiger, um das Risiko von Verwendung nach dem Freigeben Fehlern zu vermeiden.
  • Der Hyper-V-Kernelmoduscode verwendet überwiegend eine Heapbelegung, die bei der Zuordnung null wird, um nicht initialisierte Speicherfehler zu beseitigen.
• Beseitigen allgemeiner Sicherheitsrisikoklassen mit Compilerminderungen
  • Der gesamte Hyper-V Code wird mit InitAll kompiliert, wodurch nicht initialisierte Stapelvariablen entfernt werden. Dieser Ansatz wurde implementiert, da viele historische Sicherheitsrisiken in Hyper-V durch nicht initialisierte Stapelvariablen verursacht wurden.
  • Der gesamte Hyper-V Code wird mit Stack-Canaries kompiliert, um das Risiko von Stapelüberlaufanfälligkeiten erheblich zu verringern.
• Probleme finden, die in das Produkt gelangen
  • Der gesamte Windows-Code verfügt über eine Reihe statischer Analyseregeln, die darin ausgeführt werden.
  • Der gesamte Hyper-V Code wird überprüft und gefuzzt. Weitere Informationen zu Fuzzen finden Sie weiter unten in diesem Artikel unter Sicherheitssicherungsprozesse und -praktiken .
• Die Nutzung verbleibender Sicherheitsrisiken schwieriger machen
  • Der VM-Workerprozess hat die folgenden Abhilfemaßnahmen angewendet:
    • Schutz vor arbiträrer Codeausführung: Dynamisch generierter Code kann nicht im VM-Workerprozess geladen werden.
    • Code Integrity Guard – Nur von Microsoft signierter Code kann im VM-Arbeitsprozess geladen werden.
    • Ablaufsteuerungsschutz (Control Flow Guard, CFG): Bietet groben Ablaufsteuerungsschutz für indirekte Aufrufe und Sprünge.
    • NoChildProcess – Der Arbeitsprozess kann keine Kindprozesse erstellen, was sich für die Umgehung von CFG als nützlich erweist.
    • NoLowImages / NoRemoteImages – Der Arbeitsprozess kann KEINE DLLs über das Netzwerk oder DLLs laden, die von einem Sandkastenprozess auf den Datenträger geschrieben wurden.
    • NoWin32k – Der Arbeitsprozess kann nicht mit Win32k kommunizieren, wodurch Sandbox-Fluchten schwieriger werden.
    • Heap-Randomisierung – Windows wird mit einer der sichersten Heap-Implementierungen eines beliebigen Betriebssystems ausgeliefert.
    • Zufällige Anordnung des Layouts des Addressraums (Address Space Layout Randomization, ASLR): Das Layout von Heaps, Stapeln, Binärdateien und anderen Datenstrukturen im Adressbereich wird zufällig angeordnet, um die Ausnutzung weniger zuverlässig zu machen.
    • Datenausführungsverhinderung (DATA Execution Prevention, DEP/NX) – Nur Seiten mit Arbeitsspeicher, die Code enthalten sollen, sind ausführbar.
  • Der Kernel hat die folgenden Abhilfemaßnahmen angewendet:
    • Heap-Randomisierung – Windows wird mit einer der sichersten Heap-Implementierungen eines beliebigen Betriebssystems ausgeliefert.
    • Zufällige Anordnung des Layouts des Addressraums (Address Space Layout Randomization, ASLR): Das Layout von Heaps, Stapeln, Binärdateien und anderen Datenstrukturen im Adressbereich wird zufällig angeordnet, um die Ausnutzung weniger zuverlässig zu machen.
    • Datenausführungsverhinderung (DATA Execution Prevention, DEP/NX) – Nur Seiten mit Arbeitsspeicher, die Code enthalten sollen, sind ausführbar.

Von Microsoft-Investitionen in Hyper-V-Sicherheit profitiert der Azure-Hypervisor direkt. Ziel von Abwehrmaßnahmen im Detail ist es, die Waffennutzung einer Sicherheitsanfälligkeit so teuer wie möglich für einen Angreifer zu machen, deren Auswirkungen zu begrenzen und das Fenster zur Erkennung zu maximieren. Alle Exploit-Gegenmaßnahmen werden durch eine gründliche Sicherheitsüberprüfung der Azure Hypervisor-Angriffsfläche anhand von Methoden ausgewertet, die Angreifer verwenden können. In Tabelle 3 sind einige der Entschärfungen aufgeführt, die zum Schutz der Hypervisorisolationsgrenzen und der Hardwarehostintegrität vorgesehen sind.

Tabelle 3. Umfassende Verteidigung des Azure-Hypervisors

Darüber hinaus hat Azure eine Sicherheitsstrategie gegen Sicherheitsverletzungen eingeführt, die über Red Teaming implementiert wurde. Dieser Ansatz basiert auf einem dedizierten Team von Sicherheitsforschern und Ingenieuren, die fortlaufende Tests von Azure-Systemen und -Vorgängen unter Verwendung der gleichen Taktiken, Techniken und Verfahren wie echte Gegner gegen die Live-Produktionsinfrastruktur durchführen, ohne dass die Azure-Infrastruktur- und Plattform-Engineering- oder -Betriebsteams vertraut sind. Dieser Ansatz testet Sicherheitserkennungs- und Reaktionsfunktionen und hilft bei der Identifizierung von Produktionsrisiken in Azure Hypervisor und anderen Systemen, einschließlich Konfigurationsfehlern, ungültigen Annahmen oder anderen Sicherheitsproblemen auf kontrollierte Weise. Microsoft investiert stark in diese innovativen Sicherheitsmaßnahmen für eine kontinuierliche Azure-Bedrohungsminderung.

Starke Sicherheitssicherungsprozesse

Die Angriffsfläche in Hyper-V ist gut verstanden. Es war Gegenstand laufender Forschungen und gründlicher Sicherheitsüberprüfungen. Microsoft war transparent über die Hyper-V Angriffsfläche und die zugrunde liegende Sicherheitsarchitektur, wie bei einer öffentlichen Präsentation auf einer Black Hat-Konferenz im Jahr 2018 gezeigt. Microsoft steht hinter der Robustheit und Qualität der Hyper-V-Isolation mit einem Bug Bounty Program im Umfang von 250.000 USD für kritische Remotecodeausführung (RCE), Veröffentlichung von Informationen und DoS-Sicherheitslücken (Denial of Service), die in Hyper-V gemeldet wurden. Durch die Verwendung der gleichen Hyper-V Technologie in der Windows Server- und Azure-Cloudplattform stellen sie sicher, dass die öffentlich verfügbare Dokumentation und das Programm für Bug-Bounty sicherstellen, dass Sicherheitsverbesserungen für alle Benutzer von Microsoft-Produkten und -Diensten anfallen. Tabelle 4 fasst die wichtigsten Angriffsflächenpunkte aus der Präsentation "Black Hat" zusammen.

Tabelle 4. Hyper-V Details zur Angriffsfläche

Um diese Angriffsflächen zu schützen, hat Microsoft branchenführende Prozesse und Tools etabliert, die eine hohe Vertrauenswürdigkeit in die Azure-Isolationsgarantie bieten. Wie weiter unten in diesem Artikel im Abschnitt " Sicherheitssicherungsprozesse und -praktiken " beschrieben, umfasst der Ansatz zweckorientierte fuzzing, Penetrationstests, Sicherheitsentwicklungslebenszyklus, obligatorische Sicherheitsschulungen, Sicherheitsüberprüfungen, Erkennung von Sicherheitsangriffen basierend auf Gast - Host-Bedrohungsindikatoren und automatisiertes Erstellen von Warnungen über Änderungen an der Angriffsfläche. Dieser ausgereifte mehrdimensionale Zuverlässigkeitsprozess trägt dazu bei, die vom Azure-Hypervisor bereitgestellten Isolationsgarantien zu erweitern, indem das Risiko von Sicherheitsrisiken gemildert wird.

Drawbridge-Isolation

Für Dienste, die kleine Verarbeitungseinheiten mithilfe von Kundencode bereitstellen, werden Anforderungen von mehreren Mandanten innerhalb einer einzelnen VM ausgeführt und mithilfe der Microsoft Drawbridge-Technologie isoliert. Um eine Sicherheitsisolation bereitzustellen, führt Drawbridge einen Benutzerprozess zusammen mit einer leichtgewichtigen Version des Windows-Kernels (Library OS) innerhalb eines Pico-Prozesses aus. Ein Pico-Prozess ist ein leichtgewichtiger, sicherer Isolationscontainer mit minimaler Kernel-API-Oberfläche und keinem direkten Zugriff auf Dienste oder Ressourcen des Hostsystems. Die einzigen externen Aufrufe, die der pico-Prozess ausführen kann, gehen an den Drawbridge Security Monitor über die Drawbridge Application Binary Interface (ABI), wie in Abbildung 8 dargestellt.

Abbildung 8. Prozessisolation mit Drawbridge

Der Sicherheitsmonitor ist in einen Systemgerätetreiber und eine Benutzermoduskomponente unterteilt. Die ABI ist die Schnittstelle zwischen dem Bibliotheksbetriebssystem und dem Host. Die gesamte Schnittstelle besteht aus einem geschlossenen Satz von weniger als 50 zustandslosen Funktionsaufrufen:

• Die Down-Aufrufe vom Pico-Prozess bis zum Host-Betriebssystem unterstützen Abstraktionen wie Threads, virtuellen Speicher und E/A-Streams.
• Aufrufe an den Pico-Prozess führen die Initialisierung durch, geben Ausnahmeinformationen zurück und werden in einem neuen Thread ausgeführt.

Die Semantik der Schnittstelle ist fest und unterstützt die allgemeinen Abstraktionen, die anwendungen von jedem Betriebssystem benötigen. Mit diesem Design kann das Bibliotheksbetriebssystem und der Host separat weiterentwickelt werden.

Die ABI wird in zwei Komponenten implementiert:

• Die Plattform-Anpassungsschicht (PAL) läuft als Teil des Pico-Prozesses.
• Die Hostimplementierung wird als Teil des Hosts ausgeführt.

Pico-Prozesse werden in Isolationseinheiten gruppiert, die als Sandkasten bezeichnet werden. Der Sandkasten definiert die Anwendungen, Dateisysteme und externen Ressourcen, die den Pic-Prozessen zur Verfügung stehen. Wenn ein Prozess, der in einem Pico-Prozess ausgeführt wird, einen neuen untergeordneten Prozess erstellt, wird dieser mit seinem eigenen Bibliotheksbetriebssystem in einem separaten Pico-Prozess innerhalb desselben Sandkastens ausgeführt. Jeder Sandkasten kommuniziert mit dem Sicherheitsmonitor und kann nicht mit anderen Sandkästen kommunizieren, außer über zulässige E/A-Kanäle (Sockets, benannte Pipes usw.), die von der Konfiguration mit der standardmäßigen Aktivierungsmethode explizit zugelassen werden müssen, je nach Dienstanforderungen. Das Ergebnis ist, dass Code, der innerhalb eines Pico-Prozesses ausgeführt wird, nur auf seine eigenen Ressourcen zugreifen kann und das Hostsystem oder andere kollozierten Sandkästen nicht direkt angreifen kann. Es ist nur in der Lage, Objekte in ihrem eigenen Sandkasten zu beeinflussen.

Wenn der Pic-Prozess Systemressourcen benötigt, muss er den Drawbridge-Host aufrufen, um sie anzufordern. Der normale Pfad für einen virtuellen Benutzerprozess wäre das Aufrufen des Bibliotheksbetriebssystems, um Ressourcen anzufordern, und das Bibliotheksbetriebssystem würde dann in die ABI aufrufen. Sofern die Richtlinie für die Ressourcenzuordnung nicht im Treiber selbst eingerichtet ist, verarbeitet der Sicherheitsmonitor die ABI-Anforderung, indem die Richtlinie überprüft wird, um festzustellen, ob die Anforderung zulässig ist und dann die Anforderung gewartet wird. Dieser Mechanismus wird für alle Systemgrundtypen verwendet, um sicherzustellen, dass der code, der im Pic-Prozess ausgeführt wird, die Ressourcen vom Hostcomputer nicht missbrauchen kann.

Neben der Isolierung innerhalb von Sandkästen sind auch die Pico-Prozesse wesentlich voneinander isoliert. Jeder Pic-Prozess befindet sich in einem eigenen virtuellen Speicheradressraum und führt eine eigene Kopie des Bibliotheksbetriebssystems mit seinem eigenen Benutzermodus-Kernel aus. Jedes Mal, wenn ein Benutzerprozess in einer Drawbridge-Sandbox gestartet wird, wird eine neue Library-Betriebssysteminstanz gestartet. Obwohl diese Aufgabe im Vergleich zum Starten eines nicht isolierten Prozesses unter Windows zeitaufwändiger ist, ist sie wesentlich schneller als das Starten eines virtuellen Computers bei gleichzeitiger logischer Isolation.

Ein normaler Windows-Prozess kann mehr als 1200 Funktionen aufrufen, die zum Zugriff auf den Windows-Kernel führen; Die gesamte Schnittstelle für einen Pic-Prozess besteht jedoch aus weniger als 50 Aufrufen bis zum Host. Die meisten Anwendungsanforderungen für Betriebssystemdienste werden vom Library OS innerhalb des Adressraums des Pic-Prozesses verarbeitet. Durch die Bereitstellung einer deutlich kleineren Schnittstelle zum Kernel erstellt Drawbridge eine sicherere und isoliertere Betriebsumgebung, in der Anwendungen wesentlich weniger anfällig für Änderungen im Hostsystem und Inkompatibilitäten sind, die von neuen Betriebssystemversionen eingeführt wurden. Wichtiger ist jedoch, dass ein Drawbridge-Pico-Prozess ein stark isolierter Container ist, in dem nicht vertrauenswürdiger Code aus selbst aus den böswilligsten Quellen ausgeführt werden kann, ohne dass das Hostsystem gefährdet wird. Der Host geht davon aus, dass kein Code, der innerhalb des Pic-Prozesses ausgeführt wird, als vertrauenswürdig eingestuft werden kann. Der Host validiert alle Anforderungen des Pico-Prozesses mit Sicherheitsüberprüfungen.

Wie ein virtueller Computer ist der Pic-Prozess viel einfacher zu sichern als eine herkömmliche Betriebssystemschnittstelle, da es wesentlich kleiner, zustandslos ist und feste und leicht beschriebene Semantik aufweist. Ein weiterer zusätzlicher Vorteil der kleinen ABI/Treiber-syscall-Schnittstelle ist die Möglichkeit, den Treibercode mit geringem Aufwand zu überwachen/ zu fuzzen. Beispielsweise können syscall-Fuzzer ABI in relativ kurzer Zeit mit hohen Abdeckungszahlen fuzzen.

Kontextbasierte Benutzerisolation

In Fällen, in denen ein Azure-Dienst aus von Microsoft gesteuertem Code besteht und Kundencode nicht ausgeführt werden darf, wird die Isolation von einem Benutzerkontext bereitgestellt. Diese Dienste akzeptieren nur Benutzerkonfigurationseingaben und -daten für die Verarbeitung – beliebiger Code ist nicht zulässig. Für diese Dienste wird ein Benutzerkontext bereitgestellt, um die Daten festzulegen, auf die zugegriffen werden kann, und welche Azure-rollenbasierten Zugriffssteuerungsvorgänge (Azure RBAC) zulässig sind. Dieser Kontext wird von Microsoft Entra ID eingerichtet, wie weiter oben im Abschnitt Identitätsbasierte Isolation beschrieben. Nachdem der Benutzer identifiziert und autorisiert wurde, erstellt der Azure-Dienst einen Anwendungsbenutzerkontext, der an die Anforderung angefügt ist, während er durch die Ausführung wechselt, und stellt sicher, dass Benutzervorgänge getrennt und ordnungsgemäß isoliert sind.

Physische Isolation

Zusätzlich zur robusten logischen Computeisolation, die für alle Azure-Mandanten verfügbar ist, können Sie, wenn Sie eine physische Computeisolation wünschen, Azure Dedicated Host oder isolierte virtuelle Computer verwenden, die beide einem einzelnen Kunden zugeordnet sind.

Dedizierter Azure-Host

Azure Dedicated Host stellt physische Server bereit, die virtuelle Azure-Computer hosten können und ausschließlich von einem Azure-Abonnement verwendet werden. Sie können dedizierte Hosts in einer Region, einer Verfügbarkeitszone und einer Fehlerdomäne bereitstellen. Anschließend können Sie Windows, Linux und SQL Server auf Azure-VMs direkt in bereitgestellte Hosts platzieren, mit der Konfiguration, die am besten Ihren Anforderungen entspricht. Dedizierter Host bietet Hardwareisolation auf physischer Serverebene, sodass Sie Ihre Azure-VMs auf einem isolierten und dedizierten physischen Server platzieren können, der nur die Workloads Ihrer Organisation ausführt, um die Complianceanforderungen des Unternehmens zu erfüllen.

Sie können virtuelle Windows- und Linux-Computer auf dedizierten Hosts bereitstellen, indem Sie den Server- und CPU-Typ, die Anzahl der Kerne und zusätzliche Features auswählen. Der dedizierte Host ermöglicht die Kontrolle über Plattformwartungsereignisse, indem Sie sich für ein Wartungsfenster entscheiden können, um potenzielle Auswirkungen auf Ihre bereitgestellten Dienste zu reduzieren. Die meisten Wartungsereignisse haben wenig bis keine Auswirkungen auf Ihre virtuellen Computer; Wenn Sie sich jedoch in einer stark regulierten Branche oder mit einer sensiblen Arbeitsauslastung befinden, sollten Sie die Kontrolle über potenzielle Wartungsauswirkungen haben.

Microsoft bietet detaillierte Kundenleitfäden zur Bereitstellung virtueller Windows - und Linux-Azure-Computer mithilfe des Azure-Portals, Azure PowerShell und Azure CLI. Tabelle 5 fasst die verfügbaren Sicherheitsleitfaden für Ihre virtuellen Computer zusammen, die in Azure bereitgestellt werden.

Tabelle 5. Sicherheitsleitfaden für virtuelle Azure-Computer

Isolierte virtuelle Computer

Azure Compute bietet virtuelle Computergrößen, die für einen bestimmten Hardwaretyp isoliert sind und einem einzelnen Kunden zugeordnet sind. Diese VM-Instanzen ermöglichen es Ihren Workloads, auf dedizierten physischen Servern bereitzustellen. Die Verwendung isolierter VMs garantiert im Wesentlichen, dass Ihre VM die einzige ist, die auf diesem bestimmten Serverknoten ausgeführt wird. Sie können auch die Ressourcen auf diesen isolierten virtuellen Computern weiter unterteilen, indem Sie die Azure-Unterstützung für geschachtelte virtuelle Computer verwenden.

Netzwerkisolation

Die logische Isolation der Mandanteninfrastruktur in einer öffentlichen mehrinstanzenfähigen Cloud ist grundlegend für die Aufrechterhaltung der Sicherheit. Das übergeordnete Prinzip für eine virtualisierte Lösung besteht darin, nur Verbindungen und Kommunikationen zuzulassen, die für diese virtualisierte Lösung erforderlich sind, um zu arbeiten, und alle anderen Ports und Verbindungen standardmäßig zu blockieren. Azure Virtual Network (VNet) trägt dazu bei, sicherzustellen, dass Ihr privater Netzwerkdatenverkehr logisch vom Datenverkehr anderer Kunden isoliert ist. Virtuelle Computer (VMs) in einem VNet können nicht direkt mit VMs in einem anderen VNet kommunizieren, auch wenn beide VNets vom gleichen Kunden erstellt werden. Die Netzwerkisolation stellt sicher, dass die Kommunikation zwischen Ihren virtuellen Computern innerhalb eines VNet privat bleibt. Sie können Ihre VNets über VNet-Peering - oder VPN-Gateways verbinden, abhängig von Ihren Konnektivitätsoptionen, einschließlich Bandbreite, Latenz und Verschlüsselungsanforderungen.

In diesem Abschnitt wird beschrieben, wie Azure die Isolation des Netzwerkdatenverkehrs zwischen Mandanten bereitstellt und diese Isolation mit kryptografischer Sicherheit erzwingt.

Trennung des Datenverkehrs im Mandantennetzwerk

Virtuelle Netzwerke (VNets) sorgen in ihrem grundsätzlichen Design für die Isolation des Netzwerkdatenverkehrs zwischen Mandanten. Ihr Azure-Abonnement kann mehrere logisch isolierte private Netzwerke enthalten und Firewall-, Lastenausgleichs- und Netzwerkadressenübersetzung enthalten. Jedes VNet ist standardmäßig von anderen VNets isoliert. Mehrere Bereitstellungen innerhalb Ihres Abonnements können im selben VNet platziert und dann über private IP-Adressen miteinander kommunizieren.

Der Netzwerkzugriff auf VMs ist durch die Paketfilterung am Netzwerkrand, beim Lastenausgleich und auf Hostbetriebssystemebene beschränkt. Darüber hinaus können Sie Ihre Hostfirewalls so konfigurieren, dass die Konnektivität weiter eingeschränkt wird, wobei für jeden Überwachungsport angegeben wird, ob Verbindungen aus dem Internet oder nur von Rolleninstanzen innerhalb desselben Clouddiensts oder VNet akzeptiert werden.

Azure bietet Netzwerkisolation für jede Bereitstellung und erzwingt die folgenden Regeln:

• Datenverkehr zwischen VMs durchläuft immer vertrauenswürdige Paketfilter.
  • Protokolle wie Address Resolution Protocol (ARP), Dynamic Host Configuration Protocol (DHCP) und anderer OSI Layer-2-Datenverkehr von einem virtuellen Computer werden mithilfe von Schutzratenbegrenzung und Antispoofing gesteuert.
  • VMs können keinen Datenverkehr im Netzwerk erfassen, der nicht für sie vorgesehen ist.
• Ihre virtuellen Computer können keinen Datenverkehr an private Azure-Schnittstellen und Infrastrukturdienste oder an VMs senden, die anderen Kunden angehören. Ihre virtuellen Computer können nur mit anderen virtuellen Computern kommunizieren, die ihnen gehören oder von Ihnen gesteuert werden, und mit Azure-Infrastrukturdienstendpunkten, die für die öffentliche Kommunikation vorgesehen sind.
• Wenn Sie einen virtuellen Computer auf einem VNet platzieren, erhält diese VM einen eigenen Adressraum, der nicht sichtbar ist und daher nicht von VMs außerhalb einer Bereitstellung oder VNet erreichbar ist (es sei denn, dies ist so konfiguriert, dass er über öffentliche IP-Adressen sichtbar ist). Ihre Umgebung ist nur über die Ports geöffnet, die Sie für den öffentlichen Zugriff angeben; wenn der virtuelle Computer definiert ist, um eine öffentliche IP-Adresse zu haben, sind alle Ports für den öffentlichen Zugriff geöffnet.

Paketfluss- und Netzwerkpfadschutz

Das Hyperscale-Netzwerk von Azure wurde entwickelt, um Folgendes bereitzustellen:

• Einheitliche hohe Kapazität zwischen Servern.
• Leistungsisolation zwischen Diensten, einschließlich Kunden.
• Ethernet Layer-2-Semantik.

Azure verwendet mehrere Netzwerkimplementierungen, um diese Ziele zu erreichen:

• Flache Adressierung, damit Dienstinstanzen überall im Netzwerk platziert werden können.
• Lastenausgleich, um den Datenverkehr gleichmäßig über Netzwerkpfade zu verteilen.
• Endsystembasierte Adressauflösung zum Skalieren auf große Serverpools, ohne Komplexität in die Netzwerksteuerungsebene einzuführen.

Diese Implementierungen geben jedem Dienst die Illusion, dass alle ihm zugewiesenen Server und nur diese Server durch einen einzelnen nichtinterferierenden Ethernet-Switch – einen Virtual Layer 2 (VL2) – verbunden sind und diese Illusion beibehalten, selbst wenn die Größe jedes Diensts von einem Server bis zu Hunderten von Tausenden variiert. Diese VL2-Implementierung erreicht die Datenverkehrsleistungsisolation, um sicherzustellen, dass es nicht möglich ist, dass der Datenverkehr eines Diensts vom Datenverkehr eines anderen Diensts betroffen ist, als ob jeder Dienst durch einen separaten physischen Switch verbunden wäre.

In diesem Abschnitt wird erläutert, wie Pakete über das Azure-Netzwerk fließen und wie die Topologie, das Routingdesign und das Verzeichnissystem kombiniert werden, um die zugrunde liegende Netzwerk fabric zu virtualisieren, wodurch die Illusion entsteht, dass Server mit einem großen, nichtinterferierenden Layer-2-Switch verbunden sind.

Das Azure-Netzwerk verwendet zwei verschiedene IP-Adressfamilien:

• Kundenadresse (CA) ist die vom Kunden definierte/ausgewählte VNet-IP-Adresse, die auch als virtuelle IP (VIP) bezeichnet wird. Die Netzwerkinfrastruktur arbeitet mit CAs, die extern routingfähig sind. Allen Switches und Schnittstellen werden CAs zugewiesen, und Switches führen ein IP-basiertes (Layer-3)-Verbindungszustandsroutingprotokoll aus, das nur diese CAs verbreitet. Mit diesem Design können Switches die vollständige Topologie auf Switchebene abrufen und Pakete weiterleiten, die mit CAs gekapselt werden, entlang kürzester Pfade.
• Die Anbieteradresse (PA) ist die interne Azure-Fabric-Adresse, die für Benutzer nicht sichtbar ist und auch als Dynamic IP (DIP) bezeichnet wird. Kein Datenverkehr geht direkt vom Internet zu einem Server; Der gesamte Datenverkehr aus dem Internet muss einen Software Load Balancer (SLB) durchlaufen und gekapselt werden, um den internen Azure-Adressraum zu schützen, indem nur Pakete an gültige interne Azure-IP-Adressen und -Ports weitergeleitet werden. Netzwerkadressenübersetzung (Network Address Translation, NAT) trennt internen Netzwerkdatenverkehr vom externen Datenverkehr. Interner Datenverkehr verwendet RFC 1918-Adressraum oder privaten Adressraum – die Anbieteradressen (PAs), die nicht extern routingfähig sind. Die Übersetzung erfolgt bei den SLBs. Kundenadressen (CAs), die extern routingfähig sind, werden in interne Anbieteradressen (PAs) übersetzt, die nur in Azure routingfähig sind. Diese Adressen bleiben unverändert, unabhängig davon, wie sich die Speicherorte ihrer Server aufgrund der Migration der virtuellen Maschine oder der Neu-Provisionierung ändern.

Jeder PA ist einem CA zugeordnet, welcher der Bezeichner des Top of Rack (ToR)-Switches ist, mit dem der Server verbunden ist. VL2 verwendet ein skalierbares, zuverlässiges Verzeichnissystem zum Speichern und Verwalten der Zuordnung von PAs zu CAs, und diese Zuordnung wird erstellt, wenn Server für einen Dienst bereitgestellt und pa-Adressen zugewiesen werden. Ein Agent, der im Netzwerkstapel auf jedem Server ausgeführt wird, der als VL2-Agent bezeichnet wird, ruft den Auflösungsdienst des Verzeichnissystems auf, um den tatsächlichen Speicherort des Ziels zu erlernen und dann das ursprüngliche Paket dort zu tunneln.

Azure weist Server-IP-Adressen zu, die allein als Namen fungieren, ohne topologische Bedeutung. Das VL2-Adressierungsschema von Azure trennt diese Servernamen (PAs) von ihren Standorten (CAs). Der Kernpunkt des Angebots der Layer-2-Semantik besteht darin, dass Server glauben sollen, dass sie ein einzelnes großes IP-Subnetz – d. h. den gesamten PA-Adressraum – mit anderen Servern im selben Dienst teilen, während die Skalierungsengpässe des Address Resolution-Protokolls (ARP) und des Dynamic Host Configuration-Protokolls (DHCP) beseitigt werden, die große Ethernet-Bereitstellungen plagen.

Abbildung 9 zeigt einen Beispielpaketfluss, bei dem Absender S Pakete über einen zufällig ausgewählten Zwischenswitch mit IP-in-IP Kapselung an das Ziel D sendet. PAs sind von 20/8 und Zertifizierungsstellen von 10/8. H(ft) kennzeichnet einen Hash des 5-Tupels, das aus Quell-IP, Quellport, Ziel-IP, Zielport und Protokolltyp besteht. ToR übersetzt die PA in die Zertifizierungsstelle, sendet an den Zwischenswitch, der an den ToR-Switch der Zielzertifizierungsstelle sendet, der in die Ziel-PA übersetzt.

Abbildung 9. Beispielpaketfluss

Ein Server kann keine Pakete an eine PA senden, wenn der Verzeichnisdienst die Bereitstellung einer Zertifizierungsstelle verweigert, über die er seine Pakete weiterleiten kann, was bedeutet, dass der Verzeichnisdienst Zugriffssteuerungsrichtlinien erzwingt. Da das Verzeichnissystem bei der Verarbeitung eines Nachschlagevorgangs weiß, welcher Server die Anforderung vornimmt, kann es fein abgestimmte Isolationsrichtlinien durchsetzen. Sie kann beispielsweise eine Richtlinie erzwingen, die nur Server, die zum gleichen Dienst gehören, miteinander kommunizieren kann.

Verkehrsflussmuster

Zum Weiterleiten des Datenverkehrs zwischen Servern, die PA-Adressen verwenden, in einem zugrunde liegenden Netzwerk, das Routen für CA-Adressen kennt, erfasst der VL2-Agent auf jedem Server Pakete vom Host und kapselt sie mit der Ca-Adresse des ToR-Switches des Ziels. Sobald das Paket an der Zertifizierungsstelle (am Ziel-ToR-Switch) eingetroffen ist, entkapselt der Ziel-ToR-Switch das Paket und liefert es an die Ziel-PA, die im inneren Header übertragen wird. Das Paket wird zuerst an einen der Zwischenswitches übermittelt, vom Switch entkapselt, an die ToR-Zertifizierungsstelle übermittelt, erneut entkapselt und schließlich an das Ziel gesendet. Dieser Ansatz wird in Abbildung 10 unter Verwendung von zwei möglichen Datenverkehrsmustern dargestellt: 1) externer Datenverkehr (orangefarbene Linie), der über Azure ExpressRoute oder das Internet zu einem VNet durchläuft, und 2) interner Datenverkehr (blaue Linie) zwischen zwei VNets. Beide Datenverkehrsflüsse folgen einem ähnlichen Muster, um Netzwerkdatenverkehr zu isolieren und zu schützen.

Abbildung 10. Trennung des Mandantennetzwerkdatenverkehrs mithilfe von VNets

Externer Datenverkehr (orangefarbene Linie) – Bei externem Datenverkehr bietet Azure mehrere Sicherheitsebenen, um die Isolation je nach Datenverkehrsmuster zu erzwingen. Wenn Sie eine öffentliche IP auf Ihrem VNet-Gateway platzieren, werden Datenverkehr aus dem öffentlichen Internet oder Ihrem lokalen Netzwerk, das für diese IP-Adresse bestimmt ist, an einen Internet EdgeRouter weitergeleitet. Alternativ dazu, wenn Sie ein privates Peering über eine ExpressRoute-Verbindung einrichten, wird es über ein VNet-Gateway mit einem Azure VNet verbunden. Diese Konfiguration richtet die Konnektivität mit dem physischen Schaltkreis ein und macht den privaten IP-Adressraum am lokalen Standort erreichbar. Azure verwendet dann das Border Gateway Protocol (BGP), um Routingdetails mit dem lokalen Netzwerk freizugeben, um eine End-to-End-Verbindung herzustellen. Wenn die Kommunikation mit einer Ressource innerhalb des VNet beginnt, durchläuft der Netzwerkdatenverkehr normal, bis er einen Microsoft ExpressRoute Edge (MSEE)-Router erreicht. In beiden Fällen bieten VNets die Möglichkeit für Azure-VMs, als Teil Ihres lokalen Netzwerks zu fungieren. Ein kryptografisch geschützter IPsec/IKE-Tunnel wird zwischen Azure und Ihrem internen Netzwerk (z. B. über Azure VPN-Gateway oder Azure ExpressRoute Private Peering) eingerichtet, sodass die VM eine sichere Verbindung mit Ihren lokalen Ressourcen herstellen kann, als ob sie sich direkt in diesem Netzwerk befand.

Beim Internet Edge Router oder dem MSEE-Router wird das Paket mit Generic Routing Encapsulation (GRE) gekapselt. Diese Kapselung verwendet einen eindeutigen Bezeichner, der für das VNet-Ziel und die Zieladresse spezifisch ist, die verwendet wird, um den Datenverkehr entsprechend an das identifizierte VNet weiterzuleiten. Beim Erreichen des VNet-Gateways, das ein spezielles VNet ist, das nur verwendet wird, um Datenverkehr von außerhalb eines Azure-VNet zu akzeptieren, wird die Kapselung von der Azure-Netzwerk fabric überprüft, um sicherzustellen, dass: a) der Endpunkt, der das Paket empfängt, eine Übereinstimmung mit der eindeutigen VNet-ID ist, die zum Weiterleiten der Daten verwendet wird, und b) die angeforderte Zieladresse in diesem VNet vorhanden ist. Nach der Überprüfung wird das Paket als interner Datenverkehr vom VNet-Gateway an die endgültige angeforderte Zieladresse innerhalb des VNet weitergeleitet. Dieser Ansatz stellt sicher, dass der Datenverkehr von externen Netzwerken nur zu Azure VNet führt, für das er bestimmt ist und die Isolation erzwingt.

Interner Verkehr (blaue Linie) – Interner Verkehr verwendet auch GRE-Kapselung/Tunneling. Wenn zwei Ressourcen in einem Azure VNet versuchen, die Kommunikation miteinander herzustellen, greift das Azure-Netzwerk-Gewebe auf den Azure-VNet-Routingverzeichnisdienst zu, der Teil des Azure-Netzwerk-Gewebes ist. Die Verzeichnisdienste verwenden die Kundenadresse (Customer Address, CA) und die angeforderte Zieladresse, um die Anbieteradresse (PA) zu ermitteln. Diese Informationen, einschließlich des VNet-Bezeichners, der Zertifizierungsstelle und der PA, werden dann verwendet, um den Datenverkehr mit GRE zu kapseln. Das Azure-Netzwerk verwendet diese Informationen, um die gekapselten Daten mithilfe der PA ordnungsgemäß an den entsprechenden Azure-Host weiterzuleiten. Die Kapselung wird von der Azure-Netzwerk-Fabric überprüft, um Folgendes zu bestätigen:

1. Die PA ist eine Übereinstimmung,
2. Die Zertifizierungsstelle befindet sich in dieser PA, und
3. Der VNet-Bezeichner ist eine Übereinstimmung.

Sobald alle drei überprüft wurden, wird die Kapselung entfernt und als normaler Datenverkehr an die Zertifizierungsstelle weitergeleitet, z. B. an einen VM-Endpunkt. Dieser Ansatz bietet die VNet-Isolationsüberprüfung basierend auf dem korrekten Datenverkehrsrouting zwischen Clouddiensten.

Azure VNets implementiert mehrere Mechanismen, um den sicheren Datenverkehr zwischen Mandanten sicherzustellen. Diese Mechanismen richten sich an bestehende Branchenstandards und Sicherheitspraktiken und verhindern bekannte Angriffsvektoren, darunter:

• Verhindern von IP-Adress-Spoofing – Immer wenn gekapselter Datenverkehr von einem VNet übertragen wird, überprüft der Dienst die Informationen an der Empfangsseite der Übertragung erneut. Der Datenverkehr wird unabhängig vom Anfang der Übertragung nachgeschlagen und gekapselt und am empfangenden Endpunkt erneut verkapselt, um sicherzustellen, dass die Übertragung ordnungsgemäß ausgeführt wurde. Diese Überprüfung erfolgt mit einem internen VNet-Feature namens „SpoofGuard“, das überprüft, ob die Quelle und das Ziel gültig sind und kommunizieren dürfe. Dadurch werden Konflikte in erwarteten Kapselungsmustern verhindert, die andernfalls Spoofing zulassen könnten. Die GRE-Kapselungsprozesse verhindern Spoofing, da jede GRE-Kapselung und Verschlüsselung, die nicht von der Azure-Netzwerk fabric durchgeführt wird, als verworfener Datenverkehr behandelt wird.
• Bereitstellen der Netzwerksegmentierung für Kunden mit überlappenden Netzwerkplätzen – Die Implementierung von Azure VNet basiert auf etablierten Tunnelingstandards wie der GRE, die wiederum die Verwendung von kundenspezifischen eindeutigen IDs (VNet-IDs) in der gesamten Cloud ermöglicht. Die VNet-IDs werden als Bereichsbezeichner verwendet. Mit diesem Ansatz wird sichergestellt, dass Sie immer innerhalb Ihres eindeutigen Adressraums arbeiten und Adressräume zwischen Mandanten und dem Azure-Netzwerk-Fabric überlappen. Alles, was nicht mit einer gültigen VNet-ID gekapselt wurde, wird innerhalb der Azure-Netzwerk fabric blockiert. Im zuvor beschriebenen Beispiel wird jeglicher gekapselter Datenverkehr, der nicht vom Azure-Netzwerk-Fabric geführt wird, verworfen.
• Verhindern Sie, dass Netzwerkverkehr zwischen VNets fließt – Das Blockieren des Überquerens von Netzwerkverkehr zwischen VNets erfolgt durch die gleichen Mechanismen, die Adressüberlappungen behandeln und Spoofing verhindern. Zwischen VNets übertragener Datenverkehr wird durch Verwendung eindeutiger VNet-IDs, die pro Mandant eingerichtet wurden, in Kombination mit der Überprüfung des gesamten Datenverkehrs an der Quelle und am Ziel unmöglich gemacht. Benutzer haben keinen Zugriff auf die zugrunde liegenden Übertragungsmechanismen, die auf diese IDs angewiesen sind, um die Kapselung durchzuführen. Daher würde jeder Versuch, diese Mechanismen zu kapseln und zu simulieren, zu verworfenen Datenverkehr führen.

Zusätzlich zu diesen Schlüsselschutzfunktionen wird standardmäßig der gesamte unerwartete Datenverkehr, der aus dem Internet stammt, gelöscht. Jedes Paket, das in das Azure-Netzwerk eintritt, trifft zuerst auf einen Edgerouter. Edge-Router lassen absichtlich allen eingehenden Datenverkehr in das Azure-Netzwerk zu, außer spooften Datenverkehr. Diese grundlegende Datenverkehrsfilterung schützt das Azure-Netzwerk vor bekanntem schädlichem Datenverkehr. Azure implementiert auch den DDoS-Schutz auf der Netzwerkebene, das Sammeln von Protokollen zum Drosseln oder Blockieren von Datenverkehr basierend auf Echtzeit- und historischen Datenanalysen und verringert Angriffe bei Bedarf.

Darüber hinaus blockiert das Azure-Netzwerk-Fabric Datenverkehr von allen IPs, die aus dem Azure-Netzwerk-Fabric-Bereich stammen und gefälscht sind. Die Azure-Netzwerk-Fabric nutzt GRE und Virtual Extensible LAN (VXLAN), um zu überprüfen, ob der gesamte zulässige Datenverkehr Azure-kontrollierter Datenverkehr ist und aller nicht-Azure GRE-Datenverkehr blockiert wird. Durch die Verwendung von GRE-Tunneln und VXLAN zum Segmentieren von Datenverkehr mithilfe von kunden eindeutigen Schlüsseln erfüllt Azure RFC 3809 und RFC 4110. Bei Verwendung des Azure VPN-Gateways in Kombination mit ExpressRoute trifft Azure RFC 4111 und RFC 4364. Mit einem umfassenden Ansatz zur Isolierung, der den externen und internen Netzwerkdatenverkehr umfasst, bietet Azure VNets Sicherheit, dass Azure den Datenverkehr erfolgreich zwischen VNets leitet, eine ordnungsgemäße Netzwerksegmentierung für Mandanten mit überlappenden Adressräumen zulässt und das Spoofing von IP-Adressen verhindert.

Sie können auch Azure-Dienste verwenden, um Ihre Ressourcen weiter zu isolieren und zu schützen. Mithilfe von Netzwerksicherheitsgruppen (NSGs), einem Feature von Azure Virtual Network, können Sie Datenverkehr nach Quell- und Ziel-IP-Adresse, Port und Protokoll über mehrere eingehende und ausgehende Sicherheitsregeln filtern – im Wesentlichen als verteilte virtuelle Firewall und IP-basierte Netzwerkzugriffssteuerungsliste (ACL). Sie können eine NSG auf jede NIC auf einem virtuellen Computer anwenden, eine NSG auf das Subnetz anwenden, mit dem eine NIC oder eine andere Azure-Ressource verbunden ist, und direkt auf einen Skalierungssatz für virtuelle Computer anwenden, sodass eine feinere Kontrolle über Ihre Infrastruktur ermöglicht wird.

Auf der Infrastrukturebene implementiert Azure eine Hypervisor-Firewall, um alle Mandanten vor unbefugtem Zugriff zu schützen, die in virtuellen Maschinen oberhalb des Hypervisors ausgeführt werden. Diese Hypervisorfirewall wird als Teil der für den Host bereitgestellten NSG-Regeln verteilt, im Hypervisor implementiert und vom Fabric Controller-Agent konfiguriert, wie in Abbildung 4 dargestellt. Die Instanzen des Hostbetriebssystems verwenden die integrierte Windows-Firewall, um differenzierte ACLs mit einer höheren Granularität als Router-ACLs zu implementieren. Sie werden von derselben Software verwaltet, die Mandanten bereitgestellt, sodass sie nie veraltet sind. Die feinkörnigen ACLs werden mithilfe der Computerkonfigurationsdatei (MACHINE Configuration File, MCF) auf die Windows-Firewall angewendet.

Am oberen Rand des Betriebssystemstapels befindet sich das Gastbetriebssystem, das Sie als Betriebssystem verwenden. Standardmäßig lässt diese Ebene keine eingehende Kommunikation mit Clouddienst oder virtuellem Netzwerk zu, wodurch sie im Wesentlichen Teil eines privaten Netzwerks ist. Für PaaS-Web- und Workerrollen ist der Remotezugriff standardmäßig nicht zulässig. Sie können den RDP-Zugriff (Remotedesktopprotokoll) als explizite Option aktivieren. Für IaaS-VMs, die mit dem Azure-Portal erstellt wurden, werden RDP- und Remote-PowerShell-Ports standardmäßig geöffnet. Portnummern werden jedoch zufällig zugewiesen. Für iaaS-VMs, die über PowerShell erstellt werden, müssen RDP- und Remote-PowerShell-Ports explizit geöffnet werden. Wenn sich der Administrator entscheidet, die RDP- und Remote-PowerShell-Ports im Internet zu öffnen, sollte das Konto, das RDP- und PowerShell-Verbindungen erstellen darf, mit einem sicheren Kennwort gesichert werden. Auch wenn Ports geöffnet sind, können Sie ACLs für die öffentlichen IPs für zusätzlichen Schutz definieren, falls gewünscht.

Diensttags

Sie können Virtual Network-Diensttags verwenden, um die Netzwerkisolation zu erreichen und Ihre Azure-Ressourcen vor dem Internet zu schützen, während Sie auf Azure-Dienste zugreifen, die öffentliche Endpunkte aufweisen. Mit Diensttags können Sie Netzwerkzugriffssteuerungen in Netzwerksicherheitsgruppen oder in der Azure Firewall definieren. Ein Diensttag steht für eine Gruppe von IP-Adresspräfixen aus einem bestimmten Azure-Dienst. Microsoft verwaltet die vom Dienst-Tag erfassten Adresspräfixe und aktualisiert den Dienst-Tag automatisch, wenn sich die Adressen ändern, wodurch die Komplexität häufiger Updates von Netzwerksicherheitsregeln reduziert wird.

Azure Private Link

Sie können private Links verwenden, um auf Azure PaaS-Dienste und von Azure gehostete Kunden-/Partnerdienste über einen privaten Endpunkt in Ihrem VNet zuzugreifen und sicherzustellen, dass der Datenverkehr zwischen Ihrem VNet und dem Dienst über das globale Backbone-Netzwerk von Microsoft übertragen wird. Dieser Ansatz beseitigt die Notwendigkeit, den Dienst für das öffentliche Internet verfügbar zu machen. Sie können auch Ihren eigenen privaten Linkdienst in Ihrem eigenen VNet erstellen und an Ihre Kunden übermitteln.

Der private Azure-Endpunkt ist eine Netzwerkschnittstelle, die Sie privat und sicher mit einem Dienst verbindet, der von privatem Link unterstützt wird. Ein privater Endpunkt verwendet eine private IP-Adresse in Ihrem VNET und bindet den Dienst so effektiv in das VNET ein.

Aus der Sicht der Netzwerkisolation sind die wichtigsten Vorteile von privatem Link:

• Sie können Ihr VNet mit Diensten in Azure ohne öffentliche IP-Adresse an der Quelle oder am Ziel verbinden. Private Link behandelt die Verbindung zwischen dem Dienst und seinen Verbrauchern über das globale Backbone-Netzwerk von Microsoft.
• Sie können auf Dienste zugreifen, die in Azure ausgeführt werden, über Azure ExpressRoute Private Peering vor Ort, VPN-Tunnel und gekoppelte virtuelle Netzwerke mit Hilfe von privaten Endpunkten. Private Link beseitigt die Notwendigkeit, Microsoft-Peering einzurichten oder das Internet zu durchlaufen, um den Dienst zu erreichen.
• Sie können private Verbindungen mit Diensten herstellen, die in anderen Azure-Regionen ausgeführt werden.

Datenverschlüsselung während der Übertragung

Azure bietet viele Optionen zum Verschlüsseln von in Übertragung begriffenen Daten. Die Datenverschlüsselung während der Übertragung isoliert Ihren Netzwerkdatenverkehr von anderen Datenverkehr und schützt Daten vor Abfangen. In Übertragung begriffene Daten gelten für Szenarien, in denen Daten zwischen Folgendem übertragen werden:

• Ihre Endbenutzer und Ihr Azure-Dienst
• Ihr lokales Rechenzentrum und Ihre Azure-Region
• Microsoft-Rechenzentren als Teil des erwarteten Azure-Dienstvorgangs

Verbindung des Endbenutzers mit dem Azure-Dienst

Transport Layer Security (TLS) – Azure verwendet das TLS-Protokoll, um Daten zu schützen, wenn sie zwischen Ihren Endbenutzern und Azure-Diensten unterwegs sind. Die meisten Ihrer Endbenutzer stellen eine Verbindung mit Azure über das Internet her, und das genaue Routing des Netzwerkdatenverkehrs hängt von den vielen Netzwerkanbietern ab, die zur Internetinfrastruktur beitragen. Wie im Zusatz zum Datenschutz von Microsoft-Produkten und -Diensten (Data Protection Addendum, DPA) angegeben, steuert oder beschränkt Microsoft nicht die Regionen, aus denen Sie oder Ihre Endbenutzer auf Kundendaten zugreifen oder diese verschieben können.

Über Azure-Dienste hinweg wird Datenverkehr zu und vom Dienst durch TLS 1.2 mit RSA-2048 für den Schlüsselaustausch und AES-256 für die Datenverschlüsselung geschützt. Die entsprechenden Kryptomodule werden im Rahmen des Microsoft Windows-FIPS-Validierungsprogramms FIPS 140 -validiert.

TLS bietet eine sichere Authentifizierung, Nachrichtendatenschutz und Integrität. Perfect Forward Secrecy (PFS) schützt Verbindungen zwischen Ihren Clientsystemen und Microsoft-Clouddiensten, indem für jede von Ihnen initiierte Sitzung ein eindeutiger Sitzungsschlüssel generiert wird. PFS schützt vergangene Sitzungen vor potenziellen zukünftigen Schlüsselkompromittierungen. Diese Kombination erschwert das Abfangen von und Zugreifen auf in Übertragung begriffenen Daten.

Verschlüsselung während der Übertragung für virtuelle Computer – Remotesitzungen für Windows- und Linux-VMs, die in Azure bereitgestellt werden, können über Protokolle durchgeführt werden, die die Datenverschlüsselung während der Übertragung sicherstellen. Beispielsweise ermöglicht das Remotedesktopprotokoll (RDP), das von Ihrem Clientcomputer an Windows- und Linux-VMs initiiert wurde, TLS-Schutz für in Übertragung begriffene Daten. Sie können auch Secure Shell (SSH) verwenden, um eine Verbindung mit Linux-VMs herzustellen, die in Azure ausgeführt werden. SSH ist ein verschlüsseltes Verbindungsprotokoll, das standardmäßig für die Remoteverwaltung von linux-VMs verfügbar ist, die in Azure gehostet werden.

Azure Storage-Transaktionen – Bei der Interaktion mit Azure Storage über das Azure-Portal erfolgen alle Transaktionen über HTTPS. Darüber hinaus können Sie Ihre Speicherkonten so konfigurieren, dass Anforderungen nur von sicheren Verbindungen akzeptiert werden, indem Sie die Eigenschaft "Sichere Übertragung erforderlich" für das Speicherkonto festlegen. Die Option "Sichere Übertragung erforderlich" ist beim Erstellen eines Speicherkontos im Azure-Portal standardmäßig aktiviert.

Azure Files bietet vollständig verwaltete Dateifreigaben in der Cloud, auf die über Server Message Block (SMB), ein Protokoll nach Branchenstandard, zugegriffen werden kann. Standardmäßig sind alle Azure-Speicherkonten für die Übertragung verschlüsselungsfähig. Wenn Sie also eine Freigabe über SMB bereitstellen oder über das Azure-Portal (oder Azure PowerShell, Azure CLI und Azure SDKs) darauf zugreifen, lässt Azure Files die Verbindung nur zu, wenn sie mit SMB 3.0+ mit Verschlüsselung oder über HTTPS hergestellt wird.

Rechenzentrumsverbindung mit Azure-Region

VPN-Verschlüsselung – Virtual Network (VNet) bietet eine Möglichkeit für Azure Virtual Machines (VMs), die als Teil Ihres internen (lokalen) Netzwerks fungieren. Mit VNet wählen Sie die Adressbereiche von nicht global routingfähigen IP-Adressen aus, die den virtuellen Computern zugewiesen werden sollen, damit sie nicht mit Adressen kollidieren, die Sie an anderer Stelle verwenden. Sie haben Optionen, um eine sichere Verbindung mit einem VNet über Ihre lokale Infrastruktur oder Remotestandorte herzustellen.

• Site-to-Site (IPsec/IKE VPN-Tunnel) – Ein kryptografisch geschützter "Tunnel" wird zwischen Azure und Ihrem internen Netzwerk hergestellt, sodass eine Azure-VM eine Verbindung mit Ihren Back-End-Ressourcen herstellen kann, als ob sie sich direkt in diesem Netzwerk befand. Für diese Art von Verbindung ist ein lokales VPN-Gerät erforderlich, das über eine öffentlich zugängliche öffentliche IP-Adresse verfügt, die ihm zugewiesen ist. Sie können azure VPN-Gateway verwenden, um verschlüsselten Datenverkehr zwischen Ihrem VNet und Ihrer lokalen Infrastruktur über das öffentliche Internet zu senden, z. B. ein Standort-zu-Standort-VPN , das IPsec für die Transportverschlüsselung verwendet. DAS VPN-Gateway unterstützt viele Verschlüsselungsalgorithmen, die FIPS 140 validiert sind. Darüber hinaus können Sie das VPN-Gateway so konfigurieren, dass benutzerdefinierte IPsec/IKE-Richtlinie mit bestimmten kryptografischen Algorithmen und Schlüsselstärken verwendet wird, anstatt sich auf die Standardmäßigen Azure-Richtlinien zu verlassen. IPsec verschlüsselt Daten auf der IP-Ebene (Network Layer 3).
• Point-to-Site (VPN over SSTP, OpenVPN und IPsec) – Eine sichere Verbindung wird von Ihrem einzelnen Clientcomputer mit Ihrem VNet mithilfe von Secure Socket Tunneling Protocol (SSTP), OpenVPN oder IPsec hergestellt. Im Rahmen der Point-to-Site-VPN-Konfiguration müssen Sie ein Zertifikat und ein VPN-Clientkonfigurationspaket installieren, mit dem der Clientcomputer eine Verbindung mit einem beliebigen virtuellen Computer im VNet herstellen kann. Point-to-Site-VPN-Verbindungen erfordern kein VPN-Gerät oder eine öffentlich zugängliche IP-Adresse.

Zusätzlich zur Steuerung des Algorithmustyps, der für VPN-Verbindungen unterstützt wird, bietet Azure die Möglichkeit, zu erzwingen, dass der gesamte Datenverkehr, der ein VNet verlässt, nur über ein VNet-Gateway weitergeleitet werden kann (z. B. Azure VPN-Gateway). Mit dieser Erzwingung können Sie sicherstellen, dass datenverkehr kein VNet verlassen kann, ohne verschlüsselt zu sein. Ein VPN-Gateway kann für VNet-zu-VNet-Verbindungen verwendet werden und gleichzeitig einen sicheren Tunnel mit IPsec/IKE bereitstellen. Azure VPN verwendet die PRE-Shared Key (PSK)-Authentifizierung , wobei Microsoft beim Erstellen des VPN-Tunnels die PSK generiert. Sie können die automatisch generierte PSK durch Ihre eigene ersetzen.

Azure ExpressRoute-Verschlüsselung – Mit Azure ExpressRoute können Sie private Verbindungen zwischen Microsoft-Rechenzentren und Ihrer lokalen Infrastruktur oder Colocation-Einrichtung erstellen. ExpressRoute-Verbindungen gehen nicht über das öffentliche Internet und bieten eine geringere Latenz und höhere Zuverlässigkeit als IPsec-geschützte VPN-Verbindungen. ExpressRoute-Standorte sind die Einstiegspunkte zum globalen Netzwerk-Backbone von Microsoft, und sie entsprechen möglicherweise oder nicht dem Standort von Azure-Regionen. Sobald der Netzwerkdatenverkehr in das Microsoft-Backbone wechselt, wird sichergestellt, dass diese private Netzwerkinfrastruktur anstelle des öffentlichen Internets durchquert wird. Sie können ExpressRoute mit mehreren Datenverschlüsselungsoptionen verwenden, einschließlich MACsec , mit denen Sie MACsec-Verschlüsselungsschlüssel in Azure Key Vault speichern können. MACsec verschlüsselt Daten auf der MAC-Ebene (Media Access Control), d. h. auf Datenverknüpfungsebene (Vermittlungsschicht 2). Sowohl AES-128- als auch AES-256-Blockverschlüsselungsverfahren werden für die Verschlüsselung unterstützt. Sie können MACsec verwenden, um die physischen Verbindungen zwischen Ihren Netzwerkgeräten und Microsoft-Netzwerkgeräten zu verschlüsseln, wenn Sie über ExpressRoute Direct eine Verbindung mit Microsoft herstellen. ExpressRoute Direct ermöglicht direkte Glasfaserverbindungen von Ihrem Edge zu den Microsoft Enterprise-Edgeroutern an den Peeringstandorten.

Sie können IPsec zusätzlich zu MACsec auf Ihren ExpressRoute Direct-Ports aktivieren, wie in Abbildung 11 dargestellt. Mithilfe des VPN-Gateways können Sie einen IPsec-Tunnel über Microsoft Peering Ihres ExpressRoute-Schaltkreises zwischen Ihrem lokalen Netzwerk und Ihrem Azure VNet einrichten. MACsec sichert die physische Verbindung zwischen Ihrem lokalen Netzwerk und Microsoft. IPsec sichert die End-to-End-Verbindung zwischen Ihrem lokalen Netzwerk und Ihren VNets in Azure. MACsec und IPsec können unabhängig voneinander aktiviert werden.

Abbildung 11. VPN- und ExpressRoute-Verschlüsselung für Daten während der Übertragung

Datenverkehr über das globale Microsoft-Netzwerk-Backbone

Azure-Dienste wie Speicher und SQL-Datenbank können für die Georeplikation konfiguriert werden, um die Haltbarkeit und hohe Verfügbarkeit insbesondere für Notfallwiederherstellungsszenarien zu gewährleisten. Azure basiert auf gekoppelten Regionen , um georedundanten Speicher (GRS) bereitzustellen, und gekoppelte Regionen werden auch empfohlen, wenn sie die aktive Georeplikation für Azure SQL-Datenbank konfigurieren. Gekoppelte Regionen befinden sich innerhalb derselben Geografie. Für den Netzwerkdatenverkehr wird jedoch nicht garantiert, dass er immer demselben Pfad von einer Azure-Region zu einer anderen folgt. Um die für die Azure-Cloud erforderliche Zuverlässigkeit bereitzustellen, verfügt Microsoft über viele physische Netzwerkpfade mit automatischem Routing um Ausfälle für eine optimale Zuverlässigkeit.

Darüber hinaus wird der gesamte Azure-Datenverkehr, der innerhalb einer Region oder zwischen Regionen unterwegs ist, von Microsoft mit MACsec verschlüsselt, der für die Verschlüsselung auf AES-128-Blockchiffre basiert. Dieser Datenverkehr bleibt vollständig innerhalb des globalen Microsoft-Netzwerk-Backbones und wechselt nie in das öffentliche Internet. Das Backbone ist eines der größten der Welt mit mehr als 250.000 km beleuchteten Glasfaser- und Unterseekabelsystemen.

Virtuelle Netzwerkgeräte von Drittanbietern

Azure bietet Ihnen viele Features, mit denen Sie Ihre Sicherheits- und Isolationsziele erreichen können, einschließlich Microsoft Defender für Cloud, Azure Monitor, Azure Firewall, VPN-Gateway, Netzwerksicherheitsgruppen, Anwendungsgateway, Azure DDoS Protection, Netzwerküberwachung, Microsoft Sentinel und Azure-Richtlinie. Zusätzlich zu den integrierten Funktionen, die Azure bereitstellt, können Sie virtuelle Geräte von Drittanbietern verwenden, um Ihre spezifischen Netzwerkisolationsanforderungen zu erfüllen und gleichzeitig vorhandene interne Fähigkeiten anzuwenden. Azure unterstützt viele Appliances, darunter Angebote von F5, Palo Alto Networks, Cisco, Check Point, Barracuda, Citrix, Fortinet und vielen anderen. Netzwerkgeräte unterstützen Netzwerkfunktionen und -dienste in Form von virtuellen Computern in Ihren virtuellen Netzwerken und Bereitstellungen.

Die kumulierte Auswirkung von Netzwerkisolationsbeschränkungen besteht darin, dass jeder Clouddienst so agiert, als ob er sich in einem isolierten Netzwerk verhält, in dem VMs innerhalb des Clouddiensts miteinander kommunizieren können, wobei er von seinen Quell-IP-Adressen mit dem Vertrauen identifiziert wird, dass keine anderen Parteien ihre Peer-VMs imitieren können. Sie können auch so konfiguriert werden, dass eingehende Verbindungen aus dem Internet über bestimmte Ports und Protokolle akzeptiert werden, und um sicherzustellen, dass der gesamte Netzwerkdatenverkehr, der Ihre virtuellen Netzwerke verlässt, immer verschlüsselt ist.

Speicherisolation

Microsoft Azure trennt Ihre VM-basierten Computeressourcen vom Speicher als Teil des grundlegenden Designs. Durch die Trennung können Rechenleistung und Speicher unabhängig voneinander skaliert werden, wodurch mehrinstanzenfähige Umgebungen und Isolation leichter bereitgestellt werden können. Aus diesem Grund wird Azure Storage auf separater Hardware ohne Netzwerkverbindung mit Azure Compute (außer auf logischer Ebene) ausgeführt.

Jedes Azure-Abonnement kann über ein oder mehrere Speicherkonten verfügen. Azure Storage unterstützt verschiedene Authentifizierungsoptionen, darunter:

• Gemeinsam genutzte symmetrische Schlüssel – Bei der Erstellung von Speicherkonten generiert Azure zwei 512-Bit-Speicherkontoschlüssel, die den Zugriff auf das Speicherkonto steuern. Sie können diese Tasten jederzeit drehen und neu generieren, ohne dass sie mit Ihren Anwendungen koordiniert werden.
• Microsoft Entra ID-basierte Authentifizierung – Der Zugriff auf Azure Storage kann durch Die Microsoft Entra-ID gesteuert werden, die die Mandantenisolation erzwingt und robuste Maßnahmen implementiert, um den Zugriff durch nicht autorisierte Parteien, einschließlich Microsoft-Insider, zu verhindern. Weitere Informationen zur Microsoft Entra-Mandantenisolation finden Sie in einem Whitepaper zu Microsoft Entra Data Security Überlegungen.
• Freigegebene Zugriffssignaturen (SAS) – Freigegebene Zugriffssignaturen oder "vorsignierte URLs" können aus den freigegebenen symmetrischen Schlüsseln erstellt werden. Diese URLs können im Umfang erheblich eingeschränkt werden, um die verfügbare Angriffsfläche zu reduzieren, aber gleichzeitig Anwendungen erlauben, Speicherzugriff auf einen anderen Benutzer, Dienst oder Gerät zu gewähren.
• Sas der Benutzerdelegierung – Delegierte Authentifizierung ähnelt SAS, basiert jedoch auf Microsoft Entra-Token und nicht auf den gemeinsam genutzten symmetrischen Schlüsseln. Dieser Ansatz ermöglicht es einem Dienst, der sich mit Microsoft Entra-ID authentifiziert, eine vorsignierte URL mit eingeschränktem Umfang zu erstellen und temporären Zugriff auf einen anderen Benutzer, Dienst oder Gerät zu gewähren.
• Anonymer öffentlicher Lesezugriff – Sie können zulassen, dass ein kleiner Teil Ihres Speichers ohne Authentifizierung oder Autorisierung öffentlich zugänglich ist. Diese Funktion kann auf Abonnementebene deaktiviert werden, wenn Sie eine strengere Kontrolle wünschen.

Azure Storage bietet Speicher für eine Vielzahl von Workloads, darunter:

• Virtuelle Azure-Computer (Datenträgerspeicher)
• Big Data Analytics (HDFS für HDInsight, Azure Data Lake Storage)
• Speichern des Anwendungszustands, Benutzerdaten (Blob, Warteschlange, Tabellenspeicher)
• Langfristiger Datenspeicher (Azure Archive Storage)
• Netzwerkdateifreigaben in der Cloud (Dateispeicher)
• Bedienen von Webseiten im Internet (statische Websites)

Azure Storage unterstützt zwar viele unterschiedliche, extern zugängliche Kundenspeicherszenarien intern, der physische Speicher für die oben genannten Dienste wird jedoch von einer gemeinsamen Gruppe von APIs verwaltet. Um Haltbarkeit und Verfügbarkeit zu gewährleisten, basiert Azure Storage auf Datenreplikation und Datenpartitionierung über Speicherressourcen hinweg, die von Mandanten gemeinsam genutzt werden. Um die kryptografische Sicherheit der logischen Datenisolation sicherzustellen, basiert Azure Storage auf der ruhenden Datenverschlüsselung mithilfe erweiterter Algorithmen mit mehreren Verschlüsselungen, wie in diesem Abschnitt beschrieben.

Datenreplikation

Ihre Daten in einem Azure Storage-Konto werden immer repliziert , um die Haltbarkeit und hohe Verfügbarkeit sicherzustellen. Azure Storage kopiert Ihre Daten, um sie vor vorübergehenden Hardwarefehlern, Netzwerk- oder Stromausfällen und sogar massiven Naturkatastrophen zu schützen. Sie können ihre Daten in der Regel innerhalb desselben Rechenzentrums, über Verfügbarkeitszonen innerhalb derselben Region oder über geografisch getrennte Regionen replizieren. Insbesondere können Sie beim Erstellen eines Speicherkontos eine der folgenden Redundanzoptionen auswählen:

• Lokal redundanter Speicher (LRS) repliziert drei Kopien (oder die entsprechungscodierte Löschung, wie später beschrieben) Ihrer Daten in einem einzigen Rechenzentrum. Eine Schreibanforderung an ein LRS-Speicherkonto wird erst erfolgreich zurückgegeben, nachdem die Daten in alle drei Replikate geschrieben wurden. Jedes Replikat befindet sich in separaten Fehler- und Upgradedomänen innerhalb einer Skalierungseinheit (Satz von Speichergestellen innerhalb eines Rechenzentrums).
• Zonenredundanter Speicher (ZRS) repliziert Ihre Daten synchron über drei Speichercluster in einer einzelnen Region. Jeder Speichercluster wird physisch von den anderen getrennt und befindet sich in seiner eigenen Verfügbarkeitszone (AZ ). Eine Schreibanforderung an ein ZRS-Speicherkonto wird erst dann erfolgreich zurückgegeben, nachdem die Daten in alle Replikate in allen drei Clustern geschrieben wurden.
• Georedundanter Speicher (GRS) repliziert Ihre Daten in eine sekundäre (gekoppelte) Region , die Hunderte von Kilometern von der primären Region entfernt ist. GRS-Speicherkonten sind auch bei einem vollständigen regionalen Ausfall oder einer Katastrophe dauerhaft, in der die primäre Region nicht wiederhergestellt werden kann. Für ein Speicherkonto, bei dem GRS oder RA-GRS aktiviert ist, werden alle Daten zuerst mit LRS repliziert. Ein Update wird zuerst an den primären Speicherort übernommen und mithilfe von LRS repliziert. Das Update wird dann asynchron mit GRS in die sekundäre Region repliziert. Wenn Daten in den sekundären Speicherort geschrieben werden, werden sie dort auch mit LRS repliziert.
• Lesezugriff georedundanter Speicher (RA-GRS) basiert auf GRS. Sie bietet schreibgeschützten Zugriff auf die Daten am sekundären Standort und die Georeplikation in zwei Regionen. Mit RA-GRS können Sie auf Daten aus der sekundären Region zugreifen, unabhängig davon, ob Microsoft ein Failover von der primären zur sekundären Region initiiert.
• Geozonenredundanter Speicher (GZRS) kombiniert die hohe Verfügbarkeit von ZRS mit dem Schutz vor regionalen Ausfällen, wie von GRS bereitgestellt. Daten in einem GZRS-Speicherkonto werden in drei AZs in der primären Region repliziert und auch in eine sekundäre geografische Region repliziert, um den Schutz vor regionalen Katastrophen zu gewährleisten. Jede Azure-Region wird mit einer anderen Region innerhalb derselben Geografie gekoppelt und bildet zusammen ein regionales Paar.
• Lesezugriff geozonenredundanter Speicher (RA-GZRS) basiert auf GZRS. Sie können optional den Lesezugriff auf Daten in der sekundären Region mit RA-GZRS aktivieren, wenn Ihre Anwendungen daten nach einem Notfall in der primären Region lesen müssen.

Übergeordnete Azure Storage-Architektur

Azure Storage-Produktionssysteme bestehen aus Speicherstempeln und dem Standortdienst (Location Service, LS), wie in Abbildung 12 dargestellt. Ein Speicherstempel ist ein Cluster von Racks der Speicherknoten, bei dem jedes Rack als separate Fehlerdomäne mit redundantem Netzwerk und redundanter Stromversorgung erstellt wird. Der LS verwaltet alle Speicherstempel und den Kontonamespace für alle Stempel. Er weist Konten Speicherstempeln zu und verwaltet sie über die Speicherstempel für den Lastenausgleich und die Notfallwiederherstellung. Der LS selbst wird an zwei geografischen Standorten für seine eigene Notfallwiederherstellung verteilt (Calder, et al., 2011).

Abbildung 12. Allgemeine Azure Storage-Architektur (Quelle: Calder, et al., 2011)

Es gibt drei Ebenen innerhalb eines Speicherstempels: Front-End, Partition und Stream. Diese Ebenen werden im restlichen Abschnitt beschrieben.

Front-End-Ebene

Die Front-End-Ebene (FE) besteht aus einer Reihe zustandsloser Server, die die eingehenden Anforderungen übernehmen, die Anforderungen authentifizieren und autorisieren und diese dann an einen Partitionsserver in der Partitionsebene weiterleiten. Die FE-Ebene weiß, an welchen Partitionsserver jede Anforderung weitergeleitet werden soll, da jeder Front-End-Server eine Partitionszuordnung zwischenspeichert. Die Partitionszuordnung verfolgt die Partitionen für den Dienst, auf den zugegriffen wird und welcher Partitionsserver den Zugriff auf jede Partition im System steuert (bedient). Die FE-Server streamen auch große Objekte direkt von der Datenstromebene.

Das Übertragen großer Datenmengen über das Internet ist grundsätzlich unzuverlässig. Mithilfe des Azure Block Blobs-Diensts können Sie große Dateien effizient hochladen und speichern, indem Sie große Dateien in kleinere Datenblöcke aufteilen. Auf diese Weise ermöglichen Block-Blobs die Partitionierung von Daten in einzelne Blöcke zur Zuverlässigkeit großer Uploads, wie in Abbildung 13 dargestellt. Jeder Block kann bis zu 100 MB groß sein, mit bis zu 50.000 Blöcken im Block-BLOB. Wenn ein Block nicht ordnungsgemäß übertragen werden kann, muss nur dieser bestimmte Block erneut übertragen werden, anstatt die gesamte Datei erneut senden zu müssen. Darüber hinaus können mit einem Block-BLOB mehrere Blöcke parallel gesendet werden, um die Uploadzeit zu verringern.

Figure 13. Blockieren der Blobpartitionierung von Daten in einzelne Blöcke

Sie können Blöcke in beliebiger Reihenfolge hochladen und deren Reihenfolge im letzten Blocklistenbindungsschritt bestimmen. Sie können auch einen neuen Block hochladen, um einen vorhandenen nicht bestätigten Block derselben Block-ID zu ersetzen.

Partitionsebene

Die Partitionsebene ist für Folgendes verantwortlich:

• Verwalten von Datenabstraktionen auf höherer Ebene (Blob, Tabelle, Warteschlange),
• Bereitstellen eines skalierbaren Objektnamespaces,
• Bereitstellung von Transaktionsreihenfolge und starker Konsistenz für Objekte,
• Speichern von Objektdaten über der Datenstromebene und
• Zwischenspeichern von Objektdaten, um Datenträger-E/A zu reduzieren.

Diese Ebene bietet auch eine asynchrone Georeplikation von Daten und konzentriert sich auf die Replikation von Daten über Stempel hinweg. Die Replikation zwischen Stempeln erfolgt im Hintergrund, um eine Kopie der Daten an zwei Standorten für Notfallwiederherstellungszwecke beizubehalten.

Sobald ein Blob von der FE-Ebene aufgenommen wird, ist die Partitionsebene dafür verantwortlich, nachzuverfolgen und zu speichern, wo Daten in der Datenstromebene abgelegt werden. Jeder Speichermandant kann ca. 200 - 300 einzelne Partitionsebenenknoten aufweisen, und jeder Knoten ist für die Nachverfolgung und Bereitstellung einer Partition der in diesem Speichermandanten gespeicherten Daten verantwortlich. Mit dem Hochdurchsatz-Feature für Blockblobs (HTBB) können Daten innerhalb eines einzelnen Blobs partitioniert werden, wodurch die Arbeitslast großer Blobs auf mehreren Servern der Partitionsebene verteilt werden kann (Abbildung 14). Durch die Verteilung der Last zwischen mehreren Partitionsebenenservern wird die Verfügbarkeit, der Durchsatz und die Haltbarkeit erheblich verbessert.

Abbildung 14. Block-Blobs mit hohem Durchsatz verteilen Datenverkehr und Daten auf mehrere Partitionsserver und Datenströme

Streamebene

Die Datenstromschicht speichert die Bits auf dem Datenträger und ist für die Verteilung und Replikation der Daten auf vielen Servern verantwortlich, um daten dauerhaft in einem Speicherstempel zu halten. Sie fungiert als verteilte Dateisystemebene innerhalb eines Stempels. Es verarbeitet Dateien, sogenannte Streams, die sortierte Listen von Datenblöcken darstellen und sogenannten Bereichen auf physischen Festplatten entsprechen. Große Blobobjekte können in mehreren Blöcken gespeichert werden, möglicherweise auf mehreren physischen Blockknoten (ENs). Die Daten werden auf der Datenstromebene gespeichert, aber über die Partitionsebene kann darauf zugegriffen werden. Partitionsserver und Datenstromserver befinden sich auf jedem Speicherknoten in einem Stempel.

Die Datenstromschicht stellt eine synchrone Replikation (im Stempel) über verschiedene Knoten in verschiedenen Fehlerdomänen bereit, um Daten dauerhaft innerhalb des Stempels zu halten. Sie ist für die Erstellung der drei lokal replizierten Kopien jedes Blocks verantwortlich. Der Datenstromschicht-Manager stellt sicher, dass alle drei Kopien auf verschiedene physische Racks und Knoten verteilt werden, die sich in unterschiedlichen Fehler- und Upgradedomänen befinden, sodass sie fehlertolerant gegenüber einzelnen Festplatten-, Knoten- oder Rackausfällen und geplanten Ausfallzeiten aufgrund von Upgrades sind.

Erasure Coding – Azure Storage verwendet eine Technik namens "Erasure Coding", die die Wiederherstellung von Daten ermöglicht, auch wenn einige der Daten aufgrund von Datenträgerfehlern fehlen. Dieser Ansatz ähnelt dem Konzept der RAID-Striping für einzelne Datenträger, bei denen Daten über mehrere Datenträger verteilt werden, sodass die fehlenden Daten mithilfe der Paritätsbits aus den Daten auf den anderen Datenträgern wiederhergestellt werden können. Bei Erasure Coding wird ein Block in gleiche Daten- und Paritätsfragmente aufgeteilt, die auf separaten ENs gespeichert sind, wie in Abbildung 15 dargestellt.

Abbildung 15. Erasure Coding verteilt weitere Blockdaten über EN-Server, um Daten vor Fehlern zu schützen.

Alle in Erweiterungsknoten gespeicherten Datenblöcke verfügen über eine 64-Bit-zyklische Redundanzprüfung (CRC) und einen Header, der durch eine Hashsignatur geschützt ist, um die Datenintegrität der Erweiterungsknoten (EN) zu gewährleisten. Das CRC und die Signatur werden vor jedem Datenträgerschreib-, Datenträgerlese- und Netzwerkzugriff überprüft. Darüber hinaus verarbeitet die Bereinigung alle Daten in regelmäßigen Abständen, um CRC zu überprüfen und nach Datenverfall zu suchen. Wenn ein schlechtes Ausmaß gefunden wird, wird eine neue Kopie dieses Umfangs erstellt, um das schlechte Ausmaß zu ersetzen.

Ihre Daten in Azure Storage basieren auf der ruhenden Datenverschlüsselung, um kryptografische Sicherheit für die logische Datenisolation zu gewährleisten. Sie können zwischen von Microsoft verwalteten Verschlüsselungsschlüsseln (auch als plattformverwaltete Verschlüsselungsschlüssel bezeichnet) oder zwischen vom Kunden verwalteten Verschlüsselungsschlüsseln (CMK) wählen. Die Verarbeitung von Datenverschlüsselung und -entschlüsselung ist für Kunden transparent, wie im nächsten Abschnitt erläutert.

Datenverschlüsselung ruhender Daten

Azure bietet umfangreiche Optionen für die ruhende Datenverschlüsselung , um Ihre Daten zu schützen und Ihre Complianceanforderungen bei der Verwendung von von Microsoft verwalteten Verschlüsselungsschlüsseln und vom Kunden verwalteten Verschlüsselungsschlüsseln zu erfüllen. Weitere Informationen finden Sie unter Datenverschlüsselungsmodelle. Dieser Prozess basiert auf mehreren Verschlüsselungsschlüsseln und Diensten wie Azure Key Vault und Microsoft Entra ID, um sicheren Schlüsselzugriff und zentrale Schlüsselverwaltung sicherzustellen.

Im Allgemeinen erfolgt die Steuerung des Zugriffs auf Schlüssel und die Sicherstellung einer effizienten Massenverschlüsselung und Entschlüsselung von Daten über die folgenden Verschlüsselungsschlüsseltypen (wie in Abbildung 16 dargestellt), obwohl andere Verschlüsselungsschlüssel verwendet werden können, wie im Abschnitt zur Verschlüsselung des Speicherdiensts beschrieben.

• Der Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) ist ein symmetrischer AES-256-Schlüssel, der für die Massenverschlüsselung und Entschlüsselung einer Partition oder eines Datenblocks verwendet wird. Die kryptografischen Module sind FIPS 140 als Teil des Windows FIPS-Validierungsprogramms validiert. Der Zugriff auf DEKs wird vom Ressourcenanbieter oder der Anwendungsinstanz benötigt, der für das Verschlüsseln und Entschlüsseln eines bestimmten Datenblocks verantwortlich ist. Eine einzelne Ressource verfügt möglicherweise über viele Partitionen und viele DEKs. Wenn ein DEK durch einen neuen Schlüssel ersetzt wird, müssen nur die Daten im verknüpften Block erneut mit dem neuen Schlüssel verschlüsselt werden. Die DEK wird immer durch den Schlüsselverschlüsselungsschlüssel (KEY Encryption Key, KEK) verschlüsselt gespeichert.
• Schlüsselverschlüsselungsschlüssel (KEY Encryption Key, KEK) ist ein asymmetrischer RSA-Schlüssel, der optional von Ihnen bereitgestellt wird. Dieser Schlüsselverschlüsselungsschlüssel wird verwendet, um den Datenverschlüsselungsschlüssel (Data Encryption Key Key, DEK) mit Azure Key Vault oder verwaltetem HSM zu verschlüsseln. Wie bereits im Abschnitt " Datenverschlüsselungsschlüsselverwaltung " erwähnt, kann Azure Key Vault FIPS 140-validierte Hardwaresicherheitsmodule (HARDWARE Security Modules, HSMs) verwenden, um Verschlüsselungsschlüssel zu schützen; Verwaltetes HSM verwendet immer FIPS 140-validierte Hardwaresicherheitsmodule. Diese Schlüssel sind nicht exportierbar und es kann keine Klartextversion des KEK außerhalb der HSMs geben – die Bindung wird vom zugrunde liegenden HSM erzwungen. KEK wird niemals direkt dem Ressourcenanbieter oder anderen Diensten verfügbar gemacht. Der Zugriff auf KEK wird durch Berechtigungen im Azure Key Vault gesteuert, und der Zugriff auf Azure Key Vault muss über die Microsoft Entra-ID authentifiziert werden. Diese Berechtigungen können widerrufen werden, um den Zugriff auf diesen Schlüssel und damit auch auf die Daten zu blockieren, die mit diesem Schlüssel als Wurzel der Schlüsselkette verschlüsselt wurden.

Abbildung 16 gespeicherten Schlüssel verschlüsselt. Datenverschlüsselungsschlüssel werden mit Ihrem im Azure Key Vault gespeicherten Schlüssel verschlüsselt.

Daher umfasst die Verschlüsselungsschlüsselhierarchie sowohl DEK als auch KEK. DEK wird mit KEK verschlüsselt und separat für den effizienten Zugriff durch Ressourcenanbieter in Massenverschlüsselungs- und Entschlüsselungsvorgängen gespeichert. Allerdings kann nur eine Entität mit Zugriff auf das KEK die DEK entschlüsseln. Die Entität, die auf den KEK zugreifen kann, kann sich von der Entität unterscheiden, die den DEK erfordert. Da KEK zum Entschlüsseln von DEK erforderlich ist, ist KEK effektiv ein einzelner Punkt, mit dem DEK über die Löschung von KEK gelöscht werden kann.

Detaillierte Informationen zu verschiedenen Datenverschlüsselungsmodellen und Spezifischen zur Schlüsselverwaltung für viele Azure-Plattformdienste finden Sie in der Onlinedokumentation. Darüber hinaus stellen einige Azure-Dienste andere Verschlüsselungsmodelle bereit, einschließlich clientseitiger Verschlüsselung, um ihre Daten mithilfe präziserer Steuerelemente weiter zu verschlüsseln. Der Rest dieses Abschnitts befasst sich mit der Verschlüsselungsimplementierung für wichtige Azure-Speicherszenarien wie die Verschlüsselung des Speicherdiensts und die Datenträgerverschlüsselung für virtuelle IaaS-Computer.

Verschlüsselung des Speicherdiensts

Die Azure Storage-Dienstverschlüsselung für ruhende Daten stellt sicher, dass Daten automatisch verschlüsselt werden, bevor sie in Azure Storage beibehalten und vor dem Abruf entschlüsselt werden. Alle in Azure Storage geschriebenen Daten werden über die 256-Bit-AES-Verschlüsselung von FIPS 140 verschlüsselt, und die Verarbeitung von Verschlüsselung, Entschlüsselung und Schlüsselverwaltung in der Speicherdienstverschlüsselung ist für Kunden transparent. Standardmäßig steuert Microsoft die Verschlüsselungsschlüssel und ist für die Schlüsselrotation, Verwendung und den Zugriff verantwortlich. Schlüssel werden sicher gespeichert und in einem Microsoft-Schlüsselspeicher geschützt. Diese Option bietet Ihnen den größtmöglichen Komfort, da alle Azure Storage-Dienste unterstützt werden.

Sie können jedoch auch die Verschlüsselung mit Ihren eigenen Schlüsseln verwalten, indem Sie Folgendes angeben:

• Kundenseitig verwalteter Schlüssel für die Verwaltung der Azure Storage-Verschlüsselung, wobei der Schlüssel in Azure Key Vault gespeichert wird. Diese Option bietet Ihnen viel Flexibilität, um vom Kunden verwaltete Schlüssel zu erstellen, zu rotieren, zu deaktivieren und den Zugriff zu widerrufen. Sie müssen Azure Key Vault verwenden, um kundenseitig verwaltete Schlüssel zu speichern. Sowohl Schlüsseltresor als auch verwaltete HSMs werden unterstützt, wie zuvor im Abschnitt "Azure Key Vault " beschrieben.
• Vom Kunden bereitgestellter Schlüssel zum Verschlüsseln und Entschlüsseln von BLOB-Speicher nur, wobei der Schlüssel in Azure Key Vault oder in einem anderen Schlüsselspeicher in Ihrer lokalen Umgebung gespeichert werden kann, um die gesetzlichen Complianceanforderungen zu erfüllen. Mit vom Kunden bereitgestellten Schlüsseln können Sie einen Verschlüsselungsschlüssel mithilfe von BLOB-APIs als Teil von Lese- oder Schreibvorgängen an den Speicherdienst übergeben.

Die Verschlüsselung des Speicherdiensts ist für alle neuen und vorhandenen Speicherkonten standardmäßig aktiviert und kann nicht deaktiviert werden. Wie in Abbildung 17 dargestellt, verwendet der Verschlüsselungsprozess die folgenden Schlüssel, um die kryptografische Sicherheit der ruhenden Datenisolation sicherzustellen:

• Der Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) ist ein symmetrischer AES-256-Schlüssel, der für die Massenverschlüsselung verwendet wird und pro Speicherkonto in Azure Storage eindeutig ist. Sie wird vom Azure Storage-Dienst als Teil der Erstellung des Speicherkontos generiert und verwendet, um einen eindeutigen Schlüssel für jeden Datenblock abzuleiten. Der Speicherdienst verschlüsselt die DEK immer mithilfe des Stempelschlüssels oder eines Schlüsselverschlüsselungsschlüssels, wenn der Kunde die vom Kunden verwaltete Schlüsselverschlüsselung konfiguriert hat.
• Schlüsselverschlüsselungsschlüssel (KEY Encryption Key Key, KEK) ist ein asymmetrischer RSA-Schlüssel (2048 oder höher), der vom Kunden verwaltet wird und zum Verschlüsseln des Datenverschlüsselungsschlüssels (Data Encryption Key, DEK) mit Azure Key Vault oder verwaltetem HSM verwendet wird. Es wird nie direkt dem Azure Storage-Dienst oder anderen Diensten ausgesetzt.
• Stamp Key (SK) ist ein symmetrischer AES-256-Schlüssel, der von Azure Storage verwaltet wird. Dieser Schlüssel wird verwendet, um die DEK zu schützen, wenn kein vom Kunden verwalteter Schlüssel verwendet wird.

Diese Schlüssel schützen alle Daten, die in Azure Storage geschrieben werden, und bieten kryptografische Sicherheit für die logische Datenisolation in Azure Storage. Wie bereits erwähnt, ist die Azure Storage-Dienstverschlüsselung standardmäßig aktiviert und kann nicht deaktiviert werden.

Abbildung 17. Verschlüsselungsfluss für die Speicherdienstverschlüsselung

Speicherkonten werden unabhängig von ihrer Leistungsstufe (Standard oder Premium) und ihrem Bereitstellungsmodell (Azure Resource Manager oder klassisch) verschlüsselt. Alle Azure Storage-Redundanzoptionen unterstützen die Verschlüsselung, und alle Kopien eines Speicherkontos werden verschlüsselt. Alle Azure Storage-Ressourcen werden verschlüsselt, z. B. Blobs, Datenträger, Dateien, Warteschlangen und Tabellen. Objektmetadaten werden ebenfalls verschlüsselt.

Da die Datenverschlüsselung vom Speicherdienst ausgeführt wird, können Sie serverseitige Verschlüsselung mit CMK alle Betriebssystemtypen und -images für Ihre virtuellen Computer verwenden. Für Ihre Windows- und Linux IaaS-VMs bietet Azure auch azure Disk-Verschlüsselung, mit der Sie verwaltete Datenträger mit CMK innerhalb der Gast-VM oder EncryptionAtHost verschlüsseln können, die Datenträgerdaten direkt auf dem Host verschlüsselt, wie in den nächsten Abschnitten beschrieben. Die Azure Storage-Dienstverschlüsselung bietet auch eine doppelte Verschlüsselung ruhender Datenträgerdaten.

Azure Disk-Verschlüsselung

Die Azure Storage-Dienstverschlüsselung verschlüsselt die Seitenblobs, die Azure Virtual Machine-Datenträger speichern. Darüber hinaus können Sie optional die Azure Disk-Verschlüsselung verwenden, um Azure Windows - und Linux IaaS Virtual Machine-Datenträger zu verschlüsseln, um die Speicherisolation zu erhöhen und die kryptografische Sicherheit Ihrer in Azure gespeicherten Daten zu gewährleisten. Diese Verschlüsselung enthält verwaltete Datenträger, wie weiter unten in diesem Abschnitt beschrieben. Die Azure-Datenträgerverschlüsselung verwendet das Branchenstandard-BitLocker-Feature von Windows und das DM-Crypt-Feature von Linux, um betriebssystembasierte Volumeverschlüsselung bereitzustellen, die in Azure Key Vault integriert ist.

Die Laufwerkverschlüsselung über BitLocker und DM-Crypt ist ein Datenschutzfeature, das in das Betriebssystem integriert wird, und behebt die Bedrohungen des Datendiebstahls oder der Gefährdung durch verlorene, gestohlene oder unangemessen außer Betrieb genommene Computer. BitLocker und DM-Crypt bieten den meisten Schutz bei Verwendung mit einem Trusted Platform Module (TPM) Version 1.2 oder höher. Das TPM ist ein Mikrocontroller, der zur Sicherung der Hardware über integrierte kryptografische Schlüssel entwickelt wurde – es ist in der Regel auf neueren Computern vorinstalliert. BitLocker und DM-Crypt können diese Technologie verwenden, um die Schlüssel zu schützen, die zum Verschlüsseln von Datenträgervolumes und zur Bereitstellung der Integrität für den Computerstartprozess verwendet werden.

Bei verwalteten Datenträgern können Sie mit der Azure Disk-Verschlüsselung das Betriebssystem und die Datenträger verschlüsseln, die von einem virtuellen IaaS-Computer verwendet werden. Daten können jedoch nicht verschlüsselt werden, ohne zuerst das Betriebssystemvolume zu verschlüsseln. Die Lösung basiert auf Azure Key Vault, um die Datenträgerverschlüsselungsschlüssel in Schlüsseltresorn zu steuern und zu verwalten. Sie können Ihre eigenen Verschlüsselungsschlüssel bereitstellen, die in Azure Key Vault geschützt sind, um Ihre eigenen Schlüsselszenarien (BYOK) zu unterstützen, wie zuvor im Abschnitt zur Verwaltung von Datenverschlüsselungsschlüsseln beschrieben.

Die Azure Disk-Verschlüsselung unterstützt kein verwaltetes HSM oder einen lokalen Schlüsselverwaltungsdienst. Es können nur Schlüsseltresore verwendet werden, die vom Azure Key Vault-Dienst verwaltet werden, um kundenseitig verwaltete Verschlüsselungsschlüssel für Azure Disk Encryption zu schützen. Weitere Optionen für verwaltetes HSM finden Sie im Abschnitt “Verschlüsselung auf Host”.

Die Azure Disk-Verschlüsselung basiert auf zwei Verschlüsselungsschlüsseln für die Implementierung, wie zuvor beschrieben:

• Data Encryption Key (DEK) ist ein symmetrischer AES-256-Schlüssel, der zum Verschlüsseln von Betriebssystem- und Datenvolumes über BitLocker oder DM-Crypt verwendet wird. DEK selbst wird verschlüsselt und an einem internen Speicherort in der Nähe der Daten gespeichert.
• Schlüsselverschlüsselungsschlüssel (KEY Encryption Key, KEK) ist ein asymmetrischer RSA-2048-Schlüssel, der zum Verschlüsseln der Datenverschlüsselungsschlüssel verwendet wird. KEK wird in Azure Key Vault unter Ihrer Kontrolle aufbewahrt, einschließlich der Gewährung von Zugriffsberechtigungen über die Microsoft Entra-ID.

Die DEK, verschlüsselt mit dem KEK, wird separat gespeichert, und nur eine Entität mit Zugriff auf das KEK kann die DEK entschlüsseln. Der Zugriff auf das KEK wird von Azure Key Vault geschützt, wo Sie Ihre Schlüssel in FIPS 140-validierten Hardwaresicherheitsmodulen speichern können.

Bei Windows-VMs wählt die Azure Disk-Verschlüsselung die Verschlüsselungsmethode in BitLocker basierend auf der Version von Windows aus, z. B. XTS-AES 256-Bit für Windows Server 2012 oder höher. Diese Kryptomodule sind FIPS 140 als Teil des Microsoft Windows FIPS-Validierungsprogramms validiert. Für Linux-VMs verwendet die Azure-Diskverschlüsselung den Entschlüsselungsmodus aes-xts-plain64 mit einem 256-Bit-Volumemasterschlüssel, der FIPS 140 validiert ist und Teil der DM-Crypt-Validierung ist, die von Anbietern von Linux IaaS-VM-Images im Microsoft Azure Marketplace bezogen wird.

Serverseitige Verschlüsselung für verwaltete Datenträger

Von Azure verwaltete Datenträger sind Speichervolumes auf Blockebene, die von Azure verwaltet und mit virtuellen Azure Windows- und Linux-Computern verwendet werden. Sie vereinfachen die Datenträgerverwaltung für Azure IaaS-VMs, indem sie die Speicherkontoverwaltung transparent für Sie verarbeiten. Von Azure verwaltete Datenträger verschlüsseln Ihre Daten standardmäßig automatisch mithilfe der 256-Bit-AES-Verschlüsselung , die FIPS 140 überprüft wird. Für die Verschlüsselungsschlüsselverwaltung stehen Ihnen die folgenden Optionen zur Verfügung:

• Plattformverwaltete Schlüssel sind die Standardauswahl, die transparente Ruhedatenverschlüsselung für verwaltete Datenträger bereitstellt, wobei Schlüssel von Microsoft verwaltet werden.
• Mit vom Kunden verwalteten Schlüsseln können Sie ihre eigenen Schlüssel steuern, die in Azure Key Vault oder verwaltetes HSM importiert oder generiert werden können. Dieser Ansatz basiert auf zwei Schlüsselgruppen, wie zuvor beschrieben: DEK und KEK. DEK verschlüsselt die Daten mithilfe einer AES-256-basierten Verschlüsselung und wird wiederum von einem RSA KEK verschlüsselt, der in Azure Key Vault oder verwaltetem HSM gespeichert ist.

Kundenverwaltete Schlüssel (CMK) ermöglichen Ihnen die vollständige Kontrolle über Ihre Verschlüsselungsschlüssel. Sie können zugriff auf verwaltete Datenträger in Ihrem Azure Key Vault gewähren, damit Ihre Schlüssel zum Verschlüsseln und Entschlüsseln des DEK verwendet werden können. Sie können Ihre Schlüssel auch jederzeit deaktivieren oder den Zugriff auf verwaltete Datenträger widerrufen. Schließlich haben Sie die vollständige Kontrolle über die Schlüsselverwendung mit der Azure Key Vault-Überwachung, um sicherzustellen, dass nur verwaltete Datenträger oder andere autorisierte Ressourcen auf Ihre Verschlüsselungsschlüssel zugreifen.

Verschlüsselung auf dem Host

Die Verschlüsselung am Host arbeitet mit der serverseitigen Verschlüsselung zusammen, um sicherzustellen, dass die auf dem VM-Host gespeicherten Daten im Ruhezustand verschlüsselt sind und verschlüsselt zum Speicherdienst fließen. Der Server, auf dem Ihre VM gehostet wird, verschlüsselt Ihre Daten ohne Leistungsauswirkungen oder Anforderung für Code, der in Ihrer Gast-VM ausgeführt wird, und dass verschlüsselte Daten mithilfe der für die serverseitige Verschlüsselung konfigurierten Schlüssel in Azure Storage fließen. Weitere Informationen finden Sie unter Verschlüsselung am Host – End-to-End-Verschlüsselung für Ihre VM-Daten. Verschlüsselung auf Host mit CMK kann Schlüssel verwenden, die in verwaltetem HSM oder Key Vault gespeichert sind, genau wie die serverseitige Verschlüsselung für verwaltete Datenträger.

Sie haben immer die Kontrolle über Ihre Kundendaten in Azure. Sie können auf Ihre in Azure gespeicherten Kundendaten zugreifen, extrahieren und löschen. Wenn Sie Ihr Azure-Abonnement kündigen, führt Microsoft die erforderlichen Schritte aus, um sicherzustellen, dass Sie weiterhin Ihre Kundendaten besitzen. Ein häufiges Problem beim Löschen oder Kündigen des Abonnements ist, ob ein anderer Kunde oder Azure-Administrator auf Ihre gelöschten Daten zugreifen kann. In den folgenden Abschnitten wird erläutert, wie Datenlöschung, Aufbewahrung und Zerstörung in Azure funktionieren.

Löschen von Daten

Speicher wird nur mit geringem Abstand zugewiesen, was bedeutet, dass beim Erstellen eines virtuellen Datenträgers kein Speicherplatz für die gesamte Kapazität zugewiesen wird. Stattdessen wird eine Tabelle erstellt, in der Adressen des virtuellen Datenträgers Bereichen auf dem physischen Datenträger zugeordnet werden. Diese Tabelle ist anfänglich leer. Beim ersten Schreiben von Daten auf dem virtuellen Datenträger wird Speicherplatz auf dem physischen Datenträger zugewiesen, und ein Zeiger darauf wird in der Tabelle platziert. Weitere Informationen finden Sie unter Azure-Datensicherheit – Datenbereinigung und -leckage.

Wenn Sie eine Blob- oder Tabellenentität löschen, wird sie sofort aus dem Index gelöscht, der zum Suchen und Zugreifen auf die Daten am primären Speicherort verwendet wird, und dann erfolgt die Löschung asynchron bei der georeplikaten Kopie der Daten, wenn Sie einen georedundanten Speicher bereitgestellt haben. Am primären Speicherort können Sie sofort versuchen, auf das Blob oder die Entität zuzugreifen, und Sie werden es nicht in Ihrem Index finden, da Azure eine starke Konsistenz für die Löschung bietet. Sie können also direkt überprüfen, ob die Daten gelöscht wurden.

In Azure Storage sind alle Datenträgerschreibvorgänge sequenziell. Dieser Ansatz minimiert die Anzahl der Lesezugriffe auf den Datenträger, erfordert jedoch auch jedes Mal, wenn Objekte geschrieben werden, die Zeiger auf diese Objekte zu aktualisieren – neue Versionen von Zeigern werden ebenfalls sequenziell aktualisiert. Ein Nebeneffekt dieses Designs besteht darin, dass es nicht möglich ist, sicherzustellen, dass ein geheimer Schlüssel auf dem Datenträger verschwunden ist, indem er mit anderen Daten überschrieben wird. Die ursprünglichen Daten verbleiben auf dem Datenträger, und der neue Wert wird sequenziell geschrieben. Zeiger werden so aktualisiert, dass der gelöschte Wert nicht mehr gefunden werden kann. Sobald der Datenträger voll ist, muss das System jedoch neue Protokolle auf den Speicherplatz schreiben, der durch das Löschen alter Daten freigegeben wurde. Anstatt Protokolldateien direkt aus Datenträgersektoren zu zuordnen, werden Protokolldateien in einem Dateisystem mit NTFS erstellt. Ein Hintergrundthread, der auf Azure Storage-Knoten ausgeführt wird, gibt Speicherplatz frei, indem er die älteste Protokolldatei durchläuft, Blöcke kopiert, auf die immer noch von dieser ältesten Protokolldatei in die aktuelle Protokolldatei verwiesen wird, und alle Zeiger werden bei Bedarf aktualisiert. Anschließend wird die älteste Protokolldatei gelöscht. Daher gibt es zwei Kategorien von freiem Speicherplatz auf dem Datenträger: (1) Speicherplatz, den NTFS weiß, ist frei, wo neue Protokolldateien aus diesem Pool zugewiesen werden; und (2) Speicherplatz innerhalb dieser Protokolldateien, die Azure Storage kennt, ist frei, da keine aktuellen Zeiger darauf vorhanden sind.

Die Sektoren auf dem physischen Datenträger, der den gelöschten Daten zugeordnet ist, stehen sofort zur Wiederverwendung zur Verfügung und werden überschrieben, wenn der entsprechende Speicherblock zum Speichern anderer Daten wiederverwendet wird. Die Überschreibungszeit variiert je nach Datenträgerauslastung und -aktivität. Dieser Vorgang entspricht dem Vorgang eines protokollstrukturierten Dateisystems, bei dem alle Schreibvorgänge sequenziell auf den Datenträger geschrieben werden. Dieser Prozess ist nicht deterministisch und es gibt keine Garantie, wenn bestimmte Daten aus dem physischen Speicher entfernt werden. Wann genau gelöschte Daten überschrieben werden oder ob der entsprechende physische Speicherplatz einem anderen Kunden zugewiesen wird, ist für die Gewährleistung der Schlüsselisolation irrelevant, da garantiert ist, dass nach dem Löschen keine Daten wiederhergestellt werden können:

• Ein Kunde kann gelöschte Daten eines anderen Kunden nicht lesen.
• Wenn jemand versucht, eine Region auf einem virtuellen Datenträger zu lesen, in die noch nicht geschrieben wurde, ist für diese Region kein physischer Speicherplatz zugewiesen worden, daher würden nur Nullwerte zurückgegeben.

Kunden erhalten keinen direkten Zugriff auf den zugrunde liegenden physischen Speicher. Da Kundensoftware nur virtuelle Datenträger adressiert, gibt es keine Möglichkeit für einen anderen Kunden, eine Anfrage zum Lesen von oder Schreiben an eine physische Adresse auszudrücken, die Ihnen oder einer physischen Adresse zugewiesen ist, die kostenlos ist.

Konzeptionell gilt diese Begründung unabhängig von der Software, die Lese- und Schreibvorgänge verfolgt. Für Azure SQL-Datenbank ist es die SQL-Datenbanksoftware, die diese Erzwingung durchführt. Für Azure Storage ist es die Azure Storage-Software. Bei nicht dauerhaften Laufwerken einer virtuellen Maschine handelt es sich um den VHD-Verarbeitungscode des Hostbetriebssystems. Die Zuordnung von virtueller zu physischer Adresse erfolgt außerhalb des virtuellen Kundencomputers.

Schließlich, wie im Abschnitt Datenverschlüsselung im Ruhezustand beschrieben und in Abbildung 16 dargestellt, basiert die Verschlüsselungsschlüsselhierarchie auf dem Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK), der im Azure Key Vault unter Ihrer Kontrolle (das heißt, kundengesteuerter Schlüssel – CMK) aufbewahrt werden kann und zum Verschlüsseln des Datenverschlüsselungsschlüssels (DEK) verwendet wird, wodurch wiederum ruhende Daten mithilfe der symmetrischen AES-256-Verschlüsselung verschlüsselt werden. Daten in Azure Storage werden standardmäßig im Ruhezustand verschlüsselt, und Sie können sich dafür entscheiden, über Verschlüsselungsschlüssel unter Ihrer eigenen Kontrolle zu verfügen. Auf diese Weise können Sie auch den Zugriff auf Ihre in Azure gespeicherten Daten verhindern. Da KEK zum Entschlüsseln von DEK erforderlich ist, ist KEK zudem effektiv ein einzelner Punkt, mit dem DEK über die Löschung von KEK gelöscht werden kann.

Beibehaltung von Daten

Während der Laufzeit Ihres Azure-Abonnements haben Sie immer die Möglichkeit, auf Ihre in Azure gespeicherten Daten zuzugreifen, sie zu extrahieren und zu löschen.

Wenn Ihr Abonnement abläuft oder beendet wird, behält Microsoft Ihre Kundendaten für einen Aufbewahrungszeitraum von 90 Tagen bei, damit Sie Ihre Daten extrahieren oder Ihre Abonnements verlängern können. Nach diesem Aufbewahrungszeitraum löscht Microsoft alle Kundendaten innerhalb von 90 Tagen, d. h. Ihre Kundendaten werden 180 Tage nach Ablauf oder Kündigung endgültig gelöscht. Angesichts des Datenaufbewahrungsverfahrens können Sie steuern, wie lange Ihre Daten gespeichert werden, indem Sie den Zeitpunkt festlegen, zu dem Sie den Dienst mit Microsoft beenden. Es wird empfohlen, den Dienst erst zu beenden, wenn Sie alle Daten extrahiert haben, damit der anfängliche Aufbewahrungszeitraum von 90 Tagen als Sicherheitspuffer fungieren kann, wenn Sie später feststellen, dass Sie etwas verpasst haben.

Wenn Sie versehentlich ein gesamtes Speicherkonto gelöscht haben, sollten Sie sich umgehend an den Azure-Support wenden, um Unterstützung bei der Wiederherstellung zu erhalten. Sie können Supportanfragen im Azure-Portal erstellen und verwalten . Ein in einem Abonnement gelöschtes Speicherkonto wird zwei Wochen lang aufbewahrt, um die Wiederherstellung des versehentlichen Löschens zu ermöglichen, nachdem es endgültig gelöscht wurde. Wenn ein Speicherobjekt (z. B. Blob, Datei, Warteschlange, Tabelle) jedoch selbst gelöscht wird, ist der Löschvorgang sofort und unumkehrbar. Sofern Sie keine Sicherung vorgenommen haben, können gelöschte Speicherobjekte nicht wiederhergestellt werden. Für Blob-Speicher können Sie zusätzlichen Schutz vor versehentlichen oder fehlerhaften Änderungen oder Löschungen implementieren, indem Sie vorläufiges Löschen aktivieren. Wenn vorläufiges Löschen für ein Speicherkonto aktiviert ist, können Blobs, Blobversionen und Momentaufnahmen in diesem Speicherkonto nach ihrer Löschung innerhalb eines angegebenen Aufbewahrungszeitraums wiederhergestellt werden. Um die Aufbewahrung von Daten nach dem Löschen von Speicherkonten oder Abonnements zu vermeiden, können Sie Speicherobjekte einzeln löschen, bevor Sie das Speicherkonto oder Abonnement löschen.

Bei versehentlichem Löschen in der Azure SQL-Datenbank sollten Sie Sicherungen überprüfen, die der Dienst automatisch erstellt und die Point-in-Time-Wiederherstellung verwenden. Beispielsweise erfolgt die vollständige Datenbanksicherung wöchentlich, und differenzielle Datenbanksicherungen werden stündlich durchgeführt. Darüber hinaus können einzelne Dienste (z. B. Azure DevOps) eigene Richtlinien für versehentliche Datenlöschung haben.

Datenvernichtung

Wenn eine Festplatte, die als Speicher verwendet wird, einen Hardwarefehler aufweist, wird sie vor der Außerbetriebnahme sicher gelöscht oder zerstört. Die Daten auf dem Laufwerk werden gelöscht, um sicherzustellen, dass die Daten nicht auf irgendeine Weise wiederhergestellt werden können. Wenn solche Geräte außer Betrieb genommen werden, folgt Microsoft dem NIST SP 800-88 R1-Entsorgungsprozess , wobei die Datenklassifizierung an FIPS 199 Moderate ausgerichtet ist. Magnetische, elektronische oder optische Medien werden gemäß den anforderungen in NIST SP 800-88 R1 gelöscht oder zerstört, wobei die Begriffe wie folgt definiert sind:

• Bereinigung – "ein Medienbereinigungsprozess, der die Vertraulichkeit von Informationen vor einem Laborangriff schützt", was "Ressourcen und Wissen umfasst, um nicht standardmäßige Systeme zur Durchführung von Datenwiederherstellungsversuchen auf Medien außerhalb ihrer normalen Betriebsumgebung" unter Verwendung von "Signalverarbeitungsgeräten und speziell geschultem Personal" zu verwenden. Hinweis: Für Festplattenlaufwerke (einschließlich ATA, SCSI, SATA, SAS usw.) ist ein Befehl auf Firmwareebene für sicheres Löschen (Single-Pass) akzeptabel, oder eine Dreidurchlaufüberschreibung und Überprüfung auf Softwareebene (eins, Nullen, zufällig) des gesamten physischen Mediums, einschließlich Wiederherstellungsbereichen, falls vorhanden. Für Solid State Disks (SSD) ist ein Befehl auf Firmwareebene zum sicheren Löschen erforderlich.
• Zerstören – "eine Vielzahl von Methoden, einschließlich Disintegration, Verbrennung, Pulverisierung, Zerbrechen und Schmelzen", nach denen die Medien "nicht wie ursprünglich vorgesehen wiederverwendet werden können".

Lösch- und Vernichtungsvorgänge müssen mithilfe von Tools und Prozessen durchgeführt werden, die von Microsoft Security genehmigt wurden. Aufzeichnungen müssen über die Löschung und Zerstörung von Vermögenswerten aufbewahrt werden. Geräte, die die Bereinigung nicht erfolgreich abschließen, müssen entmagnetisiert (nur für magnetische Medien) oder zerstört werden.

Zusätzlich zu technischen Implementierungsdetails, die Azure Compute, Networking und Speicherisolation ermöglichen, hat Microsoft stark in Sicherheitssicherungsprozesse und -praktiken investiert, um logisch isolierte Dienste und Systeme ordnungsgemäß zu entwickeln, wie im nächsten Abschnitt beschrieben.

Sicherheitssicherungsprozesse und -praktiken

Azure-Isolierungsgarantien werden durch die interne Verwendung des Security Development Lifecycle (SDL) von Microsoft und anderer starker Sicherheitsprozesse erzwungen, um Angriffsflächen zu schützen und Bedrohungen zu mindern. Microsoft hat branchenführende Prozesse und Tools etabliert, die ein hohes Vertrauen in die Azure-Isolationsgarantie bieten.

• Security Development Lifecycle (SDL) – Der Microsoft SDL führt in allen Phasen des Entwicklungsprozesses Sicherheits- und Datenschutzaspekte ein, hilft Entwicklern beim Erstellen von hochsicherer Software, der Einhaltung von Sicherheitsanforderungen und der Reduzierung der Entwicklungskosten. Die Anleitungen, bewährten Methoden, Tools und Prozesse in Microsoft SDL sind Methoden , die intern verwendet werden, um alle Azure-Dienste zu erstellen und sicherere Produkte und Dienste zu erstellen. Dieser Prozess wird auch öffentlich dokumentiert, um die Erkenntnisse von Microsoft mit der breiteren Branche zu teilen und Branchenfeedback zu integrieren, um einen stärkeren Sicherheitsentwicklungsprozess zu schaffen.
• Tools und Prozesse – Der gesamte Azure-Code unterliegt einem umfangreichen Satz von statischen und dynamischen Analysetools, die potenzielle Sicherheitsrisiken identifizieren, ineffektive Sicherheitsmuster, Speicherbeschädigung, Benutzerberechtigungsprobleme und andere kritische Sicherheitsprobleme identifizieren.
  • Zweckgebundenes Fuzzing – Eine Testtechnik, die verwendet wird, um Sicherheitslücken in Softwareprodukten und -diensten zu finden. Es besteht aus der wiederholten Zuführung geänderter oder gefuzzter Daten an Softwareeingaben, um Blockaden, Ausnahmen und Abstürze auszulösen, die Fehlerbedingungen sind, die von einem Angreifer verwendet werden können, um Anwendungen und Dienste zu stören oder zu kontrollieren. Microsoft SDL empfiehlt Fuzzing für alle Angriffsflächen eines Softwareprodukts, insbesondere solche Oberflächen, die Datenparser nicht vertrauenswürdigen Daten aussetzen.
  • Penetrationstests für Livewebsites – Microsoft führt fortlaufende Penetrationstests für Livewebsites durch, um Cloudsicherheitskontrollen und -prozesse zu verbessern, wie im Rahmen des Red Teaming-Programms weiter unten in diesem Abschnitt beschrieben. Penetrationstests sind eine Sicherheitsanalyse eines Softwaresystems, das von erfahrenen Sicherheitsexperten durchgeführt wird, die die Aktionen eines Hackers simulieren. Ziel eines Penetrationstests ist es, potenzielle Sicherheitsrisiken aufzudecken, die sich aus Codierungsfehlern, Systemkonfigurationsfehlern oder anderen betriebstechnischen Bereitstellungsschwächen ergeben. Die Tests werden mit Azure-Infrastruktur und -Plattformen und den eigenen Mandanten, Anwendungen und Daten von Microsoft durchgeführt. Ihre Mandanten, Anwendungen und Daten, die in Azure gehostet werden, werden niemals gezielt angegriffen. Sie können jedoch Ihre eigenen Penetrationstests Ihrer Anwendungen durchführen, die Sie in Azure bereitgestellt haben.
  • Bedrohungsmodellierung – Ein Kernelement von Microsoft SDL. Es handelt sich um eine techniktechnische Technik, mit der Bedrohungen, Angriffe, Sicherheitsrisiken und Gegenmaßnahmen identifiziert werden können, die sich auf Anwendungen und Dienste auswirken könnten. Die Bedrohungsmodellierung ist Teil des Azure-Routineentwicklungslebenszyklus.
  • Automatisiertes Erstellen von Warnungen über Änderungen an der Angriffsfläche – Attack Surface Analyzer ist ein von Microsoft entwickeltes Open-Source-Sicherheitstool, das die Angriffsfläche eines Zielsystems analysiert und berichte über potenzielle Sicherheitsrisiken, die bei der Installation von Software- oder Systemfehlern eingeführt wurden. Das Kernfeature von Attack Surface Analyzer ist die Möglichkeit, die Sicherheitskonfiguration eines Betriebssystems vor und nach der Installation einer Softwarekomponente zu "diffieren". Dieses Feature ist wichtig, da die meisten Installationsprozesse erhöhte Berechtigungen erfordern und nach der Erteilung zu unbeabsichtigten Systemkonfigurationsänderungen führen können.
• Obligatorische Sicherheitsschulung – Das Microsoft Azure-Sicherheitsschulungs- und -bewusstseinsprogramm erfordert alle Für Azure-Entwicklung und -Vorgänge verantwortlichen Mitarbeiter, um grundlegende Schulungen und zusätzliche Schulungen basierend auf individuellen Arbeitsanforderungen zu übernehmen. Diese Verfahren stellen einen Standardansatz, Tools und Techniken bereit, mit denen das Bewusstseinsprogramm implementiert und unterstützt wird. Microsoft hat ein Sicherheitsbewusstseinsprogramm namens STRIKE implementiert, das monatliche E-Mail-Kommunikation an alle Azure Engineering-Mitarbeiter zum Sicherheitsbewusstsein bereitstellt und es Mitarbeitern ermöglicht, sich für persönliche oder Online-Sicherheitssensibilisierungsschulungen anzumelden. STRIKE bietet eine Reihe von Sicherheitsschulungen im laufe des Jahres plus STRIKE Central, eine zentrale Online-Ressource für Sicherheitsbewusstsein, Schulung, Dokumentation und Community-Engagement.
• Bug Bounty Program – Microsoft ist der Ansicht, dass eine enge Partnerschaft mit akademischen und Branchenforschern ein höheres Maß an Sicherheit für Sie und Ihre Daten fördert. Sicherheitsforscher spielen eine integrale Rolle im Azure-Ökosystem, indem Sicherheitsrisiken entdeckt werden, die im Softwareentwicklungsprozess verpasst wurden. Das Microsoft Bug Bounty-Programm wurde entwickelt, um Die Forschung in relevanten Technologien (z. B. Verschlüsselung, Spoofing, Hypervisorisolation, Rechteerweiterung usw.) zu ergänzen und zu fördern, um die Infrastruktur und Ihre Daten von Azure besser zu schützen. Als Beispiel für jede kritische Sicherheitsanfälligkeit, die im Azure-Hypervisor identifiziert wird, kompensiert Microsoft Sicherheitsforscher bis zu 250.000 US-Dollar – ein erheblicher Betrag, um die Teilnahme und Die Offenlegung von Sicherheitsrisiken zu ermöglichen. Der Bounty-Bereich für Sicherheitsrisikenberichte für Azure-Dienste beträgt bis zu 60.000 $.
• Red Team-Aktivitäten – Microsoft verwendet Red Teaming, eine Form von Livewebsite-Penetrationstests für von Microsoft verwaltete Infrastruktur, Dienste und Anwendungen. Microsoft simuliert reale Sicherheitsverletzungen, überwacht kontinuierlich die Sicherheit und praktiziert die Reaktion auf Sicherheitsvorfälle, um Azure-Sicherheit zu testen und zu verbessern. Red Teaming wird auf die Sicherheitsstrategie „Annehmen von Sicherheitsverletzungen“ festgelegt und von zwei Kerngruppen ausgeführt: Team Rot (Angreifer) und Team Blau (Verteidiger). Der Ansatz dient zum Testen von Azure-Systemen und -Operationen mit den gleichen Taktiken, Techniken und Verfahren wie echte Gegner gegen die Live-Produktionsinfrastruktur, ohne dass die Infrastruktur- und Plattform-Engineering- oder -Operationsteams vorher davon wissen. Dieser Ansatz testet Sicherheitserkennungs- und Reaktionsfunktionen und hilft bei der Identifizierung von Produktionsrisiken, Konfigurationsfehlern, ungültigen Annahmen oder anderen Sicherheitsproblemen auf kontrollierte Weise. Auf jede Red Team-Verletzung folgt eine vollständige Offenlegung zwischen dem Roten Team und dem blauen Team, um Lücken zu identifizieren, Ergebnisse zu beheben und die Reaktion auf Sicherheitsverletzungen erheblich zu verbessern.

Wenn Sie es gewohnt sind, eine herkömmliche lokale Rechenzentrumsbereitstellung durchzuführen, führen Sie in der Regel eine Risikobewertung durch, um Ihre Bedrohungsgefährdung zu messen und mildernde Maßnahmen zu formulieren, wenn Sie zu der Cloud migrieren. In vielen dieser Fälle sind Sicherheitsüberlegungen für herkömmliche lokale Bereitstellungen tendenziell gut zu verstehen, während die entsprechenden Cloudoptionen eher neu sind. Der nächste Abschnitt soll Ihnen bei diesem Vergleich helfen.

Überlegungen zur logischen Isolierung

Eine mehrinstanzenfähige Cloudplattform impliziert, dass mehrere Kundenanwendungen und -daten auf derselben physischen Hardware gespeichert werden. Azure verwendet logische Isolierung , um Ihre Anwendungen und Daten von anderen Kunden zu trennen. Dieser Ansatz bietet den Skalen- und wirtschaftlichen Nutzen von mehrinstanzenfähigen Clouddiensten und hilft dabei, Steuerelemente zu erzwingen, die darauf ausgelegt sind, andere Kunden am Zugriff auf Ihre Daten oder Anwendungen zu hindern. Wenn Sie von der herkömmlichen lokalen, physisch isolierten Infrastruktur zur Cloud migrieren, befasst sich dieser Abschnitt mit Bedenken, die für Sie von Interesse sein können.

Physische und logische Sicherheitsüberlegungen

Tabelle 6 enthält eine Zusammenfassung der wichtigsten Sicherheitsaspekte für physisch isolierte lokale Bereitstellungen (Bare Metal) im Vergleich zu logisch isolierten cloudbasierten Bereitstellungen (Azure). Es ist hilfreich, diese Überlegungen zu überprüfen, bevor Risiken untersucht werden, die für freigegebene Cloudumgebungen spezifisch sind.

Tabelle 6. Wichtige Sicherheitsüberlegungen für physische und logische Isolation

Nachfolgend sind wichtige Risiken aufgeführt, die für geteilte Cloud-Umgebungen einzigartig sind und die beim Umgang mit sensiblen Daten und Arbeitslasten adressiert werden müssen.

Nutzung von Sicherheitsrisiken in Virtualisierungstechnologien

Im Vergleich zu herkömmlichen lokalen gehosteten Systemen bietet Azure eine stark reduzierte Angriffsfläche , indem ein gesperrter Windows Server-Kern für das Hostbetriebssystem verwendet wird, das über den Hypervisor verteilt ist. Darüber hinaus verfügen Gast-PaaS-VMs standardmäßig nicht über Benutzerkonten, um eingehende Remoteverbindungen zu akzeptieren, und das Standardmäßige Windows-Administratorkonto ist deaktiviert. Ihre Software in PaaS-VMs ist standardmäßig auf die Ausführung unter einem Konto mit geringen Rechten beschränkt, wodurch Ihr Dienst vor Angriffen durch seine eigenen Endbenutzer geschützt wird. Sie können diese Berechtigungen ändern, und Sie können auch Ihre virtuellen Computer so konfigurieren, dass der Remoteadministratorzugriff zugelassen wird.

PaaS-VMs bieten erweiterten Schutz vor dauerhaften Schadsoftwareinfektionen als herkömmliche physische Serverlösungen, die, wenn ein Angreifer kompromittiert wird, schwierig zu bereinigen sein kann, auch nachdem die Sicherheitsanfälligkeit korrigiert wurde. Der Angreifer hat möglicherweise Änderungen am System hinter sich gelassen, die eine erneute Eingabe ermöglichen, und es ist eine Herausforderung, alle derartigen Änderungen zu finden. Im Extremfall muss das System von Grund auf neu aufgebaut werden, wobei alle Software neu installiert werden, was manchmal zu einem Verlust von Anwendungsdaten führt. Bei PaaS-VMs ist das Reimaging ein Routineteil von Vorgängen, und es kann dazu beitragen, Angriffe zu bereinigen, die noch nicht einmal erkannt wurden. Dieser Ansatz erschwert es, dass ein Kompromiss beibehalten wird.

Seitenkanalangriffe

Microsoft war an der Spitze der Verringerung spekulativer Ausführungsseitenkanalangriffe , die Hardwarerisiken in modernen Prozessoren ausnutzen, die Hyperthreading verwenden. Auf viele Arten ähneln diese Probleme dem Spectre -Seitenkanalangriff (Variante 2), der 2018 offengelegt wurde. Im Jahr 2022 wurden mehrere neue spekulative Ausführungs-Nebenkanalprobleme von sowohl Intel als auch AMD offengelegt. Um diese Sicherheitsrisiken zu beheben, hat Microsoft Hyper-V HyperClear entwickelt und optimiert, eine umfassende und leistungsstarke Risikominderungsarchitektur für Seitenkanäle. HyperClear basiert auf drei Hauptkomponenten, um eine starke Inter-VM-Isolation sicherzustellen:

• Core scheduler, um die gemeinsame Nutzung von privaten Puffern und anderen Ressourcen eines CPU-Kerns zu vermeiden.
• Virtual-Processor-Adressraumisolation , um spekulativen Zugriff auf den Arbeitsspeicher eines anderen virtuellen Computers oder den privaten Zustand eines anderen virtuellen CPU-Kerns zu vermeiden.
• Vertrauliche Datenbereinigung , um zu vermeiden, dass private Daten an einem anderen Ort im Hypervisorspeicher als im privaten Adressbereich eines virtuellen Prozessors verbleiben, damit diese Daten in Zukunft nicht spekulativ aufgerufen werden können.

Diese Schutzmaßnahmen wurden in Azure bereitgestellt und stehen in Windows Server 2016 und höher unterstützten Versionen zur Verfügung.

Wenn VMs, die zu verschiedenen Kunden gehören, auf demselben physischen Server ausgeführt werden, ist es der Auftrag des Hypervisors, sicherzustellen, dass sie nichts Wichtiges darüber erfahren können, was die VMs des anderen Kunden tun. Azure hilft, nicht autorisierte direkte Kommunikation nach Entwurf zu blockieren; Es gibt jedoch subtile Effekte, bei denen ein Kunde die Arbeit eines anderen Kunden charakterisieren kann. Die wichtigsten dieser Effekte sind Zeitliche Effekte, wenn verschiedene VMs mit den gleichen Ressourcen konkurrieren. Durch einen sorgfältigen Vergleich der Vorgänge auf CPUs mit verstrichener Zeit kann ein virtueller Computer etwas darüber erfahren, was andere VMs auf demselben Server tun. Diese Exploits haben in der akademischen Presse viel Aufmerksamkeit erhalten, wo Forscher spezifischere Informationen darüber erfahren möchten, was in einem Peer-VM passiert.

Besonders interessant sind die Bemühungen, die kryptografischen Schlüssel einer Peer-VM zu erlernen, indem sie den Zeitpunkt bestimmter Speicherzugriffe messen und ableiten, welche Cachezeilen die VM des Opfers liest und aktualisiert. Unter kontrollierten Bedingungen mit VMs mit Hyperthreading wurden erfolgreiche Angriffe gegen kommerziell verfügbare Implementierungen kryptografischer Algorithmen nachgewiesen. Neben der zuvor erwähnten Hyper-V HyperClear-Risikominderungsarchitektur, die von Azure verwendet wird, gibt es mehrere zusätzliche Entschärfungen in Azure, die das Risiko eines solchen Angriffs verringern:

• Die Standard-Kryptografiebibliotheken von Azure wurden so entwickelt, dass sie solchen Angriffen widerstehen, indem die Cachezugriffsmuster nicht von den verwendeten kryptografischen Schlüsseln abhängen.
• Azure verwendet einen erweiterten VM-Hostplatzierungsalgorithmus, der hoch entwickelt und nahezu unmöglich vorhersagbar ist, wodurch die Wahrscheinlichkeit reduziert wird, dass eine von einem Gegner kontrollierte VM auf demselben Host platziert wird wie die Ziel-VM.
• Alle Azure-Server verfügen über mindestens acht physische Kerne und einige haben viele mehr. Durch die Erhöhung der Anzahl der Kerne, die die von verschiedenen VMs platzierte Last gemeinsam nutzen, wird zu einem bereits schwachen Signal Rauschen hinzugefügt.
• Sie können virtuelle Computer auf Hardware bereitstellen, die einem einzelnen Kunden zugeordnet ist, indem Sie Azure Dedicated Host oder isolierte VMs verwenden, wie im Abschnitt " Physische Isolation " beschrieben. Die physische Mandantenisolation erhöht jedoch die Bereitstellungskosten und ist in den meisten Szenarien möglicherweise nicht erforderlich, angesichts der starken logischen Isolationszusicherungen, die von Azure geboten werden.

Insgesamt trägt PaaS – oder jede Workload, die virtuelle Computer automatisch generiert – zu einer Änderung bei der VM-Platzierung bei, die zu zufälliger VM-Zuordnung führt. Die zufällige Platzierung Ihrer virtuellen Computer macht es Angreifern viel schwieriger, auf demselben Host zu gelangen. Darüber hinaus wird der Hostzugriff mit stark reduzierter Angriffsfläche gesichert, wodurch diese Art von Exploits schwierig zu unterhalten ist.

Zusammenfassung

Eine mehrinstanzenfähige Cloudplattform impliziert, dass mehrere Kundenanwendungen und -daten auf derselben physischen Hardware gespeichert werden. Azure verwendet logische Isolation, um Ihre Anwendungen und Daten von anderen Kunden zu trennen. Dieser Ansatz stellt den Umfang und die wirtschaftlichen Vorteile von mehrinstanzenfähigen Clouddiensten bereit und verhindert gleichzeitig zuverlässig, dass andere Kunden auf Ihre Daten oder Anwendungen zugreifen können.

Azure begegnet dem wahrgenommenen Risiko der gemeinsamen Nutzung von Ressourcen, indem eine vertrauenswürdige Grundlage für die Sicherstellung mehrinstanzenfähiger, kryptografisch sicherer, logisch isolierter Clouddienste unter Verwendung eines gemeinsamen Satzes von Prinzipien bereitgestellt wird:

• Benutzerzugriffssteuerungen mit Authentifizierung und Identitätstrennung, die Microsoft Entra-ID und rollenbasierte Zugriffssteuerung in Azure (Azure RBAC) verwenden.
• Rechenisolation für die Verarbeitung, einschließlich logischer und physischer Rechenisolation.
• Netzwerkisolation einschließlich Trennung von Netzwerkdatenverkehr und Datenverschlüsselung während der Übertragung.
• Speicherisolation mit Verschlüsselung ruhender Daten mithilfe erweiterter Algorithmen mit mehreren Verschlüsselungsverfahren und Verschlüsselungsschlüsseln und Bestimmungen für kundenseitig verwaltete Schlüssel (CMK) unter Ihrer Kontrolle in Azure Key Vault.
• In das Dienstdesign eingebettete Sicherheitssicherungsprozesse entwickeln korrekt logisch isolierte Dienste, einschließlich des Security Development Lifecycle (SDL) und anderer starker Sicherheitssicherungsprozesse, um Angriffsflächen zu schützen und Risiken zu mindern.

Im Einklang mit dem Modell für gemeinsame Verantwortung in Cloud Computing bietet Ihnen dieser Artikel Anleitungen für Aktivitäten, die Teil Ihrer Verantwortung sind. Außerdem werden Designprinzipien und Technologien untersucht, die in Azure zur Verfügung stehen, um Ihre Ziele für die sichere Isolation zu erreichen.

Nächste Schritte

Weitere Informationen zu:

• Dokumentation mit grundlegenden Azure-Sicherheitsinformationen
• Sicherheit der Azure-Infrastruktur
• Azure-Plattformintegrität und -sicherheit
• Übersicht über Azure Government
• Azure Government – Sicherheit
• Azure Government-Compliance
• Azure und andere Complianceangebote für Dienste von Microsoft