Wie man mithilfe sicherer Webhooks Benachrichtigungen aus Skripten an Teams und Slack sendet

Wenn Sie mit Cloud-Infrastruktur, CI/CD, Monitoring oder Incident Management arbeiten, möchten Sie wahrscheinlich alle wichtigen Benachrichtigungen direkt in Ihren Microsoft Teams- oder Slack- Kanälen erhalten . Der flexibelste und einfachste Weg, dies mithilfe von Skripten, Automatisierungen oder externen Diensten zu erreichen, ist die Verwendung von Webhooks – vorausgesetzt, Sie sichern diese ordnungsgemäß ab.

In den letzten Jahren hat sich die Landschaft verändert: Ältere Konnektoren wie die für Office 365 in Teams werden nach und nach ersetzt , DLP-Richtlinien werden immer strenger, und viele Dienste kommunizieren nur noch mit JSON in sehr spezifischen Formaten (z. B. Amazon SNS, Azure Monitor oder ClickUp). All dies bedeutet, dass die Integration von Warnmeldungen in Teams und Slack nicht mehr einfach durch das Einfügen einer URL möglich ist; sie erfordert die Berücksichtigung von Sicherheit, Payload-Formaten und Architektur.

Was genau ist ein Webhook und warum ist er so nützlich für Benachrichtigungen?

Ein Webhook ist im Grunde eine HTTP- oder HTTPS-URL, die POST-Anfragen von einem anderen System entgegennimmt. Sobald ein Ereignis ausgelöst wird (z. B. ein Produktionsfehler, ein fehlgeschlagenes Deployment, eine Statusänderung einer Ressource), sendet Ihr Skript oder Dienst ein JSON-Objekt an diese URL, und die Nachricht erscheint im ausgewählten Teams- oder Slack-Kanal.

In dieser Konfiguration fungieren Teams und Slack als passive Empfänger : Sie warten einfach darauf, dass ihnen jemand eine Anfrage im korrekten Format sendet. Der Vorteil: Sie können praktisch jede beliebige Sprache oder Umgebung nutzen: PowerShell , Bash, Python , AWS Lambda, Azure Functions, CI-Pipelines, lokale Anwendungen – ganz nach Ihren Wünschen.

Es ist wichtig zu verstehen, dass jede Plattform eine spezifische JSON-Struktur erwartet . Beispielsweise benötigt ein Slack- oder Microsoft Teams-Webhook typischerweise mindestens ein Feld, das den Nachrichtentext enthält (üblicherweise „text“ ), während andere Dienste wie Amazon Chime andere Schlüssel erwarten (z. B. „Content“ ).

Ein weiterer wichtiger Punkt ist, dass viele Cloud-Dienste (Azure, AWS, ClickUp usw.) nicht das von Teams oder Slack erwartete Format verwenden , sondern ihr eigenes Format für Ereignisse und Benachrichtigungen. Daher ist häufig eine Zwischenkomponente erforderlich, um die Informationen in das korrekte Format zu bringen.

Integrationsarten: Webhooks, Konnektoren, Bots und APIs

In der Welt von Microsoft Teams gibt es verschiedene Möglichkeiten, automatische Benachrichtigungen von Skripten oder externen Diensten zu erhalten , und es ist wichtig, diese zu unterscheiden, um die richtige Architektur auszuwählen:

Zum einen gibt es eingehende Webhooks , die den direktesten Weg bieten, Nachrichten an einen Teams-Kanal zu senden. Durch Aktivieren dieser Funktion in einem Kanal wird eine HTTPS-URL generiert, die JSON akzeptiert und den Inhalt in die Konversation einfügt. Es ist keine Installation einer komplexen App oder zusätzlicher Azure-Ressourcen erforderlich; es handelt sich um eine native Kanalfunktion.

