A DKIM Der private Schlüssel ist die Berechtigung zum Erstellen von Signaturen, die anhand des entsprechenden öffentlichen Datensatzes überprüft werden können. Der Schutz des DNS Eintrags allein schützt diese Autorität nicht. Machen Sie eine Bestandsaufnahme der Signatursysteme, der Konten, die sie verwenden können, und jeder operativen Kopie des Geheimnisses, bevor Sie entscheiden, ob der Schlüssel kontrolliert wird.
Identifizieren Sie das Sorgerecht, anstatt es zu übernehmen
Beginnen Sie mit dem eigentlichen Anbieter oder der Signatursoftware. Ein verwalteter Dienst kann Schlüssel generieren und aufbewahren; Ein selbstgesteuerter Signierer kann eine Datei, einen geheimen Speicher oder eine unterstützte hardwaregestützte Schnittstelle lesen. Diese Modelle verfügen über unterschiedliche Zugriffs- und Wiederherstellungskontrollen. Versprechen Sie keinen Hardwareschutz, keine Exportfähigkeit oder vom Kunden verwaltete Rotation, es sei denn, das ausgewählte Produkt dokumentiert und implementiert dies.
RFC 6376 §8.3 erklärt die Konsequenz einer Kompromittierung des privaten Schlüssels: Ein Eindringling kann E-Mails erstellen, die von der Domäne signiert sind, die den entsprechenden öffentlichen Schlüssel veröffentlicht. Außerdem wird der Wert eines kontrollierten Postausgangsservers beschrieben, der Absender authentifiziert und Sendekontrollen anwendet. Bei den nachstehenden spezifischen Speicher- und Überprüfungsschritten handelt es sich um betriebliche Empfehlungen und nicht um universelle DKIM Protokollanforderungen.
Erstellen Sie eine Verwahrungskarte, die versteckte Kopien aufdeckt
Für jeden WählerNotieren Sie die Signaturdomäne, den Dienstbesitzer, den Schlüsselverwalter, die aktiven Signaturknoten, den Bereitstellungspfad und den unterstützten Wiederherstellungsmechanismus. Verfolgen Sie die Referenz oder Kennung des Geheimnisses, nicht das Geheimnis selbst. Überprüfen Sie Konfigurationsrepositorys, Container-Build-Schritte, temporäre Bereitstellungsdateien, Backups und Diagnosepakete auf unbeabsichtigte Kopien mithilfe des von der Organisation genehmigten Geheimhaltungsprozesses.
Ein synthetisches Beispiel ist ein Abrechnungscluster mit zwei Signaturknoten und einem Bereitstellungsjob. Der DNS Schlüssel ist öffentlich und wird erwartet. Der private Schlüssel soll nur die beiden Knoten erreichen, eine alte Build-Pipeline bettet ihn jedoch auch in ein Image ein, auf das nicht verwandte Projekte zugreifen können. Durch das Sichern der aktuellen Knotendateiberechtigungen würde diese ältere Gefährdung nicht entfernt. Untersuchen Sie den Verbreitungsweg und behandeln Sie ein potenziell offengelegtes Geheimnis entsprechend dem Vorfallprozess.
Fügen Sie niemals einen privaten Schlüssel in ein öffentliches DNS Feld, Ticket, Chat oder einen öffentlichen DKIM Prüfer ein. Wenn der Support Beweise benötigt, stellen Sie der Öffentlichkeit Selektorinformationen und entsprechend kontrollierte Diagnoseergebnisse zur Verfügung. Rohnachrichten können auch vertrauliche Inhalte enthalten; Minimieren Sie, was geteilt wird, und nutzen Sie genehmigte Kanäle.
Reduzieren Sie, wer unterschreiben und wer Geheimnisse abrufen kann
Verwenden Sie die von der Plattform unterstützten Steuerelemente mit den geringsten Rechten sowohl für den Verwaltungs- als auch den Laufzeitzugriff. Ein Konto, das Signaturen anfordern kann, kann auch dann leistungsstark sein, wenn es den Schlüssel nicht exportieren kann. Überprüfen Sie, wer zulässige Sendeidentitäten ändern, E-Mails senden, Schlüssel rotieren, die Unterzeichnerkonfiguration bereitstellen und Backups abrufen kann.
Separate Dienste mit unterschiedlichen Eigentümern oder Vertrauensstufen, wobei die Architektur unabhängige Schlüssel und Selektoren unterstützt. Das Kopieren eines Schlüssels in jede Anwendung erschwert die Eingrenzung eines Vorfalls und macht die Außerbetriebnahme störender. Für hohe Verfügbarkeit ist möglicherweise eine gemeinsame Signaturidentität erforderlich, dies sollte jedoch ein explizites Design mit kontrollierter Verteilung sein und keine zufällige Folge einer kopierten Konfigurationsdatei.
Testen Sie die Wiederherstellung, ohne das Geheimnis zu verteilen
Fragen Sie, ob ein Ausfall durch die Wiederherstellung eines geschützten Schlüssels, die Generierung eines Ersatzes oder die Verwendung des verwalteten Wiederherstellungspfads des Anbieters wiederhergestellt werden kann. Testen Sie das unterstützte Verfahren in einer kontrollierten Umgebung. Zeichnen Sie die Wiederherstellungszeit, DNS Abhängigkeiten und die Frage auf, ob E-Mails in der Warteschlange immer noch den älteren Selektor verwenden. Erstellen Sie keine zusätzlichen ungeschützten Sicherungskopien, nur um die Übung zu vereinfachen.
Überprüfen Sie Protokolle und Zugriffsereignisse, die auf der Signaturplattform und dem Secret-Management-System verfügbar sind. Die nützliche Frage ist, ob eine unbefugte Änderung oder Nutzung erkannt und untersucht werden konnte, und nicht, ob ein bestimmtes Dashboard existiert. Dokumentieren Sie Lücken in der Protokollierung, anstatt einen Audit-Trail zu erfinden.
Schließen Sie mit einer umsetzbaren Lebenszyklusaufzeichnung ab
Bewahren Sie die Sorgerechtskarte neben Rotations- und Kompromissverfahren auf. Entfernen Sie veraltete Zugriffe, wenn Mitarbeiter oder Lieferanten das Unternehmen verlassen, und überprüfen Sie die Verteilung nach Änderungen an der Infrastruktur erneut. Koordinieren Sie im Falle einer vermuteten Offenlegung die Zugangskontrolle, einen sauberen Austausch und die Überprüfungsfolgen der Entsorgung des alten Schlüssels. Eine geschützte aktuelle Datei ist nur ein Teil eines kontrollierten Signaturlebenszyklus.
Verwenden Sie ein Arbeitsblatt zur Sorgerechtsentscheidung
Notieren Sie für jede signierende Identität die folgenden nicht geheimen Felder:
- Verwendung: Welche Dienstkonten können Signaturen übermitteln oder anfordern und welche Identitäten sie verwenden dürfen.
- Abruf: Welche Rollen können den privaten Schlüssel exportieren oder wiederherstellen und wo genehmigte Kopien gespeichert sind.
- Ändern: Wer kann die Unterzeichnerkonfiguration, zulässige Identitäten oder Bereitstellungsartefakte ändern?
- Wiederherstellung: ob der unterstützte Pfad einen geschützten Schlüssel wiederherstellt oder einen Ersatz generiert, mit DNS und Queue-Mail-Abhängigkeiten.
- Nachweis: verfügbare Zugriffs-/Signaturprotokolle, etwaige Abdeckungslücken und der für die Überprüfung verantwortliche Eigentümer.
Wenn ein altes Build-Artefakt einen offengelegten Schlüssel enthält, reicht es nicht aus, nur den Live-Knoten zu sichern: Überprüfen Sie die alte Offenlegung und entscheiden Sie sich für einen sauberen Ersatz gemäß den Vorfallverfahren. Bei diesem Arbeitsblatt handelt es sich um eine redaktionelle Sicherheitsrichtlinie und nicht um einen Anspruch darauf, dass eine bestimmte Plattform diese Kontrollen bereitstellt.
Verwandte Lektüre
Widerrufen Sie einen DKIM Schlüssel und unterscheiden Sie den Widerruf von einem fehlenden DNS Eintrag · DKIM Schlüssellänge und Algorithmen: Überprüfen Sie die aktuelle Empfängerunterstützung.