The Changing Role of the DBA in a Data Protection-first World.
At first they were gatekeepers, focused on ensuring the stability and security of mission-critical data and information. Their default position was to protect the data, rather than share it widely outside production environments in case problems ensued.
This all changed with the spread of DevOps, which moves software development from infrequent, big bang releases to a constant stream of small releases. This affects the database too because changes to front-end applications often require the database at the back end to be updated as well. If the database is excluded from DevOps, it hinders the faster pace of development that can otherwise be achieved.
As a result, many application developers are also now responsible for developing the database, and often use a copy of it to test their proposed changes against. Indeed, Redgate's 2019 State of Database DevOps Survey revealed that 65% of organisations use a copy of the production database in development and testing. So rather than being gatekeepers, DBAs have had to become enablers, provisioning those copies on request.
The rise of regulation
Alongside the rise in DevOps, there has been a growing focus on data security and privacy with the introduction of regulations like the GDPR as well as increasing consumer expectations that their personal information will be kept safe and used responsibly.
This changing data privacy landscape has made many businesses realise that data has moved from a business asset to a business risk. Rather than no data privacy legislation, or weak legislation, legislation is now being proposed and strengthened across the globe. In fact, Redgate analysis has found that over 62% of the world's population will be protected by tougher data privacy laws moving forward.
All of this means that DBAs need to embrace a new role as guardians, protecting the personal data in production databases, yet still ensuring it's available in secure, anonymous ways to enable faster development without the risk of breaches.
Ensuring this involves taking ten steps, broken down into four areas:
1. Understand your data
* Identify where your data is
* Identify what your data is
* Identify where the risk lies
Data within organisations tends to leak into lots of different places, so businesses need to create a record of every database, every instance of it, and who has access. Once they have found where the data is, the next task is to identify what it is. It might be standard personal data like names and addresses, job titles and telephone numbers, or it could be more sensitive like a person's ethnic origin or details about their health or sexual orientation. Either way, it needs to be categorized with a taxonomy that can be used to differentiate between personal and sensitive data. With such a taxonomy in place, columns can then be tagged to identify what kind of data they contain, and therefore which needs to be protected.
At this point any risks that exist will become immediately apparent. A remote sales office could have a copy of a customer database open to every employee, for example. There are also likely to be multiple copies of the production database being accessed by a variety of people from developers to business analysts.
2. Protect your data
* Reduce the attack surface area
* Mask data outside production
Once organisations understand their data, measures can be put in place to protect it. The key here is to consolidate the storage of data to as few locations as possible and give access only to individuals who have permission to view, modify or delete personal data that is relevant to their job role.
There are two areas that are particularly important reducing the attack surface area and masking data outside production. A common fallacy is that most breaches are caused by outside hackers, but the latest data from the Identity Theft Resource Center shows that issues due to hacking are falling, while those due to unauthorized access (typically by contractors, third parties and users without the appropriate permission) have risen from 11% to 30% over the last 12 months.
So organisations need to reduce the internal attack surface area, moving to a least access methodology where people are only allowed access to data that they should have, rather than all of the information and stored procedures.
Businesses also need to move on from storing all data in one system and one place. In order to reduce the attack surface area further, the data needs to be distributed so that more sensitive information is in one place, less sensitive information is another, and only the necessary data gets transmitted across.
Then there are those copies of the production database used in development and testing. They invariably contain personal data of the kind that needs to be protected, so data masking measures like pseudonymization, encryption, anonymization and aggregation should be adopted, preferably using a third party tool to ease the process.
Data masking protects sensitive data by replacing it with fictitious, but still realistic data. This protects it from insider and outsider threats, as well as enabling compliance with data privacy regulations, but developers can still be confident that they can work effectively and not miss potential issues when changes are deployed.
3. Introduce DevOps to your data
* Standardize team-based development
* Version control database code
* Automate where possible
While the growth of DevOps has broken down the walls between DBAs and developers, it has also resulted in people working on the database with different levels of knowledge of database development languages such as TSQL. This can result in confusion, particularly when different developers have worked on the same code base over time.
Overcoming this requires standardising development. Not by forcing developers to change how they work, but by using tools which can automatically change code to a team's standard style in seconds and perform static code analysis as code is written. This makes the overall code base easier to understand and also flags up errors earlier in the development pipeline.
Then there's version control, which is becoming standard in application development and involves developers checking their changes into a common repository during the development process, commonly at the end of each working day, so that one source of truth is maintained. The same approach should be applied to database code, preferably using tools which plug into and integrate with those used in application development.
Having version control in place also opens the doors to automating parts of the development process to make it more reliable. Every time a change is committed to version control, for example, a continuous integration process can be triggered to test the change and flag up any errors in the code. The errors can be fixed immediately and tested again, before the change is then passed along to a release management tool where it can be reviewed before being deployed to production.
Importantly, this aligns with data privacy requirements. It automates onerous database development tasks, reduces errors when changes are deployed, enables database updates to be delivered in a consistent, repeatable and reliable way, and provides an audit trail of those changes.
So organisations which introduce version control and automation to the database development process also, by default, do much of the work that makes them compliant with data protection regulations.
4. Watch over your data
* Back up every change
* Monitor for compliance
Backups have always been an important part of database management but new data privacy and protection requirements add extra concerns. Businesses are expected to have the capability to restore the availability and access to personal data, should any issues occur, for example. Schedules will also need to accommodate additional requirements like data being held for no longer than is necessary. Once the processing for which the data was collected is complete, it will need to be deleted from the backup along with the original database it was stored on.
As a result, businesses need to standardize backup regimes, centralize the management of backups in one place, encrypt backups and have the facility to restore and validate backups when required, without problems.
Monitoring for performance is another long-established role of DBAs, but stricter data privacy regulations move this to the next level. Businesses are now required to monitor and manage access and ensure data is available and identifiable. Should a data breach occur, businesses are obliged to report it, describing the nature of the breach, the categories and number of individuals concerned, the likely consequences, and the measures taken to address it.
All of this makes an advanced monitoring solution a necessity in most cases, in order to monitor the availability of servers and databases containing personal data, and be alerted to issues that could lead to a data breach before it happens.
With the rise in privacy regulations across the globe, the new guardian role of DBAs is becoming a vital part of business life. As more and more countries adopt tougher, GDPR-style rules, organisations and the DBAs within them need to ensure they have the infrastructure and tools in place to both protect data and enable its legitimate use in development and testing.
Matt Hilbert, Redgate Software.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||DATABASE AND NETWORK INTELLIGENCE: OPINION|
|Publication:||Database and Network Journal|
|Date:||Jun 1, 2019|
|Previous Article:||Over Half of Businesses Can't Manage Their Digital Infrastructure.|
|Next Article:||Forescout Releases Inaugural Device Cloud Research.|