Bearbeiten

Skalierung von KI- und Machine-Learning-Initiativen in regulierten Branchen

Azure Machine Learning
Azure Synapse Analytics
Azure Databricks

In diesem Artikel werden Überlegungen zur Azure-Architektur im Zusammenhang mit Analyse und Implementierung gängiger ISRM-Kontrollen (Information Security Risk Management, Management von Risiken für die Informationssicherheit) für hohe Risiken erläutert.

Architektur

Die Architektur ist in diesem Diagramm dargestellt und folgt dem Prinzip der Zielzonen auf Unternehmensebene, insbesondere der unternehmensweiten Analyse und der KI-Referenzarchitektur.

Diagram of a scalable AI platform for regulated industries.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Die Architektur besteht aus dem in den folgenden Abschnitten beschriebenen Workflow. Jede Komponente der Architektur ist im Diagramm mit einer entsprechenden Nummer gekennzeichnet. Wir beschreiben den Hauptzweck der Komponente, ihre Einbindung in die Architektur und alle anderen wichtigen Überlegungen, die Sie bei ihrer Einführung berücksichtigen sollten:

  1. Plattform-Abonnements: Zentrale Azure-Abonnements, die Verwaltung, Konnektivität und Funktionen für Identität über Microsoft Entra ID bieten. Sie werden hier nicht näher beschrieben und als Teil der zentralen Einrichtung auf Unternehmensebene als verfügbar und einsatzbereit betrachtet.

Datenverwaltung

  1. Datenverwaltungszone: Die Datenverwaltungszone ist plattformweit für die Datengovernance verantwortlich und setzt Schutzmaßnahmen durch, um in den nachgelagerten Datenzielzone mehr Flexibilität zu bieten. Sie verfügt über ein eigenes Abonnement und hostet zentralisierte Dienste wie Datenkatalogisierung, Überwachung, Überprüfung usw. Diese Umgebung ist streng kontrolliert und unterliegt strengen Überprüfungen. Alle Datenklassifizierungstypen werden im zentralen Datenkatalog (Azure Purview) gespeichert. Je nach Metadaten werden unterschiedliche Richtlinien und Zugriffsmuster erzwungen. Es gibt nur ein Datenverwaltungszonen-Abonnement für den gesamten Mandanten. Die Datenverwaltungszone wird mittels Peering (über VNET-Peering) mit allen anderen Datenzielzonen verbunden. Private Endpunkte werden nach Möglichkeit verwendet, um sicherzustellen, dass auf die bereitgestellten Dienste nicht über das öffentliche Internet zugegriffen werden kann.
  2. Netzwerkressourcengruppe: Virtuelle Azure-Netzwerke, Netzwerksicherheitsgruppen und alle anderen netzwerkbezogenen Ressourcen, die für die Datenverwaltungszone benötigt werden, werden in dieser Netzwerkressourcengruppe bereitgestellt.
  3. Bereitstellungsressourcengruppe: Eine Bereitstellungsressourcengruppe hostet private Azure DevOps CI/CD-Agenten (VM), die für die Datenverwaltungszone benötigt werden, und einen Schlüsseltresor zum Speichern von bereitstellungsbezogenen Geheimnissen.
  4. Datengovernance-Ressourcengruppe: – Azure Purview wird als Datengovernance- und Datenkataloglösung verwendet und genutzt, um die erforderlichen Schutzvorrichtungen für Datasets zu erzwingen, um Datenanforderungen und Datenbestimmungen zu erfüllen, die durch Gesetze oder andere Entitäten vorgegeben werden. Purview wird zentral in dieser Ressourcengruppe gehostet, zusammen mit einer Key Vault-Instanz zum Speichern von Geheimnissen.
  5. Zentralisierte Ressourcen: Zentralisierte Ressourcen hosten wichtige und wertvolle Ressourcen, die für die Plattform von zentraler Bedeutung sind, z. B.:
    • Azure Container Registries, die Basis-Images hosten, die in Azure Machine Learning-basierten Datenprodukten verwendet werden (Images, die zuvor überprüft wurden und frei von Sicherheitsrisiken sind)
    • KI-/Machine Learning-Modelle, die veröffentlicht und für Kunden auf der Plattform verfügbar gemacht werden (sodass sie bei Bedarf in einer oder mehreren Datenzielzonen bereitgestellt werden können).
  6. Zusätzliche Dienste: Alle anderen Dienste, die zentralisiert werden sollen, können in einer dieser Ressourcengruppen gehostet werden, die zentralisierte Azure API Management-Instanzen, Drittanbietersoftware usw. umfassen können.
  7. Datenvisualisierungs-Ressourcengruppe: Diese Ressourcengruppe hostet Datenvisualisierungslösungen, die über Datenzielzonen hinweg gemeinsam genutzt werden. Lösungen können Power BI, Tableau oder eine andere Visualisierungslösung sein.
  8. Governance und zusätzliche Infrastruktursteuerungen: Microsoft Defender for Cloud und Azure Monitor werden als grundlegende Sicherheits- und Überwachungslösungen verwendet.

