如何使用安全性 Webhook 從腳本向 Teams 和 Slack 發送警報

如果您從事雲端基礎架構、持續整合/持續交付 (CI/CD)、監控或事件管理方面的工作，您可能需要… 所有重要通知都會直接發送到您的頻道。 微軟團隊 或 Slack透過腳本、自動化或外部服務實現此目的的最靈活、最簡單的方法是使用 webhook……前提是你要做好保護措施。

近年來，情況發生了變化： Teams 中來自 Office 365 的舊連接器等正在停用。資料防洩漏 (DLP) 策略日益嚴格，許多服務僅支援特定格式的 JSON 資料（例如 Amazon SNS、Azure Monitor 或 ClickUp）。這意味著將警報整合到 Teams 和 Slack 中並非簡單的「貼上 URL」就能完成；它需要仔細考慮安全性、有效負載格式和架構。

webhook 究竟是什麼？為什麼它對發出警報如此有用？

webhook 只不過是一個 接受 POST 請求的 HTTP 或 HTTPS URL 來自另一個系統。每次觸發事件（生產錯誤、部署失敗、資源狀態變更等）時，您的 腳本 該服務會將 JSON 資料傳送到該 URL，訊息將顯示在您選擇的 Teams 或 Slack 頻道中。

在這個方案中， Teams 和 Slack 充當被動接收器他們只是在等待有人以正確的格式發送請求。這樣做的好處是，從你的角度來看，你幾乎可以使用任何語言或環境。 PowerShell的巴什 蟒蛇AWS Lambda、Azure Functions、CI 管道、本機應用程序，無論你想要什麼。

重要的是要清楚 每個平台都要求特定的 JSON 結構。例如，Slack 或 Microsoft Teams 的 webhook 通常至少需要一個包含訊息文字的欄位（通常是 "文字"），而其他服務（例如 Amazon Chime）則需要不同的金鑰（例如）。 “內容”).

另一點是，許多雲端服務（Azure、AWS、ClickUp 等） 他們發送的內容格式與 Teams 或 Slack 期望的格式不完全一致。但它有自己獨特的事件和警報有效載荷方案。這就是為什麼你通常需要一個「中間件」來將這些資訊轉換成正確的格式。

整合類型：Webhook、連接器、機器人和 API

在 Microsoft Teams 的世界裡，有幾種方法可以 接收來自腳本或外部服務的自動通知區分它們對於選擇合適的架構至關重要：

一邊是 傳入的 webhook這是向 Teams 頻道發送訊息最直接的方式。在頻道中啟用此功能後，系統會產生一個接受 JSON 格式的 HTTPS URL，並將內容插入對話中。無需安裝複雜的應用程式或額外的 Azure 資源；這是頻道自帶的功能。

另一端是… 通知 API 和通知機器人這些是 Teams 最先進的功能之一。我們指的是功能齊全的 Teams 應用，它們可以向使用者、聊天或頻道發送豐富的通知，利用 Microsoft Graph，檢索使用者上下文，在儀表板中顯示內容等等。如果您正在尋找個人化體驗、動態自適應卡片和複雜的業務規則，那麼它就是理想之選。

參與其中的還有 用於群組的連接器 微軟365這些功能可讓您將 Webhook 及其專屬設定頁面打包到 Teams 應用中。它們通常使用操作有限的連接器卡片，非常適合與天氣、事件和其他連接器等「產品」整合。

最後，有 基於圖的通知 API它作為一個 RESTful 端點，用於觸發 Teams 活動來源中的通知。當您希望 Web 應用程式或後端向特定使用者或使用者群組發送包含聲音和作業系統通知的緊急警報時，它非常強大。

告別 Office 365 連接器：為什麼現在是時候遷移到 Power Automate 了

如果您多年來一直使用 Teams 發送訊息， Office 365 連接器 Webhook您可能已經看到相關通知，表示此功能即將停用。微軟正在調整其生態系統，使其符合「面向未來」的策略，這實際上意味著要轉向更現代化、更可控的解決方案，例如 Power Automate 和當前的 API。

