Bekannte Probleme bei der EDI-Sicherheit
In diesem Thema werden bekannte Probleme mit der Sicherheit von BizTalk Server EDI- und AS2-Lösungen beschrieben.
BizTalk hält keine signierte Nachricht von einer Partei an, für die kein Zertifikat festgelegt ist
Wenn Sie kein Signaturzertifikat für eine Partei festlegen (im Knoten Zertifikat der Seite Parteieigenschaften der Partei), aber eine eingehende Nachricht von der Partei signiert wird, hält BizTalk Server die Nachricht aufgrund des fehlenden Zertifikats nicht an und löst keine Ausnahme aus.
Wenn Sie eingehende Nachrichteneigenschaften (auf der Seite Partei als AS2-Nachrichtenabsender) außer Kraft setzen und die Eigenschaft Nachricht muss signiert sein deaktivieren, dann hält BizTalk Server eine signierte eingehende Nachricht an.
Einschränken des Zugriffs auf den Ordner „Programme“, um Manipulationen von Dateien zu verhindern
Wenn der Ordner Programme, der die ausführbaren Dateien von BizTalk Server und EDI-Schemas enthält, für nicht authentifizierte Benutzer verfügbar ist, dann können diese Benutzer die entsprechenden Dateien möglicherweise ändern. Zum Schutz vor dieser Bedrohung können Sie Zugriffssteuerungslisten (Access Control Lists, ACLs) für den Ordner Programme verwenden, um den Zugriff auf vertrauenswürdige Benutzer einzuschränken.
Ein Schema mit einem langen Feld kann für einen Denial-of-Service-Angriff anfällig sein
Ein benutzerdefiniertes Schema mit einem sehr langen Feld könnte möglicherweise von einem Denial-of-Service-Angriff ausgenutzt werden. Schemas, die mit BizTalk Server ausgeliefert werden, haben keine Felder mit großer Länge und sind daher im Allgemeinen nicht anfällig für einen solchen Angriff.
Abbrechen der Nachrichtenverarbeitung, wenn eine Kontrollnummer die maximale Länge überschreitet
Die Kontrollnummer eines Austauschs, einer Gruppe oder eines Transaktionssatzes besitzt eine eingeschränkte maximale Länge. Wenn die Länge einer dieser Kontrollnummern die maximale Länge überschreitet, wird die Verarbeitung aller Nachrichten dieses Codierungstyps für eine einzelne Partei abgebrochen. Eine Nachricht eines anderen Codierungstyps (z. B. EDIFACT anstelle von X12) ist nicht betroffen. Dies könnte ein Sicherheitsrisiko darstellen.
Wenn die Länge einer Sequenznummer die maximale Länge überschreitet, muss der Benutzer die Sequenznummer in der EDI-Eigenschaft für die betroffene Partei zurücksetzen. Nachdem die Nummer zurückgesetzt wurde, können alle Nachrichten dieses Codierungstyps erneut verarbeitet werden.
Bei X12-Nachrichten umfasst die maximale Länge der Kontrollnummer neun Ziffern. Bei EDIFACT-Nachrichten umfasst die maximale Länge der Kontrollnummer 14 Ziffern über drei Felder.
Verwenden der EDI-Empfangspipeline mit einem HTTP-Adapter lässt die Verbindung geöffnet, wenn keine Bestätigung gesendet wird
Wenn Sie einen Empfangsspeicherort erstellen, der die EDIReceive-Pipeline und den Transporttyp HTTP verwendet, kann ein Sicherheitsproblem auftreten. Von der EdiReceive-Pipeline wird keine HTTP-Bestätigung vom Typ „200 OK“ generiert. Wenn keine EDI-Bestätigung zurückgegeben wird, wird die Verbindung nicht ordnungsgemäß beendet, sondern bleibt geöffnet. Für die Verbindung tritt ein Timeout auf, wenn die Timeoutzeitspanne abgelaufen ist.
Dies gilt nicht für die AS2EdiREceive-Pipeline.
Eine X12-codierte Nachricht wird angehalten, wenn die portbasierte Authentifizierung aktiviert ist und BizTalk Server nicht auf Autorisierungs- und Sicherheitsinformationen zugreifen kann
Symptom
Wenn eine Nachricht über einen Empfangsport empfangen wird, für den die Authentifizierung aktiviert ist, und die Partei, die die Nachricht gesendet hat, nicht ermittelt werden kann, wird die Nachricht von BizTalk Server angehalten.
Mögliche Ursache
Wenn die Authentifizierung für einen Empfangsport aktiviert ist (die Eigenschaft Keine Authentifizierung ist für den Empfangsport deaktiviert), müssen in BizTalk Server Einstellungen für die Eigenschaften ISA1-2 (Autorisierungsqualifizierer und -informationen) und ISA3-4 (Sicherheitsqualifizierer und -informationen) festgelegt werden, damit der Austausch verarbeitet werden kann. Diese Eigenschaften werden auf der Seite X12-Austauschverarbeitungseigenschaften für die Partei als Austauschabsender festgelegt. Wenn BizTalk Server die Werte dieser Eigenschaften nicht ermitteln kann, wird die Nachricht angehalten.
Dies kann in zwei Varianten erfolgen. Im ersten Fall, wenn also die Partei, die die Nachricht gesendet hat, nicht von BizTalk Server ermittelt werden kann, werden die globalen EDI-Eigenschaften verwendet, und BizTalk Server kann nicht auf die Autorisierungs- und Sicherheitseinstellungen zugreifen. Folglich wird die Nachricht angehalten. Im zweiten Fall, wenn zwar die Partei von BizTalk Server ermittelt werden kann, die Eigenschaften ISA1-2 und ISA3-4 für die Partei jedoch nicht konfiguriert sind, kann BizTalk Server wieder nicht auf Autorisierungs- und Sicherheitsinformationen zugreifen, und die Nachricht wird angehalten.
Lösung
Stellen Sie sicher, dass die Partei, von der die Nachricht gesendet wird, identifiziert werden kann und die Eigenschaften ISA1-2 und ISA3-4 in der Parteivereinbarung definiert sind.