Härdning innebär att minska ett systems angreppsyta genom att ta bort onödiga funktioner, begränsa behörigheter och använda en genomtänkt säkerhetskonfiguration. För Windows och Linux behöver arbetet anpassas till operativsystemets version och maskinens uppgift. Samma inställning kan vara lämplig på en server och störa arbetet på en klient.
Ett användbart resultat är en beslutad grundkonfiguration, dokumenterade undantag och ett sätt att upptäcka avvikelser. Den här guiden hjälper IT-ansvariga att organisera arbetet och granska utfallet. Exemplen är förslag på arbetsrutiner, inte en komplett installationsanvisning eller en svensk myndighets föreskrivna standardkonfiguration.
Inventera innan ni ändrar inställningar
Börja med operativsystem, version, supportstatus, funktion, exponering och ansvarig. Ta med administrationsservrar, testmiljöer och enheter som sällan ansluts. Markera vilka system som hanterar personuppgifter eller ger åtkomst till andra kritiska resurser. Använd systemkartan för att se beroenden som kan påverkas av en förändring.
Registrera också hur konfigurationen styrs. En dator kan få inställningar från lokal policy, central enhetshantering och flera andra profiler samtidigt. Innan ni inför en ny regel behöver ni veta vilken inställning som faktiskt vinner. Annars kan en rapport om att policyn är tilldelad felaktigt tolkas som att skyddet används.
Välj en referens som gäller den aktuella plattformen och versionen. Leverantörens dokumentation och etablerade säkerhetsprofiler kan ge stöd, men en godkänd kontroll mot en profil är inte i sig ett bevis på GDPR-efterlevnad. Artikel 32 i GDPR kräver lämpliga åtgärder utifrån den faktiska risken. Den föreskriver inte en universell lista över Windows- eller Linuxinställningar.
Dela upp miljön i roller
Skapa separata grundkonfigurationer för exempelvis kontorsklienter, applikationsservrar och administrativa system. Ange vilka inställningar som är gemensamma och vilka som beror på rollen. En server som inte skriver ut behöver normalt inte en aktiv utskriftstjänst. En arbetsstation med en legitim utskriftsuppgift måste bedömas annorlunda.
För varje ändring ska det finnas ett säkerhetssyfte och ett kontrollmoment. ”Brandvägg på” är mindre användbart än ”inkommande administration tillåts bara från beslutad administrationsmiljö, och anslutning från klientnätet avvisas”. Kontrollera även att legitim drift fortfarande fungerar. Härdning som gör att personalen inför osäkra genvägar kan skapa nya problem.
Lägg ansvar och mandat i informationssäkerhetspolicyn. Den tekniska grundkonfigurationen bör ligga separat så att den kan uppdateras när plattformen ändras utan att hela policyn måste skrivas om.
Prioritera Windowsklientens vanligaste vägar in
Granska lokala administratörsrättigheter, fjärråtkomst, brandvägg, skydd av inloggningsuppgifter, diskkryptering och programkörning. Kontrollera vilka skyddsfunktioner som stöds i den aktuella utgåvan och på hårdvaran. Utgå inte från att en funktion är aktiverad bara för att den finns i produkten.
Skilj den vanliga arbetsidentiteten från den identitet som får ändra systemet. En medarbetare som behöver installera ett särskilt verktyg behöver inte nödvändigtvis ständig lokal administratörsbehörighet. Beskriv hur installationen beställs och hanteras, så att skyddet inte leder till delade administratörslösenord.
Windows LAPS enligt Microsofts dokumentation kan hantera lösenord för ett lokalt administratörskonto. Kontrollera både att lösningen är rätt konfigurerad och vilka som kan läsa eller återställa lösenorden. Ett centralt lager med för bred läsbehörighet kan underminera syftet med separata lokala hemligheter. Följ upp användning och efterföljande byte enligt er konfiguration.
För dokument och nedladdningar behöver ni bedöma vilka aktiva funktioner som verksamheten använder. Prova blockeringar med representativa arbetsflöden. Om en äldre makrobaserad lösning måste fortsätta användas ska undantaget vara avgränsat till rätt källa och användare, med en ansvarig för avveckling. Gör inte en generell uppluckring för hela organisationen.
Skydda administrationsmiljön separat
Den som administrerar identitetstjänster eller många servrar har andra risker än en vanlig användare. Begränsa vilka enheter och anslutningar som får användas för detta arbete. Undvik att privilegierade konton används för vanlig e-post och webbsurfning. Bedöm även tjänstekonton och deras faktiska rättigheter.
I en katalogmiljö behöver ni förstå vilka grupper, delegeringar och återställningsbehörigheter som ger indirekt makt över andra konton. Om identiteterna även används i Microsoft 365 behöver molntjänsternas säkerhetsinställningar granskas separat; en härdad klient visar inte vilka delningar eller appbehörigheter som är tillåtna i tjänsten. Ett konto kan vara kritiskt utan att heta ”administratör”. Inventera därför privilegier utifrån möjlig handling: ändra en grupp, återställa en hemlighet, läsa en säkerhetskopia eller påverka en central policy.
Koppla kontrollerna till autentiseringspolicyn och säkerhetsloggningen. Det ska gå att upptäcka oväntade förändringar och avgöra vem som får följa upp dem. Logga inte hemligheter för att förenkla felsökningen.
Anpassa Linux efter distribution och tjänst
Inventera installerade paket, aktiva tjänster, nätverkslyssnare och användarkonton. Ta bort eller stäng av sådant som inte behövs för serverns funktion efter att beroenden har kontrollerats. Begränsa administrationsvägar och använd separata identiteter med spårbar behörighetseskalering där miljön tillåter det.
SELinux och AppArmor är exempel på mekanismer som kan begränsa processers möjligheter utöver vanliga filrättigheter. Följ distributionens dokumentation. Red Hats SELinux-vägledning beskriver bland annat skillnaden mellan lägen som genomdriver policyn och lägen som endast registrerar överträdelser. Ett övervakande läge ger inte samma blockerande skydd.
Om en applikation inte fungerar, utred den specifika nekade åtgärden. Att stänga av skyddet för hela servern kan dölja grundproblemet. Dokumentera vilka filer, nätanslutningar och rättigheter applikationen behöver och prova den avgränsade lösningen. Red Hats vägledning för härdning visar också hur säkerhetsprofiler kan användas som utgångspunkt. Anpassningen måste följa er distribution och arbetslast.
Prova förändringarna i en representativ pilot
Välj ett mindre urval som faktiskt täcker viktiga användningsfall. Ta med en användare med specialprogram, en server med integrationer och ett realistiskt administrationsmoment. En pilot som bara använder en nyinstallerad standarddator kan missa de beroenden som avgör om utrullningen fungerar.
| Kontroll i ett fiktivt pilotprotokoll | Förväntat resultat | Observerat och beslut |
|---|---|---|
| Vanlig användare installerar ett ej godkänt program | Installationen stoppas | Stoppad; godkänd beställningsväg provad |
| Behörig tekniker utför underhåll | Åtkomst fungerar och kan följas upp | Fungerar med separat konto; logghändelse verifierad |
| Ordertjänst skriver till sin datakatalog | Skrivning tillåts i avsedd katalog | Nekades på grund av fel sökväg; avgränsad regel korrigerad |
| Anslutning till server från otillåtet nät | Anslutningen avvisas | Avvisad; tillåten administrationsväg fungerar |
Spara före- och efterkonfiguration, ändrings-ID och återställningsväg. Prova återställningsvägen innan en bred utrullning om ändringen kan låsa ute administratörerna. Att en säkerhetskopia finns innebär inte att ni kan återfå åtkomst tillräckligt snabbt. Använd återställningsplanen för beroenden och ansvar.
Hantera patchar efter exponering och risk
Härdning ersätter inte säkerhetsuppdateringar. Prioritera aktivt utnyttjade sårbarheter, internetexponering, privilegier och konsekvenser tillsammans. En teknisk allvarlighetsgrad är ett underlag, men säger inte allt om er miljö. Samma sårbarhet kan kräva olika åtgärder på en isolerad testenhet och en publik inloggningstjänst.
Bestäm egna mål för bedömning och åtgärd samt hur akuta risker eskaleras. Beskriv tillfälliga skydd när en uppdatering inte omedelbart kan installeras. Påstå inte att GDPR generellt föreskriver exempelvis 48 timmar eller 30 dagar för alla patchar. Andra tillämpliga regler och avtal behöver granskas separat.
Dokumentera undantag som går att avsluta
Ett undantag ska ange berört system, avvikande inställning, skäl, risk, tillfälligt skydd, beslutsfattare och omprövningsdatum. ”Verksamheten kräver det” räcker inte. Beskriv vilken funktion som annars bryts och vilken lösning som ska ersätta undantaget.
Exempel: en äldre tjänst behöver en anslutning som grundkonfigurationen blockerar. Undantaget begränsas till en bestämd server och mottagare. Leverantören ska leverera en ändrad integration, och systemägaren följer upp ett angivet datum. Om planen försenas krävs ett nytt beslut. Den generella profilen för övriga servrar förblir restriktiv.
Efter utrullningen behöver ni kontrollera faktisk konfiguration och upptäcka avvikelser från den beslutade nivån. Välj också några funktionella kontroller som ett penetrationstest eller en intern granskning kan pröva. Redovisa avvikelser, verkliga undantag och system som saknas i mätningen separat. Då visar resultatet vad som är skyddat och vad som återstår att åtgärda.
En rapport kan exempelvis visa att 95 av 100 inventerade klienter har kontrollerats: 90 följer profilen, tre har tidsbegränsade undantag och två behöver rättas. De fem som inte rapporterat ska stå som okända, inte räknas som godkända. Utse någon som utreder om de är avställda, förlorade eller bara frånkopplade. Koppla dessa uppföljningar till er plan för grundläggande IT-säkerhet, så att luckor i inventering och drift inte försvinner bakom ett högt genomsnittligt efterlevnadstal.