Securing Data in The Cloud

I just found an interesting article about securing your data in the cloud. Now that cloud computing has gained quite a number of followers, it will be good to understand the additional necessary steps to ensure your confidential data are secured in a cloud computing environment.

The original article can be found here.

---

Storing data in the cloud is arguably the most important aspect of public cloud resources, but it is rarely treated as such. Two practical steps to take when securing cloud data are:

• Protect your data in a real world environment.
  
• Meet compliance requirements.
  

What are the issues?
There are two primary issues that we have to deal with when talking about data security in a public cloud:

• Protection of the data: Dealing with the confidentiality, integrity, and availability (CIA) criteria. Answering the important questions, such as, "What is the risk to the data? Are the controls in place adequate to mitigate the risk?"
  
• Location of the data: Dealing with the physical location of the "bits" and answering questions like, "Do I know where the data resides? Does this violate any of my compliance requirements?"

Location is often doubly important because we do not think about it; it may easily slip by unnoticed and have significant impact if a data loss ever occurs.

An example is the conflict between the U.S. Patriot Act and Canadian laws on the privacy of certain personal information. The U.S. government says if there is a compelling reason, they are able to see data in their jurisdiction. Canadian laws say that the data of certain Canadian citizens is protected and cannot be disclosed. If you handle Canadian data (i.e., data that is protected), then you had better be sure it is not physically located on systems in the U.S. Note that this is something providers will need to ensure via contracts.



Where to start: Data classification
If you don't take time to understand your data, then you are setting yourself up for failure in a public cloud environment. Therefore, securing data must begin with data classification.

Here are some steps to follow:

1. Identify the data that will be processed or stored in the cloud.
   
2. Classify the information in regards to sensitivity towards loss of the CIA criteria. This would include identifying regulatory requirements for the data.
   
3. Define the rules by which particular information classes of instances must be stored, transmitted, archived, transported and destroyed. Many handling requirements result from contractual or regulatory requirements.
   

A thought on physical location
As stated earlier, if there are restrictions on the physical location of data, you'll need to find a provider that can handle them. Amazon Web Services uses regions, and many of the other cloud providers offer similar structures. However, you need to ensure the service-level agreements meet your locality requirements.



Protecting data in the cloud
In the cloud, your data can be in any of the following locations:

• Local storage of the virtual machine (i.e., processing engine). Data is tied to the virtual machine location and state.
  
• Persistent data store (i.e., Amazon EBS or S3, Azure SQL, etc.). Data is independent of virtual machine location and state.
  
• In transit on the wire.
  

You will also need to use one of the following methods to meet your data protection requirements:

• File system and share access control lists: This would be using the access control mechanisms in the offering to ensure appropriate restrictions on the data. This would be used in all cases, but it would not protect from malicious IT staff at the provider.
  
• Encryption with a mixture of public and private key solutions: This would most likely be used to protect against malicious IT staff at the provider.
  
• Transport level encryption: This would be used as a matter of course whenever sensitive information was being passed or transmitted.
  

In closing
I strongly insist that everyone classifies their data. Once that is done, there are a couple of cloud issues you need to think about:

• Is my data stored where is should be?
  
• If there are any physical location limits, are those met?
  
• Am I protecting against malicious IT staff?
  

The rest should be basic security practices, much like those used in your non-cloud environment. There is nothing obscure about securing data in the cloud. Just remember that "good security is good security" and you should be good to go.

---

Run your own Ubuntu Enterprise Cloud, part 3

A continuation and final article on how to set up cloud computing on Ubuntu. This information is originally posted here.

---

In part 1 and part 2 of this series, we saw how to set up a minimal cloud infrastructure and bundle a basic image (and test it). In this final article, we’ll play with our cloud from an end-user perspective.

Setting up the web UI

First of all, before accepting end users, as the administrator of the cloud you will have to setup a few things on the web UI. Using your favorite browser, you should:

* Open https://cloudcontroller:8443/
* Log in using the default user/password: admin/admin
* Change the default password, setup the cloud admin email address
* Logout

Setting up the cloud client

We’ll use Ubuntu 9.10 beta for this purpose, as it includes all the needed packages, and it’s so great ! You will have to install the following packages:

      $ sudo apt-get install euca2ools unzip



Registering on UEC, getting credentials

As the end-user, fire up your favorite browser and:

      * Open https://cloudcontroller:8443/
      * Click “Apply” and enter your end user details

