Security In The Cloud: Introducing Cloud Mashups
“Security in the cloud” just got more complicated with the introduction of “Cloud Mashups”.
What Do You Get When You Cross Salesforce.com and Amazon S3?
The answer we are told is Appirio Cloud Storage - a fully integrated Salesforce.com add-on that uses Amazon’s Simple Storage Service (S3) to store larger files. Previously, Salesforce.com users were limited to 5MB file uploads.
Read this quote from Appirio and think about it from a security perspective:
We’re excited not only about the service itself, but also what it represents. It shows where the industry as a whole can head - as the platforms mature, there is a substantial opportunity for ISVs to tie together the different clouds and provide offerings that extend and fill in the platforms themselves. In traditional enterprise application integration (EAI), packaged integrations were difficult to commercialize. The permutation of versions and customizations created and “n times n” problem, making it too expensive to create something “packaged” that appealed to more than a very small number of customers. But in the cloud, because SaaS providers commit to stable interfaces - Salesforce has maintained backwards compatability for more than a dozen revisions of its API - “integrating the cloud” can become a new class of solution.
From a security risk assessment perspective, you now need to factor in 3rd parties that hook into your “primary” cloud providers API.
If your company goes with Appirio, company data is now stored in Amazon S3 buckets paid for by Appirio, instead of storage paid for by Salesforce.com. This means your data is actually split across both providers (!) - old attachments and CRM data with Salesforce.com and new attachments with Appirio (if someone from Appirio is reading this and can say differently, please do).
As it happens, Salesforce.com already uses Amazon for computing and storage so its the same back-end storage. But what happens when another cloud storage provider pops up that offers a better deal? Lets say salesforce.com stays with Amazon S3 but Appirio migrates to the new player to attract more customers. [Just to be clear, not picking on Appirio here - this applies to *any* ISV - particularly those that store data somewhere else in the Cloud].
Multiple cloud storage providers for a single app, raises some issues.
- Is ISV obligated to tell you they are migrating to a cheaper cloud storage provider? (think cross border data transfer issues).
- What security ‘certification’ will take place of the new provider and what visibility will you have of that?
- How much notification do you get before the switchover?
- If you don’t want to go with the new provider, but that is the only supported option, what happens to all your data? Even if we *assume* an export function is provided you still need to find an alternate ISV that has coded a compatibility layer to access your existing data. If you can’t, where do you export the data too? Will we have ‘frozen clouds‘?
- What integrity checks take place to ensure data was properly migrated over?
- When the migration happens, what clean-up happens at the source? (can anyone say forensic wiping?). What about any backup tapes or off-line copies? Who is responsible for making sure those are wiped/destroyed?
Suddenly your cloud storage arrangements have gotten more complex and thus, less secure. Security issues aside, how does an agile business cope with this? With multiple providers, data portability becomes a real issue.
And we haven’t even dug into the API level security issues yet! (yeah, you get to assess that too!).
As an Information Security community, we have to start figuring out some of these issues before we find our options severely limited…
What do you think?










