Geen Basic/Consumption SKU Voor Productieomgevingen

Voor Nederlandse overheidsorganisaties is de beschikbaarheid van kritieke diensten niet alleen een technische uitdaging, maar ook een wettelijke verplichting die direct verband houdt met de continuïteit van publieke dienstverlening. Basic en Consumption SKUs vormen hierin een fundamenteel risico, omdat deze SKUs doorgaans geen of zeer beperkte service level agreements (SLA's) bieden. Dit betekent dat Microsoft geen garanties geeft over beschikbaarheidstijd, prestaties of ondersteuning voor deze SKUs, wat kan leiden tot onverwachte serviceonderbrekingen die de bedrijfscontinuïteit direct kunnen beïnvloeden. Wanneer een kritieke dienst plotseling niet beschikbaar is, kunnen burgers en bedrijven niet worden geholpen, wat leidt tot verlies van vertrouwen, mogelijke juridische aansprakelijkheid en reputatieschade voor de organisatie. Naast het ontbreken van SLA's bieden Basic en Consumption SKUs doorgaans beperkte functionaliteiten die essentieel kunnen zijn voor productieomgevingen. Basic SKUs zijn ontworpen voor test- en ontwikkelomgevingen waar hoge beschikbaarheid en geavanceerde functies niet nodig zijn. Deze SKUs missen vaak essentiële beveiligingsfuncties, prestatieoptimalisaties en monitoringmogelijkheden die nodig zijn voor productiegebruik. Consumption SKUs werken op basis van een gebruiksgebaseerd betalingsmodel zonder garanties over beschikbaarheid of prestaties, wat betekent dat services kunnen worden beperkt of zelfs gestopt wanneer er sprake is van hoge vraag of resource-schaarste. Dit maakt Consumption SKUs volledig ongeschikt voor productieomgevingen waar betrouwbaarheid en voorspelbaarheid essentieel zijn. Vanuit compliance-perspectief vereist de Baseline Informatiebeveiliging Overheid (BIO) specifiek controle 17.01 over dienstbeschikbaarheid. Deze controle vereist dat organisaties maatregelen treffen om de beschikbaarheid van diensten te waarborgen, en het gebruik van Basic of Consumption SKUs in productieomgevingen vormt een directe schending van deze vereiste. Tijdens audits moet kunnen worden aangetoond dat alle productieresources gebruikmaken van SKUs met passende service level agreements. Het niet voldoen aan deze vereisten kan leiden tot negatieve auditbevindingen, mogelijke boetes, en in extreme gevallen tot het verlies van certificeringen of accreditaties die essentieel zijn voor het uitvoeren van overheidsfuncties. Daarnaast brengen Basic en Consumption SKUs ook operationele risico's met zich mee. Zonder adequate SLA's en ondersteuning kunnen problemen met deze SKUs lang duren om op te lossen, omdat Microsoft prioriteit geeft aan klanten met Standard of Premium SKUs. Dit kan leiden tot langdurige serviceonderbrekingen waarbij IT-teams machteloos zijn en moeten wachten op externe ondersteuning. Bovendien bieden deze SKUs vaak geen of beperkte monitoring- en rapportagemogelijkheden, waardoor organisaties niet proactief kunnen reageren op problemen voordat ze impact hebben op gebruikers. Deze beperkingen maken het onmogelijk om een effectieve operationele omgeving te onderhouden die voldoet aan de hoge standaarden die worden verwacht van Nederlandse overheidsorganisaties. Tot slot vormt het gebruik van Basic of Consumption SKUs in productieomgevingen ook een financieel risico. Hoewel deze SKUs doorgaans goedkoper zijn in initiële kosten, kunnen de indirecte kosten van serviceonderbrekingen, verloren productiviteit en potentiële aansprakelijkheid aanzienlijk hoger zijn dan de besparingen op directe resourcekosten. Wanneer kritieke diensten falen, kunnen de kosten daarvan vele malen hoger zijn dan de kostenbesparingen die worden gerealiseerd door het gebruik van goedkopere SKUs. Bovendien kunnen Consumption SKUs onverwacht hoge kosten genereren wanneer er sprake is van hoge resourceconsumptie, waardoor de totale kosten uiteindelijk hoger kunnen zijn dan bij een Standard SKU met voorspelbare maandelijkse kosten.

Implementatie

Deze beveiligingsmaatregel implementeert best practices voor resourcebeheer door te waarborgen dat alle resources in productieomgevingen gebruikmaken van Standard of Premium SKUs die passende service level overeenkomsten en functionaliteiten bieden. De implementatie kan worden uitgevoerd via verschillende methoden, afhankelijk van de beschikbare beheerinfrastructuur binnen de organisatie. Azure Policy vormt de primaire aanbevolen methode, waarbij beleidsregels worden geconfigureerd die automatisch controleren of nieuwe resources voldoen aan de SKU-vereisten en die waarschuwingen genereren wanneer resources worden geconfigureerd met ongeschikte SKUs. Deze beleidsregels kunnen worden geconfigureerd op abonnementsniveau of beheergroepniveau, waardoor organisaties centraal kunnen controleren en handhaven dat alle productieresources voldoen aan de gestelde standaarden. Naast Azure Policy kunnen organisaties ook gebruikmaken van ARM-sjablonen (Azure Resource Manager) om ervoor te zorgen dat nieuwe resources standaard worden geconfigureerd met geschikte SKUs. Door standaardsjablonen te gebruiken die alleen Standard of Premium SKUs toestaan, voorkomen organisaties dat ontwikkelaars per ongeluk Basic of Consumption SKUs selecteren voor productieresources. Deze sjablonen kunnen worden geïntegreerd in CI/CD-pipelines en implementatieprocessen, waardoor automatisch wordt gecontroleerd dat alle nieuwe implementaties voldoen aan de SKU-vereisten voordat resources daadwerkelijk worden geïmplementeerd. Voor bestaande resources die momenteel gebruikmaken van Basic of Consumption SKUs moet een systematische upgrade worden uitgevoerd naar geschikte Standard of Premium SKUs. Deze upgrade moet zorgvuldig worden gepland en uitgevoerd om serviceonderbrekingen te minimaliseren en de impact op gebruikers en bedrijfsprocessen te beperken. De meeste Azure-services ondersteunen SKU-upgrades zonder downtime, maar dit is niet altijd gegarandeerd en moet voor elke resource worden geëvalueerd. Tijdens het upgradeproces moeten resources continu worden gemonitord om te verifiëren dat de service correct functioneert met de nieuwe SKU-configuratie. Naast de technische implementatie vereist deze maatregel ook organisatorische wijzigingen. Organisaties moeten een duidelijk beleid ontwikkelen dat definieert welke SKUs acceptabel zijn voor verschillende omgevingstypen, en dit beleid moet worden gecommuniceerd naar alle betrokken teams, inclusief ontwikkelteams, operationele teams en beveiligingsteams. Het beleid moet ook procedures bevatten voor uitzonderingen, waarbij duidelijk wordt aangegeven onder welke omstandigheden Basic of Consumption SKUs tijdelijk acceptabel kunnen zijn, en welke goedkeuringsprocessen hiervoor gelden. Door deze organisatorische maatregelen te combineren met technische controles, zorgt de organisatie ervoor dat de SKU-vereisten consistent worden toegepast en dat alle productieresources voldoen aan de gestelde standaarden voor beschikbaarheid, betrouwbaarheid en beveiliging.

Vereisten

Voor het implementeren van deze beveiligingsmaatregel zijn specifieke vereisten noodzakelijk om ervoor te zorgen dat productieomgevingen voldoen aan de gestelde standaarden voor beschikbaarheid, betrouwbaarheid en beveiliging. Organisaties moeten een grondige inventarisatie uitvoeren van alle Azure-resources die in productieomgevingen worden gebruikt, waarbij speciale aandacht wordt besteed aan de huidige SKU-configuraties. Deze inventarisatie vormt de basis voor het identificeren van resources die gebruikmaken van Basic of Consumption SKUs, welke niet geschikt zijn voor productieomgevingen vanwege hun beperkte service level overeenkomsten en functionaliteiten. De vereisten omvatten allereerst een volledig overzicht van alle productieresources binnen de Azure-tenant. Dit betekent dat organisaties een systematische audit moeten uitvoeren van alle resourcegroepen, abonnementen en beheergroepen om te identificeren welke resources momenteel gebruikmaken van Basic of Consumption SKUs. Deze audit moet worden uitgevoerd door gekwalificeerd IT-personeel met kennis van Azure-architectuur en resourcebeheer. Het is van cruciaal belang dat deze inventarisatie volledig en accuraat is, omdat onvolledige informatie kan leiden tot gemiste resources die later problemen kunnen veroorzaken. Daarnaast is het essentieel dat organisaties beschikken over de juiste Azure-machtigingen om resources te kunnen inventariseren en configureren. Dit vereist minimaal de rol van Lezer op abonnementsniveau, en voor implementatiedoeleinden de rol van Inzender of Resource Policy Inzender. Voor organisaties die Azure Policy willen gebruiken om deze maatregel te handhaven, is de rol van Policy Inzender vereist op het niveau waar het beleid wordt toegepast. Zonder de juiste machtigingen kunnen organisaties niet effectief controleren of resources voldoen aan de SKU-vereisten, wat kan leiden tot compliance-problemen. Een kritische vereiste is de beschikbaarheid van een gestructureerd proces voor resourcebeheer en wijzigingsbeheer. Organisaties moeten procedures hebben voor het upgraden van SKUs, inclusief impactanalyses, testprocedures en terugdraaiplannen. Dit is met name belangrijk omdat het upgraden van SKUs kan leiden tot kostenverhogingen en mogelijke serviceonderbrekingen tijdens het migratieproces. Het wijzigingsbeheerproces moet duidelijk definiëren wie verantwoordelijk is voor het goedkeuren van SKU-upgrades, welke testprocedures moeten worden gevolgd, en hoe terugdraaiscenario's moeten worden afgehandeld. Technische vereisten omvatten ook de beschikbaarheid van monitoring- en rapportagetools om de compliancestatus continu te kunnen volgen. Organisaties moeten in staat zijn om regelmatig te rapporteren over de SKU-status van productieresources en afwijkingen te identificeren. Dit vereist vaak de implementatie van Azure Policy, Azure Monitor of aangepaste monitoringoplossingen die kunnen detecteren wanneer resources worden geconfigureerd met Basic of Consumption SKUs. Deze tools moeten in staat zijn om realtime waarschuwingen te genereren wanneer niet-compliant resources worden gedetecteerd, zodat teams direct kunnen reageren. Tot slot is een belangrijke vereiste dat organisaties een duidelijk beleid hebben gedefinieerd over welke SKUs acceptabel zijn voor verschillende omgevingstypen. Dit beleid moet worden gedocumenteerd en gecommuniceerd naar alle betrokken teams, inclusief ontwikkelteams, operationele teams en beveiligingsteams. Het beleid moet ook procedures bevatten voor uitzonderingen, waarbij duidelijk wordt aangegeven onder welke omstandigheden Basic of Consumption SKUs tijdelijk acceptabel kunnen zijn, en welke goedkeuringsprocessen hiervoor gelden. Dit beleid vormt de basis voor alle beslissingen over SKU-selectie en moet regelmatig worden geëvalueerd en bijgewerkt om rekening te houden met veranderende behoeften en nieuwe Azure-services.

Monitoring

Gebruik PowerShell-script no-basic-consumption-sku.ps1 (functie Invoke-Monitoring) – Controleren.

Effectieve monitoring van resource SKUs is essentieel om te waarborgen dat productieomgevingen voldoen aan de gestelde beveiligings- en beschikbaarheidsstandaarden. Het monitoren van SKU-configuraties vereist een gestructureerde aanpak waarbij regelmatig wordt gecontroleerd of resources in productieomgevingen gebruikmaken van Basic of Consumption SKUs, welke niet geschikt zijn voor productiegebruik vanwege hun beperkte service level overeenkomsten en functionaliteiten. Zonder adequate monitoring kunnen organisaties niet garanderen dat hun productieomgevingen voldoen aan de vereiste standaarden, wat kan leiden tot onverwachte serviceonderbrekingen en nalevingsproblemen. De monitoringactiviteiten moeten systematisch worden uitgevoerd door middel van geautomatiseerde controles die alle Azure-resources binnen de organisatie inventariseren en evalueren op basis van hun SKU-configuratie. Deze controles moeten minimaal maandelijks worden uitgevoerd, maar voor organisaties met hoge compliance-eisen wordt aanbevolen om wekelijkse of zelfs dagelijkse controles uit te voeren. Het gebruik van Azure Policy biedt hierbij de mogelijkheid om realtime monitoring te implementeren, waarbij direct wordt gealarmeerd wanneer resources worden geconfigureerd met ongeschikte SKUs. Geautomatiseerde monitoring voorkomt menselijke fouten en zorgt ervoor dat afwijkingen direct worden gedetecteerd, zelfs wanneer resources worden geconfigureerd buiten normale werkuren. Het monitoringproces begint met het identificeren van alle productieresources binnen de Azure-tenant. Dit omvat resources in alle abonnementen en resourcegroepen die zijn gemarkeerd als productieomgevingen. Voor elke resource moet worden gecontroleerd welke SKU is geconfigureerd, waarbij speciale aandacht wordt besteed aan resources die gebruikmaken van Basic of Consumption SKUs. Deze resources moeten worden gemarkeerd als niet-nalevend en moeten worden geëscaleerd naar de verantwoordelijke teams voor verdere actie. Het is belangrijk dat het monitoringproces ook resources identificeert waarvan de omgevingstype niet duidelijk is gedefinieerd, omdat deze mogelijk ook in productie worden gebruikt zonder de juiste classificatie. De monitoringoplossing moet in staat zijn om verschillende typen resources te controleren, waaronder virtuele machines, App Services, Azure Functions, opslagaccounts, SQL-databases, en andere Azure-services die SKU-selectie ondersteunen. Voor elk resourcetype moeten de specifieke SKU-namen worden gecontroleerd om te bepalen of ze voldoen aan de productiestandaarden. Basic SKUs worden gekenmerkt door beperkte functionaliteiten en geen service level overeenkomsten, terwijl Consumption SKUs variabele kosten en beperkte garanties hebben. De monitoringoplossing moet kunnen omgaan met de verschillende manieren waarop SKUs worden weergegeven in verschillende Azure-services, omdat de naamgeving en configuratie kunnen variëren tussen services. Rapportage vormt een cruciaal onderdeel van het monitoringproces. Organisaties moeten regelmatig rapporten genereren die een overzicht geven van de compliancestatus van alle productieresources. Deze rapporten moeten informatie bevatten over het aantal resources met Basic of Consumption SKUs, de locatie van deze resources, de verantwoordelijke teams, en de geplande acties om deze situatie te remediëren. De rapporten moeten worden gedeeld met beveiligingsteams, nalevingsfunctionarissen, en management om transparantie te waarborgen. Effectieve rapportage maakt het mogelijk om trends te identificeren, prioriteiten te stellen voor remediatie-activiteiten, en te demonstreren aan auditors dat de organisatie proactief werkt aan het handhaven van naleving. Daarnaast moet het monitoringproces waarschuwingen bevatten voor nieuwe of gewijzigde resources die niet-compliant zijn. Wanneer een resource wordt geconfigureerd met een Basic of Consumption SKU in een productieomgeving, moet direct een waarschuwing worden gegenereerd naar de verantwoordelijke teams. Dit maakt het mogelijk om proactief te reageren op configuratiefouten voordat deze impact hebben op de productieomgeving. Waarschuwingen moeten worden geconfigureerd met de juiste prioriteit en moeten worden gerouteerd naar de teams die verantwoordelijk zijn voor het beheer van de betreffende resources, zodat snelle actie kan worden ondernomen. Door deze proactieve benadering kunnen organisaties problemen voorkomen voordat ze daadwerkelijk impact hebben op de bedrijfscontinuïteit en de kwaliteit van de geleverde diensten. Het is belangrijk dat de monitoringoplossing ook historische trends kan volgen, zodat organisaties kunnen zien of de nalevingsstatus verbetert of verslechtert over tijd. Dit maakt het mogelijk om de effectiviteit van implementatie- en remediatie-activiteiten te meten en te bepalen of aanvullende maatregelen nodig zijn om de gewenste nalevingsstatus te bereiken en te behouden. Historische data kan ook worden gebruikt om te identificeren welke teams of processen het meest bijdragen aan nalevingsproblemen, zodat gerichte verbeteringen kunnen worden geïmplementeerd. Door trends te analyseren kunnen organisaties ook voorspellen wanneer nieuwe resources mogelijk niet-nalevend zullen zijn, waardoor preventieve maatregelen kunnen worden genomen. Deze voorspellende capaciteit stelt organisaties in staat om proactief te handelen en problemen te voorkomen voordat ze daadwerkelijk optreden, wat resulteert in een hogere mate van naleving en betere bedrijfscontinuïteit.

Implementatie

Gebruik PowerShell-script no-basic-consumption-sku.ps1 (functie Invoke-Implementation) – Implementeren.

De implementatie van deze beveiligingsmaatregel vereist een gestructureerde aanpak waarbij organisaties systematisch alle productieresources evalueren en upgraden naar geschikte SKUs die voldoen aan de productiestandaarden. Het implementatieproces begint met een grondige evaluatie van alle resource SKUs binnen de Azure-tenant, waarbij wordt geïdentificeerd welke resources momenteel gebruikmaken van Basic of Consumption SKUs die niet geschikt zijn voor productieomgevingen. Een goed geplande implementatie voorkomt serviceonderbrekingen, minimaliseert kostenimpact en zorgt ervoor dat alle resources uiteindelijk voldoen aan de vereiste standaarden. Deze systematische aanpak is essentieel voor Nederlandse overheidsorganisaties die moeten voldoen aan strikte compliance-eisen en hoge beschikbaarheidsstandaarden voor kritieke publieke diensten. De eerste stap in het implementatieproces is het uitvoeren van een volledige inventarisatie van alle Azure-resources. Dit omvat het scannen van alle abonnementen, resourcegroepen en individuele resources om te bepalen welke SKUs momenteel zijn geconfigureerd. Het gebruik van geautomatiseerde scripts of Azure Policy-initiatieven kan dit proces aanzienlijk versnellen en de nauwkeurigheid verbeteren. Tijdens deze inventarisatie moet speciale aandacht worden besteed aan resources die zijn gemarkeerd als productieomgevingen, maar ook aan resources waarvan het omgevingstype niet duidelijk is gedefinieerd. Een volledige inventarisatie is essentieel omdat gemiste resources later kunnen leiden tot compliance-problemen en onverwachte serviceonderbrekingen. Na de inventarisatie moeten organisaties een prioriteringsplan ontwikkelen voor het upgraden van resources. Resources met kritieke bedrijfsfuncties moeten prioriteit krijgen, gevolgd door resources met hoge beschikbaarheidseisen. Voor elk resource moet worden bepaald welke Standard of Premium SKU het meest geschikt is, rekening houdend met de specifieke vereisten voor prestaties, beschikbaarheid en functionaliteiten. Het is belangrijk om hierbij ook de kostenimpact te evalueren, omdat het upgraden naar hogere SKUs kan leiden tot verhoogde operationele kosten. Het prioriteringsplan moet ook rekening houden met afhankelijkheden tussen resources, omdat sommige upgrades mogelijk moeten worden gecoördineerd om te voorkomen dat gerelateerde services worden beïnvloed. Het upgradeproces zelf moet zorgvuldig worden uitgevoerd om serviceonderbrekingen te minimaliseren. Voor de meeste Azure-services kan een SKU-upgrade worden uitgevoerd zonder downtime, maar dit is niet altijd het geval. Organisaties moeten voor elke resource een upgradeplan ontwikkelen dat rekening houdt met mogelijke serviceonderbrekingen en terugdraai-procedures bevat. Het wordt aanbevolen om upgrades eerst uit te voeren in testomgevingen om te valideren dat de nieuwe SKU-configuratie voldoet aan de verwachtingen. Tijdens het upgradeproces moeten resources continu worden gemonitord om te verifiëren dat de service correct functioneert en dat er geen onverwachte problemen optreden. Voor productieresources die momenteel gebruikmaken van Basic of Consumption SKUs moet worden geüpgraded naar Standard of hoger. Standard SKUs bieden betere service level overeenkomsten, meer functionaliteiten en betere prestatiegaranties, wat essentieel is voor productieomgevingen. Premium SKUs bieden nog betere garanties en geavanceerde functionaliteiten, maar zijn doorgaans alleen nodig voor resources met zeer hoge beschikbaarheids- of prestatie-eisen. Bij het selecteren van de juiste SKU moeten organisaties een balans vinden tussen kosten en functionaliteiten, waarbij wordt geëvalueerd welke functionaliteiten daadwerkelijk nodig zijn voor het specifieke gebruiksscenario. Naast het upgraden van bestaande resources moeten organisaties ook preventieve maatregelen implementeren om te voorkomen dat nieuwe resources worden geconfigureerd met ongeschikte SKUs. Dit kan worden bereikt door het implementeren van Azure Policy-definities die automatisch controleren of nieuwe resources voldoen aan de SKU-vereisten. Deze beleidsregels kunnen worden geconfigureerd om automatisch te weigeren wanneer resources worden geconfigureerd met Basic of Consumption SKUs in productieomgevingen, of om waarschuwingen te genereren die teams attenderen op de configuratiefout. Preventieve maatregelen zijn essentieel omdat ze voorkomen dat hetzelfde probleem opnieuw optreedt en zorgen voor continue compliance zonder constante handmatige interventie. Het is belangrijk dat het implementatieproces wordt gedocumenteerd en dat alle wijzigingen worden geregistreerd in het wijzigingsbeheersysteem. Dit maakt het mogelijk om te traceren welke resources zijn geüpgraded, wanneer dit is gebeurd, en welke impact dit heeft gehad op de kosten en beschikbaarheid. Deze documentatie is ook essentieel voor compliance-doeleinden en audits, waarbij moet kunnen worden aangetoond dat alle productieresources voldoen aan de gestelde standaarden. Goede documentatie maakt het ook mogelijk om lessen te leren van het implementatieproces en deze toe te passen op toekomstige implementaties. Tot slot moet het implementatieproces worden afgerond met een validatiecontrole waarbij wordt geverifieerd dat alle productieresources nu gebruikmaken van geschikte SKUs. Deze validatie moet worden uitgevoerd met dezelfde tools en processen die worden gebruikt voor continue monitoring, om te waarborgen dat de implementatie succesvol is voltooid en dat de gewenste nalevingsstatus is bereikt. Tijdens de validatie moeten ook de kostenimpact en prestatie-impact worden geëvalueerd om te verifiëren dat de upgrades de verwachte resultaten hebben opgeleverd en dat er geen onverwachte problemen zijn ontstaan. Deze validatie is cruciaal omdat het bevestigt dat de organisatie nu voldoet aan alle vereisten voor resourcebeheer en beschikbaarheid, wat essentieel is voor het behouden van compliance-certificeringen en het waarborgen van de continuïteit van publieke dienstverlening.

Compliance en Audit

De implementatie van geschikte SKUs voor productieresources is direct gerelateerd aan naleving van verschillende beveiligings- en beschikbaarheidsstandaarden, waaronder de Baseline Informatiebeveiliging Overheid (BIO). Specifiek relateert deze maatregel aan BIO controle 17.01, welke betrekking heeft op servicebeschikbaarheid en de garantie dat kritieke bedrijfsprocessen kunnen blijven functioneren onder normale en afwijkende omstandigheden. Voor Nederlandse overheidsorganisaties is het waarborgen van servicebeschikbaarheid niet alleen een technische uitdaging, maar ook een wettelijke verplichting die direct verband houdt met de continuïteit van publieke dienstverlening. BIO controle 17.01 vereist dat organisaties maatregelen treffen om de beschikbaarheid van services te waarborgen. Het gebruik van Basic of Consumption SKUs in productieomgevingen vormt een risico voor deze beschikbaarheid, omdat deze SKUs doorgaans geen of beperkte service level overeenkomsten hebben. Dit betekent dat Microsoft geen garanties geeft over beschikbaarheidstijd, prestaties of ondersteuning voor deze SKUs, wat kan leiden tot onverwachte serviceonderbrekingen die de bedrijfscontinuïteit kunnen beïnvloeden. Voor overheidsorganisaties die kritieke diensten leveren aan burgers en bedrijven, kunnen dergelijke onderbrekingen ernstige gevolgen hebben, waaronder verlies van vertrouwen en mogelijke juridische aansprakelijkheid. Voor Nederlandse overheidsorganisaties is naleving van BIO-normen niet alleen een best practice, maar een wettelijke verplichting. Organisaties moeten kunnen aantonen dat zij passende maatregelen hebben genomen om de beschikbaarheid van hun services te waarborgen, en het gebruik van Standard of Premium SKUs voor productieresources is een concrete manier om aan deze verplichting te voldoen. Tijdens audits moet kunnen worden aangetoond dat alle productieresources gebruikmaken van SKUs met passende service level overeenkomsten. Het niet voldoen aan deze vereisten kan leiden tot negatieve auditbevindingen, mogelijke boetes, en in extreme gevallen tot het verlies van certificeringen of accreditaties. Naast BIO-compliance zijn er ook andere compliance-frameworks die relevant zijn voor deze maatregel. De ISO 27001 standaard vereist bijvoorbeeld dat organisaties maatregelen treffen om de beschikbaarheid van informatie te waarborgen, en het gebruik van geschikte SKUs draagt hieraan bij. Ook de NEN 7510 standaard voor informatiebeveiliging in de zorgsector bevat vereisten voor beschikbaarheid die kunnen worden ondersteund door het gebruik van passende SKUs. Organisaties die werken met meerdere compliance-frameworks moeten ervoor zorgen dat hun SKU-selectie voldoet aan alle relevante vereisten, wat kan betekenen dat de meest strikte vereisten moeten worden gevolgd. Het auditproces voor deze maatregel moet regelmatig worden uitgevoerd om te verifiëren dat alle productieresources voldoen aan de SKU-vereisten. Audits moeten worden uitgevoerd door onafhankelijke partijen of interne auditafdelingen, en moeten een volledige inventarisatie bevatten van alle productieresources en hun SKU-configuraties. De auditresultaten moeten worden gedocumenteerd en beschikbaar zijn voor externe auditors en toezichthouders. Effectieve audits helpen organisaties niet alleen om naleving te demonstreren, maar ook om gebieden te identificeren waar verbeteringen mogelijk zijn. Voor audit-doeleinden moeten organisaties bewijs kunnen leveren van hun nalevingsstatus. Dit omvat inventarissen van alle productieresources met hun SKU-configuraties, rapporten van monitoringactiviteiten, en documentatie van implementatie- en remediatie-acties. Deze documentatie moet worden bewaard voor de vereiste bewaartermijn, welke doorgaans minimaal zeven jaar is voor overheidsorganisaties. Goede documentatie maakt het mogelijk om de nalevingshistorie te traceren en te demonstreren dat de organisatie proactief werkt aan het handhaven van standaarden, zelfs wanneer er incidenteel afwijkingen optreden. Het is belangrijk dat organisaties ook procedures hebben voor het omgaan met uitzonderingen op de SKU-vereisten. In sommige gevallen kan het tijdelijk acceptabel zijn om Basic of Consumption SKUs te gebruiken, bijvoorbeeld tijdens migraties of voor specifieke testscenario's. Deze uitzonderingen moeten echter worden gedocumenteerd, goedgekeurd door de juiste autoriteiten, en worden beoordeeld op regelmatige basis om te bepalen of ze nog steeds gerechtvaardigd zijn. Uitzonderingen moeten worden gezien als tijdelijke maatregelen en er moet altijd een plan zijn voor het bereiken van volledige naleving binnen een redelijke termijn. Tot slot moet het nalevingsproces ook aandacht besteden aan continue verbetering. Organisaties moeten regelmatig evalueren of hun SKU-configuraties nog steeds voldoen aan de veranderende behoeften en of er mogelijkheden zijn om de beschikbaarheid en betrouwbaarheid verder te verbeteren. Dit kan bijvoorbeeld betekenen dat resources die momenteel Standard SKUs gebruiken, in de toekomst moeten worden geüpgraded naar Premium SKUs als de bedrijfsvereisten toenemen. Continue verbetering zorgt ervoor dat organisaties niet alleen voldoen aan de minimale vereisten, maar ook proactief werken aan het optimaliseren van hun beveiligings- en beschikbaarheidspositie.

Remediatie

Gebruik PowerShell-script no-basic-consumption-sku.ps1 (functie Invoke-Remediation) – Herstellen.

Wanneer productieresources worden geïdentificeerd die gebruikmaken van Basic of Consumption SKUs, moeten deze onmiddellijk worden geremediateerd door te upgraden naar geschikte Standard of Premium SKUs. Het remediatieproces moet systematisch worden uitgevoerd om te waarborgen dat alle niet-nalevende resources worden aangepakt zonder onnodige serviceonderbrekingen of operationele risico's. Effectieve remediatie is essentieel omdat niet-nalevende resources een direct risico vormen voor de bedrijfscontinuïteit en nalevingsstatus van de organisatie. Het remediatieproces begint met het identificeren van alle resources die remediatie vereisen. Dit wordt gedaan door middel van de monitoring- en auditprocessen die regelmatig worden uitgevoerd. Voor elke geïdentificeerde resource moet worden bepaald welke Standard of Premium SKU het meest geschikt is, rekening houdend met de specifieke vereisten voor prestaties, beschikbaarheid, functionaliteiten en kosten. Het is belangrijk om hierbij ook te evalueren of de resource daadwerkelijk in een productieomgeving wordt gebruikt, of dat deze mogelijk verkeerd is geclassificeerd. Een grondige evaluatie voorkomt onnodige kosten en zorgt ervoor dat resources alleen worden geüpgraded wanneer dit daadwerkelijk nodig is. Voor het uitvoeren van de remediatie moet voor elke resource een upgradeplan worden ontwikkeld dat rekening houdt met mogelijke serviceonderbrekingen en de impact op gebruikers en bedrijfsprocessen. De meeste Azure-services ondersteunen SKU-upgrades zonder downtime, maar dit is niet altijd gegarandeerd. Organisaties moeten daarom voor elke resource evalueren of een live upgrade mogelijk is, of dat er een migratieproces nodig is waarbij de resource tijdelijk moet worden gestopt. Het upgradeplan moet ook rekening houden met afhankelijkheden tussen resources, omdat sommige upgrades mogelijk moeten worden gecoördineerd om te voorkomen dat gerelateerde services worden beïnvloed. Het wordt sterk aanbevolen om remediatie-acties eerst uit te voeren in een testomgeving of tijdens onderhoudsvensters om de impact te minimaliseren. Tijdens het upgradeproces moeten organisaties de resource continu monitoren om te verifiëren dat de upgrade succesvol is en dat de service correct functioneert met de nieuwe SKU-configuratie. Als er problemen optreden tijdens of na de upgrade, moeten terugdraai-procedures beschikbaar zijn om de resource terug te brengen naar de oorspronkelijke configuratie. Goede monitoring en terugdraai-procedures minimaliseren het risico van langdurige serviceonderbrekingen en zorgen ervoor dat problemen snel kunnen worden opgelost. Voor resources die niet direct kunnen worden geüpgraded vanwege technische beperkingen of bedrijfsvereisten, moeten tijdelijke mitigatiemaatregelen worden geïmplementeerd. Dit kan bijvoorbeeld betekenen dat extra monitoring wordt toegevoegd, dat back-up- en herstelprocedures worden verbeterd, of dat de resource wordt gemigreerd naar een alternatieve service die wel geschikte SKUs ondersteunt. Deze mitigatiemaatregelen moeten echter worden gezien als tijdelijke oplossingen, en er moet een duidelijk plan zijn voor definitieve remediatie. Tijdelijke mitigatie mag nooit worden gebruikt als excuus om definitieve remediatie uit te stellen, omdat dit de organisatie blootstelt aan continue risico's. Na het voltooien van de remediatie moet worden geverifieerd dat de resource nu voldoet aan de SKU-vereisten. Dit omvat het controleren van de nieuwe SKU-configuratie, het valideren dat de service correct functioneert, en het bevestigen dat alle service level overeenkomsten en functionaliteiten beschikbaar zijn. Deze verificatie moet worden gedocumenteerd als bewijs van de uitgevoerde remediatie. Verificatie is essentieel omdat het bevestigt dat de remediatie succesvol is geweest en dat de resource nu voldoet aan alle vereisten. Zonder adequate verificatie kunnen organisaties niet zeker zijn dat de remediatie daadwerkelijk het gewenste resultaat heeft opgeleverd. Het is belangrijk dat alle remediatie-acties worden geregistreerd in het wijzigingsbeheersysteem en worden gecommuniceerd naar de relevante stakeholders. Dit omvat het documenteren van de oorspronkelijke SKU-configuratie, de nieuwe SKU-configuratie, de reden voor de upgrade, de uitgevoerde stappen, en de resultaten van de verificatie. Deze documentatie is essentieel voor nalevingsdoeleinden en maakt het mogelijk om de remediatie-activiteiten te traceren en te auditen. Goede documentatie helpt ook bij het leren van ervaringen en het verbeteren van toekomstige remediatie-processen. Tot slot moet het remediatieproces worden afgerond met een evaluatie van de effectiviteit van de genomen maatregelen. Dit omvat het beoordelen van de impact op beschikbaarheid, prestaties, kosten en gebruikerservaring. Als de remediatie negatieve gevolgen heeft gehad, moeten deze worden geanalyseerd en moeten lessen worden getrokken voor toekomstige remediatie-activiteiten. Daarnaast moet worden gecontroleerd of er preventieve maatregelen zijn geïmplementeerd om te voorkomen dat nieuwe resources worden geconfigureerd met ongeschikte SKUs. Evaluatie is belangrijk omdat het helpt bij het verbeteren van het remediatieproces en ervoor zorgt dat toekomstige remediaties effectiever en efficiënter kunnen worden uitgevoerd. Door regelmatige evaluatie kunnen organisaties hun remediatieprocessen continu optimaliseren en ervoor zorgen dat ze altijd voldoen aan de hoogste standaarden voor resourcebeheer en naleving.

Compliance & Frameworks

• BIO: 17.01 - Servicebeschikbaarheid

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

Geen Basic/Consumption SKU: Gebruik Standard/Premium SKUs voor productieresources (SLA-garanties, geavanceerde functionaliteiten). Basic/Consumption acceptabel voor dev/test. Activatie: Resource SKU-evaluatie → Upgrade naar Standard+. Kosten: hoger maar SLA inbegrepen. Verplicht BIO 17.01. Implementatie: 2-4 uur audit. Productiebetrouwbaarheid.

• Implementatietijd: 4 uur
• FTE required: 0.05 FTE