Beveiliging — Synly

Drie inlogmethoden, één beveiligingsmodel

Synly ondersteunt drie authenticatiemethoden. De keuze hangt af van wat uw organisatie al gebruikt — de beveiligingsgaranties zijn in alle gevallen gelijkwaardig.

Wachtwoord + JWT

Gebruikersnaam en wachtwoord worden gevalideerd tegen een bcrypt-hash. Na inloggen ontvangt u een kortlevend access token (1 uur) en een refresh token (7 dagen).

bcrypt JWT HS256

OIDC via Keycloak

Synly valideert JWT's via de JWKS-eindpunten van uw Keycloak-instantie. Sleutels worden gecacht en automatisch ververst. Geschikt voor organisaties met een centrale identiteitsprovider.

OAuth 2.0 OIDC RS256 JWKS

SAML 2.0 SSO

Compatibel met ADFS, Shibboleth en DigiD. Synly valideert de XML-assertion cryptografisch via het X.509-certificaat van de IdP. Alleen een geldige, ondertekende assertion leidt tot een sessie.

SAML 2.0 RSA handtekening X.509

Zes onafhankelijke beveiligingslagen

Authenticatie is slechts de eerste laag. Elke API-aanroep wordt getoetst aan zes onafhankelijke controles — het falen van één laag stopt de aanroep.

Identiteitsbewijs — cryptografische tokenverificatie

Elk verzoek aan de API vereist een geldig Bearer-token in de Authorization-header. Het token wordt cryptografisch geverifieerd: bij JWT via de gedeelde sleutel, bij OIDC via de publieke JWKS-sleutel van de IdP, bij SAML via het X.509-certificaat. Een verlopen, gemanipuleerd of onbekend token wordt onmiddellijk geweigerd met HTTP 401.
Rolcontrole — alleen wat uw rol toestaat

Elke API-route controleert de rol uit het token: superadmin, admin, editor of reader. Lezers kunnen nooit schrijven; editors kunnen nooit tenantinstellingen wijzigen. Ontbrekende rechten leiden tot HTTP 403, ongeacht andere parameters.
Lidmaatschapscontrole — tenant-aanspraak geverifieerd in de database

Het token beweert dat u bij een bepaalde tenant hoort. Synly verifieert dit bij iedere aanroep opnieuw in de database. Is uw account tussentijds verwijderd of inactief gemaakt? Dan faalt deze check en wordt de aanroep geblokkeerd — ook met een nog geldig token.
Row-Level Security — isolatie op databaseniveau

PostgreSQL Row-Level Security zorgt dat zelfs een rechtstreekse databasequery van een ingelogde gebruiker nooit data van een andere tenant kan retourneren. De tenant-UUID wordt per sessie ingesteld vóór elke query. Dit is de diepste verdedigingslinie: onafhankelijk van de applicatielaag.
Accountbeveiliging — vergrendeling na mislukte pogingen

Na vijf aaneengesloten mislukte inlogpogingen wordt een account automatisch 15 minuten vergrendeld. Dit blokkeert geautomatiseerde brute-force aanvallen zonder de gebruiker permanent uit te sluiten. Een beheerder of superadmin kan de vergrendeling direct opheffen.
Auditlog — volledige verantwoording van wijzigingen

Elke schrijfoperatie — concepten aanmaken, bewerken of verwijderen, importeren, exporteren, rolewijzigingen — wordt gelogd met actor-ID, e-mailadres, actie en tijdstip. Het auditlog is alleen leesbaar voor beheerders en niet manipuleerbaar door gewone gebruikers.

Wachtwoorden en sessies

Hoe Synly omgaat met gevoelige gegevens als wachtwoorden en sessie-tokens.

Wachtwoorden worden nooit opgeslagen

Synly slaat uitsluitend een bcrypt-hash op — het wachtwoord zelf is onherleidbaar. Zelfs bij volledige databaselekkage zijn wachtwoorden niet te achterhalen.

Kortlevende access tokens

Access tokens vervallen na 1 uur. Refresh tokens na 7 dagen. Verlopen tokens worden geweigerd; de gebruiker moet opnieuw inloggen of het access token laten vernieuwen.

Token opslag in de browser

Access tokens worden in sessionStorage bewaard — ze verdwijnen automatisch bij het sluiten van de browser. Refresh tokens staan in localStorage en zijn niet toegankelijk via XSS door het ontbreken van inline script in de API-responses.

Rate limiting op kwetsbare eindpunten

Het inlogpunt is beperkt tot 10 verzoeken per minuut per IP-adres. Mutatie-eindpunten (aanmaken, wijzigen, verwijderen) zijn beperkt tot 60 per minuut. Dit blokkeert geautomatiseerde aanvallen.

Wachtwoordcomplexiteit afgedwongen

Synly vereist minimaal 8 tekens, één hoofdletter, één cijfer en één speciaal teken. Zwakke wachtwoorden worden geweigerd bij aanmaken én bij wijzigen.

Token-intrekking zonder wachttijd

Zodra een beheerder een account deactiveert, wordt bij de volgende API-aanroep — nog vóór tokenverloop — het lidmaatschap in de database gecheckt. Er is geen wachttijd van maximaal 1 uur: de blokkering werkt per aanroep.

Veelgestelde vragen

Vragen die we vaak krijgen van IT-beveiligers en privacy-officers.

Is de tenant-identificatie via een URL-slug niet een beveiligingsrisico?

