Die Frage „Wer in unserem Unternehmen hat Zugriff auf die Kundendatenbank" klingt harmlos. In den meisten KMU stellt sich nach einer Woche Antworten einsammeln heraus, dass darauf halb so viele Leute mehr Zugriff haben, als irgendwer erwartet hätte — plus zwei Konten von Mitarbeitenden, die vor drei Jahren gegangen sind, und ein Integrationslogin, dessen Passwort niemand mehr kennt.
Eine Zugriffsprüfung (im Englischen access review) ist weder ein Sicherheitsaudit noch eine SSO-Einführung. Es ist ein schlichtes, langweiliges, quartalsweises Aufräumen: jemand geht System für System und Konto für Konto durch, fragt „Braucht diese Person diesen Zugriff noch?" und hakt ab. Mehr nicht. In den meisten KMU dauert das zwei Tage einmal pro Quartal — vorausgesetzt, jemand fängt endlich damit an.
Warum überhaupt
Drei Gründe, jeder für sich ausreichend:
- Menschen gehen, Konten bleiben. Besonders in Systemen, die die IT im Tagesgeschäft nicht sieht — eine externe Logistikplattform, ein Großhandelskonto, Zugriff auf ein Bankportal. Das Offboarding erwischt 70 % der Konten; das fehlende Drittel findet erst die Prüfung.
- Berechtigungen häufen sich. Jemand ist aufgestiegen, hat die Abteilung gewechselt oder vor drei Jahren zwei Wochen lang eine Kollegin vertreten — und sitzt bis heute auf einem Zugriff, den er nicht mehr braucht. Ein Einzelfall ist harmlos; zehn davon ergeben ein Compliance-Problem.
- Prüfer fragen immer häufiger danach. Banken bei der Kreditvergabe, Versicherer bei der Cyberpolice, NIS2-Prüfungen in regulierten Branchen, ein großer B2B-Kunde vor der Rahmenvereinbarung. „Wir machen die Prüfung einmal pro Quartal" ist heute die Standardantwort, die den Punkt schließt. Keine Antwort öffnet die nächsten fünf Fragen.
Wird die Prüfung übersprungen, kommt das meistens zu spät heraus — eine Person, die vor sechs Monaten gegangen ist, bekommt noch E-Mails aus einem Firmenpostfach, weil ihr Konto in einer Cloud-Anwendung nie geschlossen wurde.
Welche Systeme überhaupt unter die Lupe
Ein 30-Personen-Betrieb hat in der Regel 15–25 Systeme, in denen irgendwer ein Konto hat. Nicht alle sind gleich wichtig. Eine vernünftige Aufteilung:
- Hohes Risiko (vierteljährlich): ERP (Comarch Optima, enova365, Subiekt, Microsoft Dynamics), WMS, CRM, Online-Banking, Microsoft 365 / Google Workspace, VPN und Fernzugriff, Domänenverwaltung (Active Directory, Entra ID), Code-Repositorys.
- Mittleres Risiko (halbjährlich): HR- und Lohnabrechnungssysteme (Płatnik, Comarch ERP HR), Logistikplattformen (Transportero, Trans.eu), Lieferantenportale und Marktplatzkonten, Ticketsysteme, Fileshare / SharePoint, Netzwerkdrucker mit Verwaltungspanel.
- Niedriges Risiko (jährlich oder ad hoc): Marketing-Apps, Grafikwerkzeuge, Nutzungslizenzen. Nicht weil sie weniger wichtig wären, sondern weil sie meist einer einzelnen Person zugeordnet und selten geteilt sind.
Die meisten Firmen versuchen, alles auf einmal zu erfassen, bleiben am vierten System stecken und werden nie fertig. Besser die erste Kategorie quartalsweise ordentlich als alle drei einmal im Jahr halbherzig.
Wie es in der Praxis aussieht — eine Firma, zwei Tage, konkrete Funde
Bei einem unserer Kunden — einem 24-Personen-Vertriebsunternehmen aus Großpolen, das mit Comarch Optima, Microsoft 365, Subiekt für eine Filiale und drei Logistikplattformen arbeitet — hat die erste ernsthafte Zugriffsprüfung insgesamt 16 Arbeitsstunden einer Person gekostet (der Hauptbuchhalter mit IT-Ader), verteilt auf drei Nachmittage. Umfang: 7 Systeme der Hochrisiko-Kategorie.
Die Funde waren typisch — und aufschlussreich. Zwei aktive Microsoft-365-Konten von Mitarbeitenden, die 18 und 24 Monate zuvor ausgeschieden waren (E3-Lizenzen für etwa 1 200 PLN pro Jahr ohne jeden Nutzen). In Comarch Optima hatten sieben Personen mit aktivem „Kassierer"-Profil zusätzlich Zugriff auf das Modul HR/Lohn, das sie 2023 für eine Woche gebraucht hatten, als eine Kollegin im Urlaub war. In Subiekt ein Gemeinschaftskonto „Lager", dessen Passwort acht Leute kannten und das sich keiner Einzelperson eindeutig zuordnen ließ. Zwei Integrationskonten (zum CRM und zu einer Logistikplattform), die niemand mehr beschreiben konnte — angelegt vom früheren IT-Dienstleister, Status unklar. Ein API-Token mit Vollrechten, 2024 „zum Testen" ausgestellt, bis heute aktiv.
Nachbereitungszeit: weitere 8 Stunden. Einmalige Einsparung: rund 1 200 PLN jährlich bei Lizenzen plus zwei geschlossene Angriffsvektoren (ein brachliegendes Microsoft-365-Konto eines Ex-Mitarbeiters ist fast schon vorbereitete Ransomware). Dauerhafte Einsparung: ein ganzes Quartal ohne die Entdeckung, dass „noch jemand Zugriff hat". Und das erste zusammenhängende Bild — zum ersten Mal seit Jahren war klar, wer welchen Schlüssel wirklich hält.
Die zweite Prüfung drei Monate später brauchte 6 Stunden. Die dritte — 4. Die erste ist schwer, weil man ein Jahrzehnt Vernachlässigung aufräumt. Danach ist es nur noch Instandhaltung.
Was pro Konto genau zu prüfen ist
Eine kurze, wiederholbare Liste — denn eine lange Liste erschlägt die Prüfung schon beim ersten Durchlauf:
- Arbeitet die Person noch im Unternehmen. Abgleich der Kontenliste mit der HR-Liste. Offensichtlich, aber überraschend oft fehleranfällig — besonders in Systemen, in denen die HR-Integration manuell oder gar nicht erfolgt.
- Ist sie noch in derselben Rolle. Die Person aus dem Lager, die vor drei Jahren in den Einkauf gewechselt ist, hat weiterhin Bestandskorrektur-Rechte. Nicht, weil sie sie nutzt, sondern weil niemand sie entzogen hat.
- Ist es ein Personen-, Gemeinschafts- oder Integrationskonto. Gemeinschaftskonten („Lager", „Rezeption") und Dienstkonten brauchen eine andere Behandlung — sie lassen sich nicht einfach deaktivieren, man muss entscheiden, ob sie gebraucht werden und wer dafür verantwortlich ist. Dazu gibt es separat unseren Beitrag über Dienstkonten.
- Ist der Zugriff für die Arbeit nötig, die diese Person tatsächlich macht. Diese Frage richtet sich an die Führungskraft, nicht an die IT. Die IT weiß nicht, ob Anna wirklich das Analyse-Modul im ERP braucht. Ihre Chefin weiß es.
- Wann die letzte Anmeldung war. In den meisten Systemen ist das eine Ein-Klick-Information. Ein Konto, das seit 6 Monaten nicht benutzt wurde, disqualifiziert sich praktisch selbst.
Antwortformat: eine Tabelle mit 20–50 Zeilen in einer Datei und vier Spalten — Konto, System, Entscheidung (belassen / Berechtigung entziehen / Konto deaktivieren), wer entschieden hat. Mehr nicht. Nicht Jira, nicht Confluence, keine dedizierte GRC-Plattform. Eine Tabelle, die nach der Prüfung ins Archiv wandert und als Nachweis dient, dass die Prüfung stattgefunden hat.
Drei Fallen, die immer passieren
Erste Anläufe laufen meist in dieselben Minen:
- Alles der IT überlassen. Die IT sieht Konten, nicht Geschäftsbedarf. Ob die Vertriebsperson Zugriff auf das Einkaufsmodul braucht, entscheidet ihr Vorgesetzter. Die IT setzt die Entscheidung nur um.
- Prüfung „auf Vorrat". Manche Betriebe wollen alles herausholen: ERP-Berechtigungen auf Fensterebene, jeden NTFS-Ordner, jeden AD-Eintrag. Nach einer Woche haben alle genug, und die Prüfung wird nie fertig. Besser 7 Systeme auf Rollenebene als 25 auf Checkbox-Ebene.
- „Machen wir nur dieses eine Mal." Eine einmalige Prüfung verliert innerhalb von 6 Monaten den größten Teil ihres Wertes, weil im Betrieb Leben herrscht — neue Leute, Rollenwechsel, Vertretungen. Der ganze Sinn liegt im Rhythmus. Wenn ein Quartalsrhythmus nicht geht, dann ein halbjährlicher — aber ein Rhythmus.
Wie man diese Woche anfängt
Eine einfache Sequenz, die keine neuen Werkzeuge voraussetzt:
- Schritt 1 — die Hochrisiko-Systeme auf einem Zettel aufzählen. Fünf oder sieben, nicht zwanzig. ERP, E-Mail, VPN, Bank, Domänenverwaltung. Dieser Zettel braucht 20 Minuten.
- Schritt 2 — für jedes System die Kontenliste exportieren. In den meisten ERPs ist das ein einziger Report; in Microsoft 365 — ein Export aus dem Admin-Center. Einen halben Tag für alles.
- Schritt 3 — die Kontenliste mit dem aktuellen HR-Stand abgleichen. Konten ohne Personen = deaktivieren. Personen ohne Konten = die Frage, ob etwas übersehen wurde.
- Schritt 4 — die verbleibenden Konten an die Abteilungsleitungen schicken mit der Frage „Braucht diese Person diesen Zugriff noch?". Nichts vorab für sie ankreuzen. Neun von zehn antworten innerhalb einer Woche.
- Schritt 5 — die Entscheidungen umsetzen. Die Tabelle mit Datum archivieren. Den Termin der nächsten Prüfung in den Kalender eintragen — nicht „in drei Monaten", sondern ein konkretes Datum.
Eine Zugriffsprüfung verhindert keine Sicherheitsvorfälle. Sie verkleinert aber deren Radius — geht etwas schief, verliert eine Person, nicht dreißig. Und sie erlaubt es, eine Prüferfrage mit einem Satz zu beantworten statt mit einer Folie.
Ein ruhendes Konto von jemandem, der vor einem Jahr gegangen ist, richtet keinen Schaden an — bis es ihn anrichtet. Eine Zugriffsprüfung ist die Viertelstunde, die „bis" beantwortet.