Security Considerations for Infrastructure as a Service (IaaS)

Security Considerations for Infrastructure as a Service (IaaS)


Infrastructure as a Service (IaaS) is often described by using the concept of utility computing, where a vendor offers a computing service that can be compared to other utilities, such as water or electricity, where the cost of the service is dependent on the amount of compute, memory, network and storage you might use. With IaaS, a CSP can host the entire infrastructure and you can then use the CSP's computing facilities to host your applications., This would be an example of Public Cloud IaaS. An example of a public IaaS offering would be the Amazon EC2 service.

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

On the other hand, you can host the entire IaaS solution on-premises, or in a hosted data center, where you control the entire stack, and then run your IaaS solution as a Private Cloud service. IaaS provides a framework that can grow with an organization's business. In a Private Cloud scenario, IaaS involves virtualizing, abstracting, and automating the enterprise architecture and moves IT toward a service delivery model. This results in cost savings, through better utilization of hardware, and increased agility, through the ability to provide self-service access to enterprise infrastructure to application owners. An example of a Private Cloud IaaS solution is Hyper-V Private Cloud.

To provide value over what is possible with a virtualized data center, IaaS must be scalable, and give the consumer of the IaaS solution the impression of unlimited capacity. The IaaS infrastructure is initially scaled to support projected requirements for at least the next year. The IaaS infrastructure should be designed to support fast and transparent addition of compute, memory, network and storage resources. The service enables scalability by providing a high abstracted, shared environment that hosts virtual machines for multiple tenants. Scale Units are used to provide a standardized approach to growing the entire IaaS computing base.

When using Public Cloud based IaaS, you need to obtain assurances from the public cloud CSP that there are effective security partitions that isolate tenants from one another. However, this isolation of virtual machines from one another is also required for Private Cloud IaaS solutions, as data held by one department or individual should not be made available to all tenants in the common IaaS Private Cloud infrastructure. In terms of security requirements, IaaS must implement security effectively at the level of the host, virtual machine, compute, memory, network and storage.

Network Security

In Public or Hybrid Cloud models, data will travel across the Internet and cloud services clients will connect to cloud services over the Internet. In this case the client is either a client computer that consumes a cloud service, or any internal (on-premises) system that is connected to the cloud-based IaaS system as part of a hybrid Private/Public cloud configuration.

Depending on the type of cloud service being offered, you have more or less control over the security state of clients that connect to your cloud service. If the cloud service is available to anyone who wishes to purchase access (or even obtain free access) to your service, then there is not much you can do to assess and control the security state of the client systems connecting over the Internet. However, while you can't enforce security policy on these non-affiliated systems, you can at least require that the systems support the level of network encryption you require (if your cloud service requires encryption at all). In most cases, the majority of communications between the clients and the public cloud service will be encrypted. Even in the worse case scenario, where the majority of the information moving between the client and cloud service is not encrypted, at least the log on process should take place in a secure session.

In contrast, there is much more you can do to control the security of the client system on the intranet or in your hosted data center that connects to the public cloud systems. In all likelihood the internal systems are already Internet connected and necessary protection is already in place, however this security must be validated. You could either enforce a baseline security level across all clients to ensure that they have sufficient security systems such as anti-virus, anti-malware, and up-to-date patches, and you should enforce these robust security mechanisms before a cloud service could be used to complete the hybrid solution.

In a hybrid cloud scenario all traffic must be secured between the systems inside the organization and those of the public cloud provider and necessary encryption should be put in place. Furthermore, the cloud systems themselves must be secured. A cloud vendor will maximize the utilization of all of its hardware, and to achieve this it is almost certain that hardware resources will be shared between customers (multi-tenant deployment). As part of your due diligence when choosing a cloud vendor, you should investigate what systems the cloud vendor has in place to isolate different customers' data and systems. An important aspect of this assessment is an evaluation of how network traffic of each tenants systems is isolated from the other tenants on the system.