Datenzielzonen

  1. Datenzielzone 001: Eine Datenzielzone ist ein Abonnement, das eine Skalierungseinheit innerhalb der Datenplattform darstellt. Datenzielzonen werden basierend auf der grundlegenden Architektur der Datenzielzone (Blaupause) bereitgestellt, einschließlich aller wichtigen Funktionen zum Hosten einer Analyse- und KI-Plattform. Es kann eine oder mehrere Datenzielzonen innerhalb der Umgebung geben. Azure Policy wird angewendet, um den Zugriff und die Konfigurationen verschiedener Azure-Dienste zu schützen. Die Datenzielzone wird mittels Peering (über VNET-Peering) mit allen anderen Datenzielzonen und der Datenverwaltungszone verbunden. Private Endpunkte werden nach Möglichkeit verwendet, um sicherzustellen, dass auf die bereitgestellten Dienste nicht über das öffentliche Internet zugegriffen werden kann.

  2. Netzwerkressourcengruppe: Virtuelle Azure-Netzwerke, Netzwerksicherheitsgruppen und alle anderen netzwerkbezogenen Ressourcen, die für die Datenzielzone benötigt werden, werden in dieser Ressourcengruppe bereitgestellt.

  3. Bereitstellungsressourcengruppe: Eine Bereitstellungsressourcengruppe hostet private Azure DevOps CI/CD-Agenten (VM), die für die Datenzielzone benötigt werden, und einen Schlüsseltresor zum Speichern von bereitstellungsbezogenen Geheimnissen.

  4. Datenspeicher-Ressourcengruppe: Eine Datenspeicher-Ressourcengruppe enthält die wichtigsten Datenspeicherkonten für diese Datenzielzone, die als Azure Data Lake Storage Gen2 mit hierarchischem Namespace bereitgestellt werden. Sie sind auf drei Hauptbereiche verteilt:

    • Roh: Daten werden aus der Datenquelle im ursprünglichen Zustand erfasst.
    • Zusammengestellt und angereichert: Daten werden bereinigt, überprüft und aggregiert.
    • Arbeitsbereich: Bestimmte Datenprodukte können ihre Datasets oder die Ausgaben der Machine Learning-Modelle usw. speichern.

    Die Pfeile in den Diagrammen zeigen den erwarteten Datenfluss, von Rohdaten über zusammengestellte und angereicherte (vertrauenswürdige) Daten bis hin zu Arbeitsbereichen zum Erkunden, Analysieren und Bereitstellen von Mehrwert aus dem Datenprodukt.

  5. Datenintegrations-Ressourcengruppe: Die Datenintegration-Ressourcengruppe hostet eine Azure Data Factory, die die Konnektivität mit der lokalen selbstgehosteten Integration Runtime (SHIR) gemeinsam nutzt. Ihr Hauptzweck ist die Herstellung von Konnektivität. Andere Data Factory-Instanzen verwenden sie wieder, sodass die Konnektivität nur an einem Ort aufrechterhalten wird. Ihr anderer Zweck besteht darin, die selbstgehostete Integration Runtime für den Azure Purview-Dienst zu hosten, damit sie zu Überprüfungszwecken auf die Datenquellen in dieser Datenzielzone zugreifen kann.

  6. Ressourcengruppe für die Metadatenverwaltung: Die Ressourcengruppe für Metadatenverwaltung hostet Metadaten für Azure Databricks (den Hive-Metaspeicher) und Azure Data Factory Erfassungs- und Verarbeitungspipelines. Außerdem hostet sie einen Schlüsseltresor zum Speichern von Geheimnissen für den Zugriff auf diese Daten. Die Azure SQL-Datenbank wird zum Hosten der Metadaten verwendet.

  7. Datenerfassungs-Ressourcengruppe: Die Datenerfassungs-Ressourcengruppe hostet eine Azure Data Factory-Instanz, in der alle spezifischen Datenerfassungspipelines für eine Datendomäne bereitgestellt werden. Azure Databricks wird als Verarbeitungs-Engine verwendet, um die Daten zu laden, zu transformieren und in den Data Lake-Konten zu speichern.

  8. Analytics-Ressourcengruppe: Die Analytics-Ressourcengruppe enthält zwei gemeinsam genutzte Dienste zur weiteren Datenanalyse und -untersuchung: Azure Synapse und Azure Databricks. Beide Dienste bieten umfangreiche Compute- und Skalierungsmöglichkeiten für umfangreiche Datenuntersuchungs- und Analysezwecke.

  9. Datenprodukt-Ressourcengruppe: Die Datenprodukt-Ressource ist eine Blaupause für ein Datenprodukt mit einer Ressourcengruppe, die grundlegende Azure-Ressourcen enthält, die ein Datenprodukt möglicherweise benötigt. Die Bereitstellung sollte über eine Azure DevOps-Pipeline konfiguriert werden können, die auf den spezifischen Anforderungen des Unternehmens basiert. Die hier bereitgestellten grundlegenden Azure-Dienste lauten wie folgt:

    • Azure Machine Learning-Arbeitsbereich als Grundlage für jedes Machine Learning-Projekt auf Unternehmensebene mit verknüpften Diensten wie Key Vault (zum Speichern von Geheimnissen)
    • Application Insights (für die Modellüberwachung)
    • Azure Storage (zum Speichern von Datasets)
    • Ein Azure Container Registry zum Speichern von Modell-Images während der Entwicklung

    Cognitive Services wird als Paket bereitgestellt, um API-Zugriff auf mehrere KI-bezogene Dienste bereitzustellen, und Azure Machine Learning Compute-Instanz und Computecluster werden für Entwicklungs-, Modellerstellungs- und Testzwecke verwendet. Azure Data Factory wird verwendet, um die Batchbewertung von Modellen bei Bedarf zu orchestrieren. Azure App Service und Azure Cosmos DB bieten eine zusätzliche Ebene für die Bereitstellung des Datenprodukts, auf der eine benutzerdefinierte Anwendung oder API mit einem eigenen internen Datenspeicher gehostet werden kann.

    In regulierten Branchen gelten in der Regel strenge Beschränkungen für den Datenzugriff, und in der Regel dürfen Produktionsdaten nur innerhalb der Produktionsumgebung gehostet werden. Aus diesem Grund erfolgt der Entwicklungslebenszyklus von Datenprodukten nur in der Zielzone für Produktionsdaten, und eine separate Umgebung oder Ressourcengruppe wird für Entwicklungs-, Test- und Bereitstellungszwecke bereitgestellt.

  10. Zusätzliche Datenprodukte: – Diese Ressourcengruppen hosten andere Datenprodukte, da eine Datenzielzone ein oder mehrere Datenprodukte hosten kann.

  11. Geteilte Computeressourcengruppe – Alle geteilten Computeressourcen, die zum Hosten und Bereitstellen von Datenprodukten benötigt werden, werden in dieser Ressourcengruppe bereitgestellt. Ein Beispiel hierfür ist ein Azure Kubernetes Service-Cluster.

  12. Governance und zusätzliche Infrastruktursteuerungen: Microsoft Defender for Cloud und Azure Monitor werden als grundlegende Sicherheits- und Überwachungslösungen verwendet.

  13. Datenzielzone 002: Diese Zielzone ist ein Platzhalter für zusätzliche Azure-Abonnements, die zum Hosten neuer Datenzielzonen verwendet werden. Sie basieren auf zuvor erwähnten Kriterien, z. B. Anforderungen an die Datenresidenz oder einer anderen Geschäftseinheit, die über ein eigenes funktionsübergreifendes Team und eine Reihe von Anwendungsfällen verfügt, die bereitgestellt werden müssen.

Komponenten

Alternativen

In verteilten Organisationen arbeiten Geschäftsgruppen unabhängig und mit einem hohen Grad an Eigenständigkeit. Daher können sie einen alternativen Lösungsentwurf in Betracht ziehen, bei dem Anwendungsfälle in Azure-Zielzonen vollständig isoliert werden und ein minimaler Satz gemeinsamer Dienste gemeinsam verwendet wird. Obwohl dieser Entwurf einen schnellen Start ermöglicht, erfordert er hohen Aufwand von IT- und ISRM-Organisationen, da der Entwurf einzelner Anwendungsfälle schnell von Blaupausenentwürfen abweichen kann. Darüber hinaus sind unabhängige ISRM-Prozesse und -Überwachungen für jedes der in Azure gehosteten KI- und Machine Learning-Produkte erforderlich.

Szenariodetails

Die Skalierung von KI- und Machine Learning-Initiativen in regulierten Umgebungen stellt Unternehmen vor erhebliche Herausforderungen, unabhängig von ihrer Größe und ihrer Kompetenz im digitalen Bereich. In diesem Artikel werden wichtige Architekturentscheidungen erläutert, die bei der Einführung von Azure-Datentechnik- und Machine Learning-Diensten in regulierten Branchen zu berücksichtigen sind. Diese Entscheidungen basieren auf den Erkenntnissen aus einer kürzlich durchgeführten Implementierung in einem weltweit tätigen Fortune 500-Unternehmen aus dem Bereich Biowissenschaften und Gesundheitswesen.

Die in diesem Artikel vorgestellte Architektur folgt dem Referenzarchitekturentwurf für Analysen auf Unternehmensebene und KI und war eine der ersten Implementierungen.

Die Einrichtung von Data Science-Projekten und Entwicklung von Machine Learning-Modellen in Umgebungen für Biowissenschaften und Gesundheitswesen erfordern in fast allen Fällen Zugriff auf Datenquellen mit erheblichen geschäftlichen Auswirkungen. Bei diesen Quellen kann es sich beispielsweise um Informationen über klinische Studienprotokolle ohne Patientendaten, chemische Formeln von Molekülen oder Geheimnisse von Herstellungsverfahren handeln.

In regulierten Branchen werden IT-Systeme basierend auf der Klassifizierung der Datenquellen klassifiziert, auf die diese Systeme zugreifen. KI- und Machine Learning-Umgebungen, die in Azure ausgeführt werden, werden als HBI (High Business Impact, erhebliche Geschäftsauswirkungen) klassifiziert und müssen eine Vielzahl von ISRM (Information Security Risk Management)-Richtlinien und -Kontrollen einhalten.

Entwurfsprinzipien

Diese Architektur basiert auf den folgenden Prinzipien:

  • Bei der Enterprise-Skalierung handelt es sich um einen Architekturansatz und eine Referenzimplementierung, die auf die Azure-Roadmap und einen Teil des Microsoft Cloud Adoption Framework (CAF) ausgerichtet ist. Mit diesem Ansatz wird eine effektive Erstellung und Inbetriebnahme von Zielzonen in Azure nach Maß ermöglicht. Die Namenszielzone wird als Grenze verwendet, in der neue oder migrierte Anwendungen in Azure landen. In diesem Szenario bezieht sie sich auch auf Teile der Datenplattform, die zum Hosten der Daten und der KI- und Machine Learning-Modelle verwendet werden.
  • Herkömmliche monolithische Datenplattformarchitekturen haben eine inhärente Einschränkung, die die Bereitstellung von Funktionen und Werten verlangsamt. Mit der hier beschriebenen Architektur können Organisationen ihren Datenbestand skalieren und die Herausforderungen eines zentralisierten monolithischen Data Lake mithilfe eines dezentralisierten Ansatzes durch Trennung des Eigentums (Data Mesh) bewältigen. Der Ansatz ermöglicht es Unternehmen, Tausende von Erfassungspipelines und Datenprodukten zu skalieren und gleichzeitig die Datenplattform sicher und wartungsfähig zu halten, indem die grundlegende Datenplattform und die Datenverwaltungsdienste (bereitgestellt in einer separaten Zielzone namens Datenverwaltungszone) von Datendomänen und Datenprodukten (bereitgestellt in einer oder mehreren Datenzielzonen) entkoppelt werden.
  • Abonnements werden als Verwaltungseinheiten verwendet und entsprechend den geschäftlichen Anforderungen und Prioritäten skaliert. Die Skalierung wird erreicht, indem neue Abonnements (Datenzielzonen) für Geschäftseinheiten bereitgestellt werden, die auf Kriterien wie unterschiedlichen Projektbeteiligten, unterschiedlichen Geschäftszielen und -anforderungen sowie Anforderungen an die Datenresidenz basieren (wobei Daten in einer bestimmten geografischen Region gehostet werden müssen).
  • Azure Policy wird verwendet, um Schutzmaßnahmen zu gewährleisten und die kontinuierliche Einhaltung von Vorschriften innerhalb der IT-Landschaft des Unternehmens sicherzustellen.
  • Eine einzelne Steuerungs- und Verwaltungsebene (über das Azure-Portal) bietet eine konsistente Erfahrung für alle Azure-Ressourcen und Bereitstellungskanäle, die rollenbasiertem Zugriff und richtliniengesteuerten Steuerungen unterliegen. Nach Möglichkeit werden native Azure-Plattformdienste und -Funktionen verwendet.
  • Funktionsübergreifende Teams übernehmen das Design, die Entwicklung und den Betrieb, um die Markteinführungszeit zu verkürzen und die Agilität der Plattform zu erhöhen. Grundprinzipien wie DevOps, Infrastructure-as-Code (IaC) und resiliente Entwürfe werden verwendet, um menschliche Fehler und Single Points of Failure zu vermeiden.
  • Datendomänen können von Domänen- und Datenquellenexperten verwendet werden, um Datenbestände aus Azure-, Drittanbieter- oder lokalen Umgebungen einzubinden. Eine Datendomäne ist eine Ressourcengruppe innerhalb einer Datenzielzone, die von funktionsübergreifenden Teams für die benutzerdefinierte Datenerfassung verwendet werden kann. Es kann eine oder mehrere Datendomänen innerhalb einer Datenzielzone geben. Datendomänen können ähnlich wie Domänen in Domain Driven Design (DDD) angezeigt werden, in denen sie eine Kontextbegrenzung bereitstellen und eigenständig und isoliert sind. Ein Beispiel für einen Datendomäne sind Daten aus klinischen Versuchen oder Daten aus der Lieferkette.

Mögliche Anwendungsfälle

Die in diesem Artikel erörterten Überlegungen zur Architektur haben ihren Ursprung in den Branchen Biowissenschaften und Gesundheitswesen. Sie sind jedoch auch für Organisationen in anderen regulierten Branchen relevant, einschließlich dieser Branchen:

  • Finanzdienstleistungen
  • Anbieter im Gesundheitswesen
  • Öl- und Gasanlagen

Die Implementierung der Enterprise Scale Analytics- und KI-Referenzarchitektur in regulierten Umgebungen folgt ähnlichen Entwurfsmustern.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

In diesem Abschnitt werden die Lektionen erläutert, die aus der Implementierung der zuvor beschriebenen Architektur in einer biowissenschaftlichen Umgebung und einer durch das Gesundheitswesen regulierten Umgebung gewonnen wurden. Wir behandeln auch allgemeine Entwurfsüberlegungen, um allgemeine ISRM-Steuerelemente und -Richtlinien zu erfüllen.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Umgebungen

In regulierten Umgebungen müssen IT-Systeme, die als HBI klassifiziert sind, über mehrere getrennte Umgebungen verfügen, z. B. Entwicklung, Qualität und Produktion (oder ähnliches). Der Zugriff auf geschützte Datenquellen ist nur in produktionszertifizierten Umgebungen autorisiert.

Da die KI- und Machine Learning-Entwicklung Zugriff auf sensible Datensätze erfordert, finden die verschiedenen Phasen des Machine Learning Operations-Prozesses, z. B. Modellentwicklung, Training und Rückschluss (oder ähnliches), in der Produktion statt. Entwicklungs- und Qualitätsumgebungen sind in der Regel auf Infrastruktur, Betrieb und Datentechnik beschränkt, um kontinuierliche Verbesserungen sicherzustellen, wenn neue Azure-Dienste und -Funktionen verfügbar gemacht werden.

KI- und Data Science-Entwicklungsaktivitäten sollten in Produktionsumgebungen ausgeführt werden, mit Ausnahme von Sandbox- oder frühen Grundlagenarbeiten.

Verschlüsselung

IT-Systeme, die auf vertrauliche Geschäftsdaten zugreifen, diese speichern und verarbeiten, müssen bestimmte Anforderungen an die Verwaltung von Verschlüsselungsschlüsseln implementieren, z. B. FIPS 140-2 Level 2- oder Level 3-Richtlinien mit Integration von kundenseitig verwalteten Schlüsseln (CMK). Geschützte Daten müssen im Ruhezustand und bei der Übertragung immer verschlüsselt werden, wobei TLS 1.2 oder höhere Protokolle zu verwenden sind.

Während des Architekturentwurfs ist eine sorgfältige Analyse der Unterstützung und Integration von Azure-Diensten in die CMK-Infrastruktur einer Organisation erforderlich. Alle Ausnahmen von der Datenverschlüsselung müssen dokumentiert werden. Die Unterstützung für Anbieter von Hardwaresicherheitsmodulen (HSM) wird ständig erweitert, und weitere Informationen finden Sie unter Azure Key Vault Managed Hardware Security Module.

Netzwerkentwurf und Ring-Fencing

KI- und Machine Learning-Umgebungen müssen über die Implementierung einer Ring-Fencing-Umgebung verfügen, bei der Netzwerksegmentierung und Netzwerkzugriffssteuerungen implementiert sind. Die Netzwerkkommunikation zwischen Architekturkomponenten ist auf die erforderlichen Datenflüsse und die zugrunde liegende Infrastruktur beschränkt, um in einem Positivlisten-Ansatz zu funktionieren. Signaturbasierte Analyse und verhaltensbasierte Analyse sollten angewendet werden.

Erzwingen Sie Netzwerkzugriffssteuerungen auf mehreren Ebenen der Architektur, einschließlich Azure Firewalls, Überprüfen der eingehenden und ausgehenden Netzwerkkonnektivität, Netzwerksicherheitsgruppen und Zugriff auf Webanwendungs-Endpunkte, die mit Web Application Firewall (WAF) geschützt sind.

Autorisierungsverwaltung

KI- und Machine Learning-Umgebungen, die in Azure ausgeführt werden, müssen in das Hauptkonto-Bereitstellungssystem einer Organisation integriert werden, in dem Anforderungen zum Gewähren des Zugriffs auf wichtige Geschäftsanwendungen übermittelt, genehmigt und überwacht werden.

Es wird erwartet, dass Kontobereitstellungssysteme eine Verbindung mit Active Directory und Microsoft Entra ID einer Organisation herstellen, sodass die Rollen für die Geschäftsautorisierung den entsprechenden Active Directory- und Microsoft Entra ID-Sicherheitsgruppen zugeordnet werden.

