Security in Hybrid Clouds

Transcription

1 Security in Hybrid Clouds

2 Executive Summary... 3 Commonly Accepted Security Practices and Philosophies... 4 Defense- in- Depth... 4 Principal of Least Privileges... 4 Hybrid Cloud Security Issues and Threats... 6 Multi- cloud and Hybrid Considerations... 8 Conclusion

3 Executive Summary As Cloud Computing has evolved and matured, it has sparked growing interest from the enterprise market where economic pressures are challenging traditional IT operations. Many companies and government agencies are being faced with growing IT costs that originate from multiple sources such as legacy systems, software licensing, power consumption, and operating overhead. These growing costs are exacerbated by the inefficiencies in traditional IT organizations such as projectbased funding, underutilization of resources, lengthy manual provisioning times, and organizational silos. Cloud Computing, either through Private or Public cloud initiatives, is focused on addressing these issues by reducing costs through better standardization, higher utilization, greater agility, and faster responsiveness of IT services. However, a high-priority concern for many enterprises in embarking on a private, public, or hybrid cloud journey, is security of the infrastructure and the information stored and processed by that infrastructure. This is particularly important for firms in domains with a high level of regulation and/or sensitive customer data. Balancing rich mechanisms for identity and access management with integral features such as single sign-on is a must for cloud environments. Securing information and software assets in the cloud can be problematic, especially in public cloud environments where the systems are not directly controlled by the data owners. However, utilizing same principals and lessons learned in developing the on-premise Private Cloud solutions, can also be applied to Public Clouds ideology. This paper will be focused primarily on the security risks, mitigations, considerations and commonly accepted practices that apply to Public, Private and Multi-Cloud deployments. 3

4 Commonly Accepted Security Practices and Philosophies Defense-in-Depth Defense-in-depth is the practice of using controls at all layers of the information architecture. In cloud architectures, the need to follow this philosophy is even more important. For Private Cloud and IaaS cloud deployments, the areas of focus include operating system, hypervisor, virtual machines, storage, database, application servers, applications, networks, and consumer portals. For Public Cloud PaaS, areas may include securing stack components using role based data access for application and database server components. One of the primary security design goals for Defense in Depth is to map application requirements to business, functional, and technical Cloud platforms. In a traditional (non-cloud) architecture, this is done using distinct servers, storage systems, and network subnets. In cloud architectures, using cloud pools is becoming an accepted method for achieving this goal. Cloud pools, which to refer to a common set of resources shared by tenants, can be separated by data sensitivity, line of business, and/or classification of users accessing it. For example, customers may place greenfield applications with non-sensitive data in AWS and place sensitive data in on-premise or Oracle/Azure Clouds. A key part of the defense in depth approach involves the three As: authentication, authorization, and auditing. Cloud Providers and stack vendors offer a variety of products and features that address these three As at various points of user data access and stack components. Customers should determine which features or products should be implemented based on business needs or existing architecture and standards; e.g., single sign-on, Active Directory integration, IP rules, etc. Principal of Least Privileges The Defense in Depth starts with the principle of least privileges. The principle of least privilege is the practice of limiting access to the minimal level, yet still allowing the application to function normally. For example, application owners and administrators should have access only to the data, applications, and systems and privileges necessary to perform their duties. This approach provides better stability and more predictable behavior; e.g., unauthorized users cannot purposely or accidently remove privileged files or stop critical processes. Additionally, least privileges also improves mean time to deploy applications, since fewer privileges or roles need to be implemented. However, least privilege principle is one of the most difficult philosophies to implement. Organizations must have knowledge of the following to successfully implement least privilege principle: 1. Classification of data 2. Knowledge of where their sensitive data resides 3. Mapping of data ownership to user credentials 4. Solid automation for user lifecycle management Although these philosophies apply to general application deployment, least privilege principle becomes even more important and relevant in Cloud deployments, as tenants will demand certain level of security isolation. 4

5 As part of this Hybrid Cloud deployment models, three new key personnel roles have emerged to play a large part in data asset management. Cloud Brokers With the various Cloud Platforms available; e.g., AWS, Azure, Oracle, as well as possible off-premise hosted systems (Rackspace, Savvis, etc.), customers will most likely have data spread across these platforms. A Cloud Broker monitors and surveys the data assets across these various Cloud platforms. The main objective is to govern, based on regulatory or compliance requirements, what can be placed outside vs. inside the DMZ. The Cloud Broker effectively is a small organization that requires a solid foundation of data classification and data accountability. Thus, subroles will include data stewards, security infrastructure management and Cloud-vendor alliances. Cloud Administrators The Cloud Administrator is the gatekeeper for accessing Cloud resources; e.g., who can access, what can they access and how much compute resources (compute shapes) can be deployed. A key aspect of this role is resource monitoring and tenant lifecycle management. Cloud Security Administrators - This traditional role has evolved into a larger security framework administrator to facilitate and enforce the Defense in Depth approach for Private and Public Cloud deployments. For example, the Cloud Security Administrator may determine whether the Access Management (single sign-on) will be offsite-hosted or on-premise, if identity management will be replicated between Cloud configurations, or if centralized Wallet management is required. In the next section we will discuss Hybrid Cloud threats and how they can be addressed 5

6 Hybrid Cloud Security Issues and Threats With the convergence of technology that represents current cloud initiatives come different threats. Complicating this is the fact that traditional perimeters of the infrastructure change in a cloud environment. Organizations must develop a clear understanding of security requirements, trust boundaries, and threat profiles. It is stated that the velocity of change in a cloud is proportional to the velocity of attack, i.e., as the rate of change increases the potential for threats manifesting themselves also increases. Such threats are typically linked to the management of the cloud infrastructure. However, these are all manageable with current security best practices, governance processes and controls are in place. The following is a sampling of potential threats that one may encounter in a cloud environment and possible remedies against the threats. Side Channel infiltration An improperly secured cloud environment can be a point from which various inter/intra system attacks can be launched to either co-tenants or external systems, thereby causing a potential cascading failure of multiple systems. Threat amplification means that a problem propagates faster and farther through a Cloud environment than it would under alternate circumstances (i.e., in a noncloud environment). This also has the effect of potentially reducing a timely response and recovery from the threat. The multi-tenancy or proximity of systems in conjunction with an improperly secured cloud environment may increase the risk to data or system corruption from adjacent systems and applications. Such threats can be addressed by utilizing a strong security architecture that enables features such Secure Enhanced Linux (SELinux). SELinux is Linux kernel security module that provides a mechanism for supporting access control security policies, including mandatory access controls (MAC). For Private Clouds that leverage virtualization for isolation, should implement the vendor s Virtual Machine (VM) hardening guide for strong compartmentalization. Data leakage With multifarious options to access corporate data, such as mobile devices, at-home or on-premise networks; there is always the possibility of data leakage. Data leakage is a very broad subject area, the key is to focus on the source of the content; i.e., where is the data and how is it exposed, and disposed off. The key aspect is to ensure that appropriate controls are put in place, such as data encryption, data redaction or role based access control (RBAC) mechanisms. It is very typical for test and development environments to be built in Public clouds; however, these datasets are generally borne from production environments. This exposes data vulnerability. To address this, all data with classification of critical should always be redacted and or masked. In a cloud environment, we could further state that data leakage may be possible by leaving data remnants in memory or on disk after a database service or (VM) is de-provisioned. One approach to addressing this threat is to ensure that the software stack is completely de-installed and or a consistent data scrubbing process is implemented. OS Layer Security Providing Operating System access to tenants is sometimes a necessary evil for certain Cloud deployments, whether Private or Public. However, OS level access comes with another angle of security vulnerability. As stated above, the Linux security policy should use Secure Enhanced Linux (SELinux) with setting of enabled. 6

