GDPR

General Data Protection Regulation

GDPR, as it applies to all companies processing the personal data of data subjects residing in the Union, regardless of the company’s location.

https://www.i-scoop.eu/gdpr-encryption/

https://techblog.bozho.net/gdpr-practical-guide-developers/

method that takes a userId and deletes all personal data about that user
cloud service provider, you should call an API of theirs that allows for the deletion of personal data. If you are such a provider, obviously, your “forget me” endpoint should be exposed. Calling the 3rd party APIs to remove data is not the full story, though. You also have to make sure the information does not appear in search results.
where there’s a list of users, there should be a button “restrict processing”. (The user settings page may also have that button with a dropdown to select from the Article 18(1) options).

1. Create and Enforce Roles and Permissions
2. Mask Sensitive Data
3. Produce an Audit Trail of Database Activity
4. Create Alerts That Notify You of Breach Attempts
5. Prevent Configuration Drift and Data Loss

AWS GDPR

AWS Key Management Service makes it easy to manage encryption keys used to encrypt data stored by your applications regardless of where you store it. KMS provides an SDK for programmatic integration of encryption and key management into your applications.

https://aws.amazon.com/compliance/gdpr-center/?nc1=h_ls

AWS compliance, data protection, and security experts have been working with customers around the world to answer their questions and help them prepare for running workloads in the AWS Cloud after the GDPR becomes enforceable. These teams have also been reviewing everything that AWS already does to ensure it complies with the requirements of the new GDPR. We can confirm that all AWS Services are GDPR ready.

https://aws.amazon.com/blogs/security/all-aws-services-gdpr-ready/

Data Subject Rights

Breach Notification

Right to Access

right for data subjects to obtain from the data controller confirmation as to whether or not personal data concerning them is being processed, where and for what purpose. the controller shall provide a copy of the personal data, free of charge, in an electronic format.

Right to be Forgotten

Also known as Data Erasure, the right to be forgotten entitles the data subject to have the data controller erase his/her personal data, cease further dissemination of the data, and potentially have third parties halt processing of the data

Data Portability

GDPR introduces data portability - the right for a data subject to receive the personal data concerning them, which they have previously provided in a 'commonly use and machine readable format' and have the right to transmit that data to another controller.

Privacy by Design

Privacy by design as a concept has existed for years now, but it is only just becoming part of a legal requirement with the GDPR. At its core, privacy by design calls for the inclusion of data protection from the onset of the designing of systems, rather than an addition.

Notes

https://www.pandasecurity.com/mediacenter/security/whois-protocol-gdpr/
WHOIS is a protocol that enables you to find the names and contact details of the owners of a domain 
Yet this system will become illegal under the GDPR, as it does not ask for the express consent of these people before sharing their personally identifiable data.

A head-on collision between GDPR and WHOIS
The GDPR prohibits companies from publishing information that identifies individuals, which means that the agreements between domain registrars and ICANN regarding WHOIS will be illegal.
This means that the current public WHOIS system is incompatible with the data privacy principles of the GDPR.

Nevertheless, there is a risk that an increasing amount of personal data will be deleted from the public WHOIS database, as it is easier for companies simply to eliminate sensitive data than to invest time in properly implementing the measures required by the GDPR.

https://www.gdpreu.org/the-regulation/key-concepts/personal-data/
For example, you may be an identified person to data controllers like your school, your employer, or your landlord if your identity has been established via your driver’s license, work authorization, criminal background check, credit score pull, etc. Any information these data controllers have on you, such as your date of birth, address, phone number, salary, and rent would therefore all constitute protected personal data under the GDPR.

If John pays with a credit card, his card info makes him directly identifiable to the merchant, which means data on his coffee purchasing history (e.g., store location, date & time, amount paid, coffee preference) is personal data, thus entitling him to certain rights and protections. If John pays with cash, he may still be indirectly identifiable if he redeems a targeted coupon that was emailed to his inbox at coffeeaddict@example.com, which can be traced back to his name through John’s blog on different coffee blends.

Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags.