When planning a hybrid cloud solution, the network availability of the public cloud-based infrastructure is a critical consideration. You should analyze what the effects of loss of availability of these systems is, whether workloads handled by the Public Cloud systems can be automatically transferred to the Private Cloud or an alternate location within the CSP's network (such as a data center in another locale), and investigate with the CSP what the security implications are if a system is migrated to provide availability (e.g., how is network addressing handled, how are the systems automatically configured to participate on the new network, how is name resolution and public DNS update, etc.).

Network attacks such as DNS misdirections, prefix hijacking, and DDoS attacks can result in loss of availability, or even release of private information. You should investigate how you are charged for a pay-as-you-go Public Cloud system if there is a DDoS attack. You could well be charged for all of the malicious data traffic.

Although much of the infrastructure is likely to be virtual, you can think of it in physical terms. There are virtual servers connected by virtual network cards to virtual networks and these virtual networks can be protected by virtual firewalls. The virtual firewalls might be virtualized instances of traditional network firewalls, or they may be special instantiations of network traffic control mechanisms that are integrated with the hypervisor environment. There are advantages and disadvantages of each approach, and you should discuss with your CSP what they consider to be best practices regarding network traffic control in their particular environment.

Figure 4: IaaS in a Hybrid Cloud

Isolation of your own internal systems should be a consideration in Private and Hybrid cloud scenarios. Using the traditional enterprise architecture approach, the network is physically or logically subdivided for different purposes. For example, the test department runs its own servers and is on a different subnet from the production network. In a Private Cloud scenario these systems will consume network resources out of a common resource pool. To provide the same level of network isolation you would see in a physical deployment, you should isolate the systems logically by taking advantage of network virtualization techniques.

You should implement virtual switches to subdivide the virtual network and, when available, use domain security to subdivide by identity at the network layer. Another possibility is the use of virtual LANs (VLANs). VLANs subdivide the network using software into multiple broadcast domains. Virtual switches can also take advantage of new capabilities in network hardware and virtualization platforms so that multiple dedicated virtual network buses can be assigned a path through a single, high throughput (e.g., 10Gbps) network interface card and present themselves to the virtual machines as different "virtual VLANs". Whether you are using virtual switches, virtual VLANs, physical VLANs, domain (IPsec) security, or multiple networking security mechanisms, you should create a logical diagram to represent the enterprise physical network and then implement this using the available virtual resources.

When you use this logical topology you can treat an IaaS solution in the Public Cloud which is protected by a virtual firewall in the same way that you would treat a branch office. The same would apply to an IaaS solution hosted in a Private Cloud. As part of your due diligence efforts you should inquire about network level logging and monitoring systems. Not all cloud vendors provide real time network monitoring or logging, but they should be able to provide historical information about network activity on a timely basis. This is a competitive market and monitoring and logging would be extremely beneficial when you are ensuring on-going network-level security or investigating problems and you should inform potential CSPs of the importance of these capabilities.

In the Private Cloud network security is more straightforward and many of the risks your might encounter in a Public Cloud environment are mitigated because you have complete control of the entire infrastructure, regardless if the infrastructure is hosted within an internal data center or a data center hosting provider. The infrastructure is behind one or more network perimeter security device(s) that you control and the virtual networks can be secured to exactly the same levels as the traditional enterprise model or even more so, since you will be architecting a new security environment with security in mind at each level of the Private Cloud IaaS design. The virtual servers can be separated using the methods discussed earlier and, furthermore, and software such as Microsoft System Center Virtual Machine Manager, System Center Configuration Manager and System Center Operations Manager can provide monitoring and maintenance capabilities for both the physical and virtual infrastructures..

The key difference between network security in a Private Cloud IaaS environment and that seen in a physical data center environment is related to the multi-tenant nature of the IaaS solution. This means that you will always need to be aware of mechanisms that you can use to isolate and control the network traffic between tenants and between the tenants and resources outside the Private Cloud IaaS environment. Virtual firewalls, virtual layer 2 or 3 switches, virtual VLANs, physical VLANs, IPsec isolation and more all need to be considered when evaluating network security options and requirements for the Private Cloud IaaS solution.

Storage and Data

With IaaS, you can use similar storage and data transport systems that you use in the traditional enterprise model, but in a virtual form. As the customer has control of everything on the virtual machine they can, and indeed should, implement data storage encryption and data transport encryption.

