Forum aux questions sur la sécurité et la confidentialité de Bot Framework

Chaque bot est un service propre. Dans le cadre du Code de conduite du développeur, les développeurs de ces services sont tenus de fournir des conditions d’utilisation et des déclarations de confidentialité. Pour plus d’informations, consultez Instructions d’évaluation des bots.

Oui. Votre bot peut être hébergé n’importe où sur Internet. Sur vos propres serveurs, dans Azure, ou dans n’importe quel autre centre de données. La seule exigence à respecter est que le bot doit exposer un point de terminaison HTTPS accessible publiquement.

Les utilisateurs peuvent signaler la présence d’un bot inapproprié en se reportant à la carte de contact du bot dans le répertoire. Les développeurs doivent se conformer aux conditions d’utilisation de Microsoft pour participer au service.

Si vous disposez d’un pare-feu pour le trafic sortant qui bloque le trafic vers Internet en provenance de votre bot, vous devrez mettre en liste d’autorisation les URL ci-après dans ce pare-feu :

• login.botframework.com (authentification du bot)
• login.microsoftonline.com (authentification du bot)
• westus.api.cognitive.microsoft.com (pour l’intégration du système de traitement du langage naturel Luis.ai)
• *.botframework.com (canaux)
• state.botframework.com (compatibilité descendante)
• login.windows.net (connexion Windows)
• login.windows.com (connexion Windows)
• sts.windows.net (connexion Windows)
• Autres URL pour certains canaux Bot Framework

Bot Framework Service est hébergé dans les centres de données Azure du monde entier, et la liste des adresses IP Azure évolue constamment. Cela signifie que la mise en liste verte de certaines adresses IP peut cesser de fonctionner du jour au lendemain lorsque les adresses IP Azure changent.

La création d’un bot dans le portail Azure nécessite un accès Contributeur, soit dans l’abonnement, soit dans un groupe de ressources. Un utilisateur qui dispose du rôle Contributeur pour un groupe de ressources peut créer un bot dans celui-ci. Un utilisateur qui dispose du rôle Contributeur pour un abonnement peut créer un bot dans un groupe de ressources nouveau ou existant.

Dans Azure CLI, vous pouvez prendre en charge des rôles personnalisés à l’aide du contrôle d’accès en fonction du rôle. Si vous souhaitez créer un rôle personnalisé avec des autorisations plus restreintes, l’ensemble ci-dessous permet à l’utilisateur de créer et de déployer un bot qui prend également en charge LUIS, QnA Maker et Application Insights.

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

1. Toutes les requêtes Bot Framework authentiques sont accompagnées d’un jeton JWT dont vous pouvez vérifier la signature de chiffrement en suivant les instructions du guide d’authentification. Le jeton est conçu pour empêcher les attaquants d’emprunter l’identité des services approuvés.
2. L’URL du service (ServiceUrl) est encodée dans le jeton de sécurité qui accompagne chaque requête adressée à votre bot ; autrement dit, même si un attaquant parvient à accéder au jeton, il ne peut pas rediriger la conversation vers une nouvelle URL ServiceUrl. Cette approche est appliquée par toutes les implémentations du kit de développement logiciel (SDK) et documentée dans nos articles de référence concernant l’authentification.
3. Si le jeton entrant est manquant ou incorrect, le kit de développement logiciel (SDK) Bot Framework ne génère aucun jeton en réponse. Cela limite les dommages potentiels en cas de configuration incorrecte du bot.
4. À l’intérieur du bot, vous pouvez vérifier manuellement l’URL ServiceUrl fournie dans le jeton. Cette opération fragilise le bot en cas d’apport de modifications à la topologie du service ; elle est donc possible, mais déconseillée.

Dans le contrôle Chat Web, il existe deux mécanismes pour garantir que le bon utilisateur est connecté.

1. Code magique. À la fin de la procédure de connexion, l'utilisateur reçoit un code à 6 chiffres généré de manière aléatoire (le code magique). L’utilisateur doit saisir ce code dans la conversation pour terminer le processus de connexion. Cela a tendance à dégrader l’expérience utilisateur. De plus, il reste vulnérable aux attaques par hameçonnage. Un utilisateur malveillant peut inciter un autre utilisateur à se connecter et à obtenir le code magique par le biais d’un hameçonnage.

   Avertissement

   L’utilisation du code magique est déconseillée. À la place, vous devez utiliser l’authentification améliorée Direct Line, décrite ci-dessous.

2. Authentification améliorée Direct Line. En raison des problèmes rencontrés avec le code magique, Azure AI Bot Service a changé de méthode. Azure AI Bot Service garantit que le processus de connexion ne peut être achevé que dans la même session de navigateur que le Chat Web lui-même. Pour activer cette protection, vous devez démarrer Chat Web avec un jeton Direct Line qui contient une liste d’origines de confiance, aussi appelés domaines de confiance, pouvant héberger le client Chat Web du bot. Grâce aux options d’authentification avancée, vous pouvez spécifier de façon statique la liste des origines approuvées dans la page de configuration de Direct Line. Pour plus d'informations, consultez l'authentification améliorée Direct Line.

La gestion des identités et des accès (IAM) est une infrastructure (stratégies et technologies) pour permettre aux bonnes personnes d’avoir un accès approprié aux ressources technologiques. Pour plus d’informations, consultez Gestion des identités.

Bot Framework fournit les mécanismes d’identification suivants :

• Authentification du bot. Détermine si une demande provient d’une source légitime. Elle est contrôlée par le service de connecteur de bot et permet une communication sécurisée entre un bot et un canal. Pour en savoir plus, consultez Authentification de bot.

• Authentification utilisateur. Elle permet au bot d’accéder à des ressources en ligne sécurisées au nom de l'utilisateur. L’OAuth standard du secteur est utilisée pour authentifier l’utilisateur et autoriser le bot à accéder aux ressources. Pour plus d'informations, consultez Authentification de l'utilisateur.

En résumé, Bot Framework gère l’authentification de service à service (authentification de bot), en validant essentiellement qu’une demande provient effectivement d’un canal approprié. Le bot est responsable de la gestion des niveaux d’authentification inférieurs. Vous pouvez appliquer un filtre afin que votre bot accepte uniquement les demandes d’un ID de locataire particulier, ou vous pouvez exiger que vos utilisateurs s’authentifient auprès d’un service OAuth (authentification utilisateur).

Vous avez deux options différentes pour restreindre les messages entrants que votre bot traite.

• Si vous traitez des données sécurisées, il est certainement recommandé d’utiliser OAuth pour authentifier les utilisateurs.

• L’utilisation d’un intergiciel est une autre option efficace. Dans le canal Teams, par exemple, vous pouvez créer un intergiciel pour obtenir l’ID de locataire à partir des données du canal Teams. L’intergiciel peut ensuite décider s’il faut laisser l’activité entrante passer à la logique de votre bot ou retourner un message d’erreur.

  Avertissement

  Vous ne pouvez pas empêcher Teams de vous envoyer des messages à partir de différents locataires, ni empêcher quelqu’un d’installer votre bot si cette personne a votre manifeste d’application. Tout ce que vous pouvez faire est d’empêcher votre bot de traiter les messages non souhaités.