Wichtige Sicherheitshinweise für die Geschäftsregel-Engine
In diesem Thema werden bekannte Sicherheitsprobleme in Microsoft BizTalk Server und die Schritte zusammengefasst, die Sie ergreifen müssen, um die Sicherheitsrisiken zu minimieren.
Böswillige Schemaeingabe verursacht Denial-of-Service-Angriff
Beim Bestätigen von Fakten wird jede Regel anhand jedes Objekts überprüft, das den unterstützten Typen in einer Richtlinie entspricht. Angenommen, es gibt in einer Richtlinie eine Regel, die eines der Elemente in einem Schema verwendet, das mithilfe eines Selektors übergeben wurde. Wenn nun die Instanz dieses Elements/Attributs, das dem Selektor entspricht, tausende Male wiederholt wird, wird jede Instanz dieser Art bestätigt, was zu Leistungseinschränkungen und in der Folge möglicherweise zu einem Denial-of-Service-Angriff (DoS, Dienstverweigerung) führt.
Um dieses potenzielle Problem zu vermeiden, müssen Sie alle unklaren Eingaben überprüfen, die während der Ausführung einer Richtlinie übergeben werden.
RuleSet überprüft keine Objekte vor der Übermittlung der Fakten
Jedes Schema, instance als Fakt an das RuleSet übergeben wird, wird nicht anhand des Schemas überprüft, bevor Regeln mithilfe von Selektoren durchgesetzt werden. Sie sollten alle Eingaben überprüfen, die während der Ausführung einer Richtlinie übergeben werden.
Erwartetes Verhalten des Geschäftsregelerstellers bei aktivierter RuleStore-Sicherheit
Sie können das rollenbasierte Sicherheitsfeature für den Regelspeicher aktivieren, indem Sie die EnableAuthorization-Methode der RuleStore-Klasse aufrufen. Wenn diese Sicherheitsfunktion aktiviert ist, zeigt der Geschäftsregelersteller folgendes erwartetes Verhalten:
Das Objektmodell filtert Regelsätze und Vokabulare heraus, auf die Benutzer keinen Lesezugriff haben. Sie werden daher nicht im Geschäftsregelersteller angezeigt.
Wenn der Benutzer keinen Schreibzugriff auf eine Richtlinie oder ein Vokabular hat, löst jeder Speicherversuch eine Ausnahme aus.
Benutzertypen für den Regelspeicheradministrator
Der Regelspeicheradministrator verfügt über die Berechtigung zum Definieren einer Autorisierungsgruppe für Elemente, die im Regelspeicher gespeichert sind. Beachten Sie jedoch folgende Unterschiede zwischen zwei Benutzertypen, denen der Regelspeicheradministrator angehören kann:
Wenn der Regelspeicheradministrator ein Windows-Benutzer ist (d. h. er stellt über die Windows-Authentifizierung die Verbindung zum Regelspeicher her), kann er eine Autorisierungsgruppe definieren, deren Benutzer eine Windows-Gruppe oder ein Windows-Benutzer ist.
Wenn der Regelspeicheradministrator ein SQL-Benutzer ist (d. h. er stellt die Verbindung zum Regelspeicher über die SQL-Authentifizierung her), kann er keine Autorisierungsgruppe definieren, deren Benutzer eine Windows-Gruppe ist. Er kann jedoch eine Autorisierungsgruppe mit einem Windows-Benutzer definieren.
Benutzer kann ohne ausreichende Berechtigung keine Autorisierungsgruppe mit einem Element verbinden
Ein Elementersteller, der weder ein SQL DBO-Benutzer noch ein Mitglied von RE_ADMIN_USERS ist und keine MODIFY_DELETE-Berechtigung für ein Element hat, kann eine neue Autorisierungsgruppe nicht mit dem Element verbinden. Das folgende Szenario ist ein Beispiel für dieses Verhalten:
Der Regelsatzersteller ist kein DBO-Benutzer, kein Mitglied der Gruppe RE_ADMIN_USERS und hat keine MODIFY_DELETE-Berechtigung nach dem Erstellen des Regelsatzes.
Der Ersteller erstellt einen Regelsatz.
Das Mitglied der Gruppe RE_ADMIN_USERS erstellt Autorisierung AG1 mit MODIFY_DELETE-Berechtigung für Benutzer2.
Der Ersteller verbindet AG1 mit dem Regelsatz.
Die Regelspeicherautorisierung wird aktiviert.
Das Mitglied der Gruppe RE_ADMIN_USERS erstellt Autorisierung AG2 mit READ_EXECUTE-Berechtigung für Benutzer2.
Der Ersteller verbindet AG2 mit dem Regelsatz. Obwohl der Ersteller nicht über ausreichende Berechtigungen hierfür verfügt, wird keine Fehlermeldung angezeigt.
Der Versuch von Benutzer2, den Regelsatz zu lesen, schlägt fehl.