A vælger monitor kan fortælle dig, at verifikationsdata er ændret eller forsvundet. Den kan ikke fastslå, at en tjeneste stadig sender, at dens private nøgle matcher den offentliggjorte nøgle, eller at dens meddelelser ankommer med aligned DKIM. Byg separate kontroller for offentliggjort konfiguration og observeret meddelelsesadfærd.
Start med kendte afsendelsesruter
Opret en beholdning fra autoriseret afsenderkonfiguration og repræsentanter modtagne beskeder. For hver rutepost skal virksomhedens ejer, d-domæne, vælger, DNS ejer, forventet TXT eller CNAME arrangement, sidst observerede signeringstid og livscyklustilstand. Antag ikke, at gættende almindelige vælgere opdager hver underskriver. DKIM leverer vælgeren i hver signatur i stedet for at definere en komplet DNS opregningstjeneste.
For en signatur, der bruger s=invoice2 og d=brand.example, skal du inspicere invoice2._domainkey.brand.example under RFC 6376 §3.6.2.1. Følg en forventet CNAME til dens bekræftelsesdata. Gem et observationstidsstempel og et offentligt nøglefingeraftryk, så en ændring kan sammenlignes med en godkendt rotation. Saml aldrig private nøgler i overvågningssystemet.
Adskil monitorens resultater
Et manglende svar, DNS timeout, tilbagekaldt nøgle og ændret nøgle er forskellige hændelser. RFC 6376 §6.1.2 skelner nøgleforespørgselsfejl fra en fraværende nøgle, og en tom p-værdi repræsenterer tilbagekaldelse under RFC 6376 §3.6.1. Registrer svardetaljer i stedet for at oversætte hver fejl til en generisk fejl.
En nuværende nøgle har stadig brug for syntaks- og algoritmetjek. RFC 8301 §3.1 forbyder rsa-sha1-signering og verifikation; RFC 8301 §3.2 opdaterer krav til RSA-størrelse: underskrivere skal bruge mindst 1024 bit og skal bruge mindst 2048. Produktsupport og nuværende organisatoriske kryptografiske politik kan være strengere. En ændring af fingeraftryk kan ikke alene fortælle dig, om en rotation var godkendt.
Tilføj en levende bevisløkke
Send kontrollerede beskeder gennem hver vigtig produktionsrute til en postkasse, hvis rå besked og pålidelige godkendelsesresultat du kan inspicere. Registrer de observerede d og s, verifikationsresultat og justering med Fra. Træn de budskabsvarianter, som downstream-behandling kan påvirke, såsom HTML og vedhæftede filer.
Illustrativ monitor: DNS fortsætter med at betjene faktura2, men en ny besked indeholder nej DKIM-Signature. Udgivelseskontrollen består, mens underskriftskontrollen mislykkes. I et andet tilfælde eksisterer signaturen, men dens kropshash fejler efter et skift af gateway-sidefod. Ingen af hændelserne løses ved at erklære DNS posten for sund. Disse er syntetiske testcases, ikke målte servicehændelser.
Syntetiske tests har også grænser. En daglig probe beviser ikke alle meddelelser mellem prober, der sendes. Kombiner det med modtagerrapporter og hændelsesbeviser, mens du anerkender rapporteringsdækning og forsinkelse.
Rut handlingsrettede advarsler
Vedhæft advarsler til en rute og ejer. Undertrykk kun et eksplicit godkendt vedligeholdelsesvindue, bevar hændelseshistorikken og bekræft den nye underskriver med frisk mail efter rotation. Eskaler uventede nøgleændringer som mulige sikkerhedshændelser uden at erklære kompromis fra en ændring alene.
Træk forældede lagerrækker tilbage med vilje. En gammel offentlig nøgle kan forblive til forsinket meddelelsesverifikation, selv når ny signering er stoppet. Skelne den planlagte tilstand fra en forladt delegation. Dashboardet skal sige, hvad der blev observeret, hvornår og med hvilken metode, så DNS sundhed aldrig forklæder sig som bevis for live-signering.
Gengiv advarselsbeslutningen
Brug fire syntetiske prober til at holde advarselslagene adskilt. En signatur med d=brand.example og s=invoice2 er knyttet til invoice2._domainkey.brand.example . Hvis dens offentlige nøgle er til stede, men det leverede modtagerresultat er en body-hash-fejl, skal du oprette en besked-bekræftelsesadvarsel. Hvis dens nøgle er fraværende, skal du lave en alarm om nøglefravær. Hvis den forventede post er til stede, men meddelelsen ikke har nogen signatur, skal du lave en advarsel om manglende underskrift. En tilstedeværende nøgle plus et leveret bestået resultat giver ingen advarsel for den pågældende sonde alene.
Disse fire beslutninger er en illustrativ beslutningsmodel med opfundne DNS tilstande og leverede modtagerresultater. Der blev ikke udført nogen live DNS forespørgsel, signeringstest eller kryptografisk verifikation til denne gennemgang. For at idriftsætte monitoren skal du erstatte dem med daterede offentlige svar og rå beskeder, der bærer resultater fra din betroede modtagegrænse. Bevar det forbundne bevis, før du beskriver en rute som operationelt verificeret.
Beviser nødvendig for den næste beslutning
For en body-hash-advarsel skal du bevare det leverede resultat og undersøge kropsrepræsentation, c/l-indstillinger, bh-værdi og implementeringsadfærd; et mismatch alene beviser ikke et gateway-modificeret indhold. Marker en rute uden ny sonde som uobserveret, selvom dens nøgle er til stede. Registrer særskilt, om justering blev kontrolleret, da DKIM pass alene ikke er aligned pass.