推薦的從腳本繼續發送警報的方法是： 使用 Power Automate 流來協調向 Teams 的交付。您的腳本不會直接呼叫 Office 365 webhook，而是觸發 Power Automate HTTP 觸發器，此流程會使用支援的連接器來建立訊息並將其傳送到 Teams 頻道。

在典型情況下，你會創造一個 雲端流，觸發器類似“當收到 HTTP 請求時”您可以透過 PowerShell、Bash 或 Python 腳本向該端點發送 POST 請求，並傳遞相關資料（嚴重性、來源、事件描述等）。工作流程會處理 JSON 數據，將其轉換為適用於 Teams 的卡片或訊息，並發佈到您選擇的頻道。

這種方法有幾個優點： 它使您無需考慮連接器未來的變化。它允許您集中管理警報的格式化和路由邏輯，並且更容易滿足安全性和合規性要求，因為 Power Automate 可以與 Microsoft 365 DLP 和治理整合。

保護您的 Webhook：令牌、租用戶和資料遺失防護 (DLP)。

在公開 webhook URL 時，一個重要的問題是如何 阻止任何人向您的頻道發送訊息 如果你發現了那個地址。雖然 Webhook 非常方便，但必須將其視為敏感憑證。

常用的模式包括： 在 URL 中新增授權令牌作為參數。例如，一個端點可能如下所示： https://miservicio/webcallback?tokenid=sometokenid&someparameter=somevalue接收呼叫的服務會在處理請求之前驗證令牌是否有效。這樣，即使有人看到沒有正確令牌的 URL，也無法使用它。

在 Azure 和 Microsoft 365 環境中，通常會更進一步， 在 Microsoft 上註冊應用程序，輸入 ID （原 Azure AD）用於保護 HTTP 終端點。 Power Automate 流可以發佈在 API 管理或 Entra 保護的函數之後，因此只有屬於您租用戶的已驗證腳本才能觸發 Webhook。

此外，許多組織也申請 資料遺失防護 (DLP) 策略 在諸如 Power Automate 或 Power 等環境中 應用程式這些策略可以阻止或限制某些連接器的使用（例如，將資料從「機密」環境傳送到被視為「不受信任」的連接器，例如 Teams Webhook）。如果在保存或運行流程時遇到錯誤，根本原因可能在於資料防洩漏 (DLP) 策略。

在這種情況下，需要與 IT 團隊或管理團隊一起進行審查。 連接器分段是如何設定的？ 並進行調整，使您的 Teams 或 Slack webhook 成為您的流程或應用程式運作環境中允許的連接器之一。

JSON 上傳格式：從 Azure Monitor 上傳到 Teams 和 Slack

Azure Monitor、Azure 活動日誌或安全系統等服務會產生 具有非常豐富且詳細的 JSON 模式的警報事件當這些事件作為一組操作的一部分發送到 webhook 時，端點收到的有效負載包含大量訊息，而不僅僅是訊息文字。

警報通知的典型佈局 Azure 活動日誌 包含一個字段 schemaId 和一個對象 data 其中包含警報狀態、上下文和屬性。 data.context.activityLog 諸如通道類型之類的資料出現， correlationId事件時間戳、等級（嚴重、錯誤、警告、訊息） operationName受影響的資源標識符等等。

取決於以下數值 eventSource 在該負載中，具體結構各不相同：存在以下類型的事件 行政, 安全防護, 推薦, ServiceHealth o ResourceHealth每件事都有其自身特定的屬性。例如，安全事件可能詳細說明 暴力破解嘗試 SSH攻擊者的 IP 位址、使用的使用者、失敗嘗試次數以及建議的補救措施。

負載的其他元素包括以下欄位： 授權 （基於角色的存取控制的行動和範圍） 呼叫者 （執行操作的使用者的電子郵件地址或UPN） eventDataId （唯一識別碼）， 子狀態 （通常帶有 HTTP 程式碼，例如 200、400、404、500 等），以及一個字典 properties 使用鍵值對為事件新增更多上下文資訊。

