Isolation in der Azure öffentlichen Cloud

Azure hilft Ihnen, Anwendungen und virtuelle Maschinen (VMs) auf gemeinsamer physischer Infrastruktur auszuführen. Einer der wichtigsten wirtschaftlichen Vorteile des Ausführens von Anwendungen in einer Cloud-Umgebung ist die Möglichkeit, die Kosten für gemeinsam genutzte Ressourcen auf mehrere Tenants zu verteilen. Diese Mandantenfähigkeitspraxis verbessert die Effizienz, indem Ressourcen kostengünstig auf verschiedene Mandanten gemultiplext werden. Allerdings birgt es auch das Risiko, physische Server und andere Infrastrukturressourcen zu teilen, um sensible Anwendungen und VMs zu betreiben, die einem beliebigen und potenziell böswilligen Nutzer gehören könnten.

Dieser Artikel beschreibt, wie Azure Isolation sowohl gegen böswillige als auch gegen nicht-böswillige Nutzer bietet. Es dient als Leitfaden für die Architektur von Cloud-Lösungen, indem es Architekten verschiedene Isolationsoptionen bietet.

Isolation auf Mandantenebene

Einer der Hauptvorteile von Cloud Computing ist das Konzept gemeinsamer gemeinsamer Infrastruktur über mehrere Mieter gleichzeitig, was zu Skaleneffekten führt. Dieses Konzept wird als Mehrinstanzenfähigkeit bezeichnet. Microsoft arbeitet kontinuierlich daran, sicherzustellen, dass die Multitenant-Architektur von Microsoft Azure Sicherheits-, Vertraulichkeits-, Datenschutz-, Integritäts- und Verfügbarkeitsstandards unterstützt.

Am cloudfähigen Arbeitsplatz ist ein Mandant ein Client oder eine Organisation, der eine bestimmte Instanz dieses Clouddiensts besitzt und verwaltet. In der von Microsoft Azure bereitgestellten Identitätsplattform ist ein Tenant eine dedizierte Instanz von Microsoft Entra ID, die Ihre Organisation erhält und besitzt, wenn sie sich für einen Microsoft-Cloud-Dienst anmeldet.

Jedes Microsoft Entra-Verzeichnis unterscheidet sich und unterscheidet sich von anderen Microsoft Entra-Verzeichnissen. Wie ein Firmengebäude ist ein Microsoft Entra-Verzeichnis ein sicheres Element, das nur von Ihrer Organisation genutzt werden kann. Die Microsoft Entra-Architektur isoliert Kundendaten und Identitätsinformationen und verhindert deren Vermischung. Diese Isolation bedeutet, dass Benutzer und Administratoren eines Microsoft Entra-Verzeichnisses nicht versehentlich oder böswillig auf Daten in einem anderen Verzeichnis zugreifen können.

Azure-Mandat

Die Azure-Mandantschaft (Azure-Abonnement) bezieht sich auf eine Kunden- und Abrechnungsbeziehung und einen eindeutigen Mandanten in Microsoft Entra ID. Microsoft Entra ID und seine Azure rollenbasierte Zugriffskontrolle bieten eine Isolation auf Mieterebene in Microsoft Azure. Jedes Azure-Abonnement ist einem Microsoft Entra-Verzeichnis zugeordnet.

Benutzer, Gruppen und Anwendungen aus diesem Verzeichnis können Ressourcen im Azure-Abonnement verwalten. Weisen Sie diese Zugriffsrechte über das Azure-Portal, Azure-Befehlszeilen-Tools und Azure-Management-APIs zu. Sicherheitsgrenzen isolieren einen Microsoft Entra-Mandanten logisch, sodass kein Kunde böswillig oder versehentlich auf Mitmandanten zugreifen oder sie kompromittieren kann. Microsoft Entra ID wird auf "Bare Metal"-Servern ausgeführt, die in einem getrennten Netzwerksegment isoliert sind, in dem die Paketfilterung auf Hostebene und die Windows-Firewall unerwünschte Verbindungen und Datenverkehr blockieren.

• Der Zugriff auf Daten in Microsoft Entra ID erfordert die Benutzerauthentifizierung über einen Sicherheitstoken-Dienst (STS). Das Autorisierungssystem nutzt Informationen über die Existenz, den aktivierten Status und die Rolle des Benutzers, um festzustellen, ob dieser Benutzer in dieser Sitzung autorisierten Zugriff auf den Ziel-Mieter hat.

• Mandanten sind diskrete Container und es gibt keine Beziehung zwischen diesen Containern.

• Es gibt keinen Zugriff über Mandanten hinweg, es sei denn, ein Mandantenadministrator gewährt ihn durch einen Verbund oder durch Bereitstellung von Benutzerkonten von anderen Mandanten.

• Microsoft beschränkt den physischen Zugriff auf die Server, die den Microsoft Entra-Dienst bilden, sowie den direkten Zugriff auf die Backend-Systeme von Microsoft Entra ID.

