Gestione dei dati di Automazione di Azure

Questo articolo contiene diversi argomenti che illustrano come i dati sono protetti e protetti in un ambiente Automazione di Azure.

TLS per Automazione di Azure

Per garantire la sicurezza dei dati in transito a Automazione di Azure, è consigliabile configurare l'uso di Transport Layer Security (TLS). Di seguito è riportato un elenco di metodi o client che comunicano tramite HTTPS al servizio di Automazione:

• Chiamate webhook

• Ruoli di lavoro utente ibridi per runbook (basati su estensione e basati su agente)

• Computer gestiti dalla funzionalità di gestione degli aggiornamenti di Automazione di Azure e Monitoraggio modifiche e inventario di Automazione di Azure

• Automazione di Azure: nodi DSC

Le versioni precedenti di TLS/Secure Sockets Layer (SSL) sono state considerate vulnerabili. Nonostante siano ancora attualmente in uso per questioni di compatibilità con le versioni precedenti, non sono consigliate. Non è consigliabile impostare in modo esplicito l’agente in modo che usi solo TLS 1.2, a meno che non sia necessario, perché può interrompere le funzionalità di sicurezza a livello di piattaforma che consentono di rilevare e sfruttare automaticamente i protocolli più sicuri e più recenti man mano che diventano disponibili, ad esempio TLS 1.3.

Per informazioni sul supporto TLS con l'agente Log Analytics per Windows e Linux, che è una dipendenza per il ruolo di lavoro ibrido per runbook, vedere Panoramica dell'agente Log Analytics - TLS.

Aggiornare il protocollo TLS per i ruoli di lavoro ibridi e le chiamate webhook

Dal 1° marzo 2025, tutti i ruoli di lavoro ibridi per runbook basati su agenti ed estensioni, i webhook, i nodi DSC e i computer gestiti nella funzione di gestione aggiornamenti e nel Rilevamento modifiche, che utilizzano i protocolli TLS (Transport Layer Security) 1.0 e 1.1, non saranno più in grado di connettersi ad Automazione di Azure. Tutti i processi in esecuzione o pianificati nei ruoli di lavoro ibridi che usano protocolli TLS 1.0 e 1.1 avranno esito negativo.

Assicurarsi che le chiamate webhook che attivano i runbook utilizzino TLS 1.2 o superiore. Informazioni su come disabilitare i protocolli TLS 1.0/1.1 sul ruolo di lavoro ibrido di Windows e abilitare TLS 1.2 oppure versione superiore sulla macchina Windows.

Per i ruoli di lavoro ibridi Linux, eseguire lo script di Python seguente per eseguire l'aggiornamento al protocollo TLS più recente.

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

Indicazioni specifiche in base alla piattaforma

Conservazione dei dati

Quando si elimina una risorsa in Automazione di Azure, viene mantenuta per molti giorni a scopo di controllo prima della rimozione permanente. In tale periodo non sarà possibile visualizzare o usare la risorsa. Questi criteri sono applicabili anche alle risorse appartenenti a un account di Automazione eliminato. I criteri di conservazione sono applicabili a tutti gli utenti e non è attualmente possibile personalizzarli. Tuttavia, se è necessario conservare i dati per un periodo più lungo, è possibile inoltrare i dati dei processi di Automazione di Azure ai log di Monitoraggio di Azure.

La tabella seguente riepiloga i criteri di conservazione per diverse risorse.

¹Il runbook può essere recuperato entro la finestra di 30 giorni aprendo un ticket di supporto con il supporto di Microsoft Azure. Passare al sito supporto tecnico di Azure e selezionare Submit a support request.

Backup dei dati

Quando si elimina un account di Automazione in Azure, tutti gli oggetti nell'account vengono eliminati. Gli oggetti includono runbook, moduli, configurazioni, impostazioni, lavori e risorse. È possibile ripristinare un account di Automazione eliminato entro 30 giorni. È anche possibile usare le informazioni seguenti per eseguire il backup del contenuto dell’account di Automazione prima di eliminarlo:

Runbook

È possibile esportare i runbook in file di script usando il portale di Azure o il cmdlet Get-AzAutomationRunbookContent in Windows PowerShell. È possibile importare questi file di script in un altro account di Automazione, come descritto in Gestire i runbook in Automazione di Azure.

Moduli di integrazione

Non è possibile esportare moduli di integrazione da Automazione di Azure, ma devono essere resi disponibili all'esterno dell'account di Automazione.

Asset

Non è possibile esportare Automazione di Azure asset: certificati, connessioni, credenziali, pianificazioni e variabili. È invece possibile usare il portale di Azure e i cmdlet Azure per prendere nota dei dettagli di questi asset. Usare quindi questi dettagli per creare eventuali asset usati dai runbook importati in un altro account di Automazione.

Non è possibile recuperare il valore delle variabili crittografate o i campi password delle credenziali mediante i cmdlet. Se non si conoscono questi valori, è possibile recuperarli in un runbook. Per il recupero dei valori delle variabili, vedere Variable assets in Automazione di Azure.For retrieving variable values, see Variable assets in Automazione di Azure. Per ulteriori informazioni sul recupero dei valori delle credenziali, vedere Credential assets in Automazione di Azure.

Configurazioni DSC

È possibile esportare le configurazioni DSC in file di script usando il portale di Azure o il cmdlet Export-AzAutomationDscConfiguration in Windows PowerShell. È possibile importare e usare queste configurazioni in un altro account di Automazione.

Residenza dei dati

Specificare un'area durante la creazione di un account Automazione di Azure. I dati del servizio, ad esempio asset, configurazione, log, vengono archiviati in tale area e possono transitare o essere elaborati in altre aree all’interno della stessa area geografica. Questi endpoint globali sono necessari per offrire agli utenti finali un’esperienza ad alte prestazioni e bassa latenza indipendentemente dalla posizione. Solo per l'area brasile meridionale (Stato di San Paolo) della geografia brasile, dell'area Asia sud-orientale (Singapore) e dell'area Asia orientale (Hongkong) dell'area geografica Asia Pacifico, vengono archiviati Automazione di Azure dati nella stessa area per soddisfare i requisiti di residenza dei dati per queste aree.

Passaggi successivi

• Per informazioni sulle linee guida sulla sicurezza, vedere Security best practices in Automazione di Azure.
• Per altre informazioni sugli asset sicuri in Automazione di Azure, vedere Encryption of secure assets in Automazione di Azure.
• Per altre informazioni sulla replica geografica, vedere Creazione e uso della replica geografica attiva.