Dieselben Texte, die alle Mitarbeitenden ins ISMS holen, halten fast alle aus dem Tool heraus, in dem es läuft; hier ist die Zugriffsmatrix, die aus den Klauseln folgt, und wo ein Produkt die Grenzen zieht.
Dieselben Texte, die alle Mitarbeitenden ins ISMS holen, halten fast alle aus dem Tool heraus, in dem es läuft; hier ist die Zugriffsmatrix, die aus den Klauseln folgt, und wo ein Produkt die Grenzen zieht.
Die Durchführungsverordnung (EU) 2024/2690 der Kommission legt die NIS2-Risikomanagementmassnahmen für einen benannten Kreis digitaler Anbieter fest: DNS- und Cloud-Anbieter, Rechenzentren, Anbieter verwalteter Dienste und verwalteter Sicherheitsdienste, Online-Marktplätze und einige mehr. Ihr Anhang ist bei der Sicherheits-Governance ungewöhnlich konkret, und zwei seiner Sätze ziehen in entgegengesetzte Richtungen.
Punkt 1.2.2: „Die betreffenden Einrichtungen verlangen von allen Mitarbeitenden und Dritten, die Netz- und Informationssystemsicherheit entsprechend dem festgelegten Konzept für die Sicherheit von Netz- und Informationssystemen, den themenspezifischen Konzepten und den Verfahren der betreffenden Einrichtungen anzuwenden.“
Punkt 11.2.2(a): Die Einrichtungen „gewähren und entziehen Zugangs- und Zugriffsrechte auf der Grundlage des Grundsatzes ‚Kenntnis nur, wenn nötig‘ (Need-to-know), des Grundsatzes der Nutzungsnotwendigkeit (Need-to-use) und des Grundsatzes der Aufgabentrennung“. Wo die deutsche Fassung von Nutzungsnotwendigkeit spricht, steht in der englischen least privilege; im Folgenden heisst dieser Grundsatz Least Privilege.
Der erste Satz holt alle herein. Der zweite hält fast alle draussen. Das Tool, in dem Sie Ihr ISMS betreiben, steht unter beiden zugleich: Dort bitten Sie Menschen um Mitwirkung, und zugleich ist es ein Netz- und Informationssystem mit eigenen Zugriffsrechten.
Die meisten Teams lösen die Spannung auf, indem sie sich für einen der beiden Sätze entscheiden. Entweder erhält jede Person, die ein Control verantwortet, ein Konto mit Bearbeitungsrechten, oder nur das Compliance-Team hat Konten, und alle anderen wirken per E-Mail mit. Das Erste verstösst gegen 11.2.2(a). Das Zweite erzeugt Mitwirkung, die sich niemandem zuordnen lässt. Keines von beiden ist nötig.
Das Wort „Rolle“ erfüllt in der Compliance zwei Aufgaben, und es hilft, sie zu trennen, bevor man irgendetwas entwirft.
Eine Verantwortungsrolle sagt, wer handeln muss. Nach Punkt 1.2.1 legen die Einrichtungen „Verantwortlichkeiten und Weisungsbefugnisse für die Sicherheit von Netz- und Informationssystemen fest und ordnen sie den Rollen zu“. Erwägungsgrund (27) nennt die Rollen, die er im Blick hat: die „des leitenden Beauftragten für die Informationssicherheit, des Beauftragten für die Informationssicherheit, des Beauftragten für die Bewältigung von Sicherheitsvorfällen, des Prüfers oder vergleichbare Funktionen“. In der Praxis ist die Liste länger: wer das Backup-Control verantwortet, wer die Lieferantenakte freigibt, wer die Zugriffsüberprüfung für das Finanzsystem bestätigt.
Eine Zugriffsrolle sagt, was ein Login in einem bestimmten System tun kann. Das ist Punkt 11.2: Zugangs- und Zugriffsrechte gewähren, ändern, löschen und dokumentieren, nach Need-to-know und Least Privilege.
Die AICPA Trust Services Criteria hinter SOC 2 halten dieselbe Trennung ein. Die Kriterien erscheinen nur auf Englisch; Zitate stehen deshalb im Original, jeweils mit einer sinngemässen deutschen Wiedergabe. CC1.3 handelt von Verantwortung: Das Management "establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives" (sinngemäss: legt unter Aufsicht des Aufsichtsgremiums Strukturen, Berichtslinien sowie angemessene Befugnisse und Verantwortlichkeiten zur Erreichung der Ziele fest), und der zugehörige Point of Focus verlangt vom Management, "assign responsibility and segregate duties as necessary at the various levels of the organization" (sinngemäss: auf den verschiedenen Ebenen der Organisation Verantwortung zuzuweisen und Aufgaben nach Bedarf zu trennen). CC5.3 verortet diese Verantwortung dort, wo die Arbeit anfällt: Die Verantwortlichkeit für Kontrollaktivitäten liegt "with management (or other designated personnel) of the business unit or function in which the relevant risks reside" (sinngemäss: beim Management oder anderen benannten Personen der Geschäftseinheit oder Funktion, in der die betreffenden Risiken liegen). CC6.3 handelt von Zugriff, und dort stehen die entscheidenden Worte: Zugriff wird autorisiert "based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties" (sinngemäss: auf Grundlage von Rollen, Verantwortlichkeiten oder des Systemdesigns und seiner Änderungen, unter Berücksichtigung der Konzepte Least Privilege und Aufgabentrennung).
Wer mit ISO/IEC 27001:2022 arbeitet, findet die eigenen Klauseln über ENISAs Mapping-Tabelle zur Verordnung. Sie ordnet Punkt 1.2 der Klausel 5.3 und den Controls A.5.2, A.5.3 und A.5.4 zu, Punkt 8.1 (Sensibilisierung) der Klausel 7.3 und A.6.3, Punkt 11.1 unter anderem A.5.15, Punkt 11.2 A.5.3 und A.5.18 und Punkt 11.3 A.8.2. ENISA knüpft daran einen Vorbehalt, den man sich merken sollte: "The mapping table should not be interpreted as a measure of equivalency among different standards or frameworks." (Sinngemäss: Die Mapping-Tabelle sollte nicht als Massstab für Äquivalenz zwischen verschiedenen Normen oder Frameworks verstanden werden.)
Achten Sie darauf, wo in diesem Mapping die Aufgabentrennung auftaucht. A.5.3 steht sowohl unter 1.2 als auch unter 11.2. Sie ist eine Frage der Verantwortung und eine Frage des Zugriffs zugleich, und genau deshalb werden die beiden Arten von Rolle verwechselt.
Die Regel, die ich aus diesen Texten ableite: Verantwortung entscheidet, wer handeln muss und wer freigibt; Zugriff entscheidet, welche Oberfläche eine Person bekommt. Wer ein Control verantwortet, muss erreichbar und rechenschaftspflichtig sein und liefern können. Nichts davon setzt das Recht voraus, das Risikoregister zu bearbeiten.
Es liegt nahe, das Compliance-Tool als den Ort zu behandeln, an dem das Zugriffskonzept geschrieben wird, und zu vergessen, dass das Konzept auch für das Tool selbst gilt. Der Anhang lässt dafür keinen Raum. Nach Punkt 11.1.2(a) müssen die Konzepte für die Zugriffskontrolle „für den Zugang von Personen, einschließlich Personal, Besuchern und externen Einrichtungen wie Anbietern und Diensteanbietern, gelten“. Das ISMS-Tool enthält das Risikoregister, offene Behandlungsmassnahmen, die Zeitachsen von Sicherheitsvorfällen und Audit-Feststellungen. Das ist eine Landkarte der Stellen, an denen die Organisation am schwächsten ist. Wenige Systeme verdienen Need-to-know mehr.
Daraus folgt, dass die Administratoren des ISMS-Tools privilegierte Konten sind und Punkt 11.3 für sie gilt. Nach Punkt 11.3.2(a) „müssen starke Verfahren zur Identifizierung, Authentifizierung (z. B. Multifaktor-Authentifizierung) und Genehmigung für privilegierte Konten und Systemverwaltungskonten eingerichtet werden“, und nach Punkt 11.3.2(c) „müssen die Systemverwaltungsrechte so weit wie möglich individuell zugeschnitten und einschränkt werden“. Punkt 10.1.2(b) ergänzt die menschliche Seite: „Mechanismen, mit denen sichergestellt wird, dass sich alle Nutzer mit administrativem oder privilegiertem Zugang ihrer Rollen, Verantwortlichkeiten und Weisungsbefugnisse bewusst sind und entsprechend handeln“.
Drei weitere Stellen in Punkt 11.2 werden zu Anforderungen an das Tool selbst. Nach Punkt 11.2.2(e) führen die Einrichtungen „ein Register der gewährten Zugangs- und Zugriffsrechte“. Nach Punkt 11.2.2(f) „protokollieren“ sie „das Management von Zugangs- und Zugriffsrechten“. Punkt 11.2.3 verlangt eine Überprüfung „in geplanten Zeitabständen“, deren Ergebnisse dokumentiert werden. Wenn Ihr ISMS-Tool Ihnen nicht sagen kann, wer welche Rolle hat und wer sie geändert hat, können Sie diese Überprüfung nicht für das Tool durchführen, in dem Ihre übrigen Überprüfungen stattfinden sollen.
Kleine Organisationen erhalten eine ehrliche Ausnahme. Erwägungsgrund (5) räumt ein, dass es „für Kleinstunternehmen schwierig sein“ könnte, „widerstrebende Pflichten und sich widersprechende Verantwortlichkeitsbereiche zu trennen“, und verweist auf „Ausgleichsmaßnahmen wie eine gezielte Beaufsichtigung durch ihr Management oder eine verstärkte Überwachung und Protokollierung“. Wenn zwei Personen alles betreiben, ist die Antwort ein Protokoll, das jemand anders liest.
Hier ist die Matrix, die ich zeichnen würde, bevor ich jemanden in ein ISMS-Tool einlade, gleich welches. Jede Zeile ist eine Personengruppe, mit der Oberfläche, die sie braucht, dem, was ihr unmöglich sein muss, und dem Text, der es verlangt.
| Gruppe | Typischerweise | Oberfläche | Darf nicht | Anker |
|---|---|---|---|---|
| Administratoren | ISMS-Verantwortliche, Informationssicherheitsbeauftragte, eine Stellvertretung | Tool konfigurieren, Mitglieder verwalten, alle Register bearbeiten | ohne MFA handeln; handeln, ohne einen Log-Eintrag zu hinterlassen | 2024/2690 11.3.2(a), (c); 11.2.2(f); ENISA: A.8.2 |
| Lesende | Leitungsorgan, Control-Verantwortliche, die Kontext brauchen, interne Risikofunktionen | Register lesen, an Diskussionen teilnehmen | einen Registereintrag ändern | 2024/2690 1.2.3, 11.2.2(a); CC6.3 |
| Unabhängige Prüfinstanz | Zertifizierungsauditor, interne Revision | alles lesen, einschliesslich der Änderungshistorie | irgendetwas ändern, auch Kommentare | 2024/2690 1.2.5, Erwägungsgrund (27); ENISA: A.5.3 |
| Mitwirkende | alle übrigen Mitarbeitenden, oft auch externe Auftragnehmer | eigene zugewiesene Elemente: bestätigen, erledigen, anhängen, melden | die Register sehen; Elemente von Kolleginnen und Kollegen sehen | 2024/2690 1.2.2, 8.1.1, 10.1.1; CC5.3; ENISA: 7.3, A.6.3 |
| Benannte Kontakte | Ansprechpersonen bei Lieferanten, externe Beratende, Personen, die als Verantwortliche referenziert werden | keine: Sie werden in Einträgen genannt | sich überhaupt anmelden | 2024/2690 11.2.2(d) |
Drei Zeilen verdienen einen Kommentar.
Lesende sind die Zeile, die man am leichtesten überspringt. Punkt 1.2.3 verlangt: „Mindestens eine Person muss gegenüber den Leitungsorganen direkt für Fragen der Sicherheit von Netz- und Informationssystemen verantwortlich sein.“ Ein Leitungsorgan, das die Berichte liest, die es genehmigt, ist besser aufgestellt als eines, das ein PDF bekommt. Lesende brauchen das ganze Bild und keinen Schreibzugriff. Ihnen Bearbeitungsrechte zu geben, für den Fall, dass sie etwas korrigieren müssen, ist genau das, was Punkt 11.2.2(a) ausschliesst.
Die unabhängige Prüfinstanz ist die Stelle, an der Aufgabentrennung konkret wird. Ein Auditor, der bearbeiten kann, was er prüft, ist nicht mehr unabhängig, und auch ein Kommentar ist eine Bearbeitung: Er verändert den Eintrag, den die nächste Person liest. Die Oberfläche der Prüfinstanz ist schreibgeschützt, und zwar vollständig.
Mitwirkende sind die grösste Gruppe und diejenige, deren Oberfläche am meisten Gestaltung braucht. Punkt 8.1.1 will, dass Mitarbeitende sich „der Risiken bewusst sind“ und „Verfahren im Bereich der Cyberhygiene anwenden“, und Punkt 10.1.1 will, dass sie „ihre Verantwortlichkeiten im Bereich der Sicherheit verstehen und sich zu ihrer Einhaltung verpflichten“. Keiner der beiden Punkte verlangt Zugriff auf das ISMS. Sie verlangen einen Ort, an dem eine Person ihrem eigenen Teil davon begegnet.
Eine Oberfläche für Mitwirkende folgt nur dann Least Privilege, wenn einige Regeln gelten. Ich würde jedes Tool, auch jedes selbst gebaute Portal, an diesen fünf messen.
Für das Offboarding verlangt Punkt 11.5.4, Kennungen „unverzüglich“ zu deaktivieren, sobald sie nicht mehr benötigt werden. Schnell deaktivieren fällt leichter, wenn die Deaktivierung nicht die Historie vernichtet, nach der ein Auditor später fragt.
Alles Bisherige funktioniert mit jedem Tool. So zieht devguard die Grenzen, Einschränkungen eingeschlossen; die Release-Daten stehen im Changelog.
devguard kennt sechs Organisationsrollen, und der Einladungsdialog beschreibt jede in einer Zeile. Admin: „Verwaltet Mitglieder, Einstellungen und alle Register“. Mitglied: „Liest alle Register und beteiligt sich an Kommentaren“. Auditor: „Sieht alles in der Anwendung ein, kann aber nichts ändern, nicht einmal einen Kommentar“. Mitarbeiter: „Nutzt ausschliesslich das Mitarbeiterportal für Richtlinien, Schulungen, Aufgaben und Vorfälle“. Extern: „Ein Kontakt ohne Zugang zur Anwendung oder zum Portal, der in der Liste geführt wird, um referenziert zu werden“. Eigentümer steht nicht in der Auswahl; diese Rolle erhält man über die Übertragung der Eigentumsrechte. Der Reihe nach entsprechen die Rollen den fünf Zeilen der Matrix, wobei Eigentümer und Admin die Administratoren sind.
Das Portal ist die Oberfläche für Mitwirkende. Ein Konto mit der Rolle Mitarbeiter landet nach der Anmeldung dort und erreicht die Admin-Anwendung nicht. Im Portal sieht man nur, was einem zugeordnet ist: Aufgaben, die einem selbst oder einer eigenen Verantwortungsrolle zugewiesen sind, Dokumente, die auf dieselbe Weise zugewiesen sind, Nachweise, bei denen eine der eigenen Rollen die verantwortliche Rolle oder die Genehmigungsrolle ist, und Vorfälle, die man selbst gemeldet hat. Alles andere verhält sich, als wäre es nicht da. Mitarbeitende können einer Nachweisanforderung Dateien anhängen und sie als erledigt markieren, aber die Genehmigung, die das nächste Überprüfungsdatum setzt, bleibt in der Anwendung, bei den Personen in der Genehmigungsrolle dieses Nachweises. Diese Befugnis kommt aus der Verantwortungsrolle, nicht aus der Zugriffsstufe: Ein Mitglied in der Genehmigungsrolle kann genehmigen, ein Admin ausserhalb davon nicht. Wer einen Vorfall meldet, erfasst ihn und ergänzt Notizen; Schweregrad und Status bleiben bei der verantwortlichen Person. Wird das Portal oder einer seiner Bereiche abgeschaltet, sind die Seiten geschlossen, auch für Links aus Lesezeichen.
Auf der Seite der Administratoren kann die Organisation Zwei-Faktor-Authentifizierung verpflichtend machen, und Einladungen, Rollenwechsel, Entfernungen, Übertragungen der Eigentumsrechte und Deaktivierungen hinterlassen jeweils einen Eintrag im Audit Log, den keine Rolle bearbeiten kann. Eine Deaktivierung sperrt den Zugang, ohne die Historie der Person zu löschen, und widerruft Berechtigungen für verbundene Apps.
Zwei Dinge kann devguard nicht, und beide haben ihren Preis.
Es gibt keine benutzerdefinierten oder registerbezogenen Rollen. Ein Mitglied liest alle Register; Sie können keine lesende Person anlegen, die das Risikoregister sieht, das Vorfallsregister aber nicht. Sechs feste Rollen sind für einen Auditor leicht zu verstehen und in einer Überprüfung leicht zu kontrollieren; ich halte das für wertvoller als feingranulare Berechtigungen, aber es ist ein Tauschgeschäft. Wenn Sie engere Lesebereiche brauchen, ist die Rolle Mitglied für Sie zu weit gefasst, und das Portal zusammen mit Verantwortungsrollen ist das engere Werkzeug.
Es gibt eine einzige Administratorenrolle, die sowohl Zugriff vergibt als auch alle Register bearbeitet. Das Tool trennt nicht zwischen der Verwaltung, wer hineinkommt, und der Verwaltung der Inhalte. In einem kleinen Team gibt es für die zweite Hälfte dieser Trennung oft niemanden, dem man sie übergeben könnte. Wenn Ihre Risikobewertung die Trennung verlangt, muss sie aus einer Ausgleichsmassnahme ausserhalb des Rollenmodells kommen: dem Audit Log, gelesen von jemandem, der kein Administrator ist, also der Art von Überwachung, die Erwägungsgrund (5) für Kleinstunternehmen nennt. Ein Konto mit der Rolle Auditor ist ein sinnvoller Platz für diese lesende Person.
Konten mit der Rolle Mitarbeiter zählen wie jedes andere Mitglied zum Benutzerlimit des Plans; externe Kontakte belegen keinen Platz.
Bevor die nächste Einladung hinausgeht, schreiben Sie die fünf Zeilen für Ihre Organisation auf, mit Namen. Führen Sie dann Ihre geplante Zugriffsüberprüfung nach Punkt 11.2.3 zuerst für das ISMS-Tool durch. Jede andere Überprüfung wird darin festgehalten, und das macht es zu dem System, dessen Zugriffsliste Sie als erste geklärt haben wollen.
devguard gibt jeder dieser Gruppen ihre eigene Oberfläche, von der Rolle Auditor bis zum Mitarbeiterportal: devguard.ch.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.