Un pianificato DKIM la rotazione cambia la chiave privata che firma la nuova posta preservando il materiale di verifica necessario per i messaggi già in transito. Pubblicazione di una nuova chiave pubblica, cambio del firmatario e ritiro della vecchia selettore sono fasi separate.
Inizia con il servizio di firma e la sua procedura di rotazione supportata. Una delega di selezione gestita dal fornitore ha un modello operativo diverso da una coppia di chiavi controllata direttamente dalla tua organizzazione.
Stabilire lo stato di firma corrente
Utilizzare i messaggi originali ricevuti per identificare i domini di firma d= effettivi e i selettori s=. Correlarli con il servizio di firma, il modello di gestione delle chiavi e il proprietario dell'azienda.
Un record DNS può esistere senza essere utilizzato dai messaggi correnti. Al contrario, un vecchio messaggio può fare riferimento a un selettore che non è più la scelta attiva per la nuova posta.
Salva le risposte pubbliche pertinenti e lo stato di configurazione. Conserva le chiavi di firma private nel sistema di firma autorizzato, non in un ticket, in un foglio di calcolo dell'inventario o in un record DNS pubblico.
Conferma l'algoritmo e i requisiti del fornitore
Esaminare le attuali linee guida crittografiche e il comportamento di verifica supportato. RFC 8301 §3 esclude rsa-sha1 e imposta i requisiti di dimensione della chiave RSA; consiglia chiavi RSA di almeno 2048 bit. RFC 8463 §5 definisce Ed25519-SHA256 come metodo aggiuntivo.
La specificazione di un algoritmo e l'effettivo supporto dei mittenti, dei fornitori e dei destinatari coinvolti sono prove diverse. Non modificare un servizio di produzione in un metodo che la sua configurazione supportata non può utilizzare.
Per la firma gestita dal provider, seguire i valori generati e il processo di rotazione. Un alias DNS può delegare la gestione delle chiavi senza fornire al tuo team la chiave privata o un controllo di cutover manuale.
Pubblica nuovo materiale di verifica prima del passaggio
Se il progetto supportato utilizza un nuovo selettore, pubblica prima il materiale di verifica pubblico corretto. Conferma il nome del proprietario finale, la risposta e l'eventuale catena di delega.
Utilizzare un selettore diverso per una nuova chiave laddove la procedura supportata lo consente. La sostituzione della chiave sotto un selettore può lasciare i messaggi firmati con la vecchia chiave incapaci di verificare rispetto alla sostituzione.
Non rimuovere la vecchia chiave semplicemente perché la nuova risposta DNS sembra corretta. In questa fase hai stabilito la pubblicazione, non che il firmatario abbia cambiato o che ogni ricevente possa recuperare il materiale previsto.
Cambia firma e verifica i nuovi messaggi
Utilizzare la procedura di firma autorizzata per iniziare a firmare con la nuova chiave. Invia messaggi rappresentativi attraverso percorsi importanti e controlla le firme originali ricevute e i risultati attendibili.
In una rotazione sintetica, la posta precedente utilizza s=old2026 e la nuova posta utilizza s=new2026. Entrambi i nomi di verifica pubblica rimangono disponibili durante la sovrapposizione pianificata, mentre i nuovi messaggi ricevuti dimostrano il selettore previsto e una firma di passaggio.
Se un gateway modifica il messaggio dopo la firma, un test diretto prima di quel gateway risulta incompleto. Controlla il percorso aziendale completo e DMARC allineamento così come il risultato della firma grezza.
Scegli il pensionamento dalle condizioni di consegna
RFC 6376 §3.1 descrive la pubblicazione simultanea durante la transizione in cui la posta potrebbe essere ancora in transito. Non fornisce una durata di sovrapposizione universale per ogni organizzazione.
Valutare le code, il comportamento dei nuovi tentativi, i ritardi di consegna previsti, il comportamento della cache DNS , la scadenza delle firme rilevanti e le esigenze di verifica. Registrare il motivo della sovrapposizione scelta ed eventuali vincoli del fornitore.
Ritirare il vecchio materiale di verifica dal processo supportato solo quando tale valutazione lo giustifica. Un controllo successivo di un messaggio salvato può differire dal risultato del tempo di consegna originale dopo la rimozione della chiave.
Tratta il sospetto compromesso come una decisione diversa
La rotazione di routine mira alla continuità. Una sospetta compromissione della chiave privata può richiedere una restrizione urgente o il ritiro nonostante il potenziale impatto della verifica sulla posta più vecchia.
Seguire il processo di incidente dell'organizzazione e la risposta supportata del fornitore di servizi di firma. Conservare le prove e spiegare il compromesso. Non promettere che una sovrapposizione adatta alla manutenzione ordinaria sia adatta durante una compromissione attiva.
Chiudi con un record di firma verificabile
Conservare il servizio, il proprietario, i selezionatori vecchi e nuovi, le prove della pubblicazione, l'osservazione del taglio, la logica della sovrapposizione, la decisione di pensionamento e i risultati ricevuti dal rappresentante.
IL guida alla selezione spiega la ricerca dell'identità. Per Microsoft 365 o Workspace, utilizzare il loro specifico dell'inquilino O dominio selezionato guida alla configurazione. Una rotazione è completa quando viene verificata la nuova rotta di firma e la vecchia dipendenza è stata ritirata per un motivo documentato.
Utilizzare tre controlli di accettazione separati
La checklist proposta non lo è un record di rotazione completata. Prima del cutover, conferma che il nuovo selettore si risolve nel valore pubblico generato mentre il vecchio selettore rimane disponibile. Dopo il cutover, un messaggio dell'applicazione appena ricevuto dovrebbe mostrare s=new2026 e il dominio d previsto con un passaggio attendibile. Prima del pensionamento, verificare che la coda/riprova concordata e le condizioni di verifica siano soddisfatte e registrare la decisione. Un passaggio da un'applicazione non correlata non chiude il percorso interessato. Non trasformare un intervallo di esempio in un tempo di attesa universale.