다음을 통해 공유

Cloud Security Challenges

  • 아티클

To highlight the changes in security between traditional IT systems and cloud-based environments, this paper takes four of the five the NIST cloud computing definitions and analyses these statements to create a problem statement and a range of possible attack vectors. This paper considers each of these challenges in turn before moving on to identify how to respond to these challenges.

This paper does not consider the measured service cloud attribute, as this attribute does not bring any additional identified security issues that are not covered in the other scenarios. However, the measured service cloud attribute is discussed in the Design and Operations Guides in this series.

Note:

This document is part of a collection of documents that comprise the Reference Architecture for Private Cloud document set. The Solution for Private Cloud is a community collaboration project. Please feel free to edit this document to improve the quality of this document. If you would like to be recognized for your work on improving this document, please include your name and any contact information you wish to share at the bottom of this page

 

Resource Pooling

Problem Statement*: As the consumer (tenant) of the services offered by a private cloud in my enterprise, I want to be sure that the data in my application is secure, that no-on else can access it, and that it is safe if something untoward occurs.*

Resource pooling is the mechanism by which cloud environments can increase utilization levels, reduce costs and make use of cheaper resources, such as commoditized servers and inexpensive hard disks. For example, organizations no longer need to buy in expensive storage area network (SAN) equipment but can instead create cheaper storage pools that employ resilience rather than redundancy to protect the data. By using management tools to create compute, storage and networking pools and by automating the allocation of these resources, the cloud administrators can enable multiple users, groups, or organizations to make use of these pooled resources.

Resource pooling needs to be considered at all three service layers of the private cloud model. But this resource pooling also requires significant consideration of the security aspects from such a configuration.

With public cloud implementations, it is self-evident that resource pooling also infers a requirement for strict account partitioning. No public cloud business model is likely even to come to market if it cannot offer effective separation and segregation of customer data. In a public cloud model, this partitioning also applies to common areas such as the directory service.

With a private cloud implementation, a similar requirement for strict data partitioning is not immediately obvious. With areas such as the directory service, such partitioning may even be counter-productive. Instead, the question you need to ask is whether you would want every business unit and individual within your organization to view the data or use the applications belonging to every other unit or user. If universal access is desirable then access control list (ACLs) and application, file, or share system permissions are superfluous and you do not need to partition your private cloud environment.

If, however, you do need to protect data and applications from access by authenticated users who are not authorized to view that information or use those applications, then you do need to implement some form of partitioning within your private cloud environment. Similarly, administrative rights need to be carefully controlled, as you may want to give certain groups or business units the right to carry out limited administrative actions on their resources.

With each pooled resource, you must ensure that each tenant’s data or applications are kept partitioned from those belonging to other tenants. Any data that is exclusively owned by a consumer should not leak to other sessions nor be accessible by other users or tenants, whether maliciously or not. Partitioning and Role Based Access Control (RBAC) also applies to your administrators, who should not have automatic access to tenant data. In the case where an administrator does require access to tenant data, then that access must be carefully audited.

The following areas are those that need to be considered when planning for resource pooling:

  • Virtualization
  • Multi-Tenancy
  • Infrastructure security
  • Platform security
  • Software security
  • Data protection
  • Service Level Agreements (SLAs)

Later sections in this document consider these factors.

On-Demand Self-Service

Problem Statement: As the architect, designer, or operator of a private cloud solution, how do I control who has access to my private cloud services and how do I monitor and audit the use of my services?

The essence of cloud provisioning is that of self-service. When combined with rapid elasticity, self-service enables cloud implementations to provide dynamic and timely responses to requests for more or fewer resources. No longer is it necessary to go through a cumbersome process to request a new server, development platform, or software  – you can simply go to a self-service portal and select what type of computing resource you want from a standardized service catalog. The portal then provisions the environment, allocates resources from the shared pools, mounts the environment, configures security, and then connects the consumer to the requested service.

Yet the simplicity of on-demand self-service can also be its weakness. Because cloud environments are often virtualized, any errors in assigning security permissions during the provisioning process could, for example, result in other tenants being able to access the newly provisioned environment. Hence monitoring of the success of provisioning and deprovisioning requests is vital.

