Eén abonnement delen kan licentiekosten besparen, maar de werkelijke kosten zijn vaak hoger. Dit artikel behandelt vier problemen: schending van voorwaarden, verspreiding van inloggegevens, niet-toewijsbare logs en blijvende toegang na vertrek, plus conforme alternatieven.
Een extra gebruikersseat voor een SaaS-tool kan een flinke kostenpost zijn. Naarmate een team groeit, wordt die rekening steeds zichtbaarder.
Daarom voelt het logisch om één set inloggegevens te delen, vooral wanneer iemand alleen af en toe een rapport hoeft te bekijken of tijdelijk gegevens voor een klant moet controleren. De werkelijke kosten worden echter vaak onderschat en zitten verspreid over verschillende gebieden: voorwaarden, inloggegevens, logs en personeelswisselingen. Elk onderdeel brengt zijn eigen problemen mee.
De voorwaarden zijn duidelijk: accounts zijn niet om te delen
De meeste SaaS-producten werken met licenties per seat. Behalve enterprise- of teamabonnementen die expliciet meerdere gebruikers ondersteunen, zijn andere plannen meestal bedoeld voor één gebruiker. In de servicevoorwaarden is het delen van dezelfde inloggegevens door meerdere personen doorgaans expliciet verboden, en het platform kan de toegang opschorten of intrekken zodra dit wordt vastgesteld. Eén punt wordt gemakkelijk gemist: zo’n beëindiging gaat meestal niet gepaard met een terugbetaling, waardoor reeds betaalde bedragen verloren kunnen gaan.
Er is ook een minder zichtbare kostenpost. Het motief voor delen is besparen, maar het platform blijft zijn prijsmodel baseren op het aantal mensen dat toegang nodig heeft. De besparing komt er dus op neer dat licentiekosten worden ingeruild voor een compliancerisico dat pas zichtbaar wordt wanneer er iets misgaat.
Als veel mensen het wachtwoord kennen, is niet duidelijk wie handelde
Delen betekent dat het wachtwoord tussen meerdere personen circuleert, vaak via chatapps, notities of andere plekken waar één bericht een blijvend spoor kan worden.
Het probleem is niet alleen het wachtwoord zelf, maar ook twee gevolgen. Ten eerste wordt het blootstellingsoppervlak groter: hoe meer mensen meedoen, hoe groter de kans dat iemand hetzelfde wachtwoord elders heeft hergebruikt of dat een apparaat wordt gecompromitteerd en zo een ingang tot het account ontstaat. Ten tweede wordt aansprakelijkheid moeilijk vast te stellen. Als het account wordt gebruikt om data te exporteren, instellingen te wijzigen of ongewenste inhoud te versturen, is achteraf alleen te zien wat het account heeft gedaan, niet wie de handeling uitvoerde. Voor teams die klanten moeten uitleggen waar data is geweest, is dit vaak het lastigste onderdeel.
Activiteitenlogs registreren het account, niet de persoon
SaaS-beheeromgevingen slaan activiteiten meestal per account op: wie een rapport exporteerde, welke instellingen werden gewijzigd en welke gegevens werden verwijderd. In het log staat vaak slechts één accountnaam.
Zodra meerdere personen hetzelfde account gebruiken, valt die traceerbaarheid weg. Intern is niet vast te stellen wie een wijziging heeft gedaan, en de anomaliedetectie van het platform loopt tegen hetzelfde probleem aan. Het systeem kan zien dat hetzelfde account vanuit meerdere steden, apparaten en netwerkuitgangen inlogt, met gelijktijdige sessies, en dat gedrag markeren. Veelvoorkomende reacties zijn gedwongen afmelden, tijdelijke blokkering of aanvullende verificatie. Als de tool onderdeel is van het dagelijkse werk, kan een blokkade tijdens kantooruren veel meer kosten dan enkele extra seats.
Wisselen van proxy of het uniformeren van browserfingerprints kan de kans op detectie alleen verkleinen; het maakt gedeelde inloggegevens niet conform. Als bovendien alle aanmeldingen aan dezelfde omgeving zijn gekoppeld, kan één probleem met die omgeving — bijvoorbeeld een gemarkeerd IP-adres of een als afwijkend beoordeelde omgeving — de toegang voor iedereen tegelijk onderbreken en zo de impact vergroten.
Iemand vertrekt, maar de toegang blijft bestaan
Wanneer een medewerker vertrekt of een externe samenwerking eindigt, is vaak niemand duidelijk verantwoordelijk voor het intrekken van toegang tot een gedeeld account. De reden is eenvoudig: het account is van iedereen, dus er is geen vaste overdrachtsstap.
Er blijven meerdere risico’s achter. Een oud teamlid kan het wachtwoord nog kennen, terwijl niemand weet wie het nog meer heeft opgeslagen. Eerder uitgegeven sessiecookies kunnen nog geldig zijn. Als die persoon automatiseringsscripts of API-aanroepen met het account heeft ingesteld, verdwijnen die toegangspaden evenmin automatisch. Tegen de tijd dat het probleem wordt ontdekt, kunnen gegevens al zijn gewijzigd.
Bovendien zou bij elke wijziging in de teamsamenstelling het wachtwoord voor iedereen moeten worden aangepast. In een gedeeld model lukt het vaak niet om dat volledig door te voeren.
Conforme alternatieven zijn niet ingewikkeld
Wanneer de redenen voor delen afzonderlijk worden bekeken, zijn de passende oplossingen vrij duidelijk.
- Voor vaste teamleden die langdurig toegang nodig hebben: koop extra seats. Dit is de enige officieel ondersteunde manier voor meerdere gebruikers en maakt persoonsgerichte traceerbaarheid in logs weer mogelijk.
- Voor grotere teams: controleer of het platform een multi-user team- of enterpriseplan heeft. Zulke plannen bieden meestal een rechtenmodel waarmee per rol kan worden beperkt wat iemand mag bekijken of wijzigen.
- Voor centrale toegangscontrole: gebruik SSO. Wanneer iemand vertrekt, kan de toegang centraal worden uitgeschakeld zonder afhankelijk te zijn van een handmatige herinnering.
- Om tijdelijk resultaten met een klant te delen: exporteer een rapport of maak een alleen-lezen deel-link, zodat de klant gegevens kan controleren zonder op het account in te loggen.
Het is belangrijk om accountdeling te onderscheiden van het gebruik van meerdere accounts. Bij accountdeling gebruiken meerdere mensen dezelfde inloggegevens. Bij meerdere accounts heeft iedereen eigen inloggegevens, maar moeten die op hetzelfde apparaat naast elkaar kunnen werken zonder elkaar te storen; dat model kan op zichzelf conform zijn. Als een team bijvoorbeeld voor elk lid een seat koopt en iedereen een eigen account heeft, kunnen cookies en sessies elkaar in één browser overschrijven. Een aparte browseromgeving per account houdt sessies, cache en data gescheiden. PurpleMark biedt precies dit soort omgevingsisolatie. Het lost het probleem op van meerdere legitieme accounts die stabiel op één apparaat naast elkaar moeten bestaan; het verandert niet dat meerdere mensen die één set inloggegevens delen nog steeds de servicevoorwaarden overtreden.
Reken het eerst uit
In wezen ruilt accountdeling compliancerisico in voor een kleine besparing op seatkosten. Incidenteel, tijdelijk gebruik door één persoon kan een tijdlang lijken te werken, maar op teamschaal kunnen ingetrokken toegang of een data-incident veel meer kosten dan de besparing.
Bereken eerst de licentiekosten en kies daarna de juiste aanpak. Kun je seats kopen, koop dan seats; kun je data exporteren, exporteer die dan.
Raadpleeg voor de exacte licentieregels altijd de officiële voorwaarden van het betreffende product.
