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, werden Sie wahrscheinlich Folgendes benötigen: Alle wichtigen Benachrichtigungen landen direkt in Ihren Kanälen. Microsoft Teams oder SlackDie flexibelste und einfachste Möglichkeit, dies mit Skripten, Automatisierungen oder externen Diensten zu erreichen, besteht in der Verwendung von Webhooks… vorausgesetzt, man schützt sie gut.

In den letzten Jahren hat sich die Lage verändert: Ältere Konnektoren, wie beispielsweise die von Office 365 in Teams, werden nicht mehr unterstützt.Die Richtlinien für Datenverlustprävention (DLP) werden immer strenger, und viele Dienste kommunizieren nur noch in sehr spezifischen JSON-Formaten (z. B. Amazon SNS, Azure Monitor oder ClickUp). Daher ist die Integration von Warnmeldungen in Teams und Slack nicht einfach durch das Einfügen einer URL möglich; sie erfordert eine sorgfältige Abwägung von Sicherheit, Payload-Formaten und Architektur.

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

Ein Webhook ist nichts anderes als ein HTTP- oder HTTPS-URL, die POST-Anfragen akzeptiert von einem anderen System. Jedes Mal, wenn ein Ereignis ausgelöst wird (ein Produktionsfehler, eine fehlgeschlagene Bereitstellung, eine Statusänderung einer Ressource usw.), wird Ihr Skript Der Dienst sendet eine JSON-Datei an diese URL, und die Nachricht erscheint in dem von Ihnen ausgewählten Teams- oder Slack-Kanal.

In diesem Schema Teams und Slack fungieren als passive Empfänger.Sie warten lediglich darauf, dass ihnen jemand eine Anfrage im korrekten Format sendet. Der Vorteil für Sie ist, dass Sie praktisch jede beliebige Sprache oder Umgebung verwenden können. PowershellBash PythonAWS Lambda, Azure Functions, CI-Pipelines, lokale Anwendungen – ganz nach Ihren Wünschen.

Es ist wichtig, das klar zu machen Jede Plattform erwartet eine spezifische JSON-Struktur.Ein Slack- oder Microsoft Teams-Webhook benötigt beispielsweise in der Regel mindestens ein Feld mit dem Nachrichtentext (normalerweise "Text"), während andere Dienste wie Amazon Chime andere Schlüssel erwarten (zum Beispiel "Inhalt").

Ein weiterer wichtiger Punkt ist, dass viele Cloud-Dienste (Azure, AWS, ClickUp usw.) Sie senden nicht genau das Format, das Teams oder Slack erwarten.sondern verwendet ein eigenes Payload-Schema für Ereignisse und Warnmeldungen. Deshalb benötigt man oft ein „Zwischenstück“, um diese Informationen in das richtige Format zu bringen.

Integrationsarten: Webhooks, Konnektoren, Bots und APIs

In der Welt von Microsoft Teams gibt es mehrere Möglichkeiten automatische Benachrichtigungen von Skripten oder externen Diensten erhaltenUnd es ist wichtig, zwischen ihnen zu unterscheiden, um die richtige Architektur auszuwählen:

Auf der einen Seite sind die eingehende WebhooksDies ist der direkteste Weg, 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 befindet sich das Benachrichtigungs-API und Benachrichtigungs-BotsDies sind einige der fortschrittlichsten Funktionen von Teams. Wir sprechen hier von vollwertigen 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. Es ist ideal, wenn Sie personalisierte Benutzererlebnisse, dynamische, adaptive Karten und ausgefeilte Geschäftsregeln benötigen.

Ebenfalls beteiligt sind Konnektoren für Gruppen von Microsoft 365Diese ermöglichen es Ihnen, einen Webhook mit eigener Einstellungsseite als Teil einer Teams-App zu verpacken. Sie verwenden typischerweise Konnektorkarten mit einer begrenzten Anzahl von Aktionen und eignen sich perfekt für Produktintegrationen wie Wetter-, Störungs- und andere Konnektoren.

Endlich gibt es die Graphbasierte Benachrichtigungs-APIEs fungiert als RESTful-Endpunkt, um Benachrichtigungen im Teams-Aktivitätsfeed auszulösen. Es 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 an Teams senden, indem Sie die Office 365 Connector WebhooksSie haben 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 die aktuellen APIs zu setzen.

Die empfohlene Methode, um weiterhin Benachrichtigungen von Skripten zu senden, ist: Die Zustellung an Teams mithilfe eines Power Automate-Flows orchestrierenAnstatt einen Office 365-Webhook direkt aufzurufen, lösen Ihre Skripte einen Power Automate HTTP-Trigger aus, und dieser Flow kümmert sich um das Erstellen und Senden der Nachricht an den Teams-Kanal mithilfe unterstützter Konnektoren.

