E-postkryptering – velg riktig kanal og kontroll

«Kryptert e-post» kan bety minst tre forskjellige ting: kryptert forbindelse mellom systemer, kryptert lagring hos leverandøren eller en melding som bare avsender og tiltenkt mottaker kan åpne. De gir ulik beskyttelse.

Start derfor med informasjonen og mottakeren, ikke protokollen. Hvis feil mottaker, kompromittert konto eller ukontrollert videresending er den største risikoen, løser ikke vanlig TLS problemet.

Velg kanal på ett minutt

En portal er ikke automatisk ende-til-ende-kryptert, og S/MIME er ikke automatisk riktig for alle sensitive data. Velg løsningen som kan forvaltes gjennom hele levetiden.

Fire lag som ofte blandes sammen

Be leverandøren beskrive hvert lag separat. «Vi bruker kryptering» er ikke et fullstendig svar.

TLS for e-posttransport

Fra bruker til e-postleverandør

Webmail skal bruke gyldig HTTPS. E-postklienter skal bruke leverandørens dokumenterte TLS-oppsett for IMAP og SMTP. Ikke slå av sertifikatkontroll eller velg «ingen kryptering» for å få en gammel klient til å virke.

Klientguiden for Outlook og Apple Mail forklarer port og test.

Mellom e-postservere

SMTP bruker ofte opportunistisk STARTTLS. Serverne forsøker da å opprette en kryptert forbindelse, men hva som skjer hvis TLS ikke er tilgjengelig eller sertifikatet feiler, avhenger av policy og leverandør. Det er ikke det samme som en garanti om kryptert levering.

For en bestemt partner kan avsenderplattformen ofte få en regel som krever TLS og avviser eller holder tilbake meldingen hvis kravet ikke oppfylles. Begge parter må teste feilscenariet, ikke bare en vellykket melding.

MTA-STS, TLS-RPT og DANE

• MTA-STS lar et mottakerdomene publisere hvilke MX-verter som skal godtas og at støttende avsendere skal bruke gyldig TLS.
• TLS-RPT lar domenet motta rapporter om problemer med TLS-transport.
• DANE for SMTP bruker DNSSEC og TLSA-poster for å autentisere mottakerens SMTP-tjeneste.

RFC 8461 beskriver MTA-STS, mens RFC 7672 beskriver DANE. Støtten varierer mellom avsendere. Feil policy kan stoppe legitim post, så innføring skal skje kontrollert.

Bruk MTA-STS- og TLS-RPT-guiden for DNS, testmodus og overvåking.

S/MIME: signering og kryptering med sertifikater

S/MIME bruker sertifikater og offentlig-nøkkel-kryptografi. To funksjoner må skilles:

• digital signering gjør det mulig å kontrollere signaturen, sertifikatet og om det signerte innholdet er endret
• kryptering bruker mottakerens offentlige nøkkel slik at riktig privat nøkkel trengs for å åpne innholdet

En gyldig signatur betyr ikke at påstanden i e-posten er sann, at avsenderens enhet er ren eller at handlingen er godkjent internt. Den viser hva som ble signert med en bestemt nøkkel og hvilket sertifikat som knytter nøkkelen til en identitet.

For å kryptere til en mottaker trenger avsenderen normalt et egnet og gyldig mottakersertifikat. Det gjør S/MIME mest praktisk når partene kommuniserer regelmessig og har styring på sertifikater og klienter.

RFC 8551 er den gjeldende S/MIME 4.0-spesifikasjonen.

S/MIME krever en livssyklus

Avklar:

• hvem som utsteder og godkjenner sertifikater
• hvordan identiteten i sertifikatet kontrolleres
• hvilke klienter og mobile enheter som støttes
• hvordan mottakers offentlige nøkkel hentes og oppdateres
• hva som skjer ved utløp og fornyelse
• hvordan kompromittert nøkkel tilbakekalles
• hvordan gamle meldinger åpnes etter nøkkelbytte
• om virksomheten trenger sikker backup eller nøkkelgjenoppretting
• hvordan nøkkel og sertifikat fjernes når en ansatt slutter

Hvis privatnøkkelen går tapt uten godkjent gjenopprettingsmulighet, kan gamle krypterte meldinger bli utilgjengelige. Hvis nøkkelen kopieres for bredt, svekkes konfidensialiteten.

OpenPGP: samme mål, annen tillitsmodell

OpenPGP bruker også offentlige og private nøkler for kryptering og signering. Standarden krever ikke at alle virksomheter bygger et klassisk «web of trust». Nøkler kan verifiseres gjennom en avtalt kanal, organisasjonsstyrt katalog eller annen kontrollert prosess.