De slug bepaalt alleen welke inlogmethode wordt aangeboden — niet wie er toegang krijgt. De slug zelf is niet geheim: hij staat in de URL en is vergelijkbaar met een bedrijfsnaam kiezen bij een inlogportaal.

De eigenlijke beveiliging zit in de vier lagen hierboven. Iemand die een andere slug invult, krijgt hooguit de inlogpagina van een andere tenant te zien — maar kan zich niet aanmelden zonder geldige credentials voor die tenant. En zelfs dan: de rol- en lidmaatschapscheck (lagen 2 en 3) en de Row-Level Security (laag 4) voorkomen dat iemand data van een andere tenant bereikt.

Organisaties die een methode willen afdwingen — zodat medewerkers alleen via SAML kunnen inloggen en niet via wachtwoord — kunnen dat instellen. De applicatie weigert dan wachtwoord-logins voor die tenant, ook als iemand probeert de slug te omzeilen.

Kan een gebruiker van tenant A ooit data van tenant B zien?

Nee — en dat is afdwingbaar op databaseniveau. PostgreSQL Row-Level Security zorgt dat elke query alleen rijen retourneert die horen bij de tenant-UUID in de huidige sessie. Dit geldt ook als de applicatielaag een fout zou maken: de database weigert de query.

De UUID van een tenant staat niet in de URL of een andere gebruikersinvoer — hij wordt uitsluitend uit het cryptografisch geverifieerde token gehaald.

Wat gebeurt er als een medewerker de organisatie verlaat?

Een beheerder kan een gebruikersaccount onmiddellijk deactiveren of verwijderen. Laag 3 (lidmaatschapscontrole) blokkeert dan alle nieuwe API-aanroepen — ook met een nog geldig, onverlopen token. Er is geen wachttijd tot het token verloopt.

Hoe worden SAML-assertions gevalideerd?

Synly gebruikt de python3-saml-bibliotheek van OneLogin, die de SAML 2.0-specificatie implementeert. Elke assertion wordt gecontroleerd op: geldige RSA-handtekening met het X.509-certificaat van uw IdP, geldig tijdvenster (NotBefore / NotOnOrAfter), juiste Audience (uw SP Entity ID) en juiste Destination (uw ACS-URL). Een assertion die ook maar één controle faalt, wordt geweigerd.

Worden OIDC-sleutels gecacht? Wat als een sleutel gecompromitteerd is?

Publieke JWKS-sleutels worden maximaal 1 uur gecacht per kid (key ID). Bij een onbekende kid haalt Synly de JWKS opnieuw op. Als uw Keycloak-instantie een sleutel intrekt en roteert, worden nieuwe tokens gesigneerd met de nieuwe sleutel-ID. Tokens met de oude sleutel-ID falen de verificatie zodra de cache verloopt of bij een cache miss.

Waar worden de gegevens opgeslagen?

Alle thesaurusdata wordt opgeslagen in een PostgreSQL-database op de Synly-infrastructuur, gehost binnen de Europese Unie. U heeft toegang tot uw data via de browser en via de REST API — er is niets te installeren. Beheerders kunnen de volledige thesaurus altijd exporteren in standaardformaten (SKOS/Turtle, CSV, JSON-LD), zodat u uw vocabulaire nooit kwijtraakt.

Wat gebeurt er na meerdere mislukte inlogpogingen?

Na vijf aaneengesloten mislukte pogingen wordt het account automatisch 15 minuten vergrendeld. De gebruiker ziet een melding met de resterende wachttijd. Een beheerder of superadmin kan de vergrendeling direct opheffen — zonder te hoeven wachten. Na een geslaagde inlog wordt de teller gereset.

Heeft Synly een auditlog?

Ja. Elke schrijfoperatie wordt vastgelegd: het aanmaken, bewerken en (zacht) verwijderen van concepten en relaties, imports, exports, rolewijzigingen en logingebeurtenissen. Elke log-entry bevat de actor-UUID, het e-mailadres, de actie, het betrokken object en het tijdstip (UTC). Het auditlog is inzichtelijk voor beheerders en niet te wijzigen of te verwijderen via de applicatielaag.

Compliance en standaarden

Synly is ontworpen met de vereisten van overheidsorganisaties als uitgangspunt.

BIO

Baseline Informatiebeveiliging Overheid — de beveiligingsarchitectuur van Synly sluit aan bij de BIO-maatregelen voor toegangsbeheer en gegevensbeveiliging.

AVG / GDPR

Synly verwerkt alleen de persoonsgegevens die strikt noodzakelijk zijn voor de dienstverlening. Een verwerkersovereenkomst is beschikbaar.

SAML 2.0

OASIS-standaard voor federated identity. Vereist door veel overheids-IdPs, waaronder ADFS-installaties en DigiD Machtigen.

OAuth 2.0 + OIDC

Industrie-standaard voor gedelegeerde autorisatie. Ondersteund via Keycloak of een andere OIDC-conforme identiteitsprovider.

HTTP Beveiligingsheaders

Alle API-responses bevatten Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Content-Security-Policy en Referrer-Policy — conform OWASP-aanbevelingen.

Soft delete

Concepten en relaties worden niet onomkeerbaar verwijderd. Een deleted_at-tijdstempel markeert ze als verwijderd; ze blijven herstelbaar via de prullenbak. Dit voorkomt onherstelbaar dataverlies.

Beveiliging zonder compromissen