Cara mengirim peringatan ke Teams dan Slack dari skrip menggunakan webhook yang aman.

Jika Anda bekerja dengan infrastruktur cloud, CI/CD, pemantauan, atau manajemen insiden, Anda mungkin ingin Semua peringatan penting akan langsung masuk ke saluran Anda. Microsoft Tim atau SlackCara paling fleksibel dan sederhana untuk mencapai hal ini dari skrip, otomatisasi, atau layanan eksternal adalah dengan menggunakan webhook… asalkan Anda melindunginya dengan baik.

Dalam beberapa tahun terakhir, lanskapnya telah berubah: Konektor lama seperti yang ada di Office 365 di Teams sedang dihentikan penggunaannya.Kebijakan DLP semakin ketat, dan banyak layanan hanya berkomunikasi dengan JSON dalam format yang sangat spesifik (seperti Amazon SNS, Azure Monitor, atau ClickUp). Semua ini berarti bahwa mengintegrasikan peringatan dengan Teams dan Slack bukan hanya sekadar "menempelkan URL" dan selesai; hal ini membutuhkan pertimbangan cermat terhadap keamanan, format muatan data, dan arsitektur.

Apa sebenarnya webhook itu dan mengapa sangat berguna untuk notifikasi?

Webhook tidak lebih dari sekadar URL HTTP atau HTTPS yang menerima permintaan POST dari sistem lain. Setiap kali suatu peristiwa dipicu (kesalahan produksi, penyebaran yang gagal, perubahan status pada sumber daya, dll.), sistem Anda akan mencatat peristiwa tersebut. naskah Layanan ini mengirimkan data JSON ke URL tersebut dan pesan akan muncul di saluran Teams atau Slack yang telah Anda pilih.

Dalam skema ini, Teams dan Slack bertindak sebagai penerima pasif.Mereka hanya menunggu seseorang mengirimkan permintaan dalam format yang benar. Keuntungannya adalah, dari sisi Anda, Anda dapat menggunakan hampir semua bahasa atau lingkungan. PowerShellPesta Ular sancaAWS Lambda, Azure Functions, pipeline CI, aplikasi on-premise, apa pun yang Anda inginkan.

Penting untuk memperjelas hal itu Setiap platform mengharapkan struktur JSON tertentu.Sebagai contoh, webhook Slack atau Microsoft Teams biasanya memerlukan setidaknya satu kolom dengan teks pesan (biasanya "teks"), sementara layanan lain seperti Amazon Chime mengharapkan kunci yang berbeda (misalnya, "Isi").

Poin penting lainnya adalah banyak layanan cloud (Azure, AWS, ClickUp, dll.) Mereka tidak mengirimkan format yang persis seperti yang diharapkan oleh Teams atau Slack.melainkan skema muatan (payload) tersendiri untuk peristiwa dan peringatan. Itulah mengapa Anda sering membutuhkan "bagian perantara" untuk menyesuaikan informasi tersebut ke format yang benar.

Jenis-jenis integrasi: webhook, konektor, bot, dan API

Di dunia Microsoft Teams, ada beberapa cara untuk menerima notifikasi otomatis dari skrip atau layanan eksternaldan penting untuk membedakan antara keduanya agar dapat memilih arsitektur yang tepat:

Di satu sisi ada webhook masukIni adalah cara paling langsung untuk mengirim pesan ke saluran Teams. Mengaktifkan fitur ini di saluran akan menghasilkan URL HTTPS yang menerima JSON dan menyisipkan konten ke dalam percakapan. Fitur ini tidak memerlukan instalasi aplikasi yang rumit atau sumber daya Azure tambahan; ini adalah fitur bawaan saluran.

Di ujung lainnya Anda memiliki API Notifikasi dan Bot NotifikasiIni adalah beberapa kemampuan Teams yang paling canggih. Kita berbicara tentang aplikasi Teams lengkap yang dapat mengirimkan notifikasi kaya kepada pengguna, obrolan, atau saluran, memanfaatkan Microsoft Graph, mengambil konteks pengguna, menampilkan konten di dasbor, dan banyak lagi. Ini ideal jika Anda mencari pengalaman yang dipersonalisasi, kartu adaptif dinamis, dan aturan bisnis yang canggih.

Yang juga terlibat adalah konektor untuk Grup Microsoft 365Ini memungkinkan Anda untuk mengemas webhook dengan halaman pengaturannya sendiri sebagai bagian dari aplikasi Teams. Biasanya, ini menggunakan kartu konektor dengan serangkaian tindakan terbatas, yang sempurna untuk integrasi "produk" seperti cuaca, insiden, dan konektor lainnya.

Terakhir, ada API notifikasi berbasis grafikIni berfungsi sebagai endpoint RESTful untuk memicu notifikasi di feed aktivitas Teams. Ini sangat ampuh ketika Anda ingin aplikasi web atau backend Anda mengirimkan peringatan mendesak, dengan suara dan notifikasi sistem operasi, tentang informasi penting yang ditujukan kepada pengguna atau grup tertentu.

Selamat tinggal konektor Office 365: mengapa saatnya beralih ke Power Automate

Jika Anda telah mengirim pesan ke Teams selama bertahun-tahun menggunakan Webhook konektor Office 365Anda mungkin sudah melihat pemberitahuan bahwa fungsi ini akan dihentikan. Microsoft sedang menyelaraskan ekosistem dengan strategi "aman untuk masa depan", yang dalam praktiknya berarti mendorong solusi yang lebih modern dan terkontrol, seperti Power Automate dan API yang ada saat ini.

Cara yang disarankan untuk terus mengirimkan peringatan dari skrip adalah Mengatur pengiriman ke Teams menggunakan alur Power Automate.Alih-alih memanggil webhook Office 365 secara langsung, skrip Anda memicu pemicu HTTP Power Automate, dan alur ini menangani pembuatan dan pengiriman pesan ke saluran Teams menggunakan konektor yang didukung.

Dalam skenario tipikal, Anda membuat sebuah Alur cloud dengan pemicu seperti “Saat permintaan HTTP diterima”Dari skrip PowerShell, Bash, atau Python Anda, Anda membuat permintaan POST ke endpoint tersebut, dengan mengirimkan data yang relevan (tingkat keparahan, sumber, deskripsi insiden, dll.). Alur kerja memproses JSON, mengubahnya menjadi kartu atau pesan yang disesuaikan untuk Teams, dan mempublikasikannya ke saluran pilihan Anda.

Pendekatan ini memiliki beberapa keunggulan: Hal ini membuat Anda terlepas dari perubahan konektor di masa mendatang.Ini memungkinkan Anda untuk memusatkan logika untuk memformat dan mengarahkan peringatan, serta mempermudah pemenuhan persyaratan keamanan dan kepatuhan, karena Power Automate dapat diintegrasikan dengan Microsoft 365 DLP dan tata kelola.

Melindungi webhook Anda: token, penyewa, dan DLP

Salah satu pertanyaan besar ketika mengekspos URL webhook adalah bagaimana caranya. Cegah siapa pun mengirim pesan ke saluran Anda. Jika Anda menemukan alamat tersebut. Meskipun webhook sangat praktis, webhook harus diperlakukan sebagai kredensial sensitif.

Pola yang umum digunakan terdiri dari Tambahkan token otorisasi sebagai parameter di URL.Sebagai contoh, sebuah endpoint mungkin terlihat seperti ini: https://miservicio/webcallback?tokenid=sometokenid&someparameter=somevalueLayanan yang menerima panggilan akan memverifikasi bahwa token tersebut valid sebelum memproses permintaan. Dengan cara ini, meskipun seseorang melihat URL tanpa token yang benar, mereka tidak akan dapat menggunakannya.

Di lingkungan Azure dan Microsoft 365, hal yang umum dilakukan adalah melangkah lebih jauh dan Daftarkan aplikasi di Microsoft Enter ID (dahulu Azure AD) untuk melindungi endpoint HTTP. Alur Power Automate dapat dipublikasikan di balik fungsi yang dilindungi API Management atau Entra, sehingga hanya skrip terautentikasi milik tenant Anda yang dapat memicu webhook.

Selain itu, banyak organisasi yang mengajukan permohonan. kebijakan pencegahan kehilangan data (DLP) pada lingkungan seperti Power Automate atau Power AppsKebijakan ini dapat memblokir atau membatasi penggunaan konektor tertentu (misalnya, mengirim data dari lingkungan "rahasia" ke konektor yang dianggap "tidak tepercaya," seperti webhook Teams). Jika Anda mengalami kesalahan saat menyimpan atau menjalankan alur kerja, penyebab utamanya mungkin terletak pada DLP.

