GDPR or General Data Protection Regulation is a European law relating to the security and data privacy of an individuals information relating to his identity. The law will come in effect on 25 May 2018.
Many countries around the world has their own version of it. In South Africa for example an equivalent of GDPR is the POPI act.
At a very high level it basically states that a user has the following rights:
- Right of access to his personal data.
- Right to erasure of personal data.
- Right to data protection.
- Right to transfer or port personal data from one system to another.
For software systems the actual changes relate to the encrypting of an Identities data when the data is in transit or at rest. Other challenges might be around the erasing of data as systems in the pas kept user information even if the individual was no longer active within the context of the software.
What is considered private data?
This is any information that can be used to uniquely identify a user. Examples of this is first name, surname, employee number, Id number, passport number… This information is information that belongs to the individual and was not generated.
Considerations for GDPR in system design
It is usually very difficult to implement data privacy into an established system. Because the data privacy rules differs from country to country it is a volatility. It is best to design a system with data privacy in mind right from the start especially in today’s age where all data is online. The fallout for having a system designed without it at its core is that changes will ripple through the entire system resulting in patch work at all integration areas which will increase maintenance and complexity.
Below is a cutaway view of an web application. It shows the BASIC flow that a clients data may travel to be saved in some sort of persistence. In this diagram data is either stored in a SQL server or a File System.
Note that this is only a example. Often there are more than a browser communicating to a website like a mobile application or even a desktop application. All the communications from these application will need to be secured.
When planning this one has to look at the integration points of a system and think about the data flowing down the pipe. It is important that the data be encrypted at rest and when in transit.
Some basic things to do.
- The website must use a SSL certificate encrypt the data between browser and the server. This means that the HTTPS protocol must be used for transport.
- Disable normal HTTP or add a redirect rule to always redirect traffic to HTTPS.
- The traffic between servers must employ TLS even when not publicly accessible
- On the server any temp files created using the users information must be encrypted.
- All data stored in sql server relating to his identity should be encrypted.
How to encrypt stored data that is at rest
- SQL server 2016+ has the build in ability to encrypt and decrypt user data automatically previously this ability was limited to SQL server Enterprise versions only. The following article discusses the always encrypt feature and has an example
- Encrypting files on the windows file system can be achieved by using the build in windows feature (EFS). The following article discusses the feature. Something to note is that this encryption is achieved using a certificate that is tied to the user account on the specific machine. Problems may occur when upgrading the Os. If a backup of the file is kept it is important to keep a state backup of the server as well otherwise it will not be possible to restore or decrypt the file
How to encrypt data in transit
- The following article shows how to enable TLS for SQL Server. TLS stands for transport layer security.
- When communicating with an Active Directory server it will also be important to use LDAPS to secure the traffic between the web server and the AD server.
- The following article shows how to enable HTTPS on a web application and how to enforce the HTTPS redirect through HSTS.
- Cookies may stored sensitive user information, this article shows how to secure the cookies.
Other things to consider
- When a user’s account is deleted in the system it will be required to delete the user account or to nullify the user details within the record that relate to the individual private data.
- Rapports that show an private data must be anonymized or protected so that only the rightful individual or system access to the information. An easy way to achieve this is by archiving rapports in files in password protected archives.