Selvitä, mitä turvallisuuspalvelu tekee reitilläsi
Havaintopisteen nimi sähköpostin suojauskonsolissa ei tarkoita, että palvelu lähettää organisaatiosi viestit tai allekirjoittaa ne verkkotunnuksellasi. Aloita todellisuudessa käyttöönotetusta integraatiosta. Tunnista postilaatikon alusta, saapuvan liikenteen tarkistusmenetelmä, lähtevän postin tarkistuksen laajuus ja mahdollinen erillinen SMTP välitys. Tämä artikkeli tarjoaa reitin tunnistamis- ja vahvistusmenetelmän. Saatavilla olevat ensimmäisen osapuolen todisteet eivät vahvista yleistä havaintopistettä SPF sisällyttää tai asiakkaan verkkotunnus DKIM asetukset.
Nykyinen WP-dokumentaatio docs.perception-point.io -sivustolla on FortiMail Workspace Securityn nimimerkki. Sen Microsoft 365 lähtevän yhteydenottosivu kuvaa lähtevän skannauksen Microsoft 365 API-yhteyden kautta, joka on lisätty olemassa olevaan saapuvaan integraatioon. Tämä dokumentoitu toiminto on turvatarkastus, ei todiste uudesta SMTP lähetystunnuksesta. Varmista, että nämä tuoteohjeet koskevat käyttöönottoa, ennen kuin käytät niiden ohjaimia.
Piirrä reitti ja määritä jokainen vastuu
Luo lyhyt kulku sovelluksesta tai postilaatikosta lopulliselle vastaanottajalle. Tallenna jokaiselle komponentille, luoko se viestin, lähettääkö se SMTP , välittääkö se SMTP , allekirjoittaako se DKIM , skannaako se kopion vai tekeekö se vastaanottajapuolen toimituspäätöksen. Pyydä alustan omistajia toimittamaan todisteita kokoonpanosta sen sijaan, että luottaisit tuotteen logoon sähköpostin alatunnisteessa.
Erottele vähintään kolme kysymystä. Mikä järjestelmä välittää viestin vastaanottajalle? Mikä verkkotunnus allekirjoittaa sen? Mikä turvallisuuspalvelu sen tarkastaa? Yhdellä tuotteella voi olla useampi kuin yksi rooli, mutta nämä roolit on esitettävä. Jos viesti on tavallista Microsoft 365 lähtevää postia, joka on havaittu API:n kautta, älä lisää yhdyskäytävän ulkopuolista saapuvan IP-aluetta lähettäjäkäytäntöösi vain siksi, että yhdyskäytävä suojaa vuokralaista.
Erota myös organisaation luomat viestit tietoturvapalvelun itsensä luomista ilmoituksista. Tuotteen lähettämä raportti tai hälytys voi käyttää eri lähettäjää ja reittiä työntekijän sähköpostista. Älä käytä ilmoituksen otsikoita todennustodistuksena liikekirjeenvaihdossa tai päinvastoin.
Tulkitse skannaustodisteita sen rajoissa
Dokumentoidun Microsoft 365 -reitin osalta palveluntarjoaja kuvaa lähtevän lähteen tarkistuksen ja lähtevän yhteyden laajuuden tarkistukset, joiden tulokset näkyvät Tarkistukset-sivulla. Siinä todetaan, että lähtevien viestien tarkistus ei estä lähteviä viestejä tai tarjoa lähteviä karanteenia. The käyttöönottomenettely varoittaa myös, että valittu laajuus voi vaikuttaa olemassa oleviin tarkistusmäärityksiin. Pyydä suojauksen järjestelmänvalvojaa tarkistamaan laajuus ennen kuin muutat mitään.
Nämä havainnot voivat osoittaa, että viesti on skannattu nimetyn integroinnin sisällä. Ne eivät vahvista SPF valtuutusta, joka on voimassa DKIM -allekirjoitus tai DMARC linjaus ulkoisessa vastaanottimessa. Säilytä skannaustulokset ja vastaanottimen tulokset erillisissä todistekentissä, jotta puhdas tuomio ei korvaa todennusta.
The tuomio-otsikko-dokumentaatio sanoo, että lueteltuja X-PERCEPTION-POINT-otsikoita ei lisätä Microsoft 365 tai Google Workspace API -tarkistuksessa eikä niitä lisätä lähteviin sähköposteihin. Niiden puuttuminen ei siis sinänsä ole todiste lähtevän skannauksen epäonnistumisesta. Niiden läsnäolo jossain muussa viestissä ei myöskään muuta niitä ulkoisen vastaanottajan DMARC päätökseksi.
Määritä todellinen lähettäjä vasta tunnistamisen jälkeen
Kun SMTP lähettäjä ja allekirjoituspalvelu ovat tiedossa, käytä kyseisen palvelun soveltuvaa ensimmäisen osapuolen määritysmenettelyä. Hanki sen myöntämät verkkotunnuksen tietueet ja aktivointitodisteet. Jos vahvistettu käyttöönotto todella käyttää ylimääräistä lähtevää välitystä, pyydä välittäjän nykyiset toimialueen todennus- ja allekirjoitusohjeet kyseiselle vuokraajalle sen sijaan, että ekstrapoloisit saapuvan tietoturvaoppaan.
SPF valtuuttaa sovellettavan SMTP identiteetin ja sillä on tietueenvalinta- ja DNS-hakurajoitukset. RFC 7208. DKIM tunnistaa allekirjoitustoimialueen ja valitsin alla RFC 6376. DMARC liittää välitettävän todetun identiteetin näkyvään From-verkkotunnukseen RFC 9989. IP-aloitusluettelo, API-suostumus tai onnistunut uhkatarkistus eivät korvaa näitä tarkistuksia.
Vältä laajaa sallittujen luetteloa diagnostisena pikakuvakkeena. Se voi muuttaa paikallista suojauskäsittelyä samalla, kun se peittää alkuperäisen vian. Jos ongelma on vastaanottajan hylkääminen, säilytä hylkäyskoodi, aika, tarkoitettu vastaanottajajärjestelmä ja redaktoitu viestin tunniste. Jos ongelma liittyy tietoturvaan, tarkista tarkistuksen laajuus ja vastaava tarkistustietue. Ratkaise tietty vika sen sijaan, että käsittelisit jokaista toimitusongelmaa SPF muutospyyntönä.
Havaintopisteen käyttöönottolaskentataulukko
Täytä tämä taulukko ennen todennustietueiden ehdottamista:
- Vuokralaisessa ja sopimuksessa näkyvä tuotteen nimi: ____; sovellettavat asiakirjat: ____.
- Postilaatikon alusta, vuokraaja ja käyttöönottoalue: ____.
- Saapuva integrointimenetelmä: ____; lähtevän liikenteen tarkistusmenetelmä ja laajuus: ____.
- Viestejä luova sovellus ja omistaja: ____; SMTP lähettäjä tai -välitys: ____.
- DKIM -allekirjoituspalvelu ja omistaja: ____; todisteet sen yhdistämisestä reitille: ____.
- Ilmoitus vs. yritysviestien luokittelu: ____.
- Kontrolloitu testiviesti-ID ja UTC-aika: ____; vastaava skannaustietue: ____.
- Ulkoinen vastaanotin, näkyvä Lähettäjä ja kirjekuoren verkkotunnus: ____.
- DKIM d= ja s=: ____; luotetut SPF , DKIM ja DMARC -tulokset: ____.
- Ehdotettu DNS muutos ja todellinen lähettäjän lähde: ____; oletukset, joita ei tueta: ____.
- Pilottipäätös, palautuksen omistaja ja ihmisen arvioija: ____.
Jos SMTP lähettäjä tai allekirjoituksen omistaja on tuntematon, laskentataulukko ei ole valmis DNS muutokseen. Jatka vain luku -selvitystä ja pyydä vastaavalta järjestelmänvalvojalta puuttuvat reitin todisteet.
Kuvitteellinen diagnoosi puuttuvista tuomiootsikoista
Vain kuvitteellinen esimerkki: Summit Design mahdollistaa lähtevän API-skannauksen ja lähettää ohjatun viestin. Sen järjestelmänvalvoja ei näe X-PERCEPTION-POINT-tuomion otsikkoa ja olettaa, että viesti on ohitettu. Dokumentoitu otsikkorajoitus selittää, miksi tämä odotus ei sovellu tälle reitille. Ryhmä tarkistaa viestin vastaavan skannausmerkinnän suojauksen kattavuuden varalta ja tutkii sitten erikseen ulkoisen vastaanottajan todennustulokset todellisen postilaatikon lähettäjän osalta.
Tietoturvapalvelun IP-osoitteiden lisääminen organisaation SPF käytäntöön ei vastaisi kumpaankaan kysymykseen ilman näyttöä siitä, että kyseiset IP-osoitteet välittävät lähtevän viestin. Tiimi jättää DNS ennalleen, kun se vahvistaa reitin. Summit-käyttöönottoa, tarkistuskonsolia, DNS vyöhykettä tai vastaanotettua viestiä ei testattu tälle käsikirjoitukselle.
Laajuus ja jäljellä olevat portit
Alkuperäinen laaja lähettäjän määritysaihe pysyy odotustilassa. Tämä ehdokas tunnistaa rajan dokumentoidun skannauksen ja vahvistamattomien asiakastoimialueen lähetysominaisuuksien välillä; se ei väitä, että nämä ominaisuudet puuttuvat yleisesti. Todellinen tuotteen soveltuvuus, reititys ja allekirjoitusomistus, vuokralaisen tarvittaessa antamat ohjeet, reaaliaikainen skannaus ja vastaanottotodistus, suoritettu tarkistus, ihmisen pk-yrityshyväksyntä ja julkaisu odottavat.
Tallenna skooppitehoste ennen skannauksen muokkaamista
Dokumentoidun Microsoft 365 API-integraation osalta toimittaja varoittaa, että uusi toimialue-, ryhmä- tai käyttäjävalikoima korvaa nykyisen saapuvan, sisäisen ja lähtevän alueen. Olemassa olevan sisäisen saapuvan integroinnin yhteydessä valinta vaikuttaa vain lähtevän liikenteen kattavuuteen. Käsittele tätä tietoturvapäätöksenä, joka edellyttää sen omistajaa, ei todennuskorjausta.
Erillinen viestien hyväksyminen käytännön käyttöönotosta
Ohjattu kohdistettu SPF tulos voi tyydyttää sanoman arvioinnin, mutta se ei yksin oikeuta siirtämään koko toimialuetta hylättäväksi. RFC 9989 Kohta 7.4 edellyttää kelvollista DKIM ää verkkotunnusten julkaisemiseen p=reject ja varoittaa epäsuoran postin yhteentoimivuudesta. Inventoi kaikki lailliset lähettäjät ja epäsuorat reitit ennen kuin käytännön omistaja hyväksyy täytäntöönpanon. Tälle artikkelille ei suoritettu DNS muutosta, vuokraajatoimintoa tai vastaanotettujen viestien testiä.