As with on-premise solutions, access control or system authorization will typically be implemented at the operating system level and can involve the following areas:

  • Access control lists (ACLs) applying to data on storage volumes
  • Permissions on directory service data
  • Message queuing permissions
  • Database access rights in server products such as SQL Server
ACLs consist of a combination of allow and deny permissions at both the user and group level, which combine to provide the resultant access rights for an individual user. Factors to consider with access control include checking that you have the exclusive ability to set permissions on cloud-based resources and that these permissions replicate rapidly through the cloud. You should also check the vendor’s policy with regard to changing those access permissions – can the vendor override your permissions and change the access policy?

The regulatory environment surrounding Public Cloud IaaS systems in most cases applies to Private Cloud IaaS. From a data protection and governance perspective, you should consider the following requirements Private Cloud IaaS infrastructure:
  • Fast access to data for which the user is authorized, and when and where it is required
  • Access is not compromised by a natural or business catastrophe
  • Data discovery must be available to answer legal and governmental requests
  • Data Loss Prevention (DLP) must be part of the service offering
  • The IaaS infrastructure should enable easy data migration back and forth between Private and Public clouds
  • Identity of data must not include its physical location, so that it can be moved easily
  • Location tags for data should be the logical country of origin, not the data’s physical location
  • Data backup and recovery operations need to be based on the data identity, not its location
  • Data-access rules (ACLs or claims) can be created and maintained by the business owner of the data
  • Access permissions can be viewed by compliance auditors
  • All data must have audit controls for both modification and access
  • Robust delegation of administration to prevent the same administrator from modifying data and audit logs
  • Service Level Agreements (SLAs) must be explicit and reflect a common understanding
Note that not all of these requirements can be enabled by the IaaS infrastructure or underlying controlling fabric. In those cases, the IaaS CSP (even if in-house) should inform the consumers of the service of these requirements and that they should be enabled at the PaaS or SaaS layers that sit on top of the IaaS Private Cloud infrastructure.

Another important consideration for a IaaS system is that multiple tenants may share the same storage mechanism and their data may be comingled with data from other tenants. While file encryption will help, it is important that compromise of the encryption key of one tenant does not impact the encryption of another tenant. The details on how this situation can be avoided depends on the storage mechanisms you choose, and any built-in encryption capabilities that are included with your storage systems. For example, whole disk encryption methods can be used to protect all data on disk, but if the encryption key is compromised, all tenants are equally affected. In contrast, if file encryption is done by each tenant, and each tenant uses a different encryption key, then compromise of one tenant's encryption key has no effect on other tenants.

In almost all instances, Direct Access Storage (DAS) will not be used in a Private Cloud IaaS environment, which means that some type of network connection is required between the member of the virtual server array and the storage subsystems. If you use iSCSI or FCoE, then you want to make sure that you have a dedicated network path between the host virtual servers and the storage array and that the path to the storage arrays is also physically secured.

Cloud Storage Systems

One area that requires specific discussion is the role of storage in cloud environments, as cloud-based data storage may introduce some security concerns to the extent that even cloud proponents do not always advocate storing data from multiple tenants in an abstracted storage resource pool which may co-locate/comingle data from different tenants and even tenants at cross-purposes. To assist this discussion, it is helpful to examine the architectural implementation of cloud-based storage. We then review the storage considerations for the different cloud service models in the light of this understanding.

Figure 5: Cloud Storage

A definition of a cloud-based storage system might be one that creates a pool of storage resources where the details of the storage solution (type of storage, location of storage, persistence of storage, etc.) is abstracted (storage virtualization) from the consumers of the service. Using this definition, both Public and Private Cloud providers can deliver "cloud storage" to their customers. The obvious security concern in this context is that data from multiple tenants can be co-located on the same disks or arrays and that a potential breach of the system can expose data to unintended tenants or malicious individuals.

