If you have connected your non-Azure Servers with Azure Arc, and you can now see them via the Azure portal and other management tools (like Azure PowerShell), a good next step is to apply some Azure Policies to them. This lets you see if they meet the configuration requirements that are important to your organization, and you can apply some policies to all of your servers - regardless of whether they are in Azure or not.
Here are some of the things to watch out for, for both individual policies and policy initiatives (a collection of more than one policy, which can be tracked as a whole).
Microsoft Azure has a large number of built-in definitions, that are published and updated by Microsoft. Some are resource type-specific, so check the Policy Category. This applies to individual policy definitions and to policy initiative definitions:
Azure Policy Definitions showing Category list
Logically, an Azure Key Vault policy won't be relevant to an Arc-enabled Server, for example.
The Guest Configuration category includes policies and initiatives that can check inside the operating system of a virtual machine.
Policies relevant to Arc-enabled servers include: [Preview] Windows machines should meet requirements for the Azure compute security baseline Audit Linux machines that do not have the passwd file permissions set to 0644 Audit Windows VMs with a pending reboot Windows web servers should be configured to use secure communications protocols
The Azure Arc category contains policies for defining the configuration of Azure Arc Private Link Scopes. Azure Private Link Scopes allow groups of Azure Arc-enabled Servers to connect to Azure services through private IP addresses, not public IP endpoints, and use a single private endpoint.
These include: Azure Arc Private Link Scopes should disable public network access Azure Arc-enabled servers should be configured with an Azure Arc Private Link Scope
This blog is not designed to be a definitive or exhaustive list, and you'll find applicable policies and initiatives in other categories too. For example, some of the definitions under the Regulatory Compliance category can apply to Arc-enabled servers - the NIST SP 800-53 REV.4 policy initiative will show non-compliant resources that are Azure virtual machines, VMware vSphere Virtual machines or Azure Arc-enabled servers:
Azure Policy showing virtual machines that are non-compliant with NIST
And you'll find policies like [Preview] Azure Security agent should be installed on your Windows Arc machines, under the Security Center category and [Preview] Log Analytics extension should be installed on your Linux Azure Arc machines, under the Monitoring category.
Checking Azure Policy definitions and assigning an Azure Policy
How can you tell if a policy would apply to an Azure Arc-enabled server or not? If Arc is not mentioned in the policy name, you can check the JSON of the policy definition for the Microsoft.HybridCompute/machines resource type:
Windows web servers secure communication protocols policy definition JSON showing Microsoft.HybridCompute/machines resource type
In the example above, the policy would exclude Arc-enabled servers by default, unless you set a parameter to include the Arc-enabled servers resource type. This is set when you assign the policy to a scope:
Include Arc connected servers when you assign an Azure Policy may be set to false by default
Note: Depending on the policy, sometimes this parameter is not shown if "Only show parameter that need input or review" is checked. Uncheck it to see all available parameters for the policy.
There's not a defined set of best practices for policies for your Arc-enabled Servers - just think of them like any other Windows or Linux server you would set some configuration requirements for and go from there.