為了在 Teams 或 Slack 中使用這些數據，直接複製整個 JSON 檔案是不合理的。更實際的做法是使用你的腳本或函數。 提取相關字段 （受影響的資源、嚴重程度、描述、關鍵時間戳、關聯性），並建立更易讀的訊息，清楚地說明發生了什麼、在哪裡發生以及下一步該做什麼。

從 Amazon SNS 到 Slack、Teams 和 Chime，Lambda 都能輕鬆應付。

當您需要時，Amazon Simple Notification Service (SNS) 是另一個關鍵元件。 對 AWS 事件做出反應，並將其傳送到聊天頻道。SNS 可以將訊息發佈到 HTTP/HTTPS 端點，但並非總是以 Slack、Microsoft Teams 或 Amazon Chime webhook 所期望的格式發布。

例如，當您設定 SNS 主題以向 webhook 發布訊息時，通知的 JSON 有效負載有其自身的按鍵（訊息、主題、時間戳記等）。但是， Slack 和 Teams 要求請求內文包含「text」鍵。 訊息將顯示在頻道上，同時 Amazon Chime 正在搜尋金鑰 “內容”SNS 不支援在發佈時直接轉換該格式。

AWS 中建議的解決方案是使用 Lambda 函數作為中間層與其直接將 webhook 訂閱到 SNS 主題，不如建立一個 SNS 主題，配置一個 Lambda 函數來訂閱該主題，然後從 Lambda 函數向 webhook 發送 POST 請求，並將 JSON 轉換為正確的結構。

流程大致如下：SNS 將事件發佈到 Lambda 函數；此函數讀取事件。 事件[«記錄»][0][«Sns»][«訊息»]建立一個字典，使用適當的按鍵（Chime 為“Content”，Slack 或 Teams 為“text”，還可以選擇性地添加其他內容）。 渠道, 用戶名 o 圖示_表情符號 （以 Slack 為例），將其序列化為 JSON 並使用 HTTP 庫（例如）發出 POST 請求。 網址庫3.

在Python程式碼中，基本框架非常簡單：你創建一個 池管理器您定義 webhook URL，建立包含預期欄位的訊息，將其轉換為 UTF-8 編碼的 JSON，然後傳送請求。之後，您可以記錄日誌。 狀態碼 以及用於偵錯的回應正文，檢查 webhook 是否正確接受訊息（代碼 200），或在參數無效或 URL 不正確時識別 4xx 錯誤。

在控制台中使用測試事件（使用「SNS 主題通知」範本）驗證 Lambda 函數的行為後，下一步是： 新增 SNS 主題作為觸發器 此功能的作用在於，每次服務向該主題發布訊息時（例如，CloudWatch 警報、實例狀態事件等），警報都會以理想的格式出現在 Slack、Teams 或 Chime 中。

Microsoft Teams 中的 Webhook：傳入、傳出和連接器

在團隊內部有 各種類型的連接 這些超出了典型的傳入 webhook 範圍，了解它們對於更好地設計警報解決方案很有幫助。

很多 傳出網路鉤子 它們允許您使用 @ 符號從頻道「呼叫」外部服務。您需要使用服務的 URL 配置出站 Webhook，當使用者透過訊息呼叫它時，Teams 會將文字傳送到您的端點，並期望快速收到回應（通常在 10 秒內），回應內容可以是純文字或卡片。這對於以下情況非常有用： 命令 或者說是按需查詢，而不是自動警報。

很多 傳入的 webhook正如我們之前提到的，它們非常適合 接收定期提醒和通知 來自外部應用程式。您可以在通道（例如 DevOps 通道）中建立 webhook，並設定您的管道、部署腳本、監控工具或安全系統，使其使用 HTTP POST 將其事件傳送至該 URL。

然後有 Microsoft 365 群組連接器這些功能可以將傳入的 Webhook 與 Teams 中的設定介面打包在一起。它們通常以連接器卡片的形式發送訊息，並提供更「產品化」的體驗，例如在天氣連接器中選擇位置、安排通知時間等等。

從建築學的角度來看，如果你的主要需求是… 您的腳本和工具會向頻道發送訊息 如果不需要太多視覺效果，簡單的傳入 Webhook 通常就足夠了。如果您需要複雜的邏輯、進階自訂和互動式操作，那麼通知機器人或具有通知 API 的 Teams 應用會更合適。

