When a managed security service provider (MSSP) centralizes cyber alerts for dozens of companies, it becomes the de facto number one target for hackers. Consolidating incidents, indicators of compromise (IOCs) and user data from 50 customers into a single system (SIEM or SOAR) is a balancing act.
Absolute risk? Inter-client data leak. Whether caused by an interface bug or malicious exploitation of an API, exposing Client A's data to the analyst in charge of Client B is serious professional misconduct. To counter this risk, the industry is abandoning classic application partitioning in favor ofRow-Level Security (RLS).
The vulnerability of “Application Partitioning”
In 90% of traditional SaaS applications (and ticketing tools not specialized in cybersecurity), the database is a large shared tank where the incidents of all customers are mixed in a giant table (e.g.:Table_Tickets).
To separate the data, the application uses “application partitioning”. The developer writes a rule in the source code of the web interface, such as:
Si l'utilisateur appartient à l'entreprise A, alors affiche uniquement les tickets où ClientID = A.
The problem with this approach is that it is incredibly fragile. If a developer forgets to include this filter clause in a new update, or if an attacker manages to forge a direct API request by modifying the HTTP parameters, the backend will naively return the entire database, causing a massive leak.
The PostgreSQL revolution: Row-Level Security (RLS)
For critical infrastructures like Akuity SOC, trusting the interface code (Frontend or Middleware) is not enough. Security must be applied at the deepest level: the database engine itself.
THERow-Level Security (RLS)is a native PostgreSQL mechanism. Instead of filtering the displayAfterAfter extracting the data, the RLS physically prevents unauthorized data extraction, row by row.
How does it work in practice?
- Cryptographic validation:During a query, the database receives the analyst's security token (the JWT generated by the authentication).
- Secure identification:PostgreSQL extracts user identity (
auth.uid()) directly from this cryptographically signed token. - The impassable wall:An RLS rule is triggered. It states that the user cannot read the table row
Ticketsonly if this line is attached to a Tenant who is himself attached to his “Workspace”.
Why is this the absolute standard (SOC 2 / NIS 2)?
Even if an attacker managed to find a flaw in the Akuity SOC API or if a developer sent a malicious SQL query likeSELECT * FROM Tickets;, the database would refuse to run globally. It would query the RLS, check the attacker's token, and only returnthatthe data to which this token is explicitly entitled. Inter-client data leakage becomes mathematically and physically impossible.
Performance and Indexing
Filtering every row in a database containing millions of security logs could slow down the system. This is why a well-designed RLS architecture must be associated with precise performance indexes. In Akuity, the partitioning keys (idxticketstenant,idxprofilsworkspace) ensure that queries are resolved in milliseconds, providing a real-time “Cockpit” without ever sacrificing security.
Conclusion: No longer leave your customers to chance
As an MSSP, you are responsible for your customers' sensitive data (Entra ID usernames, server names, attack vectors). You cannot base your legal compliance (GDPR, NIS 2) on a simple application code filter. Require database-grade waterproofing.
Ready to secure your operations center?> Find out how ourMulti-Tenant SOC Platform for MSSPuses PostgreSQL RLS to ensure strict separation of your customers' data.