This commit is contained in:
Jos de Bruijn
2016-05-26 16:56:22 -07:00
parent 6024a9c315
commit 39f7c70ed9
2 changed files with 7 additions and 6 deletions
@@ -1,6 +1,5 @@
-- Demonstrate Row Level Security
USE master;
GO
@@ -82,6 +81,7 @@ GRANT SELECT ON [Application].Cities TO [Great Lakes Sales];
GRANT SELECT ON [Application].Countries TO [Great Lakes Sales];
GO
-- impersonate the user GreatLakesUser
EXECUTE AS USER = 'GreatLakesUser';
GO
@@ -124,7 +124,7 @@ GO
-- Open the second RLS demo window and follow the instructions there
-- Finally, tidy up (optional)
/*
REVOKE SELECT, UPDATE ON Sales.Customers FROM [Great Lakes Sales];
REVOKE SELECT ON [Application].Cities FROM [Great Lakes Sales];
REVOKE SELECT ON [Application].Countries FROM [Great Lakes Sales];
@@ -151,6 +151,5 @@ GO
DROP LOGIN Website;
GO
USE tempdb;
GO
*/
@@ -49,9 +49,11 @@ To run this sample, you need the following prerequisites.
## Sample details
The sample adds a new table with sensitive data about suppliers. This sensitive data is always encrypted.
The sample enables row-level security in the database, for the table `Sales.Customers`. Users of the database can only see the customers they are allowed to see.
As part of the sample you create an encryption key that is saved locally (where you run SSMS). The client application inserts data into the table. With the sample scripts you will see how the data is encrypted in the table and cannot be viewed, even by a sysadmin, unless you have the encryption key.
The user 'Great Lakes Sales' is allowed to see only the customers in the Great Lakes sales territory.
The Website user, which is used by the Web front-end in this scenario, configures the sales territory, and RLS takes care of the required filtering based on the information provided by the Web app.
<a name=disclaimers></a>