1. User accounts control access, and the web console allows you to set the authentication method (see Configuring Authentication).
2. Nutanix uses SSL to secure communication with a cluster, and the web console allows you to install SSL certificates (see Installing an SSL Certificate).
3. Nutanix supports key-based SSH access to a cluster, but you have the option to disable such access (see Cluster Lockdown).
4. Nutanix provides an option to configure the cluster for enhanced data-at-rest security through the use of self-encrypting drives (see Data-at-Rest Encryption).

Security Policies

Nutanix Flow includes a policy-driven security framework that inspects traffic within the data center. The framework works as follows:

• Security policies inspect traffic that originates and terminates within a data center and help eliminate the need for additional firewalls within the data center.
• The framework uses a workload-centric approach instead of a network-centric approach. Therefore, it can scrutinize traffic to and from VMs no matter how their network configurations change and where they reside in the data center. The workload-centric, network-agnostic approach also enables the virtualization team to implement these security policies without having to rely on network security teams.
• Security policies are applied to categories (a logical grouping of VMs) and not to the VMs themselves. Therefore, it does not matter how many VMs are started up in a given category. Traffic associated with the VMs in a category is secured without administrative intervention, at any scale.
• Prism Central offers a visualization-based approach to configuring policies and monitoring the traffic to which a given policy applies.

Types of Policies

Policy Type	Use Case
Application Security Policy	Use an application security policy when you want to secure an application by specifying allowed traffic sources and destinations. This method of securing an application is typically called application ring fencing. For example, use an application security policy when you want to allow only those VMs in the categories department: engineering and department: customersupport (the whitelisted sources) to communicate with an issue tracking tool in the category AppType: IssueTracker (the secured application), and you want the issue tracking tool to be able to send traffic only to an integrated customer relationship management application in the category AppType: CRM. The secured application itself can be divided into tiers by the use of categories (the built-in AppTier category). For example, you can divide the issue tracking tool into web, application, and database tiers and configure tier-to-tier rules.
Isolation Environment Policy	Use an isolation environment policy when you want to block all traffic, regardless of direction, between two groups of VMs identified by their category. VMs within a group can communicate with each other. For example, use an isolation environment policy when you want to block all traffic between VMs in the category Environment: sandbox and VMs in the category Environment: production, and you want to allow all the VMs within each of those categories to communicate with each other.
Quarantine Policy	Use a quarantine policy when you want to isolate a compromised or infected VM and optionally want to subject it to forensics.

Security Policy Model

Application-centricity

The security policy model uses an application-centric policy language instead of the more complex, traditional network-centric policy language. Configuring an application security policy involves specifying which VMs belong to the application you want to protect and then identifying the entities or networks, in the inbound and outbound directions, with which you want to allow communication.

All the entities in an application security policy are identified by the categories to which they belong and not by their IP address, VLAN, or other network attributes. After a VM is associated with a category and the category is specified in a security policy, traffic associated with the VM is monitored even if it migrates to another network or changes its IP address.

The default options for allowing traffic on the inbound and outbound directions are also inherently application centric. For application security policies, the default option for inbound traffic is a whitelist, which means that a whitelist is usually the recommended option for inbound traffic. The default option can be changed to allow all traffic. The default option in the outbound direction allows the application to send traffic to all destinations, but you can configure a destination whitelist if desired.

For forensic quarantine policies, the default option in both directions is a whitelist, but you can allow all traffic in both directions. For strict quarantine policies, no traffic is allowed in either direction.

All the VMs within a category can communicate with each other. For example, in a tiered application, regardless of how you configure tier-to-tier rules, the VMs within a given tier can communicate with each other.

Whitelist-Based Policy Expression

An application security policy is expressed in terms of the categories and subnets with which you want the application to communicate and therefore, by extension, the traffic you want to allow. A more granular policy expression can be achieved by specifying which protocols and ports can be used for communication.

Any category or subnet that is not in the allowed list (the whitelist) is blocked. You cannot specify the categories and subnets you want to block because the number of such entities are typically much larger and grow at a much higher rate than the categories and subnets with which an application should be allowed to communicate. Expressing a policy in terms of allowed traffic results in a smaller, tighter policy configuration that can be modified, monitored, and controlled more easily.

Enforcement Modes

All policies, whether associated with securing an application, isolating environments, or quarantining VMs, can be run in the following modes:Apply ModeBlocks all traffic that is not allowed by the policy.Monitor ModeAllows all traffic, including traffic that is not allowed by the policy. This mode enables you to visualize both allowed and disallowed traffic and fine-tune the policy before applying it.

You can switch a policy between these two modes as many times as you want.

Automated Enforcement

A policy uses categories to identify the VMs to which it must apply. This model allows the automatic enforcement of a policy to VMs regardless of their number and network attributes. Connectivity between Prism Central and a registered AHV cluster is required only when creating and modifying policies, or when changing the mode of operation (applied or monitoring) of a policy. Policies are applied to the VMs in a cluster even if the cluster temporarily loses network connectivity with the Prism Central instance with which it is registered. New policies and changes are applied to the cluster when connectivity is restored.

Priorities Between Policies

Prism Central does not provide a way for you to specify priorities between policies of a single type. For example, you cannot prioritize one security policy over another. There is no limit to the number of inbound and outbound rules that you can add to a security policy, allowing you to define all of an application’s security requirements in a single policy. This makes priorities between policies unnecessary.

However, priorities exist between the different policy types. Quarantine policies have the highest priority followed by isolation environment policies and application security policies, in that order.

Isolation environment rules take precedence over application security rules, so make sure that isolation environment policies and application security policies are not in conflict. An isolation environment rule and an application security rule are said to be in conflict if they apply to the same traffic (a scenario that is encountered when VMs in one of the categories in the isolation environment send traffic to an application in the other category, and some or all of that traffic is either whitelisted or disallowed by the application security policy). The effect that an isolation environment policy has on a conflicting application security policy depends on the mode in which the isolation environment policy is deployed, and is as follows:

• If the isolation environment policy is in the applied mode, it blocks all traffic to the application, including the traffic that is whitelisted by the application security policy.
• If the isolation environment policy is in the monitoring mode, it allows all traffic to the application, including any traffic that is disallowed by the application security policy.