Security considerations for Azure Local with disconnected operations (preview)

This article explains the security considerations and compliance regulations for disconnected operations with Azure Local VMs enabled by Azure Arc. Learn how to protect your environment and meet regulatory standards when running Azure Local VMs disconnected.

Security and compliance overview

Azure Local with disconnected operations meets security and compliance needs by using a locked down virtual machine (VM) appliance that's accessible only through the following methods:

• Management Network Interface Card (NIC): Lets you run a limited set of commands for deployment and troubleshooting. It's secured with a customer-provided certificate during bootstrapping. For more information, see Plan your network for disconnected operations.
• External (Ingress) NIC: Exposed to users in your network. This network path is for tenants and services of the system. User authentication uses your identity provider and role-based access control. For more information, see Plan your identity for disconnected operations.

An Azure Local VM running disconnected operations uses these security features:

• Transport Layer Security (TLS) 1.2, TLS 1.3, Datagram Transport Layer Security (DTLS) 1.2, and signed Server Message Block (SMB) protocol encryption for all data in transit.
• Microsoft Defender guards against viruses and malware.
• Secure boot checks the integrity of boot components.
• Windows Defender Application Control lets only authorized code run in a disconnected operations VM appliance.

For more information about the security features for Azure Local, see Security features for Azure Local.

Data at rest encryption

By default, data volumes in the Azure Local disconnected operations VM appliance are encrypted with BitLocker using AES-XTS256 bit encryption. BitLocker recovery passwords (key protectors) stay in an internal secure secret store.

BitLocker recovery key retrieval

Azure Local with disconnected operations manages BitLocker recovery passwords for data at rest encryption. You don't need to provide them for regular operations or during system startup. However, support scenarios might require these passwords to bring the system online. Without these passwords, some support scenarios can cause data loss and require system redeployment.

Follow these steps to get your BitLocker recovery passwords:

1. Import the Azure.Local.DisconnectedOperations.psd1 module.

   # Import-Module (if not already done): 
   Import-Module "C:\azurelocal\OperationsModule\Azure.Local.DisconnectedOperations.psd1" -Force 
   

2. Set the context. The command requires a DisconnectedOperationsClientContext object as a parameter.

   $password = ConvertTo-SecureString "RETRACTED" -AsPlainText -Force 
   $context = Set-DisconnectedOperationsClientContext -ManagementEndpointClientCertificatePath "${env:localappdata}\AzureLocalOpModuleDev\certs\ManagementEndpoint\ManagementEndpointClientAuth.pfx" -ManagementEndpointClientCertificatePassword $password -ManagementEndpointIpAddress "169.254.53.25" 
   

3. Run Get-ApplianceBitLockerRecoveryKeys against the management endpoint.

   $recoveryKeys = Get-ApplianceBitlockerRecoveryKeys $context 
   $recoveryKeys.recoverykeyset 
   

   Here's an example of the output:

   protectorid                             recoverypassword  
   -----------                             ----------------  
   {DCA51B1F-F694-439E-BC8D-63AC83F956F9}  1141015-055275-382305-1911114-363957-150975-55  
   {264FB985-6E36-466F-94DD-2F2D8328C9F8}  186516-209792-097229-117040-638286-147048-26  
   {CABBDD12-1EDE-4C4D-9985-326F77490E60}  510950-025762-385451-679074-429990-493845-49  
   {067ECC8D-DD78-133E-9886-FA2DC695F6C3}  177397-082045-290301-199375-309676-673838-67  
   {9C658F04-83A8-496D-9107-DE6ECC770E82}  653796-380369-402963-237864-1486629-485254-00  
   {8F84B18A-670E-4B3E-A194-0C6ABA022083}  604494-676940-630740-390940-155859-514789-56  
   

4. Get your BitLocker recovery passwords and store them in a secure ___location outside Azure Local or the Azure Local host.

If your system is experiencing BitLocker issues, like Azure Local with disconnected operations failing to start, contact support and provide your BitLocker recovery passwords.

Manually unlock the virtual hard drive or virtual storage disk using BitLocker recovery passwords. If BitLocker recovery keys aren't available, you need to redeploy the disconnected operations VM appliance.

Export Host Guardian Service certificates

This procedure isn’t supported in the preview release.

To back up Host Guardian Service certificates from your cluster, run these commands from your seed node:

1. Set the context. The command requires a DisconnectedOperationsClientContext object as a parameter.

   $password = ConvertTo-SecureString "RETRACTED" -AsPlainText -Force 
   $context = Set-DisconnectedOperationsClientContext -ManagementEndpointClientCertificatePath "${env:localappdata}\AzureLocalOpModuleDev\certs\ManagementEndpoint\ManagementEndpointClientAuth.pfx" -ManagementEndpointClientCertificatePassword $password -ManagementEndpointIpAddress "169.254.53.25" 
   

2. To export the Host Guardian Service certificates to a specific path, run Export-ApplianceHGSCertificates.

   Export-ApplianceHGSCertificates -Path C:\AzureLocalDisconnectedOperations\HGSBackup    
   

Configure syslog forwarding

You can use the syslog protocol for Azure Local with disconnected operations VM appliance to forward security events to a customer-managed security information and event management (SIEM) system.

The syslog agent of the disconnected operations VM appliance forwards security events in syslog format from the Azure Local VM to the customer-configured syslog server.

To set up syslog forwarding, sign in to the physical host with a ___domain admin account. Use GET and PUT HTTP commands to check or change the syslog forwarding configuration. The following PowerShell scripts show how to control the syslog forwarder from Azure Local hosts. You can also use any REST client.

