In the second part of my series of blog posts on security I will cover the issue of securing access to your cloud server. Unlike with dedicated hardware, cloud servers offer you the ability to remotely conduct infrastructure management and other actions. These very powerful tools make running your cloud infrastructure significantly more convenient than dedicated hardware. It is however a double edged sword. Powerful management tools that have extensive access to your cloud infrastructure are also potent targets for those that would seek to gain unauthorised access to your cloud servers.
Infrastructure-as-a-Service (IaaS) offerings enable more points of access to your cloud infrastructure than dedicated hardware. There are four potential ways to access your cloud infrastructure, two are common with dedicated hardware equivalents, two are more specific to cloud infrastructure only. Those methods are:
The first two share the same characteristics as traditional dedicated hardware, the second two are more associated with cloud infrastructure so I’ll go into those in greater detail.
Ultimately, controlling who has physical access to the infrastructure running your cloud servers is the first step and the foundation of any security framework. In common with dedicated hardware, casual physical access to your servers will undermine any software level measures you may choose to take to secure yourself.
In the case of cloud infrastructure, the control of physical access and associated security measures is provided by the cloud vendor. In short, access to the physical server hosts should be tightly controlled and monitored. Your cloud vendor should be open about the arrangements they make with regards to securing their infrastructure from unauthorised access and monitoring the access that is provided to authorised personnel. In the case of our cloud, we are hosted in a very high security dedicated data centre near Zurich operated by Interxion. You can read more about our data center (German website), our infrastructure and our security measures. Never assume anything regarding security. Don’t assume a good website or a sizeable operation means appropriate security measures are being adhered to; it is your right to know and you should ask your vendor.
Any server with a public networking interface is potentially vulnerable to attack and attempts at unauthorised access. This problem is common to any infrastructure connected to the web and it is therefore standard practice to secure such infrastructure properly. In the case of dedicated hardware, this is generally the responsibility of the owner of that hardware i.e. the customer. The situation with cloud infrastructure is slightly more complicated. Different cloud vendors have different approaches to securing their networks. You can read part 1 of this series on this blog for a more comprehensive overview on network security and the cloud.
In the case of CloudSigma we have an open networking policy. That means that we don’t have any firewalls between your cloud servers and the open internet. Instead we give the power to the user to set up their own firewalls on their servers or use dedicated firewall/gateway servers to secure their infrastructure. This allows each customer to implement their own network security policies on their infrastructure without imposing a ‘one size fits all’ network security policy on our customers. We do of course monitor and prevent harmful network activity where necessary.
In terms of general principals, make sure you have a very secure root/administrator password to your server. Secondly, for day-to-day access use a regular user account and not the root/administrator account. Turn off network services that you don’t need or use and turn on a firewall blocking the ports you don’t need. Finally, make sure you keep your server’s operating system up to date with security patches to avoid potential vulnerabilities.
For those running larger infrastructure set-ups, it is worth considering using our VLAN functionality. This allows you to add a private networking interface to your cloud server. You can then turn off the public interface and create an internal private network within our cloud. These cloud servers will not be accessible over the open internet. Further, traffic running over a VLAN is routed on separate physical hardware within our cloud (and is also free!). You can then route all external traffic via a firewall/gateway server applying whatever network security policy you wish.
To summarise, the basis of securing access is choosing secure passwords, keeping them safe and keeping your operating systems fully up to date. In addition, turning off public internet accessibility for servers not needing it is an ideal way to side-step the issue where appropriate.
Unlike with dedicated hardware, access via a web management console is generally available for cloud infrastructure and allows customers to very easily manage their cloud servers. Keeping access secure to your web management tools is critical.
Again, any sensible security arrangements need to start with choosing and maintaining very secure passwords for web console access. We recommend choosing a randomly generated password of at least either alphanumeric characters and regularly changing it.
Last Friday we announced a new cloud server security suite of tools to help you secure web console access. The first tool is an inactivity timeout which you can set. If you forget to logout or get called away from your desk, our system will automatically log you out. You now have the ability to choose the timeout period based on your own situation. We recommend keeping the inactivity timeout to the minimum period you can accommodate without interfering with your day-to-day use of the web console.
A second, very powerful access control tool brings security of access to your web console in line with the latest internet banking systems. You now have the option to turn on two-stage authentication. This setting is invisible to any potential individual wishing to gain access but, for accounts with this turned on, after entering your username and password as usual, a second authentication stage is introduced and you will be prompted to enter an SMS code. When turned on our system sends you an SMS code that you need to enter whenever it receives a correct username and password combination. Once you enter the correct code you will gain access to the system. If however there is a failure to enter the verification code, as the account owner you will be notified by email of a correct username/password submission but no correct code. In this way you will be immediately alerted if your password has become compromised. This sort of security measure provides very strong protection against situations where your password has become compromised without your knowledge and alerts you immediately.
We have deliberately chosen as standard, security measures that provide ways for all our customers to secure access to their web console without investment in specialist authentication systems. From individuals to enterprises, the measures above allow users to meaningfully secure access to their web console. In the case of larger customers who often have their own legacy authentication tools, we work with such customers to provide customised access control systems that blend with their existing set-ups.
Google announced today that it is introducing the same two-stage authentication for its Google Apps product using SMS codes. Glad we are in good company!
One of the beauties of cloud infrastructure is the ability to automate various tasks in order to create a very powerful platform that reacts and performs as required. Essentially cloud infrastructure is dynamic with management automated via the API. As in the case of the web console, securing access and its use is essential. Unauthorised use of the API can be very destructive.
The power of the API does vary from vendor to vendor. In our case we offer full API control of accounts enabling total account management. Securing you API access is therefore critical, especially in the case of our cloud.
Again last week we announced a number of new tools that allow users to secure the API access to their account. Firstly, you now have the option to turn off API access altogether. For those not routinely using the API interface it makes sense to turn it off. As with network security, not running services you don’t use is part and parcel of securing access (our default is API access on by the way). For those that do utilise our API, we have now included a number of options that allow customers to fine tune how they access and authenticate.
Perhaps the most powerful new tool is the IP address white list. Essentially this allows you to specify a limited number of IP addresses for which API calls will be accepted. In this way, you can authorise specific machines to be able to use the API. This is already being implemented with a number of our customers who are running hybrid clouds. Namely adding our public cloud onto their existing private clouds and internal infrastructure. They wish to retain API access but only from within their corporate network. This latest tool allows them to achieve this in an elegant and easy to use way.
In addition to the IP address white list, we now have a number of options that allow you to specify how you connect to the API and what authentication methods you would like to use. You now have the option to specify HTTPS access only and to choose between Plain or Digest authentication. Finally you can also choose to use a UUID /API key combination instead of the standard username/password combination used for web console access. This last tool allows you to separate access to the API from access to the web console and for example revoke an API key without revoking the password for your general web console access.
With all these tools, our aim is to give you, the user, control over access and to allow you to implement your own policies that meet your requirements and needs. As with other aspects of our platform, we are very much about user choice and control and this extends to security. With the new suite of security tools our customers are able to fine tune access to the various aspects of our system to meet their specific needs. Ultimately security is often a trade-off between higher security or greater performance and convenience. By placing the power of choice with our customers we feel we are allowing each user to strike the right balance for their needs.
Whatever cloud vendor you choose to use, please bear in mind the four points of potential access outlined in this post. It is important to have a clear idea and understand how these access points are controlled and get comfortable that sufficient security measures are in place to control access to genuine users only for your chosen vendor.