Hantera Azure Automation-data

  • Artikel

Den här artikeln innehåller flera avsnitt som förklarar hur data skyddas och skyddas i en Azure Automation-miljö.

TLS för Azure Automation

För att säkerställa säkerheten för data under överföring till Azure Automation rekommenderar vi starkt att du konfigurerar användningen av TLS (Transport Layer Security). Följande är en lista över metoder eller klienter som kommunicerar via HTTPS till Automation-tjänsten:

  • Webhook-anrop

  • Hybrid Runbook Workers, som innehåller datorer som hanteras av Uppdateringshantering och Ändringsspårning och inventering.

  • DSC-noder

Äldre versioner av TLS/Secure Sockets Layer (SSL) har visat sig vara sårbara och även om de fortfarande arbetar för att tillåta bakåtkompatibilitet rekommenderas de inte. Vi rekommenderar inte att du uttryckligen anger att din agent endast ska använda TLS 1.2 om det inte är nödvändigt, eftersom det kan bryta säkerhetsfunktioner på plattformsnivå som gör att du automatiskt kan identifiera och dra nytta av nyare säkrare protokoll när de blir tillgängliga, till exempel TLS 1.3.

Information om TLS-stöd med Log Analytics-agenten för Windows och Linux, som är ett beroende för rollen Hybrid Runbook Worker, finns i Översikt över Log Analytics-agent – TLS.

Uppgradera TLS-protokollet för Hybrid Worker- och Webhook-anrop

Från och med den 31 oktober 2024 skulle alla agentbaserade och tilläggsbaserade User Hybrid Runbook Worker-, Webhooks- och DSC-noder med hjälp av TLS-protokollen (Transport Layer Security) 1.0 och 1.1 inte längre kunna ansluta till Azure Automation. Alla jobb som körs eller schemaläggs för hybridarbetare med TLS 1.0- och 1.1-protokoll misslyckas.

Kontrollera att Webhook-anropen som utlöser runbooks navigerar på TLS 1.2 eller senare. Se till att göra registerändringar så att agent- och tilläggsbaserade arbetare endast förhandlar om TLS 1.2- och högre protokoll. Lär dig hur du inaktiverar TLS 1.0/1.1-protokoll i Windows Hybrid Worker och aktiverar TLS 1.2 eller senare på Windows-datorn.

För Linux Hybrid Workers kör du följande Python-skript för att uppgradera till det senaste TLS-protokollet.

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.")

Plattformsspecifik vägledning

Plattform/språk Support Mer information
Linux Linux-distributioner tenderar att förlita sig på Stöd för OpenSSL för TLS 1.2. Kontrollera OpenSSL-ändringsloggen för att bekräfta att din version av OpenSSL stöds.
Windows 8.0 – 10 Stöds och aktiveras som standard. Bekräfta att du fortfarande använder standardinställningarna.
Windows Server 2012 – 2016 Stöds och aktiveras som standard. Bekräfta att du fortfarande använder standardinställningarna
Windows 7 SP1 och Windows Server 2008 R2 SP1 Stöds men är inte aktiverat som standard. Mer information om hur du aktiverar finns på sidan TLS-registerinställningar (Transport Layer Security).

Datakvarhållning

När du tar bort en resurs i Azure Automation behålls den i många dagar i granskningssyfte innan den tas bort permanent. Du kan inte se eller använda resursen under den här tiden. Den här principen gäller även för resurser som tillhör ett borttaget Automation-konto. Kvarhållningsprincipen gäller för alla användare och kan för närvarande inte anpassas. Men om du behöver behålla data under en längre period kan du vidarebefordra Azure Automation-jobbdata till Azure Monitor-loggar.

I följande tabell sammanfattas kvarhållningsprincipen för olika resurser.

