Sådan sender du advarsler til Teams og Slack fra scripts ved hjælp af sikre webhooks

Hvis du arbejder med cloud-infrastruktur, CI/CD, overvågning eller hændelsesstyring, vil du sandsynligvis gerne Alle vigtige advarsler lander direkte i dine kanaler. Microsoft Teams eller SlackDen mest fleksible og enkle måde at opnå dette på fra scripts, automatiseringer eller eksterne tjenester er at bruge webhooks ... så længe du beskytter dem godt.

I de senere år har situationen ændret sig: Ældre forbindelser som dem fra Office 365 i Teams udfases.DLP-politikker bliver stadig strengere, og mange tjenester kommunikerer kun med JSON i meget specifikke formater (såsom Amazon SNS, Azure Monitor eller ClickUp). Alt dette betyder, at integration af advarsler med Teams og Slack ikke blot er et spørgsmål om at "indsætte en URL" og afslutte det; det kræver omhyggelig overvejelse af sikkerhed, payloadformater og arkitektur.

Hvad er en webhook præcist, og hvorfor er den så nyttig til alarmer?

En webhook er intet andet end en HTTP- eller HTTPS-URL, der accepterer POST-anmodninger fra et andet system. Hver gang en hændelse udløses (en produktionsfejl, en mislykket implementering, en ændring af tilstanden i en ressource osv.), vil din script Tjenesten sender en JSON til den URL, og beskeden vises i den Teams- eller Slack-kanal, du har valgt.

I denne ordning, Teams og Slack fungerer som passive modtagereDe venter bare på, at nogen sender dem en anmodning i det korrekte format. Fordelen er, at du fra din side kan bruge stort set ethvert sprog eller miljø. PowerShellBash PythonAWS Lambda, Azure Functions, CI-pipelines, on-premise applikationer, hvad end du ønsker.

Det er vigtigt at være klar over det Hver platform forventer en specifik JSON-struktur.For eksempel kræver en Slack- eller Microsoft Teams-webhook normalt mindst ét ​​felt med beskedteksten (normalt "tekst"), mens andre tjenester som Amazon Chime forventer forskellige nøgler (f.eks. "Indhold").

Et andet vigtigt punkt er, at mange cloud-tjenester (Azure, AWS, ClickUp osv.) De sender ikke præcis det format, som Teams eller Slack forventer.men snarere sin egen nyttelastordning for hændelser og advarsler. Derfor har du ofte brug for et "mellemled" til at tilpasse disse oplysninger til det korrekte format.

Typer af integrationer: webhooks, connectors, bots og API'er

I Microsoft Teams' verden er der flere måder at modtag automatiske notifikationer fra scripts eller eksterne tjenesterog det er vigtigt at skelne mellem dem for at vælge den rigtige arkitektur:

På den ene side er indgående webhooksDisse er den mest direkte måde at sende beskeder til en Teams-kanal. Aktivering af denne funktion i en kanal genererer en HTTPS-URL, der accepterer JSON og indsætter indholdet i samtalen. De kræver ikke installation af en kompleks app eller yderligere Azure-ressourcer; det er en native kanalfunktion.

I den anden ende har du Notifikations-API og notifikationsbotsDisse er blandt de mest avancerede funktioner i Teams. Vi taler om komplette Teams-applikationer, der kan sende omfattende notifikationer til brugere, chats eller kanaler, udnytte Microsoft Graph, hente brugerkontekst, vise indhold i dashboards og meget mere. Det er ideelt, hvis du leder efter personlige oplevelser, dynamiske, adaptive kort og sofistikerede forretningsregler.

Også involveret er stik til grupper af Microsoft 365Disse giver dig mulighed for at pakke en webhook med sin egen indstillingsside som en del af en Teams-app. De bruger typisk connectorkort med et begrænset sæt handlinger, perfekt til "produkt"-integrationer såsom vejr, hændelse og andre connectorer.

