A DKIM privésleutel is de bevoegdheid om handtekeningen te maken die kunnen worden geverifieerd aan de hand van het overeenkomende openbare record. Het beschermen van de DNS record alleen beschermt die autoriteit niet. Inventariseer de ondertekensystemen, de accounts die ze kunnen gebruiken en elke operationele kopie van het geheim voordat wordt besloten of de sleutel wordt gecontroleerd.
Identificeer de voogdij in plaats van deze aan te nemen
Begin met de daadwerkelijke provider of ondertekeningssoftware. Een beheerde service kan sleutels genereren en behouden; een zelfwerkende ondertekenaar kan een bestand, een geheime opslag of een ondersteunde, door hardware ondersteunde interface lezen. Deze modellen hebben verschillende toegang- en herstelcontroles. Beloof geen hardwarebescherming, niet-exporteerbaarheid of door de klant beheerde rotatie tenzij het gekozen product dit documenteert en implementeert.
RFC 6376 §8.3 legt de consequentie uit van het compromitteren van privésleutels: een indringer kan e-mail maken die is ondertekend door het domein dat de bijbehorende openbare sleutel publiceert. Het beschrijft ook de waarde van een gecontroleerde uitgaande mailserver die indieners authenticeert en verzendcontroles toepast. De specifieke opslag- en beoordelingsstappen hieronder zijn operationele aanbevelingen en geen universele DKIM protocolvereisten.
Bouw een voogdijkaart die verborgen kopieën blootlegt
Voor elk keuzeschakelaar, leg het ondertekeningsdomein, de service-eigenaar, de sleutelbeheerder, actieve ondertekeningsknooppunten, het implementatiepad en het ondersteunde herstelmechanisme vast. Volg de referentie of identificatie van het geheim, niet het geheim zelf. Controleer configuratieopslagplaatsen, stappen voor het bouwen van containers, tijdelijke implementatiebestanden, back-ups en diagnostische bundels op onbedoelde kopieën via het goedgekeurde geheimverwerkingsproces van de organisatie.
Een synthetisch voorbeeld is een factureringscluster met twee ondertekeningsknooppunten en een implementatietaak. De DNS sleutel is openbaar en wordt verwacht. De privésleutel is bedoeld om alleen de twee knooppunten te bereiken, maar een oude build-pijplijn sluit deze ook in in een afbeelding die toegankelijk is voor niet-gerelateerde projecten. Het beveiligen van de huidige bestandsrechten van het knooppunt zou die oudere blootstelling niet verwijderen. Onderzoek het distributietraject en behandel een potentieel openbaar geheim volgens het incidentproces.
Plak nooit een privésleutel in een openbaar DNS veld, ticket, chat of openbare DKIM checker. Wanneer ondersteuning bewijs nodig heeft, verstrek dan de openbare selectorinformatie en op passende wijze gecontroleerde diagnostische resultaten. Onbewerkte berichten kunnen ook gevoelige inhoud bevatten; minimaliseer wat er wordt gedeeld en gebruik goedgekeurde kanalen.
Beperk wie kan tekenen en wie geheimen kan opvragen
Gebruik de ondersteunde besturingselementen met minimale bevoegdheden van het platform voor zowel beheer- als runtime-toegang. Een account dat handtekeningen kan aanvragen, kan krachtig zijn, zelfs als het de sleutel niet kan exporteren. Bekijk wie toegestane verzendidentiteiten kan wijzigen, e-mail kan verzenden, sleutels kan roteren, ondertekenaarsconfiguratie kan implementeren en back-ups kan ophalen.
Afzonderlijke services met verschillende eigenaren of vertrouwensniveaus waarbij de architectuur onafhankelijke sleutels en selectors ondersteunt. Het kopiëren van één sleutel naar elke applicatie maakt het moeilijker om een incident te bereiken en het buiten gebruik stellen ervan zorgt voor meer verstoring. Hoge beschikbaarheid kan legitiem een gedeelde ondertekeningsidentiteit vereisen, maar dat moet een expliciet ontwerp zijn met gecontroleerde distributie en geen toevallig gevolg van een gekopieerd configuratiebestand.
Test het herstel zonder het geheim te verspreiden
Vraag of een storing kan worden hersteld door een beschermde sleutel te herstellen, een vervanging te genereren of het beheerde herstelpad van de provider te gebruiken. Test de ondersteunde procedure in een gecontroleerde omgeving. Registreer de hersteltijd, DNS afhankelijkheden en of e-mail in de wachtrij nog steeds de oudere selector gebruikt. Maak geen extra onbeveiligde back-upkopieën alleen maar om de oefening eenvoudiger te maken.
Bekijk logboeken en krijg toegang tot gebeurtenissen die beschikbaar zijn via het ondertekeningsplatform en het geheimbeheersysteem. De nuttige vraag is of een ongeoorloofde wijziging of gebruik kan worden gedetecteerd en onderzocht, en niet of er een bepaald dashboard bestaat. Documenteer hiaten in de logboekregistratie in plaats van een audittrail uit te vinden.
Sluit af met een bruikbaar levenscyclusrecord
Bewaar de voogdijkaart naast rotatie- en compromisprocedures. Verwijder verouderde toegang wanneer personeel of leveranciers weggaan, en controleer de distributie opnieuw na wijzigingen in de infrastructuur. Coördineer tijdens een vermoedelijke blootstelling de toegangscontrole, een schone vervanging en de verificatiegevolgen van het buiten gebruik stellen van oude sleutels. Een beveiligd huidig bestand is slechts een onderdeel van de levenscyclus van een gecontroleerde ondertekening.
Gebruik een werkblad voor de voogdijbeslissing
Leg voor elke ondertekeningsidentiteit deze niet-geheime velden vast:
- Gebruik: welke serviceaccounts handtekeningen kunnen indienen of aanvragen, en welke identiteiten ze mogen gebruiken.
- Ophalen: welke rollen de privésleutel kunnen exporteren of herstellen, en waar goedgekeurde kopieën zich bevinden.
- Wijzigen: wie de ondertekenaarsconfiguratie, toegestane identiteiten of implementatieartefacten kan wijzigen.
- Herstel: of het ondersteunde pad een beschermde sleutel herstelt of een vervanging genereert, met afhankelijkheden DNS en e-mail in de wachtrij.
- Bewijs: beschikbare toegangs-/ondertekeningslogboeken, eventuele hiaten in de dekking en de eigenaar die verantwoordelijk is voor de beoordeling.
Als een oud build-artefact een blootgestelde sleutel bevat, is het beveiligen van alleen het live knooppunt onvoldoende: bepaal de oude blootstelling en beslis over schone vervanging volgens incidentprocedures. Dit werkblad is een redactionele beveiligingsrichtlijn en geen claim dat een bepaald platform deze controles levert.
Gerelateerde lectuur
Trek een DKIM sleutel in en onderscheid de intrekking van een ontbrekend DNS record · DKIM sleutellengte en algoritmen: controleer de huidige ontvangerondersteuning.