I went to Cloud Camp Boston recently and led a session on Collaboration, after I sat in on a session about security. Both of these are closely related, as any collaborative effort must also have an assurance that the participants in the collaboration are the only ones able to access the files or data that are part of the project. In a cloud situation, the files and data are often distributed over many different servers within the cloud. Concern was raised about shared resource situations, where multiple customers share resources on a single server in the cloud. The question: How do we prevent a malicious user from modifying or deleting content OUTSIDE of his realm? That is to say, a sideways attack.
We all agreed that normal security best practices combined with a well-structured database with proper protections in place would be acceptable in most situations, since it is going to result in same or better protections that what we enjoy in client-server situations today. We can add pre-and post-transaction encryption to the mix to protect the data in transit, which is also pretty much standard these days with SSL as a minimum level. We could add to that hardware level encryption with dedicated appliances at each end of the line that encode, split, reassemble and decode the traffic, transparently to the user, but the cloud once again becomes the issue.
In a client-server situation, there is one end-point (your data center) and multiple inputs (your clients). In a cloud situation, we add multiple end-points (the cloud). So long as the hardware encryption technology is present on all of the systems in the cloud (t which your project is assigned, of course), then there should be no problem.
On to the collaboration question. Collaboration has two meanings in the cloud; traditional person-to-person collaboration on projects,and also collaboration between apps/services in the cloud. Take Facebook as an example. Facebook opens its API to allow developers access your private data in order to enhance your Facebook experience. Facebook trades data with other applications by means of pre-arranged and well known data structures. Each application uses these data to produce is own content that gets displayed by Facebook. At the same time, the results are often shared with the user and the user's friends. Here, we have both schemes in place.
Our comfort level with our data must be driven by our trust that the applications in the cloud have been well designed and that vulnerabilities, when exposed, are addressed immediately. Unfortunately, since many cloud applications tend toward aggregation of services rather than having their own services, that trust must extend beyond to include secondary and tertiary applications, over which you have no control and with which you have no service agreement or contract. You may use an application with an email and calendaring function, for instance, but that functionality may be repackaged gmail and google calendars.
The watchwords, therefore, are "Constant Vigilance." Much like Mad-Eye Moody, we need to be aware of all of the players in our cloud applications, whether obvious to us or not. Talking to your service provider and setting clear expectations with respect to data interchange and secure transactions is also important, as your traditional agreements may not cover secondary and tertiary applications. Be sure to do your due diligence on those secondary and tertiary players as well. Despite Facebook's best efforts, an app may not have their same standards of data and privacy protection.
