 | |||
|
|
||
| |||
| |||
| |||
|
||||||||||||||||||||
| |
|
Home > Cloud computing News > Learning to let go: A cloud security primer with George Reese |
| |
|
|
|
|
| Cloud computing News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
George Reese: When people think of the issue of security in the cloud and why it worries them, it's the idea of losing control. You know you're giving up something, with either a managed services provider or internal [private cloud], that you had a certain level of control over. Part of it is just an emotional thing. Are there independent bodies that certify security in the cloud? Reese: I see the real issue in the cloud being more about transparency and being able to develop a level of comfort with the control you are giving up. Part of that transparency is third-party certification. In Amazon's case, the issue is that we've all got these user agreements that basically promise nothing, and then we've got a white paper that says they're doing all these things. We have to hope they're actually doing these things. The fact they've got this white paper is an element of transparency that, for example, we lack in Google. We have no idea what Google's doing. The self-service nature of cloud is great, but isn't it a real obstacle to securing your infrastructure? Reese: Certainly, for an IT department, that's a scary thing. Cloud computing is this idea that [IT] people are proliferating, and God knows what they're doing. One of the most significant problems with Amazon, for example, is the idea that you have one set of credentials to manage your entire infrastructure and that you're immediately forced to violate one of two principles: Either the principle of 'one user, one login' or the principle of redundancy and responsibility. Either you give those credentials out to multiple people and, as a result, you never know who's doing what against your system, or they're given to one person and if that person is hit by a bus, you're kind of screwed. Some vendors are pitching 'secure cloud' with hardened data centers and hardware isolation and the like. Will cloud just balkanize into different offerings with different levels of security? Reese: I think people who are focused on 'security equals hardware assets I own or lease' are the walking dead. Owning your own assets doesn't make you secure and putting something in the public cloud doesn't make you insecure. It's a false association. When you get to things like PCI or the European Union safe harbor laws around data location, the rules can be quite stringent. Cloud does not seem to be able to comply at present.
My expectation is that the standard and regulations will evolve to require certain things. If I want to be PCI level 1 in the cloud, for example, I'm going to need a certain kind of cloud vendor who has a certain kind of security certification [not yet defined]. What about private cloud? Even if a large enterprise decides to develop its own cloud, there are still real concerns about sharing a virtualized environment between multiple facets of an organization, right? Reese: That's the interesting aspect of this whole security and control question. The reason you want to go into the cloud is because Amazon has reached a level of maturity in their operations that they've achieved economies of scale that they're able to turn around and sell to you. If you can't do the basic operational level better [than Amazon], what makes you think you can do the security better? What about recent research on 'cloud cartography' that was able to pinpoint the physical locations of Web servers in Amazon and demonstrate virtualization vulnerabilities? Reese: What makes this interesting is that Amazon doesn't disclose that information. If you look at Rackspace, they do disclose where your instance is running. [This] goes to proper policies and controls again; nobody stores anything on the load balancers, which should be the only thing detectable by what you've described there. Everything else should be non-discoverable and protected by appropriate routing rules. That's one of the reasons why it's a little bit odd that organizations tend to think they can be more secure [than a public cloud], when they are doing things like leaving HTTP open to every host they have. The bottom line is, where do security concerns for the cloud lie: With the providers, the users or the managers? Reese: We've touched on the where the real security concern is, and it hasn't changed -- badly written applications and bad management policies. Those were the concerns before the cloud, and those are still the concerns in the cloud. Amazon can't make you a write a well-written Web application, enStratus can't make you write a well-written Web application -- the only person who can do that is the developer. All the hype and FUD aside, that's still what you've got to be worried about.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||
George Reese, founder of enStratus, has been delivering Software as a Service since he founded Valtira, a suite of web-based marketing tools, in 2003. Prior to Valtira, George held a variety technology leadership roles with J. Walter Thompson and Carlson Marketing Group, as well as startups like Ancept and Imaginet. George is the author of several O'Reilly books on Internet and enterprise technologies, including Java Database Best Practices, Managing and Using MySQL and the recently released Cloud Application Architectures.