Am anderen Ende des Spektrums befinden sich die Benachrichtigungs-API und Benachrichtigungs-Bots , die zu den erweiterten Funktionen von Teams gehören. Dabei handelt es sich um vollwertige Teams-Anwendungen, die umfangreiche Benachrichtigungen an Benutzer, Chats oder Kanäle senden, Microsoft Graph nutzen, Benutzerkontexte abrufen, Inhalte in Dashboards anzeigen und vieles mehr können. Dies ist ideal, wenn Sie personalisierte Benutzererlebnisse, dynamische, adaptive Karten und komplexe Geschäftsregeln wünschen.

Ebenfalls enthalten sind Konnektoren für Microsoft 365- Gruppen , mit denen Sie einen Webhook mit eigener Einstellungsseite als Teil einer Teams-App einbinden können. Diese verwenden typischerweise Konnektorkarten mit einer begrenzten Anzahl von Aktionen und eignen sich ideal für Produktintegrationen wie Wetter-, Störungs- und andere Konnektoren.

Schließlich gibt es noch die Graph-basierte Benachrichtigungs-API , die als RESTful-Endpunkt fungiert, um Benachrichtigungen im Teams-Aktivitätsfeed auszulösen. Sie ist besonders leistungsstark, wenn Ihre Webanwendung oder Ihr Backend dringende Warnmeldungen mit Ton und Betriebssystembenachrichtigungen zu wichtigen Informationen an bestimmte Benutzer oder Gruppen senden soll.

Abschied von Office 365-Konnektoren: Warum es Zeit ist, zu Power Automate zu wechseln

Wenn Sie schon seit Jahren Nachrichten über Office 365 Connector-Webhooks an Teams senden , haben Sie wahrscheinlich bereits Hinweise darauf gesehen, dass diese Funktion eingestellt wird. Microsoft richtet das Ökosystem im Sinne seiner zukunftssicheren Strategie aus, was in der Praxis bedeutet, auf modernere und besser kontrollierte Lösungen wie Power Automate und bestehende APIs zu setzen.

Die empfohlene Methode, um weiterhin Benachrichtigungen aus Skripten zu senden, besteht darin, den Versand an Teams mithilfe eines Power Automate-Flows zu orchestrieren . Anstatt einen Office 365-Webhook direkt aufzurufen, lösen Ihre Skripte einen Power Automate-HTTP-Trigger aus. Dieser Flow erstellt und sendet die Nachricht dann mithilfe unterstützter Konnektoren an den Teams-Kanal.

In einem typischen Szenario erstellen Sie einen Cloud-Flow mit einem Trigger wie „Wenn eine HTTP-Anfrage eingeht “. Aus Ihrem PowerShell-, Bash- oder Python-Skript senden Sie eine POST-Anfrage an diesen Endpunkt und übergeben die relevanten Daten (Schweregrad, Quelle, Vorfallbeschreibung usw.). Der Flow verarbeitet das JSON, wandelt es in eine für Teams angepasste Karte oder Nachricht um und veröffentlicht diese im ausgewählten Kanal.

Dieser Ansatz bietet mehrere Vorteile: Er abstrahiert Sie von zukünftigen Änderungen an Konnektoren , ermöglicht Ihnen die Zentralisierung der Logik für die Formatierung und Weiterleitung von Warnmeldungen und erleichtert die Einhaltung von Sicherheits- und Compliance-Anforderungen, da Power Automate in Microsoft 365 DLP und Governance integriert werden kann.

Schutz Ihrer Webhooks: Tokens, Mandanten und DLP

Eine der wichtigsten Fragen beim Veröffentlichen einer Webhook-URL ist, wie man verhindern kann, dass jemand Nachrichten an den Kanal sendet, sobald er diese Adresse kennt. Obwohl Webhooks sehr praktisch sind, müssen sie wie sensible Zugangsdaten behandelt werden.

