Running enterprise applications in a public cloud offers plenty of benefits. Chief among them: Renting infrastructure from an Infrastructure as a Service (IaaS) provider reduces capital expenditures and enables agility.
However, those benefits typically add a layer of complexity to application security. When running an application in-house, IT teams understand whether and how the infrastructure is secured. But the same can't always be said of IaaS environments.
"It’s not a situation where you're absolved of the responsibility," said Jim Reavis, executive director of the Cloud Security Alliance, an organization that promotes best practices and training to improve cloud data security. "There's a fair amount of work needed to understand business requirements and technology requirements and to take architecture and risk management and good application development principles to uncover what you need to do to build this in the proper way."
Understanding shared responsibility for cloud data security
Perhaps the most notable difference between securing applications in the cloud, as opposed to on-premises, is that customers and providers share responsibility for cloud data security. Typically, at least in the beginning, "there's almost a level of ignorance or naiveness in not completely understanding what the customer is responsible for in the cloud environment," said Nikita Reva, manager for information security and risk assurance with PricewaterhouseCoopers.
You have to make sure the API that your application is talking to is configured securely, and not a lot of people know how to do that properly.
"If you were to compare Amazon Web Services with another popular Infrastructure as a Service provider like Rackspace, Amazon Web Services would give you more flexibility over the security controls, and they're more transparent with what security controls need to be put in place. But the security responsibility still needs to be shared," Reva said.
Among the areas most overlooked by AWS customers is application programming interface (API) security. "You have to make sure the API [your application is] talking to is configured securely, and not a lot of people know how to do that properly. They leave it open," Reva said. "In a nutshell, API security is paramount in this sense. That's one of the more commonly overlooked areas that I've seen."
All access to the customer's Amazon instance is through the API, Reva said. An intruder who penetrates the API essentially has ownership over the customer's entire infrastructure in Amazon. The intruder could, for example, remove applications, extract data, delete data and change the number of instances, thereby increasing the victim's service bill.
"Beyond that, individuals that are handling any sensitive data through their application that's hosted on AWS need to have a good understanding of how to protect that data," Reva said. That typically involves encrypting the AWS instance, he said: "By default, that's not in place, and they don't make it easy to do that. You need to have an understanding of how to do that within the Amazon cloud."
Cloud data security beyond Amazon Web Services
Cloud data security isn't limited to AWS customers. "The big problem that I see is that you can have these applications in the cloud, but sometimes the database or the data is still on the client site," said Gregory Machler, enterprise information technical security adviser for UnitedHealth Group, a Minneapolis-based health care company.
"There has to be a data pipe to put the data that's collected from the cloud into the databases that are still in the core portion of the data center," Machler said. "You need to open some firewall ports and send all the relevant data to and from the database. "That requires bandwidth and exposes the organization to potential weaknesses from opening up the firewall."
That circumstance also creates a gray area in terms of security responsibility. The AWS catalogue includes an option for private cloud using virtual private network (VPN) services, notes Antonio Piraino, CTO of ScienceLogic Inc., a Reston, Va.-based provider of IT operations cloud-management software.
"These VPN services naturally mean that data flows beyond the AWS data-center premises, exposing it to whatever practices the enterprise has leveraged on-premises," he said. "This is a joint responsibility between the two entities with [demarcation] points typically with the AWS facility. Beyond this infrastructure layer, vulnerability -- and therefore responsibility by AWS -- opens up more and more to the shoulders of the user."
Reavis advises companies to "understand what sort of data-protection capabilities the provider has from an information lifecycle perspective, from the very beginning -- the creation -- to the deletion of that information." That includes access controls, backup, encryption and data destruction. "Understand the gap between what the provider will give to you and what your business requirements are, which can be compliance-driven," he said.
"Take the enterprise architecture view, take your compliance requirements and map those into what compliance capabilities the provider gives you," Reavis advised. "Some will say they'll help you address certain compliance requirements, but when you're building an application on top of that, depending on how you manage data, there's an opportunity for you to support that or actually break what they're doing based on how you're managing your data. We encourage people to look at that."
The Cloud Security Alliance offers an additional recommendation for companies doing business across national boundaries, Reavis said: "If this is an enterprise solution that has international implications, then we encourage the customer to look at the data sovereignty issues and how data flows outside of different jurisdictions and what are the implications to the business as a result of that."