Bewährte Methoden für Sicherheit und Compliance für Batch

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.

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.

Allgemeine sicherheitsbezogene Best Practices

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 Computeknoten, und Computeknoten müssen auch mit Azure Storage kommunizieren. Im vereinfachten Knotenkommunikationsmodell initiieren Computeknoten 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 Trusted Launch (erfordert Gen2-VM-Images und eine kompatible VM-Größe), der Aktivierung von sicherem Start, vTPM und Verschlüsselung auf Host (erfordert eine kompatible VM-Größe).

Authentifizierung für Batch-Konten

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

Es wird dringend empfohlen, Microsoft Entra ID 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 nur auf Microsoft Entra ID beschränkt werden. Wenn diese Eigenschaft festgelegt ist, werden API-Aufrufe mit Shared Key-Authentifizierung 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-eigenen 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 auf Ressourcen von VM-Skalierungsgruppen anwenden 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.

Netzwerkendpunktzugriff einschränken

Netzwerkendpunkte stapelweise

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

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 gelten Verwaltungsvorgänge für einzelne und mehrere Batch-Konten. Der Zugriff auf diese Verwaltungsvorgänge erfolgt über Azure Resource Manager.

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

Computeknoten für Batch-Pool

Der Batch-Dienst kommuniziert mit einem Batch-Knoten-Agent, der auf jedem Knoten im Pool ausgeführt wird. 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 einen oder mehrere Load Balancer 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 den Lastenausgleichsmodulen öffentliche IP-Adressen zugeordnet. Sie können auch remote über RDP oder SSH auf Poolknoten zugreifen. Weitere Informationen finden Sie unter Konfigurieren des Remotezugriffs auf Computeknoten in einem Azure-Batch-Pool.

Betriebssystem für Batch-Computeknoten

Batch unterstützt sowohl Linux- als auch Windows-Betriebssysteme. Batch unterstützt Linux mit einem kompatiblen Node-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 Support-Zeitplänen der Publisher. 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 Erreichen des EOL-Datums zu migrieren. Wenn Sie ein benutzerdefiniertes Image mit einem angegebenen Knoten-Agent verwenden, müssen Sie sicherstellen, dass Sie die End-of-Life-Termine des Batch-Supports für das Image einhalten, von dem Ihr benutzerdefiniertes Image abgeleitet oder mit dem es abgestimmt ist. 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 die Standardwerte auf Betriebssystemebene für SSL/TLS-Versionen oder die Reihenfolge der Cipher Suites nicht. Unter Windows werden SSL/TLS-Versionen und die Reihenfolge der Verschlüsselungssuiten 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, kann jedoch weiterhin 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 der Reihenfolge von Sicherheitssammlungen 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 Sicherheitsstandardeinstellungen 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.

Private Endpunkte verwenden

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 sicher zwischen Computeknoten und anderen virtuellen Maschinen oder mit einem lokalen Netzwerk kommunizieren zu können, 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 an die Computeknoten angefügten Netzwerkschnittstelle Netzwerksicherheitsgruppen (NSGs) hinzu. 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 auf jedem beliebigen Port 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 dem Subnetz, in dem Batch-Computeknoten bereitgestellt sind, eine NSG zugeordnet ist 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, um die Kommunikation zwischen dem Batch-Dienst und den Poolknoten sowie zwischen den Poolknoten und Azure Storage zu ermöglichen.

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 bei der Erstellung eines Pools erstellt, und einem Pool können bei einer Änderung der Poolgröße IP-Adressen hinzugefügt oder daraus 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 eine oder mehrere öffentliche IP-Adressen zugewiesen. Diese Endpunkte werden vom 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

Für Pools, die mit einer API-Version vor 2024-07-01 erstellt wurden, gestattet Batch standardmäßig einem Knotenbenutzer, sich bei externer Netzwerkkonnektivität mithilfe von RDP oder SSH mit einem Computeknoten in einem Batch-Pool zu verbinden.

Um den Remotezugriff einzuschränken, erstellen Sie Ihre Pools mit der API-Version 2024-07-01 oder höher.

Verwenden Sie eine der folgenden Methoden, um den Remotezugriff auf Knoten in Pools zu beschränken, die von der API mit einer Version vor 2024-07-01 erstellt wurden:

• 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 VNet eine NSG zu, um den Zugriff auf das RDP oder die SSH-Ports zu verweigern.
• Erstellen Sie keine Benutzer auf dem Knoten. Ohne Benutzer auf dem Node ist kein Remotezugriff möglich.

Daten verschlüsseln

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, sollten für die Verwendung von TLS 1.2 (Transport Layer Security) konfiguriert sein.

Batch-Daten im Ruhezustand verschlüsseln

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. Der Schlüssel wird in Azure Key Vault generiert und gespeichert, und der Schlüsselbezeichner wird bei Ihrem Batch-Konto registriert.

Verschlüsseln von Datenträgern auf Rechenknoten

Batch-Computeknoten weisen standardmäßig zwei Datenträger auf: einen Betriebssystemdatenträger sowie die lokale temporäre SSD-Festplatte. Von Batch verwaltete Dateien und Verzeichnisse befinden sich auf der temporären SSD. Dies ist der Standardspeicherort für Dateien wie beispielsweise für Task-Ausgabedateien. 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:

• Verschlüsselung von verwalteten Datenträgern ruhender Daten mit plattformseitig verwalteten Schlüsseln
• Verschlüsselung auf dem Host mithilfe eines plattformseitig verwalteten Schlüssels
• Batchpool-Festplattenverschlüsselung konfigurieren

Greifen Sie sicher auf Dienste von Computeknoten zu

Verwenden Sie poolverwaltete Identitäten mit den entsprechenden Zugriffsberechtigungen, die für die vom Benutzer zugewiesene verwaltete Identität konfiguriert sind, um auf Azure-Dienste zuzugreifen, die verwaltete Identitäten 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 der verwalteten Identität des Pools, 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 Compliance

Compliance

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 die umfassende Übersicht über Compliance-Angebote an, um herauszufinden, welche davon für Ihre Batch-Lösungen relevant sein können.

Azure-Richtlinie

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:

• Direkt über 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.
• Indirekt durch Verwendung der Ressource „Microsoft.Compute/virtualMachineScaleSets“. Bei Batch-Konten mit dem Poolzuordnungsmodus für Benutzerabonnements kann eine Richtlinie für die VM-Skalierungsgruppenressourcen festgelegt werden, die im Batch-Kontoabonnement erstellt werden. Beispielsweise zulässige VM-Größen angeben und sicherstellen, dass bestimmte Erweiterungen auf jedem Poolknoten ausgeführt werden.

Nächste Schritte

• Informieren Sie sich über die Azure-Sicherheitsbaseline für Batch.
• Erfahren Sie mehr über Best Practices für Azure Batch.