Maatwerksoftware & portalen

Rollen en toegangsrechten in een klantportaal: wie mag welk dossier gebruiken?

Werk klantportaalrechten uit per organisatie, dossier, handeling en gegeven, met uitnodigingen, downloads, wijzigingen en concrete afwijzingstests.

Op deze pagina

Een klantportaal geeft gebruikers toegang tot werk dat bij hen hoort. De moeilijke vraag is niet alleen wie kan inloggen, maar wie welk dossier mag bekijken, aanpassen of bevestigen. Een algemeen rolletje “klant” of “medewerker” beantwoordt die vraag vaak onvoldoende. Dezelfde persoon kan bij meerdere organisaties horen of tijdelijk een taak voor een collega uitvoeren.

Deze gids helpt de gewenste grenzen ontwerpen en beoordelen. Het voorbeeld is een fictief serviceportaal waarin klanten aanvragen indienen en medewerkers voortgang verwerken. De beschreven proefgevallen zijn ontwerp- en beoordelingsmateriaal, geen uitgevoerde beveiligingstest. Een bruikbaar rechtenplan legt normale toegang, uitgesloten situaties en veranderingen gedurende het gebruik naast elkaar. Zo kunnen opdrachtgever en ontwikkelaar hetzelfde gedrag bespreken voordat accounts en echte dossiers worden aangesloten.

Scheid aanmelden van toestemming

Aanmelden kan vaststellen welk account een gebruiker gebruikt. Daarmee is nog niet besloten dat dit account een bepaald dossier mag openen. Beschrijf daarom apart hoe de identiteit bekend wordt en welke relatie toegang geeft. Een uitgenodigde klantcontactpersoon kan bijvoorbeeld alleen aanvragen zien van de organisatie waarvoor de uitnodiging geldig is, terwijl een andere relatie een eigen selectie heeft.

OWASP beschrijft onder meer standaard weigeren en controle van bevoegdheid bij iedere relevante aanvraag. Vertaal dat beperkte technische uitgangspunt naar je eigen portaalregels. Een verborgen knop is bijvoorbeeld geen projectcriterium voor het verhinderen van een handeling. De beoordeling moet betrekking hebben op wat de applicatie daadwerkelijk accepteert wanneer iemand een dossier of actie rechtstreeks probeert aan te spreken.

OWASP: Authorization Cheat Sheet ↗

Maak een matrix met relaties en handelingen

Begin met enkele herkenbare rollen: klantcontactpersoon, klantbeheerder, behandelaar en intern beheerder. Beschrijf daarnaast welke organisatie en dossiers bij iedere rol horen. Splits de handelingen op in bekijken, aanvullen, downloaden, uitnodigen en bevestigen. Een rol kan in de ene organisatie meer mogen dan in een andere, zodat alleen een globaal functielabel niet genoeg is om de selectie te bepalen.

Werk eerst één normale aanvraag uit. De klantcontactpersoon kan eigen aanvragen aanvullen, de klantbeheerder kan medewerkers van dezelfde organisatie uitnodigen en de behandelaar kan een toegewezen aanvraag beoordelen. Bespreek daarna een uitgesloten geval: een behandelaar van een andere regio mag het dossier niet bekijken. Daarmee krijgt de matrix betekenis als een verzameling beslissingen in plaats van alleen een tabel met vinkjes.

Beperk ook de gegevens binnen een dossier

Toegang tot een aanvraag hoeft niet automatisch toegang tot ieder veld te betekenen. Een intern verslag, commerciële notitie en klantzichtbare status kunnen verschillende doelgroepen hebben. Bepaal welke informatie een rol nodig heeft voor haar taak en welke informatie alleen intern blijft. Maak die keuze zichtbaar in voorbeeldrecords zodat gebruikers herkennen wat wel en niet in het portaal hoort.