In einem typischen Szenario erstellen Sie ein Cloud-Flow mit einem Auslöser wie „Wenn eine HTTP-Anfrage empfangen wird“Sie senden über Ihr PowerShell-, Bash- oder Python-Skript eine POST-Anfrage an den entsprechenden Endpunkt und übergeben die relevanten Daten (Schweregrad, Quelle, Vorfallbeschreibung usw.). Der Workflow verarbeitet das JSON, wandelt es in eine für Teams optimierte Karte oder Nachricht um und veröffentlicht diese im gewünschten Kanal.

Dieser Ansatz hat mehrere Vorteile: Es schützt Sie vor zukünftigen Änderungen an den Anschlüssen.Es ermöglicht Ihnen, die Logik für die Formatierung und Weiterleitung von Warnmeldungen zu zentralisieren 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 Offenlegen einer Webhook-URL ist, wie Verhindere, dass jemand Nachrichten an deinen Kanal sendet. Sollten Sie diese Adresse herausfinden: Obwohl Webhooks sehr praktisch sind, müssen sie als 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, noch einen Schritt weiter zu gehen und Registrieren Sie eine Anwendung bei Microsoft. Geben Sie die ID ein. (das ehemalige Azure AD) zum Schutz des HTTP-Endpunkts. 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 bewerben sich viele Organisationen Richtlinien zur Verhinderung von Datenverlust (DLP) in Umgebungen wie Power Automate oder Power AppsDiese 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, liegt die Ursache möglicherweise in der Datenverlustprävention (DLP).

In diesem Fall ist eine gemeinsame Überprüfung mit dem IT- oder Governance-Team erforderlich. Wie ist die Konnektorsegmentierung konfiguriert? und nehmen Sie Anpassungen vor, 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-Aktivitätsprotokoll oder Sicherheitssysteme generieren Alarmereignisse mit sehr umfangreichen und detaillierten JSON-SchemasWenn diese Ereignisse als Teil einer Gruppe von Aktionen an einen Webhook gesendet werden, enthält die Nutzlast, die Ihr Endpunkt empfängt, eine Menge Informationen, nicht nur den Nachrichtentext.

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 Administrative, 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 all dies in Teams oder Slack nutzen zu können, ist es nicht sinnvoll, die gesamte JSON-Datei unverändert zu kopieren. Der praktischere Ansatz ist die Verwendung Ihres Skripts oder Ihrer Funktion. Die relevanten Felder extrahieren (betroffene Ressource, Schweregrad, Beschreibung, kritische Zeitstempel, Korrelation) und eine besser lesbare Nachricht erstellen, die klar darlegt, was passiert ist, wo 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 ein weiterer wichtiger Baustein, wenn Sie möchten Auf AWS-Ereignisse reagieren und diese an Chatkanäle sendenSNS kann Nachrichten an HTTP/HTTPS-Endpunkte senden, jedoch nicht immer in dem Format, das Slack, Microsoft Teams oder Amazon Chime Webhooks erwarten.

Wenn Sie beispielsweise ein SNS-Thema so konfigurieren, dass es an einen Webhook gesendet wird, enthält die JSON-Nutzlast der Benachrichtigung eigene Schlüssel (Nachricht, Betreff, Zeitstempel usw.). Slack und Teams erwarten, dass der Anfragetext einen Schlüssel namens „text“ enthält. mit der Nachricht, die auf dem Kanal angezeigt werden soll, während Amazon Chime nach einem Schlüssel sucht "Inhalt"SNS unterstützt die Umwandlung dieses Formats zum Zeitpunkt der Veröffentlichung nicht direkt.

Die empfohlene Lösung in AWS ist die Verwendung von Lambda-Funktion als ZwischenschichtAnstatt den Webhook direkt beim SNS-Thema zu abonnieren, erstellen Sie ein SNS-Thema, konfigurieren eine Lambda-Funktion, die dieses Thema abonniert, und senden von Lambda aus den POST-Request an den Webhook, wobei das JSON in die richtige Struktur transformiert wird.

Der Ablauf sähe in etwa so aus: SNS veröffentlicht das Ereignis an die Lambda-Funktion; die Funktion liest… event[«Records»][0][«Sns»][«Message»]Erstellen Sie ein Wörterbuch mit dem entsprechenden Schlüssel („Content“ für Chime, „text“ für Slack oder Teams), optional mit folgenden Ergänzungen: Kanal, Benutzername o icon_emoji (Im Fall von Slack) werden die Daten in JSON serialisiert und die POST-Anfrage mithilfe einer HTTP-Bibliothek wie z. B. … gesendet. urllib3.

Im Python-Code ist das Grundgerüst sehr einfach: Man erstellt ein PoolManagerSie 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 die Ereignisse protokollieren. Statuscode und den Antworttext zum Debuggen, um zu überprüfen, ob der Webhook die Nachricht korrekt akzeptiert (Code 200) oder um 4xx-Fehler zu identifizieren, falls ungültige Parameter vorhanden sind oder die URL falsch ist.

