Sicherheitsprobleme in Dynamics 365 Lösungen

Wenn von Sicherheit in Dynamics 365 die Rede ist, denken viele an Angriffe von außen. Die realen Probleme in Lösungen sehen anders aus: Es sind Konfigurationen, welche mehr erlauben als beabsichtigt und die jahrelang niemandem auffallen, weil sie keinen Fehler erzeugen. Die häufigsten Muster, geordnet nach dem Schaden, den sie anrichten können.

Rollen, die zu viel dürfen

Wie man den Rollenbestand systematisch durchgeht werde ich in einem extra Post in naher Zukunft behandeln. Sicherheitsrollen liegen im Lösungs-Export mit jedem einzelnen Recht und dort findet sich das häufigste Problem: Rechte auf Organisationsebene, wo Geschäftseinheit gereicht hätte, Löschrechte für Rollen, die nur lesen sollten, und Rollen, die im Projektverlauf immer weiter geöffnet wurden, weil irgendetwas nicht funktionierte und niemand die eigentliche Ursache suchte.

Das letzte Muster verdient einen eigenen Satz: Rechte erweitern, bis der Fehler weg ist, ist eine verbreitete Debugging-Methode. Die Erweiterungen bleiben dann für immer. Wer eine Rolle prüft, sollte deshalb nicht fragen, ob sie funktioniert, sondern ob jedes einzelne Recht eine Begründung hat.

Sensible Felder ohne Feldsicherheit

Gehaltsdaten, Gesundheitsvermerke, Bankverbindungen: Solche Felder existieren in vielen Umgebungen, und der Tabellenzugriff regelt nur wer den Datensatz sieht und nicht, wer das Feld sieht. Dafür gibt es Feldsicherheitsprofile, und ihre Abwesenheit ist aus dem Export ablesbar: Felder, deren Name nach sensiblem Inhalt klingt, ohne dass die Feldsicherheit aktiviert wäre, sind mindestens eine Rückfrage wert.

Kaskadierendes Löschen an der falschen Beziehung

Beziehungen mit kaskadierendem Löschverhalten entfernen abhängige Datensätze gleich mit. An der Beziehung zwischen Auftrag und Auftragsposition ist das richtig und durchaus gewünschtes Verhalten. An der Beziehung zwischen Firma und all ihren Aktivitäten bedeutet es, dass das Löschen einer einzigen Firma still deren gesamte Historie mitnimmt, selbst wenn wertvolle Informationen in den Aktivitäten vorhanden sind. Das Kaskadenverhalten jeder Beziehung steht im Lösungs Export, und die Kombination aus Löschrecht plus Kaskade ist die Stelle, an der aus einem Versehen ein Datenverlust wird.

Der Rest der Liste

Dazu kommen die Muster aus dem JavaScript-Umfeld, unsichere Skripte und unverschlüsselte Aufrufe, die ich in einem eigenen Artikel behandelt habe, sowie Endpunkte nach draußen: Webhooks und Service-Endpunkte, die Daten an externe Ziele schicken. Letztere sind nicht per se ein Problem, aber jedes Ziel sollte bekannt und aktuell sein. Ein Webhook auf eine Adresse, die niemand mehr zuordnen kann ist ein Datenabfluss der nur noch nicht aufgefallen ist.

Warum das im Export besser sichtbar ist als in der Oberfläche

Die Oberfläche zeigt Rollen und Beziehungen einzeln, auf Dutzende Bildschirme verteilt. Der Export zeigt sie als Gesamtbestand und Sicherheitsprobleme sind fast immer Bestandsprobleme: nicht die eine falsche Einstellung, sondern das Muster über 40 Rollen hinweg. Eine Liste aller Löschrechte auf Organisationsebene über alle Rollen ist in der Oberfläche mühsam und aus dem Export eine Fingerübung.

Die unbequeme Wahrheit zum Schluss: Keine dieser Prüfungen ersetzt die Frage wer die Rollen überhaupt zugewiesen bekommt. Das steht in keinem Export, das steht in der Umgebung und es gehört trotzdem zur selben Inventur.