Come inviare avvisi a Teams e Slack dagli script utilizzando webhook sicuri

Se lavori con infrastrutture cloud, CI/CD, monitoraggio o gestione degli incidenti, probabilmente vorrai Tutti gli avvisi importanti arrivano direttamente sui tuoi canali. Microsoft Squadre o SlackIl modo più flessibile e semplice per raggiungere questo obiettivo tramite script, automazioni o servizi esterni è utilizzare webhook... a patto che vengano protetti adeguatamente.

Negli ultimi anni il panorama è cambiato: I connettori più vecchi, come quelli di Office 365 in Teams, verranno ritirati.Le policy DLP stanno diventando sempre più rigide e molti servizi comunicano con JSON solo in formati molto specifici (come Amazon SNS, Azure Monitor o ClickUp). Tutto ciò significa che integrare gli avvisi con Teams e Slack non è semplicemente una questione di "incollare un URL" e concludere; richiede un'attenta valutazione della sicurezza, dei formati del payload e dell'architettura.

Cos'è esattamente un webhook e perché è così utile per gli avvisi?

Un webhook non è altro che un URL HTTP o HTTPS che accetta richieste POST da un altro sistema. Ogni volta che viene attivato un evento (un errore di produzione, una distribuzione non riuscita, un cambiamento di stato in una risorsa, ecc.), il tuo copione Il servizio invia un JSON a quell'URL e il messaggio appare nel canale Teams o Slack che hai scelto.

In questo schema, I team e Slack agiscono come ricevitori passiviStanno solo aspettando che qualcuno invii loro una richiesta nel formato corretto. Il vantaggio è che, da parte tua, puoi utilizzare praticamente qualsiasi linguaggio o ambiente. PowerShellColpo PythonAWS Lambda, Azure Functions, pipeline CI, applicazioni on-premise, tutto ciò che desideri.

È importante che sia chiaro Ogni piattaforma si aspetta una struttura JSON specifica.Ad esempio, un webhook di Slack o Microsoft Teams richiede solitamente almeno un campo con il testo del messaggio (normalmente "testo"), mentre altri servizi come Amazon Chime si aspettano chiavi diverse (ad esempio "Contenuto").

Un altro punto chiave è che molti servizi cloud (Azure, AWS, ClickUp, ecc.) Non inviano esattamente il formato previsto da Teams o Slack.ma piuttosto un proprio schema di payload per eventi e avvisi. Ecco perché spesso è necessario un "elemento intermedio" per adattare tali informazioni al formato corretto.

Tipi di integrazioni: webhook, connettori, bot e API

Nel mondo di Microsoft Teams ci sono diversi modi per ricevere notifiche automatiche da script o servizi esternied è importante distinguerli per scegliere l'architettura giusta:

Da un lato ci sono i file webhook in arrivoSi tratta del modo più diretto per inviare messaggi a un canale Teams. Abilitando questa funzionalità in un canale, viene generato un URL HTTPS che accetta JSON e inserisce il contenuto nella conversazione. Non richiedono l'installazione di un'app complessa o risorse Azure aggiuntive; si tratta di una funzionalità nativa del canale.

All'altra estremità hai il API di notifica e bot di notificaQueste sono tra le funzionalità più avanzate di Teams. Stiamo parlando di applicazioni Teams complete in grado di inviare notifiche avanzate a utenti, chat o canali, sfruttare Microsoft Graph, recuperare il contesto utente, visualizzare contenuti nelle dashboard e altro ancora. È la soluzione ideale se cerchi esperienze personalizzate, schede dinamiche e adattive e regole aziendali sofisticate.

Sono coinvolti anche connettori per gruppi di Microsoft 365Consentono di confezionare un webhook con la propria pagina di impostazioni come parte di un'app Teams. In genere utilizzano schede connettore con un set limitato di azioni, perfette per integrazioni di "prodotto" come connettori meteo, incidenti e altri.

Infine, c'è il file API di notifica basata su graficiFunziona come endpoint RESTful per attivare notifiche nel feed attività di Teams. È molto utile quando si desidera che l'applicazione web o il backend invii avvisi urgenti, con notifiche audio e del sistema operativo, su informazioni critiche destinate a utenti o gruppi specifici.

Addio ai connettori di Office 365: perché è ora di passare a Power Automate

Se hai inviato messaggi a Teams per anni utilizzando Webhook del connettore Office 365Probabilmente avrete visto avvisi che questa funzionalità verrà ritirata. Microsoft sta allineando l'ecosistema alla sua strategia "future-safe", che in pratica significa spingere verso soluzioni più moderne e controllate, come Power Automate e le API attuali.

