Across all regulations or standards, security principles dictate the mind set used when applying security controls within the VMware Validated Design.

Security Principles and Considerations

The following common concepts in separation of duties and privileges are considered:

  • Infrastructure provider vs. multi-tenant consumer

  • Least privilege

    • Super user

    • Developer

    • Operations team

    • Analyst

    • System account

  • Separation of duties

    • Super user compared to non-super user

    • Service accounts compared to user accounts

    • System to system communication

    • Development environment compared to production environment

    • Create, edit, or delete compared to read-only.

User Roles Based on Least Privilege

Access to the VMware Validated Design must be tailored specifically to the type of work that is required. Where possible, access must be restricted to each role based on the user's job function, title, and authorization. The following roles have been established within the VMware Validated Design Security Architecture Design:

Super user

Charged with managing the system and performing elevated privilege actions.

Developer

Primarily creating functionality within the system and especially restricting access to the system of ownership (infrastructure vs. multi-tenant consumer).

Operations team

Design the architecture of the cloud, network, storage, and security, or possibly the maintenance of the system as required.

Analyst

Focused on viewing relevant system data, or auditing settings and restricting access as required, and providing system models and reports to the relevant teams ensuring effectiveness

Note:

The concept of an "average user" is not included. The SDDC components outlined in the architecture overview are part of the VMware Validated Design design and management. A typical user might be restricted to the use of an application, or other end-point solution, rather than have access to the SDDC infrastructure.

The following tables are a sample on least privilege in a roles matrix for the infrastructure provider level.

Table 1. Physical Layer

Products

Infrastructure Provider Roles and Responsibilities

Super User

Developer

Operations Team (Day 2)

Analyst

  • VMware ESXi

  • Top of Rack Switches

  • Traditional Storage

ug-Physical-Admin

No access

ug-Physical-OpsTeam (Read Only)

No access
Table 2. Virtual Infrastructure Layer

Products

Infrastructure Provider Roles and Responsibilities

Super User

Developer

Operations Team (Day 2)

Analyst

  • vCenter Server

  • VMware Update Manager

  • VMware NSX for vSphere

  • VMware vSAN

  • Platform Services Controller

ug-VirtualInfra-Admin

No access

ug-VirtualInfra-OpsTeam

No access
Table 3. Operations Management Layer

Products

Infrastructure Provider Roles and Responsibilities

Super User

Developer

Operations Team (Day 2)

Analyst

  • vRealize Log Insight

  • vRealize Operations Manager

ug-OpsMgmt-Admin

ug-OpsMgmt-Developer (Read-Only)

ug-OpsMgmt-Engineer (Read-Only)

ug-OpsMgmt-Analyst
Table 4. Cloud Management Layer

Products

Infrastructure Provider Roles and Responsibilities

Super User

Developer

Operations Team (Day 2)

Analyst

  • vRealize Business Costing

  • vRealize Automation

  • vRealize Orchestrator

ug-CloudMgmt-Admin

ug-CloudMgmt-Developer

ug-CloudMgmt-OpsTeam

ug-CloudMgmt-Analyst
Table 5. Business Continuity

Products

Infrastructure Provider Roles and Responsibilities

Super User

Developer

Operations Team (Day 2)

Analyst

  • Backup software

  • VMware Site Recovery Manager

  • vSphere Replication

ug-BusContinuity-Admin

No Access

ug-BusContinuity-OpsTeam

No Access

Separation of Duties

Establishing trust in the system might require access controls to carve up the flow of work. By establishing a boundary between each key area of a wider process, a review with a focus on governance can be implemented. This approach is used to ensure that changes are not made without prior approval, unauthorized access can be contained, change management processes better monitored, and so on. Because risk tolerance and processes differ so widely, a few key roles are identified and woven into the fabric of the security architecture.

  • Super user vs. non-super user

  • Service accounts vs. user accounts

  • System to system communication

  • Development environment vs. production environment

  • Create/edit/delete vs. read-only