Как проверить издателя сообщения на служебную шину с помощью серверной задачи VSTS?

Я хочу использовать Задание сервера VSTS "Опубликовать в служебной шине Azure" и проверить на стороне получателя пользователя VSTS, проект и учетную запись, из которой появилось опубликованное сообщение. Согласно task.json связанная информация отправляется на служебную шину, но для моих целей это небезопасно, так как я хочу защитить себя от подделки информации клиентом. Несколько разных пользователей, проектов и учетных записей VSTS будут использовать задачу. Как только клиент задачи получит учетные данные для отправки в служебную шину, он может подделать данные.

Обеспечивает ли VSTS идентификацию издателя сообщений с защитой от несанкционированного доступа? В сообщении есть токен аутентификации, но, похоже, он служит другой цели: он используется для аутентификации в VSTS и не содержит в себе утверждений об идентичности.


authentication azure azure-devops azure-devops-extensions azure-pipelines-build-task
person Konrad Jamrozik    schedule 21.06.2018    source источник
comment
Нет, нет. Какие данные вы можете использовать для проверки?   -  person starian chen-MSFT    schedule 22.06.2018
comment
Требование состоит в том, чтобы участники нескольких проектов в Microsoft отправляли сообщения в одну и ту же служебную шину, и наша служба, выполняющая чтение из служебной шины, должна гарантировать, что участник одного проекта не может отправлять сообщения от имени другого проекта. Мы хотели бы иметь детализацию как минимум на уровне проекта VSTS, возможно, даже на уровне пользователя. В связанном task.json это будет ключ ProjectId. Обходной путь, который мы рассматриваем, состоит в том, чтобы написать расширение VSTS, которое изменяет встроенную задачу, добавляя дополнительный общий секрет, который наша служба будет проверять, чтобы предотвратить спуфинг.   -  person Konrad Jamrozik    schedule 22.06.2018
comment
Недавно мы добавили возможность подписывать полезные данные сообщения в задаче служебной шины Azure. Будет ли это работать для вас?   -  person Aseem Bansal    schedule 25.06.2018

Ответы (2)


arrow_upward
0
arrow_downward

Вы можете включить необходимую информацию в тело сообщения, в противном случае вам нужно настроить задачу выпуска.

{"requestUserId":"$(Release.RequestedForId)","requestUser":"$(Release.RequestedFor)"}
person starian chen-MSFT    schedule 22.06.2018
comment
Это правильно, но я боюсь, что кто-то может выдать себя за идентификатор пользователя, отправив поддельное сообщение. Я надеялся, что VSTS предоставляет такую ​​информацию защищенным от несанкционированного доступа способом, например. кодируется как утверждение в токене OAuth. Однако, это не так. - person Konrad Jamrozik; 22.06.2018
comment
В задаче служебной шины Azure такой функции нет, вы можете настроить задачу через расширение VSTS. - person starian chen-MSFT; 25.06.2018
comment
Starian, я думаю есть такая фича. См. мой ответ - person Konrad Jamrozik; 26.06.2018

arrow_upward
0
arrow_downward

Как указал Асим Бансал, The Publish To Azure Service Bus серверная задача VSTS имеет новую функцию: Signing properties. Можно предоставить Certificate Variable, который является общим секретом между отправителем (расширение VSTS) и рецептантом (служба, потребляющая сообщения из служебной шины). Значение такой переменной должно быть сохранено как секретная переменная. Это решает проблему, поскольку любые попытки спуфинга могут быть заблокированы путем проверки наличия общего секрета в сообщении служебной шины (получатель должен сохранить сопоставление, какие отправители должны знать, какие секреты). Область действия того, кто знает секрет, может контролироваться тем, кто может просматривать секретные переменные определения сборки/выпуска VSTS и отправлять сборки/выпуски из данного определения. Я считаю, что VSTS имеет довольно тонкий контроль над ним на уровне конкретных пользователей.

person Konrad Jamrozik    schedule 26.06.2018