Mehrfaktorauthentisierung, oft MFA genannt, ist eine zweite Kontrolle zusätzlich zu einem Passwort: ein Code aus einer App, eine SMS oder ein physischer Schlüssel. Die Frage, ob dies für ein Softwareunternehmen verpflichtend ist, lässt sich nicht mit einem einfachen Ja oder Nein beantworten, da die NIS2-Richtlinie keine spezifische Technik vorschreibt. Artikel 21 verpflichtet Organisationen, die unter die Sorgfaltspflicht fallen, aber zu angemessenen Maßnahmen für Zugriffskontrolle und Mehrfaktor-Authentisierung, und Aufsichtsbehörden schauen dabei, wo das Risiko am größten ist.
Für ein Softwareunternehmen sind das in der Praxis zwei sehr unterschiedliche Stellen: die Entwicklungsumgebung, in der Sie selbst arbeiten, und die Software, die Sie an Kunden bereitstellen. Beide erfordern eine eigene Bewertung, und diese Bewertung ist nicht überall gleich streng.
Zwei Stellen, an denen Mehrfaktor-Authentisierung eine Rolle spielt
Die erste Stelle ist intern: die Umgebung, in der Ihre Entwickler arbeiten. Quellcode, die Entwicklungsumgebung, Cloud-Konsolen und die Systeme, mit denen Sie in die Produktion gehen. Die zweite Stelle steckt im Produkt selbst: Wenn die Software, die Sie erstellen oder bereitstellen, eine Anmeldungsseite hat, ist Mehrfaktor-Authentisierung auch dort ein Thema, sowohl für Ihre eigenen Benutzer als auch für die Endbenutzer Ihres Kunden. Eine Sicherheits-Frageliste eines Auftragsgebers fragt fast immer nach beiden, oft in separaten Fragen, die etwas anders formuliert sind als Sie vielleicht erwarten würden.
Bei dem Zugriff auf Ihre Entwicklungsumgebung
Hier liegt die stärkste Erwartung. Wer auf den Quellcode zugreifen kann, wer in die Produktion bereitstellen kann und wer Administratorrechte auf der Cloud-Umgebung hat, stellt das größte Risiko dar, wenn ein Passwort nur gestohlen oder wiederverwendet wird. Für diese Konten gilt Mehrfaktor-Authentisierung in fast jedem Sicherheitsrahmen als grundlegende Maßnahme, und das ist auch das, was Aufsichtsbehörden und Kunden zuerst erwarten. Versionskontrolle, die Entwicklungsumgebung selbst und insbesondere jedes Konto mit Rechten zum Bereitstellen von Code in die Produktion gehören in der Praxis ausnahmslos hinter einen zweiten Schritt.
Dazu gehört auch ein Blick darauf, wer diesen Zugriff überhaupt noch braucht. Ein Dossier, in dem pro System steht, wer Zugriff haben darf und warum, macht es leichter, diese Frage in einer Frageliste mit einer konkreten Antwort zu beantworten, anstatt mit einer Annahme. wie Zugriffskontrolle und Mehrfaktor-Authentisierung pro Thema erklärt werden gibt dafür einen Ausgangspunkt.
Bei der Software, die Sie bereitstellen
Die zweite Ebene ist die Software selbst. Wenn Ihr Produkt eine Anmeldungsfunktion hat, kommt die Frage, ob Sie Mehrfaktor-Authentisierung anbieten, in einer Sicherheits-Frageliste fast immer vor, und manchmal sogar als Vertragsbedingung. Das ist eine andere Bewertung als bei Ihrer eigenen Entwicklungsumgebung: Hier geht es nicht darum, was Sie selbst verwenden, sondern darum, was Sie Ihrem Kunden bereitstellen. Ein Auftraggeber, der selbst unter die Sorgfaltspflicht fällt, muss gemäß Artikel 21 auch seine Lieferkette bewerten, und die Frage, ob Ihr Produkt starke Authentisierung unterstützt, gehört dazu.
Die Antwort muss nicht sein, dass es überall verpflichtend aktiviert ist. Oft genügt es zu zeigen, dass die Möglichkeit vorhanden ist, dass Benutzer dazu ermutigt werden und dass Sie einen Plan haben, sie dort auszuweiten, wo das Risiko dies rechtfertigt.
Wo es weniger selbstverständlich ist
Nicht alle Konten oder Umgebungen erfordern die gleiche Sicherheitsstufe. Eine Testumgebung ohne echte Kundendaten, ein internes Dokumentationssystem mit nur Lesezugriff oder ein einfaches Werkzeug, das ein Entwickler gelegentlich nutzt, werden anders bewertet als ein Konto mit Produktionszugriff. Die Sorgfaltspflicht verlangt Maßnahmen, die den Risiken entsprechen, nicht überall die gleiche hohe Sicherheitsstufe einzuführen. Aufsichtsbehörden beurteilen dies auf Grundlage der Verhältnismäßigkeit, und das bedeutet, dass eine begründete Entscheidung, die mehrstufige Authentifizierung an einer Stelle nicht einzuführen, genauso Teil eines Dokumentationsverzeichnisses sein kann wie die Stellen, an denen sie vorhanden ist.
Die Begründung ist hier das wichtigste Wort. Eine Entscheidung ohne Erklärung wirkt in einem Fragebogen schnell wie eine Auslassung, während die gleiche Entscheidung mit einer kurzen Begründung oft genau die Antwort ist, die ein Auftraggeber sucht.
Was dies für das Gespräch mit einem Auftraggeber bedeutet
Ein Auftraggeber, der einen Fragebogen versendet, möchte in der Regel nicht wissen, ob Sie jeden Punkt erfüllen, sondern ob Sie Ihre Risiken kennen und bewusst damit umgehen. Für mehrstufige Authentifizierung bedeutet das: zeigen können, was in der Entwicklungsumgebung vorhanden ist, was im Produkt vorhanden ist, und warum der Rest anders eingerichtet ist. Wer das pro System dokumentiert hat, mit einem Status und einer Verantwortlichkeit, muss die Frage nicht erneut recherchieren, sobald der nächste Fragebogen ankommt.
Ob und wie sich dies für Ihre Organisation genau auswirkt, hängt von Ihrer Rolle in der Lieferkette und von dem ab, was Ihre Kunden spezifisch abfragen; konsultieren Sie im Zweifelsfall den Text der Richtlinie selbst oder einen Berater. Wenn Sie zunächst wissen möchten, wo Sie stehen, dann gibt die kostenlose Prüfung in ein paar Fragen einen ersten Eindruck, und eine Erklärung, wo die Informationen herkommen zeigt, wie dieser Eindruck entsteht.
Wenn Sie umfassender lesen möchten, wie dieses Thema mit den anderen Maßnahmen der Sorgfaltspflicht zusammenhängt, finden Sie das in der Übersicht der Themen nach Situation. Die Schnellanalyse und die Wissensdatenbank sind frei zugänglich, ohne dass Sie dafür ein Konto erstellen müssen.