enterprise hybrid cloud 4 - dell emc · pdf fileenterprise hybrid cloud 4.0: foundation...

Solution Guide

ENTERPRISE HYBRID CLOUD 4.0 Security Management Guide

EMC Solutions

Abstract

This solution guide provides information about the features and configuration options available for securing system operations for a hybrid cloud. The guide explains why, when, and how to use these security features.

August 2016

Copyright

2 Enterprise Hybrid Cloud 4.0 Security Management Guide

Copyright © 2016 EMC Corporation. All rights reserved. Published in the USA.

Published August 2016

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose. Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

EMC2, EMC, Avamar, Data Domain, Data Protection Advisor, Isilon, PowerPath, EMC RecoverPoint, ScaleIO, Symmetrix, Unisphere, ViPR, VMAX, VPLEX, VNX, XtremIO, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com.

Enterprise Hybrid Cloud 4.0 Security Management Guide Solution Guide

Part Number H15199

http://www.emc.com/legal/emc-corporation-trademarks.htm

Contents


Contents

Chapter 1 Executive Summary 5

Overview .................................................................................................................... 6

Key benefits ............................................................................................................... 6

Document purpose ..................................................................................................... 6

Audience .................................................................................................................... 7

Essential reading ........................................................................................................ 7

Terminology................................................................................................................ 7

We value your feedback!............................................................................................. 8

Chapter 2 Public Key Infrastructure 9

Overview .................................................................................................................. 10

Enterprise PKI architecture........................................................................................ 10

Enterprise PKI solution integration ............................................................................ 12

Summary .................................................................................................................. 15

Chapter 3 Converged Authentication 16

Security and authentication ...................................................................................... 17

Active Directory integration ....................................................................................... 20

VMware Platform Services Controller ........................................................................ 21

TACACS+ authentication integration ......................................................................... 22

Summary .................................................................................................................. 22

Chapter 4 Centralized Log Management 23

Overview .................................................................................................................. 24

VMware vRealize Log Insight remote syslog architecture........................................... 26

Centralized logging integration ................................................................................. 27

Content packs for VMware vRealize Log Insight ........................................................ 29

Configuring alerts ..................................................................................................... 30

Summary .................................................................................................................. 34

Chapter 5 Network Security 35

Overview .................................................................................................................. 36

Solution architecture ................................................................................................ 36

VMware NSX for vSphere .......................................................................................... 42

VMware NSX for vSphere extensibility with Palo Alto Networks firewalls ................... 44

VMware NSX firewall policy creation ......................................................................... 45

Contents EMC Confidential [delete if not required]


N-tier application considerations .............................................................................. 46

Cross-vCenter NSX .................................................................................................... 48

Use case 1: On-demand micro segmentation with security tags ................................ 49

Use case 2: Micro-segmentation with N-tier virtual applications ............................... 51

Use case 3: Micro-segmentation with converged N-tier virtual applications .............. 54

Use case 4: Micro-segmentation with App Isolation for component machines .......... 55

Summary .................................................................................................................. 56

Chapter 6 Configuration Management 57

Overview .................................................................................................................. 58

VMware vCenter Server host profiles ........................................................................ 58

VMware vSphere Update Manager ............................................................................ 61

VMware vRealize Configuration Manager .................................................................. 65

Use case 1: Configuring a custom compliance standard ........................................... 68

Use case 2: Applying exceptions to compliance templates ....................................... 70

Summary .................................................................................................................. 71

Chapter 7 Multitenancy 72

Overview .................................................................................................................. 73

Secure separation .................................................................................................... 73

Role-based access control ........................................................................................ 75

Summary .................................................................................................................. 77

Chapter 8 Data Security 79

Overview .................................................................................................................. 80

CloudLink SecureVM ................................................................................................ 80

Policy-based management ....................................................................................... 81

Integration with the service catalog .......................................................................... 82

Summary .................................................................................................................. 82

Chapter 9 Conclusion 84

Summary .................................................................................................................. 85

Chapter 10 References 86

Enterprise Hybrid Cloud documentation ................................................................... 87

Enterprise Hybrid Cloud security documentation ...................................................... 87

Other documentation ............................................................................................... 88

Appendix A Enterprise Hybrid Cloud Security Data 90

Security data ............................................................................................................ 91

Chapter 1: Executive Summary


Chapter 1 Executive Summary

This chapter presents the following topics:

Overview .................................................................................................................... 6

Key benefits ............................................................................................................... 6

Document purpose ..................................................................................................... 6

Audience .................................................................................................................... 7

Essential reading ....................................................................................................... 7

Terminology ............................................................................................................... 7

We value your feedback! ............................................................................................ 8



Overview

Many organizations are looking for ways to drive more business value, redefine their business models, and build an enhanced customer experience in an increasingly digital world. IT must deliver enterprise IT services and applications with greater speed and agility, while reducing costs and minimizing risks.

A hybrid cloud helps organizations innovate rapidly while still delivering enterprise-grade performance, resiliency, and security. Enterprise Hybrid Cloud 4.0 delivers this by combining the control, reliability and confidence of a private cloud with the simplicity, flexibility, and cost efficiency of public clouds to transform delivery of IT services. Enterprise Hybrid Cloud delivers automated infrastructure services for traditional enterprise applications across private and public clouds with greater speed, scalability, and agility while reducing costs and minimizing risks. Workflows and application blueprints transform what was once manual into automated infrastructure provisioning, on-demand, with management insights and cost transparency. A self-service catalog empowers business users to procure traditional enterprise applications and IT services on-demand, with service levels that align with workload and cost objectives. Built-in security and data protection allow you to run your hybrid cloud with confidence.

Designed, integrated, and tested in EMC labs with best-in class technologies, automated workflows and application blueprints, Enterprise Hybrid Cloud 4.0 is the foundation for infrastructure as a service (IaaS). Deliver IaaS to meet your specific business needs with add-on options for data protection, virtual machine encryption, applications, application lifecycle automation for continuous delivery, ecosystem extensions, and more. IT can start delivering value to the business two times faster with Enterprise Hybrid Cloud when compared to building your own IaaS solution.

Key benefits

The key benefits of Enterprise Hybrid Cloud are:

Agility. Transform your IT organization through automated delivery of IaaS with on-demand access to traditional enterprise applications and IT services.

Simplicity. Engineered so you do not have to, Enterprise Hybrid Cloud is the foundation for IaaS with add-on options to meet your specific business needs. It integrates best-of-class technologies, professional services, and single contact support into an easy to consume engineered solution.

Security. Enterprise Hybrid Cloud 4.0 ensures applications and business data are protected with options for virtual machine encryption, secure network isolation, segmentation, and enhanced network security to minimize risk.

Document purpose

This solution guide provides information about the features and configuration options that are available for securing system operations in an on-premises implementation of Enterprise Hybrid Cloud 4.0. It explains why, when, and how to use these security features.



Audience

This solution guide is part of a documentation set and is intended for security architects, practitioners, and administrators responsible for the overall configuration and operation of the solution. Readers should be familiar with the VMware vRealize® Suite, storage technologies, hybrid cloud infrastructure, and general IT functions.

Essential reading

The following documents describe the architecture, components, features, and functionality of Enterprise Hybrid Cloud 4.0:

Enterprise Hybrid Cloud 4.0: Concepts and Architecture Guide

Enterprise Hybrid Cloud 4.0: Administration Guide

Enterprise Hybrid Cloud 4.0: Infrastructure and Operations Management Guide

Enterprise Hybrid Cloud 4.0: Foundation Infrastructure Reference Architecture Guide

Table 2 in Chapter 10 lists publications that are related to understanding Enterprise Hybrid Cloud security. Chapter 10 also lists relevant documentation.

Terminology

Table 1 lists the terminology used in the guide.

Table 1. Terminology

Term Definition

CRL Certificate Revocation List—contains a list of serial numbers for revoked certificates

DFW VMware NSX® Distributed Firewall

DLR VMware NSX Distributed Logical Router

ESR VMware NSX Edge Services Router

STS Security Token Service—a VMware vCenter™ Single Sign-On authentication interface

VA An abbreviation for virtual appliance used in diagrams in this guide

vRCM An abbreviation for VMware vRealize® Configuration Manager™ used in diagrams in this guide

VRO An abbreviation for VMware vRealize® Orchestrator™ used in diagrams in this guide

vRA An abbreviation for VMware vRealize® Automation™ used in diagrams in this guide



Term Definition

vR Ops An abbreviation for VMware vRealize® Operations Manager™ used in diagrams in this guide

vRealize Automation blueprint

A specification for a virtual, cloud, or physical machine that is published as a catalog item in the vRealize Automation service catalog

vRealize Automation business group

A set of users, often corresponding to a line of business, department, or other organizational unit (OU), that can be associated with a set of catalog services and infrastructure resources

vRealize Automation fabric group

A collection of virtualization compute resources and cloud endpoints that is managed by one or more vRealize Automation fabric administrators

We value your feedback!

EMC and the authors of this document welcome your feedback on the solution and the solution documentation. Contact [email protected] with your comments.

Authors: Robert Porter, Traci Morrison.

mailto:[email protected]?subject=Feedback:%20H15199:%20EHC%204.0%20Security%20Mgmt.%20Solution%20Guide

Chapter 2: Public Key Infrastructure


Chapter 2 Public Key Infrastructure


Overview .................................................................................................................. 10

Enterprise PKI architecture ...................................................................................... 10

Enterprise PKI solution integration .......................................................................... 12

Summary .................................................................................................................. 15



Overview

A significant challenge in securing any environment is ensuring the authenticity of the interfaces to which users and administrators submit their credentials and the confidentiality of related network communications. Enterprise Hybrid Cloud uses public key infrastructure (PKI) integration to implement trusted certificates that enable the authenticity of applications and devices to be verified and that encrypt administrator access to the management interfaces.

Integrating a PKI into a multitenant hybrid cloud environment ensures that all the components that use, or rely, on X.509 certificates and technology are trusted. By default, components are installed or factory-shipped with self-signed X.509 certificates that are untrusted, because you cannot verify the authenticity of who issued or signed them. In such an environment, an attacker could impersonate a device or application to perform man-in-the-middle attacks or to harvest administrative credentials for subsequent use in compromising other systems on the network. The impact of such an attack is serious because of the privileges that are usually given to systems administrators to fulfill their duties. Certain regulated industries and governments require the use of trusted certificates only.

Integration with a trusted PKI addresses this problem by establishing a chain of trust—from the trusted X.509 certificate received from the issuing certification authority (CA) and installed on the device or application, through to the root CA. Also, the PKI provides a means to validate this trust by publishing Authority Information Access (AIA) locations and Certificate Revocation Lists (CRLs).

This chapter provides an overview of integrating the Enterprise Hybrid Cloud solution stack and supporting infrastructure into an enterprise PKI hierarchy. It does not cover PKI policies, registration authorities (RAs), validation authorities (VAs), or other components that are typically used in the PKI. Design considerations for these components should be taken into account when implementing PKI within your organization, but are outside the scope of this guide.

Always follow best practices when designing your organization’s PKI infrastructure and take additional security measures to safeguard the private keys used by the CAs. In a virtualized environment, use network-based hardware security modules (HSMs) to store the CA private keys in a secure manner with tamper protection. HSMs can also provide offloading of certain cryptographic processing for symmetric or asymmetric needs where performance and speed is a requirement.

Note: Enterprise Hybrid Cloud implements Transport Layer Security (TLS)-compatible configurations and certificates. All references to Secure Sockets Layer (SSL) in this guide imply TLS compatibility.

Enterprise PKI architecture

The PKI used in the solution is based on the deployment of Microsoft Active Directory Certificate Services. Part of hardening the hybrid cloud infrastructure is to replace the



self-signed X.509 certificates with valid signed certificates from a trusted CA1. For the example shown in Figure 1, we configured an internal CA using a hierarchical structure with the root CA at the top level; the root CA can be either offline or air-gapped2. Subordinate CAs are tiered in the Active Directory forest.

Figure 1 shows the hierarchal architecture of the PKI environment with the root self-signed certificate, the issuing CA certificate, and the end-entity certificates. The architecture also shows the trust relationship between the end-entity certificates and the end user.

Figure 1. PKI hierarchy for Enterprise Hybrid Cloud solution stack

All CA certificates contain the AIA extension, which lists the locations of the certification authority’s certificates. The CA certificates also contain a CRL Distribution Point (CDP) extension. The CDP lists the locations of the certification authority’s CRLs. The end-entity certificates were issued by the subordinate CA and requested with a subject alternative name (SAN) consisting of a fully qualified domain name (FQDN), hostname, and IP address.

In production environments, it is common for systems to be managed and accessed using the system IP address, hostname, or FQDN. However, when PKI is introduced, this behavior can result in certificate validation errors that can cause integration to fail. To resolve this problem, you can issue a certificate that contains one or more subject alternative name (subjectAltName) attributes, in addition to the subject name (also known as the Common Name). However, support for this attribute is not 1 Some organizations might choose to use an external entity for this. 2 An air-gapped root CA is removed from the network and AIA and CRL updates are transferred manually.



enabled by default in Active Directory Certificate Services. In distributed or highly available environments, load balancers must be configured with multiple FQDNs and IP addresses. This requires use of the subjectAltName extension in certificates. Therefore, EMC recommends that your PKI supports and implements subjectAltName.

When designing a PKI, it is important to consider the security implications of enabling the subjectAltName extension. Your security policy may require certain controls and processes to be put in place that are beyond the scope of this guide. The Microsoft TechNet Library topic How to Request a Certificate with a Custom Subject Alternative Name describes security best practices for enabling subject alternative names in certificates.

Enterprise PKI solution integration

This section lists Enterprise Hybrid Cloud components that you should integrate into your enterprise PKI hierarchy and describes some advanced security features that use PKI for authentication. The following solution components can be integrated into a PKI:

VMware vRealize® Log Insight™

VMware vRealize Orchestrator

VMware vRealize® Operations Manager™

VMware vRealize Automation

VMware vRealize® Application Services™

VMware vSphere® ESXi™

VMware vCenter Server™

VMware Platform Services Controller™

VMware NSX® for vSphere®

EMC Avamar®

EMC Data Protection Advisor™

EMC Data Domain®

EMC Unisphere®

EMC ViPR®

CloudLink SecureVM modular add-on for virtual machine encryption

Lightweight Directory Access Protocol (LDAP) is the protocol by which many applications submit authentication or authorization requests. LDAP introduces a significant security risk because usernames and authorization requests are passed over the network unencrypted. This can quickly lead to credentials becoming compromised.

You can significantly strengthen the security of these authentication and authorization communications by encrypting the entire LDAP session with SSL/TLS,

Active Directory—LDAP over SSL/TLS certificates

http://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx




known as LDAP over SSL or LDAPS. By default, Active Directory is not configured to support LDAPS, so certain steps must be taken to enable integration of Active Directory Domain Services (ADDS) with a trusted PKI to enable LDAPS. For details, refer to the Microsoft TechNet article LDAP over SSL (LDAPS) Certificate.

The LDAPS certificate is issued by the subordinate CA and requested on each participating domain controller using the Certificates snap-in in the Microsoft Management Console (MMC). The certificate is installed in the domain controller certificate store and is applied by ADDS to LDAP communications to secure authentication and authorization requests through TLS encryption.

VMware Platform Services Controller (PSC) for vSphere 6.0 includes the following platform services, in addition to providing Single Sign On (SSO).

Licensing Service

Certificate Authority (VMCA)

Certificate Store (VECS)

Lookup Service for Component Registrations

Note: While designed to streamline certificate management in vSphere, VMCA does not yet possess the feature-rich capabilities of an enterprise-grade PKI. Therefore, we recommend that you integrate vCenter services directly with your enterprise PKI using the “custom” mode, as defined in VMware Certificate Authority overview and using VMCA Root Certificates in a browser.

The PSC includes a Security Token Service (STS) that enables administrators or applications to authenticate within a defined security domain or identity source such as Active Directory or OpenLDAP. After successful authentication, the PSC SSO STS exchanges the authentication credentials for a Security Assertion Markup Language (SAML) 2.0 token. The client uses this token to interact with the various vSphere platform applications.

During interaction between components, the client verifies the authenticity of the certificate that is presented during the TLS handshake phase. The verification protects against man-in-the-middle attacks.

Each PSC SSO-enabled component registers with SSO using the client end-entity certificate and requires a unique certificate. vRealize Automation Application Services and VMware vRealize® Business™ for Cloud integrate with SSO through vRealize Automation.

The subject Distinguished Name (DN) value is stored in the SSO database as the primary key for each certificate, rather than the hash, thumbprint, or any other attribute. This is important where multiple vCenter Server services are deployed in a single virtual machine, as recommended by VMware. In this case, the Common Name (CN) and other attributes might be identical, which can lead to the same subject DN being used across services. To ensure that the new TLS certificate for each vCenter service has a unique subject DN encoded within the certificate, specify an additional attribute, such as a unique Organizational Unit (OU), for each certificate request.

VMware vCenter Platform Services Controller

http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

http://blogs.vmware.com/vsphere/2015/03/vmware-certificate-authority-overview-using-vmca-root-certificates-browser.html

http://blogs.vmware.com/vsphere/2015/03/vmware-certificate-authority-overview-using-vmca-root-certificates-browser.html



Note: A unique OU ensures a unique subject DN, however, you can use other attributes too. A unique OU is not mandatory because it is only part of the subject DN. For more information about identifying the constituent components of a subject DN, refer to Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile .

Because of the changes in vSphere 6, the vCenter Certificate Automation Tool 5.5 is no longer needed to address the complexities of PSC SSO PKI requirements. VMware has simplified certificate management through the VMware Endpoint Certificate Store (VECS). The VECS serves as a local (client-side) repository for certificates, private keys, and other certificate information that can be stored in a keystore. VECS must be used to store all vCenter certificates, keys, and so on. ESXi certificates are stored locally on each host and not in VECS. Refer to VMware KB article 2111411 for more information on managing certificates in VECS.

Avamar clients and Avamar servers use TLS certificates and PKI for authentication and optional data-in-flight encryption. Avamar supports the X.509 v3 standard for formatting digital certificates.

Certificate acceptance workflow

Avamar uses a specific workflow when a client validates a server certificate and when a server validates a client certificate. Avamar obtains the FQDN and compares it to the CN field of the certificate. Avamar also checks for an IP address match in the list of IP addresses in the SAN field of the certificate. If there is no match (including wildcards), then the certificate is rejected and the connection terminated.

One-way authentication

With one-way authentication, the Avamar client requests authentication from the Avamar server, and the server sends the appropriate certificate to the client. The client then validates the certificate, using the certificate acceptance workflow.

Two-way authentication

When two-way authentication is enabled, the Avamar server provides authentication to the Avamar client and the Avamar client provides authentication to the Avamar server:

The Avamar client requests authentication from the Avamar server, and the server sends the appropriate certificate to the client. The client then validates the certificate, using the certificate acceptance workflow.

The Avamar server requests authentication from the Avamar client, and the client sends the appropriate certificate to the server. The server then validates the certificate, using the certificate acceptance workflow.

Usually, one-way authentication provides sufficient security. However, to provide an extra level of security, set up two-way authentication. Both configurations support data-in-flight encryption.

EMC Avamar

https://www.ietf.org/rfc/rfc3280.txt

https://www.ietf.org/rfc/rfc3280.txt

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2111411



Summary

The solution stack required to deliver hybrid cloud services must provide an easy means of centralized management so that the services can be securely managed and policies enforced.

This chapter described how an Enterprise Hybrid Cloud solution stack can be integrated with an enterprise PKI to ensure authenticity, strengthen authentication, and encrypt administrative communications.

Chapter 3: Converged Authentication


Chapter 3 Converged Authentication


Security and authentication ..................................................................................... 17

Active Directory integration ..................................................................................... 20

VMware Platform Services Controller ....................................................................... 21

TACACS+ authentication integration ........................................................................ 22

Summary .................................................................................................................. 22



Security and authentication

A significant challenge in securing any environment is the disparate, local authentication mechanisms, and differing account and password policies that are used in a solution environment. To address this challenge, Enterprise Hybrid Cloud uses Active Directory as a centralized identity management system for VMware, EMC, and VCE components. The solution also uses Kerberos, LDAPS, and Terminal Access Controller Access Control System Plus (TACACS+) authentication protocols to integrate each solution component with Active Directory and ensure that all authentication and authorization communications are encrypted.

Active Directory provides a single point of control for account management and policy enforcement. Figure 2 shows the hierarchy of authentication communication paths used in Enterprise Hybrid Cloud.



Figure 2. Authentication relationships between the solution components

Many of the systems and services that comprise an Enterprise Hybrid Cloud do not natively integrate with Active Directory but do support LDAPS integration when domain controllers are configured to enable such support. Active Directory exclusively uses a server authentication certificate in the ADDS certificate store for LDAPS connections.

There are important details to consider before you implement LDAPS. According to Microsoft:

Automatic certificate enrollment (auto-enrollment) cannot be used with certificates in the ADDS personal certificate store

Active Directory Domain Services



Current command-line tools do not allow certificate management of the ADDS personal certificate store

Certificates must be imported into the store and not moved through the certificates console

Installation of the server authentication certificate in the ADDS certificate store is only required on a server that has multiple certificates for server authentication in the local computer certificates store. If possible, the best solution is to have only one certificate in the local computer personal certificate store.

In a production environment, it is a security best practice to use service accounts to track and control applications and to mitigate the impact of a potential systems compromise.

The Integrated Windows Authentication (IWA) feature in Microsoft SQL Server provides better security than SQL Server authentication by taking advantage of Active Directory user security and account mechanisms. Enterprise Hybrid Cloud uses IWA for the SQL Server databases and service accounts for vCenter Server, vRealize Automation IaaS, and VMware vSphere® Update Manager™.

Integrated Windows Authentication

When an application connects through an Active Directory user account, SQL Server validates the account name and password using the Active Directory principal token in the operating system. This means that Active Directory confirms the user identity. SQL Server does not request the password and does not perform the identity validation.

Integrated Windows Authentication uses the Kerberos secure authentication protocol, and provides a centralized mechanism for account management, including password policy enforcement, account lockout, and password expiration. Integrated Windows Authentication offers additional password policies that are not available for SQL Server logins.

Microsoft SQL Server service accounts

Microsoft recommends isolating each SQL Server service under a separate, low-rights Active Directory or local user account. By using the principle of least privilege (POLP), this reduces the risk that one compromised service could be used to compromise other services.

During installation of SQL Server, you can configure the service account for each service. You can later use SQL Server Configuration Manager to manage or replace the accounts.

The hierarchy of accounts (from least privileged to most privileged) is:

1. Domain user (non-administrative)

2. Local user (non-administrative)

3. Network service account

4. Local system account

IWA and Microsoft SQL Server service accounts



5. Local user (administrative)

6. Domain user (administrative)

Account types 1 and 2 are preferred because they best encompass the principle of least privilege. Account type 3 is a shared account and any applications or services running under this account would potentially have access to each other’s data. Local system is a very high-privileged built-in account; it has extensive privileges on the local system and acts as the persona of the computer on the network. Account types 5 and 6 are less secure because they grant too many unneeded privileges. Enterprise Hybrid Cloud uses domain user (non-administrative) accounts.

Active Directory integration

The following solution components can be directly integrated with Active Directory:

VMware vRealize Log Insight

VMware vRealize Operations Manager

VMware vRealize Automation: Tenant identity stores

VMware vSphere ESXi hypervisor

EMC Avamar

EMC Data Protection Advisor

EMC VMAX®

EMC ViPR

EMC VNX®, EMC VPLEX®, EMC ScaleIO®

CloudLink SecureVM modular add-on for virtual machine encryption

We used Active Directory groups mapped to corresponding roles in each of these components. Membership of the Active Directory groups confers rights associated with the roles to administrative and end users.

Note: VPLEX does not currently support mapping of roles to either Active Directory or LDAP directory-based groups.

Enterprise Hybrid Cloud uses an Active Directory identity store to enable tenant integration with Active Directory. By default, authentication and authorization occur over LDAP. To enable LDAPS, you must import the CA chain into the Java cacerts keystore on the vRealize Automation virtual appliance. Use the ldaps:// protocol designator when specifying the identity store’s Active Directory URL.

Note: The protocol designator can be specified only when adding the identity store. To change from using ldap:// to ldaps://, you must delete the identity store and re-create it with the correct designator.

VMware vRealize Automation: Tenant identity stores



VMware Platform Services Controller

VMware Platform Services Controller (PSC) is an authentication broker and security token exchange solution that interacts with the enterprise identity store (Active Directory or OpenLDAP) on behalf of registered solutions to authenticate users.

The following solution components can be indirectly integrated with Active Directory through PSC SSO:



VMware vRealize Business for Cloud

VMware NSX for vSphere

EMC recommends using the PSC installed on Windows because it provides greater visibility, ease of management, and the ability to use a single namespace throughout the Enterprise Hybrid Cloud Automation Pod. The PSC also simplifies deployments at scale, and a dedicated PSC providing SSO services in the Automation Pod is mandatory for implementation of a disaster recovery architecture, where a multi-site PSC architecture is required.

The following solution components can be directly integrated with the PSC:

VMware vCenter Server



The following solution components can be indirectly integrated with SSO through vRealize Automation:

VMware vRealize Automation Application Services


Default tenant

The PSC provides SSO capability for vRealize Automation users. The native Active Directory identity store type has the following attributes:

Uses Kerberos to authenticate with Active Directory

Does not require a search base DN, making it easier to find the correct Active Directory store

Can be used only with the default tenant

When you have configured the default tenant’s identity store, you can add tenant administrators and infrastructure administrators. We recommend using Active Directory groups to assign these roles to vRealize Automation administrative users.

Tenant administrators are responsible for configuring tenant-specific branding, and for managing identity stores, users, groups, entitlements, and shared blueprints within the context of their tenant. IaaS administrators are responsible for configuring




infrastructure source endpoints in IaaS, appointing fabric administrators, and monitoring IaaS logs.

Non-default tenant

vRealize Automation 6 allows the definition of multiple tenants, and each tenant must be associated with at least one identity store. While identity stores can be OpenLDAP or Active Directory, Enterprise Hybrid Cloud uses Active Directory.

Optionally, you can configure the domain alias with a value that allows users to log in by using userid@domain-alias as a username instead, of userid@identity-store-domain. This value must be a unique value across all identity stores.

Tenant and infrastructure administrators must be configured for each tenant that is configured in vRealize Automation. We used Active Directory groups to assign these roles to hybrid cloud tenant administrative users.

TACACS+ authentication integration

TACACS+ provides an increased level of security through authentication, authorization, and accounting services and is a publicly documented TCP/IP protocol. TACACS+ encrypts credentials that are passed from the client device to the TACACS+ system and can be configured to use Active Directory as its authentication directory to enable centralized authentication.

Summary

The infrastructure solutions stack required to deliver hybrid cloud services must provide an easy means of centralized management, so that the services can be securely managed and policies enforced.

This chapter shows that integration with a common directory can be achieved to support LDAPS, Kerberos, and TACACS+ authentication services, streamline administration and policy enforcement, and provide tighter control over administrative and end user authentication.

Chapter 4: Centralized Log Management


Chapter 4 Centralized Log Management


Overview .................................................................................................................. 24

VMware vRealize Log Insight remote syslog architecture ........................................ 26

Centralized logging integration ............................................................................... 27

Content packs for VMware vRealize Log Insight ....................................................... 29

Configuring alerts .................................................................................................... 30

Summary .................................................................................................................. 34



Overview

Many key solution resources continuously record operational and security-related events to a local log. When a security incident occurs, log files can help you track down the root cause. However, without log file consolidation, investigating the root cause can be laborious and time consuming. Running a reliable and secure data center is a continual process of planning, delivering, and operating. Without a consolidated view of your infrastructure’s system log data, your data center is incomplete and at risk. The risks include:

Lack of central and holistic visibility into security-related events

Inability to easily correlate events that would indicate a security breach

Log files are overwritten causing you to lose log entries that are critical for security, compliance, and troubleshooting

Increased downtime for applications and servers, because more time is needed to locate and search system log files when problems occur

Security risks such as malicious attacks or unauthorized logins could be occurring without your knowledge

Loss of historical system logs, leaving you unprepared to report local authentications or maintain compliance

Consolidated system logging is a critical data center feature that is commonly not implemented because of its complexity. Many IT organizations rely solely on data center monitoring tools, which, while useful, mostly focus on raw metrics—such as CPU utilization, memory consumption, and storage I/O—but completely ignore log files and security events. When system log files are ignored, valuable security information is overlooked.

Every component in Enterprise Hybrid Cloud, and every virtual machine, including operating system and applications, generates numerous log messages per day. Troubleshooting and finding root causes for issues in the environment is challenging unless the logs can be aggregated and queried.

To address these challenges, Enterprise Hybrid Cloud uses VMware vRealize Log Insight to deliver real-time log management and analysis, with machine learning-based Intelligent Grouping and high-speed interactive search. vRealize Log Insight is a powerful security tool that consolidates logs across the entire Enterprise Hybrid Cloud and enables administrators to perform security auditing and compliance testing as well as log querying, aggregation, correlation, and retention.

