Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan ›
januari 22, 2026

Slack + Gmail: triagerade larm om misstänkta inloggningar

Rickard Andersson Partner, Nodenordic.se

Dina varningar om ”misstänkt inloggning” är antingen för högljudda eller för sena. Du får en Slack-ping utan sammanhang, någon frågar ”är det här på riktigt?”, och sedan tappar du 30 minuter på att plocka fram IP-info, enhetsdetaljer och tidigare inloggningar bara för att avgöra om det är värt att eskalera.

Den här automatiseringen för Slack Gmail alerts träffar SecOps-team först, men en ensam grundare med en SaaS-produkt och en byrå som hanterar kundkonton känner samma smärta. Resultatet är enkelt: bättre och snabbare triage i Slack, och e-post till användare först när det finns en verklig risksignal.

Nedan ser du exakt hur workflowet berikar en inloggningshändelse, sätter prioritet (hög/medium/låg), postar en användbar Slack-varning och först därefter avgör om Gmail ska notifiera användaren.

Så fungerar den här automatiseringen

Hela n8n-workflowet, från trigger till slutlig output:

n8n Workflow Template: Slack + Gmail: triagerade larm om misstänkta inloggningar

Problemet: varningar om misstänkt inloggning utan kontext

En händelse om ”misstänkt inloggning” låter akut, men den råa varningen saknar oftast detaljerna som gör att du kan agera. Du måste ändå kolla IP-rykte, ta reda på var IP-adressen finns, avkoda user agent-strängen och kontrollera om användaren har loggat in från den enheten eller platsen tidigare. Under tiden blir Slack-kanalen stökig. Folk börjar ignorera pingar. Ärligt talat är det så verkliga incidenter slinker igenom: inte för att du saknade varningar, utan för att du hade för många svaga.

Det går snabbt ihop. Här är vad som faller isär i den dagliga driften.

  • Du lägger cirka 10–20 minuter per varning på att samla grundläggande kontext, eftersom den initiala event-payloaden sällan berättar hela historien.
  • Falsklarm staplas, så teamet ”tystar” kanalen mentalt även om Slack fortfarande pingar.
  • Användarnotifiering blir en gissning, och att mejla varje gång tränar användare att ignorera säkerhetsmejl också.
  • Utan att jämföra med senaste inloggningar i din databas missar du den enkla signalen som spelar roll: ”ny enhet” eller ”ny plats”.

Lösningen: berikade Slack-varningar + selektiva Gmail-mejl

Det här workflowet tar en inloggningshändelse och gör den till en säkerhetsvarning som går att fatta beslut på. Det startar när en ny inloggningshändelse träffar en webhook (eller när du kör ett manuellt testevent i n8n). Workflowet plockar ut fälten du faktiskt bryr dig om: IP-adress, user agent, tidsstämpel, URL och användar-ID. Sedan berikar det händelsen parallellt. En gren kontrollerar IP-rykte via GreyNoise Community, en annan hämtar geolokalisering, och en tredje avkodar user agent för att identifiera webbläsare/enhet. Efter berikningen sätter det en prioritetsnivå (hög, medium eller låg) och postar en Slack-varning som innehåller den kontext du annars hade lagt tid på att leta fram. Till sist, om inloggningen ser ut som ett ”okänt hot”, kontrollerar det användarens senaste inloggningshistorik i Postgres och mejlar användaren bara när något faktiskt har förändrats.

Workflowet startar från din webhook för inloggningshändelser. Det berikar IP- och enhetsdetaljer, och slår sedan ihop allt till en strukturerad incidentbild. Slack får varningen oavsett, men Gmail reserveras för fallen som ser genuint avvikande ut från användarens normala beteende.

Det här får du: automatisering vs. resultat

Exempel: så här ser det ut

