Часто задаваемые вопросы о безопасности и конфиденциальности Bot Framework

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

Да. Вы можете разместить свой бот в любом расположении в Интернете. На собственных серверах, в Azure или в любом другом центре обработки данных. Единственное требование заключается в том, что бот должен предоставлять общедоступную конечную точку HTTPS.

Пользователи могут сообщить о некорректно работающем боте с помощью карты контакта бота в каталоге. Разработчики должны соблюдать условия предоставления услуг Майкрософт, чтобы участвовать в предоставлении службы.

Если у вас есть исходящий брандмауэр, который блокирует трафик от бота к Интернету, вам потребуется разрешить список следующих URL-адресов в этом брандмауэре:

• login.botframework.com (аутентификация бота)
• login.microsoftonline.com (аутентификация бота)
• westus.api.cognitive.microsoft.com (для интеграции Luis.ai NLP)
• *.botframework.com (каналы)
• state.botframework.com (обратная совместимость)
• login.windows.net (имя входа Windows)
• login.windows.com (имя входа Windows)
• sts.windows.net (имя входа Windows)
• Другие URL-адреса для определенных каналов Bot Framework

Службы Bot Framework размещаются в центрах обработки данных Azure во всем мире, и список IP-адресов Azure постоянно меняется. Это означает, что список разрешенных IP-адресов может работать в один день и прерывать следующий раз, как изменяются IP-адреса Azure.

Для создания бота на портала Azure требуется доступ уровня участника в подписке или соответствующей группе ресурсов. Пользователь с ролью Участник в группе ресурсов может создавать боты только в этой конкретной группе ресурсов. Пользователь с ролью Участник в подписке может создать боты в любой существующей или новой группе ресурсов.

Управление доступом на основе ролей при работе с Azure CLI может поддерживать пользовательские роли. Если вы хотите создать пользовательскую роль с более ограниченными разрешениями, приведенный ниже набор позволяет пользователю создавать и развертывать бот, который также поддерживает LUIS, QnA Maker и Application Аналитика.

"Microsoft.Web/*",
"Microsoft.BotService/*",
"Microsoft.Storage/*",
"Microsoft.Resources/deployments/*",
"Microsoft.CognitiveServices/*",
"Microsoft.Search/searchServices/*",
"Microsoft.Insights/*",
"Microsoft.Insights/components/*"

1. Все запросы Bot Framework сопровождаются маркером JWT, криптографическая подпись которого можно проверить, следуя руководству по проверке подлинности . Маркер разработан таким образом, чтобы злоумышленники не могли олицетворить доверенные службы.
2. Маркер безопасности, сопровождающий каждый запрос к боту, имеет в нем кодировку ServiceUrl, что означает, что даже если злоумышленник получает доступ к маркеру, он не может перенаправить беседу в новый ServiceUrl. Это реализовано во всех пакетах SDK и описано в наших справочных материалах по аутентификации.
3. Если входящие маркеры отсутствуют или неправильно сформированы, пакет SDK Bot Framework не создаст маркер в ответ. Это позволяет ограничить ущерб, если бот настроен неправильно.
4. В боте вы можете вручную проверить, указан ли параметр ServiceUrl в маркере. Это делает бот более хрупким, если топология службы изменяется, поэтому пока это возможно, не рекомендуется.

В элементе управления Веб-чат существует два механизма обеспечения входа соответствующего пользователя.

1. Волшебный код. В конце процесса входа пользователь будет представлен случайным образом созданный 6-значный код (волшебный код). Пользователь должен ввести этот код в беседе, чтобы завершить процесс входа. Это, как правило, приводит к плохому опыту пользователя. Кроме того, он по-прежнему подвержен фишинговым атакам. Злоумышленник может обманным путем вынудить другого пользователя выполнить вход, чтобы получить магический код путем фишинга.

   Предупреждение

   Использование магического кода устарело. Вместо этого следует использовать расширенную проверку подлинности Direct Line, описанную ниже.

2. Расширенная проверка подлинности Direct Line. Из-за проблем с подходом к магическому коду azure AI Служба Bot удалил свою потребность. Azure AI Служба Bot гарантирует, что процесс входа можно выполнить только в том же сеансе браузера, что и сам Веб-чат. Чтобы включить эту защиту, необходимо запустить Веб-чат с маркером Direct Line, который содержит список доверенных источников, также известный как доверенные домены, который может размещать Веб-чат клиента бота. С помощью расширенных параметров проверки подлинности можно статически указать список доверенных источников на странице конфигурации Direct Line. Дополнительные сведения см. в разделе "Расширенная проверка подлинности Direct Line".

Управление удостоверениями и доступом (IAM) — это платформа (политики и технологии), позволяющая соответствующим людям иметь соответствующий доступ к технологическим ресурсам. Дополнительные сведения см. в разделе "Управление удостоверениями".

Bot Framework предоставляет следующие механизмы идентификации:

• Аутентификация бота. Определяет, поступил ли запрос из законного источника. Он управляется службой соединителя бота и обеспечивает безопасную связь между ботом и каналом. Дополнительные сведения см. в разделе "Проверка подлинности бота".

• Аутентификация пользователя. Он позволяет боту получать доступ к защищенным онлайн-ресурсам от имени пользователя. Стандарт OAuth в отрасли используется для проверки подлинности пользователя и авторизации бота для доступа к ресурсам. Дополнительные сведения см. в разделе "Проверка подлинности пользователей".

В целом, Bot Framework обрабатывает проверку подлинности между службами (проверка подлинности бота), по сути проверяя, что запрос действительно поступил из соответствующего канала. Бот отвечает за обработку более низких уровней проверки подлинности. Вы можете применить фильтр, чтобы бот принимал запросы только из определенного идентификатора клиента или требовать, чтобы пользователи могли пройти проверку подлинности с помощью некоторых служб OAuth (проверка подлинности пользователей).

У вас есть два разных варианта ограничения входящих сообщений, которые обрабатывает бот.

• Если вы работаете с безопасными данными, рекомендуется использовать OAuth для проверки подлинности пользователей.

• Использование ПО промежуточного слоя является еще одним хорошим вариантом. Например, в канале Teams можно создать ПО промежуточного слоя, чтобы получить идентификатор клиента из данных канала Teams. Затем по промежуточному слоям можно решить, следует ли разрешить входящие действия продолжать работу в логике бота или вместо этого возвращать сообщение об ошибке.

  Предупреждение

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