SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Understanding the Three A’s of Security for SQL Server

Do you know what the “Three A’s of Security” are and how they apply to Microsoft SQL Server? Let’s look at them as they are important for managing security properly on a given Microsoft SQL Server.


Authentication is determining who a person/process is.

When a connection is made, it’s important to know what account is making that connection. Authentication is the process of validating who that connection is. There are two types of authentication with respect to users connecting to SQL Server:

  • SQL Server’s build-in logins
  • Windows logins

In the first case, SQL Server has stored logins with passwords and if SQL Server is set to mixed mode authentication, these logins can be used to make a connection to a given SQL Server. More on mixed mode authentication in another post. In the second case, a Windows user can connect to SQL Server. This access can either be granted by to the Windows user directly or via a Windows security group.

Obviously, there are times when SQL Server is able to authenticate a connection but that connection isn’t allowed access to any resources, to include simply logging in to the SQL Server itself. That leads us to the next A.


Authorization is determining what a person/process is allowed to do.

Once SQL Server knows who the connection is, the next question is what should that connection have access to? This is authorization. The initial check is to see if the account in question should even be able to log in to the SQL Server. If it does have that permission (you’ll see it as CONNECT SQL if you look at the permissions), the next question is what other permissions should it have. This can be at the server level and it can be within the individual databases.


Auditing is keeping track of what happens for a person/process.

Auditing is the record keeping involved with tracking various security events. For instance, SQL Server can track both successful and failed logins. Typically, it’s recommended that at least failed logins be tracked. SQL Server can, depending on the edition, audit just about anything you want to track. We’ll cover auditing in more detail in later posts.


Databases – Infrastructure – Security

Brian Kelley is an author, columnist, and Microsoft SQL Server MVP focusing primarily on SQL Server security. He is a contributing author for How to Cheat at Securing SQL Server 2005 (Syngress), Professional SQL Server 2008 Administration (Wrox), and Introduction to SQL Server (Texas Publishing). Brian currently serves as an infrastructure and security architect. He has also served as a senior Microsoft SQL Server DBA, database architect, developer, and incident response team lead.


Leave a comment on the original post [truthsolutions.wordpress.com, opens in a new window]

Loading comments...