• Microsoft Entra-Nutzer haben keinen Zugriff auf physische Vermögenswerte oder Standorte, sodass sie die folgenden logischen Azure-RBAC-Richtlinienprüfungen nicht umgehen können.

Verwenden Sie für Diagnose- und Wartungsanforderungen ein Betriebsmodell, das ein Just-in-Time-Berechtigungserweiterungssystem verwendet. Microsoft Entra Privileged Identity Management (PIM) führt das Konzept eines berechtigten Administrators ein. Berechtigte Administratoren sind Nutzer, die gelegentlich, aber nicht jeden Tag privilegierten Zugriff benötigen. Die Rolle ist inaktiv, bis der Benutzer Zugriff benötigt. Der Benutzer führt dann einen Aktivierungsprozess durch und wird für eine festgelegte Zeit aktiver Administrator.

Microsoft Entra ID hostet jeden Mandanten in einem eigenen geschützten Container, mit Richtlinien und Berechtigungen für und innerhalb des Containers, die ausschließlich vom Mandanten selbst verwaltet werden.

Das Konzept von Mandantencontainern ist auf allen Ebenen tief im Verzeichnisdienst verankert, von den Portalen bis hin zur persistenten Speicherung.

Selbst wenn Metadaten von mehreren Microsoft Entra-Mandanten auf demselben physischen Datenträger gespeichert sind, besteht zwischen den Containern nur die Beziehung, die vom Verzeichnisdienst definiert wird, was wiederum vom Mandantenadministrator bestimmt wird.

Azure rollenbasierte Zugriffskontrolle (Azure RBAC)

Die rollenbasierte Zugriffskontrolle von Azure (Azure RBAC) hilft Ihnen, mehrere Komponenten innerhalb eines Azure-Abonnements zu teilen, indem sie ein feingranuliertes Zugriffsmanagement für Azure bietet. Azure RBAC ermöglicht es Ihnen, Aufgaben innerhalb Ihrer Organisation zu trennen und access basierend darauf zu gewähren, welche Benutzer ihre Aufgaben ausführen müssen. Anstatt allen uneingeschränkten Berechtigungen in einem Azure Abonnement oder Ressourcen zu gewähren, können Sie nur bestimmte Aktionen zulassen.

Azure RBAC verfügt über drei grundlegende Rollen, die für alle Ressourcentypen gelten:

• Owner verfügt über vollständigen Zugriff auf alle Ressourcen, einschließlich des Rechts, den Zugriff an andere Personen zu delegieren.

• Contributor kann alle Arten von Azure-Ressourcen erstellen und verwalten, anderen jedoch keinen Zugriff gewähren.

• Reader können vorhandene Azure Ressourcen anzeigen.

Die restlichen Azure Rollen in Azure die Verwaltung bestimmter Azure Ressourcen ermöglichen. Mit der Rolle "Mitwirkender virtueller Computer" kann der Benutzer z. B. virtual machines erstellen und verwalten. Sie erhalten keinen Zugriff auf das Azure Virtual Network und das Subnetz, mit dem die virtuelle Maschine verbunden ist.

Die Azure integrierten Rollen listen die in Azure verfügbaren Rollen auf. Sie definieren die Vorgänge und den Bereich, die jede integrierte Rolle Benutzern gewährt. Wenn Sie Ihre eigenen Rollen für noch mehr Kontrolle definieren möchten, erfahren Sie, wie Sie Custom-Rollen in Azure RBAC erstellen.

Einige andere Funktionen für Microsoft Entra ID umfassen:

• Microsoft Entra ID ermöglicht SSO zu SaaS-Anwendungen, unabhängig davon, wo sie gehostet werden. Einige Anwendungen sind mit Microsoft Entra ID verbunden, und andere verwenden SSO-Kennwort. Verbundanwendungen können auch die Benutzerbereitstellung und Kennworttresore unterstützen.

• Microsoft Entra ID bietet Identity-as-a-Service durch Verbund (unter Verwendung der Active Directory-Verbunddienste) sowie Synchronisierung und Replikation mit lokalen Verzeichnissen.

• Die Microsoft Entra Multi-Faktor-Authentifizierung fordert Benutzer auf, ihre Anmeldung über eine mobile App, einen Telefonanruf oder eine SMS zu verifizieren. Verwenden Sie es mit Microsoft Entra ID, um lokale Ressourcen durch den Multi-Factor Authentication Server zu sichern, sowie mit benutzerdefinierten Anwendungen und Verzeichnissen mit dem SDK.

