Freigeben über

Best Practices für Sicherheit und Compliance in Batch

  • Artikel

Dieser Artikel stellt Anleitungen und Best Practices für die Verbesserung der Sicherheit bei der Verwendung von Azure Batch bereit.

Standardmäßig verfügen Azure Batch-Konten über einen öffentlichen Endpunkt und sind öffentlich zugänglich. Wenn ein Azure Batch-Pool erstellt wird, wird dieser in einem angegebenen Subnetz eines virtuellen Azure-Netzwerks bereitgestellt. Virtuelle Computer im Batch-Pool sind standardmäßig über öffentliche IP-Adressen zugänglich, die von Batch erstellt werden. Computeknoten in einem Pool können bei Bedarf miteinander kommunizieren, beispielsweise bei der Ausführung von Aufgaben mit mehreren Instanzen. Die Knoten können aber nicht mit virtuellen Computern außerhalb des Pools kommunizieren.

Diagramm einer typischen Batch-Umgebung

Es steht eine ganze Reihe von Features zur Verfügung, die Sie beim Erstellen einer sichereren Azure Batch-Bereitstellung unterstützen. Sie können den Zugriff auf Knoten einschränken und die Auffindbarkeit der Knoten im Internet verringern, indem Sie den Pool ohne öffentliche IP-Adressen bereitstellen. Die Computeknoten können sicher mit anderen virtuellen Computern oder einem lokalen Netzwerk kommunizieren, indem Sie den Pool in einem Subnetz eines virtuellen Azure-Netzwerks bereitstellen. Darüber hinaus können Sie den privaten Zugriff aus virtuellen Netzwerken über einen durch Azure Private Link gestützten Dienst aktivieren.

Diagramm einer sichereren Batch-Umgebung

Poolkonfiguration

Pools können in einem der zwei Knotenkommunikationsmodi („klassisch“ oder vereinfacht) konfiguriert werden. Im klassischen Knotenkommunikationsmodell initiiert der Batch-Dienst die Kommunikation mit den Serverknoten, und Serverknoten müssen auch mit Azure Storage kommunizieren. Im vereinfachten Knotenkommunikationsmodell initiieren Serverknoten die Kommunikation mit dem Batch-Dienst. Aufgrund des reduzierten Bereichs der erforderlichen eingehenden/ausgehenden Verbindungen und des nicht erforderlichen ausgehenden Azure Storage-Zugriffs für den Basisbetrieb wird empfohlen, das vereinfachte Knotenkommunikationsmodell zu verwenden. Das klassische Knotenkommunikationsmodell wird am 31. März 2026 eingestellt.

Pools sollten auch mit erweiterten Sicherheitseinstellungen konfiguriert werden, einschließlich Vertrauenswürdiger Start (erfordert Gen2-VM-Images und eine kompatible VM-Größe), aktivieren sicheren Start, vTPM und Verschlüsselung auf host (erfordert eine kompatible VM-Größe).

Authentifizierung von Batch-Konten

Der Batch-Kontozugriff unterstützt zwei Authentifizierungsmethoden: Gemeinsam verwendeter Schlüssel und Microsoft Entra ID.

Es wird dringend empfohlen, Microsoft Entra für die Authentifizierung von Batch-Konten zu verwenden. Für einige Batch-Funktionen ist diese Authentifizierungsmethode obligatorisch. Dies schließt auch viele der hier beschriebenen sicherheitsbezogenen Features ein. Der Dienst-API-Authentifizierungsmechanismus für ein Batch-Konto kann mithilfe der Eigenschaft allowedAuthenticationModes auf Microsoft Entra beschränkt werden. Wenn diese Eigenschaft festgelegt ist, werden API-Aufrufe mit Authentifizierung über einen gemeinsamen Schlüssel abgelehnt.

Poolzuordnungsmodus für Batch-Konten

