Security, governance, and compliance

In this section, we will talk about how to make sure that AVS is safe to use and that you can manage it from start to finish. We will look at some specific design elements and give specific advice for the security, governance, and compliance of your AVS.

Security

It is important to make sure that you have your security components planned out before you deploy any solution in Azure. AVS is no exception. In the following, we will look at some of the key factors to consider:

• Limits on permanent access: In the Azure resource group that hosts the AVS private cloud, the Contributor role is used. This role is used by the AVS service. To keep contributor rights from being misused, limit permanent access. Using a privileged account management tool can help you keep track of and limit how long highly privileged accounts are used.
• Centralized identity management: AVS gives cloud administrators and network administrators credentials that can be used to set up the VMware environment. They are visible to everyone who has RBAC access to the AVS.

If you want to restrict built-in cloudadmin and network administrator users’ access to the VMware control plane, use the control plane RBAC features to properly control role and account access. Using least-privilege principles, make a lot of targeted identity objects such as users and groups. Limit access to the administrator accounts provided by AVS and set them up in a break-glass configuration. If you can’t use any other administrative account, use the built-in account instead.

Use the Cloudadmin account to connect Azure AD DS with the VMware vCenter and NSX-T control applications and the administrative identities for the domain services that are part of the cloud. Use users and groups from your domain to manage and operate your AVS. Don’t share your account. Customize vCenter roles and link them to AD DS groups so that you can control access to VMware control surfaces with fine-grained privilege level control, such as who can see what.

There are options in AVS that you can use to change and reset passwords for vCenter and NSX-T administrators. When you use the break-glass configuration, set up a regular rotation of these accounts, and rotate the accounts when you do.

Governance

Consider following these suggestions when you plan for an environment and guest VM governance:

• Storage space on your vSAN: You need to have sufficient free space on your vSAN to maintain your VMware Service-Level Agreement (SLA). A minimum of 25 percent free space on your vSAN is required by VMware.
• Host quota: If there are not enough host quotas, there could be delays of up to 7 days before you get more space for growth or DR. Make sure to think about growth and DR when you ask for the host quota, and check the environment’s growth and maximums on a regular basis to make sure there is enough time for expansion requests. Suppose a three-node AVS cluster needs three more nodes for DR If you need six nodes, ask for six hosts instead of just the primary three nodes. It doesn’t cost extra if you ask for a host quota.
• Access to the ESXi: There is limited access to the ESXi hosts. Some third-party software that needs access to the ESXi host might not work. Identify any AVS-supported third-party software in the source environment that needs access to the ESXi host from AVS. Make sure you know how to use the AVS support request process in the Azure portal when you need to get into the ESXi host.

Compliance

There are many recommendations for compliance when planning your AVS environment. A few of these recommendations are listed as follows:

• Monitoring
• Backup
• Country and/or industry regulatory compliance
• Data retention
• Corporate policies

Let us look at compliance in more detail:

• Microsoft Defender for Cloud monitoring: When you use Defender for Cloud, you can use the regulatory compliance view to make sure that you are meeting the required security and regulatory standards. Defender for Cloud workflow automation can be set up to keep an eye on how well you’re doing in terms of deviation from the required compliance policies.
• Workload VM backup compliance: Ensure your AVS guest VMs are being backed up. We mentioned earlier the importance of backing up your AVS in case of a disaster.
• Country- or industry-specific regulatory compliance: If you want to avoid costly legal action or fines, make sure your guest workloads for AVS follow local and industry-specific regulations. It’s important to know how the cloud-shared responsibility model works for different industrial or regional regulatory compliance.
• Data retention and residency requirements: AVS doesn’t allow you to keep or get data from clusters that are stored on the cloud. This means that when you delete a cluster, it stops all running workloads and components and also destroys all the cluster’s data and settings, such as public IP addresses. You will not be able to recover the deleted data.
• Corporate policy compliance: Keep an eye on the guest workloads in AVS to make sure they don’t break company rules and regulations. Use solutions such as Azure Arc-enabled servers and Azure Policy, or a similar third-party solution. Routinely check and manage AVS guest VMs and applications to make sure they meet the required internal and external regulations.