For details about setting up syslog forwarding for the Azure Local host, see Manage syslog forwarding for Azure Local.

Syslog forwarding parameters

The following table provides the parameters for the REST endpoint:

Configure syslog forwarding with TCP, server authentication, and TLS encryption

In this configuration, the syslog forwarder in Azure Local forwards the messages to the syslog server over TCP with TLS encryption. During the initial handshake, the client also verifies that the server provides a valid, trusted certificate.

This configuration prevents the client from sending messages to untrusted destinations. By default, TCP with authentication and encryption is used, which is the minimum level of security recommended for production. Don't use the -SkipServerCertificateCheck flag in production environments.

To enable syslog forwarding with TCP, server authentication, and TLS encryption, prepare a configuration request in PowerShell with the following values:

$configRequestContent = @{
    Enabled = $true
    ServerName = "<FQDN or IP address of syslog server>"
    ServerPort = "<port number of the syslog server, e.g., 514>"
}

To test integration with a self-signed or untrusted certificate, use these flags to skip server validation during the initial handshake.

• Skip validation of the Common Name value in the server certificate. Use this flag if you enter an IP address for your syslog server.

$configRequestContent = @{
    ...
    SkipServerCNCheck = $true
}  

• Skip server certificate validation. Use this flag if you use a self-signed certificate for your syslog server.

$configRequestContent = @{
    ...  
    SkipServerCertificateCheck = $true
}  

Configure syslog forwarding with TCP and no encryption

In this configuration, the syslog client in Azure Local forwards messages to the syslog server over TCP with no encryption. The client doesn't verify the server's identity or provide its own identity for verification. Don't use this configuration in production environments.

To enable syslog forwarding with TCP and no encryption, prepare a configuration request in PowerShell with the following values:

$configRequestContent = @{
    Enabled = $true
    ServerName = "<FQDN or IP address of syslog server>"
    ServerPort = "<port number of the syslog server, e.g., 514>"
    NoEncryption = $true
}

Configure syslog forwarding with UDP and no encryption

In this configuration, the syslog client in Azure Local forwards messages to the syslog server over UDP with no encryption. The client doesn't verify the server's identity or provide its own identity for verification. Don't use this configuration in production environments.

To enable syslog forwarding with UDP and no encryption, prepare a configuration request in PowerShell with the following values:

$configRequestContent = @{
    Enabled = $true
    ServerName = "<FQDN or IP address of syslog server>"
    ServerPort = "<port number of the syslog server, e.g., 514>"
    UseUDP = $true
}

UDP with no encryption is the easiest to set up, but it doesn't protect against man-in-the-middle attacks or eavesdropping.

Manage syslog forwarding

Disable syslog forwarding

To disable syslog forwarding, run this cmdlet:

$configRequestContent = @{
    Enabled = $false
    ServerName = "<FQDN or IP address of syslog server>"
    ServerPort = "<port number of the syslog server, e.g., 514>"
}

Syslog setup update

After you define the configuration, send the configuration request by running this PowerShell script:

$IRVMIP = "<Azure Local VM management endpoint IP address>"
$clientCertPath = "<path to client certificate pfx file for management endpoint>"
$clientCertPassword = "<client certificate password>"

$syslogConfigurationEndpoint = "https://$IRVMIP`:9443/sysconfig/SyslogConfiguration"
$clientCert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($clientCertPath, $clientCertPassword)

$requestBody = $configRequestContent | ConvertTo-Json

Invoke-RestMethod -Certificate $clientCert -Uri $syslogConfigurationEndpoint -Method Put -Body $requestBody -ContentType "application/json" -Verbose

Syslog setup verification

After you connect the syslog client to your syslog server, you start to receive event notifications. If you don't see notifications, check your cluster syslog forwarder configuration by running this cmdlet:

$IRVMIP = "<Azure Local VM management endpoint IP address>"
$clientCertPath = "<path to client certificate pfx file for management endpoint>"
$clientCertPassword = "<client certificate password>"

$syslogConfigurationEndpoint = "https://$IRVMIP`:9443/sysconfig/SyslogConfiguration"
$clientCert = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new($clientCertPath, $clientCertPassword)

Invoke-RestMethod -Certificate $clientCert -Uri $syslogConfigurationEndpoint -Method Get -ContentType "application/json" -Verbose

If a setting property isn't configured, you see its default value when you retrieve the current configuration.

Reference: Message schema and event log

This section describes the syslog message schema and event definitions.

Syslog message schema

The syslog forwarder in Azure Local infrastructure sends messages formatted using the Berkeley Software Distribution (BSD) syslog protocol defined in RFC3164. The syslog message payload uses the Common Event Format (CEF).

Each syslog message uses this schema:

Priority (PRI) | Time | Host | CEF payload |

The PRI part has two values: facility and severity. Both values depend on the message type, like Windows Event.

Common event format payload schema/definitions

The CEF payload uses the following structure. Field mapping varies depending on the message type, like Windows Event.

CEF: |Version | Device Vendor | Device Product | Device Version | Signature ID | Name | Severity | Extensions |

• Version: 0.0
• Device Vendor: Microsoft
• Device Product: Microsoft Azure Local
• Device Version: 1.0

Windows event mapping and examples

All Windows events use the PRI facility value of 10.

• Signature ID: ProviderName:EventID
• Name: TaskName
• Severity: Level. For details, see the following severity table.
• Extension: Custom Extension Name. For details, see the following table.

Severity of windows events

Custom extensions and Windows events in Azure Local

Miscellaneous events

This section lists miscellaneous events that are forwarded. You can't customize these events.

This feature is available only in Azure Local 2506.