Was hat Ihr Unternehmen eigentlich über seine Sicherheit öffentlich gemacht? Jeder Security-Review beginnt mit denselben drei Anfragen, DSGVO Art. 28(2) macht eine davon zur Vertragspflicht, und die Antworten leben in E-Mail-Anhängen und Ad-hoc-Seitenänderungen — ein Plädoyer dafür, öffentliche Sicherheits-Offenlegung als Register zu behandeln, das man aufzählen kann, in das man absichtlich veröffentlicht und aus dem man zurückziehen kann.
Jeder Security-Review, der Sie erreicht, beginnt mit denselben drei Anfragen: Zertifizierungen zeigen, Subprocessors (DSGVO: «weitere Auftragsverarbeiter») auflisten, Framework-Status angeben. Sie kommen vor dem NDA, oft vor dem ersten Gespräch, und jede einzelne ist für sich leicht zu beantworten: Jemand leitet das Zertifikats-PDF weiter, jemand verlinkt die Subprocessor-Seite, jemand kopiert die Framework-Zusammenfassung ins Portal des Käufers. Haben Sie die Frage schon einmal andersherum gestellt? Was genau hat Ihr Unternehmen über seine Sicherheit öffentlich gemacht, wer hat jedes einzelne Stück nach draussen gestellt, und könnten Sie irgendetwas davon zurücknehmen? Versuchen Sie, diese Liste zu erzeugen. Wenn die Antwort ein Ordner voller PDFs und eine Seiten-Änderungshistorie ist, dann ist die Liste selbst das, was es zu bauen lohnt. Ich möchte Sie davon überzeugen, dass sie genau drei Eigenschaften braucht.
Ein Hinweis zur deutschen Fassung dieses Beitrags: Alle Zitate aus DSGVO und NIS2 folgen der amtlichen deutschen Fassung auf EUR-Lex.
Die Subprocessor-Anfrage hat Regulierungstext direkt unter sich. Lesen wir Art. 28 der DSGVO, denn er erklärt Ihre Subprocessor-Seite. Art. 28(1) legt die Seite des Verantwortlichen fest: «Erfolgt eine Verarbeitung im Auftrag eines Verantwortlichen, so arbeitet dieser nur mit Auftragsverarbeitern, die hinreichend Garantien dafür bieten, dass geeignete technische und organisatorische Maßnahmen so durchgeführt werden, dass die Verarbeitung im Einklang mit den Anforderungen dieser Verordnung erfolgt und den Schutz der Rechte der betroffenen Person gewährleistet.» Käufer-Due-Diligence in ihrer heutigen Form folgt aus diesem Satz: Ein Verantwortlicher, der Sie einsetzen will, trägt die Pflicht, Ihre Garantien zu prüfen, bevor die Verarbeitung beginnt. Deshalb kommen die Fragen früh und schriftlich.
Art. 28(2) legt die Seite des Auftragsverarbeiters fest, und er ist es wert, vollständig zitiert zu werden:
«Der Auftragsverarbeiter nimmt keinen weiteren Auftragsverarbeiter ohne vorherige gesonderte oder allgemeine schriftliche Genehmigung des Verantwortlichen in Anspruch. Im Fall einer allgemeinen schriftlichen Genehmigung informiert der Auftragsverarbeiter den Verantwortlichen immer über jede beabsichtigte Änderung in Bezug auf die Hinzuziehung oder die Ersetzung anderer Auftragsverarbeiter, wodurch der Verantwortliche die Möglichkeit erhält, gegen derartige Änderungen Einspruch zu erheben.»
Eine gesonderte Genehmigung pro Änderung skaliert nicht für einen Auftragsverarbeiter mit Hunderten von Verantwortlichen, also landen Auftragsverarbeitungsverträge (AVV) beobachtbar bei der allgemeinen schriftlichen Genehmigung, und die aktiviert den zweiten Satz. Die öffentliche Subprocessor-Seite, mit einem Änderungs-Benachrichtigungsmechanismus dahinter, ist die Art, wie Teams diese Informationspflicht in der Praxis tragen. Art. 28(3)(d) schliesst den Kreis: Der Vertrag selbst muss festlegen, dass der Auftragsverarbeiter «die in den Absätzen 2 und 4 genannten Bedingungen für die Inanspruchnahme der Dienste eines weiteren Auftragsverarbeiters einhält». Zusammen gelesen machen die Absätze die Subprocessor-Seite zum sichtbaren Ende einer Vertragskette, und ihre Richtigkeit ist das, was die Kette voraussetzt.
Die anderen beiden Anfragen haben ein Lieferketten-Analogon in NIS2. Art. 21(2)(d) setzt «Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern» auf die Mindestliste der Risikomanagementmassnahmen. Da NIS2 eine Richtlinie ist, die Unternehmen über nationale Umsetzung erreicht, kommt sie bei Ihnen vor allem als Lieferanten-Due-Diligence Ihrer regulierten Kunden an. Die Nachfrage nach Offenlegung ist strukturell; sie hängt nicht von der Gründlichkeit eines einzelnen Käufers ab.
Verstreute Offenlegung kann ihre eigene Inventarfrage nicht beantworten
Schauen wir uns an, wie die Antworten tatsächlich rausgehen. Das Zertifikat geht als E-Mail-Anhang raus. Die Subprocessor-Liste lebt auf einer CMS-Seite, die jemand bearbeitet, wenn ein neuer Anbieter live geht, oder ein paar Wochen danach. Der Bericht zirkuliert unter NDA und sitzt jetzt in Posteingängen, die Sie nicht kontrollieren. Diesem Setup fehlen drei Eigenschaften, und jede entspricht einem konkreten Versagen.
Erstens: Nichts zählt auf. Ihre öffentliche Offenlegung ist die Vereinigung aller Seitenänderungen und aller versendeten Anhänge, und nirgends existiert eine Liste davon. Die Subprocessor-Seite gegen den AVV-Anhang abzugleichen ist manuelle Diff-Arbeit. Das zählt, weil die Informationspflicht aus Art. 28(2) voraussetzt, dass die veröffentlichte Liste der Realität folgt; eine Seite, die niemand abgleicht, driftet von dem Vertrag weg, der auf sie verweist, und die Drift bleibt unsichtbar, weil es kein Register gibt, gegen das man sie prüfen könnte.
Zweitens: Veröffentlichung ist nie ein expliziter Akt. Ein weitergeleiteter Anhang ist implizite Veröffentlichung: Der Leserkreis wächst mit jeder Weiterleitung um einen Posteingang, und niemand hat eine Handlung vollzogen, auf die man hinterher zeigen könnte. Wenn die Frage «Wer hat entschieden, dass das öffentlich ist?» aufkommt, gibt es keine Entscheidung im Protokoll. Die Datei hat sich einfach bewegt.
Drittens: Zurückziehen existiert nicht. Einen Anhang kann man nicht zurücksenden; eine ersetzte Seite hängt in Caches und Web-Archiven nach; ein geleakter Link löst weiter auf. Die Operation, die man sich an dem Tag wünscht, an dem ein Zertifikat abläuft oder ein Anbieter rausfliegt — nimm das zurück, überall, wo es ausgeliefert wird — hat keine Implementierung.
Offenlegung als Register
Der Zug ist dieser: Behandeln Sie öffentliche Sicherheits-Offenlegung so, wie Sie Ihr Asset-Inventar oder Ihre Zugriffsliste schon behandeln, als Register mit definierten Eigenschaften, absichtlich gepflegt. Drei Eigenschaften decken die Ausfälle oben ab; definieren wir sie:
- Aufzählbar. Es gibt eine abfragbare Liste veröffentlichter Elemente. «Was haben wir öffentlich gemacht?» liefert Zeilen zurück. Den AVV-Anhang, die Review-Antwort und die öffentliche Seite abzugleichen wird zu einem Lookup gegen dieselbe Liste statt zu drei getrennten Suchjobs.
- Absichtlich. Veröffentlichen ist ein expliziter Akt, pro Element durch eine identifizierbare Person vollzogen und protokolliert. Nichts wird als Nebenwirkung einer E-Mail oder einer CMS-Änderung öffentlich. Und weil die Einheit der Veröffentlichung das Element ist, kann das Register sagen, wann jedes Ding öffentlich wurde und durch wen.
- Widerruflich. Zurückziehen ist eine Operation mit definiertem Ergebnis: Das Element verlässt das Register und wird nicht mehr ausgeliefert. Weil geleakte Links ein realer Fehlermodus sind, sollte die öffentliche Oberfläche des Registers als Ganzes kappbar sein: Landet der Endpunkt irgendwo, wo er nicht hingehört, rotieren Sie ihn, und die alte Referenz stirbt.
Nichts davon entscheidet, was Sie veröffentlichen. Ob eine Zertifikatsdatei herunterladbar sein sollte oder nur ihre Existenz genannt, ob ein Subprocessor-Eintrag Details über Name und Zweck hinaus tragen sollte — das bleiben Ermessensentscheidungen, pro Element getroffen. Ein Register gibt Ihnen das Inventar und den Akt; die Policy bleibt Ihre. Es verlangt auch kein Spezialwerkzeug: Eine reviewte Tabelle und ein Build-Schritt, der sie rendert, reichen. Was mich stört, ist die Asymmetrie: Jedes andere Artefakt, von dem Ihr Compliance-Programm abhängt (Assets, Zugriffe, Risiken), bekommt diese Behandlung bereits, und die öffentliche Offenlegung, das eine Artefakt, das Fremde tatsächlich sehen, meistens nicht.
Das kleinste Register, mit dem wir durchkommen konnten
devguard liefert dieses Register als Trust-Center-Modul aus, und ich möchte die Design-Entscheidung dahinter selbst vertreten: Wir haben das kleinste Register gebaut, mit dem wir durchkommen konnten, und wir haben es mit Absicht API-only gemacht. Hier ist, wie die drei Eigenschaften landen, und was der Minimalismus kostet.
Absichtlich: Das Trust Center ist ab Werk ausgeschaltet, und nichts wird öffentlich, bis Sie es aktivieren und Elemente einzeln veröffentlichen. Genau drei Arten von Dingen lassen sich veröffentlichen: eine Framework-Adoption, ein Anbieter, der als Subprocessor agiert, eine Zertifikatsdatei. Dieselbe Sache lässt sich kein zweites Mal veröffentlichen. Jedes Veröffentlichen, Zurückziehen, Aktivieren und jede Link-Rotation landet mit dem Namen der handelnden Person im Aktivitätsprotokoll. «Wer hat es veröffentlicht?» ist damit eine Log-Abfrage.
Aufzählbar: Die öffentliche Ansicht ist eine Liste der veröffentlichten Elemente und sonst nichts — jede Information, die sie zeigt, steht dort mit Absicht, und die Admin-Vorschau zeigt exakt das, was die Welt sehen würde.
Widerruflich: Zurückziehen entfernt das Element sofort, und die öffentliche Ansicht prüft die Gültigkeit bei jedem Abruf erneut: Archivierte Anbieter, gelöschte Adoptionen und abgelaufene Zertifikate fallen von selbst heraus, weil wir lieber gar nichts zeigen als ein veraltetes SOC 2. Der öffentliche Link selbst ist ein opakes Handle; leakt er, rotieren Sie ihn: Der neue Link funktioniert, der alte stirbt. Ein deaktiviertes Register ist ausserdem von einem nicht existierenden nicht zu unterscheiden: Ein unbekannter Link und ein bekannter, aber deaktivierter antworten identisch und geben nichts preis.
Der Preis ist real, und wir haben ihn gewählt: Das Trust Center ist API-only. devguard liefert die veröffentlichten Daten (Frameworks, Subprocessors, Zertifikate) über einen öffentlichen Endpunkt unter diesem opaken Handle aus, und Ihre Website rendert sie. Headline, Intro und jede Prosa gehören Ihnen; wir speichern sie nicht. Wenn Sie eine gehostete Trust-Seite wollen, auf die Sie den Einkauf zeigen können, ohne etwas zu bauen: Das hier ist keine, und das ist Absicht. Ich finde, Ihre öffentlichen Texte sollten durch die Hände gehen, denen Ihre öffentlichen Texte gehören.
Eine Abfrage
Die Frage vom Anfang — was hat Ihr Unternehmen über seine Sicherheit öffentlich gemacht? — sollte eine Abfrage kosten, egal, womit Sie das Register bauen. Sie macht auch die drei Anfragen billiger: Die Review-Antwort wird zu einem Link auf die Liste plus der Handvoll Elemente, die NDA-Handling brauchen, statt zu einer Suche durch gesendete Mails. Und sie gibt der Informationspflicht aus Art. 28(2) etwas, woran sie sich festmachen kann, denn eine Liste, die sich mit Absicht ändert, kann mit Absicht benachrichtigen. Wenn Sie dieses Quartal auf der Einkäuferseite des Tischs sitzen, funktioniert dieselbe Close-Reading-Gewohnheit auch in die andere Richtung: siehe das Wechselkapitel der Datenverordnung, als Einkäufer gelesen.
Das Trust Center ist Teil der devguard-Plattform.