Definire prima la domanda e il destinatario
Un fornitore potrebbe aver bisogno di prove per diagnosticare un problema di firma, un allineamento mancata corrispondenza o discrepanza nei rapporti. Raramente necessita di ogni report per ogni dominio dell'organizzazione. Inizia affermando la domanda esatta, il prodotto e l'account coinvolti, il destinatario previsto e quale decisione le prove dovrebbero consentire. Ciò impedisce una richiesta per “the DMARC dati” di diventare una divulgazione inutilmente ampia.
Confermare che il destinatario sia il supporto autorizzato o il contatto tecnico per il servizio in questione. Un nome visualizzato familiare o una richiesta inoltrata non è sufficiente per stabilire che ogni allegato debba essere inviato lì. La stesura di un pacchetto è separata dall'autorizzazione a trasmetterlo. Questo articolo descrive solo la preparazione e non autorizza un'e-mail, un caricamento o una condivisione esterna.
Mantieni l'ambito legato al percorso e all'intervallo interessati. Un fornitore che esamina il proprio flusso di lavoro di ricezione non dovrebbe ricevere posta non correlata dai dipendenti, traffico di marketing o altro fornitore semplicemente perché tali osservazioni occupano lo stesso file aggregato.
Comprendi cosa può rivelare il rapporto
Rapporti aggregati contenere osservazioni tecniche e informazioni politiche che possono rivelare aspetti dell'infrastruttura e del traffico del mittente. RFC 9990 discute considerazioni sulla privacy per i destinatari e riporta i dati. Anche quando un campo non è il corpo del messaggio, potrebbe comunque non essere necessario per l'attività del fornitore. Trattare la minimizzazione come una decisione campo per campo piuttosto che dare per scontato che tutte le informazioni aggregate siano innocue.
Rapporti di fallimento avere una superficie di esposizione separata e potenzialmente più dettagliata sotto RFC 9991. Non raggrupparli con riepiloghi aggregati sotto un'approvazione generica per i "rapporti". Identificare esplicitamente il tipo di report, il contenuto e lo scopo del destinatario. Se è possibile rispondere a una domanda diagnostica con un riassunto più piccolo o un estratto redatto, preferirlo a un manufatto grezzo completo. RFC 9990 , sezione 7.1 e 7.2; RFC 9991 , sezione 7.1 e 7.2
Costruisci una mappa dei campi dati prima della redazione
La mappa del campo dovrebbe elencare ciascun elemento candidato, il motivo per cui è necessario, se è necessario un valore esatto, il trattamento proposto e le conseguenze della sua rimozione. Gli elementi potenziali includono il dominio Da, il dominio di firma, selettore, dominio della busta, indirizzo di origine, intervallo di report, conteggio e risultato della valutazione. La loro necessità dipende dalla domanda; non esiste un pacchetto universale che dovrebbe essere sempre inviato.
Potrebbero essere necessarie alcune identità tecniche esatte per diagnosticare l'allineamento o individuare una configurazione specifica dell'account. Se tali valori non possono essere condivisi nell’ambito approvato, spiegare la limitazione diagnostica anziché sostituirli con valori fuorvianti. Altri identificatori possono essere rimossi o pseudonimizzati in modo coerente preservando le relazioni. Mantieni una mappatura privata solo quando necessario e autorizzato e non includerla nel pacchetto del fornitore per impostazione predefinita.
Rimuovi righe e domini non correlati, indirizzi di destinatari non necessari, contenuto dei messaggi, note interne e segreti. Non includere mai password, chiavi API, token di sessione o credenziali in un artefatto di supporto. Controlla nomi di file, metadati, schermate e contenuti nascosti del foglio di calcolo, nonché testo visibile; un paragrafo redatto non garantisce che l'allegato sia ridotto a icona.
Preservare le relazioni diagnostiche
Un campione di prove utile dovrebbe mantenere la distinzione tra i risultati grezzi dell'autenticazione e l'allineamento. Se la domanda riguarda il motivo per cui DMARC ha fallito, la sostituzione di ogni dominio con lo stesso segnaposto può cancellare la relazione che il fornitore deve comprendere. Preserva se le identità sono uguali, correlate o diverse ed etichetta chiaramente le sostituzioni sintetiche in modo che non vengano scambiate per nomi DNS reali da interrogare.
Mantenere insieme l'intervallo di reporting, i campi dei risultati pertinenti e le note sull'ambito. Se vengono condivise solo le righe selezionate, indicare che il campione è filtrato e identificare la regola di selezione. Non modificare un risultato per rendere l'esempio più semplice e non lasciare intendere che un conteggio filtrato rappresenti il traffico totale dell'organizzazione. Se necessario, fornire una spiegazione concisa dell'analista accanto ai campi conservati. RFC 9989 , sezione 4.4; RFC 9990 , sezione 3.1
Foglio di lavoro per l'approvazione e la conservazione
Preparare un record di approvazione con destinatario, organizzazione, prodotto, scopo, file o campi esatti, dominio o percorso interessato, intervallo di tempo, sensibilità, metodo di trasferimento e decisione di conservazione. Identificare se il fornitore può conservare il materiale solo per il caso, utilizzarlo per un altro scopo o condividerlo in seguito. Non dare per scontato che una relazione di supporto generale autorizzi un riutilizzo non correlato o un ampio accesso.
La decisione di conservazione dovrebbe riguardare sia la copia del fornitore che la copia di lavoro dell'organizzazione. Registra la durata prevista o l'attivazione dell'eliminazione e chi può verificare il completamento laddove ciò sia importante. Si tratta di una proposta di processo di governance, non di un'affermazione secondo cui un contratto con il fornitore prevede già termini specifici. Se i termini disponibili o l'accesso del destinatario non sono chiari, risolverli prima della trasmissione.
L'accettazione richiede che un revisore confronti il pacchetto finale con la mappa del campo approvata. È necessario controllare l'allegato vero e proprio, non semplicemente una descrizione, per eventuali righe non correlate, dati nascosti e segreti accidentali. Un destinatario modificato, un set di dati ampliato o un nuovo scopo dovrebbero innescare una nuova revisione anziché essere trattati come una continuazione innocua della stessa condivisione.
Pacchetto di supporto immaginario per un percorso di firma
Immagina un fornitore di ricevute immaginario che indaga su un allineamento DKIM fallimento. Il report aggregato non elaborato dell'organizzazione contiene anche la posta dei dipendenti e le osservazioni sulle campagne. Per questo esempio non è stato effettuato l'accesso a alcun report reale o richiesta del fornitore. Il pacchetto proposto contiene solo le righe rilevanti del percorso di ricezione, l'intervallo di segnalazione delimitato, le relazioni di identità pertinenti e una breve spiegazione di ciò che è incerto.
Le righe dipendente e campagna sono escluse perché non rispondono alla domanda del fornitore. Se il fornitore necessita di un dominio o di un selettore di firma esatto, l'organizzazione deve approvare tali valori per tale destinatario e scopo. Un campione redatto che li oscura può comunque essere utile per una discussione concettuale ma non può essere presentato come sufficiente per una diagnosi DNS in tempo reale.
L'approvazione finale registra anche una decisione di conservazione specifica per il caso. Nessun pacchetto viene inviato semplicemente perché la bozza è completa. Se in seguito il fornitore richiede campioni di messaggi completi, si tratta di una nuova richiesta di contenuto con un profilo di privacy diverso, soprattutto se introduce destinatari o corpi del messaggio. Il passaggio successivo è una revisione mirata, non un'espansione automatica.
Prove e stato di rilascio
Il catalogo richiede una mappa dei campi dati e un campione di prove minime approvato con una decisione esplicita di conservazione. Questo articolo fornisce solo un metodo di preparazione e un design del pacchetto fittizio. Nessun campione effettivo è stato approvato, nessun destinatario risolto e nessuna trasmissione o eliminazione del fornitore verificata.
Tutti e sei i cancelli di rilascio rimangono aperti. Un revisore qualificato dovrebbe verificare che la minimizzazione proposta preservi la domanda diagnostica rispettando i limiti del destinatario e dello scopo. Prima di qualsiasi condivisione effettiva, ottenere l'autorizzazione richiesta per i dati effettivi e la destinazione. Una bozza preparata in modo sicuro rappresenta un progresso prezioso, ma non costituisce una prova che il venditore abbia ricevuto o maneggiato qualcosa.