Întrebări frecvente MSP: separați accesul uman de cel al identităților non-umane

MSP-urile care gestionează accesul tehnicienilor și automatizările în zeci de tenanți ai clienților se confruntă cu o versiune specifică a unei probleme tot mai mari din industrie: identitățile non-umane — conturi de serviciu, chei API, token-uri de automatizare — trebuie guvernate diferit față de oamenii care le creează.

De ce identitățile non-umane au nevoie de o guvernanță separată

Proiectul OWASP Non-Human Identity Top 10 subliniază că identitățile mașinilor nu sunt legate intrinsec de o persoană și că controalele de securitate umane obișnuite, cum ar fi MFA, nu se aplică direct asupra lor. Diferența principală ține de ciclu de viață: când un tehnician pleacă, contul său este de obicei dezactivat în câteva ore, dar conturile de serviciu și cheile API create de acesta pot continua să ruleze cu permisiuni complete dacă nimeni nu le găsește și le revocă explicit. Deoarece identitățile non-umane pot depăși cu mult numărul conturilor umane în mediile moderne, un MSP care guvernează ambele categorii în același mod lasă de fapt neadministrată cea mai mare populație de identități.

Token-uri de scurtă durată în locul celor permanente

Recomandarea constantă din partea OWASP și a Cloud Security Alliance este înlocuirea secretelor de lungă durată cu token-uri efemere, de scurtă durată, care expiră automat, în locul unor credențiale care funcționează la nesfârșit odată emise. Un token de lungă durată compromis oferă atacatorului timp nelimitat; un token care expiră în minute sau ore limitează daunele chiar dacă este compromis.

Ce înseamnă acest lucru în modelul de tenanți al unui MSP

• Folosiți furnizori de identități sau principalii de serviciu distincți pentru tehnicienii umani versus automatizări.
• Nu permiteți ca o credențială break-glass a unui tehnician să fie folosită și ca credențială de serviciu pentru un pipeline.
• Legați token-urile mașinilor de un singur tenant al clientului — nu emiteți niciodată o cheie permanentă care să acopere toți tenanții.
• Mențineți durata de viață a token-urilor măsurată în minute sau ore și rotiți-le la orice schimbare de personal sau de automatizare.
• Înregistrați clasa identității (umană sau non-umană) alături de ID-ul tenantului în fiecare înregistrare de acces.

Soluția nu constă într-un singur instrument, ci într-un obicei de guvernanță: tratați automatizarea ca pe o populație distinctă de identități, cu propriul său domeniu de privilegii minime per tenant, și nu ca pe o extensie a tehnicianului care a configurat-o.

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