Produksjon av e-postbeholdning begynner ofte med ansattes post og savner ERP-planleggeren, innkjøpsverktøyet og leverandørportalen. Disse applikasjonene kan kjøres under tjenestekontoer, sendes bare etter en batch over natten, eller bruke et relé som eies av et anleggsteam. Autentiseringsarbeid må følge produksjonsprosessen uten å forstyrre den.
Kartlegg applikasjon, relé og eier
Tilordne ERP-varsler til eieren av ERP-tjenesten, kjøpsforespørsler til anskaffelsesteknologi og leverandørportalpost til leverandørintegrasjonsleddet. Registrer trigger, anlegg eller forretningsenhet, leverandørkonto, relé, forfatterdomene og signering velger. Inkluder planlagte jobber og eksepsjonelle prosesser som omarbeid, kansellerte bestillinger og gjenoppretting av leverandørkontoer der de bruker forskjellige ruter.
Bruk en testarbeidsordre og en tydelig uforpliktende kjøpsforespørselsprøve. Generer aldri en reell leverandørforpliktelse bare for å samle inn en e-postoverskrift. Be anskaffelse om å bekrefte at testen ikke kan godkjenne utgifter eller gå inn i en live oppfyllelseskø. Unngå konfidensielle styklister, priser eller bankdetaljer i det beholdte meldingseksemplet.
Spor det endelige signeringspunktet
En ERP kan sende gjennom et internt relé som legger til et varsel før en ekstern gateway signerer. En annen rute kan signere først og deretter få meldingen endret. Kartlegg sekvensen i stedet for å anta at konfigurering av en nøkkel i én konsoll dekker hele banen. En vesentlig bunntekst som settes inn etter signering endrer den kanoniserte signerte kroppen og kan ugyldiggjøre en signatur med hele kroppen. Kanonisering kan tolerere noen formateringsforskjeller, så diagnostiser de faktiske signerte bytene og signaturinnstillingene i stedet for å behandle hver endring likt. Ingen bunnteksttest ble utført her.
Den fiktive innkjøpstjenesten bruker buy.factory.test som From og procurement-vendor.test som signer. Selv forutsatt en kryptografisk gyldig signatur, feiler disse hypotetiske domenene strengt DKIM justering; dette er ikke et observert verifikasjonsresultat eller et fullstendig DMARC kjennelse. Bekreft det tiltenkte domenet og den faktiske tjenesteleieren, og evaluer deretter støttede konfigurasjonsendringer. Ikke fiks misforholdet ved å gi et anleggsomfattende relé ubegrenset bruk av alle bedriftsdomene.
Hold bedriftsgodkjenning atskilt
Autentisering fastslår ikke at en kjøpsforespørsel er godkjent, at en leverandørkonto er ekte eller at en betalingsdestinasjon er korrekt. Opprettholde anskaffelsessystemets autorisasjons- og betalingsverifiseringskontroller uavhengig. Et autorisert, men kompromittert program kan sende en godt autentisert ondsinnet instruksjon.
For aksept, utløs den virkelige testjobben, behold en mottatt prøve og avstem den med applikasjonslogger. Sammenlign normale og unntaksjobber i stedet for å ta en enkelt manuell sending som bevis. Hvis systemet er batchdrevet, observer en passende syklus under eierens godkjenning; en stille time er ikke bevis på at søknaden aldri sender.
Endring rundt operasjonelle begrensninger
Planlegg vedlikehold med anlegget og ERP-eiere. Dokumenter en gjenopprettingsbane for den spesifikke tjenesten, bevar godkjent konfigurasjonsbevis og overvåk ventende jobber etter endringen. Rapporter en avsender som uløst når eieren eller leietakeren er ukjent i stedet for å gi spekulative tillatelser. Krav til kontrakt, konfidensialitet, eksportkontroll og journalføring krever kvalifisert gjennomgang. Dette tekniske eksemplet tar ingen beslutning om disse forpliktelsene og tillater ingen kjøpshandlinger.
Fiktivt rutekart
Følgende eksplisitte identiteter er illustrative innganger, ikke ekte kundekonfigurasjon. Identitetene og ansvarlige roller er hypotetiske, ikke kundegodkjenninger eller leverte meldinger. Ingen signeringstest eller nettverkslevering ble utført.
- Erp-varsling: ERP-tjenesteeier; Fra erp.factory.test; konvolutt og DKIM signer erp.factory.test.
- Anskaffelsessystem: Anskaffelsesteknologisk leder; Fra buy.factory.test; konvolutt og DKIM underskriver anskaffelse-leverandør.test.
- Leverandørportal: Leder for leverandørintegrering; Fra suppliers.factory.test; konvolutt og DKIM signer suppliers.factory.test.
Løs et batch-baneavvik
Anta at en manuelt utløst ERP-test består, men innkjøpsbatchen over natten bruker et annet relé som setter inn et vesentlig varsel etter full body-signering. Hold anskaffelsesruten uløst og sammenlign den mottatte overskriften og signerte innholdsbevis med søknadsloggene. Endring av nøkkelen til den manuelle ruten ville ikke adressere en endring på batchruten. Dette er antatte forhold, ikke en diagnose av en faktisk plante.
RFC 6376 avsnitt 3.4, 3.5 og 3.7 forklare kanonisering, signatur-tagger og meldings-hasher. RFC 9989 avsnitt 4.4, 5.3.5 og 5.4 separate innrettings- og mottakeravgjørelser. Annen justert autentisering kan påvirke en meldingsdom, mens p=reject utrulling krever gyldig DKIM under avsnitt 7.4 og 8 i stedet for SPF alene. Ingen innkjøpsordre, underskriverendring eller produksjonsposttest ble utført.