Ein häufig verwendetes Muster besteht aus Fügen Sie ein Autorisierungstoken als Parameter in die URL ein.Ein Endpunkt könnte beispielsweise so aussehen: https://miservicio/webcallback?tokenid=sometokenid&someparameter=somevalueDer Dienst, der den Aufruf empfängt, überprüft die Gültigkeit des Tokens, bevor er die Anfrage verarbeitet. Dadurch kann die URL auch dann nicht verwendet werden, wenn jemand sie ohne das korrekte Token sieht.

In Azure- und Microsoft 365-Umgebungen ist es üblich, zusätzlich eine Anwendung mit einer Microsoft Entra-ID (ehemals Azure AD) zu registrieren, um den HTTP-Endpunkt zu schützen. Der Power Automate-Flow kann hinter einer API Management- oder Entra-geschützten Funktion veröffentlicht werden, sodass nur authentifizierte Skripte Ihres Mandanten den Webhook auslösen können.

Darüber hinaus implementieren viele Organisationen Richtlinien zur Verhinderung von Datenverlust (DLP) in Umgebungen wie Power Automate oder Power Apps . Diese Richtlinien können die Verwendung bestimmter Konnektoren blockieren oder einschränken (z. B. das Senden von Daten aus einer vertraulichen Umgebung an als nicht vertrauenswürdig eingestufte Konnektoren wie einen Teams-Webhook). Wenn beim Speichern oder Ausführen eines Flows Fehler auftreten, kann die Ursache in den DLP-Richtlinien liegen.

In diesem Fall müssen Sie mit Ihrem IT- oder Governance-Team überprüfen, wie die Konnektorsegmentierung konfiguriert ist, und Anpassungen vornehmen, damit Ihr Teams- oder Slack-Webhook zu den zulässigen Konnektoren in der Umgebung gehört, in der Ihr Flow oder Ihre Anwendung ausgeführt wird.

JSON-Upload-Format: von Azure Monitor zu Teams und Slack

Dienste wie Azure Monitor, Azure Activity Log und Sicherheitssysteme generieren Warnereignisse mit umfangreichen und detaillierten JSON-Schemas . Wenn diese Ereignisse als Teil einer Aktionsgruppe an einen Webhook gesendet werden, enthält die Nutzlast, die Ihr Endpunkt empfängt, neben dem eigentlichen Nachrichtentext eine Vielzahl weiterer Informationen.

Das typische Layout einer Warnmeldung Azure-Aktivitätsprotokoll beinhaltet ein Feld schemaId und ein Objekt data welche den Alarmstatus, den Kontext und die Eigenschaften enthält. Innerhalb data.context.activityLog Daten wie beispielsweise der Kanaltyp, correlationId, der Zeitstempel des Ereignisses, die Stufe (Kritisch, Fehler, Warnung, Information), die operationName, die betroffene Ressourcenkennung und mehr.

Abhängig vom Wert von eventSource Bei dieser Last variiert die spezifische Struktur: Es gibt Ereignisse vom Typ Verwaltung, Sicherheit, Software Empfehlungen, ServiceHealth o ResourceHealthjeweils mit seinen eigenen spezifischen Eigenschaften. Beispielsweise könnte ein Sicherheitsereignis folgende Details enthalten: rohe Gewalt SSH, IP-Adressen der Angreifer, verwendete Benutzer, Anzahl fehlgeschlagener Versuche und empfohlene Abhilfemaßnahmen.

Weitere Elemente der Last umfassen Felder wie beispielsweise Genehmigung (Aktion und Umfang der rollenbasierten Zugriffskontrolle), Anrufer (E-Mail-Adresse oder UPN des Benutzers, der die Operation durchgeführt hat), eventDataId (eindeutiger Bezeichner), Unterstatus (häufig mit HTTP-Codes wie 200, 400, 404, 500 usw.) und einem Wörterbuch von properties mit Schlüssel-Wert-Paaren, die dem Ereignis mehr Kontext hinzufügen.

