It has been wonderful to discuss with software vendors both large and small their transition to the cloud. And as you would expect, security is very much “top of mind”.
After reading a post by Olivier Coudert, I decided to provide a high-level description of some of the main techniques used to secure a cloud implementation. Hopefully it’s useful when considering a cloud (Infrastructure-as-a-Service, IaaS) or platform (Platform-as-a-Service, PaaS) provider.
Most of our customers use our platform with the Amazon cloud. And so the infrastructure portion of this discussion will be taken from their implementation, described in more detail in their white paper. (One of the primary reasons why we built our platform on top of Amazon’s infrastructure is because of their security.)
The areas to consider are illustrated below. The user (client) on the left, and the public or private cloud on the right form the two end-points. The communication network in between (what we used to call “the cloud”, before there was “The Cloud” 
) is the other key component.
End-points to Cloud Security
The Cloud - Physical Security
This is the most fundamental of considerations. Not only is it important if your data is valuable, but if you’re in a public cloud consider what else could be stored and valued in the same physical location.
The Amazon Cloud boasts extensive physical security measures, protocols, and technology, including “military grade perimeter control berms” and other “natural boundary protection”.
The Cloud - Logical Security
Firewall
Many breaches of security come from bots pinging IP addresses on multiple ports, mechanically looking for a way to get in somewhere (Port Scanning).
This type of attack is prevented at the Firewall:
(i) Close all ports except those that are to be used. And only open those when they are actually used.
(ii) Restrict access by the protocol used (http, ssh, etc.)
(iii) Restrict access to only known client IP addresses.
In addition to this, AWS detects port scanning, stops it and blocks it. Counter measures are also in place to protect against Distributed Denial of Service (DDoS) and Man In the Middle (MITM) attacks.
Operating System (Host and Guest)
Operating System Security
The Host Operating System that resides on the actual hardware needs to have strong key access to a limited number of Administrators. No one else should have access at this level. And those that do have access should only have it on a limited basis and only when they are doing actual work.
Guest OS’s (the virtual instances that are actually used by the hosted software) are isolated from the Host by the hypervisor (which also provides isolation between running instances). Unprivileged Access to these instances should only be allowed via token or key-based authentication.
Key control is paramount for success at this level.
Data - Backup & Encryption
All stored data should be redundantly backed up, ideally (as with AWS) in multiple physical locations. In addition, data can be encrypted on the remote instance. In fact, encryption can be taken down to a very low level, but performance trade-offs come into play very quickly.
The Network
Other than protection from threats residing elsewhere on the network, data interception should be protected against. Therefore, data traveling across the network should be encrypted. In our case, we implemented communication and data transfer protocols that use AES-128 symmetric key encryption for all data sent between the client and the cloud server.
The User
After all of the above (and much more) has been put in place, we still need to provide access to users (customers) outside of the firewall. And so we need to know who the users are, and to be able to confirm that they are indeed who they say they are.
In order to scale the business, the authentication and validation process must be automated and built into the on-boarding and access process.
Fortunately, as we’re dealing in a business-to-business environment, the easiest and most reliable way to automatically confirm identity is via an email validation process during user on-boarding.
Once validated and prior to accessing the cloud, the user’s identity should be authenticated again using the email address (or a username linked to the email address) and a password.
On the Xuropa Platform, we go one step further and add an additional security protocol to ensure that only the previously authenticated user can gain access to the cloud from a detected IP address.
Life’s a Trade-off
These are just a few of the techniques employed - when it comes down to it, anything is possible. However, people need to have access, and in order for businesses to run, access needs to be straight forward for the user, monitored, controlled, and automated.
In architecting our platform, security is paramount, which means we have to put a great deal of effort into automation and the user experience (UX) design.
How are you securing your cloud processes? And what are your concerns related to security?
Posted under Xuropa
Did you see the news that HP announced their foray into the public cloud space? It is great to see another classical computing giant offer cloud services (Dell, IBM).
For many (most?) software vendors, a move to the cloud has transitioned from an abstract concept to an implementation discussion. ”How do we provide our software to our customers via the cloud?”