SharePoint Online: App Management Ontwerpen Met Governance En Security Vetting

SharePoint Online biedt meerdere uitbreidingsmodellen: moderne webparts, command sets, application customizers, Viva-extensies en volledige applicaties die via SPFx of provider-hosted code draaien. Zonder centraal app-management kunnen eindgebruikers rechtstreeks vanuit de Microsoft Store of externe websites apps installeren die nooit op beveiligingscriteria zijn getoetst. Zulke installaties vragen vaak ruime rechten zoals Sites.Read.All of User.ReadWrite.All, waardoor een kwaadwillende app bij een succesvolle compromis direct toegang krijgt tot alle team- en projectsites. Daarnaast herkennen beheerders wijzigingen niet tijdig, omdat geen register bestaat van wie welke app heeft geïnstalleerd. Derde partijen brengen aanvullende risico's mee. Veel aanbieders verzamelen telemetrie of logdata buiten de EU zonder dat verwerkersovereenkomsten zijn gesloten, waardoor persoonsgegevens ongecontroleerd kunnen worden verstuurd. Vendor lock-in ontstaat wanneer afdelingen licenties rechtstreeks afnemen zonder contractuele borging, waardoor kosten uit de hand lopen en het lastig wordt om apps tijdig te patchen. Bij custom ontwikkelde SPFx-oplossingen is het risico dat broncode niet is gescand op OWASP-top-10 kwetsbaarheden of dat secrets hardcoded worden meegeleverd. Ook vanuit compliance is ongecontroleerde app-installatie problematisch. BIO 12.06 eist dat software-installaties alleen plaatsvinden na autorisatie; zonder appcatalogus is daar geen audittrail van. ISO 27001 A.14.2.1 en A.14.2.5 vragen om veilige ontwikkelpraktijken en beschermde test- en acceptatieomgevingen, maar ad-hoc apps springen vaak rechtstreeks van developer naar productie. Privacy officers kunnen niet aantonen hoe vendor-data wordt verwerkt en controllers missen inzicht in licentieverplichtingen. Bij incidenten ontbreekt informatie over welke app mogelijk betrokken was. Ten slotte leidt het gebrek aan governance tot operationele verstoringen. Verschillende sites draaien verschillende appversies, waardoor ondersteuningstickets moeilijk oplosbaar zijn. In combinatie met change freezes voor verkiezingsperioden of piekbelasting kan een onbeheerde app updates pushen die belangrijke werkprocessen stilleggen. Zonder centrale blokkade blijven ongewenste apps bovendien bestaan, zelfs nadat ze zijn afgekeurd. Het ontbreken van monitoring maakt het onmogelijk om snel te reageren als een app ineens uitzonderlijk veel API-calls doet of afwijkende fouten in de Unified Audit Logs achterlaat.

Implementatie

