Fremstilling af e-mail-beholdninger begynder ofte med medarbejdermail og savner ERP-planlæggeren, indkøbsværktøjet og leverandørportalen. Disse applikationer kan køre under servicekonti, sendes kun efter en batch natten over eller bruge et relæ, der ejes af et fabriksteam. Autentificeringsarbejde skal følge produktionsprocessen uden at forstyrre den.
Kortlæg applikation, relæ og ejer
Tildel ERP-meddelelser til ERP-tjenesteejeren, købsanmodninger til indkøbsteknologi og leverandørportalmail til leverandørintegrationsleddet. Registrer trigger, anlæg eller forretningsenhed, udbyderkonto, relæ, forfatterdomæne og underskrift vælger. Inkluder planlagte job og ekstraordinære processer såsom omarbejdning, annullerede ordrer og leverandørkontogendannelse, hvor de bruger forskellige ruter.
Brug en testarbejdsordre og en klart uforpligtende købsanmodningsprøve. Generer aldrig en reel leverandørforpligtelse blot for at indsamle en e-mail-header. Bed indkøb om at bekræfte, at testen ikke kan godkende udgifter eller komme ind i en live-opfyldelseskø. Undgå fortrolige styklister, priser eller bankoplysninger i den bevarede meddelelsesprøve.
Spor det endelige signaturpunkt
En ERP kan sende gennem et internt relæ, der tilføjer en meddelelse, før en ekstern gateway tegner. En anden rute kan underskrive først og derefter få beskeden ændret. Kortlæg sekvensen i stedet for at antage, at konfiguration af en nøgle i én konsol dækker hele stien. En væsentlig sidefod indsat efter underskrivelse ændrer den kanoniserede underskrevne krop og kan ugyldiggøre en helkropssignatur. Kanonisering kan tolerere nogle formateringsforskelle, så diagnosticer de faktiske signerede bytes og signaturindstillinger i stedet for at behandle hver ændring ens. Ingen sidefodstest blev udført her.
Den fiktive indkøbstjeneste bruger buy.factory.test som From og procurement-vendor.test som underskriver. Selv hvis man antager en kryptografisk gyldig signatur, fejler disse hypotetiske domæner strengt DKIM justering; dette er ikke et observeret verifikationsresultat eller et komplet DMARC dom. Bekræft det tilsigtede domæne og den faktiske tjenestelejer, og evaluer derefter understøttede konfigurationsændringer. Ret ikke uoverensstemmelsen ved at give et relæ for hele fabrikken ubegrænset brug af hvert virksomhedsdomæne.
Hold forretningsgodkendelse adskilt
Autentificering fastslår ikke, at en købsanmodning er godkendt, at en leverandørkonto er ægte, eller at en betalingsdestination er korrekt. Vedligeholde indkøbssystemets autorisations- og betalingsverifikationskontroller uafhængigt. En autoriseret, men kompromitteret applikation kan sende en velgodkendt ondsindet instruktion.
For accept skal du udløse det rigtige testjob, beholde en modtaget prøve og afstemme den med applikationslogfiler. Sammenlign normale og undtagelsesjob i stedet for at tage en enkelt manuel afsendelse som bevis. Hvis systemet er batchdrevet, skal du observere en passende cyklus under ejerens godkendelse; en stille time er ikke et bevis på, at ansøgningen aldrig sender.
Ændring omkring operationelle begrænsninger
Planlæg vedligeholdelse med anlægget og ERP-ejere. Dokumenter en gendannelsessti for den specifikke tjeneste, bevar godkendt konfigurationsbevis og overvåg afventende job efter ændringen. Rapportér en afsender som uløst, når dens ejer eller lejer er ukendt i stedet for at give spekulative tilladelser. Krav til kontrakt, fortrolighed, eksportkontrol og registrering kræver kvalificeret gennemgang. Dette tekniske eksempel tager ikke stilling til disse forpligtelser og tillader ingen købshandlinger.
Fiktivt rutekort
Følgende eksplicitte identiteter er illustrative input, ikke reel kundekonfiguration. Identiteterne og de ansvarlige roller er hypotetiske, ikke kundegodkendelser eller leverede meddelelser. Ingen signeringstest eller netværkslevering blev udført.
- Erp-meddelelse: ERP-tjenesteejer; Fra erp.factory.test; kuvert og DKIM underskriver erp.factory.test.
- Indkøbssystem: Indkøbsteknologisk leder; Fra buy.factory.test; konvolut og DKIM underskriver indkøb-leverandør.test.
- Leverandørportal: Supplier integration lead; Fra suppliers.factory.test; kuvert og DKIM underskriver leverandører.fabrik.test.
Løs en batch-sti-uoverensstemmelse
Antag, at en manuelt udløst ERP-test består, men indkøbsbatchen natten over bruger et andet relæ, der indsætter en væsentlig meddelelse efter fuldkropssignering. Hold indkøbsruten uafklaret, og sammenlign dens modtagne header og underskrevne indholdsbeviser med ansøgningsloggene. Ændring af den manuelle rutes nøgle ville ikke adressere en ændring på batch-ruten. Disse er forudsatte tilstande, ikke en diagnose af en egentlig plante.
RFC 6376 afsnit 3.4, 3.5 og 3.7 forklare kanonisering, signatur-tags og besked-hash. RFC 9989 afsnit 4.4, 5.3.5 og 5.4 separate tilpasnings- og modtagerbeslutninger. Anden tilpasset godkendelse kan påvirke en meddelelsesdom, mens p=reject implementering kræver gyldig DKIM i henhold til afsnit 7.4 og 8 i stedet for SPF alene. Ingen indkøbsordre, underskriverændring eller produktionsposttest blev udført.