GDPR and the Cloud: What You Need to Know
The level of attention to privacy, security and data sovereignty won't be easy. Companies that haven't already started down this path are potentially in deep, deep trouble.
When exploring IT outsourcing of any kind it doesn't take long before privacy, security and data sovereignty concerns pop up. These issues are complex, and the same rules don't apply to everyone. By now, even systems administrators uninterested in the cloud know that there exists some nebulous concerns around data sovereignty and privacy, but what are they?
Concerns about privacy, security and data sovereignty rules are especially top of mind for organizations in Europe, Canada and other countries that have adopted meaningful privacy laws. Even for organizations in more lax jurisdictions, such as the United States, however, regulatory compliance efforts can seem overwhelming.
Many regulations have required special care and consideration from organizations and IT practitioners. And a number of these regulations have been widely ignored because enforcement has been lax, the consequences amounting to nothing more than irrelevant fines.
However, the next generation of regulations, which are soon coming into effect, have teeth. Unlike previous data regulatory regimes, the privacy, security and data sovereignty regulations coming into play in many jurisdictions around the world are increasingly willing to pierce the corporate veil and send individuals to jail for noncompliance.
From a practical standpoint, this means that security teams are suddenly relevant. Systems administrators and cloud architects have to put serious thought into privacy, security and data sovereignty, lest their designs get shredded by the security team. So what do IT practitioners need to keep in mind?
Top of mind during any such discussion is always the EU's General Data Protection Regulation (GDPR). Passed on April 27, 2017, the implementation of the GDPR begins May 25, 2018. Implementation marks the start of enforcement activities for noncompliance, and fines top out at 20 million euros, or 4 percent of global turnover, whichever is higher.
The reach of the GDPR is global. It applies to every individual and organization that processes data about EU citizens, even if those individuals or organizations are not located in the EU. Any organization, anywhere in the world, that collects data on EU citizens is required to comply with the GDPR. If it does not, it faces the same consequences as an organization located in the EU.
In practice, there's little the EU can do directly to small businesses located in, for example, the United States that has no European assets. But the EU can block that organization from selling into the EU, prevent EU businesses from doing business with that organization and potentially go after any EU assets of that organization's executives, possibly even preventing them from travelling to the EU. Governments tend to get creative, given a reason to do so.
The GDPR gives EU citizens new rights, such as the right to be forgotten. This means they have the right to see whatever data an organization holds on them, have that data changed to be accurate or to have that data deleted.
These changes and deletions apply not only to production data, but to all instances of data for which an organization is responsible. That includes all backups that an organization has made, as well as any and all data that the organization has exchanged with contractors.
Larger organizations with more formal commercial ties to the EU will face more direct consequences. EU assets can be seized for noncompliance, and organization executives can be fined or jailed. If you want to do business in the EU, or sell to EU citizens, compliance with the GDPR is highly recommended.
The GDPR is among the most stringent of the new generation of data regulatory regimes. While the crossover isn't perfect, if you've managed to fully comply with both the spirit and the letter of the GDPR, chances are you'll be covered for almost everything else.
The first thing to understand about the GDPR is that it isn't a regulation aimed specifically at how organizations implement IT. The purpose of the GDPR is giving EU citizens control over their personal data. EU citizens are expected to have complete control over their data regardless of which organizations are handling that data, how it's collected or for what purpose.
The GDPR is founded on two basic concepts. The first is privacy by design, and the second is security by design. In practice, this calls for a vigorous -- even obsessive -- application of the principle of least privilege.
No user -- whether that user is a human being operating a computer under a specific user context, or a user used exclusively by computer programs to talk to other computer programs -- should ever be able to access more information than is absolutely required to perform its duties. A janitor shouldn't have access to student records, nor should a teacher from one school be able to look up students from another. A commerce application shouldn't be able to look up Social Security numbers, and a financials server has no need to be able to access medical records.
Gone are the days of having a handful of broadly powerful users with high-level access under which IT practitioners can run scripts, backups and other automated processes. As we move into the 2020s, all data access must be deliberate … and restricted. All of the above applies to outsourced IT, as well as on-premises IT.
Outsourced IT means not only organizations hired to manage e-mail lists or ecommerce sites. It means regional services providers, Software-as-a-Service (SaaS) solutions and anything that has been put into the major public cloud providers, as well. There's no hiding from the GDPR. If your organization collects or causes to be collected any data on EU citizens, it is responsible for ensuring the privacy and security of that data, wherever it may be in the world, and whomever may have been hired to process it.
Organizations will also need to implement some means of updating their backups when changes or deletions are requested. They'll need to be able to inform all contractors that have been engaged to store or process data that updates or deletions will be required. If an organization handles data for another organization (say a vendor or other member of the supply chain), then that organization will need to make a mechanism available to allow any companies that contract with them. These are not trivial undertakings.
As discussions about GDPR compliance demonstrate, modern compliance regimes require a bit more than token changes to IT security. For most organizations it involves a complete rethink of data handling, both within IT systems and without.
A large part of practically solving privacy, security and data sovereignty issues involves encryption, but "involves encryption" is rather vague. Encryption can be employed in multiple places, each with their own benefits and drawbacks.
Most modern applications, databases, operating system environments (OSEs) and storage solutions can encrypt data as it is stored (data at rest). Many of these can also encrypt data when it's transmitted over the network (data in flight).
While describing the intricacies of encryption technologies could fill at least a small ebook, the most important practical concept is that of the Key Management System (KMS). The short version of a KMS is that it stores and manages encryption keys, allowing organizations to control the encryption of their data and workloads, even when they're outsourced to a services provider or public cloud. The long version of key management is rather a bit longer, and I strongly recommend reading "The Definitive Guide to Encryption Key Management Fundamentals" by Townsend Security in order to gain a more complete understanding.
Suffice it to say that encryption should be something that all organizations should be doing, whether or not their workloads live in the cloud. And unless your organization is a U.S. corporation that only sells to customers in the United States, isn't in a regulated industry, and doesn't process regulated data, then encrypting everything that your organization places in the cloud is an absolute must.
The Narrowing Gap
Had this article been written two years ago it would have looked a lot different. About 30 months ago my colleagues and I began a journey that lasted almost a year wherein we catalogued every major regulatory regime that affects IT in the western world. We examined them in-depth and we tried to figure out what IT teams would have to do in order to be compliant.
And then along came the GDPR. This was followed by new privacy regulation in Australia, Canada and even in several U.S. states. Several things have become clear in the past two years.
The first is that over the next five to 10 years, non-U.S. regulators are going to find every single loophole that organizations can use to not secure their data and close it. There's a concerted international effort to this effect. The second is that while the U.S. government isn't ready to act on this at a federal level, individual states are more than willing to force the issue.
The net result is that there's no wiggle room left on this topic. Organizations must begin encrypting everything. They must begin implementing the principle of least privilege, even if that means buying new software or changing SaaS solutions to something that implements privacy by design. Organizations must stop collecting all the data they can on their customers and then selling that off or using it for unsolicited marketing purposes.
What's also become clear is that organizations that haven't already started down this path are potentially in deep, deep trouble.
This level of attention to privacy, security and data sovereignty isn't easy. At a minimum it will require having datacenter and cloud implementation designs vetted by professionals. Realistically it should involve annual audits and working closely with services providers to ensure that all data -- both production and backup -- is appropriately secured.
Trevor Pott is a full-time nerd from Edmonton, Alberta, Canada. He splits his time between systems administration, technology writing, and consulting. As a consultant he helps Silicon Valley startups better understand systems administrators and how to sell to them.