Deze maatregel schrijft een gelaagd governance-model voor waarin techniek, processen en toezicht gelijk opgaan. Elke tenant beschikt over een centrale App Catalog die fungeert als enige bron voor goedgekeurde uitbreidingen; optionele site collection-catalogi worden alleen ingezet wanneer een afgebakende business unit zelf apps ontwikkelt en een eigen budget en beheerteam heeft. Binnen de catalogus wordt elke app voorzien van metadata zoals eigenaar, doelstelling, gegevensclassificatie, licentievorm, herkomst en afhankelijkheden zodat het beheerteam in één document de volledige context kan terugvinden. De goedkeuringsworkflow bestaat uit meerdere checkpoints. Aanvragen worden ingediend via een formulier of ITSM-proces waarin de business impact, gewenste functionaliteit, aangevraagde permissies en geplande gebruikersgroep worden beschreven. Daarna volgt een technische intake om te bepalen of SPFx het juiste platform is en of bestaande oplossingen kunnen worden hergebruikt. Security voert een risicoanalyse uit, controleert certificaten, scant broncode of vendor-documentatie en beoordeelt of privacyvoorwaarden aansluiten bij de AVG. Pas na akkoord van zowel security als de proceseigenaar wordt de app in een testcatalogus geplaatst voor functionele acceptatie, waarna een change record de productie-uitrol afdekt. Elke app krijgt bovendien een hercertificeringsdatum zodat periodiek wordt vastgesteld of de businesscase nog bestaat. De maatregel benadrukt dat SPFx de voorkeursarchitectuur is voor nieuwe ontwikkeling omdat deze modern, client-side en sandboxed is en rechtstreeks integreert met Teams, Viva en Outlook. Legacy provider-hosted of SharePoint-hosted add-ins worden opgenomen in een migratieplan, inclusief technische risicoanalyse, zodat server-side code niet langer onnodig toegang heeft tot SharePoint. Ontwikkelaars volgen vaste standaarden voor logging, telemetrie, secrets management en dependency-updates, ondersteund door geautomatiseerde pipelines met code scanning voordat een pakket ook maar in de catalogus kan worden aangeboden. Tot slot beschrijft de maatregel hoe permissies en monitoring worden ingericht. Apps krijgen alleen toegang tot de datasets die strikt noodzakelijk zijn; waar mogelijk wordt app-only access gebruikt met beheerde identiteiten en site collection scoped permissions. Tenant policies blokkeren installaties buiten de catalogus en sturen alerts naar het security operations center wanneer een gebruiker toch probeert een store-app te installeren. Alle goedgekeurde apps worden opgenomen in een Power BI-dashboard waarin versie, installatielocatie, eigenaar en laatste review zichtbaar zijn. Lifecyclebeheer borgt dat verouderde of kwetsbare apps tijdig worden uitgefaseerd. Zodra een leverancier geen updates meer levert, wordt de app op end-of-life gezet, krijgen site-eigenaren alternatieven aangereikt en verwijdert de catalogusbeheerder de package nadat data-export is afgerond. Zo blijft de omgeving schoon, voorspelbaar en in lijn met de Nederlandse Baseline voor Veilige Cloud.

Vereisten

1. Een bevoegde SharePoint Online Administrator is noodzakelijk om tenantinstellingen, App Catalogs en blokkeringsbeleid te configureren. Deze rol moet toegang hebben tot de SharePoint admin center, PowerShell-modules zoals PnP.PowerShell en het Microsoft Graph-permissiemodel begrijpen. De administrator bewaakt ook de koppeling met Azure AD Conditional Access, zodat toegang tot de catalogus uitsluitend via beheerde apparaten verloopt. Zonder deze rol kunnen basisacties zoals het inschakelen van tenant-scoped deployment of het blokkeren van de publieke store niet worden uitgevoerd. Documenteer daarom wie deze rol vervult, welke vervanger beschikbaar is, welke auditlogs worden bijgehouden en hoe change-requests worden goedgekeurd voordat instellingen live gaan. Jaarlijkse bijscholing over nieuwe SharePoint-release waves en security baseline-wijzigingen is onderdeel van dit profiel.
2. Een tenant-level App Catalog moet zijn ingericht voordat governance kan starten. De catalogus krijgt een duidelijke URL, toegewezen storage-locatie, retentiebeleid en een dedicated serviceaccount dat via PIM wordt geactiveerd. Wanneer specifieke business units eigen apps beheren, wordt per site collection een aparte catalogus ingericht met beperkte rechten en verplichte koppeling aan het centrale registratiesysteem. Documenteer hoe packages van test naar productie worden gepromoveerd, welke versies beschikbaar zijn, hoe rollback plaatsvindt bij problemen en hoe multi-geo tenants worden ondersteund. Configureer alerts voor bijna-vol opslag en borg dat back-ups beschikbaar zijn zodat packages bij een calamiteit snel kunnen worden hersteld.
3. Er moet een uitgewerkte goedkeuringsworkflow bestaan die beschrijft welke stappen een app doorloopt van idee tot productie. De workflow bevat minimaal: business intake, risicobeoordeling, technische test, security review, privacy check, licentie- of contractcontrole, acceptatie door de proceseigenaar en changegoedkeuring. Elke stap krijgt een verantwoordelijke functie, verwachte doorlooptijd en vereiste documentatie, zoals testrapporten, DPIA's of vendor assessments. Automatiseer het proces waar mogelijk via Power Automate of het ITSM-platform zodat alle beslissingen en bijlagen centraal worden opgeslagen. Zonder deze structuur ontstaat subjectieve besluitvorming en ontbreekt auditbewijs dat BIO 12.06 is gevolgd.
4. Een security review-proces is noodzakelijk voor zowel custom SPFx-oplossingen als marketplace-apps. Het proces beschrijft welke tooling wordt gebruikt (bijvoorbeeld ESLint, npm audit, Defender for DevOps, statische code-analyse), hoe resultaten worden beoordeeld en binnen welke termijn kritieke findings moeten zijn opgelost. Voor third-party apps omvat de review een leveranciersbeoordeling, controle op SOC2-rapportages, datalokaties, subverwerkers en incidentprocedures. Daarnaast wordt vastgelegd hoe vaak een app opnieuw wordt getoetst en welke triggers leiden tot een versnelde herbeoordeling, zoals kwetsbaarheidsmeldingen of wijzigingen in verwerkersovereenkomsten. De uitkomst wordt opgenomen in een risicoregister dat direct is gekoppeld aan de App Catalog.
5. SPFx-ontwikkelstandaarden beschrijven hoe ontwikkelaars broncode structureren, versiebeheer toepassen, secrets beveiligen en accessibility-eisen naleven. Het document bevat richtlijnen voor TypeScript-versies, goedgekeurde npm-packages, gebruik van Application Insights voor telemetrie en het verplicht toepassen van unit tests en end-to-end tests voordat een package wordt gebundeld. Continuous integration pipelines ondertekenen artefacten en slaan packages op in een beveiligde feed zodat herkomst kan worden aangetoond. Het standaarddocument koppelt elke coding guideline aan het opleidingsplan voor ontwikkelaars en contractors, zodat nieuwe teamleden direct weten welke kwaliteitslat geldt.