Um diese Informationen in Teams oder Slack sinnvoll zu nutzen, reicht es nicht aus, die gesamte JSON-Datei einfach zu kopieren. Praktischer ist es, wenn Ihr Skript oder Ihre Funktion die relevanten Felder (betroffene Ressource, Schweregrad, Beschreibung, kritische Zeitstempel, Korrelation) extrahiert und eine verständlichere Nachricht erstellt, die klar beschreibt, was passiert ist, wo es passiert ist und was als Nächstes zu tun ist.

Von Amazon SNS bis hin zu Slack, Teams und Chime mit Lambda

Amazon Simple Notification Service (SNS) ist eine weitere wichtige Komponente, wenn Sie auf AWS-Ereignisse reagieren und diese an Chatkanäle senden möchten . SNS kann Nachrichten an HTTP/HTTPS-Endpunkte senden, jedoch nicht immer im Format, das Slack, Microsoft Teams oder Amazon Chime-Webhooks erwarten.

Wenn Sie beispielsweise ein SNS-Thema für die Veröffentlichung an einen Webhook konfigurieren, enthält die JSON-Nutzlast der Benachrichtigung eigene Schlüssel (Nachricht, Betreff, Zeitstempel usw.). Slack und Teams erwarten jedoch, dass der Anfragetext einen Schlüssel „text“ mit der im Kanal anzuzeigenden Nachricht enthält, während Amazon Chime einen Schlüssel „Content“ erwartet . SNS unterstützt die direkte Transformation dieses Formats beim Veröffentlichen nicht.

Die empfohlene Lösung auf AWS besteht darin, eine Lambda-Funktion als Zwischenschicht zu verwenden . Anstatt den Webhook direkt beim SNS-Thema zu abonnieren, erstellen Sie ein SNS-Thema, konfigurieren eine Lambda-Funktion, die dieses Thema abonniert, und senden von der Lambda-Funktion aus die POST-Anfrage mit dem in die korrekte Struktur transformierten JSON an den Webhook.

Der Ablauf sähe in etwa so aus: SNS veröffentlicht das Ereignis in der Lambda-Funktion; die Funktion liest event["Records"][0]["Sns"]["Message"] , erstellt ein Wörterbuch mit dem entsprechenden Schlüssel (Content für Chime, text für Slack oder Teams, optional mit Kanal , Benutzername oder icon_emoji im Fall von Slack), serialisiert es in JSON und sendet die POST-Anfrage mithilfe einer HTTP-Bibliothek wie urllib3.

In Python-Code ist das Grundgerüst sehr einfach: Sie erstellen einen PoolManager , definieren die Webhook-URL, erstellen die Nachricht mit den erwarteten Feldern, konvertieren sie in UTF-8-kodiertes JSON und senden die Anfrage. Anschließend können Sie den Statuscode und den Antworttext zur Fehlersuche protokollieren, um zu überprüfen, ob der Webhook die Nachricht korrekt empfängt (Code 200) oder 4xx-Fehler zu identifizieren, die auf ungültige Parameter oder eine fehlerhafte URL hinweisen.

Nachdem Sie das Verhalten von Lambda mit einem Testereignis in der Konsole (unter Verwendung der Vorlage „SNS-Themenbenachrichtigung“) validiert haben, fügen Sie im nächsten Schritt das SNS-Thema als Auslöser der Funktion hinzu. Dadurch wird immer dann eine Benachrichtigung in Slack, Teams oder Chime im optimalen Format angezeigt, wenn ein Dienst Informationen an das Thema sendet (z. B. CloudWatch-Alarme, Instanzstatusereignisse usw.).

Webhooks in Microsoft Teams: eingehende, ausgehende und Konnektoren

Innerhalb von Teams gibt es verschiedene Arten der Konnektivität , die über den typischen eingehenden Webhook hinausgehen, und es lohnt sich, diese zu kennen, um Ihre Benachrichtigungslösung besser zu gestalten.

