Ben jij al bewust van de “built-in all access subscription“? Nee? Om je API Management omgeving veiliger te maken moet je echt actie ondernemen. Ik heb namelijk een bug ervaren die ik niet kan reproduceren waardoor iedereen met leesrechten de “built-in all access subscription” kon inzien…
Veel bedrijven zijn zich niet bewust van de “built-in all access subscription“. Als je in bezit bent van deze subscription key kan je elke API inzien en consumeren binnen de API Management Service in de Azure Portal.
One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the darkness bind them.
De zeer bekende transcriptie uit de Lord of the rings verwoord het prachtig. Eenmaal de subscription key in handen kan je alle API’s zien, alle API’s consumeren en veel schade aanrichten.
Wat is “built-in all access subscription“?
Zoals vele van ons weten, bevat de API Management Service abonnementen die één of meer API’s bevatten. Door je te abonneren op een abonnement krijg je een tweetal sleutels tot je beschikking: een primary en secondary key.
Als er geen extra security maatregel is toegepast in de vorm van policy’s op een betreffende API kan je, door middel van de twee sleutels, de API inzien en consumeren.
Tijdens de uitrol van een API Management Service wordt er ook een abonnement aangemaakt die van toepassing is op alle API’s. Microsoft noemt het de built-in all access subscription.
Als jij of een kwaadwillende in bezit is van de subscription key kan je alle API’s aanroepen en dat is een groot beveiligingsrisico. Althans alle API’s die niet voorzien zijn van extra security maatregelen zoals extra authenticatie of andere (IP) restrictions.
De drie beste maatregelen
De onderstaande maatregelen zijn genummerd op basis van de meest veilige en effectieve manier.
1. Snel de subscription opschorten/deactiveren
Wil jij je API Management inrichting zo veilig als mogelijk maken? Deactiveer het abonnement! Zoek het abonnement op en kies voor “suspend subscription” zoals hieronder weergegeven. That’s it!
Het is dan niet meer mogelijk om de subscription key te gebruiken. Er zit hier wel een side effect aan… De “built-in all access subscription” key is in het leven geroepen voor beheerders. Met de juiste Role Based Access Control (RBAC ) rechten kan je vanuit de Azure Portal alle API’s eenvoudig testen.
Hieronder een voorbeeld voor de mogelijkheid om een API te testen vanuit de Azure Portal. Het kruimelpad is API Management Service -> API -> Specific operation -> Test.
2. Alleen administrators toegang geven tot API Management Service
Als beheerders toch gebruik willen maken van de “built-in all access subscription” mogelijkheid dan moet RBAC zorgvuldig toegepast worden.
Zorg allereerst voor een Azure Active Directory (AAD) groep waarin alle beheerders lid van zijn. We willen namelijk niet op basis van losse identiteiten rechten toekennen binnen het RBAC model.
Eenmaal de groep van beheerders bekend dat moeten we de groep API Management Service Contributor rechten toekennen op de Resource Group van de betreffende API Management Service resource binnen de Azure Portal.
3. Genereer wekelijks of nog beter dagelijks de sleutel
Het is mogelijk om de key opnieuw te genereren waardoor de key wijzigt. Met hulp van bijvoorbeeld CLI commando’s kan je geautomatiseerd de key genereren waardoor de key frequent gewijzigd kan worden.
Als de key dan toch in verkeerde handen valt, is de impact maar een dag of een week groot. Deze actie heeft helaas ook mijn bug opgelost waardoor ik hem niet kan troubleshooten 🙁 .
Kies zorgvuldig
En nu? Wat is het advies? Je kan als het goed is nu een zorgvuldige keuze maken! Zonder enige kennis van mogelijke use-cases en specifieke behoeften is het advies: ontmantel alsjeblieft en zo snel mogelijk de “built-in all access subscription” key. Je weet dan zeker dat de key niet misbruikt kan worden.
Heb je de built-in access subscription toch nodig? Is het verlangen naar macht te groot? Pas in ieder geval RBAC toe en/of genereer de key zo frequent als mogelijk.
Wil je hulp? Bekijk dan vooral de homepage van de API Magician.
3 Comments