Määrittele, mitä perusviivan on tarkoitus todistaa
Todennuksen perusviiva on hyväksytty kuvaus suunnitellusta kokoonpanosta ja sitä tukevasta todisteesta tietyllä hetkellä. Se ei ole vain kuvakaappaus DNS editorista, luettelo halutuista tietueista tai väite, jonka mukaan kaikki tulevat sähköpostit todennetaan. Hyödyllinen perusviiva yhdistää verkkotunnukset, lähetyspalvelut, tietueiden omistajuuden, odotetut todennuspolut ja vahvistusehdot. Versiointi tekee muutoksista selitettäviä; tarkastelu määrittää, sopiiko suunniteltu kokoonpano edelleen yritykseen.
Tässä artikkelissa ehdotetaan perustason ja muutoksenhallinnan työnkulkua. Tietovarastoa ei luotu, asetuksia viety, DNS tietuetta muokattu tai viestiä testattu. Protokollaviittaukset määrittelevät, mitä konfiguraatio tarkoittaa, kun taas versiointiprosessi on toimituksellinen toiminnallinen suositus eikä väite, että standardi määrää tietyn työkalun. Perustason on pysyttävä erillään todisteesta nykyisestä tuotantokäyttäytymisestä, kunnes varsinaiset havainnot kerätään.
Tallenna henkilöllisyydet ja vastuut ennen tietueita
Tallenna jokaiselle lähetystyönkululle liiketoiminnan tarkoitus, verkkotunnuksen omistaja, palveluntarjoaja, näkyvä Lähettäjä, odotettu kirjekuoren identiteetti ja DKIM verkkotunnuksen tai verkkotunnusten allekirjoittaminen. Tunnista, kuka voi hyväksyä muutoksen ja kuka voi toteuttaa sen. DNS järjestelmänvalvoja voi hallita julkaisua, kun taas toimittaja hallitsee allekirjoittamista, ja yrityksen omistaja voi määrittää, pitäisikö lähetysvirta olla olemassa. Näitä vastuita ei pitäisi puristaa yhdeksi epäselväksi "omistaja"-kenttään.
RFC 9989 määrittelee DMARCverkkotunnuksen kohdistussuhteet. Perusviivan tulisi siksi yksilöidä aiottu linjattu polku sen sijaan, että se tallentaisi vain sen SPF tai DKIM on käytössä. RFC 6376 määrittää DKIM -allekirjoituksen ja valitsin malli. Tallenna tärkeät valitsimet ja julkiset haun riippuvuudet, mutta älä koskaan sijoita yksityisiä allekirjoitusavaimia, API-salaisuuksia tai palautustunnuksia yleiseen konfigurointiin.
Säilytä koko asiaankuuluva tietuesarja
Tallenna tarkat DNS omistajien nimet, tyypit, täydelliset arvot ja TTL:t havaitsemallasi tavalla vyöhykkeen ja virallisen palveluntarjoajan kanssa. Pidä toimittaja-editorin merkintä erillään julkaistusta DNS edustamisesta. Erota TXT datan useita merkkijonoja yhdessä tietueessa useista joukon tietueista. Kuvakaappaus, jossa näkyy yksi valittu rivi, voi jättää pois muita arvoja, eikä se välttämättä tue turvallista vaihtotoimintoa. Säilytä tarpeeksi rakenne selittääksesi koko aiotun muutoksen.
Azure DNS -tietueiden dokumentaatio kuvaa tietuejoukkoja, TXT merkkijonoja ja toimittajakohtaisia metatietoja. Se on hyödyllinen todiste Azuren mallista, ei yleinen skeema jokaiselle toimittajalle. Jos todellinen toimittaja eroaa, tarkista sen nykyinen esitys ja päivitystoiminta ennen laskentataulukon käyttöönottoa. Perustaso voi käyttää neutraalia esitystä säilyttäen samalla alkuperäisen toimittajan viennin todisteena sen keruuajan ja rajoitusten kera.
Erottele aiottu tila havaitusta tilasta
Käytä erillisiä osia hyväksyttyyn kohdekonfiguraatioon ja tuotannosta kerättyihin havaintoihin. Haluttu SPF -arvo ei ole todiste siitä, että arvovaltainen palvelin julkaisi sen. DNS vastaus ei ole todiste siitä, että palveluntarjoaja on allekirjoittanut viestin odotetulla valitsimella. Vastaanotetun viestin tulos ei ole todiste siitä, että jokainen lähetystyönkulku käyttää samaa polkua. Jokaisesta havainnosta tulee ilmoittaa sen laajuus, aika, keräysmenetelmä ja identiteetti, jonka se kattaa.
Käytettäessä Authentication-Results noudata varmistustodistuksena kohdassa olevia luottamusrajoja koskevia huolenaiheita RFC 8601. Säilytä tulokset asiaankuuluvalta luotetulta vastaanottajalta sen sijaan, että hyväksyisit mielivaltaiset lähettäjän esittämät väitteet. Pidä redusoidut viestitodisteet ja täysin arkaluontoiset alkuperäiset asianmukaisten pääsynvalvontalaitteiden alla. Perustason tulee viitata hyväksyttyihin todisteiden sijainteihin, ei luottamuksellisten viestien tai valtuustietojen keräämiseen pelkästään mukavuussyistä.
Tee jokaisesta versiosta selitettävissä oleva päätös
Määritä sisäinen versiotunniste ja kirjaa ylös aiempi hyväksytty versio, muutoksen syy, suunniteltu ero, vaikuttaneet työnkulut, riskinarviointi ja liiketoiminnan allekirjoitus. Luettavissa olevan eron tulee näyttää lisäykset, poistot ja korvaukset täydellisessä yhteydessä. Sen tulee tunnistaa, otetaanko toimittaja käyttöön, käännetäänkö valitsinta, poistetaanko vanhentunut lähettäjä vai muutetaanko käytäntöä. Älä anna pelkän muotoilun muutoksen kätkeä merkityksellistä muutosta valtuutukseen tai linjaus.
Valitse organisaation työkaluille sopiva tarkistusmekanismi, mutta älä oleta, että versionhallintasitoumus vastaa hyväksyntää. Kirjaa päätöksen omistaja ja hyväksynnän laajuus erikseen. Määritä, mitä tapahtuu, jos havaittu nykyinen kokoonpano poikkeaa odotetusta perustasosta ennen suoritusta. Turvallinen vastaus on tutkia ja sovittaa ero, ei korvata uudempaa tilaa vain siksi, että valmisteltu muutostiedosto on olemassa.
Ota huomioon samanaikaiset muokkaukset ja palautusrajoitukset
Azure DNS dokumentoi vyöhykkeisiin ja tietuejoukkoon liittyvät Etag-tunnisteet ja selittää, kuinka ne voivat havaita samanaikaiset muutokset, kun ne toimitetaan päivitysten aikana. Se on palveluntarjoajakohtainen samanaikaisuusmekanismi, ei yleinen DNS ominaisuus. TTL hallitsee välimuistin toimintaa, ei sitä, kuka saa muokata ennätys vai korvaako yksi muutos toisen. Vahvista käyttöliittymän varsinainen samanaikaisuuskäyttäytyminen ja säilytä valtuutetun muutoksen versiotodisteet.
Peruutuskriteerien tulee yksilöidä sekä tekninen laukaisin että valtuutettu päätöksentekijä. Palautusmateriaali tarvitsee edellisen täydellisen kokoonpanon, asiaankuuluvan toimittajan tilan ja tunnetut riippuvuudet. DNS tietueen palauttaminen ei saa palauttaa poistettua toimittajaresurssia, kumota toimitettua postia tai korvata välimuistissa olevia vastauksia välittömästi. Suunnittele toipuminen koordinoiduna työnkulkuna sen sijaan, että lupaisit, että vanhan arvon kopioiminen kumoaa kaikki seuraukset. Tätä luonnosta valmisteltaessa ei yritetty peruuttaa.
Perustason tarkistuslaskentataulukko
Luo laskentataulukko, jossa on perusversio, toimialue ja työnkulun laajuus, liiketoiminnan tarkoitus, kokoonpanon omistaja, suorituksen omistaja, tarkka tietuevarasto ja odotettu todennuspolku. Lisää todisteita, joissa on päivämäärät, tunnetut aukot, lähdedokumenttien versiot ja tarkistuskäynnistimet. Sisällytä ehdotettuun versioon aiottu ero, liiketoiminnan hyväksyntä, ennakkoehdot, samanaikaisuuden tarkistukset, todennuskriteerit, palautuskriteerit ja lopullinen sijoitus. Merkitse havaitsemattomat tulokset selkeästi sen sijaan, että jätät ne implisiittisiksi valmiin suunnittelun arvioinnin perusteella.
Tarkistuksen käynnistäjiä voivat olla uusi lähettäjä, toimittajan lopettaminen, verkkotunnuksen siirto, avainten kierto, yrityksen omistajan muutos tai merkittävä todennustapahtuma. Kalenteritarkastelu voi myös auttaa, mutta sen tiheyden tulisi heijastaa organisaation riskiä ja muutosvolyymiä eikä keksittyä yleistä aikaväliä. Tarkista, kattaako lähtötaso edelleen kaikki lailliset työnkulut ja onko eläkkeellä olevia riippuvuuksia jäljellä. Älä käsittele muuttumatonta tiedostoa todisteena siitä, että tuotantoympäristö ei ole ajautunut.
Kuvitteellinen diagnoosi: dokumentoimaton toimittajalisäys
Kuvitteellisella organisaatiolla on hyväksytty perustaso, joka kattaa sen laskutuspalvelun ja työntekijöiden postin. Markkinointitiimi esittelee myöhemmin toisen lähettäjän erillisen toimittajan kautta. Perustaso pysyy ennallaan, kun taas valmis DNS puhdistus poistaisi uuden palvelun käyttämän riippuvuuden. Ehdotetussa harjoituksessa tarkistaja vertaa nykyistä omistajuutta ja työnkulkutietueita lähtötasoon ennen siivouksen hyväksymistä ja havaitsee dokumentaation puutteen.
Tiimi sovittaisi uuden työnkulun, hankkisi liiketoiminnan allekirjoituksen, päivittäisi suunnitellun eron ja kerää varmistustodisteita valtuutetun muutoksen jälkeen. Se ei sokeasti palauttaisi vanhaa perusviivaa vain siksi, että se oli aiemmin hyväksytty. Tämä skenaario on kuvitteellinen: toimittajaa ei löydetty, kokoonpanoeroa ei käytetty eikä toimitustestiä suoritettu. Se havainnollistaa, miksi versiohistoria on liitettävä nykyiseen omistukseen ja toiminnallisiin havaintoihin.
Vapauta perusviiva sen rajoitusten ollessa näkyvissä
Hyödyllinen tarkastelupäätelmä kertoo, mitkä työnkulut on katettu, mitkä havainnot tukevat niitä ja mitkä jäävät tarkistamatta. Se ei lupaa yleistä toimitusta tai pysyvää turvallisuutta. Todennussäädöt voivat olla oikein, kun taas sisältö, maine, tilin vaarantaminen tai vastaanottajakäytäntö vaikuttavat postin tuloksiin. Perustason tulee tehdä nämä rajat näkyviksi, jotta tulevat käyttäjät eivät erehdy erehtymään konfigurointitietueeseen täydelliseen turvallisuusarviointiin.
Luettelo vaatii muutostietueen perusviivalla, aiotulla erolla, liiketoiminnan kirjautumis-, vahvistus- ja palautuskriteereillä. Alkuperäinen toimintatietue pysyy auki. Tämä luonnos sisältää ehdotetun rakenteen, ei toteutettuja muutostodisteita. Henkilöstön asiantuntija-arviointi, lähteiden soveltuvuus, tuotantoreitit, visuaalinen saavutettavuus ja omistajan vapauttaminen ovat myös avoinna. Julkaistava versio vaatii valtuutetun esimerkin, jossa on todellisia havaintoja ja hyväksyntöjä, asianmukaisesti muokattuna ja säilytettynä paljastamatta salaisuuksia.