Perguntas frequentes sobre segurança e privacidade do Bot Framework

Cada bot é o seu próprio serviço e os programadores desses serviços são obrigados a disponibilizar Termos do Serviço e Declarações de Privacidade de acordo com o Código de Conduta do Programador. Para obter mais informações, consulte as diretrizes de revisão de bots.

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 acessível publicamente.

Os usuários têm uma maneira de denunciar um bot com comportamento incorreto por meio do cartão de visita do bot no diretório. Os programadores têm de cumprir os termos de serviço da Microsoft para participar no serviço.

Se você tiver um firewall de saída que bloqueie o tráfego do seu bot para a Internet, precisará permitir a lista dos seguintes URLs nesse firewall:

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

O Bot Framework Services está hospedado em data centers do Azure em todo o mundo e a lista de IPs do Azure está em constante mudança. Isso significa que permitir a listagem de determinados endereços IP pode funcionar em um dia e quebrar no outro à medida que os Endereços IP do Azure mudam.

A criação de um bot no portal do Azure requer o acesso de Contribuidor na subscrição ou num grupo de recursos específico. Um usuário com a função de Colaborador em um grupo de recursos pode criar um novo bot nesse grupo de recursos específico. Um usuário na função de Colaborador de 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 baseada em função pode dar suporte a funções personalizadas. Se você quiser criar uma função personalizada com permissões mais restritas, o conjunto abaixo permite que o usuário crie e implante um bot que também ofereça suporte a 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 se passar por serviços confiáveis.
2. O token de segurança que acompanha cada solicitação ao seu bot tem o ServiceUrl codificado nele, o que significa que, mesmo que um invasor obtenha acesso ao token, ele não poderá redirecionar a conversa para um novo 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 de entrada estiver ausente ou malformado, o SDK do Bot Framework não gerará um token em resposta. Isso limita quanto dano pode ser feito se o bot estiver configurado incorretamente.
4. Dentro do bot, você pode verificar manualmente o ServiceUrl fornecido no token. Isso torna o bot mais frágil se a topologia de serviço mudar, portanto, embora isso seja possível, não é recomendado.

No controle de bate-papo da Web, há dois mecanismos para garantir que o usuário adequado esteja conectado.

1. Código mágico. No final do processo de início de sessão, é apresentado ao utilizador um código de 6 dígitos gerado aleatoriamente (código mágico). O usuário deve digitar esse código na conversa para concluir o processo de login. Isso tende a resultar em uma experiência ruim do usuário. Além disso, ainda é suscetível a ataques de phishing. Um utilizador mal-intencionado pode enganar outro utilizador para iniciar sessão e obter o código mágico através de phishing.

   Aviso

   O uso do código mágico foi preterido. Em vez disso, você deve usar a autenticação aprimorada de Linha Direta, descrita abaixo.

2. Autenticação aprimorada de linha direta. Devido aos problemas com a abordagem de código mágico, o Serviço de Bot de IA do Azure removeu sua necessidade. O Serviço de Bot do Azure AI garante que o processo de entrada só pode ser concluído na mesma sessão do navegador que o próprio Bate-papo da Web. Para habilitar essa proteção, você deve iniciar o Web Chat com um token de Linha Direta que contenha uma lista de origens confiáveis, também conhecidas como domínios confiáveis, que podem hospedar o cliente de Web Chat do bot. Com as opções de autenticação avançadas, você pode especificar estaticamente a lista de origens confiáveis na página de configuração da Linha Direta. Para obter mais informações, consulte Autenticação avançada de linha direta.

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

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. É controlado pelo serviço de conector de bot e permite uma comunicação segura entre um bot e um canal. Para obter mais informações, consulte Autenticação de bot.

• Autenticação de utilizador. Ele permite que o bot acesse recursos on-line seguros em nome do usuário. O OAuth padrão do setor é usado para autenticar o usuário e autorizar o bot a acessar os recursos. Para obter mais informações, consulte Autenticação de usuário.

Em resumo, o Bot Framework lida com a autenticação 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 seu bot aceite apenas solicitações de um ID de locatário específico ou pode exigir que seus usuários se autentiquem com algum serviço OAuth (autenticação de usuário).

Você tem duas opções diferentes para restringir as mensagens recebidas que seu bot processa.

• Se você 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 middleware para obter o ID do locatário dos dados do canal do Teams. O middleware pode então decidir se permite que a atividade de entrada continue na lógica do bot ou, em vez disso, retorne 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.