Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Row level security


Published on

Row level security

Published in: Data & Analytics
  • Be the first to comment

  • Be the first to like this

Row level security

  1. 1. Row Level Security
  2. 2. Team Antonios Chatzipavlis SQL Server Evangelist • Trainer Vassilis Ioannidis SQL Server Expert • Trainer Fivi Panopoulou System Engineer • Speaker Sotiris Karras System Engineer • Speaker
  3. 3. Followus insocialmedia @sqlschool /@SotKarras fb/sqlschoolgr yt/c/SqlschoolGr SQL School Greece group
  4. 4. Helpneeded?
  5. 5. Presentation Content  Overview  Setting up RLS  Filter Predicates  Blocking Predicates  Best Practices  Considerations and Limitations
  6. 6.  First introduced in Azure SQL, in January 2015.  Row Level Security(RLS) enables the implementation of restrictions on data row access.  Row level security introduces predicate based access control where the predicate is used as a criterion to determine whether or not the user has the appropriate access to the data.  The predicate can be anything from the characteristics of the user executing the query (role membership, execution context) to complex business logic involving multiple tables of the database to SQL Server metadata.  The enforcement logic lies inside the database and schema is bound to the table. Overview
  7. 7. Overview Fine-grained access control Application transparency RLS works transparently at query time, no app changes needed Compatible with RLS in other leading products Centralized security logic Enforcement logic resides inside database and is schema-bound to the table it protects providing greater security. Reduced application maintenance and complexity Store data intended for many consumers in a single database/table while at the same time restricting row-level read and write access based on users’ execution context.
  8. 8. Setting Up RLS  Predicate Function  Security Predicates  Security Policies
  9. 9. Predicate function  User-defined inline table-valued function (iTVF) implementing security logic.  Schema bound to the table so that no changes can be done to the security policy under the hood.  Can be arbitrarily complicated, containing joins with other tables.  Performance wise, predicate functions get optimized to provide comparable performance to views, as if the logic were directly embedded in the original query statement.  Still, the more complex the security logic gets, the heavier the performance impact may get. Predicate Function
  10. 10. Security Predicate  Binds a predicate function to a particular table, applying it for all queries.  Two types of predicates: filter predicates and blocking predicates (more on that in a bit). Security Predicate
  11. 11. Security policy  Collection of security predicates for managing security across multiple tables.  Can be turned on and off at will (STATE = ON|OFF).  Can be created either by using SCHEMABINDING or not. The recommended (and default) practice is with SCHEMABINDING on.  Attempts to alter the columns of a table referenced by a schema bound security policy will result in an error. However, columns not referenced by the predicate can be altered.  Attempts to add a predicate on a table that already has one defined for the specified operation (regardless of whether it is enabled or disabled) results in an error.  Defining multiple active security policies that contain non-overlapping predicates, succeeds. Security Policy
  12. 12. Filter Predicates
  13. 13.  Filter predicates are applied while reading data from the base table, and it affects all get operations.  SELECT statements.  DELETE statements (i.e. user cannot delete rows that are filtered).  UPDATE statements (i.e. user cannot update rows that are filtered, although it is possible to update rows in such way that they will be subsequently filtered).  A filter predicate will silently filter out the rows that fail to pass the security predicate.  That means that no error message will be returned to the user if he tries to update or delete rows that he is not allowed to.  The application can INSERT any rows, regardless of whether or not they will be filtered during any other operation.  If the dbo user, a member of the db_owner role, or the table owner queries against a table that has a security policy defined and enabled the rows are filtered/restricted as defined by the security policy. Filter Predicates
  14. 14. RLS and Filter predicates
  15. 15. Blocking Predicates
  16. 16.  Enforce granular control over write access to data for different users, including scenarios that require separate access logic for INSERT, UPDATE, and DELETE operations.  Blocking predicates affect ALL write operations (inserts/updates/deletes).  Four options to choose from when declaring a blocking predicate:  AFTER INSERT and AFTER UPDATE predicates can prevent users from updating rows to values that violate the predicate.  BEFORE UPDATE predicates can prevent users from updating rows that currently violate the predicate.  BEFORE DELETE predicates can block delete operations.  If none of the above is set then the predicate covers every operation. Blocking Predicates
  17. 17. Putting Everything together
  18. 18. Best Practices
  19. 19.  Create a separate schema for the security objects.  And give permissions to that schema to the security manager.  Additionally the security manager does not require any additional permissions to the underlying tables.  Avoid type conversions in the predicate functions and be very careful of mismatches.  Recursion can be used.  If the recursion is direct the optimizer will detect it and optimize it accordingly.  If the recursion is indirect (e.g. the predicate function uses another function that calls the predicate function) then the optimizer cannot detect the recursion and a performance issue may occur.  Do not rely on SET options, especially session-specific ones.  Keep the security logic as simple as possible to allow easy maintenance and minimal performance degradation. Best Practices
  20. 20. Considerations and Limitations
  21. 21.  DBCC SHOW_STATISTICS will show statistics of unfiltered data.  When using columnstore indexes, it is possible that the optimizer may modify the query plan such that it does not use batch mode, because row-level security applies a function.  Temporal tables are compatible with RLS but the security policy must be applied individually in each table (current and history).  Memory optimized tables are compatible with RLS. The predicate function must be defined using the NATIVE_COMPILATION option.  Partitioned views are compatible with filter predicates but not with blocking predicates.  That means that a partitioned view CANNOT be created on top of a table with a block predicate defined on it.  Security policies can be created on top of indexed views BUT the creation of indexed views on top of tables that have a security policy is prohibited. (row lookups through the inde bypass the policy).  Row-Level security is incompatible with Filestream.  RLS is incompatible with Polybase. Considerations and Limitations