Because the attacker profile is different for private cloud, you also have to identify additional vulnerabilities and security gaps. Hence, you must consider who has authority to demand, provision, use, or release services, regardless at what service level (SaaS, PaaS or IaaS) those services are provided. You must be able to authenticate the users making these requests, implement RBAC to grant access to the relevant resources at the right level, ensure that permissions on the resources are correctly set, provide secure access to the resources and partition those resources from other service users.

When the requesting user indicates that the resources are no longer required, you must be able to deprovision those resources, remove access, and destroy any residual data that might be present. All resources must then be returned to the cloud in the same base state as all assets in the respective resource pools. The destruction of residual data is particularly important. Cases have come to light of public cloud providers finding that tenant data from one session was not being adequately purged, which enabled subsequent tenants to access this data.

You must also provide your consumers with an SLA that details the security levels that apply to the provisioning and deprovisioning processes. This SLA must specify the resultant security outcomes without compromising overall security by providing details of how the security is applied.

The following areas are those that need to be considered when planning for on-demand self-service:

  • Monitoring
  • Security Management, including templates and standardization
  • Infrastructure security
  • Management security
  • Incident response and forensics
  • Legal issues, such as compliance, data protection, and SLAs

Later sections in this document consider these factors.

Rapid Elasticity

Problem Statement: As the architect, designer, or operator of a private cloud solution, I am concerned that a rogue application, client, or denial of service (DoS) attack might destabilize the data center by requesting a large amount of resources. How do I balance the requirement that individual consumers or tenants have the perception of unlimited resources with the reality of limited shared resources?

A further key difference with cloud environments compared to traditional IT provision is that cloud implementations should provide the perception of unlimited resources. Because the compute, storage, and network resources are pooled and can therefore be shared between customers, customers can request as little or as much of each resource as they need within their budgetary constraints. The management system can then rapidly allocate these additional resources either through manual requests or by automatic, demand-led provisioning.

Rapid elasticity enables organizations and business units to scale their operations up and down quickly to meet demand. For example, prior to rolling out a new desktop operating system, the IT department can scale up its helpdesk application to handle the expected increase in support calls. When the operating system is bedded in and the support call volume decreases, the additional resources can be released back into the shared pool. Rapid elasticity enables organizations to cope with a variety of variations in demand such as irregular spikes (such as might occur after an exceptional news event) or regular patterns, like running month-end financial reports.

However, the very strength and advantages of rapid elasticity can also be a weakness. It is important to understand that the perception of unlimited resources does not equate to infinite resources. Ultimately, there is a resource limit even in the most well-founded private cloud implementation. In consequence, repeated requests to provisioning resources or an inability to deprovision resources properly could lead to resource exhaustion.

There is the risk that the provisioning process itself could mimic a DoS attack. If the process of requesting resources is fully automated, an application error or a logical failure in the provisioning process could lead to repeated resource requests. Eventually, these repeated requests could use up all the compute, memory and storage resources within the cloud environment. When a new tenant makes a service request or an existing tenant wants to increase their allocation of resources, the private cloud environment would not be able to respond to these service requests.

There is also the scenario of an unwitting or even semi-malicious attack where the same tenant just goes on requesting more and more resources “because they can”. Simply because departments are charged for resources may not be enough of an incentive for them not to request resources on a whim. Hence monitoring and management must be able to implement pre-set quotas and ensure that the limits of resources per tenant are not breached without prior authorization. These quotas must be centrally configurable and adjustable on a per-tenant basis for maximum flexibility.

The following areas are those that need to be considered when planning for rapid elasticity:

  • Monitoring
  • SLAs
  • Attacker profiles (authenticated attackers)
  • Infrastructure security

There is some overlap with on-demand self-service factors and these are all considered later in this document.

Broad Network Access

Problem Statement: As an architect of a private cloud solution, I want to be sure that an appropriate level of security applies regardless of where the client is connecting from and regardless of the device form factor. This requirement applies to both cloud management and application security.