• Microsoft Entra Domain Services hilft Ihnen, virtuelle Azure-Maschinen mit einer Active Directory-Domäne zu verbinden, ohne Domänencontroller bereitzustellen. Sie können sich bei diesen virtuellen Maschinen mit Ihren Active Directory-Anmeldeinformationen Ihres Unternehmens anmelden und domänenverbundene virtuelle Maschinen verwalten, indem Sie Gruppenrichtlinien verwenden, um Sicherheitsgrundlagen für alle Ihre Azure-virtuellen Maschinen zu erzwingen.

• Microsoft Entra External ID ist ein hochverfügbarer globaler Identitätsmanagementdienst für verbraucherorientierte Anwendungen, der auf Hunderte Millionen von Identitäten skalieren kann. Sie können es über mobile und Webplattformen hinweg integrieren. Ihre Kunden können sich über eine anpassbare Oberfläche bei all Ihren Anwendungen anmelden und zu diesem Zweck entweder vorhandene Konten aus sozialen Netzwerken nutzen oder Anmeldeinformationen festlegen.

Isolierung von Microsoft-Administratoren und Datenlöschung

Microsoft ergreift starke Maßnahmen, um Ihre Daten vor unangemessener access oder Verwendung durch unbefugte Personen zu schützen. Die Online Services Terms bieten vertragliche Verpflichtungen, die den Zugriff auf Ihre Daten regeln und diese betrieblichen Prozesse und Kontrollen unterstützen.

• Microsoft-Techniker haben keinen standardmäßigen Zugriff auf Ihre Daten in der Cloud. Stattdessen wird ihnen der Zugang nur bei Bedarf und unter Aufsicht der Geschäftsleitung gewährt. Dieser Zugang wird sorgfältig kontrolliert und protokolliert und widerrufen, wenn er nicht mehr benötigt wird.
• Es kann sein, dass Microsoft andere Unternehmen damit beauftragt, in begrenztem Umfang Dienstleistungen im Namen von Microsoft zu übernehmen. Subunternehmer können Kundendaten nur access, um die Dienste zu erbringen, für die Microsoft sie eingestellt hat, und sie dürfen sie nicht für andere Zwecke verwenden. Darüber hinaus sind sie vertraglich verpflichtet, die Vertraulichkeit der Kundeninformationen aufrechtzuerhalten.

Microsoft und akkreditierte Prüfungsfirmen überprüfen regelmäßig Geschäftsdienste mit geprüften Zertifizierungen wie ISO/IEC 27001. Diese Prüfer führen Stichprobenprüfungen durch, um zu bestätigen, dass access nur zu legitimen geschäftlichen Zwecken dient. Sie können jederzeit und aus jedem Grund auf Ihre eigenen Kundendaten zugreifen.

Wenn Sie Daten löschen, werden die Daten von Microsoft Azure gelöscht, einschließlich zwischengespeicherter kopien oder Sicherungskopien. Bei In-Scope-Diensten erfolgt dieser Löschvorgang innerhalb von 90 Tagen nach Ablauf des Aufbewahrungszeitraums. (Der Abschnitt "Datenverarbeitungsbedingungen" der Online Services Terms definiert Dienste im Gültigkeitsbereich.)

Wenn ein Laufwerk, das für die Speicherung verwendet wird, einen Hardwarefehler erleidet, löscht oder zerstört Microsoft das Laufwerk sicher, bevor es das Laufwerk zum Ersatz oder zur Reparatur an den Hersteller zurückgibt. Microsoft überschreibt die Daten auf der Festplatte, um sicherzustellen, dass niemand die Daten auf irgendeine Weise wiederherstellen kann.

Computeisolation

Microsoft Azure bietet verschiedene cloudbasierte Computing-Dienste, die eine breite Auswahl an Computeinstanzen und -diensten enthalten, die automatisch skaliert und herunterskaliert werden können, um die Anforderungen Ihrer Anwendung oder Ihres Unternehmens zu erfüllen. Diese Recheninstanzen und -dienste bieten Isolation auf mehreren Ebenen, um Daten zu sichern, ohne die von Organisationen geforderte Konfigurationsflexibilität zu opfern.

Isolierte Größen virtueller Maschinen

Azure Compute bietet virtuelle Computergrößen, die für einen bestimmten Hardwaretyp isoliert sind und einem einzelnen Kunden zugeordnet sind. Die isolierten Größen arbeiten auf bestimmten Hardwaregenerationen. Azure stellt diese Größen ein, wenn die Hardwaregeneration ausgemustert wird oder eine neue Hardwaregeneration verfügbar ist.

Isolierte Größen für virtuelle Maschinen eignen sich am besten für Workloads, die ein hohes Maß an Isolation von den Workloads anderer Mandanten erfordern. Diese Isolation ist manchmal erforderlich, um Compliance- und regulatorische Anforderungen zu erfüllen. Eine isolierte Größe garantiert, dass nur deine virtuelle Maschine auf dieser Serverinstanz läuft.

Da VMs mit isolierter Größe groß sind, können Sie ihre Ressourcen mithilfe der Azure-Unterstützung für geschachtelte virtuelle Maschinen unterteilen.

