Beispiel-TMA: Adapter für BizTalk-Message Queuing
In Thema Abschnitt wird die Gefahrenmodellanalyse (Threat Model Analysis, TMA) für das BizTalk-Message Queuing-Adapterszenario für die Beispielarchitektur präsentiert.
Schritt 1: Sammeln von Hintergrundinformationen (BizTalk Message Queuing-Adapterszenario)
In diesem Abschnitt wird das Datenflussdiagramm für das BizTalk-Message Queuing-Adapterszenario für die Beispielarchitektur bereitgestellt. Die folgende Abbildung zeigt die Beispielarchitektur für das HTTP- und SOAP-Adapterszenario.
Abbildung 1: Beispielarchitektur für das BizTalk-Message Queuing-Adapterszenario
Alle anderen Hintergrundinformationen sind für alle unsere Verwendungsszenarien identisch und werden zuvor unter Hintergrundinformationen für Beispielszenarien beschrieben.
Datenflussdiagramm
Die folgende Abbildung zeigt das Datenflussdiagramm für die Beispielarchitektur, wenn der BizTalk-Message Queuing-Adapter verwendet werden.
Abbildung 2: Flussdiagramm für die Beispielarchitektur des BizTalk-Message Queuing-Adapterszenarios
Der Datenfluss läuft wie folgt ab:
Ein Partner sendet eine Nachricht mithilfe des Message Queuings oder BizTalk-Message Queuings. Die Nachricht wird im entsprechenden Format verpackt und im Netzwerk versendet. Wenn Sie Active Directory verwenden, passiert die Nachricht eine Reihe von Message Queuing-Routern, bis sie das richtige Ziel erreicht hat (der BizTalk Server, der eine Hostinstanz des BizTalk-Message Queuing-Empfangsadapters ausführt).
Eine Instanz eines Hosts vom Typ „In-Process“ für den BizTalk-Message Queuing-Empfangsadapter empfängt die Nachricht regelmäßig von einem Message Queuing-Router (über Firewall 2), führt eine Erstverarbeitung durch, sendet die durch das Netzwerkprotokoll definierten richtigen Netzwerkantworten und legt die Nachricht in der MessageBox-Datenbank ab.
Eine Instanz des verarbeitenden Hosts, der ein Abonnement der Nachricht besitzt, ruft die Nachricht aus der MessageBox-Datenbank ab, führt zusätzliche Verarbeitung aus, und speichert die Nachricht dann erneut in der MessageBox-Datenbank.
Eine Instanz des Hosts vom Typ „In-Process“, der über einen BizTalk-Message Queuing-Sendeadapter verfügt, nimmt die Nachricht aus der MessageBox-Datenbank auf. Die Nachricht durchläuft eine abschließende Verarbeitung in der Sendepipeline und wird dann über Firewall 2 über das Netzwerk an den Partner oder die Anwendung gesendet.
Schritt 2 Erstellen und Analysieren des Bedrohungsmodells (BizTalk Message Queuing Adapter-Szenario)
In diesem Abschnitt werden die Ergebnisse der Gefahrenmodellanalyse (Threat Model Analysis, TMA) bereitgestellt, die wir für das BizTalk-Message Queuing-Adapterszenario für die Beispielarchitektur durchgeführt haben.
Identifizieren von Einstiegspunkten, Vertrauensgrenzen und Datenfluss : Weitere Informationen finden Sie unter Hintergrundinformationen, die weiter oben in Schritt 1 und unter Hintergrundinformationen für Beispielszenarien beschrieben wurden.
Erstellen einer Liste der identifizierten Bedrohungen : Wir haben die folgende Kategorisierung für alle Einträge im DFD verwendet, um potenzielle Bedrohungen für das Szenario zu identifizieren: Spoofing identify, Tampering with data, Repudiation, Information disclosure, Denial of service und Elevation of privileges. In der folgenden Tabelle sind die Bedrohungen aufgeführt, die wir bei der Verwendung eines BizTalk-Message Queuing-Adapters zum Senden und Empfangen von Nachrichten an und von BizTalk Server identifiziert haben.
Tabelle 1 – Liste der identifizierten Gefahren
Bedrohung | BESCHREIBUNG | Asset | Auswirkung |
---|---|---|---|
Senden zahlreicher Nachrichten an den Empfangsspeicherort | Ein böswilliger Benutzer kan eine große Anzahl gültiger oder ungültiger Nachrichten senden und die Anwendung überfluten. | BizTalk Server-Umgebung | Denial of Service |
Nachrichtenheader werden als Klartext übertragen | Während die Nachricht von der Warteschlange zum BizTalk-Message Queuing-Empfangsadapter übertragen wird, ist der Nachrichtenheader nicht verschlüsselt und ein böswilliger Benutzer kann den Header möglicherweise lesen und manipulieren. | Nachrichtenheader | Manipulation von Daten Veröffentlichung von Informationen |
Ein nicht autorisierter Benutzer kann eine Netzwerkverbindung zum BizTalk Server herstellen, der den BizTalk-Message Queuing-Host ausführt. | Sie können keine freigegebene Zugriffssteuerungsliste (DACL) verwenden, um den Zugriff auf den BizTalk-Message Queuing-Empfangsspeicherort einzuschränken. Daher kann jeder Benutzer, der eine Netzwerkverbindung zum BizTalk Server, der eine Hostinstanz des BizTalk-Message Queuing-Empfangsadapters ausführt, und zu Port 1801 herstellen kann, Nachrichten an den BizTalk-Message Queuing-Empfangsspeicherort senden. | BizTalk Server-Umgebung | Nichtanerkennung Manipulation von Daten Offenlegung von Informationen Denial of Service Unbefugte Rechteerweiterung |
Ein böswilliger Benutzer kann die Nachricht manipulieren, bevor sie von BizTalk Server empfangen wird. | Ein böswilliger Benutzer kann die Nachricht während der Übertragung abfangen und manipulieren. | Nachrichtentext | Manipulation von Daten Veröffentlichung von Informationen |
Schritt 3 Überprüfen von Bedrohungen (BizTalk Message Queuing-Adapterszenario)
In diesem Abschnitt werden die Ergebnisse der Risikoanalyse bereitgestellt, die wir für die Bedrohungen durchgeführt haben, die für das BizTalk-Message Queuing-Adapterszenario für die Beispielarchitektur identifiziert wurden. Nach der Besprechung des Standard Bedrohungsmodells haben wir die Bedrohungen überprüft und die folgenden Auswirkungskategorien verwendet, um das Risiko für jede Bedrohung zu identifizieren: DAmagepotenzial, R-Herstellbarkeit, E-Verwertbarkeit, Ainfizierte Benutzer und DIscoverability.
In der folgenden Tabelle sind die Risikoeinstufungen für die Bedrohungen aufgeführt, die wir bei der Verwendung eines BizTalk-Message Queuing-Adapters zum Senden und Empfangen von Nachrichten an und von BizTalk Server identifiziert haben.
Tabelle 2: Risikoeinstufungen für identifizierte Gefahren
Bedrohung | Auswirkung | Schadenspotenzial | Reproduzierbarkeit | Ausnutzbarkeit | Betroffene Benutzer | Erkennbarkeit | Gefahrenpotenzial durch Risiken |
---|---|---|---|---|---|---|---|
Senden zahlreicher Nachrichten an den Empfangsspeicherort | Denial of Service | 8 | 7 | 7 | 7 | 5 | 6,8 |
Nachrichtenheader werden als Klartext übertragen | Manipulation von Daten Veröffentlichung von Informationen |
8 | 10 | 8 | 3 | 5 | 6,8 |
Ein nicht autorisierter Benutzer kann eine Netzwerkverbindung zum BizTalk Server herstellen, der den BizTalk-Message Queuing-Host ausführt. | Nichtanerkennung Manipulation von Daten Offenlegung von Informationen Denial of Service Unbefugte Rechteerweiterung |
8 | 10 | 9 | 9 | 9 | 9 |
Ein böswilliger Benutzer kann die Nachricht manipulieren, bevor sie von BizTalk Server empfangen wird. | Manipulation von Daten Veröffentlichung von Informationen |
5 | 7 | 6 | 5 | 7 | 6 |
Schritt 4. Identifizieren von Entschärfungstechniken (BizTalk Message Queuing Adapter-Szenario)
In diesem Abschnitt werden einige Verfahren zum Entschärfen für die Bedrohungen präsentiert, die wir für das BizTalk-Message Queuing-Adapterszenario für die Beispielarchitektur identifiziert haben.
In der folgenden Tabelle werden die Vermeidungstechniken und -technologien für die Gefahren aufgelistet, die erkannt wurden, wenn Sie den BizTalk-Message Queuing-Adapter zum Senden und Empfangen von Nachrichten an und von BizTalk Server verwenden.
Tabelle 3: Vermeidungstechniken und -technologien
Bedrohung | Auswirkung | Gefahrenpotenzial durch Risiken | Vermeidungstechniken und -technologien |
---|---|---|---|
Senden zahlreicher Nachrichten an den Empfangsspeicherort | Denial of Service | 6,8 | Verwenden Sie den BizTalk-Message Queuing-Adapter in dem Modus, in dem eine Authentifizierung erforderlich ist. Legen Sie das Flag MsMQ-Authentifizierung erforderlich für den Empfangsspeicherort und Authentifizierung erforderlich (Nachrichten löschen) auf dem Empfangsport fest. Konfigurieren Sie BizTalk-Message Queuing so, dass eine zertifikatbasierte Authentifizierung erforderlich ist. Dieses Verhalten tritt auf Adapterebene auf und unterscheidet sich von der Komponente zur Parteiauflösung einer BizTalk-Pipeline. Bei entsprechender Konfiguration wird das öffentliche Zertifikat in die eingehende Nachricht einbezogen. Dies ist der einzige Clientauthentifizierungsmodus, der für das BizTalk-Message Queuing verfügbar ist. Wenn Sie diesen Clientauthentifizierungsmodus verwenden möchten, müssen Sie BizTalk-Message Queuing mit dem Active Directory-Integrationsmodus installieren. Wenn Sie dieses Feature verwenden, denken Sie daran, das Kontrollkästchen Authentifizierung erforderlich im Eigenschaftendialogfeld für den BizTalk Message Queuing-Empfangsspeicherort zu aktivieren. |
Nachrichtenheader werden als Klartext übertragen | Manipulation von Daten Veröffentlichung von Informationen |
6,8 | Verwenden Sie IPsec (Internet Protocol Security), um den Nachrichtentext und den Nachrichtenheader bei der Übertragung von einem Server zu einem anderen zu schützen. |
Ein nicht autorisierter Benutzer kann eine Netzwerkverbindung zum BizTalk Server herstellen, der den BizTalk-Message Queuing-Host ausführt. | Nichtanerkennung Manipulation von Daten Offenlegung von Informationen Denial of Service Unbefugte Rechteerweiterung |
9 | Erstellen Sie eine benutzerdefinierte Pipeline mit einer Pipelinekomponente für die Parteiauflösung, und konfigurieren Sie dann die Komponente zur Parteiauflösung derart, dass sie die Absender-ID (SID) zum Auflösen der Partei verwendet. Legen Sie die Eigenschaft Resolve Party By Certificate auf False und die Eigenschaft Resolve Party By SID auf True fest. Weitere Informationen finden Sie unter Pipelinekomponente für Die Parteienauflösung. Legen Sie am Empfangsport die Authentifizierungseigenschaft auf Erforderlich (Nachrichten löschen) fest. |
Ein böswilliger Benutzer kann die Nachricht manipulieren, bevor sie von BizTalk Server empfangen wird. | Manipulation von Daten Veröffentlichung von Informationen |
6 | Verwenden Sie die Authentifizierung auf Protokollebene, um sicherzustellen, dass die Nachricht während der Übertragung nicht manipuliert wurde. Es muss ein Message Queuing-Router in der E-Business-Domäne vorhanden sein, um die Authentifizierung auf Protokollebene verwenden zu können. Konfigurieren Sie BizTalk Server wie folgt: – Geben Sie auf der Seite BizTalk Messaging des Configuration Manager den Namen des Routers an. – Legen Sie für den Empfangsport die Authentifizierungseigenschaft auf Erforderlich (Nachrichten löschen) oder Erforderlich (Nachrichten beibehalten) fest. – Geben Sie für den Sendehandler auf der Registerkarte Allgemein im Feld MSMQ-Routername den Namen des Message Queuing-Routers ein. – Wählen Sie für den Sendeport Die Option MSMQ-Authentifizierung verwenden aus. |
Weitere Informationen
Analyse des Gefahrenmodells (Threat Model Analysis, TMA)
Beispielszenarios für die Gefahrenanalyse
Beispielarchitekturen für kleine und mittelgroße Unternehmen