There’s something for having job security and many of the solutions that I see offered for RDBMS challenges offer just that. With compliance with EU’s GDPR, (General Data Protection Regulations) just around the corner, (mark you calendar, May 25, 2018) you’d think we’d all be scrambling for a simpler solution to discovering and addressing all that GDPR data.
Quick refresher for those of you going, “What is GDPR?”
Data security is a known focus of GDPR when you talk to folks, but it’s much more than just security. It’s about extended rights of the individual in the EU. There’s four areas as a DBA, you need to really concern yourself with:
- The right to be forgotten, (deletion of data from systems.)
- The right to have incorrect data fixed in a reasonable amount of time, (update of data)
- To know what data is out there in your systems and why you need it, (audit your data and justify it.)
- Proper policies in place to ensure that you are in compliance and can report on GDPR.
What is included in GDPR data?
- Personal information like name, address, phone number
- The expected Social Security Number, medical and financial information
- Lesser known information like IP Addresses, cookies and other internet identifiers that can connect a person or computer to an individual or account.
It doesn’t matter if I’m looking at Microsoft or Oracle’s, (DBMS_METADATA, but there are others) reference pages for how to discover GDPR data, the first line of attack is to use home grown or sample scripts to identify the location of the data.
So this is what we’re being told is our options from most of the database vendors and we need to recognize that this will undoubtedly lead to human error.
Metadata Scripts for Discovery
Yes, you will need to query all the objects for data types that *may* contain all the GDPR data that you’re searching for. Some of the questions you’ll need to answer are:
- What if someone has named a column with a name that leaves it unidentifiable?
- What if the developer or DBA used the wrong datatype?
- What is the personal information is stored in a string, text or LOB?
- With new features like JSON, CLR and others, how will this effect what I’m querying at the database layer?
And yes, all the cool kids are doing it. We like to rely on our technical brilliance to solve a problem, but this is a problem that has a huge backlash if we’re wrong. A backlash that includes fines up to 20 million Euros or up to 4% annual revenue if found guilty. We haven’t even touched on the resulting loss of income after a company has been found out of compliance. How many customers is this kind of mistake worth?
Build Policies and Procedures
If you are a DBA that’s left with the responsibility of building a home grown solution, how are you going to ensure that:
- A repeatable process will be in place vs. individual scripts to fulfill GDPR requests.
- An audit exists that will cover all environment areas of your unique databases?
- That personnel outside of just the DBA can execute the procedure simply and without fail to continue to be in compliance if the DBA isn’t available?
- Reporting will be executed automatically and reviewed regularly?
- That an audit that spans all tiers, (database, application, file system, etc.) to ensure compliance across the environment. Just because the database is compliant doesn’t mean the job is done or that the company isn’t subject to fines.
There are considerable offerings of more automated solutions for GDPR. Use discovery tools that will remove a high percentage of the work from the DBAs shoulders. Use audit automation like STIG compliance reporting, security tools sets, etc. to again, remove anything that can be taken out of a manual solution so that the resources you do have are only having to allocate to the necessary tasks.
Last, but not least, MASK your non-production systems whenever possible, because encryption is not the “key” to everything. If you can remove the PII data from these systems, you’ll have a lot less ground you’ll have to secure to begin with.
Also published on Medium.