Jak wysyłać alerty do aplikacji Teams i Slack ze skryptów przy użyciu bezpiecznych webhooków

Jeśli pracujesz z infrastrukturą chmurową, CI/CD, monitorowaniem lub zarządzaniem incydentami, prawdopodobnie będziesz chciał Wszystkie ważne alerty trafiają bezpośrednio do Twoich kanałów. Zespoły Microsoft lub SlackNajbardziej elastycznym i prostym sposobem osiągnięcia tego celu za pomocą skryptów, automatyzacji lub usług zewnętrznych jest użycie webhooków… pod warunkiem, że będą odpowiednio zabezpieczone.

W ostatnich latach sytuacja uległa zmianie: Starsze łączniki, takie jak te z pakietu Office 365 w aplikacji Teams, są wycofywane.Zasady DLP stają się coraz bardziej rygorystyczne, a wiele usług komunikuje się z JSON tylko w ściśle określonych formatach (takich jak Amazon SNS, Azure Monitor czy ClickUp). To wszystko oznacza, że ​​integracja alertów z Teams i Slackiem to nie tylko „wklejenie adresu URL” i skończenie z zadaniem; wymaga starannego rozważenia kwestii bezpieczeństwa, formatów danych i architektury.

Czym właściwie jest webhook i dlaczego jest tak przydatny w przypadku alertów?

Webhook to nic innego jak Adres URL HTTP lub HTTPS akceptujący żądania POST z innego systemu. Za każdym razem, gdy zostanie wyzwolone zdarzenie (błąd produkcyjny, nieudane wdrożenie, zmiana stanu zasobu itp.), Twój scenariusz Usługa wysyła plik JSON na podany adres URL, a wiadomość pojawia się w wybranym przez Ciebie kanale Teams lub Slack.

W tym schemacie, Zespoły i Slack działają jako pasywne odbiornikiCzekają tylko, aż ktoś wyśle ​​im prośbę w odpowiednim formacie. Zaletą jest to, że możesz korzystać z praktycznie dowolnego języka i środowiska. PowerShellGrzmotnąć PythonAWS Lambda, Azure Functions, potoki CI, aplikacje lokalne – cokolwiek zechcesz.

Ważne jest, aby było to jasne Każda platforma oczekuje konkretnej struktury JSON.Na przykład webhook Slacka lub Microsoft Teams zwykle wymaga co najmniej jednego pola z tekstem wiadomości (zwykle "tekst"), podczas gdy inne usługi, takie jak Amazon Chime, oczekują innych kluczy (na przykład "Zadowolony").

Kolejnym kluczowym punktem jest to, że wiele usług w chmurze (Azure, AWS, ClickUp itp.) Nie wysyłają dokładnie takiego formatu, jakiego oczekują Teams i Slack.ale raczej własny schemat danych dla zdarzeń i alertów. Dlatego często potrzebny jest „element pośredniczący”, aby dostosować te informacje do prawidłowego formatu.

Typy integracji: webhooki, łączniki, boty i API

W świecie Microsoft Teams istnieje kilka sposobów odbieraj automatyczne powiadomienia ze skryptów lub usług zewnętrznychi ważne jest, aby je rozróżnić, aby wybrać odpowiednią architekturę:

Po jednej stronie są przychodzące webhookiTo najprostsza metoda wysyłania wiadomości do kanału w usłudze Teams. Włączenie tej funkcji w kanale generuje adres URL HTTPS akceptujący format JSON i wstawia treść do konwersacji. Nie wymaga instalowania skomplikowanej aplikacji ani dodatkowych zasobów platformy Azure; jest to natywna funkcja kanału.

Na drugim końcu masz API powiadomień i boty powiadomieńTo jedne z najbardziej zaawansowanych funkcji Teams. Mowa tu o pełnoprawnych aplikacjach Teams, które mogą wysyłać rozbudowane powiadomienia do użytkowników, czatów lub kanałów, korzystać z Microsoft Graph, pobierać kontekst użytkownika, wyświetlać treści na pulpitach nawigacyjnych i nie tylko. To idealne rozwiązanie, jeśli szukasz spersonalizowanych doświadczeń, dynamicznych kart adaptacyjnych i zaawansowanych reguł biznesowych.

