We gaan de witte Stormtroppers vergelijken met een slechte basic authentication inrichting binnen API Management (APIM). Ik ga een aantal belangrijke vragen beantwoorden. Wat is het Stormtrooper effect? Wat is basic authentication? Wat is een slechte inrichting? En uiteraard, wat is een goede inrichting?
Ik ga je dus helpen met het goed inrichten van basic authentication en ik laat je afscheid nemen van de witte Stormtroopers. Het doet je waarschijnlijk pijn want ze zijn natuurlijk niet weg te denken uit de Star Wars films maar niet getreurd, je krijgt de Royal Guard (rode) Stormtroopers er voor terug.
Basic authentication
Voordat we verder gaan met het Stormtrooper effect vertel ik je kort wat basic authentication is. Basic authentication is een minimale authenticatie maatregel wat je moet doen om je kostbare API’s te beveiligen: het is een combinatie van een gebruikersnaam en wachtwoord.
Eenmaal in bezit van deze informatie dan heb je toegang tot de API waar de basic authentication is toegepast. Eenmaal in bezit van een wit Stormtrooper pak…
Heb je mijn vorige twee blog posts gelezen over het gebruik van subscription keys en het toepassen van rate-limit? Nog niet gedaan? Doe dat dan even want het toepassen van basic authentication is de derde security maatregel die je minimaal moet toepassen. Is jou API dan waterdicht na deze drie security maatregelen? Nee. Dat bewijst zelfs de rode Stormtrooper 🙂 .
Slechte basic authentication inrichting
Ik kom bij veel klanten over de vloer die hun API’s beveiligen door witte Stormtroopers… Lees: een slecht inrichting van basic authentication. Het is tijd voor de witte Stormtroopers dus wat is nou het “Stormtrooper effect”?
Daarna laat ik je zien wat een slechte inrichting van basic authentication is binnen APIM.
Onze hilarische witte Stormtroopers
Je kunt je vast een aantal scenes herinneren waarbij de witte Stormtroopers overlopen worden door een klein groepje good guys. Ze schieten voortdurend mis, ze zijn geprogrammeerd om vooral niet na te denken en vallen met bosjes tegelijk om. Ook wel het “Stormtrooper effect” genoemd.
Dezelfde Stormtroopers bewaken de belangrijkste gebouwen van de First Order en zijn daarom eenvoudig om binnen te dringen of te infiltreren. Eenmaal in bezit van een Stormtrooper pak, loop je zo naar binnen en zet je alle security maatregelen uit met alle gevolgen van dien. Eenmaal in bezit van de gebruikersnaam/wachtwoord combinatie (een Stormtrooper pak) en een hacker heeft toegang tot je API’s.
Voorbeeld van een slechte inrichting
Door middel van een extra inbound policy dwingen we minimaal een gebruikersnaam/wachtwoord combinatie af die nodig is voor het gebruik van één of meer API’s. Klinkt aardig zou je zeggen maar is niet waterdicht. Het is wel een stap dichterbij om je API veiliger in te richten.
Hieronder een XML van de inbound policy waarmee je basis authenticatie toepast.
<policies>
<inbound>
<base />
<set-variable name="basic auth" value="witte:stormtrooper" />
<check-header name="Authorization" failed-check-httpcode="401" failed-check-error-message="Not authorized" ignore-case="false">
<value>@("Basic " + System.Convert.ToBase64String(Encoding.UTF8.GetBytes((string)context.Variables["basic auth"])))</value>
</check-header>
<set-backend-service base-url="base URL of the backend service" />
<set-header name="Authorization" exists-action="delete" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>Is regel vier je opgevallen binnen de bovenstaande policy? Ik zie regelmatig dat een gebruikersnaam en wachtwoord gewoon als plain text af te lezen is binnen een policy binnen APIM. Bij elk menselijk wezen met affiniteit voor security schieten de nekharen overeind.
Beste specialisten zorg er alsjeblieft voor dat dit niet meer voorkomt. Herken je deze inrichting binnen je eigen APIM omgeving of ander API gateway? Of zelfs binnen je applicatie code? Stop daar per direct mee en implementeer mijn code uit het volgende gedeelte van de blog post.
Laat je witte Stormtrooper pak niet slingeren!
Basic authentication goed inrichten
Ik ben het met veel security experts eens: basic authentication is niet optimaal maar als je het goed inricht is het best een goede security maatregel. Basic authentication is eenvoudig te implementeren maar we moeten het echt goed inrichten. Op naar de transformatie van de witte Stormtrooper naar de rode Stormtrooper.
Royal Guard Stormtroopers
Wat een verademing zijn de rode Stormtroopers zeg… Ze worden ook niet voor niets toegewezen als security maatregel voor het belangrijkste kopstuk van de First Order: Emperor Palpatine. Een goed voorbeeld van hoe we al onze API’s moeten behandelen.
Voor de Star Wars fans onder ons even een kleine uitstap. De scene uit Star Wars: Episode VIII – The Last Jedi waarin de Royal Guard Stormtroopers in gevecht zijn met Kylo Ren en Ray is fantastisch. Nadat Kylo die engerd doormidden stak was een heerlijk gevecht aanstaande.
Mijn conclusie: ook de rode Stormtroopers zijn niet perfect en dat geldt ook voor basic authentication.
Voorbeeld van een goede inrichting
Eindelijk het belangrijkste gedeelte van de blog… We gaan basic authenticatie goed inrichten met hulp van een Azure Key Vault i.c.m. named values in APIM. De eerste twee stappen beschrijf ik heel beknopt om mijn blog leesbaar te houden en Microsoft documenteert veel beter. Derde stap bevat de code van de APIM policy.
Stap 1 | Azure Key Vault
Binnen de eerste stap is het belangrijk dat je een Azure Key Vault goed inricht: je moet er twee secrets (gebruikersnaam en wachtwoord) kunnen opslaan en je APIM instance moet leesrechten hebben tot de twee secrets op basis van Managed Identities. De Managed Identity van APIM heeft “get” en “list” rechten nodig.
Gebruik voor het beide secrets (ja ik vind een gebruikersnaam ook een secret) een lekker complexe waarde:
api-id: “JeqCB}:yPeE#W&~3+Z%>mB7_ECh“
api-secret: “9cLf.KDgDt~2<9`hb@]#j(dvap,}Lg“
Succes met het hacken van deze wachtwoorden!
Stap 2 | Named Values
Maak twee Named Values aan in APIM en integreer deze met de Azure Key Vault uit stap 1. Eén Named Value voor de gebruikersnaam en één voor het wachtwoord. In de policy.xml hieronder gebruik ik api-id en api-secret.
TIP: koppel een Named Value, waarin een secret opgeslagen wordt, altijd aan een Key Vault value.
Stap 3 | Basic authentication policy
We hergebruiken de policy.xml die eerder in de blog gedeeld werd en daar hoeven we enkel regel 4 aan te passen. Zie hieronder het resultaat waar we refereren naar de twee Named Value’s uit stap 2: {{ api-id }} en {{ api-secret }}. Door middel van de curly brackets kan je dus refereren naar Named Values.
<policies>
<inbound>
<base />
<set-variable name="basic auth" value="{{api-id}}:{{api-secret}}" />
<check-header name="Authorization" failed-check-httpcode="401" failed-check-error-message="Not authorized" ignore-case="false">
<value>@("Basic " + System.Convert.ToBase64String(Encoding.UTF8.GetBytes((string)context.Variables["basic auth"])))</value>
</check-header>
<set-backend-service base-url="base URL of the backend service" />
<set-header name="Authorization" exists-action="delete" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>Zie je hoe makkelijk het is om je basic authentication goed in te richten? Succes!
Transformeer je Stormtrooper
Zorg ervoor dat je API’s minimaal beschermd worden door de Royal Guard Stormtroopers. Pas de drie stappen uit mijn blog toe en je hebt de basic authentication goed ingericht. Zorg er wel voor dat je Key Vault beperkt toegankelijk is dus hanteer a.u.b. het zero trust principe.
Je zult zien dat basic authentication niet zo slecht is als vele experts beweren maar het is niet waterdicht. Zodra een kwaadwillende toegang heeft tot je Key Vault is al het werk voor niks. Dus weer niet optimaal? Nee… Deze conclusie dwingt mij wel om je te helpen met een verbeterde en moderne vorm van authenticatie: Oauth. Maar lieve mensen dat is inspiratie is voor de volgende blog post.