Zu den derzeit isolierten virtuellen Maschinenangeboten gehören:

• Standard_E192is_v6
• Standard_E192ids_v6
• Standard_E104i_v5
• Standard_E104id_v5
• Standard_E104is_v5
• Standard_E104ids_v5
• Standard_E112ias_v5
• Standard_E112iads_v5
• Standard_E80is_v4
• Standard_E80ids_v4
• Standard_E96ias_v4
• Standard_E112ibs_v5
• Standard_E112ibds_v5
• Standard_EC96ias_v5
• Standard_EC96iads_v5
• Standard_HB120rs_v3
• Standard_HB176rs_v4
• Standard_HB368rs_v5
• Standard_HX176rs
• Standard_M832is_16_v3
• Standard_M832ids_16_v3
• Standard_M192is_v2
• Standard_M192ids_v2
• Standard_M192ims_v2
• Standard_M192idms_v2
• Standard_NC64as_T4_v3
• Standard_NC96ads_A100_v4
• Standard_NC80adis_H100_v5
• Standard_ND128isr_NDR_GB200_v6
• Standard_ND128isr_NDR_GB300_v6
• Standard_ND96isr_H100_v5
• Standard_ND96isr_H200_v5
• Standard_ND96isr_MI300X_v5
• Standard_NG32ads_V620_v1
• Standard_NG32adms_V620_v1
• Standard_NV72ads_A10_v5

Einstellung isolierter VM-Größen

Isolierte VM-Größen haben eine hardwarebegrenzte Lebensdauer. Azure wird 12 Monate vor dem offiziellen Datum für „Veraltet ab“ der Größen entsprechende Erinnerungen ausgeben und ein aktualisiertes isoliertes Angebot für Sie bereitstellen. Azure hat die Einstellung der folgenden Größen angekündigt.

Um die Ressourcen dieser isolierten virtuellen Maschinen weiter zu unterteilen, siehe Azure-Support für verschachtelte virtuelle Maschinen.

Dedizierte Hosts

Zusätzlich zu den im vorherigen Abschnitt beschriebenen isolierten Hosts bietet Azure auch dedizierte Hosts an. Azure Dedicated Host ist ein Dienst, der physische Server bereitstellt, die eine oder mehrere virtuelle Maschinen hosten können und einem einzigen Azure-Abonnement zugeordnet sind. Dedizierte Hosts bieten Hardwareisolation auf physischer Serverebene. Keine anderen virtuellen Computer werden auf Ihren Hosts platziert. Sie stellen dedizierte Hosts in den gleichen Rechenzentren bereit und nutzen dasselbe Netzwerk und die zugrunde liegende storage Infrastruktur wie andere, nicht isolierte Hosts. Weitere Informationen finden Sie in der detaillierten Übersicht über Azure dedizierte Hosts.

Hyper-V und Stammbetriebssystemisolation zwischen Stamm-VM und Gast-VMs

die Computeplattform Azure basiert auf der Computervirtualisierung. Der gesamte Kundencode wird auf einem Hyper-V virtuellen Computer ausgeführt. Auf jedem Azure Node (oder Netzwerkendpunkt) läuft ein Hypervisor direkt auf der Hardware und teilt den Node in eine variable Anzahl an Gast-VMs.

Jeder Knoten verfügt auch über eine spezielle Stamm-VM, die das Hostbetriebssystem ausführt. Der Hypervisor und das Stammbetriebssystem verwalten die Isolation der Stamm-VM von den Gast-VMs und die Isolierung der Gast-VMs voneinander. Diese Kombination aus Hypervisor und Stammbetriebssystem nutzt Microsofts jahrzehntelange Erfahrung im Bereich der Betriebssystemsicherheit sowie neuere Erkenntnisse aus der Arbeit mit Microsoft Hyper-V, um eine starke Isolierung von Gast-VMs zu gewährleisten.

Die Azure-Plattform verwendet eine virtualisierte Umgebung. Benutzerinstanzen funktionieren als eigenständige virtual machines, die keinen access auf einem physischen Hostserver haben.

Der Azure Hypervisor fungiert wie ein Mikrokernel. Es übergibt alle Hardwarezugriffsanforderungen von Gast-VMs an den Host zur Verarbeitung mithilfe einer geteilten Speicherschnittstelle, genannt VM Bus. Diese Architektur verhindert, dass Benutzer direkten Lese-, Schreib- oder Ausführungszugriff auf das System erhalten, und verringert das Risiko der Freigabe von Systemressourcen.

Fortgeschrittener VM-Platzierungsalgorithmus und Schutz vor Seitenkanalangriffen

