When you hear about breaches, so many times it’s because someone didn’t do their job protecting their SQL Server, protecting the data, or protecting the pipes that feed and move the data around. It’s a big deal – and with your (likely) cloud environment, the model and approach to all of this is changing.
Chain of custody… “that records the sequence of custody, control, transfer, analysis, and disposition of physical or electronic evidence. “
https://en.wikipedia.org/wiki/Chain_of_custody
Just substitute “information” or data for “evidence.”
One of the things that has come out of more space is better backups, more comprehensive testing, more data use. These are great things on their face. Better backups because of the ready availability of storage space, ease of access and speed of access. More testing because, well, storage space. It’s a much simpler thing now to set up test instance, move information into it from production and then start testing – might as well take a whole complete picture, test against that so you know what’s what.
These are great – but they often lead to issues of data sets being strewn about, usually protected, but sometimes forgotten. It’s important to remember this as you go through the life of data (sounds like a bad movie). As you move information around, make it available for projects, it typically lands on servers that live on-premises at your company, in worksheets, on USB drives, on extended storage in the cloud… just for awhile while you get what you need from the information. But what’s that cleanup process like? How do you KNOW it’s being followed?
Facebook (again) got stung about their data policies of the past – but this time, it’s more about the fact that they shared information with someone that didn’t do the due diligence with the information.
Here’s a link to a look at what’s happened.
But there’s a truly critical lesson here. We need to be much better about protecting the data “womb to tomb” and making sure that it moves beyond encrypting data at rest and in transit in the traditional sense. How many S3 buckets or other storage locations do you have associated with your company that have random files and “temporary” data dumps ferreted away in them?
With your SQL Server instances, have you created development servers? Do they have any real data in them? There are tools for creating typed information to be used for testing – information that is meaningless and not real. These are very important to put into use for your systems.
It’s important to have a SQL Server decommissioning plan too – not just “how we bring a new server instance online” but also “how do we take one out of service” – because so many times, as you move to a new release, or as you bring a new instance online using data from an old one, that old one hangs around for longer than it should. Perhaps forever.
Don’t get stung managing your databases – local or in the cloud – without MANAGING your instances. It can be an extremely painful process to be “found out” and not all of us have the resilience of a huge corporation to absorb a mistake that can be managed well proactively.
