[ MSP, API ja integraatiot ]

PSA-integraatiovaatimukset MSP-todennuspalvelulle

Määritä asiakkaan elinkaari, tietorajat ja hyväksyntätodisteet ennen PSA-integraation valitsemista.

EmailAuth -tutkimusryhmä · 3 min lukuaika

[Avainkohdat]

  • Määritä asiakkaan elinkaari, tietorajat ja hyväksyntätodisteet ennen PSA-integraation valitsemista.
  • Erillinen palvelusopimus, kohteen kartoitus, vikojen testaus ja poistumisen hyväksyntä; toimiva API-kutsu ei muodosta koko palvelua.
Tällä sivulla

Ammattimaisten palveluiden automaatiointegraatio yhdistää tekniset havainnot kaupallisiin ja palveluvastuisiin. Sen tulee tunnistaa, kuka saa työtä, mitä asiakassopimusta sovelletaan ja mitä tapahtuu, kun suhde päättyy. API-yhteys ei yksin tarjoa näitä vastauksia.

Aloita palvelusopimuksesta

Määritä hallitut verkkotunnukset, lähetyspalvelut, valvontakattavuus, valtuutuksen muuttaminen ja eskalointitunnit. Erota raporttien lukuoikeus luvasta muuttaa DNS tai kommunikoida asiakkaan yhteyshenkilöiden kanssa. Nimeä asiakassponsori, MSP-palvelun omistaja, tekninen operaattori, muutoksen hyväksyjä ja tietosuojayhteyshenkilö.

Ilmoita vastuut, joita voidaan todella mitata: kelpuutetun tapahtuman kuittaus, lähettäjärekisterin ylläpito, ratkaisemattomien poikkeusten tarkastelu ja todisteiden yhteenvedon toimittaminen. Älä lupaa, että jokainen viesti kulkee tai saapuu postilaatikkoon. DMARC linjaus alla RFC 9989 on vain osa sähköpostin käsittelyä ja raportin kattavuus RFC 9990 ei ole täydellinen postilaskenta.

Rakenna elinkaari vastaanottoporteilla

Käytä erillisiä hyväksymispäätöksiä valtuutukseen, kartoitukseen, virhetestaukseen, toimintoihin, muutoksiin ja poistumiseen. Oletetaan, että API-luku onnistuu, mutta hyväksytty palvelujono on poistettu eikä korvaavaa omistajaa ole vahvistettu. Asiakirjaliitännät suoritettu; toiminnallista reititystä ei ole. Pidä automaattista lähetystä, kunnes kohdekartta ja vastuullinen omistaja on hyväksytty ja testattu.

Asiakas voi erikseen hyväksyä raportin lukemisen samalla, kun hän ei saa asiakasilmoituksia ja DNS muutoksia. Älä laajenna apurahaa vain saadaksesi lentäjän tuntemaan itsensä täydelliseksi. Nämä ovat hypoteettisia aukkoja, eivät toimitettua elinkaaren runbookia, suoritettua täydellisyyden tarkistusta tai kaupallista palvelusopimusta. Määritä mikä tahansa vastauskohde sen kalenterin, vakavuuden, riippuvuuksien ja keskeytyssääntöjen mukaan ennen kuin lupaat sen.

Kartoita tekniset tapahtumat palvelurekistereihin

Ylläpidä asiakas-, toimipaikka-, sopimus-, palvelu-, jono-, prioriteetti- ja tilakartoitukset versioituina kokoonpanoina. Ratkaise jokainen arvo valitun PSA:n nykyisen liitännän mukaan. Esimerkiksi Autotask dokumentoi lippukentät ja kokoonpanosta riippuvat vaatimukset; näiden sääntöjen ei voida olettaa soveltuvan samalla tavalla muihin julkisiin palveluihin.

Sisällytä vakaa ulkoinen korrelaatioavain, kohdetietueen tunnus ja todisteiden viite. Säilytä tarkkailuaika erillään lipun luomisajasta. Minimoi viedyt tiedot: tekninen yhteenveto ja rajoitettu todistelinkki ovat yleensä sopivampia kuin koko viestin sisältö. Tarkista, ketkä voivat nähdä muistiinpanoja ja liitteitä, mukaan lukien yhteishallitut asiakaskäyttäjät.

Hyväksy vikakäyttäytyminen osana tuotetta

Pilotin tulee kattaa päällekkäinen tapahtuma, epävarma luominen, peruutettu tunniste, poistettu jono, suljettu asiakas ja luvaton vuokraajaviittaus. Aseta rajalliset uudelleenyritykset ohimeneville vikoille ja henkilökunnallinen palautusjono pysyville häiriöille. Täsmätä ennen kuin yrität uudelleen toimintoa, joka on ehkä jo onnistunut.

Vaadi vahvistus ennen teknisen tapahtuman sulkemista. PSA-tilan muutos ei osoita palautettua todennusta. Säilytä inhimilliset päätökset ja selitä, milloin integraatio voi avautua uudelleen tai liittyä siihen ennätys. Tarkista asiakasilmoitusten sivuvaikutukset ennen automaattisten päivitysten käyttöönottoa.

Tee offboardista palautuva mahdollisuuksien mukaan