Säg att du får 10 händelser om misstänkta inloggningar under en intensiv vecka. Manuellt kanske du lägger cirka 15 minuter per händelse på att kontrollera IP-rykte, geolokalisering, user agent och tidigare inloggningar, alltså ungefär 2–3 timmar. Med det här workflowet granskar du fortfarande Slack-varningarna, men berikning och prioritering sker automatiskt, vilket innebär att din ”mänskliga tid” sjunker till en snabb genomgång (kanske 2 minuter per styck). Det blir runt 20 minuter totalt, och Gmail går bara ut när en inloggning verkligen är ny för den användaren.

Det här behöver du

  • n8n-instans (testa n8n Cloud gratis)
  • Alternativ för self-hosting om du föredrar det (Hostinger fungerar bra)
  • Slack för att ta emot berikade säkerhetsvarningar.
  • Gmail för att notifiera användare bara när det behövs.
  • Postgres för senaste inloggningshistorik och användarposter.
  • GreyNoise Community API-nyckel (hämta den i din GreyNoise-kontodashboard).
  • IP-API-åtkomst för att hämta IP-geolokalisering.
  • UserParser API-nyckel (hämta den i dina UserParser-kontoinställningar).

Kunskapsnivå: Medel. Du kopplar credentials, mappar webhook-fält och verifierar att din databasfråga matchar ditt schema.

Vill du inte sätta upp detta själv? Prata med en automatiseringsexpert (gratis 15-minuters konsultation).

Så fungerar det

En inloggningshändelse träffar din webhook. Workflowet kan triggas av ett riktigt system som skickar inloggningshändelser, och det innehåller även en manuell trigger och en exempel-payload för säker testning.

Workflowet standardiserar eventfälten. Ett mapping-steg plockar ut IP, tidsstämpel, URL, användar-ID och user agent så att efterföljande kontroller inte skapar fel när payloaden ändras lite.

Berikning sker parallellt. GreyNoise ger rykte-/reputationssignaler, IP-API ger geolokalisering och UserParser avkodar user agent så att du kan se enhets-/webbläsardetaljer utan att läsa en rörig UA-sträng.

Risk bedöms och styrs. Känd aktivitet kan ignoreras tidigt, men okända hot triggar en Postgres-uppslagning av de 10 senaste inloggningarna. Om platsen eller enheten är ny skapar workflowet ett HTML-mejl och skickar det via Gmail. Slack får fortfarande en prioriterad varning så att teamet kan agera snabbt.

Du kan enkelt justera prioritetsreglerna så att de matchar din interna policy baserat på tillitsnivå, IP-klassificering eller platsförändringar. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementering

Steg 1: Konfigurera webhook-triggern

Sätt upp webhookens ingångspunkt som tar emot inloggningshändelser och mappar payloaden till normaliserade fält.

  1. Lägg till eller öppna Incoming Login Webhook och ställ in HTTP Method till POST.
  2. Ställ in Path till 705ca4c4-0a38-4ef8-9de9-abc8b3686dc6 så att det matchar workflowet.
  3. Koppla Incoming Login Webhook till Map Login Fields så att inkommande payload normaliseras.
  4. I Map Login Fields, aktivera Keep Only Set och mappa:
  5. ip → {{ $json.body.context.ip }}, userAgent → {{ $json.body.context.userAgent }}, timestamp → {{ $json.body.originalTimestamp }}, url → {{ $json.body.context.page.url }}, userId → {{ $json.body.userId }}.
⚠️ Vanlig fallgrop: Incoming Login Webhook är inaktiverad i workflowet. Aktivera den före produktionsanvändning.

Steg 2: Konfigurera den manuella test-triggern

Använd den manuella vägen för att simulera en inloggningshändelse utan att anropa den live webhooken.

  1. Öppna Manual Run Trigger och behåll den som manuell ingångspunkt.
  2. I Sample Event Payload, klistra in den medföljande JavaScript-koden i Code och koppla den till Map Login Fields.
  3. Kör Manual Run Trigger för att verifiera att Map Login Fields matar ut ip, userAgent, timestamp, url och userId.