vRealize Log Insight is tightly integrated with vCenter Server and ESXi and includes built-in knowledge and native support for vRealize Operations Manager. Alerts are configured to notify security administrators by email or through the vRealize Operations Manager dashboards. Figure 3 shows how vRealize Log Insight integrates with the components of Enterprise Hybrid Cloud for centralized logging.



Figure 3. Centralized logging of hybrid cloud components with vRealize Log Insight

Each component is configured to forward log messages to vRealize Log Insight using remote syslog. vRealize Log Insight then enables you to search for security events across all the consolidated data. For example, to search for logins across the infrastructure, you can search across all the components that make up Enterprise Hybrid Cloud, and view the results in a chart, as shown in Figure 4. Also, you can create and save your own custom queries and custom security dashboard.

Figure 4. Searching for security events with vRealize Log Insight



VMware vRealize Log Insight remote syslog architecture

For smaller instances of this hybrid cloud solution, every device for which you want to collect events is configured to send events directly to one or more vRealize Log Insight instances, as shown in Figure 5.

Figure 5. vRealize Log Insight client/server architecture

This client/server architecture is suited to environments that:

Are greenfield, with no syslog operations to date

Use automation or configuration management

Have fewer than 750 devices sending remote syslog data

For larger instances of this hybrid cloud solution, you can implement a distributed vRealize Log Insight deployment, with a master node and up to five worker nodes deployed in a cluster configuration, as shown in Figure 6. With this configuration, if any node goes down, the load balancer can redirect traffic to the remaining nodes.

Note: A worker node stores forwarded syslog events and processes queries against log data it stores on behalf of the master node.



Figure 6. vRealize Log Insight distributed architecture

For information on sizing vRealize Log Insight for this hybrid cloud solution, refer to the Enterprise Hybrid Cloud 4.0: Foundation Infrastructure Reference Architecture Guide.

Centralized logging integration

Unlike many syslog implementations that only support the User Datagram Protocol (UDP), vRealize Log Insight can receive syslog-formatted events over the UDP, TCP, and TLS protocols. In high volume environments, TCP provides a significant performance improvement over UDP. TCP supports more events over fewer connections and, because TCP is a lossless protocol, it minimizes message loss. TLS ensures that event details are transmitted over the network in a confidential manner.

vRealize Log Insight consolidates and archives all log data in Enterprise Hybrid Cloud and creates a historical record that enables:

Storage of events in sufficient detail and with accuracy

Retention of audit logs for a determined period consistent with the enterprise security policy

Identification of security incidents and policy violations as they occur

Auditing and forensic analysis

Establishment of baselines that can be used to detect future anomalous behavior



When data has been collected, you can use vRealize Log Insight to perform ad-hoc searches across all the event data. Figure 7 shows an example of successful logins by source query.

Figure 7. Example vRealize Log Insight dashboard for vCenter Server

You can save queries you perform often as Favorites and also use them to create charts, dashboard widgets, and alerts. In large environments with numerous log messages, you can use runtime field extraction with vRealize Log Insight to instantly locate and extract the most important data fields using regular expressions.

You should configure the following components of the hybrid cloud management platform to forward the application logs to vRealize Log Insight:

EMC ViPR

EMC VMAX

EMC VNX

EMC Avamar


VMware vSphere ESXi hosts




VMware vRealize Application Services


VMware vRealize Configuration Manager


VMware NSX for vSphere Manager


VMware vCenter Server


All physical compute, fabric, and network devices

Content packs for VMware vRealize Log Insight

Analysis of forwarded events can be enhanced using pre-packaged VMware, EMC, partner, and community-provided content packs, which are available on the VMware Solution Exchange.

Content packs are read-only plug-ins to vRealize Log Insight that provide predefined knowledge about specific types of events, such as log messages. A content pack provides knowledge about a specific set of events in a format that is easily understood by security administrators, monitoring teams, and auditors. Each content pack is delivered as a file, and can be imported through the vRealize Log Insight web UI.

The following content packs are available for components of Enterprise Hybrid Cloud:

EMC Avamar content pack

EMC VMAX content pack

EMC VNX content pack

vRealize Automation 6.1+ vRealize Log Insight content pack

vRealize Operations Manager content pack for vRealize Log Insight

VMware vSphere content pack (bundled with vRealize Log Insight)

Additional content packs for Microsoft Windows, Microsoft Active Directory, and other partner solutions

EMC content packs for Avamar, VNX, and VMAX provide dashboards and user-defined fields specifically for those EMC products and enable administrators to analyze problems on their VNX and VMAX arrays or backup infrastructure. Many of these content packs include dashboards with security-related charts and widgets that provide at-a-glance visibility into security-related events.

Custom dashboards and widgets can be manually created for components for which content packs do not already exist. Each widget provided by a content pack can be cloned and added to a personalized dashboard that contains only the views required

https://solutionexchange.vmware.com/store/loginsight

https://solutionexchange.vmware.com/store/loginsight



by the user. Figure 8 provides an example of this. It shows a custom vRealize Log Insight dashboard that presents Avamar backup failures, vCenter and Windows authentication failures, and ESXi host firewall changes. This dashboard was created using widgets cloned from the content packs installed for Enterprise Hybrid Cloud. Figure 9 shows another customized dashboard created from multiple content packs.

Figure 8. Custom vRealize Log Insight dashboard

Figure 9. Custom vRealize Log Insight security dashboard

Configuring alerts

Enterprise Hybrid Cloud uses vRealize Operations Manager to monitor the cloud management platform, compute resources, and tenant workloads used in production. vRealize Log Insight integration with vRealize Operations Manager enables you to raise alerts for vRealize Log Insight queries and send notifications to Operations Manager based on a configurable threshold, as shown in Figure 10.



Figure 10. vRealize Log Insight alert configured to send a notification to vRealize Operations Manager

You can also configure predefined alerts that are installed when content packs are imported to vRealize Log Insight. Figure 11 shows an example of a number of security-related alerts imported by the Microsoft Active Directory content pack.



Figure 11. Examples of security alerts installed in vRealize Log Insight

In addition, the integration between vRealize Log Insight and vRealize Operations Manager enables a Launch in context menu in the vRealize Operations Manager dashboard. You can use this menu to launch a vRealize Log Insight interactive analytics dashboard that displays events related to the selected vRealize Operations Manager object.

The example in Figure 12 uses the integration between Log Insight and vRealize Operations Manager in which the Actions menu in vRealize Operations Manager triggers a search of all relevant Log Insight information on the selected item.



Figure 12. Search logs for the cloud management platform directly from vRealize Operations Manager

The launch-in-context functionality filters the logs using the constraint hostname equals <each hostname>, which displays only events that match the specified criteria, as highlighted in Figure 13.



Figure 13. vRealize Log Insight filtering logs for the management cluster components

For a more detailed discussion of vRealize Operations Manager and the role it plays in Enterprise Hybrid Cloud, refer to the Enterprise Hybrid Cloud 4.0: Foundation Infrastructure Reference Architecture Guide and the companion Enterprise Hybrid Cloud 4.0: Concepts and Architecture Guide.

Summary

The integration of vRealize Log Insight in Enterprise Hybrid Cloud enables greater visibility into operational and security-related events.

This chapter described how vRealize Log Insight provides administrators with a single point of visibility into the environment and with alert notifications through email or vRealize Operations Manager. Where an organization already has a Security Information and Event Management (SIEM) system in place, Log Insight can act as an aggregator to forward events to the SIEM, providing the security team with a single integration point for the entire solution.

Chapter 5: Network Security


Chapter 5 Network Security


Overview .................................................................................................................. 36

Solution architecture ............................................................................................... 36

VMware NSX for vSphere .......................................................................................... 42

VMware NSX for vSphere extensibility with Palo Alto Networks firewalls ................ 44

VMware NSX firewall policy creation ........................................................................ 45

N-tier application considerations ............................................................................. 46

Cross-vCenter NSX ................................................................................................... 48

Use case 1: On-demand micro segmentation with security tags .............................. 49

Use case 2: Micro-segmentation with N-tier virtual applications ............................. 51

Use case 3: Micro-segmentation with converged N-tier virtual applications ............ 54

Use case 4: Micro-segmentation with App Isolation for component machines ......... 55

Summary .................................................................................................................. 56



Overview

This chapter discusses the security aspects of Enterprise Hybrid Cloud networking, introduces VMware NSX for vSphere, and demonstrates the value of NSX network and security integration in Enterprise Hybrid Cloud. Focusing on the network infrastructure and deployment options, the chapter details the key elements for creating a secure service offering and the processes required to implement and secure the network infrastructure. In addition, it includes common use cases for providing connectivity and security to dynamically provisioned application workloads.

Use this chapter as a reference to begin the networking and security planning and design process for your hybrid cloud and to set the stage for a successful implementation.

Solution architecture

Enterprise Hybrid Cloud requires an architecture that:

Is resilient to failure

Provides optimal throughput for workloads

Ensures multitenancy and secure separation

Figure 14 shows a logical representation of the hybrid cloud environment and highlights the management, network, and tenant compute pods and clusters.



Figure 14. Enterprise Hybrid Cloud environment

When designing the physical architecture, our main considerations were high availability, performance, and scalability. As shown in the example network topology in Figure 15, each layer of the physical architecture is fault tolerant, with physically redundant connectivity throughout. The loss of any one infrastructure component or link does not result in loss of service to the tenant; if the architecture is scaled appropriately, the loss of a component or link does not impact service performance.

Figure 15 also shows the connectivity between the physical storage, network, and converged fabric components deployed in Enterprise Hybrid Cloud.

Physical connectivity



Figure 15. Physical topology of the network

Virtual link aggregation

The network design uses IEEE 802.1AX virtual link aggregation (vLAG) trunks to provide seamless operation in the event of a hardware or link failure by enabling fault tolerance and high speed links between the distribution, access, and converged layers.

Note: Link aggregation (LAG) is variously known across vendors’ implementations as virtual port channels, split multi-link trunks, multi-chassis trunking, or multi-switch link aggregation.

vLAG trunks bundle multiple physical Ethernet links between two or more devices into a single logical link. If a physical link or switch fails, the traffic is automatically redistributed over the remaining physical links. Because multiple physical links are considered a single logical link in a vLAG trunk, physical link failures do not result in loops. If the status of a member link changes, vLAG prevents a service-interrupting spanning-tree recalculation and resulting convergence.

vLAG trunks also load balance traffic across all available links by using a load balancing algorithm to determine the physical port used. This provides an aggregate bandwidth equal to the sum of the bandwidth across all the physical links.



Configuring vLAG For vLAG trunks to function, you must cross connect one or more physical links between the distribution and access switches, and between the access and converged layer switches, as shown in Figure 15. vLAG trunks are dedicated to carrying the virtual local area networks (VLANs) and corresponding data. Typically, you should ensure that the 10 GbE ports used are in dedicated mode to avoid oversubscription issues and potential packet loss.

Depending on the vendor, a separate link that is not a member of the vLAG trunk might be required between each switch pair to synchronize state and prevent any packet duplication. This control link can be a Layer 2 or Layer 3 link between the switches. While the link typically does not carry regular network traffic, it is critical to the fault tolerant operation of the design. The control link does not have to be configured as a LAG, but having it configured as such provides fault tolerance. You can optionally configure the control link to sit in its own virtual routing and forwarding (VRF) table to enable reuse of the same control-link IP addresses on every pair of devices.

Physical network connectivity to the compute layer is provided over a converged network and Fibre Channel fabric to the fabric extenders on the compute blade chassis. Each link is capable of 10 Gb/s, which enables four 10 GbE network interfaces to be presented to each ESXi host.

The logical network topology for Enterprise Hybrid Cloud is designed to address the requirements of multitenancy and secure separation of the tenant resources. The topology is also designed to align with security best practices from vendors, such as VMware, that segment networks according to purpose or traffic type. For example, configuring an isolated network segment for VMware vSphere® vMotion® traffic between ESXi hosts helps prevent attacks in which the unencrypted transfer is intercepted by an attacker and reconstructed to gain access to potentially sensitive data.

Figure 16 shows the logical topology of the solution’s physical and virtual networks. We used VLANs to provide segmentation of the networks at Layer 2 in the cloud management pod (Automation Pod), because that environment is likely to be static and is an extension of existing management networks.

We configured the trunks on the physical network infrastructure to allow access by only the VLANs and private VLANs (PVLANs) required for operations within the hybrid cloud environment. This best practice helps to conserve valuable resources such as Spanning Tree Protocol (STP) logical interfaces. Each switch supports a limited number of STP logical interfaces, and this number can be used up before the VLAN limit is reached, especially in a multitenant environment. Therefore, pruning and carrying only the necessary VLANs can be of critical importance.

Logical network topology



Figure 16. Logical topology with the clusters, pods, and functional networks

We created a cloud management vSphere Distributed Switch (vDS) spanning the Automation Pod and Network Edge Infrastructure (NEI) Pod. We created a separate resource vDS spanning the Workload Pods. By doing so, we created a logical and physical boundary segmenting the management and tenant workload traffic flows and enabling a more focused approach to performance and security monitoring. Both vDSs were spanned to the NEI Pod to establish connectivity with the physical core.



Implementing a separate vDS for Workload Pods enables you to limit administrative access to the cloud management vDS, which will have comparatively few networks compared with possibly thousands of dynamic tenant networks. This configuration also makes it easier to establish a baseline for management traffic and identify flows that fall outside expected characteristics. A number of port groups are defined within the cloud management vDS to provide Edge connectivity for services such as backup and Active Directory.

We configured the resource vDS with a single port group for Edge connectivity. The remaining port groups on this vDS were created by NSX when the hosts were prepared for network virtualization. The VMware Virtual Extensible LAN (VXLAN) network segments (also called logical switches) were configured by the administrator through the Network and Security view in the vSphere Web Client.

VXLAN is an overlay technology for network virtualization that provides network abstraction, elasticity, and scaling across the data center. VXLAN provides an architecture for scaling your applications across clusters and pods without any physical network reconfiguration. With VXLAN, physical switches do not need to be reconfigured when a new VXLAN network is created. Instead, VXLAN virtual wires or networks can be deployed over a single or multiple transit VLANs. The decoupling of virtual networks from physical networks provides great flexibility and agility without requiring changes to or impacting the physical network. This enables rapid and dynamic provisioning of new networks at a theoretical scale of millions of VXLAN networks.

The fact that VXLAN overlays can be used to dynamically segment network traffic is of importance to the security posture of enterprise workloads. The scalability limitations of VLANs are no longer an impediment to segmenting mission-critical applications and creating as many trust zones as necessary.

The VXLAN port groups all share the same VLAN. This is one of the key benefits of implementing VXLAN. You can use one VLAN as the physical transport for VXLAN overlay networks. This reduces the required configuration of the ESXi host and top of rack (TOR) physical switches to a single VLAN and enables the virtual VXLAN networks to scale to 6,500 (assuming static port groups) per vDS.

