Ima make a deal with the SA so the SA don’t bite no more

T-SQL Tuesday

TSQL Tuesday #63 – How do you manage security?

Yay, so this is my first official blog party post.  I was late with my post last month because I didn’t have it figured out until I saw everyone posting and wondered what was going on.

One of my goals for this year is to increase security across my 50 SQL servers.  The SA log-in is a dangerous one and I don’t want it out there on my servers, the trouble is that it is hard to exterminate. Here is my new plan.

I am going to script out my SA log-in and password using this script.

Next I am going to rename the SA log-in to something else and give it a much stronger password. This information will go into my password safe so that I have it just in case I need it.

I am going to create a dummy SA. I have many vendor databases that claim they need SA, but they really don’t and I don’t want them to have high privileges.  I am going to work on lowering the privileges to only give what they need (this will be a slow server by server process to get the permissions right).  The reason I am keeping a log in with the name “SA” is because of vendors who hard code that user name.

As I was talking to people in the #SLCSQL user group last night, someone suggested that we can also monitor that dummy SA login to watch for attacks. It is a great idea and plan to include monitoring on the new log in.

Lars Rasmussen suggested I have a user on each server that will always be there to handle running jobs and other database needs.  I plan to include this too so that when I don’t have a proper SA log in, I will still have a log in that can handle all my fun stuff.

By doing all of this, my SA won’t bite me anymore.

T-SQL Tuesday is a blog party started by Adam Machanic (b|t) just over five years ago.  This month it is hosted by Kenneth Fisher (b|t).

Biting – Bits and Bytes

A few weeks ago I found myself talking with a network engineer.  We were discussing why my data being transferred over a network was slow.  It was a small database and I didn’t understand why if we have a 1 gigabit connection, my 1 gigabyte database was slow moving over it.  I am still working this concept in my head and would love feedback of how to help me understand it better.

A bit is one binary digit of 0 or 1.  One kilo-bit (kb) is 1000 bits, One Megabit(Mb) is 1,000,000 bits and One Gigabit (Gb) is 1,000,000,000 bits. Bits are always represented as b whereas Bytes are represented as B.  Bits focus on the data being moved over the wire between two telecommunication devices and are moved as binary.  Usually the speed is measured in seconds for example 8kbps means you moved 8000 bits or 8 kilo-bits in a second between two telecommunication points. Moving 8000 binary digits in a second isn’t too bad…right?  So why is my stuff moving slow.  Isn’t that close to moving  an 8KB SQL page?  No, let’s keep going.

One Byte is equal to 8 bits.  One Kilobytes (KB) is 1024 bytes or 8192 bits. One Megabyte (MB) is 1,048,576 bytes or 8,388,608 bits and for fun, lets do Gigabytes.  One Gigabyte (GB) is 1,073,741,824 bytes or 8,589,934,592 bits.  This is a lot of math and there are wonderful calculators around to help you compute your current and desired throughput.

On to our next interesting fact: To go over the wire, your Bytes are being transferred into bits and then back up to Bytes on the other end.  So if your connection is 8kbps (remember that is kilo-bits per second) you are only moving about 1000 Bytes per second.  Let’s look at my gigabit connection. If I am moving one gigabit per second (1gbps) then I am only moving (I am rounding) about 120 Megabytes (MB) per second. That is a big difference that what I thought I should be moving.

I know there are a lot of cool ways to move data faster, but this is a concept that every DBA should keep at the back of their mind even if it is just to perform a party trick to make your network engineer friends feel included.

Happy Biting!