Compartir vía

Administración de datos de Azure Automation

  • Artículo

Este artículo contiene varios temas que explican cómo se protegen y aseguran los datos en un entorno de Azure Automation.

TLS para Azure Automation

Para garantizar la seguridad de los datos en tránsito hacia Azure Automation, se recomienda encarecidamente configurar el uso de Seguridad de la capa de transporte (TLS) 1.2. A continuación se muestra una lista de métodos o clientes que se comunican a través de HTTPS con el servicio Automation:

  • Llamadas de webhook

  • Hybrid Runbook Workers de usuario (basado en extensiones y basado en agente)

  • Máquinas administradas por Azure Automation Update Management y Seguimiento de cambios e inventario de Azure Automation

  • DSC de Automatización de Azure

Las versiones anteriores de TLS/Capa de sockets seguros (SSL) han demostrado ser vulnerables y, si bien todavía funcionan para permitir la compatibilidad con versiones anteriores, no se recomiendan. No se recomienda establecer explícitamente el agente para que solo use TLS 1.2, a menos que sea necesario, ya que esto puede interrumpir las características de seguridad a nivel de la plataforma que le permiten detectar y aprovechar automáticamente las ventajas de los protocolos más seguros más recientes a medida que estén disponibles, como TLS 1.3.

Para obtener información sobre la compatibilidad de TLS con el agente de Log Analytics para Windows y Linux, que es una dependencia del rol de Hybrid Runbook Worker, consulte la introducción del agente de Log Analytics: TLS.

Actualización del protocolo TLS para las llamadas a instancias de Hybrid Worker y Webhook

Desde el 31 de octubre de 2024, todos los Runbook Híbridos de usuario basados en agente y basados en extensiones, Webhooks, nodos DSC y máquinas administradas de Azure Automation Update Management y Change Tracking, mediante protocolos de seguridad de la capa de transporte (TLS) 1.0 y 1.1 ya no podrían conectarse a Azure Automation. Se producirá un error en todos los trabajos que se ejecutan o programan en instancias de Hybrid Worker que usan los protocolos TLS 1.0 y 1.1.

Asegúrese de que las llamadas a Webhook que desencadenan runbooks navegan por TLS 1.2 o posterior. Obtenga información sobre cómo deshabilitar los protocolos TLS 1.0/1.1 en Windows Hybrid Worker y habilitar TLS 1.2 o superior en una máquina Windows.

Para instancias de Linux Hybrid Worker, ejecute el siguiente script de Python para actualizar al protocolo TLS más reciente.

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

Guía específica para la plataforma

Plataforma/lenguaje Soporte técnico Más información
Linux Las distribuciones de Linux tienden a basarse en OpenSSL para la compatibilidad con TLS 1.2. Compruebe el registro de cambios de OpenSSL para confirmar si su versión de OpenSSL es compatible.
Windows 8.0 a 10 Compatible y habilitado de manera predeterminada. Para confirmar que aún usa la configuración predeterminada.
Windows Server 2012 a 2016 Compatible y habilitado de manera predeterminada. Para confirmar que aún usa la configuración predeterminada
Windows 7 SP1 y Windows Server 2008 R2 SP1 Compatible, pero no habilitado de manera predeterminada. Consulte la página Configuración del registro de TLS para obtener más información sobre cómo se habilita.

Retención de datos

Cuando elimina un recurso en Azure Automation, se conserva durante muchos días con fines de auditoría antes de su eliminación definitiva. Durante este tiempo, no es posible ver ni usar el recurso. Esta directiva también se aplica a los recursos que pertenecen a una cuenta de Automation eliminada. La directiva de retención se aplica a todos los usuarios y, por el momento, no se puede personalizar. Sin embargo, si tiene que conservar los datos durante un periodo de tiempo mayor, puede reenviar los datos de trabajos de Azure Automation a los registros de Azure Monitor.

La tabla siguiente resume la directiva de retención para distintos recursos.

