There’s an odd thing happening with data. I say “odd” but really it’s expected I suppose with the privacy concerns, privacy mandates and wild-wild-west of managing information that we’re all facing right now. With so many new regulations, so many new expectations, and so much fear about data mis-use, I suppose it’s probably to be expected.
Essentially, when I talk with people about new SQL Server systems, the FIRST things out of their mouths now is quite often a discussion about security systems. This may be with encryption, Azure access controls, server management, data in flight management, at rest, etc. All of it. It’s commonplace now to need to have full discussions about the toolsets, then about applying those tools, for data controls, auditing and access management.
On top of all of that, is the need to be able to report if there is a breach, to report on what happened, and to be able to recover it. The recovery is different as well – traditional (let me get my cane out here and talk in the old DBA dude voice…) recovery was all about backup and restore. Now, it’s business recovery. What was accessed? How do we set up to investigate it? What is our process if that happens?
People are learning that while it’s about protecting data against loss, it’s just as likely that the information will be copied or duplicated and used, not lost. So the days of someone coming in, wiping out the database and associated information systems may not be gone, but it’s just as critical to deal with a breach situation where information was copied out, no destroyed.
So, in the design phase, we’re building many more systems now starting with the security features needed, then moving on to implementing the solution on top of those. Quite different from days of olde.
On top of this, the options you have available to you are changing rapidly. Make sure you know what’s up on Azure, what’s happening with AWS or Rackspace or Google – make sure you know what your provider is making available to you for security. It’s not just “secure connections” or “encrypted backups” it’s about key management, it’s about access controls and the security controls you have management access to. It’s about encryption all the way through, but also about auditing and documenting those controls.
There are some good tools, but things are developing so quickly – it’s worth subscribing to the security blogs for your platforms of choice so you know as things are updated/released and can stay on top of it.
You’ll also want to be working on understanding the options within the database platform you’re using (SQL Server) and making sure you have those options in place and activated. There have been several cases lately where we’re working with a customer about a specific issue and we find that, while they have the options, (TDE, other encryption options, access controls, audits, etc.) they aren’t fully deployed and they’re left a bit in the wind in terms of protection and management.
All of this comes full circle to data reputation. People are much, much less trusting of information – we have a huge mountain to climb with regards to trust. The trust extends from protecting information to data use. As you design your SQL Server systems (and other platforms, yes), make sure the data pedigree is top of mind. Make sure you’re working closely with consumers of that data to find out what they’ll need to know to feel good about the information they’re using.
These are significant responsibilities for data folks. Collectively, we have to figure how both the protection and the projection of the information we manage. Only then can we start to work through addressing the trust issues on a more general basis.