A Public Cloud CSP offering IaaS solutions might give customers access to their data, either through a Web portal (in the case of direct client storage) or as a Web service (more common with server-based data transactions). Advanced implementations in a Hybrid Cloud may use a Public cloud storage gateway appliance on-premises, which translates cloud storage application programming interfaces (APIs) such as SOAP into more conventional data retrieval protocols, such as iSCSI, Fibre Channel (FC), Server Messaging Block (SMB) or Network File System (NFS).

The result is that the customer sees one physical data storage volume, even though this volume may be spread across multiple host virtual servers and storage arrays or stored in massive database systems. Access controls (authorization) coupled with authentication of user identities are then used to partition this data, preventing other customers from accessing data that does not belong to them. Cloud storage must also enable strict data storage encryption (within a database, at the file level and at the whole disk level) and end-to-end encryption to increase security. The Public Cloud IaaS provider should be explicit regarding which encryption methods are available and which are used when the data is at rest (on disk) and in flight (over the network).

Public Cloud (and to a lesser extent, Private Cloud) storage security is not as necessarily as problematic as many consider if confidentiality, integrity, and availability (CIA) is maintained through rigorous and well documented processes that include ongoing monitoring and and continuous review. While it may be considered to be unusual for sensitive data to be stored in the Public Cloud and or on the public side of a Hybrid Cloud solution, the facts of actual practice don't bear out the truth. Many large enterprises host their email systems in the Public Cloud. And while enterprise email solutions are typically part of a SaaS offering, it still remains true that much of the organization's proprietary intellectual property and other private information is stored in email messages and attachments to those email messages.

If one we're to conclude that Public Cloud storage could not be trusted, then no enterprise would consider a Public Cloud-based SaaS hosted email solution. Since we know that this not the case, there can be no truism assigned to a de facto distrust of Public Cloud storage. As long as well-architected security policies are architected and designed, and requisite security controls are enabled, enforced and subject to stringent change management procedures, Public Cloud storage can be as secure as Private Cloud, and perhaps more so, depending on the level of security sophistication and actualization of any particular Private Cloud deployment.

You should investigate what type and level of encryption the CSP uses, what identity systems are available for authentication, which mechanisms are used for authorization, whether public/private key systems are in place to provide integrity, and whether high availability solutions are provided as part of the CSP IaaS solution fabric. The same requirements exist for a Private Cloud IaaS deployment.

When defining availability for the IaaS instructure, you might want to consider a tiered solution as part of the services offering. Availability could be sub-divided into high availability and disaster recovery and provide several tiers for your consumers to choose from (such as what might be provided by a "service menu"). When working with Public Cloud IaaS CSPs, you should ask if the cloud vendor can provide mirrored storage for high availability, what level of availability can be guaranteed by an SLA (e.g. four 9s), and whether backups are offered. Another important question is what is the mean time to service restoration. In addition to using the cloud vendors own availability and encryption systems, you should encrypt all of the data that is stored in the public cloud by taking advantage of mechanisms available at the PaaS and SaaS layers. By leveraging the controls you have at the platform and finished service layers, security breaches in the public cloud would only release encrypted data.

Even with a combination of authentication, access controls, and encryption, the Public Cloud service provider may still be able to use administrator rights to gain access to the data. This concern is discussed in the section on compliance considerations. This concern is also not limited to Public Cloud Iaas - Private Cloud IaaS can suffer from the same "single point of (security) failure", where a super-user in control of the entire IaaS infrastructure can take control of the PaaS and SaaS elements and potentially breach those services' security mechanisms (for example, by using an offline attack method).

Host level

In a Hybrid Cloud scenario, host level security in IaaS systems in the public portion of the solution becomes a critical concern because of exposure to third-parties and the Internet, and also by the rapid provisioning and de-provisioning of virtual machines. The security of the host servers themselves is the responsibility of the Public Cloud vendor and you should investigate, document and include SLAs in contracts that guarantee host servers are secured using specified methodologies and are continuously monitored to assure that they remain that way. In a Private Cloud, or the Private Cloud portion of a hybrid scenario, the host server should be physically secure and security should be at the level of the highest security guest VM that could run on it. While hypervisor attacks are extremely rare and at the moment have only been performed as a proof of concept, you should ensure that the hypervisor is fully patched and up-to-date.