Dalam hal ini, perlu ditinjau bersama dengan tim TI atau tim tata kelola. Bagaimana segmentasi konektor dikonfigurasi? dan lakukan penyesuaian agar webhook Teams atau Slack Anda dapat menjadi bagian dari konektor yang diizinkan di lingkungan tempat alur kerja atau aplikasi Anda berjalan.

Format unggahan JSON: dari Azure Monitor ke Teams dan Slack

Layanan seperti Azure Monitor, log aktivitas Azure, atau sistem keamanan menghasilkan Peristiwa peringatan dengan skema JSON yang sangat kaya dan detail.Ketika peristiwa-peristiwa ini dikirim ke webhook sebagai bagian dari sekelompok tindakan, muatan yang diterima oleh endpoint Anda mencakup banyak informasi, bukan hanya teks pesan.

Tata letak umum notifikasi peringatan Log aktivitas Azure mencakup sebuah bidang schemaId dan sebuah objek data yang berisi status peringatan, konteks, dan properti. Di dalam data.context.activityLog Data seperti jenis saluran, correlationId, stempel waktu kejadian, level (Kritis, Kesalahan, Peringatan, Informasi), operationName, pengidentifikasi sumber daya yang terpengaruh, dan lainnya.

Tergantung pada nilai eventSource Dalam beban tersebut, struktur spesifiknya bervariasi: terdapat peristiwa tipe Administratif, Security, Rekomendasi, Layanan Kesehatan o Kesehatan Sumber Dayamasing-masing dengan properti spesifiknya sendiri. Misalnya, suatu peristiwa keamanan mungkin merinci upaya paksa SSH, IP penyerang, pengguna yang digunakan, jumlah upaya yang gagal, dan langkah-langkah perbaikan yang disarankan.

Elemen lain dari beban tersebut meliputi bidang-bidang seperti otorisasi (tindakan dan ruang lingkup kontrol akses berbasis peran), penelepon (email atau UPN pengguna yang melakukan operasi), eventDataId (pengidentifikasi unik), subStatus (seringkali dengan kode HTTP seperti 200, 400, 404, 500, dll.), dan kamus yang berisi properties dengan pasangan kunci-nilai yang menambahkan lebih banyak konteks pada peristiwa tersebut.

Agar semua ini bermanfaat di Teams atau Slack, menyalin seluruh file JSON apa adanya bukanlah solusi yang tepat. Pendekatan yang lebih praktis adalah menggunakan skrip atau fungsi Anda. ekstrak bidang yang relevan (sumber daya yang terpengaruh, tingkat keparahan, deskripsi, stempel waktu penting, korelasi) dan membangun pesan yang lebih mudah dibaca, dengan menyatakan secara jelas apa yang terjadi, di mana, dan apa yang harus dilakukan selanjutnya.

Dari Amazon SNS hingga Slack, Teams, dan Chime dengan Lambda

Amazon Simple Notification Service (SNS) adalah bagian penting lainnya ketika Anda menginginkan Bereaksi terhadap peristiwa AWS dan mengirimkannya ke saluran obrolan.SNS dapat mempublikasikan pesan ke titik akhir HTTP/HTTPS, tetapi tidak selalu dalam format yang diharapkan oleh webhook Slack, Microsoft Teams, atau Amazon Chime.

Sebagai contoh, ketika Anda mengkonfigurasi topik SNS untuk mengirim data ke webhook, payload JSON notifikasi memiliki kunci tersendiri (Pesan, Subjek, Stempel Waktu, dll.). Namun, Slack dan Teams mengharapkan isi permintaan menyertakan kunci "teks". dengan pesan yang akan ditampilkan di saluran tersebut, sementara Amazon Chime mencari kunci. "Isi"SNS tidak secara langsung mendukung transformasi format tersebut pada saat publikasi.

Solusi yang direkomendasikan di AWS adalah menggunakan Fungsi Lambda sebagai lapisan perantaraAlih-alih berlangganan webhook langsung ke topik SNS, Anda membuat topik SNS, mengkonfigurasi fungsi Lambda yang berlangganan ke topik tersebut, dan dari Lambda Anda mengirimkan POST ke webhook dengan JSON yang telah diubah ke dalam struktur yang benar.

Alurnya akan terlihat seperti ini: SNS mempublikasikan event ke fungsi Lambda; fungsi tersebut membaca... acara[«Catatan»][0][«Sns»][«Pesan»]Buat kamus dengan kunci yang sesuai ("Konten" untuk Chime, "teks" untuk Slack atau Teams, secara opsional menambahkan saluran, nama pengguna o ikon_emoji (dalam kasus Slack), melakukan serialisasi ke JSON dan membuat permintaan POST menggunakan pustaka HTTP seperti urllib3.

Dalam kode Python, kerangka dasarnya sangat sederhana: Anda membuat sebuah Manajer Kolam RenangAnda menentukan URL webhook, menyusun pesan dengan kolom yang diharapkan, mengonversinya ke JSON yang dikodekan UTF-8, dan mengirimkan permintaan. Kemudian, Anda dapat mencatatnya. kode_status dan isi respons untuk debugging, memeriksa apakah webhook menerima pesan dengan benar (kode 200) atau mengidentifikasi kesalahan 4xx jika ada parameter yang tidak valid atau URL yang salah.

Setelah perilaku Lambda divalidasi dengan event pengujian di konsol (menggunakan template “SNS Topic Notification”), langkah selanjutnya adalah tambahkan tema SNS sebagai pemicu dari fungsi tersebut. Dengan demikian, setiap kali suatu layanan mempublikasikan ke topik tersebut (misalnya, CloudWatch Alarms, peristiwa status instance, dll.), peringatan tersebut akan sampai di Slack, Teams, atau Chime dalam format yang ideal.

Webhook di Microsoft Teams: masuk, keluar, dan konektor

Di dalam Tim terdapat berbagai jenis konektivitas Hal ini melampaui webhook masuk biasa dan penting untuk mengetahuinya agar dapat merancang solusi peringatan Anda dengan lebih baik.

Los webhook keluar Fitur ini memungkinkan Anda untuk "memanggil" layanan eksternal dari saluran menggunakan simbol @. Anda mengkonfigurasi webhook keluar dengan URL layanan Anda, dan ketika pengguna memanggilnya dengan pesan, Teams mengirimkan teks ke endpoint Anda dan mengharapkan respons cepat (biasanya dalam 10 detik) dengan konten yang dapat berupa teks biasa atau kartu. Ini berguna untuk perintah atau kueri sesuai permintaan, bukan untuk peringatan otomatis.

Los webhook masukSeperti yang telah kami sebutkan sebelumnya, produk ini sangat cocok untuk... menerima peringatan dan pemberitahuan berkala Dari aplikasi eksternal. Anda membuat webhook di sebuah saluran (misalnya, saluran DevOps) dan mengkonfigurasi pipeline, skrip deployment, alat pemantauan, atau sistem keamanan Anda untuk mengirimkan event mereka ke URL tersebut menggunakan HTTP POST.

Lalu ada Konektor untuk Grup Microsoft 365Fungsi-fungsi ini adalah untuk mengemas webhook yang masuk dengan antarmuka konfigurasi di dalam Teams. Biasanya, pesan dikirim dalam bentuk kartu konektor dan memungkinkan pengalaman yang lebih "mirip produk", seperti memilih lokasi di konektor cuaca, menjadwalkan waktu notifikasi, dan sebagainya.

Dari sudut pandang arsitektur, jika kebutuhan utama Anda adalah itu Skrip dan alat Anda mengirim pesan ke suatu saluran. Tanpa terlalu banyak hiasan visual, webhook masuk yang sederhana biasanya sudah lebih dari cukup. Jika Anda mencari logika yang kompleks, kustomisasi tingkat lanjut, dan tindakan interaktif, maka bot notifikasi atau aplikasi Teams dengan API notifikasi lebih tepat.

Cara membuat webhook masuk di Teams dan menggunakannya dari layanan eksternal.

Proses untuk mengaktifkan webhook masuk di saluran Teams cukup mekanis, tetapi hal itu bermanfaat. pahami sepenuhnya setiap langkah lalu mengintegrasikannya dengan skrip atau aplikasi Anda.

Pertama, di antarmuka Teams, Anda memilih tim dan saluran standar Di sinilah Anda ingin peringatan tersebut muncul. Ini bisa berupa saluran yang sudah ada (misalnya, "Insiden") atau saluran baru yang dibuat khusus untuk integrasi.

Kemudian Anda klik tiga titik di sebelah nama saluran dan pilih opsi untuk KonektorDalam daftar konektor yang tersedia, temukan "Incoming Webhook" dan klik "Konfigurasi." Kemudian, berikan nama yang mengidentifikasi tujuannya (misalnya, "CertSecure Alerts," "CI/CD Alerts," atau "Azure Monitoring") dan, secara opsional, unggah ikon untuk memudahkan pengenalan sumber pesan.

Saat Anda mengkonfirmasi pembuatan, Teams akan menghasilkan sebuah URL webhook unikItulah alamat yang akan Anda salin dan tempel ke pengaturan alat atau layanan eksternal Anda. Penting untuk menjaganya tetap aman, karena siapa pun yang mendapatkan akses ke alamat tersebut dapat mengirim pesan ke saluran atas nama Anda.

Beberapa produk, seperti solusi manajemen sertifikat (misalnya, CertSecure), memiliki bagian khusus di portal administrasinya sendiri untuk mengintegrasikan TimDi sana, mereka biasanya meminta Anda untuk menempelkan URL webhook; setelah menyimpannya, sistem akan mengirimkan pesan uji ke saluran tim yang menunjukkan bahwa integrasi telah berhasil diselesaikan.

Dari situ, Anda dapat mengaktifkan atau menonaktifkan berbagai opsi. peristiwa pemberitahuan (penerbitan sertifikat baru, pencabutan, perpanjangan, kedaluwarsa, atau peringatan sebelum kedaluwarsa) sehingga setiap perubahan yang relevan menghasilkan pesan otomatis di saluran tersebut, menjaga tim tetap mendapatkan informasi terbaru tanpa perlu terus-menerus mengakses panel alat.

Masalah umum dengan ClickUp, Slack, dan layanan lainnya

Tidak semua platform langsung kompatibel dengan webhook Slack atau Teams, meskipun tampaknya yang perlu Anda lakukan hanyalah menempelkan URL. Contoh tipikalnya adalah... ClickUp dan Slack Saat Anda ingin memberi tahu saluran setiap kali status folder atau daftar berubah.

ClickUp memungkinkan Anda untuk mengkonfigurasi otomatisasi di mana, setelah perubahan status, sebuah tindakan dipicu yang mengirimkan permintaan ke URL webhook (misalnya, URL Slack yang menghasilkan webhook masuk). Masalahnya adalah... ClickUp mengirimkan payload JSON-nya sendiri. dengan skema yang tidak sesuai dengan yang diharapkan Slack, sehingga notifikasi mungkin tidak muncul di saluran.

Di Slack, webhook yang masuk biasanya mengharapkan sesuatu yang sesederhana ini. { "text": "Mensaje a mostrar" }dengan beberapa kolom opsional seperti saluran, nama pengguna, atau ikon. Jika Anda malah menerima JSON bersarang dengan kolom khusus ClickUp, Anda dapat mengabaikan permintaan tersebut. atau salah menafsirkannya, sehingga menghasilkan peringatan yang sebenarnya tidak pernah dilihat.

Cara terbaik untuk mengatasi jenis ketidakcocokan ini adalah dengan memperkenalkan lapisan perantara yang bertindak sebagai penerjemahSama seperti SNS dan Lambda, alih-alih mengarahkan webhook ClickUp langsung ke Slack, Anda mengarahkannya ke endpoint Anda sendiri (fungsi cloud, API kecil di backend Anda). Endpoint tersebut menerima JSON ClickUp, memilih informasi yang relevan (misalnya, nama tugas, status sebelumnya dan baru, penerima tugas), dan menyusun JSON minimum yang dibutuhkan Slack, kemudian meneruskan permintaan ke webhook masuk Slack.

Pola ini dapat digeneralisasikan ke banyak alat lain yang "mengirim JSON" tetapi bukan dalam format yang dibutuhkan oleh Slack atau Teams. Dengan memiliki lapisan integrasi sendiri, Anda memiliki kendali penuh atas pemformatan pesan, penyaringan, keamanan, dan pengayaanDan Anda dapat menangani perubahan API tanpa harus menyentuh konfigurasi semua skrip Anda.

Memanfaatkan webhook yang aman untuk mengirimkan peringatan dari skrip ke Teams dan Slack melibatkan lebih dari sekadar menyalin dan menempel URL: hal ini membutuhkan pemahaman tentang berbagai jenis integrasi Teams, skema JSON dari layanan seperti Azure Monitor dan Amazon SNS, peran lapisan middleware seperti Power Automate atau AWS Lambda, serta langkah-langkah keamanan dan DLP yang terkait dengan semua ini. Jika Anda merancang arsitektur ini dengan baik, tim Anda akan menikmati peringatan yang kaya, andal, dan real-time, tanpa kejutan perubahan konektor yang sudah usang atau format yang tidak kompatibel yang secara diam-diam menelan notifikasi Anda.