A DKIM privat nøgle er autoritet til at oprette signaturer, der kan verificere mod den tilsvarende offentlige registrering. Beskyttelse af DNS posten alene beskytter ikke denne myndighed. Inventar signeringssystemerne, de konti, der kan bruge dem og hver operationel kopi af hemmeligheden, før du beslutter dig for, at nøglen er kontrolleret.
Identificer forældremyndigheden i stedet for at antage det
Start med den faktiske udbyder eller signeringssoftware. En administreret tjeneste kan generere og beholde nøgler; en selvbetjent underskriver kan læse en fil, en hemmelig butik eller en understøttet hardware-understøttet grænseflade. Disse modeller har forskellige adgangs- og gendannelseskontroller. Lov ikke hardwarebeskyttelse, ikke-eksporterbarhed eller kundestyret rotation, medmindre det valgte produkt dokumenterer og implementerer det.
RFC 6376 §8.3 forklarer konsekvensen af kompromis med privat nøgle: en ubuden gæst kan oprette e-mails, der er signeret af domænet, der udgiver den tilsvarende offentlige nøgle. Den beskriver også værdien af en kontrolleret udgående mailserver, der godkender afsendere og anvender afsendelseskontroller. De specifikke lagrings- og gennemgangstrin nedenfor er driftsanbefalinger, ikke universelle DKIM protokolkrav.
Byg et depotkort, der afslører skjulte kopier
For hver vælger, optag signeringsdomæne, tjenesteejer, nøgledepot, aktive signeringsnoder, implementeringssti og understøttet gendannelsesmekanisme. Spor hemmelighedens reference eller identifikator, ikke selve hemmeligheden. Gennemgå konfigurationslagre, containerbygningstrin, midlertidige implementeringsfiler, sikkerhedskopier og diagnostiske bundter for utilsigtede kopier gennem organisationens godkendte hemmelige håndteringsproces.
Et syntetisk eksempel er en faktureringsklynge med to signeringsnoder og et implementeringsjob. DNS nøglen er offentlig og forventet. Den private nøgle er beregnet til kun at nå de to noder, men en gammel byggepipeline indlejrer den også i et billede, der er tilgængeligt for ikke-relaterede projekter. Sikring af de aktuelle nodefiltilladelser ville ikke fjerne den ældre eksponering. Undersøg distributionsstien og behandl en potentielt afsløret hemmelighed i henhold til hændelsesprocessen.
Indsæt aldrig en privat nøgle i et offentligt DNS felt, billet, chat eller offentlig DKIM kontrol. Når der er behov for støtte, skal du give den offentlige vælgerinformation og passende kontrollerede diagnostiske resultater. Rå beskeder kan også indeholde følsomt indhold; minimere det, der deles og bruge godkendte kanaler.
Reducer, hvem der kan underskrive, og hvem der kan hente hemmeligheder
Brug platformens understøttede kontrolelementer med mindst privilegium til både administration og runtime-adgang. En konto, der kan anmode om signaturer, kan være effektiv, selvom den ikke kan eksportere nøglen. Gennemgå, hvem der kan ændre tilladte afsendelsesidentiteter, indsende mail, rotere nøgler, implementere underskriverkonfiguration og hente sikkerhedskopier.
Separate tjenester med forskellige ejere eller tillidsniveauer, hvor arkitekturen understøtter uafhængige nøgler og vælgere. Kopiering af én nøgle til hver applikation gør en hændelse sværere at omfatte og pensionering mere forstyrrende. Høj tilgængelighed kan legitimt kræve en delt signeringsidentitet, men det bør være et eksplicit design med kontrolleret distribution snarere end en utilsigtet konsekvens af en kopieret konfigurationsfil.
Test gendannelse uden at distribuere hemmeligheden
Spørg, om et afbrydelse genoprettes ved at gendanne en beskyttet nøgle, generere en erstatning eller bruge udbyderens administrerede retableringssti. Test den understøttede procedure i et kontrolleret miljø. Registrer gendannelsestid, DNS afhængigheder og om post i kø stadig bruger den ældre vælger. Opret ikke yderligere ubeskyttede sikkerhedskopier blot for at gøre en øvelse lettere.
Gennemgå logfiler og adgangsbegivenheder, der er tilgængelige fra signeringsplatformen og hemmelighedsstyringssystemet. Det nyttige spørgsmål er, om en uautoriseret ændring eller brug kunne opdages og undersøges, ikke om et bestemt dashboard eksisterer. Dokumenter logningshuller i stedet for at opfinde et revisionsspor.
Afslut med en brugbar livscyklusoptegnelse
Opbevar forældremyndighedskortet ved siden af rotations- og kompromisprocedurer. Fjern forældet adgang, når personale eller leverandører forlader, og tjek distributionen igen efter infrastrukturændringer. Under en formodet eksponering skal du koordinere adgangsinddæmning, en ren udskiftning og verifikationskonsekvenserne af old-key pensionering. En beskyttet aktuel fil er kun én del af en kontrolleret signeringslivscyklus.
Brug et arbejdsark til afgørelse om forældremyndighed
For hver signeringsidentitet skal du notere disse ikke-hemmelige felter:
- Brug: hvilke tjenestekonti kan indsende eller anmode om signaturer, og hvilke d identiteter de kan bruge.
- Hentning: hvilke roller kan eksportere eller gendanne den private nøgle, og hvor godkendte kopier findes.
- Ændring: hvem kan ændre underskriverkonfiguration, tilladte identiteter eller implementeringsartefakter.
- Gendannelse: om den understøttede sti gendanner en beskyttet nøgle eller genererer en erstatning med DNS og e-mail-afhængigheder i kø.
- Beviser: tilgængelige adgangs-/signeringslogfiler, eventuelle dækningshuller og ejeren, der er ansvarlig for gennemgangen.
Hvis en gammel byggeartefakt indeholder en blotlagt nøgle, er sikring af kun den aktive node utilstrækkelig: scoper den gamle eksponering og beslut om ren udskiftning under hændelsesprocedurer. Dette regneark er redaktionel sikkerhedsvejledning, ikke en påstand om, at en bestemt platform leverer disse kontroller.
Relateret læsning
Tilbagekald en DKIM nøgle og skeln tilbagekaldelse fra en manglende DNS post · DKIM nøglelængde og algoritmer: Tjek den aktuelle modtagerunderstøttelse.