Ausgehende Webhooks ermöglichen es Ihnen, einen externen Dienst aus einem Kanal heraus mithilfe eines @-Symbols aufzurufen. Sie konfigurieren den ausgehenden Webhook mit der URL Ihres Dienstes. Wenn ein Benutzer ihn mit einer Nachricht aufruft, sendet Teams den Text an Ihren Endpunkt und erwartet eine schnelle Antwort (in der Regel innerhalb von 10 Sekunden). Der Inhalt kann Klartext oder eine Karte sein. Dies ist nützlich für bedarfsgesteuerte Befehle oder Abfragen, jedoch weniger für automatisierte Benachrichtigungen.

Eingehende Webhooks eignen sich , wie bereits erwähnt, ideal zum Empfangen regelmäßiger Warnungen und Benachrichtigungen von externen Anwendungen. Sie erstellen einen Webhook in einem Kanal (z. B. einem DevOps-Kanal) und konfigurieren Ihre Pipelines, Bereitstellungsskripte, Überwachungstools oder Sicherheitssysteme so, dass sie ihre Ereignisse per HTTP POST an diese URL senden.

Dann gibt es noch die Konnektoren für Microsoft 365-Gruppen , die dazu dienen, eingehende Webhooks mit einer Konfigurationsoberfläche in Teams zu verknüpfen. Sie senden typischerweise Nachrichten in Form von Konnektorkarten und ermöglichen eine benutzerfreundlichere Oberfläche, beispielsweise die Auswahl eines Standorts in einem Wetterkonnektor, die Planung von Benachrichtigungszeiten usw.

Aus architektonischer Sicht ist ein einfacher eingehender Webhook in der Regel völlig ausreichend, wenn Ihre Skripte und Tools primär Nachrichten an einen Kanal senden sollen, ohne dabei aufwendige visuelle Elemente zu benötigen. Benötigen Sie hingegen komplexe Logik, erweiterte Anpassungsmöglichkeiten und interaktive Aktionen, eignen sich ein Benachrichtigungs-Bot oder eine Teams-App mit Benachrichtigungs-API besser.

Wie man einen eingehenden Webhook in Teams erstellt und ihn von einem externen Dienst aus verwendet

Der Prozess zum Aktivieren eines eingehenden Webhooks in einem Teams-Kanal ist recht mechanisch, aber es lohnt sich, jeden Schritt genau zu verstehen , um ihn später in Ihre Skripte oder Anwendungen integrieren zu können.

Zuerst wählen Sie in der Teams-Oberfläche das Team und den Standardkanal aus , in dem die Benachrichtigungen angezeigt werden sollen. Dies kann ein bestehender Kanal sein (z. B. „Probleme“) oder ein neuer, der speziell für Integrationen erstellt wurde.

Klicken Sie anschließend auf die drei Punkte neben dem Kanalnamen und wählen Sie „Connectors“ . Suchen Sie in der Liste der verfügbaren Connectors nach „Eingehender Webhook“ und klicken Sie auf „Konfigurieren“. Vergeben Sie dann einen aussagekräftigen Namen (z. B. „CertSecure-Warnungen“, „CI/CD-Warnungen“ oder „Azure-Überwachung“) und laden Sie optional ein Symbol hoch, um die Nachrichtenquelle leichter erkennbar zu machen.

Sobald Sie die Erstellung bestätigen, generiert Teams eine eindeutige Webhook-URL . Diese Adresse müssen Sie in die Einstellungen Ihres externen Tools oder Dienstes kopieren und einfügen. Es ist wichtig, diese URL sicher aufzubewahren, da jeder, der Zugriff darauf hat, in Ihrem Namen Nachrichten an den Kanal senden könnte.

Einige Produkte, wie beispielsweise Zertifikatsverwaltungslösungen (z. B. CertSecure), bieten in ihrem Administrationsportal einen speziellen Bereich zur Integration von Teams . Dort werden Sie üblicherweise aufgefordert, die Webhook-URL einzufügen. Nach dem Speichern sendet das System eine Testnachricht an den Teamkanal, die die erfolgreiche Integration bestätigt.