Implementatie

Start met het opzetten of herconfigureren van de tenantbrede App Catalog. Maak de sitecollection aan, wijs opslagquota toe, configureer retentie en koppel de catalogus aan een dedicated beheeraccount dat via Privileged Identity Management wordt geactiveerd. Maak aparte bibliotheken voor productie, acceptatie en archief zodat packages nooit onbedoeld worden overschreven. Documenteer welke regio data host en hoe multi-geo tenants worden ondersteund. Zodra de catalogus beschikbaar is, schakel je in het SharePoint admin center de optie om store-apps te blokkeren en wijs je alleen de catalogus als toegestane bron aan. Wanneer de infrastructuur staat, implementeer je de goedkeuringsworkflow. Gebruik Power Automate of het bestaande ITSM-platform om een formulier te bouwen waarin aanvragers de businesscase, gegevensclassificatie, gewenste functionaliteit, aangevraagde permissies en verwachte gebruikersgroep beschrijven. Het proces routeert automatisch naar security voor een risicobeoordeling, naar privacy voor AVG-checks en naar de proceseigenaar voor budgettaire goedkeuring. Voor custom ontwikkeling wordt een build pipeline gestart die linting, unit tests en dependency-scans uitvoert; de resultaten worden als bijlage opgeslagen bij het aanvraagrecord. Na succesvolle tests wordt de app eerst in een testcatalogus geplaatst voor functionele acceptatie, waarna een change advisory board de productiegoedkeuring geeft. Security- en privacycontroles vormen de kern van de implementatie. SPFx-pakketten worden voorzien van component governance, secret scanning en code signing. Third-party apps worden beoordeeld op SOC2-rapporten, datalocatie, versleutelingsniveaus en supportafspraken. De uitkomst wordt vastgelegd in een risicoprofiel dat bepaalt hoe vaak hercertificering nodig is. Apps die persoonsgegevens verwerken krijgen verplicht een DPIA, inclusief maatregelen voor logging en incidentrespons. Tegelijkertijd wordt een permissionmatrix opgesteld waarin per app staat welke Graph- en SharePoint-rechten zijn toegekend, zodat afwijkingen direct zichtbaar zijn. Automatiseer vervolgens de operationele controles. Een PowerShell- of Graph-runbook controleert dagelijks welke apps zijn geïnstalleerd, vergelijkt ze met de goedgekeurde lijst en stuurt meldingen naar het SOC wanneer onbekende packages verschijnen. Conditional Access policies zorgen ervoor dat alleen beheerde apparaten toegang hebben tot de catalogus, terwijl Sensitivity Labels voorkomen dat packages buiten het beheerproces worden gedeeld. Versiebeheer wordt geregeld via een Azure DevOps-artifactfeed of GitHub Packages, waardoor rollback en provenance gegarandeerd zijn. Wanneer een app een update nodig heeft, wordt deze eerst in acceptatie getest en daarna gedistribueerd via het tenant deployment-mechanisme. Sluit de implementatie af met adoptie- en governance-activiteiten. Train ontwikkelaars, beheerders en proceseigenaren in het nieuwe proces met handleidingen, e-learnings en kennissessies. Richt dashboards in die doorlooptijden, openstaande reviews, licentie-expiraties en securitybevindingen tonen. Leg vast hoe incidenten worden geëscaleerd en hoe data van afgekeurde apps veilig wordt verwijderd. Plan kwartaalreviews waarin CISO, CIO en vertegenwoordigers van de business het app-landschap doornemen, prioriteiten bijstellen en eventueel uitzonderingen beoordelen. Zo blijft App Management geen eenmalig project maar een blijvend onderdeel van de Nederlandse Baseline voor Veilige Cloud.

