By: K. Brian Kelley | Updated: 2017-08-07 | Comments (1) | Related: > Security
Problem
Recently, the security folks in my organization have pushed for all of us to have two accounts: one for normal use and one for when we are doing any sort of administrative work, such as the typical DBA tasks for Microsoft SQL Server. Is this really necessary?
Solution
The short answer is, “Yes.” Let’s walk through some of the reasons why.
Email as an Attack Vector
The reality is that email is still a common used attack method to gain access into an organization’s network. An adversary develops malware, verifies it doesn’t trip the most commonly used anti-virus software out there, and then either sends it in email or sends a link in email which, along with attacking some other vulnerability, causes the malware to execute.
Viruses and Worms
It could be that the malware is a virus or worm. It then attempts to infect/destroy whatever it can. We’ve seen this a lot over the last decade and a half. That malware will run in the same user context as the person who opened it. If you have only one account and that account has administrative rights somewhere, anywhere, so does the malware.
Remote Access Trojans / Remote Control Software
Or the malware could install remote control software allowing an adversary to use the computer (and the user account) which executed the malware. If the user account has administrative rights to SQL Server, then so does the attacker.
Ransomware
While this is a particular type of virus, it has made a lot of news recently as organizations including medical hospitals have fallen prey. If everything that a particular account has access to gets encrypted and an account has administrative rights over other servers, has access to shares with sensitive or important information, it’ll all be potentially encrypted. And if you don’t have good, up to date backups/snapshots, you most likely don’t have that data any more.
The “Oops” Factor
Let’s say you’re working on automating a task. You’ve got the components on your workstation or in a test environment of VMs and that’s where you’re doing your testing. Or at least, that’s where you thought you were doing your testing. To your horror you discover that somehow the automation is hitting production. Worse, there’s a bug. Oops.
By having a privileged account that’s separate from your normal account, if you’re not using your privileged account for your testing (perhaps you have another account just dedicated for testing, and this is a valid example of why that’s something to consider), then you can’t affect production. Your automation scripts should fail.
When You Need to be a Regular User and an Admin
If you’re active in the development process, there are times you may need to access the information as a “normal” or regular user. You don’t need to be able to see all the data. And you definitely don’t need to be able to manipulate it. Therefore, by having two accounts you can ensure you have two different levels of access.
Also, and this goes back to the “Oops” factor, consider the case where you may be using Excel to access the data. Maybe you’re only supposed to have read-only access. But if you only have one account and it has sysadmin rights on the SQL Server, you have the ability to change or even destroy the data. A simple mistake could result in a very long day involving restores from backup.
Privileged Access Manager Solutions
Some organizations go a step further and use a privileged access manager solution. Typically these solutions are deployed to servers but in some cases they may even be deployed to workstations. Also typically, only the privileged or “elevated” accounts are protected, at least in the first phase. If you only have one account and you have a PAM, that means for even basic tasks you may find yourself performing additional logins and authentication tasks. It slows down and impairs your day-to-day business. Security is about trade-offs, and availability (or the ability to do your job) is part of that equation.
Compliance
Some regulatory and/or industry standards mandate separate accounts. Some go so far as to break up even workstation versus server administration. Therefore, in order to be in compliance, you have to have multiple accounts. This isn’t really up to the organization because some of the standards there’s no wiggle room. The standards that do this are trying to prevent lateral movement from one type of system (like workstations) to another (like servers).
Next Steps
- Learn about why you should not allow BUILTIN\Administrators by default.
- Consider using Windows groups for access as a best practice.
- Read about more topics in security with our Security Tips.
About the author
K. Brian Kelley is a SQL Server author and columnist focusing primarily on SQL Server security.This author pledges the content of this article is based on professional experience and not AI generated.
View all my tips
Article Last Updated: 2017-08-07