KI- und Machine Learning-Umgebungen folgen einem rollenbasierten Zugriffssteuerungsmodell. Autorisierungen der Zugriffssteuerung stellen sicher, dass Benutzer nur die Aufgaben und Aktionen für ihre Aufgaben und Geschäftsanforderungen ausführen können. Es wird erwartet, dass Machine Learning-Anwendungsfälle in hohem Maß getrennt sind, da Datenwissenschaftler, die in einem bestimmten Anwendungsfall arbeiten, nur auf die Ressourcen in diesem Anwendungsfall zugreifen dürfen, und dies nach dem Prinzip der geringsten Rechte. Diese Ressourcen können Folgendes umfassen:

  • Speicherkonten
  • Azure Machine Learning-Arbeitsbereiche
  • Computing-Instanzen

Die rollenbasierte Zugriffssteuerung verwendet Sicherheitsgruppen in Microsoft Entra ID.

Mehrstufige Authentifizierung

Die Multi-Faktor-Authentifizierung muss für den Zugriff auf alle Umgebungen, die in Azure ausgeführt werden, implementiert und als „erhebliche Geschäftsauswirkungen“ klassifiziert werden. Die Multi-Faktor-Authentifizierung kann mithilfe von Multi-Faktor-Authentifizierungsdiensten von Microsoft Entra erzwungen werden. Anwendungsendpunkte – einschließlich Azure DevOps, Azure-Verwaltungsportal, Azure Machine Learning, Azure Databricks und Azure Kubernetes Services – sollten in Zugriffssteuerungsrichtlinien für die Multi-Faktor-Authentifizierung konfiguriert werden.

Die Multi-Faktor-Authentifizierung muss für alle Benutzer erzwungen werden, einschließlich Azure Service Manager, technische Fachkräfte für Daten und Datenwissenschaftler.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

Protokollierung und Überwachung

Alle Azure-Dienste müssen ihre sicherheitsrelevanten Ereignisse in der Security Operations Center-Plattform (SOC) einer Organisation erfassen, und die folgenden sicherheitsrelevanten Ereignisse sollten aufgezeichnet werden:

  • Erfolgreiche und fehlgeschlagene Authentifizierungsversuche
  • Zugriff auf vertrauliche Daten
  • Änderungen an der Sicherheitsrichtlinie
  • Änderungen an Administratorbenutzergruppen, Benutzern oder Rollen
  • Übertragung vertraulicher Daten an externe Speicherorte, falls zutreffend
  • Aktivierung und Deaktivierung von Schutzsystemen, wie. ABAC-Steuerelemente
  • Aktualisierter Zugriff auf Protokolle und Unterbrechung der Protokollierung

Azure-Sicherheitsprotokolle können in SOC mit unterschiedlichen Mustern erfasst werden:

  • Azure Log Analytics-Arbeitsbereich
  • Event Hub mit Verbindung mit SOC-Plattformsystemen wie Splunk
  • Windows VM und andere Computeressourcen, die mit SOC-Agents bereitgestellt werden

DevOps

In regulierten Umgebungen müssen IT-Systeme strenge Qualitätskontrollprozesse im Wasserfallstil mit formalen Genehmigungen (oder Gates) zwischen Prozessphasen – z. B. Benutzeranforderungen, funktionale Spezifikationen, Entwurfs- und Testspezifikationen oder ähnliches – mit umfangreicher und zeitaufwändiger unterstützender Dokumentation befolgen.

Azure-Umgebungen und Data Science-Entwicklung folgen iterativen Prozessen, die in einer DevOps-Kultur verankert sind. Ein erheblicher Aufwand bei der Skalierung von KI und Machine Learning-Initiativen ist damit verbunden, die Säulen einer DevOps-Organisation zu kommunizieren und eine automatisierte End-to-End-Zuordnung der Nachverfolgbarkeit zwischen Azure DevOps-Epics, Funktionen, Benutzerberichten, Testplänen und CI/CD-Pipelines sowie erforderlichen Entitäten und Beweisen für die Qualitätskontrolle zu erstellen.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Um KI und maschinelles Lernen in regulierten Umgebungen zu skalieren und eine schnelle Einführung in den Geschäftsbereichen der Organisation zu fördern, empfehlen wir Ihnen, ein Einführungs-Framework zu entwerfen und einzurichten, um den von den Azure-Diensten erstellten Nutzen zu messen, zu überwachen und zu bewerten. Aus unserem Beispiel aus den Biowissenschaften und dem Gesundheitswesen wurden die folgenden geschäftlichen Wertfaktoren und Key Performance Indicators (KPI) ausgewertet:

