Azure Security pt 4. – Identity & MFA

Active Directory vervangen voor Azure Active Directory

Na het lezen van deze post zul je denken, we moeten volledig standaardiseren op Azure Active Directory en we moeten afscheid nemen van onze on-premise Active Directory. Vanuit security oogpunt zou dit inderdaad een prima overweging zijn. Echter is dit heel erg afhankelijk van een aantal factoren. Waar wordt de zwaarste workload uitgevoerd? Hoe groot is de omgeving? Hoe wil je onderdelen in een netwerk koppelen? Hoewel InTune best wel wat mogelijkheden geeft om enduser devices te managen, het verbleekt nog bij de mogelijkheden van Group Policy. Azure AD ondersteunt geen LDAP, NTLM en Kerberos. Wederom vanuit security-oogpunt een win-situatie. Maar heel vaak wordt er nog gewerkt met legacy toepassingen of hardware die alleen over deze protocollen kunnen communiceren. Azure Active Directory is een 'platte' directory structuur. Ben je gewent (of genoodzaakt) om met Forests of Organisation Units te werken dan is ook dat geen optie in Azure Active Directory. Dus om met het slechte nieuws te beginnen, Azure Active Directory is (nog) geen 1-op-1 vervanger voor on-premise Active Directory. Gelukkig bestaat er wel de mogelijkheid om informatie zoals users van beide 'directories' veilig met elkaar te synchroniseren. Op deze manier kun je er bijvoorbeeld voor kiezen om je on-premise omgeving te blijven managen met Active Directory en om je cloud-oplossingen te managen met Azure Active Directory. Je hebt dan twee directories (met gedeeltelijk dezelfde objecten) om te beheren, maar dit geeft ook de mogelijkheid om on-premise met legacy oplossingen te werken en om online gemakkelijk integraties uit te voeren via Azure Active Directory en om hierbij eveneens gebruik te kunnen maken van alle voordelen en security-features van Azure Active Directory. Zoals Conditional Access welke we in de vorige post besproken hebben. Maar ook:

MFA – Multi Factor Authentication

Inloggen doen we traditioneel via een gebruikersnaam en een wachtwoord. Het advies voor maximale beveiliging is om te authenticeren via iets dat je 'bent' (biometrische authenticatie) OF door gebruik te maken van een combinatie van:

• Iets wat je 'weet', zoals een wachtwoord.
• Iets dat je 'hebt', zoals een authenticator met een unieke code.

Authenticeren met een wachtwoord alleen is tegenwoordig niet meer afdoende. Uiteraard kunnen lange en sterke wachtwoorden afgedwongen worden. Deze zijn ook ontzettend veilig tot het moment dat ze verloren worden (zoals door het noteren op een Post-It). Met een wachtwoord leg je altijd de veiligheid van de identity in handen van de natuurlijke persoon welke deze identity representeert. En keer op keer is al gebleken dat dit niet afdoende is. Biometrische authenticatie maakt hierin een belangrijke stap voorwaarts (maar is minder makkelijk te veranderen indien nodig). De belangrijkste stap in de beveiliging van een identity is echter door MFA hieraan toe te voegen. Zelfs wanneer bijvoorbeeld een wachtwoord verloren wordt dan nog kan deze zonder de unieke MFA code (iets waar de originele identiy over beschikt) niet inloggen.

Multi Factor Authenticatie noemen we dan ook vaak '2 Factor Authenticatie' ofwel '2FA'.

Multi Factor Authentication (hierna gewoon MFA genoemd) is aanwezig binnen bijna alle web-apps en cloud-based diensten. Soms wordt je verplicht om MFA in te stellen en soms heb je zelf de keuze om dit wel of niet te doen. Wanneer je weleens een MFA ingesteld hebt dan heb je vaak de keuze om dit te doen via een zogenaamde 'App' op je telefoon. In sommige gevallen kun je ook nog SMS, e-mail en bellen als mogelijkheid gebruiken om de MFA code te ontvangen. Maar het gebruiken van een app is de veiligste en snelste methode. De bekendste apps zijn de Microsoft Authenticator en de Google Authenticator. Er zijn overigens nog veel meer apps. De app die je gebruikt maakt overigens niet uit. De werking is vrijwel altijd hetzelfde. Scan een QR code, ontvang de code in de app, vul deze code in op de site en de MFA koppeling is gereed. Zo ook bij Microsoft. Microsoft kent een hele degelijke, goed te beheren MFA oplossing voor alle gebruikers binnen Azure Active Directory. Het gebruik van MFA kan afgedwongen worden of op voorkeur van de gebruiker worden ingesteld.

