SysAdmin Magazine

SQL Server:
Security and Order
 SysAdmin Magazine May 2019

SysAdmin Contents
Magazine

48
03 6 SQL Server security basics every database admin should know
May ‘19
№
06 How to implement row and column level security in SQL Server

09 Everything you want to know about SQL Server encryption

SysAdmin Magazine is a free
source of knowledge for IT Pros
11 How to enable audit in SQL Server
who are eager to keep a tight
grip on network security and do
the job faster. 15 Tool of the month: Free Netwrix Auditor for SQL Server

16 How to find database changes in SQL Server

The Sysadmin Magazine team

sysadmin.magazine@netwrix.com

2
 SysAdmin Magazine May 2019

6 SQL Server 1. SQL Server Authentication vs.

Windows Authentication
2. Server Logins and Roles
Regardless of the authentication method you choose, there

security basics Microsoft SQL Server supports two authentication options:

the security ID (SID) of the corresponding user object.
are two types of login that you configure to SQL instances:
user logins and server logins. I’ll discuss user logins in the next

every database
section. Server logins let users establish a connection to a SQL
•• Windows Authentication relies on Active Directory (AD) Server instance. Each server login is assigned one or more
to authenticate users before they connect to SQL Serv- server roles that enables it to perform specific actions on the

admin should know er. It is the recommended authentication mode because

AD is the best way to manage password policies and user
and group access to applications in your organization.
instance. By default, server logins are assigned the public serv-
er role, which gives basic access to the instance. Other avail-
able roles include bulkadmin, sercurityadmin, dbcreator and
serveradmin.
•• SQL Server Authentication works by storing user-
names and passwords on the database server. It can be
Russell Smith Server logins can be created using T-SQL or the SQL Server
Data Security Expert, IT Consultant used in situations where Active Directory is not available.
Management Studio. When creating a server login, you must
You can use SQL Server and Windows Authentication at the specify a default database. Server logins are associated with
same time (mixed-mode), but, whenever possible, use Win- a user login in the default database. It’s worth noting that a
dows Authentication exclusively. server login name and the name of its associated user login
Too many data breaches are caused by poorly secured da-
don’t need to match. If there is no associated user object in the
tabase servers. Microsoft SQL Server is a popular enterprise
If you must use SQL Server Authentication, make sure that default database, the server login will be denied access unless
solution, but it is also complex to understand and config-
the default sa account is either disabled or has a strong the server role assigned to the login has access to all databas-
ure. Here are 6 SQL Server security features that you should
password that is changed frequently, because this account es. Server logins can be mapped to a user in one or more data-
know to keep your server data protected.
is often targeted by hackers. SQL Server accounts, includ- bases, and you can create users when setting up server logins.
ing sa (if it’s enabled), can be managed using the SQL Serv-
er Management Studio service or the ALTER LOGIN Trans-
act-SQL (T-SQL) command.

3

3. Database Users, Schema and Roles
When creating a user login, you need to specify the data-
base it will be associated with, a username and a default
schema that will be applied to all objects that the user cre-
ates if no other schema is specified. SQL Server schemas
are collections of objects, like tables and views, logically
separated from other database objects, which makes it
easier to manage access and means there is no need to
use the schema name when running T-SQL commands
against a database.
The default schema for user-defined objects is dbo. The
other default schema is sys; it owns all system objects.
In the same way that server logins are assigned server
roles, user logins are assigned database roles, which as-
sign rights in databases. Server database roles include
public, db accessadmin, db owner and db securityadmin.
4. Securables and Permissions
When server or database roles would give a user too much
or too little access, you can assign one or more securables
instead. Securables exist at the server, schema and data-
base levels; they are SQL Server resources that can be ac-
cessed by server and user logins. For example, using se-
4
curables, you could give a server login access to a specific
table or function only, a level of granularity that isn’t possi-
ble by assigning a role to a login.
Permissions are used to grant access to SQL Server se-
curables. You might grant permission to just view data or
just to modify data. The GRANT, DENY and REVOKE T-SQL
statements are used for configuring permissions.
However, permissions can be complicated. For example,
setting DENY permissions on a securable prevents per-
mission inheritance on lower-level objects. But the col-
umn-level GRANT permission overrides DENY at the object
level, so DENY permission set on a table is overridden by
GRANT permission on a column. Because permissions can
be complex, it’s always worth checking effective permis-
sions using T-SQL. The following command determines Jo-
eB’s permissions granted on an object, in this case a table
called ‘employees’.
SELECT * FROM fn_my_permissions('joeb',
employees);
GO
SysAdmin Magazine May 2019
5. Data Encryption
SQL Server supports multiple encryption options:
•• Secure Sockets Layer (SSL) encrypts traffic as it travels
between the server instance and client application, much
like internet traffic is secured between browser and serv-
er. Additionally, the client can validate the server’s identi-
ty using the server’s certificate.
•• Transparent Data Encryption (TDE) encrypts data on
disk. More specifically, it encrypts the entire data and log
files. Client applications don’t need to be changed when
TDE is enabled.
•• Backup Encryption is similar to TDE but encrypts SQL
backups instead of the active data and log files.
•• Column/Cell-Level Encryption makes sure that specif-
ic data is encrypted in the database and remains so even
when it is stored in memory. Data is decrypted using a func-
tion and requires changes to client applications to work.
•• Always Encrypted is an improvement on Column/Cell-Lev-
el Encryption in that it doesn’t require any changes to cli-
ent applications; data stays encrypted over the network, in
memory and on disk. It also protects sensitive data from the
prying eyes of privileged SQL Server users. But you can en-
counter some issues with this encryption option — because
SQL Server can’t read the data, some indexing and func-
tions won’t work.
 SysAdmin Magazine May 2019

6. Row-Level Security
Row-Level Security (RLS) allows organizations to control
who can see rows in a database. For example, you could
restrict users to seeing only rows that contain informa-
tion about their clients.
Free Guide
RLS consists of three main parts: a predicate function,
a security predicate and a security policy. The predicate
function checks whether the user executing the database
query can access a row based on logic. For instance, you
could check if the username of the user running the que- SQL Server
ry matches a field in one of the row’s columns. A predi-
cate function and security predicate are defined together Security Best
Practices
in a function to either silently filter the results of a query
without raising errors or to block with an error if row ac-
cess is denied. Finally, a security policy binds the function
to a table.

Free Download

5
 SysAdmin Magazine May 2019

How to implement Securables, Principals, and

Permissions
SQL Server Column Level Security

row and column Before we can dive into rows and column security, we need to
review some SQL Server security basics. Basically, database
There are two ways to protect columns in SQL Server: col-
umn level permissions and column level encryption. The

level security in security involves allowing someone to access a data stored

in a database and perform actions on it. The “someone” a
great thing for administrators is that these two techniques
can be combined.

SQL Server
principal, the actions they is allowed to take are their permis-
sions, and the data on which the actions are performed is a Column Level Permissions
securable — examples of securables include databases, ta-
Column level permissions provide a more granular level
bles, schemas, rows and columns.
of security for data in your database. You do not need to
execute a separate GRANT or DENY statements for each
Jeff Melnick Let’s take a look at the permissions that can be applied to
column; just name them all in a query:
IT Security Expert, Blogger securables:

SQL Server includes a range of security features. Two of the
most valuable are column level security and row level se-
curity, which enable you to granularly grant users access to
rows and columns in a table. This article explains how to
implement these features in your environment.
•• SELECT — Principals requires this permission to get or
read data from the table.
•• INSERT — Principals need this permission to add new
rows to a table.
•• UPDATE — Principals need this permission to modify
data in a table.
•• DELETE — Principals need this permission to remove
rows from a table.
•• REFERENCES — Principals need this permission to create
a foreign key to a table if they have no other permissions
on the table.
GRANT SELECT ON data1.table (column1, co-
lumn2) TO user1;
GO
DENY SELECT ON data1.table (column3) TO
user1;
GO
If you execute a DENY statement at table level to a column
for a user, and after that you execute a GRANT statement
on the same column, the DENY permission is removed and
the user can have access to that column. Similarly, if you
execute GRANT and then DENY, the DENY permission will
be in force.

6
 SysAdmin Magazine May 2019

Column Level Encryption 1.First, we create the database master key to encrypt our 3. Next, we need to add a column to our table to store en-
symmetric key. This can be done using the CREATE MAS- crypted data.
Column level encryption is a direct encryption of data in a
TER KEY command and the ENCRYPTION BY PASSWORD
column. It requires code changes because it can be applied
argument, which defines the password to encrypt the key: USE DB;
only while programming the database. It is a granular way
GO
of encrypting data so only specific columns, or parts of col-
ALTER TABLE Testtable
umns, can be encrypted. You can even use different en- CREATE MASTER KEY ENCRYPTION BY PASSWORD =
ADD EncryptedColumn varbinary(MAX )NULL
cryption keys for different columns. Column level encryp- 'P@$$w0rd'
GO
tion requires binary columns to store encrypted data. Also, GO

it stores the keys on the server, so SQL database needs to

trust the server that stores the keys.
4. In order to encrypt the table data, we need to open our
2. Then we have to create a symmetric key, but in order
Colum level encryption uses symmetric keys for encrypt- symmetric key and update the table.
to secure it, we should make a digitally signed certificate.
ing the data because that helps maintain productivity, and
To create a certificate, use the CREATE CERTIFICATE com-
each symmetric key is protected by an asymmetric key. OPEN SYMMETRIC KEY SQLSymmetricKey
mand, which will be protected by our master key. Then we
You can use different algorithms for symmetric keys but DECRYPTION BY CERTIFICATE SelfSignedCertifi-
can create a symmetric key using the CREATE SYMMETRIC
AES is the best option. In addition, symmetric keys can also cate;
KEY command and the AES_256 encryption algorithm.
be protected with passwords or master keys.

In order to keep your keys safe, you can use SQL permis- CREATE CERTIFICATE SelfSignedCertificate WITH
5. Once the symmetric key is open, we need to update the table.
sions to limit access to them to only trusted user accounts. SUBJECT = 'Column Encryption';

Another important note is that encrypted data is not in- GO

CREATE SYMMETRIC KEY SQLSymmetricKey
dexable; if you want to index it, you need to decrypt it first. UPDATE Testtable
WITH ALGORITHM = AES_256 SET [EncryptedColumn] = EncryptByKey(Key_
To implement column level encryption, we need to take
ENCRYPTION BY CERTIFICATE SelfSignedCertificate; GUID('SQLSymmetricKey'), ColumnWithSensiti-
the following steps:
GO veData);
GO
select * from Testtable

7

6. The encrypted column has been created; it contains the
encrypted data of the columnwithsensitivedata column. To
achieve our SQL Server security goal, we should drop the
existing plain text columnwithsensitivedata column using
the DROP command and retain only the encrypted column.
SQL Server Row Level Security
Row-level security (RLS) allows developers to control user
access rights to information on a row by row basis; each
user can see only that rows that they have access to. This
security feature has high level set of permissions because
it bypasses existing SQL Server security access lists. It con-
sists of three parts:
•• Predicate function — This is a schema function that
regulates whether a user account executing the query
has access to the row.
•• Security predicate — A security predicate binds a pred-
icate function to the table. There are two types of secu-
rity predicates:
Filter predicate — This limits read operations (SE-
LECT) on the row. This filtering is done silently with-
out any event logs.
8
SysAdmin Magazine May 2019
Block predicate — This limits write operations (IN- 2. Next, we create a security policy by executing the follow-
SERT) on the row. There are four types of BLOCK ing script, which adds the predicate function we just created
predicates: AFTER INSERT, BEFORE UPDATE, AFTER as a filter predicate on our test table.
UPDATE and BEFORE DELETE operations.
CREATE SECURITY POLICY PrivacyPolicy
•• Security policy — This is a collection of security predi- ADD FILTER PREDICATE
cates grouped in a single new object. dbo.NewPredicateFunction(privilegeuser) ON
dbo.testtable
WITH (STATE = ON)
The logic is simple: A predicate function defines whether to
allow or block rows a user can access based on certain pa-
rameters, and then the function is applied to a table with a
That’s all. Our security policy is active in our SQL database
security policy and becomes active. Let’s take a close look to
and will allow users to access only their row while allowing
this process:
the ADMIN account to access all rows.
1. First, we need to create a filter predicate function. For
this example, we will allow access to a row for a user if it is
matches the privilegeuser column of that row or if the user
name is ADMIN.
CREATE FUNCTION dbo.NewPredicateFunction
( @privilegeuser AS SYSNAME )
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS AccessRight
WHERE @privilegeuser = USER_NAME() OR
USER_NAME() = 'ADMIN'
GO
 SysAdmin Magazine May 2019

Everything you
data as it travels across the network, but, unlike most of the TDE, you must back up the certificate and the private key as-
other forms of encryption in SQL Server, SSL is available in all sociated with the certificate. You will need to restore or attach
supported versions of SQL Server and in all editions. the database on a different SQL Server. The tempdb system

want to know Before enabling SSL, you’ll need to install a certificate on the
database is also encrypted if you enable TDE on any other
SQL Server database. If you disable TDE, you should keep the

about SQL Server

SQL Server. The best way to do this is by requesting a certif- certificate and private key because parts of the transaction
icate from your own enterprise Certification Authority (CA). log could remain encrypted until you perform a full backup.
Windows Server can be configured as a CA and you can set

encryption up clients so that they trust the certificates that it issues. A SQL database master key (DMK) is a symmetric key that
protects the private keys of certificates and asymmetric keys
stored in databases. TDE requires a database encryption key

Russell Smith
Data Security Expert, IT Consultant
Microsoft SQL Server supports 5 different kinds of encryp-
tion for protecting data. This article explains each of them
and where they should be used.
SSL Transport Encryption
Like websites that secure traffic between browser and serv-
er, SQL Server can be configured to use Secure Sockets Layer
(SSL) to encrypt traffic as it travels between the server instance
and client application. Additionally, the client can validate the
server’s identity using the server’s certificate. SSL only protects
SQL Server Transparent Data (DEK), which is a symmetric key that is protected using a cer-
tificate stored in the master database or an asymmetric key
Encryption (TDE) protected by Extensible Key Management (EKM), like Micro-
soft Azure Key Vault. Backup files of TDE-enabled databases
Transparent Data Encryption (TDE) in SQL Server protects
are encrypted using the DEK, so during restore operations,
data at rest by encrypting database data and log files on
the certificate protecting the DEK must be available.
disk. It works transparently to client existing applications,
so they don’t need to be changed when TDE is enabled. TDE
Symmetric keys use the same password to encrypt and de-
uses real-time encryption at the page level. Pages are en-
crypt data. Asymmetric keys use one password to encrypt
crypted before they are written to disk, without increasing
data (public key) and a different password to decrypt data
the size of your data and log files, and pages are decrypted
when read into memory. TDE is available only in Enterprise
(private key). You can use the CREATE CERTIFICATE com-
mand to create certificates, and the CREATE SYMMETRIC KEY
editions of SQL Server. It also works for Azure SQL Database,
and CREATE ASYMMETRIC KEY Transact-SQL commands to
Azure SQL Data Warehouse and Parallel Data Warehouse.
create database encryption keys.
SQL Server can generate certificates for use with TDE or you
RIC KEY and CREATE ASYMMETRIC KEY Transact-SQL com-
can request a certificate from a CA. If you decide to enable
mands to create database encryption keys.

9

Backup Encryption
Backup Encryption works like TDE but encrypts SQL back-
ups instead of the active data and log files. Backup En-
cryption is available in SQL Server 2014 and later. You can
specify AES 128, AES 192, AES 256 or Triple DES encryption,
and use either a certificate or asymmetric key stored in
EKM. Additionally, it is possible to enable TDE and Backup
Encryption simultaneously, although you should use dif-
ferent certificates or keys.
Just as with TDE, if you enable Backup Encryption, you
must also back up the certificate or key. Backups can also
be encrypted when using SQL Server Managed Backup to
Microsoft Azure.
It’s worth noting that if you are using a certificate to en-
crypt backups, you must have the original certificate when
restoring data. That means the certificate must have the
same thumbprint as when the backup was created.
Column/Cell-Level Encryption
Available in all editions of SQL Server, cell-level encryption
can be enabled on columns that contain sensitive data. The
data is encrypted on disk and remains encrypted in mem-
ory until the DECRYPTBYKEY function is used to decrypt
10
it. Therefore, although the SQL data is encrypted, it is not
secure beyond simply using a function in the user context
to decrypt it. Additionally, because a function is needed to
decrypt the data, client applications must be modified to
work with cell-level encryption.
Encryption Key Management
As with TDE, you need to create a master key (DMK) before
using cell-level encryption. There are four options for en-
crypting information using cell-level encryption:
•• You can use a passphrase to encrypt and decrypt the
data, but you must encrypt stored procedures and
functions; otherwise, the passphrase can be accessed
in the metadata.
•• Asymmetric keys provide strong security but can have
an impact on performance.
•• Symmetric keys are usually strong enough and provide
a good balance between security and performance.
•• Certificates also provide a good balance between secu-
rity and performance, and they can be associated with
a database user.
SysAdmin Magazine May 2019
Always Encrypted
Always Encrypted encrypts sensitive data in client appli-
cations without revealing the encryption keys to the data-
base engine, providing separation between data owners
and data managers. For example, with Always Encrypted
enabled, you can be sure that your database administra-
tors won’t be able to read sensitive data. As the name sug-
gests, data is encrypted at rest and if used in a third-party
system, such as Azure.
Always Encrypted can be configured for individual data-
base columns. Two kinds of keys are used: column encryp-
tion keys and column master keys. Column encryption
keys protect data in a column and column master keys are
‘key-protecting keys’ that encrypt one or more column en-
cryption keys. Column master keys are stored in external
trusted key stores, like Azure Key Vault.
The encryption process is transparent to client applica-
tions but requires a special driver on client computers. Al-
ways Encrypted is available in SQL Server 2016 and later,
but only in Enterprise editions. Because of the extra cli-
ent-side requirements, Always Encrypted is best suited to
situations in which separation of data owners and manag-
ers is a primary requirement.
 SysAdmin Magazine May 2019

How to enable
•• SQL Trace Common Criteria Compliance is a newer standard that su-
persedes C2 auditing. It was developed by the European
•• Extended Events
Union and can be enabled in Enterprise and Datacenter

audit in SQL Server •• Change Data Capture

•• DML, DDL, and Logon Triggers

editions of SQL Server 2008 R2 and later. But it can cause
performance issues if your server isn’t sufficiently spec’d to
cope with the extra overhead.

This article is for database administrators (DBAs) who are look-

Russell Smith
Data Security Expert, IT Consultant
Auditing Microsoft SQL Server is critical to identifying secu-
rity issues and breaches. In addition, auditing SQL Server
is a requirement for compliance with regulations like PCI
DSS and HIPAA.
The first step is to define what to audit. For example,
you might audit user logins, server configuration, sche-
ma changes and audit data modifications. Next, you have
choose which security auditing features to use. Useful fea-
tures include the following:
•• C2 Auditing
•• Common Compliance Criteria
•• Login Auditing
•• SQL Server Auditing
ing at using C2 auditing, Common Compliance Criteria and
SQL Server Auditing. We will not be looking at any third-party
auditing tools, though they can be of great help, especially for
larger environments and in regulated industries.
Enabling C2 Auditing and Common
Criteria Compliance
If you aren’t currently auditing your SQL Server, the easi-
est place to start is by enabling C2 auditing. C2 auditing is
an internationally accepted standard that can be turned
on in SQL Server. It audits events like user logins, stored
procedures, and the creation and removal of objects. But
it is all or nothing — you can’t choose what it audits, and it
can generate a lot of data. Furthermore, C2 auditing is in
maintenance mode, so it will likely be removed in a future
version of SQL Server.
Here’s how to enable C2 auditing in SQL Server 2017:
1. Open the SQL Server Management Studio.
2. Connect to the database engine for which you want to
enable C2 auditing. In the Connect to Server dialog, make
sure that Server type is set to Database Engine and then
click Connect.
3. In the Object Explorer panel on the left, right-click your
SQL Server instance at the top and select Properties from
the menu.
4. In the Server Properties window, click Security under
Select a page.
5. On the Security page, you can configure login monitor-
ing. By default, only failed logins are recorded. Alternative-
ly, you can audit just successful logins, or both failed and
successful logins.

11

Figure 1. Configuring access auditing
6. Check Enable C2 audit tracing under Options.
7. If you want to enable C2 Common Criteria Compliance
auditing, check Enable Common Criteria compliance.
Common Criteria (CC) Compliance is a flexible standard
that can be implemented with different Evaluation Assur-
ance Levels (EALs), from 1 to 7. Higher EALs have a more
demanding verification process. When you check Enable
12
Common Criteria compliance in SQL Server, you are en-
abling CC Compliance EAL1. It is possible to configure SQL
Server manually for EAL4+.
Enabling CC Compliance changes SQL Server behavior.
For example, table-level DENY permissions will take prece-
dence over column-level GRANTs, and both successful and
failed logins will be audited. In addition, Residual Informa-
tion Protection (RIP) is enabled, which over-writes memory
allocations with a pattern of bits before they are used by a
new resource.
8. Click OK.
9. Based on the selected options, you might be prompt-
ed to restart SQL Server. If you get this message, click OK
in the warning dialog. If you enabled C2 Common Criteria
Compliance, reboot the server. Otherwise, right-click your
SQL Server instance in Object Explorer again and select
Restart from the menu. In the warning dialog, click Yes to
confirm that you want to restart SQL Server.
SysAdmin Magazine May 2019
Enabling SQL Server Audit
SQL Server auditing can be enabled instead of C2 auditing;
you can also choose to enable both. SQL Server Audit ob-
jects can be configured to collect events at the server level
or the SQL Server database level.
Create Server Audit Object
Let’s create a server-level SQL Server audit object:
1. In the Object Explorer panel on the left, expand Security.
2. Right-click Audits and select New Audit… from the menu.
This will create a new SQL Server Audit object for serv-
er-level auditing.
3. In the Create Audit window, give the audit settings a
name in the Audit name field.
4. Specify what should happen if SQL Server auditing fails us-
ing the On Audit Log Failure option. You can choose Continue
or choose to shut down the server or stop database opera-
tions that are audited. If you select Fail operation, database
operations that are not audited will continue to work.

Figure 2. Creating a server-level SQL Server audit object
5. In the Audit destination dropdown menu, you can choose
to write the SQL audit trail to a file or to audit events in
the Windows Security log or Application event log. If you
choose a file, you must specify a path for the file.
Note that if you want to write to the Windows Security
event log, SQL Server will need to be given permission. For
13
SysAdmin Magazine May 2019
the sake of simplicity, select the Application event log. Ad-
ditionally, you can include a filter as part of the audit object
to provide a narrow set of results; filters must be written in
Transact-SQL (T-SQL).
6. Click OK.
7. You will now find the new audit configuration in Object
Explorer below Audits. Right-click the new audit configura-
tion and select Enable Audit from the menu.
Figure 3. Creating a server audit specification for database-lev-
8. Click Close in the Enable Audit dialog.
el auditing
Create Database Audit Object 3. In the Properties window under Actions, use the dropdown
menus to configure one or more audit action types, selecting
To create a SQL Server audit object for database-level audit-
the statements you want to audit (such as DELETE or INSERT),
ing, the process is a little different and you need to create at
the object class on which the action is performed, and so on.
least one server-level audit object first.
4. When you’re done, click OK and then enable the audit ob-
1. Expand Databases in Object Explorer and expand the da-
ject by right-clicking it and selecting Enable Database Audit
tabase on which you want to configure auditing.
Specification.
2. Expand the Security folder, right click Database Audit
Specifications and select New Database Audit Specifica-
tion… from the menu.
 SysAdmin Magazine May 2019

Viewing SQL Server Audit Logs

C2 Audit SQL Server audit logs are stored in the default
data directory of the SQL Server instance. Each log file can
be a maximum of 200 megabytes. A new file is automati-
cally created when the limit is reached.
A native solution that is recommended to view SQL Server
audit logs called Log File Viewer. To use it, take the follow- Quick Reference Guide
ing steps:

SQL Server
1. In SQL Server Management Studio, in the Object Explor-
er panel, expand Security and Audit.

2. Right-click the audit object that you want to view and

select View Audit Logs from the menu.
Auditing
Figure 4. Reviewing SQL Server audit logging in the Log File
3. In the Log File Viewer, the logs will be displayed on the
Viewer
right side. Regardless of whether the logs are written to a Free Download
file or to the Windows Event Log, Log File Viewer will dis-
play the logs.

4. At the top of Log File Viewer, you can click Filter to cus-
tomize which log entries are displayed. SQL Server file logs
are saved in .sqlaudit format and are not readable, so Log
File Explorer allows you to click Export to save logs to a
comma-delimited .log file format.

14
 SysAdmin Magazine May 2019

Freeware that keeps you informed about changes and logons to your Microsoft SQL Server.

Tool of the Month Stay on top of what’s happening inside your database server by detecting logons and changes made to SQL Server objects
and permissions, including server instances, roles, databases, tables, stored procedures and more.

Netwrix Auditor for SQL Server

Activity Summary
Free Community Edition
Removed 1
Modified 1

Netwrix Auditor Successful Logons 1

for SQL Server

Action Object type What Item Where When Workstation

Successful Windows SQL3 sql3 sql3 4/17/2017 atl-mkt021.enterprise.com

Logon logon 3:44:12 AM

Removed Table Databases\HR\Tables\ sql3 sql3 4/17/2017 atl-mkt021.enterprise.com

Download Free Tool dbo.SALARY 3:44:28 AM

Modified Login Security\Logins\ sql3 sql3 4/17/2017 atl-mkt021.enterprise.com

[ENTERPRISE\D.Abraham] 3:44:52 AM

Role Members Added: "Enterprise\D.Abraham"

This message was sent by Netwrix Auditor from au-srv-fin.enterprise.com.

15
 SysAdmin Magazine May 2019

How-to for IT Pro

5. Execute this query in order to view top 1000 rows of
EXEC sp_trace_setevent @TraceID, 128, 35, @ trace data:
on
EXEC @RC = sp_trace_setstatus @TraceID, 1
GO SELECT TOP 1000 [TextData] ,[HostName]
How to find database changes in SQL Server
,[LoginName] ,[StartTime] ,[EndTime] ,[Ser-
verName] ,[EventClass]

1. Run MS SQL Management Studio → Connect to the FROM [DBname].[dbo].[tablename]

WHERE DBname.dbo.tablename.TextData IS NOT
database you want to audit → Click "New Query" → 2. Define the file trace location (marked red) and hit "Ex-
Copy the following code into the "New Query" box: ecute" to start a new trace.

6. Inspect the "TextData" column for the events: CREATE

3. Execute this query to stop the trace when you want to
DECLARE @RC int, @TraceID int, @on BIT DATABASE, DROP DATABASE, ALTER DATABASE in or-
audit data:
EXEC @rc = sp_trace_create @TraceID output, der to know what database was changed. To find out
2, N'C:\path\file' who changed it and when it was changed, refer to the
SELECT RC = @RC, TraceID = @TraceID
sp_trace_setstatus @traceid = 1, @status = 0 "LoginName" and "StartTime" columns respectively.
-- Follow Common SQL trace event list and
common sql trace
-- tables to define which events and table
you want to capture 4. Execute this query in order to import the trace into a
SELECT @on = 1
database table:
EXEC sp_trace_setevent @TraceID, 128, 1, @
on
-- (128-Event Audit Database Management USE DBname
Event, 1-TextData table column) SELECT * INTO tablename FROM ::fn_trace_get-
EXEC sp_trace_setevent @TraceID, 128, 11, @ table('C:\path\file.trc', DEFAULT)
on GO
EXEC sp_trace_setevent @TraceID, 128, 14, @
on

16
 [On-Demand Webinar]

How to Conduct If your server is not properly secured, this critical data is an easy target for hackers as well as disgruntled employees.
To ensure the security and availability of your data, you need to track all changes and detect all failed logon attempts

Effective on your SQL servers.

SQL Server • Who removed records from your SQL database?

Auditing
• What is the name of each removed object?
• When did each modification occur?

Adam Stetson
Systems Engineer, Security Expert Watch Now

Corporate Headquarters: Phone: 1-949-407-5125 Copyright © Netwrix Corporation. All rights reserved. Netwrix is trademark of Netwrix Corporation and/or
300 Spectrum Center Drive, Toll-free: 888-638-9749 one or more of its subsidiaries and may be registered in the U.S. Patent and Trademark Office and in other
Suite 200 Irvine, CA 92618 EMEA: +44 (0) 203-318-02 countries. All other trademarks and registered trademarks are the property of their respective owners.