Beim Erstellen eines Batch-Kontos können Sie zwischen zwei Poolzuordnungsmodi wählen:

  • Batch-Dienst: Dies ist die Standardoption. Die zugrunde liegenden Ressourcen für die VM-Skalierungsgruppe, die zum Zuordnen und Verwalten von Poolknoten verwendet werden, werden in Batch-Abonnements erstellt und sind im Azure-Portal nicht direkt sichtbar. Sichtbar sind nur die Batch-Pools und -Knoten.
  • Benutzerabonnement: Die zugrunde liegenden Ressourcen für die VM-Skalierungsgruppe werden im selben Abonnement erstellt, in dem sich auch das Batch-Konto befindet. Daher sind diese Ressourcen im Abonnement zusätzlich zu den entsprechenden Batch-Ressourcen sichtbar.

Im Benutzerabonnementmodus werden virtuelle Batchcomputer und andere Ressourcen direkt in Ihrem Abonnement erstellt, wenn ein Pool erstellt wird. Der Benutzerabonnementmodus ist erforderlich, wenn Sie Batch-Pools mithilfe von Azure Reserved VM Instances erstellen, Azure Policy in VM-Skalierungsgruppenressourcen verwenden und/oder das Kernkontingent im Abonnement verwalten möchten (das Kontingent wird von allen Batch-Konten im Abonnement gemeinsam genutzt). Wenn Sie ein Batch-Konto im Benutzerabonnementmodus erstellen möchten, müssen Sie auch Ihr Abonnement in Azure Batch registrieren und das Konto einer Azure Key Vault-Instanz zuordnen.

Einschränken des Zugriffs auf einen Netzwerkendpunkt

Batch-Netzwerkendpunkte

Beachten Sie, dass für die Kommunikation mit Batch-Konten, Batch-Pools und Poolknoten standardmäßig Endpunkte mit öffentlichen IP-Adressen verwendet werden.

Batch-Konto-API

Beim Erstellen eines Batch-Kontos wird ein öffentlicher Endpunkt erstellt, der zum Aufrufen der meisten Vorgänge für das Konto über eine REST-API verwendet wird. Der Kontoendpunkt weist eine Basis-URL mit dem Format https://{account-name}.{region-id}.batch.azure.com auf. Der Zugriff auf das Batch-Konto ist geschützt: Die Kommunikation mit dem Kontoendpunkt wird über HTTPS verschlüsselt, und jede Anforderung wird entweder mit einem gemeinsam verwendeten Schlüssel oder über Microsoft Entra ID authentifiziert.

Azure Resource Manager

Zusätzlich zu den für ein Batch-Konto spezifischen Vorgängen werden Verwaltungsvorgänge für einzelne und mehrere Batch-Konten ausgeführt. Der Zugriff auf diese Verwaltungsvorgänge erfolgt über Azure Resource Manager.

Batch-Verwaltungsvorgänge über Azure Resource Manager werden über HTTPS verschlüsselt, und jede Anforderung wird über Microsoft Entra authentifiziert.

Computeknoten für Batch-Pool

Der Batch-Dienst kommuniziert mit Batch-Knoten-Agents, die aus jedem Knoten im Pool ausgeführt werden. Der Dienst kann den Knoten-Agent z. B. anweisen, eine Aufgabe auszuführen, eine Aufgabe zu beenden oder die Dateien für eine Aufgabe abzurufen. Die Kommunikation mit dem Knoten-Agent wird über mindestens ein Lastenausgleichsmodul ermöglicht. Die Anzahl der Module richtet sich nach der Anzahl von Knoten in einem Pool. Das Lastenausgleichsmodul leitet die Kommunikation an den gewünschten Knoten weiter, und jeder Knoten wird über eine eindeutige Portnummer kontaktiert. Standardmäßig sind Lastenausgleichsmodulen öffentliche IP-Adressen zugeordnet. Sie können auch über RDP oder SSH remote auf Poolknoten zugreifen (dieser Zugriff ist standardmäßig aktiviert, die Kommunikation erfolgt über Lastenausgleichsmodule).

Betriebssystem für Batch-Computeknoten

Batch unterstützt sowohl Linux- als auch Windows-Betriebssysteme. Batch unterstützt Linux mit einem angepassten Knoten-Agent für einen Teil der Linux-Betriebssystemdistributionen. Es wird empfohlen, das Betriebssystem mit den neuesten Patches, die vom Betriebssystemherausgeber bereitgestellt werden, auf dem neuesten Stand zu halten.

