Stairway to SQL Server Security
SQL Server has everything you need to secure your server and data against today’s sophisticated attacks. But before you can use these security features effectively, you need to understand the threats you face and a few basic security concepts. This first stairway level provides a foundation so that you can take full advantage of the security features in SQL Server without wasting time on features that do nothing to protect against specific threats to your data.
- The ubiquity of databases and the potentially valuable information stored in them makes them attractive targets for people who want to steal data or harm its owner by tampering with it. Making sure that your data is secure is a critical part of configuring SQL Server and developing applications that use it to store data.
- Authentication is the first step in letting a principal get access to an instance of SQL Server, essentially resolving the question, Who are you? In this stairway level you’ll learn about the basics of authentication and the authentication options available. This level covers logins and users and you’ll learn about the password policies that can help strengthen SQL Server authentication.
- What is a SQL Server principal? And what does it get a permission on? In this stairway level, you’ll learn about the various principals that can be authorized through permissions to perform actions and access securable objects in the SQL Server instance.
- A permission gives a principal access to an object to perform certain actions on or with the object. SQL Server has a mind-numbingly huge number of permissions that you can grant to a principal, and you can even deny or revoke those permissions. This sounds a bit complicated, but by the end of this stairway level you’ll understand how SQL Server permissions work and how you can exert very granular control over object creation, data access, and other types of actions on database and server objects.
- In this stairway level you’ll learn how you can give principals access to groups of objects by assigning permissions on schemas instead of individual tables, code modules, and other objects. You’ll also learn about the benefits of user-schema separation and how it can increase object security, and how using default schemas for users and groups can simplify object access management and security.
- A fundamental way that SQL Server determines whether a principal has the permissions necessary to execute code is with its execution context rules. It’s all complicated by the possibility that a principal has permission to execute code but doesn’t have permission on the underlying objects accessed by the code, such as the data in a table. This stairway level will explore SQL Server’s execution context, ownership chains, and impersonation, as well as show you how you can control access to data via T-SQL code.
- Sometimes you need to reach outside a database and access data and objects from multiple databases, which raises some security issues and increases the complexity of data access. In this stairway level, you’ll learn about cross-database ownership chaining so that you can reach across database boundaries securely.
- This stairway level will explore data protection through encryption, both when the data is in motion across the network or in memory and at rest in a table. You’ll learn about the encryption key hierarchy and the various kinds of keys you can use to encrypt data, as well as how you can manage the keys or let SQL Server do it for you.
- Even an otherwise well-secured database is susceptible to attack if an attacker is able to get access to the disk files that comprise the database. Cell-level encryption can protect some of the data, but for complete protection against this kind of attack it is necessary to encrypt the files and not just the data. That is exactly what Transparent Data Encryption (TDE) does, and in this stairway level you'll learn what TDE does, how it works, and how to make use of it to protect your database files.
- Unlike some other industrial-strength database servers, SQL Server lacks a built-in mechanism for protecting individual data records, called row-level security. This stairway level explores why you might want to use such a low-level granularity of data access security and how you can implement row-level security.
- By defining server- and database-level audits, you can record just about any kind of event that occurs in SQL Server, which can be an invaluable source of security troubleshooting and forensic information when security breaches occur. In this stairway level you’ll learn how to define the various audit specification objects, how to capture audit data, and how to explore and use the data.