DMARC og kryptering løser forskellige e-mail-risici. DMARC hjælper et modtagende system med at vurdere, om et domæne bliver brugt gennem en justeret, autentificeret sti. Kryptering beskytter meddelelsesdata på tværs af et transporthop eller, med et andet design, mellem meddelelsesendepunkter. Ingen af styringerne forsyner automatisk den anden.
Denne sondring er vigtig, fordi den samme meddelelse kan godkendes og stadig rejse uden den transportforsikring, du havde til hensigt. En besked kan også rejse over en krypteret forbindelse, mens den gør krav på et From-domæne, der ikke har nogen tilpasset godkendelse.
Start med beskyttelsesspørgsmålet
Spørg, hvad der skal beskyttes, før du vælger kontrol:
- Beskyttelsesspørgsmål: Er et passerende godkendt domæne justeret med domænet i From?; Relevant mekanisme: DMARC med SPF eller DKIM; Hvad det ikke fastslår: Fortrolighed, afsenderens hensigt eller sikkert indhold
- Beskyttelsesspørgsmål: Blev meddelelsen underskrevet af en indehaver af en privat DKIM nøgle til d=-domænet?; Relevant mekanisme: DKIM ; Hvad det ikke fastslår: Menneskelig identitet, hemmeligholdelse eller indbakkeplacering
- Beskyttelsesspørgsmål: Var dette SMTP leveringshop påkrævet for at bruge acceptabel TLS ?; Relevant mekanisme: MTA-STS eller en anden transportpolitik; Hvad det ikke fastslår: End-to-end fortrolighed eller Fra-domæne justering
- Beskyttelsesspørgsmål: Kan en modtager dekryptere indhold beregnet til den pågældende modtager?; Relevant mekanisme: Kryptering på meddelelsesniveau; Hvad den ikke etablerer: DMARC -justering, medmindre den er konfigureret separat
Denne matrix beskriver kontrolgrænser, ikke en produktrangering. En komplet arkitektur kan bruge mere end én mekanisme, fordi truslerne ikke er udskiftelige.
Følg én syntetisk beskedsti
Overvej en fiktiv faktura sendt fra billing@shop.example.com til accounts@buyer.example.org ved direkte SMTP levering. Afsendertjenesten bruger et konvolutdomæne på bounce.mailer.example.net og skilter med d=shop.example.com. Antag en gældende DMARC politik og gennemførte identitetstjek. I dette syntetiske scenarie er afsendelsen MTA opdager og henter en gyldig enforce-mode MTA-STS -politik for det modtagende domæne buyer.example.org fra https://mta-sts.buyer.example.org/.well-known/mta-sts.txt. Den kontrollerer, at den valgte destination, mx1.buyer.example.org , matcher politikken, forbinder og forhandler derefter TLS og validerer MX certifikatet, før meddelelsen overføres.
Under RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2 og RFC 8461 §5, ville de hypotetiske kontroller understøtte disse udsagn:
- DKIM kan levere en tilpasset sti, fordi signaturen verificerer, og dens d=-domæne matcher From-domænet i dette eksempel.
- DMARC kan passere på meddelelsesniveau gennem den tilpassede DKIM sti.
- Det modtagende SMTP hop brugte TLS i overensstemmelse med modtagerdomænets offentliggjorte transportpolitik, forudsat at politikken var gyldig, aktuel og anvendt korrekt.
- Ingen af disse fakta beviser, at fakturaen er ægte, at afsenderens konto ikke blev kompromitteret, eller at alle tidligere og senere kopier af beskeden forbliver krypteret.
Skift nu kun signeringsdomænet til d=mailer.example.net. DKIM kunne stadig bestå, men det ikke-relaterede domæne ville ikke stemme overens med shop.example.com . En TLS-beskyttet leveringshop reparerer ikke denne justeringsfejl.
Hold DKIM -signering og kryptering adskilt
Under RFC 6376 §3.7, DKIM anvender en kryptografisk signatur over udvalgte meddelelsesdata. Verifikatoren bruger en offentlig nøgle, der er offentliggjort for vælger og d= domæne. Signaturen giver bevis for det signerede indhold og underskriftsdomæne. Det skjuler ikke budskabet.
Kryptering har et andet formål. Under RFC 3207 §6, SMTP TLS beskytter data på en forhandlet forbindelse mellem systemer, ikke den fulde ende-til-ende-meddelelsessti. MTA-STS tillader et modtagende domæne at udgive en politik, som kompatible afsendere kan bruge, når de validerer TLS levering til sine MX værter. TLS -rapportering kan give aggregeret feedback om transportfejl under RFC 8460 §4.1, RFC 8460 §4.2 og RFC 8460 §4.3. Disse kontroller gør ikke SMTP mail til et ende-til-ende-krypteret objekt.
Kryptering på meddelelsesniveau er et andet lag, illustreret af S/MIME i RFC 8551 §1 og RFC 8551 §3.3. Det kan beskytte indhold, så kun tiltænkte slutpunkter med passende nøgler kan læse det, men nøgledistribution og certifikatbehandling som f.eks. RFC 8551 §4 sagen. Modtagerkapacitet, gendannelse og arkivadgang kræver også et eksplicit operationelt design. DMARC forbliver en separat vurdering af det synlige From-domæne og tilpasset godkendelse.
Definer hver tillidsbeslutning
En nyttig designpost nævner fire ting for hver kontrol:
- Kontrol: DMARC ; Identitet eller aktiv: Domæne i Fra; Tillidsanker: DNS politik plus tilpasset SPF eller DKIM resultat; Beviser, der skal opbevares: Pålidelig modtagerresultat og gældende politik
- Kontrol: DKIM ; Identitet eller aktiv: Signering af domæne og vælger; Tillidsanker: DNS offentlig nøgle; Bevis, der skal opbevares: Signatur, verifikationsresultat og nøgleregistrering
- Kontrol: MTA-STS ; Identitet eller aktiv: Modtagende domæne og MX transport; Tillidsanker: DNS opdagelse plus HTTPS-politik; Bevis at beholde: Politik-id, hentet politik og leveringsresultat
- Kontrol: Beskedkryptering; Identitet eller aktiv: Modtager- eller slutpunktsnøgler; Tillidsanker: Valgt nøgle- og certifikattillidsmodel; Bevis at beholde: Krypteringstilstand, modtagerkortlægning og nøglelivscyklus
Oversæt ikke disse til et enkelt grønt badge. Hvert svar har en snævrere betydning og en anden fejltilstand.
Kortlæg kontroller til trusler
DMARC kan gøre uautoriseret brug af et beskyttet From-domæne nemmere for deltagende modtagere at identificere og håndtere. Det forhindrer ikke en legitim konto i at blive misbrugt, undersøge, om en betalingsanmodning er sand, eller kryptere gemt post.
TLS kan reducere eksponeringen for passiv aflytning på et beskyttet hop. Det godkender ikke From-domænet. Et system, der forhandler TLS med den forkerte eller ikke-pålidelige destination, har ikke opnået den samme sikkerhed som en policy-håndhævet, valideret forbindelse.
Meddelelseskryptering kan beskytte indhold ud over transportsessionen, afhængigt af dets design. Det skaber ikke i sig selv DMARC -tilpasning, autoriserer en forretningstransaktion eller eliminerer kompromis med slutpunkter.
Byg beviser uden at overkrav
For identitet, indfang en repræsentant modtaget besked og optag Fra, kuvertidentiteten, hvert DKIM d= domæne, rå godkendelsesresultater, justering og DMARC disposition. Til transport skal du beholde MTA-STS politikken, MX omfanget og TLS -rapporteringsbeviset. For beskedkryptering, dokumenter, hvem der har nøgler, hvordan modtagere er tilmeldt, hvad der sker, når en nøgle går tabt, og hvilke systemer der kan få adgang til almindelig tekst.
En laboratorietest skal mærkes som en test. Det beviser ikke, at alle produktionsruter opfører sig identisk. Validere lavvolumentjenester, videresendelsesruter, backup MX værter og mobil- eller arkivadgang, hvor de påvirker kontrolmålet.
Tildel separate ejere og gendannelsesruter
Mail-operationer ejer ofte godkendelse og SMTP transport. Sikkerhedsarkitekturen kan eje politik, trusselsdækning og krypteringsstandarder. Applikationsteams ejer afsendelsesruterne, der genererer forretningsmail. Juridiske teams og journalteams kan påvirke krav til indholdsopbevaring og nøglegendannelse.
Giv hver kontrol en eskaleringsudløser. En tilpasningsregression går til afsenderens ejerskab og postoperationer. En TLS politikfejl går til transport- og DNS ejere. En mistet beskedkrypteringsnøgle går til gendannelsesprocessen for nøglehåndtering. Én generisk "e-mailsikkerhed"-kø skjuler den beslutning, der skal træffes.
Gør købsbeslutningen eksplicit
Inden du godkender et projekt, skal du skrive en sætning for det ønskede resultat. "Reducer uautoriseret brug af vores Fra-domæner" peger mod DMARC og tilpasset godkendelse. "Kræv acceptabel TLS for levering til vores domæne" peger mod transportpolitik. "Hold meddelelsesindhold ulæseligt uden for godkendte slutpunkter" kræver et meddelelseskrypteringsdesign.
Disse resultater kan eksistere side om side. Den vigtige beslutning er at finansiere den manglende beskyttelse i stedet for at antage, at et velkendt e-mail-sikkerhedsakronym dækker identitet, fortrolighed og forretningsmæssig legitimitet på én gang.
Hold konklusionen inden for beviserne
For fakturaopstillingen skal du beholde den vellykkede DKIM justering og validerede SMTP hop i forskellige bevisfelter. Hvis kun d= ændres til det ikke-relaterede udbyderdomæne, mens SPF forbliver ujusteret, opretter TLS stadig ikke en tilpasset identitet. Politikhentningen, TLS forhandlingen og signaturbekræftelsen beskrevet her er antaget undervisningsinput, ikke udførte netværks- eller meddelelsestests.