Häufig gestellte Fragen zu Datenschutz und Sicherheit in Bot Framework

Jeder Bot ist ein eigener Dienst, und die Entwickler dieser Dienste sind aufgefordert, Nutzungsbedingungen und Datenschutzrichtlinien in ihre Verhaltensregeln für Entwickler einzubinden. Weitere Informationen finden Sie in den Richtlinien für die Bot-Überprüfung.

Ja. Ihr Bot kann überall im Internet gehostet werden – auf Ihren eigenen Servern, in Azure oder in jedem beliebigen anderen Rechenzentrum. Die einzige Voraussetzung ist, dass der Bot einen öffentlich zugänglichen HTTPS-Endpunkt verfügbar machen muss.

Benutzer haben die Möglichkeit, einen fehlerhaften Bot über die Kontaktkarte des Bots im Verzeichnis zu melden. Entwickler müssen die Vertragsbedingungen von Microsoft einhalten, um den Dienst nutzen zu können.

Wenn Sie eine ausgehende Firewall haben, die Datenverkehr vom Bot in das Internet blockiert, müssen Sie in der Firewall die folgenden URLs auf die Whitelist setzen:

• login.botframework.com (Botauthentifizierung)
• login.microsoftonline.com (Botauthentifizierung)
• westus.api.cognitive.microsoft.com (NLP-Integration von Luis.ai)
• *.botframework.com (Kanäle)
• state.botframework.com (Abwärtskompatibilität)
• login.windows.net (Windows-Anmeldung)
• login.windows.com (Windows-Anmeldung)
• sts.windows.net (Windows-Anmeldung)
• Andere URLs für spezifische Bot Framework-Kanäle

Bot Framework Service wird in Azure-Rechenzentren auf der ganzen Welt gehostet, und die Liste der Azure-IP-Adressen ändert sich laufend. Das heißt, dass bestimmte IP-Adressen manchmal auf die Whitelist aufgenommen werden kann und manchmal nicht, wenn sich die Azure-IP-Adressen ändern.

Für die Bot-Erstellung über das Azure-Portal ist Zugriff vom Typ „Mitwirkender“ erforderlich – entweder im Abonnement oder in einer bestimmten Ressourcengruppe. Ein Benutzer, der über die Rolle Mitwirkender in einer Ressourcengruppe verfügt, kann einen neuen Bot in dieser spezifischen Ressourcengruppe erstellen. Ein Benutzer, der über die Rolle Mitwirkender für ein Abonnement verfügt, kann einen Bot in einer neuen Ressourcengruppe oder in einer bereits vorhandenen Ressourcengruppe erstellen.

Bei Verwendung der Azure-Befehlszeilenschnittstelle können über die rollenbasierte Zugriffssteuerung benutzerdefinierte Rollen unterstützt werden. Wenn Sie eine benutzerdefinierte Rolle mit stärker eingeschränkten Berechtigungen erstellen möchten, erlaubt die folgende Gruppe dem Benutzer das Erstellen und Bereitstellen eines Bots zu ermöglichen, der auch LUIS, QnA Maker und Application Insights unterstützt.

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

1. Alle authentischen Bot Framework-Anfragen verfügen über ein JWT-Token, dessen kryptografische Signatur überprüft werden kann, indem Sie der Anleitung zur Authentifizierung folgen. Das Token ist so konzipiert, dass Angreifer nicht die Identität vertrauenswürdiger Dienste imitieren können.
2. Das Sicherheitstoken, das mit jeder Anforderung an Ihren Bot gesendet wird, enthält die codierte „ServiceUrl“. Selbst wenn ein Angreifer Zugriff auf das Token erlangt, kann er daher die Konversation nicht an eine neue „ServiceUrl“ umleiten. Dieses Verhalten wird von allen Implementierungen des SDK erzwungen und ist in unseren Referenzmaterialien zur Authentifizierung dokumentiert.
3. Wenn das eingehende Token fehlt oder falsch formatiert ist, generiert das Bot Framework SDK kein Token. Auf diese Weise wird der Schaden begrenzt, der im Fall einer falschen Bot-Konfiguration entstehen kann.
4. Innerhalb des Bots können Sie die im Token bereitgestellte „ServiceUrl“ manuell überprüfen. Dadurch ist der Bot anfälliger, wenn Änderungen an der Diensttopologie vorgenommen werden. Diese Vorgehensweise ist also möglich, aber nicht empfehlenswert.

Im Webchat-Steuerelement gibt es zwei Mechanismen, um sicherzustellen, dass der richtige Benutzer angemeldet ist.

