Policy driven governance: vangrails voor cloud

Met alle wijzigingen in het Azure-platform is het lastig geworden handmatig te toetsen op governance, Er bestaan daarom al zo’n 800 voorgedefinieerde policies in de Azure-omgeving. Daarnaast zijn er nog 2.360 extra policies beschikbaar die vanuit de community zijn aangedragen. Al deze policies vormen een mooie basis om te starten met de inrichting van jouw cloudomgeving. Maar omdat iedere cloudomgeving uniek is, zijn er daarnaast aanvullende policies nodig die beter aansluiten bij de governance van jouw organisatie.

Het principe achter de policy

In de wereld van compliancy geldt het comply or explain-principe. Vanuit dit gedachtegoed zet je met een set aan policies de juiste vangrails (guardrails) neer die de eindgebruiker en ontwikkelaar de vrijheid geeft om te bepalen hoe hij iets doet. De policies zetten dus vast hoe groot het speelveld is. Waar policies traditioneel gezien ingezet werden als 'je mag alleen dit', geven deze tegenwoordig juist aan 'je mag alleen niet dat'. Doordat je met policies naar een enabler-functie verschuift vanuit compliance, geef je de eindgebruiker en ontwikkelaar veel meer vrijheid.

Verschillende soorten en maten

In een draaiende cloudomgeving wijzigt er nog niets bij het toewijzen van een nieuwe policy. Deze policy wordt pas werkend wanneer je een nieuwe deployment uitrolt, ongeacht het type policy. Dit maakt het toepassen van een policy laagdrempelig. Ieder type policy heeft zijn eigen voor- en nadelen. Welk type je uitrolt, hangt af van de governance van de cloudomgeving van jouw organisatie.

Deny

Met een deny-policy specificeer je wat je als gebruiker niét mag doen binnen de IT-omgeving. Hiermee bepaal je als het ware het speelveld voor de gebruiker, zonder dat deze zijn vrijheid verliest. Neem als voorbeeld de Prevent public IP-based services. Hiermee geef je aan dat ontwikkelaars bepaalde diensten niet mogen benaderen vanaf het internet. Doen ontwikkelaars dit toch, dan worden zij tegengehouden vanuit de deny-policy.

Een nadeel van het gebruik van deny-policies zit ‘m in het klakkeloos overnemen van de bestaande set policies. Zonder een evaluatie van de bestaande policies loop je bij de volgende deployment de kans dat je je productieomgeving omvergooit. In dit geval blokkeren de bestaande deny-policies namelijk de nieuw uitgerolde policies.

Allow

De allow-policy is het meer traditionele type policy en specificeert juist wat wél mag. Het is als het ware de tegengestelde variant van een deny-policy. Een voorbeeld hiervan is allowed locations. Hiermee geef je aan in welke Azure-regio’s een ontwikkelaar iets mag uitrollen. Hiermee kun je er dus voor zorgen dat alle resources binnen Europa uitgerold worden, of juist bewust niet vanwege uitwijk. Op deze manier kun je regiospecifiek bepalen wat wel of niet mag.

Audit

Een audit-policy zet je in wanneer je enkel monitort of iets wel of niet mag. Zaken die niet mogen, worden gemarkeerd als niet compliant. De verantwoordelijkheid voor aanpassen ligt echter bij de gebruiker in plaats van bij compliance. Dit type policy wordt normaliter enkel toegepast in testomgevingen, om te zien of deze oplossing compliant is of niet. In de productieomgeving worden deze audit-policies omgezet naar deny-policies, zodat de uitrol geblokkeerd wordt.

Bij audit-policies is het van belang dat er een controle zit op de status van de non-compliant items. Als deze zaken niet verholpen worden, gaat dit later in het proces tegenwerken. De verantwoordelijkheden hiervoor moeten duidelijk zijn binnen de organisatie, zodat non-compliancies tijdig opgepakt worden. Deze verantwoordelijkheid ligt vaak bij het ontwikkelteam dat zich bezighoudt met de uitrol. Bij het werken in de cloud hoort namelijk een gezamenlijke verantwoordelijkheid voor cloudgovernance.

Deploy if not exist (DINE)

Met een DINE-policy voer je controle uit, waarbij je, in tegenstelling tot audit-policies, de benodigde aanpassingen wél doorvoert vanuit compliance. Wanneer de gebruiker zelf een bepaalde instelling, waarde of configuratie niet instelt, wordt dit voor hem gedaan, omdat dit verplicht is. Denk hierbij aan policies op het gebied van logging.

Het gevaar bij het gebruik van DINE-policies is dat je oplossing onbedoeld volledig verandert in een ander type oplossing. De cloudarchitect ontwerpt omgeving A en krijgt na deployment van alle DINE-policies uiteindelijk omgeving B. Ook kan een DINE-policy je architectuur zelf ondergraven. Zo kun je forceren dat een http-omgeving automatisch een https-omgeving wordt al verander je hiermee wel je website. Wanneer een policy zo’n wijziging maakt en er een probleem ontstaat in je omgeving, wordt er vaak eerst naar de policy gewezen als schuldige van de ongewenste situatie. Als je wil voorkomen dat je oplossing wordt aangepast, is een DINE-policy dus geen passende keuze.

Exemption op de regel

Zoals eerder benoemd, geldt in de compliancy-wereld het comply or explain-principe. De policies die je uitrolt in je cloudomgeving vallen onder comply. De exemptions die je maakt op je policies, vallen onder explain. Het is namelijk mogelijk een uitzondering op een policy te maken voor een bepaalde periode, of zelfs voor onbeperkte tijd. Zo kun je bijvoorbeeld de uitzondering hanteren dat de website gedurende één jaar op http draait, in plaats van https. De ontwikkelaar moet dan na een jaar wel letten op de termijnafloop van deze uitzondering en deze non-compliancy voor die tijd oplossen.

Policy driven cloud governance

Policies zorgen er dus voor dat je grip houdt op je cloudomgeving, ook in een steeds complexer wordend IT-landschap. Met de juiste set policies die past bij jouw organisatie zet je de kaders uit waarin gebruikers kunnen bewegen, zonder hen te limiteren in hun vrijheid. Ook geven de verschillende type policies je de mogelijkheid om de compliance-verantwoordelijkheid verspreid te beleggen in de organisatie. Zo maak je van compliance een business enabler!

Wil je meer weten over hoe je grip krijgt en houdt op je cloudomgeving? Bekijk dan het webinar On Point: Grip op cloud of lees het highlights-artikel.