Een nog veiligere data-uitwisseling!
In het eerste deel van deze blog zijn we uitgebreid ingegaan op de beveiliging van de data-uitwisseling tussen onze API en de CRM/ERP pakketten van klanten. We spraken toen voornamelijk over hoe data versleuteld en beveiligd aangeleverd wordt. Hoe we vervolgens de ontvangen data veilig borgen en beschermen, vertelt Ben je vandaag.
Omdat de veiligheid van jouw data bij ons voorop staat, heeft Ben samen met zijn team extra goed nagedacht over de beveiliging van de database. Op het moment dat wij data ontvangen van klanten is het nog niet versleuteld. Dat wil zeggen dat de data leesbaar is mocht een hacker in de database komen en de informatie openbaar willen maken. We hanteren daarom een 3-laags beveiligingssysteem. Lees je mee?
De wereld van API-, token- en cipher-services
’’We werken met een REST API. De REST API accepteert data van klanten en controleert of het informatie is waar de Planning Suite wat mee kan.’’ We noemen de REST API ook wel onze externe API, omdat het enkel met klanten communiceert. ‘’Na de datacheck wordt alles gestuurd naar de interne API van PTI, die zet alle data in de database.’’ In de praktijk betekent dit dat we alle informatie (de opdrachten/workorders die gepland moeten worden) ontvangen via een externe API, die het na goedkeuring pas doorstuurt naar onze interne API. Dit doen we omdat we er zeker van willen zijn dat de data inhoudelijk correct is. Zo voorkomen we fouten in opdrachten en de Planning Suite.
‘’De interne API heet bij ons de API-service. De API-service scant de gegevens op gevoelige informatie. Alle gevoelige informatie, zoals persoonsgegevens, moet versleuteld worden.’’ Maar hoe zorgt de service er dan voor dat dit versleuteld wordt?
’’De API-service communiceert met een token- en een cipher-service. De API-service haalt eerst de specifieke token op uit de token-service. De data gaat na het ontvangen van een token door naar de cipher-service, waar de data samen met de generieke token onleesbaar wordt gemaakt.’’
Hoe het werkt
Je moet onze beveiliging zien als een bankkluis. Wij zijn de bank en jouw data zit veilig in onze kluis. Om de kluis te openen heb je twee sleutels nodig. Eén van de bank en één van jou. De token-service is jouw sleutel (record specifieke sleutel) en de cipher-service versleuteld de data samen met de sleutel van de bank (generieke sleutel). Wij noemen het alleen geen sleutels maar tokens.
Wanneer jouw data een token heeft gekregen en onleesbaar gemaakt is, stuurt de api-service het weer terug naar de database. Op deze manier is de data voor niemand af te lezen. ‘’Mocht het een hacker lukken om in de database te komen, dan is het volstrekt onleesbaar. Zelfs ik als developer kan niet zien welke namen de klant naar ons toe heeft gestuurd.’’
Een voorbeeld uit de praktijk
Laten we even een situatie schetsen om het makkelijk te maken. Bij één van jouw klanten moeten zonnepanelen geplaatst worden. Zijn naam is Michael Janssen en woont op de Korenmolenlaan 1c in Woerden. Al zijn gegevens en alle opdracht informatie wordt ontvangen in de Planning Suite via de externe API. Uit de datacheck blijkt dat de naam en adres gegevens van Michael gevoelige informatie zijn, dus wordt dit meteen weer doorgestuurd naar onze interne API. De API-service haalt een token (of te wel een sleutel) op van de specifieke record en de cipher-service maakt ieder stukje informatie onleesbaar. Hoe de naam Micheal Janssen er nu in de database uitziet? Ongeveer zo: 8šl5»ý.Ðß”“1£¹„.
Ieder zijn eigen database
Het is gebruikelijk om te werken vanuit één database. Dit is echter een stuk minder hacker-proof. Daarom hebben we besloten om voor iedere klant een eigen database te bouwen. ‘’We hebben een SaaS platform waarbij we meerdere klanten in het zelfde stukje software plaatsen, dus hebben we voor iedere klant een eigen database met daarin de klant specifieke gegevens.’’
De API-service heeft toegang tot de databases van alle klanten door middel van gebruikersnamen en wachtwoorden. Op deze manier kan het de data naar klant A of klant B communiceren. ‘’Zo haalt de API-service voor ieder stukje data van iedere klant unieke tokens op.’’
De data is achter de schermen dus volledig versleuteld. Maar in de Planning Suite willen jouw planners natuurlijk aan de slag en hebben ze niks aan versleutelde data. Daarom werkt de API-service ook andersom. ‘’Wanneer onze klanten met hun data aan de slag willen in de Planning Suite, wordt de API-service getriggered om de data uit de database te halen. Dit is natuurlijk onleesbaar gemaakt door de API-service, maar kan het daardoor ook als enige weer ontsleutelen.’’ Na het weer leesbaar maken van de data, communiceert de API-service het naar de Planning Suite waardoor alle persoons- en opdrachtgegevens zichtbaar zijn voor de klant.
Dare to be different
Naast het feit dat de meeste bedrijven alles in één database bewaren, versleutelen de meeste bedrijven ook hun data direct in de database. Een standaardmethode en zeer gemakkelijk, maar niet zonder gevaren. ‘’Het brengt heel veel risico’s met zich mee als je de standaardmethode gebruikt voor het versleutelen van je data. Op het moment dat een hacker toegang krijgt tot de database, heeft de hacker ook de mogelijkheid om de data te ontsleutelen.’’
Daarom hebben wij gekozen voor het versleutelen door middel van een api-, token- en cipher-service. ‘’Bij veel bedrijven is dit in ontwikkeling, maar het is nog niet overal toegepast. Soms kan er minder prioriteit aan gegeven worden omdat zij de kans kleiner inschatten dat ze daadwerkelijk gehackt worden. Of de data is minder belangrijk, dat kan natuurlijk ook. Wij zijn er echt voor gaan zitten met externe partijen. Er is onder andere een security expert bij gekomen om dit met ons door te lopen en te bedenken.’’
De nieuwe manier van security testing
Er in geloven dat wij jouw data goed beveiligd hebben? Dat doen we zeker. Maar slechts geloven vinden we niet genoeg. We willen het zeker weten. Daarom testen wij iedere maand met ethical hackers of onze databases nog altijd goed beveiligd zijn.