Data Policy
Accounts Ett konto tas bort permanent 30 dagar efter att en användare har tagit bort det.
Tillgångar En tillgång tas bort permanent 30 dagar efter att en användare har tagit bort den, eller 30 dagar efter att en användare har tagit bort ett konto som innehåller tillgången. Tillgångar omfattar variabler, scheman, autentiseringsuppgifter, certifikat, Python 2-paket och anslutningar.
DSC-noder En DSC-nod tas bort permanent 30 dagar efter att den har avregistrerats från ett Automation-konto med hjälp av Azure-portalen eller cmdleten Unregister-AzAutomationDscNode i Windows PowerShell. En nod tas också bort permanent 30 dagar efter att en användare har tagit bort det konto som innehåller noden.
Projekt Ett jobb tas bort och tas bort permanent 30 dagar efter ändringen, till exempel när jobbet har slutförts, stoppas eller pausas.
Moduler En modul tas bort permanent 30 dagar efter att en användare har tagit bort den, eller 30 dagar efter att en användare har tagit bort det konto som innehåller modulen.
Nodkonfigurationer/MOF-filer En gammal nodkonfiguration tas bort permanent 30 dagar efter att en ny nodkonfiguration har genererats.
Nodrapporter En nodrapport tas bort permanent 90 dagar efter att en ny rapport har genererats för noden.
Runbooks En runbook tas bort permanent 30 dagar efter att en användare har tagit bort resursen, eller 30 dagar efter att en användare har tagit bort det konto som innehåller resursen1.

1Runbooken kan återställas inom 30-dagarsfönstret genom att skicka in en Azure-supportincident med Microsoft Azure Support. Gå till Azure-supportwebbplatsen och välj Skicka en supportbegäran.

Säkerhetskopiering av data

När du tar bort ett Automation-konto i Azure tas alla objekt i kontot bort. Objekten omfattar runbooks, moduler, konfigurationer, inställningar, jobb och tillgångar. Du kan återställa ett borttaget Automation-konto inom 30 dagar. Du kan också använda följande information för att säkerhetskopiera innehållet i ditt Automation-konto innan du tar bort det:

Runbooks

Du kan exportera dina runbooks till skriptfiler med hjälp av antingen Azure-portalen eller cmdleten Get-AzureAutomationRunbookDefinition i Windows PowerShell. Du kan importera dessa skriptfiler till ett annat Automation-konto, enligt beskrivningen i Hantera runbooks i Azure Automation.

Integreringsmoduler

Du kan inte exportera integreringsmoduler från Azure Automation. De måste göras tillgängliga utanför Automation-kontot.

Tillgångar

Du kan inte exportera Azure Automation-tillgångar: certifikat, anslutningar, autentiseringsuppgifter, scheman och variabler. I stället kan du använda Azure-portalen och Azure-cmdletar för att notera informationen om dessa tillgångar. Använd sedan den här informationen för att skapa tillgångar som används av runbooks som du importerar till ett annat Automation-konto.

Du kan inte hämta värdena för krypterade variabler eller lösenordsfälten för autentiseringsuppgifter med hjälp av cmdletar. Om du inte känner till dessa värden kan du hämta dem i en runbook. Information om hur du hämtar variabelvärden finns i Variabeltillgångar i Azure Automation. Mer information om hur du hämtar autentiseringsvärden finns i Autentiseringstillgångar i Azure Automation.

DSC-konfigurationer

Du kan exportera dina DSC-konfigurationer till skriptfiler med hjälp av antingen Azure-portalen eller cmdleten Export-AzAutomationDscConfiguration i Windows PowerShell. Du kan importera och använda dessa konfigurationer i ett annat Automation-konto.

Dataresidens

Du anger en region när du skapar ett Azure Automation-konto. Tjänstdata som tillgångar, konfiguration, loggar lagras i den regionen och kan överföras eller bearbetas i andra regioner inom samma geografiska område. Dessa globala slutpunkter är nödvändiga för att ge slutanvändarna en högpresterande upplevelse med låg svarstid oavsett plats. Endast för regionen Brasilien, södra (Delstaten Sao Paulo) i Brasilien, sydostasien (Singapore) och asien, östra (Hongkong) i asien och stillahavsområdets geografi, lagrar vi Azure Automation-data i samma region för att tillgodose kraven på datahemvist för dessa regioner.

Nästa steg