Steg 3: Konfigurera enrichment-uppslag (parallellt)

Berika varje inloggning med IP-rykte, geolokalisering och user agent-detaljer. Dessa grenar körs parallellt.

  1. Map Login Fields skickar ut till GreyNoise Lookup, User Agent Lookup och IP Geolocation Lookup parallellt.
  2. I GreyNoise Lookup, ställ in URL till =https://api.greynoise.io/v3/community/{{ $json.ip }}.
  3. Autentisering krävs: Anslut era httpHeaderAuth-uppgifter i GreyNoise Lookup.
  4. I User Agent Lookup, ställ in URL till https://api.userparser.com/1.1/detect och Query Parameter ua till {{ $json.userAgent }}.
  5. Autentisering krävs: Anslut era httpQueryAuth-uppgifter i User Agent Lookup.
  6. I IP Geolocation Lookup, ställ in URL till =http://ip-api.com/json/{{ $json.ip }}.
De här tre grenarna är designade för att köras samtidigt. Om något externt API begränsar er genomströmning, lägg till rate limits eller retries på HTTP-noderna.

Steg 4: Slå ihop kontext och utvärdera risk

Kombinera berikningsresultat och routa risk baserat på IP-klass och förtroendeindikatorer.

  1. Koppla IP Geolocation Lookup och User Agent Lookup till Combine Geo & Agent med Mode satt till combine och Combination Mode till multiplex.
  2. Routa GreyNoise Lookup till Assemble Login Context så att hotmetadata ansluts till den kombinerade kontexten.
  3. Från GreyNoise Lookup, routa även till Check Noise Signal och därefter till Evaluate IP Class för att klassificera risk.
  4. I Evaluate IP Class, ställ in Value 1 till {{ $json.classification }} med regler för malicious, benign och unknown.
  5. I Check Riot Flag, utvärdera {{ $('GreyNoise Lookup').item.json.riot }} och skicka true-grenen till Evaluate Trust Level.
  6. I Evaluate Trust Level, ställ in Value 1 till {{ $json.trust_level }} och mappa utgångar till 🔴 Set High Priority, 🟡 Set Medium Priority och 🟢 Set Low Priority.

Steg 5: Upptäck signaler för ny plats och enhet

Jämför aktuell inloggningsdata mot nylig historik för att flagga nya enheter eller platser.

  1. Från Assess Unknown Threat, routa till Fetch Recent User Logins när inloggningen inte är markerad som känd aktivitet.
  2. Autentisering krävs: Anslut era postgres-uppgifter i Fetch Recent User Logins och behåll frågan satt till SELECT * FROM staging_n8n_cloud_frontend.user_signed_in WHERE user_id='{{ $('Map Login Fields').item.json.userId }}' ORDER BY received_at DESC LIMIT 10;.
  3. Fetch Recent User Logins skickar ut till både Lookup IP Geo (API) och Decode User Agent parallellt.
  4. I Lookup IP Geo (API), ställ in URL till =http://ip-api.com/json/{{ $json.context_ip }} och koppla den till Check New Location.
  5. I Check New Location, jämför {{ $json.city }} med {{ $('Combine Geo & Agent').item.json.city }} och routa true till Flag New Location.
  6. Autentisering krävs: Anslut era httpQueryAuth-uppgifter i Decode User Agent och ställ in Query Parameter ua till {{ $json.context_user_agent }}.
  7. I Detect New Device, behåll Combine Operation som any och jämför fält för webbläsare, OS och enhet med {{ $('Assemble Login Context').first().json... }} för att routa nya enheter till Flag New Device.
⚠️ Vanlig fallgrop: Retrieve User Record och Fetch Recent User Logins är inaktiverade som standard. Aktivera båda, annars får enhets-/platskontrollerna ingen data.

Steg 6: Hämta användardata och skapa e-post

