Veelgestelde vragen over Beveiliging en privacy van Bot Framework

Elke bot is een eigen service, en ontwikkelaars van deze services zijn verplicht om servicevoorwaarden en privacyverklaringen op te geven conform de gedragscode voor ontwikkelaars. Zie de richtlijnen voor botbeoordeling voor meer informatie.

Ja. Uw bot kan overal op internet worden gehost. Op uw eigen servers, in Azure of in een ander datacenter. De enige vereiste is dat de bot een openbaar toegankelijk HTTPS-eindpunt moet weergeven.

Gebruikers kunnen een foutief gedragen bot melden via het visitekaartje van de bot in de adreslijst. Ontwikkelaars moeten zich houden aan de servicevoorwaarden van Microsoft om deel te nemen aan de service.

Als u een uitgaande firewall hebt die verkeer van uw bot naar internet blokkeert, moet u de volgende URL's in die firewall toestaan:

• login.botframework.com (Botverificatie)
• login.microsoftonline.com (Botverificatie)
• westus.api.cognitive.microsoft.com (voor Luis.ai NLP-integratie)
• *.botframework.com (kanalen)
• state.botframework.com (compatibiliteit met eerdere versies)
• login.windows.net (Windows-aanmelding)
• login.windows.com (Windows-aanmelding)
• sts.windows.net (Windows-aanmelding)
• Andere URL's voor specifieke Bot Framework-kanalen

Bot Framework Services wordt wereldwijd gehost in Azure-datacenters en de lijst met Ip-adressen van Azure verandert voortdurend. Dit betekent dat het toestaan van bepaalde IP-adressen één dag kan werken en de volgende kan worden verbroken wanneer de Azure IP-adressen worden gewijzigd.

Voor het maken van een bot in Azure Portal is Inzender-toegang vereist voor het abonnement of een specifieke resourcegroep. Een gebruiker met de rol Inzender in een resourcegroep kan een nieuwe bot maken in die specifieke resourcegroep. Een gebruiker in de rol Inzender voor een abonnement kan een bot maken in een nieuwe of bestaande resourcegroep.

Met behulp van de Azure CLI kan een op rollen gebaseerd toegangsbeheer de aangepaste rollen ondersteunen. Als u een aangepaste rol wilt maken met meer beperkte machtigingen, kan de gebruiker met de onderstaande set een bot maken en implementeren die ook ONDERSTEUNING biedt voor LUIS, QnA Maker en Application Insights.

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

1. Alle authentieke Bot Framework-aanvragen worden vergezeld van een JWT-token waarvan de cryptografische handtekening kan worden geverifieerd door de verificatiehandleiding te volgen. Het token is zo ontworpen dat aanvallers geen vertrouwde services kunnen imiteren.
2. Het beveiligingstoken dat bij elke aanvraag aan uw bot hoort, heeft de ServiceUrl erin gecodeerd. Dit betekent dat zelfs als een aanvaller toegang krijgt tot het token, het gesprek niet kan worden omgeleid naar een nieuwe ServiceUrl. Dit wordt afgedwongen door alle implementaties van de SDK en gedocumenteerd in onze referentiemateriaal voor verificatie.
3. Als het binnenkomende token ontbreekt of onjuist is ingedeeld, genereert de Bot Framework SDK geen token als reactie. Hiermee wordt beperkt hoeveel schade kan worden uitgevoerd als de bot onjuist is geconfigureerd.
4. In de bot kunt u de ServiceUrl in het token handmatig controleren. Dit maakt de bot kwetsbaarder als de servicetopologie verandert, dus hoewel dit mogelijk is, wordt dit niet aanbevolen.

In de Webchat controle zijn er twee mechanismen om ervoor te zorgen dat de juiste gebruiker is aangemeld.

1. Magic code. Aan het einde van het aanmeldingsproces krijgt de gebruiker een willekeurig gegenereerde zescijferige code (magic code) te zien. De gebruiker moet deze code in het gesprek typen om het aanmeldingsproces te voltooien. Dit leidt meestal tot een slechte gebruikerservaring. Daarnaast is het nog steeds vatbaar voor phishingaanvallen. Een kwaadwillende gebruiker kan een andere gebruiker misleiden om zich aan te melden en de magic-code te verkrijgen via phishing.

   Waarschuwing

   Het gebruik van de magic-code is afgeschaft. In plaats daarvan moet u verbeterde verificatie voor Direct Line gebruiken, zoals hieronder wordt beschreven.

2. Verbeterde verificatie via Direct Line. Vanwege de problemen met de magic code-benadering heeft Azure AI Bot Service de noodzaak verwijderd. Azure AI Bot Service garandeert dat het aanmeldingsproces alleen kan worden voltooid in dezelfde browsersessie als de Webchat zelf. Als u deze beveiliging wilt inschakelen, moet u beginnen Webchat met een Direct Line-token dat een lijst met vertrouwde origins bevat, ook wel vertrouwde domeinen genoemd, die de Webchat-client van de bot kunnen hosten. Met verbeterde verificatieopties kunt u statisch de lijst met vertrouwde oorsprongen opgeven op de pagina Direct Line-configuratie. Zie Verbeterde verificatie via Direct Line voor meer informatie.

Het identiteits- en toegangsbeheer (IAM) is een framework (beleid en technologieën) waarmee de juiste mensen toegang hebben tot technologiebronnen. Zie Identiteitsbeheer voor meer informatie.

Bot Framework biedt de volgende identificatiemechanismen:

• Botverificatie. Bepaalt of een aanvraag afkomstig is van een legitieme bron. Het wordt beheerd door de botconnectorservice en maakt beveiligde communicatie mogelijk tussen een bot en een kanaal. Zie Botverificatie voor meer informatie.

• Gebruikersverificatie. Hiermee kan de bot namens de gebruiker toegang krijgen tot beveiligde onlinebronnen. De industriestandaard OAuth wordt gebruikt om de gebruiker te verifiëren en de bot toegang te geven tot de resources. Zie Gebruikersverificatie voor meer informatie.

Kortom, bot framework verwerkt de service-naar-service-verificatie (botverificatie), die in wezen valideert dat een aanvraag inderdaad afkomstig is van een juist kanaal. De bot is verantwoordelijk voor het verwerken van lagere verificatieniveaus. U kunt een filter toepassen zodat uw bot alleen aanvragen van een bepaalde tenant-id accepteert, of u kunt vereisen dat uw gebruikers worden geverifieerd met een bepaalde OAuth-service (gebruikersverificatie).

U hebt twee verschillende opties voor het beperken van binnenkomende berichten die door uw bot worden verwerkt.

• Als u te maken hebt met beveiligde gegevens, is het raadzaam om OAuth te gebruiken om de gebruikers te verifiëren.

• Het gebruik van middleware is een andere goede optie. In het Teams-kanaal kunt u bijvoorbeeld middleware maken om de tenant-id op te halen uit de Teams-kanaalgegevens. De middleware kan vervolgens bepalen of de binnenkomende activiteit naar uw botlogica moet worden voortgezet of dat er in plaats daarvan een foutbericht wordt geretourneerd.

  Waarschuwing

  U kunt niet voorkomen dat Teams u berichten van verschillende tenants stuurt en u kunt ook voorkomen dat iemand uw bot installeert als deze uw app-manifest heeft. U kunt alleen voorkomen dat uw bot de ongewenste berichten verwerkt.