In de komende blog-posts neem ik jullie graag mee op reis in de wereld van Azure en dan met name alle mooie security-oplossingen die Azure vandaag-de-dag te bieden heeft. Azure, AWS en Google zijn zeer volwassen IaaS (Infrastructure as a Service) platformen. En wanneer je een bepaalde infrastructuur biedt kun je er niet buiten, om daar de nodige security-controls op aan te bieden en om best-practices door te voeren. Daar hebben we meteen het grote voordeel te pakken. Veel best-practices zijn al standaard doorgevoerd en moeten namelijk eerst worden uitgeschakeld voor de setting onveilig wordt. Dat betekent echter niet dat een IaaS oplossing van nature een veilig product (of veilige omgeving) is. Naast het feit dat settings backwards-compatible moeten zijn en dus bewust “minder veilig” ingesteld kunnen worden, zijn ook de default settings niet optimaal. De aanbieder probeert namelijk een gezonde mix te vinden tussen gemak en security en dan worden er altijd compromissen gesloten.

Waarom Azure?

Hoewel elke grote aanbieder mooie security-controls aanbiedt en de ene op een specifiek vlak weer beter is dan de ander, beperk ik mezelf in de komende posts op Microsoft Azure. Ik denk dat Microsoft Azure (en daarmee uiteraard ook Microsoft 365) de laatste jaren veel mooie oplossingen ontwikkeld en geprofessionaliseerd heeft. Daarnaast wordt Microsoft Azure ontzettend veel gebruikt in Nederland en door onze achterban. In de komende posts bekijken we diverse onderwerpen en geven we diverse tips en achtergrondinformatie over dat onderwerp. Ik zal proberen de posts “behapbaar” te houden en toch informatie te geven waar je meteen je voordeel mee kunt doen. Is dat alle informatie? Nee, dat is helaas met de mogelijkheden van Microsoft Azure een hele opgave en feitelijk een grote cursus. Dus, wil je weten hoe bepaalde zaken toepasbaar zijn op jou omgeving, dan raadt ik je aan om daar verder onderzoek naar te doen. Het internet is een fantastische bron van informatie en ook worden er op dit gebiedt veel cursussen aangeboden. Ook hoop ik dat deze posts ervoor zorgen dat de “beginnersangst” wordt weggenomen en je aan de slag kunt met de eerste verbeteringen. Het mooiste is uiteraard wanneer je een oefenomgeving hebt waarin je eerst kunt proberen voordat je het e.e.a. probeert binnen een productieomgeving.

Begrippen

Voor we (in de volgende post) echt van start gaan denk ik dat het goed is om eerst een aantal begrippen te verduidelijken. 

De volgende opbouw vertelt globaal de opzet van een Tenant. In de praktijk kan dit er als volgt uitzien:

Ik ga er in deze serie vanuit dat de structuur / architectuur van het landschap bekend is. Dit is uiteraard essentieel om de juiste keuzes te kunnen maken. Misschien is de architectuur een “Build & Adjust” principe waarbij deze wordt aangepast op basis van nieuwe bouwblokken en wensen. Of misschien gebruik je een bestaande structuur die prima past binnen het gestelde groeiscenario. Welk principe je hanteert maakt niets uit, maar het is wel belangrijk om in kaart te brengen hoe het landschap eruit ziet en dat changes netjes worden gedocumenteerd. We zien vaak dat on-premise omgevingen door de jaren heen wat “vervuilt” zijn. Door het hanteren van een strakke infrastructuur en de daarbij horende regels voorkom je dat dit gaat gebeuren binnen je virtuele infrastructuur.

Azure Tenant

Een Azure Tenant verwijst naar een enkele instantie van Azure Active Directory (Azure AD). Azure AD is een belangrijk onderdeel van het cloudplatform van Microsoft. Ditomdat het één plek biedt voor het beheer van gebruikers, groepen en de machtigingen die ze hebben met betrekking tot toepassingen die zijn gepubliceerd in Azure AD. Zie een Tenant als het hoogste niveau waarin alle onderstaande onderdelen aangemaakt en beheerd kunnen worden op basis van de Azure AD. Azure Tenants zijn wereldwijd uniek en eindigen altijd op het 'onmicrosoft.com' domein. Veel bedrijven hebben slechts 1 tenant (b.v. hetwaterschapshuis.onmicrosoft.com) maar er zijn ook bedrijven die meerdere tenants hebben. Een tenant heeft ook een uniek 'Tenant-ID' in de vorm van een UUID/GUID.

Management Group

Een Azure Management Group biedt de organisatie een manier om toegang, naleving en beleid voor hun subscriptions binnen de Tenant te beheren. Deze containers bieden een bereik boven de subscriptions, waardoor een overnameniveau (inheritance) kan worden toegepast op onderliggende groepen en subscriptions. Dit maakt het mogelijk om een specifieke onderdeel zoals RBAC (role-based access control) te configureren en te standaardiseren voor alle subscriptions in plaats van deze afzonderlijk toe te wijzen.

In het kort:

  • Een subscription kan maar tot één management group behoren.
  • Management groups kunnen “nested” zijn, maar maximaal zes niveaus diep.
  • Er kunnen maximaal 10.000 management groups aangemaakt worden binnen één tenant.
  • Er is één root management group op het hoogste niveau, deze kan niet worden verwijderd.
  • Nieuwe subscriptions worden automatisch onder de root management group geplaatst.
  • Elke toegang die aan een management group is toegewezen wordt toegepast op alle bronnen en onderliggende management groups (inheritance).

Subscription

Een subscription (abonnement) is feitelijk een logische container waarin een willekeurig aantal resources (zoals virtuele machines, web-apps, opslagaccounts, enz.) kan worden ondergebracht. Een Subscription is in essentie een belangrijk item m.b.t. de kosten. Subscriptions worden separaat gefactureerd en elke subscriptie kent dus zijn eigen kostenplaats en inzicht tot de gemaakt kosten (verbruikte resources). Een abonnement kan altijd maar aan één Azure AD-tenant worden gekoppeld. Het is wel mogelijk om gebruikers van buiten de tenant toegang te verlenen tot resources binnen een subscription. Ook kunnen subscriptions overgezet worden naar andere Tenants maar dan nog zijn ze altijd slechts onderdeel van 1 tenant. Subscriptions hebben zowel een weergavenaam (die je kunt wijzigen) als een abonnements-ID (UUID/GUID) die je niet kunt wijzigen.

Resource Group

Een resource group is iets anders dan een management group. Een management group kan alleen andere management groups en subscriptions bevatten en een resource group bevat de werkelijke resources. Een resource group is een logische container om resources onder te brengen en te managen. Ook kun je de toegang binnen een resource group regelen op het niveau van de resource group. Ook hier speelt inheritance weer een belangrijke rol. Wanneer een resource binnen een resource group is aangemaakt kan deze niet altijd meer verplaatst worden naar een andere resource group. Je kunt maximaal 800 resources van hetzelfde type aanmaken binnen een resource group.

Resource

Dit is de feitelijke resource, ofwel het product dat gebruikt wordt. Dit kan een SQL database, virtuele machine, web-app of een andere resource zijn. Dit is dus uiteindelijk het onderdeel dat je “gebruikt” en het onderdeel welke gefactureerd wordt.

Geografische verdeling

Azure verschilt van de andere grote cloudproviders in de benadering van het leveren van services dicht bij de klant. Dit betekent dat je tijdens het aanmaken van een resource vaak kunt kiezen voor de locatie waar deze gehost moet worden. Je kiest een regio en een regio is een groep datacenters die samen een implementatielocatie vormen voor je workloads. Een geografie, zoals deze betrekking heeft op Azure, kan worden gebruikt om een ​​specifieke markt te beschrijven, meestal een land (Australië), maar soms ook een geografische regio (Azië, Europa). Normaal gesproken bevinden zich binnen een geografie twee regio's die worden gekoppeld om klanten hoge beschikbaarheidsopties te bieden. Er zijn een paar speciale regio's die niet voor iedereen toegankelijk zijn - Amerikaanse regeringsregio's, de hele Duitse geografie en China. Wanneer je ervoor kiest om gegevens of services tussen regio’s te repliceren dan betaal je een verhoogd tarief voor de gegevensoverdracht tussen regio's en/of dubbele hostingkosten in de secundaire regio. Sommige services, zoals Azure Storage en Azure SQL Database, bieden “geografisch redundante” opties waarbij je extra kosten betaalt om de gegevens naar de secundaire regio te laten repliceren. In andere gevallen moet je je eigen replicatieaanpak ontwerpen op basis van de applicatie en de bijbehorende hostinginfrastructuur. Wanneer je eenmaal een service naar een regio hebt geïmplementeerd, kunt je deze niet meer verplaatsen. Om de primaire omgeving naar een andere regio te verplaatsen moet deze dus volledig opnieuw worden ingericht.

Standaarden

Het is belangrijk om al vroegtijdig diverse standaarden te ontwikkelen. Ga je gebruik maken van een ontwikkelomgeving? Hoe worden omgevingen ingericht (wat zijn de basis bouwblokken van elke omgeving). Hoe wil je omgaan met rechten en machtigingen? En hoe ziet de naamgeving van alle objecten eruit. Het doorvoeren van een generieke standaard zorgt voor eenduidigheid en herkenning binnen de infrastructuur en ook op de factuur. Microsoft geeft op deze pagina: https://docs.microsoft.com/nl-nl/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming(externe link) en op deze pagina https://docs.microsoft.com/nl-nl/azure/cloud-adoption-framework/ready/azure-best-practices/resource-abbreviations(externe link) een aantal voorbeelden van goeie standaarden. Implementeer deze vroegtijdig en zorg dat deze waar mogelijk worden doorgevoerd.

Ten slotte

Deze introductiepost laat al een klein beetje zien hoe diep een dienst als Azure gaat en dus ook hoe uitgebreid de security-controls van deze dienst zijn. En dan hebben we het nu nog niet eens over Office 365 gehad. In de komende posts zal ik zowel voor Offcice365 als voor Azure diverse tips en informatie delen. Maar de belangrijkste boodschap van deze post is dat voor dat je aan “security” kunt denken, je er eerst voor moet zorgen dat “de basis” op orde is. Zorg voor een duidelijke architectuur, opzet en standaardisering. Zorg er bijvoorbeeld voor dat de basis altijd in Europa staat en dat de rechten tussen de verschillende onderdelen juist geregeld is. Wanneer dat op orde is dan kunnen we alles alleen nog maar mooier maken. En dat is wat we gaan doen. Dus heel graag, tot de volgende post!

Jarno Baselier