The most crucial of a database administrator's tasks is frequently security. SQL Server includes numerous sophisticated security and data-protection capabilities, but they take forethought and work to fully use. Robert Sheldon discusses the different components available to safeguard and protect SQL Server databases in this first of a series of articles.
When administering a SQL Server instance, security is one of the most difficult concerns to deal with, but it's also one of the most vital, especially when sensitive and personal data is at stake. Indeed, security is a top priority for many firms, which should come as no surprise given the stakes.
SQL Server, fortunately, comes with several features for safeguarding data from theft, destruction, and other forms of hostile action. In this first of a series of SQL Server security articles, I'll introduce you to a number of these tools, to give you a sense of the options available for protecting your data. In upcoming posts, I'll go into greater detail about the various technologies, including how they function and what it takes to defend a SQL Server instance.
Importance of SQL Server Security
SQL Server is an enterprise-class database platform with a vast and increasing user base. Many businesses use it since it is well-known. This means that SQL Servers, which are increasingly being targeted by hackers, are storing large volumes of essential and sensitive data. You leave SQL Servers vulnerable to data breaches and stolen information if your access to them isn't secure. Managing SQL Server security is one of the more difficult responsibilities you'll face, but it's also one of the most important.
SQL Server Security Basics and Functions
Here are some SQL Server security features to be aware of to protect your server's data:
SQL Server Authentication vs. Windows Authentication
Microsoft SQL Server offers two types of authentications i.e., Windows Authentication and Server Authentication.
Before users connect to SQL, Windows Authentication uses Active Directory (AD) to authenticate them. Because AD is the best approach to handle password restrictions and user and group access to applications in your organization, it is the recommended authentication mode. The database server stores usernames and passwords for SQL Server Authentication. When Active Directory isn't available, it can be utilized instead.
You can use both SQL Server and Windows Authentication at the same time (mixed-mode), however, Windows Authentication should be used solely whenever possible.
If SQL Server Authentication is required, make sure the default SA account is either disabled or has a strong password that is updated periodically, as this account is frequently targeted by hackers. The SQL Server Management Studio service or the ALTER LOGIN Transact-SQL (T-SQL) command can be used to manage SQL Server accounts, including sa (if it's enabled).
Server Logins and Roles
There are two sorts of logins that you can configure to SQL instances, regardless of the authentication technique you use: user logins and server logins. In the next section, I'll go through user logins. Users can connect to a SQL Server instance using server logins. Each server login has one or more server roles assigned to it, which allows it to conduct particular tasks on the instance. Server logins are given the public server role by default, which grants basic access to the instance. Bulkadmin, securityadmin, dbcreator, and serveradmin are some of the other jobs available.
T-SQL or the SQL Server Management Studio can be used to generate server logins. A default database must be specified when configuring a server login. In the default database, server logins are linked to user logins. It's worth mentioning that the names of a server login and its corresponding user login don't have to match. The server login will be refused access if there is no related user object in the default database unless the server role assigned to the login has access to all databases. When setting up server logins, you can map them to a user in one or more databases, and you can also create users.
Database Users, Schema, and Roles
You must indicate the database with which the user will be associated, a username, and a default schema that will be applied to all objects created by the user if no alternative schema is specified. SQL Server schemas are logically separated groups of items, such as tables and views, from other database objects, making access easier to manage and eliminating the need to utilize the schema name when running T-SQL commands against a database.
The dbo schema is the default schema for user-defined objects. The sys schema is the other default schema, and it owns all system objects.
User logins are assigned database roles, which assign rights in databases, in the same manner, that server logins are assigned server roles. Public, db accessadmin, db owner, and db securityadmin are some of the database roles available on a server.
Securables and Permissions
You can assign one or more securables instead of server or database roles when a user has too much or too little access. Securables are SQL Server resources that can be accessed by server and user logins at the server, schema, and database levels. For example, you could use securables to grant a server login access to a single table or function, a level of granularity that isn't achievable when a role is assigned to a login.
Access to SQL Server securables is controlled by permissions. You can give people permission to only look at data or just change it. Permissions are configured using the GRANT, DENY, and REVOKE T-SQL commands.
Permissions, on the other hand, can be tricky. Setting DENY permissions on a securable, for example, prohibits permissions from being passed down to lower-level objects. However, GRANT permission at the column level supersedes DENY permission at the object level, thus DENY permission on a table is overruled by GRANT permission on a column. Because permissions might be complicated, it's usually a good idea to double-check them with T-SQL. Joel's permissions on an object, in this case, a table called 'employees,' are determined by the following command.
SELECT * FROM fn_my_permissions(‘joel’, employees);
- Data Encryption Multiple encryption options are available in SQL Server:
- Secure Sockets Layer (SSL) encrypts traffic as it passes between the server instance and the client application, similar to how internet traffic is encrypted between the browser and the server. The client can also use the server's certificate to verify the server's identity.
- Data on the disc is encrypted using Transparent Data Encryption (TDE). It encrypts the entire data and log files, in particular. When TDE is enabled, client apps do not need to be updated.
- Backup Encryption is similar to TDE, except instead of encrypting active data and log files, it encrypts SQL backups.
- Column/Cell-Level Encryption ensures that data is encrypted in the database and that it stays encrypted even when it is stored in memory. Data is decrypted via a function, which necessitates client application adjustments.
- Always Encrypted is a step forward over Column/Cell-Level Encryption in that it doesn't necessitate any changes to client programs; data remains encrypted throughout the network, in memory, and on disc. It also shields confidential information from the prying eyes of privileged SQL Server users. However, because SQL Server can't read the data, several indexing and functions won't operate if you select this encryption option.
- Row Level Security Organizations can use Row-Level Security (RLS) to limit who can see which records in a database. You could, for example, limit users' access to rows containing information about their clients. A predicate function, a security predicate, and a security policy are the three major components of RLS. The predicate function determines if the database query's user can access a row based on logic. You could, for example, see if the query's user's username matches a field in one of the row's columns. A function that combines a predicate function and a security predicate to either silently filter the results of a query without raising errors or to block with an error if row access is refused.
The Best SQL Server Security Monitoring Tools
Various technologies on the market can assist businesses in managing database security and performance. SQL database security solutions should be a key priority for any administrator, as your information is at risk without one.
SolarWinds® Security Event Manager (SEM) comes highly recommended as a comprehensive tool for swiftly and efficiently detecting security risks. As soon as an issue emerges, SEM has automated incident reactions to destroy malicious apps or USBs, block IPs, and adjust privileges or access rights. It also keeps track of all your files to guarantee that registry, file, and folder activity isn't malicious, which might assist you to avoid transferring harmful files to your servers.
You can also use the tool to examine incidents for SQL Server security audit or compliance purposes, to figure out what went wrong or what you could have done differently. SEM is available for a 30-day free trial from SolarWinds so you can see if it's perfect for your company.
Paessler PRTG is a network monitoring solution that monitors your network, routers, switches, and servers without the use of any agents. With PRTG, you can track the time it takes a SQL query to complete its request, including the time it takes to create the connection, execute the query, handle the transaction, and close the connection, all of which can be seen on the PRTG dashboard.
The PRTG licensing model is based on sensors (device-level metrics such as CPU load, port status, and network traffic) and includes pre-configured sensors for all major databases. The Microsoft SQL v2 Sensor from PRTG analyzes the response time of a complete request, as well as the response time of individual requests in Microsoft SQL. Paessler PRTG is available for a 30-day free trial.
3. ManageEngine Applications Manager (APM)
ManageEngine APM is an agentless application and server performance monitoring solution that helps businesses assure optimal performance of mission-critical applications like SQL Servers in physical, virtual, and cloud environments. APM provides SQL Servers and other applications with out-of-the-box discovery, availability, health and performance tracking, and reporting.
Database administrators can use APM to get visibility into SQL applications, track resource utilization, optimize SQL Server performance, prevent problems, and maintain the database application's general health.
4. Microsoft Defender
Microsoft Defender for SQL is a SQL Server security solution that detects and mitigates potential SQL database vulnerabilities and unusual activity that could put your database at risk.
Microsoft Defender for SQL is made up of two Microsoft Defender plans: This plan is meant to safeguard Azure SQL databases, Azure SQL managed instances, and dedicated SQL pools in Azure synapse. On-machine Microsoft Defender for SQL Servers: This strategy enhances Azure-native SQL Server protections to fully support hybrid environments and protect SQL Servers hosted in Azure and other cloud environments, as well as on-premises equipment, such as SQL Server on virtual machines and on-premises SQL Servers.
DPA employs machine learning techniques to learn how your database users generally function, allowing it to spot performance irregularities or red flags that indicate a security risk. You can test it for 14 days for free. These plans can be enabled at the subscription level (from Microsoft Defender for Cloud or using the REST API, Azure CLI, PowerShell, or Azure Policy) or at the resource level (from Microsoft Defender for Cloud or via the REST API, Azure CLI, PowerShell, or Azure Policy). All supported resources that exist within the subscription (including future resources created on the same subscription) are covered when you enable one of these plans.
Datadog is a cloud application, server, database, tool, and service monitoring solution with an agent-based on-premises and cloud infrastructure monitoring service. Datadog explores and identifies apps, devices, and servers on your network using its auto-discovery service. Once all devices and linkages have been detected, the Datadog dashboard can be used to observe all activity and immediately detect any network changes.
Datadog delivers end-to-end visibility into your SQL Server instances' health and performance. It includes two out-of-the-box SQL Server dashboards, as well as tools and critical metrics for SQL Server monitoring:
A screening board that shows you an overview of your SQL Server instances in real-time. A timetable that's ideal for comparing SQL Server metrics to system metrics and events.