ISO 27001:2022 opdaterede og omorganiserede Bilag A-kontrollerne markant sammenlignet med 2013-versionen. Kryptografi- og nøglestyringskontrollen blev mere eksplicit, og kravene til aktivstyring blev styrket. For organisationer der styrer TLS-certifikater har flere kontroller nu direkte, testbare implikationer for hvordan certifikater inventariseres, administreres og overvåges.
De Bilag A-kontroller der dækker certifikater
Kontrol 5.9 — Fortegnelse over informationer og andre tilknyttede aktiver. Denne kontrol kræver at en fortegnelse over aktiver udarbejdes, vedligeholdes og holdes nøjagtig og konsistent. TLS-certifikater er informationsaktiver. En revisor der vurderer denne kontrol vil gerne se bevis for at certifikater er inkluderet i aktivfortegnelsen — ikke kun servere og software, men selve certifikaterne med ejerskab, klassifikation og livscyklusoplysninger.
Kontrol 5.12 — Klassifikation af information. Certifikater og særligt private nøgler kræver passende klassifikation. Private nøgler til produktionscertifikater bør som minimum behandles som fortrolige — med tilsvarende adgangskontroller og lagringskrav.
Kontrol 8.24 — Brug af kryptografi. Dette er den primære certifikatkontrol. Den kræver at regler for effektiv brug af kryptografi er defineret og implementeret, der dækker nøglehåndtering i hele livscyklussen. For TLS specifikt betyder det dokumenterede politikker der dækker hvilke certifikattyper der er godkendte, hvilke CA'er der er autoriserede, acceptable nøglelængder og algoritmer, og hvordan certifikater fornyes og udfases. En revisor vil kontrollere at politikken eksisterer og at den faktiske praksis matcher den.
Kontrol 8.20 — Netværkssikkerhed. Kræver at netværk administreres og kontrolleres for at beskytte information. Svag TLS-konfiguration — forældet protokolversioner, forladte cipher suites, manglende sikkerhedsheadere — er et netværkssikkerhedsfinding under denne kontrol.
Kontrol 5.30 — ICT-beredskab til forretningskontinuitet. Certifikatudløb der forårsager utilgængelighed af tjenester er en forretningskontinuitetsfejl. Kontollen kræver at ICT-beredskab planlægges og testes. Certifikatovervågnings- og fornyelsesprocesser bør dokumenteres som en del af forretningskontinuitetsplandlægning.
Hvad revisorer faktisk kigger efter
En velforberedt revisor der vurderer certifikatstyring vil typisk anmode om:
Certifikatfortegnelsen. Vis mig jeres liste over certifikater. Hvor er de? Hvem ejer dem? Hvornår udløber de? Hvad er jeres advarseltærskler? En fortegnelse der kun eksisterer i én persons hoved, i et regneark med en nylig "sidst opdateret"-dato, eller som bemærkelsesværdigt udelader hele kategorier af certifikater (interne tjenester, leverandørsystemer, staging-miljøer), vil generere et finding.
Bevis for overvågning. Har I bevis for at advarsler udløste sig inden nylige certifikatfornyelser? Blev disse advarsler handlet på i tide? En fornyelse gennemført med timer i reserve på en advarsel der udløste sig for 14 dage siden tyder på at processen virkede men var ubehageligt tæt på. En fornyelse gennemført efter udløb er en uoverensstemmelse.
Nøglehåndteringsdokumentation. Hvor opbevares private nøgler? Hvem har adgang? Hvordan er de beskyttet? For certifikater på cloudplatforme, i HSM'er eller i konfigurationsstyringssystemer vil revisoren gerne se at adgang er kontrolleret og logget.
CA-autorisationspolitik. Specificerer din kryptografipolitik hvilke CA'er der er autoriserede til at udstede certifikater til dine domæner? Er der kontroller (CAA DNS-records, CA pinning, godkendelsesworkflows for indkøb) der håndhæver disse begrænsninger? En organisation der hævder kun at autorisere et specifikt sæt CA'er men har Let's Encrypt-certifikater spredt ud over skygge-IT-tjenester har et gab mellem politik og praksis.
Algoritme- og nøglelængdekrav. Bruger alle certifikater godkendte algoritmer og nøglelængder? RSA-2048 er acceptabelt i dag; RSA-1024 og MD5-signerede certifikater er findings. En scanning på tværs af alle certifikater for algoritmecompliance er et rimeligt revisionstrin.
TLS-konfiguration på eksternt tilgængelige tjenester. Revisorer med teknisk viden vil kontrollere om TLS 1.0 eller 1.1 er aktiveret, om svage cipher suites tilbydes, og om sikkerhedsheadere er til stede. Disse er testbare på få minutter med frit tilgængeligt værktøj — revisorer der ikke tjekker dem selv kan bruge eksterne vurderingsresultater som bevis.
Almindelige findings ved certifikatstyring
Baseret på tilbagevendende mønstre i ISO 27001-revisioner er de hyppigste certifikatrelaterede findings:
- Ufuldstændig eller ikke-vedligeholdt fortegnelse. Fortegnelsen eksisterer men er ikke blevet opdateret siden den seneste revision. Certifikater der er tilføjet eller fjernet siden da er ikke afspejlet.
- Intet defineret ejerskab. Certifikater eksisterer i fortegnelsen uden en klar ejer eller ansvarligt team. Når revisorer spørger hvem der ville handle hvis certifikatet udløb i morgen, er svaret uklart.
- Advarseltærskler der er for korte. Advarsler konfigureret til at udløse 7 eller 14 dage inden udløb efterlader utilstrækkelig tid til fornyelsesprocesser der involverer ændringsstyringsgodkendelser eller leverandørkoordinering.
- Svag TLS-konfiguration på ikke-primære tjenester. Produktionstjenester er ofte velkonfigurerede. Staging-miljøer, interne værktøjer og partnerintegrationsendepunkter kører ofte forældede TLS-versioner.
- Adgang til private nøgler logges ikke. Adgang til private nøgler bør logges. I mange organisationer opbevares certifikater og nøgler på steder — delte filsystemer, uovervågede vaults, konfigurationsfiler — hvor adgang ikke er reviderbar.
- Intet bevis for test af fornyelsesprocessen. Processen er dokumenteret men er aldrig blevet testet. Revisorer der leder efter bevis for test finder det ikke.
Opbygning af revisionsklaret certifikatstyring
Målet er ikke blot at bestå en revision — det er at have en genuint velstyret certifikatbeholdning der er nem at demonstrere under en revision. Den praktiske forskel er at ægte styring producerer naturlige beviser: advarselslog, fornyelsesregistre, fortegnelsesopdateringer, konfigurationsscanningsresultater. En organisation der styrer certifikater godt vil have disse beviser som en bivirkning af sin normale drift. En organisation der styrer certifikater dårligt vil kæmpe med at samle beviser ved hvert revisionscyklus.
CertControl producerer beviserne naturligt. Fortegnelsen opdateres automatisk. Advarsler logges med tidsstempler. Rapporter der dækker udløbsstatus, TLS-konfigurationscompliance og certifikatkædesundhed er tilgængelige på forespørgsel. Når en revisor beder om certifikatstyringsdokumentationspakken, er svaret et par klik frem for et weekends regnearksarbejde.