Jeder Cross-VM-Angriff umfasst zwei Schritte: Das Platzieren einer vom Gegner kontrollierten VM auf demselben Host wie eine der Opfer-VMs und das Überschreiten der Isolationsgrenze, um entweder sensible Opferinformationen zu stehlen oder deren Leistung durch Ressourcendiebstahl oder Störung zu beeinträchtigen. Microsoft Azure bietet Schutz in beiden Schritten mithilfe eines erweiterten VM-Platzierungsalgorithmus und Schutz vor allen bekannten Seitenkanalangriffen, einschließlich lauter VMs des Nachbarn.

Der Azure Fabric-Controller

Der Azure Fabric Controller weist Infrastrukturressourcen Mandantenworkloads zu und verwaltet unidirektionale Kommunikationen vom Host zu virtuellen Maschinen. Der VM-Platzierungsalgorithmus ist hoch ausgefeilt und auf physischer Hostebene nahezu unmöglich vorherzusagen.

In Azure führt der virtuelle Stammcomputer ein gehärtetes Betriebssystem aus, das als Stammbetriebssystem bezeichnet wird, das einen Fabric-Agent (FA) hostet. FAs verwalten Gast-Agents (GA) innerhalb von Gastbetriebssystemen auf Kunden-VMs und verwalten auch Speicherknoten.

Die Sammlung von Azure Hypervisor, Stammbetriebssystem/FA und Kunden-VMs/GAs besteht aus einem Computeknoten. Ein Fabric-Controller (FC) verwaltet FAs. Der FC befindet sich außerhalb der Compute- und Speicherknoten. Separate FCs verwalten Compute- und Storage-Cluster. Wenn ein Kunde die Konfigurationsdatei seiner Anwendung während der Ausführung aktualisiert, kommuniziert der FC mit der FA. Der FA kontaktiert die GAs, die die Anwendung über die Konfigurationsänderung informieren. Im Falle eines Hardwarefehlers findet der FC automatisch verfügbare Hardware und startet die VM dort neu.

Die Kommunikation von einem Fabric-Controller zu einem Agenten erfolgt einseitig. Der Agent implementiert einen per SSL geschützten Dienst, der nur auf Anforderungen vom Controller antwortet. Der Agent kann keine Verbindungen zum Controller oder anderen privilegierten internen Knoten initiieren. Der FC behandelt alle Antworten als nicht vertrauenswürdig.

Die Isolation erstreckt sich von der Stamm-VM auf Gast-VMs und von einer Gast-VM auf eine andere. Computeknoten werden auch von Speicherknoten isoliert, um den Schutz zu erhöhen.

Der Hypervisor und das Hostbetriebssystem stellen Netzwerkpaketfilter bereit. Mithilfe dieser Filter wird sichergestellt, dass nicht vertrauenswürdige virtual machines keinen gefälschten Datenverkehr generieren oder nicht an sie adressierten Datenverkehr empfangen können. Sie leiten Datenverkehr an geschützte Infrastrukturendpunkte und verhindern das Senden oder Empfangen von unangemessenem Übertragungsdatenverkehr.

Weitere Regeln, die vom Fabric Controller Agent konfiguriert werden, um VM zu isolieren

Standardmäßig blockiert Azure den gesamten Datenverkehr, wenn du eine virtuelle Maschine erstellst. Anschließend konfiguriert der Fabric Controller-Agent den Paketfilter, um Regeln und Ausnahmen hinzuzufügen, um autorisierten Datenverkehr zuzulassen.

Der Fabric Controller Agent programmiert zwei Regelkategorien:

• Maschinenkonfigurations- oder Infrastrukturregeln: Standardmäßig blockiert Azure jegliche Kommunikation. Fügen Sie Ausnahmen hinzu, mit denen ein virtueller Computer DHCP- und DNS-Datenverkehr senden und empfangen kann. Virtual machines können auch Datenverkehr an das "öffentliche" Internet senden und Datenverkehr an andere virtual machines innerhalb desselben Azure Virtual Network und des Betriebssystemaktivierungsservers senden. Die Liste der erlaubten ausgehenden Ziele für virtuelle Maschinen umfasst keine Azure-Router-Subnetze, Azure-Management und andere Microsoft-Eigenschaften.
• Role-Konfigurationsdatei: Diese Datei definiert die eingehenden Access Control Listen (ACLs) basierend auf dem Dienstmodell des Mandanten.

VLAN-Isolation

Jeder Cluster enthält drei VLANs:

• Das Haupt-VLAN: Verbindet nicht vertrauenswürdige Kundenknoten.
• Das FC-VLAN: Enthält vertrauenswürdige FCs und unterstützende Systeme.
• Das Geräte-VLAN: Enthält vertrauenswürdige Netzwerk- und andere Infrastrukturgeräte.

Das FC-VLAN kann mit dem Haupt-VLAN kommunizieren, aber das Haupt-VLAN kann keine Kommunikation mit dem FC-VLAN initiieren. Das Haupt-VLAN kann auch nicht mit dem Geräte-VLAN kommunizieren. Diese VLAN-Architektur stellt sicher, dass ein Knoten, der Kundencode ausführt, selbst dann, wenn er kompromittiert wird, keine Knoten in den FC- oder Geräte-VLANs angreifen kann.

