Sicherheit der Serverruntime

A4SWIFT Nachrichtenreparatur und neue Übermittlung steuert den Fluss von SWIFT-Nachrichten zwischen Geschäftsbenutzern, Back-End-Systemen und SWIFT-Netzwerkendpunkten auf sichere und deterministische Weise. Es authentifiziert Nachrichten, die von Geschäftsbenutzern übermittelt werden, überprüft Nachrichten auf Daten- und Geschäftsregelkorrektheit und leitet Nachrichten an Back-End-Systeme oder für die endgültige Übermittlung an das SWIFT-Netzwerk weiter. Weitere Informationen zu digitalen Zertifikaten finden Sie unter "Verschlüsselungs- und Signaturzertifikate" auf der MSDN Library-Website unter https://go.microsoft.com/fwlink/?linkid=50285.

Nachrichtenreparatur und neue Übermittlung ist eine BizTalk Server Orchestrierungsanwendung, die im BizTalk Server Sicherheitskontext gehostet und ausgeführt wird. Es wird als BizTalk Server Anwendung durch die oben beschriebenen BizTalk Server Sicherheitsfeatures geschützt. Nachrichtenreparatur und neue Übermittlung definiert und erzwingt auch Sicherheitsrichtlinien auf Benutzerebene, die für die Erstellung, Reparatur, Genehmigung und Übermittlung von SWIFT-Nachrichten spezifisch sind:

  • Alle Nachrichten, ob neu oder repariert, die über die Nachrichtenreparatur und neue Übermittlung an BizTalk Server übermittelt werden, müssen von einem vertrauenswürdigen Benutzer stammen.

  • Vertrauenswürdige Benutzer, die Nachrichten erstellen oder reparieren, müssen über die richtige Autorisierung und die richtigen Rechte verfügen. Vertrauenswürdige Benutzer, die Nachrichten genehmigen oder ablehnen, müssen über die richtige Autorisierung und die richtigen Rechte verfügen.

  • Alle Nachrichten müssen von einer bekannten Anzahl vertrauenswürdiger Benutzer genehmigt werden. Jeder vertrauenswürdige Benutzer in der Kette von Nachrichtenerstellern, -reparaturern und genehmigenden Personen muss eindeutig sein. Derselbe Benutzer kann keine Nachricht erstellen, reparieren und genehmigen oder ablehnen. Derselbe Benutzer kann in einem mehrstufigen Genehmigungsprozess keine Genehmigungs- oder Ablehnungsentscheidungen für eine einzelne Nachricht eingeben. Sie können ihre eigenen erstellten oder reparierten Nachrichten nicht genehmigen oder dieselbe Nachricht wie mehrere genehmigende Personen genehmigen.

  • Sie können eine Nachricht während des Genehmigungsprozesses nicht ändern (das heißt, eine Nachricht kann nach der ursprünglichen Übermittlung an Nachrichtenreparatur und Neue Übermittlung als neue oder reparierte Nachricht nicht geändert werden).

  • Nachrichten, die während einer Überprüfungsphase für einen erneuten Schlüssel geändert wurden, müssen genau mit der ursprünglichen Nachricht übereinstimmen (entweder erstellt oder repariert).

    Um diese Sicherheitssemantik zu erzwingen, überprüft die Nachrichtenreparatur und neue Übermittlung die digitale Signatur, die in jeder empfangenen XML-Nachricht eingebettet ist, in jeder Phase des Erstellungs- oder Reparaturgenehmigungsübermittlungsprozesses. Die Überprüfung der digitalen Signatur "Nachrichtenreparatur" und "Neue Übermittlung" führt die folgenden Überprüfungen aus. Wenn eine oder mehrere dieser Überprüfungen fehlschlägt, wird die Nachrichtenreparatur und neue Übermittlung beendet und über das Meldungsfeld beibehalten, und ein Sicherheitsfehler wird im Ereignisprotokoll protokolliert:

  • Die XML-Nachricht muss digital signiert sein und daher eine entsprechende digitale Signatur enthalten.

  • Jede digitale Signatur, die im Workflow verwendet wird, muss mithilfe eines vertrauenswürdigen digitalen Zertifikats erstellt werden. Dadurch wird sichergestellt, dass der Ersteller, der Reparatureur, der Prüfer und die genehmigenden Personen vertrauenswürdig sind.

  • Jedes vertrauenswürdige digitale Zertifikat muss einem Windows-Domänenbenutzer gehören, der mitglied in der Domänengruppe ist und über logische Berechtigungen oder Rechte zum Ausführen von Aktionen in A4SWIFT verfügt. Dadurch wird sichergestellt, dass jeder Teilnehmer am Erstellungs- oder Reparaturgenehmigungs-Übermittlungsprozess über die richtigen Berechtigungen oder Rechte zum Ausführen der spezifischen Aktion verfügt, die er ausgeführt hat.

    Die obigen Regeln werden über ACLs auf der SharePoint-Website über Websitebenutzergruppen und den Formularsendencode erzwungen. Wenn sich der Benutzer, der auf die Nachricht handelt, nicht in der Gruppe A4SWIFT Benutzer (Domäne oder lokal) befindet, werden die Nachrichtenreparatur und neue Übermittlung abgelehnt.

    Beispielsweise kann ein organization, der einen dreistufigen Genehmigungsprozess erzwingt, diese drei logischen Rollen definieren: Repairer, Verifiers (Neuschlüsselphase) und Genehmigende Personen. Entsprechend müssen die Benutzer, die an den Rollen teilnehmen, der Domänengruppe A4SWIFT Benutzer angehören. Um die SharePoint-Website weiter zu sperren, sollten die Benutzer in logische Domänengruppen (z. B. Reparaturen, Prüfer, genehmigende Personen) organisiert werden.

    Weitere Informationen zu Websitebenutzergruppen finden Sie unter Windows SharePoint Services Security.

  • Jede digitale Signatur im Stapel muss eindeutig sein. Das heißt, jede digitale Signatur muss mithilfe eines eindeutigen digitalen Zertifikats (relativ zu den anderen Signaturen im selben Stapel) erstellt werden. Dadurch wird sichergestellt, dass die Nachricht nicht von der Person genehmigt wurde, die die Nachricht erstellt/repariert hat, und dass keine Person dieselbe Nachricht wie mehrere genehmigende Personen genehmigt hat.

    Nachrichtenreparatur und neue Übermittlung erzwingen strenge Sicherheitsrichtlinien, indem prüfpunkte an jedem Einstiegspunkt in die Nachrichtenerstellungs-, Reparatur-, Genehmigungs- und Übermittlungsinfrastruktur vorhanden sind. Diese Prüfpunkte sind eng mit den Kernfunktionen von Nachrichtenreparatur und neuer Übermittlung gekoppelt und können nicht umgangen werden. Während die Nachrichtenreparatur und neue Übermittlung für die nahtlose Integration in die InfoPath-Formularsignaturfunktion konzipiert ist, ist sie auch so konzipiert, dass sie sicher und robust genug ist, um die Authentizität und den Schutz von SWIFT-Nachrichten zu erzwingen, auch wenn InfoPath nicht verwendet wird und Nachrichten von Endbenutzern direkt an Die Endpunkte "Nachrichtenreparatur" und "Neue Übermittlung" (SharePoint-Webordner) gesendet werden.