Azure API Management: Beveiligingspolicies Configureren Voor API-beveiliging

Azure API Management wordt in steeds meer overheidsorganisaties gebruikt als centraal punt voor het beheren, beveiligen en monitoren van API's. Dit platform fungeert als gateway tussen interne en externe systemen, en vormt daarmee een kritieke schakel in moderne dienstverlening en digitale transformatie. Zonder goed geconfigureerde beveiligingspolicies ontstaan echter snel beveiligingsproblemen: API's zijn toegankelijk zonder adequate authenticatiecontroles, waardoor onbevoegden toegang krijgen tot gevoelige gegevens. Inputvalidatie ontbreekt, waardoor injection-aanvallen en malformed payloads de achterliggende systemen kunnen bereiken. Er is geen of onvoldoende encryptie in transit en at rest, waardoor data-in-transit kunnen worden onderschept of gestolen. Cross-origin requests zijn niet adequaat gecontroleerd, wat beveiligingsrisico's met zich meebrengt voor webapplicaties. En er ontbreken logging- en monitoringmechanismen, waardoor incidenten niet tijdig worden gedetecteerd of geanalyseerd. Voor CISO's, auditors en toezichthouders is het dan moeilijk aan te tonen dat passende technische en organisatorische maatregelen zijn getroffen volgens BIO, ISO 27001 en NIS2. Daarnaast worden veel API Management-installaties opgezet als onderdeel van agile projecten, waarbij security-by-design pas later wordt ingevuld. Zonder structurele beveiligingspolicyconfiguratie blijven deze tijdelijke keuzes jarenlang doorwerken in productie.

Implementatie

Dit artikel beschrijft hoe u een samenhangend beveiligingspolicyraamwerk voor Azure API Management opzet dat aansluit op de Nederlandse Baseline voor Veilige Cloud. We behandelen de belangrijkste bouwstenen: encryptiepolicies (TLS-configuratie, certificaatbeheer en versleuteling van gevoelige data), authenticatie- en autorisatiepolicies (OAuth2, JWT-validatie, API-sleutels en geavanceerde autorisatiescenario's), validatie- en sanitatiepolicies (input- en outputvalidatie, schema-validatie en content-transformatie), netwerkbeveiligingspolicies (IP-filtering, CORS-configuratie en geografische beperkingen), en operationele beveiligingspolicies (logging, monitoring, threat detection en foutafhandeling). Daarnaast laten we zien hoe u met het bijbehorende PowerShell-script een feitelijk overzicht maakt van de beveiligingspolicystatus van API Management-services binnen uw abonnementen, zodat verbeteracties prioriteerbaar en herhaalbaar worden aangestuurd. De focus ligt op realistische implementatie in omgevingen met meerdere teams en leveranciers, waarbij compliance-eisen, cloud-schaalbaarheid en ontwikkelsnelheid met elkaar in balans moeten blijven.

Fundamenten van beveiligingspolicies in API Management

Een effectief beveiligingspolicyraamwerk voor Azure API Management begint bij heldere uitgangspunten die aansluiten bij de Nederlandse Baseline voor Veilige Cloud. Voor Nederlandse overheidsorganisaties zijn dat in de kern Zero Trust, defense in depth, least privilege en aantoonbaarheid. Zero Trust betekent dat geen enkel API-verzoek standaard wordt vertrouwd: authenticatie en autorisatie worden afgedwongen op elk verzoek, ongeacht de bron of context. In een API Management-context vertaalt dit zich naar verplichte authenticatie voor alle API's (geen open endpoints zonder authenticatie), geavanceerde autorisatie op basis van claims, rollen en context, en continue validatie van tokens en verzoeken gedurende de volledige levenscyclus van een API-call. Defense in depth houdt in dat meerdere beveiligingslagen worden toegepast: netwerkbeveiliging op gateway-niveau, authenticatie op policy-niveau, validatie op applicatie-niveau, en aanvullende controles in de achterliggende services. Least privilege tenslotte vraagt om strikte autorisatieregels waarbij API-consumenten uitsluitend toegang krijgen tot de endpoints en operaties die nodig zijn voor hun specifieke use case.

Beveiligingspolicies in Azure API Management worden geïmplementeerd via XML-gebaseerde policy-definities die worden toegepast op verschillende scopes: globaal (voor alle API's), product-niveau (voor alle API's binnen een specifiek product), API-niveau (voor een specifieke API), en operatie-niveau (voor een specifieke operatie binnen een API). Deze hiërarchische structuur maakt het mogelijk om algemene beveiligingsregels centraal te definiëren en waar nodig te verfijnen op lager niveau. Belangrijke policycategorieën voor beveiliging omvatten authenticatie- en autorisatiepolicies (validate-jwt, check-header, authorize), encryptiepolicies (set-header voor security headers, transform XML/JSON voor data masking), validatiepolicies (validate-content, check-header, check-query-parameter), netwerkbeveiligingspolicies (ip-filter, cors), en operationele policies (log-to-eventhub, send-request voor externe validatie). De volgorde waarin policies worden uitgevoerd is cruciaal: authenticatie moet altijd voorafgaan aan autorisatie, validatie moet plaatsvinden voordat data wordt doorgestuurd naar achterliggende services, en logging moet gebeuren zonder dat de performance of beveiliging wordt aangetast.

De gekozen principes en architectuur moeten expliciet worden vertaald naar concrete policyconfiguraties. Denk aan eisen als: alle productie-API's vereisen TLS 1.2 of hoger met perfect forward secrecy; alle API-verzoeken worden gevalideerd op basis van geldige JWT-tokens uitgegeven door vertrouwde identity providers; input wordt gevalideerd tegen schema's om injection-aanvallen en malformed payloads te voorkomen; gevoelige gegevens worden gemaskeerd in logs en responsen; CORS-configuraties zijn restrictief en toegestane origins zijn expliciet gedefinieerd; en alle API-verzoeken worden gelogd met minimaal timestamp, client-identificatie, endpoint, HTTP-methode en responsestatus. Deze policies moeten niet alleen worden beschreven, maar ook technisch worden afgedwongen via API Management policy-configuraties en gecontroleerd via geautomatiseerde checks en periodieke audits. Belangrijk is om vanaf het begin een balans te vinden tussen strengheid en gebruiksvriendelijkheid: te restrictieve policies die structureel worden omzeild of genegeerd, ondermijnen zowel de beveiliging als de governance. Daarom is het raadzaam om per policycategorie een groeipad te definiëren, waarbij u start met minimaal aanvaardbare maatregelen en in de tijd naar een hogere volwassenheid toewerkt. Het bij dit artikel geleverde PowerShell-script helpt om deze groei meetbaar te maken door periodiek de feitelijke beveiligingspolicystatus van API Management-services inzichtelijk te maken.

Encryptie- en transportbeveiligingspolicies

Gebruik PowerShell-script security-policies.ps1 (functie Invoke-Monitoring) – Voert een beveiligingspolicycontrole uit op API Management-services binnen de opgegeven scope en rapporteert over kernaspecten zoals TLS-configuratie, certificaatbeheer en encryptie-instellingen..

Encryptie vormt de basis voor vertrouwelijke gegevensbescherming in API Management. Alle API-verkeer moet worden versleuteld in transit via Transport Layer Security (TLS), waarbij minimaal TLS 1.2 wordt vereist en TLS 1.3 wordt aanbevolen voor nieuwe implementaties. Azure API Management ondersteunt TLS-versies via configuratie op service-niveau en via policies die kunnen worden gebruikt om specifieke TLS-eisen af te dwingen. Belangrijk is dat weak cipher suites worden uitgeschakeld en dat perfect forward secrecy wordt afgedwongen om ervoor te zorgen dat gestolen private keys niet kunnen worden gebruikt om eerdere sessies te ontsleutelen. Certificaatbeheer is kritiek: alle certificaten moeten worden beheerd via Azure Key Vault of een ander centraal certificaatbeheersysteem, certificaten moeten worden gemonitord op verloopdatum en automatisch worden vernieuwd, en self-signed certificaten moeten volledig worden vermeden in productie-omgevingen behalve voor specifieke testscenario's.

Naast transport-encryptie is het belangrijk om gevoelige gegevens ook te beschermen wanneer deze worden gelogd of doorgestuurd naar monitoring- en analyticsystemen. Data masking policies kunnen worden gebruikt om creditcardnummers, social security numbers, wachtwoorden en andere gevoelige informatie te verbergen in logs en responsen. Deze policies werken op basis van reguliere expressies die patronen identificeren en vervangen door gemaskerde waarden (bijvoorbeeld creditcardnummers worden vervangen door XXXX-XXXX-XXXX-1234). Het is cruciaal dat masking consistent wordt toegepast: niet alleen in response bodies, maar ook in logs, error messages en debugging output. Verder moeten API Management-services worden geconfigureerd om security headers te verzenden die browsers en clients instrueren over beveiligingsgedrag: Strict-Transport-Security (HSTS) om HTTPS af te dwingen, X-Content-Type-Options om MIME-sniffing te voorkomen, X-Frame-Options om clickjacking-aanvallen te voorkomen, en Content-Security-Policy om cross-site scripting (XSS) te beperken.

Voor API's die werken met persoonsgegevens in het kader van de AVG is aanvullende encryptie vereist. Gevoelige persoonsgegevens moeten worden versleuteld at rest in achterliggende databases en storage accounts, en encryptie keys moeten worden beheerd via Azure Key Vault met role-based access control. In sommige gevallen kan end-to-end encryptie nodig zijn, waarbij gegevens worden versleuteld op de client en pas worden ontsleuteld in de eindbestemming, zonder dat de API Management-service toegang heeft tot de onversleutelde data. Dit vereist specifieke policyconfiguraties die encryptie en decryptie afhandelen zonder dat gevoelige informatie wordt blootgesteld aan de gateway zelf.

Authenticatie- en autorisatiepolicies voor API-beveiliging

Authenticatie- en autorisatiepolicies vormen de eerste en belangrijkste verdedigingslinie voor API's in Azure API Management. Alle productie-API's moeten zijn geconfigureerd met robuuste authenticatiemechanismen die aansluiten bij de organisatie-identiteitsarchitectuur. De meest voorkomende en aanbevolen aanpak voor Nederlandse overheidsorganisaties is integratie met Microsoft Entra ID via OAuth2 of OpenID Connect. Dit biedt naadloze integratie met bestaande identiteitsinfrastructuur, ondersteuning voor meervoudige authenticatie en voorwaardelijke toegang, en centrale beheerbaarheid van gebruikers en rollen. API Management ondersteunt JWT-tokenvalidatie via de validate-jwt policy, die controleert op token-signatuur, expiratie, issuer, audience en specifieke claims. Deze validatie moet worden toegepast op alle API-verzoeken waarbij authenticatie vereist is, en moet plaatsvinden voordat andere policies worden uitgevoerd om te voorkomen dat ongeldige tokens worden verwerkt door downstream policies.

Autorisatie in API Management kan op verschillende niveaus worden geconfigureerd: op gateway-niveau via policies die controleren of een gebruiker of service toegang heeft tot een specifieke API, op operatie-niveau waarbij toegang wordt gecontroleerd per HTTP-methode en endpoint, en op gegevensniveau waarbij policies kunnen controleren of een gebruiker toegang heeft tot specifieke resources op basis van claims in JWT-tokens. Voor Nederlandse overheidsorganisaties is het gebruikelijk om autorisatie te baseren op rollen en groepen in Microsoft Entra ID, waarbij API Management policies JWT-tokens valideren en claims extraheren om toegangsbeslissingen te nemen. Dit sluit aan bij de Zero Trust-principes en maakt het mogelijk om toegang centraal te beheren via Entra ID zonder dat elke API afzonderlijk autorisatielogica hoeft te implementeren. Geavanceerde autorisatiescenario's kunnen context-afhankelijke beslissingen omvatten: bijvoorbeeld toegang tot gevoelige gegevens alleen tijdens kantooruren, of alleen vanaf geautoriseerde IP-adressen of netwerksegmenten.

Naast OAuth2 en OpenID Connect ondersteunt API Management ook andere authenticatiemechanismen zoals API-sleutels, basic authenticatie en certificaat-gebaseerde authenticatie. Voor productie-omgevingen worden API-sleutels doorgaans alleen aanbevolen voor service-to-service communicatie binnen vertrouwde netwerken, omdat sleutels relatief eenvoudig kunnen worden gestolen of gelekt. Basic authenticatie moet volledig worden vermeden tenzij er sprake is van legacy-integraties die niet anders kunnen worden opgelost, en zelfs dan moet worden overwogen om basic authenticatie alleen toe te staan via private endpoints met aanvullende netwerkbeveiliging. Certificaat-gebaseerde authenticatie biedt sterke beveiliging voor service-to-service scenario's en is bij uitstek geschikt voor kritieke integraties waarbij hoge beveiligingsniveaus vereist zijn. Belangrijk is dat alle authenticatiemechanismen worden gemonitord en gelogd, zodat misbruik, brute-force-aanvallen of anomalieën tijdig kunnen worden gedetecteerd.

Inputvalidatie- en sanitatiepolicies

Inputvalidatie en sanitatie zijn fundamentele beveiligingsmaatregelen om te voorkomen dat kwaadaardige of malformed payloads de achterliggende systemen bereiken. Azure API Management biedt verschillende policies voor validatie: validate-content policies die controleren of request- of response-bodies voldoen aan gespecificeerde schema's (bijvoorbeeld JSON Schema of XML Schema), check-header policies die controleren op aanwezigheid en waarde van specifieke HTTP-headers, en check-query-parameter policies die query-parameters valideren. Validatie moet worden toegepast op zowel inkomende verzoeken (om injection-aanvallen en malformed data te voorkomen) als uitgaande responsen (om te voorkomen dat gevoelige gegevens per ongeluk worden gelekt via response-bodies). Voor API's die werken met gestructureerde data zoals JSON of XML is schema-validatie essentieel om ervoor te zorgen dat alle verzoeken en responsen voldoen aan de verwachte structuur en datatype-eisen.

Sanitatie gaat een stap verder dan validatie: niet alleen wordt gecontroleerd of input voldoet aan de verwachte structuur, maar ook worden potentiële gevaarlijke patronen verwijderd of onschadelijk gemaakt. Dit is vooral belangrijk voor API's die user-generated content accepteren of die data doorsturen naar andere systemen. Common injection-aanvallen die moeten worden voorkomen omvatten SQL injection (waarbij SQL-code wordt ingesloten in input parameters), NoSQL injection (voor document databases zoals MongoDB), command injection (waarbij operating system commands worden uitgevoerd), LDAP injection (voor directory services), en XML/XXE injection (voor XML-parsers). API Management policies kunnen worden gebruikt om dergelijke patronen te detecteren en te blokkeren voordat ze de achterliggende services bereiken. Belangrijk is dat validatie- en sanitatiepolicies worden gebaseerd op whitelisting (alleen toegestane patronen) in plaats van blacklisting (blokkeren van bekende gevaarlijke patronen), omdat blacklists altijd incompleet zijn en nieuwe aanvalstechnieken kunnen omzeilen.

Error handling bij validatiefouten is een belangrijk aspect van beveiliging. Foutmeldingen moeten voldoende informatie bevatten voor troubleshooting door beheerders, maar mogen niet te veel details lekken die kunnen worden misbruikt door aanvallers. Bijvoorbeeld: in plaats van een foutmelding te geven zoals 'SQL syntax error near line 5', moet een generieke foutmelding worden gegeven zoals 'Invalid input parameters'. Dit voorkomt dat aanvallers informatie krijgen over de onderliggende databasestructuur of andere implementatiedetails. Validatiefouten moeten ook worden gelogd voor security monitoring, zodat patroonherkenning kan worden toegepast om herhaalde pogingen tot injection-aanvallen te detecteren en te blokkeren.

Netwerkbeveiliging en CORS-configuratie

Netwerkbeveiligingspolicies bieden een aanvullende beveiligingslaag door toegang te beperken op basis van netwerklocatie en geografische locatie. IP-filtering in API Management maakt het mogelijk om toegang te beperken tot specifieke IP-adressen of IP-bereiken via whitelisting (alleen toegang vanaf opgegeven IP-adressen) of blacklisting (blokkeren van specifieke IP-adressen). Dit is vooral waardevol voor interne API's die alleen toegankelijk moeten zijn vanuit geautoriseerde netwerken, zoals het interne bedrijfsnetwerk of specifieke cloudomgevingen. Voor productie-omgevingen wordt whitelisting aanbevolen voor interne API's, waarbij alleen geautoriseerde IP-bereiken worden toegestaan. Publieke API's gebruiken doorgaans blacklisting om bekende kwaadaardige IP-adressen te blokkeren, in combinatie met andere beveiligingsmaatregelen zoals rate limiting en monitoring. Het is belangrijk om te beseffen dat IP-filtering alleen effectief is wanneer de API Management-service zelf niet rechtstreeks via het openbare internet wordt bereikt, maar via een firewall of andere netwerkbeveiligingscomponenten die de werkelijke client-IP kunnen detecteren. Bij gebruik van Azure Application Gateway of Azure Front Door als reverse proxy moet de X-Forwarded-For header worden gebruikt om de werkelijke client-IP te bepalen.

CORS (Cross-Origin Resource Sharing) configuratie is cruciaal voor webapplicaties die API's aanroepen vanuit een browser. Zonder correcte CORS-configuratie kunnen browsers API-aanroepen blokkeren vanwege same-origin policy-beperkingen, maar te permissieve CORS-configuraties kunnen ernstige beveiligingsrisico's met zich meebrengen zoals cross-site request forgery (CSRF) aanvallen. API Management policies moeten CORS-headers expliciet configureren met restrictieve instellingen: alleen specifieke origins moeten worden toegestaan (niet wildcard '*' tenzij absoluut noodzakelijk), alleen benodigde HTTP-methoden moeten worden geautoriseerd, en alleen vereiste headers moeten worden toegestaan. Voor productie-omgevingen moet CORS-configuratie worden afgestemd op de werkelijke client-applicaties die de API gebruiken, en moet regelmatig worden gecontroleerd of alle toegestane origins nog steeds legitiem en noodzakelijk zijn. Preflight-verzoeken (OPTIONS-verzoeken) moeten snel en efficiënt worden afgehandeld zonder onnodige validatie of downstream calls, om de performance niet te beïnvloeden.

Geografische filtering kan worden gebruikt om API-toegang te beperken tot specifieke landen of regio's, wat vooral relevant is voor compliance-vereisten zoals data residency. Azure API Management biedt geen ingebouwde geografische filtering, maar dit kan worden geïmplementeerd via externe services zoals Azure Front Door met geografische filtering of via custom policies die IP-adressen koppelen aan geografische locaties via geolocation databases. Voor Nederlandse overheidsorganisaties kan dit relevant zijn om ervoor te zorgen dat API's alleen toegankelijk zijn vanuit Nederland of de Europese Unie, in overeenstemming met data residency-vereisten en NIS2-richtlijnen.

Monitoring, logging en compliance voor beveiligingspolicies

Gebruik PowerShell-script security-policies.ps1 (functie Invoke-Remediation) – Genereert een overzicht van API Management-services die niet aan beveiligingspolicycriteria voldoen en geeft tekstuele aanbevelingen voor vervolgstappen en governance..

Uitgebreide logging en monitoring zijn essentieel voor operationele beveiliging en compliance. Azure API Management biedt verschillende logging-mogelijkheden: diagnostic logs die informatie vastleggen over alle API-verzoeken inclusief timestamps, client-identificatie, endpoints, HTTP-methoden, response-codes en latency, application insights-integratie voor gedetailleerde analytics en custom telemetry, en event hub-integratie voor real-time event processing en integratie met SIEM-systemen. Voor Nederlandse overheidsorganisaties is het gebruikelijk om alle API-verzoeken te loggen met minimaal de volgende informatie: timestamp van het verzoek, client-IP-adres of client-identificatie, geauthenticeerde gebruiker of service principal, aangeroepen endpoint en HTTP-methode, request- en response-headers (met uitzondering van gevoelige headers zoals authorization), response-statuscode en -latency, en eventuele foutmeldingen of uitzonderingen. Deze logs moeten centraal worden opgeslagen met een bewaarperiode die voldoet aan compliance-vereisten (bijvoorbeeld 7 jaar voor audit-doeleinden volgens BIO-normen).

Security monitoring moet verder gaan dan alleen logging: actieve detectie van verdacht gedrag, anomalieën en potentiële aanvallen is essentieel. Azure API Management kan worden geïntegreerd met Azure Sentinel of andere SIEM-systemen voor threat detection en incident response. Belangrijke security events die moeten worden gemonitord omvatten: herhaalde authenticatiefouten (mogelijke brute-force-aanvallen), ongebruikelijke toegangspatronen (bijvoorbeeld toegang buiten kantooruren of vanaf onbekende locaties), grote aantallen verzoeken binnen korte tijd (mogelijke denial-of-service-aanvallen), verzoeken die validatiefouten veroorzaken (mogelijke injection-aanvallen), en verzoeken die worden geblokkeerd door security policies (mogelijke exploitatiepogingen). Automatische alerts moeten worden geconfigureerd voor kritieke security events, met escalatieprocedures voor high-severity incidents.

Vanuit complianceperspectief sluiten API Management beveiligingspolicyconfiguraties direct aan op eisen uit de BIO, ISO 27001 en NIS2. Deze kaders vragen onder meer om adequate toegangscontrole op basis van behoefte, logging en monitoring van kritieke systemen, bescherming tegen denial-of-service-aanvallen, encryptie van gevoelige gegevens, en aantoonbaar beheer van API-beveiliging. In auditdossiers wordt niet alleen gekeken naar beleidsdocumenten, maar ook naar concrete bewijsstukken uit de technische inrichting: beveiligingspolicyconfiguratieoverzichten, rapportages uit monitoring- en beveiligingstools, en beschrijvingen van incidentafhandeling en verbeteracties. Door de output van het beveiligingspolicyscript op te nemen in periodieke rapportages aan CISO-organisatie en lijnmanagement, en deze te koppelen aan een portfolio van verbetermaatregelen, ontstaat een sluitende audittrail. Zo kan worden aangetoond welke API's wanneer zijn beveiligd, welke resterende risico's nog worden geaccepteerd en welke afspraken zijn gemaakt over vervolgstappen. Een goed ingerichte governance-structuur maakt van API Management beveiligingspolicyconfiguratie een vast onderdeel van bredere cloud security- en risicobeheersing. Richt bijvoorbeeld een API security governance board in waarin periodiek de belangrijkste bevindingen uit security scans, penetration tests en incidentanalyses worden besproken. Betrek daarbij vertegenwoordigers van API-ontwikkelteams, platformteams, security, architectuur en lijnmanagement. Maak gebruik van policy-templates en standaardconfiguraties die automatisch worden toegepast op nieuwe API's, en zorg dat afwijkingen van standaardpolicies expliciet moeten worden goedgekeurd en gedocumenteerd. Door API Management beveiligingspolicyconfiguratie op deze manier te positioneren als structureel onderdeel van de Nederlandse Baseline voor Veilige Cloud, ontstaat een duurzaam evenwicht tussen innovatie en beveiliging: teams kunnen nieuwe API's ontwikkelen binnen duidelijke kaders, terwijl bestuurders en toezichthouders vertrouwen kunnen ontlenen aan aantoonbare, meetbare beveiligingsmaatregelen.

Compliance & Frameworks

• CIS M365: Control CIS Microsoft Azure Foundations Benchmark (L1/L2) - Aanbevelingen voor het beveiligen van Azure API Management, waaronder authenticatie, encryptie, logging en monitoring.
• BIO: 09.01, 12.02, 13.01, 14.01, 15.01 - Eisen uit de Baseline Informatiebeveiliging Overheid rond toegangsbeheersing, logging, monitoring, encryptie en bescherming tegen aanvallen voor kritieke API's.
• ISO 27001:2022: A.5.15, A.8.16, A.9.04, A.14.01, A.17.01 - Beheer van API-beveiliging in de cloud, inclusief authenticatie, autorisatie, logging, monitoring en encryptie van kritieke API-endpoints.
• NIS2: Artikel - Verplichting tot het treffen van passende technische en organisatorische maatregelen om risico's voor netwerk- en informatiesystemen te beperken, waaronder beveiligde API-configuraties, encryptie en monitoring van essentiële diensten.

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

Risico zonder implementatie

Management Samenvatting

Ontwikkel en implementeer een organisatiebreed beveiligingspolicyraamwerk voor Azure API Management dat authenticatie- en autorisatie, encryptie, inputvalidatie, netwerkbeveiliging en monitoring integraal adresseert. Gebruik het bijbehorende PowerShell-script om de feitelijke beveiligingspolicystatus van API Management-services periodiek te meten, verbeteracties te prioriteren en de voortgang aantoonbaar te maken in rapportages aan bestuurders, CISO en auditors. Zo wordt API Management een volwaardig en veilig platform binnen de Nederlandse Baseline voor Veilige Cloud.

• Implementatietijd: 130 uur
• FTE required: 0.5 FTE