7 In addition to SELinux, file system audit and object action logging should also be enabled. Most native operating systems include a built-in capability for files system auditing. With file system auditing, the service collects data about the use of filesystem resources; e.g., files and data objects, and provides a record of security-related events. For system auditing, administrators can pre-select which classes of audit records to monitor or the degree of auditing that is performed for individual users. Auditing generates records when specified events occur; e.g. system startup/shutdown, login and logout, use of privilege capabilities or rolebased access control (RBAC) or administrative actions (such as installing a package) Once the relevant event information has been captured, it can be formatted into an audit record. However, audit capture is only one part of the puzzle. Audit records need to be analyzed (sometimes in real-time), to detect and alert on unauthorized activity, patterns of access or evaluating attempts to bypass the protection mechanisms. Distributed Denial of Service (DDoS) attacks A denial of service (DoS) attack is an incident in which a user or application becomes unavailable or non-serviceable because it is deprived of the resources necessary to operate. A distributed denial-ofservice (DDoS) is a large DOS attack based, comprised of large number of compromised systems attack a single target. A DOS/DDoS involves a loss of service or business function, such as customer facing websites, , or networks. DDoS attacks may be launched against a cloud environment that can result in the loss of access to or exhaustion of some resources or services so that the systems underperform or become unusable. A common DOS attack is the Buffer Overflow Attack. Customers should leverage the capabilities of load balancers and Web Servers such as monitoring frequently accessed URI and denying requests, if the request frequency exceeds a pre-defined threshold or maximum number of requests allowed from a client per second is hit. Complexity Complexity is an inherent and potential threat in any computing environment. As complexity grows, so does the security risks: more components means more attack surfaces and more interactions among components. When a system environment includes a variety of configuration and components (e.g., multiple O/S versions to maintain, multiple vendors to track, etc.), the management of the components is more difficult. Private and Public Cloud methodology reduces complexity by emphasizing a rationalized, standardized environment. With less variety to manage, each component can be given more detailed attention. Furthermore, when data stores are consolidated, the data visibility is centralized, whereas in a silo d environment there are more opportunities for data stores to fall outside of standard processes. Complexity can be further addressed through enforcement of strong security policies and procedures, along with standardized processes for provisioning users into the cloud and decommissioning environments. 7

8 Multi-cloud and Hybrid Considerations The movement and progression towards Cloud has created a myriad of options and configurations. Many customers that adopted Private Cloud early on have now implemented greenfield systems using AWS for IaaS configurations, or even Microsoft Azure. A multi-cloud strategy allows customers the flexibility to run on appropriate Cloud platforms based on application suitability. It has become a best of breed approach, not unlike the platform and database wars of earlier years. Regardless of the name, either Hybrid Cloud or Multi-Cloud, there are essentially three camps in this field: Clouds configurations that are distinct and purposely disjointed; e.g., on-premise Private Cloud for mission critical and Public Cloud for non-critical systems. In these cases, there may be no interaction or integration between these systems. Configurations where the Public Cloud is direct extension of on-premise system configurations. This implies application and system integration between the Cloud platforms. Configurations where the Public Cloud systems are on standby (or with minimal activity) but configured for Cloud bursting. For organizations that want interoperability across Cloud boundaries, it is essentially non-existent, unless customers are deploying a homogenous stack between cloud platforms; e.g., Oracle databases in Private Cloud and Oracle Public Cloud. In these cases, tools such as Oracle Enterprise Management is leveraged for management, administration, monitoring, and provisioning. However, for heterogeneous applications across heterogeneous Cloud platforms, this requires manual setup of management stack components and custom integration. Technologies such as OpenStack, Eucalyptus, Chef and Puppet have played a large part in this integration. What does this mean from a security perspective? In many cases organizations existing on-premise security architecture needs to be extended into the multi-cloud system. For example, access management, endpoint and wallet management, encrypting data in transit and at rest, and operational ownership for change management needs to be applied in hybrid cloud. This can be complicated if companies are trying to tie-back security from AWS, Azure, and Oracle Public Cloud into their on-premise Active Directory system. Nevertheless, there are Cloud based technologies emerging that provide [off-premise] User Lifecycle Management (cradle to grave) and centralized single sign-on (SSO) capabilities, enabling users access, from any device, to apps, whether they reside on cloud, mobile, or on-premises, all this can be based on IT based policies. 8

9 Conclusion Hybrid Cloud architectures enable organizations better utilization, improved agility and efficiency. However, Hybrid Cloud architectures can only provide benefits to an organization as long they are implemented and managed securely. Customers must ensure that their standards based Hybrid Cloud deployments cover all aspects of security, such as infrastructure, OS and database security. Without proper isolation, tenants may intentionally or unintentionally abuse shared resources or compromise security of their neighbors. Proper isolation enables the fair and secure use of the environment's shared resources. 9

10 Authors: Nitin Vengurlekar, CTO Viscosity North America Charles Kim, CEO Viscosity North America Publish Date: 8/8/