Service Busのセキュリティリスクはどのようなもので、どのように軽減しますか？
Service Bus は、Windowsに インストールしたり、Azureでレンタルしたりできるソフトウェアです そして、誰かがXML over HTTPSペイロードの形式でインターネットを介してSOAP/WCF情報をリレーできるようにします。
私が目にする1つのリスクは、本質的に、アウトバウンドHTTP/Sアクセスのみを持つユーザーが、外部プロキシを介した「インバウンド」WCF呼び出しを受け入れることを許可していることです。
これはアプリケーションを「そのまま動作させる」のに役立ちますが、セキュリティの観点からはこれは悪いことだと思います。私の理解では、このソリューションは外部のMicrosoftホストに着信データをポーリングすることで機能します。
このテクノロジーには正当なビジネス上の理由がある可能性があることを考慮して、このリレーの未承認または悪意のある使用からネットワークをどのように保護しますか？
「Azure AppFabricサービスバス」を介してWebサービスを公開する場合、そのエンドポイントを保護する方法は複数あります。
まず、サービスバス自体を構成して[1]、認証された呼び出し元のみがエンドポイントにメッセージを送信できるようにします。この場合、Microsoftに承認ポリシーを適用させることができます。
次に、エンドツーエンドの方法でサービスを保護できます。つまり、Microsoftが実行する基本的な下位レベル（トランスポート）の強制に加えて、メッセージベースのセキュリティなど、独自のセキュリティモデルを適用できます。 （WS-Security）SOAPの場合。
組み合わせて使用すると、Microsoftは、認証された呼び出し元のみがサービスに向けてメッセージをディスパッチし、サービス内では独自のセキュリティモデルを実行するように強制します。
機密性（暗号化）に関しては、ここにも複数の層があります。トランスポート層は、クライアントとMicrosoftの間、およびMicrosoftとサービスの間のメッセージを保護します。メッセージレイヤーはクライアントとサービス間のエンドツーエンドのセキュリティを提供するため、Microsoftは暗号化されたSOAP bodyのみを認識します。
[1] AppFabricサービスバス接続の保護と認証 http://msdn.Microsoft.com/en-us/library/dd582773.aspx
[2] .NETサービスバスの保護 http://msdn.Microsoft.com/en-us/magazine/dd942847.aspx
サービスバスについての私の理解は、800番台の特定のポートで機能するということです-私は思います。これらのポートを介したアウトバウンド接続を無効にすると、メッセージを取得するためにサービスバスにアクセスできなくなります。また、各サービスバスには、問題のサービスに固有の独自の固有のエンドポイントがあるため、既知のエンドポイントのみへのアクセスをロックダウンできます。