http://techgenix.com/personal-information-under-gdpr/
To comply with GDPR, organizations must follow certain steps to ensure that the personal information that they process, collect, and store is properly protected.

All personal information must be securely processed and managed.
Remember…collect and process only what you need for business function (and have acquired explicit permission for). If you don’t need it, don’t collect it!

GDPR also references “sensitive personal data,” which requires extra special care that incorporates enhanced requirements for protection and processing. This is usually attributed to health-related data, among others.

Can personal data become non-personal data if it is pseudonymized or encrypted?

Online identifiers and location data are all personal and must be protected as such. 

So, the answer to the question “can personal data that is encrypted become non-personal data?” is — no, it can’t. Encryption does not convert personal data to non-personal data.

However, it does remove the ability for the data to identify a person. As the data can longer be used to identify a person, the organization that used the technical measure to pseudonymize the data is offered some regulation leniency, particularly with regards to data breach notification requirements.

Through employing technologies that encrypt the data or render it pseudonymized, organizations are able to manage compliance responsibilities and better manage their risk.


Linked personal data examples (directly linked to a person)     
Full name       
Date of birth   
Residential Address     
Telephone number        
Email Address   
Passport number 
Identification number   
Drivers Licence number  
Social security number          
Banking/card numbers            

Linkable personal types (combine to identify a person)  
First name only 
Last name only  
A portion of the address (country, street, postcode etc.)       
Age Category not specific (20-30 years or 40-60 years etc.)     
Place of work   
Position at work        
IP address      
Device ID       

Sensitive (special personal data types)
Biometric data
Racial data
Health data
Ethnic origin
Political opinions
Religious or philosophical belief
Trade union details
Genetic data
Sexual preference

If unsure, perhaps it’s best to just encrypt it is all!

http://techgenix.com/6-gdpr-privacy-principles/
By informing the data subject of what, how (in an easy to understand and accessible means), and why their data will be processed ensures that you are transparent with regards to the processing of their data.

Personal data can only be collected for specified, explicit, and legitimate purposes.
Only collect the personal data that is necessary for the purpose of the business function.
Personal data must be kept accurate and current.

Do not retain the data if you no longer require it for the purposes defined and agreed for processing. Securely remove the data when it is no longer necessary. Do not store personal data that you no longer use! Review, review, review!

Integrity, confidentiality, and availability are fundamental to security! The confidentiality and integrity of the personal data must always be maintained. Access must also be controlled to achieve this.

How can the data be seen ?
Who can see the data ? 

you must be able to demonstrate this compliance


https://www.itgovernance.eu/blog/en/how-to-maintain-gdpr-compliant-databases
A significant part of the process will involve managing your databases, as this is probably where you keep most of your personal data.
designing your systems with privacy as your primary concern
first thing you need to do is map your data with a data flow audit.

Locate your data
A data map should identify the following key elements:

Data items (e.g. names, email addresses, records)
Formats (e.g. hard copy forms, online data entry, database)
Transfer methods (e.g. post, telephone, internal/external)
Locations (e.g. offices, Cloud, third parties)

Limit who has access to your data
you should set up access controls to make sure personal information can only be viewed by relevant employees.
manage who has access to what data, making sure no one can view, modify or delete data that isn’t relevant to their job role.

You should also protect your personal data by pseudonymising and/or encrypting it.
 
Encryption also obscures information by replacing identifiers with something else. But whereas pseudonymisation allows anyone with access to the data to view part of the data set, encryption allows only approved users to access the full data set. 
 
https://blog.thalesesecurity.com/2018/03/01/securing-containers-for-gdpr-compliance/
GDPR Data Security Requirements
The GDPR calls for a layered or “Defense in Depth” security approach to protect sensitive data from compromise. Layers should include not only perimeter security, but also, among others as prescribed by GDPR Article 32:

Limiting access to data
Encrypting or pseudonymization of sensitive data
Monitoring and reporting user access patterns


https://www.manageengine.com/key-manager/gdpr-compliance.html
Digital keys and certificates are at the heart of PKI. These are digital identities which protect access to critical systems and ensure strong encryption of personal data.

