There are two major problems with the oft-asked question, “Is it possible to actually secure your data once it’s in the cloud?” Those problems are the words, “secure” and “cloud”—both of which are subject to widely varying notions of what they mean.
In many conversations, “secure” means merely “no unauthorized access.” That’s not really useful, if it’s the only thing that’s promised. “Cloud” has the opposite problem of being often defined too broadly: the label is commonly slapped on any externally located IT facility, which may not even begin to satisfy the goal of providing enterprise-grade service.
Let’s start this discussion by raising expectations for security. For data to be considered usefully secure:
- Data integrity must be assured. It’s not enough that the bad guys can’t see it; one also needs to be confident that neither malice nor accident will corrupt it.
- The owner of data must be able to define and grant role-based access: full read-write privileges for some, read-only for others, anonymized and/or aggregated views for those with no legitimate need for more.
- The custodian of data must have visibility—and be able to maintain accountability—as to who has done what, when, from where, with the privileges that the owner has granted.
- The data must remain available to those with appropriate permissions. Security can always be made tighter at a cost of greater difficulty of access–but in practice, inconvenience (or unreliability of access when/where needed) will likely lead to evasion.
Now let’s talk about the cloud. There must be a clear distinction between “cloud” as remote location, and “cloud service” as enterprise-grade offering. Building a room full of hardware, even if decorated with virtualization tools, does not create a cloud service—any more than buying a dozen trucks creates a delivery service. Training, learning, and the highest standards of transparency to customers are crucial ingredients that take time to develop and constant effort for a service provider to maintain.
Further, cloud services are not all created equal. There are poorly designed clouds that merely duplicate the brittleness and excessive privilege grants of legacy IT models. There are poorly administered services that make no pretense of rigorous protection. No due diligence would ever find these appropriate for use in handling sensitive information.
Many respected industry observers have stated that a multi-tenant design is a requirement for the label of “cloud”—and multi-tenant design enables more precise control from the bottom up, because data ownership is baked into the data representation instead of being relegated to the data container. Forrester’s John Rymer has been among the most emphatic industry analysts in his comments on the positive consequences of the multi-tenant model, saying in a blog post in March 2012:
“Despite resource sharing, multi-tenancy will often improve security. Most current enterprise security models are perimeter-based, making you vulnerable to inside attacks. Multitenant services secure all assets at all times, since those within the main perimeter are all different clients. Leveraging a mix of dedicated resources and metadata map architectures, these services can deliver stronger security.”
True to Rymer’s description, there are cloud services (including salesforce.com’s) that offer granular control of role-based privilege; that hold extensive formal certifications; and that undergo frequent professional testing by (or at the behest of) the company’s customers and their internal security teams. Does the result satisfy our criteria for useful security?
First, does this kind of cloud improve data integrity? People have grown too accustomed to the routine destruction or corruption of data in legacy IT environments, often caused by lost devices or storage media; human error; or failed backups. Cloud services, in general, minimize the accumulation of data at the edge of the network; maximize consistency of operating environments, by emphasizing common configurations and automated procedures; and routinize the testing and verification of backups and other safety measures, less often seen in on-premise IT environments.
Importantly, a service that’s “born cloud” (and is not merely relocated legacy technology) also breaks entrenched dependency on single-vendor client ecosystems. When designed for the cloud from the bottom up, services are expected to work across multiple platforms and browsers—freeing companies from tight coupling with legacy browsers and plug-ins, which often prevents technical teams from securing their environments and operations.
Second, does this kind of cloud enable granular privilege management? As previously observed, clouds are not all created equal. Many services merely relocate traditional, hierarchical models of access control, which makes them better termed “outsourced” than “cloud” IT. One must distinguish clearly between “can” and “does,” but we have already discussed the positive outcomes that true multi-tenancy enables.
Third, does the cloud provide visibility and accountability? In too many legacy IT environments, everyone “inside the wall” has excessive privilege to see and to share everything—and in such environments, the easiest way to share things is to make and transmit copies that escape all subsequent efforts at control. In contrast, cloud applications can be designed and configured to make secure behavior more convenient—and therefore more likely.
For example, a cloud-based collaboration tool can let employees grant external customers or partners specific access to specific data—with the ability to log the time and manner of any external access using those privileges, providing far superior visibility and governance compared to the sending of email attachments. Versioning of documents can be automated and consistently performed by cloud-based applications and platforms. Rollback to a known good state can be enabled, not only for relational data, but also for unstructured data and even for application logic. Again, these capabilities are not inherent in all clouds, but are demonstrably possible because they have long been available in many cloud services (in some cases with augmentation by third-party offerings).
Finally, will cloud-resident data be available? Web sites like trust.salesforce.com and status.aws.amazon.com are evidence that this can be done to an impressive and continually improving degree—and that the bar has been set for enterprise-grade services to share candid and timely information about their own performance.
For those still not fully persuaded, an important point (often not understood) is that the decision to use the cloud does not have to be a polar choice between all or none. Specific data, even specific fields of records, can be assigned to local storage—or encrypted cloud storage—in a manner that simultaneously satisfies concerns about sensitivity, regulatory compliance, and utility of information while also gaining value from cloud-based analytics.
Cloud is a choice—and that choice absolutely includes the ability to be secure.
Peter Coffee spent ten years as a practicing engineer in petrochemical and aerospace projects before his 19-year detour as Technology Editor at PCWeek (which later became eWEEK). He’s now VP and Head of Platform Research at Salesforce.com, where he works with CxOs and ISVs to advance the state-of-the-art of cloud-based application development.