The National Institute for Standards and Technology (NIST) (Badger et al 2011) has produced some useful guidance to address concerns that users of cloud environments are effectively giving up:
- control in terms of absolute clarity and decision-making authority as to who can access what information and confidence that actions such as erasing data are not undermined by the existence of other copies and
- visibility in terms of being able to monitor such actions.
They use the concept of a ‘security perimeter’ (which has a fairly generic meaning covering firewalls, networks and access rights) to illustrate various ways in which security controls can be implemented. The security perimeter is composed of building blocks that can be put together in different ways depending on the nature of the cloud deployment model and whether hosting is on-site or outsourced.
The following diagrams are a selection of those discussed in the NIST report (ibid) and are used here to illustrate the relative complexity of each of the different models. The reader is referred to the full report for a detailed discussion on the risks, costs and skills required in each of the scenarios.
In this scenario the organisation requires in-house cloud skills and traditional IT skills (whilst the latter may decline over time, there may be a lengthy period when both sets of skills are needed to cover handover from legacy systems).
The number of potential attackers in the system is limited but there is still a need to secure against malicious attack from the inside and to secure data such as payroll records. Upfront costs may be high depending on whether a new data centre is required and on whether parallel cloud/non-cloud running is required or indeed feasible.
Scenario 2: outsourced private cloud
In this scenario there are two security perimeters, one implemented by the customer and the other implemented by the cloud provider. The two security perimeters are joined by a protected communications link. The cloud provider accepts responsibility for ensuring that this customer’s cloud resources are not intermingled with those of other customers.
The security levels applied should go well beyond the hardware virtualisation that occurs in the public cloud environment. The cost of connecting to the outsourced cloud and switching over to this type of cloud environment may be significant but less than in 1 above. The infrastructure is likely to be rented rather than paid for up front but of fixed capacity rather than offering the elasticity of the public cloud.
Scenario 3: on-site community cloud
This scenario depicts a community cloud. At least one member of the community must serve as the cloud provider. There could however be multiple providers of cloud space as well as some members of the community who simply consume cloud resources. The additional level of complexity this creates is clear from the diagram.
The members of the community will need to give one another access to their cloud resources whilst presumably restricting access to non-cloud resources.
Communication will also need to be effective in order to manage instances of hardware failure or planned downtime for maintenance. Community members who are cloud providers will need similar skills to those in scenario 1 (but at a higher level to cover the added complexity) and up front costs will be similarly high.
Scenario 4: on-site public cloud
On the face of it this diagram looks quite similar to scenario 2. What is different is the amount of direct competitors and potential hackers who are sharing the same cloud space. System operation and software details are usually proprietary and customers have no definitive way of managing or monitoring access to their resources and have to place trust in the cloud provider performing operations as expected. Customers can benefit from unlimited scalability although NIST warns that SLAs generally make very limited promises as to the liability of the cloud provider.
There are many other variants of these scenarios. The hybrid cloud scenario is potentially the most complex of all as it could encompass all of these models and more. There are however some potentially simpler hybrid models such as ‘cloud-bursting’ to obtain resources from a different cloud at times of peak need or the use of one cloud as a backup or disaster recovery option for another.