Management of Azure Automation data
This article contains several topics explaining how data is protected and secured in an Azure Automation environment.
TLS 1.2 for Azure Automation
To ensure the security of data in transit to Azure Automation, we strongly encourage you to configure the use of Transport Layer Security (TLS) 1.2. The following are a list of methods or clients that communicate over HTTPS to the Automation service:
Hybrid Runbook Workers, which include machines managed by Update Management and Change Tracking and Inventory.
Older versions of TLS/Secure Sockets Layer (SSL) have been found to be vulnerable and while they still currently work to allow backwards compatibility, they are not recommended. We do not recommend explicitly setting your agent to only use TLS 1.2 unless its necessary, as it can break platform level security features that allow you to automatically detect and take advantage of newer more secure protocols as they become available, such as TLS 1.3.
For information about TLS 1.2 support with the Log Analytics agent for Windows and Linux, which is a dependency for the Hybrid Runbook Worker role, see Log Analytics agent overview - TLS 1.2.
|Linux||Linux distributions tend to rely on OpenSSL for TLS 1.2 support.||Check the OpenSSL Changelog to confirm your version of OpenSSL is supported.|
|Windows 8.0 - 10||Supported, and enabled by default.||To confirm that you are still using the default settings.|
|Windows Server 2012 - 2016||Supported, and enabled by default.||To confirm that you are still using the default settings|
|Windows 7 SP1 and Windows Server 2008 R2 SP1||Supported, but not enabled by default.||See the Transport Layer Security (TLS) registry settings page for details on how to enable.|
When you delete a resource in Azure Automation, it's retained for many days for auditing purposes before permanent removal. You can't see or use the resource during this time. This policy also applies to resources that belong to a deleted Automation account. The retention policy applies to all users and currently can't be customized. However, if you need to keep data for a longer period, you can forward Azure Automation job data to Azure Monitor logs.
The following table summarizes the retention policy for different resources.
|Accounts||An account is permanently removed 30 days after a user deletes it.|
|Assets||An asset is permanently removed 30 days after a user deletes it, or 30 days after a user deletes an account that holds the asset. Assets include variables, schedules, credentials, certificates, Python 2 packages, and connections.|
|DSC Nodes||A DSC node is permanently removed 30 days after being unregistered from an Automation account using Azure portal or the Unregister-AzAutomationDscNode cmdlet in Windows PowerShell. A node is also permanently removed 30 days after a user deletes the account that holds the node.|
|Jobs||A job is deleted and permanently removed 30 days after modification, for example, after the job completes, is stopped, or is suspended.|
|Modules||A module is permanently removed 30 days after a user deletes it, or 30 days after a user deletes the account that holds the module.|
|Node Configurations/MOF Files||An old node configuration is permanently removed 30 days after a new node configuration is generated.|
|Node Reports||A node report is permanently removed 90 days after a new report is generated for that node.|
|Runbooks||A runbook is permanently removed 30 days after a user deletes the resource, or 30 days after a user deletes the account that holds the resource1.|
1The runbook can be recovered within the 30-day window by filing an Azure support incident with Microsoft Azure Support. Go to the Azure support site and select Submit a support request.
When you delete an Automation account in Azure, all objects in the account are deleted. The objects include runbooks, modules, configurations, settings, jobs, and assets. You can recover a deleted Automation account within 30 days. You can also use the following information to back up the contents of your Automation account before deleting it:
You can export your runbooks to script files using either the Azure portal or the Get-AzureAutomationRunbookDefinition cmdlet in Windows PowerShell. You can import these script files into another Automation account, as discussed in Manage runbooks in Azure Automation.
You can't export integration modules from Azure Automation, they have to be made available outside of the Automation account.
You can't export Azure Automation assets: certificates, connections, credentials, schedules, and variables. Instead, you can use the Azure portal and Azure cmdlets to note the details of these assets. Then use these details to create any assets that are used by runbooks that you import into another Automation account.
You can't retrieve the values for encrypted variables or the password fields of credentials using cmdlets. If you don't know these values, you can retrieve them in a runbook. For retrieving variable values, see Variable assets in Azure Automation. To find out more about retrieving credential values, see Credential assets in Azure Automation.
You can export your DSC configurations to script files using either the Azure portal or the Export-AzAutomationDscConfiguration cmdlet in Windows PowerShell. You can import and use these configurations in another Automation account.
You specify a region during the creation of an Azure Automation account. Service data such as assets, configuration, logs are stored in that region and may transit or be processed in other regions within the same geography. These global endpoints are necessary to provide end-users with a high-performance, low-latency experience regardless of location. Only for the Brazil South (Sao Paulo State) region of Brazil geography, Southeast Asia region (Singapore) and East Asia region (Hongkong) of the Asia Pacific geography, we store Azure Automation data in the same region to accommodate data-residency requirements for these regions.
- To learn about security guidelines, see Security best practices in Azure Automation.
- To learn more about secure assets in Azure Automation, see Encryption of secure assets in Azure Automation.
- To find out more about geo-replication, see Creating and using active geo-replication.
Submit and view feedback for