собирают ли боты, зарегистрированные в bot framework, личную информацию? если да, то как можно убедиться в том, что данные сохранены надежно и безопасно? как насчет конфиденциальности?

 

<p>каждый бот имеет собственную службу, и разработчики этих служб обязаны предоставлять условия обслуживания и заявление о конфиденциальности в соответствии с правилами поведения разработчиков. см. руководство по <a href="bot-service-review-guidelines">программированию ботов</a>.</p>


могу ли я разместить бот на своих серверах?

 

<p>да. вы можете разместить свой бот в любом расположении в интернете. на собственных серверах, в azure или в любом другом центре обработки данных.
нужно только, чтобы бот предоставлял общедоступную конечную точку https.</p>


как вы блокируете или удаляете боты из службы?

 

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


какие конкретные url-адреса нужно разрешить в моем корпоративном брандмауэре для доступа к службам платформы bot?

 

<p>если у вас есть исходящий брандмауэр, блокирующий трафик от программы-робота к интернету, необходимо разрешить в этом брандмауэре перечислить следующие url-адреса:</p>
<ul>
<li><code>login.botframework.com</code> (аутентификация бота)</li>
<li><code>login.microsoftonline.com</code> (аутентификация бота)</li>
<li><code>westus.api.cognitive.microsoft.com</code> (для интеграции luis.ai nlp)</li>
<li><code>*.botframework.com</code> (каналы)</li>
<li><code>state.botframework.com</code> (обратная совместимость)</li>
<li><code>login.windows.net</code> (имя входа windows)</li>
<li><code>login.windows.com</code> (имя входа windows)</li>
<li><code>sts.windows.net</code> (имя входа windows)</li>
<li>дополнительные url-адреса для конкретных каналов bot framework</li>
</ul>
<div class="note">
<p>примечание</p>
<p>вы можете использовать, <code><channel>.botframework.com</code> если вы не хотите допустить вывод url-адреса со звездочкой. <code><channel></code> равен любому каналу, используемому вашим ботом, например <code>directline.botframework.com</code>, <code>webchat.botframework.com</code> и <code>slack.botframework.com</code>.
кроме того, при тестировании бота важно наблюдать за трафиком, поступающим в брандмауэр, проверяя, чтобы ничего лишнего не было заблокировано.</p>
</div>


можно ли заблокировать весь входящий трафик бота, кроме трафика от bot framework service?

 

<p>службы платформы bot размещаются в общедоступных центрах обработки данных azure, и список ip-адресов azure постоянно меняется.
это означает, что список определенных ip-адресов может работать в течение одного дня и разрывать его после изменения ip-адресов azure.</p>


какая роль rbac нужна для создания и развертывания бота?

 

<p>для создания бота на портала azure требуется доступ уровня участника в подписке или соответствующей группе ресурсов.
пользователь с ролью <em>участник</em> в группе ресурсов может создавать боты только в этой конкретной группе ресурсов.
пользователь с ролью <em>участник</em> в подписке может создать боты в любой существующей или новой группе ресурсов.</p>
<p>управление доступом на основе ролей при работе с azure cli может поддерживать пользовательские роли.
если вы хотите создать пользовательскую роль с более ограниченными разрешениями, указанный ниже набор позволяет пользователю создать и развернуть робот, который также поддерживает luis, qna maker и application insights.</p>
<p>"microsoft.web/ <em>", "microsoft.botservice/</em> ", "microsoft.storage/ <em>", "microsoft.resources/deployments/</em> ", "microsoft.cognitiveservices/ <em>", "microsoft.search/searchservices/</em> ", "microsoft.insights/ <em>", "microsoft.insights/components/</em> "</p>
<div class="note">
<p>примечание</p>
<p>для luis и qna maker требуются разрешения cognitive services. для qna maker также требуются разрешения на поиск.
при создании пользовательской роли помните, что все унаследованные разрешения <em>deny</em> будут заменять <em>эти разрешения</em> .</p>
</div>


какие есть способы защиты от клиентов, олицетворяющих bot framework service?

 

<ol>
<li>все подлинные запросы к платформе bot сопровождаются маркером jwt, криптографическую подпись которого можно проверить, следуя руководству по <a href="rest-api/bot-framework-rest-connector-authentication">проверке подлинности</a> .
этот маркер разработан таким образом, что злоумышленники не могут олицетворять доверенные службы.</li>
<li>маркер безопасности, который указан в каждом запросе к боту содержит закодированный url-адрес службы (serviceurl). это означает, что даже если злоумышленник получит доступ к маркеру, он не сможет перенаправить диалог на новый url-адрес службы.
это реализовано во всех пакетах sdk и описано в наших <a href="rest-api/bot-framework-rest-connector-authentication#bot-to-connector&preserve-view=true">справочных материалах по аутентификации</a>.</li>
<li>если входящий маркер отсутствует или имеет неправильный формат, пакет sdk для bot framework не создаст маркер в ответ. это позволяет ограничить ущерб, если бот настроен неправильно.</li>
<li>в боте вы можете вручную проверить, указан ли параметр serviceurl в маркере. в результате бот станет более уязвимым, если топология службы изменится. то есть это возможно, но не рекомендуется.</li>
</ol>
<div class="note">
<p>примечание</p>
<p>это исходящие подключения из программы-робота к интернету.
списка ip-адресов или dns-имен, которые служба bot framework connector будет использовать для обращения к боту, нет.
список разрешений входящих ip-адресов не поддерживается.</p>
</div>