RFC 9580 beskriver dagens OpenPGP-format og erstatter den eldre RFC 4880. Faktisk støtte for algoritmer, nøkkelformater, gruppepost og mobile klienter må testes i valgt programvare.

OpenPGP kan passe når:

• begge parter allerede bruker og forvalter OpenPGP
• virksomheten vil styre nøkkelutstedelse uten offentlig sertifikatmyndighet
• tekniske brukere kan håndtere nøkkelkontroll og gjenoppretting
• arbeidsflyten tåler begrensninger i søk, skanning, mobilbruk og arkiv

Det er ikke tilstrekkelig å publisere en nøkkel og anta at den tilhører riktig person. Fingeravtrykk eller annen nøkkelidentitet må bekreftes gjennom en kjent kanal.

Hva metadata kan røpe

Ende-til-ende-kryptering beskytter ikke nødvendigvis:

• avsender- og mottakeradresse
• tidspunkt og meldingsstørrelse
• rute gjennom e-postsystemene
• enkelte emnefelt og andre meldingshoder
• hvem som kommuniserer med hvem
• lokale varsler, forhåndsvisning og skjermbilder

Kontroller den valgte implementasjonen. Ikke legg sensitiv informasjon i emnefelt, filnavn eller annen metadata uten å vite om det beskyttes.

Sikker portal eller fildeling

En tilgangsstyrt portal er ofte enklere når mottakerne varierer eller virksomheten må kunne tilbakekalle tilgang. En god løsning bør tilby:

• sterk kontroll av mottakerens identitet
• tydelig utløp og mulighet for tilbakekalling
• begrensning av nedlasting og videredistribusjon der det er reelt håndhevbart
• hendelseslogg og varsling
• kryptert transport og lagring
• databehandleravtale og avklart lagringssted ved behov
• sletting, eksport og dokumentert avslutning
• tilgjengelighet for mottakeren

Ikke send portalpassordet eller hele gjenopprettingshemmeligheten i samme e-post som lenken. En SMS-kode kan være egnet i noen arbeidsflyter, men telefonnummer og SIM-risiko må inngå i vurderingen.

Guiden om sikker filoverføring dekker større filer og system-til-system-overføring.

Dette er ikke ende-til-ende-kryptering

• SPF, DKIM og DMARC autentiserer deler av e-postflyten og avsenderdomenet; de krypterer ikke innholdet.
• DKIM-signatur er ikke en personlig digital signatur som S/MIME eller OpenPGP.
• kryptert disk hos leverandøren betyr ikke at leverandørens systemer aldri kan lese meldingen.
• passordbeskyttet ZIP er bare så trygg som krypteringen, passordet og den separate kanalen.
• konfidensialitetsmerke i emne eller footer er en instruks, ikke en teknisk sperre.
• VPN beskytter ikke meldingen etter at den forlater VPN-endepunktet.

SPF-, DKIM- og DMARC-guiden forklarer autentiseringen.

Før dere sender sensitiv informasjon

1. Klassifiser innholdet og vurder om e-post er riktig kanal.
2. Bekreft mottaker og minste nødvendige mottakerliste.
3. Velg transport, ende-til-ende-løsning eller portal etter risiko.
4. Verifiser sertifikat, nøkkel eller portalidentitet i en kjent kanal.
5. Test med ufarlige data på alle nødvendige klienter.
6. Avklar arkiv, journalføring, søk, sletting og gjenoppretting.
7. Send minst mulig informasjon og unngå sensitiv metadata.
8. Kontroller at mottakeren faktisk kunne åpne riktig innhold.
9. Fjern eller tilbakekall tilgang når formålet er ferdig.

Ved gjentakende utveksling bør dette være en dokumentert prosess, ikke en ny vurdering i hver e-post.

Testplan før innføring

Hva inngår hos Vymo?

Vymos publiserte e-postplaner oppgir spam- og virusfilter, webmail og e-postklienttilgang. De lover ikke S/MIME-sertifikater, OpenPGP-forvaltning, håndhevet partner-TLS, MTA-STS, DANE, kundestyrte lagringsnøkler eller sikker meldingsportal.

Har virksomheten krav til kryptering, send en konkret kravliste før bestilling . Oppgi datakategori, mottakertyper, klienter, krav til transport, ende-til-ende-beskyttelse, arkiv, gjenoppretting av nøkler og logging. Ikke send den sensitive informasjonen, private nøkler eller aktive passord i kontaktskjemaet.