Speicherisolation

Logische Isolation zwischen Rechen- und Speichereinheiten

Im Rahmen des grundlegenden Designs trennt Microsoft Azure die VM-basierte Berechnung von storage. Dieses Design ermöglicht eine unabhängige Skalierung von Berechnung und Speicherung, was die Bereitstellung von Multitenancy und Isolation erleichtert.

Daher läuft Azure Storage auf separater Hardware ohne Netzwerkkonnektivität zu Azure Compute, außer logischer Konnektivität. Dieses Speicherdesign bedeutet, dass das System beim Erstellen einer virtuellen Festplatte keinen Speicherplatz für seine gesamte Kapazität zuweist. Stattdessen erstellt das System eine Tabelle, die Adressen auf dem virtuellen Datenträger Bereichen auf dem physischen Datenträger zuordnet. Diese Tabelle ist anfangs leer. Beim ersten Schreiben von Daten auf dem virtuellen Datenträger weist das System Speicherplatz auf dem physischen Datenträger zu und platziert einen Zeiger darauf in der Tabelle.

Isolation mithilfe der Speicherzugriffskontrolle

Access control in Azure Storage verwendet ein einfaches access control Modell. Jedes Azure-Abonnement kann ein oder mehrere Speicherkonten erstellen. Jedes Speicherkonto verfügt über einen einzigen geheimen Schlüssel, den Sie verwenden, um den Zugriff auf alle Daten in diesem Speicherkonto zu steuern.

Sie können den Zugriff auf Azure Storage-Daten (einschließlich Tabellen) durch ein SAS-Token (Shared Access Signature) steuern, das bereichspezifischen Zugang gewährt. Sie erstellen die SAS über eine Abfragevorlage (URL), und signieren sie mit dem SAK (Storage Account Key). Du kannst die signierte URL einem anderen Prozess (delegiert) geben. Der delegierte Prozess kann dann die Details der Abfrage ausfüllen und die Anforderung des storage-Diensts stellen. Mithilfe einer SAS können Sie Clients zeitbasierten Zugriff gewähren, ohne den geheimen Schlüssel des Speicherkontos offenzulegen.

Mit dem SAS können Sie einem Client für einen bestimmten Zeitraum begrenzte Berechtigungen für Objekte in Ihrem Speicherkonto und eine festgelegte Berechtigungsmenge gewähren. Sie gewähren diese eingeschränkten Berechtigungen, ohne Ihre Konto-Zugriffsschlüssel freigeben zu müssen.

Speicherisolierung auf IP-Ebene

Sie können Firewalls einrichten und einen IP-Adressbereich für Ihre vertrauenswürdigen Clients definieren. Mithilfe eines IP-Adressbereichs können nur Clients, die über eine IP-Adresse im definierten Bereich verfügen, eine Verbindung mit Azure Storage herstellen.

Verwenden Sie einen Netzwerkmechanismus, der einen dedizierten Datenverkehrstunnel dem IP-Speicher zuweist, um IP-Speicherdaten vor unbefugten Nutzern zu schützen.

Verschlüsselung

Azure bietet die folgenden Verschlüsselungstypen zum Schutz von Daten:

• Verschlüsselung während der Übertragung
• Verschlüsselung ruhender Daten

Verschlüsselung während der Übertragung

Verschlüsselung während der Übertragung schützt Daten, wenn sie über Netzwerke übertragen werden. Durch den Einsatz von Azure Storage können Sie Daten mithilfe von absichern:

• Transport-Level-Verschlüsselung, z. B. HTTPS, wenn Sie Daten in oder aus Azure Storage übertragen.
• Wire-Verschlüsselung (etwa SMB 3.0-Verschlüsselung für Azure-Dateifreigaben).
• Client-seitige Verschlüsselung, um die Daten zu verschlüsseln, bevor sie in den Speicher übertragen werden, und um die Daten zu entschlüsseln, nachdem sie aus dem Speicher übertragen wurden.

Verschlüsselung ruhender Daten

Für viele Organisationen ist die Verschlüsselung ruhender Daten ein obligatorischer Schritt in Richtung Datenschutz, Compliance und Datensouveränität. Azure Features, die die Verschlüsselung ruhender Daten bereitstellen, umfassen:

• Die Verschlüsselung von Storage Services verschlüsselt die Daten automatisch, wenn sie in Azure Storage geschrieben werden.
• Client-seitige Verschlüsselung verschlüsselt Daten, bevor sie in den Speicher übertragen werden.
• Verschlüsselung auf dem Host bietet End-to-End-Verschlüsselung für VM-Daten.

Verschlüsselung auf dem Host

