In de wereld van internet, webapplicaties en cloud computing wordt de verwerking van gegevens vaak geregeld via het ter beschikking stellen van webservices.

Er zijn verschillende soorten webservices, zoals SOAP en REST.

In deze blogpost zal kort ingegaan worden over het gebruik van webservices bij het verwerken van persoonsgegevens.

Wat zijn webservices?

Webservices zijn een gestandardiseerde manier om gegevens over een netwerk uit te wisselen.

Het laat een veelheid van applicaties, die met verschillende technologieën werden ontwikkeld (PHP, .NET, Java, Python, …), via een gestandardiseerde interface toe om gegevens uit te wisselen; via een doorgaans publiek netwerk (het internet) dat voornamelijk loopt over HTTP of HTTPS.

Een webservice kan, simpel uitgedrukt, een klein software programma zijn dat via een URL kan worden uitgevoerd, en waarbij de vragende partij enkele parameters via een query string kan meegeven aan de service provider of aan de backend, om bepaalde gegevens te bekomen. M.a.w. een webpagina met daarin een algorithme verwerkt dat business logica vertegenwoordigt.

In sommige gevallen zal de uitvoering van de webservice slechts een uitvoering inhouden van een andere webservice, die gehost wordt bij een derde.

Het contract

De beschikkingstelling van webservices is gedefinieerd in een overeenkomst, waarin de aard (methoden GET, PUT, POST, …), het adres (endpoints waar de webservice kan worden gevonden), de communicatie (HTTP, HTTPS, …) en de output en scope van de output als deliverables (JSON, XML, HTML, …) in zijn opgenomen.

Het contract, dat bijvoorbeeld gedefinieerd is in de WSDL taal (Web Service Description Language), kan ook verschillende webservices omvatten die bijvoorbeeld behoren tot een bepaald domein; bijvoorbeeld alle webservices (GET, PUT, DELETE, …) inzake betalingen.

De output

De output van een verzoek via een webservice wordt o.a. geleverd onder de vorm van een gestandardiseerd object in XML of JSON formaat, doch andere formaten zoals HTML, CSV, … zijn ook mogelijk.

Het object bevat alle zones die in het contract voor de webservice werden voorzien; zoals bijvoorbeeld het adres, huisnummer, gemeente en postcode voor een bepaald persoon.

Als het object een JSON formaat heeft dan lijkt de structuur van de output sterk op een array, {“key1”: “data1”, “key2”: “data2”}. In sommige gevallen kan deze array multi-dimensioneel zijn, of meerdere multi-dimensionele arrays bevatten.

Authenticatie en autorisatie

Het gebruik van en de toegang tot webservices voor het verwerken, zoals het opvragen, het wijzigen, het verwijderen, van (persoons)gegevens is doorgaans beveiligd.

De beveiliging kan betrekking hebben op de scope van de webservices die een gebruiker kan uitvoeren, evenals over welke personen er gegevens kunnen van worden verwerkt.

Deze beveiliging is enorm belangrijk wanneer de gegevens (gevoelige) persoonsgegevens betreft, zoals medische gegevens.

Tokens

De toegang tot het platform waar de webservices zijn gehost, kan gebeuren via tokens.

Authenticatievormen kunnen bijvoorbeeld oAuth tokens zijn, waarbij het token bijvoorbeeld gelinkt is aan een bepaalde persoon of het kan gaan om een applicatie- of een machine gelinkt token.

Bij het eerste type token, namelijk het persoonlijk token, kan het platform zodanig zijn geconfigureerd dat enkel (persoons)gegevens van de betrokken persoon kunnen worden verwerkt.

Dit persoonlijk token wordt meestal pas gegeven na een andere authenticatie, zoals een in te geven gebruikersnaam en wachtwoord combinatie of door multi-factor authenticatie.

Bij een applicatietoken daarentegen kunnen de verwerkbare (persoons)gegevens veel ruimer zijn, en niet louter beperkt tot de gegevens van de ingelogde of opvragende persoon.

Dit laatste type token, een applicatie of een machine token, is minder geschikt voor het opvragen van (gevoelige) persoonsgegevens, tenzij de applicatie zelf de nodige controles zou uitvoeren om de opvraag- en verwerkingsmogelijkheden te beperken.

Geldigheidsduur van het token

Een bijkomende beveiliging is het beperken van de geldigheid van het verleende token; bijvoorbeeld maximaal 60 minuten.

Het beperken van de geldigheidsduur van het token zal de mogelijkheid blokkeren om gegevens op te halen of door te sturen wanneer het token is verlopen.

Dit kan vooral belangrijk zijn bij mobiele applicaties, die doorgaans open blijven staan op de smartphone, hoewel ze niet meer worden gebruikt; wat kan gezegd worden van een mobiele applicatie kan ook worden gezegd van een tabblad dat in een browser open is blijven staan.

Scope

Een bijkomende mogelijkheid om de toegang tot bepaalde webservices te beperken is om de scope van de uitvoerbare webservices te beperken volgens het token dat aan de gebruiker wordt afgeleverd.

Zo kan een organisatie bijvoorbeeld enkel de toegang verlenen tot de webservices die betrekking hebben tot het consulteren van een betaling, maar niet tot degene voor het maken van een betaling.

Query string

Sommige webservices laten de gebruiker toe een query string mee te geven met verschillende parameters.

Het beperken of volledig elimineren van de mogelijkheid van het meegeven van een query string in de URL kan de beveiliging van de webservice verbeteren, voorals wanneer systemen geen validatie doen op de meegegeven of ontvangen gegevens.

Het is immers niet de eerste keer dat verzendende en ontvangende systemen van een query string van een webservice, of een van beide systemen, geen validatie code hebben voor de in de query string meegegeven gegevens.

In het verleden heeft het ontbreken van validatie reeds tot datalekken geleid.

Een bijkomend element inzake beveiliging is dat de URL met de query string o.a. ook gelogd wordt en dus geconsulteerd kan worden door onbevoegden.

Authenticaie en autorisatie systeem

Authenticaties en autorisaties tot de webservices worden doorgaans niet aangemaakt door het platform waar de webservices zijn gehost, maar door een apart systeem, zoals (het oorspronkelijk door Sun Microsystems, bekend van de RISC SPARC servers en workstations, ontwikkelde OpenSSO) OpenAM of zijn afgeleide commerciële varianten.

Monetisatie

Het ter beschikking stellen van webservices kan gemonetiseerd worden.

Meer en meer organisaties zien webservices immers als een melkkoe (cash cow).

Inkomstenmodel

De monetisatie neemt doorgaans de vorm aan van een maandelijks abonnement per volume aan uitvoeringen (calls) voor een bepaalde webservice voor een bepaalde methode (GET, POST, …).

M.a.w. organisaties verkopen aan geïnteresseerden pakketen voor een bepaald volume van calls voor een bepaalde webservice of webservices en voor een bepaalde methode of methoden.

Wanneer dit maandelijks volume door de klant is opgebruikt, dan dient de klant een nieuw pakket te bestellen, indien hij verder gebruik wenst te maken van de gewenste webservices.

M.a.w. het inkomstenmodel is sterk vergelijkbaar met het inkomstenmodel dat door een AI-bedrijf wordt gehanteerd, waarbij een klant een volume aan tokens koopt en dus per token betaalt. Hoe meer tokens er gebruikt worden voor een vraag aan het AI-platform hoe meer dat gebruik voor de klant zal kosten (zie bijvoorbeeld de laatste nieuwsberichten inzake de sterke en buitensporige toename van de AI-gebruikskosten bij sommige grote Amerikaanse bedrijven).

Kostenmodel

Het ter beschikking stellen van een platform voor webservices brengt ook heel wat kosten met zich mee.

Dit omvat, indien men alles zelf wilt gaan doen, de aanschaf van de nodige software licenties en hardware, onder andere voor het authenticatie en autorisatie platform, API gateway, servers, actieve netwerk componenten, etc.

Outsource men alle componenten van het volledige platform voor de webservices, dan zal de organisatie doorgaans te maken hebben met een managed cloud omgeving; waarvoor men betaalt per gebruik.

Conclusie

Er zijn verschillende manieren om het ter beschikking stellen van webservices te beveiligen, zoals tijdsgebonden tokens, de scope van het token beperken, geen of een beperkte query string toelaten, …

Gezien de kosten en de complexiteit die het ter beschikking stellen van webservices met zich meebrengt is het ter beschikking stellen van webservices misschien niet geschikt voor iedere organisatie.

Bloep, 31 mei 2026.