Zaangażowani są również złącza dla grup Microsoft 365Umożliwiają one spakowanie webhooka z własną stroną ustawień jako części aplikacji Teams. Zazwyczaj korzystają z kart łączników z ograniczonym zestawem działań, co idealnie nadaje się do integracji „produktowych”, takich jak pogoda, zdarzenia i inne łączniki.

Wreszcie jest Interfejs API powiadomień oparty na grafieDziała jako punkt końcowy RESTful, który aktywuje powiadomienia w kanale aktywności Teams. Jest bardzo przydatny, gdy chcesz, aby Twoja aplikacja internetowa lub zaplecze wysyłały pilne alerty, z powiadomieniami dźwiękowymi i systemowymi, dotyczące krytycznych informacji, skierowane do określonych użytkowników lub grup.

Żegnaj łączniki pakietu Office 365: dlaczego czas przejść na usługę Power Automate

Jeśli od lat wysyłasz wiadomości do Teamsów za pomocą Webhooki łącznika Office 365Prawdopodobnie widzieliście już ogłoszenia o wycofaniu tej funkcjonalności. Microsoft dostosowuje ekosystem do swojej strategii „bezpiecznej przyszłości”, co w praktyce oznacza dążenie do nowocześniejszych i bardziej kontrolowanych rozwiązań, takich jak Power Automate i obecne interfejsy API.

Zalecanym sposobem kontynuowania wysyłania alertów ze skryptów jest zorganizuj dostawę do Teams za pomocą przepływu Power AutomateZamiast bezpośrednio wywoływać webhook usługi Office 365, skrypty uruchamiają wyzwalacz HTTP usługi Power Automate, a ten przepływ obsługuje tworzenie i wysyłanie wiadomości do kanału Teams przy użyciu obsługiwanych łączników.

W typowym scenariuszu tworzysz przepływ w chmurze z wyzwalaczem takim jak „Gdy zostanie odebrane żądanie HTTP”Ze skryptu PowerShell, Bash lub Pythona wysyłasz żądanie POST do tego punktu końcowego, przekazując odpowiednie dane (ważność, źródło, opis incydentu itp.). Przepływ pracy przetwarza dane JSON, przekształca je w kartę lub wiadomość dostosowaną do Teams i publikuje w wybranym kanale.

To podejście ma kilka zalet: Abstrahuje od przyszłych zmian w złączach.Umożliwia scentralizowanie logiki formatowania i kierowania alertami oraz ułatwia spełnianie wymagań dotyczących bezpieczeństwa i zgodności, ponieważ usługę Power Automate można zintegrować z usługą Microsoft 365 DLP i zarządzaniem.

Ochrona webhooków: tokeny, dzierżawcy i DLP

Jednym z najważniejszych pytań przy ujawnianiu adresu URL webhooka jest to, jak Zablokuj możliwość wysyłania wiadomości na Twój kanał przez kogokolwiek Jeśli odkryjesz ten adres. Chociaż webhooki są bardzo wygodne, należy je traktować jako poufne dane uwierzytelniające.

Często używany wzór składa się z dodaj token autoryzacyjny jako parametr w adresie URLNa przykład punkt końcowy może wyglądać tak: https://miservicio/webcallback?tokenid=sometokenid&someparameter=somevalueUsługa odbierająca połączenie weryfikuje ważność tokena przed przetworzeniem żądania. W ten sposób, nawet jeśli ktoś zobaczy adres URL bez poprawnego tokena, nie będzie mógł go użyć.

W środowiskach Azure i Microsoft 365 często idzie się o krok dalej i Zarejestruj aplikację w systemie Microsoft Wprowadź identyfikator (dawniej Azure AD) w celu ochrony punktu końcowego HTTP. Przepływ Power Automate można opublikować za pomocą funkcji API Management lub Entra, dzięki czemu tylko uwierzytelnione skrypty należące do dzierżawy mogą wyzwalać webhook.

Ponadto wiele organizacji stosuje zasady zapobiegania utracie danych (DLP) w środowiskach takich jak Power Automate lub Power AppsTe zasady mogą blokować lub ograniczać korzystanie z określonych łączników (na przykład wysyłanie danych z „poufnego” środowiska do łączników uznanych za „niezaufane”, takich jak webhook w Teams). Jeśli podczas zapisywania lub uruchamiania przepływu wystąpią błędy, przyczyną może być DLP.

W takim przypadku konieczne jest omówienie tej kwestii z zespołem IT lub zespołem ds. zarządzania. W jaki sposób konfigurowana jest segmentacja złącza? i dokonaj zmian, aby umożliwić Twojemu webhookowi Teams lub Slack dołączenie do dozwolonych łączników w środowisku, w którym działa Twój przepływ lub aplikacja.

