En TLS-kontroll skal vise hvordan opplysninger beskyttes på hver relevant forbindelse, om klienten bekrefter riktig mottaker og hvordan sertifikater vedlikeholdes. Det er ikke nok at en nettleser viser en sikker forbindelse til forsiden. API-er, administrative grensesnitt og trafikk mellom tjenester kan ha et annet oppsett og andre svakheter.
IETFs RFC 9325 gir anbefalinger for sikker bruk av TLS og DTLS. RFC 9852 fra juli 2026 oppdaterer deler av anbefalingene for nye protokoller som bruker TLS: TLS 1.3 skal være standard, med avgrenset mulighet for TLS 1.2 som et tillegg av hensyn til innføring. Dette er tekniske standardanbefalinger med et definert virkeområde, ikke en generell norsk lovregel om at alle eksisterende tjenester har samme migreringsfrist. Kontroller relevante oppdateringer og tjenestens konkrete dokumentasjon før konfigurasjon endres.
Lag et register over endepunktene
Registrer navn, port, tjeneste, eier og hvor forbindelsen avsluttes. Ta med offentlige nettsteder, API-er, administrasjon og interne forbindelser med relevante opplysninger. Angi hvilke klienter som bruker endepunktet og om trafikken går gjennom en mellomliggende tjeneste. Et domenenavn kan peke til flere tekniske miljøer med forskjellige innstillinger.
Knytt registeret til systemoversikten. Beskriv også forbindelser som opprettes automatisk av integrasjoner. En kontroll av vanlig nettleserbruk dekker ikke nødvendigvis en eldre klient eller en bakgrunnsjobb. Kartet bør gjøre det mulig å finne både ansvarlig person og faktisk teknisk avslutning av forbindelsen.
Skill kanalbeskyttelse fra resten av dataflyten
TLS beskytter en bestemt forbindelse. Undersøk hva som skjer før og etter den, inkludert mellomlagring og videre transport. Hvis en proxy avslutter TLS, må forbindelsen videre til applikasjonen vurderes separat. En ekstern sikker forbindelse dokumenterer ikke automatisk at alle interne ledd har samme beskyttelse.
Bruk krypteringsvurderingen til å beskrive hvor klartekst finnes og hvem som kan lese den. TLS erstatter ikke tilgangsstyring i applikasjonen, sikker lagring eller kontroll med mottakeren etter levering. En bruker med for bred tilgang kan fortsatt hente ut opplysninger gjennom en teknisk sikker forbindelse.
Velg protokolloppsett etter gjeldende tekniske kilder
Undersøk hvilke versjoner og kryptografiske valg endepunktet faktisk tillater. RFC 9325 sier at implementasjoner ikke skal forhandle SSL 2.0, SSL 3.0, TLS 1.0 eller TLS 1.1, mens nyere veiledning for nye TLS-baserte protokoller styrker overgangen til TLS 1.3. Skillet mellom eksisterende distribusjoner og utforming av nye protokoller må beholdes når anbefalingene brukes.
Ikke kopier verdier fra et gammelt innlegg uten å kontrollere dato og virkeområde. Biblioteker, operativsystemer og tjenesteplattformer kan ha forskjellige konfigurasjonsmåter. Bruk primærkildene til å velge et oppsett som passer faktisk programvare, og dokumenter eventuelle kompatibilitetsbehov. Et ubegrunnet unntak for en gammel klient bør ikke bli permanent normaltilstand.
Kontroller sertifikatet og navnet det gjelder
Undersøk om sertifikatet dekker navnet klienten bruker, har en gyldig tillitskjede og er gyldig på kontrolltidspunktet. Kontroller også hvordan klienten håndterer feil. En applikasjon som ignorerer sertifikatfeil, kan miste en sentral del av beskyttelsen selv om serveren ellers har et riktig oppsett.
Skill sertifikatets offentlige opplysninger fra den private nøkkelen. Den private nøkkelen trenger kontrollert tilgang og håndtering ved mistanke om kompromittering. Dokumentasjon av utløpsdato bør ikke inneholde hemmelig nøkkelmateriale. Et register over sertifikater skal hjelpe drift, ikke bli en ny samling av midler til å utgi seg for tjenestene.
Arbeidsark for en endepunktkontroll
| Felt | Hva dere bør registrere |
|---|---|
| Tjeneste | Navn, miljø, eier og relevante klienter |
| Avslutning | Hvor TLS-forbindelsen faktisk ender |
| Protokoll | Tillatte versjoner og begrunnede avvik |
| Sertifikat | Navnedekning, utsteder, kjede og gyldighet |
| Nøkkel | Eier, tilgang og plan ved tap eller mistanke |
| Klientkontroll | Hvordan feil sertifikat eller navn håndteres |
| Videre trafikk | Beskyttelse etter et mellomledd |
| Vedlikehold | Fornyelse, varsler og bekreftelse etter endring |
| Resultat | Kontrollmetode, dato og kjente begrensninger |
Tabellen er et praktisk register og ingen automatisk samsvarserklæring. Et enkelt grønt resultat kan dekke bare et bestemt navn og en bestemt port. Vær presis om hvilke endepunkter som ble undersøkt og hvilke forbindelser som fortsatt trenger kontroll.
Planlegg fornyelse som en driftsprosess
Avklar hvem som mottar varsel om utløp og hvem som kan gjennomføre fornyelsen. Automatisering kan redusere manuelt arbeid, men må selv overvåkes. En jobb kan feile fordi et domene er flyttet, en tilgang er endret eller et mellomledd ikke lenger kan gjennomføre nødvendig validering.
Kontroller etter fornyelsen at riktig sertifikat faktisk presenteres på alle relevante endepunkter. Det kan være lastbalansering eller flere servere med ulike tilstander. En vellykket utstedelse viser ikke alene at den nye versjonen er tatt i bruk. Dokumenter også hvordan tilbakeføring eller rask korrigering håndteres hvis endringen påvirker klientene.
Undersøk maskin-til-maskin-kommunikasjon
API-er og integrasjoner kan bruke egne biblioteker, sertifikatlager og innstillinger. Spør utviklere og leverandører hvordan sertifikater valideres, hvilke versjoner som støttes og hvordan feil meldes. En feil som bare skrives til en logg uten oppfølging, kan føre til at en viktig overføring stopper ubemerket.
Knytt hendelser til sikkerhetsloggrutinen. Vurder hvilke opplysninger som trengs for å oppdage utløp og forbindelsesfeil, uten å logge hele innholdet i forespørsler med personopplysninger. Når en forbindelse feiler, bør systemet ikke automatisk falle tilbake til en ubeskyttet metode for å få overføringen gjennomført.
Vurder endringer i et kontrollert omfang
Før en eldre protokoll eller et kryptografisk valg deaktiveres, må dere forstå hvilke klienter som bruker det. Samle et egnet grunnlag og planlegg prøving uten å eksponere sensitive data. Det er ikke nødvendig å beholde svake valg ubegrenset, men en gjennomført migrering krever at legitime arbeidsprosesser får et fungerende alternativ.
Bruk herdingsprosessen til å dokumentere måltilstand og unntak. Angi hvem som eier en gammel avhengighet og hva som skal skje videre. Hvis et unntak videreføres, bør konsekvensen og kompenserende tiltak vurderes på nytt. En gammel godkjenning viser ikke at dagens trusselbilde eller bruk er uendret.
Hypotetisk eksempel: sertifikatet er fornyet, men én klient feiler
En tenkt virksomhet fornyer sertifikatet for en tjeneste. Nettleserne fungerer, men en integrasjon slutter å levere opplysninger. Undersøkelsen viser at klienten har et utdatert tillitsgrunnlag. Teamet oppdaterer klienten gjennom en kontrollert endring fremfor å slå av sertifikatvalideringen.
Samtidig oppdager virksomheten at den vanlige overvåkingen bare kontrollerer nettsiden. Den legger til oppfølging av integrasjonsflyten og beskriver hvem som håndterer feilen. Eksemplet viser hvorfor en fullstendig kontroll må omfatte klienter og arbeidsprosesser. Et gyldig serverbevis er en viktig del av sikkerheten, men beskriver ikke hele leveransen.
Avklar hva en ekstern kontrolltjeneste får se
Noen verktøy undersøker offentlige endepunkter uten å motta innhold fra virksomheten. Andre krever tilgang eller opplasting av konfigurasjon. Vurder omfang, fullmakt og hvilke opplysninger som deles før et verktøy brukes. Ikke send private nøkler, hemmelige konfigurasjonsverdier eller personopplysninger for å få en generell vurdering.
En ekstern score kan hjelpe med å finne tekniske avvik, men må leses med kunnskap om metoden. Den erstatter ikke egen vurdering av interne forbindelser eller klientadferd. Ved større undersøkelser kan bestilling av en penetrasjonstest gi en ramme for autorisasjon, påvirkning og oppfølging av funn.
Knytt funn til tiltak og beredskap
Prioriter etter eksponering, opplysningenes betydning og mulige konsekvenser. Skill kritiske feil som kan svekke mottakerkontroll fra vedlikeholdsoppgaver som har et annet tidsbilde. Angi ansvar og hvordan retting verifiseres. En oppdatert konfigurasjonsfil er ikke bevis på at tjenesten faktisk bruker den nye innstillingen.
Ta med sertifikat- og nøkkelhendelser i kontinuitetsplanen. Virksomheten bør vite hvordan en viktig tjeneste håndteres ved utløp, feil eller mistanke om kompromittering. Et improvisert valg om å ignorere alle sertifikatfeil kan skape en større risiko enn det opprinnelige avbruddet.
Bevar presis dokumentasjon over tid
Lagre kontrollresultat med endepunkt, dato, metode og omfang. Noter tekniske kilder og versjoner som oppsettet bygger på. Følg relevante standardoppdateringer og leverandørendringer, særlig når nye protokoller eller klienter innføres. En teknisk anbefaling er et tidsbestemt grunnlag som må vurderes når omstendighetene endres.
Den ferdige leveransen bør vise hvilke forbindelser som er kontrollert, hvem som eier sertifikatene og hvordan vedlikeholdet fungerer. Det gjør TLS til et håndtert sikkerhetstiltak med kjent ansvar og begrensning, fremfor bare en innstilling som ble slått på da tjenesten ble lansert.