Compliance en Auditing

BIO 12.06 schrijft voor dat software alleen mag worden geïnstalleerd na expliciete autorisatie en binnen gecontroleerde procedures. Door alle SharePoint-apps via de centrale catalogus en een goedkeuringsworkflow te laten lopen, kan de organisatie aantonen wie wanneer welke beslissing heeft genomen. Het change record bevat de businesscase, de security- en privacybeoordeling en de uiteindelijke CAB-goedkeuring, waardoor auditors exact kunnen volgen hoe een app in productie kwam. Door de publieke store te blokkeren, toont de organisatie bovendien aan dat ongeautoriseerde installaties technisch onmogelijk zijn. ISO 27001 A.14.2.1 en A.14.2.5 richten zich op veilige ontwikkelprocessen, testacceptatie en beschermde productieomgevingen. Het App Management-proces levert hiervoor concreet bewijs: SPFx-code doorloopt standaard pipelines met linting, vulnerability scanning en peer review; deployment vindt pas plaats na goedkeuring in het change management-systeem; en rollback-scenario's zijn gedocumenteerd. Voor third-party apps wordt vastgelegd welke due diligence is uitgevoerd, welke contracten of verwerkersovereenkomsten gelden en hoe updates worden ontvangen. Daarmee wordt aangetoond dat externe software dezelfde beveiligingslat krijgt als interne ontwikkeling. AVG-vereisten zoals doelbinding, minimale gegevensverwerking en transparantie over subverwerkers zijn ingebed in de workflow. Elk verzoek beschrijft welke persoonsgegevens worden verwerkt, welke rechtsgrond van toepassing is en hoe betrokkenen worden geïnformeerd. Privacy officers kunnen rapportages genereren over welke apps persoonsgegevens verwerken en wanneer de laatste hercertificering is uitgevoerd. Wanneer een app data buiten de EU verwerkt, worden passende waarborgen zoals SCC's of een Data Processing Agreement vastgelegd en gekoppeld aan het auditdossier. Ook andere kaders profiteren van het programma. CIS Controls 2 en 16 verlangen inventarisatie van softwareassets en monitoring van applicatierechten; de dashboards en scripts leveren deze informatie realtime. De Wet digitale overheid en de BIO-paragraaf over ketenafhankelijkheden vragen om inzicht in leveranciersrisico's; vendor-assessments en hercertificeringsdatums voldoen aan deze eis. Omdat alle rapportages minimaal vijf jaar worden bewaard in een onveranderbare opslaglocatie, kunnen accountants, interne audits of toezichthouders op elk moment terugkijken hoe beslissingen tot stand kwamen. Wanneer SharePoint-apps persoonsgegevens van burgers bevatten, koppelt de organisatie het App Management-dossier aan logging- en forensische procedures uit BIO 10 en 11. Het dossier beschrijft hoe auditlogs van app-acties worden opgeslagen in Microsoft Purview, hoe lang deze bewaard blijven en wie toegang heeft. Daarmee kan tijdens incidentrespons snel worden vastgesteld welke app betrokken was en of de werking in lijn was met de goedgekeurde specificatie. Het compliance-raamwerk wordt afgerond met continue monitoring en rapportage. De output van het script Invoke-Monitoring wordt aan het ISMS gekoppeld zodat aantoonbaar is dat controles daadwerkelijk plaatsvinden. Elke afwijking leidt tot een incident of change-record met een verwijzing naar de getroffen controle, waardoor de PDCA-cyclus zichtbaar is. Daarnaast wordt een jaarlijkse managementreview uitgevoerd waarin trends, zoals stijgend aantal uitzonderingen, worden besproken en maatregelen opnieuw worden beoordeeld. Deze structurele evaluatie toont aan dat App Management niet alleen op papier bestaat, maar operationeel volwassen is en voldoet aan de Nederlandse Baseline voor Veilige Cloud.