Endelig er der Grafbaseret notifikations-APIDet fungerer som et RESTful-slutpunkt til at udløse notifikationer i Teams-aktivitetsfeedet. Det er meget effektivt, når du ønsker, at din webapplikation eller backend skal sende hastebeskeder med lyd- og operativsystemnotifikationer om kritiske oplysninger målrettet mod bestemte brugere eller grupper.

Farvel til Office 365-connectorer: Derfor er det tid til at skifte til Power Automate

Hvis du har sendt beskeder til Teams i årevis ved hjælp af Webhooks til Office 365-forbindelserDu har sikkert set meddelelser om, at denne funktionalitet bliver udfaset. Microsoft tilpasser økosystemet til sin "fremtidssikre" strategi, hvilket i praksis betyder at skubbe hen imod mere moderne og kontrollerede løsninger, såsom Power Automate og de nuværende API'er.

Den anbefalede måde at fortsætte med at sende advarsler fra scripts er Orkestrer leveringen til Teams ved hjælp af et Power Automate-flowI stedet for direkte at kalde en Office 365-webhook, udløser dine scripts en Power Automate HTTP-trigger, og dette flow håndterer opbygning og afsendelse af beskeden til Teams-kanalen ved hjælp af understøttede forbindelser.

I et typisk scenarie opretter du en cloud flow med en trigger som "Når en HTTP-anmodning modtages"Fra dit PowerShell-, Bash- eller Python-script sender du en POST-anmodning til det pågældende slutpunkt og sender de relevante data (alvorlighedsgrad, kilde, hændelsesbeskrivelse osv.). Arbejdsgangen behandler JSON-filen, omdanner den til et kort eller en besked, der er tilpasset Teams, og publicerer den på den kanal, du ønsker.

Denne tilgang har flere fordele: Det abstraherer dig fra fremtidige ændringer i stik.Det giver dig mulighed for at centralisere logikken til formatering og routing af advarsler og gør det nemmere at opfylde sikkerheds- og overholdelseskrav, da Power Automate kan integreres med Microsoft 365 DLP og -styring.

Beskyttelse af dine webhooks: tokens, lejere og DLP

Et af de store spørgsmål, når man eksponerer en webhook-URL, er hvordan Forhindr andre i at sende beskeder til din kanal Hvis du opdager den adresse. Selvom webhooks er meget praktiske, skal de behandles som følsomme legitimationsoplysninger.

Et almindeligt anvendt mønster består af Tilføj et autorisationstoken som en parameter i URL'enFor eksempel kan et slutpunkt se sådan ud: https://miservicio/webcallback?tokenid=sometokenid&someparameter=somevalueDen tjeneste, der modtager kaldet, verificerer, at tokenet er gyldigt, før anmodningen behandles. På denne måde kan nogen ikke bruge URL'en, selvom de ser den korrekte token.

I Azure- og Microsoft 365-miljøer er det almindeligt at gå et skridt videre og Registrer en applikation på Microsoft Enter ID (tidligere Azure AD) for at beskytte HTTP-slutpunktet. Power Automate-flowet kan udgives bag en API Management- eller Entra-beskyttet funktion, så kun godkendte scripts, der tilhører din lejer, kan udløse webhook'en.

Derudover ansøger mange organisationer Politikker til forebyggelse af datatab (DLP) i miljøer som Power Automate eller Power AppsDisse politikker kan blokere eller begrænse brugen af ​​bestemte forbindelser (f.eks. afsendelse af data fra et "fortroligt" miljø til forbindelser, der betragtes som "ikke-tillid", såsom en Teams-webhook). Hvis du støder på fejl, når du gemmer eller kører et flow, kan den grundlæggende årsag ligge i DLP.