digital signature

https://www.ctrl.blog/entry/gdpr-web-server-logs
Personal data in server logs
The default configuration of popular web servers including Apache Web Server and NGINX collect and store at least two of the following three types of logs:

Access logs
Error logs (including processing-language logs like PHP)
Security audit logs (e.g. ModSecurity)

If you don’t have a legitimate need to store these logs you should disable logging in your web server

Legal basis for collecting and storing logs without consent
You can’t collect and store any personal data without having obtained, and being able to document that you obtained, consent from the persons you’re collecting data from.
 
You can, however, collect and store personal data as part of web servers logs for the purposes of detecting and preventing fraud and unauthorized access and maintaining the security of your systems.

Data should be deleted (including from backups) when there is no longer a need to retain it.

Unless you encrypt your logs, an unauthorized third-party who gained access to your servers could extract a lot of data about your users from your logs. Depending on how much private information is stored in your log files and the potential sensitive nature of your business, you shouldn’t store log files for more than a few hours or days unless you take measures to protect them.

Managing PGP keys in GnuPG is beyond the scope of this article. However, in short you would create a key-pair on a secure machine, and then import the public key into the GnuPG key chain on your servers while storing the private key on a secure medium with limited access for authorized employees only (e.g. printed on paper or kept on a removable storage media).

The server can then use the public key to encrypt its log files with public key cryptography; resulting in the server being able to encrypt the data without being able to decrypt it without the private. The log files could even be transferred to a centralized log-storage server for cold storage.

SQL server Dynamic data masking

https://docs.microsoft.com/en-us/sql/relational-databases/security/dynamic-data-masking?view=sql-server-2017

Dynamic data masking limits (DDM) sensitive data exposure by masking it to non-privileged users. It can be used to greatly simplify the design and coding of security in your application. Dynamic Data Masking is designed to simplify application development by limiting data exposure in a set of pre-defined queries used by the application As an example, consider a database principal that has sufficient privileges to run ad-hoc queries on the database, and tries to 'guess' the underlying data and ultimately infer the actual values

SQL Server Encryption

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/sql-server-encryption?view=sql-server-2017

Encryption is the process of obfuscating data by the use of a key or password. This can make the data useless without the corresponding decryption key or password. Encryption does not solve access control problems. However, it enhances security by limiting data loss even if access controls are bypassed.

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/encrypt-a-column-of-data?view=sql-server-2017 Encrypt a Column of Data

CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<some strong password>'; 
EncrypyByKey
DecryptByKey

MariaDB

https://mariadb.com/kb/en/library/data-at-rest-encryption/

MariaDB allows the user to configure flexibly what to encrypt. In XtraDB or InnoDB, one can choose to encrypt:
everything — all tablespaces (with all tables)
individual tables
everything, excluding individual tables
Additionally, one can choose to encrypt XtraDB/InnoDB log files (recommended).

Encrypting table data requires that you implement an encryption plugin, such as the File Key Management plugin. Once you have this plugin set up and configured, you can enable encryption on your InnoDB, XtraDB and Aria tables.

https://mariadb.com/kb/en/library/aes_encrypt/

Encryption at Rest

https://docs.mongodb.com/manual/core/security-encryption-at-rest/
Secure management of the encryption keys is critical.
Integration with a third party key management appliance via the Key Management Interoperability Protocol (KMIP). Recommended

There are two broad classes of approaches to encrypting data at rest with MongoDB: Application Level Encryption and Storage Encryption.

KMIP

https://en.wikipedia.org/wiki/Key_Management_Interoperability_Protocol_(KMIP)
https://en.wikipedia.org/wiki/Key_management#Public-key_infrastructure_(PKI)
Closed source Amazon Web Service (AWS) Key Management Service (KMS) [16]
Microsoft Azure Key Vault[30]
Oracle Key Manager[31]

CKMS

A key management system (KMS), also known as a cryptographic key management system (CKMS), is an integrated approach for generating, distributing and managing cryptographic keys for devices and applications.