Il modo consigliato per continuare a inviare avvisi dagli script è orchestrare la consegna ai team utilizzando un flusso Power AutomateInvece di chiamare direttamente un webhook di Office 365, gli script attivano un trigger HTTP di Power Automate e questo flusso gestisce la creazione e l'invio del messaggio al canale Teams utilizzando i connettori supportati.

In uno scenario tipico, si crea un flusso cloud con un trigger come "Quando viene ricevuta una richiesta HTTP"Dal tuo script PowerShell, Bash o Python, invii una richiesta POST a quell'endpoint, passando i dati rilevanti (gravità, origine, descrizione dell'incidente, ecc.). Il flusso di lavoro elabora il JSON, lo trasforma in una scheda o in un messaggio adattato per Teams e lo pubblica sul canale da te scelto.

Questo approccio presenta diversi vantaggi: Ti astrae da future modifiche nei connettori.Consente di centralizzare la logica per la formattazione e l'instradamento degli avvisi e semplifica il rispetto dei requisiti di sicurezza e conformità, poiché Power Automate può essere integrato con la governance e la prevenzione della perdita dei dati di Microsoft 365.

Proteggere i webhook: token, tenant e DLP

Una delle grandi domande quando si espone un URL webhook è come Impedisci a chiunque di inviare messaggi al tuo canale Se scopri quell'indirizzo. Sebbene i webhook siano molto comodi, devono essere trattati come credenziali sensibili.

Un modello comunemente utilizzato è costituito da aggiungere un token di autorizzazione come parametro nell'URLAd esempio, un endpoint potrebbe apparire così: https://miservicio/webcallback?tokenid=sometokenid&someparameter=somevalueIl servizio che riceve la chiamata verifica che il token sia valido prima di elaborare la richiesta. In questo modo, anche se qualcuno visualizza l'URL senza il token corretto, non potrà utilizzarlo.

Negli ambienti Azure e Microsoft 365, è comune fare un ulteriore passo avanti e Registra un'applicazione su Microsoft Inserisci ID (ex Azure AD) per proteggere l'endpoint HTTP. Il flusso di Power Automate può essere pubblicato dietro una funzione protetta da API Management o Entra, in modo che solo gli script autenticati appartenenti al tenant possano attivare il webhook.

Inoltre, molte organizzazioni applicano politiche di prevenzione della perdita di dati (DLP) su ambienti come Power Automate o Power AppsQuesti criteri possono bloccare o limitare l'uso di determinati connettori (ad esempio, l'invio di dati da un ambiente "riservato" a connettori considerati "non attendibili", come un webhook di Teams). Se si verificano errori durante il salvataggio o l'esecuzione di un flusso, la causa principale potrebbe risiedere nella prevenzione della perdita dei dati.

In tal caso, è necessario esaminarlo insieme al team IT o di governance. Come viene configurata la segmentazione del connettore? e apportare modifiche per consentire al webhook Teams o Slack di far parte dei connettori consentiti nell'ambiente in cui viene eseguito il flusso o l'applicazione.

Formato di caricamento JSON: da Azure Monitor a Teams e Slack

Servizi come Azure Monitor, registro attività di Azure o sistemi di sicurezza generano eventi di avviso con schemi JSON molto ricchi e dettagliatiQuando questi eventi vengono inviati a un webhook come parte di un gruppo di azioni, il payload ricevuto dall'endpoint include molte informazioni, non solo il testo del messaggio.

Il layout tipico di una notifica di avviso Registro attività di Azure include un campo schemaId e un oggetto data che contiene lo stato dell'avviso, il contesto e le proprietà. All'interno data.context.activityLog Dati come il tipo di canale, il correlationId, il timestamp dell'evento, il livello (critico, errore, avviso, informativo), il operationName, l'identificatore della risorsa interessata e altro ancora.

A seconda del valore di eventSource In quel carico, la struttura specifica varia: ci sono eventi di tipo Amministrativo, Sicurezza , Consigli, ServizioSalute o RisorseSaluteognuno con le sue proprietà specifiche. Ad esempio, un evento di sicurezza potrebbe dettagliare tentativi di forza bruta SSH, IP degli aggressori, utenti utilizzati, numero di tentativi falliti e misure correttive suggerite.

Altri elementi del carico includono campi come autorizzazione (azione e ambito del controllo degli accessi basato sui ruoli), visitatore (email o UPN dell'utente che ha eseguito l'operazione), ID dati evento (identificatore univoco), sottostato (spesso con codici HTTP come 200, 400, 404, 500, ecc.) e un dizionario di properties con coppie chiave-valore che aggiungono più contesto all'evento.

Per rendere tutto questo utile in Teams o Slack, non ha senso copiare l'intero file JSON così com'è. L'approccio più pratico è usare il tuo script o la tua funzione. estrarre i campi rilevanti (risorsa interessata, gravità, descrizione, timestamp critici, correlazione) e creare un messaggio più leggibile, indicando chiaramente cosa è successo, dove e cosa fare dopo.

Da Amazon SNS a Slack, Teams e Chime con Lambda

Amazon Simple Notification Service (SNS) è un altro elemento chiave quando vuoi reagire agli eventi AWS e inviarli ai canali di chatSNS può pubblicare messaggi su endpoint HTTP/HTTPS, ma non sempre nel formato previsto dai webhook di Slack, Microsoft Teams o Amazon Chime.

Ad esempio, quando si configura un argomento SNS per pubblicare su un webhook, il payload JSON della notifica ha le sue chiavi (messaggio, oggetto, timestamp, ecc.). Tuttavia, Slack e Teams si aspettano che il corpo della richiesta includa una chiave "testo". con il messaggio che verrà visualizzato sul canale, mentre Amazon Chime cerca una chiave "Contenuto"SNS non supporta direttamente la trasformazione di tale formato al momento della pubblicazione.

La soluzione consigliata in AWS è quella di utilizzare un Funzione lambda come strato intermedioInvece di sottoscrivere il webhook direttamente all'argomento SNS, si crea un argomento SNS, si configura una funzione Lambda che si sottoscrive a quell'argomento e da Lambda si invia il POST al webhook con il JSON trasformato nella struttura corretta.

Il flusso sarebbe simile a questo: SNS pubblica l'evento nella funzione Lambda; la funzione legge evento[«Record»][0][«Sns»][«Messaggio»]Crea un dizionario con la chiave appropriata ("Contenuto" per Chime, "testo" per Slack o Teams, aggiungendo facoltativamente canale, nome utente o icon_emoji (nel caso di Slack), serializza in JSON ed effettua la richiesta POST utilizzando una libreria HTTP come urllib3.

Nel codice Python, lo scheletro di base è molto semplice: si crea un PoolManagerDefinisci l'URL del webhook, costruisci il messaggio con i campi previsti, lo converti in JSON codificato UTF-8 e invii la richiesta. Quindi, puoi registrare il codice_di_stato e il corpo della risposta per il debug, verificando che il webhook accetti correttamente il messaggio (codice 200) o identificando errori 4xx se sono presenti parametri non validi o l'URL non è corretto.

Una volta che il comportamento Lambda è stato convalidato con un evento di test nella console (utilizzando il modello "Notifica argomento SNS"), il passaggio successivo è aggiungi il tema SNS come trigger della funzione. Pertanto, ogni volta che un servizio pubblica sull'argomento (ad esempio, allarmi CloudWatch, eventi sullo stato dell'istanza, ecc.), l'avviso finirà in Slack, Teams o Chime nel formato ideale.

Webhook in Microsoft Teams: in entrata, in uscita e connettori

All'interno dei Team ci sono vari tipi di connettività che vanno oltre il tipico webhook in entrata e vale la pena conoscerli per progettare al meglio la propria soluzione di avviso.

I webhook in uscita Consentono di "chiamare" un servizio esterno da un canale utilizzando il simbolo @. Si configura il webhook in uscita con l'URL del servizio e, quando un utente lo richiama con un messaggio, Teams invia il testo al proprio endpoint e si aspetta una risposta rapida (in genere entro 10 secondi) con contenuto che può essere testo normale o una scheda. Questo è utile per comandi o query su richiesta, non tanto per gli avvisi automatici.

I webhook in arrivoCome abbiamo detto prima, sono perfetti per ricevere avvisi e notifiche periodiche Da applicazioni esterne. È possibile creare un webhook in un canale (ad esempio, un canale DevOps) e configurare pipeline, script di distribuzione, strumenti di monitoraggio o sistemi di sicurezza per inviare i propri eventi a tale URL tramite HTTP POST.

Poi ci sono i file Connettori per gruppi Microsoft 365Funzionano come un modo per confezionare un webhook in entrata con un'interfaccia di configurazione all'interno di Teams. In genere inviano messaggi sotto forma di schede di connessione e consentono un'esperienza più "simile a un prodotto", come la selezione di una posizione in un connettore meteo, la pianificazione degli orari di notifica e così via.

Da un punto di vista architettonico, se la tua esigenza principale è quella I tuoi script e strumenti inviano messaggi a un canale Senza troppi fronzoli visivi, un semplice webhook in entrata è solitamente più che sufficiente. Se si desidera una logica complessa, una personalizzazione avanzata e azioni interattive, un bot di notifica o un'app Teams con un'API di notifica sono più appropriati.

