Condividi tramite

Gestione dei dati di Automazione di Azure

  • Articolo

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

TLS per Automazione di Azure

Per garantire la sicurezza dei dati in transito in 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 ibridi per runbook utente (basati su estensione e basati su agente)

  • Computer gestiti da Gestione aggiornamenti e Rilevamento modifiche e inventario di Automazione di Azure

  • Nodi DSC (Desired State Configuration) di Automazione di Azure

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 di Log Analytics per Windows e Linux, che è una dipendenza per il ruolo di lavoro ibrido per runbook, vedere Panoramica dell’agente di Log Analytics - TLS.

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

Dal 31 ottobre 2024, tutti i ruoli di lavoro ibridi per runbook utente basati su agenti ed estensioni, i webhook, i nodi DSC e i computer gestiti da Gestione aggiornamenti e Rilevamento modifiche di Automazione di Azure che usano i protocolli TLS 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 si spostino su TLS 1.2 o versione successiva. Informazioni su come disabilitare i protocolli TLS 1.0/1.1 nel ruolo di lavoro ibrido di Windows e abilitare TLS 1.2 o versione successiva nel computer Windows.

Per i ruoli di lavoro ibridi di Linux, eseguire lo script 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

Piattaforma/linguaggio Supporto tecnico Ulteriori informazioni
Linux Le distribuzioni Linux si basano generalmente su OpenSSL per supportare TLS 1.2. Controllare nel log delle modifiche di OpenSSL per assicurarsi che la versione di OpenSSL sia supportata.
Windows 8.0 - 10 Supportato e abilitato per impostazione predefinita. Assicurarsi che le impostazioni predefinite siano ancora in uso.
Windows Server 2012 - 2016 Supportato e abilitato per impostazione predefinita. Assicurarsi che le impostazioni predefinite siano ancora in uso
Windows 7 SP1 e Windows Server 2008 R2 SP1 Supportato ma non abilitato per impostazione predefinita. Vedere la pagina Transport Layer Security (TLS) registry settings (Impostazioni del Registro di sistema di Transport Layer Security (TLS)) per informazioni dettagliate su come eseguire l'abilitazione.

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. Se tuttavia è necessario conservare i dati per un periodo di tempo più lungo, è possibile inviare 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.

Dati Criteri
Account Un account viene rimosso definitivamente 30 giorni dopo l'eliminazione da parte di un utente.
Asset Un asset viene rimosso definitivamente 30 giorni dopo l'eliminazione da parte di un utente o 30 giorni dopo l'eliminazione di un account che possiede l'asset. Gli asset includono variabili, pianificazioni, credenziali, certificati, pacchetti Python 2 e connessioni.
Nodi DSC Un nodo DSC viene rimosso in modo permanente 30 giorni dopo l'annullamento della registrazione dall'account di Automazione tramite il portale di Azure o il cmdlet Unregister-AzAutomationDscNode in Windows PowerShell. I nodi vengono rimossi in modo permanente anche 30 giorni dopo aver eliminato l'account che possiede il nodo.
Processi Un processo viene eliminato e rimosso definitivamente 30 giorni dopo la modifica, ad esempio dopo il completamento, l'arresto o la sospensione del processo.
moduli Un modulo viene rimosso definitivamente 30 giorni dopo l'eliminazione da parte di un utente o 30 giorni dopo l'eliminazione di un account che possiede il modulo.
Configurazioni di nodo/File MOF Una configurazione di nodo precedente verrà rimossa definitivamente 30 giorni dopo che viene generata una nuova configurazione di nodo.
Report sul nodo Un report sul nodo viene rimosso definitivamente 90 giorni dopo la generazione di un nuovo report per quel nodo.
Runbook Un runbook viene rimosso definitivamente 30 giorni dopo che un utente elimina la risorsa o 30 giorni dopo che un utente elimina l’account che contiene la risorsa1.

1Il runbook può essere recuperato entro la finestra di 30 giorni inviando un evento di supporto tecnico di Azure con il supporto di Microsoft Azure. Passare al sito di supporto tecnico di Azure e selezionare Invia una richiesta di supporto.

Backup dei dati

Quando si elimina un account di automazione in Azure, vengono eliminati tutti gli oggetti presenti nell'account. Gli oggetti includono runbook, moduli, configurazioni, impostazioni, processi e asset. È 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-AzureAutomationRunbookDefinition in Windows PowerShell. È possibile importare questi file di script in un altro account di Automazione, come illustrato in Gestire 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 gli asset di Automazione di Azure: certificati, connessioni, credenziali, pianificazioni e variabili. È invece possibile usare il portale di Azure e i cmdlet di 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 recuperare i valori delle variabili, vedere Asset di tipo variabile in Automazione di Azure. Per altre informazioni sul recupero dei valori delle credenziali, vedere Asset credenziali in Automazione di Azure.

Configurazioni DSC

È possibile esportare le configurazioni DSC in file di script tramite 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

Si specifica un’area durante la creazione di un account di 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) dell’area geografica del Brasile, Asia sud-orientale (Singapore) e Asia orientale (Hongkong) dell’area geografica Asia Pacifico. I dati di Automazione di Azure vengono archiviati nella stessa area per soddisfare i requisiti di residenza dei dati per queste aree.

Passaggi successivi