Es wird empfohlen, automatische Betriebssystemupgrades für Batch-Pools zu aktivieren, wodurch die zugrunde liegende Azure-Infrastruktur Updates über den Pool koordinieren kann. Diese Option kann so konfiguriert werden, dass sie die Aufgabenausführung nicht beeinträchtigt. Das automatische Betriebssystemupgrade unterstützt nicht alle Betriebssysteme, die von Batch unterstützt werden. Weitere Informationen finden Sie in der Unterstützungsmatrix für automatische Betriebssystemupgrades für VM-Skalierungsgruppen. Stellen Sie bei Windows-Betriebssystemen sicher, dass Sie die Eigenschaft virtualMachineConfiguration.windowsConfiguration.enableAutomaticUpdates nicht aktivieren, wenn Sie das automatische Betriebssystemupgrade im Batch-Pool verwenden.

Die Batch-Unterstützung für Images und Knoten-Agents wird im Laufe der Zeit schrittweise eingestellt, in der Regel entsprechend den Unterstützungszeitplänen der Herausgeber. Es wird empfohlen, die Verwendung von Images mit kurz bevorstehenden End-of-Life-Datumsangaben (EOL) zu vermeiden. Auch die Verwendung von Images, deren EOL-Datum bereits abgelaufen ist, sollte vermieden werden. Es liegt in Ihrer Verantwortung, die Ansicht der für Ihre Pools relevanten EOL-Datumsangaben in regelmäßigen Abständen zu aktualisieren und Ihre Workloads vor dem EOL zu migrieren. Wenn Sie ein benutzerdefiniertes Image mit einem angegebenen Knoten-Agent verwenden, müssen Sie sicherstellen, dass Sie die EOL-Datumsangaben der Batch-Unterstützung für das Image berücksichtigen, von dem Ihr benutzerdefiniertes Image abgeleitet oder an dem es ausgerichtet wird. Ein Image ohne batchSupportEndOfLife-Datum gibt an, dass ein solches Datum noch nicht vom Batch-Dienst festgelegt wurde. Das Fehlen eines Datums bedeutet nicht, dass das jeweilige Image unbegrenzt unterstützt wird. Ein EOL-Datum kann jederzeit in der Zukunft hinzugefügt oder aktualisiert werden. Sie können die EOL-Daten über die ListSupportedImages-API, mithilfe von PowerShell oder über die Azure CLI ermitteln.

Transport Layer Security (TLS) in Windows-Betriebssystemen

Der Batch-Knoten-Agent ändert weder die Standardwerte auf Betriebssystemebene für SSL/TLS-Versionen noch die Reihenfolge der Verschlüsselungssammlung. Unter Windows werden SSL/TLS-Versionen und die Reihenfolge der Verschlüsselungssammlung auf Betriebssystemebene gesteuert, und daher übernimmt der Batch-Knoten-Agent die Einstellungen, die von dem auf den einzelnen Computeknoten verwendeten Image festgelegt werden. Der Batch-Knoten-Agent versucht zwar, nach Möglichkeit die sichersten verfügbaren Einstellungen zu verwenden, dies kann jedoch durch Einstellungen auf Betriebssystemebene eingeschränkt sein. Es wird empfohlen, die Standardwerte auf Betriebssystemebene zu überprüfen und entsprechend auf den sichersten Modus festzulegen, der für Ihre Workflow- und Organisationsanforderungen geeignet ist. Weitere Informationen zur Erzwingung von Verschlüsselungssammlungen finden Sie unter Verwalten von TLS und zur SSL/TLS-Versionssteuerung für Schannel SSP unter TLS-Registrierungseinstellungen. Beachten Sie, dass einige Einstellungsänderungen einen Neustart erfordern, um wirksam zu werden. Es wird empfohlen, ein neueres Betriebssystem mit modernen Sicherheitsstandards oder ein benutzerdefiniertes Image mit geänderten Einstellungen zu verwenden, anstatt solche Einstellungen mit einer Batch-Startaufgabe zu verwenden.

Einschränken des Zugriffs auf Batch-Endpunkte