To support infrastructure operations, EMC recommends configuring networking on each ESXi host throughout the environment to enable connectivity to the backup and vMotion networks. To do this, configure a VMkernel interface for NFS and vMotion on each ESXi host and create a port group for the Avamar proxy virtual machines on the cloud management vDS to complete the network connectivity.

The high levels of deduplication and compression provided by the Avamar system contribute to minimal data being sent across the LAN. However, as a best practice design for performance, availability, and security, use a dedicated network for the backup infrastructure, separate from the production networks, within which the Avamar server nodes and proxy virtual servers reside.

All Avamar proxy servers should be configured with an isolated PVLAN ID, with the result that they can communicate only with the Avamar server nodes and not with any

Overlay networks with VXLAN

Supporting infrastructure services

Network environment for data protection



other system on the backup network. The backup infrastructure resources are further protected by the isolation of the backup network from other Layer 3 networks. By separating production and backup data on the networks, an attacker who gains control of a virtual machine cannot compromise additional systems by using the backup network. Where communications must be allowed to enable the solution to function correctly—for example, for management of the Avamar system by backup administrators, and for control communications with EMC Data Protection Advisor, vRealize Automation, vRealize Operations Manager, and vCenter Server instances—a firewall mediates the access attempt and permits the connection if authorized.

In Enterprise Hybrid Cloud, access between the production network and the backup network is permitted only through a firewall policy that restricts access to the Avamar management and control planes to authorized administrators and orchestration processes only.

With improvements in server virtualization, network configuration has become a chokepoint of the provisioning process when new applications are being deployed. VXLAN overlay networks greatly simplify the configuration of physical networking equipment, while increasing the scale and speed of deploying new networks and logical switches.

A virtual application can be deployed in minutes. However, planning, designing, and configuring the network and security elements to support the application often can take days or weeks. Using the automation capabilities of vRealize Automation, NSX can significantly reduce the time required for the provisioning, update, and removal processes. Multiple networks and a router, a firewall, and a load balancer can be deployed dynamically with the virtual machine components of a blueprint. This capability enables the delivery of an application stack and supporting services to production users within minutes, including all the necessary network and security services.

VMware NSX for vSphere

VMware NSX offers additional functionality and improved performance. The additional functionality includes distributed logical routing, distributed virtual firewalling, logical load balancing, and support for routing protocols such as Border Gateway Protocol (BGP), Intermediate System to Intermediate System (IS-IS), and Open Shortest Path First (OSPF). NSX also provides substantial performance improvements in throughput, with logical routing and firewalling providing line-rate performance distributed across many hosts instead of being limited to a single virtual machine or physical host.

The NSX Distributed Logical Router (DLR) performs all East-West workload traffic routing at the hypervisor level. DLR ensures that as long as the workloads are on the same host, even if they are on different subnets, the traffic does not leave that host. If the workloads are on separate hosts, the traffic takes the optimal path directly from one host to the other, again without having to take a hairpin route through a virtual appliance or physical router in the data center core. This offers optimal traffic flows and significant performance gains.

Automation and provisioning

NSX Distributed Logical Router



The NSX Distributed Firewall (DFW), which is implemented as a hypervisor kernel module, eliminates the need to route traffic through virtual or external physical firewalls for inspection. Traffic is analyzed by the hypervisor when it leaves the source virtual machine virtual network interface card (vNIC) and before it enters the vNIC of the destination virtual machine. It is this enforcement at the vNIC level that enables East-West virtual machine separation. For more information, see N-tier application considerations.

Because NSX is integrated with vCenter Server, it can use the vCenter inventory and filter on more than just source and destination IP addresses or ports. Rules can be applied to virtual machines, security groups, clusters, and data centers. Security groups can also have dynamic membership, which enables rules to be applied based on virtual machine attributes such as guest operating system, virtual machine name, or security tags. Because inspection is performed at the hypervisor level, traffic does not have to be steered through and analyzed by another device or virtual machine on the network.

NSX Flow Monitoring provides a detailed view of historical and real-time traffic flows. These flows can be shown in aggregate, by service, or by virtual machine. The data can be used for troubleshooting performance issues, firewall misconfigurations, or rogue traffic on the network.

The NSX Logical Load Balancer (LLB) enables load sharing across a pool of virtual machines. It provides intelligent application monitoring, so that if a virtual machine in the pool stops responding, it is automatically taken out of the pool and no traffic is sent to it until it becomes responsive again. The load balancer can either be deployed as a service on an Edge appliance that acts as the network gateway, or in “one-arm” mode, where it has a single interface on the network and is not the gateway. It can support throughput of up to 9 Gb/s and 130 k connections per second. The load balancer can also be deployed in High Availability (HA) mode.

Inside NSX, the Service Composer is a built-in tool that defines a new model for consuming network and security services; it allows you to provision and assign firewall policies and security services to applications in real time in a cloud data center. Security policies are assigned to groups of virtual machines, and the policy is automatically applied to new virtual machines as they are added to the group.

NSX Service Composer integrates with third-party security services. These services can identify virtual machines on the network that are infected with malware, or with known vulnerabilities, and place them into a quarantine security group that restricts the virtual machines until the issue is resolved.

Security groups

A security group is a collection of assets or grouping objects from the vSphere inventory. The grouping feature enables you to create custom containers to which you can assign resources, such as virtual machines and network adapters, for distributed firewall protection. After a group is defined, you can add the group as source or destination to a firewall rule for protection.

NSX Distributed Firewall

NSX Flow Monitoring

NSX Logical Load Balancer

NSX Service Composer

Security groups, security policies, and security tags



The dynamic mapping capability of security groups allows you to define the criteria that an object must meet for it to be added to a security group you are creating. This enables you to include virtual machines in a security group by defining a filter criterion that can be selected from a range of attributes. For example, you might include a criterion to add all virtual machines that run a specific operating system such as Microsoft Windows 2003.

Security policies

A security policy is a set of endpoint, firewall, and network introspection services that can be applied to a security group. During vRealize Automation data collection, the security policies that have been defined in NSX appear in the Security tab. From there, the tenant administrator or business group manager can assign security policies to selected component machines. For example, you could apply a Web security policy to a Web component.

Security tags

Security tags are additional, customizable criteria that you can use to create security policies. Tags can be manually created and assigned to virtual machines, or they can be added to virtual machines dynamically. Certain third-party software that integrates with NSX can also consume and update these tags. For example, an anti-virus application could label a virtual machine with the tag ANTI_VIRUS.VirusFound.threat=high. This tag could then be included in a firewall rule that automatically blocks all traffic to or from the tagged virtual machine.

VMware NSX for vSphere extensibility with Palo Alto Networks firewalls

Because NSX for vSphere is a networking option with Enterprise Hybrid Cloud, you can use the integration developed by VMware and Palo Alto Networks to expand your cloud capabilities. Integrating VMware NSX and Palo Alto Networks VM-Series firewalls with Enterprise Hybrid Cloud extends the protections offered by NSX for vSphere to your physical data center.

With the integrated VMware and Palo Alto Networks solution, you can access an advanced security feature set that:

Protects north-south and east-west traffic and offers software-defined networking with VMware NSX and the Palo Alto Networks VM-Series

Maintains dynamic context-based policies across:

NSX security groups

Palo Alto Networks dynamic address groups

Addresses simplified security and compliance mandates with protection against known and unknown threats including exploits, viruses, spyware, malware, and advanced persistent threats (APTs)—for example:

Reduces attack surface with application whitelisting

Blocks known threats using an integrated Intrusion Prevention System (IPS)

Blocks unknown threats by using Palo Alto Networks Wildfire



Centralizes management and automation:

Common firewall management with Palo Alto Networks Panorama

Automated deployment with NSX and Panorama

For information on how to integrate the VM-Series from Palo Alto Networks with NSX for vSphere, refer to the Next Generation Security with VMware NSX and Palo Alto Networks VM-Series technical white paper on the VMware.com website.

VMware NSX firewall policy creation

The traditional model of firewall rule creation is based on network traffic sources and destinations defined using the IP addresses of relevant hosts (and virtual machines), groups of IP addresses, or the subnets containing groups of IP addresses. This model can require a significant amount of preparation and administration when IP addresses change.

NSX goes beyond this model by providing multiple additional options for defining firewall rule sources and destinations. Because NSX can understand virtual machine attributes, you can create rules based on criteria such as virtual machine names, virtual machine operating systems, and descriptive tags. These non-IP based rules simplify the creation, organization, and maintenance of rules. They also enable a more simplified set of security rules.

Here are some examples of rules you can create with NSX:

The source of the network traffic is defined as all virtual machines where the guest OS is Windows, and the destination is a local patching/update server

Virtual machines whose name contains the term application-server can be reached only from virtual machines whose name contains the term web-server

Criteria are combined using the AND or OR condition—for example, the guest OS must be Windows AND the virtual machine name must contain the term application-server

This method of rule creation directly supports the micro-segmentation model described in N-tier application considerations.

The NSX model of rule creation is inherently dynamic, supporting the rapid elasticity that is a main benefit of embracing the hybrid cloud. As virtual machines that match the rule criteria are added, they automatically inherit the correct security policies. When virtual machines are removed, there is no need to edit the security policies accordingly.

With the first rule example described in Multiple firewall rule criteria, any new virtual machines created where Windows is the guest OS will automatically match the rule and be able to reach the patch server; no update of the policy is required to enable that network communication. With the second example, the groups of web server and application server virtual machines can be dynamically scaled up and down as

Multiple firewall rule criteria

Dynamic rules

http://www.vmware.com/



capacity needs dictate, and the correct network communications are inherited automatically.

With NSX, any virtual machine can also be manually included or excluded with a rule that also has defined virtual machine criteria.

N-tier application considerations

N-tier architecture is a technique used by software developers to split components of an application to allow greater flexibility and modularity. A three-tier architecture typically consists of a presentation layer, a logic layer, and a storage layer. This architecture is commonly used for web applications, with web servers in the presentation layer, application and middleware components in the logic layer, and databases in the storage layer.

Security practitioners have adopted the three-tier model for best practices, because it fits well with the principle of least privilege. Granular security controls can be applied to allow only the minimum required network traffic through to each tier. For the web application example, best practices allow end-user traffic to reach the web servers only, using only required services such as HTTP/HTTPS. Network traffic to the application servers is similarly restricted to traffic from the web servers on specific ports. Traffic to the database servers is allowed only from the application servers to the ports used by the database servers. In a typical physical data center, these restrictions are achieved through Layer 3 separation of the tiers. This requires a different subnet for each tier and firewalls between the tiers that allow only the required traffic through, as shown in Figure 17.

Figure 17. Traditional three-tier security architecture

The three-tier model is easily configured with NSX. However, because NSX firewall rules are enforced at the vNICs of each virtual machine, NSX provides increased flexibility for segmenting virtual machines. With NSX, web servers, application servers, and database servers can sit next to each other within a flat Layer 2 subnet, yet still have granular rules segmenting them from each other. This model can simplify the network organization of applications by, for example, providing a single class C subnet for each application.

Another benefit of this NSX model is the ability to achieve full application containerization. In the physical world, often all web servers in a DMZ can see and

Traditional three-tier architecture



talk to each other, even if they are not part of the same application. This is also true of application servers in a protected zone, and of database servers, which are often placed into an internal core network for licensing reasons (exposing the rest of the internal core network if a database server is compromised from the outside). With NSX, all tiers of an application can be fully containerized to ensure that if an application is compromised by an attacker at any tier, the attacker cannot pivot beyond the application to attack other applications or hosts within the same network zone.

While the three-tier application model is prevalent, some applications are designed to be split into only two tiers. These applications generally combine the presentation and logic layers, while keeping the database tier separate. This model is becoming more common in applications developed using frameworks such as Ruby on Rails and certain Python frameworks. In other cases, a web server might only be used for specific capabilities, such as single sign-on, because using a separate server or virtual machine would be wasteful.

Frequently, an enterprise security team forces an application into a three-tier architecture, often artificially creating a public-facing tier in a DMZ with a reverse proxy for web applications. This can become a source of contention between the security team, who is trying to ensure the best possible protection of the data, and the development team, who is trying to deliver an application as inexpensively and efficiently as possible. Many two-tiered applications do not easily lend themselves to being forced to a three-tiered implementation. Also, in reality, inflating an application to three tiers, and using the web tier as a proxy for all traffic through to an application tier, does not offer significantly better security; however, applying extra controls in the web proxy tier can help improve security further—for example, installing the ModSecurity application on top of Apache for additional web traffic inspection.

In a physical data center where multiple applications are present across network tiers, and databases might be contained in an internal or private zone, the extra protection provided by a three-tier architecture is well warranted. In the cloud, however, the ability of NSX to containerize applications and limit potential exposure in the event of a compromised application reduces the need to artificially inflate two-tier applications to three tiers. While certain applications with sensitive data might still require the extra protection of the three-tier model, NSX enables many applications to be run in two tiers as originally designed, without many of the risks associated with bridging network zones. Often the operational issues introduced by the increased complexity of the three-tier model far out-weigh the enhanced security posture. Figure 18 shows an example of a two-tiered security architecture applied to a virtual application.

Two-tier applications



Figure 18. Two-tiered application secured with micro-segmentation

Cross-vCenter NSX

Enterprise Hybrid Cloud permits the use of cross-vCenter NSX and universal objects in all Site Recovery Manager-based disaster recovery protection services. This feature allows multiple NSX managers to be joined together in a primary/secondary relationship, as described in Enterprise Hybrid Cloud 4.0: Concepts and Architecture Guide.

These cross-vCenter network and security components are referred to as “universal” and can only be managed on the primary manager. Some network and security objects are not universal, and are referred to as standard or local objects and must be managed from their associated NSX manager. Replication of universal objects takes place from the primary NSX managers to the secondary managers so that each manager has the configuration details for all universal objects. This allows a secondary NSX manager to be promoted if the primary NSX manager fails.

The universal distributed logical router (uDLR) and the universal logical switch (uLS) are used to span networks and east-west routing across vCenters. There is a single primary NSX manager and a single universal controller cluster in a federated NSX environment, so the placement and protection of these components must be considered carefully. The primary NSX manager will be connected to one of the cloud vCenters in Enterprise Hybrid Cloud. The universal controller cluster can only be deployed to clusters that are part of that cloud vCenter. When considering the placement of the primary NSX manager and the universal controller cluster, if Enterprise Hybrid Cloud uses VPLEX to support continuous availability single site protection, ensure that the primary NSX manager and the universal controller cluster are VPLEX protected.



When cross-vCenter NSX is utilized within an Enterprise Hybrid Cloud environment, vRealize Automation has some limitations when deploying and managing workloads in Enterprise Hybrid Cloud. These limitations are noted below.

The uDLR and the uLS span networks and east-west routing across vCenters. uDLRs offer centralized administration and a routing configuration that can be customized at the universal logical router, cluster, or host level. uLSs allow Layer 2 networks to span multiple sites.

When you create a universal logical router, you must choose whether to enable local egress, as this cannot be changed after creation. Local egress allows you to control what routes are provided to ESXi hosts based on an identifier, the locale ID.

Note: When you create a logical switch in a universal transport zone, you create a universal logical switch. This switch is available on all clusters in the universal transport zone. The universal transport zone can include clusters in any vCenter in the cross-vCenter NSX environment.

Each cross-vCenter NSX environment has one universal controller cluster associated with the primary NSX Manager. Secondary NSX Managers do not have a controller cluster.

The distributed firewall in a cross-vCenter NSX environment allows centralized management of rules that apply to all vCenter Servers in your environment.

From the primary NSX Manager, you can create a distributed firewall rule section that is marked for universal synchronization. You can create one universal Layer 2 rule section and one universal Layer 3 rule section. These sections and their rules are synchronized to all secondary NSX Managers. Rules in other sections remain local to the appropriate NSX Manager.

Universal network and security objects can be created only from the primary NSX Manager.

Universal security groups can contain only universal IP sets, universal MAC sets, and universal security groups. Membership is defined by included objects only. You cannot use dynamic membership or excluded objects.

Universal security groups cannot be created from Service Composer. Security groups created from Service Composer are local to that NSX Manager.

Note: Because of these limitations and the version of vRealize Automation used in this version of Enterprise Hybrid Cloud, use of universal security objects is not supported.

Use case 1: On-demand micro segmentation with security tags

In a cloud environment, application workloads are provisioned, moved, and repurposed on demand. With NSX Service Composer (available only in NSX for vSphere), security can be easily organized by dissociating the assets you want to

Universal network objects

Universal controller cluster

Universal firewall rules

Universal security objects



protect from the policies that define how you want to protect them. NSX security groups define which assets to protect; NSX security policies define how the assets are protected. You map a security policy to a security group to apply the security policy criteria to members of the security group. Figure 19 shows the relationship between a security group and a security policy.

Figure 19. Security group relationship with security policies

This use case demonstrates how to use NSX security tags to configure dynamic membership for a security group and define IF/THEN workflows across security services. By defining a security tag and mapping it to a security group, any virtual machines with that tag are immediately and automatically added to the security group.

For example, IF a user selects a Finance application, THEN the application virtual machines are automatically added to the Finance security group, in real time. The workflow for implementing this example is as follows:

1. The security administrator predefines a security group (Finance) and a security policy (Finance Policy), with dynamic membership based on a security tag (Finance), as shown in Figure 20.

Figure 20. Security Admin persona defines the Finance Policy

2. The cloud administrator creates a multimachine blueprint and sets the Finance tag for one of the component blueprints (Finance App), as shown in Figure 21. The cloud administrator needs no knowledge of security groups or security policies to do this.



Figure 21. Cloud Administrator persona configures the Finance tag on the blueprint

3. In the service catalog, an end user requests the Finance App application, which is attached to the multimachine template, as shown in Figure 22.

Figure 22. Cloud consumer requests the protected Finance App

4. The application virtual machines are deployed. The virtual machine based on the Finance App blueprint is dynamically assigned to the Finance security group, as shown in Figure 23. As a member of the Finance security group, the virtual machine automatically inherits the security policies that are mapped to that security group.

Figure 23. Security tag relationship with security groups

Use case 2: Micro-segmentation with N-tier virtual applications

A three-tier application can be used to demonstrate the network and security provisioning capabilities of NSX when integrated with vRealize Automation. The web tier, serving web pages to users, is external facing and load balanced. Each web server communicates with the application server, and the application server in turn writes to and retrieves data from the database server.

The virtual machines are assigned to their respective security groups by the vRealize Automation blueprint. The security groups are associated with security policies (firewall rules) that are enforced by the NSX DFWs. The deployed virtual machines in each tier inherit their specific security policy based on their security group

Overview



membership. This ensures that applications are protected from the moment of deployment.

Figure 24 shows an example of a three-tiered application implemented with micro-segmentation.

Figure 24. Three-tiered application implemented with micro-segmentation

In this example, we used Service Composer to create three security groups, one for each application tier, as shown in Figure 25.

Figure 25. Service Composer view of the security groups

We created the following security policies (firewall rules) for the security groups:

The web-tier policy allows external connectivity on ports 80 and 443 to virtual machines in the Web Servers security group.

NSX security groups and security policies



The application-tier policy allows connectivity from the virtual machines in the Web Servers security group to the virtual machines in the Application Servers security group.

The database-tier policy allows connectivity from the virtual machines in the Application Servers security group to the database virtual machines in the Database Servers security group.

We applied the security policies to their respective security groups. For example, we applied the Web Server Security Policy to the Web Servers security group, as shown in Figure 26.

Figure 26. Web Server Security Policy applied to Web Servers security group

The completed security policies allow access to virtual machines in the web-tier security group over the HTTP and HTTPS protocols, allow the web-tier virtual machines to communicate with the application-tier virtual machines, and allow the application-tier virtual machines to store and retrieve data from the database tier.

The NSX firewall is a stateful firewall, so when a connection is allowed and a communication session established, the response communication path is also allowed. All other inbound or outbound traffic is denied by the block rules at the end of the rule set. Like a traditional firewall, rules are applied sequentially from top to bottom.

For the use case, we created three single-machine blueprints, one for each component of the three-tier application (web, application, and database), and combined them in a pre-provisioned multimachine blueprint, as shown in Figure 27.

Figure 27. Multimachine blueprint showing single machine components

Pre-provisioned multimachine blueprint



We edited each component blueprint and mapped the network adapter to the corresponding security groups, as shown in Figure 28. In this example, there is only one network adapter.

Figure 28. Blueprint network and security group configuration

We then published the blueprint and added it to the service catalog. From there, users can select the blueprint to provision new application virtual machines. Based on the blueprint, vRealize Automation clones the virtual machines and attaches them to their respective logical switch network segments. It also adds the provisioned virtual machines to the appropriate security groups.

For the use case, we did not assign any members to the groups and we did not configure any dynamic criteria for assigning members to the group. vRealize Automation automatically assigns the virtual machines, when provisioned, to the security groups specified in the blueprint.

Use case 3: Micro-segmentation with converged N-tier virtual applications

As demonstrated in Use case 2: Micro-segmentation with N-tier virtual applications, micro-segmentation enables significantly greater control and security in your network. However, we can take this a step further. Often, micro-segmentation removes the need for a network segment per tier; therefore, you can implement a converged architecture, as shown in Figure 29.



Figure 29. Converged three-tiered application secured with micro-segmentation

You can use the process described in Use case 2: Micro-segmentation with N-tier virtual applications to define the security groups and policies for the converged infrastructure. In fact, you can use the same groups and policies. The only difference in the multimachine blueprint configuration is that you assign the same network profile to the component machine network adapters. As a result, the three tiers are provisioned to the same network segment.

Use case 4: Micro-segmentation with App Isolation for component machines

vRealize Automation App Isolation uses the logical firewall to prevent all inbound and outbound traffic to component workloads in a multimachine blueprint. When App Isolation is enabled for a multimachine blueprint, the component machines in the blueprint can communicate with each other but cannot connect outside the firewall, as shown in Figure 30.

Figure 30. Perimeter security enabled by App isolation



When a multimachine service is provisioned with App Isolation, vRealize Automation creates a security group corresponding to the multimachine service and assigns the component machines as members of that security group. The NSX security policy called vRealize Automation App Isolation Policy is created and applied to the security group. The firewall rules are defined in the security policy to allow only internal traffic.

The vRealize Automation App Isolation Policy has a lower precedence than other security policies in NSX. For example, if a multimachine service contains a Web component machine and an App component machine, and the Web component machine hosts a Web service, then the service must allow inbound traffic on ports 80 and 443. In this case, you must create a web-tier security policy in NSX with firewall rules defined to allow incoming traffic to these ports, and you must apply the security policy on the Web component of the multimachine blueprint. If the Web component machine needs access to the App component machine using a load balancer on ports 8080 and 8443, the security policy must also include firewall rules to allow outbound traffic to these ports.

Application Isolation provides an optional first level of security. When enabled, all inbound and outbound application access is blocked, while inter-application traffic is permitted. Component-level security policies are applied at a higher precedence to permit selected traffic.

Summary

This chapter outlined the network architecture of Enterprise Hybrid Cloud, the design considerations for the network environment, and recommended security best practices. It also described how we implemented the network and security architecture for the solution using NSX for vSphere.

The three-tier application use cases demonstrated both traditional and converged N-tier architectures, with micro-segmentation implemented to enhance the security posture. NSX and vRealize Automation enable flexible creation and deployment of workload resources, while providing richer functionality and improved performance over traditional solutions.

Chapter 6: Configuration Management


Chapter 6 Configuration Management


Overview .................................................................................................................. 58

VMware vCenter Server host profiles ....................................................................... 58

VMware vSphere Update Manager ........................................................................... 61

VMware vRealize Configuration Manager ................................................................. 65

Use case 1: Configuring a custom compliance standard ........................................... 68

Use case 2: Applying exceptions to compliance templates ...................................... 70

Summary .................................................................................................................. 71



Overview

Enterprise Hybrid Cloud Security Management applies the recommendations in the vSphere 6.0 Hardening Guide as well as security configuration recommendations from EMC and other vendors. Integrating security guidance from multiple sources requires coordination. EMC engineering has developed processes to manage this integration and provide a secure, seamless, experience for Enterprise Hybrid Cloud customers. The tools that underpin these processes ensure that the relevant security configurations are in effect to assure adherence with electronic governance, risk, and compliance (eGRC) requirements and with your organization’s internal IT and security standards.

Configuration management is a vital element of implementing secure systems consistently and in accordance with your security policies. It comprises a collection of steps focused on establishing a configuration baseline to maintain the integrity of Enterprise Hybrid Cloud and the resources it supports.

Many organizations’ IT and security groups face a significant challenge in gaining visibility into configuration management and compliance in their environments. To address this challenge, Enterprise Hybrid Cloud uses a number of native capabilities, including:

vCenter host profiles ensure that a baseline is applied consistently across all ESXi hosts, and enable many vSphere hardening guidelines to be centrally applied. They also provide a means to perform ad-hoc scans for host compliance with a profile and display alerts within the vSphere Web Client.

vSphere Update Manager enables patch management across virtual appliances and ESXi hosts and provides a means to install and update third-party software on ESXi hosts. With Update Manager, you can establish a baseline and ensure audit compliance.

vRealize Configuration Manager extends the capabilities of vCenter host profiles and vSphere Update Manager to provide inventory and asset management, scheduled configuration and compliance scans, reports, and integration with vRealize Operations Manager. In addition, vRealize Configuration Manager enables configuration management of Windows and Linux guest OS patches, and can audit the entire virtualized environment against many industry or regulatory frameworks and standards.

VMware vCenter Server host profiles

vCenter Server host profiles ensure that a consistent configuration is applied across all ESXi hosts when Enterprise Hybrid Cloud is initially deployed and as it is scaled out to meet future capacity requirements. Specifically, host profiles:

Ensure consistency for compliance

Reduce the deployment time for new hosts

Apply the same configuration changes to multiple hosts



To apply the same configuration settings to a group of ESXi hosts, you can create or import a host profile. The host profile is associated with a single reference host. A new or updated profile is established through the reference host, and propagated to the other hosts in the environment through the host compliance tool.

When events occur that require storage, network, or security configuration changes on multiple hosts in a cluster—firmware upgrades, for example—you can edit the host profile and apply it across the cluster for consistent configuration updates. In addition, you can exclude from the host profile any host configuration values that need to be unique across your environment. Figure 31 shows some of the parameters that can be configured in a host profile.

Figure 31. Host profile configuration parameters

When the host profile has been created and configured, you can attach it to one or more vSphere hosts or clusters. The configuration of each host is then compared against the host profile and any deviations are reported. For example, Figure 32 shows a non-compliant status for one of the hosts in one of the clusters in the test environment.



Figure 32. Host compliance status with the host profile

The additional host profiles shown in Figure 33 correspond to other clusters in the test environment that have different vDS configurations and demonstrate that you can have multiple host profiles according to your configuration requirements.

Figure 33. Compliance view of the clusters attached to the Resource Pods host profile

Note: You may associate ESXi hosts and clusters with a single host profile only.



You can configure new hosts that are added to vCenter Server by applying the appropriate host profile. This configuration management feature enables you to create a profile once, and then use it for rapid configuration of multiple vSphere hosts. This feature also eliminates the need to set up specialized scripts or to manually configure hosts.

You can create scheduled tasks that will routinely check host compliance against a host profile, email the results, and log a vCenter Server event. You can view the compliance status in the vSphere Web Client by selecting the host profile and selecting Monitor, as shown in Figure 33.

When compliance checks return a non-compliant status, a vCenter error event is generated and can be tracked in vRealize Operations Manager. While vRealize Operations Manager is outside the scope of this security guide, it is discussed in detail in the Enterprise Hybrid Cloud 4.0: Infrastructure and Operations Management Guide.

VMware vSphere Update Manager

Patch management is a core requirement of security compliance standards that require that all system components and software are protected from known vulnerabilities by having the latest vendor-supplied security patches installed. The Payment Card Industry Data Security Standard (PCI DSS) is one such standard. Organizations that are unable to patch systems effectively and efficiently are susceptible to compromises that are easily preventable. Consider patch management carefully in the context of security, because it is important in establishing and maintaining a solid security baseline.

Enterprise Hybrid Cloud uses VMware vSphere Update Manager to address patch management and keep vSphere hosts and virtual appliances up to date. Update Manager automates patch management and eliminates manual tracking and patching of vSphere hosts and virtual appliances.

vSphere Update Manager includes these core features:

A compliance dashboard to provide visibility into the patch and upgrade status of hosts and virtual appliances, for compliance to static or dynamic baselines

Stage and schedule patching for remote sites and scheduled maintenance windows

Deployment of patches that are downloaded directly from a vendor website, including drivers, Common Information Models (CIMs), and other updates from hardware vendors for vSphere hosts

Patching can lead to compatibility errors that require remediation. Update Manager can eliminate the most common patching problems before they occur, ensuring that the time you save in batch processing automation is not wasted later in performing rollbacks.



The benefits of vSphere Update Manager include:

Storing snapshots for a user-defined period, so that administrators can roll back the virtual machine if necessary

Securely patching offline virtual machines without exposing them to the network, reducing the risk of non-compliant virtual machines

Ensuring the current version of a patch is applied with automatic notification services

vSphere Update Manager compares the state of vSphere hosts with baselines, and can then stage and apply patches to enforce compliance. Dynamic baselines update dynamically as vendors release additional patches. Fixed baselines are statically defined and are used for upgrades. Extension baselines are statically defined. Figure 34 shows examples of configured baselines.

Figure 34. Examples of baselines configured in vSphere Update Manager

A good example of a dynamic baseline is the Critical Host Patches baseline that ships with vSphere Update Manager. We configured the inclusion criteria for this baseline to include any patch of severity Critical, from any vendor and for any product, as shown in Figure 35.

Baselines



Figure 35. Example of patch inclusion criteria for an Update Manager baseline

The inclusion criteria are granular; you can include or exclude individual patches, giving you the flexibility to define a custom baseline specific to your environment. In addition, you can include non-VMware extensions, such as EMC PowerPath®/VE extensions, in a custom baseline, as shown in Figure 36.

Figure 36. EMC PowerPath/VE extension added to a custom Update Manager baseline



Custom baselines enable you to deploy non-VMware extensions to all your ESXi hosts and ensure that consistent revision control is maintained throughout your environment.

Baselines can be grouped together and included in a baseline group, as shown in Figure 37.

Figure 37. Components of the EHC Hosts baseline group

Baseline groups are useful for applying multiple baselines to virtual appliances, hosts, clusters, or data center objects, and are especially useful when you audit compliance, because the compliance status can be viewed across the group of baselines instead of individually for each baseline.

The vSphere Update Manager Host Compliance view in the vSphere Web Client provides a quick overview of your compliance status. For example, if 50 percent of the hosts in the selected group are out of compliance. The affected baseline group and individual baselines are red flagged as non-compliant, and the type of update is also red flagged on the affected host.

To rectify this situation, click Remediate to start the Remediation wizard. From there, the appropriate baseline can be applied to the affected assets.

You can schedule the remediation for a later time and date. This is useful when you are restricted to a maintenance window and want to combine a scheduled remediation with the staging feature to ensure you meet your maintenance window requirements.

Baseline groups

Audit compliance



The Remediation wizard also enables you to select host remediation options, including the virtual machine power state and the disabling of any removable media mounted to virtual machines on the hosts to be remediated.

Selecting the Enable parallel remediation option can significantly reduce the time to remediate by running the remediation tasks in parallel on clusters with two or more hosts and according to the resources in demand on the cluster at the time of remediation. When remediating a vSphere cluster with DRS enabled, all workloads remain available throughout the remediation process.

VMware vRealize Configuration Manager

The security status of each cloud system changes dynamically. These changes might be caused by a cloud administrator operation introducing risk into the environment, cloud components that are susceptible to a vulnerability, or an external environment change such as a new attack method. It is important to continuously monitor the security status of Enterprise Hybrid Cloud, mitigate or remediate the potential risks, and keep the system compliant to a security baseline.

In Enterprise Hybrid Cloud, we integrated VMware vRealize Configuration Manager to build a configuration compliance audit and management system.

vRealize Configuration Manager provides a unified dashboard for managing configuration compliance. It integrates with vSphere for configuration data collection. This enables the vSphere infrastructure and its dependent components to be audited, exceptions to policy flagged, and remediation performed.

Preset rules and templates are available that enable you to begin monitoring system compliance to various standards, as shown in Figure 38:

Regulatory standards—for example, Sarbanes-Oxley (SOX), Health Insurance Portability and Accountability Act (HIPAA), Gramm-Leach-Bliley Act (GLBA), Federal Information Security Management Act (FISMA)

Industry standards—for example, PCI DSS

Microsoft standards

Configuration compliance



Figure 38. View of the vRealize Configuration Manager compliance dashboards showing vSphere hardening compliance

Examples of elements that can be tracked for compliance are:

Hypervisor configuration through vCenter Server host profiles

Hypervisor and virtual appliance patch management through vSphere Update Manager baselines

Linux and Windows guest OS configuration

Regulatory and industry standards through default compliance toolkits

Configuration compliance can be maintained against internal standards, security best practices, vendor hardening guidelines, and regulatory mandates such as:

Security best practices developed by the Defense Information Systems Agency (DISA STIGs), the National Institute of Standards and Technology (NIST), the Center for Internet Security (CIS), and many more

Hardening guidelines from VMware and Microsoft

Regulatory mandates such as SOX, the PCI standard, HIPAA, and FISMA

You can also use vRealize Configuration Manager to assess compliance with your own internal IT standard to drive best practices in your environment.

The integration between vRealize Operations Manager and vRealize Configuration Manager includes using compliance template results from Configuration Manager to contribute to the Risk badge score in vRealize Operations Manager, as shown in Figure 39.

Risk badge and compliance scores



Figure 39. vRealize Operations Manager dashboard displaying Risk badge score

The compliance templates are included in badge mappings that are run in Configuration Manager against objects in vCenter Server instances that are managed by both Configuration Manager and vRealize Operations Manager. These objects include virtual machines, host systems, clusters, vCenter Server instances, and datastores. The compliance mapping results determine the compliance score. Expanding the Why is Risk option shown in Figure 39 displays the compliance status summary shown in Figure 40.

Figure 40. vRealize Operations Manager dashboard showing compliance status summary

vRealize Operations Manager pulls the compliance scores into the formulas used to calculate the Risk badge scores. When you review the standards compliance in vRealize Operations Manager, you can navigate back to Configuration Manager to view the detailed results and identify any configuration changes that you must make to bring a non-compliant object back into compliance.

Operational compliance views enable you to proactively enforce configuration standards, detect configuration drift early, and automatically remediate against IT

Operational compliance



policy violations. You can also harden the infrastructure for security and regulatory requirements. Preparing for and responding to an audit is no longer an intimidating and time consuming process because, with automated reporting, you can pinpoint critical areas with ease. Compliance views are tightly integrated with the operations dashboard for comprehensive visibility into the health, risk, and efficiency of the infrastructure and applications, as shown in Figure 41.

Figure 41. Risk dashboard showing compliance status in the environment

Use case 1: Configuring a custom compliance standard

Configuring a custom compliance standard includes creating compliance rules, rule groups, and templates. Compliance templates consist of one or more rule groups, each of which contain one or more rules and filters. When you run compliance, you are running templates.

Compliance rules compare your virtual or physical machines (running Linux, UNIX, Mac OS X, or Windows operating systems) against configuration standards that you import or create, to determine if the machines meet the standards. The results of the compliance run identify which machines comply with or are in violation of the standards. In some cases, you can enforce certain settings on the machines that are not in compliance, initiating the changes from vRealize Configuration Manager.

In the example for this use case, we created a rule group that checks whether VMware Tools™ is running in guest virtual machines that are included in the inventory of the two hybrid cloud vCenter Server instances. We then created a compliance template and added the rule group to it.



The process is as follows:

1. In the vRealize Configuration Manager console, create a new rule group.

2. Add a compliance rule to the rule group with the following attributes, as shown in Figure 42:

Rule type: Conditional

IF criterion:

IF Tools Version Status <> ‘guestToolsNotInstalled’

This excludes virtual machines that do not have VMware Tools installed.

THEN criterion:

THEN Tools Running Status = ‘guestToolsRunning’

This checks whether VMware Tools is running.

Figure 42. Rule criteria for detecting the running state of VMware Tools

Severity: Moderate

3. Add a filter to the rule group to exclude guests that are not in the inventory of one or other of the two hybrid cloud vCenter Server instances. This filter has the following attributes, as shown in Figure 43:

Data type: Basic

Conditions:

vCenter =’EPCIP-VC01’

vCenter =’EPCMP-VC01’

Figure 43. Filter criteria for detecting the running state of hybrid cloud vCenter Server instances



4. Create a new compliance template and add the rule group to it.

5. Run the template to view the compliance data results and verify the configuration. Figure 44 shows a results summary view.

Figure 44. Summary of the custom compliance template results

Use case 2: Applying exceptions to compliance templates

To override specific template results, you can use exceptions rather than explicitly resolving non-compliant results. The exceptions are applied against the compliance template results and indicate that a specific result is compliant or non-compliant even though it does not match the rule requirements. Examples of where exceptions may be necessary include:

Avamar image-level backup and restore. Avamar uses the http feature in vCenter Server to backup or restore virtual machines—this feature is called Http datastore

Cloud Foundry requires that the Managed Object Browser (MOB) is enabled on the vCenter Server system or deployments of Cloud Foundry will fail

Disabling the http Datastore Browser and MOB features in accordance with vSphere hardening guidelines would break critical functionality. Exceptions are used so that results are not skewed. The template to which you want to apply an exception must



already exist. Refer to the VMware Security Hardening Guides for vSphere 6.0 for more information.

Summary

This chapter outlined the native configuration management and compliance capabilities of Enterprise Hybrid Cloud. It detailed how configuration consistency can be achieved through the implementation of vCenter host profiles, patch management using vSphere Update Manager, and configuration compliance using vRealize Configuration Manager.

The chapter examined the configuration of each feature, and outlined two use cases that showed how to configure a custom compliance standard and how to create compliance exceptions where a business need exists.

The chapter demonstrated how the Enterprise Hybrid Cloud configuration can be protected, audited, and visibility enabled using tools that are native to the solution.

http://www.vmware.com/security/hardening-guides.html

Chapter 7: Multitenancy


Chapter 7 Multitenancy


Overview .................................................................................................................. 73

Secure separation .................................................................................................... 73

Role-based access control ....................................................................................... 75

Summary .................................................................................................................. 77



Overview

Valid concerns exist around information leakage and unauthorized access on a shared infrastructure. Consumers of the provisioned resources need to operate in a dedicated environment while still benefiting from infrastructure standardization. To address concerns around shared infrastructure, Enterprise Hybrid Cloud was designed for multitenancy, with a defense-in depth perspective that is demonstrated through:

Secure separation

Network segmentation and separation

Tenant authentication

Role-based access control

Solution infrastructure

Entitlements

This chapter introduces the mechanisms that Enterprise Hybrid Cloud uses to address multitenancy security.

Secure separation

The network infrastructure for the solution is designed to address the requirements of multitenancy and secure separation of the tenant resources. It is also designed to align with security best practices, from vendors such as VMware, for segmenting networks according to the purpose or traffic type. For example, configuring an isolated network segment for vMotion traffic between ESXi hosts helps prevent attacks where the unencrypted data transfer can be intercepted by an attacker and reconstructed to gain access to sensitive data.

We configured the trunks on the physical network infrastructure to carry only the VLANs and PVLANs required for operations within the hybrid cloud environment. Figure 45 shows the logical topology of the physical and virtual networks defined in Enterprise Hybrid Cloud. We used VLANs to provide segmentation of the networks at Layer 2 in the cloud management pod, because that environment is likely to be static and an extension of existing management networks.

Note: The architecture can be supplemented at the physical switch layer with PVLANs and VRF tables to provide segmentation at Layers 2 and 3. This approach is outside the scope of Enterprise Hybrid Cloud.

Network segmentation



Figure 45. Enterprise Hybrid Cloud network architecture

To enable connectivity between the physical network core and the tenant resources, we deployed an enterprise Edge router and a tenant Edge router in HA mode for each tenant.

We implemented an NSX ESR to act as a perimeter gateway for the Enterprise Hybrid Cloud tenants, and applied a perimeter security policy. Where more than one tenant was required, we isolated each tenant by implementing an NSX ESR per tenant. This enabled us to manage security policies for the entire Enterprise Hybrid Cloud environment from a single interface.

Note: An existing Layer 3 core can provide the function of the enterprise Edge router. The use of an NSX appliance for this function is not prescriptive.

Tenants can use a common single directory with separation provided by dedicated OUs. However, where secure multitenant authentication is required, a much more robust solution is to use a dedicated directory for each tenant to provide authentication for the tenant application owners and consumers.

Tenant and enterprise Edge routers

Tenant authentication



VMware vRealize Automation identity stores

Enterprise Hybrid Cloud uses a native Active Directory identity store for the default tenant in vRealize Automation. This identity store uses Kerberos authentication with Active Directory. Each newly created tenant must be associated with at least one Active Directory or Open LDAP identity store. Configure each tenant identity store using one of the following options:

In the same directory as other tenants

In the same directory as other tenants, but using a dedicated OU per tenant

In a separate and distinct directory

This configuration enables degrees of separation according to the risk profile of the business assets provisioned and managed by the solution and according to the organization’s appetite for risk.

EMC ViPR authentication providers

Enterprise Hybrid Cloud maps tenants to ViPR Projects. Each ViPR Project must be associated with an authentication provider. Authentication providers can be configured to use Active Directory or an LDAP directory. You can configure each authentication provider to use:

The same directory for all projects

A separate and distinct directory for each project

Each ViPR Project must be configured with an ACL that maps groups or users to the All (read-write) or Backup (read-only) ViPR Project roles.

Role-based access control

The integration of the solution components with Active Directory enables the mapping of each component’s local roles to corresponding Active Directory groups for the purposes of administration, operation, and auditing.

While access to the solution infrastructure components is limited to IT and security administrators, end users use vRealize Automation as a self-service catalog and to manage their provisioned resources. User roles and responsibilities are defined and used in the structure of vRealize Automation. The administration of users and compute resources in vRealize Automation is managed through the vRealize Automation portal.

The main vRealize Automation roles are:

System administrator

Infrastructure administrator

Fabric administrator

Tenant administrator

Service architect

vRealize Automation groups and roles



System administrator

The system administrator ([email protected]) is responsible for:

Tenant creation, system defaults, branding, and tenant Simple Mail Transfer Protocol (SMTP) relays

Assigning the infrastructure administrator and tenant administrator roles to Active Directory users and groups

Infrastructure administrator

The infrastructure administrator (IaaS admin) is a system-wide role that is responsible for:

Discovery and management of the compute, network, and storage resources used to provision workloads

Defining the vRealize Automation endpoints that are required to discover and interact with the infrastructure resources in the physical, virtual, and public cloud environments

Creating and configuring the fabric groups, assigning the fabric administrator role to Active Directory users and groups, and adding discovered compute resources to bring them under vRealize Automation control

Fabric administrator

Fabric groups can be used to segregate the resources used by different organizational groups. Fabric administrators can manage cloud resources for their respective fabric groups, as defined by the IaaS administrator.

Fabric group administrators are responsible for:

Configuring resource reservations to be consumed by each business group

Defining network, storage, compute, and cost profiles

Defining approval groups and policies

Tenant administrator

The tenant administrator role is responsible for configuring tenant-specific branding and user management, including:

Creating business groups and assigning the business group manager, support, and user roles to Active Directory or OpenLDAP users and groups

Managing and configuring catalog services, entitlements, approval policies, and shared blueprints within the context of their tenant

Tracking resource usage by all the tenant’s users and initiating reclamation requests to decommission unused virtual machines



Business groups

Business group users are the consumers of the infrastructure provided to the business group by a fabric group administrator:

The Business Group Manager role can perform some of the same functions as the tenant administrator, such as authoring new services, managing provisioned virtual machines, managing approval requests, and working on behalf of other users. However, the scope of their responsibility is limited to their respective business groups.

The Support User role can provision and manage resources on behalf of other users, but cannot author new services.

The User role is assigned to those users who request and manage resources made available to their business group.

Users with the User role are the primary consumers of the vRealize Automation self-service portal, which they use to provision and manage their virtual machines. The deployment of machine blueprints might be subject to approval by the Business Group Manager. The business group manager sets this approval policy per blueprint.

Enterprise Hybrid Cloud also uses business groups to provision infrastructure services and corporate application platforms (for example, Microsoft SQL Servers, Exchange Servers, and Oracle Servers), and to provide access to service blueprints that automate repetitive administrator tasks. These resources and functions are typically used by administrators and applications owners to meet their functional requirements.

Service architect

The service architect is responsible for authoring advanced services such as service blueprints, custom resources, and resource actions. The service architect can also perform catalog management functions.

Note: vRealize Automation is configured to use Active Directory (or OpenLDAP) as an identity source, so vRealize Automation roles are mapped to Active Directory groups that correspond to existing enterprise teams, as described in vRealize Automation Installation and Configuration. Additional user groups can be created in Active Directory and assigned to support the various roles in vRealize Automation.

Entitlements are a vRealize Automation construct, similar to access control lists (ACLs), designed to grant access to machine and service blueprints to specific business group users or groups. In addition, entitlements are the implementation point for approval policies. vRealize Automation entitlements can be used to restrict certain users to a defined view of the service catalog, permitting them access only to the machine and service blueprints that they require to fulfill their function.

Summary

This chapter discussed ways to segment the network infrastructure, storage, and authentication on a tenant-by-tenant basis. It also discussed how the solution implements RBAC to separate functions and enforce the principal of least privilege.

Entitlements



The chapter detailed the various roles vRealize Automation uses to provide separation of duties at the infrastructure, service definition, and consumption layers and how entitlements can be used to control access to the self-service catalog. This demonstrates the multitenant capabilities of Enterprise Hybrid Cloud, enabling organizations to confidently and securely provision service offerings to their consumers.

Chapter 8: Data Security


Chapter 8 Data Security


Overview .................................................................................................................. 80

CloudLink SecureVM ................................................................................................ 80

Policy-based management ....................................................................................... 81

Integration with the service catalog ......................................................................... 82

Summary .................................................................................................................. 82



Overview

The protection of information assets, whether located in an on-premises or off-premises cloud, is of paramount concern to enterprises and their customers. There are many threats to the confidentiality and integrity of information that could result in a reputational, financial, or human impact through the disclosure of commercially sensitive or personally identifiable information (PII) and other critical data. This chapter discusses how you can use CloudLink SecureVM with Enterprise Hybrid Cloud to enhance protection of your most sensitive data.

CloudLink SecureVM

Cloud computing offers undeniable benefits in relation to deployment flexibility and agility, scaling, and cost-effective resource utilization. However, the strengths and benefits of cloud computing must be balanced against the loss of control and visibility in cloud deployments. CloudLink SecureVM provides organizations with the security controls necessary to run virtual machines in the cloud with confidence.

SecureVM enables encryption of the entire virtualized server or desktop running in the cloud, independent of the cloud service provider. Protection of the entire virtual machine enables organizations to define security policies to allow or disallow startup of a particular virtual machine, and to verify the integrity of the virtual machine. This provides complete protection against potentially malicious tampering. SecureVM ensures that only trusted and verified virtual machines have the ability to run and to access sensitive data residing in the cloud.

Platform support

SecureVM works in combination with native OS encryption technology such as Microsoft BitLocker—a proven and high-performance volume encryption solution widely implemented for physical machines. SecureVM extends BitLocker functionality because BitLocker native authentication mechanisms are not supported in cloud environments. The SecureVM proven encryption key policy management functionality enables BitLocker to be used for automated encryption of boot volumes in the cloud, while enabling enterprise administrators to control security policy and encryption keys. SecureVM also supports Linux native encryption, providing organizations with a single encryption management solution for multiple clouds and virtual machine operating systems.

SecureVM operates transparently to end users across virtually any private, public, hybrid, or multicloud environment. Fully integrated with leading hypervisor and cloud platforms, it is easy to deploy with almost limitless scalability. CloudLink provides control, flexible policy- and key-management options, and reporting and monitoring capabilities across different operating systems, virtual machines, and storage infrastructures.

CloudLink can unlock and make use of the tried and trusted native encryption of Windows and Linux operating systems.



Policy-based management

From CloudLink Center, you can define encryption policies and manage individual virtual machines on which SecureVM Agent is deployed. For example, you can configure the IP addresses from which virtual machines can start automatically, or require interactive authorization to boot volumes, decrypt volumes, and block individual virtual machines from starting up automatically. In addition to IP addresses, a number of other virtual machine attributes are verified by CloudLink Center—for example, the checksum of the pre-boot environment, which must match the previous known-good checksum to assure users that the software has not been tampered with while a virtual machine was not running. For information about deploying SecureVM Agent, refer to the CloudLink SecureVM Deployment Guide.

When a virtual machine starts up, CloudLink Center checks that certain conditions are met before allowing the startup to continue. One of the conditions that CloudLink Center checks is that the virtual machine IP address has been identified as authorized to CloudLink Center. You can view the current list of valid IP addresses in the Approved Networks list.

You can define IP addresses as authorized to CloudLink Center by:

IP: to specify a single IP address

CIDR: to specify a network of IP addresses using Classless Inter-Domain Routing

IP Range: to specify a range of consecutive IP addresses

When a virtual machine starts up, CloudLink Center checks if the virtual machine IP address has changed since the last startup process. By default, if the IP address has changed, startup is not allowed to continue automatically, and the virtual machine is assigned the Pending status. You must manually approve the virtual machine start up, either using CloudLink Center or through the Enterprise Hybrid Cloud self-service interface.

There may be circumstances in which you know that the IP addresses of virtual machines might change. For example, in some cloud environments, such as Microsoft Azure, the public IP address of a virtual machine might change when the machine shuts down and restarts. A new IP address is assigned from the same subnet as the previous address. To avoid having to manually confirm startups in these circumstances, you can change the global policy to approve automatically. You can also limit automatic approvals to virtual machines with a new IP address that is on the same subnet as the previous IP address. At any time, you can change the global policy back to the default condition. The global policy applies only to virtual machines with IP addresses identified as authorized.

For Windows and Linux virtual machines, you can encrypt the unencrypted boot partition. You can also encrypt Windows virtual machine data disks or Linux virtual machine mounted devices on an individual basis.

Defining authorized IP addresses for virtual machines

Changing the global policy for virtual machine start up

Encrypting virtual machine volumes



For example, when deploying SecureVM Agent to a Windows virtual machine, you might have applied a volume encryption policy that encrypted only the boot partition. After deployment, you can encrypt the virtual machine data disks individually. After initiating encryption, you can monitor progress on the virtual machine in the virtual machine console. You can also view progress in the virtual machine panel on the SecureVM tab of CloudLink Center.

You can decrypt a Windows or Linux virtual machine encrypted boot partition. You can also decrypt Windows virtual machine data disks or Linux virtual machine mounted devices on an individual basis.

For example, before removing a virtual machine that you no longer want to be under SecureVM control, you must decrypt the volumes if you want to continue using the virtual machine. Otherwise, the volumes remain encrypted and therefore inaccessible.

You can decrypt volumes (boot partition and data disks) from the Enterprise Hybrid Cloud self-service interface. After initiating decryption, monitor progress on the virtual machine console. You can also view progress in the virtual machine panel on the SecureVM tab of CloudLink Center.

You can change the volume encryption policy that you selected during SecureVM Agent deployment. For information, refer to the CloudLink SecureVM Deployment Guide.

For example, if the volume encryption policy applied during SecureVM Agent deployment was Boot and Manual Data, only the boot partition is encrypted. No data disks are encrypted during deployment and any data disks added after deployment must be manually encrypted while the initial policy is in effect. You can change to the All Data policy, so that data disks added to the virtual machine are automatically encrypted.

Changing the volume encryption policy does not affect the boot partition or any existing data disks. The new policy is applied only when data disks are added to the virtual machine.

Integration with the service catalog

CloudLink SecureVM encryption is integrated with the service catalog, allowing encryption of both new and existing workloads. A catalog blueprint can easily be created, cloned, or modified, whereby the CloudLink build profile is attached to create an encrypted catalog item. Day two operations are also available to apply encryption to an existing virtual machine or workload. Virtual disk encryption policies are applied programmatically based on workload location and requestor selection.

Summary

This chapter discussed using CloudLink SecureVM with Enterprise Hybrid Cloud to enhance protection of your most sensitive data. CloudLink SecureVM allows you to

Decrypting virtual machine volumes

Changing the volume encryption policy for a Windows virtual machine



control, monitor, and secure your Windows and Linux virtual machines everywhere in your hybrid cloud. This chapter also discussed policy-based management, service catalog integration, and encrypting workloads.

Chapter 9: Conclusion


Chapter 9 Conclusion

This chapter presents the following topic:

Summary .................................................................................................................. 85

Chapter 9: Conclusion


Summary

Enterprise Hybrid Cloud drives business agility and reduces cost by providing users self-service access to traditional IT services and enterprise applications, from private or public clouds with the service levels they choose. A one-of-a-kind converged platform; it combines best of class technologies, software purpose-built to accelerate business outcomes, with professional services and single contact support. Enterprise Hybrid Cloud automates delivery of secure, always-on infrastructure for traditional enterprise applications. Built on hundreds of thousands of engineering hours, it makes delivering hybrid cloud simple, starting with the foundation for IaaS and add-on options to deliver ITaaS.

Chapter 10: References


Chapter 10 References


Enterprise Hybrid Cloud documentation ................................................................... 87

Enterprise Hybrid Cloud security documentation ..................................................... 87

Other documentation ............................................................................................... 88



Enterprise Hybrid Cloud documentation

The following guides, available on EMC.com, provide information about various aspects of Enterprise Hybrid Cloud:

Enterprise Hybrid Cloud 4.0: Concepts and Architecture Guide

Enterprise Hybrid Cloud 4.0: Administration Guide

Enterprise Hybrid Cloud 4.0: Infrastructure and Operations Management Guide

Enterprise Hybrid Cloud 4.0: Foundation Infrastructure Reference Architecture Guide

Enterprise Hybrid Cloud security documentation

Enterprise Hybrid Cloud has been secured by implementing the recommendations in the product security guides from EMC and VMware listed in Table 2.

Table 2. Product security guides

Publication Description

EMC documentation

EMC Product Security White Paper

P/N H13230

Describes how EMC embeds security in the company’s product development, deployment, and maintenance practices, as well as in its supply chain.

EMC VNX Series

Security Configuration Guide for VNX

P/N 300-015-128 REV 04

Provides information about features and configuration options that are available for configuring secure system operation and storage processing. The guide explains why, when, and how to use these security features.

EMC Symmetrix

Security Configuration Guide

REV 02

Describes how to securely deploy, use, and maintain EMC Solutions Enabler version 7.6 and Unisphere for VMAX version 1.6.

EMC ViPR Controller Version 2.4

Security Configuration Guide

P/N 302-002-412 REV 01

Provides an overview of security configuration settings available in EMC ViPR, secure deployment and usage settings, and secure maintenance and physical security controls needed to ensure secure operation of ViPR.

EMC Avamar 7.3

Product Security Guide

P/N 302-002-859 REV 01

Provides an overview of the settings and security provisions that are available in Avamar to ensure secure operation of the product.

EMC Avamar 7.2 Extended Retention

Security Guide

P/N 302-001-941 REV 01

Describes how to configure security features for the Avamar extended retention feature.

https://www.emc.com/collateral/white-papers/product-security.pdf

https://www.emc.com/collateral/TechnicalDocument/docu48491.pdf



http://www.emc.com/collateral/TechnicalDocument/docu46991.pdf

http://www.emc.com/collateral/TechnicalDocument/docu46991.pdf

https://support.emc.com/docu62086_ViPR_Controller_2.4_Security_Configuration_Guide.pdf?language=en_US

https://support.emc.com/docu62086_ViPR_Controller_2.4_Security_Configuration_Guide.pdf?language=en_US

https://support.emc.com/docu69635_Avamar-7.3-Product-Security-Guide.pdf

https://support.emc.com/docu69635_Avamar-7.3-Product-Security-Guide.pdf

https://support.emc.com/docu59599_Avamar-7.2-Extended-Retention-Security-Guide.pdf

https://support.emc.com/docu59599_Avamar-7.2-Extended-Retention-Security-Guide.pdf



Publication Description

EMC Data Domain Product Security Guide

P/N 302-002-097 REV 04

Describes the key security features of EMC Data Domain systems and provides the procedures required to ensure data protection and appropriate access control.

VMware documentation

VMware Product Security: An Overview of VMware’s Security Programs and Practices

Describes VMware’s approach to security for virtualization software products and solutions.

VMware vRealize Configuration Manager Security Guide

Describes how to harden vRealize Configuration Manager for secure use.

vSphere Security ESXi 6.0 vCenter Server 6.0

Provides information about securing your vSphere environment for VMware vCenter Server and VMware ESXi.

vSphere 6.0 Hardening Guide Provides guidance for hardening the following vSphere components:

Virtual machines

ESXi hosts

Virtual networks

vCenter Server and its database and clients (includes common vCenter and Windows-specific guidance)

vCenter Web Client

VMware PSC

vCenter Virtual Appliance (VCSA)

VMware vRealize Log Insight Security Guide

Provides a reference to the security features of vRealize Log Insight.

VMware NSX for vSphere Network Virtualization Design Guide

Provides an overview of the VMware NSX network virtualization platform.

VMware NSX for vSphere 6 Documentation Center

Provides information about installing, configuring, and using NSX.

Hardened Appliance Operations Guide

Addresses the site‐specific technical requirements required to meet Security Technical Information Guides (STIG).

Other documentation

VCE Foundation for EMC Enterprise Hybrid Cloud Addendum 4.0

VCE Foundation Upgrade from 3.1 to 3.5 Process

VMware vRealize Automation Installation and Configuration

Next Generation Security with VMware NSX and Palo Alto Networks VM-Series

CloudLink SecureVM Version 5.0 Deployment Guide for Enterprise

https://support.emc.com/docu61791_Data-Domain-Product-Security-Guide.pdf?language=en_US

https://support.emc.com/docu61791_Data-Domain-Product-Security-Guide.pdf?language=en_US

http://www.vmware.com/files/pdf/VMware-Product-Security.pdf



http://www.vmware.com/pdf/vcenter-configuration-manager-55-security-guide.pdf

http://www.vmware.com/pdf/vcenter-configuration-manager-55-security-guide.pdf

https://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-security-guide.pdf

https://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-security-guide.pdf

https://www.vmware.com/files/xls/vSphere_6_0_Hardening_Guide_GA_15_Jun_2015.xls

http://pubs.vmware.com/log-insight-33/topic/com.vmware.ICbase/PDF/log-insight-33-security-guide.pdf

http://pubs.vmware.com/log-insight-33/topic/com.vmware.ICbase/PDF/log-insight-33-security-guide.pdf

https://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf

https://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf

https://www.vmware.com/support/pubs/nsx_pubs.html

https://www.vmware.com/support/pubs/nsx_pubs.html

http://www.vmware.com/files/pdf/techpaper/VMWare-Hardened-Appliance-Operations-Guide.pdf

http://www.vmware.com/files/pdf/techpaper/VMWare-Hardened-Appliance-Operations-Guide.pdf

http://pubs.vmware.com/vra-62/topic/com.vmware.vra.install.doc/GUID-3CABD137-CC9A-41E4-BCB4-65A0D5919270.html

https://www.vmware.com/files/pdf/products/nsx/NSX-Palo-Alto-Networks-WP.pdf

https://support.emc.com/docu61816_CloudLink-SecureVM-5.0-Deployment-Guide-for-Enterprise.pdf?language=en_US



Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (RFC 5280)

How to Request a Certificate With a Custom Subject Alternative Name (Microsoft TechNet)

LDAP over SSL (LDAPS) Certificate (Microsoft TechNet)

https://tools.ietf.org/html/rfc5280

https://tools.ietf.org/html/rfc5280


http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

Appendix A: Enterprise Hybrid Cloud Security Data


Appendix A Enterprise Hybrid Cloud Security Data

This appendix presents the following topics:

Security data ............................................................................................................ 91



Security data

The tables in this chapter provide information on security data for Enterprise Hybrid Cloud.

Table 3. Application and management interface APIs

Product API Document Part number or location


REST EMC Data Protection Advisor REST API Reference

EMC Online Support

EMC ViPR REST EMC ViPR Controller REST API Developer Guide

302-000-496

VMware NSX-V REST NSX vSphere API Guide EN-001545-04


REST vSphere Web Services SDK Programming Guide

EN-001153-00

VMware Site Recovery Manager

REST Site Recovery Manager API Developer’s Guide

EN-001401-00

VMware SSO SDK REST vCenter Single Sign-On Programming Guide

EN-001413-00


REST Using the vCenter Orchestrator REST API

VMware vSphere 6.0 Documentation Center


vSphere VMware vSphere Management SDK



REST Using Application Services REST APIs

EN-001652-00


REST Programming Guide EN-001636-01


REST VMware vRealize Log Insight Developer's Guide

EN-001660-00

VMware ESXi vSphere VMware vSphere Management SDK


VMware vSphere® Web Services SDK

REST Developer’s Setup Guide

Note: CloudLink SecureVM includes a comprehensive set of REST APIs. For documentation about these APIs, see About, REST Documentation in the CloudLink Center contents pane.

EN-001154-02



Table 4. Authentication mechanisms and integration

Enterprise Hybrid Cloud component Active Directory Exceptions

EMC Avamar Y MCCLI

EMC Data Domain Y

EMC Data Protection Advisor Y

Enterprise Hybrid Cloud modules

EMC Storage Analytics Y

EMC ViPR Y

EMC ViPR Analytics Y

Microsoft SQL Server Y

Microsoft Windows Server Y


VMware vSphere ESXi Y

VMware vRealize Log Insight Y

VMware vCenter Server (for Windows)


VMware vRealize Operations Manager Y



Table 5. Log capability matrix for vRealize Log Insight or similar solution (such as Q-Radar)

Enterprise Hybrid Cloud component Format

EMC Avamar syslog/file

EMC Data Domain syslog/file

EMC Data Protection Advisor API/WinRM/file

Enterprise Hybrid Cloud modules via vCenter vRealize Orchestrator

EMC RecoverPoint® syslog/file

EMC ViPR syslog/file

EMC ViPR SRA (for Windows) API/WinRM/file

Microsoft SQL Server API/WinRM/file

Microsoft Windows Server API/WinRM/file

VMware vRealize Business for Cloud syslog/file



Enterprise Hybrid Cloud component Format

VMware NSX-V syslog

VMware vCenter Server (for Windows) API/WinRM/file

VMware Site Recovery Manager API/WinRM/file

VMware vRealize Automation syslog/file

VMware vRealize Log Insight syslog/file

VMware vRealize Operations Manager syslog/file

VMware vRealize Operations Manager Adapters via vRealize Operations Manager

VMware vRealize Orchestrator syslog/file

VMware vRealize Orchestrator Plugins via vRealize Orchestrator

VMware vSphere ESXi syslog/file

Table 6. Operating systems in use in Enterprise Hybrid Cloud CMP

System component Operating system OS type

EMC Avamar Proxy SLES 11 SP1 Bare metal

EMC Avamar Server SLES 11 SP1 Bare metal

EMC Data Domain DDOS 5.5.0.9 Bare metal

EMC Data Protection Advisor Windows Server 2012 SP1 Guest

EMC ViPR SLES 11 SP3 Appliance

Microsoft SQL Server Windows Server 2012 SP1 Guest

VMware vCenter Server (for Windows) Windows Server 2012 SP1 Guest


SLES 11 SP3 Appliance

VMware vRealize Automation SLES 11 SP3 Appliance

VMware vRealize Business for Cloud SLES 11 SP2 Appliance

VMware vRealize Log Insight SLES 11 SP3 Appliance

VMware vRealize Operations Manager SLES 11 SP2 Appliance

VMware vRealize Orchestrator SLES 11 SP3 Appliance

VMware vSphere ESXi ESXi 5.5.2b Bare metal

Table 7. Ports in use in EMC Avamar Server

Application and services Protocol Port Direction

ECHO TCP/UDP 7




SSH TCP 22 Both

NTP TCP/UDP 123 Both

Client downloads/DTLT TCP 80/443 Inbound

Avamar Installer (TLS) TCP 8543

GSAN TCP/UDP 19000-19500




Avamar Server TCP 27000 Inbound

Avamar Server TLS TCP 29000 Inbound

avagent TCP 28002

Table 8. Ports in use in EMC Data Protection Advisor


Data Protection Advisor Agent

TCP 3741 Inbound

Data Protection Advisor Application Server

TCP 9002 Inbound

Data Protection Advisor Datastore Server

TCP 9003 Inbound

HTTP TCP 9004 Inbound

HTTPS TCP 9002 Inbound

MANAGEMENT_NATIVE TCP 9999 Inbound

MANAGEMENT_HTTP TCP 9005 Inbound

MESSAGING TCP 5445 Outbound

MESSAGING_THROUGHPUT TCP 5455 Outbound

OSGI TCP 8090 Outbound

REMOTING TCP 4447 Outbound

TXN_RECOVERY TCP 4712 Outbound

TXN_STATUS TCP 4713 Outbound



MANAGEMENT_NATIVE TCP 57600 Inbound




MANAGEMENT_HTTP UDP 5445 Inbound

MESSAGING UDP 7500 Outbound

MESSAGING_THROUGHTPUT UDP 9876 Outbound

OSGI UDP 45700 Outbound

REMOTING UDP 45688 Outbound

TXN_RECOVERY UDP 45689 Outbound

Table 9. Ports in use in EMC PowerPath/VE licensing appliance


SSH TCP 22 Both


DNS UDP 53 Outbound

License Reporting TCP 443 or 8443 Inbound

Table 10. Ports in use in EMC SMI-S_ECOM


EMC Solutions Enabler TCP 2707 Inbound

Event daemon TCP Dynamic Inbound

EMC VNX TCP 443 or 2163 Inbound

SMI-S Provider TCP 5988 Inbound

SMI-S Provider (TLS) TCP 5989 Inbound

Table 11. Ports in use in EMC Unisphere for VMAX


Storage management server

TCP 80, 443, 2162, 2163 Inbound

Host agent TCP 6389 Outbound

SMTP TCP 25, 465, or 587 Outbound

Storage processor agent TCP 6389 Outbound

RemotelyAnywhere Host TCP 9519, 22 Outbound

LDAP Server TCP 389 Outbound

LDAP over SSL/TLS Server TCP 636 Outbound




iSNS Server TCP 3205 Outbound

VNX OE for Block TCP 3260 Inbound

Storage management server

UDP 2162 Outbound

Unisphere Storage System Initialization Utility

UDP 2163 Outbound

NTP Server UDP 123 Both

SMTP Traps UDP 162 Outgoing

ESXi or Virtual Center Server

TCP 443 Outbound

Table 12. Ports in use in EMC VIPR


ECHO UDP 7 Inbound

SSH TCP 22 Both

SMTP TCP 25 Outbound

NTP UDP 123 Both

SNMP UDP 162 Outbound

HTTPS TCP 443 Both

ConnectEMC FTPS 990 Outbound

SMI-S Provider TCP 5988 Outbound

SMI-S Provider (TLS) TCP 5989 Outbound

ViPR Controller user interface TCP 6443 Inbound

CIM adapter TCP 7012 Inbound

RecoverPoint API (TLS) TCP 7225 Outbound

Authentication service TCP 7443 Inbound

API service TCP 8443 Outbound

VASA TCP 9083 Inbound

sys service TCP 9993 Both

syssvc CLI download (unauthenticated)

TCP 9998 Both



Table 13. Ports in use in Microsoft SQL Server


SQL Server TCP 1433 Both

Dedicated Admin Connection TCP 1434 Inbound

SQL Server named instance UDP 1434 Both

SQL Server Analysis Service TCP 2383 Inbound

Connection request to a named instance of Analysis Services

TCP 2383 Both

Transact-SQL debugger and SQL Server Integration Services

TCP 135 Both

Table 14. Ports in use in VMware NSX Manager



HTTP TCP 80 Inbound

Messaging TCP 1234 Inbound

Messaging UDP 56711 Outbound

SSH TCP 22 Both

Table 15. Ports in use in VMware vRealize Operations Manager


SSH TCP 22 Both

HTTP TCP 80 Inbound


Table 16. Ports in use in VMware vRealize Orchestrator




Web configuration HTTPS access port

TCP 8283 Inbound

Messaging port TCP 8286 Inbound

Messaging port TCP 8287 Inbound




LDAP TCP 389 Outbound

LDAP over SSL/TLS TCP 636 Outbound

Platform Services Controller TCP 443 Outbound

SQL Server TCP 1433 Outbound

SMTP Server TCP 25 Outbound

vCenter Server API TCP 443 Outbound

Lookup port TCP 8230 Inbound

Command port TCP 8240 Inbound

Message port TCP 8250 Inbound

Data port TCP 8244 Inbound

Web configuration HTTP access port TCP 8282 Inbound

LDAP TCP 389 Outbound

LDAP over SSL/TLS TCP 636 Outbound

LDAP using Global Catalog TCP LDAP on 3268, LDAPS on 3269

Outbound

Table 17. Ports in use in VMware vRealize Automation Application Services


RPC TCP 111 Inbound

Access to vRealize Automation console

TCP 443 Inbound

VAMI TCP 5480 Inbound

TCP 5488, 5489 Inbound

Internal vCenter TCP 8230, 8280, 8281

Inbound

SMTP TCP/UDP 25, 587 Outbound

DNS TCP/UDP 53 Both

DHCP TCP/UDP 67, 68, 546, 547 Outbound

Software updates TCP 80 Inbound

POP TCP/UDP 110, 995 Outbound

IMAP TCP/UDP 143, 993 Outbound


IaaS Manager Service over HTTPS TCP 443 Inbound




PostgreSQL database TCP/UDP 5433 Outbound

SSO service over HTTPS TCP 443 Outbound

vRealize Orchestrator instance TCP 8281 Outbound

Manager Service TCP 80 Inbound

proxy agents TCP 80 Inbound

guest agents TCP 80 Inbound

Virtualization host TCP 80 Inbound

DEMs TCP 443 Inbound

vFabric, RabbitMQ TCP 5671 Inbound

Table 18. Ports in use in VMware vRealize Automation


vRealize Automation Appliance TCP 443, 8444 (for the Remote Console ability)

Inbound

vRealize Automation Application Services

TCP 8443 Inbound

SSH TCP 22 Inbound

VAMI TCP 5480 Inbound

Platform Services Controller TCP 443 Outbound

VMware vSphere ESXi (for the Remote Console capability)

TCP 902 Outbound

vSphere Endpoint TCP 443 Outbound

Table 19. Ports in use in VMware vRealize Automation IaaS


Manager Service TCP 443 Inbound

DNS TCP/UDP 53 Outbound


Manager Service TCP 443 Outbound

Website TCP 443 Outbound

Distributed Execution Managers TCP 443 Outbound

Manager Service, Website TCP 1433 Outbound




Manager Service (optional) TCP 80 Outbound

Table 20. Ports in use in VMware vRealize Business for Cloud


HTTPS (for VAMI) TCP 5480 Inbound


SSH TCP 22 Inbound

vPostgres TCP 5432 Inbound

Table 21. Ports in use in vRealize Log Insight


SSH TCP 22 Both

HTTP (optional) TCP 80 Inbound


Syslog TCP 514 Inbound

Syslog UDP 514 Inbound

Syslog-TLS TCP 1514 Inbound

Syslog TCP 6514 Outbound

vRealize Log Insight Ingestion API TCP 9000 Inbound

Thrift RPC TCP 16520:16580 Inbound

log4j Server TCP 59778 Inbound

database Server TCP 12543 Inbound

Table 22. Ports in use in VMware vSphere ESXi


SSH TCP 22 Both

DNS UDP 53 Both

HTTP TCP/UDP 80 Inbound

vCenter Server / VMware Infrastructure Client

TCP/UDP 902 Inbound

Remote Access to Virtual Machine Console

TCP 903 Inbound




Web Access TCP 443 Inbound

Optional Ports

NTP UDP 123 Both

SNMP UDP 161-162 Both

Kerberos TCP/UDP 88 Outbound

Active Directory TCP/UDP 464 Outbound

Software iSCSI TCP 3260 Outbound

enterprise hybrid cloud 4 - dell emc · pdf fileenterprise hybrid cloud 4.0: foundation...

Documents