Microsoft Reference Architecture for Private Cloud: Cloud Security Overview

Security is one of the major concerns in cloud computing. To mitigate security risks while still gaining benefits from cloud computing, organizations can choose to focus on on-premises (private cloud) solutions. This enables the organization to move to a hybrid cloud solution in a controlled manner and extend the use of public cloud services as confidence in, and the capabilities of, the public cloud increase. Consequently, the focus of our cloud security architectural discussions goes beyond the definition of cloud-based solutions as those that provide purely Internet-based (web) services, to concentrate instead on in-house private cloud solutions that exist entirely behind the firewall and hybrid clouds, which combine private cloud systems with Internet-based (public or private cloud) services.

Moving to a cloud-based platform requires a change in mindset for IT security professionals. Throughout these architectural discussions you will see that some of the risks of the public cloud are mitigated by using a private cloud architecture. However, the perimeter security protecting a private cloud should be seen as an addition to public cloud security practices, not an alternative.

Traditional defense-in-depth security models include, among an essentially limitless array of security systems, physical security, firewalls, anti-virus software, identity and authorization systems and perimeter networks (DMZs). You cannot apply the traditional defense-in-depth security models directly to public cloud computing because many of these systems will be outside of your organization's control, however you should still apply the principal of multi-layered security and you should thoroughly evaluate the security systems of CSPs (Cloud Service Providers) you are considering.

By taking a fresh look at security when you move to a cloud-based model, your security practices will evolve to include the unique requirements imposed by the cloud, which do not map precisely with traditional on-premises approaches. In spite of the differences in approach, you should still target security levels which are at least as high existing on-premises solutions, as the opportunity for architecting security into the cloud-based solution is optimal when changing the core of your IT architecture from traditional on-premises to either Private Cloud or Hybrid Cloud.

In a cloud-based platform, regardless of whether it is private or public, you will be working in an abstracted and virtualized environment. The platform or software may run on top of a shared physical infrastructure managed internally (as in the case of Private Cloud) or by the service provider (as in the case of Public Cloud). The security architecture used by the applications will need to move up from the platform infrastructure to the application layers. For example, if a Software as a Service (SaaS) application is provided by a public cloud vendor, you will have no control over the software development platform or infrastructure and you will need to consider and apply all available and necessary security controls at the application level. And the level of security controls you can enable will be defined by the CSP and thus limited. In Private Cloud environments, you are responsible for all levels of security, from layer 1 to layer 7.

In public or hybrid cloud computing there is variable control and availability of perimeter defenses, with applications in a public or public side of a hybrid model potentially directly exposed to all Internet clients. Instead of network Access Control Lists (ACLs) and firewalls that were used to enforce an edge boundary, cloud public applications may need to rely on host-based packet filters, virtual firewalls, and application security. This can result in depending on the CSP providing much of the security and, therefore, one of your key security tasks is to assess vendors and put in place service level agreements (SLAs) and contracts to ensure the on-going application of security by the CSP.

Because of what seems like excessive reliance on the CSP to provide robust security controls, Private Cloud might be seen to have an advantage since perimeter defense security mechanisms are available and are under your control. However, this advantage may be more apparent than real, since the highest impact security breaches occur internally (insider attacks), behind the firewall and other network-centric security devices and therefore a cloud-based architecture should be seen as an opportunity to protect against all threats (not just attacks by outsiders) by assessing and architecting a security design that places emphasis not only on traditional perimeter security, but throughout the entire stack. If you take the approach that all networks are untrusted, then the security you put in place in your newly architected cloud solution will be more robust than your current design and align itself more closely with the threat landscape we see today.

Whether the cloud architecture is public, private, or hybrid, you must write applications with security in mind.

Applications must be designed so that they:

• Expose a reduced attack surface
• Run with least privilege
• Validate inputs
• Require user authentication
• Enforce authorization policies
• Encrypt data on disk
• Encrypt data over the network
• Encrypt data at the client application

