Wenn der Praktikant alle Daten löschen kann

„Zugriff ist Zugriff“ – höre ich oft.
Und dann wundert sich jemand, warum in der Tabelle Rechnungen plötzlich alles weg ist.
Oder warum die BI-Auswertung plötzlich #Zugriffsfehler ausgibt.

Meistens: Rechte falsch gesetzt.
Zu viel Zugriff.
Oder zu wenig.
Beides ist schlecht.

Ich zeige Dir, wie ich Rechte konzipiere, prüfe und durchsetze – ohne Schikane, aber mit Verstand.

Grundprinzip: Least Privilege

Jeder bekommt genau das, was er braucht.
Nicht mehr. Nicht weniger.

• Buchhaltung darf buchen, nicht löschen
• Lager darf aktualisieren, nicht einfügen
• BI darf lesen, aber nicht schreiben
• Entwickler haben temporäre Adminrechte – nie dauerhaft

Schritt 1: Benutzerrollen definieren

-- Beispielrollen in SQL Server
CREATE ROLE db_reader;
CREATE ROLE db_writer;
CREATE ROLE db_admin;
CREATE ROLE app_user_sales;
CREATE ROLE app_user_logistik;

Dann: Rechte zuweisen – nicht direkt an Benutzer, sondern an Rollen.

Schritt 2: Objektrechte gezielt vergeben

-- Lesen auf Tabelle Kunden
GRANT SELECT ON dbo.Kunden TO db_reader;

-- Schreiben auf Tabelle Bestellungen
GRANT INSERT, UPDATE ON dbo.Bestellungen TO db_writer;

-- Keine Rechte auf sensible Tabelle
DENY SELECT, INSERT, UPDATE, DELETE ON dbo.Personalakte TO db_reader;

Du brauchst klare Regeln.
Und kein GRANT ALL.

Schritt 3: Benutzer zu Rollen hinzufügen

-- Beispiel: Benutzerin Anna bekommt nur Leserechte
ALTER ROLE db_reader ADD MEMBER Anna;

-- Max darf alles im Lager
ALTER ROLE app_user_logistik ADD MEMBER Max;

So kannst Du neue Kolleg:innen zuweisen, ohne einzelne Objekte anfassen zu müssen.

Schritt 4: Rechtematrix dokumentieren

Tabelle	Leserecht	Schreibrecht	Adminrechte
Kunden	Vertrieb, BI	Vertrieb	Admin
Rechnungen	Buchhaltung, BI	Buchhaltung	Admin
Artikel	Alle	Logistik, Einkauf	Admin
Benutzerrollen	–	–	Admin

Dokumentation ist kein Selbstzweck.
Hilft bei Audits. Und wenn Du selbst 6 Monate später wieder ran musst.

Schritt 5: Rechte in Access umsetzen (Frontend)

Auch in Access kannst Du per VBA prüfen, was jemand darf.
Ich baue mir dazu ein kleines Modul.

Public Function HatRecht(strModul As String, strAktion As String) As Boolean
    Dim rs As DAO.Recordset
    Set rs = CurrentDb.OpenRecordset("SELECT 1 FROM Benutzerrechte WHERE Loginname='" & Environ("USERNAME") & "' AND Modul='" & strModul & "' AND Aktion='" & strAktion & "'")
    HatRecht = Not rs.EOF
End Function

Dann bei Buttonklick:

Private Sub btnLoeschen_Click()
    If Not HatRecht("Artikel", "Loeschen") Then
        MsgBox "Du darfst das nicht.", vbExclamation
        Exit Sub
    End If

    ' Löschen durchführen
End Sub

Kein Wildwuchs. Klare Kontrolle.

Schritt 6: Monitoring nicht vergessen

-- Wer hat Zugriff auf was?
SELECT 
    dp.name AS Principal, 
    dp.type_desc, 
    o.name AS Object, 
    p.permission_name
FROM sys.database_permissions p
JOIN sys.database_principals dp ON p.grantee_principal_id = dp.principal_id
LEFT JOIN sys.objects o ON p.major_id = o.object_id
ORDER BY dp.name, o.name;

Damit siehst Du auf einen Blick, was falsch gelaufen ist.
Und kannst aufräumen.

Tabelle: Typische Fehler – und bessere Lösung

Problem	Besser so
Rechte direkt auf User vergeben	Rollen verwenden
GRANT ALL	Nur benötigte Rechte setzen
Jeder darf alles in Access	Rechte prüfen per Benutzerrolle
SQL-Logins ohne Kontrolle	Nur Windows Auth oder Azure AD
Keine Übersicht über Berechtigungen	Rechtematrix und Reporting-Query

Mein Setup für sicheres Rechtemanagement

Bereich	Umsetzung
Benutzerverwaltung	über AD-Gruppen + SQL-Rollen
Rechtevergabe	nur über Rollen, nie direkt
Doku	als Tabelle im Repo / Wiki
Access-Steuerung	per VBA + Rechte-Tabelle
Audits	2× jährlich SQL-Berechtigungen prüfen

Rechte sind wie Sicherheitsgurte.

Stören manchmal –
aber fehlen sie, wird’s teuer.

Wenn Du’s gleich richtig machst,
sparst Du Dir viele Stunden Chaosreparatur.
Und kannst nachts ruhig schlafen.
Auch wenn ein Praktikant versehentlich DELETE * drückt.