Let ook op afgeleide weergaven: zoekresultaten, aantallen, exports en meldingen kunnen informatie prijsgeven die niet in de detailpagina staat. Een overzicht met een verborgen klantnaam maar herkenbare onderwerpregel kan de grens alsnog onduidelijk maken. Neem daarom de verschillende presentaties van hetzelfde dossier mee in het ontwerp. Het rechtenplan moet de gegevens volgen, niet alleen de plaats waar zij worden getoond.

Als het portaal ook bedrijfsdocumenten doorzoekbaar maakt, moeten diezelfde toegangsgrenzen doorwerken in de zoeklaag: Toegangsrechten in RAG: wie mag welke bedrijfskennis terugvinden?.

Ontwerp uitnodigen en organisatiekeuze expliciet

Een uitnodiging moet duidelijk maken voor welke organisatie en verantwoordelijkheid iemand wordt toegevoegd. Laat een klantbeheerder niet ongemerkt toegang verlenen tot andere organisaties doordat een bestaand e-mailadres meerdere rollen kan hebben. Beschrijf wie een uitnodiging mag versturen, hoe een acceptatie wordt gekoppeld en wat gebeurt bij een verlopen of ingetrokken uitnodiging.

Een gebruiker met meerdere relaties moet kunnen begrijpen in welke context hij werkt. Toon de relevante organisatie en zorg dat een contextwissel de gegevensselectie volgt. Test een handeling die is voorbereid voordat de gebruiker van organisatie wisselt. De applicatie moet kunnen bepalen voor welke relatie de handeling geldt; de laatst getoonde schermtitel mag die beslissing niet stilzwijgend overnemen.

Behandel bestanden als zelfstandige toegangspunten

Een download kan buiten de normale detailpagina worden geopend of later opnieuw worden gebruikt. Leg vast hoe de applicatie bepaalt of de gebruiker het document op dat moment nog mag krijgen. Het bezitten van een verwijzing naar een bestand is niet hetzelfde als een actuele zakelijke relatie met het dossier. Onderzoek ook wat gebeurt wanneer iemand zijn accounttoegang of organisatierol verliest.

Gebruik in de proef twee organisaties met vergelijkbare bestandsnamen. Laat zien dat een geldige gebruiker zijn eigen document kan openen en dat dezelfde route geen document van de andere organisatie oplevert. Neem een gewijzigd of vervangen bestand op, zodat duidelijk is welke versie bedoeld is. Een correcte lijstweergave bewijst op zichzelf nog niet dat de achterliggende downloadgrens goed is ingericht.

Maak wijzigen en bevestigen verschillende rechten

Een gebruiker die informatie mag aanvullen, hoeft niet automatisch een definitieve afspraak te mogen bevestigen. Beschrijf de consequentie van iedere handeling. Een adres corrigeren, een voorstel accepteren en een interne taak afronden zijn verschillende gebeurtenissen. Bepaal welke gegevens de gebruiker daarvoor moet zien en of opnieuw beoordelen nodig is wanneer de inhoud na een eerdere controle verandert.

In het fictieve portaal kan een contactpersoon een concept indienen, terwijl een klantbeheerder een specifieke opdracht bevestigt. Bewaar daarbij welke inhoud is beoordeeld en door welke geldige rol de overgang is gemaakt. De technische inrichting moet voorkomen dat een later gewijzigde versie wordt uitgevoerd alsof zij al is goedgekeurd. Bespreek voor belangrijke handelingen expliciet hoe die koppeling aantoonbaar wordt gemaakt.

OWASP: Transaction Authorization Cheat Sheet ↗

Bereid vertrek, vervanging en intrekken voor

Een rechtenplan is pas volledig bruikbaar wanneer toegang ook kan veranderen. Een medewerker vertrekt, een klantcontactpersoon krijgt een andere taak of een dossier wordt overgedragen. Beschrijf welke toegang vervalt, welke openstaande acties moeten worden beoordeeld en wie de verantwoordelijkheid overneemt. Een geblokkeerd account alleen vertelt niet hoe het werk daarna verdergaat.

