E-Mail-Bestände in der Fertigung beginnen oft mit der E-Mail der Mitarbeiter und vermissen den ERP-Planer, das Beschaffungstool und das Lieferantenportal. Diese Anwendungen können unter Dienstkonten ausgeführt werden, nur nach einem Batch über Nacht gesendet werden oder ein Relay verwenden, das einem Anlagenteam gehört. Die Authentifizierungsarbeit muss dem Produktionsprozess folgen, ohne ihn zu beeinträchtigen.
Ordnen Sie die Anwendung, das Relay und den Besitzer zu
Weisen Sie ERP-Benachrichtigungen dem ERP-Dienstleister, Kaufanfragen der Beschaffungstechnologie und Lieferantenportal-Mails dem Lieferantenintegrationsleiter zu. Erfassen Sie den Auslöser, die Anlage oder Geschäftseinheit, das Anbieterkonto, das Relay, die Autorendomäne und die Signatur Wähler. Beziehen Sie geplante Aufträge und außergewöhnliche Prozesse wie Nacharbeiten, stornierte Bestellungen und die Wiederherstellung von Lieferantenkonten ein, wenn diese unterschiedliche Wege nutzen.
Nutzen Sie einen Probeauftrag und ein eindeutig unverbindliches Muster einer Kaufanfrage. Generieren Sie niemals eine echte Lieferantenverpflichtung, nur um eine zu erhalten E-Mail-Header. Bitten Sie die Beschaffung, zu bestätigen, dass der Test keine Ausgaben genehmigen oder in eine Live-Abwicklungswarteschlange gelangen kann. Vermeiden Sie vertrauliche Stücklisten, Preise oder Bankdaten in der gespeicherten Nachrichtenprobe.
Verfolgen Sie den endgültigen Signierpunkt
Ein ERP kann über ein internes Relay übermitteln, das einen Hinweis hinzufügt, bevor ein externes Gateway signiert. Eine andere Route kann zuerst signieren und dann die Nachricht ändern lassen. Ordnen Sie die Reihenfolge zu, anstatt davon auszugehen, dass die Konfiguration eines Schlüssels in einer Konsole den gesamten Pfad abdeckt. Eine nach dem Signieren eingefügte inhaltliche Fußzeile verändert den kanonisierten signierten Text und kann eine vollständige Signatur ungültig machen. Kanonisierung kann einige Formatierungsunterschiede tolerieren, diagnostizieren Sie daher die tatsächlichen signierten Bytes und Signatureinstellungen, anstatt jede Änderung gleich zu behandeln. Hier wurde kein Footer-Test durchgeführt.
Der fiktive Beschaffungsdienst verwendet buy.factory.test als From und Procurement-vendor.test als Unterzeichner. Selbst wenn eine kryptografisch gültige Signatur vorausgesetzt wird, versagen diese hypothetischen Domänen strikt DKIM Ausrichtung; Dies ist kein beobachtetes oder vollständiges Verifizierungsergebnis DMARC Urteil. Bestätigen Sie die beabsichtigte Domäne und den tatsächlichen Dienstmandanten und bewerten Sie dann die unterstützten Konfigurationsänderungen. Beheben Sie die Nichtübereinstimmung nicht, indem Sie einem anlagenweiten Relay die uneingeschränkte Nutzung jeder Unternehmensdomäne gewähren.
Halten Sie die Geschäftsgenehmigung getrennt
Durch die Authentifizierung wird nicht nachgewiesen, dass eine Kaufanfrage genehmigt wurde, dass ein Lieferantenkonto echt ist oder dass ein Zahlungsziel korrekt ist. Pflegen Sie die Autorisierungs- und Zahlungsüberprüfungskontrollen des Beschaffungssystems unabhängig. Eine autorisierte, aber kompromittierte Anwendung kann eine gut authentifizierte böswillige Anweisung senden.
Lösen Sie zur Abnahme den eigentlichen Testauftrag aus, bewahren Sie ein empfangenes Muster auf und gleichen Sie es mit den Anwendungsprotokollen ab. Vergleichen Sie Normal- und Ausnahmeaufträge, anstatt einen einzelnen manuellen Versand als Beweis zu verwenden. Wenn das System stapelbetrieben ist, halten Sie mit Genehmigung des Eigentümers einen geeigneten Zyklus ein; Eine ruhige Stunde ist kein Beweis dafür, dass die Bewerbung nie abgeschickt wird.
Umstellung auf betriebliche Zwänge
Planen Sie die Wartung mit den Anlagen- und ERP-Eigentümern. Dokumentieren Sie einen Wiederherstellungspfad für den jeweiligen Dienst, bewahren Sie genehmigte Konfigurationsnachweise auf und überwachen Sie ausstehende Jobs nach der Änderung. Melden Sie einen Absender als ungelöst, wenn sein Eigentümer oder Mieter unbekannt ist, anstatt spekulative Genehmigungen zu erteilen. Vertrags-, Vertraulichkeits-, Exportkontroll- und Aufzeichnungsanforderungen bedürfen einer qualifizierten Prüfung. Dieses technische Beispiel trifft keine Feststellung über diese Verpflichtungen und genehmigt keine Kaufhandlung.
Fiktive Streckenkarte
Die folgenden expliziten Identitäten sind veranschaulichende Eingaben und keine echte Kundenkonfiguration. Die Identitäten und verantwortlichen Rollen sind hypothetisch, keine Kundengenehmigungen oder bereitgestellten Nachrichten. Es wurde kein Signierungstest oder Netzwerkzustellung durchgeführt.
- ERP-Benachrichtigung: ERP-Dienstinhaber; Von erp.factory.test; Umschlag und DKIM Signer erp.factory.test.
- Beschaffungssystem: Leiter Beschaffungstechnologie; Von buy.factory.test; Umschlag und DKIM Unterzeichner Procurement-Vendor.test.
- Lieferantenportal: Lieferantenintegrationsleiter; Von „suppliers.factory.test“; Umschlag- und DKIM Signatur-Lieferanten.factory.test.
Beheben Sie eine Diskrepanz im Batch-Pfad
Angenommen, ein manuell ausgelöster ERP-Test wird bestanden, aber der Beschaffungsstapel über Nacht verwendet ein anderes Relay, das nach der vollständigen Unterzeichnung einen inhaltlichen Hinweis einfügt. Halten Sie den Beschaffungsweg ungelöst und vergleichen Sie die empfangenen Header- und signierten Inhaltsnachweise mit den Anwendungsprotokollen. Eine Änderung des Schlüssels der manuellen Route würde keine Änderung an der Batch-Route bewirken. Hierbei handelt es sich um angenommene Zustände, nicht um eine Diagnose einer tatsächlichen Pflanze.
RFC 6376 Abschnitte 3.4, 3.5 und 3.7 Erklären Sie Kanonisierung, Signatur-Tags und Nachrichten-Hashes. RFC 9989 Abschnitte 4.4, 5.3.5 und 5.4 getrennte Ausrichtungs- und Empfängerentscheidungen. Eine andere ausgerichtete Authentifizierung kann sich auf das Nachrichtenurteil auswirken p=reject Für die Bereitstellung ist ein gültiges DKIM gemäß den Abschnitten 7.4 und 8 erforderlich SPF allein. Es wurde keine Bestellung, kein Unterzeichnerwechsel oder kein Produktions-Mail-Test durchgeführt.