1. Magic- Code. Am Ende der Anmeldung wird dem Benutzer bisher ein zufällig generierter 6-stelliger Code (auch bekannt als Magic-Code) bereitgestellt. Der Benutzer muss diesen Code in der Konversation eingeben, um den Anmeldevorgang abzuschließen. Das führt tendenziell zu einer schlechten Benutzererfahrung. Zudem ist er nach wie vor anfällig für Phishing-Angriffe. Ein böswilliger Benutzer kann einen anderen Benutzer dazu bringen, sich anzumelden und den magischen Code durch Phishing erhalten.

   Warnung

   Die Verwendung des Magic-Code ist veraltet. Stattdessen sollten Sie die erweiterte Direct Line-Authentifizierung verwenden, die unten beschrieben wird.

2. Erweiterte Direct Line-Authentifizierung Aufgrund der Probleme mit dem Magic-Code-Ansatz hat Azure KI Bot Service die Anforderung dafür entfernt. Azure KI Bot Service garantiert, dass der Anmeldevorgang nur in derselben Browsersitzung durchgeführt werden kann, in der sich auch die Web Chat-Instanz befindet. Um diesen Schutz zu aktivieren müssen Sie Webchat mit einem Direct Line-Token starten, das eine Liste mit vertrauenswürdigen Ursprüngen, auch als vertrauenswürdige Domänen bekannt, enthält, die den Webchat-Client des Bots hosten können. Mithilfe von erweiterten Authentifizierungsoptionen können Sie nun die Liste der vertrauenswürdigen Ursprünge auf der Direct Line-Konfigurationsseite statisch angeben. Weitere Informationen finden Sie unter erweiterte Direct Line-Authentifizierung.

Das Identitäts- und Zugriffsmanagement (IAM) ist ein Framework (Richtlinien und Technologien), um den richtigen Personen einen angemessenen Zugang zu Technologieressourcen zu ermöglichen. Weitere Informationen finden Sie unter Identitätsverwaltung.

Das Bot Framework bietet die folgenden Identifikationsmechanismen:

• Botauthentifizierung. Bestimmt, ob eine Anforderung aus einer legitimen Quelle stammt. Es wird vom Bot-Konnektor-Dienst gesteuert und ermöglicht eine sichere Kommunikation zwischen einem Bot und einem Kanal. Weitere Informationen finden Sie unter Bot-Authentifizierung.

• Benutzerauthentifizierung. Es ermöglicht dem Bot den Zugriff auf gesicherte Online-Ressourcen im Namen des Benutzers. Der Branchenstandard OAuth wird verwendet, um den Benutzer zu authentifizieren und den Bot für den Zugriff auf die Ressourcen zu autorisieren. Weitere Informationen finden Sie unter Benutzerauthentifizierung.

Zusammenfassend behandelt das Bot Framework die Dienst-zu-Dienst-Authentifizierung (Bot-Authentifizierung), wobei im Wesentlichen überprüft wird, dass eine Anforderung tatsächlich von einem richtigen Kanal stammt. Der Bot ist für die Behandlung niedrigerer Authentifizierungsebenen verantwortlich. Sie können einen Filter anwenden, sodass Ihr Bot nur Anforderungen aus einer bestimmten Mandanten-ID akzeptiert, oder Sie können ihre Benutzer zur Authentifizierung bei einem OAuth-Dienst (Benutzerauthentifizierung) verpflichten.

Sie haben zwei verschiedene Optionen zum Einschränken eingehender Nachrichten, die Ihr Bot verarbeitet.

• Wenn Sie mit sicheren Daten arbeiten, empfiehlt es sich definitiv, OAuth zur Authentifizierung der Benutzer zu verwenden.

• Die Verwendung von Middleware ist eine weitere gute Option. Im Teams-Kanal können Sie beispielsweise Middleware erstellen, um die Mandanten-ID aus den Teams-Kanaldaten abzurufen. Die Middleware kann dann entscheiden, ob die eingehende Aktivität mit Ihrer Bot-Logik fortgesetzt werden oder stattdessen eine Fehlermeldung zurückgegeben werden soll.

  Warnung

  Sie können nicht verhindern, dass Microsoft Teams Nachrichten von verschiedenen Mandanten sendet oder dass jemand Ihren Bot installiert, wenn er über Ihr App-Manifest verfügt. Alles, was Sie tun können, ist, zu verhindern, dass Ihr Bot die unerwünschten Nachrichten verarbeitet.