(RLS) for SQL Database is now generally available. RLS enables you to store data for many users in a single database and table, while at the same time restricting row-level access based on a user's identity, role, or execution context. RLS centralizes access logic within the database itself, which simplifies and reduces the risk of error in your application code.
RLS can help customers develop secure applications for a variety of scenarios. For instance:
As a concrete example, we'd like to highlight how K2 Appit
is leveraging RLS today to ensure isolation of individual users' data:
Before the advent of RLS, we would have had to meet this requirement via diligent use of query predicates, but this mode of security enforcement is onerous and prone to bugs. By using RLS, we were able to accelerate our development while ensuring the policy-based management applies across all database-access vectors. Furthermore, the data access layer and business logic are able to evolve independently from the RLS policy logic; this separation of concerns improves code quality. The developers could use a policy language they were familiar with – T-SQL – and as such we were productive on RLS from day one.
Ultimately, being able to state that row-level security is taken care of by Azure SQL Database itself gives both the customer and our teams confidence in how we protect our customers’ data.
- Grant Dickinson, Architect, K2
Thanks to valuable input from our preview customers, we've incorporated a significant amount of customer feedback into this first version of RLS. We're continuing this iterative process, too, so stay tuned for future announcements on new RLS capabilities. If you have any feedback or questions for our team, please leave us a comment below.
Lots of customers are using RLS today, and we encourage you to try it, too. To get started, check out our MSDN documentation
. You can also find additional demos, tips, and tricks in this introductory post
, Channel9 video
, and on our SQL Security Blog