Microsoft has added a number of new features to Azure to support the European Union’s General Data Protection Regulation (GDPR), which many organizations outside and inside of Europe will require to avoid stiff penalties. This post discusses the new features.
Plenty of material has been published in the last few weeks that covers GDPR more than we have time for here. In short, if you store personally identifiable information (PII) on a European Union citizen, then you must have consent for a suitable amount of data for the consented processing, keep it only as long as the data subject has agreed, secure that data, be able to produce reports on that data for data subjects, and delete that data upon request by the data subject.
Azure has either added new features, modified existing services, or made previously preview functions generally available to support compliance with GDPR as of May 25th.
Note that these announcements are to support your usage of the Azure infrastructure and platform, where the data subjects are your employees, contract staff, or external engineers with access to the administrative features of Azure. What happens inside a virtual machine or at the application layer is your responsibility, so you will either need to acquire third-party solutions or implement changes to custom-developed code.
Data Subject Requests
A data subject is a natural person that might have PII data stored in your systems. Azure does not have some magic tool that gathers everything into one place. Instead, you will use a series of tools to access data.
Some personal data on employees can be found in Azure Active Directory (AAD), namely the user account and profile data. If you open Azure Active Directory in the Azure Portal, browse to Users. If you can find a user for the data subject, then there is still PII to report on. You can open the profile of the user (open the user) and view/capture/modify/delete the data as required.
If a data subject requires an export of its data, then you can use Azure Policy. This was recently made generally available. Open the Azure Portal, search for and launch Azure Policy, click User Privacy, and go into Manage User Requests.
You can click + Add Export Request to start the process. Enter the name of the user account in question and specify a storage account that the exported data will be stored in. And then, you have to wait between w and 30 days. 30 days will put your Controller at risk of violating GDPR compliance because they have 1 month to respond to the Requestor. However, a 2-month extension can be requested of the Requestor if the Controller can prove that the search is complex.
A data dump will be written to the storage account in a container named after the user account. I have yet to see the results of an export. I’ve been waiting a few days for my first export!
The Controller and Processors that collect/store/use PII must secure that data and restrict access to just those users/systems that require access for the consented purposes.
We can use Azure Policy for governance, helping us with enforcing policies onto a subscription or resource group, and preventing unwanted practices or access. Policy includes several components:
- User Privacy: As previously mentioned
- Definitions: A set of built-in and administrator-defined policies for locking down Azure with the concept of Initiatives, which can group those policies for easier deployment
- Assignments: A listing of applied policies or initiatives
- Compliance: Comparing assignments with the realities of what is deployed/configured
Some of the built-in policy definitions include:
- Auditing Transparent Data Encryption (TDE) in SQL databases for securing PII
- Finding web applications that do not have a Web Application Firewall (WAF)
- Enforcing encryption on Data Lake stores
- Allowed locations/Azure regions
It is the responsibility of the Controller to ensure that data security is built into the design. To aid with this, Microsoft has produced the Azure Security And Compliance GDPR Blueprint website. You will find some GDPR documentation and links to Office 365 tools. The documentation library breaks Azure down into different sections and provides plenty of information on how GDPR affects that section.
A number of additional reference architectures are also shared by Microsoft explaining the architecture, component roles, threat models, compliance, and recommendations. If you wish to build a web app on PaaS or IaaS and GDPR is a concern for you, then these reference architectures are a good place to start your architectural process.
Microsoft provides us, as long as you don’t use the government or private cloud services, with a tool called Compliance Manager for assessing Office 365, CRM 365, and Azure. This tool can assess your subscriptions against a number of different certifications – GDPR, ISO 27018:2014, or ISO 27001:2013.
Note that you must sign in using a work account (not a Microsoft account or “Live ID”) to use this tool.
What do you get from the tool? You will see a report on Microsoft’s responsibilities as a processor or the host of your services and data. There is also a set of customer responsibilities, which is not assessed by this tool. You can see each “control” or responsibility, assign it to an owner, upload documentation, update assessment status, and record an audit result. In short, the tool provides a structured approach to help you with your manual assessment of your Azure implementations in a structured manner.
Lots of Work
If you quickly browse the above features, documentation, and tools, you will find that complying with GDPR is much more work than checking some boxes. Using these tools, you can build compliance into new designs, assess your environment, and use a structure with this lengthy process.