Skalierbarkeit – Um sicherzustellen, dass die Azure-Architektur unabhängig vom Skalierungspunkt parallel zu den Geschäftsanforderungen skaliert werden kann, werden die folgenden KPIs empfohlen:

  • Anzahl der Compute-Instanzen und gesamter verwendeter Speicher und Arbeitsspeicher
  • Anzahl der durchgeführten Experimente
  • Anzahl der bereitgestellten Modelle

Beschleunigung der KI-Entwicklung: Um die Entwicklung von KI und Machine Learning-Lösungen zu beschleunigen, werden die folgenden KPIs empfohlen:

  • Anzahl der verschiedenen Geschäftseinheiten, die KI- und Machine Learning-Dienste von Azure nutzen
  • Anzahl der Benutzer pro Kategorie, für die Onboarding durchgeführt wurde– z. B. Datentechniker, Datenwissenschaftler, zivile Datenwissenschaftler und Geschäftsbenutzer
  • Anzahl der durchgeführten Experimente
  • Zeit zwischen dem Onboarding von Benutzern und der aktiven Nutzung
  • Zeit für die Bereitstellung von Diensten – von der Konfigurationsänderungsanforderung bis zum Abschluss der Dienstbereitstellung

Compliance: Um die kontinuierliche Compliance der bereitgestellten KI- und Machine Learning-Lösungen sicherzustellen, werden die folgenden KPIs empfohlen:

  • Allgemeine Compliance mit den geltenden ISRM-Steuerelementen
  • Anzahl von Sicherheitsrisikowarnungen
  • Anzahl von Sicherheitsvorfällen für den letzten Zeitraum

Benutzererfahrung – Um sicherzustellen, dass qualitativ hochwertige und konsistente Benutzeroberflächen verfügbar sind, werden die folgenden KPIs empfohlen:

  • Anzahl von Helpdesk-Anfragen durch Benutzer
  • Net Promoter Score (NPS)

Sichere Grundlagen: Um sichere Grundlagen zu gewährleisten, werden die folgenden KPIs empfohlen:

  • Uptime kritischer Dienste
  • Anzahl der gemeldeten Vorfälle im Zusammenhang mit der Leistungsverfügbarkeit

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Die Kostenverwaltung ist ein wichtiger Bestandteil des Entwurfs bei der Implementierung skalierbarer KI- und Machine Learning-Plattformen, da laufende Kosten nicht einfachen und vorhersagbaren Mustern folgen. Die Kosten werden hauptsächlich durch die Anzahl und Größe der KI- und Machine Learning-Experimente bestimmt, die auf der Plattform ausgeführt werden, und genauer gesagt von der Anzahl und den SKUs der Compute-Ressourcen beeinflusst, die beim Trainieren und Rückschließen des Modells verwendet werden.

Wir empfehlen unter anderem diese Methoden:

  • Weisen Sie jedem Anwendungsfall und jedem KI- und Machine Learning-Produkt ein eigenes Azure-Dienstbudget zu, was eine gute Methode zur Kostenverwaltung ist.
  • Richten Sie ein transparentes Kostenmodell für freigegebene Plattformdienste ein.
  • Verwenden Sie Tags konsistent, um Anwendungsfall- und Produktressourcen Kostenstellen zuzuordnen.
  • Verwenden Sie Azure Advisor und Azure Budget, um zu verstehen, wo Ressourcen nicht optimal genutzt werden, und überprüfen Sie Konfigurationen regelmäßig.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Nächste Schritte

Hier erfahren Sie, wie Sie mit Azure Machine Learning Modelle trainieren und bereitstellen und den Machine Learning-Lebenszyklus verwalten. Tutorials, Code-Beispiele, API-Referenzen und vieles mehr finden Sie hier:

Erfahren Sie, wie Sie eine Zielzone auf Unternehmensebene für Datenanalysen und KI in Azure implementieren:

Produktdokumentation:

Artikel zur Übersicht über Azure Architecture Center: