Restrict Access to Your SQL Server Data Using a Facade Database

how many times have you felt the need to grant restricted access to your sql server databases to external users and felt unsafe about doing it? external users might be downstream consumers of your data or a team under the same organization that needs access to your database for their apps/databases to work. what if the external users try to hack into your database and read data that they're not supposed to, or even worse gain write access to it? what if they destroy/damage your data?

this post describes a method to create a facade database to provide restricted access to specific tables in your databases to specific users without granting direct access to any of the underlying databases/tables. sql server provides a feature called cross-database ownership chaining that can help us achieve this. the examples provided in this article have been developed and tested on a sql server 2008 r2 server. this feature is supported in older versions of sql server too, but we'll limit the discussion to the following versions:

• sql server 2005
• sql server 2008
• sql server 2008 r2
• sql server 2012
• sql server 2014

ownership chaining

when a script accesses multiple database objects sequentially, the sequence is known as a chain. although such chains do not independently exist, when sql server traverses the links in a chain, it evaluates permissions on the constituent objects differently than it would if it were accessing the objects separately. these differences have important implications for managing access and security.

when an object is accessed through a chain, sql server first compares the owner of the object to the owner of the calling object. if both objects have the same owner, permissions on the referenced object are not evaluated.

cross database ownership chaining

sql server can be configured to allow ownership chaining between specific databases or across all databases inside a single server of sql server. cross-database ownership chaining is disabled by default and should not be enabled unless it is specifically required. to make cross-database ownership chaining work, the databases involved must have a common owner.

server-level vs. database-level

cross-database chaining can be enabled at the server-level or at the individual database-levels. enabling it at the server-level makes cross-database ownership chaining work across all databases on the server, regardless of individual settings of the database. if the requirement is to enable it only for a few databases, then you should enable it at the database-level.

server-level cross-database ownership chaining

to enable server-level cross-database ownership chaining, use the following t-sql statements.

execute sp_configure 'show advanced', 1
go
reconfigure
go

execute sp_configure 'cross db ownership chaining', 1
go
reconfigure
go

to check if it is enabled already, use this query:

select [name], value  
from [sys].configurations 
where [name] = 'cross db ownership chaining';

a value of one indicates that it is already enabled.

database-level cross-database ownership chaining

to enable database-level cross-database ownership chaining, use the following t-sql statements.

alter database mydatabase set db_chaining on
go

to check if it already enabled at the individual database-level, run:

select name, is_db_chaining_on from sys.databases
go

preparing the primary db

let me illustrate this with an example. create a database named customerdb. then, create a table named customers and insert some test data

create table [dbo].[customers](
    [customerid] [int] identity(1,1) not null,
    [customername] [varchar](50) not null,
    [address] [varchar](500) not null,
    [city] [varchar](50) not null,
    [country] [varchar](50) not null,
 constraint [pk_customers] primary key clustered 
(
    [customerid] asc
)with (pad_index  = off, statistics_norecompute  = off, ignore_dup_key = off, allow_row_locks  = on, allow_page_locks  = on) on [primary]
) on [primary]

insert into customers ([customerid], [customername], [address], [city], [country]) values (1, 'michael douglas', 'la home', 'los angeles', 'us')
insert into customers ([customerid], [customername], [address], [city], [country]) values (2, 'al pacino', 'ny home', 'new york', 'us')
insert into customers ([customerid], [customername], [address], [city], [country]) values (3, 'james cameroon', 'nj home', 'new jersey', 'us')

creating the facade db

create a database named facadedb (or any other name for that matter).

creating views

create views for each table in the primary db that you wish to grant access to the restricted user.

create view [dbo].[customerview] as select * from customerdb.dbo.customers

your object explorer should look like this now:

creating login and users to streamline access

create the restricted user login and its associated users in the databases. the user must be added to the primary database as "public." otherwise, ownership chaining will not work. the user must have at least a "db_datareader" role on the facade database.

create login [facadeuser] with password=n'facadeuser', default_database=[facadedb], 
            default_language=[us_english], check_expiration=off, check_policy=off
go

use [customerdb]
go
create user [facadeuser] for login [facadeuser] with default_schema=[dbo]
go

use [facadedb]
go
create user [facadeuser] for login [facadeuser] with default_schema=[dbo]
go
exec sp_addrolemember n'db_datareader', n'facadeuser'
go

turning on database ownership chaining on both the databases

alter database customerdb set db_chaining on
go
alter database facadedb set db_chaining on
go

testing

log in to the server as the restricted user (facadeuser) and execute the following commands.

select * from customerview

you should be able to see the rows of the underlying table.

now, try querying the underlying table directly.

select * from customerdb.dbo.customers

you should see this error:

the select permission was denied on the object 'customers', database 'customerdb', schema 'dbo'.

conclusion

if you followed the above steps, you should have a working setup where a restricted user can query the facadedb and view the results, but they cannot query the underlying tables in the customerdb.

this post is a mirror of my original article posted in my blog