Een 100% secure integratie-applicatie bestaat niet, maar je kunt risico’s wel mitigeren

Disclaimer: 100% secure bestaat niet!

Voordat we beginnen, een korte disclaimer: 100% secure bestaat niet! Met genoeg tijd, wilskracht en rekenkracht komt een hacker overal doorheen. Betekent dit dat we security dan maar aan de kant kunnen schuiven? Zeker niet! Je wilt niet de persoon zijn die bijvoorbeeld verantwoordelijk is voor een groot datalek, met alle gevolgen van dien. Het is dus belangrijk om zo veel mogelijk security-aspecten in acht te nemen, om de kans op een hack zo klein mogelijk te maken. Vergelijk het met een goed fietsslot: je fiets kan alsnog gestolen worden, maar je koopt tijd om daar iets aan te doen.

Vertrekpunt: de ontwikkeling van een integratie-applicatie

Voordat je begint met het ontwikkelen van een integratie-applicatie moet je de tooling op orde hebben. De eerste vraag die ik mezelf dan ook stel bij de ontwikkeling van een integratie-applicatie: welke ontwikkeltools ga ik gebruiken en komen deze van een trusted provider? Je moet er alert op zijn of je te maken hebt met een betrouwbare applicatie en niet met een onveilige copycat-applicatie. Bedrijven gaan hier op verschillende manieren mee om. Je kunt op organisatieniveau een overzicht met links naar veilige pagina’s aanbieden. Of je kunt op teamniveau bepalen welke vertrouwde tools je gebruikt. Een organisatie kan ook een library maken van installeerbare applicaties. Deze library moet echter wel worden bijgehouden.

Start van de ontwikkeling van een integratie-applicatie

Libraries maken het leven van een developer eenvoudiger. Deze verzameling vooraf geschreven code kun je hergebruiken in programma’s of projecten. Door gebruik te maken van supported software of open source-projecten met een grote en actieve community, kun je al veel risico’s wegnemen. Zo kun je een integratie met Apache Camel bijvoorbeeld baseren op Spring runtime. Bij zo’n groter framework kun je daarop vertrouwen, maar als er op het internet een handige library staat, kun je die niet zomaar binnentrekken. Deze kan insecure code bevatten of zelfs een backdoor voor hackers. Het is fijn als je als developer tijd kunt besparen met een library, maar je mag nooit voorbijgaan aan security risks. Bestudeer de code dan ook goed en gebruik alleen hetgeen dat je echt nodig hebt.

OWASP Dependency-Check

Oké, we hebben nu een aantal libraries en frameworks die we willen gebruiken en de code lijkt er goed uit te zien. Kunnen we nog meer doen om het risico te verkleinen en met grotere zekerheid zeggen dat deze veilig zijn? Hiervoor kunnen we bijvoorbeeld de OWASP Dependency-Check gebruiken. Deze tool gebruiken we bij Virtual Sciences Conclusion om de libraries in onze applicaties te controleren op bekende problemen. Dan krijg je een mooi rapport met high- en low-risk security-uitdagingen. Soms kun je deze simpelweg oplossen door de library te updaten, maar er zijn ook vulnerabilities waarvoor (nog) geen fix is. Dan moet je beoordelen of het risico acceptabel is of dat hier andere handelingen op ondernomen moeten worden.

Extra check met SonarQube

Alles ziet er goed uit, we hebben onze eigen applicatie gemaakt. Maar hoe weten we of wat we zelf geschreven hebben ook veilig is? Hiervoor gebruiken we code-analyse tools. Binnen Virtual Sciences Conclusion gebruiken we hiervoor SonarQube. SonarQube checkt automatisch de code die je in je applicatie geschreven hebt en controleert of deze kwalitatief in orde is. Dit gebeurt op het gebied van code standard, maar ook checkt SonarQube of je zelf geen securityrisico’s geïntroduceerd hebt in je code. Zo kun je eventuele kwetsbaarheden fixen voordat ze een risico vormen.

Security van de integratie-applicatie zelf

Met geautomatiseerde tooling kun je een globale scan maken van de security van je integratie-applicatie. Daarmee kies je voor een zogenaamde brute force approach: de tool gooit van alles op de applicatie af en kijkt wat er blijft plakken. Bij Virtual Sciences Conclusion gebruiken we daar OWASP Zed Attack Proxy (ZAP) voor. Daarmee kunnen we externe end-points, maar ook front-end testen. Geautomatiseerd wordt er gezocht naar veelvoorkomende vulnerabilities waarmee mensen jouw systeem zouden kunnen hacken. De grootste veiligheidsrisico’s kun je hiermee afvangen. Aanvullend is het aan te raden om periodieke security audits te laten uitvoeren door een externe partij. Met automatische tools kom je een heel eind, maar in de praktijk zie je dat als er een persoon naar kijkt er vaak toch nog wel iets is wat automatische tools over het hoofd hebben gezien.

Identiteits- en toegangsbeheer (IAM) van de integratie-applicatie

In het hele developmentproces hebben we continu kritisch gekeken naar de security. Dan is het tot slot belangrijk om te bepalen wie er überhaupt toegang heeft tot de applicatie. Je wilt mensen buiten de deur houden die niets in de integratie-applicatie te zoeken hebben. Veel veiligheidsproblemen spelen namelijk enkel als je echt op de machine kunt komen. De user access kun je op verschillende manieren regelen. Vaststaat dat puur een gebruikersnaam en wachtwoord tegenwoordig niet meer secure genoeg is. Er moet op zijn minst sprake zijn van multi-factor authenticatie (MFA). MFA werkt fantastisch als je met een graphical user interface (GUI) te maken hebt, maar als we het over integraties hebben is dit eigenlijk nooit het geval. Hier gebruiken we vaak Oauth. Dit betekent dat een gebruiker of systeem toegang moet vragen aan het systeem. Hierbij wordt er een sleutel verstrekt die tijdelijk geldig is. Op deze manier zorg je ervoor dat als deze sleutel onderschept wordt, de kwaadwillende maar tijdelijk toegang heeft tot het systeem en de schade beperkt blijft.

Conclusie

100% secure bestaat niet, maar als developer kun je met het juiste bewustzijn en de nodige kennis, tools, checks en balances een integratie-applicatie wél veilig laten draaien.