Format przesyłania danych JSON: z Azure Monitor do Teams i Slack

Usługi takie jak Azure Monitor, Azure Activity Log czy systemy zabezpieczeń generują zdarzenia alertowe z bardzo bogatymi i szczegółowymi schematami JSONGdy zdarzenia te zostaną wysłane do webhooka jako część grupy akcji, ładunek odbierany przez punkt końcowy będzie zawierał wiele informacji, nie tylko tekst wiadomości.

Typowy układ powiadomienia o alercie Dziennik aktywności platformy Azure zawiera pole schemaId i obiekt data który zawiera status alertu, kontekst i właściwości. W ramach data.context.activityLog Wyświetlane są dane takie jak typ kanału, correlationId, znacznik czasu zdarzenia, poziom (krytyczny, błąd, ostrzeżenie, informacyjny), operationName, identyfikator zasobu, którego to dotyczy i więcej.

W zależności od wartości eventSource W tym obciążeniu struktura szczegółowa ulega zmianom: występują zdarzenia typu Administracyjny, Ochrona, Rekomendacja, ServiceHealth o ResourceHealthkażdy z własnymi specyficznymi właściwościami. Na przykład zdarzenie bezpieczeństwa może zawierać szczegółowe informacje próby siłowe SSH, adres IP atakujących, użyci użytkownicy, liczba nieudanych prób i sugerowane działania naprawcze.

Inne elementy obciążenia obejmują pola takie jak: autoryzacja (działanie i zakres kontroli dostępu opartej na rolach), dzwoniący (adres e-mail lub UPN użytkownika, który wykonał operację), eventDataId (unikalny identyfikator), podstatus (często z kodami HTTP takimi jak 200, 400, 404, 500 itd.) i słownikiem properties z parami klucz-wartość, które dodają więcej kontekstu do zdarzenia.

Aby to wszystko było przydatne w Teamsach lub Slacku, nie ma sensu kopiować całego pliku JSON w obecnej postaci. Praktycznym rozwiązaniem jest użycie własnego skryptu lub funkcji. wyodrębnij odpowiednie pola (zasób, którego dotyczy problem, powaga, opis, krytyczne znaczniki czasu, korelacja) i stworzyć bardziej czytelny komunikat, jasno określający, co się stało, gdzie i co należy zrobić dalej.

Od Amazon SNS do Slacka, Teams i Chime z Lambdą

Usługa Amazon Simple Notification Service (SNS) to kolejny kluczowy element, gdy chcesz reaguj na zdarzenia AWS i wysyłaj je do kanałów czatuSNS może publikować wiadomości w punktach końcowych HTTP/HTTPS, ale nie zawsze w formacie, jakiego oczekują webhooki Slack, Microsoft Teams czy Amazon Chime.

Na przykład, gdy skonfigurujesz temat SNS do publikacji w webhooku, ładunek JSON powiadomienia będzie miał własne klucze (wiadomość, temat, znacznik czasu itd.). Jednak Slack i Teams oczekują, że treść żądania będzie zawierać klucz „text”. z wiadomością, która będzie wyświetlana na kanale, podczas gdy Amazon Chime będzie szukał klucza "Zadowolony"W momencie publikacji serwis SNS nie obsługuje bezpośrednio transformacji tego formatu.

Zalecanym rozwiązaniem w AWS jest użycie Funkcja lambda jako warstwa pośredniaZamiast subskrybować webhook bezpośrednio do tematu SNS, tworzysz temat SNS, konfigurujesz funkcję Lambda, która subskrybuje ten temat, a następnie z Lambdy wysyłasz żądanie POST do webhooka z danymi JSON przekształconymi w odpowiednią strukturę.

