Ennen hyväksymistä DKIM delegaatio, kysy tarkkaa DNS muutosta ja sen mahdollistamaa allekirjoitusidentiteettiä. "Lisää DNS tietueemme" on liian laaja ohje turvallisuustarkistukseen. A valitsin CNAME, NS-delegaatio ja pääsy koko DNS tilille antavat erilaisia hallintamuotoja.
Piirrä raja ennen sen hyväksymistä
Yhden valitsimen omistajan nimessä oleva CNAME ohjaa resoluution kohteensa läpi. Tätä kohdetta hallitseva palveluntarjoaja voi muuttaa aliaksen kautta saavutettuja vahvistustietoja. Se ei itsessään anna lupaa muokata mielivaltaisia nimiä vyöhykkeelläsi. NS-valtuus määrittää vyöhykkeen rajan ja antaa valtuutetuille valtuutetuille palvelimille vastuun sen alla olevista nimistä DNS hierarkian mukaisesti. Koko tilin järjestelmänvalvojan käyttöoikeus voi olla vielä paljon laajempi. RFC 1034 §3.6.2 ja RFC 1034 §4.2 kuvaile näitä DNS mekanismeja.
Kirjoita hyväksyntään omistajan nimi ja alipuu. Pyyntö ko service1._domainkey.example.com eroaa kokonaisuuden hallinnasta _domainkey.example.com alipuu. Älä korvaa kapeaa toimittajan tukemaa tietuetta laajalla delegaatiolla vain siksi, että se näyttää yksinkertaisemmalta automatisoida.
Erota DNS alue allekirjoituksen vaikutuksesta
DKIM vahvistus hankkii avaimen käyttämällä allekirjoituksen valitsinta ja allekirjoitustoimialuetta. Käyttökelpoisen valitsimen vahvistustietojen hallinta yhdessä vastaavan yksityisen allekirjoitusavaimen kanssa voi ottaa käyttöön kelvolliset allekirjoitukset kyseiselle allekirjoitustoimialueelle. Yhden DNS nimen näennäinen kapea ei siis tarkoita, että sähköpostin luottamuksen seuraus olisi mitätön.
Synteettinen esimerkki havainnollistaa eroa. Palveluntarjoaja vastaanottaa CNAME n osoitteessa invoices._domainkey.example.com ja käyttää vastaavaa allekirjoittajaa d=example.com. Sen DNS käyttö rajoittuu aliaskohteeseen, mutta allekirjoittaja voi tuottaa allekirjoituksia, jotka vaativat vastuuta example.com. Valitsija nimeltä laskut ei rajoita allekirjoituksia laskuihin, tiettyihin vastaanottajiin tai hyväksyttyyn kampanjaan. Sovellusten ja tilien hallinnan on asetettava nämä rajoitukset.
Jos käytät erillistä lähetysaliverkkotunnusta, arvioi sopiva DMARC linjaus säännöt myös. Aliverkkotunnusten erottelu ei automaattisesti eristä rentoa kohdistusta. RFC 9989 §4.4 kuvaa kuinka todennettuja tunnisteita verrataan tekijän verkkotunnukseen; politiikan ja organisaation toimialueen määrittelyssä.
Kerää todisteita, jotka vastaavat hyväksymiskysymykseen
Pyydä palveluntarjoajan nykyiset ohjeet, luodut nimet, tilin tunniste, tuettu allekirjoitustoimialue ja rotaatiomalli. Tarkista, kuka voi muuttaa näitä arvoja palveluntarjoajan tilissä ja onko roolien erottelu käytettävissä. Kysy tilin sulkemisesta ja vanhentuneesta DNS-käsittelystä olettamatta sopimustakuita, joita ei ole toimitettu.
Rakenna kompakti rekisteri: DNS omistaja, tietuetyyppi, kohde tai nimipalvelimet, palvelun omistaja, tarkoitettu d= henkilöllisyys, etuoikeutetut palveluntarjoajan käyttäjät, uusimispäivä ja eläkkeelle jäämismenettely. Jos kyseessä on ehdotettu NS-delegointi, tarkista koko alipuu olemassa olevien valitsimien varalta ennen sen hyväksymistä. Hae tilin käyttöoikeuspyyntöä varten, miksi tietuekohtaiset ohjeet tai suppeampi tuettu rooli eivät riitä.
Testaa käyttöönottoa ja suunnittele irtisanomista
Hyväksytyn muutoksen jälkeen vertaa arvovaltaisia ja rekursiivisia DNS havaintoja ja lähetä aiotun palvelun kautta. Tarkista luotettavan vastaanottimen DKIM tulos ja kohdistus. Testin tulee osoittaa myönnetty henkilöllisyys, ei vain osoittaa, että jokin allekirjoitus läpäisee.
Lopettaessa lopeta sovellusten käyttö, poista vanhentuneet lähetystiedot ja koordinoi valitsimen poistuminen toimitusjonojen ja palveluntarjoajan prosessien kanssa. Jos palveluntarjoajaa epäillään vaarantuneen, käynnistä tapausvastaus sen sijaan, että säilytät rutiinin päällekkäisyyden automaattisesti. Palvelu, joka on merkitty ei-aktiiviseksi hankintatietueissa, voi silti edustaa elävää teknistä riippuvuutta.
Dokumentoi jäännösluottamus selkeästi: mitä palveluntarjoaja voi allekirjoittaa, kuka voi hallinnoida sitä ja kuinka nopeasti organisaatio voi poistaa riippuvuuden. Tämä tietue tekee myöhemmissä uusimisissa todellisen auktoriteetin tarkastelun alkuperäisen DNS lipun toiston sijaan.
Vertaa kolmea hypoteettista hyväksymispyyntöä
Käytä laajuutta ja seurausta yhdessä:
- Yksi valitsin CNAME : tarkista sen tarkka omistaja ja kohde, suunniteltu identiteetti ja palveluntarjoajan tilin hallinta. Se ei myönnä mielivaltaista vyöhykkeen muokkausoikeutta, mutta sen avainkartoitus voi mahdollistaa kyseisen identiteetin allekirjoittamisen.
- NS-delegointi _domainkey.example.com -osoitteen alla: inventoi kyseisen delegoidun vyöhykkeen valitsimet ja kuka hallitsee sen arvovaltaisia palvelimia. Tämä saattaa vaikuttaa olemassa oleviin tai tuleviin valitsimiin, mikäli vyöhykeleikkaukset voivat jatkua.
- Täysi DNS -tilin käyttöoikeus: vaadi selkeä tarve ja tarkista tilin todelliset käyttöoikeudet. Se voi saavuttaa aiheeseen liittymättömät sähköposti- ja verkkotietueet; tämä ei vastaa yhden valitsinaliaksen julkaisemista.
Nämä ovat tarkistusskenaarioita, eivät todelliseen vyöhykkeeseen tehtyjä valtuutuksia tai muutoksia. Jos tarkkaa laajuutta tai omistajuutta ei tunneta, korjaa aukko ennen hyväksymistä.
Aiheeseen liittyvää luettavaa
DKIM TXT ja CNAME julkaisu: noudata toimittajan avaintenhallintamallia · Peruuta DKIM -avain ja erottaa peruutus puuttuvasta DNS tietueesta.