Nutanix NCP-NS key terms

A security model that grants no implicit trust based on network location; every request is authenticated, authorized, and continuously evaluated. Nutanix applies it through segmentation, strong identity integration, and tightly scoped permissions.

The practice of granting each user, service, or workload only the permissions it needs to do its job and nothing more, which shrinks the damage possible if an account or credential is compromised.

A cloud-delivered service that continuously assesses Prism Central-managed environments for misconfigurations, missing patches, and compliance gaps, then reports findings with remediation guidance for each cluster.

A consensus-developed hardening baseline from the Center for Internet Security containing specific, testable configuration checks for AOS and Prism. Teams use it to measure a cluster against an industry standard and track drift.

Security Technical Implementation Guides published by the U.S. Defense Information Systems Agency. They are prescriptive hardening settings, and Nutanix publishes STIG guidance so clusters can be configured to meet Department of Defense requirements.

Connecting Prism Central or Prism Element to Active Directory or an LDAP directory so that existing directory users and groups can authenticate and receive Nutanix roles instead of relying on separate local accounts.

An XML-based federation standard that lets Prism Central delegate sign-in to an external identity provider, so users authenticate once with corporate credentials and are redirected back with a signed assertion describing who they are.

The trusted service that authenticates users and issues identity assertions, such as Microsoft Entra ID, ADFS, or Okta. In a Nutanix single sign-on deployment it holds the credentials and group memberships.

In SAML federation, the application that receives and trusts assertions from the identity provider. Prism Central acts in this role when single sign-on is configured for the cluster.

An access model where permissions are bundled into roles, roles are assigned to users or groups, and every request is checked against those assignments rather than granting permissions to individuals object by object.

The configuration that ties an identity, such as a directory user, a directory group, or an identity provider group attribute, to a specific Nutanix role that determines what the user can see and do.

A Prism Central construct that groups users, categories, and resources so each team sees and manages only its own workloads, providing scoped multi-tenancy on a shared cluster without separate clusters.

Key-value labels attached to VMs and other entities that drive policy and scoping. Flow rules, protection domains, and project membership all select workloads by category rather than by IP address or VM name.

Dividing a data center into small logical security zones built around individual workloads, allowing only explicitly required traffic between them so an attacker who compromises one VM cannot move freely across the network.

The Nutanix distributed firewall capability, managed from Prism Central, that applies per-workload allow and deny rules close to each VM in order to segment traffic and stop lateral movement inside the cluster.

A firewall enforced inside the virtual switch on every host rather than in a physical appliance, so rules follow a VM as it migrates and traffic is filtered before it ever leaves the host.

A named set of ordered rules in Flow that states which sources may reach which destinations on which services, with the protected and peer workloads chosen by category membership.

A Flow policy that permits traffic only among the VMs placed in the policy group and blocks everything else, creating a closed enclave for a set of related workloads such as a multi-tier application.

A Flow policy applied to VMs believed to be compromised or under investigation, dropping essentially all traffic to and from them except limited access needed for remediation, which contains the threat while forensics proceed.

A per-policy setting that either only records traffic that would have been blocked, called monitor mode, or actually drops it, called enforce mode. Monitoring first lets teams validate rules without an outage.

Protecting data stored on cluster disks so it is unreadable without the correct key. Nutanix can do this in software or through self-encrypting drives, with keys held inside or outside the cluster.

A disk that encrypts its own data in hardware, keeping the media encryption key inside the drive. Nutanix supports SED-based encryption so data at rest is protected without a software encryption performance cost.

An external appliance or service that stores and protects the keys a Nutanix cluster needs to unlock encrypted storage. The cluster contacts it at startup and during key operations over a standard protocol.

Key Management Interoperability Protocol, the standard used by Nutanix to communicate with an external key management server for creating, retrieving, and rotating the keys that protect encrypted storage.

The key that actually encrypts stored data. It is itself wrapped and protected by a higher-level key held in the key management server, so it can be replaced without re-encrypting the entire cluster by hand.

Periodically replacing encryption keys with newly generated ones through the key management server or a re-key operation, limiting how much data is exposed if an old key is ever compromised.

Retiring a self-encrypting drive by destroying its media encryption key, which instantly renders the remaining ciphertext unreadable. It is far faster than overwriting the entire disk during decommissioning.

A firmware feature that verifies the cryptographic signatures of boot components and refuses to run anything unsigned or untrusted, blocking bootkits and unauthorized hypervisors. Nutanix hardening guidance covers enabling it where hardware and hypervisor support allow.

A chip on the server motherboard that stores cryptographic keys and records measurements of boot components. It underpins platform trust features such as secure boot attestation and hardware-protected key storage.

The trusted entity that signs digital certificates. In a Nutanix deployment it may be a public CA, an enterprise internal CA, or the cluster's own self-signed authority used for internal service certificates.

A block containing a public key and identity details that you submit to a certificate authority. The authority returns a signed certificate that you import to replace the default self-signed Prism certificate.

A Nutanix hardening setting that disables SSH access to controller VMs and the hypervisor, forcing administration through Prism and the API only, which reduces the attack surface available to stolen credentials.

A chronological record of activity in Prism, including sign-ins, configuration changes, and policy edits, showing who did what and when. It supports accountability, troubleshooting, and forensic investigation.

Sending cluster, Prism, and audit events to an external syslog server or SIEM so records survive local deletion and can be correlated with the rest of the organization's security telemetry.

Producing evidence that a cluster meets a chosen standard such as CIS, STIG, PCI DSS, or HIPAA by running automated checks and exporting findings, remediation status, and historical results for auditors.

A grouping of VMs and volume groups that are snapshotted and replicated together to a remote site, so related workloads stay consistent and can be recovered as a unit after a disaster.

A space-efficient point-in-time copy of VM or volume data held on the cluster. Nutanix uses snapshots for fast rollback, cloning, and as the unit that replication sends to a remote site.

A set of VMs or volumes whose snapshots are captured at the same instant, ensuring that a multi-tier application restarts after recovery with all its components in a mutually consistent state.

Copying snapshots from a primary cluster to a remote cluster on a schedule, which tolerates wide-area latency. The interval between copies determines the data loss the site can experience.

The maximum amount of data loss a workload can tolerate, expressed as time. It sets how frequently replication or backup must run and therefore drives the design of the protection schedule.