VMware ESXi and vSphere Cluster Management

IT Security Design Guidelines: Least Privilege, Layered Defense, Segregation of Duties, and Auditing

Learn how least privilege, defense in depth, separation of duties, and auditing help design resilient and accountable IT network infrastructure.

Security design guidelines are principles used to reduce risk when building and operating networks, systems, applications, and identity services. They help an organization reduce attack opportunities, limit the blast radius of a compromise, detect suspicious activity, and preserve accountability for important actions.

Security should be designed into infrastructure rather than added only after deployment. Retrofitting controls can be expensive, disrupt services, and leave undocumented paths that attackers can exploit. Effective security architecture combines technical controls, administrative processes, and operational monitoring.

Core IT Security Guidelines

Principle of Least Privilege

The principle of least privilege means granting an identity, service, application, or device only the permissions required for an approved function. Access should be narrow in scope, limited in duration when possible, and reviewed regularly.

A permission is an allowed action, such as reading a file or changing a firewall rule. A privilege is a capability that permits an identity or process to perform an action. A role is a collection of permissions associated with a job function. Administrative access is elevated authority used to manage systems, devices, applications, or security settings.

Role-based access control (RBAC) assigns permissions to roles rather than directly to individual users. Users receive access through appropriate roles, which makes access easier to review and remove when responsibilities change.

Applying Least Privilege

• User accounts: Use standard accounts for email, browsing, documents, and normal work.
• Administrator accounts: Use separate, tightly controlled accounts only for administrative tasks. Do not use an administrator identity for routine browsing or email.
• Service accounts: Give each service only the file, database, network, or operating-system access it needs. Avoid unrestricted accounts and interactive login unless required.
• File shares: Grant access to the required folders and operations, such as read-only access instead of full control.
• Network devices: Use delegated command privileges or narrowly scoped administrative roles where supported. Keep configuration privileges restricted to authorized network administrators.
• Databases: Give applications access only to required databases, tables, views, and operations. Prefer controlled procedures over unrestricted table access.
• Applications: Limit application permissions, exposed interfaces, and access to secrets or operating-system resources.

Elevated access should be time-limited, approval-based, and task-specific when practical. A technician might receive permission to restart one service for 30 minutes after an approved request, rather than receive permanent server administration.

Excessive permissions increase the impact of stolen credentials, malware, mistakes, and insider misuse. Shared administrator accounts remove individual accountability. Broad group membership can grant unintended access, while unrestricted service accounts can let a compromised application modify large parts of an environment.

Review access periodically and whenever a person changes role, leaves the organization, or no longer needs a resource. Remove stale accounts, inherited permissions, unnecessary group membership, and temporary grants that were never revoked.

Defense in Depth

Defense in depth uses multiple independent and complementary security layers. If one safeguard fails, another should still prevent, detect, contain, or help recover from the attack. The layers should not all be identical or depend on the same single point of failure.

A security control is a safeguard that prevents, detects, deters, corrects, or compensates for a risk. Preventive controls block unwanted activity. Detective controls identify activity. Deterrent controls discourage misuse. Corrective controls restore a secure state. Compensating controls reduce risk when an ideal control cannot be implemented.

Common Defense-in-Depth Layers

Traffic inspection can occur at several locations. Edge routers can apply basic filters, firewalls can enforce stateful policy, an IDS can identify suspicious activity, and an IPS can identify and block malicious or policy-violating traffic. Internal segmentation points can restrict zone-to-zone flows, while hosts can enforce local firewall and endpoint policies.

For example, an Internet-facing application might use edge filtering, a stateful firewall, an IPS, a reverse proxy or web application protection layer, a segmented server network, and host firewall rules. Each layer addresses different failure modes. A firewall mistake should not automatically provide unrestricted access to the database host.

Layering has trade-offs. Additional controls increase cost, configuration complexity, administration, performance impact, and alert volume. Different tools may enforce inconsistent policies. Design layers deliberately, document ownership, tune alerts, and test that controls work together without creating unnecessary bottlenecks.

Network Segmentation Policy Example

Network segmentation divides a network into controlled zones and restricts communication between them. A deny-by-default posture means traffic is blocked unless a documented rule explicitly permits it.

policy inter-zone
  default-action deny
  allow user-zone  -> app-zone      service https  log
  allow app-zone   -> database-zone  service db-port log
  allow admin-zone -> device-zone    service management log
  deny  any         -> any            log

Exact syntax varies by firewall and network platform. Log denied traffic and sensitive allowed flows, but tune logging so routine noise does not hide important events.

Separation of Duties

Separation of duties, also called segregation of duties, divides sensitive processes among different people or roles. It reduces fraud, unauthorized change, accidental misuse, and the ability of one person to bypass every safeguard.

Typical responsibilities include requesting access, approving access, implementing changes, reviewing logs, and auditing outcomes. These responsibilities should not all be assigned to one person for sensitive operations.

Apply the principle to firewall administration, account provisioning, financial systems, backup recovery, network changes, and incident response. For example, the person who declares an incident should not be the only person who can erase evidence or close the investigation.

Small teams may not be able to separate every role completely. Use compensating controls such as peer review, manager approval, mandatory ticketing, immutable or tamper-resistant logs, configuration backups, and post-change review. Urgent changes should still be documented and reviewed afterward.

Auditing and Accountability

Auditing is the collection, preservation, review, and reporting of evidence about activities, events, and changes affecting systems and network security. Audit records support troubleshooting, incident investigation, compliance, and change accountability.

• Event logging: Recording an event, such as a login failure or configuration change.
• Monitoring: Observing systems and traffic over time to identify conditions or trends.
• Accounting: Tracking usage or activity associated with users, systems, or network resources.
• Auditing: Reviewing records and other evidence to determine what happened and whether policy was followed.
• Alerting: Notifying a person or system when an event meets a defined condition or threshold.

Events to Record

• Successful and failed authentication attempts
• Privilege changes, role assignments, and account creation or deletion
• Configuration modifications and administrative commands
• Firewall permits and denials, especially for sensitive flows
• Policy changes, system errors, service starts and stops, and security alerts
• IDS or IPS detections, endpoint detections, and administrative access

Syslog is a common protocol and message format for generating and forwarding event messages. Centralized logging forwards records from distributed systems to a dedicated collection and analysis platform. Centralization makes correlation easier and helps preserve evidence when an individual device is compromised or its local logs are deleted.

! Conceptual network-device example; syntax varies by platform
logging on
logging trap informational
logging host 192.0.2.50
logging source-interface Management0

# Conceptual server-side receiver
module(load="imudp")
input(type="imudp" port="514")
*.* /var/log/remote/%FROMHOST-IP%.log

Use a suitable transport security option where supported, protect the collector, and select facility and severity settings appropriate to the platform. Exact syntax, transport choices, storage paths, and severity meanings vary. A collector should restrict who can read or alter logs and should retain records according to operational and legal requirements.

Reliable auditing requires consistent timestamps, time synchronization, log integrity protections, retention rules, access controls, documented review procedures, and useful alert thresholds. Synchronize devices with an approved time source. Record the device identity, user identity where available, event time, action, result, and affected object.

Conceptual Access-Control Configuration

# Conceptual RBAC example
role helpdesk-password-reset
  permit user.password.reset
  permit ticket.read
  deny account.admin.create
  deny firewall.policy.change
  deny server.console.access

role network-administrator
  permit approved.network-device.configuration
  permit approved.network-device.show
  deny unrelated.business-system.admin

assign helpdesk-group       helpdesk-password-reset
assign network-admin-group  network-administrator

This illustrates narrow roles, not a platform-specific command language. Do not assign broad administrative roles for convenience. Test the effective permissions, including direct grants, nested groups, inherited access, and emergency access paths.

Combining the Guidelines in an Infrastructure Design

Consider a design in which employees access an application hosted in a protected server zone. Users authenticate through an identity service and receive only the application permissions associated with their roles. Network administrators use separate privileged identities from a management subnet. A firewall permits only documented user-to-application and application-to-database flows. Internal boundaries prevent ordinary workstations from reaching database servers directly.

IDS or IPS controls inspect relevant traffic, host-based security protects servers and endpoints, and centralized logging receives identity, firewall, endpoint, and device events. A change workflow requires an application owner to request a connection, a security role to approve it, a network administrator to implement it, and an independent reviewer to verify the deployed rule. Time-synchronized logs provide evidence for each step.

This design works because the principles reinforce one another. Least privilege limits what identities can do. Layered controls limit where an attacker can go. Separation of duties limits who can make or conceal a sensitive change. Auditing provides evidence to verify that the other controls are operating as intended. Policies must be supported by technical enforcement and operational verification.

Architecture Checklist

• Identities: Are standard and privileged accounts separate? Are roles narrow, approved, time-limited where possible, and reviewed regularly?
• Administration: Are administrative paths restricted to a management network? Are privileged actions individually attributable?
• Network boundaries: Are Internet, user, application, database, management, and other sensitive zones separated by policy-enforcing controls?
• Traffic policy: Is access denied by default, with documented exceptions for required flows? Are sensitive permits and denials logged?
• Independent layers: Do physical, perimeter, segmentation, host, identity, application, data, and monitoring controls address different failure modes?
• Logging: Are authentication, privilege, configuration, policy, firewall, error, and security events forwarded to protected centralized storage?
• Time and integrity: Are clocks synchronized, logs protected from alteration, retention defined, and access to logs restricted?
• Separation of duties: Are request, approval, implementation, validation, and audit responsibilities divided?
• Review: Are access reviews, alert reviews, configuration comparisons, incident exercises, and post-change checks scheduled?
• Recovery: Are backups protected and recovery procedures tested if preventive controls fail?

Troubleshooting Security Design Problems

Users Have Excessive Access

1. Review direct permissions, group memberships, inherited access, privileged roles, and service-account assignments.
2. Compare effective access with documented job requirements.
3. Identify stale accounts and permissions retained after role changes.
4. Remove unnecessary grants, replace direct permissions with role-based assignments, and establish recurring access reviews.

A Firewall Permits Unexpected Traffic

1. Check rule order, source and destination definitions, service objects, network address translation behavior, and implicit policies.
2. Review firewall logs and determine whether another path bypasses the intended inspection point.
3. Narrow the rule, correct ordering or object definitions, validate segmentation boundaries, and document the approved flow.

Events Cannot Be Correlated Across Devices

1. Verify time synchronization, log forwarding, source identification, severity filtering, collector capacity, and retention.
2. Determine whether devices generate logs locally but fail to transmit them.
3. Synchronize clocks, correct forwarding configuration, protect centralized storage, and test with known events.

One Administrator Controls Every Sensitive Step

1. Map the end-to-end workflow and identify where one account or person controls multiple critical steps.
2. Check approval records, change tickets, configuration history, and administrative logs.
3. Separate approval and implementation roles or introduce compensating reviews, mandatory ticketing, and tamper-resistant audit records.

Many Tools Exist but an Incident Spreads Widely

1. Assess whether controls operate at different layers or merely duplicate the same weak boundary.
2. Check internal segmentation, endpoint hardening, identity restrictions, alert handling, and backup or recovery readiness.
3. Strengthen independent layers, limit lateral movement, validate alert response, and test the failure of individual controls.

Exam-Relevant Notes

• Least privilege limits permissions; RBAC is one way to implement it.
• Defense in depth is not simply adding many identical tools. Layers should be complementary and have independent failure modes.
• IDS detects and alerts; IPS can actively block detected traffic.
• Separation of duties divides responsibilities among roles. It is distinct from least privilege, although both reduce misuse.
• Accounting records activity or usage, while auditing reviews evidence and determines whether activity was appropriate.
• Centralized logs are more useful when timestamps are synchronized and records are protected from alteration.
• A deny-by-default segmentation policy permits only documented, necessary flows.

For further study, review IT Security Guidelines alongside access control, AAA, firewall policy, segmentation, IDS or IPS, SIEM, incident response, and configuration management topics.