I så fald er det nødvendigt at gennemgå det sammen med IT- eller styringsteamet. Hvordan er segmenteringen af ​​forbindelsesstikket konfigureret? og foretag justeringer for at tillade din Teams- eller Slack-webhook at være en del af de tilladte forbindelser i det miljø, hvor dit flow eller din applikation kører.

JSON-uploadformat: fra Azure Monitor til Teams og Slack

Tjenester som Azure Monitor, Azure-aktivitetslog eller sikkerhedssystemer genererer alarmhændelser med meget omfattende og detaljerede JSON-skemaerNår disse hændelser sendes til en webhook som en del af en gruppe af handlinger, indeholder den nyttelast, som dit endpoint modtager, en masse oplysninger, ikke kun beskedteksten.

Det typiske layout af en alarmmeddelelse Azure-aktivitetslog inkluderer et felt schemaId og en genstand data som indeholder alarmstatus, kontekst og egenskaber. Indenfor data.context.activityLog Data såsom kanaltype, correlationId, hændelsestidsstemplet, niveauet (Kritisk, Fejl, Advarsel, Information), den operationName, det berørte ressource-id og mere.

Afhængigt af værdien af eventSource I den belastning varierer den specifikke struktur: der er hændelser af typen Administrative, Sikkerhed, Anbefaling, ServiceSundhed o Ressourcesundhedhver med sine egne specifikke egenskaber. For eksempel kan en sikkerhedshændelse detaljere brute force-forsøg SSH, angribernes IP-adresse, anvendte brugere, antal mislykkede forsøg og foreslåede afhjælpningstrin.

Andre elementer i lasten omfatter felter som f.eks. tilladelse (handling og omfang af rollebaseret adgangskontrol) opkalds (e-mail eller UPN for den bruger, der udførte handlingen), hændelsesdata-id (entydig identifikator), understatus (ofte med HTTP-koder som 200, 400, 404, 500 osv.) og en ordbog med properties med nøgle-værdi-par, der tilføjer mere kontekst til begivenheden.

For at gøre alt dette nyttigt i Teams eller Slack, giver det ikke mening at kopiere hele JSON-filen, som den er. Den praktiske fremgangsmåde er at bruge dit script eller din funktion. udtræk de relevante felter (berørt ressource, alvorlighedsgrad, beskrivelse, kritiske tidsstempler, korrelation) og opbyg en mere læselig besked, der tydeligt angiver, hvad der skete, hvor, og hvad der skal gøres næste gang.

Fra Amazon SNS til Slack, Teams og Chime med Lambda

Amazon Simple Notification Service (SNS) er en anden vigtig del, når du vil reagere på AWS-begivenheder og sende dem til chatkanalerSNS kan udgive beskeder til HTTP/HTTPS-slutpunkter, men ikke altid i det format, som Slack-, Microsoft Teams- eller Amazon Chime-webhooks forventer.

Når du for eksempel konfigurerer et SNS-emne til at blive sendt til en webhook, har notifikationens JSON-nyttelast sine egne nøgler (Besked, Emne, Tidsstempel osv.). Men... Slack og Teams forventer, at anmodningsteksten indeholder en "tekst"-nøgle. med den besked, der vises på kanalen, mens Amazon Chime søger efter en nøgle "Indhold"SNS understøtter ikke direkte transformation af dette format på udgivelsestidspunktet.

Den anbefalede løsning i AWS er ​​at bruge en Lambda-funktion som et mellemliggende lagI stedet for at abonnere webhooken direkte på SNS-emnet, opretter du et SNS-emne, konfigurerer en Lambda-funktion, der abonnerer på det emne, og fra Lambda sender du POST'en til webhooken med JSON'en transformeret til den korrekte struktur.