Es steht eine Reihe von Funktionen zur Verfügung, mit denen Sie den Zugriff auf die verschiedenen Batch-Endpunkte einschränken können. Dies ist insbesondere dann wichtig, wenn Ihre Lösung ein virtuelles Netzwerk nutzt.

Verwenden privater Endpunkte

Azure Private Link ermöglicht den Zugriff auf Azure-PaaS-Dienste und auf in Azure gehostete kundeneigene Dienste/Partnerdienste über einen privaten Endpunkt in Ihrem virtuellen Netzwerk. Mit Private Link können Sie den Zugriff auf ein Batch-Konto aus dem virtuellen Netzwerk oder aus einem mittels Peering verbundenen Netzwerk einschränken. Auf Ressourcen, die Private Link zugeordnet sind, kann auch lokal über privates Peering über VPN oder Azure ExpressRoute zugegriffen werden.

Damit private Endpunkte verwendet werden können, muss ein Batch-Konto bei der Erstellung entsprechend konfiguriert werden: Die Konfiguration des Zugriffs aus öffentlichen Netzwerken muss deaktiviert werden. Nach der Erstellung können private Endpunkte erstellt und dem Batch-Konto zugeordnet werden. Weitere Informationen finden Sie unter Verwenden privater Endpunkte mit Azure Batch-Konten.

Erstellen von Pools in virtuellen Netzwerken

Computeknoten in einem Batch-Pool können miteinander kommunizieren, z. B. zum Ausführen von Aufgaben mit mehreren Instanzen, ohne dass ein virtuelles Netzwerk (VNET) erforderlich ist. Allerdings können Knoten in einem Pool standardmäßig nicht mit virtuellen Computern kommunizieren, die sich außerhalb des Pools in einem virtuellen Netzwerk befinden und private IP-Adressen aufweisen. Beispiele hierfür sind Lizenzserver oder Dateiserver.

Um eine sichere Kommunikation zwischen Computeknoten und virtuellen Computern oder lokalen Netzwerken zu ermöglichen, können Sie den Pool in einem Subnetz eines Azure VNETs konfigurieren.

Wenn die Pools über öffentliche IP-Endpunkte verfügen, muss das Subnetz die eingehende Kommunikation vom Batch-Dienst zulassen, damit auf dem Computeknoten Aufgaben geplant und andere Vorgänge ausgeführt werden können. Die ausgehende Kommunikation muss ebenfalls zugelassen sein, damit entsprechend den Anforderungen Ihrer Workload mit Azure Storage und anderen Ressourcen kommuniziert werden kann. Für Pools in der VM-Konfiguration fügt Batch auf der Ebene der Netzwerkschnittstelle Netzwerksicherheitsgruppen (NSGs) hinzu, die an die Computeknoten angefügt sind. Diese Netzwerksicherheitsgruppen enthalten Regeln, um Folgendes zu ermöglichen:

  • Eingehender TCP-Datenverkehr von IP-Adressen des Batch-Diensts
  • Eingehender TCP-Datenverkehr für den Remotezugriff
  • Ausgehender Datenverkehr an allen Ports zum virtuellen Netzwerk (kann gemäß NSG-Regeln auf Subnetzebene geändert werden)
  • Ausgehender Datenverkehr an allen Ports zum Internet (kann gemäß NSG-Regeln auf Subnetzebene geändert werden)

Sie müssen keine NSGs auf der Subnetzebene des virtuellen Netzwerks angeben, da Batch eigene NSGs konfiguriert. Wenn eine Ihrer NSGs dem Subnetz zugeordnet ist, in dem Batch-Computeknoten bereitgestellt sind, oder wenn Sie benutzerdefinierte NSG-Regeln anwenden möchten, um die angewendeten Standardeinstellungen außer Kraft zu setzen, müssen Sie diese NSG mindestens mit Eingangs- und Ausgangssicherheitsregeln konfigurieren. Dies ist für die Kommunikation zwischen dem Batch-Dienst und den Poolknoten sowie den Poolknoten und Azure Storage erforderlich.

