Mappa le decisioni effettivamente prese dai sistemi di posta
Un'utile mappa delle dipendenze della posta elettronica collega un servizio di invio aziendale alle identità, ai record DNS e ai servizi di trasporto che utilizza. Un elenco di tutti registrazione TXT non è abbastanza La mappa dovrebbe consentire al proprietario di rispondere a cosa potrebbe interrompersi se un provider, un nome host, una chiave o una policy cambiano e identificare le prove necessarie prima di approvare tale modifica.
Mantieni l'autenticazione dell'identità in uscita e la politica di trasporto in entrata come rami separati. Possono condividere amministratori e domini, ma non proteggono la stessa decisione. La mappa qui proposta è un modello operativo che un'organizzazione deve popolare a partire dal proprio inventario autorizzato e dalle prove dei messaggi. Non si afferma che una scansione DNS possa scoprire ogni mittente o determinare il comportamento di tutto il destinatario.
Inizia ogni ramo in uscita con un percorso di invio reale
Creare una voce per ciascun servizio e percorso materialmente distinto, inclusa la fatturazione periodica, i sistemi di supporto e le campagne gestite esternamente. Registra il proprietario dell'azienda, il proprietario tecnico, il dominio dell'autore visibile, il dominio della busta, l'infrastruttura di invio e l'osservazione DKIM dominio di firma e selettore. Contrassegna ciascun valore come osservato, documentato dal fornitore o ancora sconosciuto. Non trasformare la guida di configurazione generica di un fornitore in una prova della configurazione di questo account.
IL SPF branch inizia con l'identità valutata e segue i termini della policy effettivamente rilevanti per quel percorso. Includere riferimenti a politiche esterne e i team che li controllano. RFC 7208 sezioni 2.3 e 4.6.4 spiegare la valutazione dell'identità e i limiti dipendenti dal DNS. Una mappa dipendente può mostrare dove le modifiche esterne potrebbero influenzare la valutazione, ma un conteggio statico dei nodi non stabilisce il risultato per ogni indirizzo di connessione.
Il ramo DKIM inizia con i valori d e s della firma e porta al record di verifica del selezionatore. Aggiungi qualsiasi destinazione alias, proprietario della zona di destinazione e proprietario del ciclo di vita della chiave. RFC 6376 sezione 3.6.2.1 definisce questo spazio dei nomi di ricerca. Tieni le chiavi private fuori dalla mappa; registrare la proprietà operativa sicura e fare invece riferimento a un sistema di gestione delle chiavi approvato.
Connetti l'autenticazione alla decisione DMARC pertinente
Aggiungi il dominio dell'autore, applicabile DMARC la documentazione politica e le prove di come la politica è stata scoperta. Collega il passaggio di identificatori autenticati al file allineamento decisione, con modalità rigorosa o rilassata identificata. Sotto RFC 9989 sezione 4.4, un identificatore SPF o DKIM allineato valido può soddisfare DMARC ; due passaggi di autenticazione non correlati non possono stabilire l'allineamento.
Registrare le specifiche e il contesto di implementazione utilizzati per la valutazione dell'individuazione delle politiche. RFC 9989 descrive a Passeggiata sull'albero DNS, quindi un'ipotesi ereditata dal foglio di calcolo relativa alla scoperta dovrebbe essere rivista anziché portata avanti silenziosamente. La mappa dovrebbe mantenere l'incertezza sui ricevitori la cui implementazione non è stata verificata. Includi le destinazioni della segnalazione e la loro proprietà, ma mantieni la disponibilità della segnalazione separata dalla prova che ogni mittente legittimo è stato osservato.
Mostra la politica richiesta dal proprietario e la gestione osservata dal destinatario in diversi campi. Ciò rende più difficile per un futuro revisore confondere una stringa di policy con la prova che un messaggio è stato rifiutato, consegnato o inserito in una casella di posta.
Aggiungi il ramo di trasporto indipendente
Per la posta in entrata, collega il dominio del destinatario ai suoi host MX e alle relative dipendenze di indirizzo. Se MTA-STS viene distribuito, aggiungere il record TXT di rilevamento, l'host dei criteri HTTPS, il proprietario della manutenzione del certificato, la modalità pubblicata, i nomi MX consentiti e la durata dei criteri. RFC 8461 sezioni 3 e 6 descrivere il rilevamento e la memorizzazione nella cache. La durata della policy non è lo stesso campo del DNS TTL e la modifica di una non riscrive direttamente l'altra.
Dove DANE SMTP è distribuito, mappa il file DNSSEC catena, risoluzione MX , TLSA record e il corrispondente servizio TLS . RFC 7672 sezione 2 rende DNS autenticato una dipendenza centrale. Un record TLSA copiato nell'inventario senza la relativa relazione di convalida e certificato costituisce una prova operativa incompleta.
Aggiungere la segnalazione TLS come canale di osservazione, non come meccanismo di applicazione. RFC 8460 sezione 3 definisce l'individuazione delle politiche di reporting. La destinazione del reporting necessita di un proprietario e di un processo di revisione, mentre l’effettiva politica dei trasporti rimane una dipendenza distinta.
Esempio immaginario di migrazione di un provider
L'organizzazione fittizia Esempio Riparazioni prevede di spostare la posta delle fatture a un nuovo fornitore. La mappa proposta collega il servizio di fatturazione a billing.example.com come dominio dell'autore, un dominio busta separato e un vecchio selettore DKIM ospitato tramite un alias. Il proprietario della migrazione nota che il provider ritirato controlla ancora la destinazione dell'alias e che alcuni messaggi in coda potrebbero contenere la vecchia firma.
La revisione propone quindi un cambio graduale della segnaletica, la verifica del percorso sostitutivo e una decisione di pensionamento approvata separatamente. Nel frattempo, le voci MX e MTA-STS in entrata rimangono un ramo diverso e non vengono modificate automaticamente come parte di uno spostamento del fornitore in uscita. Questo esempio è inventato; le identità, le approvazioni e i risultati dei messaggi non sono stati ottenuti da un account reale.
Il vantaggio della mappa è la domanda che pone: quali prove consentono di ritirare quell'alias senza interrompere la verifica dei messaggi legittimi? La mappa stessa non risponde. Il proprietario del servizio deve fornire informazioni sulla coda e sulla firma e il revisore deve collegare tali fatti alla modifica proposta.
Mantieni prove e proprietà con la mappa
Assegna a ciascun bordo la data dell'ultima verifica, il riferimento alle prove, il proprietario e l'attivatore della revisione. Rivisitalo dopo la migrazione di un fornitore, una rotazione del selettore, una modifica della delega, una modifica della politica di trasporto o un errore di autenticazione inspiegabile. I proprietari sconosciuti e i bordi non verificati dovrebbero rimanere visibili anziché essere pieni di ipotesi.
Prima dell'implementazione, crea la matrice di preparazione mittente per mittente, l'esatta differenza di policy e il record di approvazione. Dopo l'esecuzione autorizzata, allegare il messaggio pertinente e le osservazioni DNS . Questi sono gli artefatti originali richiesti dal catalogo e rimangono aperti qui. Questo manoscritto fornisce un progetto di mappa e un esercizio decisionale fittizio, non un inventario popolato degli inquilini o un'implementazione verificata.