Sobald das Lambda-Verhalten mit einem Testereignis in der Konsole (unter Verwendung der Vorlage „SNS-Themenbenachrichtigung“) validiert wurde, ist der nächste Schritt Füge das SNS-Theme als Auslöser hinzu der Funktion. Jedes Mal, wenn ein Dienst Daten zu diesem Thema veröffentlicht (z. B. CloudWatch-Alarme, Instanzstatusereignisse usw.), landet die Benachrichtigung im idealen Format in Slack, Teams oder Chime.

Webhooks in Microsoft Teams: eingehende, ausgehende und Konnektoren

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

Die ausgehende Webhooks Sie ermöglichen es Ihnen, einen externen Dienst aus einem Kanal 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) mit Inhalt, der entweder Klartext oder eine Karte sein kann. Dies ist nützlich für Befehle oder Abfragen auf Abruf, weniger für automatische Benachrichtigungen.

Die eingehende WebhooksWie bereits erwähnt, sind sie perfekt geeignet für regelmäßige Warnungen und Benachrichtigungen erhalten 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 die Konnektoren für Microsoft 365-GruppenDiese dienen dazu, einen eingehenden Webhook mit einer Konfigurationsoberfläche innerhalb von 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, wenn Ihr Hauptbedarf darin besteht, dass Ihre Skripte und Tools senden Nachrichten an einen Kanal Ohne viel Schnickschnack ist ein einfacher eingehender Webhook meist völlig ausreichend. Wer komplexe Logik, erweiterte Anpassungsmöglichkeiten und interaktive Aktionen benötigt, für den ist ein Benachrichtigungs-Bot oder eine Teams-App mit Benachrichtigungs-API besser geeignet.

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

Das Verfahren zum Aktivieren eines eingehenden Webhooks in einem Teams-Kanal ist zwar recht mechanisch, aber es lohnt sich. jeden Schritt vollständig verstehen um es dann in Ihre Skripte oder Anwendungen zu integrieren.

Zuerst wählen Sie in der Teams-Oberfläche das Team und das Standardkanal Geben Sie an, wo die Benachrichtigungen angezeigt werden sollen. Dies kann ein bestehender Kanal sein (z. B. „Vorfälle“) oder ein neuer, der speziell für Integrationen erstellt wird.

Dann klicken Sie auf die drei Punkte neben dem Kanalnamen und wählen die Option aus. AnschlüsseSuchen Sie in der Liste der verfügbaren Konnektoren nach „Eingehender Webhook“ und klicken Sie auf „Konfigurieren“. Vergeben Sie anschließend einen Namen, der den Zweck verdeutlicht (z. B. „CertSecure-Warnungen“, „CI/CD-Warnungen“ oder „Azure-Überwachung“) und laden Sie optional ein Symbol hoch, um die Nachrichtenquelle leichter erkennbar zu machen.

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

Einige Produkte, wie beispielsweise Zertifikatsverwaltungslösungen (z. B. CertSecure), verfügen über einen speziellen Bereich in ihrem eigenen Administrationsportal für Teams integrierenDort werden Sie in der Regel aufgefordert, die Webhook-URL einzufügen; nach dem Speichern sendet das System eine Testnachricht an den Teamkanal, die anzeigt, dass die Integration erfolgreich abgeschlossen wurde.

Von dort aus können Sie verschiedene Funktionen aktivieren oder deaktivieren. Benachrichtigungsereignisse (Ausstellung neuer Zertifikate, Widerrufe, Verlängerungen, Ablaufdaten oder Vorab-Benachrichtigungen), sodass jede relevante Änderung automatisch eine Nachricht im Kanal auslöst und das Team auf dem Laufenden hält, ohne dass es ständig auf das Bedienfeld 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 Sie den Kanal jedes Mal benachrichtigen möchten, wenn sich der Status eines Ordners oder einer Liste ändert.

ClickUp ermöglicht die Konfiguration von Automatisierungen, bei denen bei einer Zustandsänderung eine Aktion ausgelöst wird, die eine Anfrage an eine Webhook-URL sendet (z. B. die Slack-URL, die einen eingehenden Webhook generiert). Das Problem ist, dass ClickUp sendet seine eigene JSON-Nutzlast. mit einem Schema, das nicht den Erwartungen von Slack entspricht, sodass die Benachrichtigung möglicherweise nicht im Kanal angezeigt wird.

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 Methode, solche Inkompatibilitäten zu beheben, ist die Einführung eines Zwischenschicht, die als Übersetzer fungiertGenau wie bei SNS und Lambda leiten Sie den ClickUp-Webhook nicht direkt an Slack weiter, sondern an Ihren eigenen Endpunkt (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 anschließend an den eingehenden Webhook von Slack weiter.

Dieses Muster lässt sich auf viele andere Tools verallgemeinern, die „JSON senden“, jedoch nicht im von Slack oder Teams benötigten Format. Mit einer eigenen Integrationsschicht haben Sie die volle Kontrolle darüber. Nachrichtenformatierung, Filterung, Sicherheit und AnreicherungUnd Sie können API-Änderungen vornehmen, ohne die Konfiguration all Ihrer Skripte anfassen 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.