Mijn accountSecurity Architecture · gratis praktijkroute
Oefen hoe je een toegangsgrens tekent, een misbruikscenario formuleert en maatregelen toetsbaar maakt. Je levert een kleine securityreview op.
Voor: Startende security- en solution-architecten. Werk in je eigen document; deze pagina bewaart geen antwoorden.
Fictieve casus: Noordhaven laat gebruikers hun eigen aanvraag bekijken via een portaal. Een API haalt dossiers op uit een register. Beheerders ondersteunen de dienstverlening. De toepassing draait op een beheerde clouddienst. Contractafspraken en bewaartermijnen zijn nog niet vastgesteld.
Je levert op: Een kaart met toegangsgrenzen, drie misbruikscenario’s en een controleplan met verantwoordelijken.
Stap 1 van 5
Begin met de dienstverlening, actoren en informatie. Authenticatie stelt de identiteit vast. Autorisatie bepaalt welke handeling die identiteit op welke gegevens mag uitvoeren. Een intern netwerk of bekend account is op zichzelf geen bewijs van bevoegdheid.
Benoem gebruiker, beheerder, API en register. Beschrijf voor elk de gewenste handeling. Welke informatie mag een gebruiker nooit over een andere gebruiker ontvangen?
Open de template voor toegangsgrenzen →
Gebruiker A mag het eigen dossier raadplegen. Voor dossier B is een afzonderlijke bevoegdheidsgrond nodig; alleen ingelogd zijn volstaat niet. De API gebruikt een dienstidentiteit voor het register. Beheer vraagt een expliciete rol met afgebakende taken. Welke beheertaken werkelijk nodig zijn, moet nog worden vastgesteld.
Heb je identiteit, handeling en gegevens afzonderlijk benoemd?
Naar stap 2 →Stap 2 van 5
Een grens is een plek waar andere vertrouwens- of beheeraannames gelden. Teken ook de teruggaande gegevensstroom. Een pijl zonder identiteit en handeling vertelt te weinig om toegangscontrole te beoordelen.
Teken gebruiker → API → register en beheerder → beheerfunctie. Noteer per overgang de identiteit, gegevens en plaats van controle. Markeer wat je nog niet weet.
Bij gebruiker → API moet de API controleren of de identiteit deze aanvraag mag lezen. Bij API → register moet de dienst alleen de noodzakelijke registerhandelingen kunnen uitvoeren. Een beheerpad krijgt eigen bevoegdheden. Het is nog onbekend hoe de beheerde dienst deze controles ondersteunt; daarvoor zijn ontwerp en configuratiebewijs nodig.
Wordt controle ook server-side uitgevoerd wanneer iemand het portaal overslaat?
Naar stap 3 →Stap 3 van 5
Een bruikbaar dreigingsscenario beschrijft actor, handeling, zwakke plek en mogelijk gevolg. 'De applicatie wordt gehackt' is te algemeen. Maak het scenario concreet genoeg om een maatregel en test te kiezen.
Beschrijf: gebruiker A vraagt dossier B op; een ingetrokken beheerrol doet een beheerhandeling; de API vraagt onnodig veel gegevens op. Noteer per scenario het gevolg en ontbrekend bewijs.
Bepaal welke informatie nodig is →
Voor het eerste scenario kan een ontbrekende dossiercontrole leiden tot inzage in andermans gegevens. Het ontwerp moet afwijzen, ook bij een directe API-aanvraag. Voor de beheerrol moet de verwachte werking na intrekking expliciet zijn, inclusief sessiegedrag. Voor de API vergelijk je noodzakelijke gegevens met werkelijk ontvangen velden. De casus levert nog geen betrouwbare kansinschatting.
Is elk scenario verbonden aan een te beschermen belang en een concrete controlevraag?
Naar stap 4 →Stap 4 van 5
Een beheerde dienst neemt niet vanzelf alle beveiligingstaken over. Verdeel per concrete taak uitvoering, besluit en controlebewijs. De precieze verdeling volgt uit dienst, configuratie en contract.
Werk toegang beheren, logregistratie en herstel oefenen uit. Wie voert uit, wie accepteert het resultaat en welk leveranciersbewijs ontbreekt?
Vul de verantwoordelijkheidsmatrix in →
Een voorstel kan zijn dat klantbeheer gebruikersrechten beheert, de provider de platformvoorziening levert en de diensteigenaar de herstelproef accepteert. Dat is pas een afspraak wanneer het contract en de operationele werkwijze dit ondersteunen. Registreer daarom 'voorgesteld', 'afgesproken' en 'getoetst' afzonderlijk. Een certificaat van een leverancier bewijst deze dossiercontrole niet.
Hebben alle taken een verantwoordelijke en is de contractaanname herkenbaar?
Naar stap 5 →Stap 5 van 5
Een geslaagde toegestane handeling bewijst nog niet dat ongeoorloofde toegang wordt geweigerd. Gebruik positieve en negatieve proeven. Werk alleen in een daarvoor bestemde testomgeving met fictieve dossiers en geautoriseerde testaccounts.
Schrijf een proef voor eigen dossier, ander dossier en ontbrekende sessie. Noteer verwachte uitkomst, eigenaar, datum en wat het bewijs niet dekt. Sluit af met een vrijgaveadvies.
Account A leest dossier A. Dezelfde account krijgt dossier B niet terug, ook niet met een directe aanvraag. Zonder sessie wordt geen dossierinhoud verstrekt. Bewaar het resultaat zonder wachtwoorden, tokens of echte dossiers. Met alleen deze drie proeven zijn andere rollen, beheer, herstel en configuratie nog niet bewezen. Het advies benoemt daarom welke vragen vóór ingebruikname nog moeten worden gesloten.
Bevat je controleplan zowel toegestane als geweigerde handelingen en een duidelijke bewijsgrens?
De volledige Security Architecture-training is in ontwikkeling. Deze route is een begeleide oefening met zelfcontrole; je voert hier geen technische aanval of officiële eindtoets uit.