Veilig werken met Microsoft Azure
Een Azure Sandbox-omgeving kan een waardevolle manier zijn om studenten, klanten of collega’s praktisch te leren werken met Microsoft Azure. Alleen video’s bekijken is immers niet genoeg om Azure echt onder de knie te krijgen. Door zelf oplossingen te bouwen en echte problemen op te lossen, doe je ervaring op in de praktijk.
Maar hoe richt je zo’n sandboxomgeving veilig in? In deze blog bekijken we de verschillende lagen die je kunt gebruiken om gebruikers vrijheid te geven om te experimenteren, terwijl je tegelijkertijd controle houdt over kosten, rechten en resources.
Waarom een Azure Sandbox?
Bij het leren werken met Azure draait het om toegang. Je krijgy hier de mogelijkheid om zelf oplossingen te bouwen en met Azure-services te experimenteren.
Een Azure Sandbox biedt hiervoor een geïsoleerde omgeving waarin gebruikers zelfstandig aan de slag kunnen. Tegelijkertijd kun je als beheerder bepalen welke resources mogen worden aangemaakt, welke rechten gebruikers krijgen en hoeveel er mag worden uitgegeven.
Een goed ingerichte sandbox combineert daarmee vrijheid om te leren met duidelijke veiligheidsmaatregelen.
Meer tips zoals dit?
Schrijf je dan in voor onze nieuwsbrief!
De zeven lagen van een Azure Sandbox
Een veilige Azure Sandbox kan worden opgebouwd uit verschillende lagen. In dit voorbeeld bestaat de omgeving uit zeven belangrijke onderdelen:
- Subscription isolation
- Azure Policy
- Policy initiatives
- Custom RBAC-rollen
- Conditional role assignments
- Geen API keys
- Budget controls
Samen zorgen deze lagen ervoor dat gebruikers kunnen experimenteren binnen duidelijke grenzen.
Laag 1: Subscription isolation
De eerste laag bevindt zich op subscriptionniveau.
Je kunt de subscription zien als een appartementencomplex. Binnen deze subscription krijgt iedere gebruiker een eigen resource group. De resource group vormt als het ware het eigen appartement van de student.
De beheerder is eigenaar van het appartementencomplex, terwijl iedere gebruiker de benodigde toegang krijgt tot zijn of haar eigen appartement.
Door iedere gebruiker een eigen resource group te geven, blijven de resources van verschillende gebruikers van elkaar gescheiden.
Laag 2: Azure Policy
De tweede laag is Azure Policy. Een policy is een regel die wordt afgedwongen wanneer een identiteit een resource probeert aan te maken of te wijzigen.
Binnen een sandbox kun je hiermee bepalen welke resources wel en niet zijn toegestaan.
In deze omgeving kunnen bijvoorbeeld resources volledig worden geblokkeerd die niet relevant zijn voor het curriculum, zoals:
- virtual machines
- databases die niet nodig zijn voor het curriculum
- bepaalde networking-resources
- big data analytics-platformen
Andere resources kunnen juist wel worden toegestaan, maar beperkt. Zo kunnen gebruikers bijvoorbeeld een storage account aanmaken of een Azure AI Search-resource gebruiken die nodig is voor RAG-scenario’s.
Ook kunnen bepaalde modellen binnen Microsoft Foundry worden gedeployed, waarbij voor sommige modellen limieten voor het aantal tokens gelden.
Zo blijft de omgeving gericht op de leerdoelen, zonder gebruikers onbeperkte toegang te geven tot alle Azure-mogelijkheden.
Laag 3: Policy initiatives
Wanneer je meerdere Azure Policies gebruikt, kan het beheer daarvan al snel complex worden.
Daarom kun je policies bundelen in een policy initiative. Een initiative bevat meerdere policies die vervolgens gezamenlijk aan een resource group kunnen worden toegewezen.
In plaats van iedere policy afzonderlijk toe te wijzen, hoef je hierdoor alleen het initiative te beheren.
Wanneer je een policy binnen het initiative aanpast, wordt deze wijziging toegepast op alle resource groups waaraan het initiative is gekoppeld.
Dit maakt het eenvoudiger om dezelfde beveiligingsregels consequent toe te passen op alle sandboxomgevingen.
Laag 4: Custom RBAC-rollen
De vierde laag bestaat uit custom RBAC-rollen.
Voor de Azure Sandbox kan bijvoorbeeld een eigen rol worden aangemaakt: de Sandbox Resource Builder-rol.
Deze rol geeft gebruikers de mogelijkheid om resources binnen hun sandbox aan te maken, ermee te experimenteren en oplossingen te bouwen.
Tegelijkertijd krijgen ze geen rechten om belangrijke onderdelen van de omgeving te verwijderen. Zo kunnen ze bijvoorbeeld niet:
- de volledige resource group verwijderen
- het budget van de resource group verwijderen
- baseline-resources verwijderen
Op deze manier krijgen gebruikers voldoende vrijheid om te leren, zonder dat ze de volledige sandboxomgeving kunnen aanpassen of verwijderen.
Laag 5: Conditional role assignments
Sommige lessen en scenario’s vereisen dat gebruikers rollen kunnen toewijzen. Dat kan echter risico’s met zich meebrengen.
Daarom kunnen conditional role assignments worden gebruikt. Hierbij worden voorwaarden gekoppeld aan het toewijzen van bepaalde rollen.
Wanneer een gebruiker een roltoewijzing probeert uit te voeren, wordt gecontroleerd of deze actie is toegestaan. Is de rol niet toegestaan, dan wordt de actie geweigerd.
Een goedgekeurde roltoewijzing kan wel worden uitgevoerd. Dit kan bijvoorbeeld nodig zijn wanneer een service toegang moet krijgen tot een Azure AI Search-resource om een index aan te maken of een bestaande index te lezen.
Zo blijft het mogelijk om noodzakelijke oefeningen uit te voeren, zonder gebruikers onbeperkte mogelijkheden te geven om rechten toe te kennen.
Laag 6: Geen API keys
De zesde laag is het vermijden van API keys.
API keys kunnen uitlekken en wanneer een sleutel in handen komt van iemand die er misbruik van maakt, is het lastig om vast te stellen wie de sleutel daadwerkelijk gebruikt.
Daarom gebruikt de sandbox managed identities en Microsoft Entra ID in plaats van API keys.
Hierdoor is iedere actie en iedere aanroep gekoppeld aan een identiteit. Dat maakt het eenvoudiger om te bepalen wie welke actie uitvoert en sluit aan bij een veiligere manier van werken met Azure-resources.
Laag 7: Budget controls
De laatste laag is het budget.
In dit voorbeeld krijgt iedere resource group een budget van $200 aan Azure-tegoed. Om het verbruik inzichtelijk te houden, worden verschillende budgetalerts ingesteld.
Er zijn waarschuwingen bij:
- 50% van het budget
- 80% van het budget
- 90% van het budget
- 100% van het budget
Daarnaast is er een forecasting-alert. In totaal krijgt de gebruiker hiermee meerdere meldingen over het daadwerkelijke en verwachte verbruik.
Ook de beheerder ontvangt deze meldingen. Zo blijven de kosten transparant en kunnen gebruikers zich bewust worden van hoeveel hun experimenten daadwerkelijk kosten.
Hoe komen gebruikers in de Sandbox?
Een gebruiker krijgt toegang tot de omgeving via een Microsoft Entra guest account.
De gebruiker wordt uitgenodigd met het e-mailadres waarmee hij of zij zich heeft aangemeld. Na het accepteren van de uitnodiging krijgt de gebruiker toegang tot de subscription en de bijbehorende resource group.
Daarbij worden automatisch de verschillende beveiligingsmaatregelen toegepast. Denk aan:
- de policies
- het policy initiative
- de juiste roltoewijzingen
- de resource group
- het budget
- de benodigde baseline-resources
Wanneer bepaalde resources nodig zijn voor het curriculum, zoals Azure AI Search of een container registry, kunnen hiervoor specifieke rechten worden toegekend.
Zo krijgt iedere gebruiker een eigen omgeving waarin hij of zij zelfstandig kan experimenteren, terwijl de belangrijkste beveiligingsmaatregelen centraal worden beheerd.
Zelf een Azure Sandbox bouwen
Wil je zelf een vergelijkbare Azure Sandbox bouwen? Dan kun je de verschillende onderdelen geautomatiseerd aanmaken met bijvoorbeeld Bicep-files.
Daarmee kun je onder andere de volgende onderdelen definiëren:
- resources
- Azure Policies
- policy initiatives
- RBAC-rollen
- conditional role assignments
- budgetten
- budgetalerts
Een goede manier om te beginnen is met één resource group per gebruiker. Richt vervolgens een systeem voor budgetalerts in, zodat je inzicht houdt in de kosten per resource group.
Tot slot is het belangrijk om steeds uit te gaan van least privilege. Geef gebruikers alleen de rechten die ze daadwerkelijk nodig hebben voor de oefeningen en oplossingen die ze binnen de sandbox moeten bouwen.
Conclusie
Een Azure Sandbox draait om de balans tussen vrijheid en controle. Gebruikers moeten voldoende ruimte krijgen om Azure te ontdekken, maar tegelijkertijd mogen ze niet per ongeluk belangrijke resources verwijderen, onbeperkte kosten veroorzaken of onnodig veel rechten krijgen.
Door subscription isolation, Azure Policy, policy initiatives, custom RBAC-rollen, conditional role assignments, managed identities en budget controls te combineren, ontstaat een omgeving waarin gebruikers veilig en zelfstandig kunnen leren werken met Azure.
Een goed ingerichte sandbox kan daarom een belangrijke basis vormen voor hands-on leren.
Benieuwd wat dit voor jouw organisatie betekend?
Neem vrijblijvend contact met ons op en wij helpen je verder.