Verschlüsselung am Host bietet End-to-End-Verschlüsselung für Ihre VM-Daten, indem Daten auf VM-Hostebene verschlüsselt werden. Standardmäßig werden plattformverwaltete Schlüssel verwendet, Sie können jedoch optional kundengesteuerte Schlüssel verwenden, die in Azure Key Vault oder Azure Key Vault Managed HSM gespeichert sind, wenn Sie eine größere Kontrolle benötigen.

Verschlüsselung auf Host bietet serverseitige Verschlüsselung auf VM-Hostebene mithilfe der AES 256-Verschlüsselung, die FIPS 140-2 kompatibel ist. Diese Verschlüsselung tritt auf, ohne VM-CPU-Ressourcen zu verbrauchen und bietet End-to-End-Verschlüsselung für:

• Temporäre Datenträger
• Betriebssystem- und Datenträgercaches
• Datenflüsse in Azure Storage

Wichtige Vorteile der Verschlüsselung auf Host:

• Keine Leistungsbeeinträchtigung: Die Verschlüsselung erfolgt auf Host-Ebene ohne Nutzung von VM-CPU-Ressourcen.
• Breite VM-Unterstützung: Unterstützt bei den meisten VM-Serien und -Größen.
• Kundenverwaltete Schlüssel: Optionale Integration mit Azure Key Vault oder Managed HSM zur Schlüsselkontrolle.
• Plattformverwaltete Schlüssel standardmäßig: Keine zusätzliche Konfiguration für die Verschlüsselung erforderlich.

Weitere Informationen finden Sie unter Encryption auf host und Overview of managed disk encryption options.

SQL-Datenbankisolation

Azure SQL-Datenbank ist ein cloudbasierter relationaler Datenbankdienst, der auf der Microsoft SQL Server Engine basiert. Azure SQL-Datenbank ist ein hochverfügbarer, skalierbarer, multitenanter Datenbankdienst mit vorhersehbarer Datenisolation auf Konto-, Geografie-, Regions- und Netzwerkebene. Der Dienst bietet diese Datenbankisolation mit nahezu null Verwaltung.

SQL-Datenbankanwendungsmodell

Aus der Sicht der Anwendung bietet SQL Database die folgende Hierarchie, bei der jede Ebene die darunter liegenden Ebenen einschließt (one-to-many).

Das Konto und das Abonnement sind Microsoft Azure Plattformkonzepte, um Abrechnung und Verwaltung zuzuordnen.

Logische SQL-Server und -Datenbanken sind SQL-Datenbankspezifische Konzepte. Sie verwalten sie, indem Sie von der SQL-Datenbank bereitgestellte OData- und T-SQL-Schnittstellen oder das Azure-Portal verwenden.

Server in SQL Database sind keine physischen oder VM-Instanzen. Stattdessen handelt es sich um Sammlungen von Datenbanken, die Management- und Sicherheitsrichtlinien teilen und in einer sogenannten logischen Hauptdatenbank gespeichert sind.

Logische Masterdatenbanken umfassen Folgendes:

• SQL-Anmeldungen zum Herstellen der Verbindung mit dem Server
• Firewallregeln

Abrechnungs- und nutzungsbezogene Informationen für Datenbanken vom selben Server sind nicht garantiert, dass sie auf derselben physischen Instanz im Cluster liegen. Anwendungen müssen beim Verbinden den Namen der Zieldatenbank angeben.

Aus deiner Sicht erstellst du einen Server in einer geografischen Region, aber Azure erstellt den Server in einem der Cluster in dieser Region.

Isolierung durch Netzwerktopologie

Wenn du einen Server erstellst und seinen DNS-Namen registrierst, verweist der DNS-Name auf die Gateway-VIP-Adresse im jeweiligen Rechenzentrum, in dem du den Server platzierst.

Hinter der VIP (virtuelle IP-Adresse) gibt es eine Sammlung zustandsloser Gatewaydienste. Im Allgemeinen werden Gateways einbezogen, wenn die Koordination zwischen mehreren Datenquellen (Masterdatenbank, Benutzerdatenbank usw.) erforderlich ist. Gatewaydienste implementieren die folgenden Funktionen:

• Proxyfunktion für TDS-Verbindung: Diese Funktion umfasst das Auffinden der Benutzerdatenbank im Back-End-Cluster, die Implementierung der Authentifizierungssequenz und anschließendes Weiterleiten der TDS-Pakete an das Back-End und zurück.
• Datenbankverwaltung: Diese Funktion umfasst die Implementierung einer Sammlung von Workflows zum Verarbeiten von CREATE-, ALTER- und DROP-Datenbankvorgängen. Der Dienst kann Datenbankoperationen aufrufen, indem er entweder TDS-Pakete oder explizite OData-APIs snifft.
• CREATE-, ALTER- und DROP-Authentifizierungs- und Benutzeroperationen
• Serververwaltungsvorgänge über die OData-API