Craig,
Thanks for writing this, it’s a thought-provoking piece that should be put to anyone attempting to “integrate the cloud”. A few clarifications / perspectives from us.
1. I do not believe salesforce.com currently uses Amazon for back end storage– our ability to leverage Amazon S3 is what makes Appirio Cloud Storage an order of magnitude less expensive than other offerings.
2. We believe that customers will use Appirio only if we continually provide value with our offering, not because customers and their data are “locked in” to our solution. Its very possible, that a solution like Appirio Cloud Storage will not be needed in the future if solutions like Salesforce embed the capability into their solution. As a result, we know we have to make it easy to get data in and out of the system so that customers can adapt to a rapidly changing landscape of file storage offerings between Google, Amazon, and Saleforce. Thats one of the reasons to use us, because we won’t lock you in. That will be one of the fundamental principles and key differences from an on-premise approach to enterprise software.
3. Security was critical to us. For Appirio Cloud Storage, we never collect your username or password, we use SSL for all communication, and rely on salesforce.com to ensure an end user has access to put / get a particular file. In other words we validate at the org, user, and access level you have access to the document you are trying to get to. In addition, because salesforce.com enforces user rights all the way through to their API, we never have more rights than the user.
Ok, now to your questions.
Is ISV obligated to tell you they are migrating to a cheaper cloud storage provider? (think cross border data transfer issues).
In our opinion yes. Part of the reason people will trust us, is that we are relying on Amazon S3 for storage. After all, who are those Appirio guys? The reason you sign up with us is that we are working in the frameworks established by salesforce.com and Amazon. We’re happy to make that commitment as loudly as we can. In fact, I would say users should be able to ask for their money back if we tried to pull such a switch.
We won’t move to a new provider for storage, that would be a different offering and we won’t bait and switch you. You are trusting that Amazon doesn’t shut down S3, seems like a safe bet to us :-) I believe that answers the rest of the below questions (since we take the bait and switch off the table)
It’s a different world up in the cloud, and one that should not allow arbitrary lock-in. Much like open source, we believe millions of eyes can ensure security is maintained and vendors can’t get away with locking you in by locking in your data.
We’ll make that commitment, just make sure everyone else does too!!
Narinder
http://www.appirio.com
Narinder
Thanks for dropping by - to me its a positive sign when a vendor responds publicly to concerns. Also, congratulations on the product launch and good luck with it.
Now to respond to your comments:
1. OK, lets assume Salesforce.com isn’t using Amazon S3 - it just forwards the story to the point where customer data is now stored in two, separately managed repositories. This immediately makes things more complex IMHO.
2. Is Appirio guaranteeing that you won’t “lock in” customers either (a) one set of customers (or simply a large customer) puts you under pressure to move to a cheaper provider (”look over here, its cheaper, why aren’t you using this backend storage provider to lower your and my costs?”). I’m guessing as an ISV you would support both right? What happens if the new provider unexpectedly quits the game (funding runs out/whatever)? What kind of guarantees is Appirio willing to give business customers about getting their data out and available to another provider. I appreciate your sentiment about customers should be able to ask for their money back if you switch storage providers, but for many that will be cold comfort unless they can get to *their data* in a timely fashion. Out of interest, what data export options do you offer today?
3. I get that you are operating within the salesforce.com/amazon framework - makes perfect sense and seems like a smart move to lower the barrier to entry. Can you provide details of the storage encryption you guys are using in conjunction with Amazon S3?
Thanks,
Craig
Apologies for the delay in response. We feel confident in our choice of
Amazon S3. The value proposition is not simply a lower cost storage
solution, but the combination of cost, security, reliability and seamless
user experience. So the notion that we will move to another less reputable
provider (than Amazon) is definitely not in line with our approach.
We will offer a data export option through either an API (web services) or
potentially by providing a higher level services that simply moves it to a
client specified ftp compliant server.
There is no external access to the S3 servers information is stored on.
They are only accessible through our EC2 instance. All transmission is
encrypted via SSL, no password information is stored or sent between
salesforce and our EC2 instance. Amazon has a substantial set of
information on how there servers are locked down and S3 storage operates. Getting to the information would requiring defeating Amazon’s S3 security architecture.
Hope this helps,
Narinder
Narinder
Thanks for getting back on this. I understand you are using SSL encryption to protect network traffic but I feel you didn’t really answer my question about storage encryption. Do users of the Appirio solution benefit from encryption of their salesforce.com attachments *at rest*? If it does, please share the algorithm and key length. If not - given the potential sensitivity of the data involved (contracts etc) - what is your reasoning and have you advised your users that they should encrypt sensitive attachments before they upload them?
Thanks
Craig
On the “data at rest” issue. We are using the same approach as Amazon and Google, in fact we are relying on them. There is no single machine the data is sitting on that can be compromised Its sitting across an entire virtual layer (shards of paper scattered across the city is the analogy I believe Google uses). As such we are not offering additional layers of encryption.
Again this is same approach as other providers. I’d suggest if people encrypt data before they upload it to salesforce or store it on their local file system, they should take the same approach with Cloud Storage. For most types of information, I believe users do not do this, and it is unnecessary, but that is completely up to them. Our security is no better or worse than native attachements with salesforce.
Apr 21st, 2008 at 9:40 pm
[…] Craig Balding raises the following issues related to security cloud computing. Since some of the issues concern to the theme of this blog, opensource, open standards and open web, I thought I will link the concerns here. Some of the issues highlight the need to have a cloud computing infrastructure without any proprietary software infrastructure. Multiple cloud storage providers for a single app, raises some issues. […]
Jun 23rd, 2008 at 10:10 pm
[…] your services to the cloud, isn’t always about giving your apps and data to Google, Amazon or […]