Teilen über

Bewerten Sie staatliche Anforderungen

  • Artikel

Das Microsoft Cloud Adoption Framework für Azure ist ein vollständiges Lebenszyklus-Framework, das Cloud-Architekten, IT-Experten und Geschäftsentscheidungsträgern hilft, ihre Cloud-Einführungsziele zu erreichen. Es bietet Best Practices, Dokumentationen und Tools, die bei der Erstellung und Umsetzung von Geschäfts- und Technologiestrategien für die Cloud helfen. Organisationen des öffentlichen Sektors, die strenge Souveränitätsanforderungen haben, können ihre Souveränitätsziele in ihre Planungsbemühungen einbeziehen, sodass strategische Entscheidungen zur Cloud-Einführung mit diesen Souveränitätsanforderungen in Einklang gebracht werden.

Dieser Artikel hebt Bereiche hervor, in denen Organisationen ihre Souveränitätsanforderungen bewerten, identifizieren und dokumentieren möchten, und bietet Empfehlungen dazu, wo diese Anforderungen in ihre umfassenderen Planungsbemühungen im Zusammenhang mit dem Cloud Adoption Framework für Azure passen könnten.

Ermitteln von unabhängigen Daten

Zu den Anforderungen an die Datensouveränität können Mandate gehören, das Eigentum an Daten zu behalten und Methoden für die Speicherung, Nutzung und Übertragung von Daten festzulegen. Manchmal können Anforderungen an die Datensouveränität auch Einschränkungen oder Vorschriften hinsichtlich der Datenresidenz beinhalten. Das Verständnis dieser Anforderungen zu Beginn der Cloud-Reise eines Unternehmens kann dazu beitragen, gemeinsame Entwurfsmuster für die Datensouveränität zu etablieren, anstatt von Workload-Eigentümern zu erwarten, dass sie Lösungen zur Erfüllung von Souveränitätsanforderungen entwickeln.

Organisationen, die das Cloud Adoption Framework für Azure befolgen, identifizieren in der Planungsphase Kandidaten-Workloads für die Migration in die Cloud und entwerfen dann die Umgebung zum Hosten dieser Workloads während der Bereitschaftsphase. Diese Aktivitäten können es einer Organisation ermöglichen, souveräne Datentypen zu identifizieren, die eine besondere Behandlung in der Zielzustands-Cloud-Umgebung erfordern.

Microsoft verwendet viele Arten von Daten, z. B. persönliche Informationen, die Microsoft zur Verfügung gestellt werden, und Kundendaten, die in Cloud-Dienste hochgeladen werden, um Online- und professionelle Dienste bereitzustellen. Die Datenschutzverantwortung von Microsoft ist im Microsoft Products and Services Data Protections Addendum (DPA) dokumentiert und in den Vereinbarungen einer Organisation mit Microsoft enthalten. Das DPA spezifiziert die verschiedenen Datentypen, die Microsoft verwaltet, und beschreibt die von Microsoft zum Schutz dieser Datentypen verwendeten Praktiken.

Viele Organisationen verfügen über bestehende Data-Governance-Programme, die Anforderungen für den Umgang mit sensiblen Daten festlegen, und können anhand dieser Informationen bestimmen, ob Anforderungen an die Datensouveränität für alle oder nur eine Teilmenge der Datenklassifizierungen gelten. Wenn eine Organisation ihre Daten in einen Cloud-Dienst hochlädt und verwaltet, liegt es in ihrer Verantwortung, die Daten entsprechend ihren Datenverarbeitungsanforderungen genau zu klassifizieren, zu kennzeichnen und zu verwalten. Einige Unternehmen möchten die Cloud-Einführung möglicherweise als Gelegenheit nutzen, ihre Datenklassifizierungsprogramme zu überprüfen.

Weitere Informationen dazu, wie sich die Datenklassifizierung auf die Cloud-Einführung auswirkt, finden Sie in den Cloud-Governance-Leitfäden Datenklassifizierung in Azure und Cloud-Governance-Anleitungen.

Beispiele für Anforderungen zur Datenhoheit

Organisationen mit strengen Anforderungen an die Datensouveränität müssen möglicherweise einige der folgenden repräsentativen Szenarien einplanen, wenn sie Arbeitslasten in die Cloud migrieren.

Beschriftung der Datenklassifizierung

Klassifizierungsbeschriftungen kennzeichnen Ressourcen mit besonderen Anforderungen an die Handhabung. Während Klassifizierungsbeschriftungen auf Dokumente angewendet werden, können sie auch auf Assets angewendet werden. Kunden können die nativen Tagging-Funktionen in Azure verwenden, um Klassifizierungsbeschriftungen auf Ressourcen wie Compute Services und Datenspeicher sowie auf logische Strukturen in Azure wie Abonnements und Verwaltungsgruppen anzuwenden.

