Teilen über

Azure Information System-Komponenten und -Grenzen

Dieser Artikel enthält eine allgemeine Beschreibung der Azure-Architektur und -Verwaltung. Die Azure-Systemumgebung besteht aus den folgenden Netzwerken:

  • Microsoft Azure-Produktionsnetzwerk (Azure-Netzwerk)
  • Microsoft-Unternehmensnetzwerk (Corpnet)

Separate IT-Teams sind für den Betrieb und die Wartung dieser Netzwerke verantwortlich.

Azure-Architektur

Azure ist eine Cloud Computing-Plattform und Infrastruktur zum Erstellen, Bereitstellen und Verwalten von Anwendungen und Diensten über ein Netzwerk von Rechenzentren. Microsoft verwaltet diese Rechenzentren. Basierend auf der Anzahl der von Ihnen angegebenen Ressourcen erstellt Azure virtuelle Computer (VMs) basierend auf dem Ressourcenbedarf. Diese virtuellen Computer werden auf einem Azure-Hypervisor ausgeführt, der für die Verwendung in der Cloud entwickelt wurde und für die Öffentlichkeit nicht zugänglich ist.

Auf jedem physischen Azure-Serverknoten gibt es einen Hypervisor, der direkt über die Hardware ausgeführt wird. Der Hypervisor teilt einen Knoten in eine variable Anzahl von Gast-VMs auf. Jeder Knoten verfügt auch über einen virtuellen Stammcomputer, der das Hostbetriebssystem ausführt. Die Windows-Firewall ist auf jedem virtuellen Computer aktiviert. Sie definieren, welche Ports adressierbar sind, indem Sie die Dienstdefinitionsdatei konfigurieren. Diese Ports sind die einzigen offenen und adressierbaren, intern oder extern. Der gesamte Datenverkehr und der Zugriff auf den Datenträger und das Netzwerk werden vom Hypervisor und dem Stammbetriebssystem vermittelt.

Auf der Hostebene führen Azure-VMs eine angepasste und gehärtete Version der neuesten Windows Server-Version aus. Azure verwendet eine Version von Windows Server, die nur diese Komponenten enthält, die zum Hosten von VMs erforderlich sind. Dadurch wird die Leistung verbessert und die Angriffsfläche reduziert. Computergrenzen werden vom Hypervisor erzwungen, was nicht von der Betriebssystemsicherheit abhängt.

Azure-Verwaltung durch Fabric-Controller

In Azure werden virtuelle Computer, die auf physischen Servern (Blades/Knoten) ausgeführt werden, in Clustern von ca. 1000 gruppiert. Die virtuellen Computer werden unabhängig von einer skalierten und redundanten Plattformsoftwarekomponente verwaltet, die als Fabric Controller (FC) bezeichnet wird.

Jeder FC verwaltet den Lebenszyklus von Anwendungen, die in seinem Cluster ausgeführt werden, und stellt die Integrität der Hardware unter ihrer Kontrolle bereit und überwacht sie. Es führt autonome Vorgänge aus, z. B. das Reincarnieren von VM-Instanzen auf fehlerfreien Servern, wenn festgestellt wird, dass ein Server fehlgeschlagen ist. Der FC führt auch Anwendungsverwaltungsvorgänge aus, z. B. Bereitstellen, Aktualisieren und Skalieren von Anwendungen.

Das Rechenzentrum ist in Cluster unterteilt. Cluster isolieren Fehler auf FC-Ebene und verhindern, dass bestimmte Arten von Fehlern Auswirkungen auf Server außerhalb des Clusters haben, in dem sie auftreten. FCs, die einem bestimmten Azure-Cluster dienen, werden in einem FC-Cluster gruppiert.

Hardwareinventar

Der FC bereitet eine Bestandsaufnahme von Azure-Hardware- und Netzwerkgeräten während des Bootstrap-Konfigurationsprozesses vor. Alle neuen Hardware- und Netzwerkkomponenten, die in die Azure-Produktionsumgebung eintreten, müssen dem Bootstrap-Konfigurationsprozess folgen. Der FC ist für die Verwaltung des gesamten Inventars verantwortlich, das in der datacenter.xml Konfigurationsdatei aufgeführt ist.

Vom FC verwaltete Betriebssystemimages

Das Betriebssystemteam stellt Bilder in Form von virtuellen Festplatten bereit, die auf allen Host- und Gast-VMs in der Azure-Produktionsumgebung bereitgestellt werden. Das Team erstellt diese Basisimages über einen automatisierten Offlinebuildprozess. Das Basisimage ist eine Version des Betriebssystems, in dem der Kernel und andere Kernkomponenten geändert und optimiert wurden, um die Azure-Umgebung zu unterstützen.

Es gibt drei Arten von durch Fabrics verwaltete Betriebssystemimages:

  • Host: Ein angepasstes Betriebssystem, das auf Host-VMs ausgeführt wird.
  • Nativ: Ein natives Betriebssystem, das auf Mandanten (z.B. Azure Storage) ausgeführt wird. Dieses Betriebssystem hat keinen Hypervisor.
  • Gast: Ein Gastbetriebssystem, das auf Gast-VMs ausgeführt wird.