Weitere Informationen finden Sie unter Erstellen eines Azure Batch-Pools in einem virtuellen Netzwerk.

Erstellen von Pools mit statischen öffentlichen IP-Adressen

Standardmäßig sind die öffentlichen IP-Adressen, die Pools zugeordnet sind, dynamisch. Sie werden während der Poolerstellung erstellt und können bei einer Änderung der Poolgröße hinzugefügt oder entfernt werden. Wenn die auf den Poolknoten ausgeführten Anwendungen für Aufgaben auf externe Dienste zugreifen müssen, muss dieser Zugriff möglicherweise auf bestimmte IP-Adressen beschränkt werden. In diesem Fall ist die Verwendung von dynamischen IP-Adressen nicht praktikabel.

Sie können statische öffentliche IP-Adressen im selben Abonnement erstellen, in dem sich das Batch-Konto befindet, bevor Sie den Pool erstellen. Dann können Sie beim Erstellen des Pools diese Adressen angeben.

Weitere Informationen finden Sie unter Erstellen eines Azure Batch-Pools mit angegebenen öffentlichen IP-Adressen.

Erstellen von Pools ohne öffentliche IP-Adressen

Standardmäßig wird allen Computeknoten in einem Azure Batch-Konfigurationspool für virtuelle Computer mindestens eine öffentliche IP-Adresse zugewiesen. Diese Endpunkte werden Batch-Dienst zur Planung von Aufgaben und zur Kommunikation mit Computeknoten verwendet, einschließlich des ausgehenden Zugriffs auf das Internet.

Um den Zugriff auf diese Knoten einzuschränken und die Auffindbarkeit dieser Knoten im Internet zu verringern, können Sie den Pool ohne öffentliche IP-Adressen bereitstellen.

Weitere Informationen finden Sie unter Erstellen eines Pools ohne öffentliche IP-Adressen.

Beschränken des Remotezugriffs auf Poolknoten

Standardmäßig kann Batch es einem Knotenbenutzer mit Netzwerkkonnektivität ermöglichen, über RDP oder SSH eine externe Verbindung mit einem Computeknoten in einem Batch-Pool herzustellen.

Um den Remotezugriff auf Knoten zu beschränken, verwenden Sie eine der folgenden Methoden:

  • Konfigurieren Sie die PoolEndpointConfiguration so, dass der Zugriff verweigert wird. Dem Pool wird die entsprechende Netzwerksicherheitsgruppe zugeordnet.
  • Erstellen Sie Ihren Pool ohne öffentliche IP-Adressen. Standardmäßig ist kein Zugriff auf diese Pools von außerhalb des virtuellen Netzwerks möglich.
  • Ordnen Sie dem virtuellen Netzwerk eine Netzwerksicherheitsgruppe zu, um den Zugriff auf das RDP oder die SSH-Ports zu verweigern.
  • Erstellen Sie keine Benutzer auf dem Knoten. Ohne Knotenbenutzer ist kein Remotezugriff möglich.

Verschlüsseln von Daten

Verschlüsseln von Daten während der Übertragung

Die gesamte Kommunikation mit dem Batch-Kontoendpunkt (oder über Azure Resource Manager) muss HTTPS verwenden. Beim Herstellen einer Verbindung mit dem Batch-Dienst müssen Sie https:// in den Batch-Konto-URLs verwenden, die in den APIs angegeben sind.

Clients, die mit dem Batch-Dienst kommunizieren, müssen für die Verwendung von TLS 1.2 (Transport Layer Security) konfiguriert sein.

Verschlüsseln ruhender Batch-Daten

Einige der in Batch-APIs angegebenen Informationen – z. B. Kontozertifikate, Auftrags- und Aufgabenmetadaten und Aufgabenbefehlszeilen – werden beim Speichern durch den Batch-Dienst automatisch verschlüsselt. Diese Daten werden standardmäßig mit Schlüsseln verschlüsselt, die von der Azure Batch-Plattform verwaltet werden und für jedes Batch-Konto eindeutig sind.

Sie können diese Daten auch mithilfe von kundenseitig verwalteten Schlüsseln verschlüsseln. Die Schlüssel werden in Azure Key Vault generiert und gespeichert, und die Schlüsselbezeichner werden bei Ihrem Batch-Konto registriert.

Verschlüsseln von Datenträgern auf Computeknoten

Batch-Computeknoten weisen standardmäßig zwei Datenträger auf: einen Betriebssystemdatenträger sowie das lokale temporäre SSD. Von Batch verwaltete Dateien und Verzeichnisse befinden sich auf dem temporären SSD. Dies ist der Standardspeicherort für Dateien wie beispielsweise für die Aufgabenausgabe. Batch-Aufgabenanwendungen können den Standardspeicherort auf dem SSD oder den Betriebssystemdatenträger verwenden.

Um für zusätzliche Sicherheit zu sorgen, verschlüsseln Sie diese Datenträger mithilfe einer der folgenden Azure-Funktionen für die Datenträgerverschlüsselung:

Sicherer Zugriff auf Dienste von Computeknoten

Verwenden Sie verwaltete Poolidentitäten mit den entsprechenden Zugriffsberechtigungen, die für die benutzerseitig zugewiesene verwaltete Identität konfiguriert sind, um auf Azure-Dienste zuzugreifen, die die verwaltete Identität unterstützen, darunter auch Azure Key Vault. Wenn Sie Zertifikate auf Batch-Knoten bereitstellen müssen, verwenden Sie die verfügbare Azure Key Vault-VM-Erweiterung in Verbindung mit einer verwalteten Poolidentität, um Zertifikate im Batch-Pool zu installieren und zu verwalten. Weitere Informationen zum Bereitstellen von Zertifikaten über Azure Key Vault mit verwalteter Identität in Batch-Pools finden Sie unter Aktivieren der automatischen Zertifikatrotation in einem Batch-Pool.

Governance und Einhaltung

Konformität

Um Kunden bei der Erfüllung ihrer Complianceverpflichtungen in stark regulierten Branchen und Märkten auf der ganzen Welt zu unterstützen, pflegt Azure ein umfangreiches Portfolio mit Complianceangeboten.

Diese Angebote basieren auf unterschiedlichen Arten von Zusicherungen, z. B. formale Zertifizierungen, Nachweise, Validierungen, Autorisierungen und Bewertungen, die von unabhängigen externen Prüfunternehmen erstellt wurden, sowie Vertragsänderungen, Selbstbewertungen und Kundenleitfäden, die von Microsoft erstellt wurden. Sehen Sie sich umfassende Übersicht über unsere Complianceangebote an, um herauszufinden, welche Angebote für Ihre Batch-Lösungen relevant sein können.

Azure Policy

Azure Policy hilft bei der Durchsetzung von Organisationsstandards und bei der Bewertung der Compliance im großen Stil. Häufige Anwendungsfälle für Azure Policy sind die Implementierung von Governance für Ressourcenkonsistenz, Einhaltung gesetzlicher Bestimmungen, Sicherheit, Kosten und Verwaltung.

Je nachdem, welchen Poolzuordnungsmodus Sie nutzen und für welche Ressourcen eine Richtlinie gelten soll, können Sie Azure Policy auf eine der folgenden Arten mit Batch verwenden:

  • Direkte Nutzung: Verwenden Sie die Ressource „Microsoft.Batch/batchAccounts“. Hierbei können Sie einen Teil der Eigenschaften für ein Batch-Konto verwenden. Ein Beispiel: Ihre Richtlinie kann gültige Batch-Kontoregionen und einen gültigen Poolzuordnungsmodus einschließen und festlegen, ob ein öffentliches Netzwerk für die Konten aktiviert ist.
  • Indirekte Nutzung: Verwenden Sie die Ressource „Microsoft.Compute/virtualMachineScaleSets“. Bei Batch-Konten mit dem Poolzuordnungsmodus „Benutzerabonnement“ kann eine Richtlinie für die VM-Skalierungsgruppenressourcen festgelegt werden, die im Batch-Kontoabonnement erstellt werden. Sie können beispielsweise zulässige VM-Größen angeben und sicherstellen, dass bestimmte Erweiterungen auf jedem Poolknoten ausgeführt werden.

Nächste Schritte