If there’s anything around here more important than my ego, I want it caught and shot now!

This week I decided to take a step back and dedicate the entire week (with the exception of my Technology Tuesday post) to highlighting the latest and greatest in each of the different cloud service models, starting with today’s post dedicated to Infrastructure as a Service or IaaS. Throughout the week I will be exploring aside from IaaS, Platform as a Service (PaaS), Software as a Service (SaaS) and Desktop as a Service (DaaS).

So let’s just right in, shall we? Today we look at the bottom level of our service model, Infrastructure as a Service, or IaaS as it’s usually called.

IaaS refers to a cloud service model in which customers leverage the cloud providers physical infrastructure, usually a dedicated server share running virtualized machines (Vms), along with physical services including storage and networking. These services are billed to the customer based on the amount of resources required and usage, but each provider may bundle it slightly different, with some based soely on usage of resources, or some as a flat fee for a reserved block of infrastructure.

The benefit for a customer utilizing IaaS is that it can eliminate the need for an on-site data centre, or sophisticated networking. The customer doesn’t need to worry about purchasing servers, software or rack space -they simply outsource the whole thing as a complete service. The idea customer for this type of service is generally one who wants to maintain control over the environment itself, but does not have the resources to (or the desire to) manage the equipment.

So, now that we have the basic idea of IaaS, let’s look at some of the issues you need to keep in mind when deciding to move to an IaaS service. From a security standpoint, there is some difference depending if you want to do a private cloud (not shared) or public cloud (shared). With a private cloud, you retain complete control over the solution from end to end. With a public cloud, you may be hindered by the service provider in some areas, generally the SLA will make note of what you have access to from an infrastructure standpoint including compute, network and storage.

But regardless of whether you use a public or private cloud, the same key security principles apply. Since IaaS is a very basic level service (the provider is only providing infrastructure), the responsibilities for security fall predominantly to the customer, not the service provider. While there are many different security controls that need to be applied in all cloud environments, the main ones that I will address within IaaS from a customer perspective include data loss prevention (DLP), hardening (including encryption) and user authentication.

DLP is one of the key security issues that needs to be closely monitored, and critical if using a public cloud. This simply means that your organization knows who is accessing information in your cloud environment, and specifically what are they doing with it. One of the least intrusive ways to do this is to set permissions on all business-critical assets, so that there are set policies on how these assets can be used (ie do not copy, do not distribute, etc). Some DLP solutions also allow for data tagging which can remotely delete files that should not be used outside the IaaS environment. DLP works best in a silent mode where the user does not have to make decisions as to whether they are violating proper use policies or if the data is business-critical.

In regards to hardening of the infrastructure, there are two key components to this; encryption and hardening. In the case of encryption, it is recommended that you are not just leveraging full-disk encryption (if you only encrypt data files, you run the risk of back-door access into your environment and the ability for unauthorized access to files). You should also ensure that all connections to the IaaS service are encrypted with SSL VPN or IPSEC. This includes all communication channels such as those from users, remote management consoles, and inter-VM traffic (if applicable). It is also recommended that you use a mainstream encryption key -don’t use proprietary solutions built in-house, it will just make it more difficult to integrate additional services down the road.

You also want to make sure that your virtual machine templates and master image files are clean and hardened. This helps to reduce the risk of contamination should you find a security vulnerability in an image. If you make sure that your master is secure, any new machines created from the master should be secure as well.

Lastly is the topic of user authentication. This ties back into DLP as the only way that DLP will be truly successful is if you have the proper user authentication controls in place. Two-factor is the minimum that you should be using to access data in cloud environments, more-so in public cloud environments. Assign group profiles to users to control their access to data and business-critical assets. You can also rate applications and decide what levels of authorization to apply to each.

Tomorrow we look at Platform as a Service (PaaS).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s