Come creare un webhook in entrata in Teams e utilizzarlo da un servizio esterno

Il processo per abilitare un webhook in entrata in un canale Teams è piuttosto meccanico, ma ne vale la pena. comprendere appieno ogni passaggio per poi integrarlo con i tuoi script o applicazioni.

Per prima cosa, nell'interfaccia Teams scegli il team e il canale standard dove desideri che vengano visualizzati gli avvisi. Può trattarsi di un canale esistente (ad esempio, "Incidenti") o di uno nuovo creato appositamente per le integrazioni.

Quindi fai clic sui tre punti accanto al nome del canale e seleziona l'opzione per Connettori connettoriNell'elenco dei connettori disponibili, trova "Webhook in arrivo" e fai clic su "Configura". Quindi, assegna un nome che ne identifichi lo scopo (ad esempio, "Avvisi CertSecure", "Avvisi CI/CD" o "Monitoraggio di Azure") e, facoltativamente, carica un'icona per facilitare il riconoscimento dell'origine del messaggio.

Quando confermi la creazione, Teams genera un URL webhook univocoQuesto è l'indirizzo che copierai e incollerai nelle impostazioni del tuo strumento o servizio esterno. È importante mantenerlo sicuro, poiché chiunque vi acceda potrebbe inviare messaggi al canale per tuo conto.

Alcuni prodotti, come le soluzioni di gestione dei certificati (ad esempio, CertSecure), hanno una sezione specifica nel proprio portale di amministrazione per integrare i teamDi solito, ti chiedono di incollare l'URL del webhook; dopo averlo salvato, il sistema invia un messaggio di prova al canale del team per indicare che l'integrazione è stata completata correttamente.

Da lì, puoi attivare o disattivare diversi eventi di notifica (emissione di nuovi certificati, revoche, rinnovi, scadenze o avvisi di pre-scadenza) in modo che ogni modifica rilevante generi un messaggio automatico nel canale, mantenendo il team aggiornato senza dover accedere continuamente al pannello dello strumento.

Problemi comuni con ClickUp, Slack e altri servizi

Non tutte le piattaforme sono immediatamente compatibili con i webhook di Slack o Teams, anche quando sembra che basti incollare un URL. Un esempio tipico è... ClickUp e Slack quando si desidera avvisare il canale ogni volta che cambia lo stato di una cartella o di un elenco.

ClickUp consente di configurare automazioni in cui, in caso di modifica dello stato, viene attivata un'azione che invia una richiesta a un URL webhook (ad esempio, l'URL Slack che genera un webhook in arrivo). Il problema è che ClickUp invia il proprio payload JSON con uno schema che non corrisponde a quello previsto da Slack, quindi la notifica potrebbe non apparire nel canale.

In Slack, il webhook in arrivo di solito si aspetta qualcosa di semplice come { "text": "Mensaje a mostrar" }con alcuni campi opzionali come canale, nome utente o icona. Se invece ricevi un JSON annidato con campi specifici di ClickUp, puoi ignorare la richiesta oppure interpretarlo male, generando un avviso che in realtà non viene mai visualizzato.

Il modo migliore per risolvere questi tipi di incompatibilità è introdurre un strato intermedio che funge da traduttoreProprio come con SNS e Lambda, invece di indirizzare il webhook di ClickUp direttamente a Slack, lo indirizzi al tuo endpoint (una funzione cloud, una piccola API nel tuo backend). Tale endpoint riceve il JSON di ClickUp, seleziona le informazioni rilevanti (ad esempio, nome dell'attività, stato precedente e nuovo, assegnatario) e costruisce il JSON minimo di cui Slack ha bisogno, quindi inoltra la richiesta al webhook in arrivo di Slack.

Questo schema può essere generalizzato a molti altri strumenti che "inviano JSON", ma non nel formato richiesto da Slack o Teams. Avendo un proprio livello di integrazione, si ha il controllo completo su formattazione, filtraggio, sicurezza e arricchimento dei messaggiE puoi gestire le modifiche API senza dover modificare la configurazione di tutti i tuoi script.

Sfruttare webhook sicuri per inviare avvisi dagli script a Teams e Slack non significa solo copiare e incollare URL: richiede la comprensione dei diversi tipi di integrazioni di Teams, degli schemi JSON di servizi come Azure Monitor e Amazon SNS, del ruolo di livelli middleware come Power Automate o AWS Lambda e delle misure di sicurezza e DLP che li circondano. Progettando bene questa architettura, i tuoi team potranno usufruire di avvisi completi, affidabili e in tempo reale, senza lo shock di modifiche obsolete ai connettori o di formati incompatibili che inghiottono silenziosamente le tue notifiche.