The guest operating systems are the responsibility of the customer and up-to-date security updates is at least as important in the Public Cloud as in a Private Cloud. The difference with Public Cloud systems is that additional VMs might be provisioned to cope with heavy workload and might depend on online updating mechanisms. Inquire about whether the Public Cloud IaaS provider is able to perform offline patching of virtual machine templates. The update level and general security of these systems must be at the same level as all other VMs.

Whether Public, Private, or Hybrid cloud is deployed you should create secure template VMs. These should have minimum capabilities, be as secure as possible, and contain no secure data, encryption keys, passwords, or anything else that could compromise security.

Architecture and Design Example:

At Contoso, they have a collection of template VMs to cover the most common scenarios. If a new virtual machine is provisioned from one of these images, it is straightforward to allow access to more resources. It is far harder to detect unnecessary permissions. When a user or application has insufficient rights they, or the developer, immediately notify the Contoso IT department. If they have excessive rights, they are typically unlikely to let anyone know.

Even in a purely Private Cloud scenario it is advisable to keep a well-documented collection of template virtual machines. There are many threats within the enterprise and most security breaches actually occur behind the firewall and therefore it is critical that these virtual machines are as secure as possible. Using template virtual machines is essentially the same as having an approved hardware and software list, along with golden images. The risk of virtualization is that the number of operating systems, software products, and virtual hardware can potentially be unregulated. The more systems deployed, the larger the aggregate attack surface of the entire IaaS infrastructure to potential threats. Therefore, you should keep tight control on the template virtual machines and the changes that can be made to them. In this way, patching and threat assessment is much more straightforward.

Bill Malone at Contoso can see the advantages of implementing a Public Cloud-based IaaS solution to reduce costs and provide dynamic increases in capacity as and when required. However, Bill knows that moving parts of the Contoso IT infrastructure to the cloud would be unacceptable to the Contoso board at this time and has decided that he should keep abreast of developments in the IaaS in the Public Cloud , but not implement this as a solution. Bill has decided that they will implement a Private Cloud IaaS solution by virtualizing servers, networks, software, and storage to increase hardware utilization and improve flexibility. This Private Cloud IaaS solution has the advantage that it could be ported directly to the Public Cloud if that decision is taken in the future.

A Security Checklist for Cloud Models

Microsoft Private Cloud Security Overview

Security Think Tank: What are the Major Security Issues with Virtualization?

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]

Return to Previous Page

Return to Cloud Computing Security Architecture

Return to Reference Architecture for Private Cloud

Leave a Comment
  • Please add 1 and 3 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
  • Richard Mueller edited Revision 21. Comment: Removed (en-US) from title, added tags

  • Fernando Lugão Veltem edited Revision 20. Comment: added toc and tags

  • Jewel Lambert edited Revision 18. Comment: more spelling corrections

  • Jewel Lambert edited Revision 17. Comment: more spelling corrections

  • Jewel Lambert edited Revision 16. Comment: corrected spelling typos

  • Thomas W Shinder - MSFT edited Revision 14. Comment: added links and community note.

  • Thomas W Shinder - MSFT edited Revision 12. Comment: added think tank link

  • Thomas W Shinder - MSFT edited Revision 11. Comment: edit

  • Thomas W Shinder - MSFT edited Revision 10. Comment: first version complete

  • Thomas W Shinder - MSFT edited Revision 9. Comment: save

Page 1 of 2 (18 items) 12
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
  • Richard Mueller edited Revision 21. Comment: Removed (en-US) from title, added tags

  • Fernando Lugão Veltem edited Revision 20. Comment: added toc and tags

  • Jewel Lambert edited Revision 18. Comment: more spelling corrections

  • Jewel Lambert edited Revision 17. Comment: more spelling corrections

  • Jewel Lambert edited Revision 16. Comment: corrected spelling typos

  • Thomas W Shinder - MSFT edited Revision 14. Comment: added links and community note.

  • Thomas W Shinder - MSFT edited Revision 12. Comment: added think tank link

  • Thomas W Shinder - MSFT edited Revision 11. Comment: edit

  • Thomas W Shinder - MSFT edited Revision 10. Comment: first version complete