Voice of the DBA

Category: Editorial

  • 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.

  • 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.

  • You Need Offline Backups

    If you hadn’t heard about it, VFEMail may be dead. At least, that’s what the founder was thinking in this article. A malicious hacking incident took place last week, and though they’re back up and running, who knows if customers will stick by them, or maybe sue them out of existence. I wouldn’t be surprised as a large number of their infrastructure servers were wiped out by reformatting servers. These included mail servers, backup servers, and SQL Servers.

    That’s quite an attack, and whether this was directed at the company or some individuals, a large number of people might have lost their mailboxes and previously stored mail that was in IMAP storage. This is the type of issue that is most likely an annoyance for individuals, but it would be potentially catastrophic for businesses. Imagine your small business hosted with them and all your mailboxes were lost with customer communications and who knows what else. Perhaps you could recover data or keep the business going, but it might be an issue.

    Could this happen with a cloud provider like Azure O365, Google Apps or AWS? Possibly, and while I’m sure they have backups, I’m not sure how reliable those might be for the average individual or small business. This makes me worry slightly as I depend on GMail and wouldn’t even try to backup to few 100GBs of mail I have. I’m not even sure how to do it, though I don’t really keep anything in there that’s really important. In any case, I’d suspect that connecting and somehow wiping out Gmail servers, along with backups, would be very difficult.

    This does make me think about a few customers I know that use online storage for backups. They assume that they will always have either a primary server or the online backup server/share/bucket/container and can download data. The problem is that online systems that connect to the primary can be accessed. If an attacker were to access one, they potentially could access the second.

    The world seems to be moving towards more online storage, or in the case of cloud vendors, a reliance on snapshots. That might be good enough for cloud vendors, but it’s certainly not for any on-premise system. It’s likely that an attacker, possibly with insider help, would wipe out backups first, then primary systems. I’d always want some sort of disconnected offline backup of data, especially database servers. I have seen Murphy’s Law strike two systems at once, so an air gap between copies of data just feels prudent.

    Steve Jones

  • A Supercomputer in My Pocket

    I work with data on a regular basis, and I really depend on my cell phone to help me with both work and life. I regularly make notes and get ideas for articles and editorials from things that happen when I’m on the go. Without a smartphone, I’d be juggling a notebook and pen, perhaps pulling over and making notes that I’d transcribe later. Since I’m in different cars and vehicles with different bags, I’m not sure how well I’d be able to keep track of notes on paper.

    In the last decade, as I’ve purchased and upgraded mobile devices, it’s been amazing to me that I can use many services to help me. I can log into something like Instapaper to save an interesting article I might write about later, or capture a few thoughts in Evernote. Or even send myself an email with an idea for a Question of the Day. I’ve done all of those things while in various points when inspiration has struck.

    In the last few years, I’ve started to use some audio notes for tracking when I’m driving. I might hear something on the radio, or from a podcast, and need to make a note. The power of dictation apps, which have improved tremendously since the early Dragon Speech Recognition days on 486 computers. While I still don’t completely trust audio recognition, what I’ve learned to appreciate is the ability to just record sound with an audio app that I can play back later. There are audio recording apps, though I often just use Evernote.

    I use a lot of data transfer and storage on my mobile device. So much so that when I switched a couple years ago to the Google Fi, I was disappointed with only having 32GB of storage. It was amazing for a kid that grew up with 300kb floppy disks to think that 32GB wasn’t enough, but it wasn’t. I was constantly juggling space and deleting things. I recently upgraded to a phone with 192GB, and I’m hoping that will satisfy my need for pictures, video, and notes.

    It’s amazing to see just how far computing has expanded, giving us incredible capabilities on the go that were science fiction a quarter century ago. Many appreciate the ability to review a document or spreadsheet, or even view a Power BI Report from any device. While I don’t often have the need, it is nice to know that I can catch SQL Monitor alerts and view data on my phone, or even restart a VM from a cloud shell from my car if I have the need.

    Steve Jones

    The Voice of the DBA Podcast

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