Weitere Informationen finden Sie unter Tagging in Azure und Microsoft Purview eDiscovery-Lösungen.

Datenklassifizierungsgrenzen

Wenn eine Organisation beschließt, Daten (oder Anwendungen) einer ähnlichen Klassifizierung zu aggregieren, wird häufig ein Sicherheitsperimeter eingesetzt, der als Grenze des Standorts dient, an dem die Datenspeicherung zulässig ist. Wenn Kunden Arbeitslasten in Azure bereitstellen, können sie Abonnements und Verwaltungsgruppen verwenden, um logische Grenzen innerhalb der Cloud-Umgebung der Organisation zu schaffen. Diese Grenzen tragen dazu bei, Vertraulichkeitsrisiken im Zusammenhang mit unbefugtem Zugriff und Datenschutzrisiken im Zusammenhang mit der Datenaggregation und -zuordnung zu mindern.

Organisationen mit strengen Anforderungen an die Datensouveränität sollten möglicherweise darüber nachdenken, ob sie ihre Umgebung in einem hierarchischen Modell organisieren möchten, bei dem höhere Privilegienebenen niedrigere Privilegienebenen erben (z. B. wie im Bell-LaPadula-Modell), oder ob sie dies bevorzugen um ein nicht hierarchisches Modell zu implementieren, bei dem obligatorische Zugangskontrollen verwendet werden, um Grenzen zu schaffen, die Teile der Umgebung vom Rest der Umgebung abgrenzen. Entscheidungen darüber, wie eine Organisation Datenklassifizierungsgrenzen verwaltet, sind beim Entwerfen von Landing Zones in der Bereitschaftsphase des Cloud Adoption Framework für Azure von entscheidender Bedeutung.

Weitere Informationen finden Sie unter Verwaltungsgruppen in Azure und Data Governance.

Datenresidenz

Organisationen, die Anforderungen an die Datenresidenz erfüllen müssen, sollten besonders darauf achten, welche Azure-Dienste sie zur Unterstützung einer Arbeitslast benötigen und wo diese Dienste geografisch verfügbar sind. Azure-Dienste werden in Regionen bereitgestellt, die Netzwerkverbindungen mit geringer Latenz und Funktionen wie Verfügbarkeitszonen unterstützen. Diese Regionen sind in Regionen gruppiert, die zusätzliche Ausfallsicherheits- und Notfallwiederherstellungsfunktionen bieten.

Wenn eine Organisation die Datenresidenz für ihre Arbeitslast aufrechterhalten muss, muss sie sicherstellen, dass die verwendeten Azure-Dienste in ihrer bevorzugten Region und Region verfügbar sind. Darüber hinaus werden einige Dienste weltweit bereitgestellt und bieten keine Datenresidenz innerhalb einer bestimmten Region oder Region für die in diesem Dienst gespeicherten Daten.

Weitere Informationen zur Datenresidenz, zu Azure-Regionen und -Verfügbarkeitszonen sowie zur regionalen Verfügbarkeit von Azure-Diensten finden Sie in den folgenden Artikeln:

Eigentum, Verwahrung und Portabilität von Daten

Kunden mit strengen Anforderungen an die Datensouveränität haben oft viele Fragen dazu, wer Eigentümer der in Azure gespeicherten Daten bleibt, wer auf diese Daten zugreifen kann und was mit diesen Daten passiert, wenn ein Kunde beschließt, seine Workload auf eine andere Plattform zu verlagern. Diese Anforderungen können in Umfang und Spezifität variieren, beziehen sich jedoch in der Regel auf die grundlegende Frage, was mit Daten passiert, wenn Sie sie in einem Microsoft Cloud Service hosten.

Um diese Fragen auf hoher Ebene zu beantworten und Kunden einen Ausgangspunkt für die Ermittlung ihrer Anforderungen an die Datensouveränität zu geben, die für Cloud-Dienstanbieter gelten, hat Microsoft eine Reihe von Artikeln zum Schutz und zur Verwaltung von Kundendaten veröffentlicht, in denen viele dieser und weitere Fragen behandelt werden. Artikel sind online im Trust Center verfügbar.

Weitere Informationen finden Sie unter Datenverwaltung bei Microsoft.

Behalten Sie die operative Souveränität in der Cloud

Anforderungen an die betriebliche Souveränität können sich darauf auswirken, wie eine Umgebung in Azure entworfen, aktualisiert und verwaltet wird. Daher ist es wichtig, ein klares Verständnis dieser Anforderungen zu haben, bevor technische Entwürfe im Rahmen der Bereitschaftsphase des Cloud Adoption Framework für Azure finalisiert werden. Zu den allgemeinen Anforderungen an die operative Souveränität können gehören:

  • Beschränkungen hinsichtlich des Standorts und der Nationalität des Verwaltungspersonals.
  • Zugriffskontrollanforderungen, die den privilegierten Zugriff von Cloud-Dienstanbietern einschränken.
  • Mandate für hohe Verfügbarkeit und Notfallwiederherstellung