This process, sometimes referred to as the Security Development Lifecycle (SDL), describes a methodology for how applications should be written before any move to a cloud-based infrastructure and, if these practices have already been implemented, the risks in adopting to a cloud deployment model are reduced. If you write Private Cloud applications in this way, they will provide higher levels of security and may not require a a significant update or rewrite if you move them to the public cloud. In addition, you become less dependent on network based security controls, which may be a nominal value in an era where attackers focus on stealth and therefore avoid disturbing network based security controls.

Much has been written on the security benefits of particular models of cloud security, contrasting the perceived benefits and threats of public versus private cloud solutions. In reality, public cloud systems can be secure or insecure and so can private cloud. Security is about implementation, not whether the solution is Internet-based, and each implementation will have different security architecture, design and controls that are specific for the implementation.

For example, an IaaS solution could include identity, storage, and software, and security needs to be applied at every level from application to transport to firewall and so on. Another system might be a pure SaaS solution that has no storage or confidential data, but needs identity and authorization systems to ensure that only approved users can use the system.

You should also consider that security costs can be reduced when deployed on a larger scale, as is the case for Public Clouds. Therefore, for a given investment in security by a large CSP, protection could be better in their public cloud-based system. However, by their very nature, Public Cloud systems transfer data over public networks and therefore there may be the impression that they are inherently less secure, regardless of possibility that Public Cloud CSP's security architecture, design and implementation are superior than virtually any on-premise solution seen in production today.

It is expected that as cloud adoption grows that the most common cloud use case will be a hybrid cloud solution with confidential and mission critical data kept in an on-premises Private Cloud that works in concern with a front-end system running in the Public Cloud. In this way, it may be possible to mitigate and isolate the effects of security breaches in the Public Cloud. However, there still remains a network link between the Public and Private Clouds in this model. Given that the security architecture and design of a multi-tier solution may only be as strong as its weakest link, it will still remain an imperative that you fully qualify your CSP even in hybrid cloud deployments and that you have available both automated and manual mechanisms that enable you to shut down the link between the Private and Public components of the Hybrid cloud solution. Security and reputation (i.e., the CSP's security reputation) are two of the key differentiators between Public Cloud providers. 

Traditional on-premises enterprise IT systems are typically well managed and maintained. The security risks are typically well understood and documented and standard processes are put in place to develop new applications and systems, or to provision them from 3^rd party vendors. It is very unlikely that a department manager would be able to purchase and install software without approval from the IT department.

This model of service delivery changes with cloud computing, for both Public and Private. Public Cloud (and even Private Cloud) enables departmental managers to obtain services on demand, making it possible that individual department managers could bypass the IT department and provision cloud-based solutions. While it may seem that corporate IT can mitigate this situation by using a Private Cloud environment where only Infrastructure as a Service (IaaS) is offered. If the departmental group can obtain compute, memory, network and storage resources from a self-service portal, then they will be able to instantiate a large number of services that they would not have been able to in the past and create a situation similar to that seen when a "rogue" employee purchases Public Cloud services "out-of-band".

When it comes to the public cloud, users might use free cloud storage systems such as Microsoft Windows Live SkyDrive as a convenient means to synchronize High Business Impact (HBI) documents without even considering that they are using public cloud services. Public cloud systems might be appealing to a manager as they could very quickly provision a new system and remove what they might see as unnecessary bureaucracy enforced by corporate IT. They may even be unaware of the security and compliance policies that are in place to protect the organization.

Furthermore, unauthorized cloud-based systems are likely to each have their own set of authentication system, credential providers, and authorization mechanisms, some of which may have significantly lower trustworthiness than others. This proliferation of credentials could at best be problematic, and at worst, result in ex-employees having the only means of accessing mission critical sensitive data by locking out formerly authorized users. In a cloud-based landscape, we must protect corporate systems and data from these unauthorized, untested systems.

References

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:

• Chilberto

Return to Cloud Computing Security Architecture

Return to Reference Architecture for Private Cloud