какова цель волшебного кода во время проверки подлинности?

 

<p>в элементе управления "веб-чат" есть два механизма, которые гарантируют, что пользователь вошел в подходящую учетную запись.</p>
<ol>
<li><p><strong>волшебный код</strong>. в конце процесса входа пользователю предоставляется случайный код из 6 цифр (<em>волшебный код</em>).
пользователь должен ввести этот код в диалоге, чтобы завершить процесс входа. это приводит к неправильному опыту пользователя.
кроме того, он обычно подвергается фишинговым атакам. злоумышленник может обманным путем вынудить другого пользователя выполнить вход, чтобы получить магический код путем фишинга.</p>
<div class="warning">
<p>предупреждение</p>
<p>использование волшебного кода является устаревшим. вместо этого следует использовать <strong>прямую линейную проверку подлинности</strong>, описанную ниже.</p>
</div>
</li>
<li><p><strong>прямая строка расширенная проверка подлинности</strong>. из-за проблем с методом <em>волшебного кода</em> служба azure bot удалила свою потребность.
служба azure bot гарантирует, что процесс входа может выполняться только <strong>в том же сеансе браузера</strong>, в котором запущен экземпляр web chat.
чтобы включить эту защиту, необходимо запустить веб-чат с <strong>прямым маркером</strong> , который содержит список <strong>доверенных источников</strong>, также известных как доверенные домены, на которых может размещаться клиент интернет-чата.
с помощью расширенных параметров проверки подлинности можно статически указать список доверенных источников на странице конфигурации с прямой линией.
дополнительные сведения см. в разделе <a href="bot-builder-security-enhanced">прямая строка расширенная проверка подлинности</a>.</p>
</li>
</ol>


как с помощью платформы bot управлять удостоверениями и доступом?

 

<p>управление удостоверениями и доступом (iam) — это платформа (политики и технологии), позволяющая соответствующим пользователям иметь доступ к технологическим ресурсам. дополнительные сведения см. в разделе <a href="https://en.wikipedia.org/wiki/identity\_management">управление удостоверениями</a>.</p>
<p>платформа bot предоставляет следующие механизмы идентификации:</p>
<ul>
<li><p><strong>проверка подлинности с помощью bot</strong>. определяет, поступил ли запрос от легального источника.
он управляется <strong>службой соединителя bot</strong> и обеспечивает безопасный обмен данными между bot и каналом.
дополнительные сведения см. в статье <a href="bot-builder-concept-authentication-types#bot-authentication">bot authentication</a>.</p>
</li>
<li><p><strong>проверка подлинности пользователя</strong>. он позволяет bot получать доступ к защищенным сетевым ресурсам от имени пользователя.
стандарт oauth отраслевого стандарта используется для проверки подлинности пользователя и авторизации программы-робота для доступа к ресурсам.
дополнительные сведения см. в разделе <a href="bot-builder-concept-authentication-types#user-authentication">проверка подлинности пользователя</a>.</p>
</li>
</ul>
<p>в целом, платформа bot обрабатывает проверку подлинности между службами (bot-аутентификация), по сути проверяя, что запрос действительно был получен из правильного канала. bot отвечает за обработку более низких уровней проверки подлинности.
вы можете применить фильтр, чтобы ваш bot принимал запросы только от конкретного идентификатора клиента, или потребовать от пользователей пройти проверку подлинности с помощью определенной службы oauth (проверка подлинности пользователя).</p>


разделы справки запретить использование программы bot пользователям, принадлежащим только к моему клиенту?

 

<p>существует два варианта, позволяющие ограничивать входящие сообщения, выполняемые процессом bot.</p>
<ul>
<li><p>при работе с защищенными данными для проверки подлинности пользователей определенно рекомендуется использовать oauth.</p>
</li>
<li><p>использование по промежуточного слоя является еще одним хорошим вариантом. например, в случае <strong>канала команд</strong> добавьте <code>teamstenantfilteringmiddleware</code> класс в bot и подпишите его в методе запуска.
<div class="warning">
<p>предупреждение</p>
<p>нельзя запретить командам отправлять вам сообщения от разных клиентов, а также предотвратить установку программы-робота, если у них есть манифест приложения.
все, что можно сделать, — предотвратить обработку нежелательных сообщений программой bot.</p>
</div>
</li>
</ul>