Flowet ville se nogenlunde sådan ud: SNS udgiver hændelsen til Lambda-funktionen; funktionen læser begivenhed[«Optegnelser»][0][«Sns»][«Besked»]Byg en ordbog med den relevante nøgle ("Content" for Chime, "text" for Slack eller Teams, eventuelt med tilføjelse af kanal, brugernavn o icon_emoji (i tilfælde af Slack), serialiserer til JSON og foretager POST-anmodningen ved hjælp af et HTTP-bibliotek som f.eks. urllib3.

I Python-kode er det grundlæggende skelet meget ligetil: du opretter en PoolManagerDu definerer webhook-URL'en, konstruerer beskeden med de forventede felter, konverterer den til UTF-8-kodet JSON og sender anmodningen. Derefter kan du logge statuskode og svarteksten til fejlfinding, kontrol af at webhooken korrekt accepterer beskeden (kode 200) eller identifikation af 4xx-fejl, hvis der er ugyldige parametre, eller URL'en er forkert.

Når Lambda-adfærden er blevet valideret med en testhændelse i konsollen (ved hjælp af skabelonen "SNS Topic Notification"), er næste trin Tilføj SNS-temaet som en trigger af funktionen. Således vil alarmen ende i Slack, Teams eller Chime i det ideelle format, hver gang en tjeneste publicerer til emnet (f.eks. CloudWatch-alarmer, statushændelser for instanser osv.).

Webhooks i Microsoft Teams: indgående, udgående og connectorer

Inden for Teams er der forskellige typer tilslutningsmuligheder der går ud over den typiske indgående webhook, og det er værd at kende til dem for bedre at designe din alarmløsning.

masse udgående webhooks De giver dig mulighed for at "kalde" en ekstern tjeneste fra en kanal ved hjælp af et @-symbol. Du konfigurerer den udgående webhook med din tjenestes URL, og når en bruger kalder den med en besked, sender Teams teksten til dit slutpunkt og forventer et hurtigt svar (normalt inden for 10 sekunder) med indhold, der kan være almindelig tekst eller et kort. Dette er nyttigt for kommandoer eller forespørgsler on-demand, ikke så meget for automatiske alarmer.

masse indgående webhooksSom vi nævnte før, er de perfekte til modtage periodiske advarsler og meddelelser Fra eksterne applikationer. Du opretter en webhook i en kanal (f.eks. en DevOps-kanal) og konfigurerer dine pipelines, implementeringsscripts, overvågningsværktøjer eller sikkerhedssystemer til at sende deres hændelser til den pågældende URL ved hjælp af HTTP POST.

Så er der Connectorer til Microsoft 365 GrupperDisse fungerer som en måde at pakke en indgående webhook med en konfigurationsgrænseflade i Teams. De sender typisk beskeder i form af connectorkort og muliggør en mere "produktlignende" oplevelse, såsom at vælge en placering i en vejrconnector, planlægge notifikationstider osv.

Fra et arkitektonisk synspunkt, hvis dit primære behov er, at Dine scripts og værktøjer sender beskeder til en kanal Uden for mange visuelle detaljer er en simpel indgående webhook normalt mere end nok. Hvis du leder efter kompleks logik, avanceret tilpasning og interaktive handlinger, er en notifikationsbot eller en Teams-app med en notifikations-API mere passende.

Sådan opretter du en indgående webhook i Teams og bruger den fra en ekstern tjeneste

Processen til at aktivere en indgående webhook i en Teams-kanal er ret mekanisk, men det er umagen værd. fuldt ud forstå hvert trin for derefter at integrere det med dine scripts eller applikationer.

Først vælger du teamet og standardkanal hvor du vil have advarslerne vist. Dette kan være en eksisterende kanal (f.eks. "Hændelser") eller en ny, der er oprettet udelukkende til integrationer.

Derefter klikker du på de tre prikker ud for kanalnavnet og vælger muligheden for at stikPå listen over tilgængelige forbindelser skal du finde "Indgående webhook" og klikke på "Konfigurer". Tildel derefter et navn, der identificerer dens formål (f.eks. "CertSecure Alerts", "CI/CD Alerts" eller "Azure Monitoring"), og upload eventuelt et ikon for at gøre det nemmere at genkende meddelelseskilden.

Når du bekræfter oprettelsen, genererer Teams en Unik webhook-URLDet er den adresse, du kopierer og indsætter i indstillingerne for dit eksterne værktøj eller din eksterne tjeneste. Det er vigtigt at holde den sikker, da alle, der får adgang til den, kan sende beskeder til kanalen på dine vegne.

Nogle produkter, såsom certifikatadministrationsløsninger (f.eks. CertSecure), har en specifik sektion i deres egen administrationsportal til integrere TeamsDer beder de dig normalt om at indsætte webhook-URL'en. Efter at have gemt den, sender systemet en testbesked til teamkanalen, der angiver, at integrationen er gennemført.

Derfra kan du aktivere eller deaktivere forskellige notifikationshændelser (udstedelse af nye certifikater, tilbagekaldelser, fornyelser, udløb eller advarsler før udløb), så hver relevant ændring genererer en automatisk besked i kanalen, hvilket holder teamet opdateret uden løbende behov for at få adgang til værktøjets panel.

Almindelige problemer med ClickUp, Slack og andre tjenester

Ikke alle platforme er kompatible med Slack- eller Teams-webhooks med det samme, selvom det ser ud til, at alt, hvad du skal gøre, er at indsætte en URL. Et typisk eksempel er... ClickUp og Slack når du vil give kanalen besked, hver gang status for en mappe eller liste ændres.

ClickUp giver dig mulighed for at konfigurere automatiseringer, hvor en handling udløses ved en tilstandsændring, der sender en anmodning til en webhook-URL (f.eks. den Slack-URL, der genererer en indgående webhook). Problemet er, at ClickUp sender sin egen JSON-nyttelast med en ordning, der ikke matcher, hvad Slack forventer, så notifikationen vises muligvis ikke i kanalen.

I Slack forventer den indkommende webhook normalt noget så simpelt som { "text": "Mensaje a mostrar" }med nogle valgfrie felter såsom kanal, brugernavn eller ikon. Hvis du i stedet modtager en indlejret JSON med ClickUp-specifikke felter, du kan ignorere anmodningen eller misfortolke den, hvilket resulterer i en alarm, der aldrig rent faktisk ses.

Den bedste måde at løse disse typer uforeneligheder på er at introducere en mellemlag, der fungerer som oversætterLigesom med SNS og Lambda, i stedet for at pege ClickUp-webhooken direkte til Slack, dirigerer du den til dit eget endpoint (en cloud-funktion, en lille API i din backend). Dette endpoint modtager ClickUp JSON'en, vælger de relevante oplysninger (f.eks. opgavenavn, tidligere og ny status, tildelt person) og konstruerer den minimale JSON, som Slack har brug for, og videresender derefter anmodningen til Slacks indgående webhook.

Dette mønster kan generaliseres til mange andre værktøjer, der "sender JSON", men ikke i det format, der kræves af Slack eller Teams. Ved at have dit eget integrationslag har du fuld kontrol over meddelelsesformatering, filtrering, sikkerhed og berigelseOg du kan håndtere API-ændringer uden at skulle røre ved konfigurationen af ​​alle dine scripts.

At udnytte sikre webhooks til at sende advarsler fra scripts til Teams og Slack involverer mere end blot at kopiere og indsætte URL'er: det kræver forståelse af de forskellige typer Teams-integrationer, JSON-skemaerne for tjenester som Azure Monitor og Amazon SNS, rollen af ​​middleware-lag som Power Automate eller AWS Lambda, og sikkerheds- og DLP-foranstaltningerne omkring alt dette. Hvis du designer denne arkitektur godt, vil dine teams nyde godt af omfattende, pålidelige advarsler i realtid uden chokket over forældede connector-ændringer eller inkompatible formater, der lydløst opsluger dine notifikationer.