DMARC e la crittografia risolvono diversi rischi legati alla posta elettronica. DMARC aiuta un sistema ricevente a valutare se un dominio viene utilizzato attraverso un percorso allineato e autenticato. La crittografia protegge i dati dei messaggi attraverso un hop di trasporto o, con una progettazione diversa, tra gli endpoint del messaggio. Nessuno dei due controlli fornisce automaticamente l'altro.
Questa distinzione è importante perché lo stesso messaggio può essere ben autenticato e continuare a viaggiare senza la garanzia di trasporto prevista. Un messaggio può anche viaggiare su una connessione crittografata rivendicando un dominio Da che non ha un'autenticazione allineata.
Cominciamo dalla questione della protezione
Chiedere cosa deve essere protetto prima di selezionare il controllo:
- Domanda di protezione: un dominio autenticato di passaggio è allineato con il dominio in Da?; Meccanismo rilevante: DMARC con SPF O DKIM; Cosa non stabilisce: riservatezza, intenzione del mittente o contenuto sicuro
- Domanda di protezione: il messaggio è stato firmato da un titolare di una chiave privata DKIM per il dominio d=?; Meccanismo rilevante: DKIM ; Cosa non stabilisce: identità umana, segretezza o posizionamento nella casella di posta
- Domanda di protezione: era necessario questo hop di consegna SMTP per utilizzare TLS accettabile?; Meccanismo rilevante: MTA-STS o un'altra politica dei trasporti; Cosa non stabilisce: riservatezza end-to-end o From-domain allineamento
- Domanda di protezione: un destinatario può decrittografare il contenuto destinato a quel destinatario?; Meccanismo rilevante: crittografia a livello di messaggio; Cosa non stabilisce: allineamento DMARC se non configurato separatamente
Questa matrice descrive i limiti di controllo, non una classificazione del prodotto. Un'architettura completa può utilizzare più di un meccanismo perché le minacce non sono intercambiabili.
Segui un percorso di messaggio sintetico
Considera una fattura fittizia inviata da billing@shop.example.com accounts@buyer.example.org tramite consegna SMTP diretta. Il servizio di invio utilizza un dominio busta su bounce.mailer.example.net e firma con d=shop.example.com. Presupporre una policy DMARC applicabile e controlli di identità completati. In questo scenario sintetico, l'invio MTA rileva e recupera una policy MTA-STS in modalità di applicazione valida per il dominio ricevente buyer.example.org da https://mta-sts.buyer.example.org/.well-known/mta-sts.txt. Verifica che la destinazione selezionata, mx1.buyer.example.org , corrisponda alla policy, quindi si connette e negozia TLS , convalidando il certificato MX prima di trasferire il messaggio.
Sotto RFC 8461 §3.3, RFC 8461 §4.1, RFC 8461 §4.2 E RFC 8461 §5, i controlli ipotetici sosterrebbero queste affermazioni:
- DKIM può fornire un percorso di passaggio allineato perché la firma viene verificata e il relativo dominio d= corrisponde al dominio Da in questo esempio.
- DMARC può passare a livello di messaggio attraverso il percorso DKIM allineato.
- L'hop SMTP ricevente utilizzava TLS in conformità con la politica di trasporto pubblicata del dominio ricevente, presupponendo che la politica fosse valida, attuale e applicata correttamente.
- Nessuno di questi fatti dimostra che la fattura sia autentica, che l'account del mittente non sia stato compromesso o che ogni copia precedente e successiva del messaggio rimanga crittografata.
Ora cambia solo il dominio della firma in d=mailer.example.net. DKIM potrebbe comunque passare, ma il dominio non correlato non si allineerebbe a shop.example.com . Un hop di consegna protetto da TLS non ripara tale errore di allineamento.
Mantieni la firma DKIM e la crittografia separate
Sotto RFC 6376 §3.7, DKIM applica una firma crittografica sui dati dei messaggi selezionati. Il verificatore utilizza una chiave pubblica pubblicata per il selettore e d= dominio. La firma fornisce prova del contenuto firmato e del dominio di firma. Non nasconde il messaggio.
La crittografia ha uno scopo diverso. Sotto RFC 3207 §6, SMTP TLS protegge i dati su una connessione negoziata tra sistemi, non sull'intero percorso del messaggio end-to-end. MTA-STS consente a un dominio ricevente di pubblicare una policy che i mittenti conformi possono utilizzare durante la convalida della consegna TLS ai propri host MX . I report TLS possono fornire feedback aggregato sugli errori di trasporto di seguito RFC 8460 §4.1, RFC 8460 §4.2 E RFC 8460 §4.3. Questi controlli non trasformano la posta SMTP in un oggetto crittografato end-to-end.
La crittografia a livello di messaggio è un altro livello, illustrato da S/MIME in RFC 8551 §1 E RFC 8551 §3.3. Può proteggere il contenuto in modo che solo gli endpoint previsti con chiavi adeguate possano leggerlo, ma la distribuzione delle chiavi e l'elaborazione dei certificati come RFC 8551 §4 questione. Anche la funzionalità dei destinatari, il ripristino e l'accesso agli archivi richiedono una progettazione operativa esplicita. DMARC rimane una valutazione separata del dominio Da visibile e dell'autenticazione allineata.
Definire ogni decisione di fiducia
Un utile record di progettazione nomina quattro cose per ogni controllo:
- Controllo: DMARC ; Identità o asset: Dominio in Da; Ancoraggio di fiducia: politica DNS più risultato SPF o DKIM allineato; Prove da conservare: risultato del destinatario affidabile e politica applicabile
- Controllo: DKIM ; Identità o risorsa: dominio di firma e selettore; Trust Anchor: chiave pubblica DNS ; Prove da conservare: firma, risultato della verifica e registrazione della chiave
- Controllo: MTA-STS ; Identità o risorsa: dominio di ricezione e trasporto MX ; Trust Anchor: rilevamento DNS più policy HTTPS; Prove da conservare: ID polizza, polizza recuperata e risultato della consegna
- Controllo: crittografia dei messaggi; Identità o risorsa: chiavi del destinatario o dell'endpoint; Trust Anchor: chiave scelta e modello di attendibilità del certificato; Prove da conservare: stato della crittografia, mappatura dei destinatari e ciclo di vita della chiave
Non tradurli in un unico badge verde. Ogni risposta ha un significato più ristretto e una diversa modalità di fallimento.
Associa i controlli alle minacce
DMARC può rendere più semplice l'identificazione e la gestione dell'uso non autorizzato di un dominio protetto da parte dei ricevitori partecipanti. Non impedisce l'uso improprio di un account legittimo, né verifica se una richiesta di pagamento è vera, né crittografa la posta archiviata.
TLS può ridurre l'esposizione all'intercettazione passiva su un hop protetto. Non autentica il dominio Da. Un sistema che negozia TLS con la destinazione sbagliata o non attendibile non ha ottenuto la stessa garanzia di una connessione convalidata e applicata tramite policy.
La crittografia dei messaggi può proteggere il contenuto oltre la sessione di trasporto, a seconda della sua progettazione. Di per sé non crea l'allineamento DMARC , non autorizza una transazione commerciale né elimina la compromissione degli endpoint.
Costruisci prove senza esagerare
Per l'identità, acquisire un messaggio ricevuto da un rappresentante e registrare Da, l'identità della busta, ciascun dominio DKIM d=, i risultati dell'autenticazione non elaborata, l'allineamento e la disposizione DMARC . Per il trasporto, conservare la policy MTA-STS , l'ambito MX e le prove di reporting TLS . Per la crittografia dei messaggi, documentare chi detiene le chiavi, come vengono registrati i destinatari, cosa succede quando una chiave viene persa e quali sistemi possono accedere al testo in chiaro.
Un test di laboratorio dovrebbe essere etichettato come test. Ciò non dimostra che ogni percorso di produzione si comporti in modo identico. Convalida servizi a basso volume, percorsi di inoltro, host MX di backup e accesso mobile o di archivio laddove influiscono sull'obiettivo di controllo.
Assegna proprietari e percorsi di ripristino separati
Le operazioni di posta spesso possiedono l'autenticazione e il trasporto SMTP . L’architettura di sicurezza può possedere policy, copertura delle minacce e standard di crittografia. I team delle applicazioni possiedono i percorsi di invio che generano la posta aziendale. I team legali e di documentazione possono influenzare i requisiti di conservazione dei contenuti e di ripristino delle chiavi.
Assegna a ciascun controllo un trigger di escalation. Una regressione di allineamento riguarda la proprietà del mittente e le operazioni di posta. Un errore della policy TLS va a carico dei proprietari di trasporto e DNS . Una chiave di crittografia dei messaggi perduta viene inviata al processo di ripristino della gestione delle chiavi. Una coda generica di "sicurezza e-mail" nasconde la decisione da prendere.
Rendi esplicita la decisione di acquisto
Prima di approvare un progetto, scrivi una frase per il risultato richiesto. "Ridurre l'uso non autorizzato dei nostri domini From" punta verso DMARC e l'autenticazione allineata. "Richiedi TLS accettabile per la consegna al nostro dominio" punta alla politica dei trasporti. "Mantieni il contenuto dei messaggi illeggibile all'esterno degli endpoint approvati" richiede una progettazione di crittografia dei messaggi.
Questi risultati possono coesistere. La decisione importante è quella di finanziare la protezione mancante piuttosto che dare per scontato che un acronimo familiare di sicurezza e-mail copra allo stesso tempo identità, riservatezza e legittimità aziendale.
Mantieni la conclusione all'interno delle prove
Per il fissaggio della fattura, mantenere l'allineamento DKIM riuscito e l'hop SMTP convalidato in diversi campi di prova. Se solo d= passa al dominio del provider non correlato mentre SPF rimane non allineato, TLS continua a non creare un'identità allineata. Il recupero delle policy, la negoziazione TLS e la verifica della firma qui descritti sono presupposti come input didattici, non come test di rete o di messaggi eseguiti.