Gli inventari e-mail di produzione spesso iniziano con la posta dei dipendenti e mancano lo scheduler ERP, lo strumento di approvvigionamento e il portale dei fornitori. Queste applicazioni possono essere eseguite con account di servizio, inviate solo dopo un batch notturno o utilizzare un relè di proprietà di un team dell'impianto. Il lavoro di autenticazione deve seguire il processo produttivo senza interferire con esso.
Mappare l'applicazione, il relè e il proprietario
Assegnare notifiche ERP al proprietario del servizio ERP, richieste di acquisto alla tecnologia di approvvigionamento e posta del portale fornitori al responsabile dell'integrazione del fornitore. Registra il trigger, l'impianto o l'unità aziendale, l'account del fornitore, l'inoltro, il dominio dell'autore e la firma selettore. Includere lavori programmati e processi eccezionali come rilavorazioni, ordini annullati e recupero del conto fornitore laddove utilizzino percorsi diversi.
Utilizzare un ordine di lavoro di prova e un modello di richiesta d'acquisto chiaramente non vincolante. Non generare mai un impegno reale da parte del fornitore semplicemente per raccogliere un intestazione dell'e-mail. Chiedi all'approvvigionamento di confermare che il test non può approvare la spesa o inserire una coda di evasione in tempo reale. Evitare distinte base riservate, prezzi o dettagli bancari nell'esempio di messaggio conservato.
Traccia il punto di firma finale
Un ERP può inviare tramite un relè interno che aggiunge un avviso prima che un gateway esterno firmi. Un altro percorso potrebbe prima firmare e poi modificare il messaggio. Mappa la sequenza anziché dare per scontato che la configurazione di una chiave in una console copra l'intero percorso. Un piè di pagina sostanziale inserito dopo la firma modifica il corpo canonico della firma e può invalidare una firma a corpo intero. Canonicalizzazione può tollerare alcune differenze di formattazione, quindi diagnosticare i byte firmati effettivi e le impostazioni della firma anziché trattare allo stesso modo ogni alterazione. Qui non è stato eseguito alcun test del footer.
Il servizio di approvvigionamento fittizio utilizza buy.factory.test come Da e procurement-vendor.test come firmatario. Anche presupponendo una firma crittograficamente valida, questi ipotetici domini falliscono in modo rigoroso DKIM allineamento; questo non è un risultato di verifica osservato o completo DMARC verdetto. Conferma il dominio previsto e il tenant del servizio effettivo, quindi valuta le modifiche alla configurazione supportate. Non correggete la discrepanza concedendo a un inoltro a livello di stabilimento l'uso illimitato di ogni dominio aziendale.
Mantieni separata l'approvazione aziendale
L'autenticazione non stabilisce che una richiesta d'acquisto sia approvata, che un conto fornitore sia autentico o che la destinazione del pagamento sia corretta. Mantenere in modo indipendente i controlli autorizzativi e di verifica dei pagamenti del sistema di approvvigionamento. Un'applicazione autorizzata ma compromessa può inviare un'istruzione dannosa ben autenticata.
Per l'accettazione, avviare il lavoro di test reale, conservare un campione ricevuto e riconciliarlo con i registri dell'applicazione. Confronta lavori normali ed eccezionali invece di prendere come prova un singolo invio manuale. Se il sistema è a batch, osservare un ciclo appropriato sotto l'approvazione del proprietario; un'ora tranquilla non è la prova che l'applicazione non viene mai inviata.
Cambiamento rispetto ai vincoli operativi
Pianificare la manutenzione con i proprietari dell'impianto e dell'ERP. Documenta un percorso di ripristino per il servizio specifico, preserva le prove della configurazione approvata e monitora i lavori in sospeso dopo la modifica. Segnala un mittente come non risolto quando il suo proprietario o inquilino è sconosciuto invece di concedere autorizzazioni speculative. I requisiti contrattuali, di riservatezza, di controllo delle esportazioni e di tenuta dei registri necessitano di una revisione qualificata. Questo esempio tecnico non determina tali obblighi e non autorizza alcuna azione di acquisto.
Mappa del percorso immaginaria
Le seguenti identità esplicite sono input illustrativi, non una reale configurazione del cliente. Le identità e i ruoli responsabili sono ipotetici, non approvazioni dei clienti o messaggi forniti. Non è stato eseguito alcun test di firma o distribuzione in rete.
- Notifica Erp: titolare del servizio ERP; Da erp.factory.test; busta e firmatario DKIM erp.factory.test.
- Sistema di approvvigionamento: responsabile della tecnologia di approvvigionamento; Da buy.factory.test; busta e firmatario DKIM procurement-vendor.test.
- Portale fornitori: responsabile dell'integrazione dei fornitori; Da fornitori.fabbrica.test; busta e firmatario DKIM fornitori.factory.test.
Risolvere una discrepanza nel percorso batch
Supponiamo che un test ERP attivato manualmente superi ma che il batch di approvvigionamento notturno utilizzi un altro relè che inserisce un avviso sostanziale dopo la firma completa. Mantieni irrisolto il percorso di approvvigionamento e confronta l'intestazione ricevuta e la prova del contenuto firmato con i registri dell'applicazione. La modifica della chiave del percorso manuale non risolverebbe un'alterazione sul percorso batch. Queste sono condizioni presunte, non una diagnosi di una pianta reale.
RFC 6376 Sezioni 3.4, 3.5 e 3.7 spiegare la canonicalizzazione, i tag della firma e gli hash dei messaggi. RFC 9989 Sezioni 4.4, 5.3.5 e 5.4 decisioni separate sull'allineamento e sul ricevitore. Altre autenticazioni allineate possono influenzare il verdetto del messaggio, mentre p=reject la distribuzione richiede DKIM valido ai sensi delle Sezioni 7.4 e 8 anziché SPF solo. Non è stato eseguito alcun ordine di acquisto, modifica del firmatario o test della posta di produzione.