A DKIM privat nøkkel er autoritet til å lage signaturer som kan verifisere mot samsvarende offentlige post. Beskyttelse av DNS posten alene beskytter ikke denne myndigheten. Inventar signeringssystemene, kontoene som kan bruke dem og hver operasjonell kopi av hemmeligheten før du bestemmer deg for at nøkkelen kontrolleres.
Identifiser varetekt i stedet for å anta det
Start med den faktiske leverandøren eller signeringsprogramvaren. En administrert tjeneste kan generere og beholde nøkler; en selvbetjent signer kan lese en fil, hemmelig butikk eller støttet maskinvarestøttet grensesnitt. Disse modellene har forskjellige tilgangs- og gjenopprettingskontroller. Ikke lov maskinvarebeskyttelse, ikke-eksporterbarhet eller kundestyrt rotasjon med mindre det valgte produktet dokumenterer og implementerer det.
RFC 6376 §8.3 forklarer konsekvensen av kompromiss med privat nøkkel: en inntrenger kan lage e-post signert av domenet som publiserer den tilsvarende offentlige nøkkelen. Den beskriver også verdien av en kontrollert utgående e-postserver som autentiserer sendere og bruker sendekontroller. De spesifikke lagrings- og gjennomgangstrinnene nedenfor er driftsanbefalinger, ikke universelle DKIM protokollkrav.
Bygg et depotkart som avslører skjulte kopier
For hver velger, registrer signeringsdomenet, tjenesteeier, nøkkelforvalter, aktive signeringsnoder, distribusjonsbane og støttet gjenopprettingsmekanisme. Spor hemmelighetens referanse eller identifikator, ikke selve hemmeligheten. Gjennomgå konfigurasjonslagre, trinn for beholderbygging, midlertidige distribusjonsfiler, sikkerhetskopier og diagnostiske pakker for utilsiktede kopier gjennom organisasjonens godkjente hemmelige håndteringsprosess.
Et syntetisk eksempel er en faktureringsklynge med to signeringsnoder og en distribusjonsjobb. DNS nøkkelen er offentlig og forventet. Den private nøkkelen er ment å bare nå de to nodene, men en gammel byggepipeline bygger den også inn i et bilde som er tilgjengelig for ikke-relaterte prosjekter. Å sikre gjeldende nodefiltillatelser vil ikke fjerne den eldre eksponeringen. Undersøk distribusjonsveien og behandle en potensielt avslørt hemmelighet i henhold til hendelsesprosessen.
Lim aldri inn en privat nøkkel i et offentlig DNS felt, billett, chat eller offentlig DKIM kontroll. Når støtte trenger bevis, gi den offentlige velgeren informasjon og passende kontrollerte diagnostiske resultater. Rå meldinger kan også inneholde sensitivt innhold; minimere det som deles og bruke godkjente kanaler.
Reduser hvem som kan signere og hvem som kan hente hemmeligheter
Bruk plattformens støttede minste-privilegier for både administrasjon og kjøretidstilgang. En konto som kan be om signaturer kan være kraftig selv om den ikke kan eksportere nøkkelen. Gjennomgå hvem som kan endre tillatte sendingsidentiteter, sende inn e-post, rotere nøkler, distribuere underskriverkonfigurasjon og hente sikkerhetskopier.
Separate tjenester med ulike eiere eller tillitsnivåer der arkitekturen støtter uavhengige nøkler og velgere. Å kopiere én nøkkel inn i hver applikasjon gjør en hendelse vanskeligere å omfatte og pensjonering mer forstyrrende. Høy tilgjengelighet kan legitimt kreve en delt signeringsidentitet, men det bør være et eksplisitt design med kontrollert distribusjon i stedet for en utilsiktet konsekvens av en kopiert konfigurasjonsfil.
Test gjenoppretting uten å distribuere hemmeligheten
Spør om et strømbrudd gjenopprettes ved å gjenopprette en beskyttet nøkkel, generere en erstatning eller bruke leverandørens administrerte gjenopprettingsbane. Test den støttede prosedyren i et kontrollert miljø. Registrer gjenopprettingstid, DNS avhengigheter og om e-post i kø fortsatt bruker den eldre velgeren. Ikke lag flere ubeskyttede sikkerhetskopier bare for å gjøre en drill enklere.
Se gjennom logger og tilgangshendelser som er tilgjengelige fra signeringsplattformen og hemmeligstyringssystemet. Det nyttige spørsmålet er om en uautorisert endring eller bruk kan oppdages og undersøkes, ikke om et bestemt dashbord eksisterer. Dokumenter logghull i stedet for å finne opp et revisjonsspor.
Avslutt med en handlingskraftig livssyklus
Hold varetektskartet ved siden av rotasjons- og kompromissprosedyrer. Fjern foreldet tilgang når ansatte eller leverandører forlater, og sjekk distribusjonen på nytt etter infrastrukturendringer. Under en mistenkt eksponering, koordiner tilgangsbegrensning, en ren erstatning og verifiseringskonsekvensene av gammel-nøkkel-pensjonering. En beskyttet gjeldende fil er bare én del av en kontrollert signeringslivssyklus.
Bruk et arbeidsark om forvaringsavgjørelse
Registrer disse ikke-hemmelige feltene for hver signeringsidentitet:
- Bruk: hvilke tjenestekontoer som kan sende inn eller be om signaturer, og hvilke d identiteter de kan bruke.
- Henting: hvilke roller kan eksportere eller gjenopprette den private nøkkelen, og hvor godkjente kopier ligger.
- Endre: hvem som kan endre underskriverkonfigurasjon, tillatte identiteter eller distribusjonsartefakter.
- Gjenoppretting: om den støttede banen gjenoppretter en beskyttet nøkkel eller genererer en erstatning, med DNS og e-postavhengigheter i kø.
- Bevis: tilgjengelige tilgangs-/signeringslogger, eventuelle dekningshull og eieren som er ansvarlig for gjennomgangen.
Hvis en gammel byggeartefakt inneholder en synlig nøkkel, er det ikke tilstrekkelig å sikre bare den aktive noden: omfang den gamle eksponeringen og avgjør om ren erstatning under hendelsesprosedyrer. Dette regnearket er redaksjonell sikkerhetsveiledning, ikke en påstand om at en bestemt plattform leverer disse kontrollene.
Relatert lesing
Tilbakekall en DKIM nøkkel og skille tilbakekalling fra en manglende DNS post · DKIM nøkkellengde og algoritmer: sjekk gjeldende mottakerstøtte.