Perguntas frequentes sobre privacidade e segurança do Bot Framework

Cada bot é seu próprio serviço, e os desenvolvedores desses serviços são obrigados a fornecer Termos de Serviço e Políticas de Privacidade de acordo com seu Código de Conduta do Desenvolvedor. Para obter mais informações, confira as diretrizes de análise do bot.

Sim. Seu bot pode ser hospedado em qualquer lugar na Internet. Em seus próprios servidores, no Azure ou em qualquer outro data center. O único requisito é que o bot deve expor um ponto de extremidade HTTPS publicamente acessível.

Os usuários têm um modo para relatar o comportamento inadequado de um bot, que é o cartão de visita do bot no diretório. Os desenvolvedores precisam respeitar os termos de serviço da Microsoft para participar do serviço.

Se tiver um firewall de saída bloqueando o tráfego do seu bot com a Internet, você precisará incluir na lista de permitidos desse firewall as URLs a seguir:

• login.botframework.com (Autenticação do bot)
• login.microsoftonline.com (Autenticação do bot)
• westus.api.cognitive.microsoft.com (para integração do NLP no Luis.ai)
• *.botframework.com (canais)
• state.botframework.com (compatibilidade com versões anteriores)
• login.windows.net (Logon do Windows)
• login.windows.com (Logon do Windows)
• sts.windows.net (Logon do Windows)
• Outras URLs de canais específicos do Bot Framework

Os Bot Framework Services são hospedados em data centers do Azure em todo o mundo e a lista de IPs do Azure está em constante alteração. A lista de permissões de determinados endereços IP pode funcionar um dia e parar no próximo, à medida que os Endereços IP do Azure mudam.

A criação de um bot no portal do Azure requer acesso de colaborador na assinatura ou em um grupo de recursos específico. Um usuário com a função de Colaborador em um grupo de recursos pode criar um bot nesse grupo de recursos específico. Um usuário na função de Colaborador para uma assinatura pode criar um bot em um grupo de recursos novo ou existente.

Usando a CLI do Azure, uma abordagem de controle de acesso baseado em função pode dar suporte a funções personalizadas. Se quiser tornar uma função personalizada com permissões mais restritas, o conjunto a seguir permitirá que o usuário crie e implante um bot compatível também com LUIS, QnA Maker e Application Insights.

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

1. Todas as solicitações autênticas do Bot Framework são acompanhadas por um token JWT cuja assinatura criptográfica pode ser verificada seguindo o guia de autenticação. O token foi projetado para que os invasores não possam usurpar a identidade de serviços confiáveis.
2. O token de segurança que acompanha todas as solicitações feitas para seu bot tem em si a ServiceUrl codificada, o que significa que, mesmo se um invasor obtiver acesso ao token, ele não conseguirá redirecionar a conversa para uma nova ServiceUrl. Isso é imposto por todas as implementações do SDK e documentado em nossos materiais de referência de autenticação.
3. Se o token recebido estiver ausente ou se for malformado, o SDK do Bot Framework não irá gerar um token na resposta. Isso limita o dano que poderá ocorrer se o bot for configurado incorretamente.
4. Dentro do bot, você pode verificar manualmente a ServiceUrl fornecida no token. Isso torna o bot mais frágil em caso de alterações de topologia de serviço, por isso tal verificação manual é possível, mas não recomendada.

No controle WebChat, há dois mecanismos para garantir que o usuário correto esteja conectado.

1. Código mágico. Ao final do processo para iniciar sessão, o usuário recebe um código de seis dígitos gerado aleatoriamente (código mágico). O usuário deve digitar esse código na conversa para concluir o processo para iniciar sessão. Isso tende a resultar em uma experiência de usuário inadequada. Além disso, ele ainda está suscetível a ataques de phishing. Um usuário mal-intencionado pode induzir outro usuário a se conectar e a obter o código mágico por meio de phishing.

   Aviso

   O uso do código mágico foi preterido. Em vez disso, você deve usar a autenticação avançada do Direct Line, descrita abaixo.

2. Autenticação avançada do Direct Line. Devido aos issues com a abordagem código mágico o Serviço de Bot de IA do Azure a tornou desnecessária. O Serviço de Bot de IA do Azure garante que o processo para iniciar sessão só possa ser concluído na mesma sessão do Browser que a do próprio Webchat. Para habilitar essa proteção, como desenvolvedor de bot, você deve iniciar o Webchat com um token do Direct Line que contenha uma lista de origens confiáveis, também conhecidas como domínios confiáveis, que possam hospedar o cliente do Webchat do bot. Agora, com as opções de autenticação avançada, você pode especificar estaticamente a lista de origens confiáveis na página de configuração do Direct Line. Para obter mais informações, confira Autenticação avançada do Direct Line.

O gerenciamento de identidades e acesso (IAM), é uma estrutura (de políticas e tecnologias) para permitir que pessoas adequadas tenham acesso apropriado a recursos tecnológicos. Para obter mais informações, confira Gerenciamento de Identidades.

O Bot Framework fornece os seguintes mecanismos de identificação:

• Autenticação de bot. Determina se uma solicitação veio de uma fonte legítima. É controlada pelo serviço do conector de bot e permite a comunicação segura entre um bot e um canal. Para obter mais informações, confira Autenticação de bot.

• Autenticação do usuário. Permite que o bot tenha acesso a recursos online protegidos em nome do usuário. O OAuth standard do setor é usado para autenticar o usuário e autorizar o bot a acessar os recursos. Para obter mais informações, confira Autenticação do usuário.

Em resumo, o Bot Framework lida com a autenticação de serviço a serviço (autenticação de bot), essencialmente validando que uma solicitação realmente veio de um canal adequado. O bot é responsável por lidar com níveis mais baixos de autenticação. Você pode aplicar um filtro para que o bot aceite apenas solicitações de um ID de locatário específico ou pode exigir que os usuários se autentiquem com algum serviço OAuth (autenticação de usuário).

Há duas opções diferentes para restringir as mensagens recebidas que o bot processa.

• Se estiver lidando com dados seguros, é definitivamente recomendável usar o OAuth para autenticar os usuários.

• Usar middleware é outra boa opção. No canal do Teams, por exemplo, você pode criar um middleware para obter a ID do locatário dos dados do canal do Teams. O middleware pode então decidir se deseja permitir que a atividade recebida continue na lógica do bot ou, em vez disso, retornar uma mensagem de erro.

  Aviso

  Você não pode impedir que o Teams envie mensagens de vários locatários, nem impedir que alguém instale seu bot se tiver o manifesto do aplicativo. Tudo o que você pode fazer é impedir que seu bot processe as mensagens indesejadas.