Microsoft ist kein Cloud-Dienst
Eine Zeile im Dienstleisterverzeichnis beantwortet die Frage nach der Cloud-Nutzung nicht: Exchange Online, Teams und Entra ID sind drei Dienste mit verschiedenen Datenstandorten und Ausstiegswegen. Warum OPS.2.2 das Bezugsobjekt je Dienst verlangt und was ein Erprobungsdatum am Ausstieg leistet.
Im Verzeichnis der Dienstleister steht eine Zeile: Microsoft. Daneben ein Vertrag, ein Ansprechpartner, vielleicht eine Kritikalität. Damit ist die Frage nach der Cloud-Nutzung beantwortet, so scheint es.
Sie ist es nicht, und zwar aus einem Grund, der nichts mit Sorgfalt zu tun hat: Microsoft ist kein Cloud-Dienst, sondern ein Anbieter. Exchange Online, Teams und Entra ID sind drei Dienste. Sie haben verschiedene Datenstandorte, verschiedene Verantwortliche im Haus, verschiedene Ausstiegswege und im Zweifel verschiedene Unterauftragnehmer.
Warum der Baustein das erzwingt
Der BSI-Baustein OPS.2.2 Cloud-Nutzung verlangt für jeden Cloud-Dienst eine Service-Definition, geklärte Verantwortungsbereiche, einen Nachweis der Informationssicherheit und eine geordnete Beendigung. Ohne ein Verzeichnis der Dienste lässt sich das nicht führen, weil schlicht das Bezugsobjekt fehlt. An eine Anbieterzeile lässt sich keine Service-Definition hängen, weil sie für drei Dienste gleichzeitig gelten müsste.
Ein Cloud-Dienst trägt deshalb Servicemodell und Betriebsmodell, Verfügbarkeit und Servicezeiten, dazu zwei getrennte Verantwortliche: fachlich und IT-seitig. Die Trennung ist kein Formalismus. Wer über die Nutzung entscheidet, ist selten derselbe, der die Anbindung betreibt.
Der Datenstandort ist nicht der Firmensitz
Erfasst werden das Land des Rechenzentrums und, davon getrennt, alle weiteren Verarbeitungsländer. Beides fällt regelmäßig auseinander, etwa wenn der Betrieb in Frankfurt läuft, der Zweitlevel-Support aber nicht in der EU sitzt. Dazu kommen die Unterauftragnehmer je Dienst, denn Artikel 28 DSGVO knüpft daran die Informations- und Widerspruchsrechte.
Der Teil, der beim Einkauf niemanden interessiert
Die Ausstiegssektion beschreibt, wie Sie den Dienst wieder verlassen: Ausstiegsregelung, Kündigungsfrist, Portabilität und Datenformate. Daneben steht ein Feld, das in kaum einem Verzeichnis vorkommt: Ausstieg erprobt am.
Zwischen einer beschriebenen und einer erprobten Ablösung liegt die Frage, ob der Export vollständig ist und ob sich die Daten außerhalb des Dienstes überhaupt noch benutzen lassen. Das erfährt man nicht beim Lesen des Vertrags, sondern beim einmaligen Ausführen. Ein leeres Feld ist an dieser Stelle eine ehrliche Antwort, eine ausgefüllte Ausstiegsregelung ohne Datum dagegen eine Absichtserklärung, die im Ernstfall nichts trägt.
Was das Register nicht ist
Es ersetzt kein bestehendes Verzeichnis. Was im Dienstleisterverzeichnis, im Vertragsmanagement oder beim Auftragsverarbeiter schon gepflegt wird, ist hier ein Verweis. Der Dienst zeigt auf den Anbieter, auf den Vertrag, auf den Auftragsverarbeiter und auf die betroffene Verarbeitungstätigkeit.
Es ist auch keine technische Prüfung. Fehlkonfigurationen in Cloud-Konten findet Cloud Security Posture Management, das dafür in die Konten schaut. Das Register beantwortet die organisatorische Hälfte: welcher Dienst, mit welchen Daten, in welchem Land, mit welchen Unterauftragnehmern und mit welchem Weg wieder heraus.
Und die Anforderungen selbst?
Die stehen nicht im Register. Jeder Cloud-Dienst ist ein Zielobjekt und erscheint damit in der Zielobjekt-Auswahl des Realisierungsplans, neben Prozessen, IT-Systemen und Software. Aus der Detailansicht lassen sich die Anforderungen des Bausteins mit einem Klick dorthin übernehmen, wo Umsetzungsstand, Termin und Verantwortliche ohnehin gepflegt werden. Ein zweiter Ort für dieselbe Sache würde auseinanderlaufen, und zwar zuverlässig.
Mehr auf der Modulseite zum Cloud-Dienste-Register.
Fragen zu dieser Neuerung?
Sprechen Sie mit uns – wir zeigen Ihnen die Funktion gern in einer Demo.