We have a single SQL Server database for all tenants of a web-application. How can we ensure when a support engineer queries the DB directly via SSMS, they only touch data belonging to one tenant?
The web-application reliably isolates data between tenants as all DB queries have an additional clause added automatically to every query:
WHERE tenantID = @currentUserTenantId.
The support team have a need to query the database directory and sometimes perform changes to the database. How can we ensure someone doesn't forget to add
WHERE tenantID = X when executing a query via SSMS?
Row Level Security (RLS) may be one such solution which would require the support engineer to set the tenantID via SESSION_CONTEXT and reject running the query if no tenantID was specified. Support engineers each have their own SQL User.
Alternatively is there a way, using RLS or otherwise, to ensure that a query ran by a support engineer can only touch a single tenantID? i.e. if they failed to specify
WHERE tenantID = X and a query would return data with multiple values in tenantID, then block the query?
Perhaps an ideal solution would be for support engineers not to be able to run any raw SQL and only run predefined stored procedures maintained by the development team. However we don't have the resources to do this at present.
Similarly, Zendesk/Salesforce have the ability for customers to grant access to their respective support teams. I've also seen other solutions which require the customer to share a code with the support team (say by phone). How might that be implemented to protect queries ran via SSMS?