[ Yritystoiminta ]

Hallitse todennusta eri DNS omistajien tytäryhtiöissä

Koordinoi todennus tytäryhtiöiden välillä olettamatta, että keskuskäytäntö vastaa paikallista DNS -hallintaa.

EmailAuth -tutkimusryhmä · 3 min lukuaika

[Avainkohdat]

  • Koordinoi todennus tytäryhtiöiden välillä olettamatta, että keskuskäytäntö vastaa paikallista DNS -hallintaa.
  • Säilyttää jokaisen tytäryhtiön auktoriteetin ja todisteiden rajat; ryhmänlaajuinen näyte ei voi sulkea puuttuvaa paikallista testiä.
Tällä sivulla

Konserninlaajuinen sähköpostikäytäntö voi kuvata halutun tuloksen, kun taas kukin tytäryhtiö hallitsee eri osaa toteutuksesta. Yksi tiimi voi omistaa rekisteröinnin, toinen voi käyttää DNS ja paikallinen toimittaja voi allekirjoittaa sovelluspostin. Tehokas koordinointi alkaa näiden viranomaisten kartoittamisesta ja vertailukelpoisten todisteiden keräämisestä, ei olettamalla, että päätoimipaikka voi muuttaa kaikkia toimialueita.

Rakenna verkkotunnus ja palvelukartta

Ilmoita kunkin tytäryhtiön oikeus- tai yrityshenkilö, verkkotunnus, virallinen DNS operaattori, rekisterinpitäjän yhteyshenkilö, paikallinen yrityksen omistaja ja tapauksen yhteyshenkilö. Yhdistä jokainen lähetyspalvelu sen tiliin, tarkoitukseen, kriittisyyteen, toimialueelta, kirjekuoriverkkotunnukseen, DKIM verkkotunnus, valitsin ja viimeinen hyväksytty testi. Säilytä tarkat nimet sen sijaan, että luottaisit lyhenteisiin, jotka voidaan sekoittaa samannimisten yritysten välillä.

DNS delegation divides administrative responsibility at zone boundaries. Keskitetysti ylläpidetty ylätason verkkotunnus ei tarkoita, että jokaista lapsialuetta hallinnoi keskustiimi. RFC 1034 kuvaa vyöhykkeet ja delegoinnin; Käytä todellisia arvovaltaisia ​​tietueita ja käytä tietueita toteutuksen määrittämiseen. DNS -käsitteet. Rekisteröinnin, DNS toiminnan ja palvelun hyväksynnän tulee olla erilliset inventaariokentät.

Tee yhteinen todistelusopimus

Pyydä jokaiselta paikalliselta tiimiltä sama vähimmäistodiste: nykyinen kokoonpano, valtuutetun edustajan viesti, luotettavan vastaanottajan todennustulokset, hyväksyntäviittaus ja palvelusta vastaava henkilö. Kirjaa ylös havaintoaika ja reitti. Älä laske puuttuvan tytäryhtiön keskiarvoa raportoimalla koko ryhmän onnistumisprosenttia vain vastanneille verkkotunnuksille.

DMARC politiikan löytö ja tunnisteen kohdistus noudata protokollasääntöjä, älä yrityksen omistajuuskaavioita. Erilliset rekisteröidyt verkkotunnukset eivät jaa käytäntöjä vain siksi, että sama emoyhtiö omistaa ne. Aliverkkotunnuksen käyttäytyminen on arvioitava sovellettavien käytäntöjen löytämissääntöjen ja -tietueiden mukaisesti. RFC 9989. Dokumentoi jokaisen testatun identiteetin tarkka tehokas käytäntö sen sijaan, että kopioit päämajan johtopäätöksen.

Pidä kahden tytäryhtiön todisteet erillään

Oletetaan, että tytäryhtiöllä A on voimassa oleva valtuutettu testi laskutusreitilleen ja tytäryhtiö B toimittaa kopioidun A-näytteen, koska molemmat käyttävät samaa palveluntarjoajaa. B:n yritys- ja DNS omistajat on nimetty, mutta sen todellinen asiakastili, henkilöllisyydet ja reitti jäävät vahvistamatta. Jaettu palveluntarjoajatunniste ei anna A:n viestitodisteita koskemaan B:tä.

Ilmoita toinen kahdesta tytäryhtiöstä, jolla on nykyinen laskutusreittinäyte, ei konsernin laajuinen vahvistettu kattavuus. Pyydä B:n valtuutetulta operaattorilta sen omat konfiguraatiot ja edustavat viestit. Jos B ei pysty tuottamaan sitä nykyisen ikkunan aikana, säilytä nimetty todisteiden aukko sen sijaan, että laskeisit puuttuvat tiedot epäonnistumiseksi tai onnistumiseksi. Nämä ovat hypoteettisia raportointipäätöksiä, eivät todellisia tytäryhtiöitä, allekirjoituksia tai omistuspäätöksiä.

Koordinoi muutokset oikealla rajalla

Käytä yhtä muutostietuetta ryhmän tavoitteelle ja laajuudeltaan paikallisia muutoksia jokaiselle itsenäisesti toimivalle vyöhykkeelle tai palvelulle. Tietueen hyväksyjät, käyttöönottoikkunat, palautussuunnitelmat ja vahvistusten omistajat. Toimittajan kyky julkaista ennätys ei ole todiste, että sillä on lupa valita täytäntöönpanokäytäntösi. Pidä hätäyhteystiedot ajan tasalla ja määritä, kuinka keskusryhmä vastaanottaa todisteita kiireellisen paikallisen muutoksen jälkeen.

Raportoi edistymisestä verkkotunnuksen ja kriittisen palvelun mukaan nimenomaisin poikkeuksin ja määräajoin. Säilytä keskitetty näkymä, joka säilyttää paikallisen omistuksen sen sijaan, että korvaisi sen jaetulla postilaatikolla, jota kukaan ei katso. Tarkastele yritysostoja, myyntiä, toimittajien muutoksia ja palveluiden siirtymiä valtuuksien muuttuessa. Valmistuminen tarkoittaa, että jokaisella soveltamisalaan kuuluvalla tytäryhtiöllä on todisteilla tuettu tila ja vastuullinen toimija, ei vain johdonmukaisen näköinen politiikkaasiakirja.

Ilmoita puuttuvasta kattavuudesta piilottamatta sitä

Ilmoita soveltamisalaan kuuluvat alueet ja kriittiset työnkulut, osajoukko nykyisten todisteiden kanssa ja erityiset puutteet. Paikallisen omistajan nimi ei korvaa testiartefaktia. Anna jokainen aukko käyttäjälle, joka voi todella kerätä tai korjata sen.

[ Takeaway ]

Säilyttää jokaisen tytäryhtiön auktoriteetin ja todisteiden rajat; ryhmänlaajuinen näyte ei voi sulkea puuttuvaa paikallista testiä.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

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

IT / Mail Admin

Kartta todellinen DNS hallinta

Delegointi ja rekisteröinti ovat erilaisia.

Seuraavat vaiheet

  1. Tallenna arvovaltaiset toimijat
  2. Kerää vertailukelpoisia näytteitä
  3. Tarkista jokainen paikallinen muutos

CISO / SecOps

Ilmoita kattavuus rehellisesti

Puuttuvat tytäryhtiöt pysyvät näkyvissä.

Seuraavat vaiheet

  1. Määritä ryhmän nimittäjä
  2. Tarkista toimittajan valtuutus
  3. Seuraa todisteiden aukkoja

Perustaja / ei-tekninen

Säilytä paikallinen vastuu

Ryhmäpolitiikka tarvitsee paikallisia päättäjiä.

Seuraavat vaiheet

  1. Nimeä tytäryhtiösponsorit
  2. Rahaston todisteiden kerääminen
  3. Ratkaise kokonaisuuksien väliset poikkeukset

[ UKK ]

Usein kysytyt kysymykset

Tarkoittaako yrityksen omistus jaettua DMARC käytäntöä?

Ei. Arvioi kunkin todellisen verkkotunnuksen ja aliverkkotunnuksen käytäntöhaku.

Kuka hyväksyy toimittajan suorittaman DNS muutoksen?

Toimialueelle valtuutettu rooli ja muutos; toimittajan pääsy yksin ei ole hyväksyntää.

Voiko keskustiimi raportoida vain vastaavat tytäryhtiöt?

Se voi ilmoittaa tämän osajoukon, mutta sen on ilmoitettava nimittäjä ja puuttuva kattavuus.

Mitä jokaisen paikallisen todistepaketin tulee sisältää?

Nykyinen kokoonpano, laajennetut viestitodisteet, hyväksyntä, tarkkailuaika ja vastuulliset kontaktit.

Miltä esimerkkitytäryritykseltä puuttuu omat todisteet?

Tytäryhtiö B toimittaa A:n näytteen. Nimetyt omistajat ja jaettu tarjoaja eivät määritä B:n todellista reittitulosta.

Vahvistaako esimerkki todellisen DNS tai allekirjoitukset?

Ei. Se havainnollistaa todisteiden laajuutta ja raportoinnin kattavuutta ilman reaaliaikaisia DNS , allekirjoitus- tai omistajuustarkastuksia.

Pitäisikö kaikkien tytäryhtiöiden jakaa yksi käyttöönottoikkuna?

Vain jos niiden toiminta- ja hyväksymisrajoitukset tukevat sitä; säilyttää kattavat paikallissuunnitelmat.

Mitkä tapahtumat käynnistävät arvostelun?

Hankinnat, myynnit, DNS toimittajan vaihdot ja lähettäjien tai vuokralaisten siirrot.

[ Lähteet ]

Lähteet

  1. RFC 1034 -verkkotunnuskonseptit ja -toiminnot

    Osat §4.2 · §4.2.1 · §4.2.2

  2. RFC 9989 DMARC

    Osat §4.4 · §4.10.1 · §5.3.5 · §7.4 · §8

  3. NIST SP 800-53 Rev 5 Release 5.2.0 virallinen OSCAL-luettelo

    Osat CM-3 kokoonpanon muutoksen valvonta · CM-5 muutoksen käyttörajoitukset · AC-6 vähiten etuoikeus · CM-8 järjestelmäkomponenttien luettelo

[ Sanasto ]

Sanasto

Toissijainen todistepaketti
Rajattu joukko konfigurointi-, hyväksyntä- ja testitietueita yhdelle tytäryhtiölle.
Virallinen DNS -operaattori
Osapuoli, joka ylläpitää vyöhykkeen arvovaltaisia ​​tietoja julkaisevia palvelimia.
Kattavuuden nimittäjä
Eksplisiittisesti määritelty populaatio, jota vastaan ​​kattavuusmitta lasketaan.

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