← Alla nyheter
ARTIKEL
16 oktober 2026 Uppdaterad den 23 september 2026 2 min läsning

MSP-FAQ: håll mänsklig och maskinell åtkomst separerad mellan klienter

Tjänstekonton och automatiseringstokens är nu fler än mänskliga användare hos de flesta organisationer. OWASP:s NHI-vägledning säger att de behöver egna identiteter och en egen livscykel.

I den här artikeln
  1. Varför NHI:er behöver separat styrning
  2. Kortlivat framför bestående
  3. Vad detta innebär i en MSP:s klientmodell

MSP:er som jonglerar teknikeråtkomst och automatisering över dussintals kundklienter står inför en specifik version av ett växande branschproblem: icke-mänskliga identiteter — tjänstekonton, API-nycklar, automatiseringstokens — behöver styras annorlunda än de människor som skapar dem.

Automatiska spärrar med kortåtkomst vid ingången till en tunnelbanestation
Foto: Secondarywaltz (CC BY-SA 4.0), Wikimedia Commons.

Varför NHI:er behöver separat styrning

OWASP:s Non-Human Identity Top 10-projekt konstaterar att maskinidentiteter inte är intrinsikalt knutna till en person och att vanliga mänskliga säkerhetskontroller, som MFA, inte mappar rent på dem. Missförhållandet handlar främst om livscykel: när en tekniker slutar avaktiveras deras konto vanligtvis inom timmar, men tjänstekontona och API-nycklarna de skapade kan fortsätta köra med full behörighet om inte någon uttryckligen hittar och återkallar dem. Eftersom icke-mänskliga identiteter kan vara betydligt fler än mänskliga konton i moderna miljöer, lämnar en MSP som styr båda på samma sätt i praktiken sin största identitetspopulation ohanterad.

Kortlivat framför bestående

Den konsekventa rekommendationen från OWASP och Cloud Security Alliance är att ersätta långlivade hemligheter med efemära, kortlivade tokens som löper ut automatiskt, snarare än autentiseringsuppgifter som fungerar på obestämd tid när de väl har utfärdats. En läckt långlivad token ger en angripare obegränsad tid; en token som löper ut inom minuter till timmar begränsar skadan även om den läcker.

Vad detta innebär i en MSP:s klientmodell

  • Använd separata identitetsleverantörer eller tjänsteprincipaler för mänskliga tekniker respektive automatisering.
  • Låt aldrig en teknikers nödfallsuppgifter dubblera som en pipelines tjänsteuppgifter.
  • Bind maskintokens till en enskild kundklient — utfärda aldrig en bestående nyckel som spänner över varje klient.
  • Håll tokenlivslängder mätta i minuter till timmar och rotera vid varje personal- eller automatiseringsförändring.
  • Logga identitetsklass (mänsklig eller icke-mänsklig) tillsammans med klient-ID på varje åtkomstpost.

Lösningen är inte ett enskilt verktyg utan en styrningsvana: behandla automatisering som en egen population av identiteter, med ett eget minsta privilegie-scope per klient, snarare än en förlängning av den tekniker som satte upp den.

Källor: OWASP Non-Human Identities Top 10, Cloud Security Alliance — Defining Non-Human Identity.