This is part 3 of a longer series in securing SharePoint Online as part of securing Office 365. The purpose in writing this is to provide a more comprehensive look into the aspects of SharePoint Online security, especially for those who might not have extensive experience in working with SharePoint Online yet.
The whole series contains the following articles:
- SharePoint Online and security: Overview
- Securing users and admins
- Securing content in SharePoint Online (this article)
- SharePoint Online external sharing and extranets
- Advanced security with Azure Active Directory
About content in SharePoint Online
As a long time SharePoint user, I still remember with certain fondness the very first versions of the software – SharePoint Portal Server 2001 comes to mind. You could create exactly one (1) document library, and store your Office documents there. In essence it was a simpler time then, and SharePoint acted as a glorified file share with some extra functionality.
While SharePoint Online has matured way beyond this, the essential question of content is still very valid. Users store Office documents – and other files, as many other file types are supported now – in SharePoint Online sites. For us, it does not matter if the site is technically a classic or a modern site, provisioned through SharePoint Admin Center or some other means. It still typically has at least one document library, and it supports several features we need to secure the content.
Encrypt everything?
Someone once said to me that Finnish, my native language, is a great language as it’s encrypted by default. While partially true, it’s not a particularly strong encryption scheme as even a 2 year old can learn it.
When working with customers I am often asked that since Office 365 is a shared public cloud, with many other customers using the very same infrastructure, whether all content stored in SharePoint Online should be encrypted by default.
There’s a few different ways to achieve this, and they are:
Make certain all content is encrypted before it’s transferred to SharePoint Online. We can use Azure Information Protection (AIP) for this, as it allows us to label and optionally encrypt files while creating and modifying them locally. For this, we can deploy Azure Information Protection client for classifying (labeling) and protecting files directly via Windows Explorer.
It even allows me to expire access after sharing the file with someone else. I can then track the file through the Azure Rights Management Portal (which is the old name for AIP in many cases). For each file I’ve shared with other people I can revoke access at any time, see when and where they’ve viewed the file and when the last activity occurred.
Using AIP I can now enforce these very same labels to my SharePoint Online team site. Beware, that once you enable your labels through Office 365 Security & Compliance portal, it takes up to one day for the labels to become visible for SharePoint Online.
Restricting content that can be stored
You can later use these same policies for enforcing what type of data can be stored to SharePoint Online. This is known as Data Loss Prevention (or DLP for short), and it allows us to use pre-defined sensitive information types or custom types. The purpose of DLP would be to let the user (and admins) know that certain type of data cannot be stored unencrypted – or at all – in Office 365. This is typically personally identified information such as passport and credit card numbers.
DLP is advanced enough to allow us to combine these sensitive information types and our labels. In the picture below I’ve created a DLP policy that shows a small notification for the user if content includes passport or credit card info, debit card, Finnish national ID’s or content that is encrypted through one of our labels.
With this type of approach we can enforce certain behavior for our users. We could enforce that all content uploaded to a given destination or service has to conform to these policies.
To recap, we can use AIP to encrypt, share and track files and this is based on labels. We can then use these labels in DLP, to track if users conform to our requirements for what kind of data is being stored to Office 365. This is of course a simple example of the vast possibilities these powerful services can do – yet it’s always best to start with something simple, as not to confuse your users and to be certain that data is secured in a correct and supported way.
Securing data at rest in the cloud
Another approach that I’m seeing organizations planning for is the use of Customer Key. This is a fairly new capability within Office 365, and what it allows is for organizations to encrypt data at rest using their own encryption key. There’s some good background info on how content is encrypted with BitLocker and AES-256 encryption on the datacenter side by default.
To prevent inventing yet another way to store and manage keys and secrets, Office 365 uses Microsoft Azure’s Key Vault service. This gem, which should be used more widely, allows us to create a custom encryption key, which is then used to encrypt data at rest for Exchange Online, Skype for Business and SharePoint Online.
The procedure for enabling Customer Key is a bit complex, so make sure to follow the instructions carefully. It’s worth noting that this approach requires some serious planning, as it demands two distinct Azure subscriptions for storing the encryption policies, and some communications activity between Microsoft’s FastTrack people. It’s also advisable to peek at the FAQ before initiating this change.
Over to you
Why not check out the Security in and with Office 365 using Secure Code eBook by Jethro Seghers. This eBook is solely dedicated to explaining and helping you improve the Security in and with Office 365. Download this eBook for free today!
