AZ Jim comments in my editorial about SharePoint as a Service:
“One thing I haven’t heard discussed about SharePoint as a Service is security/auditability. For PaaS, database encryption at-rest is the norm (I believe). But unless your Word and Excel files are incorporated as database LOBs, are the external files encrypted? That plays a key role in regulatory compliance for PCI and HIPAA in the US and whatever other compliance is performed outside the US. If the database is stored as LOBs, the size of the database can grow to monstrous proportions (and impact backup/recovery). In other words, are you choosing between bad performance with good encryption, or unencrypted external files with good performance? I am not making a statement — just asking the question.”
I think this is a good question. I am not the “Expert” on this issue. However, I do have some very strong opinions, and a lot of experience in this matter. Here are a few of my thoughts in no particular order.
Personally, for many of the reasons Jim sited, I don’t like putting LOBs in a database. I think the argument for it being an ACID transaction is forced. Save the file to disk before you write a record to the database, identifying where the file is store. Sure, you can use filestreams…but what do you really gain. Any company able to adequately backup and restore a database should be able to include any files as well.
If you really must put it in a database, then put it in separate tables on a separate database file object. Then you can do file group backup and restore. Moreover, you don’t have large file objects fragmenting your relational data.
Don’t encrypt in the database. Many companies who comply for PCI use an external encryption tool. Why do you want to slow down your data engine by having it do encryption as well? Using an encryption appliance you data can ALWAYS be encrypted, even in memory. Not only that, if a backup of your database is stolen, without having also stolen the encryption appliance, and it’s keys, there is little they can do to recover data.
I know this flies in the face of what has been enabled in SQL Server. They have built encryption, file streams, and blob storage. Use them…and then as your application grows, begin looking for a larger server. Oh yeah, we used to call that a mainframe. We have worked hard to learn how to build distributed systems, even micro services. We can scale out on a near infinite level. We have platforms designed to work most effectively in a distributed model (Azure, etc.).
So, let’s apply this set of obstinate personal opinions to SharePoint as a Service. Let’s say you want to store protected information, such as patient confidential notes, in a SharePoint as a service engine. What would you do if you want to pass HIPAA compliance by encrypting confidential documents at rest? If you use an encryption appliance, your documents are encrypted prior to writing, and decrypted while reading. So, making a SharePoint call to save the document has nothing to do with encryption; it is only responsible for persistence. We are not relying on SharePoint to assure our documents are encrypted. That is the responsibility of some other tier in our application architecture.
The second point is how SharePoint stores documents. If a SharePoint database were chosen for persistence, then you have less control over your options. In this case, for those tables containing my BLOB data I would move them to separate file objects in the database. You can do that through index creation without changing the schema. Be sure to do it early on. It will take much longer to do as data is added to your tables.
Most likely, I wouldn’t choose SharePoint as a Service to persist HIPPA confidential data in the architecture. Using a good repository pattern, nothing keeps you from using a hybrid persistence capability both in and out of SharePoint, while the client has no clue this is going on.
Thanks for the comment AZJim. I hope to have you challenge my thoughts on this. If you agree, or don’t agree, your comments are always welcome. So, get into the conversation, for the benefit of us all.
Cheers,
Ben