Data Directiva
Cuentas Una cuenta se elimina de manera permanente 30 días después de que un usuario la elimine.
Activos Un recurso se elimina de forma permanente 30 días después de que un usuario lo elimina o 30 días después de que un usuario elimina la cuenta que contiene el recurso. Los recursos incluyen variables, programaciones, credenciales, certificados, paquetes de Python 2 y conexiones.
Nodos de DSC Un nodo de DSC se elimina de forma permanente 30 días después de que se anula el registro del nodo de la cuenta de Automation mediante Azure Portal o el cmdlet Unregister-AzAutomationDscNode de Windows PowerShell. Los nodos también se eliminan de forma permanente 30 días después de que el usuario elimine la cuenta que contiene el nodo.
Trabajos Un trabajo se elimina de forma permanente 30 días después de cualquier modificación, por ejemplo, después de que el trabajo se complete, detenga o suspenda.
Módulos Un módulo se elimina de forma permanente 30 días después de que un usuario lo elimina o 30 días después de que un usuario elimina la cuenta que contiene el módulo.
Configuraciones de nodo y archivos MOF La configuración de nodo anterior se elimina de forma permanente 30 días después de que se genere una nueva configuración.
Informes de nodo Un informe de nodo se elimina de forma permanente 90 días después de que se genere un nuevo informe para ese nodo.
Runbooks Un runbook se elimina de forma permanente 30 días después de que un usuario lo elimina o 30 días después de que un usuario elimina la cuenta que contiene el recurso1.

1El runbook se puede recuperar en un período de 30 días mediante la presentación de un incidente de Soporte técnico de Azure en el soporte técnico de Microsoft Azure. Vaya al sitio de Soporte técnico de Azure y seleccione Submit a support request (Enviar una solicitud de soporte técnico).

Copia de seguridad de datos

Cuando elimina una cuenta de Automation en Azure, se eliminan todos los objetos de esa cuenta. Entre los objetos se incluyen runbooks, módulos, configuraciones, valores, trabajos y recursos. Puede recuperar una cuenta de Automation eliminada en un plazo de 30 días. También puede usar la información siguiente para crear una copia de seguridad de los contenidos de la cuenta de Automation antes de eliminarla:

Runbooks

Puede exportar los runbooks a archivos de script con Azure Portal o el cmdlet Get-AzureAutomationRunbookDefinition en Windows PowerShell. Puede importar estos archivos de script en otra cuenta de Automation, como se indica en Administración de runbooks en Azure Automation.

Módulos de integración

Los módulos de integración no se pueden exportar desde Azure Automation, tienen que estar disponibles fuera de la cuenta de Automation.

Activos

No se pueden exportar recursos de Azure Automation: certificados, conexiones, credenciales, programaciones y variables. En su lugar, puede usar los cmdlets de Azure Portal y de Azure para anotar los detalles de estos recursos. Posteriormente, puede usar esos detalles para crear todos los recursos utilizados por los runbooks que importe a otra cuenta de Automation.

No es posible recuperar el valor de variables cifradas o del campo de contraseña de las credenciales mediante cmdlets. Si no conoce estos valores, puede recuperarlos en un runbook. Para recuperar valores de variables, consulte Recursos de variables en Azure Automation. Para más información sobre cómo recuperar valores de credenciales, consulte Recursos de credenciales en Azure Automation.

Configuraciones DSC

Puede exportar las configuraciones de DSC a archivos de script con Azure Portal o con el cmdlet Export-AzAutomationDscConfiguration en Windows PowerShell. Puede importar y usar estas configuraciones en otra cuenta de Automation.

Residencia de datos

Especifique una región durante la creación de una cuenta de Azure Automation. Los datos de servicio, como los recursos, la configuración y los registros, se almacenan en esa región y pueden transitar o procesarse en otras regiones dentro de la misma geografía. Estos puntos de conexión globales son necesarios para proporcionar una experiencia de alto rendimiento y baja latencia a los usuarios finales, independientemente de su ubicación. Solo para la región Sur de Brasil (estado de Sao Paulo) del área geográfica de Brasil, la región Sudeste Asiático (Singapur) y la región Este de Asia (Hong Kong) del área geográfica de Asia Pacífico, almacenamos los datos de Azure Automation en la misma región para cumplir con los requisitos de residencia de datos de estas regiones.

Pasos siguientes