Monitoring

Gebruik PowerShell-script sharepoint-app-management.ps1 (functie Invoke-Monitoring) – Invoke-Monitoring in het script sharepoint-app-management.ps1 is ontworpen om binnen vijftien seconden een volledig beeld te geven van de staat van SharePoint-apps. De functie maakt gebruik van zowel PnP.PowerShell als Microsoft Graph om gegevens uit de tenant App Catalog, site collection-catalogi en het App Management-register op te halen. Door parallelle requests en caching te gebruiken, blijft de uitvoering lichtgewicht terwijl toch honderden apps kunnen worden gecontroleerd. De functie ondersteunt multi-geo tenants en draait bij voorkeur dagelijks via Azure Automation zodat resultaten beschikbaar zijn voor het SOC en het governance-team. In de eerste controle vergelijkt het script de inhoud van de catalogi met de lijst van goedgekeurde packages. Het signaleert ontbrekende metadata (zoals eigenaar, versie of hercertificeringsdatum), detecteert apps die direct op sites zijn geüpload en markeert catalogusitems die niet overeenkomen met de artefactfeed. Wanneer packages verouderd zijn of geen koppeling hebben met het CMDB-record, wordt dit als afwijking geregistreerd inclusief impactscore en voorgestelde eigenaarsactie. Vervolgens onderzoekt Invoke-Monitoring de permissies en beleidsinstellingen. Het script leest via Graph de toegewezen app-permissions en vergelijkt deze met de toegestane matrix. Als een app plotseling extra rechten heeft gekregen of een nieuw consent heeft ontvangen, wordt dit als kritieke afwijking vastgelegd. Tegelijkertijd controleert de functie of tenantinstellingen voor de publieke store en self-service app-acquisitie nog steeds geblokkeerd zijn. Wanneer een beheerder deze instellingen heeft aangepast, genereert het script een waarschuwing zodat dit snel kan worden teruggedraaid. De resultaten worden geëxporteerd naar JSON en CSV en kunnen naar een Log Analytics workspace worden geschreven. Elk record bevat het app-id, de site, de gevonden afwijking, de verantwoordelijke eigenaar en een voorgestelde remediatiestap. Daarnaast berekent het script indicatoren zoals het totaal aantal actieve apps, verlopen hercertificeringen, packages zonder recente security-scan en installaties buiten de catalogus. Deze indicatoren voeden Power BI-dashboards en sturen automatische berichten via Teams of e-mail wanneer drempelwaarden worden overschreden. Rapporten worden standaard vijf jaar bewaard zodat audit- en incidentteams altijd kunnen terugvallen op historische data. Tot slot bevat de monitoringfunctie ingebouwde kwaliteitschecks. De runtime, het aantal API-calls en eventuele throttlingfouten worden gelogd zodat beheerders weten of het script binnen de afgesproken limiet is gebleven. Wanneer cruciale data niet kan worden opgehaald, wordt dit als blocking issue gemeld en wordt automatisch een ITSM-ticket geopend. Zo blijft de monitoring niet alleen gericht op apps zelf, maar ook op de volledigheid van het register. Door deze aanpak is er continu zicht op de effectiviteit van het App Management-programma en kan tijdig worden ingegrepen voordat risico's materialiseren..

Remediatie

Gebruik PowerShell-script sharepoint-app-management.ps1 (functie Invoke-Remediation) – Invoke-Remediation gebruikt dezelfde dataset als de monitoringfunctie maar voegt geautomatiseerde herstelacties toe. Zodra een rapport is ingeladen, wordt per afwijking bepaald of een standaardactie beschikbaar is. De operator kan kiezen uit drie modi: alleen rapporteren, semi-automatisch (per categorie bevestiging) of volledig automatisch voor laagrisico-acties. Elke run genereert vooraf een draaiboek waarin staat welke apps, sites en eigenaren worden geraakt, zodat geen onverwachte wijzigingen plaatsvinden. Voor onbevoegde installaties voert het script een gecontroleerde verwijdering uit. Het verwijdert eerst eventuele site-scoped installaties via PnP.Remove-PnPAppInstance, daarna wordt het package uit de catalogus gehaald of op pending removal gezet. Wanneer een app tenant-breed is uitgerold, voert het script een staged withdrawal uit: deactiveren, eigenaar informeren, verwijderen. Tijdens elke stap wordt gecontroleerd of het team alternatieve functionaliteit nodig heeft; indien nodig wordt automatisch een ticket aangemaakt voor het aanbieden van een vervangende oplossing. Wanneer permissie-afwijkingen worden gevonden, draait het script de consent terug naar het goedgekeurde niveau. Voor Graph-permissions gebeurt dit via de Azure AD PowerShell-module, terwijl SharePoint site-scoped rechten via PnP worden aangepast. Als een app onterecht extra rechten heeft gekregen doordat een globale administrator consent heeft verleend, wordt een waarschuwing naar het securityteam gestuurd en wordt het consent automatisch ingetrokken. Tegelijkertijd wordt een melding geplaatst in het access control register zodat hercertificering kan plaatsvinden en lessons learned worden vastgelegd. Alle herstelacties worden nauwkeurig gedocumenteerd. Het script schrijft per stap het tijdstip, de uitvoerende identiteit, het resultaat en eventuele foutmeldingen naar dezelfde opslag als de monitoringoutput. Daarnaast wordt een samenvattend rapport gemaakt dat automatisch aan het change-record of incidentticket wordt gekoppeld via de ITSM-API. Hiermee ontstaat een complete audittrail die laat zien dat afwijkingen niet alleen worden gesignaleerd maar ook aantoonbaar zijn opgelost, inclusief verwijzing naar de betreffende controle uit de Nederlandse Baseline voor Veilige Cloud. Rapporten worden volgens het bewijsbeleid minimaal vijf jaar bewaard. Om veilig te blijven werken bevat Invoke-Remediation meerdere waarborgen. Bepaalde kritieke apps staan op een uitsluitingslijst en vereisen altijd handmatige goedkeuring. Het script controleert of de operator de juiste rol heeft via Azure AD PIM en stopt wanneer de sessie niet is geautoriseerd. Na afloop vergelijkt het script de omgeving opnieuw met de referentielijst zodat automatische validatie bevestigt dat de afwijking daadwerkelijk is opgelost. Door deze combinatie van automatisering en controle blijft remediatie snel, herhaalbaar en aantoonbaar, terwijl de uitvoering ruim binnen de maximale draaitijd blijft..

Compliance & Frameworks

• BIO: 12.06.02 - Beheersing van software-installaties via goedgekeurde procedures en centrale registratie (BIO 12.06).
• ISO 27001:2022: A.14.2.1 - Veilig ontwikkel- en releasebeleid voor maatwerk en third-party apps (ISO 27001 A.14.2.1/A.14.2.5).

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

Gebruik de App Catalog als enige distributiekanaal, verplicht SPFx of beoordeelde third-party apps, automatiseer de goedkeuringsworkflow inclusief security en privacychecks, blokkeer de publieke store en monitor installaties met het meegeleverde script. Implementatie kost circa 16 uur en levert directe compliancewinst op.

• Implementatietijd: 16 uur
• FTE required: 0.1 FTE