Wherever you are in the world, data privacy is now a major regulatory and consumer concern. The introduction of the GDPR in 2018 ushered in tough new rules for anyone dealing with the personal data of European Union citizens, while a string of cases involving either hacking or the improper use of data has led to consumers everywhere becoming more aware of how their information is used and protected.
This can be seen by the shift in the global regulatory framework. Since the GDPR became law, 16 countries have made plans to introduce similar legislation. Along with the current 28 member states of the EU, this means that over 62% of the world's population will be protected by tougher data privacy laws moving forward. In the United States, the California Consumer Privacy Act will also come into force on January 1, 2020, and 12 other states are moving down the regulatory path.
This affects businesses in general, but DevOps in particular, given that developers rely on having access to copies of the production database to test proposed changes against and avoid problems when the changes are deployed. Businesses now, however, have to move from seeing themselves as data owners to being data guardians, responsible for protecting information and only using it for specific, defined and agreed purposes.
The positive news is that the majority of countries and states are using the GDPR as a blueprint for their own legislation. That means that businesses can adopt a broadly common approach across the globe, tweaked as necessary for individual countries. Ensuring global legislative compliance in such a way starts by following these ten steps:
1. Identify where your data is
Create a record of every database, everywhere across your business, and who has access to it. This will provide a real understanding of where the data flowing through your business is stored and processed, and give a true picture of the precise location of data, how it is being used, and by who.
2. Identify what your data is
We live in a data-rich world and organizations often find they've gathered a surprising amount of data about their customers. Some will be standard personal data like names and addresses and telephone numbers. Other data could be more sensitive like a person's racial or ethnic origin.
All of this data needs to be categorized with a taxonomy that can be used to differentiate between personal and sensitive data. Columns can then be tagged to identify what kind of data they contain, and therefore which need to be protected.
3. Identify where the risk lies
Discovering where your data is, and what it covers, provides a clear picture of any risks that you need to address. As mentioned earlier, copies of the production database may be in use in DevOps development and testing, or backups may not be encrypted and could be in multiple locations with no access controls.
4. Reduce the attack surface area
When the topic of data breaches comes up, people normally look at external hackers. The latest data from the Identity Theft Resource Center, however, shows that data breaches as a result of hacking are falling, while those due to internal unauthorized access have risen from 11% to 30% over the last 12 months.
Businesses therefore need to move to a least access methodology where people are only allowed access to the data they need to do their jobs. Additionally, data should be distributed so that sensitive information is in one place, less sensitive information is another, and only the necessary data gets transmitted across.
5. Mask data outside production
Redgate's 2019 State of Database DevOps Survey revealed that 65% of organizations use a copy of the production database in order to provide realistic data during development and testing. Yet production databases invariably contain personal data of the kind that needs to be protected and, therefore, restricted.
Data masking — taking a copy of the production database and replacing the data with similar but fictious data — is the best way of achieving this balance. This means copies of the production database can be provided to DevOps teams that are truly representative of the original, accelerating development.
6. Standardize team-based development
DevOps has brought down barriers between application and database development, and full-stack developers now work on code for the database as well as applications. This means many people with different levels of experience and styles are working together, which can cause issues. Look to standardize development to avoid problems by, for example, using tools to automatically change code to the team's standard style to ensure consistency.
7. Version control database code
Introducing the same version control tools to the database as used within application development ensures that everyone has access to the latest version of database code and that one source of truth is maintained, with a full audit trail for regulatory compliance.
8. Automate where possible
With version control in place, organizations can look to automate parts of the development process further down the pipeline to make it more reliable. This also supports greater data privacy as automation reduces manual errors, demonstrates a clear process and provides an audit trail of any changes.
9. Backup every change
New data privacy and protection requirements add extra concerns to backups. For example, given that data should be held for no longer than is necessary, it will need to be removed from backups as well as the original database itself. Backups will also need to be encrypted and managed centrally in a documented, compliant manner.
10. Monitor for compliance
Stricter GDPR-style data privacy regulations move monitoring up to the next level, covering areas such as monitoring access and reporting breaches as soon as they occur. This needs to include a full audit trail — particularly if a breach does happen.
Balancing the need for protection with seamless DevOps processes is not only possible, but is vital and following these ten steps will help ensure compliance and competitiveness across the globe.