# Användare ## Vad det är En användare är den, eller det, som ett system agerar för. I vanlig teknisk text gör ordet tre olika jobb, och det mesta av förvirringen kring användare kommer av att de jobben får flyta ihop till ett. Den första betydelsen är personen: någon som öppnar en produkt och försöker få något gjort. Designer, supportpersonal och produktansvariga menar oftast den, och den har ingen fast form alls inne i systemet. Den andra är kontot: den post som ett system sparar för att kunna känna igen någon igen, oftast ett namn att logga in med, en intern identifierare, en uppsättning behörigheter och en status som aktiv eller avstängd. Den mesta applikationskoden menar den. Den tredje är användaren i operativsystemet: på Unix-liknande system en post i användardatabasen med ett användarnamn och ett numeriskt användar-id, och varje process som kör agerar som exakt en av dem. De tre stämmer sällan överens ett till ett. En person kan ha konton i många tjänster, och NIST:s riktlinjer för digital identitet säger rakt ut att en person kan ha flera digitala identiteter, där var och en är unik bara inom sin egen tjänst. Ett konto kan delas av flera personer, vilket nästan alltid är ett misstag. Och väldigt många användare har ingen person bakom sig alls: webbservern, databasen, jobbet för säkerhetskopiering och skriptet för driftsättning körs var och ett som en egen användare i operativsystemet, och har ofta konton i andra system också. Det är därför definitionen från NIST lyder ”individual, or (system) process acting on behalf of an individual”, alltså en individ eller en process som agerar för en individs räkning. På en Unix-värd är det lätt att se uppdelningen mellan namn och nummer: ```text $ id ana uid=1001(ana) gid=1001(ana) groups=1001(ana) ``` Systemkärnan arbetar med numret. POSIX definierar en användardatabas som för varje användare innehåller användarnamnet, det numeriska användar-id:t, ett första grupp-id, en första arbetskatalog och ett första program att köra. Ägarskap till filer lagras som numret, och namnet slås upp först när något ska visas för en person. En process bär dessutom mer än ett användar-id: ett verkligt, som säger vem som startade den, och ett effektivt, som säger vems behörigheter den använder just då. Konton i applikationer gör oftast samma uppdelning. Schemat i SCIM, som används för att föra över användare från ett system till ett annat, kräver ett `userName` som människor ser och loggar in med, unikt inom tjänsten och jämfört utan hänsyn till versaler och gemener, och ett separat `id` som tjänsten tilldelar, som förblir stabilt och aldrig delas ut igen. En flagga, `active`, skiljer ett avstängt konto från ett som fungerar. ## Varför det spelar roll Varje beslut om åtkomst är ett beslut om en användare, så en grumlig bild av vem användaren är blir ett grumligt beslut. Frågan ”får den här personen se den här fakturan?” besvaras i koden som ”har det här kontot, i det här sammanhanget, en behörighet som täcker den här posten?”, och varje steg i den översättningen är ett ställe där den avsedda personen och det faktiska kontot kan glida isär. Gränsen mellan person och konto är också platsen där ansvarsskyldigheten finns. Loggar registrerar konton. När varje konto tillhör exakt en person säger en loggrad vem som gjorde något. När ett konto delas säger loggen vilken hemlighet som användes och ingenting om vem som skrev in den, och att stänga en persons åtkomst innebär att ändra den för alla. Användare i operativsystemet är den äldsta fungerande formen av minsta behörighet. En tjänst som kör som en egen oprivilegierad användare kan bara skada det som den användaren äger, så ett fel i den förblir ett fel i ett enda program. Samma tjänst körd som superanvändaren gör samma fel till herravälde över hela maskinen. Att ge varje program en egen användare kostar en rad konfiguration och begränsar varje misstag som kommer efter. Till sist har personer och konton olika livslängd. Personer byter namn, e-postadress och arbetsgivare, och konton stängs av, slås ihop och raderas. Ett system som behandlar ett attribut som kan ändras, t.ex. en e-postadress, som kontots identitet kommer en dag att knyta en persons historik till någon annan. ## Så ser det ut i praktiken På en maritim plattform förvaltar yrkesverksamma organisationer, som företag och akademier, som saknar egna inloggningar. Sidan säger regeln rakt ut: personen är kontot, och organisationen är något som personen agerar på uppdrag av. Arbetet var ett [kontextbyte som låter en användare agera som vilken organisation som helst som den förvaltar](/sv/portfolio/designed-an-organization-context-switching-system-with-client-59/). Webbläsarens lokala lagring håller reda på vilken organisation som är aktiv, så bytet sker direkt, och en cookie på serversidan speglar valet så att sidor som renderas på servern visar samma kontext. Åtkomsten följer ändå användaren och inte det webbläsaren minns: servern slår upp behörigheten på nytt när varje anrop kommer in, så den som redigerar det sparade värdet ändrar bara vad den egna skärmen visar. På företagets egen värd levereras releaser av en användare i operativsystemet som nästan inte har några rättigheter alls. När [containermiljön](/sv/portfolio/deployed-a-container-plane-on-podman-and-quadlet-122/) sattes upp skildes driftsättning från provisionering. Root används en gång, för att förbereda driftsättningsvägen. Varje senare driftsättning görs av den oprivilegierade användaren, som genom en avgränsad regel får köra ett enda fast skript utan argument och ingenting annat. En rutinmässig release bygger avbildningen och startar om tjänsten utan att något root-skal öppnas. Att veta vilka användarna är blir i sig en rapport. En av [sju skrivskyddade rapportroller](/sv/portfolio/built-seven-read-only-host-reporting-roles-120/) återger en åtkomstrapport från den levande värden som Markdown i repot, med konton, sudo-omfattning, nyckelfingeravtryck, användare i git-forgen och databasroller sida vid sida. Alla sju rapporterna redovisar enbart siffror som körningen själv har mätt. Tillsammans har rapporterna hittat verkliga saker, bl.a. två döda säkerhetsåtgärder och en odeklarerad lyssnande port. ## Var det går fel **En raderad användare kommer tillbaka som någon annan.** Ett konto tas bort, dess identifierare delas senare ut igen, och det nya kontot ärver allt som fortfarande pekar på det gamla värdet: rader i en tabell, en plats på en lista, filer på disken. På en Unix-värd behåller de filer som en borttagen användare ägde sin numeriska ägare, och nästa användare som skapas med det numret äger dem. Ge konton identifierare som aldrig återanvänds, så som SCIM kräver av sitt `id`, och bestäm vad som händer med en avgående användares data innan användaren tas bort. **En e-postadress används som konto.** Den ser ut som en naturlig nyckel tills någon byter adress, förlorar åtkomsten till en gammal eller en arbetsgivare ger en adress vidare till en ny medarbetare. Då knyts en persons historik till en annan, eller så får en person två konton. Behåll en stabil intern identifierare som nyckel och behandla adressen som ett attribut som kan ändras. **Alla loggar in med samma konto.** En delad administratörsinloggning går fort att sätta upp och är omöjlig att granska. När någon slutar upphör åtkomsten bara om hemligheten ändras för alla, och loggen namnger en roll i stället för en person. Ett konto per person, där delad makt ges genom grupper, roller eller en snävt avgränsad sudo-regel, håller både loggen och avgångarna ärliga. **Webbläsaren avgör vad användaren får göra.** En roll som sparas i lokal lagring, i en cookie eller i ett dolt formulärfält är ett förslag från klienten, och vem som helst kan redigera det. Om servern litar på det blir redigeringen en attack. Klienten får minnas sammanhang för bekvämlighetens skull, men servern måste själv kontrollera behörigheterna, vid varje anrop. **En tjänst kör som root för att det var enklare.** Allt fungerar, och det första felet i den tjänsten är ett fel i hela värden. Ge varje tjänst en egen oprivilegierad användare, och ge varje extra rättighet snävt, för ett namngivet kommando, i stället för brett. ## Läs mer - [NIST CSRC glossary: user](https://csrc.nist.gov/glossary/term/user) — definitionerna som används i NIST:s publikationer om säkerhet, var och en med det dokument den kommer från. - [POSIX.1-2024 Base Definitions: Definitions](https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap03.html) — den formella betydelsen av user database, user ID och user name på Unix-liknande system. - [RFC 7643: SCIM Core Schema](https://www.rfc-editor.org/rfc/rfc7643) — resursen User för att flytta konton mellan tjänster, med `userName`, `id` och `active`. - [NIST SP 800-63-4: Digital Identity Guidelines](https://pages.nist.gov/800-63-4/sp800-63.html) — hur en person kan ha flera digitala identiteter, och rollerna applicant, subscriber och claimant.