Wie erkennt man kritische Konfigurationen und Datenabfluss?

Jede Dataverse-Umgebung hat Türen nach draußen. Die meisten sind gewollt: die Anbindung ans ERP, ein Datenexport zu Datev, der Mailversand, eine API Abfrage oder die Dokumentenablage. Kritisch wird es bei den Türen, die niemand mehr auf dem Schirm hat. Die gute Nachricht: Fast alle diese Wege hinterlassen Spuren im Solution-Export, und man kann sie systematisch absuchen.

Die Inventur der Außenverbindungen

HTTP-Aktionen in Flows. Die Definitionen der Flows liegen im Lösungs-Export als JSON bereit, und eine HTTP-Aktion steht dort mit voller Zieladresse. Eine Suche über den Workflows-Ordner liefert die Liste aller Endpunkte, die per Flow angesprochen werden. Jede Adresse darauf sollte jemand zuordnen können, besonders die, die nicht nach dem eigenen Unternehmen aussehen.

Connection References und Custom Connectors. Sie verraten, welche Dienste überhaupt angebunden sind: Standardconnectors sind am Namen erkennbar, eigene Connectors bringen ihre Zieladresse mit. Ein Connector zu einem Dienst, den die Organisation offiziell gar nicht nutzt, ist ein Fund, dem man nachgehen sollte, ob dahinter Schatten-IT steckt oder ein Altprojekt.

Webhooks und Service-Endpunkte. Die klassische Variante der Außenanbindung: Plattformereignisse, die an eine externe Adresse oder einen Service Bus gemeldet werden. Sie stehen als eigene Komponenten im Export. Gerade hier lohnt der Blick, weil diese Registrierungen oft aus frühen Projektphasen stammen und still weiter Daten senden, auch wenn das Ziel längst niemand mehr betreibt.

Skripte mit externen Aufrufen. JavaScript-Web-Ressourcen, die Adressen außerhalb der eigenen Umgebung aufrufen, finden sich per Textsuche über den entpackten Bestand. Unverschlüsselte Ziele sind dabei ein doppelter Fund. Ähnlich verhält es sich mit nachladenden Javascript Bibliotheken die zur Laufzeit vom Server geholt werden. Ist die entsprechende Bibliothek kompromittiert kann das zu erheblichen Problemen führen.

Was der Export nicht sieht

Ehrlichkeit gehört zur Inventur: Kompilierter Plug-in-Code ist im Export nicht lesbar. Ein Plug-in kann Daten an beliebige Ziele senden, ohne dass der Export es zeigt. Sichtbar sind nur die Registrierungen, also auf welchen Ereignissen der Code läuft. Bei Assemblies aus unklarer Quelle hilft nur der Quellcode oder das Gespräch mit dem Hersteller. Ebenfalls unsichtbar: alles, was außerhalb der Lösung direkt gegen die API arbeitet.

Kritisch ist eine Kombination, nicht ein Fund

Eine HTTP-Aktion ist für sich kein Problem. Kritisch wird die Kombination: ein Ereignis auf einer Tabelle mit sensiblen Daten, ein externes Ziel, das niemand zuordnet und keine Dokumentation dazu. Deshalb funktioniert die Prüfung am besten als Kreuztabelle: Welche Außenverbindung hängt an welcher Tabelle, und wer bestätigt, dass sie gewollt ist?

Diese Liste einmal aufzustellen dauert bei einer normalen Lösung einen Vormittag. Sie aktuell zu halten kostet danach fast nichts, denn neue Außenverbindungen kommen selten dazu. Und im Ernstfall, bei einer Datenschutzanfrage oder einem Vorfall, ist genau diese Liste das Dokument, das man sofort braucht und nie schnell genug erstellen kann.