Wenn ein Managed Security Service Provider (MSSP) Cyberwarnungen für Dutzende von Unternehmen zentralisiert, wird er de facto zum Hauptziel für Hacker. Die Konsolidierung von Vorfällen, Kompromittierungsindikatoren (IOCs) und Benutzerdaten von 50 Kunden in einem einzigen System (SIEM oder SOAR) ist ein Balanceakt.
Absolutes Risiko? Datenleck zwischen Kunden. Ganz gleich, ob die Ursache ein Schnittstellenfehler oder die böswillige Ausnutzung einer API ist: Die Weitergabe der Daten von Kunde A an den für Kunde B zuständigen Analysten stellt ein schwerwiegendes berufliches Fehlverhalten dar. Um diesem Risiko entgegenzuwirken, verzichtet die Branche auf die klassische AnwendungspartitionierungSicherheit auf Zeilenebene (RLS).
Die Schwachstelle der „Anwendungspartitionierung“
In 90 % der herkömmlichen SaaS-Anwendungen (und Ticketing-Tools, die nicht auf Cybersicherheit spezialisiert sind) ist die Datenbank ein großer gemeinsamer Tank, in dem die Vorfälle aller Kunden in einer riesigen Tabelle gemischt sind (z. B.:Table_Tickets).
Zur Trennung der Daten nutzt die Anwendung die „Anwendungspartitionierung“. Der Entwickler schreibt eine Regel in den Quellcode der Weboberfläche, wie zum Beispiel:
Si l'utilisateur appartient à l'entreprise A, alors affiche uniquement les tickets où ClientID = A.
Das Problem bei diesem Ansatz ist, dass er unglaublich fragil ist. Wenn ein Entwickler vergisst, diese Filterklausel in ein neues Update aufzunehmen, oder wenn es einem Angreifer gelingt, durch Änderung der HTTP-Parameter eine direkte API-Anfrage zu fälschen, gibt das Backend naiverweise die gesamte Datenbank zurück, was zu einem massiven Leck führt.
Die PostgreSQL-Revolution: Row-Level Security (RLS)
Für kritische Infrastrukturen wie Akuity SOC reicht es nicht aus, dem Schnittstellencode (Frontend oder Middleware) zu vertrauen. Sicherheit muss auf der tiefsten Ebene angewendet werden: der Datenbank-Engine selbst.
DERSicherheit auf Zeilenebene (RLS)ist ein nativer PostgreSQL-Mechanismus. Anstatt die Anzeige zu filternNachNach dem Extrahieren der Daten verhindert das RLS physisch die unbefugte Datenextraktion Zeile für Zeile.
Wie funktioniert es in der Praxis?
- Kryptografische Validierung:Bei einer Abfrage erhält die Datenbank das Sicherheitstoken des Analysten (das durch die Authentifizierung generierte JWT).
- Sichere Identifizierung:PostgreSQL extrahiert die Benutzeridentität (
auth.uid()) direkt von diesem kryptografisch signierten Token. - Die unpassierbare Mauer:Eine RLS-Regel wird ausgelöst. Darin heißt es, dass der Benutzer die Tabellenzeile nicht lesen kann
TicketsNur wenn diese Leitung mit einem Mieter verbunden ist, der selbst mit seinem „Arbeitsbereich“ verbunden ist.
Warum ist dies der absolute Standard (SOC 2 / NIS 2)?
Selbst wenn es einem Angreifer gelingt, einen Fehler in der Akuity SOC-API zu finden oder wenn ein Entwickler eine böswillige SQL-Abfrage wie folgt sendetSELECT * FROM Tickets;, würde die Datenbank die globale Ausführung verweigern. Es würde das RLS abfragen, das Token des Angreifers überprüfen und nur zurückkehrenDasdie Daten, auf die dieser Token ausdrücklich Anspruch hat. Datenlecks zwischen Kunden werden mathematisch und physikalisch unmöglich.
Leistung und Indizierung
Das Filtern jeder Zeile in einer Datenbank mit Millionen von Sicherheitsprotokollen könnte das System verlangsamen. Aus diesem Grund muss eine gut konzipierte RLS-Architektur mit präzisen Leistungsindizes verknüpft sein. In Akuity sind die Partitionierungsschlüssel (idxticketstenant,idxprofilsworkspace) stellen sicher, dass Anfragen in Millisekunden gelöst werden, und stellen so ein Echtzeit-„Cockpit“ bereit, ohne jemals Einbußen bei der Sicherheit hinnehmen zu müssen.
Fazit: Überlassen Sie Ihre Kunden nicht mehr dem Zufall
Als MSSP sind Sie für die sensiblen Daten Ihrer Kunden (Entra-ID-Benutzernamen, Servernamen, Angriffsvektoren) verantwortlich. Sie können Ihre Rechtskonformität (DSGVO, NIS 2) nicht auf einen einfachen Anwendungscodefilter stützen. Erfordern eine Abdichtung in Datenbankqualität.
Sind Sie bereit, Ihr Betriebszentrum zu sichern?> Finden Sie heraus, wie unserMulti-Tenant-SOC-Plattform für MSSPnutzt PostgreSQL RLS, um eine strikte Trennung der Daten Ihrer Kunden sicherzustellen.