Diplom-Biologe | Senior IT-Consultant
|
SH |
Sascha Hess xenosystems.de - IT-Consulting & Data Management |
www.xenosystems.de |
|
|
Strategische Wissens-Roadmap 2026 |
|
|
|
|
|
ERP-Sicherheit |
|
|
Berechtigungs-konzepte |
|
|
Zugriffsschutz, Rollenmodelle und Compliance für den Mittelstand |
WAS SIE IN DIESEM KIT ERHALTEN:
|
|
1 |
10 Sicherheits-Fallen Die häufigsten Berechtigungsfehler in KMU-ERP-Systemen — mit Sofort-Korrekturen |
|
|
2 |
Rollenmodell-Baukasten Fertige Rollenstrukturen für Einkauf, Vertrieb, Buchhaltung und IT |
|
|
3 |
Berechtigungs-Audit SQL-Skripte für vollständige Transparenz über Zugriffsrechte in unter 1 Stunde |
|
|
4 |
Compliance-Framework DSGVO, GoBD, SOX-Analogie und AI Act — was KMU wirklich brauchen |
|
|
5 |
30-Tage-Bereinigungsplan Vom Berechtigungs-Wildwuchs zur sauberen, auditierbaren Struktur |
HAFTUNGSAUSSCHLUSS
Alle Skripte, Konzepte und Empfehlungen wurden sorgfältig erarbeitet. Da jede ERP-Umgebung individuell ist, übernimmt der Autor keinerlei Haftung für Sicherheitsvorfälle, Datenverlust, Compliance-Verstöße oder sonstige Schäden. Testen Sie alle Änderungen an Berechtigungsstrukturen in einer Testumgebung und führen Sie vor jeder Produktionsänderung ein vollständiges Backup durch.
KEIN ERSATZ FÜR RECHTSBERATUNG
Dieses Kit liefert Orientierung zu DSGVO, GoBD und weiteren Regularien — es ersetzt keine rechtliche oder steuerrechtliche Fachberatung. Klären Sie Compliance-Anforderungen mit Ihrem Datenschutzbeauftragten, Steuerberater und ggf. Wirtschaftsprüfer.
VERSIONSHINWEIS
Die Inhalte beziehen sich auf gängige ERP-Systeme im deutschen Mittelstand sowie SQL Server 2022/2025, Stand März 2026. ERP-spezifische Berechtigungsmodelle (SAP, Dynamics, MACH, APplus) entwickeln sich mit jeder Produktversion weiter.
URHEBERRECHT
Dieses Dokument ist für den persönlichen oder betriebsinternen Gebrauch des Käufers lizenziert. Weiterverkauf, Weitergabe an Dritte und öffentliche Veröffentlichung sind ohne schriftliche Genehmigung nicht gestattet.
KEINE VERBINDUNG ZU ERP-HERSTELLERN
Dieses Kit ist ein unabhängiges Werk ohne Verbindung zu SAP SE, Microsoft Corporation, MACH AG, Asseco Solutions oder anderen genannten ERP-Herstellern. Alle Produktnamen sind Marken der jeweiligen Unternehmen.
Eine ausführliche Version dieses Haftungsausschlusses befindet sich am Ende dieses Dokuments.
01 Einleitung
Warum ERP-Berechtigungen das unterschätzte Sicherheitsrisiko Nr. 1 sind
02 Grundlagen
Rollenmodelle, Segregation of Duties und das Least-Privilege-Prinzip
03 Die 10 Sicherheits-Fallen
Typische Berechtigungsfehler in KMU-ERP-Systemen — mit Korrekturen
04 Berechtigungs-Audit
SQL-Skripte und Checklisten für vollständige Transparenz
05 Rollenmodell-Baukasten
Fertige Strukturen für alle KMU-Kernbereiche
06 ERP-spezifische Besonderheiten
SAP, Dynamics 365, MACH, APplus — was jeweils zu beachten ist
07 Datenbank-Sicherheitsschicht
SQL Server Berechtigungen als zweite Verteidigungslinie
08 Compliance-Framework
DSGVO, GoBD, SOX-Analogie und AI Act für KMU
09 Notfall- und Ausnahmekonzept
Firefighter-Accounts, temporäre Rechte und Krisenprotokoll
10 30-Tage-Bereinigungsplan
Vom Berechtigungs-Wildwuchs zur auditierbaren Struktur
01
Wenn mittelständische Unternehmen über IT-Sicherheit sprechen, denken sie an Firewalls, Virenscanner und Phishing-Awareness-Trainings. Das ERP-Berechtigungskonzept — der eigentliche Schlüssel zu Finanzdaten, Kundendaten, Lieferantenkonditionen und Lohnbuchhaltung — wird dabei regelmäßig übersehen.
Die Realität in der KMU-Praxis ist ernüchternd: In über 80 % der mittelständischen ERP-Installationen, die im Rahmen von Audits oder ERP-Migrationen untersucht werden, existieren kritische Berechtigungsfehler, die seit Jahren unbemerkt bestehen.
→ Der Buchhalter kann Lieferantenstammdaten ändern und Zahlungen freigeben — eine klassische Funktionstrennung, die fehlt.
→ Zehn ehemalige Mitarbeiter haben noch aktive ERP-Zugänge — manche seit zwei Jahren.
→ Der IT-Administrator hat in der Produktivumgebung dieselben Rechte wie in der Testumgebung — inklusive Lohnbuchhaltung und Finanzbuchhaltung.
→ Alle Außendienstmitarbeiter nutzen einen gemeinsamen Sammelaccount, weil "das einfacher ist."
→ Das ERP-System schreibt Audit Logs — aber niemand liest sie.
Diese Muster sind keine Nachlässigkeit böswilliger Akteure. Sie entstehen durch organisches Wachstum, fehlende Prozesse beim Mitarbeiterein- und -austritt und den alltäglichen Pragmatismus im KMU-Betrieb. Das Ergebnis sind Risiken, die sich in drei Kategorien teilen:
→ Internes Betrugsrisiko: Wer Buchungen erstellen und freigeben kann, kann Geld entnehmen.
→ Compliance-Risiko: DSGVO, GoBD und zunehmend der AI Act stellen Anforderungen an Zugriffsprotokollierung und Funktionstrennung, die ohne Berechtigungskonzept nicht erfüllbar sind.
→ Reputationsrisiko: Ein externer Angreifer, der einen ERP-Account übernimmt, hat mit Vollzugang sofort Zugriff auf alle Kundendaten, Preislisten und Bankverbindungen.
Dieses Kit gibt Ihnen die Werkzeuge, um den tatsächlichen Zustand Ihrer ERP-Berechtigungen in unter einer Stunde zu analysieren, ein tragfähiges Rollenmodell zu entwickeln und die Bereinigung strukturiert in 30 Tagen durchzuführen — ohne den laufenden Betrieb zu gefährden.
|
|
DIE DREI HÄUFIGSTEN AUSLÖSER FÜR BERECHTIGUNGS-AUDITS ■ ERP-Migration: Berechtigungen aus dem Altsystem werden ungeprüft übernommen — inklusive aller historischen Fehler. ■ Externer Audit: Wirtschaftsprüfer oder Datenschutzbeauftragter fordert Nachweis über Zugriffskontrolle. ■ Sicherheitsvorfall: Ein Mitarbeiter hat auf Daten zugegriffen, auf die er keinen Zugriff hätte haben sollen. |
02
Das wichtigste Grundprinzip jedes Berechtigungskonzepts: Jeder Benutzer erhält genau die Rechte, die er für seine Arbeit benötigt — nicht mehr. Klingt selbstverständlich. In der Praxis wird es fast überall verletzt, weil "mehr Rechte" kurzfristig Probleme löst und niemand die Langzeitkonsequenz im Blick hat.
→ Warum es verletzt wird: Ein Mitarbeiter braucht einmalig Zugriff auf Modul X. Der Einfachste Weg ist, ihm Vollzugriff zu geben. Der Aufwand, später wieder zu reduzieren, entsteht nie.
→ Was es kostet: Im Schadensfall — Betrug, Datenleck, Complianceverstoß — haftet die Geschäftsführung persönlich für fehlende Zugriffskontrollen.
|
-- Least-Privilege-Verletzungen in SQL Server erkennen -- Benutzer mit mehr Rechten als ihre Rolle erfordert SELECT dp.name AS Benutzer, dp.type_desc AS Benutzertyp, o.name AS Objekt, p.permission_name AS Berechtigung, p.state_desc AS Status, -- Flag: direkte Grants sind Least-Privilege-Verstöße CASE WHEN p.grantee_principal_id = dp.principal_id THEN 'DIREKT — prüfen!' ELSE 'Via Rolle' END AS GrantTyp 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 WHERE dp.type NOT IN ('R','A') -- keine Rollen, nur Benutzer AND p.state_desc = 'GRANT' AND dp.name NOT IN ('dbo','guest','INFORMATION_SCHEMA','sys') ORDER BY dp.name, o.name; |
Segregation of Duties bedeutet: Kritische Geschäftsprozesse müssen auf mindestens zwei Personen aufgeteilt sein, sodass keine Einzelperson eine vollständige Transaktion alleine durchführen kann — von der Erfassung bis zur Freigabe.
Die vier kritischen SoD-Paare im KMU:
|
Funktion A |
Funktion B |
Risiko bei Kombination |
Lösungsansatz |
|
Lieferant anlegen |
Zahlung freigeben |
Phantomlieferant + Zahlung |
Vier-Augen bei Lieferantenneuanlage |
|
Rechnung erfassen |
Rechnung buchen |
Gefälschte Rechnungen |
Unterschiedliche Buchhalter-Rollen |
|
Gehalt pflegen |
Lohnlauf starten |
Gehaltsmanipulation |
IT oder GF als zweite Instanz |
|
Artikel anlegen |
Preise pflegen |
Preismanipulation |
Einkauf ≠ Stammdatenpflege |
Im RBAC-Modell werden Rechte nicht Personen, sondern Rollen zugewiesen. Personen erhalten Rollen. Das hat drei entscheidende Vorteile:
→ Skalierbarkeit: Ein neuer Mitarbeiter bekommt eine Rolle — nicht 47 Einzelrechte.
→ Auditierbarkeit: Was eine Rolle darf, ist einmal dokumentiert und gilt für alle Rolleninhaber.
→ Reversibilität: Rollenänderungen gelten sofort für alle Inhaber.
|
-- RBAC-Struktur in SQL Server: Rollen statt Einzelrechte -- Rolle anlegen CREATE ROLE ERP_Buchhaltung_Sachbearbeiter; CREATE ROLE ERP_Buchhaltung_Teamleiter; CREATE ROLE ERP_Einkauf_Sachbearbeiter; CREATE ROLE ERP_Vertrieb_Innendienst; CREATE ROLE ERP_Lager_Mitarbeiter;
-- Rechte auf Rollen vergeben (nie direkt auf Benutzer) GRANT SELECT, INSERT ON SCHEMA::Buchhaltung TO ERP_Buchhaltung_Sachbearbeiter; GRANT EXECUTE ON dbo.SP_Rechnung_Erfassen TO ERP_Buchhaltung_Sachbearbeiter; GRANT EXECUTE ON dbo.SP_Rechnung_Freigeben TO ERP_Buchhaltung_Teamleiter; -- SoD!
-- Benutzer zu Rollen zuweisen ALTER ROLE ERP_Buchhaltung_Sachbearbeiter ADD MEMBER [DOMAIN\a.mueller]; ALTER ROLE ERP_Buchhaltung_Sachbearbeiter ADD MEMBER [DOMAIN\b.schmidt]; ALTER ROLE ERP_Buchhaltung_Teamleiter ADD MEMBER [DOMAIN\k.weber]; |
|
Linie |
Verantwortlich |
Aufgabe |
|
1. Linie |
Fachbereich + IT |
Berechtigungen pflegen, Prozesse einhalten, Anomalien melden |
|
2. Linie |
IT-Leitung + Datenschutzbeauftragter |
Richtlinien definieren, regelmäßige Überprüfung, Schulung |
|
3. Linie |
Geschäftsführung + externer Auditor |
Unabhängige Prüfung, Compliance-Nachweis, Eskalation |
03
"Alle Außendienstmitarbeiter nutzen den Account 'vertrieb_allgemein'." In der Praxis weit verbreitet, weil es einfach ist. Im Schadensfall ist keine Handlung mehr einer Person zuzuordnen. Audit Logs sind wertlos. DSGVO-Nachweise unmöglich.
LÖSUNG:
✓ Personalisierte Accounts sind nicht verhandelbar — jeder Mensch, eine Identität.
✓ Sammelaccounts deaktivieren, nachdem individuelle Accounts eingerichtet sind.
✓ Passwort-Manager einführen, wenn das Argument "zu viele Passwörter" kommt.
✓ Single Sign-On (SSO) über Azure AD reduziert den Passwort-Overhead auf null.
|
-- Sammelaccounts identifizieren: Accounts ohne zugehörigen AD-Benutzer -- oder mit generischen Namen SELECT name AS Account, create_date AS Erstellt, modify_date AS GeaendertAm, is_disabled AS Deaktiviert, -- Verdachtsmerkmale für Sammelaccounts CASE WHEN name LIKE '%allgemein%' THEN 'SAMMELACCOUNT-VERDACHT' WHEN name LIKE '%service%' THEN 'SERVICE-ACCOUNT — prüfen' WHEN name LIKE '%test%' THEN 'TESTACCOUNT in Produktion!' WHEN name LIKE '%admin%' THEN 'ADMIN-ACCOUNT — berechtigt?' ELSE 'OK' END AS Bewertung FROM sys.server_principals WHERE type_desc = 'SQL_LOGIN' AND is_disabled = 0 ORDER BY Bewertung DESC, name; |
Ein Mitarbeiter verlässt das Unternehmen. HR informiert die IT — oder auch nicht. Der Account bleibt aktiv. Im besten Fall passiert nichts. Im schlechtesten Fall nutzt der ehemalige Mitarbeiter seinen Zugang, oder ein Angreifer übernimmt das verwaiste Konto.
LÖSUNG:
✓ Offboarding-Checkliste mit IT-Schritt "ERP-Account deaktivieren" am letzten Arbeitstag.
✓ Monatliche automatische Prüfung: Accounts ohne Login seit > 60 Tagen.
✓ AD-Synchronisation: Wenn AD-Account deaktiviert wird, wird ERP-Account automatisch gesperrt.
|
-- Inaktive Accounts identifizieren — Logins seit > 60 Tagen SELECT sp.name AS Account, sl.last_successful_logon AS LetzterLogin, DATEDIFF(DAY, sl.last_successful_logon, GETDATE()) AS InaktivSeit_Tagen, sp.is_disabled AS Deaktiviert, CASE WHEN sl.last_successful_logon IS NULL THEN 'NIE EINGELOGGT' WHEN DATEDIFF(DAY, sl.last_successful_logon, GETDATE()) > 180 THEN 'SOFORT DEAKTIVIEREN' WHEN DATEDIFF(DAY, sl.last_successful_logon, GETDATE()) > 60 THEN 'PRÜFEN UND BEREINIGEN' ELSE 'AKTIV' END AS Empfehlung FROM sys.server_principals sp LEFT JOIN sys.dm_exec_sessions sl ON sp.name = sl.login_name WHERE sp.type_desc IN ('SQL_LOGIN','WINDOWS_LOGIN','WINDOWS_GROUP') AND sp.is_disabled = 0 AND sp.name NOT LIKE '##%' -- System-Accounts ausschließen AND sp.name NOT IN ('sa','NT AUTHORITY\SYSTEM') GROUP BY sp.name, sl.last_successful_logon, sp.is_disabled HAVING MAX(sl.last_successful_logon) < DATEADD(DAY,-60,GETDATE()) OR MAX(sl.last_successful_logon) IS NULL ORDER BY InaktivSeit_Tagen DESC; |
Der IT-Administrator braucht gelegentlich Zugriff auf das ERP-System — für Wartung, Updates, Fehlersuche. Also bekommt er dauerhaften Vollzugriff. Inklusive Lohnbuchhaltung, Finanzbuchhaltung und Preislisten — Daten, die er für seine IT-Arbeit nie braucht.
LÖSUNG:
✓ IT-Administratoren bekommen nur technische Berechtigungen: Datenbankwartung, Backup, Monitoring.
✓ Inhaltlicher ERP-Zugriff nur über Firefighter-Account mit Protokollierung (Kapitel 9).
✓ Lohnbuchhaltung und Finanzbuchhaltung immer in separatem Datenbankschema mit eigenem Rollenkonzept.
|
-- Kritische Rollenüberschneidung: IT-Accounts mit Finanzzugriff SELECT r.name AS Rolle, m.name AS Mitglied, -- Sicherheitskritische Rollen im ERP-Kontext CASE WHEN r.name IN ('db_owner','sysadmin') AND EXISTS (SELECT 1 FROM sys.schemas s WHERE s.name IN ('Lohn','Fibu','Controlling')) THEN 'KRITISCH: Admin mit Finanzzugriff' WHEN r.name = 'db_owner' THEN 'HOCH: db_owner in Produktivdatenbank' ELSE 'PRÜFEN' END AS Risikobewertung FROM sys.database_role_members rm JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id JOIN sys.database_principals m ON rm.member_principal_id = m.principal_id WHERE r.name IN ('db_owner','sysadmin','db_securityadmin') ORDER BY Risikobewertung, r.name, m.name; |
Dieselbe Person legt Lieferanten an, erfasst Eingangsrechnungen und gibt Zahlungen frei. Das ist das klassischste und am häufigsten ausgenutzte Betrugsmuster in KMU-Buchhaltungen — und es ist in Minuten umsetzbar, wenn niemand es bemerkt.
LÖSUNG:
✓ Drei getrennte Rollen: Lieferant anlegen (Stammdatenpflege) — Rechnung erfassen (Buchhalter) — Zahlung freigeben (Teamleiter/GF).
✓ Vier-Augen-Prinzip für alle Neuzugänge im Lieferantenstamm.
✓ Automatischer Alert: neuer Lieferant + erste Zahlung innerhalb von 48 Stunden → Eskalation.
|
-- SoD-Verletzungs-Monitor: wer hat gleichzeitig Anlage- und Freigabe-Rechte? SELECT u.Benutzername, MAX(CASE WHEN r.RollenName = 'Kreditoren_Anlage' THEN 1 ELSE 0 END) AS Kann_Anlegen, MAX(CASE WHEN r.RollenName = 'Kreditoren_Buchen' THEN 1 ELSE 0 END) AS Kann_Buchen, MAX(CASE WHEN r.RollenName = 'Zahlung_Freigabe' THEN 1 ELSE 0 END) AS Kann_Freigeben, -- SoD-Verletzung wenn alle drei Flags = 1 CASE WHEN MAX(CASE WHEN r.RollenName = 'Kreditoren_Anlage' THEN 1 ELSE 0 END) = 1 AND MAX(CASE WHEN r.RollenName = 'Zahlung_Freigabe' THEN 1 ELSE 0 END) = 1 THEN 'KRITISCH: Anlage + Freigabe in einer Hand!' WHEN MAX(CASE WHEN r.RollenName = 'Kreditoren_Buchen' THEN 1 ELSE 0 END) = 1 AND MAX(CASE WHEN r.RollenName = 'Zahlung_Freigabe' THEN 1 ELSE 0 END) = 1 THEN 'HOCH: Buchen + Freigabe in einer Hand' ELSE 'OK' END AS SoD_Status FROM dbo.ERP_Benutzer u JOIN dbo.ERP_Benutzer_Rollen ur ON u.BenutzerID = ur.BenutzerID JOIN dbo.ERP_Rollen r ON ur.RollenID = r.RollenID GROUP BY u.Benutzername HAVING MAX(CASE WHEN r.RollenName = 'Kreditoren_Anlage' THEN 1 ELSE 0 END) = 1 AND MAX(CASE WHEN r.RollenName = 'Zahlung_Freigabe' THEN 1 ELSE 0 END) = 1 ORDER BY SoD_Status; |
Entwickler und Berater erhalten für die ERP-Anpassung Vollzugriff auf die Produktivumgebung — "weil die Testumgebung nicht aktuell ist." Nach Projektende werden die Rechte nicht entzogen. Monate später greift der externe Berater noch auf Produktivdaten zu.
LÖSUNG:
✓ Testumgebung ist Pflicht — kein Entwicklungsarbeit auf Produktion, keine Ausnahmen.
✓ Externe Accounts haben ein eingetragenes Ablaufdatum — maximal 30 Tage nach Projektende.
✓ Automatisches Ablaufen von Accounts: SQL Server Account Expiry oder AD-Accountlaufzeit.
|
-- Externe Accounts mit Ablaufdatum überwachen SELECT name AS Account, create_date AS Erstellt, LOGINPROPERTY(name,'PasswordExpirationEnabled') AS AblaufAktiv, CAST(LOGINPROPERTY(name,'PasswordExpired') AS INT) AS Abgelaufen, -- Externe identifizieren (Namenskonvention: EXT_ Prefix) CASE WHEN name LIKE 'EXT_%' THEN 'EXTERN' WHEN name LIKE 'BERATER_%' THEN 'BERATER' ELSE 'INTERN' END AS AccountTyp FROM sys.server_principals WHERE type_desc = 'SQL_LOGIN' AND is_disabled = 0 AND name NOT LIKE '##%' ORDER BY AccountTyp DESC, create_date ASC; |
Der Audit-Trail existiert nicht oder wird nicht gelesen. Niemand weiß, wer wann auf welche Daten zugegriffen hat. Im Schadensfall ist Forensik unmöglich, DSGVO-Meldepflicht kaum erfüllbar.
LÖSUNG:
✓ SQL Server Audit für alle privilegierten Aktionen einrichten (Kapitel 7).
✓ ERP-seitiges Änderungsprotokoll für Stammdaten und Buchungen aktivieren.
✓ Wöchentlicher automatischer Bericht: Top-10-Zugriffsaktivitäten außerhalb der Regelarbeitszeit.
|
-- SQL Server Audit einrichten: privilegierte Zugriffe protokollieren CREATE SERVER AUDIT ERP_Sicherheits_Audit TO FILE (FILEPATH = 'C:\SQLAudit\ERP\', MAXSIZE = 100 MB, MAX_ROLLOVER_FILES = 12, RESERVE_DISK_SPACE = OFF) WITH (QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE);
CREATE DATABASE AUDIT SPECIFICATION ERP_DB_Audit FOR SERVER AUDIT ERP_Sicherheits_Audit ADD (SCHEMA_OBJECT_ACCESS_GROUP), -- alle SELECT/INSERT/UPDATE/DELETE ADD (DATABASE_ROLE_MEMBER_CHANGE_GROUP), -- Rollenänderungen ADD (DATABASE_PERMISSION_CHANGE_GROUP), -- Berechtigungsänderungen ADD (BACKUP_RESTORE_GROUP) -- Backups und Restores WITH (STATE = ON);
ALTER SERVER AUDIT ERP_Sicherheits_Audit WITH (STATE = ON);
-- Audit-Log auswerten: Zugriffe außerhalb Regelarbeitszeit SELECT event_time, server_principal_name AS Benutzer, database_name AS Datenbank, object_name AS Objekt, statement, action_id FROM sys.fn_get_audit_file('C:\SQLAudit\ERP\*.sqlaudit', DEFAULT, DEFAULT) WHERE DATEPART(HOUR, event_time) NOT BETWEEN 7 AND 19 -- außerhalb Regelzeit OR DATEPART(WEEKDAY, event_time) IN (1,7) -- Wochenende ORDER BY event_time DESC; |
Das ERP-System läuft unter einem Service-Account mit einem Passwort, das seit der Installation vor acht Jahren nicht geändert wurde. Oft ist das Passwort in Klartextform in Konfigurationsdateien hinterlegt. Jeder Systemadministrator kennt es.
LÖSUNG:
✓ Service-Accounts mit Windows Authentication statt SQL Authentication.
✓ Managed Service Accounts (MSA) oder Group Managed Service Accounts (gMSA) — Passwort rotiert automatisch.
✓ Wenn SQL Authentication unvermeidbar: Passwort mindestens jährlich rotieren, in PAM-System (Privileged Access Management) hinterlegen.
|
-- Service-Accounts ohne Passwortrichtlinie identifizieren SELECT name AS Account, create_date AS Erstellt, LOGINPROPERTY(name, 'PasswordPolicyEnforced') AS PolicyAktiv, LOGINPROPERTY(name, 'PasswordExpirationEnabled') AS AblaufAktiv, LOGINPROPERTY(name, 'BadPasswordCount') AS FehlversuchtCount, -- Service-Accounts ohne Policy sind ein Risiko CASE WHEN LOGINPROPERTY(name,'PasswordPolicyEnforced') = 0 THEN 'RISIKO: Keine Passwortrichtlinie' ELSE 'OK' END AS Bewertung FROM sys.server_principals WHERE type_desc = 'SQL_LOGIN' AND is_disabled = 0 AND name NOT IN ('sa') AND name NOT LIKE '##%' ORDER BY Bewertung DESC, name; |
"Alle Buchhalter bekommen die Rolle 'Buchhaltung_Vollzugriff'." Acht Buchhalter — aber nur zwei davon dürfen Jahresabschlüsse buchen, nur einer darf Lohnkonten sehen. Stattdessen haben alle acht Vollzugriff, weil eine feingranulare Rolle "zu aufwendig" ist.
LÖSUNG:
✓ Rollenmodell nach tatsächlichen Aufgaben, nicht nach Abteilungen (Kapitel 5).
✓ Maximal zwei bis drei Rechteebenen je Bereich: Lesen — Bearbeiten — Freigeben.
✓ Einmalinvestition in sauberes Rollenkonzept spart jährliche Audit-Aufwände.
Ein Mitarbeiter wechselt intern von Einkauf zu Buchhaltung. Er bekommt die Buchhaltungs-Rechte — aber die Einkaufs-Rechte werden nicht entzogen. Nach drei solchen Wechseln hat er kumulierte Rechte, die keine einzelne Stellenbeschreibung rechtfertigt.
LÖSUNG:
✓ Rollenwechsel-Prozess: Neue Rolle zuweisen UND alte Rolle entziehen — als atomare Aktion.
✓ Quartalsweise Rezertifizierung: Jeder Fachbereichsleiter bestätigt, dass seine Mitarbeiter die richtigen Rechte haben.
✓ Akkumulierte-Rechte-Alarm: Benutzer mit mehr als drei verschiedenen Rollen → automatische Meldung.
|
-- Akkumulierte Rechte erkennen: Benutzer mit zu vielen Rollen SELECT m.name AS Benutzer, COUNT(DISTINCT r.name) AS AnzahlRollen, STRING_AGG(r.name, ', ') AS AlleRollen, CASE WHEN COUNT(DISTINCT r.name) > 5 THEN 'KRITISCH: Zu viele Rollen' WHEN COUNT(DISTINCT r.name) > 3 THEN 'WARNUNG: Rollen prüfen' ELSE 'OK' END AS Bewertung FROM sys.database_role_members rm JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id JOIN sys.database_principals m ON rm.member_principal_id = m.principal_id WHERE r.is_fixed_role = 0 -- keine System-Rollen AND m.type NOT IN ('R') -- keine Rollen-in-Rollen GROUP BY m.name HAVING COUNT(DISTINCT r.name) > 3 ORDER BY AnzahlRollen DESC; |
Das Berechtigungskonzept existiert als 50-seitiges Word-Dokument aus dem Jahr 2019. Es entspricht nicht mehr der Realität. Niemand weiß, welche Rolle welche Rechte hat, wer welche Rolle innehat und warum. Ein externer Auditor fragt — niemand kann antworten.
LÖSUNG:
✓ Berechtigungsdokumentation wird aus dem System generiert — nicht manuell gepflegt.
✓ Automatischer wöchentlicher Bericht: Rollenmatrix, Mitgliedschaften, letzte Änderungen.
✓ Änderungen an Berechtigungen immer mit Begründung und Genehmiger im Ticketsystem dokumentieren.
|
-- Automatisch generierte Berechtigungsmatrix für Dokumentation SELECT SCHEMA_NAME(o.schema_id) AS Schema, o.name AS Objekt, o.type_desc AS ObjektTyp, r.name AS Rolle, p.permission_name AS Berechtigung, p.state_desc AS Status, -- Direkter Grant (Least-Privilege-Verstoß) oder via Rolle CASE WHEN grantee.type = 'R' THEN 'Via Rolle' ELSE 'DIREKTER GRANT — prüfen!' END AS GrantTyp FROM sys.database_permissions p JOIN sys.database_principals grantee ON p.grantee_principal_id = grantee.principal_id LEFT JOIN sys.objects o ON p.major_id = o.object_id LEFT JOIN sys.database_role_members rm ON grantee.principal_id = rm.member_principal_id LEFT JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id WHERE p.state_desc = 'GRANT' AND grantee.name NOT IN ('dbo','public','guest','INFORMATION_SCHEMA','sys') ORDER BY Schema, Objekt, Rolle, Berechtigung; |
04
|
-- SCHRITT 1 (10 Min): Benutzer-Inventar — wer hat überhaupt Zugang? SELECT sp.name AS Login, sp.type_desc AS LoginTyp, sp.is_disabled AS Deaktiviert, sp.create_date AS Erstellt, ISNULL(sl.last_successful_logon, sp.create_date) AS LetzterLogin, dp.name AS DB_Benutzer, dp.default_schema_name AS Standardschema FROM sys.server_principals sp LEFT JOIN sys.dm_exec_sessions sl ON sp.name = sl.login_name LEFT JOIN sys.database_principals dp ON sp.sid = dp.sid WHERE sp.type_desc IN ('SQL_LOGIN','WINDOWS_LOGIN','WINDOWS_GROUP') AND sp.name NOT LIKE '##%' AND sp.name NOT IN ('sa','NT AUTHORITY\SYSTEM', 'NT SERVICE\SQLSERVERAGENT','NT SERVICE\MSSQLSERVER') ORDER BY sp.is_disabled, sl.last_successful_logon DESC; |
|
-- SCHRITT 2 (10 Min): Rollenmitgliedschaften — wer darf was? SELECT r.name AS Rolle, m.name AS Mitglied, m.type_desc AS MitgliedTyp, -- Ampel-Bewertung kritischer Rollen CASE r.name WHEN 'db_owner' THEN 'ROT: Vollzugriff auf Datenbank' WHEN 'sysadmin' THEN 'ROT: Server-Vollzugriff' WHEN 'db_securityadmin' THEN 'ORANGE: Kann Rechte vergeben' WHEN 'db_ddladmin' THEN 'ORANGE: Kann Schema ändern' WHEN 'db_datawriter' THEN 'GELB: Schreibzugriff alle Tabellen' WHEN 'db_datareader' THEN 'GRÜN: Nur Lesen' ELSE 'PRÜFEN: Benutzerdefinierte Rolle' END AS Risikostufe FROM sys.database_role_members rm JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id JOIN sys.database_principals m ON rm.member_principal_id = m.principal_id ORDER BY Risikostufe, r.name, m.name; |
|
-- SCHRITT 3 (10 Min): Direkte Grants — Least-Privilege-Verstöße SELECT dp.name AS Benutzer, ISNULL(SCHEMA_NAME(o.schema_id) + '.' + o.name, p.class_desc) AS Objekt, p.permission_name AS Berechtigung, p.state_desc AS Status 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 WHERE dp.type NOT IN ('R','A') -- nur Benutzer, keine Rollen AND p.state_desc = 'GRANT' AND dp.name NOT IN ('dbo','guest','INFORMATION_SCHEMA','sys') ORDER BY dp.name, Objekt; |
|
-- SCHRITT 4 (15 Min): SoD-Matrix — kritische Rollenkombinationen WITH UserRoles AS ( SELECT m.name AS Benutzer, r.name AS Rolle FROM sys.database_role_members rm JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id JOIN sys.database_principals m ON rm.member_principal_id = m.principal_id ) SELECT DISTINCT a.Benutzer, a.Rolle AS Rolle_A, b.Rolle AS Rolle_B, 'SoD-KONFLIKT: ' + a.Rolle + ' + ' + b.Rolle AS Konflikt FROM UserRoles a JOIN UserRoles b ON a.Benutzer = b.Benutzer AND a.Rolle < b.Rolle WHERE -- Kritische Kombinationen (a.Rolle LIKE '%Anlage%' AND b.Rolle LIKE '%Freigabe%') OR (a.Rolle LIKE '%Erfassen%' AND b.Rolle LIKE '%Freigabe%') OR (a.Rolle LIKE '%Lohn%' AND b.Rolle LIKE '%Admin%') OR (a.Rolle LIKE '%Fibu%' AND b.Rolle LIKE '%IT%') ORDER BY a.Benutzer; |
|
-- SCHRITT 5 (15 Min): Audit-Ampel — Gesamtübersicht SELECT 'Aktive Benutzer gesamt' AS Metrik, COUNT(*) AS Wert, 'INFO' AS Ampel FROM sys.server_principals WHERE type_desc IN ('SQL_LOGIN','WINDOWS_LOGIN') AND is_disabled = 0 AND name NOT LIKE '##%' UNION ALL SELECT 'Inaktiv > 60 Tage', COUNT(*), CASE WHEN COUNT(*) > 5 THEN 'ROT' WHEN COUNT(*) > 0 THEN 'GELB' ELSE 'GRUEN' END FROM sys.server_principals sp LEFT JOIN sys.dm_exec_sessions sl ON sp.name = sl.login_name WHERE sp.type_desc = 'SQL_LOGIN' AND sp.is_disabled = 0 AND (sl.last_successful_logon < DATEADD(DAY,-60,GETDATE()) OR sl.last_successful_logon IS NULL) UNION ALL SELECT 'db_owner Mitglieder', COUNT(*), CASE WHEN COUNT(*) > 2 THEN 'ROT' WHEN COUNT(*) > 1 THEN 'GELB' ELSE 'GRUEN' END FROM sys.database_role_members rm JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id WHERE r.name = 'db_owner' UNION ALL SELECT 'Direkte Grants (Least-Privilege-Verstöße)', COUNT(*), CASE WHEN COUNT(*) > 10 THEN 'ROT' WHEN COUNT(*) > 3 THEN 'GELB' ELSE 'GRUEN' END FROM sys.database_permissions p JOIN sys.database_principals dp ON p.grantee_principal_id = dp.principal_id WHERE dp.type NOT IN ('R','A') AND p.state_desc = 'GRANT' AND dp.name NOT IN ('dbo','guest','INFORMATION_SCHEMA','sys'); |
05
|
Rolle |
Berechtigung |
Typische Stelleninhaber |
|
Fibu_Leser |
SELECT auf Fibu-Schema |
Controller, GF, Revision |
|
Fibu_Sachbearbeiter |
SELECT + INSERT Buchungen, kein DELETE |
Buchhalter |
|
Fibu_Teamleiter |
+ UPDATE Buchungen, Periodenabschluss vorbereiten |
Buchhaltungsleitung |
|
Fibu_Abschluss |
+ Jahresabschluss buchen, Perioden sperren |
Steuerberater, leitende Buchhaltung |
|
Kreditor_Anlage |
Lieferanten anlegen/ändern |
Einkauf (NICHT Buchhaltung — SoD!) |
|
Zahlung_Freigabe |
Zahlungsläufe starten |
GF oder bevollmächtigte Prokura |
|
-- Buchhaltungs-Rollenstruktur anlegen CREATE ROLE Fibu_Leser; CREATE ROLE Fibu_Sachbearbeiter; CREATE ROLE Fibu_Teamleiter; CREATE ROLE Zahlung_Freigabe; CREATE ROLE Kreditor_Anlage;
GRANT SELECT ON SCHEMA::Fibu TO Fibu_Leser; GRANT SELECT, INSERT ON SCHEMA::Fibu TO Fibu_Sachbearbeiter; GRANT EXECUTE ON dbo.SP_Buchung_Erfassen TO Fibu_Sachbearbeiter; GRANT EXECUTE ON dbo.SP_Buchung_Stornieren TO Fibu_Teamleiter; GRANT EXECUTE ON dbo.SP_Zahlung_Starten TO Zahlung_Freigabe; GRANT SELECT, INSERT, UPDATE ON dbo.Lieferanten TO Kreditor_Anlage;
-- SoD durchsetzen: Zahlung_Freigabe darf NICHT Kreditor_Anlage haben -- Wird durch separate Rollen und Genehmigungsprozess sichergestellt -- Technische Prüfung via SoD-Monitor (Kapitel 4) |
|
Rolle |
Berechtigung |
SoD-Hinweis |
|
Einkauf_Leser |
SELECT Artikel, Lieferanten, Preise |
— |
|
Einkauf_Sachbearbeiter |
+ Bestellungen anlegen und ändern |
Darf NICHT Wareneingänge buchen |
|
Einkauf_Teamleiter |
+ Bestellungen freigeben, Preiskonditionen ändern |
Darf NICHT Lieferanten anlegen |
|
Wareneingang_Bucher |
Wareneingänge erfassen und buchen |
Darf NICHT Bestellungen anlegen |
|
Rolle |
Berechtigung |
SoD-Hinweis |
|
Vertrieb_Innendienst |
Angebote, Aufträge anlegen und bearbeiten |
Kein Zugriff auf Einkaufspreise |
|
Vertrieb_Außendienst |
Nur eigene Kunden und Angebote (RLS!) |
Kein Zugriff auf Kreditlimit anderer |
|
Vertrieb_Teamleiter |
+ Rabatte > 10 % genehmigen, Kreditlimit erhöhen |
— |
|
Versand |
Lieferscheine erstellen, Bestände buchen |
Kein Zugriff auf Preise |
|
-- Row-Level Security für Außendienst: nur eigene Kunden sichtbar CREATE OR ALTER FUNCTION sec.FN_Vertrieb_RLS (@VertreterNr INT) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS RLS_OK WHERE @VertreterNr = ( SELECT VertreterNr FROM dbo.Mitarbeiter WHERE LoginName = USER_NAME() ) OR IS_ROLEMEMBER('Vertrieb_Teamleiter') = 1 OR IS_ROLEMEMBER('db_owner') = 1;
CREATE SECURITY POLICY sec.Policy_Kunden_Vertrieb ADD FILTER PREDICATE sec.FN_Vertrieb_RLS(ZustaendigerVertreter) ON dbo.Kunden WITH (STATE = ON); |
|
-- Lohn-Schema: maximale Isolation, minimale Rollen CREATE SCHEMA Lohn AUTHORIZATION dbo;
-- Nur zwei Rollen für Lohn — konsequente Trennung CREATE ROLE Lohn_Sachbearbeiter; -- Pflege Stammdaten, Lohnarten CREATE ROLE Lohn_Freigabe; -- Lohnlauf starten, Auszahlung freigeben
-- Alle anderen Rollen explizit ausschließen DENY SELECT ON SCHEMA::Lohn TO Fibu_Leser; -- Buchhaltung sieht keine Löhne DENY SELECT ON SCHEMA::Lohn TO ERP_Buchhaltung_Sachbearbeiter;
-- Lohn-Freigabe: nur namentlich benannte Personen, GF oder HR-Leitung ALTER ROLE Lohn_Freigabe ADD MEMBER [DOMAIN\hr.leitung]; ALTER ROLE Lohn_Freigabe ADD MEMBER [DOMAIN\gf.name]; -- GF als zweite Instanz
-- Audit für Lohn-Schema: jeder Zugriff wird protokolliert CREATE DATABASE AUDIT SPECIFICATION Lohn_Vollaudit FOR SERVER AUDIT ERP_Sicherheits_Audit ADD (SELECT ON SCHEMA::Lohn BY PUBLIC), ADD (INSERT ON SCHEMA::Lohn BY PUBLIC), ADD (UPDATE ON SCHEMA::Lohn BY PUBLIC) WITH (STATE = ON); |
06
Business Central hat ein eigenes rollenbasiertes Berechtigungsmodell auf Basis von Permission Sets:
→ Permission Sets definieren Zugriffsrechte auf Tabellen, Reports, Codeunits und XMLports.
→ Profiles steuern die Benutzeroberfläche — unabhängig von Berechtigungen.
→ Security Filter ermöglichen zeilenbasierte Zugriffsbeschränkung (analog zu SQL Row-Level Security).
|
-- Dynamics 365 BC: Berechtigungsanalyse über SQL-Datenbank -- (nur für On-Premise-Installationen mit Datenbankzugriff) SELECT u.User_Name AS Benutzer, ups.Role_ID AS PermissionSet, -- Kritische Standard-Sets erkennen CASE ups.Role_ID WHEN 'SUPER' THEN 'ROT: Vollzugriff — nur für Admins' WHEN 'SECURITY' THEN 'ORANGE: Sicherheitsverwaltung' WHEN 'BASIC' THEN 'GRUEN: Basisrechte' ELSE 'PRÜFEN: Benutzerdefiniert' END AS Risikobewertung FROM [CRONUS$User$...] u -- Tabellennamen je BC-Version anpassen JOIN [CRONUS$User Permission Set$...] ups ON u.User_Security_ID = ups.User_Security_ID WHERE u.State = 0 -- aktive Benutzer ORDER BY Risikobewertung DESC, u.User_Name; |
In SAP-Umgebungen ist das Berechtigungskonzept auf Basis von Rollen und Berechtigungsobjekten aufgebaut:
→ Transaktionscodes (T-Codes) steuern den Zugriff auf Funktionen.
→ Berechtigungsobjekte steuern den Datenzugriff innerhalb von Transaktionen.
→ Rollen (PFCG) bündeln Transaktionscodes und Berechtigungsobjekte.
→ SU53 zeigt fehlgeschlagene Berechtigungsprüfungen — wichtigstes Diagnosewerkzeug.
Kritische SAP-Transaktionscodes für SoD-Analyse:
|
T-Code |
Funktion |
Kritische Kombination |
|
FK01 |
Kreditor anlegen |
+ F110 (Zahlung) = SoD-Verstoß |
|
F110 |
Automatische Zahlung |
+ FK01 = SoD-Verstoß |
|
PA30 |
Personaldaten pflegen |
+ PC00 (Lohnlauf) = SoD-Verstoß |
|
MM01 |
Material anlegen |
+ ME21N (Bestellung) = prüfen |
Für MACH- und APplus-Umgebungen gilt das Grundprinzip der rollenbasierten Zugriffskontrolle identisch — die Umsetzung erfolgt über die jeweiligen Administrationsmodule:
→ MACH: Berechtigungen über Benutzergruppen in der MACH-Benutzerverwaltung, Anbindung an Active Directory empfohlen.
→ APplus: Rollenkonzept über APplus-Benutzerrollen mit Modulberechtigungen und Aktivitätsbeschränkungen.
→ Für beide Systeme gilt: Berechtigungen auf SQL-Server-Ebene als zweite Sicherheitsschicht immer zusätzlich konfigurieren (Kapitel 7).
07
Das ERP-Berechtigungskonzept schützt den Zugriff über die Anwendung. Aber: Wer direkten SQL-Server-Zugriff hat — sei es ein DBA, ein Berater oder ein Angreifer mit gestohlenen Credentials — umgeht die ERP-Berechtigungen vollständig. Die SQL-Server-Berechtigungsschicht ist die letzte Verteidigungslinie.
|
-- Transparent Data Encryption (TDE) aktivieren: Daten auf Disk verschlüsseln -- Schutz bei physischem Datenträgerzugriff oder gestohlenen Backup-Dateien USE master; CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'SehrSicheresPasswort!2026'; CREATE CERTIFICATE TDE_Zertifikat WITH SUBJECT = 'ERP-Datenbank TDE';
USE ERP_Produktiv; CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE TDE_Zertifikat;
ALTER DATABASE ERP_Produktiv SET ENCRYPTION ON;
-- Zertifikat sofort sichern — ohne es ist die Datenbank nach Disaster Recovery unlesbar! BACKUP CERTIFICATE TDE_Zertifikat TO FILE = 'E:\Sicherung\TDE_Zertifikat.cer' WITH PRIVATE KEY (FILE = 'E:\Sicherung\TDE_PrivateKey.pvk', ENCRYPTION BY PASSWORD = 'AnderesSicheresPasswort!2026'); |
|
-- Always Encrypted: Felder werden nur auf dem Client entschlüsselt -- Selbst DBA kann verschlüsselte Werte nicht lesen -- Geeignet für: IBAN, Gehalt, Sozialversicherungsnummer, Gesundheitsdaten
-- Spalte nachträglich verschlüsseln (vereinfachtes Beispiel) ALTER TABLE dbo.Mitarbeiter ALTER COLUMN Gehalt DECIMAL(18,2) ENCRYPTED WITH ( COLUMN_ENCRYPTION_KEY = CEK_Lohn, ENCRYPTION_TYPE = Randomized, -- Randomized: sicherer, kein Index möglich ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256' );
-- Gehaltsdaten sind nun für DBA unlesbar: -- SELECT Gehalt FROM dbo.Mitarbeiter → gibt verschlüsselten Hex-Wert zurück -- Nur Anwendung mit Zugriff auf Column Master Key kann entschlüsseln |
|
-- Erzwingen dass alle Verbindungen verschlüsselt sind (SQL Server 2025) -- In SQL Server Configuration Manager: "Force Encryption = Yes" -- Überprüfung der verschlüsselten Verbindungen: SELECT session_id, login_name, encrypt_option AS Verschluesselt, auth_scheme AS Authentifizierung, net_transport AS Protokoll, client_net_address AS ClientIP, -- Unverschlüsselte Verbindungen sind ein Risiko CASE encrypt_option WHEN 'TRUE' THEN 'OK' WHEN 'FALSE' THEN 'RISIKO: Verbindung unverschlüsselt!' ELSE 'PRÜFEN' END AS Sicherheitsstatus FROM sys.dm_exec_sessions WHERE is_user_process = 1 ORDER BY Sicherheitsstatus DESC; |
08
|
DSGVO-Anforderung |
Konkrete ERP-Maßnahme |
Nachweismittel |
|
Zugangskontrolle (Art. 32) |
Starke Authentifizierung, Benutzer-individuelle Accounts |
AD-Protokolle, Login-Logs |
|
Zugriffskontrolle (Art. 32) |
RBAC, Least Privilege, RLS für Kundendaten |
Rollenmatrix, Audit-Berichte |
|
Vertraulichkeit (Art. 5) |
TDE, Always Encrypted für sensitive Felder |
Verschlüsselungs-Zertifikate |
|
Rechenschaftspflicht (Art. 5) |
Vollständige Audit Logs, Änderungshistorie |
SQL Server Audit-Dateien |
|
Betroffenenrechte (Art. 15–22) |
Auskunft, Löschung technisch umsetzbar |
Lösch-Stored-Procedures |
|
Datenpannen-Meldung (Art. 33) |
Erkennbarkeit durch Audit Logs |
Incident-Response-Prozess |
Die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern (GoBD) stellen spezifische Anforderungen an ERP-Berechtigungen:
→ Unveränderlichkeit: Gebuchte Belege dürfen nicht nachträglich gelöscht oder überschrieben werden — technisch durch Insert-only-Design und Audit Logs sichergestellt.
→ Nachvollziehbarkeit: Jede Buchung muss einer Person und einem Zeitpunkt zugeordnet werden können — erfordert personalisierte Accounts, keine Sammelaccounts.
→ Vollständigkeit: Alle Geschäftsvorfälle müssen erfasst sein — erfordert Zugriffskontrolle, die unautorisierten Zugriffen vorbeugt.
→ Aufbewahrung: 10 Jahre für steuerlich relevante Daten — Audit Logs und Berechtigungshistorie eingeschlossen.
|
-- GoBD-Konformitäts-Check: Buchungen ohne Benutzerzuordnung SELECT COUNT(*) AS Buchungen_Ohne_Benutzer FROM dbo.Buchungen WHERE ErfasstVon IS NULL OR ErfasstVon = ''; -- Ergebnis > 0 ist ein GoBD-Verstoß
-- GoBD: Gelöschte Buchungen — darf nicht existieren SELECT COUNT(*) AS Geloeschte_Buchungen FROM dbo.Buchungen WHERE IsDeleted = 1; -- In GoBD-konformen Systemen: immer 0, nur Stornierungen erlaubt |
Mit vollständiger Geltung des EU AI Acts ab August 2026 entstehen neue Compliance-Anforderungen auch für ERP-seitige Automatisierungen:
→ Automatisierte Freigaben: Wenn das ERP automatisch Bestellungen oder Zahlungen freigibt (Regelbasiert oder ML-gestützt), kann das als KI-System eingestuft werden.
→ Protokollierungspflicht: Jede automatisierte Entscheidung muss protokolliert und menschlich überprüfbar sein.
→ Menschliche Aufsicht: Hochrisiko-Entscheidungen (Kreditvergabe, Personalentscheidungen) dürfen nicht vollautomatisch getroffen werden.
|
-- AI Act: Automatisierte ERP-Aktionen protokollieren CREATE TABLE dbo.AutomatisierungsLog ( LogID INT IDENTITY PRIMARY KEY, Zeitpunkt DATETIME2 DEFAULT SYSUTCDATETIME(), ProzessName NVARCHAR(200), AktionTyp NVARCHAR(100), -- 'BESTELLUNG_AUTO', 'ZAHLUNG_REGEL' ObjektID INT, AusloeserRegel NVARCHAR(MAX), -- welche Regel hat die Aktion ausgelöst? ErgebnisBetrag DECIMAL(18,2), MenschlichGeprueft BIT DEFAULT 0, -- Pflicht für Hochrisiko-Aktionen GeprueftVon NVARCHAR(100), GeprueftAm DATETIME2 ); |
09
Ein Firefighter-Account ist ein privilegierter Notfallzugang, der nur in definierten Ausnahmesituationen genutzt wird — mit vollständiger Protokollierung jeder Aktion.
|
-- Firefighter-Account einrichten CREATE LOGIN ERP_Firefighter WITH PASSWORD = 'SehrKomplexesNotfallPasswort#2026!'; CREATE USER ERP_Firefighter FOR LOGIN ERP_Firefighter;
-- Vollständige Protokollierung ALLER Aktionen des Firefighter-Accounts CREATE DATABASE AUDIT SPECIFICATION Firefighter_Vollaudit FOR SERVER AUDIT ERP_Sicherheits_Audit ADD (DATABASE_OBJECT_ACCESS_GROUP), ADD (SCHEMA_OBJECT_ACCESS_GROUP), ADD (SELECT ON DATABASE::ERP_Produktiv BY ERP_Firefighter), ADD (INSERT ON DATABASE::ERP_Produktiv BY ERP_Firefighter), ADD (UPDATE ON DATABASE::ERP_Produktiv BY ERP_Firefighter), ADD (DELETE ON DATABASE::ERP_Produktiv BY ERP_Firefighter), ADD (EXECUTE ON DATABASE::ERP_Produktiv BY ERP_Firefighter) WITH (STATE = ON);
-- Firefighter ist standardmäßig DEAKTIVIERT ALTER LOGIN ERP_Firefighter DISABLE;
-- Aktivierungsprozedur: nur mit Ticket-Nummer und Genehmiger CREATE OR ALTER PROCEDURE dbo.SP_Firefighter_Aktivieren @TicketNummer NVARCHAR(50), @Genehmiger NVARCHAR(100), @GueltigBis DATETIME2 AS BEGIN SET NOCOUNT ON;
INSERT INTO dbo.Firefighter_Log (Zeitpunkt, TicketNummer, Genehmiger, AktiviertVon, GueltigBis) VALUES (SYSUTCDATETIME(), @TicketNummer, @Genehmiger, SUSER_SNAME(), @GueltigBis);
ALTER LOGIN ERP_Firefighter ENABLE;
-- Automatische Deaktivierung über SQL Agent Job einrichten EXEC msdb.dbo.sp_add_job @job_name = 'Firefighter_Deaktivieren_' + @TicketNummer; -- [Job-Konfiguration für automatische Deaktivierung zum GueltigBis-Zeitpunkt] END |
|
-- Temporäre Berechtigungen dokumentieren und automatisch entziehen CREATE TABLE dbo.Temp_Berechtigungen ( TempID INT IDENTITY PRIMARY KEY, Benutzer NVARCHAR(100), Rolle NVARCHAR(100), Begruendung NVARCHAR(500), Genehmiger NVARCHAR(100), GueltigVon DATETIME2 DEFAULT SYSUTCDATETIME(), GueltigBis DATETIME2, Entzogen BIT DEFAULT 0, EntzogenAm DATETIME2 );
-- SQL Agent Job: abgelaufene temporäre Berechtigungen täglich entziehen CREATE OR ALTER PROCEDURE dbo.SP_Temp_Berechtigungen_Bereinigen AS BEGIN SET NOCOUNT ON;
DECLARE @Benutzer NVARCHAR(100), @Rolle NVARCHAR(100), @TempID INT;
DECLARE temp_cursor CURSOR FOR SELECT TempID, Benutzer, Rolle FROM dbo.Temp_Berechtigungen WHERE GueltigBis < SYSUTCDATETIME() AND Entzogen = 0;
OPEN temp_cursor; FETCH NEXT FROM temp_cursor INTO @TempID, @Benutzer, @Rolle;
WHILE @@FETCH_STATUS = 0 BEGIN -- Rollenmitgliedschaft entziehen DECLARE @sql NVARCHAR(500) = N'ALTER ROLE ' + QUOTENAME(@Rolle) + N' DROP MEMBER ' + QUOTENAME(@Benutzer); EXEC sp_executesql @sql;
UPDATE dbo.Temp_Berechtigungen SET Entzogen = 1, EntzogenAm = SYSUTCDATETIME() WHERE TempID = @TempID;
-- Benachrichtigung EXEC msdb.dbo.sp_send_dbmail @profile_name = 'ERP_Monitoring', @recipients = 'it-sicherheit@ihrunternehmen.de', @subject = 'Temporäre Berechtigung automatisch entzogen', @body = 'Benutzer: ' + @Benutzer + ' / Rolle: ' + @Rolle;
FETCH NEXT FROM temp_cursor INTO @TempID, @Benutzer, @Rolle; END
CLOSE temp_cursor; DEALLOCATE temp_cursor; END |
|
Schritt |
Aktion |
Verantwortlich |
Zeitfenster |
|
1 |
Betroffenen Account sofort sperren |
IT-Administrator |
Sofort |
|
2 |
Audit Logs sichern (read-only Kopie) |
IT-Administrator |
< 30 Minuten |
|
3 |
Datenschutzbeauftragten informieren |
IT-Leitung |
< 1 Stunde |
|
4 |
Schadensausmaß durch Log-Analyse bestimmen |
IT + Datenschutz |
< 4 Stunden |
|
5 |
DSGVO-Meldepflicht prüfen (72h-Frist) |
Datenschutzbeauftragter |
< 24 Stunden |
|
6 |
Betroffene Personen informieren |
Geschäftsführung |
Gem. DSGVO |
|
7 |
Ursache beseitigen, Berechtigungen bereinigen |
IT-Team |
< 48 Stunden |
|
8 |
Post-Mortem und Maßnahmenplan |
Alle |
< 1 Woche |
10
|
|
VOR DEM START Führen Sie den 60-Minuten-Audit aus Kapitel 4 vollständig durch und dokumentieren Sie den Ist-Zustand. Sichern Sie die Datenbank vollständig. Kommunizieren Sie das Vorhaben an die Fachbereichsleiter — Berechtigungsänderungen werden ankündigt, nicht still durchgeführt. Legen Sie fest, wer im Eskalationsfall Entscheidungen treffen darf. |
■ TAG 1-2: VOLLSTÄNDIGES BERECHTIGUNGS-INVENTAR
■ 60-Minuten-Audit aus Kapitel 4 auf allen ERP-Produktivdatenbanken durchführen
■ Ergebnisse in Ampelstruktur aufbereiten: ROT / ORANGE / GELB / GRÜN
■ Alle ROT-Befunde dokumentieren — das sind Ihre Sofortmaßnahmen
■ Stakeholder informieren: GF, Datenschutzbeauftragter, Fachbereichsleiter
■ TAG 3-4: SOFORTMASSNAHMEN ROT-BEFUNDE
■ Sammelaccounts identifizieren und Ablöse-Zeitplan festlegen (2 Wochen)
■ Inaktive Accounts ehemaliger Mitarbeiter sofort deaktivieren — kein Abwarten
■ db_owner und sysadmin Mitglieder auf absolutes Minimum reduzieren
■ Offboarding-Checkliste mit IT-Schritt für künftige Austritte einführen
■ TAG 5-7: SoD-ANALYSE UND ESKALATION
■ SoD-Matrix aus Kapitel 4 für Kreditorenbuchhaltung und Lohn ausführen
■ Kritische SoD-Verstöße an Geschäftsführung eskalieren — mit konkretem Betrugsrisiko
■ Für jeden SoD-Verstoß: Übergangslösung (Vier-Augen manuell) bis Rollenstruktur steht
■ Termin mit Fachbereichsleitern zur Rollenmodell-Abstimmung (Woche 2) vereinbaren
■ TAG 8-10: ROLLENMODELL MIT FACHBEREICHEN ABSTIMMEN
■ Workshop mit Buchhaltungsleitung: welche Rollen brauchen wir wirklich? (Kapitel 5.1)
■ Workshop mit Einkaufsleitung: SoD-Anforderungen und Rollenstruktur festlegen
■ Workshop mit Vertriebsleitung: RLS-Anforderungen für Außendienst klären
■ Rollenmatrix dokumentieren: Rolle — Berechtigung — typische Stelleninhaber
■ TAG 11-13: ROLLEN IN SQL SERVER ANLEGEN
■ Alle neuen Rollen nach Baukasten aus Kapitel 5 anlegen
■ Berechtigungen auf Rollen (nicht auf Benutzer) vergeben
■ Lohn-Schema isolieren und separates Audit einrichten (Kapitel 5.4)
■ SoD-Monitor als SQL Agent Job einrichten: tägliche Prüfung, Ergebnis per Mail
■ TAG 14: DATENSCHUTZ UND COMPLIANCE-CHECK
■ DSGVO-Checkliste aus Kapitel 8.1 mit Datenschutzbeauftragtem durcharbeiten
■ GoBD-Konformitäts-Skript aus Kapitel 8.2 ausführen — Ergebnis dokumentieren
■ SQL Server Audit aktivieren (Kapitel 3, Punkt 6) falls noch nicht vorhanden
■ TDE für alle ERP-Produktivdatenbanken aktivieren und Zertifikat sichern (Kapitel 7.1)
■ TAG 15-17: BENUTZER AUF NEUE ROLLEN MIGRIEREN
■ Je Fachbereich: Benutzer aus alten Rollen entfernen, in neue Rollen aufnehmen
■ Testen: kann jeder Benutzer seine Kernaufgaben noch ausführen? (Testprotokoll)
■ Direkte Grants auf Benutzer entfernen — Rechte laufen nur noch über Rollen
■ Temporäre Berechtigungen-Tabelle einrichten, alle bestehenden Ausnahmen eintragen
■ TAG 18-20: SAMMELACCOUNTS ABLÖSEN
■ Für jeden Sammelaccount: individuelle Accounts anlegen, Passwörter kommunizieren
■ Sammelaccount auf read-only reduzieren (Übergangsphase) — nicht sofort deaktivieren
■ Nach 5 Arbeitstagen ohne Nutzung des Sammelaccounts: deaktivieren
■ Protokoll führen: wer nutzte wann welchen Sammelaccount (für GoBD-Nachweis)
■ TAG 21: FIREFIGHTER-KONZEPT EINRICHTEN
■ Firefighter-Account anlegen und deaktivieren (Kapitel 9.1)
■ Aktivierungsprozedur mit Ticket-Pflicht und Genehmiger-Protokoll einrichten
■ Krisenprotokoll aus Kapitel 9.3 als Dokument erstellen und verteilen
■ Notfall-Kontaktliste: wer ist wann erreichbar bei Sicherheitsvorfall?
■ TAG 22-25: AUTOMATISCHES MONITORING AKTIVIEREN
■ Wöchentlicher Audit-Bericht als SQL Agent Job einrichten — Ampel-Übersicht per Mail
■ Inaktive-Accounts-Check monatlich automatisieren (Kapitel 3, Punkt 2)
■ Akkumulierte-Rechte-Alarm einrichten: > 3 Rollen → automatische Meldung
■ Temp-Berechtigungen-Bereinigung täglich als Job aktivieren (Kapitel 9.2)
■ TAG 26-28: REZERTIFIZIERUNG EINFÜHREN
■ Quartalsweise Rezertifizierung einrichten: Fachbereichsleiter bestätigen Berechtigungen
■ Rollenmatrix aus dem System generieren (Kapitel 3, Punkt 10) und als Basis versenden
■ Ticketpflicht für alle Berechtigungsänderungen ab sofort einführen
■ Onboarding-Checkliste aktualisieren: Berechtigungsvergabe als standardisierter Schritt
■ TAG 29-30: ABSCHLUSS UND DOKUMENTATION
■ Abschluss-Audit: 60-Minuten-Audit erneut durchführen — Ampel-Vergleich Vorher/Nachher
■ Berechtigungsdokumentation aus System generieren und archivieren (GoBD-Pflicht)
■ Ergebnisbericht für Geschäftsführung: was wurde bereinigt, was bleibt als Risiko
■ Jahresplan festlegen: wann findet das nächste Berechtigungs-Audit statt?
■ Ergebnis feiern — saubere Berechtigungen sind nachweisbare Compliance und echter Schutz! ■
|
|
ERGEBNIS NACH 30 TAGEN Ihr Ergebnis nach 30 Tagen: Kein aktiver Account eines ehemaligen Mitarbeiters, keine Sammelaccounts, saubere SoD-Trennung in Buchhaltung und Lohn, dokumentiertes Rollenmodell, aktives Audit-Logging, automatisches Monitoring und ein Krisenprotokoll für den Ernstfall. Das ist auditierbar — gegenüber Wirtschaftsprüfern, Datenschutzbehörden und Ihrem eigenen Gewissen. |
Die in diesem Dokument enthaltenen Informationen, Skripte und Empfehlungen wurden nach bestem Wissen und Gewissen auf der Grundlage langjähriger praktischer Erfahrung erarbeitet. Da jede ERP-Umgebung individuell ist, übernimmt der Autor keinerlei Haftung für Sicherheitsvorfälle, Datenverlust, Compliance-Verstöße, Bußgelder oder sonstige unmittelbare oder mittelbare Schäden.
Änderungen an ERP-Berechtigungsstrukturen sind betriebskritisch. Testen Sie alle Änderungen in einer Nichtproduktionsumgebung, erstellen Sie vollständige Backups und führen Sie Produktionsänderungen immer mit Rollback-Konzept durch.
Dieses Kit liefert Orientierung zu DSGVO, GoBD, AI Act und verwandten Regularien. Es ersetzt keine rechtliche Beratung durch einen Datenschutzbeauftragten, Rechtsanwalt oder Steuerberater. Klären Sie konkrete Compliance-Anforderungen stets mit qualifizierten Fachleuten.
Berechtigungsmodelle und SQL-Strukturen variieren je nach ERP-Hersteller, Version und Konfiguration erheblich. Die gezeigten Skripte sind Muster — passen Sie sie auf Ihre konkrete Umgebung an und testen Sie sie vor dem Produktiveinsatz.
Die Inhalte beziehen sich auf SQL Server 2022/2025, Microsoft Dynamics 365 Business Central, SAP Business One und gängige KMU-ERP-Systeme, Stand März 2026. DSGVO-Auslegungen und regulatorische Anforderungen entwickeln sich weiter.
© 2026 Sascha Hess, xenosystems.de. Alle Rechte vorbehalten. Dieses Dokument ist für den persönlichen oder betriebsinternen Gebrauch des Käufers lizenziert.
SAP und SAP Business One sind eingetragene Marken der SAP SE. Microsoft Dynamics, SQL Server, Azure Active Directory und Power BI sind eingetragene Marken der Microsoft Corporation. MACH ist eine Marke der MACH AG. APplus ist eine Marke der Asseco Solutions AG.
Es gilt ausschließlich deutsches Recht. Gerichtsstand für alle Streitigkeiten ist, soweit gesetzlich zulässig, Weimar, Thüringen, Deutschland.
Sascha Hess ist Diplom-Biologe und IT-Professional mit über 20 Jahren Erfahrung in der Administration von ERP-, BI- und Datenbanksystemen. Er hat mehr als 300 Oracle- und SQL-Server-Instanzen administriert und betreut — von mittelständischen KMU bis zu Universitäten und Energieversorgern.
Sein Ansatz verbindet naturwissenschaftliche Präzision mit hochgradiger IT-Spezialisierung. Schwerpunkte: SQL Server Performance-Tuning, ERP-Sicherheit und Berechtigungskonzepte, ERP-Einführungen, Business Intelligence (Power BI, DeltaMaster), Prozessdigitalisierung und IT-Interim-Management.
Web: www.xenosystems.de | E-Mail: info@xenosystems.de | Standort: Weimar, Thüringen / Remote
|
Service |
Beschreibung |
|
ERP-Berechtigungs-Audit |
Vollständige Analyse Ihres ERP-Berechtigungskonzepts — Risikobericht, SoD-Matrix, Maßnahmenplan und Compliance-Nachweis. Scope: 3-5 Tage. |
|
SQL Server DB Health Check |
Professioneller Audit Ihres SQL Servers — Performance, Sicherheit, Berechtigungen, Backup-Strategie. Scope: 3-5 Tage. |
|
ERP-Einführungsberatung |
Begleitung von ERP-Projekten (MACH, Dynamics NAV, APplus) — Datenmigration, Berechtigungskonzept, Go-Live-Support. |
|
Datenschutz-Technologie-Beratung |
Technische Umsetzung von DSGVO-Anforderungen im ERP und Datenbankumfeld — TDE, Verschlüsselung, Audit-Logging, Löschkonzepte. |
|
Interim IT-Management |
Übernahme der IT-Steuerung auf Zeit — Budgetplanung, Dienstleister-Management, strategische IT-Ausrichtung. |
Vollständiges Dokument
Strategische Wissens-Roadmap · Checklisten · Praxisbeispiele
49,90 €
Sichere Zahlung über PayPal · Sofort-Download nach Zahlungseingang