DMARC ja salaus ratkaisee erilaisia sähköpostiriskejä. DMARC auttaa vastaanottavaa järjestelmää arvioimaan, käytetäänkö toimialuetta kohdistetulla, todennettulla polulla. Salaus suojaa viestidataa siirtohypyn yli tai eri mallilla viestin päätepisteiden välillä. Kumpikaan ohjain ei syötä automaattisesti toista.
Tällä erolla on merkitystä, koska sama viesti voidaan todentaa hyvin ja silti kulkea ilman haluamaasi kuljetustakuuta. Viesti voi kulkea myös salatun yhteyden kautta samalla, kun se vaatii Lähettäjä-toimialueen, jolla ei ole kohdistettua todennusta.
Aloita suojelukysymyksestä
Kysy mitä tulee suojata ennen kuin valitset säätimen:
- Suojauskysymys: Onko ohittava todennettu toimialue linjassa Lähettäjässä olevan toimialueen kanssa?; Asiaankuuluva mekanismi: DMARC kanssa SPF tai DKIM; Mitä se ei osoita: Luottamuksellisuus, lähettäjän tarkoitus tai turvallinen sisältö
- Suojakysymys: Allekirjoittiko viestin d=-verkkotunnuksen yksityisen DKIM avaimen haltija?; Asiaankuuluva mekanismi: DKIM ; Mitä se ei vahvista: Ihmisen identiteetti, salassapito tai postilaatikon sijoittelu
- Suojauskysymys: vaadittiinko tämä SMTP toimitushyppy hyväksyttävän TLS käyttämiseen?; Asiaankuuluva mekanismi: MTA-STS tai muu liikennepolitiikka; Mitä se ei vahvista: Päästä päähän -luottamuksellisuus tai From-domain linjaus
- Suojauskysymys: Voiko vastaanottaja purkaa tälle vastaanottajalle tarkoitetun sisällön salauksen?; Asiaankuuluva mekanismi: Viestitason salaus; Mitä se ei määritä: DMARC kohdistus, ellei sitä ole määritetty erikseen
Tämä matriisi kuvaa kontrollirajoja, ei tuotteen sijoitusta. Täydellinen arkkitehtuuri voi käyttää useampaa kuin yhtä mekanismia, koska uhat eivät ole keskenään vaihdettavissa.
Seuraa yhtä synteettistä viestipolkua
Harkitse kuvitteellista laskua, joka lähetetään osoitteesta billing@shop.example.com osoitteeseen accounts@buyer.example.org suoralla SMTP toimituksella. Lähetyspalvelu käyttää kirjekuoriverkkotunnusta osoitteessa bounce.mailer.example.net ja allekirjoittaa tunnuksella d=shop.example.com. Oletetaan sovellettava DMARC -käytäntö ja suoritettu henkilöllisyystarkastukset. Tässä synteettisessä skenaariossa lähetys MTA löytää ja noutaa voimassa olevan pakottavan MTA-STS -käytännön vastaanottavalle verkkotunnukselle buyer.example.org osoitteesta https://mta-sts.buyer.example.org/.well-known/mta-sts.txt. Se tarkistaa, että valittu kohde mx1.buyer.example.org vastaa käytäntöä, muodostaa sitten yhteyden ja neuvottelee TLS ja vahvistaa MX -varmenteen ennen viestin siirtämistä.
Under RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2 ja RFC 8461 §5, hypoteettiset kontrollit tukisivat näitä väitteitä:
- DKIM voi tarjota tasaisen välityspolun, koska allekirjoitus vahvistaa ja sen d=-verkkoalue vastaa tämän esimerkin From-toimialuetta.
- DMARC voi kulkea viestitasolla saman DKIM polun kautta.
- Vastaanottava SMTP hyppy käytti TLS vastaanottajan toimialueen julkaistun siirtokäytännön mukaisesti olettaen, että käytäntö oli kelvollinen, ajan tasalla ja sitä sovellettiin oikein.
- Mikään näistä tosiasioista ei todista, että lasku on aito, että lähettäjän tili ei ole vaarantunut tai että viestin jokainen edellinen ja myöhempi kopio säilyy salattuna.
Muuta nyt vain allekirjoitustoimialue muotoon d=mailer.example.net. DKIM voi silti läpäistä, mutta tämä riippumaton verkkotunnus ei ole sama kuin shop.example.com . TLS-suojattu toimitushyppy ei korjaa kohdistusvirhettä.
Pidä DKIM -allekirjoitus ja -salaus erillään
Under RFC 6376 §3.7, DKIM käyttää kryptografista allekirjoitusta valittuihin viestitietoihin. Todentaja käyttää julkista avainta, joka on julkaistu valitsin ja d = verkkotunnus. Allekirjoitus antaa todisteita allekirjoitetusta sisällöstä ja allekirjoitusalueesta. Se ei peitä viestiä.
Salauksella on eri tarkoitus. Under RFC 3207 §6SMTP TLS suojaa järjestelmien välisen neuvotellun yhteyden tietoja, ei koko päästä päähän -viestipolkua. MTA-STS sallii vastaanottavan toimialueen julkaista käytännön, jota yhteensopivat lähettäjät voivat käyttää vahvistaessaan TLS toimituksen sen MX isäntäkoneilleen. TLS -raportointi voi antaa koottua palautetta alla olevista kuljetushäiriöistä RFC 8460 §4.1, RFC 8460 §4.2 ja RFC 8460 §4.3. Nämä säätimet eivät muuta SMTP postia päästä päähän -salatuksi objektiksi.
Viestitason salaus on toinen kerros, jota havainnollistaa S/MIME in RFC 8551 §1 ja RFC 8551 §3.3. Se voi suojata sisältöä siten, että vain tarkoituksenmukaiset päätepisteet, joilla on sopivat avaimet, voivat lukea sitä, mutta avainten jakelu ja varmenteiden käsittely, kuten RFC 8551 §4 asia. Vastaanottajan ominaisuudet, palautus ja arkiston käyttö edellyttävät myös selkeää toiminnallista suunnittelua. DMARC on edelleen erillinen arvio näkyvästä From-toimialueesta ja kohdistetusta todennusta.
Määrittele jokainen luottamuspäätös
Hyödyllinen suunnittelutietue nimeää neljä asiaa jokaiselle säätimelle:
- Ohjaus: DMARC ; Identiteetti tai omaisuus: Domain in From; Luottamusankkuri: DNS käytäntö sekä kohdistettu SPF tai DKIM tulos; Säilytettävät todisteet: Luotettava vastaanottimen tulos ja sovellettava käytäntö
- Ohjaus: DKIM ; Identiteetti tai omaisuus: Allekirjoitusverkkotunnus ja valitsin; Luottamusankkuri: DNS julkinen avain; Säilytettävät todisteet: Allekirjoitus, varmistustulos ja avaintietue
- Ohjaus: MTA-STS ; Identiteetti tai omaisuus: vastaanottava verkkotunnus ja MX -siirto; Luottamusankkuri: DNS etsintä ja HTTPS-käytäntö; Säilytettävät todisteet: Vakuutustunnus, haettu käytäntö ja toimitustulos
- Ohjaus: Viestin salaus; Identiteetti tai omaisuus: vastaanottajan tai päätepisteen avaimet; Luottamusankkuri: Valittu avain ja varmenteen luottamusmalli; Säilytettävät todisteet: Salauksen tila, vastaanottajan kartoitus ja avaimen elinkaari
Älä käännä näitä yhdeksi vihreäksi tunnukseksi. Jokaisella vastauksella on kapeampi merkitys ja erilainen vikatila.
Kartoita ohjaimet uhkiin
DMARC voi helpottaa suojatun From-verkkotunnuksen luvatonta käyttöä osallistuvien vastaanottajien tunnistamista ja käsittelyä varten. Se ei estä laillisen tilin väärinkäyttöä, tarkista, onko maksupyyntö totta, tai salaa tallennettua postia.
TLS voi vähentää altistumista passiiviselle sieppaukselle suojatussa hyppyssä. Se ei todenna Lähettäjä-toimialuetta. Järjestelmä, joka neuvottelee TLS väärän tai epäluotettavan kohteen kanssa, ei ole saavuttanut samaa varmuutta kuin käytännön pakotettu, vahvistettu yhteys.
Viestin salaus voi suojata sisältöä siirtoistunnon jälkeen sen suunnittelusta riippuen. Se ei itsessään luo DMARC kohdistusta, valtuuta liiketapahtumaa tai poista päätepisteen vaarantumista.
Rakenna todisteita liioittelematta
Identiteettiä varten kaappaa edustava vastaanotettu viesti ja tallenna Lähettäjä, kirjekuoren identiteetti, jokainen DKIM d= -toimialue, raakatodennuksen tulokset, kohdistus ja DMARC sijoitus. Säilytä kuljetuksen osalta MTA-STS -käytäntö, MX alue ja TLS raportointitodisteet. Viestin salausta varten dokumentoi, kuka omistaa avaimet, kuinka vastaanottajat rekisteröidään, mitä tapahtuu, kun avain katoaa ja mitkä järjestelmät voivat käyttää selkeää tekstiä.
Laboratoriotesti tulee merkitä testiksi. Se ei todista, että jokainen tuotantoreitti käyttäytyy samalla tavalla. Vahvista vähäiset palvelut, edelleenlähetysreitit, vara- MX isännät ja mobiili- tai arkiston käyttö, jos ne vaikuttavat ohjaustavoitteeseen.
Määritä erilliset omistajat ja palautusreitit
Postitoiminnot omistavat usein todennuksen ja SMTP -kuljetuksen. Suojausarkkitehtuurilla voi olla käytäntöjä, uhkien kattavuutta ja salausstandardeja. Sovellustiimit omistavat lähetysreitit, jotka luovat yrityspostia. Laki- ja rekisteritiimit voivat vaikuttaa sisällön säilyttämis- ja avainten palautusvaatimuksiin.
Anna kullekin ohjaukselle eskalaatiolaukaisin. Tasoitusregressio menee lähettäjän omistajuuteen ja postitoimintoihin. TLS -käytännön virhe kohdistuu kuljetus- ja DNS omistajiin. Kadonnut viestin salausavain siirtyy avaintenhallinnan palautusprosessiin. Yksi yleinen "sähköpostin suojaus" -jono piilottaa päätöksen, joka on tehtävä.
Tee ostopäätös selkeästi
Ennen kuin hyväksyt projektin, kirjoita yksi lause vaaditusta tuloksesta. "Vähennä From-verkkotunnustemme luvatonta käyttöä" viittaa kohti DMARC ja yhdenmukaistettua todennusta. "Edellytä hyväksyttävää TLS :ää toimitettavaksi verkkotunnukseemme" viittaa kuljetuskäytäntöön. "Pidä viestin sisältö lukukelvottomana hyväksyttyjen päätepisteiden ulkopuolella" edellyttää viestin salaussuunnittelua.
Nämä tulokset voivat esiintyä rinnakkain. Tärkeä päätös on rahoittaa puuttuva suoja sen sijaan, että tuttu sähköpostin turvalyhenne kattaisi henkilöllisyyden, luottamuksellisuuden ja liiketoiminnan legitiimiyden kerralla.
Pidä johtopäätös todisteiden sisällä
Säilytä laskun onnistunut DKIM kohdistus ja validoitu SMTP hyppy eri todistekentissä. Jos vain d= muuttuu riippumattomaan palveluntarjoajan toimialueeseen, kun SPF pysyy tasaamattomana, TLS ei silti luo tasattua identiteettiä. Tässä kuvatut käytäntöjen haku, TLS -neuvottelu ja allekirjoituksen vahvistus ovat oletettuja opetussyötteitä, ei suoritettuja verkko- tai viestitestejä.