Xenosystems Logo
Sascha Hess

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


 

 

Rechtliche Hinweise und Haftungsausschluss

 

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.

 


 

 

Inhaltsverzeichnis

 

 

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

Einleitung

 

Warum ERP-Berechtigungen das unterschätzte Sicherheitsrisiko Nr. 1 sind

 

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

Grundlagen

 

Rollenmodelle, Segregation of Duties und das Least-Privilege-Prinzip

 

2.1 Das Least-Privilege-Prinzip

 

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;

 

 

2.2 Segregation of Duties (SoD) — die wichtigste Kontrollregel

 

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

 

2.3 Rollenbasierte Zugriffskontrolle (RBAC)

 

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];

 

 

2.4 Das Drei-Linien-Modell für ERP-Sicherheit

 

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

Die 10 Sicherheits-Fallen

 

Typische Berechtigungsfehler in KMU-ERP-Systemen — mit sofortigen Korrekturen

 

01 Sammelaccounts und geteilte Passwörter

 

"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;

 

 

02 Inaktive Accounts ehemaliger Mitarbeiter

 

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;

 

 

03 IT-Administrator mit Vollzugriff auf Produktiv-ERP

 

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;

 

 

04 Fehlende SoD bei Kreditorenbuchhaltung

 

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;

 

 

05 Produktionssystem-Vollzugriff für Testumgebungs-Entwicklung

 

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;

 

 

06 Keine Protokollierung von privilegierten Zugriffen

 

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;

 

 

07 Passwortlose Service-Accounts im ERP

 

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;

 

 

08 Globale Rollen statt granularer Berechtigungen

 

"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.

 

09 Keine Berechtigungsprüfung bei Rollenänderungen

 

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;

 

 

10 Fehlende Berechtigungsdokumentation

 

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

Berechtigungs-Audit

 

SQL-Skripte und Checklisten für vollständige Transparenz in unter einer Stunde

 

4.1 Der 60-Minuten-Audit-Plan

 

-- 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

Rollenmodell-Baukasten

 

Fertige Rollenstrukturen für alle KMU-Kernbereiche

 

5.1 Buchhaltung / Finanzbuchhaltung

 

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)

 

 

5.2 Einkauf

 

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

 

5.3 Vertrieb / Auftragsbearbeitung

 

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);

 

 

5.4 Personal / Lohnbuchhaltung — Höchste Schutzstufe

 

-- 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

ERP-spezifische Besonderheiten

 

SAP, Dynamics 365, MACH, APplus — was jeweils zu beachten ist

 

6.1 Microsoft Dynamics 365 Business Central

 

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;

 

 

6.2 SAP Business One / SAP S/4HANA

 

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

 

6.3 MACH und APplus

 

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

Datenbank-Sicherheitsschicht

 

SQL Server Berechtigungen als zweite Verteidigungslinie

 

7.1 Defense in Depth — warum die DB-Schicht unverzichtbar ist

 

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');

 

 

7.2 Always Encrypted für höchst sensible Felder

 

-- 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

 

 

7.3 Verbindungsverschlüsselung und minimale Exposition

 

-- 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

Compliance-Framework

 

DSGVO, GoBD, SOX-Analogie und AI Act — was KMU wirklich brauchen

 

8.1 DSGVO-Anforderungen an ERP-Berechtigungen

 

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

 

8.2 GoBD-Anforderungen — was Steuerprüfer prüfen

 

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

 

 

8.3 AI Act — neue Anforderungen ab 2026

 

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

Notfall- und Ausnahmekonzept

 

Firefighter-Accounts, temporäre Rechte und Krisenprotokoll

 

9.1 Das Firefighter-Konzept

 

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

 

 

9.2 Temporäre Berechtigungen mit automatischem Ablauf

 

-- 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

 

 

9.3 Krisenprotokoll bei Sicherheitsvorfall

 

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

30-Tage-Bereinigungsplan

 

Vom Berechtigungs-Wildwuchs zur auditierbaren Struktur

 

 

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.

 

WOCHE 1: INVENTAR & SOFORTMASSNAHMEN

 

■ 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

 

WOCHE 2: ROLLENMODELL ENTWICKELN

 

■ 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)

 

WOCHE 3: MIGRATION UND KOMMUNIKATION

 

■ 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?

 

WOCHE 4: MONITORING UND DAUERBETRIEB

 

■ 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.

 


 

 

Ausführlicher Haftungsausschluss und Lizenzbestimmungen

 

1. Allgemeiner Haftungsausschluss

 

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.

 

2. Kein Ersatz für Rechts- und Steuerberatung

 

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.

 

3. ERP-Versionsspezifische Abweichungen

 

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.

 

4. Versionsabhängigkeit und Aktualität

 

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.

 

5. Urheberrecht und Nutzungsrechte

 

© 2026 Sascha Hess, xenosystems.de. Alle Rechte vorbehalten. Dieses Dokument ist für den persönlichen oder betriebsinternen Gebrauch des Käufers lizenziert.

 

6. Markenrechte

 

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.

 

7. Anwendbares Recht und Gerichtsstand

 

Es gilt ausschließlich deutsches Recht. Gerichtsstand für alle Streitigkeiten ist, soweit gesetzlich zulässig, Weimar, Thüringen, Deutschland.

 


 

 

Über den Autor

 

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

ERP Sicherheit Berechtigungskonzepte 2026

Strategische Wissens-Roadmap · Checklisten · Praxisbeispiele

49,90 €

Sichere Zahlung über PayPal · Sofort-Download nach Zahlungseingang