Bot Framework 安全性和隱私權常見問題

本文回答常見的安全性和隱私權問題。

適用于: SDK v4

向 Bot Framework 註冊的 Bot 會收集個人資訊嗎? 如果是,如何確定資料是安全的? 隱私權呢?

每個 Bot 都是它自己的服務,這些服務的開發人員必須根據其開發人員管理辦法,提供服務條款及隱私權聲明。 如需詳細資訊,請參閱 Bot 檢閱指導方針

我可以在自己的伺服器上裝載 Bot 嗎?

是。 您的 Bot 可以裝載于網際網路上的任何位置。 在您自己的伺服器上、Azure 或任何其他資料中心。 唯一的需求是 Bot 必須公開可公開可公開存取的 HTTPS 端點。

如何禁止或移除服務的 Bot?

使用者有辦法透過 Bot 的連絡人卡片在目錄中回報行為錯誤的 Bot。 開發人員必須遵守 Microsoft 服務條款才能參與服務。

我需要在公司防火牆中允許列出哪些特定 URL,才能存取 Bot Framework 服務?

如果您有封鎖從 Bot 到網際網路流量的輸出防火牆,則必須在該防火牆中列出下列 URL:

  • login.botframework.com (Bot 驗證)
  • login.microsoftonline.com (Bot 驗證)
  • westus.api.cognitive.microsoft.com (適用于 Luis.ai NLP整合)
  • *.botframework.com (頻道)
  • state.botframework.com (回溯相容性)
  • login.windows.net (Windows 登入)
  • login.windows.com (Windows 登入)
  • sts.windows.net (Windows 登入)
  • 特定 Bot Framework 通道的其他 URL

注意

Language Understanding (LUIS) 將于 2025 年 10 月 1 日淘汰。 從 2023 年 4 月 1 日起,您將無法建立新的 LUIS 資源。 新版的語言理解現在已提供作為 Azure AI 語言的一部分。

對話式語言理解(CLU)是 Azure AI 語言的一項功能,是 LUIS 的更新版本。 如需 Bot Framework SDK 中語言理解支援的詳細資訊,請參閱 自然語言理解

注意

如果您不想允許以星號列出 URL,您可以使用 <channel>.botframework.com<channel> 等於 Bot 所使用的每個通道,例如 directline.botframework.comwebchat.botframework.comslack.botframework.com 。 在測試 Bot 時,也值得監看防火牆上的流量,以查看其封鎖的流量。

我可以封鎖 Bot 的所有流量,但來自 Bot Framework 服務的流量除外?

Bot Framework Services 裝載于全球 Azure 資料中心,且 Azure IP 清單會不斷變更。 這表示允許列出特定 IP 位址可能會有一天工作,並在 Azure IP 位址變更時中斷下一個 IP 位址。

建立及部署 Bot 所需的 RBAC 角色為何?

在 Azure 入口網站中建立 Bot 需要訂用帳戶或特定資源群組中的「參與者」存取權。 具有 資源群組中參與者 角色的使用者可以在該特定資源群組中建立新的 Bot。 訂用帳戶參與者 角色中的使用者可以在新的或現有的資源群組中建立 Bot。

使用 Azure CLI 時,角色型存取控制方法可以支援自訂角色。 如果您想要建立具有更多限制許可權的自訂角色,下列集合可讓使用者建立及部署也支援 LUIS、QnA Maker 和 Application Insights 的 Bot。

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

注意

Azure AI QnA Maker 將于 2025 年 3 月 31 日淘汰。 從 2022 年 10 月起,您將無法建立新的 QnA Maker 資源或知識庫。

Language Understanding (LUIS) 將于 2025 年 10 月 1 日淘汰。 從 2023 年 4 月 1 日起,您將無法建立新的 LUIS 資源。

這些服務的較新版本現在已可供作為 Azure AI 語言的一部分使用。 如需 Bot Framework SDK 中問答與語言理解支援的詳細資訊,請參閱 自然語言理解

注意

LUIS 和 QnA Maker 需要 Azure AI 服務許可權。 QnA Maker 也需要搜尋許可權。 建立自訂角色時,請記住,任何繼承的 拒絕 許可權都會取代這些 允許 許可權。

