Mensen ruimte geven. Gegevens en bevoegdheden beschermen.

Inloggen vertelt wie iemand is. Het bepaalt nog niet welke opdracht, medewerker of locatie die persoon mag zien of wijzigen. We werken rechten uit op het niveau waarop het bedrijf ze nodig heeft: organisatie, rol, team, object en handeling.

In de praktijk: initiatief bij de jongere, een eigen rol voor de ouder

Voor KidsJobs werkten we de ondernemersvisie uit tot product, app en backend. Opdrachtgevers plaatsen klussen, jongeren reageren en ouders hebben een eigen relatie met het account van hun kind. Een algemene rol “gebruiker” zou die verschillende verantwoordelijkheden niet beschrijven.

We modelleerden de accounts, hun onderlinge relaties en de stappen van klus naar toewijzing. Die productuitwerking laat zien waar een rechtenmodel begint: begrijpen namens wie iemand handelt en wat die persoon zelfstandig moet kunnen doen.

We nemen ook het intrekken van toegang mee. Een andere functie, beëindigde samenwerking of gewijzigd team moet doorwerken in wat iemand kan doen.

Een verborgen knop is geen beveiliging. Kritieke acties moeten ook worden gecontroleerd als iemand een verzoek rechtstreeks naar de API stuurt.

Bij een platform voor vastgoedonderhoud bouwden we toepassingen voor beheerders, leveranciers en uitvoerders. De backendfunctie voor een gedeelde werkorder controleert identiteit en beheerderscontext. De mobiele toepassing haalt werk op binnen de context van leverancier, medewerker en datum. Eén opdracht verbindt zo meerdere organisaties, ieder met een eigen verantwoordelijkheid.

Bij het aanvraag- en partnerplatform heeft de registratie van commissiebatches een expliciete beheerderscontrole in de API. Niet alleen het portaal, maar ook de verwerking zelf kent die bevoegdheidsgrens.

Bij directe toegang tot Firestore richten we passende Security Rules in. Serverlibraries gaan daar niet automatisch doorheen: die gebruiken andere toegangsmechanismen. Daarom verdienen backendautorisatie en IAM hun eigen ontwerp en tests. Google licht dit onderscheid toe.

App Check kan daarnaast helpen verzoeken uit toegestane apps of apparaten te herkennen. Het vervangt geen gebruikersrechten; het vult de gebruikersauthenticatie aan. Over App Check.

Welke gegevens zijn echt nodig voor een handeling? Wie moet ze kunnen zien? Hoe lang blijven ze beschikbaar? En komen ze ook terecht in exports, logs, back-ups, testomgevingen of een AI-verzoek?

We maken die gegevensstromen zichtbaar en vertalen afspraken naar het ontwerp. Bijvoorbeeld minder persoonsgegevens in logging, afzonderlijke bestandsrechten en testdata die geen kopie van personeelsdossiers hoeven te zijn.

De gewenste opslagregio en de rol van externe leveranciers nemen we mee in de keuze. Een Europese serverlocatie is op zichzelf geen volledig privacybeleid. De technische inrichting moet passen bij de afspraken en verplichtingen van de organisatie; juridische beoordeling blijft een eigen verantwoordelijkheid.

Integraties en achtergrondtaken hebben eigen identiteiten en rechten nodig. We ontwerpen die voor hun taak. Een dienst die informatie uitleest, heeft niet vanzelf toestemming nodig om gegevens te verwijderen of financiële handelingen te starten.

Geheimen horen niet in de frontend, broncode of gewone logregels. We nemen beheer van sleutels, omgevingen en toegangen mee in de oplevering. Voor gevoelige beheerhandelingen bespreken we aanvullende verificatie en passende scheiding van verantwoordelijkheden.

Een test moet niet alleen aantonen dat een bevoegde gebruiker de juiste gegevens ziet. We willen ook weten of een gebruiker buiten de eigen organisatie wordt geweigerd, of oude toegangen echt vervallen en of een ongeldige statuswijziging wordt tegengehouden.

Onze aanpak omvat, passend bij de opdracht:

• Een overzicht van gegevens, rollen en belangrijke risico’s.
• Tests voor toegestane én geweigerde handelingen.
• Controle van dependencies, configuratie en gevoelige gegevensstromen.
• Review van kritieke wijzigingen en herstelmogelijkheden.
• Een afgesproken route voor beveiligingsmeldingen en onderhoud.

Voor toepassingen met verhoogde risico’s kan een onafhankelijke pentest onderdeel van het traject worden. We bepalen die diepgang op basis van de gevolgen van een fout, niet op basis van de grootte van het scherm.

Een assistent die namens iemand handelt, moet dezelfde grenzen respecteren. We bepalen welke bronnen hij mag gebruiken, welke handelingen hij kan voorbereiden en welke expliciete goedkeuring vragen.

De autorisatie blijft buiten het taalmodel. Dat is ook de kern van OWASP’s advies over te ruime agentbevoegdheden. Lees over excessive agency. Onze agentic architectuur maakt dit concreet.

Software, medewerkers en leveranciers veranderen. Daarom horen updates, toegangsbeheer, monitoring en incidentafspraken bij het gesprek over beheer. We leggen vast wat wij verzorgen, wat bij jullie organisatie ligt en welke controles bij een verandering opnieuw nodig zijn.

Je krijgt inzicht in de inrichting, de uitgevoerde controles en de afspraken waarop je kunt sturen. Bespreek de technische verantwoordelijkheid voor jullie platform.