Microsoft SQL Server Administration Security David Hoksza http://siret.cz/hoksza
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Microsoft SQL Server Administration
Security
David Hokszahttp://siret.cz/hoksza
Outline
• Server vs Database realm
• Permissions
• Roles
• Schemas
• Endpoints
• Auditing
Security LevelsServer Realm Database Realm
• server/primary principals -entities that can request SQL Server resourceso logins
o server roles
o sys.server_principals
• server securables - resources to which the SQL Server Database Engine authorization system regulates access
• server permissions
• database/secondary principals - entities that can request SQL Server resourceso users
o database roles
o application roles
o sys.database_principals
• database securables -resources to which the SQL Server Database Engine authorization system regulates access
• database permissions
• Login/user identificationo IDo SID (Security ID)
• Users are mapped to logins using SID
Logins
• sys.sysloginso Windows and SQL Server logins
• sys.server_principals
• sys.sql_loginso SQL Server logins
• sp_helplogins
• Login types (Windows principals)o Windows (local/domain) logino SQL Server logino server properties → security
• Password policyo Windows Local Security Policy
CREATE LOGIN myLogin WITH PASSWORD = 'S%V7Vlv3c9Es8' MUST_CHANGE,
DEFAULT_DATABASE = AdventureWorks, CHECK_EXPIRATION= ON, CHECK_POLICY = ON;
CREATE LOGIN [<domainName>\<loginName>] FROM WINDOWS;
• mapping to windows login
ALTER LOGIN …
DROP LOGIN …
LOGINPROPERTY ('loginName', {'isLocked'|'IsExpired'|…}
Users• Automatically created when a login is mapped to
the database (SSMS)
• Can be explicitly created from the database and
mapped to a login (if such a mapping doesn’t exist
yet)
CREATE USER testUser FOR LOGIN testLogin
CREATE USER testUser2 WITHOUT LOGIN
ALTER USER testUser2 WITH LOGIN = testLogin2, DEFAULT_SCHEMA = testSchema
Securables• Server scope
o Endpoint, login, server role, database
• Database scopeo User, database role, assembly, schema, …
• Schema scopeo Type, table, view, function, procedure, …
• https://msdn.microsoft.com/en-
us/library/ms190401.aspx
Granting Permissions
Securables Principals
• resources to which access can be regulated
• divided into a hirerachy of scopes which can be nestedo server
• login, server role, database, endpoint
o database
• user, database role, schema, …
o schema
• type, object (table, view, procedure, …)
• sys.database_principals
• sys.server_principals
{GRANT|DENY|REVOKE} permission [ON [class::]securable] TO principal [WITH GRANT OPTION]
• permissions to database objects need to be explicitly granted to be available to a user
• securable object has permissions that can be granted to a principal using permission statements
Permission types• https://technet.microsoft.com/en-
us/library/ms191291.aspx
• CONTROL
• ALTER
• ALTER ANY [<Server Securable>| <Database Securable>]
• CREATE [<Server Securable>|<Database Securable>|Schema-contained Securable]
• VIEW DEFINITION
• SELECT, UPDATE, INSERT, DELETE, EXECUTE
Permissions• http://social.technet.microsoft.com/wiki/contents/a
rticles/11842.sql-server-database-engine-permission-
posters.aspx
• sys.fn_builtin_permissions(securable_class)o sys.fn_builtin_permissions(DEFAULT)
o sys.fn_builtin_permissions(‘LOGIN’)
• sys.fn_my_permissions(securable, securable_class);o sys.fn_my_permissions(NULL, ‘SERVER’);
o sys.fn_my_permissions(‘DBO’, ‘SCHEMA’);
o sys.fn_my_permissions(‘DBO.TEST’, ‘OBJECT’);
• sys.database_permissionso list of granted permissions in a database
Granting Server Permissions - Examples
GRANT ALTER ANY LOGIN TO testlogin
GRANT ALTER ON LOGIN::[login1] TO [login2]
REVOKE ALTER ON LOGIN::[login1] TO [login2]
GRANT CONTROL SERVER TO testLogin;
GRANT CONTROL SERVER TO testLogin WITH GRANT
OPTION;
REVOKE CREATE ANY DATABASE TO testLogin;
DENY CREATE ANY DATABASE TO testLogin;
Granting Database Permissions - Examples
GRANT EXECUTE ON spTest TO testUser
GRANT CREATE VIEW TO testUser WITH GRANT OPTION
GRANT CREATE TABLE TO testUser
REVOKE CREATE TABLE TO testUser
GRANT INSERT ON OBJECT::t TO testUser1
GRANT SELECT ON t TO Guest
GRANT ALTER ON DATABASE::test ON testUser
Guest user• Special user not existing as a login
• Account which is automatically created when a
database is created
• Granting GUEST access to a database allows
anyone to access the database
GRANT CONNECT TO GUEST
o anybody can access given database
GRANT SELECT ON Sales.Customer TO GUEST
o anybody who connects to the database can query the
Sales.Customer table
Ownership changing
ALTER AUTHORIZATION ON [class_type::]name]
TO principal
o ownership of database-contained entities can be transferred to any database-level principal
o ownership of server-level entities can be transferred only to server-level
principals
Roles• Permissions assigned to roles are inherited by all
members of the role
• Typeso server role
• fixed (predefined),
• flexible (user-defined)
o database role
• fixed (predefined),
• flexible (user-defined)
• Can be nestedo just add a role as a member of another role (see the following slides)
Server Roles
Server Role Rights Given
bulkadmin Can run the BULK INSERT statement
dbcreator Can create, alter, restore, drop databases
diskadmin Can manage the disk files
processadmin Can terminate sessions connecting to the SQL Server
securityadmin Can create logins and grant logins rights to a database. Can also reset passwords and alter the login.
serveradmin Can shut down the SQL Server and alter the instance’s configuration
setupadmin Can add and remove linked servers
sysadmin Can do anything on the server
EXEC master..sp_addsrvrolemember @loginame = ‘testlogin', @rolename = 'securityadmin‘
• sys.server_role_members
User-Defined Server Roles• Since SQL Server 2012
CREATE SERVER ROLE testDBA AUTHORIZATION
testLogin;
ALTER SERVER ROLE testDBA ADD [DROP] MEMBER
testLogin1
GRANT CONTROL SERVER TO testDBA
DENY ALTER ANY LOGIN TO testDBA
Fixed Database Roles
EXEC master..sp_addrolemember 'db_datareader' 'testlogin'
Database Role Rights Given
db_accessadmin Can add or remove access for a login
db_backupoperator Can back up specified database
db_datareader Can read from every table in the database unless the access is explicitly denied
db_datawriter Explicitly grants the user permission to run an UPDATE, DELETE, INSERT statement for the database
db_ddladmin Can run any DDL statement inside the database
db_denydatareader Explicitly prevents the user from reading data
db_denydatawriter Explicitly prevents the user from running UPDATE, DELETE, INSERT statements
db_securityadmin Can manage roles and permissions on objects
db_owner Specifies a database administrator, who can perform any function
public Special database role to which every database user belongs
• sys.database_role_members
Flexible (User-Defined) Database Roles
CRETE ROLE testRole AUTHORIZATION testUser
GRANT EXECUTE ON procName TO testRole
EXEC sp_addrolemember 'testRole', 'testlogin'
ALTER ROLE testRole ADD MEMBER testlogin
EXEC sp_droprolemember 'testRole', 'testlogin‘
ALTER ROLE testRole DROP MEMBER testlogin
sp_helproleo roles in current database
Schemas• allows grouping database objects
o analogy to namespace in .NET
• sys.schemas
• Four-part naming syntaxo Server.Database.DatabaseSchema.DatabaseObject
GRANT CREATE TABLE TO testuser1
GRANT ALTER ON SCHEMA::dbo TO testuser1
REVOKE ALTER ON SCHEMA::dbo TO testuser1
CREATE SCHEMA testscheme1 AUTHORIZATION testuser2
ALTER USER testuser1 WITH DEFAULT_SCHEMA = testscheme1
GRANT ALTER ON SCHEMA::testscheme1 TO testuser1
ALTER AUTHORIZATION ON SCHEMA::testscheme1 TO testuser1
User/Schema separation
Metadata Schemas• INFORMATION_SCHEMA
o ANSI standard metadata views
o TABLES, COLUMNS, TABLE_CONSTRAINTS, VIEWS, …
• syso catalog views
o more SQL Server-specific views
o sys.tables, sys.columns, sys.key_constraints, sys.views
• since 2005 metadata information can be obtain only for objects to which access is granted
• mapping system tables (2000) to system views (>=2005)o sysxxx X sys.xxx
Context Switching• Security context
o login token + user token
o sys.login_token
o sys.user_token
• EXECUTE ASo CALLER
• Default
o ‘user_name’
• running under security context of user_name
o SELF
• running under security context of the user who created the object
o OWNER
• running under security context of the owner
CREATE PROCEDURE proc
WITH EXECUTE AS xxx
AS
EXECUTE AS USER = 'testuser1‘
GO
SELECT USER_NAME(), SUSER_NAME(), USER_ID(), USER_SID(), ORIGINAL_LOGIN()
GO
REVERT
o IMPERSONATE permissions must be granted on the principal specified in the EXECUTE AS statemento TRUSTWORTHY setting on the database needs to be turned on
Ownership Chaining• ownership chain
o object A (e.g. stored procedure) referencing object B (e.g. table) in the same schema
o when accessing A, permissions to B are not checked
• cross-schema ownership chainingo the schemas must have identical owner
• cross-database ownership chainingo ownership of schemas is mapped back to the login levelo cross-database ownership has to be turned on for each of the databases
• ALTER DATABASE db_name SET DB_CHAINING ON• exec sp_dboption ‘db_name' , 'db chaining’‚ ‘TRUE’
o the calling user needs to have access to the target database
• dynamic SQL breaks the chaino EXEC, sp_executesql
Active Sessions• sys.sysprocesses
o client and server processes running on an instance of SQL Server
• sys.dm_exec_connectionso connections established to this instance
of SQL Server and the details of each connection
• sys.dm_exec_sessionso one row per authenticated session on
SQL Server
o includes both connections and internal background processes
• sys.dm_exec_requestso one row for each request executing
within SQL Server
• sys.dm_exec_sql_text(sql_handle)
SELECT *
FROM
sys.dm_exec_requests
CROSS APPLY sys.dm_exec_sql_text(sql_handle)
• sp_who, sp_who2 (undocumented and
officially unsupported)o sp_who ‘ACTIVE’
o sp_who ‘login_name’
o sp_who2 ‘login_name’
o DBCC INPUTBUFFER
• KILL spid
• @@SPID – PID of the actual
session
Endpoints• SQL Server access points
• sys.tcp_endpoints
• sys.dm_exec_connections
CREATE ENDPOINT TestEndpointSTATE = STARTEDAS TCP
(LISTENER_PORT = 2025 ,LISTENER_IP = (195.112.25.134))
FOR TSQL () ;GO
GRANT CONNECT ON ENDPOINT::TestEndpoint TO testLogin
ALTER ENDPOINT TestEndpoint STATE = STOPPED
DROP ENDPOINT TestEndpoint
GRANT CONNECT ON ENDPOINT::[TSQL DEFAULT TCP] TO public
Auditing• Server audit
o auditing server level actions
• Database audito auditing database level actions
CREATE SERVER AUDIT [audit_failed_login]
TO SECURITY_LOG
WITH
( QUEUE_DELAY = 1000
,ON_FAILURE = CONTINUE
)
CREATE SERVER AUDIT SPECIFICATION [audit_failed_login_spec]
FOR SERVER AUDIT [audit_failed_login]
ADD (FAILED_LOGIN_GROUP)
Tasks1. Create two logins and respective users. Verify that one user can
not see the tables of the other user unless being granted the VIEW DEFINITION permission. Also check that this does not grant a user the rights to read the contents of this table (if not granted the SELECT permission).
2. Verify that a user can own more schemas.
3. Find owners of all database’s views, tables and stored procedures exluding objects in sys and INFORMATION_SCHEMA schemas (sys.objects, sys.schemas, sys.database_principals).
4. Find out the number of logged users for each database.
5. Try out cross-database ownership chaining. Create a SP selecting from a table in another database which the callerdoes not have permissions to.
Related Documents
