Beheer van Azure Automation-gegevens
Dit artikel bevat verschillende onderwerpen waarin wordt uitgelegd hoe gegevens worden beveiligd en beveiligd in een Azure Automation-omgeving.
TLS voor Azure Automation
Om de beveiliging van gegevens in transit naar Azure Automation te waarborgen, raden we u ten zeere aan het gebruik van Transport Layer Security (TLS) te configureren. Hier volgt een lijst met methoden of clients die via HTTPS communiceren met de Automation-service:
Webhook-aanroepen
Hybrid Runbook Workers voor gebruikers (op basis van extensies en agents)
Machines die worden beheerd door Azure Automation Updatebeheer en Azure Automation Wijzigingen bijhouden en inventaris
Azure Automation DSC-knooppunten
Oudere versies van TLS/Secure Sockets Layer (SSL) zijn kwetsbaar gebleken en hoewel ze momenteel nog steeds werken om compatibiliteit met eerdere versies mogelijk te maken, worden ze niet aanbevolen. Het is niet raadzaam om uw agent expliciet in te stellen op alleen TLS 1.2, tenzij dit nodig is, omdat het beveiligingsfuncties op platformniveau kan verbreken waarmee u automatisch nieuwere, veiligere protocollen kunt detecteren en gebruiken zodra ze beschikbaar komen, zoals TLS 1.3.
Zie het overzicht van de Log Analytics-agent - TLS voor informatie over TLS-ondersteuning met de Log Analytics-agent voor Windows en Linux. Dit is een afhankelijkheid voor de rol Hybrid Runbook Worker.
TLS-protocol upgraden voor Hybrid Workers en Webhook-aanroepen
Vanaf 31 oktober 2024 zouden alle op agents gebaseerde en extensiegebaseerde Hybrid Runbook Workers voor gebruikers, Webhooks, DSC-knooppunten en Azure Automation Updatebeheer en Wijzigingen bijhouden beheerde machines, met behulp van TLS-protocollen (Transport Layer Security) 1.0 en 1.1, geen verbinding meer kunnen maken met Azure Automation. Alle taken die worden uitgevoerd of gepland op Hybrid Workers met behulp van TLS 1.0- en 1.1-protocollen, mislukken.
Zorg ervoor dat de webhook aanroept die runbooks activeren op TLS 1.2 of hoger. Meer informatie over het uitschakelen van TLS 1.0/1.1-protocollen op Windows Hybrid Worker en het inschakelen van TLS 1.2 of hoger op windows-computers.
Voer voor Linux Hybrid Workers het volgende Python-script uit om een upgrade uit te voeren naar het nieuwste TLS-protocol.
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.")
Platformspecifieke richtlijnen
Platform/taal | Ondersteuning | Meer informatie |
---|---|---|
Linux | Linux-distributies zijn meestal afhankelijk van OpenSSL voor TLS 1.2-ondersteuning. | Controleer het Changelog van OpenSSL om te bevestigen dat uw versie van OpenSSL wordt ondersteund. |
Windows 8.0 - 10 | Ondersteund en standaard ingeschakeld. | Controleer of u nog steeds de standaardinstellingen gebruikt. |
Windows Server 2012 - 2016 | Ondersteund en standaard ingeschakeld. | Bevestigen dat u nog steeds de standaardinstellingen gebruikt |
Windows 7 SP1 en Windows Server 2008 R2 SP1 | Ondersteund, maar niet standaard ingeschakeld. | Zie de registerinstellingenpagina Transport Layer Security (TLS) voor meer informatie over het inschakelen. |
Gegevensretentie
Wanneer u een resource verwijdert in Azure Automation, wordt deze gedurende vele dagen bewaard voor controledoeleinden voordat deze definitief wordt verwijderd. U kunt de resource gedurende deze tijd niet zien of gebruiken. Dit beleid is ook van toepassing op resources die deel uitmaken van een verwijderd Automation-account. Het bewaarbeleid is van toepassing op alle gebruikers en kan momenteel niet worden aangepast. Als u gegevens echter langer wilt bewaren, kunt u Azure Automation-taakgegevens doorsturen naar Azure Monitor-logboeken.
De volgende tabel bevat een overzicht van het bewaarbeleid voor verschillende resources.
Gegevens | Beleid |
---|---|
Accounts | Een account wordt 30 dagen nadat een gebruiker het heeft verwijderd definitief verwijderd. |
Activa | Een asset wordt 30 dagen nadat een gebruiker het heeft verwijderd definitief verwijderd of 30 dagen nadat een gebruiker een account met de asset heeft verwijderd. Assets omvatten variabelen, planningen, referenties, certificaten, Python 2-pakketten en verbindingen. |
DSC-knooppunten | Een DSC-knooppunt wordt 30 dagen na de registratie van een Automation-account definitief verwijderd met behulp van Azure Portal of de cmdlet Unregister-AzAutomationDscNode in Windows PowerShell. Een knooppunt wordt ook 30 dagen nadat een gebruiker het account dat het knooppunt bevat, definitief verwijderd. |
Projecten | Een taak wordt 30 dagen na wijziging verwijderd en definitief verwijderd, bijvoorbeeld nadat de taak is voltooid, is gestopt of wordt opgeschort. |
Modules | Een module wordt 30 dagen nadat een gebruiker deze heeft verwijderd definitief verwijderd of 30 dagen nadat een gebruiker het account verwijdert dat de module bevat. |
Knooppuntconfiguraties/MOF-bestanden | Een oude knooppuntconfiguratie wordt 30 dagen na het genereren van een nieuwe knooppuntconfiguratie definitief verwijderd. |
Knooppuntrapporten | Een knooppuntrapport wordt 90 dagen na het genereren van een nieuw rapport definitief verwijderd voor dat knooppunt. |
Runbooks | Een runbook wordt 30 dagen na het verwijderen van de resource definitief verwijderd of 30 dagen nadat een gebruiker het account met de resource1 heeft verwijderd. |
1Het runbook kan worden hersteld binnen het venster van 30 dagen door een ondersteuning voor Azure incident in te dienen bij Microsoft Azure Support. Ga naar de ondersteuning voor Azure site en selecteer Een ondersteuningsaanvraag indienen.
Back-up van gegevens
Wanneer u een Automation-account in Azure verwijdert, worden alle objecten in het account verwijderd. De objecten omvatten runbooks, modules, configuraties, instellingen, taken en assets. U kunt een verwijderd Automation-account binnen 30 dagen herstellen . U kunt ook de volgende informatie gebruiken om een back-up te maken van de inhoud van uw Automation-account voordat u het verwijdert:
Runbooks
U kunt uw runbooks exporteren naar scriptbestanden met behulp van Azure Portal of de cmdlet Get-AzureAutomationRunbookDefinition in Windows PowerShell. U kunt deze scriptbestanden importeren in een ander Automation-account, zoals beschreven in Runbooks beheren in Azure Automation.
Integratiemodules
U kunt integratiemodules niet exporteren vanuit Azure Automation. Deze moeten buiten het Automation-account beschikbaar worden gesteld.
Activa
U kunt Azure Automation-assets niet exporteren: certificaten, verbindingen, referenties, planningen en variabelen. In plaats daarvan kunt u de Azure-portal en Azure-cmdlets gebruiken om de details van deze assets te noteren. Gebruik vervolgens deze gegevens om assets te maken die worden gebruikt door runbooks die u in een ander Automation-account importeert.
U kunt de waarden voor versleutelde variabelen of de wachtwoordvelden van referenties niet ophalen met behulp van cmdlets. Als u deze waarden niet weet, kunt u deze ophalen in een runbook. Zie Variabele assets in Azure Automation voor het ophalen van variabele waarden. Zie Referentieassets in Azure Automation voor meer informatie over het ophalen van referentiewaarden.
DSC-configuraties
U kunt uw DSC-configuraties exporteren naar scriptbestanden met behulp van Azure Portal of de cmdlet Export-AzAutomationDscConfiguration in Windows PowerShell. U kunt deze configuraties importeren en gebruiken in een ander Automation-account.
Gegevensresidentie
U geeft een regio op tijdens het maken van een Azure Automation-account. Servicegegevens zoals assets, configuratie, logboeken worden opgeslagen in die regio en kunnen worden overgedragen of verwerkt in andere regio's binnen dezelfde geografie. Deze globale eindpunten zijn nodig om eindgebruikers een hoogwaardige, lage latentie-ervaring te bieden, ongeacht de locatie. Alleen voor de regio Brazilië - zuid (São Paulo) van geografie Brazilië, regio Azië - zuidoost (Singapore) en regio Azië - oost (Hongkong) van de regio Azië en Stille Oceaan, slaan we Azure Automation-gegevens op in dezelfde regio om te voldoen aan vereisten voor gegevenslocatie voor deze regio's.
Volgende stappen
- Zie Best practices voor beveiliging in Azure Automation voor meer informatie over beveiligingsrichtlijnen.
- Zie Versleuteling van beveiligde assets in Azure Automation voor meer informatie over beveiligde assets in Azure Automation.
- Zie Actieve geo-replicatie maken en gebruiken voor meer informatie over geo-replicatie.