Ja: op zijn minst moet een beleid worden ingevoerd dat verouderde authenticatiemechanismen blokkeert en indien mogelijk MFA voor alle gebruikers vereist (minimaal beheerders). Als je werknemers hebt die inloggen vanuit andere landen, kun je ook geofencing instellen. Vergeet ten slotte niet om je "break glass" -accounts in te stellen!

Er zijn functies in de Identity Protections-functies in M365 die hierbij kunnen helpen. Bovendien kan een plug-in worden geïnstalleerd op je on-prem DC's om ook lokale wachtwoorden te laten controleren.

Je kan MFA instellen, die zelfs in de lagere licentieniveaus is opgenomen. Training voor gebruikersbewustzijn en zorgvuldige logboekbewaking kunnen ook nuttig zijn bij deze organisatieomvang.

Niet perse. De dreigingsactor wacht nog steeds tot de eindgebruiker doet wat hij moet doen om in te loggen. De sessietoken van de dreigingsactor is nog steeds het doelwit en kan worden gecompromitteerd na een succesvolle authenticatie met zaken als kwaadaardige OAuth-toepassingen etc.

Best practices op het gebied van beveiliging zeggen dat je dit om een ​​aantal redenen niet moet doen. Idealiter heeft elke beheerder die dit toegangsniveau nodig heeft, zijn eigen algemene beheerdersaccount en maakt gebruik van functies zoals just-in-time toegang.

Elke situatie is natuurlijk anders, maar alles wat het algehele vertrouwen van een apparaat kan vergroten (zoals beheerd worden door InTune als dat voor jouw organisatie werkt) is over het algemeen gunstig.

Dit is zeker een gebied waarop organisaties zich moeten concentreren met consistente regelmatige training. Dat gezegd hebbende, moet dit gepaard gaan met technische oplossingen die in staat zijn om een ​​bedreiging te identificeren en actie te ondernemen, omdat het menselijke element op een gegeven moment zal falen ondanks de best opgestelde plannen

Helemaal niet! Het kan zijn dat je denkt aan 'Conditional Access Baseline Policies', dat nooit uit de preview is gekomen, maar in plaats daarvan is vervangen door 'Security Defaults'. Dat gezegd hebbende, blijft voorwaardelijke toegang zelf een zeer krachtig hulpmiddel voor beveiliging in M365.

Ik ken er zelf geen. Tot op zekere hoogte wordt de lijst gedeeltelijk bepaald door de licenties die actief zijn in jouw M365-tenant. Als je bijvoorbeeld alleen Exchange Online Plan 1 hebt en niets anders, ziet het er misschien vreemd uit om Teams en SharePoint in die lijst te zien etc. Zelfs met standaardinstellingen moet de lijst regelmatig door een mens worden beoordeeld.

Ik vermoed dat deze vraag voortkomt uit mijn discussies over MAPI als een verouderd authenticatieprotocol en had moeten vermelden dat het advies daar specifiek is voor MAPI via HTTP, dat alleen wordt gebruikt via Outlook 2010 en oudere clients. Nieuwere Outlook-clients kunnen volledig profiteren van moderne authenticatie en werken nog steeds probleemloos, omdat hier geen gebruik wordt gemaakt van een verouderd MAPI-protocol.

Toegegeven, je hebt bijna een doctoraat nodig om je hoofd rond M365-licenties te wikkelen. Kortom, de 3 potentiële "ad-dons" waarnaar je op zoek bent, zijn Azure AD Premium Plan 1 of Plan 2, of een van de EMS E3- of E5-opties , die verschillende niveaus van AAD Premium bevatten. Elk van deze kan worden gekoppeld aan verschillende M365-pakketten voor de extra beveiligingsfunctionaliteit, en sommige pakketten worden meegeleverd. Business Premium wordt bijvoorbeeld geleverd met AAD Premium-abonnement 1, waarmee je de basisfuncties voor voorwaardelijke toegang krijgt. Ik raad aan om de AAD Pricing-pagina en de EMS-vergelijkingspagina te bekijken. Dan wordt het een prijsoefening welke optie het beste werkt voor de specifieke behoeften van jouw klant.

Natuurlijk! Het e-book is hier te vinden!

Juist. Met AAD Premium Plan 1 krijg je toegang tot basisfunctionaliteit voor voorwaardelijke toegang die veel gebruiksscenario's voor verschillende organisaties dekt. Als je alle toeters en bellen nodig hebt, zoals risicovolle aanmeldingsbeveiliging, risicovolle gebruikersdetectie etc., dan heb je AAD Premium Plan 2 nodig. Zie de AAD-prijspagina voor enkele vergelijkingen.

Zonder extra context neem ik aan dat je meerdere AD-forests moet synchroniseren met Azure AD? Als dat het geval is, raad ik aan om de documentatie over Azure AD Connect-topologieën hier te bekijken voor meer informatie over die use-case.

Dit is een vrij brede vraag. Ik zou willen voorstellen om dit item uit de Microsoft Docs-documentatie te lezen voor meer informatie over Intune en de apparaatbeveiligingen die het kan bieden.

Het is een mogelijke manier om te werk te gaan, en het werkt in de meeste gevallen best goed. Dat gezegd hebbende, als je deel uitmaakt van een organisatie die meer specifieke beveiligingsvereisten heeft, zijn er andere opties, zoals hardware MFA-sleutels, als voorbeeld.