← Kennisbank · Security Architecture

Waar moet mijn oplossing toegang opnieuw controleren?

Security Trust Boundary Map

Maak grensovergangen zichtbaar en koppel iedere toegang aan identiteit, bevoegdheid en controlebewijs.

Uitleg en hulpmiddelen · v1.0 · Gepubliceerd

Download template (.pptx)Download ingevuld voorbeeld (.pptx)Download samenvatting (.png)

Wanneer gebruik je dit?

  • Bij een nieuwe koppeling of blootstelling van een dienst.
  • Bij review van toegangsrechten en ongewenste gegevensoverdracht.

Wat heb je nodig?

Dienst, omgeving, actoren en beschermde informatie.

Een voorbeeld uit de praktijk

Fictieve casus: Noordhaven Servicebureau

Bij Noordhaven vraagt een gebruiker via een API een eigen aanvraag op. Aanmelden stelt vast wie de gebruiker is. Daarnaast moet de API controleren of die gebruiker juist dit dossier mag lezen.

De API gebruikt een eigen dienstidentiteit voor het register. Ook de beheerder heeft afzonderlijke bevoegdheden. Een bekend account of een interne netwerkpositie geeft geen automatische toegang tot alle dossiers.

De proef gebruikt twee fictieve accounts met verschillende dossiers. Account A moet het eigen dossier kunnen lezen en mag dossier B niet lezen, ook niet via een directe API-aanvraag. Dit bewijst alleen de geteste dossiercontrole; andere rollen en routes vragen eigen controles.

Bekijk de visuele samenvattingVisuele samenvatting van Security Trust Boundary MapOpen op volledig formaat (nieuw tabblad)

Aan de slag

  1. Baken dienst, actoren en beschermde gegevens af.
  2. Teken zones, gegevensstromen en vertrouwensgrenzen.
  3. Beschrijf per overgang identiteit en toegestane handeling.
  4. Werk een misbruikscenario, controle en bewijs uit.
Naar de downloads ↑

Controleer je resultaat

  • Een zone is geen automatische toestemming.
  • Elke grensovergang benoemt actor, handeling en gegevens.
  • Identiteitscontrole en bevoegdheidscontrole zijn onderscheiden.
  • Een maatregel verwijst naar een misbruikscenario en toetsbaar bewijs.
Verdieping en begrippen
EAW-codes
Lokale verwijzingen die kaart, register, scenario en besluit met elkaar verbinden.

Wat beschrijft dit model?

Een EAW Security Trust Boundary Map toont waar een actor of gegevensstroom een grens met andere toegangsvoorwaarden passeert. Per overgang beschrijft het model de identiteit, gevraagde handeling, beschermde gegevens, controle en het bewijs van werking.

Afbakening

De kaart ondersteunt ontwerp en review. Zij vervangt geen volledige dreigingsanalyse, penetratietest of autorisatiemodel. Een netwerkzone, versleutelde verbinding of bekende identiteit bewijst op zichzelf niet dat een actor bevoegd is voor een specifiek dossier.

Zo lees je de werkbladen

De codes zijn EAW-werkafspraken. Gebruik dezelfde codes in de kaart, registers en besluiten. De template bevat vier werkbladen; het voorbeeld vult precies dezelfde velden in.

Grensovergangen in de oplossing

Dienst, omgeving, actoren en beschermde informatie. Benoem per grens welke toegangsvoorwaarden wijzigen. Stroomcode, richting en handeling per verbinding. Bronstatus, versie en peildatum.

Stromen en bevoegdheid

Actor, doel, handeling, informatie en beslisregel. Actor, doel, handeling, informatie en beslisregel. Actor, doel, handeling, informatie en beslisregel. Welke informatie is voor elke stroom noodzakelijk? Ontbrekende regel, eigenaar en vervolgactie.

Misbruikscenario en controle

Ongewenste handeling en geraakt belang. Controle, plaats van afdwingen en eigenaar. Testgegevens, verwachte weigering en bewijs. Toegestane handeling en gewenst resultaat. Wat wordt vastgelegd zonder gevoelige gegevens te kopiëren?

Besluit en resterende risico’s

Welke conclusie ondersteunt het bewijs werkelijk? Besluit, bevoegde eigenaar, rationale en voorwaarden. Niet afgedekte situatie en eigenaar. Welke wijziging maakt het eerdere bewijs onvoldoende? Waar staan plaatsing, informatiebetekenis en integratieafspraken?