如何保護 Bot 的安全,防止模擬 Bot Framework 服務的用戶端?

  1. 所有正宗的 Bot Framework 要求都會隨附 JWT 權杖,其密碼編譯簽章可以遵循 驗證指南進行驗證 。 權杖的設計目的是讓攻擊者無法模擬受信任的服務。
  2. 每個要求給 Bot 的安全性權杖都會在 Bot 中編碼 ServiceUrl,這表示即使攻擊者取得權杖的存取權,他們也無法將交談重新導向至新的 ServiceUrl。 這會由 SDK 的所有實作強制執行,並記載于我們的驗證 參考 資料中。
  3. 如果傳入權杖遺失或格式不正確,Bot Framework SDK 將不會在回應中產生權杖。 如果 Bot 設定不正確,這會限制可以完成多少損害。
  4. 在 Bot 中,您可以手動檢查權杖中提供的 ServiceUrl。 這可讓 Bot 在服務拓撲變更時更加脆弱,因此雖然可行,但不建議這麼做。

注意

這些是從 Bot 到網際網路的輸出連線。 Bot Framework 連線or Service 不會使用 IP 位址或 DNS 名稱清單來與 Bot 通訊。 不支援輸入 IP 位址允許清單。

驗證期間魔術程式碼的用途為何?

在網路聊天控制項中,有兩種機制可確保適當的使用者已登入。

  1. Magic 程式碼 。 在登入程式結束時,使用者會看到隨機產生的 6 位數代碼( magic code )。 使用者必須在交談中輸入此程式碼,才能完成登入程式。 這通常會導致使用者體驗不佳。 此外,它仍然容易受到網路釣魚攻擊。 惡意使用者可誘使其他使用者登入,並透過網路釣魚取得魔術代碼。

    警告

    魔術程式碼的使用已被取代。 相反地,您應該使用 Direct Line 增強式驗證 ,如下所述。

  2. Direct Line 增強驗證 。 由於魔術程式碼 方法的問題 ,Azure AI Bot Service 已移除其需求。 Azure AI Bot Service 保證登入程式只能在與網路聊天本身相同的瀏覽器會話 完成。 若要啟用此保護,您必須使用包含受信任來源 清單的 Direct Line 權杖來啟動網路聊天 ,這些權杖 也稱為可裝載 Bot 網路聊天 用戶端的受信任網域。 使用增強的驗證選項,您可以在 [Direct Line 組態] 頁面中以靜態方式指定受信任的來源清單。 如需詳細資訊,請參閱 Direct Line 增強驗證

Bot Framework 如何處理身分識別和存取管理?

身分識別和存取管理(IAM)是一個架構(原則和技術),可讓適當的人員有適當的技術資源存取權。 如需詳細資訊,請參閱 身分識別管理

Bot Framework 提供下列識別機制:

  • Bot 驗證 。 判斷要求是否來自合法來源。 它是由 Bot 連接器服務 所控制,可啟用 Bot 與通道之間的安全通訊。 如需詳細資訊,請參閱 Bot 驗證

  • 使用者驗證。 它可讓 Bot 代表使用者存取受保護的線上資源。 業界標準 OAuth 可用來驗證使用者,並授權 Bot 存取資源。 如需詳細資訊,請參閱 使用者驗證

總而言之,Bot Framework 會處理服務對服務驗證(Bot 驗證),基本上驗證要求確實來自適當的通道。 Bot 負責處理較低層級的驗證。 您可以套用篩選準則,讓 Bot 只接受來自特定租使用者識別碼的要求,或要求使用者向某些 OAuth 服務進行驗證(使用者驗證)。

如何?將 Bot 的使用限制為僅屬於我的租使用者的使用者?

您有兩種不同的選項可限制 Bot 處理的傳入訊息。

  • 如果您正在處理安全的資料,絕對建議您使用 OAuth 來驗證使用者。

  • 使用中介軟體是另一個很好的選項。 例如,在 Teams 頻道 中,您可以建立中介軟體,從 Teams 頻道資料取得租使用者識別碼 。 中介軟體接著可以決定是否讓傳入活動繼續進入 Bot 邏輯,或改為傳回錯誤訊息。

    警告

    您無法防止 Teams 從各種租使用者傳送訊息,也無法防止有人在具有您的應用程式資訊清單時安裝 Bot。 您可以做的就是防止 Bot 處理不想要的訊息。