Hämta användarprofilen, verifiera e-postadressen och generera varningsmejlets HTML.

  1. Från Flag New Location och Flag New Device, routa till Retrieve User Record.
  2. Autentisering krävs: Anslut era postgres-uppgifter i Retrieve User Record och behåll frågan SELECT * FROM staging_n8n_cloud_frontend.users WHERE id='{{ $('Map Login Fields').item.json.userId }}'.
  3. I Verify Email Availability, använd strängvillkoret {{ $json.email }} med Is Not Empty för att bara skicka till giltiga e-postadresser.
  4. I Compose Email HTML, behåll HTML-mallen som den är och säkerställ att den refererar till {{ $('Map Login Fields').item.json.timestamp }} och {{ $('Assemble Login Context').item.json.city }} för detaljer.

Steg 7: Konfigurera larm och notiser

Skicka användarnotiser och posta Slack-larm baserat på prioritet.

  1. Koppla Compose Email HTML till Send User Email och ställ in Send To till {{ $('Verify Email Availability').item.json.email }} och Message till {{ $json.html }}.
  2. Autentisering krävs: Anslut era gmailOAuth2-uppgifter i Send User Email.
  3. Från 🔴 Set High Priority, 🟡 Set Medium Priority och 🟢 Set Low Priority, routa till Post Slack Alert.
  4. I Post Slack Alert, behåll fältet Text satt till =Suspicious login attempt detected: ... och välj rätt Channel-värde.
  5. Autentisering krävs: Anslut era slackApi-uppgifter i Post Slack Alert.
⚠️ Vanlig fallgrop: Send User Email och Post Slack Alert är inaktiverade. Aktivera dem innan ni testar notiser end-to-end.

Steg 8: Testa och aktivera ert workflow

Kör ett manuellt test, validera parallella grenar och växla sedan workflowet till aktivt.

  1. Klicka på Execute Workflow i Manual Run Trigger för att testa hela flödet med Sample Event Payload.
  2. Verifiera att Map Login Fields matar ut förväntade värden och att GreyNoise Lookup, User Agent Lookup och IP Geolocation Lookup körs parallellt.
  3. Bekräfta att Compose Email HTML genererar HTML och att Send User Email och Post Slack Alert skickar larm när de är aktiverade.
  4. Aktivera Incoming Login Webhook och växla workflowet till Active för produktionsanvändning.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • GreyNoise-credentials kan gå ut eller klistras in fel. Om varningar plötsligt tappar prioritetsdata, kontrollera först autentiseringsinställningarna i GreyNoise request-noden och output från senaste körningen.
  • Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om efterföljande noder fallerar på tomma svar.
  • Gmail-sändning kan fallera om användarposten saknar e-post eller om ditt Gmail-konto saknar behörighet. Bekräfta output från Postgres ”Retrieve User Record” och villkoret ”Verify Email Availability” innan du antar att workflowet är trasigt.
  • Standardprompter i AI-noder är generiska. Lägg in din tonalitet tidigt, annars kommer du att redigera output för alltid.

Relaterade workflows

Om ditt team också behöver omvandla autentiseringsbrus till spårbara arbetsobjekt passar Slack + Jira-varningar för misslyckade inloggningar, loggade i Notion bra med detta workflow, eftersom det lägger till ett tydligt ”skapa ett ärende och logga det”-spår efter att du har avgjort att något är viktigt.

För team som hanterar medarbetarrapporterade hot kompletterar Gmail + Jira: phishingrapporter fångas och arkiveras snabbt triage av misstänkta inloggningar genom att omvandla inkommande phishingmejl till strukturerade incidentposter utan att någon behöver kopiera skärmdumpar och headers för hand.

När bedrägeri och kontosäkerhet överlappar (tänk bokningssajter och marknadsplatser) är Gmail + Google Sheets, smartare varningar för bokningsbedrägeri användbart bredvid inloggningsövervakning eftersom det samlar ”udda aktivitet”-mönster i ett ark du kan granska varje vecka.

