Voice of the DBA

Tag: data privacy

  • Data Privacy Grows in California

    A few years ago the CCPA passed in California. This was the first large scale effort in the US to provide some legislative action on data privacy in the wake of the GDPR taking effect in the EU. While there have been some actions under the CCPA, it didn’t seem to have as much of an affect on how data is managed as the GDPR did.

    However, in November 2020, the citizens of California passed Proposition 24, which was seen as a CCPA 2.0. This expands data privacy laws and allows consumers to direct businesses not to share their information.

    To me, this is a good trend in that consumers want more say in how businesses use their data. Unlike a law passed by a legislature, consumers would have to amend this in another vote. This places a greater burden on businesses, both to handle data more carefully, but also to ensure more cybersecurity. I think this just requires business to stop giving lip services to these items and actually back up what they claim they want to do.

    I also like that consumers have new rights, which is important. I’ve been dealing with the GDPR at Redgate Software for a few years and this hasn’t been overly burdensome to many businesses. It is work, but often many companies have played fast and loose with consumer data in the past, and now they need to respect their customers’ rights more.

    I wish this type of regulation were in place across the entire US, and I hope it becomes a focus in the future. While this can raise some costs, it also requires good practices for data handling and security, something that most of us want from every company. If you need to use data, protect it.

    Steve Jones

  • The Best Way to Protect Sensitive Data

    I was listening to someone talk about data privacy recently, and the ways that you can protect the sensitive information in your databases. They had a great quote about something you might consider. They said, “The best way to protect data is not hang onto the raw data at all.”

    If we don’t have sensitive data, then a loss of data can’t occur. Hacks won’t cause issues, we can’t accidentally send out data or leave it lying around. There’s a good case to be made that keeping less sensitive data around is a good idea.

    For some applications, we can’t avoid keeping sensitive data. Medical databases keep private health information. E-commerce systems likely need financial information. Many of us will definitely have to deal with some sensitive data, and protect it, but we can minimize our struggles.

    We often don’t have a good reason for keeping lots of data around. Lots of queries run by users end up looking at only a small portion of data. Often recent data is needed, and some aggregates for older data, but we don’t actually look at the details of old data often. We may even have older data around that we’ve forgotten about, and our users don’t even know is available.

    We certainly don’t often need sensitive data in non-production environments. Plenty of people use scripts or tooling to obfuscate, anonymize, generate, or otherwise ensure sensitive data isn’t in unprotected environments. We can archive, or even change, old data to ensure it isn’t a liability. We can even do this in production, preserving metrics, but delinking data from any individual.

    I’ve always been someone that kept more data than necessary, just in case I needed it. However, over time, I find that the costs, and the potential risks, just aren’t worth it. Moving forward, archival, anonymization, and other strategies need to be a part of any system I manage.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Prized PII

    If I asked you what specific type of information criminals would like to capture about you, what would be your response? Take a minute and think of something and then leave it in a comment after reading the rest of this.

    I know that usually more than one piece of data about me is needed, and while most of this data is probably somewhere in a database, and perhaps leaked in a breach, it’s not necessarily organized. I still think it’s good to protect information where I can. Every year my wife laughs as people wish me Happy Birthday in Facebook, on a day that’s not my birthday. I think any day is as good as any other to wish me well, and so I disclose April 1 to my friends. In fact, I often disclose a slightly incorrect birthday when sites and organizations ask me, unless I have some legal obligation to type in my real date.

    There was an article that caught my eye about the data that thieves most often want. It opens with a story about pharmacists using personal data to bill insurance for non-existent medications, which is criminal activity for sure, but there’s not much you can do about these people using your data. The piece then goes on to talk about the value of healthcare fraud and how data related to this is even more valuable than credit card numbers.

    That isn’t something I’d have expected, though, I do live in the US. With the high cost of healthcare, I shouldn’t be surprised. Fraud is big business, and there is a large volume of claims, providers, and statements that people have to review. If you’ve tried to go through your statements, they often don’t seem to be easily relate-able to the treatment you may have received. I think this creates opportunity for fraud, as it might not be something an individual can catch.

    I haven’t worked with healthcare data, but I suspect anyone that does will need extra protection on their systems, and certainly encryption along with the prevention of PII in non-production environments is important. I also think this is the type of data that you may want to be more careful about in your own life. Though how you can be more careful escapes me.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Data Sovereignty Issues

    Many people think about the cloud for cost reasons first, often because they can transfer the expense from a capital to operating budgets. Others think about the flexibility the cloud vendors offer to spin systems up and down, change configurations, and adapt to requirements quicker than many internal groups can. A few consider scalability, where we can grow or add systems to meet our needs.

    What about data sovereignty? I ran across an article recently that talked about the new SAS cloud on Azure, but located in different places for different reasons. Customers in the EU can use the German version of this. Those customers in the UK, because of Brexit, might choose the UK data center.

    It’s an interesting idea, where we might not think about just which specifications and services we use, but where they are located. That can pose challenges for architects and software developers, who may need to route customer requests to different data stores, based on their location. I’d think this is easier for database professionals, as we just duplicate stores in different places.

    This does mean that we’d need to manage backup, integrity, ETL flows, etc. in multiple locations, and we’d had the need to roll some data up across different data connections, but technology is making this easier all the time.

    The legal requirements and protections of having data in different places are still being argued and worked out. Microsoft fought a battle, and there was some resolution for how to handle cross border data issues, but I’m not sure this is settled law yet. Time will tell, but if there is any value to customers in where data is located, I suspect some of us will need to consider how we store data in different physical locations.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.