Beveiliging met Apigee & Okta – In de vorige artikelen hebben we je geïntroduceerd in de wereld van API’s en daarna hebben we je meegenomen op de reis van API ontwikkeling in Talend. Nu je je API hebt ontwikkeld en klaar bent om deze aan de buitenwereld bloot te stellen, komt beveiliging in het spel!
Application Programming Interfaces (API’s) worden gebruikt om te communiceren tussen meerdere applicaties. In sommige gevallen kan de consument ook een externe gebruiker zijn die u toegang wilt geven tot uw gegevens als u de API’s publiekelijk beschikbaar stelt. Bij het ontwikkelen van API’s zijn er een heleboel dingen die je zorgvuldig moet overwegen, een aantal van deze zijn:
- Beveiliging
- Prestatie (responstijd)
- Versiebeheer
- Monetization
In dit artikel zullen we ons richten op het veiligheidsaspect van API ontwikkeling. De platforms met betrekking tot het beveiligingsaspect die in dit artikel worden gebruikt zijn Apigee en Okta. De use case is dat er een wereldwijd klantenportaal is dat API’s gebruikt om de gegevens op te halen die de gebruiker opvraagt. Bijvoorbeeld, de gebruiker logt in en wil het Management Dashboard zien, het Global Customer Portal roept dan een of meer API’s aan om die pagina te vullen met de juiste informatie.
Apigee is een API management platform (gateway), waar men bijvoorbeeld een reverse proxy API kan creëren om alle API activiteiten te overzien binnen één API Management laag. Dit helpt ook om beveiliging in te stellen, bijvoorbeeld op enterprise niveau. Dit dwingt veiligheidsbeleid af dat al uw API’s beveiligt die via Apigee stromen. Men kan ervoor kiezen om een API-sleutel te gebruiken die binnen Apigee wordt gegenereerd, om ervoor te zorgen dat alleen gebruikers die binnen Apigee zijn geregistreerd, de API-eindpunten mogen oproepen. Dit helpt u niet alleen uw API te beveiligen, maar u kunt ook het gebruik van uw API’s bijhouden, wie er gebruik van maakt en hoe vaak. Dit kan bijvoorbeeld nuttig zijn om te bepalen of u een bepaalde versie van uw API kunt depreciëren.
Voor (Customer) Identity and Access Management gebruiken we in dit artikel Okta. Dit stelt ons in staat om gebruikers te registreren, hetzij een klant of (interne) ontwikkelaar en nog veel meer. Door ze te registreren in Okta kunnen we valideren of de gebruiker die inlogt, in dit geval toegang moet hebben tot het Global Customer Portal. Okta wordt ook gebruikt als een Authenticatie Server die het slaan van OAuth2 toegang tokens doet. Met deze functionaliteit biedt het ook een endpoint voor het valideren van dezelfde token tegen uw Okta organisatie.
Het volgende diagram legt de flow uit van de gebruiker naar de AWS Instance waar de API draait. Houd in gedachten dat er meer beveiligingsmaatregelen kunnen zijn die een ontwikkelaar kan overwegen. Merk op dat stap 2 en 4 eigenlijk een 2-staps interactie zijn: elk proces, bijvoorbeeld het aanvragen van een access token en deze ontvangen als de Authentication Server (Okta) de gebruiker heeft geauthenticeerd, en dezelfde gebruiker is geautoriseerd om uw API’s te consumeren. Dit is een nogal simplistische weergave voor complexe beveiligingsmaatregelen, de focus voor dit artikel is de beveiliging en niet de procesflow zelf.
Stap 1: De gebruiker logt in op het klantenportaal met een gebruikersnaam en wachtwoord.
Stap 2: Het Klantenportaal valideert deze inloggegevens en vraagt een OAuth2 toegangstoken aan voor deze gebruiker. Als de credentials correct zijn en de resource die de gebruiker probeert te consumeren is toegestaan voor deze gebruiker, dan genereert Okta een access token dat gebruikt kan worden tijdens de sessie op de Customer Portal. Typisch wordt een access token gegenereerd voor een korte tijd en vervalt in bijvoorbeeld 30 of 60 minuten.
Stap 3 and 4: Op dit moment is het klantenportaal er zeker van dat de gebruiker is geverifieerd en geautoriseerd om toegang te krijgen tot de bron. Dit triggert het klantenportaal om een of meer API’s aan te roepen om de informatie voor deze gebruiker op te halen. In plaats van het API-eindpunt rechtstreeks aan te roepen, gaat het via Apigee. Deze proxy laat ons toe om meer policies af te dwingen, bijvoorbeeld veiligheidsmaatregelen. In onderstaand voorbeeld kunt u de verschillende stappen zien die worden uitgevoerd in Apigee in een volgorde van links naar rechts voordat het verzoek naar de backend wordt gestuurd.
De eerste component is een beleid om het risico te beperken van bijvoorbeeld een DDoS-aanval waarbij uw hele backend kan crashen en gebruikers niet de informatie kunnen krijgen die ze hebben opgevraagd. De volgende in de rij is een beleid dat de verstrekte API Sleutel verifieert. In dit geval wordt de API Key gemunt binnen Apigee en daarom kunnen we verkeer monitoren binnen de dashboards vanuit Apigee. Nadat de controle met succes is geverifieerd, wordt een andere policy geactiveerd die de API Key uit de header verwijdert, zodat de API Key niet in de rest van het verzoek te zien is. Daarna is er een policy die de OAuth2 access token en de Okta credentials valideert in Base64 encryptie met Okta. Het maakt een service callout naar het Okta endpoint voor validatie, op deze manier kun je controleren of het verstrekte access token nog geldig is of niet en of de credentials correct zijn. Merk op dat elke stap moet worden uitgevoerd en de ‘true’ vlag moet teruggeven voordat het volgende component kan worden uitgevoerd. De twee componenten die daarna komen hebben te maken met de Okta validatie policy.
Stap 5: Als alle veiligheidscontroles zijn uitgevoerd en geldig zijn bevonden, wordt het verzoek naar de backend gestuurd om de gevraagde informatie op te halen. Dit deel wordt op twee verschillende manieren beveiligd:
- 2-way TLS
- IP whitelisting
Door 2-way TLS te implementeren zorgen we ervoor dat de backend enkel oproepen aanvaardt van onze Apigee instantie en omgekeerd. Dit is gebaseerd op een sleutel/trust store aan beide zijden die certificaten bevat ondertekend door een CA. Om er zeker van te zijn dat verkeer alleen binnenkomt van vertrouwde IP-adressen kun je uiteindelijk ook bepaalde IP-adressen whitelisten.
Dit artikel bevat slechts enkele veiligheidsmaatregelen die men kan nemen met betrekking tot API ontwikkeling. Er zijn veel meer manieren om uw API te beveiligen en meer in de diepte.
Geïnteresseerd in wat cimt voor uw bedrijf kan betekenen? Voel je vrij om contact met ons op voor meer informatie.
Contact