Es ist wichtig, die Absicht und die Risiken, die diese Anforderungen mindern, klar zu verstehen, da viele dieser Anforderungen in der Cloud mit anderen als den üblicherweise verwendeten Methoden erfüllt werden lokal.

Nachdem die Organisation die betrieblichen Souveränitätsanforderungen ermittelt hat, kann sie die geeigneten technischen und administrativen Souveränitätskontrollen auswählen, um das richtige Maß an Risikominderung und -Sicherheit zu gewährleisten. Bei der Auswahl von Souveränitätskontrollen ist es wichtig zu verstehen, dass die Auswahl einiger Funktionen, die zusätzliche betriebliche Souveränität bieten können, die Optionen einer Organisation für die Einführung anderer Azure-Dienste einschränkt.

Beispielsweise muss eine Organisation, die vertrauliches Computing für ihre Azure-Workloads benötigt, ihre Architekturauswahl auf Dienste beschränken, die auf Azure Confidential Computing ausgeführt werden können, wie etwa Confidential Virtual Machines oder Confidential Containers. Aus diesem Grund ist es oft eine gute Idee, betriebliche Souveränitätsanforderungen mit einer bestimmten Datenklassifizierung zu verknüpfen, anstatt einen Ansatz zu verfolgen, bei dem alle Workloads und Daten die restriktivsten Souveränitätsanforderungen erfüllen müssen.

Darüber hinaus sind einige Anforderungen an die betriebliche Souveränität wie Autarkie (z. B. die Fähigkeit, unabhängig von externen Netzwerken und Systemen zu laufen) auf Hyperscale-Cloud-Computing-Plattformen wie Azure, die auf regelmäßige Plattformaktualisierungen angewiesen sind, um Systeme in einem optimalen Zustand zu halten, nicht umsetzbar.

Beispiele für Anforderungen an die operative Souveränität

Einige allgemeine Anforderungen an die betriebliche Souveränität sowie Beispiele relevanter Azure-Dienste und -Funktionen, die diese Anforderungen erfüllen können, sind wie folgt:

Softwaresicherheit

Zu den Softwaresicherheitsanforderungen können Entwicklungsaktivitäten wie die Anwendung spezifischer kryptografischer Sicherheitsmaßnahmen, die Durchführung von Codeüberprüfungen sowie die Durchführung von Anwendungssicherheits- und Penetrationstests gehören. Dazu können auch betriebliche Prozesse gehören, etwa die Implementierung von Zugangskontrollen, der Einsatz von Verschlüsselungstechnologien und die Überwachung von Sicherheitsereignissen.

Microsoft bietet verschiedene Funktionen, um Kunden bei der Erfüllung der Anforderungen an die betriebliche Souveränität für von Microsoft und Kunden entwickelte Software zu unterstützen. Microsoft folgt bei der Entwicklung von Software auf Plattformebene für Azure dem Secure Development Lifecycle (SDL). Die 12 Praktiken des SDL sind in die technischen Prozesse und Verfahren von Microsoft integriert und werden im Rahmen der Assurance-Aktivitäten von Microsoft regelmäßig bewertet. Darüber hinaus bietet Microsoft Funktionen, die Kunden bei der Einführung der Secure Development Lifecycle-Praktiken als Teil ihres Softwareentwicklungslebenszyklus unterstützen.

Weitere Informationen finden Sie unter Microsoft Secure Development Lifecycle und Best Practices für sichere Entwicklung auf Azure.

Infrastruktursicherheit

Workloads, die auf Azure ausgeführt werden, können die vielen Funktionen nutzen, die Microsoft entwickelt hat, um die Integrität der Plattform sicherzustellen. Zu den Funktionen gehören Firmware, Software und Host-Infrastruktur. Organisationen haben möglicherweise betriebliche Souveränitätsanforderungen, um ihre Daten von Cloud-Betreibern zu isolieren. Azure bietet Funktionen, die Kunden nutzen können, um von der Agilität und Widerstandsfähigkeit der öffentlichen Cloud zu profitieren und gleichzeitig die Isolation von Cloud-Dienstanbietern und deren Verwaltungspersonal aufrechtzuerhalten. Organisationen mit Anforderungen im Zusammenhang mit der Bescheinigung auf Hardwareebene, der Überprüfung der Softwareintegrität (z. B. sicherer Start) und der sicheren Schlüsselverwaltung können die Plattformintegritäts- und Sicherheitspraktiken von Microsoft überprüfen und auf die Prüfdokumentation zugreifen, um die Implementierung dieser Funktionen zu validieren.