Von dort aus können Sie verschiedene Benachrichtigungsereignisse (Ausstellung neuer Zertifikate, Widerrufe, Verlängerungen, Ablauf oder Vorab-Ablauf-Benachrichtigungen) aktivieren oder deaktivieren, sodass jede relevante Änderung automatisch eine Nachricht im Kanal generiert und das Team auf dem Laufenden hält, ohne dass es ständig auf das Dashboard des Tools zugreifen muss.

Häufige Probleme mit ClickUp, Slack und anderen Diensten

Nicht alle Plattformen sind sofort mit Slack- oder Teams-Webhooks kompatibel, selbst wenn es so aussieht, als müsse man nur eine URL einfügen. Ein typisches Beispiel ist ClickUp und Slack, wenn man den Kanal jedes Mal benachrichtigen möchte, wenn sich der Status eines Ordners oder einer Liste ändert.

ClickUp ermöglicht die Konfiguration von Automatisierungen, die bei einer Statusänderung eine Aktion auslösen, welche eine Anfrage an eine Webhook-URL sendet (z. B. die Slack-URL, die einen eingehenden Webhook generiert). Das Problem besteht darin, dass ClickUp eine eigene JSON-Nutzlast mit einem Schema sendet , das nicht dem von Slack erwarteten Schema entspricht. Daher wird die Benachrichtigung möglicherweise nicht im Kanal angezeigt.

In Slack erwartet der eingehende Webhook üblicherweise etwas so Einfaches wie { "text": "Mensaje a mostrar" }mit einigen optionalen Feldern wie Kanal, Benutzername oder Symbol. Falls Sie stattdessen ein verschachteltes JSON mit ClickUp-spezifischen Feldern erhalten, Sie können die Anfrage ignorieren. oder ihn falsch interpretieren, was zu einer Warnung führt, die tatsächlich nie angezeigt wird.

Die beste Lösung für solche Inkompatibilitäten ist die Einführung einer Zwischenschicht, die als Übersetzer fungiert , ähnlich wie bei Workarounds für SNS und Lambda. Anstatt den ClickUp-Webhook direkt an Slack weiterzuleiten, verwenden Sie einen eigenen Endpunkt (z. B. eine Cloud-Funktion oder eine kleine API in Ihrem Backend). Dieser Endpunkt empfängt das ClickUp-JSON, extrahiert die relevanten Informationen (z. B. Aufgabenname, vorheriger und neuer Status, Bearbeiter), erstellt das minimale JSON, das Slack benötigt, und leitet die Anfrage an den eingehenden Webhook von Slack weiter.

Dieses Muster lässt sich auf viele andere Tools übertragen, die JSON senden, jedoch nicht im von Slack oder Teams benötigten Format. Mit einer eigenen Integrationsschicht haben Sie die volle Kontrolle über Nachrichtenformatierung, Filterung, Sicherheit und Anreicherung und können API-Änderungen umsetzen, ohne die Konfiguration all Ihrer Skripte anpassen zu müssen.

Die Nutzung sicherer Webhooks zum Senden von Benachrichtigungen aus Skripten an Teams und Slack erfordert mehr als nur das Kopieren und Einfügen von URLs: Sie setzt ein Verständnis der verschiedenen Arten von Teams-Integrationen, der JSON-Schemas von Diensten wie Azure Monitor und Amazon SNS, der Rolle von Middleware-Schichten wie Power Automate oder AWS Lambda sowie der damit verbundenen Sicherheits- und DLP-Maßnahmen voraus. Bei einer gut konzipierten Architektur profitieren Ihre Teams von umfassenden, zuverlässigen Echtzeit-Benachrichtigungen, ohne dass veraltete Konnektoren oder inkompatible Formate Ihre Benachrichtigungen unbemerkt unterdrücken.