MANAGED SERVICES cloud
So how can we secure our data when we don’t necessarily know where it is – perhaps not even in which country it resides?
This highlights another area where cloud computing is only just starting to follow developments in the finance sector and that is in the definition of common standards and service levels. Clearly, when sensitive corporate data is stored and retained beyond the direct control of the corporation, then legal frameworks need to be established with the supplier of those services. As such frameworks become standardised, the decision to hand over that control will become easier. And while data protection legislation exists across most of the developed world, the laws, and perhaps equally significantly, the penalties and likelihood of prosecution when those laws are broken, still vary significantly from country to country.
Ideally, security administrators would be able to manage all external
as well as private resources. They would also be informed in the event of any breach, attack or other incident on a resource that has been exploited by a third party. Sadly, this is still something cloud computing service providers (SaaS, PaaS or IaaS) still rarely offer.
Just like the money in our bank accounts, as we outsource the storage of our data, so do we outsource the protection of that stored data. However, its management and retrieval is another matter, so why not just make sure that we lock down all possible methods of access?
One problem with this approach is that with the rise of web-based applications, legacy security appliances can no longer distinguish sensitive application data from everyday web-browsing since they will likely use the same TCP / IP port – port 80. Another problem lies in the lack of control of access devices. Here perhaps the banking analogy breaks down, for while banking customers may be unlikely to request cash withdrawals from their own personal devices, this is exactly what today’s corporate IT managers are faced with. The problem of unauthorised devices being used to connect to the network and its resources, referred to by some analysts as “shadow IT”, adds another level of complexity to security within a cloud environment.
The reality is that IT professionals don’t really have a choice; they can fight the wave and lose, or try to surf it. Application-level security policy should replace device- based access-lists - whatever the device is - personal or corporate. Despite what some security vendors may tell you, this does not mean you have to forget the devices completely. You just need to have the ability to recognise them and apply different security profiles accordingly. Technology can help. A well-chosen unified security gateway should be able to manage local and remote access, automatically identify the applications and devices in use, and apply different security inspection strategies based on this information.
Tracking the different usage scenarios and automatically adapting your security policy gives you an all-important advantage over a simple blocking strategy: you know what’s happening. This enables you to act on the most important link in the overall security chain: your users.
Finally, some practical steps that organisations can take to secure the cloud:
1. Rethink peripheral security in order to take into account both the existing architecture and the virtualised resources under the control of your service providers.
2. Accept the reality of shadow IT, balancing security efforts between the new smaller perimeters, staying as close as possible to devices that host the most strategic applications and which store the most sensitive data for the company and its clients, and employing deeper inspection and analysis of application and user behaviour.
3. Map virtualised security appliances to strategic applications, so that the company’s sensitive data remain protected, regardless of where the physical platforms supporting them are located.
May 2012 I
www.dcseurope.info 45
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52