Deze blog behandelt een integratieonderwerp vanuit het perspectief van een projectmanager: beveiliging en toegang op applicatieniveau. Ben jij de beheerder van integratieprojecten? Ooit verstrikt geraakt in technisch jargon dat slechts een handvol specialisten begrijpt? Diende je tickets in bij verschillende leveranciers, die uiteindelijk gewoon weer bij jou terugkwamen? Dan kan deze blog je helpen.
In deze blog lees je meer over beveiliging en toegang op applicatieniveau. Een beter begrip helpt je om het overzicht te behouden, nodig om een complex probleem naar een oplossing te leiden. Begrippen worden hier mogelijk vereenvoudigd. Praktische uitdagingen worden besproken. Wie verder wil verdiepen, vindt online veel aanvullende informatie.
Beveiliging en authenticatie op applicatieniveau
In een eerdere blog werd fysieke connectiviteit besproken, met name: versleutelde site-to-site VPN (op ‘transportniveau’). Daarbij werd vermeld dat end-to-end authenticatie daarbovenop nodig is, dus op applicatieniveau. Ook werd mutual TLS genoemd, als alternatief voor de meer permanente site-to-site VPN. Mutual TLS biedt zowel end-to-end authenticatie voor toegang als versleuteling.
Beveiliging
Integraties en API’s bevatten vaak gevoelige informatie, dan moet data tijdens transport worden beveiligd. Hier komt encryptie om de hoek kijken. Het standaard encryptieprotocol is TLS, historisch ook bekend als SSL/TLS. TLS creëert een versleuteld communicatiekanaal op basis van certificaten. Op applicatieniveau zorgt TLS voor end-to-end encryptie, ongeacht de onderliggende fysieke verbinding (veilig of niet). Dubbele encryptie, zowel op transport- als applicatieniveau, is niet ongebruikelijk. En het spreekt voor zich: dubbele encryptie is lastiger te kraken. De verantwoordelijke security officer bepaalt welke beveiligingsmaatregelen nodig zijn voor de betreffende applicatie.
TLS-encryptie wordt ook toegepast bij HTTPS, als uitbreiding op het HTTP-protocol.
Authenticatie
Authenticatie is cruciaal bij integraties en API’s. Allereerst moet de applicatie die data aanbiedt worden geauthentiseerd, zodat de aanroepende applicatie geen onbedoelde of zelfs kwaadaardige data ontvangt. Daarnaast moet ook de aanroepende applicatie mogelijk worden geauthentiseerd, om te voorkomen dat gegevens op de verkeerde plek terechtkomen.
Toegang
Authenticatie voor toegang kan op verschillende manieren worden ingericht.
- Basic Authentication is de eenvoudigste techniek om toegang te krijgen tot webresources. Hierbij worden een gebruikersnaam en wachtwoord meegegeven in een HTTP-verzoek. De gegevens worden Base64-gecodeerd, wat niet voldoende vertrouwelijkheid biedt zoals encryptie of hashing dat wel doen. Daarom wordt Basic Authentication doorgaans alleen gebruikt in combinatie met HTTPS.
Let op: veel security officers staan Basic Authentication met HTTPS niet toe bij gevoelige integraties. - Een tweede methode is authenticatie via TLS-certificaten, gebruikt in combinatie met eenzijdige TLS (alleen serverauthenticatie) of mutual TLS (zowel client- als serverauthenticatie, doorgaans tussen twee bekende partijen).
Let op: eenzijdige TLS wordt meestal toegepast wanneer een client (bijv. een laptop) verbinding maakt met een webserver (website), onderdeel van het HTTPS-protocol, om de client ervan te verzekeren dat de website legitiem is. - De klassieke manier om een aanroepende applicatie te authentiseren is via gebruikersgegevens. Dit is op zichzelf een kwetsbare methode, maar de kwetsbaarheid kan worden verminderd met een tokenmechanisme. Tokens worden in deze blog niet verder behandeld, dat gebeurt in een volgende blog (over autorisatie, OIDC, OAUTH, JWT).
Uiteindelijk ontvangt de aanroepende applicatie een kortdurende toegangstoken, na validatie op basis van de aangeboden Client ID en Client Secret.
Autorisatie
Authenticatie hangt nauw samen met autorisatie. API’s kunnen verschillende rechten toekennen aan verschillende applicaties, zodra die correct geauthentiseerd zijn. Autorisatie is een onderwerp op zich.
Praktijk voorbeelden
Welke situaties kunnen zich in de praktijk voordoen?
- Organisatorisch
Bij het implementeren van TLS moet je duidelijk vastleggen wie waarvoor verantwoordelijk is:
– Wie is de data-eigenaar en moet het certificaat (CRT) aanvragen bij de Certificate Authority (CA)?
– Wie levert input voor de aanvraag van het certificaat (CSR)?
– Wie installeert het (vernieuwde) certificaat?
– Welke afstemming is nodig tussen beide partijen?
Als één partij niet tijdig handelt, faalt de communicatie. - Ontwerp
De architect en security officer bepalen samen de authenticatiemethode: via Basic Authentication, TLS, token of (API-)sleutels. Zorg ervoor dat beide kanten compatibele TLS-versies gebruiken: minimaal TLS 1.2, liefst TLS 1.3.
Oudere applicaties ondersteunen soms alleen TLS 1.0 of 1.1, terwijl nieuwere systemen minimaal TLS 1.2 vereisen.
Laat het ontwerp altijd vooraf controleren door de security officer. - Realisatie
Houd rekening met een doorlooptijd van enkele weken, door afhankelijkheden tussen taken en mogelijke issues.
Tijdens de implementatie van VPN kan tijdelijk toegang tot testomgevingen nodig zijn, zodat de integratieontwikkeling niet stilvalt.
Overweeg dan een tijdelijke oplossing via het internet, bijvoorbeeld met toegangsgegevens en IP-whitelisting. - Beheer
Wijs duidelijk aan wie verantwoordelijk is voor het bewaken van de verloopdatum van TLS-certificaten en het tijdig vernieuwen ervan.
De supportteams van beide partijen moeten weten hoe ze in zulke gevallen moeten handelen. - Uitdagingen
Specialisten voeren hun taken vaak goed uit, maar missen soms overzicht. Documenteer daarom werkwijzen om afhankelijkheid van individuen te voorkomen.
Certificaten brengen beheerkosten met zich mee. Tokens zijn een goed alternatief vanwege automatische vernieuwing.
Samenvatting
Beveiliging op applicatieniveau en goede authenticatie zijn cruciaal voor succesvolle integraties. De technologie is bekend, maar de praktijk kent valkuilen.
Deze blog biedt een overzicht dat je helpt om die valkuilen te herkennen en aan te pakken. In toekomstige blogs gaan we dieper in op gerelateerde onderwerpen.
Call to Action
Wil je dieper in de materie duiken rond beveiliging op applicatieniveau, token-gebaseerde authenticatie of autorisatiemodellen zoals OAuth en OIDC?
Neem contact op met een van onze integratiespecialisten via: Yenlo, om jouw integratievraagstukken te bespreken.
