The Software Defined Data Center (SDDC) provides a unique technology stack to secure. From the perspective of a compliance assessment, external audit, or internal security hardening team, the SDDC will likely need to evidence Access Control—the method for granting, revoking, and monitoring who has access to what, as well as demonstrating access is restricted to the minimum level required by users to do their job.
When planning for compliance, it is important to note that some standards and regulations can be very specific with regards to Access Control, while others may only outline general concepts subjectively evaluated by external auditors in charge of concluding appropriateness. This can make it a challenge to develop security architecture and designs that address Access Control to satisfy myriad interpretations.
Below is an Access Control blueprint using the VMware Validated Design (VVD) for the SDDC. The VVD solution has been used across a wide array of industries and customer deployments have varied in size from 1,000 to 20,000 Virtual Machines (VM). This provides a reasonable blueprint to overlay the security principles supporting Access Control. Combining the VVD with SDDC best practices used in compliance and security, the concept of separation of duties and least privilege are showcased in this Access Control security architecture design. This design was benchmarked against NIST 800-53 R4, with compliance mapping to other regulations such as PCI, HIPAA, ISO27001, NIST 800-171, DISA STIG, and FBI CJIS to provide a wider compliance suitability evaluation. Regardless if compliance is a main driver for securing the SDDC, this design offers a security architecture and design VVD best practice.
Access Control Assumptions
The following compliance and security assumptions were taken into in account when formulating the proposed Access Control security architecture and design:
- Each user has their own unique user ID that they use to log into the system
- Generic, or standard accounts are disabled, renamed, or only used when necessary
- Each user’s access is catered to their job function
- Users that leave the company or transition roles have their access removed, or modified accordingly
- A cohesive structure is used to manage job function and monitor appropriateness
VMware Validated Design (VVD) Architecture Layers
The VVD breaks out the architecture into five layers. These layers group several products and similar components into concepts that can be designed, discussed, implemented, and maintained consistently. The five layers also form a natural adoption point for Access Control. This is a key design decision because it means that product capabilities are tailored by layer—this access can be further modified within individual products to apply more granular roles. Authentication would be managed using Active Directory groups. Authorization would be managed by association Active Directory groups to individual product roles. This design can also be customized by customers.
A matrix approach was used to develop the intersection of architecture layers (system functionality) with job functions (roles). Using a two-axis model provides a table visualization that can be used for reference, lookup, and communication of Access Control.
Matrix Model: First Axis for Access Control
The five-layer architecture maps to the SDDC stack. Each layer manages functionality within the SDDC and correlates to a set of products. Each layer within the VVD architecture has been well documented.
- Operations Management Layer—includes products/components vRLI, vROPS; relates to logging, performance, and insight into the operational state of the SDDC
- Cloud Management Layer—includes products/components vRBC, vRA, vRO; relates to automation, orchestration, costing, and other enablement of the SDDC to standardize it and simplify its operation
- Virtual Infrastructure Layer—includes products/components vCenter, Update Manager, NSX, vSAN, PSC; relates to the core management of virtual machines, virtual resources such as memory, data, load balancing, and virtualization of the network
- Physical Layer—includes products/components ESXi (Hosts), Top or Rack (ToR) Switches, Traditional Storage; relates to the integration point between the SDDC and the physical switches that connect it beyond the SDDC, as well as the physical servers that are the bare metal used to run the virtual machines
- Business Continuity—includes products/components SRM, vSphere Replication and backup software; relates to backups, business continuity, disaster recovery, and the ability to seamlessly move virtual systems across the SDDC
Matrix Model: Second Axis for Access Control
To further build out the Access Control matrix, four job functions were used as a minimum level of separation of duties. Within each of these groups, a customer could customize access to reflect a more granular model further subdividing it. For example, the model could be further split into quality of access—supervisor access (read only, for example), senior system administration (broader), junior administrator (narrow), and so forth.
For this security architecture and design, only a view of the infrastructure provider is provided. Individual tenants are not included. The delicate balance reached in this design provides a minimum structure to support separation of duties enforcement.
The four job functions that make up the second axis include:
- Super Users—these are the administrators of the systems that are given elevated access
- Developers—focused on making blueprints and standardizing virtual schemes to enable better operation of the SDDC, including automation
- Operations Team—day-to-day operators that monitor the SDDC, perform maintenance, and ensure resources are being used efficiently
- Analysts—business users that are focused on costing such as system charge-backs, overall cost associated with performance/usage, require limited access
Active Directory User Groups
The enforcement of the access control matrix outlined in this security architecture and design requires Active Directory. A nestling structure is recommended to achieve a structure that can be navigated, monitored, and understood by system administrators. This requires a universal security group to manage the first axis (architecture layer) and a global security group to manage the second axis (job function on a per product basis). Together, this combination allows users to be assigned access to a universal security group and inherit the underlying product job function access that correlates with the relevant intersection of products and product roles. This also ensures that for example, a Super User and a Developer would be assigned separate Active Directory groups to minimize assigning inappropriate access.
Access Control Matrix
Below is an example of one architecture layer and the universal security groups associated within each job function. This is a top-level view and additional tables for each layer are provided in published in VVD guidance.
Assigning Access within Products
The granular access assignment takes place at the product level. Each global group is assigned a specific product role(s) that matches the user’s job function. This structure removes the need to create new roles within products. Instead, access can be managed via Active Directory using the existing, standardized product roles. Below is an example depicting access to the Management Operations layer and corresponding products vRLI and vROPS for a Operations Team system user.
Access Control can be managed within the VVD using a prescriptive user access security structure using Active Directory. The design is built on a minimum separation of duties. Job functions combined with VVD architectural layers are used to create a system access matrix to identify Access Control requirements. The security architecture and design should enable better, simpler, and faster administration of users within the SDDC. The design can also be customized and enhanced into further granular access. We encourage interested parties to read the detailed designs that includes an explanation of each decision, product role assignment, and background.
- Introduction Security and Compliance
- Architecture and Design Guidance for NIST 800-53 (Early Access)
~Carlos Phoenix, CISA – Global Cyber Strategist
Visit security.vmware.com and learn how VMware delivers security in our products, solutions, cloud services, and across industries
Follow us on Twitter at @VMwareSecurity