Die Ebene hinter den Gateways wird als Back-End bezeichnet. Das Backend-Tier speichert alle Daten auf eine hochzugängliche Weise. Jedes Datenelement gehört zu einer Partition oder Failovereinheit, und jede Partition verfügt über mindestens drei Replikate. Das SQL Server-Modul speichert und repliziert Replikate, und ein Failoversystem, das häufig als fabric bezeichnet wird, verwaltet sie.

Normalerweise kommuniziert das Back-End-System aus Sicherheitsgründen nicht in ausgehender Richtung mit anderen Systemen. Azure reserviert die ausgehende Kommunikation an die Systeme im Frontend-(Gateway-) Tier. Die Gateway-Tier-Rechner verfügen über begrenzte Rechte auf den Backend-Rechnern. Diese Einschränkung minimiert die Angriffsfläche als Mechanismus zur Verteidigung in der Tiefe.

Isolierung nach Maschinenfunktion und Zugriff

SQL Database umfasst Dienste, die auf verschiedenen Maschinenfunktionen laufen. SQL Database teilt diese Dienste in Backend-Cloud-Datenbanken sowie Frontend-Gateway- und Managementumgebungen auf, wobei das allgemeine Prinzip gilt, dass der Datenverkehr nur ins Backend und nicht nach außen geht. Die Frontend-Umgebung kann mit der Außenwelt anderer Dienste kommunizieren und hat im Allgemeinen nur begrenzte Berechtigungen im Backend (genug, um die benötigten Einstiegspunkte aufzurufen).

Netzwerkisolation

Azure-Deployments verfügen über mehrere Schichten der Netzwerkisolation. Das folgende Diagramm zeigt verschiedene Schichten der Netzwerkisolation, die Azure bereitstellt. Diese Schichten enthalten native Azure-Plattformfunktionen und kundendefinierte Funktionen. Eingehend aus dem Internet bietet Azure DDoS Protection eine Isolierung gegen groß angelegte Angriffe auf Azure. Die nächste Isolationsebene ist kundendefinierte öffentliche IP-Adressen (Endpunkte), die Sie verwenden, um zu bestimmen, welcher Datenverkehr den Clouddienst an die virtual network übergeben kann. Die native virtuelle Netzwerkisolation von Azure gewährleistet vollständige Isolation von allen anderen Netzwerken. Traffic fließt nur über vom Nutzer konfigurierte Pfade und Methoden. Diese Pfade und Methoden sind die nächste Schicht, in der NSGs, UDR und Sie Netzwerk-virtuelle Appliances nutzen können, um Isolationsgrenzen zu schaffen, um die Anwendungseinsätze im geschützten Netzwerk zu schützen.

Traffic isolation: Ein virtuelles Netzwerk ist die Grenze für die Isolation des Datenverkehrs auf der Azure-Plattform. Virtual machines (VMs) in einem virtual network können nicht direkt mit virtuellen Computern in einem anderen virtual network kommunizieren, auch wenn beide virtuellen Netzwerke vom gleichen Kunden erstellt werden. Isolation ist eine entscheidende Eigenschaft, die sicherstellt, dass Kunden-VMs und Kommunikation innerhalb eines virtuellen Netzwerks privat bleiben.

Ein Subnetz bietet eine weitere Isolationsschicht innerhalb eines virtuellen Netzwerks basierend auf IP-Reichweite. Sie können eine virtual network in mehrere Subnetze für Organisation und Sicherheit unterteilen. VMs und PaaS-Rolleninstanzen, die in Subnetzen (identisch oder anders) innerhalb eines virtual network bereitgestellt werden, können ohne zusätzliche Konfiguration miteinander kommunizieren. Sie können auch Netzwerksicherheitsgruppen (Network Security Groups, NSGs) so konfigurieren, dass netzwerkdatenverkehr zu einer VM-Instanz basierend auf Sicherheitsregeln zugelassen oder verweigert wird. Sie können NSGs entweder subnetzen oder einzelnen Netzwerkschnittstellen zuordnen, die an VMs angefügt sind. Wenn Sie ein NSG einem Subnetz zuordnen, gelten die Sicherheitsregeln für alle VM-Instanzen in diesem Subnetz.

Nächste Schritte

• Erfahren Sie mehr über network-Sicherheitsgruppen. Netzwerksicherheitsgruppen filtern den Netzwerkdatenverkehr zwischen Azure Ressourcen in einem virtual network. Sie können den Datenverkehr zu Subnetzen oder virtuellen Maschinen durch Sicherheitsregeln einschränken, die auf Quelle, Ziel, Port und Protokoll basieren.

• Erfahren Sie mehr über virtual machine isolation in Azure. Azure Compute bietet virtuelle Computergrößen, die für einen bestimmten Hardwaretyp isoliert sind und einem einzelnen Kunden zugeordnet sind.