Les inventaires de courrier électronique du secteur de la fabrication commencent souvent par le courrier des employés et ne contiennent pas le planificateur ERP, l'outil d'approvisionnement et le portail des fournisseurs. Ces applications peuvent s'exécuter sous des comptes de service, être envoyées uniquement après un lot de nuit ou utiliser un relais appartenant à une équipe de l'usine. Le travail d'authentification doit suivre le processus de production sans interférer avec celui-ci.
Cartographier l'application, le relais et le propriétaire
Attribuez des notifications ERP au propriétaire du service ERP, des demandes d'achat à la technologie d'approvisionnement et des courriers du portail fournisseur au responsable de l'intégration du fournisseur. Enregistrez le déclencheur, l'usine ou l'unité commerciale, le compte du fournisseur, le relais, le domaine de l'auteur et la signature. sélecteur. Incluez les tâches planifiées et les processus exceptionnels tels que les reprises, les commandes annulées et la récupération des comptes fournisseurs lorsqu'ils empruntent des itinéraires différents.
Utilisez un bon de commande test et un spécimen de demande d’achat clairement non contraignant. Ne génèrez jamais un véritable engagement fournisseur simplement pour percevoir un en-tête de l'e-mail. Demandez au service des achats de confirmer que le test ne peut pas approuver les dépenses ou entrer dans une file d'attente d'exécution en direct. Évitez les nomenclatures, les prix ou les coordonnées bancaires confidentielles dans l’échantillon de message conservé.
Tracez le point de signature final
Un ERP peut soumettre via un relais interne qui ajoute une notification avant qu'une passerelle externe ne signe. Un autre itinéraire peut d'abord signer, puis modifier le message. Mappez la séquence plutôt que de supposer que la configuration d’une clé dans une console couvre l’intégralité du chemin. Un pied de page de fond inséré après la signature modifie le corps signé canonisé et peut invalider une signature complète. Canonisation peut tolérer certaines différences de formatage, donc diagnostiquez les octets signés et les paramètres de signature plutôt que de traiter chaque modification de la même manière. Aucun test de pied de page n'a été exécuté ici.
Le service d'approvisionnement fictif utilise buy.factory.test comme From et Procurement-vendor.test comme signataire. Même en supposant une signature cryptographiquement valide, ces domaines hypothétiques échouent aux règles strictes. DKIM alignement; il ne s'agit pas d'un résultat de vérification observé ni d'un résultat complet DMARC verdict. Confirmez le domaine prévu et le locataire de service réel, puis évaluez les modifications de configuration prises en charge. Ne corrigez pas l’inadéquation en accordant à un relais à l’échelle de l’usine une utilisation illimitée de chaque domaine d’entreprise.
Séparez l’approbation commerciale
L'authentification n'établit pas qu'une demande d'achat est approuvée, qu'un compte fournisseur est authentique ou qu'une destination de paiement est correcte. Maintenir les contrôles d'autorisation et de vérification des paiements du système d'approvisionnement de manière indépendante. Une application autorisée mais compromise peut envoyer une instruction malveillante bien authentifiée.
Pour l'acceptation, déclenchez le travail de test réel, conservez un échantillon reçu et rapprochez-le avec les journaux d'application. Comparez les tâches normales et exceptionnelles plutôt que de prendre un seul envoi manuel comme preuve. Si le système fonctionne par lots, respectez un cycle approprié sous l'approbation du propriétaire ; une heure calme ne prouve pas que la candidature n'est jamais envoyée.
Changement autour des contraintes opérationnelles
Planifier la maintenance avec les propriétaires de l'usine et de l'ERP. Documentez un chemin de récupération pour le service spécifique, conservez les preuves de configuration approuvées et surveillez les tâches en attente après la modification. Signalez un expéditeur comme non résolu lorsque son propriétaire ou locataire est inconnu plutôt que d'accorder des autorisations spéculatives. Les exigences contractuelles, de confidentialité, de contrôle des exportations et de tenue de registres nécessitent un examen qualifié. Cet exemple technique ne permet aucune détermination sur ces obligations et n'autorise aucune action d'achat.
Carte d'itinéraire fictive
Les identités explicites suivantes sont des entrées illustratives et non une véritable configuration client. Les identités et les rôles responsables sont hypothétiques et non des approbations des clients ou des messages fournis. Aucun test de signature ni livraison réseau n’a été effectué.
- Notification Erp : propriétaire du service ERP ; Depuis erp.factory.test ; enveloppe et signataire DKIM erp.factory.test.
- Système d'approvisionnement : responsable de la technologie des achats ; Depuis buy.factory.test ; enveloppe et signataire DKIM Procurement-vendor.test.
- Portail fournisseurs : responsable de l'intégration des fournisseurs ; De fournisseurs.factory.test ; enveloppe et signataire DKIM supplier.factory.test.
Résoudre une divergence de chemin de lot
Supposons qu'un test ERP déclenché manuellement réussisse, mais que le lot d'approvisionnement du jour au lendemain utilise un autre relais qui insère une notification substantielle après la signature complète. Gardez la procédure d'approvisionnement non résolue et comparez l'en-tête reçu et les preuves de contenu signé avec les journaux d'application. La modification de la clé de l'itinéraire manuel ne résoudrait pas une modification de l'itinéraire par lots. Il s’agit de conditions supposées et non d’un diagnostic d’une usine réelle.
RFC 6376 sections 3.4, 3.5 et 3.7 expliquer la canonisation, les balises de signature et les hachages de messages. RFC 9989 sections 4.4, 5.3.5 et 5.4 décisions distinctes en matière d’alignement et de récepteur. Une autre authentification alignée peut affecter le verdict d'un message, tandis que p=reject le déploiement nécessite DKIM valide en vertu des sections 7.4 et 8 plutôt que SPF seul. Aucun bon de commande, changement de signataire ou test de courrier de production n'a été effectué.