Är lösenord i ett system fortfarande nödvändigt?
Lösenord har blivit utdömda fler gånger än någon orkar räkna. Regelverken för att hantera lösenord gör det riktigt besvärligt att använda. Förutom att lösenordet måste vara långt och komplext ska det dessutom roteras regelbundet. Administrationen för att flera personer ska ha tillgång till ett systemlösenord för exempelvis en databasanslutning eller ett rootkonto gör att du antingen behöver dela det genom en lösenordshanterare eller i värsta fall lägga ett kuvert i ett kassaskåp. Det är omöjligt att lista ut vilken person som slarvade med rutinerna ifall det gemensamma lösenordet kommer på avvägar. Lösningen på detta är inte ännu längre eller komplexare lösenord. Alla som någon gång försökt knappa in ett lösenord på 40 tecken i en VMWare-konsoll med exotisk tangentborsuppsättning svär att detta aldrig ska få hända igen. Lösningen är naturligtvis att inte använda lösenord. Då kan vi automatiskt slänga en rejäl bit av regelverken som handlar om lösenordshantering och lösenordskvalitet.
Samma lösenord på administrator/rootkonto på alla maskiner i organisationen
Det är inte så ovanligt som man kan tro. Det är himla praktiskt att ha lösenordet sommar2001 på alla maskiner när man som systemadministratör ska felsöka vid något oväntat tillfälle. Är du dessutom systemadministratör gäller inte reglerna för lösenordskomplexitet dig, bara dina användare. Det var inget bra val för tjugofem år sedan och det har inte blivit bättre med tiden.
Du sparar väl inte lösenord i klartext i ditt repo?
Har du lösenord i klartext i ditt Git-repo bör du åtgärda det direkt. Även andra textsträngar som kan användas för autentisering kan vara problematiska om de indirekt ger tillgång till mer information än planerat. Du behöver även byta lösenordet då versionshistoriken ser till att det fortfarande är tillgängligt. Hur många som redan läst informationen i ditt repo vet du inte heller. Programvaran trufflehog hjälper dig att leta igenom alla repon i din organisation efter hemligheter.
Men program X måste ha lösenordet i klartext i en fil för att fungera. Om det inte går att lösa är din sista utväg strikta behörigheter noggrann övervakning av vilka användare som faktiskt petar på filen. Alla moderna operativsystem har inbyggd funktionalitet för att logga vilka användare som gjort vad med en utvald fil. Loggarna måste dock transporteras till en central loggserver där en SOC förhoppningsvis kan sätta upp regler för övervakning.
Hantering av hemligheter är inget nytt problem
Kör du k8s i en större miljö är det sannolikt att någon redan satt upp en Vault-instans. Ska den däremot spänna över flera datorhallar behöver man se över att allt verkligen fungerar vid eventuella driftstörningar i framtiden. Det kan även finnas licenstekniska incitament att leta efter andra lösningar än Vault i större miljöer. Guldstjärna om ett HSM (Hardware Security Module) används för hemligheterna, detta är något som inte ens alla molnjättar lyckats med att implementera.
Klientcertifikat kan användas för autentisering
Många system fungerar också med certifikat för säkra anslutningar till exempelvis databasanslutningar eller webtjänster. Även certifikaten måste hanteras på ett säkert sätt men det är fortfarande en bättre lösning än klassiska lösenord. Stödet för automatiserad certifikathantering är ibland redan på plats, om det enkelt går att rotera ofta är detta ett lockande alternativ.
Hur bygger vi då system utan lösenord?
Sitter du i en modern moln- eller k8s-miljö är problemet i princip redan löst åt dig. Det fungerar inte likadant överallt men någon lösning för säker lösenordshantering brukar det finnas. En gammal monolit kräver sannolikt lösenord i en textfil, det kan du inte bygga bort, bara övervaka.
OIDC (OpenID Connect protocol) och M2M (Machine to Machine)
Bästa lösningen idag är att helt lämna över beslutet om applikation x får prata med applikation y till OIDC. Detta är ofta snyggt löst hos molnleverantörerna så att du inte ens vet att det är OIDC i botten. I en lösning onprem där saker ska fungera utan externa beroenden blir det ditt arbete att sätta upp en IDP (IDentity Provider) om ingen gjort det före dig. Din IDP bör dessutom vara redundant eftersom väldigt få saker kommer fungera vid en eventuell driftstörning.
Vad besvärligt det blev. Det blev plötsligt ganska mycket arbete för att bli av med lösenorden. Kanske är det därför de fortfarande lever kvar? Det viktiga är att arbetet påbörjas och att du är medveten om problemen och inte bygger nya lösningar med gamla problem.
Användarnas lösenord då?
Det tar vi nästa gång!
Inläggsförfattare
