#service #azureservicebus
Вопрос:
У меня есть веб-приложение, размещенное в темах публикации azure в очереди служебной шины. Строка подключения хранится в безопасном хранилище, и все в порядке.
Я хотел бы, чтобы несколько служб Windows, запускающих рабочие потоки на различных локальных компьютерах клиентов, забирали свои собственные сообщения, а затем выполняли ряд задач на основе полученного сообщения.
Как защитить строку подключения служебной шины для службы Windows? Приложения?
Ответ №1:
Есть несколько опций, встроенных в диспетчер учетных данных Windows, который является более общим приложением для хранения паролей на машине, и API защиты данных Windows, который помогает шифровать/расшифровывать пароли, которые вы можете хранить где-то на диске. Оба используют пароль пользователя для шифрования и расшифровки паролей.
Что я хотел бы предложить в качестве дополнительного уровня защиты, так это выдавать клиентам идентификатор/секрет принципала службы вместо строки подключения очереди служебной шины с доступом на чтение к этому конкретному секрету в вашем хранилище ключей. Это разблокирует зависимость между строкой подключения служебной шины и вашими клиентами, т. е. вы можете поворачивать ключи, не связываясь с каждым из них, и если вы выдадите отдельных Участников обслуживания, вы сможете легко отменить доступ — добавление Участников обслуживания в группу безопасности и предоставление группе доступа к Хранилищу ключей значительно упростит управление.
Комментарии:
1. Спасибо, я думал, что вы можете использовать участников службы только в том случае, если приложение размещено. Клиентская служба Windows не размещается, она запускается локально.
2. Я добавил удостоверение приложения в azure ad и предоставил доступ к служебной шине. Используя клиент, идентификатор токена и секрет, я могу подключиться к служебной шине без проблем, но….. конечно, я не храню клиент, токен и секрет в app.config?
3. Управляемое удостоверение доступно только в Azure. Субъекты-службы можно использовать из любого места. Идентификатор приложения не так важен, но вы хотели бы поместить секрет в Диспетчер учетных данных или использовать API защиты данных Windows так же, как если бы вы использовали строку подключения.
4. в вашем комментарии выше о снятии связи с зависимостью. Вы имеете в виду использование приложения (клиента) Идентификатор, идентификатор арендатора и секретное значение для доступа к ключевому значению, содержащему строку подключения к очередям (т. е. конечную точку sas)? или что-то еще, я все еще пытаюсь заставить это работать, я думал о сертификатах?
5. Правильный. Вы также можете настроить доступ к хранилищу ключей с сертификатом, если хотите — вы все еще можете использовать параметр субъект-служба — > хранилище ключей, так как вы можете проверить это с помощью секрета или сертификата: > docs.microsoft.com/en-us/azure/developer/java/sdk/…