Authentication, Authorization, and Accounting (AAA) framework built in. The AAA is designed to control access ensuring the right person is using the system, provide what level of access they have, and log activity to account for what has been done, and by whom.
Authentication to HCI System Software is handled by SSO through the vCenter plugin. VxRail vCenter supports the organization’s centralized identity management system in accordance with authentication security policies.
Organizations often centralize identity management using directory services such as Microsoft Active Directory (AD) using LDAP. If the VxRail is a standalone environment and not part of a domain, users and passwords can be managed locally in vSphere and iDRAC. From a best practice’s stance, it would be recommended to use centralized authentication.
Many environments strengthen their identity management using multi-factor authentication that requires an additional level of identity verification including certificates, smartcards, or security token such as RSA SecureID in addition to a username and password. VxRail fully supports multi-factor authentication for both domain and locally managed users.
Often there may be different individuals responsible for the physical servers, the VxRail lifecycle management, and the management of the server, storage, and network virtualization environment. Therefore, VxRail uses fine-grained, role-based access controls for iDRAC, HCI System Software, and vSphere.
Using the “principle of least privilege,” (POLP) a user is granted the required rights to perform their role but no more than is needed. vSphere includes several predefined roles that are used to grant appropriate privilege. For example, a user may be granted the role of vSphere Administrator, HCIA Management, or both. The HCIA Management role grants a user privilege to perform VxRail lifecycle management tasks from the VxRail management plugin within vCenter. vSphere Administrator grants privilege to perform Administrator tasks in vCenter. In addition, vSphere allows an even finer level of access control by the creation of custom roles. For example, a privileged user may be granted the ability to acknowledge an alarm or create a storage profile but not deploy VMs.
Roles are associated with users and groups and with specific objects, where an object is a thing or group of things. For example, a user or group might have permission to acknowledge alerts for a particular VM or port, but not other objects. In addition, restrictive roles such as “No Access” may be assigned to users, preventing them from seeing specific areas within vCenter. Multiple users or groups can be granted the same or different levels of access to the same object. Permissions granted to a child object can be used to override permissions inherited from a parent object.
vSphere Role Based access control supports the granular security principles of “Least Privilege” and “Separation of Responsibility,” and allows the security administrator to enhanced security by defining precise permissions based on the systems management structure of an organization.
Understanding changes in configuration and component status is vital to keeping systems secure and available. Changes may be the result of a temporary fix causing a configuration drift. Or these changes could be an indication of a possible intrusion. Proactively monitoring infrastructure is an important security activity.
Timely detection when an intrusion happens can mean the difference between a brief interruption where the attacker is unable to compromise any critical systems and an intrusion that persists for months leading to the compromise of multiple critical systems. Failure to maintain a system of audit logs, may not provide adequate information on the attack to determine severity. According to the 2019 Trustwave Global Security Report, (registration required), Fifty-seven percent of the incidents investigated involved corporate and internal networks (up from 50% in 2017).
Configuration drift is a challenge that affects all systems. Systems may start with a secure configuration baseline but over time, changes can occur that may leave the system vulnerable. These changes can happen for a variety of reasons including a temporary change while troubleshooting or an approved change that should become part of the baseline configuration. Without monitoring, those changes become very hard to detect.
The challenge with monitoring the information is that it comes from many different sources—an individual VM, a physical server, the virtualization infrastructure, the network, security components, or the applications themselves. Making sense of this information requires a consolidated view of activity and changes. VxRail includes vRealize Log Insight. Log Insight compiles VMware logs including servers, network devices, storage, and applications. As the graphic below shows, Log Insight creates a dashboard with graphs based on the data in the logs. This helps the administrator quickly and easily drill down to the root cause of the issue. The following figure shows the vRealize Log Insight dashboard:
Figure 10. Realize Log Insight
Correlating all of this information is one of the many reasons that VxRail uses the industry standard Network Time Protocol (NTP) to keep all of the component clocks in sync.
For organizations that already have a log management system or Security Incident and Event Management (SIEM) system, VxRail easily integrates using the standard syslog protocol.
Physical security is an important part of any comprehensive security solution. Because VxRail may be deployed outside of a traditional data center, physical security can take on even greater importance. In order to prevent malware or infected software from being introduced via a USB drive, the USB ports on a VxRail can be disabled and then enabled only when needed.
The VxRail nodes also monitor for other events such as chassis openings, parts failure or replacement, firmware changes, and temperature warnings. This information is recorded in the iDRAC Lifecycle Log. In many cases, a chassis need not be opened after it’s put into production, and tracking such activity could be an indicator of an attempt to compromise the system.
An important part of maintaining security is assuring that all of the relevant security configuration elements are implemented on all of the objects in an environment. An individual VxRail cluster can have up to 64 physical nodes, and multiple VxRail clusters can be managed by one vCenter, thus supporting thousands of VMs. Even a simple change—if it must be configured on all the VMs—could take a significant amount of time to enact. In addition, when performing repetitive tasks, people are prone to make mistakes. This is where automation becomes critical.
Automation allows an environment to have fewer configuration errors and more consistent configuration while increasing efficiency and reducing the time between when a decision is made and when it is implemented, increasing the time to value of those decisions.
Compatible tools like vRealize Automation allows the automation of vSphere and vSAN. These tools can be used to automate standard day-to-day operations such as the creation of VMs or storage policies. vRealize Automation can also be used to validate that the security configuration has not drifted from its appropriate settings. If the configuration has changed, vRealize Automation is able to reconfigure the ESXi servers, vCenter, or individual VMs so that they once again meet the required security configuration. In addition, because vRealize Automation is a standard VMware tool, many IT virtualization teams already know how to work with vRealize Automation and have created profiles that will work with a VxRail cluster.