如何在 Teams 中建立傳入 Webhook 並從外部服務中使用它

在 Teams 頻道中啟用傳入 webhook 的過程相當機械化，但值得。 完全理解每個步驟 然後將其與您的腳本或應用程式整合。

首先，在 Teams 介面中選擇團隊，然後 標準頻道 您希望警報顯示的位置。這可以是現有頻道（例如「事件」），也可以是專門為整合而創建的新頻道。

然後點擊頻道名稱旁邊的三個點，並選擇該選項 連接器在可用連接器清單中，找到“傳入 Webhook”，然後按一下“設定”。接下來，為其指派一個能夠識別其用途的名稱（例如，「CertSecure 警報」、「CI/CD 警報」或「Azure 監控」），並且（可選）上傳一個圖標，以便更容易識別消息來源。

確認創建後，Teams 會產生一個 唯一 webhook URL你需要複製這個位址並貼上到外部工具或服務的設定中。務必妥善保管，因為任何獲取到此地址的人都可以代表你向該頻道發送訊息。

某些產品，例如憑證管理解決方案（例如 CertSecure），在其自身的管理入口網站中設有專門的版塊。 整合團隊他們通常會要求你貼上 webhook URL；儲存後，系統會向團隊頻道發送測試訊息，表示整合已成功完成。

從那裡，您可以啟用或停用不同的 通知事件 （頒發新憑證、撤銷、續約、到期或到期前提醒）以便每次相關變更都會在頻道中產生一條自動訊息，使團隊能夠及時了解最新情況，而無需不斷存取工具的面板。

ClickUp、Slack 和其他服務的常見問題

並非所有平台都能立即相容於 Slack 或 Teams 的 Webhook，即使看起來只需貼上一個 URL 即可。一個典型的例子是… ClickUp 和 Slack 當您希望在資料夾或清單狀態發生變更時通知頻道時。

ClickUp 可讓您設定自動化流程，當狀態變更時，會觸發一個操作，該操作會向 webhook URL（例如，產生傳入 webhook 的 Slack URL）發送請求。問題在於… ClickUp 會傳送它自己的 JSON 有效負載。 由於採用了與 Slack 預期不符的方案，因此通知可能不會出現在頻道中。

在 Slack 中，傳入的 webhook 通常會預期會收到一些簡單的訊息，例如： { "text": "Mensaje a mostrar" }其中包含一些可選字段，例如頻道、使用者名稱或圖示。如果您收到的是包含 ClickUp 特有欄位的巢狀 JSON， 您可以忽略此請求。 或誤解它，導致發出的警報實際上從未被看到。

解決這類不相容性的最佳方法是引入… 充當翻譯器的中間層與 SNS 和 Lambda 類似，ClickUp 的 webhook 不是直接指向 Slack，而是指向您自己的端點（例如雲端函數或後端的小型 API）。此端點接收 ClickUp 的 JSON 數據，提取相關資訊（例如任務名稱、先前狀態和新狀態、負責人），並建立 Slack 所需的最小 JSON 數據，然後將請求轉發到 Slack 的傳入 webhook。

這種模式可以推廣到許多其他「傳送 JSON」但格式不符合 Slack 或 Teams 要求的工具。透過擁有自己的整合層，您可以完全控制… 訊息格式化、過濾、安全和增強而且，您無需修改所有腳本的配置即可處理 API 變更。

利用安全 Webhook 從腳本向 Teams 和 Slack 發送警報，並非僅僅是複製貼上 URL 那麼簡單：它需要了解不同類型的 Teams 整合、Azure Monitor 和 Amazon SNS 等服務的 JSON 模式、Power Automate 或 AWS Lambda 等中間件層的作用，以及圍繞所有這些的安全和資料防洩漏措施 (DLP) 措施。如果架構設計得當，您的團隊將能夠收到豐富、可靠且即時的警報，而無需擔心過時的連接器變更或不相容的格式悄無聲息地吞噬您的通知。