If you set up the email correctly on your cloud controller, it should send an email to the cloud admin address asking him to approve that request. Follow the instructions on that email to approve the account as the admin.

You should then get an email at the end user email address asking you to confirm the account request. Follow the instructions on that email, then you can log in on the web UI:

      * Open https://cloudcontroller:8443/
      * Login using your end user username and password
      * Click “Download Credentials” in the “Credentials” tab
      * Note the EMI reference you can use on the “Images” tab

Starting up an instance

You should unzip the credentials zipfile you just downloaded, then source the eucarc file and test the connection:

      $ unzip euca2-enduser-x509.zip
      $ . eucarc
      $ euca-describe-availability-zones verbose

Setup a SSH key and allow connection to the SSH port:

      $ euca-add-keypair enduserkey > enduserkey.priv
      $ chmod 0600 enduserkey.priv
      $ euca-authorize default -P tcp -p 22 -s 0.0.0.0/0

Then starting up an instance is just a matter of passing the right EMI and type:

      $ euca-run-instances -k enduserkey emi-XXXXXXXX -t c1.medium

Enjoy !

---

Run your own Ubuntu Enterprise Cloud, part 2

A continuation on how to set up cloud computing on Ubuntu. This information is originally posted here.

---

In part 1 of this series, we saw how to install the cloud infrastructure. In this article, we’ll bundle and upload an EMI (Eucalyptus Machine Image), based on Ubuntu Server 9.10 Beta, and validate that we can run an instance of it.

Download required elements

Go to the cloud/cluster controller and download the required items.

For a 64-bit image:

      $ URL="http://uec-images.ubuntu.com/releases/karmic"
      $ wget -O image.gz $URL/beta/ubuntu-uec-karmic-amd64.img.gz
      $ wget -O vmlinuz $URL/beta/ubuntu-uec-karmic-amd64-vmlinuz-
        2.6.31-11-server
      $ wget -O initrd $URL/beta/ubuntu-uec-karmic-amd64-initrd.img-
        2.6.31-11-server

For a 32-bit image:

      $ URL="http://uec-images.ubuntu.com/releases/karmic"
      $ wget -O image.gz $URL/beta/ubuntu-uec-karmic-i386.img.gz
      $ wget -O vmlinuz $URL/beta/ubuntu-uec-karmic-i386-vmlinuz-
        2.6.31-11-generic-pae
      $ wget -O initrd $URL/beta/ubuntu-uec-karmic-i386-initrd.img-
        2.6.31-11-generic-pae



Bundle the EMI

First you should unpack and resize your image to the desired size, lets say 4Gb. This can take a very long time (15 minutes !) on slow disks as you unpack 10Gb-worth of image space:

      $ zcat -f image.gz | cp --sparse=always /dev/stdin image
      $ e2fsck -f image
      $ resize2fs image 4G
      $ truncate --size=4G image

Then bundle and upload the kernel:

      $ . eucarc
      $ euca-bundle-image -i vmlinuz --kernel true
      $ euca-upload-bundle -b ueckernel -m /tmp/vmlinuz.manifest.xml
      $ euca-register ueckernel/vmlinuz.manifest.xml
      IMAGE eki-KKKKKKKK

Take note of the EKI reference, you’ll need it later. Then bundle, upload and register the ramdisk:

      $ euca-bundle-image -i initrd --ramdisk true
      $ euca-upload-bundle -b uecramdisk -m /tmp/initrd.manifest.xml
      $ euca-register uecramdisk/initrd.manifest.xml
      IMAGE eri-RRRRRRRR

Take note of the ERI reference. Finally, bundle the image with the kernel and ramdisk, upload and register:

      $ euca-bundle-image -i image --kernel eki-KKKKKKKK --ramdisk
        eri-RRRRRRRR
      $ euca-upload-bundle -b uecimage -m /tmp/image.manifest.xml
      $ euca-register uecimage/image.manifest.xml
      IMAGE emi-XXXXXXXX

Bundling will also take a lot of time ! Take note of your EMI reference.

Start an instance of your EMI

In order to access your instance using SSH, you’ll need to setup a few one-time things (create a SSH key and authorize access to port 22 of your instances):

      $ euca-add-keypair mykey > mykey.priv
      $ chmod 0600 mykey.priv
      $ euca-authorize default -P tcp -p 22 -s 0.0.0.0/0

