Row Level Security
The need for row level security stems from the demand for fine-grained security to the data. As the applications are generating vast amounts of data by the day. Application developers are in need of making sure that the data is accessible to the right audience based on the right access level settings.
Even today, whenever an application was built, the application development team used to spend a lot of time researching the approach, implementing multiple tables multiple logics 25 queries to add filters to manage the data security for every query that gets transferred from the end user request to the application database.
This approach requires a lot of thought process, testing and security review because the queries needs to be intercepted, updated and the data retrieval to be validated to make sure the end-users see only the data that they are entitled to.
Implementation
With the advent of of row level security feature being rolled out in main databases like postgreSQL, the logic of enforcing various policies to restrict the data that is being queried by a user is largely handed over or to the database where we have the users, policies which are defined and applied to the table level so that the enforcement happens on every execution of query be it as select, read, update or Delete query.
In this post we will take a look at how A Row Level Security implementation can be done with the control given to the tenants in case of a multi tenant SaaS product. This process involves building tables and services that might be called as an entity level permissions or entity permissions which acts as a container for storing the tenant the user the role entity and permission that are available for any user with regards to the crud operations.
Entity Record Level Security
However in case of building and application that in was very fine grained access individual records in a business object or a domain object be like a customer, product, this can be achieved by having the IDs provided along with the permissions which work at record level so this data can be internally used to create policies or update policies against the target database server like postgreSQL data filtering is automatically happening the alongside having configurable and very flexible mechanism that can be provided to the administrators of the application through the UI which makes application development lot more easier and customizable.
Alternative approach
As an alternative approach to the above image which shows keeping track of the record identifiers for each entity in a single row, in order to implement security, we could have a separate table that have all the identifiers in individual rows for every entity alongside that having the permissions define so that would enable us to have a very large volume of data being mapped to multiple users for accessing them for performing crud operations
Hope this helps
Comments
Post a Comment