A DKIM la chiave privata è l'autorità per creare firme che possono essere verificate rispetto al record pubblico corrispondente. La sola protezione del record DNS non protegge tale autorità. Inventariare i sistemi di firma, gli account che possono utilizzarli e ogni copia operativa del segreto prima di decidere se la chiave è controllata.
Identificare la custodia piuttosto che assumerla
Inizia con il fornitore effettivo o il software di firma. Un servizio gestito può generare e conservare chiavi; un firmatario autonomo può leggere un file, un archivio segreto o un'interfaccia supportata da hardware supportato. Questi modelli hanno controlli di accesso e ripristino diversi. Non promettere protezione hardware, non esportabilità o rotazione gestita dal cliente a meno che il prodotto scelto non la documenti e la implementi.
RFC 6376 §8.3 spiega la conseguenza della compromissione della chiave privata: un intruso può creare posta firmata dal dominio che pubblica la chiave pubblica corrispondente. Descrive inoltre il valore di un server di posta in uscita controllato che autentica i mittenti e applica i controlli di invio. I passaggi specifici di archiviazione e revisione riportati di seguito sono raccomandazioni operative, non requisiti universali del protocollo DKIM .
Costruisci una mappa di custodia che esponga le copie nascoste
Per ciascuno selettore, registra il dominio di firma, il proprietario del servizio, il custode delle chiavi, i nodi di firma attivi, il percorso di distribuzione e il meccanismo di ripristino supportato. Tieni traccia del riferimento o dell'identificatore del segreto, non del segreto stesso. Esamina i repository di configurazione, le fasi di creazione del contenitore, i file di distribuzione temporanei, i backup e i bundle diagnostici per individuare eventuali copie indesiderate attraverso il processo di gestione dei segreti approvato dall'organizzazione.
Un esempio sintetico è un cluster di fatturazione con due nodi di firma e un processo di distribuzione. La chiave DNS è pubblica e prevista. La chiave privata è destinata a raggiungere solo i due nodi, ma una vecchia pipeline di build la incorpora anche in un'immagine accessibile a progetti non correlati. La protezione delle autorizzazioni del file del nodo corrente non rimuoverebbe l'esposizione precedente. Esaminare il percorso di distribuzione e trattare un segreto potenzialmente esposto in base al processo dell'incidente.
Non incollare mai una chiave privata in un campo DNS pubblico, in un ticket, in una chat o in un controllo DKIM pubblico. Quando il supporto necessita di prove, fornire al selezionatore pubblico informazioni e risultati diagnostici adeguatamente controllati. Anche i messaggi non elaborati possono contenere contenuti sensibili; ridurre al minimo ciò che viene condiviso e utilizzare canali approvati.
Riduci chi può firmare e chi può recuperare i segreti
Utilizza i controlli con privilegi minimi supportati dalla piattaforma sia per l'amministrazione che per l'accesso runtime. Un account che può richiedere firme può essere potente anche se non può esportare la chiave. Controlla chi può modificare le identità di invio consentite, inviare posta, ruotare le chiavi, distribuire la configurazione del firmatario e recuperare i backup.
Servizi separati con proprietari o livelli di fiducia diversi in cui l'architettura supporta chiavi e selettori indipendenti. La copia di una chiave in ogni applicazione rende l'incidente più difficile da individuare e il ritiro più problematico. L'elevata disponibilità può legittimamente richiedere un'identità di firma condivisa, ma questa dovrebbe essere una progettazione esplicita con distribuzione controllata piuttosto che una conseguenza accidentale di un file di configurazione copiato.
Testare il ripristino senza distribuire il segreto
Chiedi se un'interruzione viene ripristinata ripristinando una chiave protetta, generando una sostituzione o utilizzando il percorso di ripristino gestito del provider. Testare la procedura supportata in un ambiente controllato. Registra il tempo di ripristino, le dipendenze DNS e se la posta in coda utilizza ancora il vecchio selettore. Non creare ulteriori copie di backup non protette semplicemente per facilitare l'esercitazione.
Esamina i registri e accedi agli eventi disponibili dalla piattaforma di firma e dal sistema di gestione dei segreti. La domanda utile è se è possibile rilevare e indagare una modifica o un utilizzo non autorizzato, non se esista una particolare dashboard. Documentare le lacune nella registrazione invece di inventare una traccia di controllo.
Termina con un record del ciclo di vita utilizzabile
Conservare la mappa di custodia accanto alle procedure di rotazione e di compromesso. Rimuovi gli accessi obsoleti quando il personale o i fornitori se ne vanno e ricontrolla la distribuzione dopo le modifiche all'infrastruttura. Durante una sospetta esposizione, coordinare il contenimento dell'accesso, una sostituzione pulita e le conseguenze della verifica del ritiro della vecchia chiave. Un file corrente protetto è solo una parte di un ciclo di vita di firma controllata.
Utilizzare un foglio di lavoro per la decisione sull'affidamento
Per ogni identità di firma, registra questi campi non segreti:
- Utilizzo: quali account di servizio possono inviare o richiedere firme e quali identità possono utilizzare.
- Recupero: quali ruoli possono esportare o ripristinare la chiave privata e dove risiedono le copie approvate.
- Modifica: chi può modificare la configurazione del firmatario, le identità consentite o gli artefatti di distribuzione.
- Ripristino: se il percorso supportato ripristina una chiave protetta o genera una sostituzione, con dipendenze DNS e posta in coda.
- Prova: registri di accesso/firma disponibili, eventuali lacune di copertura e proprietario responsabile della revisione.
Se un vecchio artefatto di build contiene una chiave esposta, proteggere solo il nodo attivo non è sufficiente: ambito della vecchia esposizione e decisione sulla sostituzione pulita in base alle procedure di incidente. Questo foglio di lavoro costituisce una guida alla sicurezza editoriale, non un'affermazione secondo cui una particolare piattaforma fornisce questi controlli.
Lettura correlata
Revocare una chiave DKIM e distinguere la revoca da un record DNS mancante · Lunghezza della chiave DKIM e algoritmi: controlla il supporto attuale del ricevitore.