← Zurück zur Wissensdatenbank← Vorherige FrageNächste Frage →
ProgrammierungSQL-Architekt

Welche Möglichkeiten gibt es, Daten durch Berechtigungen und Rollen in SQL vor unbeabsichtigter oder böswilliger Änderung zu schützen? Was sind die Unterschiede zwischen Zugriffsleveln und wie implementiert man eine mehrstufige Sicherheitsrichtlinie sinnvoll?

Bestehen Sie Vorstellungsgespräche mit dem Hintsage-KI-Assistenten

Antwort.

Der SQL-Server unterstützt ein mehrstufiges Berechtigungssystem durch Rollen, Benutzerrechte (GRANT/REVOKE) und Schemata (Schemas). Wichtige Prinzipien:

  • Weisen Sie eine Rolle zu = Set von Berechtigungen, das der Benutzer später erhält.
  • Geben Sie minimal erforderliche Rechte (Prinzip der minimalen Privilegien).
  • Trennen Sie Berechtigungen auf Datenbank-, Tabellen-, View- und Prozedurebene.
  • Für besonders wichtige Operationen – nur über gespeicherte Prozeduren oder Views verwenden, nicht über direkten Zugriff auf Tabellen.

Beispiel für die Erstellung von Rollen und die Zuweisung von Rechten:

-- Rolle für Analysten erstellen
CREATE ROLE Analyst;
-- Nur SELECT zu den benötigten Tabellen gewähren
GRANT SELECT ON Sales TO Analyst;
-- Modifizierung von Daten verbieten
REVOKE INSERT, UPDATE, DELETE ON Sales FROM Analyst;
-- Rolle einem Benutzer zuweisen
GRANT Analyst TO user_ivan;

Häufig werden Rollen für Lesen (read-only), Modifizieren, Administrieren und für spezielle Operationen unterschieden.

Fangfrage.

Fangfrage: "Kann ein Benutzer, der nur Zugriff auf eine View hat, die zugrunde liegende Tabelle über diese ändern? Geben Sie ein Beispiel an."

Antwort: Ja, wenn die VIEW keine Aggregation/Gruppierung enthält und nicht nur lesezugänglich ist (WITH CHECK OPTION) – können INSERT/UPDATE/DELETE auf der VIEW ausgeführt werden, und die Änderungen gelangen in die zugrunde liegende Tabelle, wenn die Berechtigungen es zulassen.

-- View, die überflüssige Spalten ausschließt
CREATE VIEW SalesAsView AS SELECT id, total, manager_id FROM Sales;
-- Wenn erlaubt, kann der Benutzer Änderungen wie folgt vornehmen:
UPDATE SalesAsView SET total=1000 WHERE id=42;
-- Dies betrifft Sales.total für id=42

Lösung: Nur readonly VIEW verwenden oder Änderungen an Daten über Views verbieten.

Beispiele für reale Fehler aus Unkenntnis der Feinheiten des Themas.

Geschichte

Projekt: HR-Portal, persönliche Daten der Mitarbeiter.

Fehler: Betreiber hatten Zugriff auf die zugrunde liegende Tabelle über VIEW ohne Einschränkung auf UPDATE – änderten versehentlich die Gehälter der anderen, obwohl die VIEW von Anfang an "nur für Berichte" gedacht war.

Geschichte

Projekt: Buchhaltung, externe Integration.

Fehler: Vergaben der externen Systeme Rechte für INSERT und SELECT auf die gesamte DB statt nur für INSERT in die benötigten Tabellen. Ergebnis: Verwundbarkeit zum Lesen der gesamten DB und mögliches Verstoß gegen die Datenschutzgesetze (GDPR).

Geschichte

Projekt: SaaS-Plattform, Multi-User-Berichte.

Fehler: Alle Kunden arbeiteten in einem Schema mit gemeinsamen Rechten: sahen versehentlich und konnten die Daten anderer bearbeiten. Lösung – Aufteilung in Schemata, separate Rollen und eigene Einschränkungen auf Ebene der Zeilensicherheit (Row Level Security, RLS).