Het configureren van de globale Multi Factor Authenticatie Settings binnen Azure Active Directory kan via een speciaal ontworpen pane (https://portal.azure.com/#view/Microsoft_AAD_IAM/MultifactorAuthenticationMenuBlade/~/GettingStarted).

Hier kunnen we zaken instellen als 'Account Lockout' policy, het blokken en unblocken van users, uploaden en downloaden van OAUTH tokens en het openstellen van een 'One-time bypass' indien we dat willen.

Het afdwingen van MFA wordt idealiter gedaan via Conditional Access (zie vorige post).

Hier kunnen we exact aangeven welke gebruikers (groepen) wanneer wel en wanneer niet moeten authentiseren met MFA:

Wanneer je ervoor kiest om geen gebruik te maken van Conditional Access maar toch MFA op 1-of-meerdere gebruikers in te stellen dan kun je het oude MFA panel benaderen via Azure Active Directory – Users. Hier hebben we de mogelijkheid om te kiezen voor 'Per-user MFA':

In de pane die opent kun je MFA per-user instellen. De settings die ingesteld zijn binnen 'Conditional Access' hebben geen invloed op de status die weergegeven is binnen de per-user functie. Wanneer MFA op een user wordt ingeschakeld in de per-user functie en MFA zou voor die user disabled zijn op basis van de Conditional Access Policy dan nog zal de user gevraagd worden om MFA. Voor eenduidigheid en het dynamisch afdwingen van MFA is dus de voorkeur om alleen Conditional Access te gebruiken.

Wanneer MFA enabled is kan een Azure Active Directory beheerder deze gemakkelijk resetten indien dit nodig is (bij b.v. het verlies van een telefoon):

Een gebruiker heeft overigens altijd toegang tot het beheren van zijn security-principals via het Self-Service portal (https://mysignins.microsoft.com/security-info) waar deze indien gewenst authenticators en MFA methodes kan toevoegen (indien deze vanuit de corporate policy worden toegestaan):

En wanneer dan uiteindelijk MFA is ingesteld, en een gebruiker logt in op een cloud-dienst die via zijn Azure identity benaderd kan worden dan zal deze, na het invoeren van een valide wachtwoord, doorgestuurd worden van onderstaande scherm om zijn MFA code in te voeren of om de goedkeuring te geven via de Microsoft Authenticator app. Wanneer de MFA code is opgegeven en correct is, is de gebruiker succesvol ingelogd.

MFA is dus een grote stap voorwaarts omtrent de beveiliging van online identies en binnen Microsoft Azure Active Directory gemakkelijk te implementeren en beheren. De mogelijkheid om Azure MFA te gebruiken bevindt zich binnen alle Microsoft subscriptions. Wil je echter dynamisch MFA gebruiken in combinatie met Conditional Access dan kan dit met AD Premium P1, AD Premium P2, Microsoft 365 Business Premium, Microsoft 365 E3 en Microsoft 365 E5.

Azure RBAC - Azure Role-Based Access Control

RBAC, ofwel 'Role-Based Access Control' is een autorisatiesysteem op basis van de 'Azure Resource Manager' en helpt bij het toegangsbeheer van Azure-resources. Het voorkomt namelijk dat toegang verleend wordt op basis van individuele identies of groepen. Feitelijk is het 'Role-Based Access Control' principe een grote verzameling van rollen (beheerd door Microsoft) welke bepaalde rechten geven op bepaalde resources.

Vaak wordt RBAC gebruikt voor het beperken van netwerktoegang op basis van de rollen van individuen binnen een organisatie. Het geeft gebruikers toegang tot de informatie en resources welke ze nodig hebben om hun taak uit te voeren. RBAC voorkomt aan de andere kant uiteraard dat er toegang verkregen wordt tot resources waar het individu (de identity) geen toegang toe mag hebben. Tot op heden lijkt RBAC een fancy term voor simpelweg een 'rechtenstructuur' aangezien hier ook de gebruikersrol een grote 'rol' (phun intended) speelt. De volgende identities (security principals) kunnen namelijk toegang nodig hebben tot een specifieke resource:

Er kan toegang gegeven worden op verschillende niveaus (scope):

En de rol van de identity bepaald hoe toegang verkregen wordt. Zo zijn er verschillende rollen zoals:

Dit zijn niet de enige rollen. Azure kent meer dan 150 built-in roles die allemaal hun eigen rechten en mogelijkheden kennen. Daarnaast kun je zelf nog custom-roles aanmaken als dit nodig mocht zijn. De 4 hierboven genoemde rollen zijn overigens wel 4 fundamentele rollen:

• Owner – Heeft volledige toegang op de scope en het recht om toegang te delegeren aan anderen.
• Contributor – Heeft eveneens volledige rechten op de scope maar kan geen toegang delegeren.
• Reader – Kan Azure resources bekijken maar niet aanpassen.
• User Access Administrator – Heeft het recht om toegang tot resources te managen en te delegeren.

Zoals de naam 'Role-Based Access Contol' al doet vermoeden draait het bij RBAC om 'rollen. Een 'role' wordt gegeven aan een identity (security principal) en geeft toegang tot een bepaalde scope. Bij RBAC telt dat 'de maximale rechten' gaan voor 'de restrictievere rechten'. Dus wanneer een gebruiker vanuit een rol het recht heeft om een resource te beheren en vanuit een andere rol om de resource alleen te lezen dan zal de gebruiker uiteindelijk toch de resource kunnen beheren.

RBAC is geen functie die separaat in te richten is. RBAC is aanwezig binnen ieder Azure abonnement en Microsoft adviseert om alleen toegang te verlenen op basis van de RBAC rollen. Dit bevorderd de snelheid en het beheer.

PIM - Privileged Identity Management

Privileged Identity Management (PIM) is een Azure Active Directory service waarmee eveneens de toegang tot belangrijke Azure resources beheerd, gecontroleerd en bewaakt kan worden. In die zin lijkt PIM heel erg op RBAC. Toch is Privileged Identity Management compleet anders en geeft het meer vrijheid en dynamiek aan het beheren van toegang. Vaak wordt PIM ingezet om toegang te beheren en loggen van verhoogde rechten.

Je kunt PIM zien als een extra beveiligingslaag bovenop Azure Resources, Azure Roles en Azure Groups.

Als je PIM gebruikt om de toegang tot bronnen te beheren dan maak je hiervoor een zogenaamde PIM 'assignment' (toewijzing). PIM ondersteunt twee verschillende soorten assignments, namelijk:

• Eligible (in aanmerking komend).
• Active (Actief).

Beide kunnen permanent of tijdelijk zijn:

PIM wordt vaak gebruikt om toegang met hogere rechten te beveiligen. Wanneer deze toegang 'Eligible' is dan mag deze worden goedgekeurd nadat de gebruiker die de rechten nodig heeft de toegang heeft aangevraagd. Dit goedkeuren is een handmatige actie. Wanneer de toewijzing 'Active' is dan is er geen gebruikersinteractie voor nodig en kan de gebruiker die deze rechten nodig heeft de rechten activeren/gebruiken. Zowel Eligible en Active kunnen permanent zijn of tijdelijk. Een paar voorbeelden:

• Een ingehuurde werknemer gaat voor 6 maanden aan de slag en heeft (verhoogde) toegang nodig tot bepaalde resources. Deze toegang is nodig om het dagelijkse werk te kunnen doen.
  PIM: Active – Fixed Timeframe
• Een andere ingehuurde werknemer gaat 3 maanden aan de slag en heeft sporadisch verhoogde rechten nodig.
  PIM: Eligible – Fixed Timeframe
• Een interne werknemer heeft voor zijn werkzaamheden op wekelijkse basis verhoogde rechten nodig.
  PIM: Eligible - Permanent
• Een beheerder heeft voor zijn werkzaamheden op dagelijkse basis verhoogde rechten nodig.
  PIM: Active – Permanent

Door het inzetten van PIM gebeurt het uitgeven van rechten dus heel gecontroleerd en dynamisch. Dit heeft o.a. de volgende voordelen:

• Verhoogde rechten alleen op basis van aanvraag.
• Het verwijderen van (verhoogde) rechten kan niet meer vergeten worden.
• Zeer gecontroleerd uitgeven van (verhoogde) rechten.
• Betere logging en controle op de uitgegeven rechten.
• Vastlegging d.m.v. requests.

Om gebruik te kunnen maken van Privileged Access Management is minimaal een Azure AD Premium P2 licentie vereist. Wanneer PIM actief is ziet dit er als volgt uit in de Azure Portal: