Note: My background is in web based solutions. This question is about the highest possible security for a user directly running an app with direct postgreSQL/MSSQL access.
Lets say you have a windows application (VBA macro, vb6, c#, etc) that communicates directly with MS SQL using windows authentication (or direct access to psotgreSQL using ODBC drivers).
Lets say there are 500 users and 100 tables.
Many of those tables contain sensitive information that can only be read by the user who the record/row belongs to.
Is there a clean easy way to get this done? Id imagine a DBA would need to write many queries to put in policies for each table with specific access? For example something in the spirit of 'CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user);' so a manager can only select rows belonging to them?
Is this the correct way to handle these situations? Seems like a messy situation. Especially if you have the permissions in another table (ex: tblClient has a 1 to many relationship with tblUsersWhoCanWorkOnClients that determines if the user should even be allowed to read any specific row in table client). Wouldn't those type of situations cause slower queries the more complex the policies you create?
Lets say you have a windows application (VBA macro, vb6, c#, etc) that communicates directly with MS SQL using windows authentication (or direct access to psotgreSQL using ODBC drivers).
Lets say there are 500 users and 100 tables.
Many of those tables contain sensitive information that can only be read by the user who the record/row belongs to.
Is there a clean easy way to get this done? Id imagine a DBA would need to write many queries to put in policies for each table with specific access? For example something in the spirit of 'CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user);' so a manager can only select rows belonging to them?
Is this the correct way to handle these situations? Seems like a messy situation. Especially if you have the permissions in another table (ex: tblClient has a 1 to many relationship with tblUsersWhoCanWorkOnClients that determines if the user should even be allowed to read any specific row in table client). Wouldn't those type of situations cause slower queries the more complex the policies you create?
