[ Alueelliset vaatimukset ]

Yhdistyneen kuningaskunnan hallituksen sähköpostin todennus: nykyinen käytäntö ja todisteet

Yhdistä Ison-Britannian julkisen sektorin sähköpostipolitiikka todellisiin palveluihin, sovita eläkkeelle jääneet Mail Check -ohjeet ja pidä täytäntöönpanotodisteet erillään vaatimuksista.

EmailAuth -tutkimusryhmä · 6 min lukuaika

[Avainkohdat]

  • GOV.UK nimeää julkisen sektorin Internet-sähköpostiverkkotunnuksia, ei kaikkia Yhdistyneen kuningaskunnan kaupallisia lähettäjiä.
  • Vuoden 2024 asennusoppaassa viitataan edelleen Mail Checkiin, joka poistettiin maaliskuussa 2026.
  • Luokittelu, todennus, kuljetus ja raportin omistajuus edellyttävät erillistä näyttöä.
Tällä sivulla

Aloita julkisen sektorin rajasta

Yhdistyneen kuningaskunnan hallituksen sähköpostivaatimus tulee liittää nimettyyn organisaatioon, verkkotunnukseen ja tietojenkäsittelykontekstiin. Siitä ei pitäisi tulla väite, että jokaisen Yhdistyneen kuningaskunnan yrityksen on otettava käyttöön tietty DNS käytäntö. GOV.UK:n suojattu valtion sähköpostisivu, joka on viimeksi päivitetty 4. maaliskuuta 2024 ja tarkistettu täällä 8. marraskuuta 2026, kattaa nimenomaisesti julkisen sektorin organisaatioiden ylläpitämät Internet-sähköpostialueet. Se vaatii vähintään TLS ja DMARCvaihdettujen tietojen asianmukaisen suojan ohella. Se on hallituksen poliittinen konteksti, ei todiste yleisestä kaupallisen alan säännöstä. GOV.UK politiikka.

Aloita soveltuvuustietue organisaation juridisesta identiteetistä ja julkisen sektorin suhteesta. Lisää jokainen lähettävä ja vastaanottava toimialue, palvelun omistaja ja käsiteltävien tietojen luokitus. Toimittajan osallistuminen vaatii oman sopimusanalyysinsä: valtion asiakkaat ja tuttu verkkotunnuksen pääte eivät sinänsä tunnista kaikkia toimittajaa sitovia velvoitteita. Kirjaa ylös todellinen käytäntö tai sopimus, joka sisältää vaatimuksen kyseiseen palveluun.

Lue käytäntö- ja määritysohjeet yhdessä

Täydentävä asennusopas sisältää postilaatikot, välitykset, suodatuspalvelut ja kolmannen osapuolen tapahtumalähettäjät. Sen todennusohjeet kattavat saapuvan ja vaiheittaisen lähtevän tarkastuksen DMARC -valvonta, kanssa SPF ja DKIM kokoonpano. Käsittele vaiheittaista käytäntöä toteutusvaiheena, jossa on omistaja- ja poistumiskriteerit, sen sijaan, että se määrittelee loppuunsaattamisen. Oppaan maaliskuu 2024 päivämäärä on tärkeä myös sen toiminnallisia riippuvuuksia arvioitaessa. Valtion sähköpostin asetukset.

Tietojen luokittelukontekstia varten Cabinet Office Guidance 1.5, versio 2.0, päivätty 5. elokuuta 2024, tunnistaa toimialueen todennuksen ja siirtosuojaukset sähköpostiohjaimissaan. VIRALLINEN sähköposti -sarake sisältää DMARC , DKIM , SPF , MTA-STS ja TLS -raportointi; herkemmillä tasoilla on erilaiset jakamisjärjestelyt. Älä irrota kyseistä saraketta ympäröivästä luokitustaulukosta tai esitä yhtä Internet-sähköpostimallia sopivana jokaiseen luokitukseen. Turvallisuusneuvojan opastus.

Ratkaise eläkepalveluriippuvuus

Lähdejoukossa on konkreettinen versioongelma. Vanhempi asetussivu ohjaa edelleen järjestelmänvalvojat NCSC Mail Checkiin, mukaan lukien raportointi- ja rekisteröintiesimerkit. NCSC :n oma eläkkeelle jäämisilmoitus vahvistaa, että Mail Check ja Web Check päättyivät 31.3.2026. Näin ollen nykyinen toteutussuunnitelma ei voi käsitellä näitä vanhempia ohjeita todisteena siitä, että palvelu on edelleen saatavilla. Tämä on riippuvuuden täsmäytysongelma, ei syy taustalla olevien todennussäätimien hylkäämiseen. NCSC eläkkeelle jäämisilmoitus.

Varastoraporttien kohteet, ilmoitusten omistajuus ja vikojen tutkimiseen käytetty palvelu. Tunnista, mitkä kohteet kuuluvat organisaatiolle ja mitkä ovat riippuvaisia ​​eläkkeellä olevasta tai ulkopuolelta toimitetusta käsittelystä. Ehdota vaihtoa vasta sen jälkeen, kun olet arvioinut pääsyn, säilyttämisen, luottamuksellisuuden ja kustannukset. Tämä artikkeli ei oikeuta raportointiosoitteiden vaihtamiseen tai palvelun tilaamiseen. Säilytä vanhat tietueet ja hyväksytty siirtymäsuunnitelma, jotta tarkastaja voi erottaa suunnitellun siirtymisen selittämättömästä seuranta-aukosta.

Rakenna todisteita todellisten postivirtojen ympärille

Hyödyllinen ohjaustietue sisältää erilliset kentät vaatimukselle, aiotulle asetukselle ja havaitulle tulokselle. Rajoittavan DNS -käytännön julkaiseminen ei todista, että jokainen laillinen sovellus linjaa tai että jokainen vastaanottaja hylkää huijausta. DMARC arvioi tekijän toimialueen suhteessa kohdistettuun todennettuun identiteettiin; nykyinen ydinspesifikaatio on RFC 9989, julkaistu toukokuussa 2026. Sen julkaisu ei todista, että jokainen tuote olisi omaksunut päivitetyn käsittelynsä. Nykyinen DMARC spesifikaatio.

Valmistele näyttösuunnitelma, joka kattaa henkilöstön postin, tapaushallinnon ilmoitukset, julkiset tilausviestit ja valtuutetut lähettäjät. Tunnista jokaiselle kululle näkyvä Lähettäjä-toimialue, vastuullinen tiimi, allekirjoituspalvelu, raportin kohde ja vaikutus, jos toimitus epäonnistuu. Säilytä vastaanottimen havainnot vain, kun valtuutettu testi todella tapahtuu. Laskentataulukon solusta, jossa lukee Configured, ei pitäisi hiljaa tulla onnistunut toimitustesti. Säilytä tapahtumaraportit ja arkaluontoisten viestien sisältö hyväksytyissä arkistoissa sen sijaan, että upottaisit niitä julkiseen artikkeliin.

Käytä fiktiivinen neuvostoesimerkki

Kuvittele kuvitteellinen neuvosto, joka toimii henkilöstöpostina ja erillinen tapaaminen-ilmoitustoimittaja. Sen projekti kirjaa aluksi DMARC valvonnan valmiiksi, koska henkilöstön toimialueella on rajoittava käytäntö. Ehdotettu tarkistus löytää vastaamattoman kysymyksen: käyttääkö toimittaja sovittua identiteettiä ajanvarausviesteissä? Yhtään viestiä ei ole tarkastettu tässä esimerkissä, joten löydös on todistevaje, ei epäonnistunut testi.

Valtuuston politiikan omistaja vahvistaa ensin asiaankuuluvan julkisen sektorin laajuuden. Viestitiimi määrittelee sitten edustajan tapaaminen ja kontrolloidun hyväksymissuunnitelman. Turvatiimi varmistaa erikseen, että raportit saapuvat ylläpidettyyn kohteeseen sen jälkeen, kun Mail Check on lopetettu. Täytetty toimittajakysely olisi hyödyllinen valmistelu, mutta se ei korvaisi varsinaista sanoman näyttöä. Hyväksynnän tulee nimetä sekä yrityksen omistaja, joka hyväksyy häiriöriskin, että operaattori, jolla on oikeus muuttaa DNS .

Tee poikkeukset ja tarkastelupäivät selkeästi

Poikkeustietueen tulee kertoa, mihin toimialueeseen tai reittiin vaikuttaa, miksi tavoiteohjausta ei vielä saavuteta, mitä kompensoivia toimenpiteitä on olemassa ja kuka voi hyväksyä jäännösriskin. Lisää tarkistuspäivämäärä ja laukaisu, kuten toimittajan siirto, luokituksen muutos tai poistumisilmoitus. Älä valmista lakisääteistä määräaikaa verkkosivun viimeisimmän päivityksen päivämäärästä tai oleta, että historialliset arviointijärjestelyt ovat edelleen voimassa, koska ne jäävät muutoslokiin.

Luettelo edellyttää: Valtuutettujen valvontataulukkoa, jonka asianmukainen sääntely- tai lakiasiantuntija on tarkistanut. Mukana oleva kartta on kyseisen taulukon hyväksymätön valmistelu, ei asiantuntijatarkastus. Hanki ennen julkaisua Yhdistyneen kuningaskunnan käytäntöjen ja laillisen omistajan vahvistus, tekninen pk-yrityskatsaus palvelun siirtymisestä ja alkuperäiset toiminnalliset todisteet täytäntöönpanovaatimuksista. Täysi lukija jättää myös visuaaliset, tuotantoreitit ja omistajan julkaisuportit auki. Tämän artikkelin osalta ei käytetty tai muutettu neuvostoa, hallintojärjestelmää tai raportin kohdetta.

[ Takeaway ]

Käytä julkisen sektorin käytäntöä sen luokituksen ja palvelukontekstin kanssa ja tarkista sitten nykyinen valvontariippuvuus.

[ Roolin mukaan ]

Mitä tämä tarkoittaa sinulle

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

Hallituksen politiikan omistaja

Vahvista organisaatio ja luokitus

Viranomaisen päätöksessä tulee kuvata varsinainen julkisen sektorin palvelu- ja tiedotuskonteksti.

Seuraavat vaiheet

  1. Hyväksy kunkin palvelun käytäntö ja sopimusviitteet.
  2. Selvitä, kuka voi hyväksyä poikkeuksen ja milloin se vanhenee.

Viestien ylläpitäjä

Yhdistä raportoinnin siirtyminen

Todennusasetuksissa ja seurannan käytettävyydellä on eri elinkaari.

Seuraavat vaiheet

  1. Luettele kohteet, jotka riippuvat sähköpostin tarkistuksesta.
  2. Valmistele valvotut lähettäjän havainnot ja erikseen hyväksytty siirtymäsuunnitelma.

Palveluntarjoajan omistaja

Suojaa tärkeät ilmoitukset

Tapaaminen ja tapausviestit tarvitsevat yrityshyväksynnän, eivät vain toimialuetason tilaa.

Seuraavat vaiheet

  1. Nimeä toimittajat ja viestityypit, joiden on oltava saatavilla.
  2. Sovi omistajuuden palautus ennen täytäntöönpanon muutosta.

[ UKK ]

Usein kysytyt kysymykset

Perustuuko tämä DMARC laki jokaiselle Yhdistyneen kuningaskunnan yritykselle?

Ei. Mainitulla hallituksen politiikalla on julkisen sektorin laajuus. Yksityinen organisaatio tarvitsee oman laillisen, sopimusperusteisen tai hyväksytyn politiikan perustan.

Onko Mail Check edelleen saatavilla vastaanottopalvelu?

NCSC vahvistaa eläkkeelle jäämisen 31. maaliskuuta 2026. Vanhemmat asennusviitteet eivät kerro tämänhetkistä saatavuutta.

Pitäisikö vanha raportointiosoite kopioida uuteen DNS ?

Tässä ei ole hyväksytty nykyistä määränpäätä. Palvelun omistajan on vahvistettava huollettu prosessori ja valtuutettava kaikki siirrot; tämä luonnos ei tee DNS muutosta.

Kattaako asennusopas ulkoistetut ilmoitukset?

Sen palveluvalikoimaan kuuluu kolmannen osapuolen lähetysjärjestelmiä. Todisteiden tulee seurata todellista reittiä sen sijaan, että ne pysähtyisivät henkilökunnan postilaatikoihin.

Voidaanko VIRALLISIA sähköpostiohjaimia käyttää uudelleen SALASTA materiaalia varten?

Ei ilman luokituskohtaista politiikkapäätöstä. Lähdetaulukossa erotetaan tietotasot ja niiden jakamisjärjestelyt.

Riittääkö rajoittava tietue merkitsemään palvelun valmiiksi?

Ei. Säilytä reittikohtaiset havainnot, ilmoita omistajuus ja hyväksyntä. DNS käytäntö ei yksin määritä jokaista laillista lähettäjän tulosta.

Kenen pitäisi päättää, kuuluuko toimittaja vakuutusturvaan?

Sopimuksen ja vakuutuksen omistajan tulee määrittää asiaankuuluva sopimus ja järjestelmän raja sekä Yhdistyneen kuningaskunnan oikeudellinen tarkastelu tarvittaessa. Pelkkä toimittajabrändi ei riitä.

Mitä todisteita tästä artikkelista vielä puuttuu?

Tilattu asiantuntijan arvioima auktoriteettitaulukko, varsinainen konfiguraatio ja viestitodisteet, tuotannon katsaus ja julkaisuhyväksyntä puuttuvat.

[ Lähteet ]

Lähteet

  1. RFC 9989 : DMARC -ydin
  2. Kabinetti: Ohje 1.5 turvallisuusneuvojille
  3. GOV.UK: Valtion sähköpostin turvaaminen
  4. NCSC : Mail Check ja Web Check eläkkeelle jääminen
  5. GOV.UK: Määritä valtion sähköpostipalvelut turvallisesti

[ Sanasto ]

Sanasto

Hallituksen suojatun sähköpostin käytäntö
Julkaistu Yhdistyneen kuningaskunnan julkisen sektorin ohjeet määritellyllä Internet-verkkotunnuksen laajuudella.
VIRALLINEN
Tietojen luokittelukonteksti, jonka ohjausobjektit on luettava Cabinet Office -taulukosta.
Mail Check eläkkeelle
NCSC palvelu päättyy 31.3.2026, mikä edellyttää vanhojen toimintareferenssien uudelleenarviointia.
Tekijän verkkotunnus
Viestin tekijän identiteetin verkkotunnus on arvioinut DMARC .
Hyväksymispöytäkirja
Hyväksytty tietue, joka yhdistää tietyn palveluvaatimuksen havaittuun näyttöön ja ratkaisemattomiin poikkeuksiin.

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