Behöver du en striktare beviskedja för utredningar? Gmail till Jira, phishingrapporter arkiverade med bevis är byggt för det, och det fungerar bra när misstänkta inloggningar eskalerar till bredare phishing- eller kontokapningsärenden.

Slutligen, om du vill fånga mönster i stället för enskilda händelser, lägger Slack-varningar för toppar av misstänkta inloggningar från dina loggar till ett lager för ”spike detection” så att du upptäcker brute-force-vågor eller credential stuffing tidigare.


Snabbreferens:

Vanliga frågor

Hur lång tid tar det att sätta upp den här automatiseringen för Slack Gmail alerts?

Cirka en timme om du redan har API-nycklarna och Postgres-tabellerna redo.

Behöver jag kunna koda för att automatisera Slack Gmail alerts?

Nej. Du kopplar mest konton och klistrar in API-nycklar. Den enda ”tekniska” delen är att bekräfta att din Postgres-fråga matchar hur du lagrar inloggningshistorik.

Är n8n gratis att använda för det här workflowet för Slack Gmail alerts?

Ja. n8n har ett gratis alternativ för self-hosting och en gratis testperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna in API-kostnader för GreyNoise, IP-API och UserParser (ofta låga vid lätt användning, men det beror på din volym).

Var kan jag hosta n8n för att köra den här automatiseringen?

Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller self-hosting på en VPS. För self-hosting är Hostinger VPS prisvärt och hanterar n8n bra. Self-hosting ger dig obegränsade körningar men kräver grundläggande serverhantering.

Kan jag anpassa det här workflowet för Slack Gmail alerts för andra riskregler?

Ja, och det bör du. Du kan justera switcharna ”Evaluate Trust Level” och ”Evaluate IP Class” så att de matchar din interna policy, och sedan finjustera villkoren ”Assess Unknown Threat” och ”Check New Location / Detect New Device” för att styra när Gmail skickar. Vanliga anpassningar är att ändra vad som räknas som ”nytt” (stad vs. land), lägga till tillåtna IP-intervall och routa varningar med hög prioritet till en annan Slack-kanal.

Varför misslyckas min Slack-anslutning i det här workflowet?

Oftast beror det på att Slack OAuth-credentials har gått ut eller att boten inte har bjudits in till målkanalen. Öppna Slack-noden, koppla om kontot och bekräfta att kanal-ID:t inte har ändrats. Om det bara fallerar på stressiga dagar, kontrollera om din workspace har rate limits för meddelanden eller om workflowet postar i en tajt loop på grund av upprepade webhook-retries.

Hur många inloggningshändelser kan den här automatiseringen för Slack Gmail alerts hantera?

Många, så länge dina API:er och din databas hänger med.

Är den här automatiseringen för Slack Gmail alerts bättre än att använda Zapier eller Make?

För det här användningsfallet är n8n oftast en bättre match eftersom du kan köra tre berikningsgrenar parallellt, slå ihop dem och sedan förgrena igen baserat på risksignaler utan att betala extra för varje ”steg”. Self-hosting spelar också roll i SecOps, eftersom du kanske inte vill att känslig inloggningskontext ska gå via en tredjepartsleverantör av automation. Zapier eller Make kan fortfarande fungera om du bara vill ha en enkel ”inloggningshändelse → Slack-meddelande”-pipeline, men det är den stökiga varianten du troligen försöker komma bort från. Om du vill ha hjälp att välja, prata med en automatiseringsexpert så tar vi fram det billigaste och säkraste alternativet för din volym.

När det här väl rullar slutar dina varningar att vara avbrott och börjar bli beslut. Workflowet sköter de repetitiva uppslagningarna, så att du kan fokusera på respons och förebyggande.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

Våra tjänster Om Node Nordic
×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Kopiera och importera JSON-arbetsflödet i ditt n8n-arbetsflöde