- By David LeBlanc
In most organizations, data is the most valuable asset, and keeping that data secure is a major concern. Any vulnerability in an organization’s security might end up triggering a series of events that could prove catastrophic to the business. This is why SQL Server 2012 consists of a robust security subsystem that allows you to control access via two modes of authentication, SQL and Windows. As an administrator, you are able to configure SQL Server security at multiple levels. Using T-SQL or SQL Server Management Studio, you can control access to a particular instance of SQL Server, to specific databases, to objects within those databases, and even to columns within a particular table.
SQL Server also includes native encryption. For example, if you want to secure employees’ Social Security numbers, using column level encryption, you could encrypt a single column in a table. SQL Server also includes Transparent Data Encryption (TDE), which allows you to encrypt an entire database without affecting how clients and applications access the data. However, if someone were to breach your network security and obtain a copy of a data file or backup file, the only way that person could access the data is with an encryption key that you set and store.
Even with all of these security capabilities, SQL Server provides you with the ability to audit your server and databases proactively. In SQL Server 2012, you can filter audit events before they are written to the audit log. Chapter 26, “Security,” describes how to plan and deploy your SQL Server security strategy. You will learn specific concepts around creating logins and users, and you will examine how to create a security approach and maintain security accounts.
Also in SQL Server 2012, you can create user-defined server roles, which can assist in providing a more secure method of allocating server-level access to server administrators. Microsoft has included the ability to create users within a database without requiring you to create a server login, known as contained databases. In past versions of SQL Server, prior to granting access at the database level, an administrator was required to create a server login. With the advent of SQL Server 2012, a user can be self-contained within a database.