App IDs enables application-level rules to match an application or protocol across any port.

App IDs are preconfigured for common enterprise applications such as Microsoft Active Directory, WINS, Kerberos, GitHub, and MySQL, ss well as protocol-level rules – for instance, versions and cipher suites of Secure Sockets Layer/Transport Layer Security (SSL/TLS) and Common Internet File System/Server Message Block (CIFS/SMB).

The following figure shows a three-tier application micro-segmentation policy, independent of IP addresses and ports. The TLS version 1.2 protocol is enforced on the ingress web tier. HTTP traffic is allowed between the web tier and the application tier, and SQL traffic is allowed between the application tier and the DB tier. This policy is achieved independently of IP addresses and TCP ports, using an app ID.

Figure 2.32 – Port-independent application DFW rule enforcement

Application-based security rules increase policy simplicity and enhance security, as applications can be detected dynamically even when a non-standard application port is used.

FQDN filtering

Domain filtering can lower the attack surface by blocking applications from accessing problematic domains or unrequired domains.

Tip

You must set up a DFW DNS rule before creating an FQDN rule. VMware NSX uses DNS snooping to map the IP address and the FQDN.

As described in the following figure, customers can apply an FQDN rule as part of their DFW policies – for example, blocking Linux servers and certain legacy Windows OSs from accessing https://update.microsoft.com.

Figure 2.33 – FQDN filtering for Windows updates

FQDN filtering is useful for reducing the SDDC attack surface and blacklisting a known malicious domain.

Identity Firewall

Customers can use NSX Distributed Firewall with a user ID known as Identity Firewall to create Active Directory user-based Distributed Firewall (DFW) rules.

Integration between DFW and Active Directory allows the control of which user can access which app. DFW enforces rules based on the user ID at the source.

For instance, protecting Virtual Desktop Infrastructure (VDI) workloads allows only different users on shared infrastructure access to enterprise applications, based on their identity, as illustrated in the following figure:

Figure 2.34 – Identity Firewall access for a VDI user to a finance app, based on user identity

Additional advanced security capabilities are constantly added to the advanced security add-on.

Summary

In this chapter, we learned about the unique NSX architecture running over VMware Cloud on AWS, including security and firewall architecture, the roles of the CGW and MGW, and advanced security features such as micro-segmentation and IPS/IDS. We also looked at advanced networking architectures such as native AWS TGW integrations. With those lessons in hand, we can now move on to designing and implementing a scalable and secure deployment of applications in VMware Cloud.

In the next chapter, we will further explore add-on services, such as migrations with HCX, monitoring with vRLI, and Kubernetes with Tanzu services.