Lopeta uusi käsittely ja reititys sovitun suunnitelman mukaisesti, vie todisteet valtuutetulle vastaanottajalle ja peruuta integraatiokäyttö. Tunnista säilytysvelvollisuudet ja poistohyväksynnät erikseen. Älä poista toimivia DNS tietueita automaattisesti laskutuksen tilan muuttuessa: nämä tietueet voivat silti suojata asiakkaan postia. Palvelun keskeyttäminen, luvan peruuttaminen ja teknisen kokoonpanon muutos ovat erillisiä päätöksiä.

Tämä on integrointivaatimusmenetelmä, ei todiste siitä, että EmailAuth tukee tiettyä PSA:ta. Hyväksyminen edellyttää todellista dokumentaatiota, valtuutettujen vuokralaisten testejä ja vastuullista asiakkaan kirjautumista.

[ Takeaway ]

Erillinen palvelusopimus, kohteen kartoitus, vikojen testaus ja poistumisen hyväksyntä; toimiva API-kutsu ei muodosta koko palvelua.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

Valitse roolisi ja seuraa käytännön toimia.

IT / Mail Admin

Versio elinkaari

Kartaukset ja palvelutilat muuttuvat asiakassuhteen aikana.

Seuraavat vaiheet

  1. Jatka kartoitusversioita.
  2. Testi peruutettu ja puuttuvat kohteet.
  3. Yhdistä tekninen luovutus.

CISO / SecOps

Tarkista pääsyraja

Kaupalliset järjestelmät voivat paljastaa teknisiä todisteita laajasti.

Seuraavat vaiheet

  1. Tarkista muistiinpanon ja liitteiden näkyvyys.
  2. Vaadi rajoitettu käyttöoikeus.
  3. Hyväksy säilytys- ja vientivastaanottajat.

Perustaja / ei-tekninen

Myy määritelty vastuu

Palvelulupaus vaatii mitattavaa työtä ja selkeitä riippuvuuksia.

Seuraavat vaiheet

  1. Hyväksy laajuus ja kattavuus.
  2. Erottele tuki muutosviranomaisesta.
  3. Tarkista irtautumisvelvollisuudet.

[ UKK ]

Usein kysytyt kysymykset

Mitä tulee sopia ennen API-käyttöä?

Asiakkaan laajuus, vastuut, luvat, eskaloinnin kattavuus ja todisteiden käsittely.

Lupaako tämä opas vasteaikaisen SLA:n?

Ei. Kaikki todellinen kohde tarvitsee hyväksytyn palvelusopimuksen, jossa määritellään kattavuus, vakavuus, kellot, tauot ja riippuvuudet.

Voiko yksi kenttäkartta palvella jokaista PSA:ta?

Ei. Vahvista valittu järjestelmä ja asiakaskokoonpano.

Miksi testata poistettua jonoa?

Se paljastaa pysyviä kartoitusvirheitä, jotka onnellinen polku aiheuttaa testin epäonnistumisia.

Pitäisikö jäädyttämisen poistaa DNS tietueet?

Ei automaattisesti. Postin jatkuvuus ja DNS muutokset tarvitsevat oman hyväksytyn suunnitelmansa.

Todistaako lipun sulkeminen palautumisen?

Ei. Vaadi asianomaiseen palveluun soveltuvaa teknistä näyttöä.

Mitä offboardingin pitäisi tuottaa?

Hyväksytyt viennit, käyttöoikeuden peruutuskuitit, säilytyspäätökset ja vastuullinen luovutus.

Mitä hyväksymisesimerkit osoittavat?

Ne kuvaavat erillisiä yhteyksiä, reititystä ja viranomaispäätöksiä. Reaaliaikaista palvelun suorituskykyä tai elinkaaren täydellisyystestiä ei ole vahvistettu.

[ Lähteet ]

Lähteet

  1. Autotask REST API: Liput

    Osat Entiteetin URL-osoitteet ja suhteet · Ehdot ja vaatimukset · Erityiset kenttäattribuutit

  2. RFC 9989 : Verkkotunnuspohjainen viestien todennus, raportointi ja vaatimustenmukaisuus

    Osat §4.4 · §5.3.5 · §5.4 · §7.4 · §8

  3. RFC 9990 : DMARC Aggregate Reporting

    Osat §3.1 · §3.1.1.4 · §3.1.2 · §3.5.1 · §3.5.4 · §4 · §7 · §8

[ Sanasto ]

Sanasto

PSA
Asiantuntijapalveluiden automaatiojärjestelmä, jota käytetään asiakaspalvelutyön järjestämiseen.
Vastaanottoportti
Todisteet vaaditaan ennen kuin työnkulku siirtyy seuraavaan vaiheeseen.

Yrityksen alkuperä

Miksi parhaat rahoituslaitokset ja hallitukset lopettivat sähköpostin suojauksen hallintapaneelinsa.

Perinteiset sähköpostin todennusalustat myyvät sinulle kojelaudan ja pyytävät insinöörejäsi tekemään työtä. Korkeiden panosten ympäristöissä manuaalinen valvonta tarkoittaa viivästynyttä täytäntöönpanoa, konfiguraatioiden siirtymistä ja valvomattomia varjoalueita.

EmailAuth on agentti sähköpostin alkuperäalusta. Agenttimme valvovat p=reject, pidä kolmannen osapuolen lähettäjät kohdakkain ja siirrä verkkotunnuksesi täyteen RFC 9989 noudattaminen, uusi DMARC standardi, jossa on in-the-loop -tarkastettavuus.

hallitukset Suuret yritykset Tason 1 rahoituslaitokset

SaaS · Dedikoitu vuokrasopimus · Ilmarakoinen on-prem · BYOK-salaus

Tietokanta