|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
| Segments for Protection This editorial was originally published on 18 Jun 2019. It is being re-run as Steve starts his sabbatical today and this gives Grant and Kellyn a few more days to get organized. I haven't worked in many high security environments. While I have worked in a nuclear power plant, we had tremendous physical security and air gapped control systems, but cyber-security was still fairly loose from the perspective of internal systems. If anyone got to a local machine, they could have done some serious hacking and likely found lots of open information on our LAN. This was pre-Internet days, and I wonder if security has improved in those plants with the advent of the Internet and http protocols. I certainly hope so. I thought back to that environment as I was reading a network security piece from DCAC on some of the problems they have seen with ransomware attacks. There are all sorts of things you can do to protect and educate users, but ultimately those humans are going to be a weak link. As a result, locking down network, and potentially account, access to servers is important. In the piece, Joey talks about needing to use a special laptop, two keycards, and jump hosts to connect to a server for one customer. I have another customer that has a similar arrangement, using a jump box that's in a data center to connect to servers. Nothing runs from his desktop, with no way to connect to the actual DMV other than using RDP to visualize SSMS on a remote machine. In their systems, Microsoft has implemented some very secure SAW and PAW systems to allow access to Azure systems in a secure way for their employees, while protecting customers and auditing all actions. These are all cumbersome, annoying, and painful solutions. They slow down the ability to get things done, but they also limit the mistakes people make. Who among us has logged onto the wrong machine and run a script? Worse, who might have granted access on the wrong instance before realizing it and adding the privilege on the right server. After doing that, did you remove the mistake from the first instance? Maybe, but experience has shown me many people plan to remove things later and then forget to actually perform the action. This seems especially relevant today. I got a message as I was writing this from a user on one of the SQLServerCentral social network platforms. This user wanted to know if they could restore their database with only a log file as their data file was encrypted with ransomware. That's a bad day at work, and likely one that occurred because every machine on the network can connect with every other one. Convenient, but insecure and certainly a problem today. This is one place the cloud forces you to be better. Everything is locked down from the start because Microsoft (Azure) and Amazon (AWS) do not trust the customers on their internal networks. They have to segregate everything, and force us to explicitly configure things ourselves. They make it easy, but we still need to do the work. It's a scary time to work on systems, with constant scanning, probing, and attacks taking place on systems. It's also a time where we have more tools, templates, scripts, and capabilities for defense. We should use those to better protect our systems from ourselves. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
