Tài liệu VMware® vCloud™ Director Security Hardening Guide doc

VMware ® vCloud ™ Director Security Hardening Guide TECHNICAL WHITE PAPER TECHNICAL WHITE PAPER / 2 VMware vCloud Director Security Hardening Guide Table of Contents Introduction  Threats  MultitenancyandInternalThreats  SecureHostingandExternalThreats  VMware®vCloud™DirectorArchitectureandSecurityFeatures  VirtualMachineSecurityandIsolation  SecurityandtheUnderlyingVirtualizationLayer  SecurityandtheVMwarevCloudDirectorAbstraction  SecurityandtheVirtualNetworkingLayer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Provider-LevelNetworkResources  OrganizationNetworkTypes  vAppNetworks  InfrastructureHardening  CellGuestOS  ProtectingSensitiveFiles  OracleDatabaseSecurity  OracleDatabaseUserConfiguration  AdministrativeCredentials  Certificates  ConfiguringvCenterCertificates  ConfiguringVMwarevCloudDirectortoCheckvCenterCertificates  CertificatesandKeysforVMwarevCloudDirectorCells  ReplacingVMwarevCloudDirectorCertificates  NetworkSecurity—GeneralTopics  Firewalls(PacketFiltering)  BlockingMaliciousTrac  BlockingJMXandJMSTrac  WebApplicationFirewalls  Introduction  WhyDeployaWAF?  ExamplesofWAFRules  RemoteAPIAccess  VendorsandProducts  ConfigurationofPublicWebURLsandAddresses  VMware vCloud Director Security Hardening Guide TECHNICAL WHITE PAPER / 3 WAFLoadBalancersandTLSvSSLTermination  TLSSSLTerminationandCertificates  X-Forwarded-ForHeader  SecuringAccesstoJMX  JMXAuthentication  LimitingConnectionstoJMX  SecuringJMXCommunications  JMSMessageQueueProtection  JMSAuthentication  NetworkRouting  NetworkSecurityforOrganizations  SecuringOrganizationNetworkswithVLANsandVLAN-backedNetworkPools .  ABriefVLANDefinition  VLAN-BackedNetworkPools  WhenToUseVLAN-BackedNetworkPools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  VLAN-BackedNetworkPoolSetup  SecuringOrganizationNetworkswithVMwarevCloudDirectorNetworkIsolation– BackedNetworkPools  VMwarevCloudDirectorNetworkIsolationDefinition  VMwarevCloudDirectorNetworkIsolation–BackedNetworkPools  WhenToUseVMwarevCloudDirectorNetworkIsolation–BackedNetworkPools  VMwarevCloudDirectorNetworkIsolation–BackedNetworkPoolSetup  ResourceAllocationandIsolation  SharedResourceDeployment  ResourceSharingandIsolationRecommendations  SecurityDomainsandProviderVDCs  ResourcePools  ExternalNetworks  NetworkPools  Datastores  IsolatingStorage  ManagementNetworkConfiguration  ManagementNetworkComponents  VirtualInfrastructureManagementNetworkConfigurationRequirements  OtherRelatedNetworks  VMware vCloud Director Security Hardening Guide TECHNICAL WHITE PAPER / 4 AuditingandLogging  Introduction  LogginginVMwarevCloudDirector  DiagnosticLoggingandLogRollover  NTP  AdditionalLogs  UserManagementandIdentities  AboutUsersGroupsRolesandRights  ConfiguringIdentitySources  NamingService(LDAPv)Connectivity  LDAPoverTLSSSL  ImportingGroups  UserandCredentialManagement  PasswordStrength. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UserManagement  PasswordManagement  OtherPasswords  UserPasswordProtection  Checklist  TECHNICAL WHITE PAPER / 5 VMware vCloud Director Security Hardening Guide Introduction VMware® vCloud™ Director is a flexible system for providing cloud computing services. It leverages and extends VMware’s core virtualization and management technologies for support of cloud environments. Because the system was developed and tested with multitenancy, scalability and other security concerns in mind, the way in which it is deployed can have a significant impact on the security of the overall system. This document will describe some possible threats the system faces, as well the security features provided by the overall VMware software stack and the related components it uses, such as databases. No set of guidelines can cover all possible customer use cases. Each deployment of VMware vCloud Director may have its own IT environment, with dierences in network topology, internal security systems and standards, customer requirements, and use cases. Some general guidelines will be given to increase the overall security of the system. Where appropriate, more specific usage scenarios will also be considered along with guidance tailored to those particular cases. Nevertheless, the specific recommendations from this guide that you choose to follow will ultimately depend on your unique deployment environment, as well as the threats you determine to be a risk for your organization and wish to mitigate. It is also important to remember that secure deployment of software is only part of an overall security process, which includes physical security, training, operational procedures, patch strategy, escalation and response plans, disaster recovery, and many other topics. Most of these ancillary topics are not discussed in this guide. In general, threats to VMware vCloud Director fall into two separate baskets: internal threats and external threats. Internal threats typically involve issues of multitenancy, and external threats target the security of the hosted cloud environment, but those lines are not hard and fast. There are internal threats that attack the security of the hosting environment, for example. In addition to the guidance in this document, you should monitor the security advisories at http://www.vmware. com/security/advisories/ and sign up for email alerts using the form on that page. Additional security guidance and late-breaking advisories for VMware vCloud Director will be posted there. Threats Multitenancy and Internal Threats VMware vCloud Director is designed to give limited and controlled access to network, computing and storage resources to users who are clients of the cloud. These users can log into the system and are generally given rights to deploy and/or use virtual machines, use storage, run applications, and (to a limited extent) share resources with other users. One of the key features of VMware vCloud Director is that it does not provide direct visibility or access to most system-level resources—including physical host information such as IP addresses, MAC addresses, CPU type, VMware ESX® access, physical storage locations, and so on—to non administrative users. However, users may attempt to gain access to information about the system infrastructure on which their cloud-enabled applications run. If they were able to do so, they might be able to better launch attacks against the lower levels of the system. Even at the level of virtualized resources, users can attempt to use their legitimate access to obtain unauthorized access to parts of the system they are not entitled to, such as resources that belong to another organization. They might attempt privilege escalation, in particular, obtaining access to actions reserved for administrators. Users may also attempt actions that—intended or not—disrupt the overall availability and performance of the system, in extreme cases resulting in a “denial of service” for other users. In addition, a variety of administrative users generally exist. These include the system administrator for a VMware vCloud Director instance, Organization administrators, administrators of databases and networks, TECHNICAL WHITE PAPER / 6 VMware vCloud Director Security Hardening Guide and users with access rights to hypervisors, to VMware vCenter™, or to guest operating systems that run management tools. These users have higher privileges compared to ordinary users, and usually have direct login to internal systems. Nevertheless their privileges are not unlimited—and there is a potential threat that they too may attempt privilege escalation or do harmful actions. As will be seen, the security of VMware vCloud Director from these threats comes from the architecture, design, and implementation of VMware vCloud Director, VMware vSphere™ 4.1 (“vSphere”), vShield, other security systems, and the infrastructure on which these systems are deployed. Due to the flexibility of these systems, like vSphere, following the specific guidance in this and other documents, such as the vSphere Hardening Guidelines, is critical to creating an environment that meets your organization’s specific security needs. Secure Hosting and External Threats The sources of external threats are systems and users outside the cloud, including attackers from the Internet against VMware vCloud Director through its APIs, the Web Console (written using Adobe Flex), the vApp transfer service, and the virtual machine remote console. A remote user who has no access rights to the system can attempt to gain access as an authorized user. Authenticated users of those interfaces can also be considered to be the sources of external threats, as they may try to exploit vulnerabilities in the system not available to unauthenticated users. Typically, these actors attempt to exploit flaws in the system implementation or its deployment in order to obtain information, acquire access to services, or simply to disrupt the operation of the cloud through loss of system availability or system and information integrity. As the description of these attacks implies, some of these attacks violate the tenant boundaries and hardware abstraction layers that VMware vCloud Director attempts to enforce. While the deployment of the dierent layers of the system aect the mitigation of these threats, the externally facing interfaces, including firewalls, routers, VPNs, and so on, are of utmost concern. TECHNICAL WHITE PAPER / 7 VMware vCloud Director Security Hardening Guide VMware vCloud Director Architecture and Security Features VMware vCloud Director was purpose built to provide Infrastructure as a Service on top of vSphere. Thus the system leverages the secure isolation of virtual machines and virtual networks provided by vSphere. In addition, VMware vCloud Director takes advantage of vShield to provide additional networking controls not found in vSphere. Finally, the VMware vCloud Director architecture enables the multitenant separation at the management and distribution layer required in a cloud environment. vShield Manager vShield Manager VMware vCloud Director Server Host VMware vCloud Director Cluster Cell VMware vCloud Director Database VMware vCloud Director VMware vSphere vCenter vCenter vCenter ESX/ESXi ESX/ESXi ESX/ESXi ESX/ESXi ESX/ESXi vCenter Database vCenter Database vCenter Database vShield Manager Figure 1. VMware vCloud Director Architecture. Figure 1 shows a single VMware vCloud Director cluster. Within the cluster there might be many vCloud Director server hosts, each with a single cell running. Together, the cluster shares the vCloud Director Oracle database and an NFS file share (not shown). The cloud abstraction is built using the VMware vCloud Director software and leveraging capabilities in both vCenter and vShield, shown in the diagram as connecting to the cluster. The eect is that Organizations and their users do not interact directly with vCenter and vShield to load and manage their vApps, but only through the vCloud Director. Even when connecting to virtual machines’ consoles (not shown), the VMware vCloud Director software proxies and mediates those connections. The subsequent subsections describe security at the virtual computing layer, the cloud abstraction, and the virtual networking layer. Virtual Machine Security and Isolation When we refer to security and network isolation, we are looking to assess the risk that network segregation and trac isolation controls are insucient, and to choose the recommended corrective actions. When looking at network segmentation, we have a notion of a trust zone. TECHNICAL WHITE PAPER / 8 VMware vCloud Director Security Hardening Guide Trust zones are a proactive security control to control access to network trac. A trust zone is loosely defined as a network segment within which data flows relatively freely, whereas data flowing in and out of the trust zone is subject to stronger restrictions. Examples of trust zones include: •Demilitarized zones (DMZs) •Payment-card industry (PCI) cardholder data environment •Site-specific zones, such as segmentation according to department or function •Application-defined zones, such as the three tiers of a Web application Security and the Underlying Virtualization Layer A significant portion of VMware vCloud Director security, especially in protecting multitenancy from internal threats, comes from the security design and the specific configuration of the underlying virtualization layer. This includes not only vSphere’s design but also the configuration of vSphere, additional security of VMware vCloud Director isolated networks, the leveraging of vShield technology, and the security of the ESX and VMware ESXi™ hosts themselves. Security and the VMware vCloud Director Abstraction The VMware vCloud Director abstraction allows a service provider to delegate vApp creation, management, and use to tenant Organizations (or an IT department to delegate these capabilities to line of business teams). While providing these capabilities, the Organization administrators and users do not operate on or manage vCenter or vSphere’s capabilities, like VMware vMotion™. Tenants deal only with deploying vApps to resource pools, datastores, and networks created for and assigned to that Organization. Since Organization administrators and users never log in to vCenter, there’s no chance of a misconfigured vCenter permission giving the user too many rights. Moreover, the provider is free to change the composition of resource pools without the Organization needing to change anything. More important, this abstraction separates dierent Organizations from each other. Even if they happen to be assigned common networks, datastores, or resource pools, they cannot modify or even see each other’s vApps without explicitly sharing them. (The exception is vApps connected to the same External Network, as they’re sharing the same vSwitch.) Providing Organizations with unique datastores, networks, and resource pools enforces even greater separation between the Organizations through the quotas you can set in those abstractions. The VMware vCloud Director layer also provides the ability to leverage vShield for network address translation (NAT) and firewalling of networks. This is discussed in more detail in the next section. Security and the Virtual Networking Layer How virtual networking in your virtual infrastructure is set up is critical to ensuring the security of VMware vCloud Director in general and isolation of individual tenants in particular. VMware vCloud Director leverages the virtual switches and portgroups set up in the virtual infrastructure when creating Organization Networks (via External Networks and Network Pools). The dierent types of networks and pools at the VMware vCloud Director layer provide dierent types of isolation: Provider-Level Network Resources These resources are used to create Organization and vApp networks: •An External Network provides no isolation between virtual machines, vApps, or organizations by design. It is “external” in order to connect to systems outside the cloud. Connecting directly to that network doesn’t give the protection of the other types of networks. •A VLAN-backed Network Pool provides isolation using VLANs across a vNetwork Distributed Switch. TECHNICAL WHITE PAPER / 9 VMware vCloud Director Security Hardening Guide •A VMware vCloud Director network isolation–backed Network Pool provides isolation by encapsulating Layer 2 packets in other Layer 2 packets (MAC-in-MAC) in the ESX or ESXi kernel, allowing the kernel when de-encapsulating packets to direct them to the correct guest virtual machines connected to the networks created out of this sort of pool. •A vSphere portgroup-backed Network Pool does not enforce isolation directly, but is dependent on the portgroups not being connected to the same vSwitches and physical networks. Isolation can be provided at the physical network with VLANs or other mechanisms. Further discussion of this network type is out of the scope for this document. None of the provider-level network types provide confidentiality if packets are intercepted at the physical network. Organization Network Types The following Organization Networks exist and should be used for the following scenarios: •A public Organization Network is based on an External Network. Machines on this type of network are directly reachable from any network that can route to the underlying vSwitch and portgroup. This type of network would be useful in an enterprise internal cloud when the vApps in the Organization need to be directly reachable and NAT is not necessary. •A routed private Organization Network connects to an External Network, but sits behind a virtual NAT device. This type of network is useful for Organizations at a cloud service provider that need vApps to connect to the Internet but want to limit their visibility and accessibility from the outside. Firewall rules can also be applied to this type of Network Pool. •An isolated private Organization Network is useful for vApps that don’t need access to any resources outside of the Organization. No other Organizations or systems outside of VMware vCloud Director can access an Organization’s internal Organization Network. vApp Networks A vApp can be connected to a vApp specific network or to an Organization Network. •A vApp network isolates the virtual machines in that vApp from everything else; in that way, it is like an internal Organization Network, but is only used by that vApp. •It is possible to “connect” the vApp network to an Organization Network and get access to it via NAT and Firewall protection. •Connecting to an Organization Network gives the protections of that network. •Fencing o a vApp allows its virtual machines to connect to Organization Networks without worrying about IP and MAC address conflicts. In addition, additional firewall rules can be added to protect virtual machines in the vApp. Infrastructure Hardening Much of this guide is concerned with protecting the VMware vCloud Director cell itself, but overall system security also depends on securing the infrastructure on which it depends. Administrators should apply the steps recommended in the vSphere Security Hardening Guide to ensure that they have secure installations of vCenter Server and vSphere. Applying current security patches to the OS, database, and virtual infrastructure before installation is a key step and ongoing monitoring to keep these components at a current patch level is also crucial. Cell Guest OS VMware vCloud Director cells run on a Linux-based guest operating system under a non-root user created by the installation script. TECHNICAL WHITE PAPER / 10 VMware vCloud Director Security Hardening Guide Standard security hardening procedures should be applied to the guest OS, including disabling unnecessary network services, removing unnecessary packages, restricting remote root access, and enforcing strong password policies. Use if possible a centralized authentication service such as Kerberos. Consider installation of monitoring and intrusion detection tools. It is possible to install additional applications and provision additional users on the cell OS instance, but it is recommended that you do not do this—widening access to the cell OS may decrease security. Securing network trac to the cells will be discussed later. Protecting Sensitive Files The global.properties and responses.properties files, both found under $VCLOUD _ HOME/etc, are critical files that contain sensitive information. The responses.properties file contains responses provided by the administrator when running the configuration script. That file contains an encrypted version of the Oracle database password and system KeyStore passwords. Unauthorized access to that file could give an attacker access to the VMware vCloud Director database with the same permissions as the Oracle user specified in the configuration script. The global.prop erties file also contains encrypted credentials that should not be made accessible to users besides the cell administrator. The Installation and Configuration Guide recommends saving and using the responses.properties file when installing VMware vCloud Director on additional server hosts, placing it in a location accessible to all target hosts. That recommendation is enhanced here with the requirement that the file only be made available to authorized individuals. Appropriate access controls should be placed on the “location accessible to all target hosts.” Any backups that are made should be carefully controlled and encrypted if your backup software supports that. Once the software is installed on all server hosts, any copies of the responses.properties file in these accessible locations should be deleted. There will still be a copy on the original server host where it can be retrieved if another host needs to be installed at a later time. The responses.properties and glo bal.prop erties files are protected by access controls on the $VCLOUD _ HOME/etc folder and the files themselves. Do not change the permissions on the files or folder as it may either give too much access, reducing security, or restrict access too much, stopping the VMware vCloud Director software from working. In order for the access controls to properly work, physical and logical access to the VMware vCloud Director servers must be strictly limited to those with a need to log in and only with the minimal levels of access required. This involves limiting the use of the root account through sudo and other best practices that are outside the scope of this document. Moreover, any backups of the servers must be strictly protected and encrypted, with the keys managed separately from the backups themselves. Oracle Database Security In general, Oracle database security is outside the scope of this document. Like all other systems used in creating your cloud deployment, you are expected to properly secure them per industry best practices. Please refer to guides such as the Oracle Database Security Checklist, the Oracle Database Security Guide, and similar resources and apply them as appropriate in your environment. Oracle Database User Configuration As specified in the “About the VMware vCloud Director Database” section of the VMware vCloud Director Installation and Configuration Guide, the Oracle database user account should not be a system administrator. Rather, it should only have the system privileges listed. Please see the above-referenced document for the complete list. These privileges will allow the user to initialize the database as well as to read and write required data to that database. The user should not be given privileges over other databases on that server or other system administration privileges. This would violate the Principle of Least Privilege on the database server and give the user more rights than necessary. [...]... per vCloud Director installation and stored in the $VCLOUD _ HOME/etc/global.properties file As mentioned earlier in this document, carefully protect any backups that contain that file TECH N I C AL WH ITE PAPE R / 32 VMware vCloud Director Security Hardening Guide Checklist • In addition to the guidance in this document, you should monitor the security advisories at http://www vmware.com /security/ advisories/... AL WH ITE PAPE R / 2 8 VMware vCloud Director Security Hardening Guide System LDAP users are stored in the LDAP directory configured at the system level, and references to them are imported into the VMware vCloud Director database where roles are assigned LDAP users’ passwords are managed and maintained in the LDAP directory, and authentication occurs against that directory using the settings specified... many log management and Security Information and Event Management (SIEM) systems will integrate with VMware vCloud Director This allows: a Correlation of events and activities across VMware vCloud Director, vShield, vSphere, and even the physical hardware layers of the stack TECH N I C AL WH ITE PAPE R / 26 VMware vCloud Director Security Hardening Guide b Integration of cloud security operations with... manually change those passwords using the vCloud Director configuration script for the Oracle database password or the Web UI for the vCenter and vShield passwords TECH N I C AL WH ITE PAPE R / 3 1 VMware vCloud Director Security Hardening Guide User Password Protection LDAP users’ passwords are stored in the LDAP directories They are never stored in the vCloud Director database They are transmitted using... is 443/TCP TECH N I C AL WH ITE PAPE R / 33 VMware vCloud Director Security Hardening Guide • As the VMware vCloud Director cells are in the DMZ, their access to the services they need should also be mediated by a network firewall Specifically, it is recommended that access to the Oracle DB, vCenter Server, vSphere hosts, Directory (LDAPv3) directories, and any backup or similar services be on the... Firewall Web Application Firewall VM Data Network Load Balanced DMZ VMware Cloud Director cell 1 ••• VMware Cloud Director cell n ESX Security Domain 1 ESX Security Domain N Storage Network Private Management Security systems applied broadly: - IDS/IPS - SIEM - ConfigPatch/Vuln Management - OS anti-mailware - GRC (not security ops) Oracle Not shown: vMotion Network between hosts in same domain •••... recommends a separate physical network for vMotion for security and privacy of that data VM DMZ Data Network Network Firewall ••• Cloud Pod 1 VM Data Network Cloud Pod N Private Management Storage Network Figure 6 Cloud Pod Networks TECH N I C AL WH ITE PAPE R / 2 2 VMware vCloud Director Security Hardening Guide It is also assumed that typical datacenter security technologies, such as IDS/IPS, SIEM, configuration... recommended approach to making VMware vCloud Director services available to the outside is to place the cells in a DMZ, with a network firewall separating the Internet from VMware vCloud Director cells on the DMZ The only port that needs to be allowed through the Internet facing firewall is 443/TCP TECH N I C AL WH ITE PAPE R / 12 VMware vCloud Director Security Hardening Guide NOTE: These management connections... vCloud Director create audit logs that should be consolidated into your audit processes These include logs from vShield Manager, the Oracle database, vCenter Server, and vSphere hosts The details of each system’s log files and their purpose is beyond the scope of this document and can be found in documentation related to those products TECH N I C AL WH ITE PAPE R / 27 VMware vCloud Director Security Hardening. .. upload and download quarantine Thus, the information in that message queue is sensitive TECH N I C AL WH ITE PAPE R / 13 VMware vCloud Director Security Hardening Guide No matter how the networks connected to the VMware vCloud Director cells are configured, a defense in depth doctrine requires that JMX (port 8999/TCP) and JMS (ports 61611/TCP and 61616/TCP) be blocked at the network firewall that protects . VMware ® vCloud ™ Director Security Hardening Guide TECHNICAL WHITE PAPER TECHNICAL WHITE PAPER / 2 VMware vCloud Director Security Hardening Guide Table of.  TECHNICAL WHITE PAPER / 5 VMware vCloud Director Security Hardening Guide Introduction VMware® vCloud™ Director is a flexible system for providing cloud