Software And Architecture

There exists a notion that in order to achieve the better security, we should opt for the physical isolation of databases This is not true in reality, we can design using the right patterns so that we can still have the single table which have all the tenant information and still use the row level security pattern to restrict the data access by the tenant. However, this has to be done for a MVP and based on the various parameters, this design is to be revisited and incase of having a tenant that has a very huge volume of data, in that case, we can migrate the tenant data to a separate database. The migration of the data might be taking more time, so there should be a suitable connector that is built so that the tenant filter is applied during the data migration in the appropriate value. The approach of having a single database is not applicable when there are GDPR or other HIPPAA compliances to be enforced.

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 d