Weitere Informationen finden Sie unter Plattformintegrität und -Sicherheit und Azure-Infrastruktursicherheit.

Die Verschlüsselung ruhender, übertragener und genutzter Daten kann dazu beitragen, eine Vielzahl betrieblicher Souveränitätsanforderungen im Zusammenhang mit Datenvertraulichkeit und Datenschutz zu erfüllen. Allerdings müssen Organisationen, die diese Funktionen benötigen, die Erstellung und Verwaltung von Verschlüsselungsschlüsseln planen. Azure bietet Kunden eine große Auswahl an Data-at-Rest-Verschlüsselungsmodellen, von clientseitigen Verschlüsselungsmethoden, die eine wissensfreie Verschlüsselung für in der Cloud gehostete Daten ermöglichen, bis hin zu dienstverwalteten Schlüsseln, die ein Höchstmaß an Interoperabilität mit nativen Cloud-Diensten bieten.

Darüber hinaus können Organisationen, die den Bedarf an Vertrauen in Plattformkomponenten wie das Host-Betriebssystem, den Kernel, den Hypervisor und das Verwaltungspersonal minimieren möchten, eine Verschlüsselung der genutzten Daten implementieren. Azure Confidential Computing umfasst mehrere Rechendienste, die in hardwarebasierten Sicherheitsenklaven bereitgestellt werden, die Daten im Arbeitsspeicher mithilfe von Intel Software Guard Extensions (SGX) oder AMD Secure Encrypted Virtualization (SEV-SNP) verschlüsseln.

Organisationen mit betrieblichen Souveränitätsanforderungen, die die Implementierung von Verschlüsselung erfordern, sollten sich mit den folgenden Verschlüsselungsfunktionen in Azure vertraut machen:

Vorgänge und Resilienz

Betriebssicherheitsanforderungen können sowohl für Software auf Plattformebene gelten, die von Microsoft zum Betrieb der Azure-Plattform erstellt und verwaltet wird, als auch für vom Kunden verwaltete Software, die Teil einer Arbeitslast ist. Das Modell der geteilten Verantwortung für Cloud Computing verlagert die administrative Verantwortung vom Kunden auf den Cloud-Dienstleister. Abhängig von der Art des genutzten Cloud-Dienstes ist Microsoft möglicherweise für die Verwaltung und Aktualisierung der Bare-Metal-Infrastruktur in unseren Rechenzentren, Betriebssystemen und Dienstlaufzeiten verantwortlich. Die Sicherheitstechnikorganisation von Microsoft implementiert ein Betriebssicherheitsprogramm, das auf den Praktiken des Microsoft Secure Development Lifecycle (SDL) mit Betriebssicherheitspraktiken aufbaut. Zu den Praktiken gehören Geheimnisverwaltung, Penetrationstests und Sicherheitsüberwachung, implementiert durch das Microsoft Security Response Center.

In seltenen Fällen benötigt Microsoft möglicherweise Zugriff auf Kundendaten, um ein Problem zu beheben, das sich auf Dienste auswirken könnte. Kunden mit Anforderungen an die betriebliche Souveränität im Zusammenhang mit der Änderungskontrolle und der Verwaltung privilegierter Zugriffe möchten möglicherweise Kunden-Lockbox für Azure aktivieren, damit sie die Zugriffsanfragen im Rahmen der Support-Workflows von Microsoft genehmigen können.

Darüber hinaus möchten Kunden mit strengen Anforderungen an die Genehmigung und Planung von Plattformsoftware-Updates möglicherweise Azure Dedicated Hosts in Betracht ziehen, mit denen Kunden Wartungskonfigurationen verwenden können, um Plattformwartungsaktivitäten auf Hostebene zu steuern. Darüber hinaus sollten Kunden ihre Ausfallsicherheitsanforderungen überprüfen, um festzustellen, ob es auf Souveränität basierende Einschränkungen für die Dienste und Regionen gibt, die zum Hosten von Arbeitslasten verwendet werden.

Anforderungen an die Betriebssouveränität im Hinblick auf die Kontinuität des Betriebs (z. B. die Anforderung, dass Workloads in hochverfügbaren Konfigurationen bereitgestellt werden müssen, um die Betriebszeit aufrechtzuerhalten) können im Widerspruch zu Anforderungen an die Datensouveränität im Zusammenhang mit der Datenresidenz stehen (z. B. die Beschränkung von Workloads auf eine geografische Grenze, die keine diversen Standorte bietet).

Organisationen sollten diese Anforderungen frühzeitig bewerten und überlegen, wie sie diese Anforderungen am besten in Einklang bringen können.