Przepływ wyglądałby mniej więcej tak: SNS publikuje zdarzenie do funkcji Lambda; funkcja odczytuje wydarzenie[«Rekordy»][0][«Sns»][«Wiadomość»]Utwórz słownik z odpowiednim kluczem („Content” dla Chime, „text” dla Slacka lub Teams, opcjonalnie dodając kanał, nazwa użytkownika o ikona_emoji (w przypadku Slacka), serializuje do JSON i wysyła żądanie POST za pomocą biblioteki HTTP, takiej jak urllib3.

W kodzie Pythona podstawowy szkielet jest bardzo prosty: tworzysz Menedżer puliDefiniujesz adres URL webhooka, tworzysz wiadomość z oczekiwanymi polami, konwertujesz ją do JSON-a zakodowanego w UTF-8 i wysyłasz żądanie. Następnie możesz zalogować kod_statusu oraz treść odpowiedzi służącą do debugowania, sprawdzającą, czy webhook prawidłowo akceptuje wiadomość (kod 200) lub identyfikującą błędy 4xx, jeśli występują nieprawidłowe parametry lub adres URL jest niepoprawny.

Po sprawdzeniu zachowania funkcji Lambda za pomocą zdarzenia testowego w konsoli (przy użyciu szablonu „Powiadomienie dotyczące tematu SNS”) kolejnym krokiem jest dodaj motyw SNS jako wyzwalacz funkcji. W ten sposób za każdym razem, gdy usługa publikuje w temacie (na przykład alarmy CloudWatch, zdarzenia dotyczące stanu instancji itp.), alert trafi do Slacka, Teams lub Chime w idealnym formacie.

Webhooki w usłudze Microsoft Teams: przychodzące, wychodzące i łączniki

W Zespołach znajdują się: różne rodzaje łączności które wykraczają poza typowy przychodzący webhook i warto o nich wiedzieć, aby lepiej zaprojektować rozwiązanie dotyczące alertów.

L wychodzące webhooki Umożliwiają one „wywołanie” usługi zewnętrznej z kanału za pomocą symbolu @. Konfigurujesz wychodzący webhook za pomocą adresu URL swojej usługi, a gdy użytkownik wywoła go z wiadomością, Teams wysyła tekst do punktu końcowego i oczekuje szybkiej odpowiedzi (zwykle w ciągu 10 sekund) z treścią, która może być zwykłym tekstem lub kartą. Jest to przydatne w przypadku… polecenia lub zapytań na żądanie, a nie automatycznych alertów.

L przychodzące webhookiJak już wcześniej wspomnieliśmy, idealnie nadają się do otrzymuj okresowe alerty i powiadomienia Z aplikacji zewnętrznych. Tworzysz webhook w kanale (na przykład kanale DevOps) i konfigurujesz swoje potoki, skrypty wdrożeniowe, narzędzia monitorujące lub systemy bezpieczeństwa, aby wysyłały zdarzenia na ten adres URL za pomocą żądania HTTP POST.

Potem są Łączniki dla grup Microsoft 365Służą one do pakowania przychodzącego webhooka z interfejsem konfiguracyjnym w Teams. Zazwyczaj wysyłają wiadomości w formie kart łącznika i umożliwiają bardziej „produktowe” działanie, takie jak wybór lokalizacji w łączniku pogodowym, planowanie czasu powiadomień itd.

Z punktu widzenia architektury, jeśli Twoją główną potrzebą jest to, Twoje skrypty i narzędzia wysyłają wiadomości do kanału Bez zbędnych ozdobników wizualnych, prosty webhook przychodzący zazwyczaj w zupełności wystarcza. Jeśli szukasz złożonej logiki, zaawansowanej personalizacji i interaktywnych działań, bardziej odpowiedni będzie bot powiadomień lub aplikacja Teams z API powiadomień.

Jak utworzyć przychodzący webhook w aplikacji Teams i używać go z poziomu usługi zewnętrznej

Proces włączania przychodzącego webhooka w kanale Teams jest dość mechaniczny, ale warto. w pełni zrozumieć każdy krok aby następnie zintegrować go ze skryptami lub aplikacjami.

Najpierw w interfejsie Teams wybierasz zespół i kanał standardowy gdzie mają się pojawiać alerty. Może to być istniejący kanał (na przykład „Incydenty”) lub nowy utworzony specjalnie na potrzeby integracji.

Następnie kliknij na trzy kropki obok nazwy kanału i wybierz opcję ZłączaNa liście dostępnych łączników znajdź „Przychodzący webhook” i kliknij „Konfiguruj”. Następnie nadaj mu nazwę identyfikującą jego cel (na przykład „Alerty CertSecure”, „Alerty CI/CD” lub „Monitorowanie platformy Azure”) i opcjonalnie prześlij ikonę, aby ułatwić rozpoznanie źródła wiadomości.

Po potwierdzeniu utworzenia aplikacja Teams wygeneruje Unikalny adres URL webhookaTo adres, który skopiujesz i wkleisz do ustawień swojego zewnętrznego narzędzia lub usługi. Ważne jest, aby był bezpieczny, ponieważ każdy, kto uzyska do niego dostęp, może wysyłać wiadomości do kanału w Twoim imieniu.

Niektóre produkty, takie jak rozwiązania do zarządzania certyfikatami (na przykład CertSecure), mają w swoim własnym portalu administracyjnym specjalną sekcję przeznaczoną do zarządzania certyfikatami. zintegrować zespołyTam zazwyczaj proszą o wklejenie adresu URL webhooka; po jego zapisaniu system wysyła wiadomość testową do kanału zespołu informującą o pomyślnym zakończeniu integracji.

Stamtąd możesz aktywować lub dezaktywować różne zdarzenia powiadomień (wydawanie nowych certyfikatów, unieważnianie, odnawianie, wygasanie lub powiadamianie o zbliżającym się terminie wygaśnięcia), dzięki czemu każda istotna zmiana generuje automatyczną wiadomość w kanale, dzięki czemu zespół jest na bieżąco informowany, bez konieczności ciągłego dostępu do panelu narzędzia.

Typowe problemy z ClickUp, Slackiem i innymi usługami

Nie wszystkie platformy są od razu kompatybilne z webhookami Slacka lub Teams, nawet jeśli wydaje się, że wystarczy wkleić adres URL. Typowy przykład to… ClickUp i Slack gdy chcesz powiadamiać kanał za każdym razem, gdy zmieni się status folderu lub listy.

ClickUp umożliwia konfigurację automatyzacji, w których po zmianie stanu uruchamiana jest akcja wysyłająca żądanie do adresu URL webhooka (na przykład adresu URL Slacka, który generuje przychodzący webhook). Problem polega na tym, że ClickUp wysyła własny ładunek JSON ze schematem, który nie odpowiada temu, czego oczekuje Slack, więc powiadomienie może nie pojawić się na kanale.

W Slacku przychodzący webhook zwykle oczekuje czegoś tak prostego jak { "text": "Mensaje a mostrar" }z opcjonalnymi polami, takimi jak kanał, nazwa użytkownika lub ikona. Jeśli zamiast tego otrzymasz zagnieżdżony plik JSON z polami specyficznymi dla ClickUp, możesz zignorować prośbę lub błędnie je zinterpretować, co w efekcie spowoduje wyświetlenie alertu, który nigdy nie zostanie zauważony.

Najlepszym sposobem na rozwiązanie tego typu niezgodności jest wprowadzenie warstwa pośrednia, która działa jako tłumaczPodobnie jak w SNS i Lambda, zamiast kierować webhook ClickUp bezpośrednio do Slacka, kierujesz go do własnego punktu końcowego (funkcji w chmurze, małego API w zapleczu). Ten punkt końcowy odbiera JSON ClickUp, wybiera odpowiednie informacje (na przykład nazwę zadania, poprzedni i nowy status, osobę przypisaną) i konstruuje minimalny kod JSON wymagany przez Slacka, a następnie przekazuje żądanie do przychodzącego webhooka Slacka.

Ten wzorzec można uogólnić na wiele innych narzędzi, które „wysyłają JSON”, ale nie w formacie wymaganym przez Slacka lub Teams. Dzięki własnej warstwie integracyjnej masz pełną kontrolę nad… formatowanie wiadomości, filtrowanie, bezpieczeństwo i wzbogacanieMożesz wprowadzać zmiany w API bez konieczności modyfikowania konfiguracji wszystkich skryptów.

Wykorzystanie bezpiecznych webhooków do wysyłania alertów ze skryptów do Teams i Slacka wymaga czegoś więcej niż tylko kopiowania i wklejania adresów URL: wymaga zrozumienia różnych typów integracji z Teams, schematów JSON usług takich jak Azure Monitor i Amazon SNS, roli warstw oprogramowania pośredniczącego, takich jak Power Automate czy AWS Lambda, a także środków bezpieczeństwa i DLP związanych z tym wszystkim. Jeśli dobrze zaprojektujesz tę architekturę, Twoje zespoły będą cieszyć się bogatymi, niezawodnymi alertami w czasie rzeczywistym, bez szoku związanego ze zmianami przestarzałych łączników lub niekompatybilnymi formatami, które po cichu pochłaniają Twoje powiadomienia.