Azure Security pt 3. – Conditional Access

Hoe werkt Conditional Access:

In de basis is Conditional Access gestoeld op 2 verschillende onderdelen:

• Het controleren van policies
• Het controleren en afdwingen van security controls

Een conditie kan van alles zijn, denk aan o.a.:

• Gebruikers
• Groepen
• Cloud apps
• Device platforms (OSen)
• Locaties
• Client apps

Etc.

Onder controls verstaan we de inlogmethode die gehanteerd moet worden (of juist niet). We kennen zogenaamde “Grant Controls” die de toegang toestaan wanneer gebruik wordt gemaakt van een bepaalde methode. En we kennen ook “Session Controls” die van toepassing zijn op de actieve sessie. Laten we eens in de praktijk gaan kijken hoe dit eruit ziet.

We vinden “Conditional Access” binnen de Azure portal onder “Azure AD Conditional Access” (https://portal.azure.com/#view/Microsoft_AAD_IAM/ConditionalAccessBlade/~/Policies).

Het hoofditem aan de linkerkant zijn de policies. Wanneer we een nieuwe policy maken zijn er een aantal stappen / velden die we moeten doorlopen. Allereerst moeten we de policy een naam geven. En daarna gaan we de policy finetunen door conditions en controls toe te voegen. Binnen Conditional Access zijn deze verdeeld over 4 verschillende onderdelen:

We hebben:

1. Users or Workload identifiers
2. Cloud apps or actions
3. Conditions
4. Access controls

Users or Workload identifiers

Hier specificeren we expliciet voor welke gebruikers deze policy van toepassing is. We kunnen hier simpelweg kiezen voor alle gebruikers, individuele gebruikers, groepen, guest & external users, directory roles en service principals (Workload identities). En uiteraard kunnen we hier ook de nodige exclusions maken. Zo kunnen we een policy maken voor alle externe en interne gebruikers m.u.v. de beheerders.

Cloud apps or actions

Deze volgende optie is om te bepalen op welke cloud-apps deze policy van toepassing is. We kunnen hier kiezen voor alle cloud-apps die aanwezig zijn binnen Azure, specifieke apps en we kunnen hier tegenwoordig ook kiezen voor specifieke gebruikersacties zoals het registreren of joinen van devices. Een andere nieuwe feature is dat we de policy ook kunnen toepassen op een authentication context. Deze authentication context kan worden gebruikt om gegevens en acties in toepassingen verder te beveiligen. Deze toepassingen kunnen eigen toepassingen zijn, aangepaste LOB-toepassingen (Line-Of-Business), toepassingen zoals SharePoint of toepassingen die worden beveiligd door Microsoft Defender for Cloud Apps. Een organisatie kan bijvoorbeeld bestanden bewaren op SharePoint sites zoals het lunchmenu en de notulen van een vergadering. Iedereen heeft mogelijk toegang tot de lunchmenusite, maar gebruikers die toegang hebben tot de notulen, moeten mogelijk toegang krijgen vanaf een beheerd apparaat en akkoord gaan met specifieke gebruiksvoorwaarden.

Kortom, met deze actie bepalen we feitelijk de toepasbaarheid van de policy:

Conditions

Onder “conditions” gaan we bepalen aan welke condities de toegang moet voldoen. We hebben hier de volgende opties:

• User risk level: Azure AD bepaald per gebruiker een “risk level”. Hier kunnen we bepalen v.a. welk risk level deze policy wordt toegepast (low, medium & high).
• Sign-in risk level: Net zoals bij het user risk level wordt door azure een risk level gegeven aan het sign-in risico. Wordt er b.v. ongewoon gedrag gemeten dan kunnen we ervoor kiezen om deze policy te activeren.
• Device platforms: Hier kiezen we de device platforms zoals Windows, Android, IOS etc. We kunnen er b.v. voor kiezen om alleen een Windows policy te maken.
• Locations: Hier kunnen we ervoor kiezen om een policy te activeren wanneer wordt ingelogd v.a. een bepaalde locatie (of juist niet). Deze locaties kun je aanmaken binnen conditional access. Hier komen we zo nog even op terug.
• Client apps: Hier kunnen we ervoor kiezen om de policy wel of niet te activeren bij het gebruik van bepaalde client applicaties zoals b.v. bij modern of legacy authentication clients.
• Filters for devices:Tenslotte kunnen we nog een filterrule maken voor specifieke devices. We kunnen er dus voor kiezen om de policy juist wel of niet toe te passen op Dell machines. Deze filters geven veel mogelijkheden om devices en dus policies te differentiëren.

Access controls

Onder de access controls bepalen we vervolgens of de toegang wel of niet verleend mag worden en welke security controls dan verplicht zijn. Zo kunnen we ervoor kiezen om de toegang bij een match toe te staan wanneer MFA gebruikt wordt door middel van de authenticator:

En datzelfde kunnen we ook session-based doen. Hier kunnen we er dus voor kiezen om de sessie periodiek opnieuw te authenticeren:

En tenslotte vinden we onderaan een zeer belangrijke optie, namelijk de opties van de policy. Willen we deze inschakelen, uitschakelen of alleen in “report-only” mode plaatsen. Bij Report-only mode worden alle acties gelogd (indien een logger geactiveerd is, maar daarover later meer). Op deze manier kun je kijken wat de policy zou doen indien deze ingeschakeld was. Wanneer dit alles bepaald is kunnen we de policy opslaan:

Naast de polcies vinden we aan de rechterkant nog meer belangrijke opties. Denk hierbij aan de “named locations” waarbij we de eerder genoemde locaties kunnen aanmaken op basis van IP of geografische zone. Je kunt dus zelf bepaalde IP adressen uitsluiten van conditional access (dit wordt vaak gebruikt binnen het interne bedrijfsnetwerk) of je kunt ervoor kiezen om een policy alleen te activeren wanneer een verzoek afkomstig is v.a. het buitenland of een specifiek land.

Ook kunnen we hier custom authentication contexts maken, custom controls en nog meer zaken die we in een conditional access policy kunnen gebruiken.

Hoe start je met het bouwen van Conditional Access Policies?

Maar hoe begin je nu met het verzinnen en maken van alle policies? Uiteraard is het raadzaam om de policies aan te maken in “reporting” mode en om deze pas na evaluatie (en eventuele bijsturing) in te schakelen. Daarnaast moet je er altijd rekening mee houden dat je jezelf niet uitsluit. Dus nadat de “reporting-fase” voorbij is maak je voor de POC (proof-of-concept) periode een expliciete whitelisting policy dat jij in deze periode geen conditional access afgedwongen krijgt. Pas na de POC periode kun je deze rule volledig verwijderen. Daarnaast is het goed om te weten dat “blocking” altijd zwaarder weegt dan “whitelisting”. Dus heb je meerdere polcies en een policy zorgt ervoor dat je geblokkeerd wordt terwijl de andere je expliciet toelaat dan nog zal het eindresultaat zijn dat je geblokkeerd bent.

En daarna is het tijd om te kijken naar een aantal verschillende zaken binnen de organisatie:

• Wat is de rol van externe gebruikers?
• Wat moet Conditional Access doen op het interne netwerk?
• Welke groepen moeten op basis van bepaalde voorwaarden anders behandeld worden? Kortom, wat zijn de uitzonderingen?
• Kun je werken met 1 global basis policy?
• Breng in kaart wat voor soorten authenticatiemethoden gebruikt worden en of deze een rol spelen in de toegang.
• Is MFA al ingeregeld? Wat is de rol van MFA?

Het is dus belangrijk om te kijken hoe de interne organisatiestructuur eruit ziet. Wat je als beheerder en als organisatie graag wilt en hoe je dat in gaat richten en gaat handhaven. Zorg ervoor dat je in gesprek gaat met de organisatie en teken eerst alles goed uit op papier alvorens je gaat bouwen. Hanteer ook duidelijke titels zodat je meteen weet wat de functie van een policy is. Probeer ook het aantal policies zo klein mogelijk te houden. Want hoe minder policies des te makkelijker alles te monitoren en begrijpen is. Zorg er ook voor dat je geen verschillende doelen combineert in een policy. Dit komt de duidelijkheid niet ten goede. Leg de policies duidelijk vast in een draaiboek die gekoppeld is aan de architectuur. Maak indien mogelijk ook een architectuurplaat van de policies zodat het ook voor niet-beheerders (of nieuwe beheerders) meteen duidelijk is welke regels voor toegang worden afgedwongen. Dus in het kort:

• Maak een PVA (plan van aanpak) samen met de business/organisatie.
• Breng alles eerst in kaart en weet wat er is en wat er beschermd moet worden.
• Maak de polcies aan in “reporting mode” en zorg ervoor dat je jezelf ook na de reporting periode niet uitsluit.
• Maak niet teveel policies maar voorkom altijd het combineren van verschillende doelen in 1 policy.
• Documenteer alles goed.

Tenslotte is het goed om al je regels te testen. Binnen de “Conditional Access” policy feature kunnen we gebruik maken van een “What If” analyse. Deze analyse geeft ons een uitkomt op basis van de aanwezige policy’s nadat we een aantal voorwaarden hebben ingevuld.

Conditional Access Aanbevelingen:

Uiteraard heb ik nog wel een aantal aanbevelingen welke altijd het overwegen waard zijn. Denk b.v. eens aan het volgende:

1. Zorg ervoor dat er security information registration plaatsvindt van interne gebruikers. Op deze manier wordt vastgelegd wanneer gebruikers aanpassingen maken aan hun security context.
   
   
    
2. Blokkeer, indien mogelijk “legacy authentication”. Dit zorgt ervoor dat toegang alleen verkregen wordt wanneer “modern authentication” gebruikt wordt. Indien er geen legacy applications of devices zijn zou het afdwingen van deze policy geen probleem moeten zijn en de veiligheid een heel stuk verhogen.
   
   
    
3. Dwing MFA af bij privileged users en gevoelige applicaties. MFA zorgt voor een dubbele authenticatielaag en is veel veiliger dan “alleen een wachtwoord”. Daarom is het aan te raden om MFA altijd af te dwingen. Maar als dat niet nodig is zorg dan minimaal dat alle gebruikers met verhoogde rechten MFA moeten gebruiken en dan eveneens toegang tot gevoelige applicaties alleen mogelijk is in combinatie met MFA.
   
   
    
4. Zorg voor een controle op het gebruikte device. Zorg er bijvoorbeeld voor dat alleen devices die als “compliant” aangemerkt worden toegang kunnen krijgen.
   
   
    
5. Maak een regel die toegang v.a. specifieke landen blokkeert indien dit nodig is. Hiervoor dien je eveneens de “locations” optie te gebruiken om deze landen aan te maken en te definiëren in een “named list”.
6. Blokkeer risky logins altijd met MFA

Voorbeeld policy:

Laten we eens een voorbeeld policy gaan maken. We pakken hierbij als voorbeeld de laatst genoemde policy uit het vorige hoofdstuk, de “risky logins”. Een goede regel om te hebben is dat wanneer de sign-in met een “medium” (of hoger) risico berekend wordt dat dan altijd om een MFA verificatie gevraagd word. Deze ziet er dan per stap als volgt uit:

• Users or workload identities: All users.
• Cloud apps or actions: All cloud apps.
• Conditions: Sign-in level: Medium.
• Access controls: Grant – Grant Access – Require multifactor authentication.

Je kunt ervoor kiezen om bij hoge (gedocumenteerde) uitzondering een user of cloud-app van deze policy te excluden indien dit nodig is.