With public cloud implementations, delivering broad network access requires public network connectivity. In private cloud environments, there is no absolute requirement to connect your data center to the Internet, although not having this connectivity might adversely affect the potential benefits from the private cloud implementation.

In a fully managed and closed network environment, it is possible have a unanimously homogenous client base. However, the phenomenal proliferation of mobile devices, browsers and computer form factors from multiple vendors combined with greater user demands to access work data from anywhere in the world means that private cloud architectures must plan to include broad network access as an option. This proliferation has led to the phrase “bring your own device” or BYOD being coined to cover this consumerization of IT.

Any form of hybrid cloud architecture also implies the requirement for broad network access. Consumers may be authenticating to an application provided by a public cloud provider using federated identity to authenticate from your internal directory service. Your internally-hosted private cloud implementations may also be using web services from a third public cloud provider. In consequence, failing to consider the broad network access picture is inherently limiting.

The broad network access cloud characteristic requires IT departments to consider the entirety of the client to service network journey. It is also requires consideration of the effect of this requirement for universal access on management of the environment. Just as consumers need to access the cloud services from anywhere, so do providers.

Coping with broad network access requires consideration of the following factors:

  • Perimeter network role and location
  • Identity and Access Management (IdAM)
  • Authentication
  • Authorization
  • Role-based access control (RBAC)
  • Federation
  • Auditing
  • Public network connectivity
  • Service delivery security
  • Endpoint protection
  • Connectivity to software, platform, and infrastructure layers
  • Client security

Note that as the cloud service provider, you may not be able to control all aspects of client security.

When moving to a private cloud environment, you may want to review the relative importance of the perimeter network as a security boundary. Although this paper does not advocate removal of the perimeter network, there are several reasons why the perimeter network and associated firewalls should no longer be regarded as a total defense against network intrusion. This list highlights some of the reasons for this change of emphasis:

  • Authenticated attackers. As organizations secure their environments against anonymous users, attacks against data centers are increasingly using authenticated credentials. With private cloud environments, this trend is expected to continue and you should design your environment with this scenario in mind. If the attacker is able to authenticate, then they can already penetrate your perimeter network and access your cloud-based applications and data.
  • Client types. Moving to a cloud environment may result in the requirement to allow access from untrusted clients, such as kiosk computers. Connections from these client types require checking not just at the perimeter but at every stage throughout the end-to-end communication process. A later section in this document discusses aspects of trusted and untrusted clients.
  • Defense in depth. Private cloud implementations require a true defense in depth approach to security, where every layer of the architecture is secured. This approach inevitably changes the relative importance of the perimeter network, making it just a part of your total defenses.

So although the perimeter network is still a major security boundary (and the first that the customers encounter), you should consider whether its relative weight in the overall security picture has changed.

In private or hybrid cloud implementations, rather than remove the perimeter network altogether, you can place all other networks outside the perimeter into the untrusted zone. Figure 6 provides a conceptual representation of this change.

Figure 1: Changes between perimeter network in data center and private cloud implementations.

The remaining factors are all considered in later sections in this paper.

In all these scenarios, you must also consider insider attacks. With privileged access to all areas of the centralized private cloud infrastructure, your administrators have the ability to cause the most damage to your environment. Hence, these individuals must be considered as part of your overall security assessment.

In the next section, this paper considers the implications of untrusted clients; you must also review the implications of having untrustworthy administrators and identify mechanisms for detecting attacks by these individuals. Such security starts with careful background checks and robust selection procedures, but errant behavior rarely comes out of the blue. Good management plays an important part in overall security and identifying if people are acting out of the ordinary can help prevent security breaches.

Likewise, implementing a private cloud strategy does not remove the requirement for good security training of customers and providers. As with conventional network implementations, users should be aware of the different attack vectors that can affect client computers, such as phishing attacks, or Trojans and other forms of malicious software. Users should also not have administrative rights on client computers and should be trained to identify suspicious activity. 

 

RESOURCES:

ACKNOWLEDGEMENTS LIST:

If you edit this page and would like acknowledgement of your participation in the v1 version of this document set, please include your name below:

[Enter your name here and include any contact information you would like to share]

  • ...