Wereldgebeurtenissen sinds maart 2020 hebben een van de belangrijkste voordelen van Office 365 en op de cloud gebaseerde SaaS-services in het algemeen benadrukt: ze zijn altijd en overal beschikbaar, op elk apparaat. Terwijl de wereld gedwongen was om vanuit huis te werken, konden Office 365-apps zoals Teams, Outlook, SharePoint en OneDrive eenvoudig worden geopend buiten het traditionele bedrijfsnetwerk, zelfs op niet-bedrijfsapparaten. In feite hebben de meeste Office 365- en Microsoft 365-abonnementen gebruikerslicenties om hun apps op maximaal vijf apparaten te installeren en te gebruiken.

Een van uw belangrijkste zorgen als gevolg hiervan kan zijn de preventie van gegevensverlies. Zo kan een gebruiker standaard authenticeren bij zijn bedrijfs-OneDrive of mailbox op een persoonlijk apparaat zonder enige beperkingen op de mogelijkheid om alle bestanden en e-mails die in die service zijn gehost te synchroniseren. Wat gebeurt er met lokale kopieën van gegevens wanneer die gebruiker de organisatie verlaat?

Azure Active Directory Conditional Access kan beheerders weer in controle brengen. Onderdeel van de Azure Active Directory Premium P1-licentie, met Conditional Access kunt u de voorwaarden bepalen waaronder een gebruiker toegang krijgt tot Azure AD-resources of geblokkeerd wordt. Zelfs als u toegang verleent, kunt u extra maatregelen afdwingen, zoals reageren op een prompt voor multi-factor authenticatie (MFA), of hoe lang het duurt voordat ze opnieuw moeten inloggen.

Hoe Conditional Access bedrijfsapparaten identificeert

In ons scenario zullen we Conditional Access gebruiken om gebruikers alleen op bedrijfsapparaten te laten aanmelden bij Office 365. Dit doen we op basis van de apparaatstatus.

Hoewel er geen apparaatstatus genaamd “bedrijfsapparaat” is in Conditional Access, kunnen we twee dingen identificeren over een apparaat en daaruit concluderen dat een apparaat zakelijk eigendom is:

1. Is het apparaat hybride Azure AD-ingeschakeld?
2. Is het apparaat gemarkeerd als compliant?

Hybride Azure AD-ingevoegd verwijst naar een staat waarin een apparaat is toegetreden tot uw on-premises Active Directory, maar ook gesynchroniseerd en toegetreden tot de cloudgebaseerde Azure AD. We hebben behandeld hoe u uw apparaten in deze staat kunt krijgen hier. Dit is alleen geschikt voor Windows-apparaten.

In de onderstaande schermafbeelding ziet u hoe Azure AD meldt welk type hybride Azure AD-toetreden er is.

Gemarkeerd als compliant betekent dat het apparaat is ingeschreven in een mobiele apparaatbeheeroplossing, zoals Intune, en voldoet aan de nalevingsvereisten van dat MDM, zoals het hebben van een actieve firewall. Op vele manieren is dit een betere controle dan alleen het controleren van de domeinlidmaatschap van het apparaat, aangezien u ook een bepaald beveiligingsniveau waarborgt, wat gunstig is voor een zero-trust-strategie. Als u echter alleen wilt bevestigen dat het apparaat is ingeschreven in Intune, zou u een nalevingsbeleid kunnen instellen zonder specifieke beveiligingseisen. Deze methode kan worden gebruikt voor de “grote 4” moderne platformen: Windows 10, macOS, iOS en Android.

In de onderstaande schermafbeelding kunt u zien hoe Intune de naleving van apparaatrapporten teruggeeft.

Strikt genomen is de juiste term voor een apparaat in een van deze staten een beheerd apparaat. Dit betekent dat een IT-beheerder enige mate van controle heeft over dat apparaat, zoals de mogelijkheid om instellingen toe te passen en te beheren vanuit Groepsbeleid of Intune. Apparaten in geen van beide staten worden beschouwd als niet-beheerd. Als we ervan uitgaan dat we de mogelijkheid om in te schrijven bij Intune beperkt hebben tot alleen zakelijke apparaten, kunnen we redelijkerwijs de termen beheerd en zakelijk door elkaar gebruiken.

Belangrijk om op te merken is dat Azure AD sommige platforms en browsers om certificaatinformatie kan vragen als een Conditional Access-beleid op basis van apparaatstatus wordt gebruikt. Dit zijn meestal niet-Microsoft-platforms, zoals Apple- en Google-platforms. Dit gebeurt omdat de apparaatstatusinformatie wordt bewaard in een certificaat op dat apparaat, en niet alle software maakt dit automatisch beschikbaar voor Azure AD tijdens de verificatie.

Het maken van het Conditional Access-beleid

Conditional Access-beleidsregels worden gemaakt binnen Azure AD > Beveiliging > Conditional Access. Het is een goede praktijk om uw beleid een naam te geven waarmee het eenvoudig is om exact te identificeren wat het beleid beoogt te bereiken. Dit komt doordat als meerdere beleidsregels overeenkomen met een verificatiepoging, ze allebei van toepassing zijn, en een goede naamgevingsconventie vereenvoudigt probleemoplossing en beheer.

Beleidsregels zijn onderverdeeld in toewijzingen en toegangscontroles.  Toewijzingen zijn het equivalent van een checklist van alles wat waar moet zijn over de aanmelding voor het beleid om van toepassing te zijn op de aanmelding.  Voor de meeste van deze instellingen kunt u zowel voorwaarden opnemen als uitsluiten.  Bijvoorbeeld, alle gebruikers opnemen maar IT-personeel uitsluiten.  Als het beleid van toepassing is, bepalen de toegangscontroles of toegang wordt geweigerd of toegestaan en, wanneer toegestaan, welke andere stappen en maatregelen van toepassing moeten zijn of waar moeten zijn.

Voordat u aan Conditional Access begint, is het belangrijk om te overwegen hoe krachtig het is: het geeft u de mogelijkheid om authenticatie naar alle apps volledig te blokkeren.  Daarom kunt u iets verkeerd configureren en belangrijke gebruikers van belangrijke apps blokkeren, of zelfs alle beheerders.  U moet overwegen uitzonderingen te maken voor break-glass noodtoegangsaccounts waarvan u de aanmeldingsactiviteit controleert.  Persoonlijk is dit de eerste stap die ik neem bij het maken van eventuele Conditional Access-beleidsregels.

Toewijzingen

Gebruikers en groepen bepalen op wie het beleid van toepassing zal zijn.  Als u niet in deze toewijzing staat, bent u niet onderworpen aan de regels ervan. Voor een beleid dat de toegang tot Office 365 blokkeert op onbeheerde apparaten, wilt u mogelijk alle gebruikers omvatten maar gasten/externe gebruikers en de noodtoegangsaccounts uitsluiten. U kunt ook alleen een geschikte Azure AD-groep opnemen.

Voor Cloud-apps of acties, selecteer Office 365. U kunt meer dan een cloud-app selecteren, dus u wilt mogelijk een beleid maken dat alle apps beperkt die u gevoelig acht, niet alleen Office 365. De Office 365-app die wordt vermeld in Conditional Access is eigenlijk een verzameling van andere apps die u individueel kunt selecteren. Zo omvat het bijvoorbeeld Exchange Online en SharePoint Online, maar u kunt in theorie gewoon de component-apps kiezen. De reden om Office 365 te selecteren en niet een van de onderdelen ervan, is te wijten aan de geïntegreerde aard van de service. Door het selecteren van het uniforme platform worden problemen die verband houden met de afhankelijkheden die ze op elkaar hebben, verminderd.

Voorwaarden zijn waar u signalen en verificatie-eigenschappen specificeert, zoals IP-adressen, besturingssystemen en apps (wat, ruwweg genomen, betekent web- of clienttoegang tot apps). In ons voorbeeld zullen we de toegang tot alle Office 365-toegangsmethoden blokkeren, dus specificeer geen voorwaarden. Dit betekent dat elke voorwaarde van toepassing is. Een veelvoorkomend gebruik van deze voorwaarden is echter om verschillende regels te hebben voor webtoegang en toegang via desktop-apps.

U zult ook de voorwaarde voor apparaatstatus in deze sectie opmerken, maar we zullen deze eigenlijk niet selecteren voor dit beleid. Lees verder om te zien waarom.

Toegangscontroles

Nu we het element “als dit…” van ons beleid hebben behandeld, is het tijd voor het “dan dat…”. Toegangscontroles zijn opgesplitst in toewijzing en sessie instellingen.

In het toekennings paneel, selecteer toegang toekennen en vink de vakjes aan voor vereist apparaat om als compliant te worden gemarkeerd en vereist hybride Azure AD-verbonden apparaat . Je hebt ook de optie om te kiezen of het apparaat beide van deze moet zijn, of een van beide. De aanbeveling is om een van de geselecteerde controles vereist te selecteren zodat zowel domeingejoinde on-premises apparaten als alleen op Azure AD-verbonden apparaten toegang kunnen krijgen.

Wat we hier hebben gedaan is zeggen “je kunt toegang krijgen, maar je hebt een beheerd apparaat nodig”. Met andere woorden, dit betekent ook “je kunt geen toegang krijgen tenzij je een beheerd apparaat bent”. Als we ervan uitgaan dat ons proces voor het toetreden tot het domein on-premises veilig is, en onze Intune-inschrijving beperkt is tot bedrijfsapparaten, beperkt dit alle toegang tot Office 365 tot bedrijfsapparaten.

Sessie instellingen bepalen wat een gebruiker mag doen zodra ze toegang hebben gekregen. Bijvoorbeeld, in webbrowsersessies, kunt u applicatie-afgedwongen beperkingen gebruiken om downloads van services zoals Exchange Online en SharePoint Online te blokkeren. Hopelijk brengt dit je op ideeën over de verschillende manieren waarop je je beleid kunt vormgeven: potentieel één om de toegang voor volledige apps op onbeheerde apparaten te blokkeren, maar een ander die alleen toegang tot webapps toestaat, waarbij geen downloads worden afgedwongen.

Het implementeren van het Conditional Access-beleid.

Met alle toegepaste instellingen kan uw Conditional Access-beleid nu in de standen alleen rapporteren of ingeschakeld worden gezet. Het doel van de alleen-rapporteren stand is om Azure AD-aanmeldingslogs te controleren wat er zou zijn gebeurd zonder de productieomgeving te onderbreken. U kunt deze informatie vervolgens gebruiken om de gevolgen van het beleid te begrijpen: bijvoorbeeld, welke verstoring kunnen we verwachten en daarom wat voor soort opleiding moeten we onze gebruikers bieden?

Er is echter een belangrijke waarschuwing van kracht voor de alleen-rapporteren modus in ons geval. Zoals eerder vermeld, moet Azure AD om de apparaatstatus te bepalen een certificaat opvragen en sommige platforms staan ​​dit niet automatisch toe. Zelfs als u in de alleen-rapporteren modus werkt, heeft het nog steeds dat certificaat nodig om te weten wat het had kunnen doen. U wordt hier altijd voor gewaarschuwd in beleidsregels als u instellingen op basis van apparaatstatus opneemt.

Wanneer u er zeker van bent dat uw beleid correct is geconfigureerd en geen nadelige gevolgen zal hebben voor het bedrijf, wijzigt u eenvoudig de status naar ingeschakeld, waarna het beleid onmiddellijk wordt toegepast op toekomstige Azure AD-authenticatiepogingen.

Gebruikerservaring

Als een gebruiker nu probeert toegang te krijgen tot een Office 365-bron op een niet-bedrijfs (Intune-compatibel of hybride Azure AD-aangesloten) apparaat, zal Azure AD hen adviseren dat de toegang is geblokkeerd. Dit geldt voor elke vorm van toegang, of het nu gaat om het gebruik van een web-applicatie of een volledige client-applicatie. Opnieuw kunt u voor zowel web-apps als client-apps verschillende regels hanteren met behulp van voorwaarden.

Op zakelijke apparaten verandert het authenticatieproces niet zover de gebruiker weet: ze zullen gewoon door kunnen gaan. De enige uitzondering hierop is wanneer die app de toestand van het apparaat niet kan controleren. Dit zou geen probleem moeten zijn voor first-party apps zoals de Office 365-suite, maar kan bijvoorbeeld wel een probleem zijn met third-party browsers, zelfs in Windows. Uw gebruikers kunnen een foutmelding krijgen die vergelijkbaar is met die op de bovenstaande afbeelding. Chrome voor Windows ondersteunt de toestand van het apparaat als de Windows 10 Accounts-extensie wordt gebruikt en zoals u zich kunt voorstellen, ondersteunt de op Chromium gebaseerde Edge dit standaard.

Gerelateerd artikel:

• Waarom u de toegang tot Office 365 zou moeten beperken met behulp van Microsoft Conditional Access-beleid