Wat zijn rolaccounts?
Rolaccounts zijn accounts die gekoppeld zijn aan een specifieke rol binnen je organisatie (d.w.z. een groep medewerkers of een geautomatiseerd systeem) in plaats van aan een individu. Ze worden vaak gebruikt om taken te automatiseren en gegevensstromen te stroomlijnen.
Als je HR-systeem bijvoorbeeld moet communiceren met het salarissysteem, kun je een gebruiker "hr" instellen om het credentialing-proces te automatiseren. Je kunt vervolgens de logboeken controleren om te zien wanneer het account met de rol ”hr” toegang heeft tot het Payroll-systeem, waardoor je meer inzicht krijgt in toegangspatronen. Daarnaast weet je dat het verkeer dat door “hr” wordt veroorzaakt geen verkeer van een individuele gebruiker is, dus kun je het uitfilteren wanneer je scant op onregelmatig inloggedrag. Dit kan je workflows zowel tijd besparen als de beveiliging verbeteren.
Er zijn echter ook enkele nadelen. Er ontstaan problemen wanneer je rolaccounts onjuist gaat gebruiken met systemen die een identiteit vereisen. Een rolaccount delen tussen meerdere medewerkers als een login voor meervoudig gebruik voor een leverancier (bijv. vendor-name@mystartup.com), het gebruik van de gebruiker “ubuntu” op een in de cloud gehoste Linux-host, of het gebruik van het account “Administrator” op onze Windows-servers, zijn allemaal voorbeelden van het gebruik van rolaccounts in strijd met best practices. Dit zijn allemaal systemen waarbij het gebruik van een unieke identiteit belangrijk is en het delen van een rolaccount de beveiliging in gevaar brengt.
Enkele voorbeelden van functieaccounts
Wanneer je in deze systemen een rolaccount gebruikt, verlies je de mogelijkheid om verkeer te scheiden. Daardoor worden toegangslogboeken onduidelijk en ondoorzichtig.
Als voorbeeld:
Je logboeken laten zien dat gebruiker “ubuntu” om 04:32:15 heeft ingelogd en de opdracht rm -rf */command heeft uitgevoerd. Je hebt echter geen inzicht in welke van je engineers de opdracht daadwerkelijk heeft uitgevoerd, omdat ze een gedeeld rolaccount gebruikten!
Nog een voorbeeld:
Al je Account Reps loggen in op je gehoste CRM (Customer Relationship Manager) als “vendor-name@mystartup.com”, omdat het veel goedkoper is om maar één account te hebben en dit zorgt voor meer transparantie binnen het team. Je kunt echter niet zien wie wat heeft gedaan, alleen dát het is gedaan.
Dit zijn slechts mogelijke administratieve kwesties en kwesties rond verantwoording. Het echte gevaar van misbruik van rolaccounts komt door verzwakte beveiliging.
Wanneer je dit soort gedeelde role accounts gebruikt, moeten de inloggegevens telkens worden gewijzigd wanneer iemand het team verlaat, en moeten die nieuwe inloggegevens opnieuw worden verspreid onder iedereen die toegang nodig heeft. Dit is een arbeidsintensief en handmatig proces dat gevoelig is voor fouten.
Veelvoorkomende valkuilen
Hoewel je de problemen met gedeelde rolaccounts kunt beperken door goede hygiëne toe te passen en unieke middelen te gebruiken om toegang te krijgen tot het rolaccount, verhul je uiteindelijk nog steeds identiteiten. Het instellen van de accounts “ec2-user” en “Administrator” om unieke sleutels of certificaten te gebruiken die individuele toegang tot rolaccounts verlenen, is beter, maar nog steeds slechts een gedeeltelijke oplossing.
Vertrouwen op je medewerkers en collega's is een belangrijk onderdeel van elk beveiligingssysteem. Maar elke keer dat je iemand aan het team toevoegt, voeg je meerdere aanvalsvectoren toe aan de resources waartoe die persoon toegang heeft. Wanneer je rolaccounts gebruikt, zijn al die aanvalsvectoren geconcentreerd op één enkel doelwit, waardoor een aanvaller nu meerdere manieren heeft om dezelfde set inloggegevens aan te vallen.
Bovendien beperkt dit je herstelopties wanneer een aanval succesvol is. Je kunt het rolaccount niet zomaar uitschakelen, want dan ontzeg je het hele team de toegang.
Een ander probleem ontstaat wanneer teamleden je organisatie verlaten. Wanneer de stageperiode van je salesstagiair afloopt en diegene nog steeds toegang heeft tot je volledige CRM, is dat meer dan alleen het meenemen van zijn of haar adresboekje – het is het meenemen van ieders adresboekje. Als je lead engineer het team verlaat, heeft diegene nog steeds de private key voor je gebruikersrolaccount “ubuntu” op zijn of haar persoonlijke laptop. Als die ex-medewerker bij een concurrent gaat werken, kan diegene ongemerkt doorlopend toegang tot je infrastructuur behouden.
De juiste weg vooruit
Gelukkig kunnen al deze problemen worden opgelost door elke persoon die toegang heeft tot je tools een eigen identiteit te geven. Je logboeken worden overzichtelijker en het wordt duidelijk vastgelegd wie wel en geen toegang heeft tot systemen.
Het toekennen en intrekken van rechten wordt een eenvoudige taak en is gemakkelijk te controleren. Bovendien slapen je CEO en beveiligingsteam ’s nachts een stuk rustiger, omdat niemand van buiten het bedrijf chaos kan veroorzaken in je systemen.
Traditioneel had je op elk systeem dat je wilde gebruiken een unieke identiteit nodig om het gebruik van rolaccounts te vermijden. Dat betekent dat voor elke host waarop je wilde inloggen en elke leverancier waartoe je toegang wilde hebben, voor elke medewerker unieke accounts nodig zouden zijn. Dit voegt echter alleen maar extra stappen toe aan het on-/offboardingproces en kan gemakkelijk worden vergeten.
Hier bieden oplossingen voor identiteitsbeheer uitkomst. Door één centrale identiteitsbron te gebruiken waarmee alle andere systemen kunnen integreren, verleen of trek je met één klik machtigingen in. Met protocollen zoals OAuth en SAML, gecombineerd met tools zoals LDAP en AD, krijg je een volledig identiteitsbeheer over meerdere platforms heen. Je kunt het zelf bouwen of door leveranciers geleverde oplossingen gebruiken en de mensen in je team laten uitblinken door iedereen een eigen identiteit te geven.
Bij Foxpass helpen we je om de beveiliging en operationele best practices te handhaven door het eenvoudig te maken om afzonderlijke gebruikersaccounts te beheren. We automatiseren zelfs het aanmaken en verwijderen van accounts door te synchroniseren met je identiteitsprovider (zoals Google, Office365, Okta, OneLogin of Bitium). We bieden ook functies voor tijdelijke toegang die de toegang na een ingestelde periode automatisch intrekken. Bovendien nemen onze in de cloud gehoste servers je het gedoe uit handen van een doe-het-zelf LDAP- of RADIUS-server.
Wil je zelf het gemak en de efficiëntie van Foxpass ervaren? Waar wacht je nog op? Start vandaag nog een gratis proefperiode van 30 dagen:
