我希望得到一些关于我已经实现的解决方案的建议，以管理无法撤销ServiceBus中的令牌 .
我们遇到的问题是，当我们需要删除已安装的现场设备的访问权限以及如何最好地实现此目的时 . 无法撤销令牌会带来这种挑战 .
The issue: 我们的系统将放置在现场硬件中，该硬件将访问各种队列's, topics and relays. If this hardware fell into the wrong hands it would be possible for someone to reverse engineer the code and obtain the token'，使他们能够访问这些队列和主题 . 一旦他们有了这个，就不难在我们的系统上创建dos攻击 .
理想情况下 - 如果我们检测到此事件，我们可以通过快速阻止访问来恢复 - 但是当令牌无法撤销时，这不是那么直接 . 等待令牌超时是不可接受的解决方案 .
建议我们为客户端应用程序创建SAS令牌，并尽可能使令牌安全访问尽可能具体（路径，侦听和发送权限） . 撤销共享访问策略（SAP）不是一个选项，因为这也会影响其他仍然有效的令牌，因为SAP的数量非常有限，因此必须共享它们 .
ServiceBus队列只在硬件上侦听新消息并不是真正的问题，因为对侦听器的dos攻击我不确定是一个问题，因为你可以删除队列或主题订阅而不影响其他硬件，它更多当硬件发送到也可由其他硬件访问的队列时 . 我们有许多队列，例如将日志记录数据发送回我们的系统 . 所有已安装的硬件都使用相同的队列，因此我们有许多发件人和一个接收器 .
这意味着无法删除队列以修复dos攻击，因为队列由其他硬件使用 .
修复：要解决此问题 - 我们实施了转发队列 . 现在，每个硬件都有自己特定的硬件特定队列，该队列直接转发到公共日志记录队列 . 这意味着当出现问题时，我们可以删除特定于硬件的队列，而不会影响其他硬件 .
这有一个稍微复杂的设置，并且还增加了天蓝色服务的成本，因为我相信消息是重复的 . 它还意味着创建更多队列 . 在原始系统中，我们为所有硬件配备了一个队列，现在我们为每个硬件都有一个唯一的队列 .
这是我上面详述的安全问题的推荐解决方案吗？在我完全实现这一点之前，我会对其他人如何解决这个问题感兴趣？