制限されたネットワーク内にSQLServerがあります。どういうわけか外部からデータを取得する必要があります。
メッセージブローカーの利用を活用したいと思います。私の考えでは、外部データベースはメッセージをキューに入れ、制限されたLANの内部にあるサービスがこれらのメッセージをリッスン（ポーリング？）してからそれに基づいて動作する必要があります。外部キューに制限付きLANへの通常のブローカー会話を開始させることはできません。
私の質問は、制限されたLAN内に座って新しいメッセージをリッスンし、それらに基づいて行動するブローカーの外部アクティベーターを確認する必要があるかどうかです。誰かがこれを経験したことがありますか。外部アクティベーターのドキュメント/例は、地上ではかなり薄く、モノローグはメッセージブローカーではまだサポートされていません。
msmqはより良いオプションですか？
私の推奨事項は、ServiceBrokerが制限付きLAN内のSQLServerインスタンスにメッセージを完全に配信できるようにすることです。これには、着信接続を許可するために制限されたLANが必要になります（内部サーバーがリッスンして受け入れることを許可します）。MSMQも例外ではなく、制限されたLANでMSMQポートを開く必要があります。
内部のデータを「取得」する制限付きLAN内の専用プロセスを使用する場合は、外部サーバーの「取得」と内部サーバーの書き込みの間のトランザクションの一貫性を確保する必要があります。2つの操作を分散トランザクションに登録する必要があります。また、DTCプロトコル自体が制限されたLANに侵入できるようにする必要があります。そのため、制限付きLANで一部のポートを開く必要があります。
LANセキュリティ設計者が理解する必要があるのは、ServiceBroker接続はそうではないということです。Transact-SQL接続。Service Brokerは、ServiceBrokerメッセージの交換のみを許可する専用プロトコルを使用します。すべてのトラフィックは暗号化され、RC4またはAES暗号化で保護されます。SSB暗号化はFIPSに準拠しています。内部のSQLServerへのServiceBrokerトラフィックを許可することは、外部サーバーからのデータがセキュリティで保護されたサーバーに到達できるようにするための最も安全な方法です。Service Brokerネットワーキングには、「クライアント」と「サーバー」の概念はなく、1つの方向でのみ接続を許可するネットワークを設計することはできません（たとえば、HTTPとは異なり、内部から外部に接続するように設計できますが、その逆はできません）。 ）。SSBネットワーキングでは、関係する両方のマシンが相互に接続できる必要があります。これは、応答メッセージが長い遅延（数時間、数日、キューがバックアップされ、メッセージが処理されて応答が送信されるまでに長い時間がかかる場合を考えてみてください）。応答を期待するために接続を数日間開いたままにしておくことは現実的ではないため、メッセージの受信者応答を配信するには、送信者に接続できる必要があります。