Funktionen
Wenn Sie Ihr Compliance-Programm in eine SaaS-Plattform verlagern, geben Sie wirklich sensibles Material aus der Hand: Ihr Risikoregister, Ihre Vorfallsakten, Ihre Verträge mit IKT-Dienstleistern, Ihre Prüfnachweise, Ihre Gap-Analysen. Das sind genau die Daten, nach denen eine Aufsichtsbehörde fragt und die ein Wettbewerber gern lesen würde. Deshalb ist eine faire Frage an jeden Anbieter eine sehr einfache: wer auf Ihrer Seite kann meine Daten sehen, und wann?
Bei den meisten SaaS-Produkten lautet die ehrliche Antwort: "Support und Engineering können es, sobald sie es für nötig halten." Venvera geht den umgekehrten Weg. Standardmäßig kann kein Venvera-Engineer den Arbeitsbereich Ihres Mandanten öffnen. Der Zugriff auf Ihren Mandanten über den Support-Pfad "view as" erfolgt ausschließlich dann, wenn einer Ihrer eigenen Mandanten-Administratoren eine konkrete, zeitlich befristete Anfrage genehmigt. Dieser Artikel erklärt, wie dieser Ablauf funktioniert und warum wir das Produkt so gebaut haben, dass der Ausgangszustand geschlossen ist.
Der Standardzustand ist geschlossen
Venvera ist mandantenfähig. Die Daten jedes Mandanten sind auf Datenbankebene durch Row Level Security isoliert, sodass jede Abfrage auf genau eine Organisation eingegrenzt läuft. Darüber hinaus ist das Öffnen eines Kundenmandanten über den Support-Pfad "view as" abgesichert: Die Plattform verweigert den Start der Sitzung, solange für diesen Mandanten keine aktive, genehmigte Zugriffsfreigabe vorliegt.
Der Ausgangszustand ist geschlossen. Das Mandanten-Flag, das dies steuert, ist für jede Kundenorganisation standardmäßig aktiv; offen bleiben allein Venveras eigene interne Mandanten und Demo-Mandanten. Ohne aktive, genehmigte Freigabe wird der Versuch eines Engineers, Ihren Mandanten über den View-as-Pfad zu öffnen, abgewiesen. Die Sitzung startet gar nicht erst.
Für eine Plattform, die Compliance-Daten hält, ist das die richtige Voreinstellung. Sie kann aber nicht die ganze Geschichte sein, denn Supportarbeit braucht gelegentlich einen Blick in den echten Mandanten.
Der Zielkonflikt gehört offen benannt, denn er ist real. Ein geschlossener Standardzustand macht den Support langsamer. Ein Engineer, der sonst kurz in einen Mandanten schauen würde, muss eine Begründung schreiben und darauf warten, dass jemand bei Ihnen sie liest. Wir halten das für den angemessenen Preis bei einer Plattform, die Ihr Risikoregister und Ihre Vorfallsakten hält. Wenn Sie Anbieter vergleichen, rechnen Sie damit, dass die Anbieter mit stehendem Zugriff manche Tickets schneller schließen. Entscheiden Sie, welche dieser beiden Eigenschaften Sie von einem Compliance-Werkzeug tatsächlich erwarten.
So funktioniert der temporäre Zugriff
Manche Probleme lassen sich nur mit Ihren echten Daten reproduzieren: ein Fehler, der von einer bestimmten Konfiguration abhängt, ein hängengebliebener Import, ein Key Risk Indicator, der eine Zahl berechnet, die falsch aussieht. Für diese Fälle hat Venvera einen Anfrage-und-Genehmigungs-Ablauf, der dem nachempfunden ist, was Cloud-Anbieter Customer Lockbox nennen. Er läuft in vier Stufen ab, und das Tor bei Stufe zwei kontrollieren Sie.
Nichts in Stufe drei und vier kann geschehen, solange ein Mandanten-Administrator nicht in Stufe zwei aktiv genehmigt. In diesem Ablauf gibt es kein Timeout, das von sich aus Zugriff gewährt, keinen Eskalationspfad, der an Ihnen vorbeiführt, und keine Möglichkeit für den anfragenden Engineer, die eigene Anfrage selbst zu genehmigen.
Wozu sich der Engineer verpflichten muss
Ein Engineer kann Zugriff weder still noch pauschal noch in Sammelform anfragen. Das Anfrageformular verlangt eine schriftliche Festlegung auf drei konkrete Punkte.
- Eine genehmigende Person. Ein namentlich benannter Administrator aus Ihrer Organisation. Der Engineer wählt eine reale Person, die bei Ihnen arbeitet, statt eines Venvera-Postfachs oder einer allgemeinen Support-Warteschlange, und die Plattform weist jede Person zurück, die kein Administrator Ihres Mandanten ist.
- Eine Begründung. Freitext von mindestens acht Zeichen, im Wortlaut gespeichert. Die genehmigende Person sieht sie Wort für Wort, und sie wird als Teil des Anfragedatensatzes in Ihrem Mandanten-Audit-Log erfasst. Eine vage oder kopierte Begründung bleibt damit für Sie sichtbar und bleibt aktenkundig.
- Eine Dauer. In Minuten gemessen und auf 1440 begrenzt, also 24 Stunden. Durchgesetzt wird das sowohl vom Anfrageformular als auch von einer Datenbank-Constraint. Dauert die Arbeit länger, muss der Engineer eine neue Anfrage stellen, und Sie genehmigen erneut.
Sobald die Anfrage abgeschickt ist, wird die ausgewählte genehmigende Person benachrichtigt. Niemand sonst kann an ihrer Stelle genehmigen, und der Engineer hat zu diesem Zeitpunkt weiterhin keinerlei Zugriff.
Der Grund, eine einzelne Person zu benennen statt einer gemeinsamen Warteschlange, ist wenig glamourös. Warteschlangen, die jeder abarbeiten kann, werden von der Person abgearbeitet, die die Begründung am wenigsten wahrscheinlich liest. Eine namentlich benannte genehmigende Person, die die schriftliche Begründung ansehen muss, ist ein langsameres und ein deutlich besseres Tor.
Genehmigen, über das Dashboard oder per E-Mail
Die genehmigende Person kann auf zwei Wegen handeln. Innerhalb von Venvera erscheint die Anfrage auf ihrem Dashboard, und sie genehmigt oder lehnt sie direkt ab. Außerhalb der App erhält sie eine E-Mail mit einem Einmal-Link und einem sechsstelligen Code. Das Öffnen des Links allein genügt nicht: Die genehmigende Person muss in Venvera als sie selbst angemeldet sein und anschließend den Code eingeben. Diese zweiteilige Prüfung sorgt dafür, dass weder ein automatisch klickender Mail-Scanner noch ein an das falsche Postfach weitergeleiteter Link irgendetwas genehmigen kann.
Warum zwei Kanäle? Der Dashboard-Kanal ist der schnelle Weg für Administratoren, die ohnehin gerade in Venvera arbeiten. Der E-Mail-Kanal sorgt dafür, dass die Genehmigung auch dann funktioniert, wenn die genehmigende Person nicht angemeldet ist, und er schwächt die Prüfung an keiner Stelle: Ein Klick auf den Link gewährt für sich genommen gar nichts.
Zeitlich befristet und jederzeit widerrufbar
Eine genehmigte Freigabe ist an beiden Enden begrenzt.
| Typischer SaaS-Supportzugriff | Venvera Engineer-Zugriff |
|---|---|
| Support und Engineering haben stehenden Zugriff auf Kundendaten. Sie vertrauen einer Richtlinie und können in der Regel nicht sehen, wann dieser Zugriff genutzt wird. | Kein stehender Zugriff. Jede Freigabe ist eine genehmigte Einzelanfrage mit Beginn, Ablauf und einer namentlich benannten genehmigenden Person auf Ihrer Seite. |
| Einmal erteilter Zugriff bleibt meist bestehen. Ihn zu entziehen ist eine manuelle Aufräumaufgabe, die häufig unterbleibt. | Der Zugriff endet von selbst. Die Anzeigesitzung, die ein Engineer erhält, ist auf den Ablaufzeitpunkt der Freigabe gedeckelt und lässt sich damit nicht über das von Ihnen genehmigte Fenster hinaus dehnen. |
| Zugriff zu widerrufen bedeutet, ein Ticket beim Anbieter zu eröffnen und darauf zu warten, dass jemand es bearbeitet. | Jeder Mandanten-Administrator, auch über die ursprünglich genehmigende Person hinaus, kann eine aktive Freigabe sofort über das Zugriffs-Dashboard widerrufen. |
Das Maximum, das eine einzelne Anfrage verlangen kann, sind 24 Stunden. Kürzer ist der Normalfall: Eine einstündige Freigabe für eine schnelle Reproduktion ist üblich. Entscheidend ist, dass der Zugriff von Anfang an ein eingebautes Ende hat, statt darauf zu bauen, dass jemand daran denkt, ihn wieder zu entziehen.
Die Anfrage und ihre Entscheidungen stehen in Ihrem Audit-Log
Sie müssen dem Ablauf nicht blind vertrauen, denn die Anfrage und jede Entscheidung darüber werden in Ihrem eigenen Mandanten-Audit-Log festgehalten, direkt neben dem Live-Status auf Ihrem Zugriffs-Dashboard.
- Die ursprüngliche Anfrage, einschließlich der Begründung und der beantragten Dauer.
- Die Genehmigung oder Ablehnung, einschließlich des genutzten Kanals, in der App oder per E-Mail.
- Der Widerruf, sofern es einen gab, einschließlich der Angabe, welcher Mandanten-Administrator ihn ausgelöst hat.
Jede Freigabe trägt ihren eigenen Startzeitpunkt, ihren Ablauf und ihre namentlich benannte genehmigende Person. So sehen Sie genau, wann ein Fenster geöffnet wurde, wann es sich geschlossen hat und wer es autorisiert hat. Das ist ein Nachweis über die Anfrage und die dazu getroffenen Entscheidungen. Das Zugriffs-Dashboard unter /tenant-access zeigt offene, aktive und abgeschlossene Anfragen an einem Ort.
Warum das für NIS2 und DORA zählt
Wenn Sie ein Compliance-Programm betreiben, ist der Zugriff Dritter auf Ihre Daten etwas, das Ihre eigenen Rahmenwerke Ihnen zu steuern auftragen. Unter NIS2 ist Lieferkettensicherheit eine ausdrückliche Pflicht. Unter DORA gehören Ihre IKT-Drittdienstleister und die Zugriffe, die sie halten, in Ihr Informationsregister und in Ihre Überwachungsvorkehrungen. ISO 27001 Anhang A behandelt Lieferantenbeziehungen und privilegierte Zugriffe im selben Geist.
Venvera ist gegenüber seinen Kunden selbst ein IKT-Dienstleister. Der hier beschriebene Genehmigungsablauf gehört zu dem, was Ihnen erlaubt, die Fragen zum Lieferantenzugriff in diesen Rahmenwerken mit etwas Konkretem zu beantworten: Der Zugriff über den Support-Pfad ist standardmäßig gesperrt, wird nur pro Anfrage gewährt, ist zeitlich befristet, widerrufbar und auf Ihrer Seite protokolliert. Das ist eine weit belastbarere Antwort als ein Absatz in einem Anbieterrichtliniendokument.
Stellen Sie dieselbe Frage jedem SaaS-Anbieter, der Ihre regulierten Daten hält, und achten Sie auf die Form der Antwort. "Der Zugriff ist gemäß unserer Sicherheitsrichtlinie auf autorisiertes Personal beschränkt" beschreibt eine Absicht. Eine Genehmigung pro Anfrage, die Sie einsehen, widerrufen und aus Ihrem eigenen Audit-Log exportieren können, beschreibt eine Kontrolle. Nur eine davon gibt einer prüfenden Person etwas in die Hand, aus dem sie eine Stichprobe ziehen kann.
Ein Prüfer wird danach fragen. "Wie steuern Sie den Zugriff Ihrer SaaS-Anbieter auf Ihre regulierten Daten?" ist eine gängige Frage in einer NIS2- oder DORA-Prüfung. Einen Genehmigungsablauf pro Anfrage vorzeigen zu können, zeitlich befristet und im Audit-Log erfasst, ist eine saubere Antwort.
Umfang und Grenze dieser Kontrolle
Es lohnt sich, die Grenze dieser Kontrolle präzise zu ziehen. Der Genehmigungsablauf ist ein prozessuales Tor. Die Anwendungsschicht von Venvera hält den mandantenspezifischen Schlüssel, der nötig ist, um auf Ihren Daten zu arbeiten, und die Genehmigung eines Mandanten-Administrators ist das, was den Support-Pfad durch diese Schicht öffnet. Der Ablauf garantiert, dass dieser Pfad standardmäßig geschlossen ist, nur mit Ihrer ausdrücklichen und dokumentierten Zustimmung geöffnet wird und sich automatisch wieder schließt, sobald das Fenster endet.
Der Entschlüsselungsschlüssel bleibt dabei in der Plattform. Ein kundenseitig gehaltener Schlüssel, den selbst Venvera-Mitarbeitende nicht nutzen könnten, wäre eine andere Kontrolle, und dieser Ablauf beansprucht nicht, sie zu liefern. Was dieser Ablauf liefert, ist ein standardmäßig geschlossenes, pro Anfrage genehmigtes, zeitlich befristetes und im Audit-Log erfasstes Tor vor dem Mitarbeitendenzugriff über den Support-View-as-Pfad.
Wenn ein Anbieter Ihnen sagt, kundenverwaltete Schlüssel machten Mitarbeitendenzugriff unmöglich, lesen Sie das Kleingedruckte dazu, welche Operationen weiterhin innerhalb seiner Plattform laufen. Schlüsselverwahrung und Zugriffssteuerung sind getrennte Kontrollen, und die meisten Produkte, die die erste anbieten, brauchen weiterhin die zweite. Wir ziehen es vor, die Grenze klar zu benennen, statt Sie mit einer Garantie gehen zu lassen, die wir nicht gegeben haben.
Für diesen Pfad gilt der Standard: Ihre Mandantendaten bleiben Ihre Daten, und Venvera-Mitarbeitende öffnen sie nur, wenn Sie es sagen, so lange Sie es sagen, mit der Anfrage und ihrer Genehmigung auf dem Papier.
