SQL Server Security

Best Practices
Table of contents

Introduction 4

Harden the Windows Server where SQL Server Operates 4

Understand Common SQL Threats 4

Install Only the Required SQL Database Components 5

Limit the Permissions of Service Accounts According to the Principle of Least Privilege 6

Follow Firewall and Network Security Best Practices 7

Configure SSL to Encrypt SQL Data in Transit 8

Turn Off the SQL Server Browser Service 8

Understand SQL Server Roles 9

Understand SQL Server Effective Permissions 10

Use Strong Passwords for Database Administrators 10

Install SQL Server Updates Promptly 11

Understand SQL Server Authentication Options 11

Control Password Options for Logins 12

Be Diligent about Disabling and Deleting Logins 12

Back Up Your Databases 13

Monitor and Alert on SQL Server Activity 13

Mitigate the Risk of SQL Server Concurrency Issues 14

Baseline SQL Activity and Watch for Deviations 15

Audit Access Attempts and Changes to Access Permissions 16

Enable SQL Server Audit 16

Mitigate SQL Injection Risks 16

Minimize the Risk of Side-Channel Attacks 17

Use Encryption Wisely 18

Use Data Masking Techniques 19

Choose Effective SQL Security Tools 20

About Netwrix 23
Introduction
While SQL Server is designed to be a secure database platform, following best practices for configuring, managing,
and monitoring your SQL Server environment can significantly reduce your risk of costly breaches, downtime, and
violations of data protection and privacy regulations such as GDPR, HIPAA, PCI DSS, and SOX.

To help, this article details the critical SQL Server security best practices to implement. You’ll learn about implementing
robust access controls, regularly patching and updating software, conducting security assessments, and more.

Harden the Windows Server where SQL

Server Operates
Hardening the Windows Server operating system before installing SQL Server is one of the most critical security
best practices. Attackers who gain access to the OS can copy your valuable database files to their server, where
they can break passwords and encryption at their leisure. To learn how to strengthen your Windows Server,
review these Windows Server hardening best practices.

Understand Common SQL Threats

Like any database management system, SQL Server is susceptible to threats that could compromise data integrity,
confidentiality and availability. Common threats to be aware of include:

▪ SQL injection attacks occur when malicious SQL code is injected into the input fields or parameters of a SQL
query. This can enable attackers to execute commands or to steal sensitive data, modify database records or
gain access to the underlying system.

▪ Unauthorized access refers to exploiting weak authentication mechanisms or misconfigured access controls
to gain entry into SQL Server instances or databases. Attackers may attempt to brute-force passwords, exploit
default credentials or bypass access controls to gain elevated privileges or access sensitive data.
 ▪ Data leakage occurs when sensitive or confidential information is improperly exposed from SQL Server
databases. This can happen due to misconfigured permissions, insecure data storage practices or inadequate
encryption of sensitive data.

▪ Denial of service (DoS) attacks target SQL Server instances or databases with the intent of disrupting service
availability or causing system downtime. Attackers may flood SQL Server with excessive requests, execute
resource-intensive queries or exploit vulnerabilities to exhaust system resources and disrupt normal
operations.

▪ Database exploitation involves the exploitation of vulnerabilities in SQL Server or the underlying operating
system to gain unauthorized access to or control over the database server. Attackers may exploit unpatched
vulnerabilities, insecure configurations or weak encryption mechanisms to compromise the integrity or
availability of SQL Server databases.

▪ Privilege escalation occurs when attackers exploit vulnerabilities or misconfigurations to elevate their privileges
in order to gain access to sensitive data or administrative functions on the database server.

▪ Insufficient auditing and logging practices may hinder detecting and responding to security incidents in SQL
Server environments. Inadequate logging of security events, weak audit policies or lack of monitoring may
prevent timely detection of unauthorized access, data breaches or suspicious activities.

▪ Social engineering attacks target SQL Server administrators, developers or users through manipulation or
deception to expose sensitive information or grant unauthorized access. Attackers may use phishing emails,
pretexting or impersonation techniques to trick individuals into revealing credentials, executing malicious
code or disclosing confidential information.

Install Only the Required SQL Database

Components
You should limit the installation to just the components your database needs to perform its tasks. This
approach reduces your attack surface area by eliminating components that could have security vulnerabilities.
It also minimizes resource utilization by the database and simplifies administration by removing services and
components that must be managed.
Below are some essential components to consider:

▪ Database Engine Services — This is the core component of SQL Server responsible for storing, processing
and securing data.

▪ SQL Server management tools — Include SQL Server Management Studio (SSMS) or Azure Data Studio for
managing and administering the SQL Server instance.

▪ Integration services — If your applications require ETL (extract, transform, load) functionality, select
Integration Services to enable SSIS package execution.

▪ Full-text and semantic extractions for search — Enable this feature if your applications require full-text
search capabilities.

▪ Analysis services — Choose this option if you need multidimensional or tabular data analysis services.

Limit the Permissions of Service

Accounts According to the Principle
of Least Privilege
Each SQL Server service runs under a specified account. Those service accounts should be configured based on
the principle of least privilege, which states that each account should have the minimum permissions it needs
to function. Those rights should be assigned using security groups rather than directly to improve accuracy and
transparency.

Best practices include assigning each service a separate account. That way, even if the account for one service is
compromised or damaged, other services will still operate normally.
Here are the types of accounts you can use for SQL Server services:

▪ Active Directory (AD) managed service account (MSA) — This is the best option for two reasons. First,
managed service accounts cannot be used to log on to a server, so they are more secure than domain user
accounts. Second, you do not need to manually manage password resets for service accounts, which reduces
the risk of account compromise.

▪ Domain user account — This is the most common type of account used to run services. This account type is
entirely secure in a domain environment because it doesn’t have administrator privileges.
 ▪ Local user account — This is a good choice for non-domain environments.

▪ Local system account — These accounts are highly privileged, so you should avoid using them to run services.

▪ Network service account — This type of account has fewer privileges than a system account. Still, it enables
a service to access network resources, so you should avoid using it whenever possible.

▪ Virtual service account — A virtual service account is similar to an AD managed service account, but it is
a type of local account that you can use to manage services without a domain. NT Service\MSSQLSERVER is
an example of a virtual account that gets created when you install SQL Server and is assigned to the service.
These accounts have minimal privileges by default and are more secure than domain user accounts.

Follow Firewall and Network Security

Best Practices
You can further enhance the security posture of your SQL Server environment by implementing the following
firewall and network security best practices:

▪ Limit network access to SQL Server by configuring firewalls to allow connections only from trusted IP
addresses or subnets. Use network segmentation to isolate SQL Server from other systems and services
to reduces the attack surface. Disable unnecessary network protocols and services on SQL Server, such as
Named Pipes and TCP/IP.

▪ Change the default port used by SQL Server (1433 for default instances, 1434 for SQL Server Browser) to a
non-standard port to make it harder for attackers to discover and target SQL Server instances.

▪ Use IPsec (Internet Protocol Security) to secure network communication between SQL Server instances and client
applications. IPsec provides authentication and encryption at the IP packet level, enhancing network security.

▪ Use Windows Firewall or a third-party firewall to control inbound and outbound traffic to SQL Server.
Configure firewall rules to allow only necessary traffic to SQL Server ports.

▪ Implement an intrusion detection and prevention system (IDPS) to monitor network traffic and alert
administrators about suspicious activity.
Configure SSL to Encrypt SQL Data
in Transit
Configuring SSL/TLS to encrypt SQL data in transit helps protect sensitive information from unauthorized access
during communication between client applications and the SQL Server instance. You should obtain a server
authentication certificate from a trusted Certificate Authority (CA) or create a self-signed certificate. The certificate
should include the fully qualified domain name (FQDN) of the SQL Server computer as the Common Name (CN)
or as a Subject Alternative Name (SAN).

Test SSL/TLS encryption by connecting to the SQL Server instance from a client application using SQL Server
Management Studio (SSMS) or another database client.

Turn Off the SQL Server Browser Service

The SQL Server Browser service eliminates the need to assign port numbers to instances. While enabling this
service enables SQL admins and authorized users to discover database instances over the network, it also makes
it possible for attackers to gain knowledge of the available SQL Server resources.

When running a default instance of SQL Server, you should turn off the SQL Server Browser service or configure
another port for it to use to communicate. Then restart the SQL Server instance service, test application and client
connectivity to the SQL Server, and update your firewall rules to allow direct access to the SQL Server.
Configure SSL to Encrypt SQL Data
in Transit
Server roles provide an easy way to delegate administrative privileges, but you must assign these roles carefully.
Always follow the principle of least privilege when assigning roles to users. For example, if a user needs only to be
able to shut down the server and end processes, they should be assigned the server admin and process admin
roles; assigning them the sysadmin role would violate the principle of least privilege. There are several types of
roles to understand:

▪ Fixed server roles are predefined server-level roles with a specific set of permissions. They provide
administrative access to various server-level operations. Examples of fixed server roles include:

– sysadmin — Members of this role have full administrative privileges on the SQL Server instance.
– server admin — Members can configure server-wide settings.
– security admin — Members can manage Microsoft SQL server security settings and permissions.
– setup admin — Members can manage linked servers and server configuration settings.
– process admin — Members can manage SQL Server processes.
– bulk admin — Members can perform bulk insert operations.

▪ Fixed database roles are predefined roles within each database with specific permissions. They control
access to database-level operations. Examples of fixed database roles include:

– db_owner — Members of this role have complete control over the database, including the ability to modify
the schema, execute DDL statements and manage users.
– db_datareader — Members can read all data in the database.
– db_datawriter — Members can add, modify and delete data in the database.
– db_ddladmin — Members can execute DDL statements in the database.
– db_securityadmin — Members can manage security permissions in the database.

▪ User-defined roles are created by administrators or database owners to meet specific application or business
requirements. These roles can have custom sets of permissions tailored to the needs of the application or users.
Understand SQL Server Effective
Permissions
Create containers (such as groups or roles) and assign them permissions to access resources. Then, make accounts
of members of those groups of roles.

Following this best practice will be easier to understand the effective permissions for each account. Moreover, simply
by putting a user in the right groups or roles, you can easily assign the correct permissions to new hires, accurately
modify permissions as a user’s role changes and remove a user’s permissions when they leave the organization.

When multiple permissions are granted to a user through different roles or groups, SQL Server follows a hierarchy
to determine the effective permissions. Generally, the most permissive permission prevails, but if any permissions
are explicitly denied, that overrides any grants.

There are three levels of permissions to understand:

▪ Server-level permissions — Server-level permissions control actions that can be performed at the server
level, such as creating databases, altering server configuration settings and shutting down the server.

▪ Database-level permissions — Database-level permissions control actions that can be performed within a
specific database, such as querying tables, updating data and executing stored procedures.

▪ Object-level permissions — Object-level permissions control access to individual database objects, such as
tables, views, stored procedures and functions. You can grant permissions such as SELECT, INSERT, UPDATE,
DELETE, EXECUTE and CONTROL at the object level.

Use Strong Passwords for Database

Administrators
Strong passwords are necessary for all database administrator accounts to make them resistant to brute-force
attacks. Be sure to follow current password best practices for password length and complexity.
Install SQL Server Updates Promptly
Both white-hat and malicious hackers are constantly discovering vulnerabilities and exploits in SQL Server.
Microsoft releases several types of updates to fix them:

▪ Hotfixes, also known Quick Fix Engineering (QFE), are released to solve problems ASAP. Due to the tight time
constraints, hotfixes receive limited testing, so they should be applied only to systems known to have the
specific issues they address.

▪ Cumulative updates (CUs) are periodic releases of hotfixes with thorough testing.

▪ Service packs (SPs) are collections of patches and fixes that have been adequately tested and can easily be
installed as a single package.

The simplest way to keep SQL Server up to date is to enable automatic updates from Microsoft. Organizations
with a solid change process should apply updates only after performing their own testing.

Understand SQL Server Authentication

Options
SQL Server offers several options for authenticating users:

▪ Windows Authentication is recommended in environments where SQL Server and client applications are
in a Windows domain. Users connect to the SQL Server using their Windows credentials and the SQL Server
validates their identity. This provides a more secure and centralized authentication mechanism.

▪ SQL authentication or mixed mode authentication requires users to provide an SQL server login ID and
password when connecting to the SQL server. User credentials are stored in SQL Server’s security system
rather than managed by Windows; this provides flexibility for environments where Windows authentication is
not feasible. If you use this authentication mode to connect to SQL Server, do not use the sa account since it
is the first account attackers will try to compromise in a brute-force attack.
 ▪ Microsoft Entra authentication (introduced in SQL Server 2022) allows users to connect to SQL Server
using their Entra ID identities. It provides centralized identity management and integrates with Azure AD’s
security features, such as conditional access and multifactor authentication. It requires the SQL Server to
be configured for Azure AD authentication and for users to be synchronized with Azure AD. Microsoft Entra
authentication supports Azure SQL database, Azure SQL managed instance, SQL Server on Windows Azure
VMs, Azure Synapse Analytics and SQL Server.

Control Password Options for Logins

In a Windows environment, administrators can enable policies that control user password complexity and
expiration. You have similar options for SQL Server logins:

▪ MUST_CHANGE — SQL Server will prompt users to change their password the next time they log on. Use this
option whenever you create a new user. You can also use it to force a user to reset their password.

▪ CHECK_POLICY —The Windows password policies of the computer on which the SQL Server is running will be
enforced for the user. Always enable this setting.

▪ CHECK_EXPIRATION — The user will be required to reset their password regularly. Always enable this setting.

Be Diligent about Disabling and Deleting

Logins
If a login will not be used for longer than one month, it should be disabled for the interim and then re-enabled.
Regularly review all logins and deleted any that have been disabled for more than one year.
Back Up Your Databases
Backups help ensure that data can be recovered in case of system failure. Full backups back up the entire
database, while differential backups back up only the changes since the last full backup.

Differential backups are much faster and occupy less disk space than full backups, so they are especially useful
for large databases. However, full backups should still be taken periodically. For small databases, the best practice
is to use full backups every time.

You can also take file and filegroup backups, which back up only specific files or filegroups. This strategy can
reduce backup time and speed recovery of a single file or filegroup. However, be aware that managing filegroup
backups can be complex.

Monitor and Alert on SQL Server Activity

Effective monitoring is critical to detecting, diagnosing and resolving problems. For example, you might be able to
identify long-running queries that could be malicious. Valuable tools include the following:

▪ SQL Server Management Studio (SSMS) — Utilize SSMS tools to monitor processes, resource usage and
system performance. In particular, SSMS Activity Monitor provides real-time insights into CPU usage, memory
consumption, disk I/O and active sessions.

▪ Dynamic management views (DMVs) — Use DMVs to identify long-running queries, blocking processes,
memory pressure and other performance bottlenecks. Common DMVs include:

– sys.dm_exec_requests
– sys.dm_exec_sessions
– sys.dm_exec_connections
– sys.dm_os_wait_stats

▪ SQL Server Profiler — Use SQL Server Profiler to capture and analyze SQL Server events, including queries,
stored procedure executions, errors and security-related events. Customize trace templates to capture
specific events or filter out unnecessary information. Analyze captured traces to identify performance issues,
diagnose errors and optimize queries.
 ▪ Extended Events — Use Extended Events for lightweight and customizable event monitoring. Create custom
event sessions to capture specific events, performance metrics and diagnostic information. Compared to SQL
Server Profiler, Extended Events offer lower overhead and more event filtering and analysis flexibility.

▪ Performance Monitor (PerfMon) — Use PerfMon to monitor SQL Server performance metrics such as CPU
usage, memory utilization, disk I/O and network activity. Create data collector sets to collect performance
counters over time and analyze performance trends. Monitor key performance indicators (KPIs) to identify
performance issues and resource bottlenecks proactively.

▪ Third-party monitoring tools — Consider using third-party monitoring tools specifically designed for SQL
Server monitoring and management. These tools offer comprehensive monitoring capabilities, customizable
dashboards, alerting mechanisms and performance analysis features.

In addition, configure alerts and notifications to proactively notify administrators about critical events, performance
issues and system failures. You can use SQL Server Agent alerts, Database Mail or external monitoring systems to
send alerts via email, SMS or other communication channels.

Mitigate the Risk of SQL Server

Concurrency Issues
Concurrency issues in SQL Server include deadlocks and blocking. Deadlocks occur when two or more transactions
wait for each other to release resources, so none of the transactions can proceed. Blocking occurs when one
transaction holds a lock on a resource, preventing other transactions from accessing or modifying it.

The following strategies can help mitigate the risk of these issues:

▪ Minimize transaction duration by breaking down long-running transactions into smaller units to reduce the
likelihood of deadlocks.

▪ Use proper indexing and query optimization. These options can significantly reduce contention and
improve concurrency by minimizing the time and resources required for query execution. Analyze query
execution plans, identify performance bottlenecks, and optimize queries and indexes accordingly.

▪ Implement retry logic in applications to handle deadlock errors gracefully.

▪ Identify and monitor blocking chains using DMVs like sys.dm_exec_requests and sys.dm_tran_locks, and
optimize queries and indexes to minimize the duration and scope of locks.
 ▪ Using locking hints (e.g., ROWLOCK, READPAST) to control locking behavior.

▪ Implement row versioning techniques such as snapshot isolation or Read Committed Snapshot Isolation (RCSI).

▪ Choose the appropriate isolation level ((e.g., READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ,
SERIALIZABLE) based on the application requirements and sensitivity to concurrency issues.

▪ Use optimistic concurrency control mechanisms, such as row versioning, optimistic locking and timestamp-
based concurrency, to reduce contention and improve scalability.

▪ Design applications with concurrency in mind, considering factors such as transaction boundaries, data
access patterns and error handling.

To identify and troubleshoot concurrency issues, monitor SQL Server performance metrics like locks, blocking and
deadlock events using tools like SQL Server Profiler, Extended Events and performance monitoring dashboards.

Baseline SQL Activity and Watch

for Deviations
Establish a baseline of normal behavior for your SQL Server instance, including CPU usage, memory utilization, disk
I/O, locking and blocking events, query execution times, and other relevant performance indicators. Monitor these
metrics to capture typical usage patterns and performance characteristics under normal operating conditions
and establish threshold values. Be sure to periodically update the baselines and threshold values to account for
changes in workload patterns, system configuration or database schema modifications.

Implement anomaly detection rules to identify deviations from the baselines. This can include simple threshold-
based alerts or more advanced statistical methods for anomaly detection. Then investigate the root causes of the
deviations, which can include attacks, resource contention and application issues.
Audit Access Attempts and Changes
to Access Permissions
Enable login auditing in SQL Server and monitor the SQL Server error logs for information about failed and
successful login attempts, as well as changes and deletions of database objects containing restricted data.

In addition, track changes to SQL Server configurations and permissions so you can spot and remediate unwanted
changes before you suffer significant damage. This tracking can be done using SQL traces or third-party software
like Netwrix Auditor for SQL Server.

Enable SQL Server Audit

Enable the SQL Server Audit feature of SQL Server and specify the events to be audited, such as SELECT, INSERT,
UPDATE, DELETE and EXECUTE. Configure audit log filtering to capture relevant events and minimize the volume
of audit data generated.

For more granular information, use SQL Server Audit to capture database level events such as data access, schema
changes and object modifications.

Mitigate SQL Injection Risks

SQL injection is a technique in which an attacker injects malicious SQL code into an application’s input fields,
forms or queries. As a result, they can steal or modify data, alter database schemas, execute resource-intensive
SQL queries that overload the database server, deface websites, and hijack user sessions.
The following techniques can reduce the risk of SQL injection attacks in your applications and databases:

▪ Use parameterized queries — Instead of dynamically constructing SQL queries by concatenating user
input, use parameterized queries or prepared statements provided by your programming language or ORM
framework. Parameterized queries separate SQL code from user input, preventing attackers from injecting
malicious SQL code.

▪ Require input validation — Validate and sanitize all user-supplied input before using it in SQL queries. Reject input
that contains unexpected characters or patterns, such as SQL keywords, special characters or escape sequences.
Use whitelisting rather than blacklisting to validate input, as it’s more robust against evasion techniques.

▪ Parameterize APIs — If you are using APIs to interact with the database, ensure that API parameters
are adequately validated and parameterized to prevent SQL injection attacks. Apply input validation and
parameterization techniques at the API and database levels.

▪ Use stored procedures — Utilize stored procedures to encapsulate database operations. This helps prevent
SQL injection by ensuring user input is treated as data, not executable SQL code.

▪ Escape special characters — If parameterized queries or prepared statements are not feasible, ensure that
special characters in user input are correctly escaped before being included in SQL queries. Use database-
specific escape functions or libraries to handle special characters safely.

▪ Conduct security testing — Conduct regular security assessments, including code reviews, vulnerability scans
and penetration testing, to identify potential injection points and validate input sanitization mechanisms.

Minimize the Risk of Side-Channel Attacks

In a side-channel attack, an adversary attempts to gather information or influence the execution of a system
by measuring or exploiting its indirect effects, rather than targeting the system. Below are some strategies to
mitigate the risk of side-channel attacks.

▪ Use well-established cryptographic algorithms and protocols that have undergone rigorous analysis and
scrutiny and come from reputable sources such as NIST or IETF. Avoid custom cryptographic implementations.

▪ Protect cryptographic keys from unauthorized access or disclosure. Use hardware security modules (HSMs)
or trusted execution environments (TEEs) to generate, store and use cryptographic keys securely. Regularly
rotate encryption keys and revoke compromised keys to mitigate the impact of key leakage.
 ▪ Use a defense-in-depth approach that combines cryptographic protections with other security measures
such as access controls, network segmentation and intrusion detection systems.

▪ Use secure memory allocation and deallocation techniques to prevent memory-related side-channel
attacks such as memory scraping or timing attacks. Avoid storing sensitive data in memory for longer than
necessary and securely wipe memory buffers afterward.

▪ Mitigate the risk of timing side-channel attacks. Implement constant-time algorithms and data structures.
Avoid branching or conditional statements that can leak information through timing discrepancies. Use
performance counters or timing-resistant functions to ensure consistent execution time regardless of input
or conditions.

▪ Implement secure error-handling mechanisms to avoid leaking sensitive information through error
messages or exception handling. Use generic error messages that do not reveal details about the internal
state or operation of the system.

▪ Conduct regular security assessments to identify side-channel vulnerabilities. In addition to performing

code reviews, penetration testing and vulnerability scanning, use tools and techniques specifically designed
to detect timing, power consumption and electromagnetic emanation leaks.

Use Encryption Wisely

Encrypting data helps keep it secure even if unauthorized users access it, but encryption and decryption operations
can introduce overhead and impact database performance. Evaluate the performance impact of encryption on
your workload and optimize queries, indexes and server configurations to mitigate performance bottlenecks.

You can use several encryption features in SQL Server to protect your data:

▪ Transparent data encryption (TDE) — TDE encrypts database files on disk, so it requires minimal changes to
applications and queries. However, it does not protect data in memory or during transmission.

▪ SQL column-level protection — The Always Encrypted option allows you to encrypt individual columns
containing sensitive data, such as credit card details or Social Security numbers, while still allowing the
database users to perform operations on the data. The data is encrypted in client applications before being
sent to SQL Server and decrypted in the application after retrieval from SQL Server, ensuring the data remains
encrypted both at rest and in transit.
 ▪ SQL row-level protection — Row-level security (RLS) enables you to define security policies that specify which
rows users can access based on user attributes, session context or other criteria, allowing fine-grained control
over row-level access. You can also create indexes on a subset of rows in a table that meet specified filter
criteria. SQL table views can also implement row level security by limiting the rows returned to users based on
their permissions. Triggers can enforce row-level security by intercepting data modification operations (e.g.,
INSERT, UPDATE, DELETE) and applying custom security logic.

Use Data Masking Techniques

SQL Server provides several data masking techniques to obfuscate sensitive information while preserving data
integrity and usability for non-production environments. These techniques help prevent unauthorized access to
sensitive data during development, testing or troubleshooting activities.

The following are some common data masking techniques in SQL Server:

▪ Dynamic data masking (DDM) masks sensitive data in real time based on user permissions without modifying
the underlying data.

▪ Static data masking permanently obfuscates sensitive data in non-production environments while preserving
data relationships and characteristics. Static data masking can be applied to entire databases, specific tables
or individual columns.

▪ Hashing involves transforming sensitive data into irreversible hashed values using cryptographic hash
functions such as SHA-256 or MD5. Hashing masks sensitive data by converting it into a fixed-length string
that cannot be reversed to obtain the original value. While hashing helps protect passwords and other one-
way encrypted data, it is unsuitable for preserving data usability in all scenarios.

▪ Subsetting involves extracting a subset of data from a production database for non-production environments.
During data extraction, you can use subsetting techniques to mask sensitive data by excluding or obfuscating
specific rows or columns.

▪ Tokenization replaces sensitive data with randomly generated tokens or placeholders while storing the
original data in a secure vault. Tokenization allows you to preserve data relationships and usability while
masking sensitive information. Tokenization is commonly used in payment processing and other applications
where data security in SQL and compliance are critical.
 ▪ Format-preserving encryption encrypts sensitive data while preserving its original format, such as
maintaining the same data type, length and structure. FPE ensures that the masked data remains compatible
with existing applications and databases without requiring extensive modifications. FPE techniques can
encrypt credit card numbers, Social Security numbers and other structured data elements.

Choose Effective SQL Security Tools

For help in evaluating and improving the security posture of your SQL Server environment, consider the following
Microsoft tools:

▪ Assessment and Planning Toolkit (MAP) is a free tool that helps organizations assess their SQL Server
environment’s readiness for migration, identify security vulnerabilities and generate reports with actionable
recommendations. The assessment reports cover SQL Server versions, security configurations and compliance
with best practices.

▪ Secure Score for SQL Server is a feature of Microsoft Defender for SQL Server (formerly SQL Advanced Threat
Protection). It analyzes SQL Server configurations, security settings and user permissions to identify potential
security risks and provides actionable recommendations for improving security posture.

▪ SQL Server Vulnerability Assessment (SSVA) is a feature of SQL Server Management Studio (SSMS) that helps
identify security vulnerabilities in SQL Server databases. It performs automated checks against a predefined
set of security best practices and recommendations, and provides detailed findings and remediation steps.

In addition, consider the following third-party solutions:

▪ DbDefence for SQL Server helps organizations assess and improve SQL database security by encrypting data
at rest, controlling access to sensitive data, and auditing user activity.

▪ Idera SQL Compliance Manager monitors Microsoft SQL security, activity analyzes security events and
generates reports to help organizations ensure compliance with regulatory requirements such as GDPR,
HIPAA, and PCI DSS.

▪ Imperva SecureSphere Database Assessment scans SQL Server databases for vulnerabilities, misconfigurations,
and access control issues. It provides actionable recommendations for improving security and compliance with
industry standards and regulations.
▪ Nessus is a widely used vulnerability assessment tool that scans security SQL Server instances for known
vulnerabilities, misconfigurations, and other security weaknesses and provides detailed remediation
recommendations.

▪ Netwrix Auditor for SQL Server provides actionable intelligence about your Microsoft SQL Server, including
who has access to what, who’s logging in and what critical changes are being made.
Strengthen database security
with Netwrix Auditor for SQL
Server
Proactively investigate and remediate unwanted or malicious
actions before they affect your business.

Quickly sort through the SQL Server audit trail and fine-tune
your search criteria until you find the information you need.

Discover high-risk user accounts inside your SQL Server and

other critical systems with the Behavior Anomaly Discovery tool.

Identify and revoke excessive permissions to reduce the risk of

a breach — and pass audits with fewer findings.

Download 20-Day Free Trial

About Netwrix
Netwrix empowers security professionals to face digital threats with confidence by enabling them to identify and
protect sensitive data as well as to detect, respond to, and recover from attacks. More than 13,500 organizations
across 100+ countries rely on Netwrix solutions to strengthen their security and compliance posture across all
three primary attack vectors: data, identity, and infrastructure. By reducing the cybersecurity burden with Netwrix,
organizations concentrate on advancing their cause while reducing cyber risk.

For more information, visit www.netwrix.com

Next Steps

Netwrix products — Check out the full portfolio of Netwrix products: netwrix.com/products

Live demo — Take a product tour with a Netwrix expert: netwrix.com/livedemo

Request quote — Receive pricing information: netwrix.com/buy

CORPORATE HEADQUARTER: PHONES: OTHER LOCATIONS: SOCIAL:

6160 Warren Parkway, Suite 1-949-407-5125 Spain: +34 911 982608

100 Frisco, TX, US 75034 Toll-free (USA): 888-638-9749 Netherlands: +31 858 887 804
Sweden: +46 8 525 03487
Switzerland: +41 43 508 3472
5 New Street Square, London +44 (0) 203 588 3023 France: +33 9 75 18 11 19 netwrix.com/social
EC4A 3TW Germany: +49 711 899 89 187
Hong Kong: +852 5808 1306
Italy: +39 02 947 53539