Das E-Mail-Inventar eines Softwareunternehmens beginnt oft bei seiner Marketingplattform und endet zu früh. Der passwortlose Zugriff, Support-Antworten, Rechnungen und Statusaktualisierungen können von verschiedenen Anbietern, Anmeldeinformationen und Domänen abhängen. Sie scheitern auch zu unterschiedlichen Zeitpunkten. Eine Status-E-Mail, die von derselben nicht verfügbaren Anwendung abhängt, die sie beschreiben soll, stellt ein betriebliches Abhängigkeitsproblem dar, selbst wenn dies der Fall ist DKIM Die Konfiguration ist korrekt.
Ordnen Sie den Dienst hinter dem Absender zu
Erstellen Sie Zeilen für Produktereignisse, Supportgespräche, Abrechnungen und Statusseitenbenachrichtigungen. Erfassen Sie für jeden den Besitzer, den Anbieter-Mandanten, den Auslöser, die Absenderdomäne, die Umschlagidentität, DKIM Domäne usw Wähler, Antwortbearbeitung und Wiederherstellungskontakt. Verfolgen Sie, welche Anwendung oder Person einen Versand initiieren kann. Identifizieren Sie Abhängigkeiten von der Produktionsdatenbank, dem Identitätsanbieter, dem Geheimspeicher und der Bereitstellungspipeline und entscheiden Sie dann, welche für die Vorfallkommunikation akzeptabel sind.
Genehmigen Sie keine IP-Adresse, da diese zu einem bekannten Cloud-Anbieter gehört. Eine gemeinsam genutzte Infrastruktur beweist nicht, dass der Mieter des Unternehmens die Nachricht gesendet hat. Verbinden Sie die Beobachtung mit einem genehmigten Konto, einer unterstützten Domänenkonfiguration und einem verantwortlichen Eigentümer. Behalten Sie den unsicheren Datenverkehr als ungelöst bei, bis die Beweise die Zuordnung stützen.
Definieren Sie die Akzeptanz per Workflow
Ein Produktereignistest sollte innerhalb des Produkts beginnen, ein Supporttest innerhalb des Supportsystems und ein Abrechnungstest innerhalb seiner autorisierten Sandbox. Wenden Sie sich für Statusaktualisierungen an den zuständigen Herausgeber des Vorfalls und prüfen Sie, ob diese Person während eines Ausfalls des primären Dienstes tätig sein kann. Bestätigen Sie die beabsichtigte Antwortroute, damit Kunden nicht unerwartet auf eine nicht überwachte Adresse antworten.
RFC 9989 unterstützt die Bewertung der abgestimmten Domänennutzung, nicht der Anwendungsverfügbarkeit oder der Richtigkeit einer Rechnung. Eine Signatur aus der eigenen Domäne des Anbieters kann die Überprüfung durchführen, obwohl die beabsichtigte Überprüfung fehlschlägt Ausrichtung Beziehung. Authentifizierungsergebnisse müssen daher den Workflow-Abnahmetest begleiten und nicht ersetzen.
Lassen Sie nicht zu, dass Produkt-Mails den Statusweg verdecken
Angenommen, Produkt-, Support- und Abrechnungsrouten verwenden DKIM -d=-Domänen, die ihren jeweiligen Absenderdomänen entsprechen, während status.software.example die Absenderdomäne der Statusmitteilung und provider.example.net der Unterzeichner ist. Selbst wenn eine gültige Kryptografie vorausgesetzt wird, scheitert letzteres an der strikten DKIM Ausrichtung. Bestätigen Sie die unterstützte Identitätskonfiguration des Statusanbieters, anstatt unabhängige Rechnungsmails zu ändern. Bei diesen Identitäten handelt es sich um hypothetische Identitäten, es handelt sich nicht um bereitgestellte signierte Exemplare oder tatsächliche Verifizierungsergebnisse.
Die Ausrichtung einer einzelnen Signatur ist keine vollständige DMARC Urteil: Bewerten Sie andere gültige ausgerichtete Signaturen und SPF wie unten anwendbar RFC 9989 Abschnitte 4.4 und 5.3.5. Für p=reject Für die Bereitstellung erfordern die Abschnitte 7.4 und 8 ein gültiges DKIM , anstatt sich nur auf SPF zu verlassen. Weder der Signaturerfolg noch die Ausrichtung belegen, dass der Statusherausgeber während eines Ausfalls funktionieren kann. Es wurde kein Live-Plattform- oder kryptografischer Test durchgeführt.
Testen Sie die Vorfallabhängigkeit, nicht nur das DNS
Führen Sie eine autorisierte Übung durch, bei der der normale Produktbetreiber nicht verfügbar ist und der Herausgeber des Backup-Vorfalls dem dokumentierten Weg folgt. Unterbrechen Sie die Produktion nicht absichtlich, nur um diesen Leitfaden zu testen. Erfassen Sie, welche Anmeldeinformationen, Konten und Systeme erforderlich waren, ob ein kontrollierter Empfänger das Update erhalten hat und was die Empfangsgrenze gemeldet hat. Wenn der Fallback den nicht verfügbaren Identitätsanbieter erfordert, notieren Sie sich diese Einschränkung und entwerfen Sie sie mit dem Sicherheitseigentümer neu, anstatt ein gemeinsames Passwort zu improvisieren.
Befolgen Sie zum Signieren von Änderungen die aktuellen Anweisungen des Anbieters und bewahren Sie Rollback-Nachweise auf. Entfernen Sie veraltete Autorisierungen erst, nachdem Sie bestätigt haben, dass sie von keinem beibehaltenen Produkt, Support oder Abrechnungsworkflow verwendet werden. Belege mit geringem Volumen und seltene Vorfallmeldungen können aus kurzen Beobachtungsfenstern verschwinden, ohne dass sie veraltet sind.
Machen Sie die Bestandsaufnahme zum Bestandteil der Änderungskontrolle
Fordern Sie eine Routenüberprüfung an, wenn ein Team einen Benachrichtigungsanbieter hinzufügt, eine Absenderadresse ändert, eine Support-Warteschlange verschiebt oder den Statusdienst ersetzt. Testen Sie betroffene Abläufe erneut und bewahren Sie Beweisdaten auf. Das Inventar ist nur im angegebenen Umfang vollständig; Neue Produktfunktionen können neue Absender hinzufügen. Schließen Sie jede Migration mit einem vom Eigentümer genehmigten Test und einem brauchbaren Wiederherstellungsverfahren ab, nicht mit einem domänenweiten Durchschnitt.