En lösenordspolicy behöver omfatta hela vägen till ett konto: skapande, inloggning, flerfaktorsautentisering, återställning och stängning. Ett långt lösenord hjälper inte om supporten kan ta bort den andra faktorn utan tillräcklig kontroll. Börja därför med vilka konton och system som ska skyddas, och välj regler som faktiskt kan införas och följas upp.
Här finns ett ifyllt exempel på en intern policy samt en arbetsgång för att kontrollera inställningarna. De tekniska värdena i exemplet är en organisations val med en angiven referens. De ska inte läsas som universella krav i svensk lag.
Skilj svenska säkerhetskrav från tekniska referenser
Artikel 32 i GDPR kräver säkerhetsåtgärder som är lämpliga med hänsyn till risken. Den anger inte en bestämd lösenordslängd för alla system. IMY:s råd om lösenordshantering framhåller bland annat flerfaktorsautentisering för skyddsvärda uppgifter över öppna nät, unika lösenord, lösenordshanterare och skydd mot klartextlagring.
En teknisk referens är NIST SP 800-63B-4, avsnitt 3.1.1.2. Inom dess tillämpningsområde ska lösenord som används som enda faktor ha minst 15 tecken. Minst åtta får användas när lösenordet bara används inom flerfaktorsautentisering. Referensen anger stöd för minst 64 teckens maximal längd, kontroll mot olämpliga eller komprometterade val och begränsning av inloggningsförsök. Den avråder från godtyckliga sammansättningskrav och återkommande tidsstyrda byten, men kräver byte när det finns tecken på kompromettering.
NIST är här en uttryckligt vald referens, inte svensk lag eller ett beslut från IMY. Kontrollera särskilda verksamhetskrav separat. Ett system för patientuppgifter eller säkerhetskänslig verksamhet kan behöva bedömas mot ytterligare regler.
Inventera alla vägar till systemen
För varje applikation bör ni identifiera vanliga konton, administratörer, leverantörsåtkomst, integrationskonton och nödkonton. Kontrollera om inloggningen går genom organisationens centrala identitetstjänst eller kan ske lokalt i applikationen. En centralt beslutad MFA-regel täcker inte automatiskt den lokala administratören.
Använd systemkartläggningen för att hitta beroenden. En äldre integration kan använda ett tekniskt konto som inte klarar samma interaktiva inloggning som en människa. Det kräver en egen hantering av hemligheter och behörigheter, inte ett permanent undantag som döljs under ”alla använder MFA”.
Dokumentera också vem som bestämmer kravet och vem som gör inställningen. Supporten behöver veta hur återställning ska gå till. Systemägaren behöver bekräfta vilka användare som ska omfattas. Säkerhetsansvarig behöver kunna bedöma avvikelser och kontrollera resultatet.
Ifyllt exempel på en intern regel
Anta att ett konstruerat tjänsteföretag inför gemensam autentisering för kundsystem och dokumenthantering. Företaget väljer följande regler för sina användarkonton:
| Område | Företagets beslut i exemplet |
|---|---|
| Längd | Minst 15 tecken även där MFA används; systemet ska tillåta minst 64 |
| Unikhet | Varje tjänst ska ha ett unikt lösenord när separat lösenord behövs |
| Olämpliga val | Kända komprometterade, vanliga och lätt förutsägbara lösenord avvisas |
| Sammansättning | Inga obligatoriska mönster med viss blandning av teckentyper |
| Byte | Byte vid misstänkt eller bekräftad kompromettering; inget rutinbyte var tredje månad |
| MFA | Krävs för de berörda tjänsterna; administratörer får särskilt bedömda metoder |
| Hantering | Godkänd lösenordshanterare; inga hemligheter i ärenden eller chattar |
| Återställning | Identiteten kontrolleras enligt supportens fastställda rutin före ändring |
Företaget väljer 15 tecken även med MFA för att ha en enhetlig regel inom detta begränsade område. NIST:s möjlighet till minst åtta inom MFA betyder inte att åtta är rätt val i varje verksamhet. Tabellen omfattar inte maskinella hemligheter eller alla tänkbara specialsystem.
Den publicerade policyn ska inte innehålla ett exempel som medarbetare kan kopiera som sitt riktiga lösenord. Beskriv i stället hur ett unikt lösenord genereras eller hur slumpmässigt valda ord kan användas. Ett långt citat eller en känd fras kan fortfarande vara lätt att gissa.
Kontrollera att systemen accepterar reglerna
Prova skapande, vanlig inloggning, byte och återställning med en avsedd testidentitet. Samma längd och teckenstöd ska fungera genom alla stegen. Ett formulär som accepterar en lång sträng hjälper inte om inloggningen senare kapar den eller återställningssidan har en lägre gräns.
Kontrollera hur lösenordshanteraren fungerar i de aktuella tjänsterna. Användaren bör kunna följa organisationens säkra rutin utan att behöva klistra in hemligheter i ett dokument. Om ett system kräver delade personliga konton bör behov och möjliga alternativ omprövas.
Detta hör ihop med inbyggt dataskydd: en säker inställning ska vara möjlig att använda i den verkliga arbetsprocessen. Annars riskerar personalen att skapa egna lösningar som organisationen inte känner till.
Välj MFA och kontrollera reservvägar
Flerfaktorsautentisering bygger på olika typer av faktorer, exempelvis något användaren vet och något användaren har. Två lösenord är inte automatiskt två faktorer. Bedöm metodernas motståndskraft mot nätfiske och felaktig återställning, särskilt för administratörer och fjärråtkomst till skyddsvärd information.
IMY:s vägledning om autentisering förklarar sambandet mellan identitetskontroll och behörighet. Autentisering bekräftar vem som loggar in; behörigheten avgör vad personen får göra. En säker inloggning ska därför inte användas som argument för bredare åtkomst än arbetsuppgiften kräver.
Kartlägg alla reservmetoder. Om en stark huvudmetod kan kringgås med en svagt skyddad återställningsadress blir helheten svagare än huvudmetoden antyder. Kontrollera även vem som får lägga till en ny faktor och hur användaren underrättas om en oväntad ändring.
Gör återställning till en egen arbetsprocess
Rutinen bör börja med vilken situation som inträffat: glömt lösenord, förlorad faktor, misstänkt övertagande eller spärrat konto. Dessa situationer behöver inte hanteras på samma sätt. Ett misstänkt kontointrång kan kräva att aktiva sessioner och andra autentiseringsmetoder återkallas, inte bara att lösenordet byts.
I företagsexemplet får supporten inte återställa en administratörs MFA enbart efter ett mejl som påstår sig komma från administratören. Handläggaren använder en i förväg fastställd kontrollväg och en separat godkännandeprocess för privilegierad åtkomst. Underlaget beskriver kontrollen som utförts, utan att lagra hemliga koder eller onödiga identitetshandlingar.
Registrera relevanta återställningshändelser i säkerhetsloggningen. Det ska gå att se vem som initierade och genomförde ändringen. Loggen ska inte innehålla det nya lösenordet, återställningslänken eller återställningskoden.
Skydda lagringen och skilj på tekniska hemligheter
Lösenord ska inte lagras i klartext. System som verifierar lösenord behöver en ändamålsenlig, saltad lösenordshashning med motstånd mot offlineangrepp. Parametrar och metoder måste väljas och underhållas mot aktuell teknisk dokumentation. Vanlig kryptering av databasen ersätter inte säker lösenordslagring hos applikationen.
API-nycklar, certifikat och integrationshemligheter har andra livscykler än användarens memorerade lösenord. Ange ägare, rättigheter, giltiga användningar och hur en hemlighet ersätts utan att nödvändiga tjänster stannar. En teknisk hemlighet som läckt till en kodfil behöver hanteras även om ingen ännu har observerat missbruk.
Se kryptering och nyckelhantering för att avgränsa skydd av transport och lagring. Lägg inte kopior av alla hemligheter i samma allmänt tillgängliga driftdokument som beskriver återställningen.
Stäng åtkomst vid rollbyte och avslut
När någon byter arbetsuppgifter ska gamla rättigheter tas bort om behovet upphör. Vid avslut behöver organisationen kontrollera centrala konton, lokala konton, aktiva sessioner, leverantörsportaler och kända delade hemligheter. Att stänga e-postkontot är inte en komplett avveckling.
Nödkonton ska ha en ägare och en kontrollerad användningsrutin. De behöver vara tillgängliga när den ordinarie identitetstjänsten inte fungerar, men inte utgöra en dold permanent genväg. Användningen ska följas upp och hemligheter hanteras efter det som inträffat.
Knyt avbrottsscenariot till kontinuitetsplanen. Företaget i exemplet låter två utpekade funktioner kontrollera att nödåtkomsten kan användas utan att den beror på samma otillgängliga inloggning som den ska ersätta. Antalet funktioner är ett lokalt organisationsval, inte ett generellt lagkrav.
Verifiera innan policyn markeras som införd
Välj ett representativt system och kontrollera normal inloggning, avvisat olämpligt lösenord, MFA, förlorad faktor och avslutad användare. Dokumentera faktisk observation, ansvarig och kvarstående brist. Sprid inte skärmbilder med hemligheter som bevis på att inställningen fungerar.
I exemplet visar första kontrollen att huvudkontot kräver MFA men en gammal lokal inloggning fortfarande fungerar utan den. Teamet stänger vägen efter kompatibilitetskontroll och uppdaterar systemkartan. Policyns status ändras först när kontrollen upprepats med rätt resultat.
Låt informationssäkerhetspolicyn ange ansvar för återkommande uppföljning. Ändringar i tjänster, hotbild eller återställningsvägar ska kunna utlösa en tidigare granskning. Det viktiga slutresultatet är ett regelsystem som motsvarar den faktiska inloggningen och som supporten kan upprätthålla även när något går fel.