Now it’s time to start your instance !

      $ euca-run-instances -k mykey emi-XXXXXXXX -t c1.medium

The “c1.medium” VM type is sufficient by default to run a 4Gb instance. You should take note of the i-YYYYYYYY reference that is displayed on your INSTANCE line. The first time you start an EMI, it can take some time (like 10 minutes) to move from “pending” state to “running”, depending on size. You can use the following command to automatically watch the output of euca-describe-instances, every 5 seconds:

      $ watch -n 5 euca-describe-instances

Take note of the first ZZZ.ZZZ.ZZZ.ZZZ IP address mentioned in the output of the command. When the instance is “running”, ctrl-C to exit watch, then:

      $ ssh -i mykey.priv ubuntu@ZZZ.ZZZ.ZZZ.ZZZ

You are in ! When you’re done playing with your instance, just run the following command on the cloud/cluster controller.

      $ euca-terminate-instances i-YYYYYYYY

In the third and last part of this series of articles, we’ll talk about how to run instances from another workstation, as a cloud “customer”.

---

Run your own Ubuntu Enterprise Cloud, part 1

This information is originally posted here.

---

Ubuntu Enterprise Cloud is the product, powered by Eucalyptus, that allows you to easily run your own Amazon-EC2-like private cloud. It’s a lot simpler than you’d think. With the recent Ubuntu Server 9.10 beta release, you are now able to easily deploy that infrastructure from the CD installer.

Prerequisites

To deploy a minimal cloud infrastructure, you’ll need at least two dedicated systems. One will hold the cloud controller (clc), the cluster controller (cc), walrus (the S3-like storage service) and the storage controller (sc). This one needs fast disks and a reasonably fast processor. The other system(s) are node controllers (nc) that will actually run the instances. These ones need CPUs with VT extensions, lots of CPU cores, lots of RAM, and fast disks. For both, 64-bit support is highly recommended.

Installing the cloud/cluster controller

Download the 9.10 Server beta ISO. When you boot, select “Ubuntu Enterprise Cloud install”. When asked whether you want a “Cluster” or a “Node” install, select “Cluster”. It will ask two other cloud-specific questions during the course of the install:

      1. Name of your cluster: pick any name you want :)
      2. List of IP addresses on the LAN that the cloud can allocate to instances:
         enter a list of space-separated unused IP addresses on your LAN.

When it reboots, run the following to get the latest eucalyptus package and reboot:

      $ sudo apt-get update
      $ sudo apt-get upgrade
      $ sudo reboot

Installing node controllers

The node controller install is even simpler. Just make sure that you are connected to the network on which the cloud/cluster controller is already running. Take the same ISO, select “Ubuntu Enterprise Cloud install”. It should detect the Cluster and preselect “Node” install for you. That’s all.

It is also recommended to update to the latest 9.10 status:

      $ sudo apt-get update
      $ sudo apt-get upgrade



Connect your node controllers to the cloud

After all nodes are installed, you need to return to the cloud/controller and run the following command to make it “discover” your newly-installed nodes.

      $ sudo euca_conf --no-rsync --discover-nodes

Confirm all the nodes it finds, and you are done. To check that your private cloud infrastructure is ready to serve, you need to retrieve admin credentials and run euca-describe-availability-zones command. Run the following on your cloud/cluster controller:

      $ sudo euca_conf --get-credentials mycreds.zip
      $ unzip mycreds.zip
      $ . eucarc
      $ euca-describe-availability-zones verbose

This last command returns a description of the capabilities of your cloud cluster, how many instances of each type you could run on it, for example:

AVAILABILITYZONE myowncloud   192.168.1.1
AVAILABILITYZONE |- vm types  free / max  cpu  ram disk
AVAILABILITYZONE |- m1.small  0004 / 0004  1   128    2
AVAILABILITYZONE |- c1.medium 0004 / 0004  1   256    5
AVAILABILITYZONE |- m1.large  0002 / 0002  2   512   10
AVAILABILITYZONE |- m1.xlarge 0002 / 0002  2  1024   20
AVAILABILITYZONE |- c1.xlarge 0001 / 0001  4  2048   20

In part 2 of this series, we’ll cover bundling your first EMI (Eucalyptus Machine Image), based on Ubuntu Server 9.10 Beta. We’ll test it by starting an instance of it. Stay tuned !

---