Fictief voorbeeld: Noordhaven

Alle toewijzingen en maatregelen zijn voorstellen binnen een verzonnen oefencasus. Zij zijn geen bewezen productiegedrag.

Grensovergangen in de oplossing

Scope — Fictief loket Noordhaven. Productie-API voor aanvragen. Beschermd: aanvraaggegevens en bijlagen.

Zones en grenzen — G-01: aanvrager naar API. G-02: API naar register. G-03: beheerder naar beheerfunctie. Geen zone geeft automatisch toegang.

Lijnbetekenis — F-01 vraagt eigen aanvraag op. F-02 leest dossier via API-identiteit. F-03 wijzigt beheerinstellingen.

Status — Fictief ontwerp v1.0. Controles zijn voorstellen en nog niet als werkend getest.

Stromen en bevoegdheid

F-01 / G-01 — A-01 vraagt P-01 om eigen aanvraag. Identiteit vastgesteld én toegang tot precies dit dossier gecontroleerd. Alleen aanmelden is onvoldoende.

F-02 / G-02 — P-01 leest R-01 met eigen dienstidentiteit. Beperk bewerkingen en gegevens. Toegang van de aanvrager blijft een afzonderlijke controle.

F-03 / G-03 — A-02 gebruikt de beheerfunctie. Beheerdersrol geeft niet automatisch inzage in alle aanvragen. Beheerhandelingen afzonderlijk autoriseren.

Gegevensbeperking — F-01 toont alleen benodigde velden van het toegestane dossier. F-02 retourneert die selectie. F-03 bevat geen dossierinhoud.

Onzekerheid — Uitzondering voor vertegenwoordiging is nog niet ontworpen. Security- en proceseigenaar bepalen mandaatcontrole vóór toevoeging.

Misbruikscenario en controle

S-01 — Een aangemelde aanvrager wijzigt het dossiernummer en probeert een aanvraag van iemand anders te lezen.

M-01 — P-01 controleert bij ieder dossierverzoek de bevoegdheid voor actor én dossier. Applicatieteam implementeert de controle serverzijdig.

Negatieve proef — Twee fictieve testaccounts met verschillende dossiers. Account A mag dossier B niet lezen, ook niet via een directe API-aanvraag.

Positieve proef — Account A kan het eigen dossier lezen. De test controleert noodzakelijke velden en voorkomt dat een totale blokkade als beveiligingssucces telt.

E-01 — Testverslag met scenario, versie, pseudonieme testidentiteiten en resultaat. Geen tokens of dossierinhoud in het verslag.

Besluit en resterende risico’s

Beoordeling — Een geslaagde S-01-proef onderbouwt alleen de geteste dossiercontrole. Geen conclusie over alle rollen of andere API-routes.

D-01 — Fictief voorstel: vrijgave pas na positieve en negatieve proef van F-01, F-02 en F-03. Security-eigenaar adviseert; diensteigenaar beslist.

Open risico — Vertegenwoordiging blijft buiten scope. Proceseigenaar levert de regels, applicatieteam ontwerpt daarna de bevoegdheidscontrole.

Herijkmoment — Nieuwe rol, beheerfunctie, dossierkoppeling of vertegenwoordiging vraagt herbeoordeling van betrokken stromen en tests.

Andere modellen — Verwijs naar Solution Interaction & Integration Model en Solution Information Usage Model. Hergebruik dezelfde actor- en resourcecodes.

Gebruik het resultaat

Controleer de kwaliteitscriteria. Bespreek ontbrekend bewijs met de genoemde eigenaar en leg vast wanneer het model opnieuw wordt beoordeeld. Een ingevulde template is nog geen goedgekeurd ontwerp.

Verder werken

Gebruik een verwant onderwerp om een volgend deel van je vraag uit te werken.

Ook bij EAW

Je accountvoorkeuren worden geladen.

Achtergrond en bronnen

EAW-werkwijze en werktemplate. Voorbeeldcasussen zijn fictief.

Codes en modelstructuur zijn EAW-werkafspraken; geen formele notatiestandaard.

Versie 1.0 · Gepubliceerd

NIST SP 800-207
Parafrase: netwerkpositie of eigendom alleen geeft geen impliciet vertrouwen; authenticatie en autorisatie zijn afzonderlijke functies. Deze kaart is geen volledige zero-trustarchitectuur of conformiteitsverklaring.