Voice of the DBA

Author: way0utwest

  • Treat All Sensitive Data as Important

    We know that not all the data in our company is important. We have databases that contain orders or inventory or schedules, often much of which isn’t easily or directly related to an individual. At least, it’s not if you have a normalized database. If you use SQL Server to emulate Excel spreadsheets, it’s possible that most of the rows of information in your system contain sensitive data.

    In some systems, there is definitely some data that is sensitive and needs more care than other data. We know this, and with legislation like the GDPR, we must protect this data. We also need to ensure we know where this data is, and having a good data catalog is important. This is something that few of us have, though I expect this to be a more regular part of our job as data professionals. SQL Server is building data classification into the product, which I am happy to see.

    When data is sensitive, we need to treat it carefully, even if we don’t like the content of the data. Recently there was a data breach from B&Q, a home improvement retailer in the UK, where 70,000 names were lost. These weren’t customers, but rather people that had been caught stealing from the stores. Perhaps this was an honest mistake, on a data store with poor security. Perhaps no one thought this data needed security because these were criminals, or suspected criminals. Even if these were individuals that might be prosecuted by the company, their data still deserves the same protection as any other person’s data.

    I don’t know what the fallout will be from this breach, and certainly most people would have little sympathy for criminals, but who knows just how accurate the data might be. I certainly think this is a situation where there is a high likelihood of legal action against the company if the proper GDPR notifications were not followed. Wouldn’t that insult to injury? People caught or suspected of theft suing you because you leaked their personal information. I could certainly see management getting extra upset and terminating someone that forgot to secure these systems.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 3.4MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Default Security

    If anyone sets up a new desktop machine, a new SQL Server instance, a new Elastisearch instance, or any other platform, you need to ensure there is default security. That was a problem recently with a financial company that had a default Elasticsearch instance up with no authentication required. When I look at the install directions, security isn’t mentioned. There is a secure settings page, but that’s not authentication. It’s not until you look way down the setup instruction list that you find configuring security. Even then this mentions “you can password-protect your data”, which isn’t a good option to have.

    This should be built in with a “you must” protect your data. SQL Server used to allow a blank password, but there was plenty of outcry about this and setup changed to either require Windows Auth only, which inherently has some secure settings for accounts, or mixed security where a password must be entered for the only default account. That’s how many software programs work these days, and really how all should work.

    I’m still amazed by people that don’t put a password (code, fingerprint, etc.) on a mobile phone. I’m surprised that we have any data store platform that doesn’t require some security. As much as I find Google Drive sometimes a pain, I am glad that I can’t put files in there and open them to the general public. At least, I haven’t figured out how to do this. I constantly need to add specific people to access files.

    All data files/software/stores/platforms/etc. need to be secured. Containers, buckets, any file shares should be limited in some way. Any platform ought to require user accounts and not allow access to all data by default. Really, privileged accounts ought to separate configuration  and security from data access. I’d like to see “sa” allowed to work the instance and create databases and move files, but not allowed to access data.

    We need better default security, and more importantly, we need to believe that we need better default security. That’s for all data, including backups, search services, and anything else that can access a database. Leaving data open to anyone that might stumble upon the URL is a mistake that has no excuse these days.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.5MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • SQL in the City 2019 in London

    We’ve started setting up our SQL in the City Summits for 2019 and the first one is London on April 30. I’m going to start making my plans now and hope to see some of you there.

    We’re still finalizing agendas and getting some speakers lined up, but if you’re anywhere near London, take a day and come see us talk about DevOps, compliance, and Redgate.

  • How Perfect Should Our Software Be?

    I’ve a fan of Basecamp (formerly 37Signals). I think that Jason and David run their company, business, design, and software in a fascinating way. If I didn’t work for an amazing company (Redgate Software), I’d might see if they want a DBA/evangelist.

    Over the years I’ve read a number of interesting posts from them, including their ReWork book, and I’ve learned a lot. They make me think, give me ideas, and a perspective I might otherwise miss about work, life, or something else. They tend to focus on software and since I’m a part of that business, I like reading those posts. I ran across a good one from Jonas Downey called “The right amount of perfect“.

    The piece talks about the tendency to want our work to be perfect. We want our new software, class, table, method, stored procedure to be right. We craft systems to work well and meet requirements. Sometimes, perhaps often, we over engineer things. At least, the very talented people I know tend to over engineer. The less talented more often than not just barely get things working, meeting only one particular case, and leave behind a load of technical debt, often in a steaming pile.

    Finding a balance for how good our software should be can be hard. I do think that often it doesn’t take longer to write good code than bad code, but it does take time to learn to write better code and practice using patterns that perform well, both in terms of solving a problem and not using too many resources. Early on, when experimenting, it does seem more important to try things, even if they don’t work well. Later, when we are more confident that this particular feature/view/method/etc. is highly likely to be used, we ought to ensure we refactor code or adjust our design to become more “perfect”. We still have to balance how robust we make code given the fact that we always have more work than time, but it should be better than a the first, quick cut at getting a working feature.

    The worry I have had, and likely many of you, is that our quick design, our hasty prototype, will be used in production without any time given to rebuild the underlying code properly. That is certainly a concern, and I don’t have a good solution if your management insists on releasing poor code and living with poor performance. The one piece of advice I can give is to learn patterns that work well for queries, for database design, for error handling, or any other task. That won’t allow you to build an extremely robust system quickly, but it can help you minimize the amount of poor coding you do when under time constraints. You’ll write more good code the first time.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.0MB) podcast or subscribe to the feed at iTunes and Libsyn.