Maak het verschil duidelijk tussen historisch bewijs en actuele bevoegdheid. Je wilt kunnen begrijpen wie een eerdere beslissing nam, zonder die persoon blijvend toegang te geven. Neem bij intrekken ook bestaande sessies, gedeelde verwijzingen en geplande acties in het technische onderzoek mee. De concrete aanpak hangt af van de gebruikte systemen; de gewenste zakelijke grens moet vooraf duidelijk blijven.

Leg toegangsonderzoek uit aan de beheerder

Wanneer een gebruiker een dossier niet kan openen, moet een bevoegde beheerder kunnen onderzoeken waarom. Gebruik begrijpelijke redenen zoals ontbrekende organisatierelatie, vervallen uitnodiging of niet-toegewezen dossier. Geef ondersteuning genoeg informatie om een juiste vervolgstap te bepalen zonder automatisch alle dossierinhoud breder toegankelijk te maken voor iedereen die een melding kan lezen.

Bespreek wie een toegangswijziging mag goedkeuren en hoe die wordt geregistreerd. Een helpdeskmedewerker die wachtwoorden helpt herstellen hoeft niet zelf klantrelaties te mogen toekennen. Werk een situatie uit waarin spoed wordt gevraagd. Een herkenbare escalatieroute is beter beheersbaar dan ad-hocbeheer waarmee iedere onduidelijke blokkade wordt opgelost door een gebruiker meteen een veel ruimere rol te geven.

Beoordeel met een kleine maar betekenisvolle proefset

Maak voor iedere belangrijke rol een toegestane en geweigerde handeling. Neem directe dossierverwijzingen, downloads en aanvragen na een rolwijziging mee. Controleer niet alleen welke melding verschijnt, maar ook dat de verboden wijziging niet is opgeslagen en de afgeschermde inhoud niet wordt teruggegeven. Bewaar de gebruikte fictieve accounts, records en verwachte resultaten bij de betreffende versie.

Herhaal de relevante gevallen wanneer een nieuw roltype, organisatieverband of gegevensweergave wordt toegevoegd. De proefset groeit mee met betekenisvolle grenzen, niet met iedere cosmetische verandering. Laat de proceseigenaar beoordelen of de verwachte toegang past bij het werk en de ontwikkelaar uitleggen waar zij wordt afgedwongen. De combinatie van zakelijke keuzes en aantoonbaar applicatiegedrag maakt een rechtenplan praktisch bruikbaar voor ontwerp en overdracht.

Van uitleg naar een concrete projectkeuze

Leg je aannames, open vragen en oplevercriteria vast in de bijbehorende tool. Gebruik de dienstengidsen om uitvoering en afbakening te bespreken.

Open de voorbereidingstool ↗

Vragen over dit onderwerp

Is een rolverdeling met klant en beheerder voldoende?

Soms voor een zeer eenvoudige toepassing, maar onderzoek ook de relatie met organisatie, dossier en handeling. Een algemene rol zegt niet vanzelf welke specifieke records iemand mag gebruiken. Begin met concrete voorbeelden van toegang die moet worden toegestaan en geweigerd.

Moet iedere download opnieuw worden gecontroleerd?

Het ontwerp moet voorkomen dat een bestand beschikbaar wordt buiten de afgesproken toegang. Onderzoek hoe actuele rechten, bestandsverwijzingen en intrekken samen werken in de gekozen technische omgeving. Neem downloaden apart op in de proefset; een verborgen link is op zichzelf geen afgedwongen grens.

Kan deze gids aantonen dat mijn portaal veilig is?

Nee. Zij helpt de gewenste grenzen en proefgevallen voorbereiden. Het daadwerkelijke ontwerp, de implementatie en de passende controles moeten in de eigen omgeving worden onderzocht. Een afgerond rechtenplan of geslaagde kleine proef onderbouwt geen onbeperkte beveiligingsgarantie.

Verder met een aansluitende vraag

Bronnen en technische achtergrond

Bespreek je project met Ricardo ↗