Die host- und nativen vom FC verwalteten Betriebssysteme sind für die Verwendung in der Cloud konzipiert und sind nicht öffentlich zugänglich.

Host- und systemeigene Betriebssysteme

Das Host- und native Betriebssystem sind Betriebssystemimages mit verstärkter Sicherheit, die die Fabric-Agents hosten und einen Computeknoten (wird als erste VM auf dem Knoten ausgeführt) sowie Speicherknoten ausführen. Der Vorteil bei der Verwendung optimierter Basisimages des Host- und nativen Betriebssystems besteht darin, dass sie die Angriffsfläche verringern, die durch APIs und ungenutzte Komponenten geschaffen wird. Diese können hohe Sicherheitsrisiken darstellen und den Fußabdruck des Betriebssystems erhöhen. Betriebssysteme mit eingeschränktem Speicherbedarf enthalten nur die Komponenten, die für Azure erforderlich sind.

Gastbetriebssystem

Interne Azure-Komponenten, die auf VMs des Gastbetriebssystems ausgeführt werden, haben keine Möglichkeit, Remotedesktopprotokoll auszuführen. Alle Änderungen an den Basiskonfigurationseinstellungen müssen den Änderungs- und Veröffentlichungsverwaltungsprozess durchlaufen.

Azure-Rechenzentren

Das Microsoft Cloud Infrastructure and Operations (MCIO)-Team verwaltet die physische Infrastruktur und Rechenzentren für alle Microsoft-Onlinedienste. MCIO ist in erster Linie für die Verwaltung der physischen und Umgebungskontrollen innerhalb der Rechenzentren sowie für die Verwaltung und Unterstützung äußerer Umkreisnetzwerkgeräte (z. B. Edgerouter und Rechenzentrumsrouter) verantwortlich. MCIO ist auch für die Einrichtung der minimalen Serverhardware auf Racks im Rechenzentrum verantwortlich. Kunden haben keine direkte Interaktion mit Azure.

Dienstverwaltungs- und Serviceteams

Verschiedene Engineering-Gruppen, die als Serviceteams bezeichnet werden, verwalten die Unterstützung des Azure-Diensts. Jedes Serviceteam ist für einen Bereich des Supports für Azure verantwortlich. Jedes Serviceteam muss einen Techniker 24x7 zur Verfügung stellen, um Fehler im Dienst zu untersuchen und zu beheben. Serviceteams haben standardmäßig keinen physischen Zugriff auf die Hardware, die in Azure ausgeführt wird.

Die Serviceteams sind:

  • Anwendungsplattform
  • Microsoft Entra ID
  • Azure Compute
  • Azurblaues Netz
  • Cloud-Engineering-Dienstleistungen
  • ISSD: Sicherheit
  • Mehrstufige Authentifizierung
  • SQL-Datenbank
  • Lagerung

Benutzertypen

Mitarbeiter (oder Auftragnehmer) von Microsoft gelten als interne Benutzer. Alle anderen Benutzer gelten als externe Benutzer. Alle internen Azure-Benutzer haben ihren Mitarbeiterstatus mit einer Vertraulichkeitsstufe kategorisiert, die ihren Zugriff auf Kundendaten definiert (Zugriff oder keinen Zugriff). Benutzerberechtigungen für Azure (Autorisierungsberechtigungen nach der Authentifizierung) werden in der folgenden Tabelle beschrieben:

Rolle Intern oder extern Vertraulichkeitsstufe Autorisierte Berechtigungen und ausgeführte Funktionen Zugriffstyp
Azure-Rechenzentrumstechniker Intern Kein Zugriff auf Kundendaten Verwalten Sie die physische Sicherheit des Geländes. Führen Sie Patrouillen in und außerhalb des Rechenzentrums durch, und überwachen Sie alle Einstiegspunkte. Begleiten Sie bestimmte nicht freigegebene Personen in das Rechenzentrum hinein und aus dem Rechenzentrum heraus, die allgemeine Dienstleistungen (z. B. Gastronomie oder Reinigung) oder IT-Arbeiten innerhalb des Rechenzentrums leisten. Führen Sie routinebasierte Überwachung und Wartung von Netzwerkhardware durch. Durchführung von Incident Management und Break-Fix-Arbeiten mithilfe verschiedener Tools. Führen Sie routinebasierte Überwachung und Wartung der physischen Hardware in den Rechenzentren durch. Auf Anfrage Zugang zur Umgebung von Grundstückeigentümern. In der Lage, forensische Untersuchungen durchzuführen, Vorfallberichte zu protokollieren und obligatorische Sicherheitsschulungen und Richtlinienanforderungen zu erfordern. Betriebsbesitz und Wartung kritischer Sicherheitstools, z. B. Scanner und Protokollsammlung. Beständiger Zugriff auf die Umgebung.
Azure-Incidentselektierung (Rapid Response-Techniker) Intern Zugriff auf Kundendaten Verwalten Sie die Kommunikation zwischen MCIO, Support und Engineering-Teams. Triage-Plattformvorfälle, Bereitstellungsprobleme und Serviceanfragen. Just-in-Time-Zugriff auf die Umgebung mit eingeschränktem permanentem Zugriff auf Nicht-Kundensysteme.
Azure-Bereitstellungstechniker Intern Zugriff auf Kundendaten Bereitstellen und Aktualisieren von Plattformkomponenten, Software und geplanten Konfigurationsänderungen zur Unterstützung von Azure. Just-in-Time-Zugriff auf die Umgebung mit eingeschränktem permanentem Zugriff auf Nicht-Kundensysteme.
Azure-Kundensupport bei Ausfällen (Mandant) Intern Zugriff auf Kundendaten Debuggen und Diagnostizieren von Plattformausfällen und Fehlern bei einzelnen Computemandanten und Azure-Konten. Analysieren Sie Fehler. Fördern Sie wichtige Fixes für die Plattform oder den Kunden, und fördern Sie technische Verbesserungen für den gesamten Support. Just-in-Time-Zugriff auf die Umgebung mit eingeschränktem permanentem Zugriff auf Nicht-Kundensysteme.
Azure Live Site Engineers (Überwachungsengineers) und Incident Intern Zugriff auf Kundendaten Diagnostizieren und Beheben von Problemen mit der Plattformintegrität durch Diagnosetools. Steuern von Fehlerbehebungen für Volumetreiber, Reparatur von durch Ausfälle verursachten Posten und Unterstützung bei Maßnahmen zur Behebung von Ausfällen. Just-in-Time-Zugriff auf die Umgebung mit eingeschränktem permanentem Zugriff auf Nicht-Kundensysteme.
Azure-Kunden Äußerlich Nicht verfügbar Nicht verfügbar Nicht verfügbar

Azure verwendet eindeutige IDs, um Organisationsbenutzer und -kunden zu authentifizieren (oder Prozesse, die im Auftrag von Organisationsbenutzern handeln). Dies gilt für alle Ressourcen und Geräte, die Teil der Azure-Umgebung sind.

Interne Azure-Authentifizierung

Die Kommunikation zwischen internen Azure-Komponenten ist mit TLS-Verschlüsselung geschützt. In den meisten Fällen sind die X.509-Zertifikate selbstsigniert. Zertifikate mit Verbindungen, auf die von außerhalb des Azure-Netzwerks zugegriffen werden kann, sind eine Ausnahme, wie Zertifikate für die FCs. FCs verfügen über Zertifikate, die von einer Microsoft Certificate of Authority (CA) ausgestellt wurden, die von einer vertrauenswürdigen Stammzertifizierungsstelle unterstützt wird. Dadurch kann problemlos ein Rollover für öffentliche FC-Schlüssel ausgeführt werden. Darüber hinaus verwenden Microsoft-Entwicklertools FC Public Keys. Wenn Entwickler neue Anwendungsbilder übermitteln, werden die Bilder mit einem öffentlichen FC-Schlüssel verschlüsselt, um eingebettete Geheimnisse zu schützen.

Azure-Hardwaregeräteauthentifizierung

Der FC verwaltet eine Reihe von Anmeldeinformationen (Schlüssel und/oder Kennwörter), die zur Authentifizierung bei verschiedenen Hardwaregeräten unter seiner Kontrolle verwendet werden. Microsoft verwendet ein System, um den Zugriff auf diese Anmeldeinformationen zu verhindern. Insbesondere wurde der Transport, die Persistenz und die Verwendung dieser Anmeldeinformationen entwickelt, um den Zugriff von Azure-Entwicklern, Administratoren sowie Sicherungsdiensten und -personal auf sensible, vertrauliche oder private Informationen zu verhindern.

Microsoft verwendet Verschlüsselung basierend auf dem öffentlichen Master-Identity-Schlüssel des FC. Dies geschieht bei FC-Setup- und FC-Neukonfigurationszeiten, um die Anmeldeinformationen zu übertragen, die für den Zugriff auf Netzwerkhardwaregeräte verwendet werden. Wenn der FC die Anmeldeinformationen benötigt, ruft der FC sie ab und entschlüsselt sie.

Netzwerkgeräte

Das Azure-Netzwerkteam konfiguriert Netzwerkdienstkonten, damit ein Azure-Client sich bei Netzwerkgeräten authentifiziert (Router, Switches und Lastenausgleichsgeräte).

Sichere Dienstverwaltung

Azure-Betriebsmitarbeiter müssen sichere Administratorarbeitsstationen (SAWs) verwenden. Kunden können ähnliche Steuerelemente mithilfe von Arbeitsstationen mit privilegiertem Zugriff implementieren. Bei SAWs verwenden Verwaltungsmitarbeiter ein individuell zugewiesenes Administratorkonto, das vom Standardbenutzerkonto getrennt ist. Die SAW baut auf dieser Kontotrennungspraxis auf, indem eine vertrauenswürdige Arbeitsstation für diese vertraulichen Konten bereitgestellt wird.

Nächste Schritte

In den folgenden Artikeln erfahren Sie mehr über den Schutz der Azure-Infrastruktur durch Microsoft: