Verwaltung von Azure Automation-Daten

  • Artikel

Dieser Artikel enthält verschiedene Themen, in denen erläutert wird, wie die Daten in einer Azure Automation-Umgebung geschützt und gesichert werden.

TLS 1.2 oder höher für Azure Automation

Um die Sicherheit von Daten bei der Übertragung an Azure Automation zu gewährleisten, wird dringend empfohlen, den Computer für die Verwendung von TLS 1.2 oder höher (Transport Layer Security) zu konfigurieren. Im Folgenden sehen Sie eine Liste der Methoden bzw. Clients, die über HTTPS mit dem Automation-Dienst kommunizieren:

  • Webhookaufrufe

  • Hybrid Runbook Workers, einschließlich Computern, die über die Updateverwaltung sowie „Änderungsnachverfolgung und Bestand“ verwaltet werden.

  • DSC-Knoten

Bei älteren Versionen von TLS/Secure Sockets Layer (SSL) wurde ein Sicherheitsrisiko festgestellt. Sie funktionieren aus Gründen der Abwärtskompatibilität zwar noch, werden jedoch nicht empfohlen. Es wird nicht empfohlen, Ihren Agent explizit so einzurichten, dass nur TLS 1.2 verwendet wird, es sei denn, dies ist erforderlich. Denn dadurch können Sicherheitsfeatures auf Plattformebene deaktiviert werden, mit deren Hilfe neuere, sicherere Protokolle wie TLS 1.3 automatisch erkannt und genutzt werden können, sobald diese verfügbar sind.

Informationen zur TLS 1.2-Unterstützung mit dem Log Analytics-Agent für Windows und Linux, bei dem es sich um eine Abhängigkeit für die Hybrid Runbook Worker-Rolle handelt, finden Sie unter Übersicht über den Log Analytics-Agent – TLS 1.2.

Aktualisieren des TLS-Protokolls für Hybrid-Worker und Webhook-Aufrufe

Ab dem 31. Oktober 2024 können alle Agent-basierten und erweiterungsbasierten Benutzerhybrid-Runbook-Worker, Webhooks und DSC-Knoten mit Transport Layer Security (TLS) 1.0- und 1.1-Protokollen keine Verbindung mehr mit Azure Automation herstellen. Alle Aufträge, die für Hybrid-Worker mit TLS 1.0- und 1.1-Protokollen ausgeführt oder geplant werden, werden fehlschlagen.

Stellen Sie sicher, dass die Webhook-Aufrufe, die Runbooks auslösen, in TLS 1.2 oder höher navigieren. Stellen Sie sicher, dass Registrierungsänderungen vorgenommen werden, damit Agent- und erweiterungsbasierte Worker nur über TLS 1.2 und höhere Protokolle verhandeln. Erfahren Sie, wie Sie TLS 1.0/1.1-Protokolle unter Windows Hybrid Worker deaktivieren und TLS 1.2 oder höher auf Windows-Computern aktivieren.

Führen Sie für Linux Hybrid Worker das folgende Python-Skript aus, um auf das neueste TLS-Protokoll zu aktualisieren.

import os

# Path to the OpenSSL configuration file as per Linux distro
openssl_conf_path = "/etc/ssl/openssl.cnf"

# Open the configuration file for reading
with open(openssl_conf_path, "r") as f:
    openssl_conf = f.read()

# Check if a default TLS version is already defined
if "DEFAULT@SECLEVEL" in openssl_conf:
    # Update the default TLS version to TLS 1.2
    openssl_conf = openssl_conf.replace("CipherString = DEFAULT@SECLEVEL", "CipherString = DEFAULT@SECLEVEL:TLSv1.2")

    # Open the configuration file for writing and write the updated version
    with open(openssl_conf_path, "w") as f:
        f.write(openssl_conf)

    # Restart any services that use OpenSSL to ensure that the new settings are applied
    os.system("systemctl restart apache2")
    print("Default TLS version has been updated to TLS 1.2.")
else:
    # Add the default TLS version to the configuration file
    openssl_conf += """
    Options = PrioritizeChaCha,EnableMiddleboxCompat
    CipherString = DEFAULT@SECLEVEL:TLSv1.2
    MinProtocol = TLSv1.2
    """

    # Open the configuration file for writing and write the updated version
    with open(openssl_conf_path, "w") as f:
        f.write(openssl_conf)

    # Restart any services that use OpenSSL to ensure that the new settings are applied
    os.system("systemctl restart apache2")
    print("Default TLS version has been added as TLS 1.2.")

Plattformspezifische Anleitungen

Plattform/Sprache Support Weitere Informationen
Linux Linux-Distributionen greifen zur Unterstützung von TLS 1.2 tendenziell auf OpenSSL zurück. Überprüfen Sie anhand des OpenSSL-Änderungsprotokolls, ob Ihre Version von OpenSSL unterstützt wird.
Windows 8.0 bis 10 Wird unterstützt und ist standardmäßig aktiviert. Zur Bestätigung, dass Sie weiterhin die Standardeinstellungen verwenden.
Windows Server 2012 bis 2016 Wird unterstützt und ist standardmäßig aktiviert. Zur Bestätigung, dass Sie weiterhin die Standardeinstellungen verwenden.
Windows 7 SP1 und Windows Server 2008 R2 SP1 Wird unterstützt, ist jedoch standardmäßig deaktiviert. Details zur Aktivierung finden Sie auf der Seite Transport Layer Security (TLS) registry settings (Registrierungseinstellungen für Transport Layer Security (TLS)).

Datenaufbewahrung

Wenn Sie eine Ressource in Azure Automation löschen, wird diese zu Überwachungszwecken für viele Tagen aufbewahrt, bevor sie endgültig gelöscht wird. In diesem Zeitraum kann die Ressource weder angezeigt noch verwendet werden. Diese Richtlinie gilt auch für Ressourcen, die zu einem gelöschten Automation-Konto gehören. Die Datenaufbewahrungsrichtlinie gilt für alle Benutzer und kann zurzeit nicht angepasst werden. Wenn Sie jedoch Daten für einen längeren Zeitraum aufbewahren müssen, können Sie Azure Automation-Auftragsdaten an Azure Monitor-Protokolle weiterleiten.

Die folgende Tabelle zeigt die Aufbewahrungsrichtlinie für unterschiedliche Ressourcen.

Daten Policy
Konten Ein Konto wird 30 Tage nach seiner Löschung durch den Benutzer endgültig entfernt.
Objekte Ein Objekt wird 30 Tage nach seiner Löschung durch den Benutzer endgültig entfernt oder 30 Tage, nachdem ein Benutzer ein Konto gelöscht hat, das das Objekt enthält. Zu den Objekten gehören Variablen, Zeitpläne, Anmeldeinformationen, Zertifikate, Python 2-Pakete und Verbindungen.
DSC-Knoten Ein DSC-Knoten wird 30 Tage nach Aufhebung seiner Registrierung im Automation-Konto über das Azure-Portal oder mit dem Cmdlet Unregister-AzAutomationDscNode in Windows PowerShell endgültig entfernt. Auch ein Knoten wird nach 30 Tagen endgültig entfernt, nachdem ein Benutzer das Konto gelöscht hat, das den Knoten enthält.
Aufträge Ein Auftrag wird 30 Tage nach der Änderung gelöscht und endgültig entfernt, z. B. nachdem der Auftrag abgeschlossen, beendet oder angehalten wurde.
Module Ein Modul wird 30 Tage nach seiner Löschung durch einen Benutzer endgültig entfernt oder 30 Tage, nachdem ein Benutzer das Konto gelöscht hat, das das Modul enthält.
Knotenkonfigurationen/MOF-Dateien Eine alte Knotenkonfiguration wird 30 Tage nach dem Generieren einer neuen Knotenkonfiguration endgültig entfernt.
Knotenberichte Ein Knotenbericht wird 90 Tage nach dem Generieren eines neuen Berichts für diesen Knoten endgültig entfernt.
Runbooks Ein Runbook wird 30 Tage, nachdem ein Benutzer die Ressource gelöscht hat, oder 30 Tage, nachdem ein Benutzer das Konto gelöscht hat, das die Ressource enthält, endgültig entfernt.1

1 Das Runbook kann innerhalb des 30-tägigen Zeitfensters wiederhergestellt werden. Hierzu muss ein Azure-Supportfall für den Microsoft Azure-Support erstellt werden. Besuchen Sie die Azure-Supportwebsite, und erstellen Sie eine Supportanfrage.

Datensicherung

Wenn Sie ein Automation-Konto in Azure löschen, werden auch alle Objekt in dem Konto gelöscht. Zu den Objekten zählen Runbooks, Module, Konfigurationen, Einstellungen, Aufträge und Objekte. Sie können ein gelöschtes Automatisierungskonto innerhalb von 30 Tagen wiederherstellen. Sie können die Inhalte Ihres Automation-Kontos auch mithilfe der folgenden Informationen sichern, bevor Sie das Konto löschen:

Runbooks

Sie können Ihre Runbooks entweder unter Verwendung des Azure-Portals oder mithilfe des Cmdlets Get-AzureAutomationRunbookDefinition in Windows PowerShell in Skriptdateien exportieren. Sie können diese Skriptdateien in ein anderes Automation-Konto importieren, wie unter Verwalten von Runbooks in Azure Automation besprochen.

Integrationsmodule

Integrationsmodule können nicht aus Azure Automation exportiert werden, sondern müssen außerhalb des Automation-Kontos zur Verfügung gestellt werden.

Objekte

Sie können keine Azure Automation-Objekte exportieren: Zertifikate, Verbindungen, Anmeldeinformationen, Zeitpläne und Variablen. Stattdessen können Sie das Azure-Portal und Azure-Cmdlets verwenden, um sich die Details dieser Objekte zu notieren. Verwenden Sie dann diese Details, um alle Objekte zu erstellen, die von Runbooks verwendet werden, die Sie in ein anderes Automation-Konto importieren.

Es ist nicht möglich, die Werte verschlüsselter Variablen oder die Kennwortfelder für Anmeldeinformationen mithilfe von Cmdlets abzurufen. Wenn Sie diese Werte nicht kennen, können Sie sie aus einem Runbook abrufen. Informationen zum Abrufen von Variablenwerten finden Sie unter Variablenobjekte in Azure Automation. Weitere Informationen zum Abrufen von Anmeldeinformationswerten finden Sie unter Anmeldeinformationsobjekte in Azure Automation.

DSC-Konfigurationen

Sie können Ihre DSC-Konfigurationen unter Verwendung des Azure-Portals oder mithilfe des Cmdlets Export-AzureRmAutomationDscConfiguration in Windows PowerShell in Skriptdateien exportieren. Sie können diese Konfigurationen in ein anderes Automation-Konto importiert importieren und darin verwenden.

Datenresidenz

Sie geben während der Erstellung eines Azure Automation-Kontos eine Region an. Dienstdaten wie Ressourcen, Konfiguration, Protokolle werden in dieser Region gespeichert und können in anderen Regionen innerhalb derselben Geografie übertragen oder verarbeitet werden. Diese globalen Endpunkte sind erforderlich, um Endbenutzern unabhängig von ihrem Standort eine hohe Leistung mit geringer Wartezeit zu bieten. Nur für die Region „Brasilien Süd“ (Bundesstaat Sao Paulo) im Großraum „Brasilien“, die Region „Asien Südost“ (Singapur) und „Asien Ost“ (Hongkong) im Großraum „Asien-Pazifik“ werden Azure Automation-Daten in derselben Region gespeichert, um die Anforderungen an die Datenresidenz für diese Regionen zu erfüllen.

Nächste Schritte