Microsoft Intune als Sicherheits- und Steuerungsinstanz im Modern Workplace – Architektur, Risiken und neue Ansätze im Endpoint Management

Einordnung: Intune im Kontext des Modern Workplace

Mit der Einführung von Windows 11, der Integration von Cloud-Diensten und der zunehmenden Bedeutung von Microsoft Entra ID hat sich die Rolle von Microsoft Intune grundlegend verändert. Während klassische Management-Ansätze stark gerätezentriert waren, verschiebt sich der Fokus im Modern Workplace hin zu einer Kombination aus Identität, Gerätezustand und kontextbasierter Zugriffskontrolle.

Intune übernimmt dabei eine zentrale Rolle. Die Plattform fungiert nicht mehr ausschließlich als Verwaltungswerkzeug für Endgeräte, sondern entwickelt sich zu einer sicherheitskritischen Steuerungsinstanz, die maßgeblich beeinflusst, welche Geräte unter welchen Bedingungen auf Unternehmensressourcen zugreifen dürfen.

Microsoft beschreibt Intune entsprechend als Cloud-basierten Dienst für das Endpoint Management, der Richtlinien durchsetzt, Geräte schützt und Anwendungen bereitstellt. Diese Beschreibung greift jedoch zu kurz, wenn man Intune aus einer architektonischen Perspektive betrachtet.

Vom Verwaltungswerkzeug zur sicherheitsrelevanten Plattform

Im Zusammenspiel mit Microsoft Entra ID und Conditional Access entsteht eine Architektur, in der Intune nicht isoliert agiert, sondern Teil einer übergeordneten Steuerungslogik ist:

• Identität (Entra ID) bestimmt, wer Zugriff anfordert
• Intune bewertet den Zustand des Geräts
• Conditional Access entscheidet über den Zugriff

Dadurch verschiebt sich die Verantwortung von Intune deutlich. Die Plattform ist nicht mehr nur für Konfiguration und Deployment zuständig, sondern wirkt aktiv an Sicherheitsentscheidungen mit.

Gerade im Vergleich zu klassischen Active Directory- und GPO-basierten Umgebungen wird dieser Wandel deutlich. Während dort Richtlinien häufig statisch und netzwerkgebunden angewendet wurden, erfolgt die Steuerung heute dynamisch und kontextabhängig.

Einordnung im Kontext bestehender Inhalte im Blog

Die im Beitrag beschriebenen Zusammenhänge lassen sich nicht isoliert betrachten. Sie bauen auf grundlegenden Konzepten auf, die an anderer Stelle im Blog bereits ausführlicher behandelt wurden.

So zeige ich im Beitrag zu Windows 11 im Modern Workplace: Identität, Geräteverwaltung und Sicherheit mit Entra ID und Intune wie sich moderne Client-Plattform, Identität und Gerätemanagement im Unternehmenskontext verzahnen. Ergänzend dazu verdeutliche ich im Beitrag Anmeldesicherheit neu denken – Warum Passwörter scheitern und Windows Hello for Business sowie Passkeys die Zukunft sind warum Identität und insbesondere starke Authentifizierungsverfahren heute im Zentrum jeder Sicherheitsstrategie stehen. Darüber hinaus liefert der Beitrag Azure Grundlagen: Architekturprinzipien, Identität, Governance und Best Practices für moderne Cloud-Umgebungen eine übergeordnete Perspektive auf Architekturprinzipien wie Governance, Identity und Zero Trust.

Aus diesen Inhalten ergibt sich ein konsistentes Gesamtbild:

• Windows 11 bildet die sichere Client-Plattform
• Cloud-Dienste erweitern die Funktionalität und Skalierbarkeit
• Identitäten entwickeln sich zum zentralen Sicherheitsanker

Intune ergänzt diese Architektur um die operative Steuerungsebene. Dadurch entsteht eine klare Trennung zwischen Identität, Kontrolle und Zugriff – ein Prinzip, das sich direkt in modernen Zero-Trust-Modellen wiederfindet.

Bedrohungsmodell: Warum Intune ein attraktives Angriffsziel ist

Mit der zunehmenden Zentralisierung von Verwaltung und Sicherheitsrichtlinien entsteht ein grundlegender Zielkonflikt. Einerseits vereinfacht diese Bündelung den Betrieb erheblich, da Konfigurationen, Sicherheitsvorgaben und Softwareverteilung zentral gesteuert werden können. Andererseits erhöht genau diese Konzentration von Funktionen die Attraktivität der Plattform für Angreifer:innen, da sich mit einem einzigen erfolgreichen Zugriff weitreichende Kontrollmöglichkeiten eröffnen.

Microsoft Intune vereint in diesem Kontext mehrere sicherheitskritische Aufgaben in einer gemeinsamen Steuerungsebene. Über die Plattform werden Anwendungen verteilt, Sicherheitsrichtlinien durchgesetzt und Gerätezustände kontinuierlich bewertet. Gleichzeitig liefert Intune entscheidende Informationen für Conditional Access Entscheidungen und wirkt damit direkt an der Zugriffskontrolle auf Unternehmensressourcen mit.

Diese enge Verzahnung führt dazu, dass Intune innerhalb der IT-Architektur nicht mehr nur eine unterstützende Rolle einnimmt, sondern als zentrale Kontrollinstanz fungiert. Genau diese Rolle macht die Plattform jedoch zu einem besonders attraktiven Angriffsziel. Wird ein privilegierter Zugriff auf Intune kompromittiert, betrifft dies nicht nur einzelne Systeme oder Datenbestände. Vielmehr geraten die Mechanismen selbst in den Fokus, die festlegen, welche Geräte als vertrauenswürdig gelten und unter welchen Bedingungen Zugriff gewährt wird.

Angriffsszenarien aus der Praxis

Die Relevanz dieses Bedrohungsmodells zeigt sich nicht nur auf konzeptioneller Ebene, sondern auch in realen Sicherheitsvorfällen. Sicherheitsbehörden wie die CISA haben im Zusammenhang mit dem sogenannten Stryker-Vorfall dokumentiert, dass Angreifer gezielt Verwaltungsplattformen wie Intune missbrauchen konnten, um Endgeräte zu manipulieren oder sogar vollständig zurückzusetzen. Damit verschiebt sich der Angriffsvektor weg vom einzelnen System hin zur zentralen Steuerungsebene.

Ein kompromittierter administrativer Zugriff auf Intune eröffnet in diesem Kontext weitreichende Möglichkeiten. Angreifer sind in der Lage, manipulierte Anwendungen auf verwaltete Geräte auszurollen und damit Schadcode direkt in vertrauenswürdige Umgebungen einzuschleusen. Gleichzeitig können bestehende Sicherheitsrichtlinien gezielt abgeschwächt oder vollständig entfernt werden, wodurch Schutzmechanismen wiederum systematisch ausgehebelt werden. Besonders kritisch ist zudem die Möglichkeit, Geräte remote zurückzusetzen oder gezielt aus der Verwaltung zu entfernen, was sowohl operative Ausfälle als auch Datenverluste nach sich ziehen kann.

Darüber hinaus zeigt aktuelle Forschung, dass sich die Angriffsfläche deutlich erweitert, wenn Intune mit angrenzenden Systemen kombiniert wird. Insbesondere die enge Integration mit Entra ID sowie Zertifikatsdiensten führt dazu, dass Identitäts- und Geräteebene zunehmend miteinander verschmelzen. In solchen Szenarien gewinnen tokenbasierte Angriffe, kompromittierte Service Principals und missbrauchte Zertifikate erheblich an Bedeutung. Angriffe zielen damit nicht mehr nur auf klassische Zugangsdaten, sondern auf die Vertrauensbeziehungen innerhalb der gesamten Architektur.

Verschiebung des Angriffsvektors

Ein zentraler Unterschied zu klassischen Angriffsmustern liegt in der strukturellen Verschiebung des Angriffsziels. Während Angriffe früher häufig direkt auf Endgeräte abzielten, rückt heute zunehmend die Management- und Steuerungsebene in den Fokus. Diese Entwicklung ist eng mit der Transformation hin zu cloudbasierten Architekturen verbunden, in denen Kontrolle nicht mehr lokal, sondern zentral orchestriert wird.

Angreifer:innen verfolgen dabei einen klar strategischen Ansatz. Anstatt einzelne Geräte isoliert zu kompromittieren, wird gezielt die Instanz angegriffen, die diese Geräte verwaltet. Dadurch entsteht ein Multiplikatoreffekt: Ein erfolgreicher Zugriff auf die Management-Ebene ermöglicht indirekt die Kontrolle über eine Vielzahl von Systemen. Gleichzeitig verlagert sich der Fokus von klassischen Zugangsdaten hin zu Identitäten und insbesondere zu Token-basierten Authentifizierungsmechanismen, da diese oft weniger sichtbar und schwerer zu überwachen sind.

Auffällig ist zudem, dass moderne Angriffe zunehmend auf legitime Funktionen setzen. Anstatt Schadsoftware einzuschleusen, werden vorhandene Management-Mechanismen missbraucht, um Konfigurationen zu verändern, Richtlinien anzupassen oder Aktionen auf Endgeräten auszulösen. Dadurch verschwimmen die Grenzen zwischen regulärer Administration und bösartiger Aktivität, was die Erkennung erheblich erschwert.

Diese Entwicklung lässt sich konsequent in moderne Zero-Trust-Modelle einordnen. Wenn Identität und Kontrolle die zentralen Sicherheitsanker darstellen, werden genau diese Ebenen zwangsläufig zum primären Angriffsziel.

Konsequenzen für die Sicherheitsstrategie

Aus dieser Perspektive ergibt sich eine zentrale Erkenntnis: Die Absicherung von Intune ist keine optionale Maßnahme, sondern ein integraler Bestandteil der gesamten Sicherheitsarchitektur.

Mit der Verlagerung von Kontrolle und Steuerung in die Cloud verschiebt sich auch die Verantwortungsebene. Sicherheit entsteht nicht mehr primär auf dem Endgerät, sondern entlang der gesamten Zugriffskette – von der Identität über die Management-Ebene bis hin zur tatsächlichen Durchsetzung von Richtlinien. Intune nimmt in diesem Modell eine Schlüsselrolle ein, da hier technische Kontrolle und sicherheitsrelevante Entscheidungen zusammenlaufen.

Organisationen, die Intune einsetzen, müssen daher nicht nur Endgeräte absichern, sondern insbesondere die Plattform selbst sowie deren Zugriffspfade konsequent schützen. Andernfalls entsteht ein strukturelles Risiko, bei dem zentrale Steuerungsmechanismen zum Single Point of Failure werden.

Dazu gehören unter anderem:

• Absicherung privilegierter Konten, insbesondere durch starke Authentifizierungsverfahren und Minimierung von dauerhaften Administratorrechten
• Klare Rollen- und Berechtigungskonzepte, die eine saubere Trennung von Aufgaben und Verantwortlichkeiten gewährleisten
• Kontinuierliche Überwachung administrativer Aktivitäten, um missbräuchliche oder ungewöhnliche Aktionen frühzeitig zu erkennen
• Integration in ein ganzheitliches Zero-Trust-Modell, in dem Identität, Gerätezustand und Kontext gemeinsam bewertet werden

Diese Anforderungen bilden die Grundlage für die folgenden Kapitel, in denen konkrete Schutzmaßnahmen und architektonische Ansätze detailliert betrachtet werden. Ziel ist es, Intune nicht nur als Verwaltungswerkzeug zu verstehen, sondern als sicherheitskritische Plattform, die aktiv in die Gesamtstrategie eingebunden werden muss.

Security-In-Depth: Die drei zentralen Schutzprinzipien

Moderne Sicherheitsarchitekturen folgen keinem einzelnen Schutzmechanismus, sondern einem mehrschichtigen Ansatz. Gerade im Kontext von Microsoft Intune ist dies entscheidend, da hier Identität, Gerätemanagement und Zugriffskontrolle eng miteinander verzahnt sind.

Ein wirksames Schutzkonzept basiert daher auf drei zentralen Prinzipien: der konsequenten Reduktion von Berechtigungen, der Absicherung von Authentifizierungsverfahren sowie der Kontrolle kritischer Änderungen. Erst das Zusammenspiel dieser Ebenen ermöglicht eine robuste und belastbare Sicherheitsarchitektur.

Least Privilege und Rollenmodell

Das Prinzip der minimalen Rechtevergabe bildet die zentrale Grundlage für eine sichere Intune-Architektur. Ziel ist es, administrative Berechtigungen konsequent zu reduzieren, klar zu strukturieren und nur dort bereitzustellen, wo sie tatsächlich benötigt werden. In der Praxis entsteht daraus ein Zusammenspiel mehrerer Mechanismen: das rollenbasierte Zugriffskontrollmodell (RBAC) von Intune, die Segmentierung über Scope Tags sowie die zeitlich begrenzte Vergabe privilegierter Rechte über Entra Privileged Identity Management (PIM). Gemeinsam folgen diese Komponenten einem übergeordneten Architekturprinzip: Es existieren keine dauerhaft privilegierten Konten mehr.

Intune RBAC im Sicherheitskontext

Das rollenbasierte Zugriffskontrollmodell von Intune ermöglicht eine granulare Steuerung administrativer Aufgaben und bildet damit die operative Grundlage für Least Privilege. Rollen definieren dabei nicht nur Zuständigkeiten, sondern setzen gleichzeitig sicherheitsrelevante Grenzen.

Entscheidend ist, dass Rollen bewusst restriktiv gestaltet werden. Werden Berechtigungen zu weit gefasst, erhöht sich unmittelbar die Angriffsfläche. Gleichzeitig steigt die potenzielle Wirkung kompromittierter Konten erheblich. RBAC ist daher kein reines Organisationswerkzeug, sondern ein zentraler Baustein zur Begrenzung von Risiken.

Segmentierung durch Scope Tags

Ergänzend zum Rollenmodell ermöglichen Scope Tags eine gezielte Segmentierung der Verwaltungsumgebung. Administratoren erhalten dadurch nicht nur bestimmte Rollen, sondern diese gelten ausschließlich für definierte Teilbereiche, etwa bestimmte Gerätegruppen oder organisatorische Einheiten.

Gerade in größeren Umgebungen verhindert diese Trennung, dass einzelne Administratoren globale Kontrolle erhalten. Gleichzeitig wird die seitliche Bewegung im Angriffsfall deutlich eingeschränkt, da Berechtigungen strikt auf klar abgegrenzte Kontexte begrenzt bleiben.

Just-in-Time Privilegien mit Entra PIM

Ein weiterer zentraler Baustein ist die Nutzung von Just-in-Time-Privilegien über Entra Privileged Identity Management. Anstatt Administrationsrechte dauerhaft zu vergeben, werden diese gezielt angefordert und nur für einen begrenzten Zeitraum aktiviert.

Dieser Ansatz ermöglicht die Integration zusätzlicher Sicherheitsmechanismen, etwa Multi-Faktor-Authentifizierung, Genehmigungsprozesse und detaillierte Protokollierung. Gleichzeitig wird sichergestellt, dass privilegierte Rechte nur dann existieren, wenn sie tatsächlich benötigt werden.

Architekturprinzip: Keine stehenden Admin-Rechte

Aus dem Zusammenspiel von RBAC, Scope Tags und PIM entsteht ein klares Zielbild: Dauerhaft privilegierte Konten werden konsequent vermieden. Stattdessen werden administrative Rechte situativ vergeben, kontrolliert genutzt und anschließend wieder entzogen.

Dieses Modell reduziert nicht nur die Angriffsfläche, sondern verändert auch die Qualität potenzieller Angriffe grundlegend. Selbst wenn Zugangsdaten kompromittiert werden, entfaltet ein Konto ohne aktive Privilegierung nur eine stark eingeschränkte Wirkung.

Phishing-resistente Authentifizierung

Die Absicherung von Identitäten stellt eine der zentralen Herausforderungen moderner IT-Sicherheitsarchitekturen dar. Insbesondere privilegierte Konten erfordern ein deutlich höheres Schutzniveau, da sie direkten Zugriff auf sicherheitskritische Funktionen ermöglichen. Vor diesem Hintergrund reicht klassische Authentifizierung nicht mehr aus. Stattdessen sind Verfahren erforderlich, die gezielt gegen moderne Angriffsformen wie Phishing und Token-Missbrauch ausgelegt sind.

Die grundlegenden Zusammenhänge und die Entwicklung hin zu passwortlosen Verfahren habe ich im Beitrag zur modernen Anmeldesicherheit ausführlich vertieft. Im vorliegenden Kontext liegt der Fokus hingegen gezielt auf der Absicherung privilegierter Zugriffe innerhalb von Intune- und Cloud-Management-Umgebungen.

Grenzen klassischer MFA

Viele Sicherheitskonzepte setzen weiterhin auf klassische Multi-Faktor-Authentifizierung als primären Schutzmechanismus. In der Praxis zeigt sich jedoch zunehmend, dass diese Verfahren nicht ausreichend widerstandsfähig sind. Angriffe wie Phishing-as-a-Service oder gezielte MFA Fatigue-Kampagnen ermöglichen es, Benutzer zur Freigabe von Anmeldeversuchen zu bewegen oder Authentifizierungsprozesse zu manipulieren.

Dadurch verliert klassische MFA ihre Rolle als alleinige Schutzmaßnahme, insbesondere im Kontext privilegierter Konten. Sie bleibt zwar ein wichtiger Bestandteil der Sicherheitsstrategie, muss jedoch durch stärkere, phishing-resistente Verfahren ergänzt werden.

Token-basierte Angriffe als neue Realität

Ein wesentlicher Paradigmenwechsel besteht darin, dass Angreifer nicht mehr primär Zugangsdaten stehlen, sondern gültige Authentifizierungssitzungen übernehmen. Techniken wie Session Hijacking oder Token Replay ermöglichen es, bestehende Sitzungen auszunutzen, ohne den eigentlichen Login-Prozess erneut durchlaufen zu müssen.

Diese Entwicklung ist besonders kritisch, da viele Sicherheitsmechanismen an die initiale Authentifizierung gekoppelt sind. Wird ein gültiges Token kompromittiert, greifen zusätzliche Schutzmaßnahmen häufig nicht mehr. Im Kontext von Cloud-Diensten wie Intune kann dies dazu führen, dass Angreifer direkten Zugriff auf Verwaltungsfunktionen erhalten, ohne erneut authentifiziert werden zu müssen.

Anforderungen an privilegierte Konten

Vor diesem Hintergrund ergeben sich klare Anforderungen an die Absicherung privilegierter Zugriffe. Phishing-resistente Authentifizierungsverfahren sind keine optionale Ergänzung mehr, sondern eine zwingende Voraussetzung für eine belastbare Sicherheitsarchitektur.

Dazu gehören insbesondere:

• Einsatz von FIDO2-basierten Authentifizierungsverfahren, die gegenüber klassischen Phishing-Angriffen resistent sind
• Nutzung von Windows Hello for Business als gerätegebundene, schlüsselbasierte Authentifizierung
• Einsatz zertifikatsbasierter Authentifizierung, insbesondere in verwalteten Geräteumgebungen

Ergänzend dazu sollten privilegierte Zugriffe ausschließlich über dedizierte, gehärtete Arbeitsumgebungen erfolgen, etwa in Form von Privileged Access Workstations (PAW). Dadurch wird sichergestellt, dass administrative Aktionen nicht aus potenziell kompromittierten Standardumgebungen heraus durchgeführt werden.

In der Kombination entsteht ein mehrschichtiges Schutzmodell, das nicht nur den Authentifizierungsprozess absichert, sondern auch die Integrität der gesamten Zugriffskette stärkt.

Multi Admin Approval

Die Absicherung von Identität und Berechtigungen bildet eine zentrale Grundlage moderner Sicherheitsarchitekturen. Darüber hinaus gewinnt jedoch ein weiterer Aspekt zunehmend an Bedeutung: die gezielte Kontrolle besonders sensibler Änderungen innerhalb der Plattform. Gerade in Intune, wo administrative Aktionen unmittelbare Auswirkungen auf Geräte, Benutzer und Sicherheitsrichtlinien haben, entsteht hier ein kritischer Kontrollpunkt.

Bestimmte Maßnahmen wirken direkt und oft ohne zeitliche Verzögerung auf produktive Systeme. Dazu zählen beispielsweise das Zurücksetzen von Geräten, das Ausrollen von Skripten oder Änderungen an Rollen und Berechtigungen. Ohne zusätzliche Absicherung können solche Aktionen – ob absichtlich oder unbeabsichtigt – weitreichende Folgen haben.

Vier-Augen-Prinzip als Sicherheitsmechanismus

Multi Admin Approval etabliert in diesem Kontext ein technisches Vier-Augen-Prinzip. Kritische Aktionen werden nicht mehr durch eine einzelne Instanz ausgeführt, sondern erfordern eine zusätzliche Freigabe durch eine zweite autorisierte Person.

Dieses Vorgehen schafft eine zusätzliche Kontrollschicht und reduziert Risiken auf mehreren Ebenen. Zum einen wird die unmittelbare Ausnutzbarkeit kompromittierter Konten eingeschränkt. Zum anderen entsteht ein strukturiertes Prüfverfahren, das auch unbeabsichtigte Fehlkonfigurationen frühzeitig abfangen kann. Insbesondere in sicherheitskritischen oder regulierten Umgebungen ist dieser Mechanismus ein zentraler Bestandteil belastbarer Governance-Strukturen.

Typische Anwendungsfälle sind:

• Genehmigung von Device-Wipe-Aktionen
• Freigabe von Skripten oder sicherheitsrelevanten Konfigurationsänderungen
• Kontrolle von Rollen- und Berechtigungsanpassungen

Reduktion von Insider- und Fehlkonfigurationsrisiken

Ein wesentlicher Vorteil dieses Ansatzes liegt in der systematischen Reduktion von Insider-Risiken. Selbst wenn privilegierte Konten missbräuchlich verwendet oder kompromittiert werden, verhindert die zusätzliche Freigabeinstanz eine unmittelbare Eskalation.

Darüber hinaus wirkt Multi Admin Approval als wirksamer Schutzmechanismus gegen Fehlkonfigurationen. In komplexen IT-Umgebungen entstehen Risiken häufig nicht durch gezielte Angriffe, sondern durch unbeabsichtigte Änderungen mit großer Reichweite. Durch die verpflichtende Gegenprüfung werden solche Effekte deutlich reduziert.

Insgesamt ergänzt Multi Admin Approval die technischen Schutzmaßnahmen um eine organisatorische und prozessuale Sicherheitsebene. Erst durch dieses Zusammenspiel entsteht eine ganzheitliche Sicherheitsarchitektur, die sowohl externe Angriffe als auch interne Risiken wirksam adressiert.

Conditional Access als Durchsetzungsebene

Moderne Sicherheitsarchitekturen entfalten ihre Wirkung nicht durch einzelne Maßnahmen, sondern durch das koordinierte Zusammenspiel mehrerer Ebenen. Im Microsoft-Ökosystem übernimmt Conditional Access dabei die Rolle der zentralen Durchsetzungsebene. Hier werden Entscheidungen darüber getroffen, ob und unter welchen Bedingungen ein Zugriff tatsächlich erlaubt wird.

Während Identitäten über Entra ID verwaltet und Geräte über Intune bewertet werden, verknüpft Conditional Access diese Informationen zu konkreten Zugriffsentscheidungen. Dadurch entsteht ein dynamisches Sicherheitsmodell, das Kontext, Zustand und Risiko in Echtzeit berücksichtigt.

Zusammenspiel von Identität, Gerätezustand und Zugriff

Eine belastbare Sicherheitsarchitektur im Modern Workplace basiert auf drei eng verzahnten Komponenten: Identität, Gerätezustand und Zugriffskontrolle.

Entra ID stellt die Identität als primären Sicherheitsanker bereit. Hier werden Benutzerkonten, Gruppen, Rollen und Authentifizierungsmechanismen verwaltet. Gleichzeitig liefert Entra ID Signale zur Risikobewertung, etwa im Kontext von Anmeldeverhalten oder potenziellen Kompromittierungen.

Intune ergänzt diese Perspektive um den Gerätezustand. Geräte werden kontinuierlich bewertet, etwa hinsichtlich Compliance, Sicherheitskonfiguration oder Patch-Stand. Diese Informationen sind entscheidend, um zu beurteilen, ob ein Gerät als vertrauenswürdig gilt.

Conditional Access fungiert schließlich als verbindende Instanz. Auf Basis der Identität und des Gerätezustands werden Zugriffsrichtlinien durchgesetzt. Ein Zugriff kann beispielsweise nur dann erlaubt werden, wenn sowohl die Identität als auch das verwendete Gerät definierte Sicherheitsanforderungen erfüllen.

Dieses Zusammenspiel bildet die technische Grundlage für Zero-Trust-Architekturen, in denen kein Zugriff per se als vertrauenswürdig gilt, sondern kontinuierlich überprüft wird.

Design Patterns für administrative Zugriffe

Besonders kritisch sind Zugriffe mit erhöhten Rechten. Für administrative Konten gelten daher strengere Anforderungen, die über Standardrichtlinien hinausgehen müssen.

Ein bewährtes Design Pattern besteht darin, administrative Zugriffe konsequent zu isolieren. Administrator:innen arbeiten nicht mit ihren regulären Konten, sondern nutzen dedizierte Identitäten für privilegierte Aufgaben. Diese Konten unterliegen verschärften Conditional-Access-Richtlinien, etwa durch verpflichtende phishing-resistente Authentifizierung und eingeschränkte Zugriffskontexte.

Darüber hinaus sollten administrative Zugriffe an den Zustand des verwendeten Geräts gebunden sein. Zugriffe erfolgen idealerweise ausschließlich von als compliant bewerteten und speziell gehärteten Systemen, etwa Privileged Access Workstations. Dadurch wird sichergestellt, dass administrative Aktionen nicht aus potenziell kompromittierten Umgebungen heraus durchgeführt werden.

Ein weiteres zentrales Muster besteht in der konsequenten Trennung von Rollen und Zugriffsebenen. Administrative Rechte werden nicht dauerhaft genutzt, sondern über Mechanismen wie PIM temporär aktiviert und anschließend wieder entzogen. Conditional Access kann diesen Prozess zusätzlich absichern, indem erhöhte Anforderungen an die Authentifizierung während der Aktivierungsphase gestellt werden.

Typische Fehlkonfigurationen in der Praxis

Trotz leistungsfähiger Sicherheitsmechanismen kommt es in der Praxis häufig zu Schwachstellen, die auf fehlerhafte oder unvollständige Konfigurationen zurückzuführen sind. Diese Schwachstellen entstehen selten aufgrund mangelnder technologischer Möglichkeiten, sondern meist durch unklare Architekturentscheidungen oder eine inkonsistente Umsetzung der Sicherheitsvorgaben. In vielen Fällen werden Sicherheitsmechanismen zwar implementiert, jedoch nicht mit der nötigen Sorgfalt und Konsequenz.

Ein typisches Beispiel für eine solche Fehlkonfiguration ist die zu allgemeine Definition von Conditional-Access-Richtlinien. Wenn alle Benutzer:innen identisch behandelt werden und keine differenzierten Schutzmechanismen für privilegierte Konten existieren, entstehen unnötige Risiken. Besonders kritische Zugriffe werden dadurch nicht ausreichend abgesichert, was die Angriffsfläche für potenzielle Bedrohungen erhöht.

Ebenso problematisch ist eine mangelnde Verknüpfung zwischen Gerätezustand und Zugriffskontrolle. Werden Compliance-Informationen aus Intune nicht konsequent in die Conditional-Access-Entscheidungen integriert, verlieren zentrale Sicherheitsmechanismen ihre Wirkung. Dadurch kann es passieren, dass Zugriffe von unsicheren oder nicht konformen Geräten ermöglicht werden und somit das Sicherheitsniveau der gesamten Umgebung sinkt.

Ein weiterer kritischer Punkt ist die fehlende Absicherung von administrativen Zugängen. Wenn privilegierte Konten nicht durch zusätzliche Anforderungen geschützt werden oder von beliebigen Geräten aus genutzt werden können, entsteht ein erhebliches Angriffspotenzial. Die Gefahr, dass Angreifer administrative Rechte missbrauchen, steigt deutlich, sofern keine klaren Zugriffsregeln und Schutzmechanismen existieren.

Darüber hinaus zeigt sich in vielen Umgebungen, dass zwar Richtlinien definiert werden, diese jedoch nicht konsequent überwacht oder weiterentwickelt werden. Ohne regelmäßige Überprüfung schleichen sich Sicherheitslücken ein, beispielsweise durch veränderte Anforderungen oder neue Angriffsszenarien. Die fortlaufende Anpassung und Überwachung der Sicherheitsrichtlinien ist daher unerlässlich, um das Schutzniveau dauerhaft zu gewährleisten.

Insgesamt wird deutlich, dass Conditional Access nicht isoliert betrachtet werden darf. Erst durch das Zusammenspiel mit Identität und Gerätezustand entsteht eine wirksame Ebene zur Durchsetzung von Sicherheitsanforderungen, die Zero-Trust-Prinzipien technisch umsetzt und für eine kontinuierliche Kontrolle sorgt.

Identity als Fundament: Die eigentliche Kontrollinstanz moderner Sicherheitsarchitekturen

Die bisherigen Betrachtungen haben verdeutlicht, dass Microsoft Intune als zentrale Steuerungsinstanz innerhalb moderner IT-Architekturen fungiert und Sicherheitsmechanismen über verschiedene Ebenen hinweg orchestriert. Gleichzeitig wird jedoch klar: Diese Steuerung basiert nicht primär auf Geräten oder Richtlinien – sondern auf Identitäten.

Der zugrunde liegende Paradigmenwechsel ist dabei fundamental. Während klassische Sicherheitsmodelle auf klar definierten Netzwerkgrenzen beruhten, verlagert sich die Kontrollinstanz in modernen Cloud-Umgebungen konsequent auf die Identität. Sie ist nicht mehr nur ein Zugangselement, sondern das zentrale Steuerungsobjekt der gesamten Architektur.

Unabhängig davon, wie granular Berechtigungen modelliert, wie restriktiv Conditional-Access-Richtlinien definiert oder wie sicher Endgeräte konfiguriert sind – jede Entscheidung innerhalb dieser Architektur beginnt mit einer Identität. Damit wird Identity Security nicht zu einem Teilaspekt, sondern zur tragenden Grundlage der gesamten Sicherheitsstrategie.

Identity Security als Abhängigkeitsebene von Intune

Microsoft Intune ist tief in das Identitätsmodell von Microsoft Entra ID integriert. Jede administrative Aktion, jede Richtlinienzuweisung und jede Geräteinteraktion ist unmittelbar an eine authentifizierte Identität gebunden. Daraus ergibt sich eine zentrale Abhängigkeit: Die Sicherheitswirkung von Intune ist direkt gekoppelt an die Integrität der zugrunde liegenden Identitäten.

Wird eine Identität kompromittiert, verliert die darüber gesteuerte Sicherheitsarchitektur einen wesentlichen Teil ihrer Wirksamkeit. Angreifer agieren nicht mehr gegen Schutzmechanismen, sondern innerhalb legitimierter Zugriffspfade. Sie nutzen vorhandene Berechtigungen, umgehen klassische Sicherheitsgrenzen und bewegen sich entlang der vorgesehenen Steuerungslogik der Plattform.

Diese Perspektive ist entscheidend für das Verständnis moderner Angriffsszenarien. Ziel ist nicht mehr primär die technische Schwachstelle eines Systems, sondern die Übernahme der Identität, die dieses System steuert. Identitäten werden damit zu hochkritischen Angriffszielen – und zugleich zu den sensibelsten Kontrollpunkten der Architektur.

Privilegierte Identitäten, Anwendungen und Token als Risikofaktoren

Die Absicherung von Identitäten umfasst weit mehr als klassische Benutzerkonten. Besonders kritisch sind privilegierte Rollen, Service Principals sowie Enterprise Applications, die häufig im Hintergrund operieren und dennoch weitreichende Steuerungsrechte besitzen.

Privileged Identity Management (PIM) adressiert diese Herausforderung, indem es privilegierte Zugriffe zeitlich begrenzt, nachvollziehbar macht und an zusätzliche Prüfmechanismen bindet. Gleichzeitig entsteht jedoch eine zweite, oft unterschätzte Ebene: nicht-interaktive Identitäten und tokenbasierte Zugriffskonzepte.

Token-basierte Authentifizierung ermöglicht effiziente und skalierbare Zugriffsmodelle, bringt jedoch inhärente Risiken mit sich. Ein einmal ausgestelltes Token kann innerhalb seiner Gültigkeitsdauer genutzt werden, ohne dass eine erneute Authentifizierung erforderlich ist. In Kombination mit umfangreichen Berechtigungen entsteht daraus ein potenziell kritischer Angriffsvektor.

Im Kontext von Intune gewinnt dieser Aspekt besondere Relevanz. Tokens können nicht nur auf Daten zugreifen, sondern auch Managementfunktionen ausführen. Ein kompromittiertes Token ermöglicht somit nicht lediglich Einsicht, sondern aktive Einflussnahme auf Konfigurationen und Richtlinien – und damit auf die Steuerungslogik der gesamten Umgebung.

Operative Vertiefung durch spezialisierte Analysen

Die Komplexität moderner Identity- und Cloud-Sicherheitsarchitekturen lässt sich nur begrenzt innerhalb eines einzelnen Beitrags abbilden. Für die operative Umsetzung ist daher die gezielte Vertiefung einzelner Themenbereiche essenziell.

Insbesondere in den Bereichen Conditional Access, Identity Protection und Token-Sicherheit existieren spezialisierte Analysen, die konkrete Implementierungsansätze, typische Fehlkonfigurationen und bewährte Betriebsmodelle adressieren. Beiträge von Expert:innen wie Aaron Siller liefern hier wertvolle Einblicke, indem sie konzeptionelle Grundlagen mit praktischen Erfahrungen verknüpfen.

Die Einbindung solcher Deep Dives erweitert die architektonische Perspektive um eine operative Dimension. Sie unterstützt dabei, theoretische Sicherheitsprinzipien in belastbare Implementierungen zu überführen und die eigene Sicherheitsstrategie kontinuierlich zu validieren und weiterzuentwickeln.

Kernaussage: Identität definiert die Sicherheitsgrenze

Aus der Gesamtbetrachtung ergibt sich eine zentrale Erkenntnis: Die Sicherheitswirkung von Intune ist untrennbar mit der Sicherheit der zugrunde liegenden Identitäten verbunden.

Investitionen in Geräteschutz, Richtlinien und Managementprozesse entfalten nur dann ihre volle Wirkung, wenn die Identitätsebene konsequent abgesichert ist. Authentifizierung, Autorisierung und Token-Management bilden die erste und zugleich kritischste Verteidigungslinie moderner IT-Architekturen.

Damit schließt sich der Kreis zur übergeordneten Security-in-Depth-Strategie. Identität, Kontrolle und Durchsetzung sind keine isolierten Komponenten, sondern eng verzahnte Elemente eines ganzheitlichen Sicherheitsmodells. Erst ihr abgestimmtes Zusammenspiel ermöglicht eine nachhaltige, belastbare und zukunftsfähige Sicherheitsarchitektur.

Evolution der Gerätesteuerung: Declarative Device Management (DDM)

Die Art und Weise, wie Geräte verwaltet und gesteuert werden, befindet sich aktuell in einem grundlegenden Wandel. Während klassische Managementansätze stark auf direkte Steuerung und zentrale Kontrolle setzen, entwickelt sich die Architektur zunehmend hin zu deklarativen Modellen. Dieser Übergang lässt sich exemplarisch am Konzept des Declarative Device Management (DDM) nachvollziehen, das insbesondere im Apple-Ökosystem (iOS und iPadOS) zunehmend an Bedeutung gewinnt und auch in Intune integriert wird.

Imperatives vs. deklaratives Management

Die traditionelle Geräteverwaltung orientiert sich am imperativen Ansatz, bei dem das Management-System konkrete Befehle an das Endgerät sendet. Dieser Command-and-Control-Ansatz setzt auf eine zentrale Steuerung: Das System sorgt kontinuierlich dafür, dass der gewünschte Zustand aktiv durchgesetzt wird.

In der Praxis zeigt sich, dass Änderungen explizit vom Management-System angestoßen werden müssen. Diese werden überwacht und gegebenenfalls erneut ausgeführt, falls der Zielzustand nicht erreicht oder aufrechterhalten wird. Die Intelligenz liegt dabei primär auf Seiten des Management-Systems, während das Endgerät vor allem als ausführende Instanz agiert und nur die erhaltenen Anweisungen umsetzt.

Im Gegensatz dazu steht das deklarative Modell. Hier wird nicht mehr festgelegt, wie ein Zustand zu erreichen ist, sondern welcher Zustand gelten soll. Das Endgerät erhält eine Beschreibung des angestrebten Zielzustands und übernimmt selbst die Verantwortung, diesen Zustand herzustellen sowie aufrechtzuerhalten.

Die Verlagerung eines Teils der Logik vom zentralen Management-System auf das Endgerät führt zu einer flexibleren und resilienteren Architektur. Das Endgerät ist nicht mehr bloß ein Empfänger von Befehlen, sondern agiert eigenständiger und kann auf Abweichungen selbst reagieren, was die Stabilität und Anpassungsfähigkeit der Gesamtarchitektur erhöht.

Funktionsweise von DDM in Intune (iOS/iPadOS)

Im Rahmen von Microsoft Intune kommt das Declarative Device Management (DDM) insbesondere bei iOS- und iPadOS-Geräten zum Einsatz. Apple bietet hierfür spezielle Frameworks, die es ermöglichen, Gerätekonfigurationen nicht mehr als einzelne Befehle, sondern als deklarative Beschreibungen eines gewünschten Zielzustands zu übermitteln. Dadurch wird die Verwaltung von Geräten erheblich flexibler und effizienter.

Intune überträgt anstatt sequenzieller Befehle eine umfassende Beschreibung des Zielzustands an die Geräte. Diese Beschreibung enthält beispielsweise Sicherheitsrichtlinien, Konfigurationsparameter sowie Compliance-Anforderungen. Das Endgerät erhält dadurch einen klar definierten Rahmen, innerhalb dessen es selbstständig agiert und die Vorgaben lokal umsetzt.

Die Umsetzung erfolgt direkt auf dem Gerät: Es interpretiert die erhaltenen Vorgaben eigenständig und sorgt dafür, dass der definierte Zustand hergestellt und aufrechterhalten wird. Das Endgerät ist in der Lage, Veränderungen im eigenen Zustand selbstständig zu erkennen und darauf zu reagieren, ohne dass jede Anpassung erneut von Intune angestoßen werden muss. Dies erhöht die Autonomie und die Resilienz der Geräteverwaltung.

Ein wesentlicher Vorteil dieses Ansatzes liegt darin, dass das Gerät nicht mehr als reine Ausführungsinstanz fungiert, sondern aktive Verantwortung für die Einhaltung des gewünschten Zustands übernimmt. Dadurch wird die Architektur insgesamt flexibler und kann auf unerwartete Abweichungen oder lokale Besonderheiten besser reagieren.

Ebenso wichtig ist die kontinuierliche Rückmeldung des aktuellen Gerätezustands. Die Geräte liefern fortlaufend Statusinformationen, sodass Abweichungen vom gewünschten Zustand nahezu in Echtzeit erkannt werden können. Dies ermöglicht eine schnelle Reaktion und eine hohe Transparenz im Gerätemanagement.

Vorteile: Stabilität, Skalierbarkeit und Echtzeitstatus

Der Übergang zu deklarativen Modellen bringt mehrere wesentliche Vorteile mit sich. Einer der wichtigsten Aspekte ist die erhöhte Stabilität. Da Geräte eigenständig auf Zustandsabweichungen reagieren können, reduziert sich die Abhängigkeit von kontinuierlicher zentraler Steuerung. Temporäre Verbindungsprobleme oder Verzögerungen wirken sich dadurch deutlich weniger stark aus.

Darüber hinaus reduziert der deklarative Ansatz technische Reibungsverluste, die in klassischen, imperativen Modellen häufig auftreten. Wenn die zentrale Steuereinheit nicht in der Lage ist, gerätespezifische Einstellungen korrekt oder vollständig bereitzustellen, entstehen Inkonsistenzen oder Fehlkonfigurationen. Durch die zentrale Definition des gewünschten Zielzustands und die lokale Umsetzung auf dem Endgerät wird dieses Problem deutlich entschärft, da das Gerät selbst die bestmögliche Umsetzung innerhalb seiner Systemlogik vornimmt.

Auch die Skalierbarkeit verbessert sich signifikant. In großen Umgebungen entfällt die Notwendigkeit, jede einzelne Änderung aktiv zu orchestrieren. Stattdessen wird der gewünschte Zustand einmal definiert und anschließend dezentral umgesetzt.

Ein weiterer Vorteil liegt in der verbesserten Transparenz. Durch kontinuierliche Statusmeldungen entsteht ein nahezu Echtzeitbild des aktuellen Gerätezustands. Dies ermöglicht schnellere Reaktionen auf Abweichungen und unterstützt sowohl den operativen Betrieb als auch Sicherheitsanalysen.

Architektonischer Wandel: Von Command-and-Control zu Desired State

Der Einsatz von Declarative Device Management markiert einen grundlegenden architektonischen Wandel. Während klassische Ansätze auf direkte Steuerung setzen, verschiebt sich der Fokus hin zur Beschreibung und Durchsetzung eines gewünschten Zielzustands.

Dieser Übergang lässt sich als Wechsel von einem Command-and-Control-Modell hin zu einem Desired-State-Modell beschreiben. Die zentrale Instanz definiert nicht mehr jede einzelne Aktion, sondern formuliert die Rahmenbedingungen, innerhalb derer sich Geräte selbstständig konfigurieren und stabilisieren.

Diese Entwicklung fügt sich nahtlos in moderne IT-Architekturen ein. Ähnliche Prinzipien finden sich bereits in Bereichen wie Infrastructure as Code, Cloud-Native-Design oder Policy-driven Security.

Im Kontext von Intune bedeutet dies, dass Gerätemanagement zunehmend intelligenter, autonomer und resilienter wird. Gleichzeitig steigen jedoch auch die Anforderungen an das Design der Zielzustände, da diese präzise definiert und konsistent umgesetzt werden müssen.

Cloud Policy Preferences: Erweiterung des Intune-Steuerungsmodells

Die Transformation von klassischer Active-Directory-basierter Verwaltung hin zu cloudbasierten Modellen bringt nicht nur neue Möglichkeiten, sondern auch funktionale Lücken mit sich. Eine dieser Lücken betrifft die feingranulare Konfiguration von Systemen, wie sie in der On-Premises-Welt über Group Policy Preferences (GPP) etabliert war.

Mit der Einführung von Cloud Policy Preferences entsteht nun ein Ansatz, diese Lücke im Modern Workplace gezielt zu schließen.

Rückblick auf Group Policy Preferences (GPP)

In klassischen Active-Directory-Umgebungen stellten Group Policy Preferences eine flexible Ergänzung zu klassischen Gruppenrichtlinien dar. Während Richtlinien strikt durchgesetzt wurden, ermöglichten Preferences eine weniger restriktive, aber sehr praxisnahe Konfiguration von Systemen.

Typische Einsatzszenarien umfassten:

• Anlegen von Verknüpfungen
• Erstellen geplanter Aufgaben
• Konfiguration von Netzlaufwerken und Druckern
• Setzen von Registry-Werten
• Verteilen von Dateien

Gerade im operativen Alltag erwiesen sich GPP als unverzichtbares Werkzeug, da sie Konfigurationsaufgaben abbildeten, die über klassische Richtlinien hinausgingen.

Funktionale Lücke beim Wechsel zu Intune

Mit dem Übergang zu Microsoft Intune als cloudbasierte Managementplattform wurde eine zentrale funktionale Lücke sichtbar. Zahlreiche etablierte Szenarien aus den Group Policy Preferences (GPP) ließen sich zunächst nur eingeschränkt oder mit unverhältnismäßigem Aufwand abbilden. Insbesondere die Kombination aus Flexibilität und operativer Praxistauglichkeit, die GPP auszeichnete, fehlte in der frühen Intune-Welt.

Zwar bietet Intune ein breites Spektrum an Konfigurationsmöglichkeiten über Richtlinien, Einstellungskataloge und Skripte, jedoch fehlte lange ein konsistentes Modell für typische Preference-Szenarien. In der Praxis führte dies dazu, dass Administratoren auf individuelle Lösungen ausweichen mussten – häufig in Form von PowerShell-Skripten oder komplexen Automatisierungslogiken.

Die daraus resultierende Fragmentierung hatte unmittelbare Auswirkungen auf den Betrieb. Unterschiedliche Lösungsansätze mussten parallel gepflegt, angepasst und miteinander kombiniert werden. Dies erhöhte nicht nur den administrativen Aufwand, sondern auch die Komplexität und Fehleranfälligkeit der Umgebung. Die fehlende Standardisierung im Umgang mit nicht sicherheitskritischen, aber betrieblich relevanten Konfigurationen entwickelte sich damit zu einem strukturellen Defizit im Modern-Management-Ansatz.

Einführung von Cloud Policy Preferences

Cloud Policy Preferences adressieren diese Lücke auf konzeptioneller Ebene. Der Ansatz greift die Grundidee der Group Policy Preferences auf, überführt sie jedoch in ein cloudbasiertes, identitätszentriertes Steuerungsmodell.

Im Kern geht es darum, wiederkehrende Konfigurationsanforderungen nicht mehr isoliert oder skriptbasiert umzusetzen, sondern in eine zentrale, strukturierte und wiederverwendbare Logik zu überführen. Dabei stehen nicht die Ablösung klassischer Richtlinienmechanismen im Vordergrund, sondern deren gezielte Ergänzung.

Cloud Policy Preferences erweitern somit die bestehende Intune-Architektur um eine zusätzliche Ebene: Neben strikt durchgesetzten Policies entsteht ein flexibler Mechanismus zur Abbildung operativer Anforderungen. Diese Integration erfolgt nahtlos innerhalb der bestehenden Entra-ID- und Intune-Strukturen und fügt sich damit konsistent in das identitätsbasierte Steuerungsmodell moderner IT-Umgebungen ein.

Inhalte und Möglichkeiten

Cloud Policy Preferences fokussieren gezielt jene Konfigurationsszenarien, die im täglichen Betrieb regelmäßig auftreten, jedoch keine zwingend sicherheitskritische Durchsetzung erfordern. Ihr Mehrwert liegt in der strukturierten und standardisierten Abbildung solcher Anforderungen innerhalb eines konsistenten Modells.

Typische Einsatzbereiche umfassen die Bereitstellung und Verwaltung von Dateien, die Definition geplanter Aufgaben, die Einbindung von Netzlaufwerken und Druckern, die Erstellung von Verknüpfungen sowie die Konfiguration von Registry-Einstellungen. Diese Szenarien waren bislang häufig Gegenstand individueller Skriptlösungen und damit nur eingeschränkt standardisierbar.

Durch die Integration in ein zentrales Steuerungsmodell werden diese Konfigurationsaufgaben nun vereinheitlicht umgesetzt. Anstelle isolierter Einzelmaßnahmen entsteht ein wiederverwendbarer Ansatz, der sich in bestehende Management- und Automatisierungsstrategien integrieren lässt.

Das Ergebnis ist eine deutlich verbesserte Wartbarkeit und Nachvollziehbarkeit der Konfigurationen. Gleichzeitig wird der operative Aufwand reduziert, da weniger individuelle Sonderlösungen erforderlich sind. Cloud Policy Preferences leisten damit einen wesentlichen Beitrag zur Standardisierung administrativer Prozesse und zur Reduktion struktureller Komplexität in modernen IT-Umgebungen.

Technische Umsetzung

Die technische Umsetzung von Cloud Policy Preferences beruht auf einer Kombination moderner Cloud- und Automatisierungsmechanismen. Im Zentrum steht dabei der Einsatz von Azure Functions, mit denen Konfigurationslogik zentral bereitgestellt, versionskontrolliert verwaltet und skalierbar ausgeführt werden kann. Diese Logik definiert den angestrebten Soll-Zustand der jeweiligen Konfiguration und ermöglicht eine flexible und nachhaltige Steuerung.

Die tatsächliche Umsetzung auf den Endgeräten erfolgt über PowerShell-basierte Remediation-Mechanismen, wie sie bereits in Microsoft Intune etabliert sind. Remediation beschreibt ein zweistufiges Verfahren: Zunächst wird der aktuelle Zustand eines Systems erkannt (Detection). Im Falle einer Abweichung vom definierten Soll-Zustand erfolgt anschließend automatisch eine Korrektur (Remediation), um die gewünschte Konfiguration wiederherzustellen.

Konkret bedeutet dies, dass ein Gerät regelmäßig mithilfe definierter Skripte überprüft, ob beispielsweise ein bestimmter Registry-Wert, eine Datei oder eine geplante Aufgabe vorhanden ist. Wird festgestellt, dass der gewünschte Zustand nicht erfüllt ist, greift unmittelbar die Remediation-Logik und stellt die korrekte Konfiguration wieder her. Dieses Verfahren folgt dem Prinzip der kontinuierlichen Zustandsvalidierung und -korrektur und gewährleistet eine stabile und verlässliche Umsetzung der Anforderungen.

Im Gegensatz zu klassischen, einmalig angewendeten Konfigurationen entsteht so ein zyklischer Prozess: Systeme werden fortlaufend überwacht und bei Bedarf automatisiert in den gewünschten Zustand zurückgeführt. Diese dynamische und adaptive Steuerung ist insbesondere in cloudbasierten Umgebungen von zentraler Bedeutung, da sie auf Veränderungen flexibel reagieren kann und damit die Stabilität im Alltag erhöht.

Die Integration in Entra ID sorgt dafür, dass Zuweisungen und Zielgruppensteuerung konsistent über Identitäten und Gruppen erfolgen. Geräte und Benutzer erhalten die relevanten Mechanismen basierend auf ihrer Zugehörigkeit, was eine nahtlose Einbindung in bestehende Compliance- und Conditional-Access-Strategien ermöglicht.

Insgesamt entsteht dadurch ein flexibles und zugleich robustes Steuerungsmodell: Die zentrale Konfigurationslogik, automatisierte Zustandsprüfung und dynamische Korrekturmechanismen greifen ineinander und ermöglichen eine präzise, skalierbare und nachhaltige Umsetzung selbst komplexer Konfigurationsanforderungen.

Bewertung: Ergänzung zu Intune, kein Ersatz

Cloud Policy Preferences sind nicht als Ersatz für bestehende Intune-Funktionalitäten zu verstehen, sondern als gezielte Erweiterung innerhalb der Gesamtarchitektur. Sie adressieren spezifische Anforderungen, die durch klassische Richtlinien nur eingeschränkt oder mit unverhältnismäßigem Aufwand abgebildet werden können.

Während Intune-Richtlinien weiterhin die zentrale Rolle bei der Durchsetzung sicherheitsrelevanter und verbindlicher Konfigurationen übernehmen, schaffen Cloud Policy Preferences eine zusätzliche Ebene für operative Anpassungen. Sie ermöglichen es, praxisnahe Anforderungen flexibel umzusetzen, ohne die Stabilität und Klarheit der übergeordneten Richtlinienstruktur zu beeinträchtigen.

Diese Differenzierung folgt einem bewährten Prinzip aus der klassischen Windows-Welt, das auch in modernen Architekturen weiterhin Bestand hat. Policies definieren verbindliche Rahmenbedingungen und Sicherheitsanforderungen, die konsequent eingehalten werden müssen. Preferences hingegen unterstützen den operativen Betrieb, indem sie Konfigurationen bereitstellen, die sinnvoll, aber nicht zwingend sicherheitskritisch sind.

In der Kombination entsteht ein ausgewogenes Modell: Klare, strikt durchgesetzte Sicherheitsrichtlinien bilden das Fundament, während flexible Mechanismen wie Cloud Policy Preferences die notwendige Anpassungsfähigkeit im Alltag ermöglichen. Genau dieses Zusammenspiel ist entscheidend, um sowohl Stabilität als auch Praxisnähe in modernen IT-Umgebungen sicherzustellen.

Brücke zwischen AD-Welt und Cloud

Ein besonderer Mehrwert von Cloud Policy Preferences liegt in ihrer Funktion als verbindendes Element zwischen der klassischen Active-Directory-Welt und modernen, cloudbasierten Architekturen. Sie schaffen eine Kontinuität in der Steuerung, die es Organisationen ermöglicht, den Übergang schrittweise und kontrolliert zu gestalten.

Gerade in Transformationsphasen, in denen On-Premises- und Cloud-Modelle parallel existieren, entsteht häufig die Herausforderung, etablierte Betriebsprozesse mit neuen Technologien in Einklang zu bringen. Cloud Policy Preferences greifen hier bekannte Konzepte aus der AD- und GPO-Welt auf und übertragen sie in ein modernes, cloudfähiges Modell. Dadurch bleiben vertraute Denkweisen und Arbeitsmuster erhalten, während gleichzeitig die Vorteile einer identitätszentrierten Steuerung genutzt werden können.

Diese Brückenfunktion hat nicht nur technische, sondern auch organisatorische Relevanz. Sie reduziert die Komplexität der Migration, erleichtert den Wissenstransfer innerhalb von IT-Teams und ermöglicht eine evolutionäre Weiterentwicklung bestehender Strukturen, anstatt einen vollständigen Bruch mit bisherigen Modellen zu erzwingen.

Gleichzeitig unterstützen Cloud Policy Preferences die strategische Neuausrichtung hin zu einer cloudbasierten IT-Architektur. Sie helfen dabei, klassische Anforderungen in moderne Steuerungsmodelle zu überführen und tragen so dazu bei, dass sich Organisationen konsequent in Richtung einer identitäts- und kontextbasierten Verwaltung entwickeln können.

Damit leisten sie nicht nur einen funktionalen Beitrag zur Erweiterung von Intune, sondern wirken als Katalysator für die gesamte Transformation moderner IT-Landschaften.

Typische Schwachstellen in realen Umgebungen

Trotz moderner Werkzeuge und klar definierter Best Practices zeigt sich in der Praxis ein wiederkehrendes Muster: Sicherheitslücken entstehen selten durch fehlende Technologie, sondern durch unzureichende oder inkonsistente Umsetzung. Gerade in Intune- und Microsoft-365-Umgebungen lassen sich typische Schwachstellen identifizieren, die sich durch viele Organisationen hinweg wiederholen.

Diese Schwachstellen sind häufig das Ergebnis historischer Entwicklungen, pragmatischer Entscheidungen oder fehlender architektonischer Leitlinien. Umso wichtiger ist es, sie systematisch zu erkennen und gezielt zu adressieren.

Überprivilegierte Rollen

Eine der häufigsten Schwachstellen liegt in übermäßig weit gefassten Berechtigungen. Administrative Rollen werden oft zu großzügig vergeben, um operative Flexibilität zu gewährleisten oder kurzfristige Anforderungen zu erfüllen.

In der Folge entstehen jedoch Risiken, da kompromittierte Konten mit weitreichenden Rechten erhebliche Auswirkungen auf die gesamte Umgebung haben können. Besonders kritisch ist dies in Kombination mit fehlender Segmentierung oder unzureichender Nutzung von RBAC und Scope Tags.

Eine konsequente Umsetzung des Least-Privilege-Prinzips sowie die Nutzung von Just-in-Time-Mechanismen sind hier zentrale Gegenmaßnahmen.

Schwache Authentifizierung

Ein weiterer kritischer Punkt ist die Absicherung von Identitäten. In vielen Umgebungen wird zwar Multi-Faktor-Authentifizierung eingesetzt, jedoch häufig in einer Form, die nicht gegen moderne Angriffe resistent ist.

Phishing-basierte Angriffe, MFA-Fatigue oder Token-Missbrauch können klassische Authentifizierungsverfahren umgehen. Besonders problematisch ist dies bei privilegierten Konten, die häufig nicht ausreichend durch stärkere Verfahren wie FIDO2 oder Windows Hello for Business geschützt sind.

Eine konsequente Umstellung auf phishing-resistente Authentifizierung ist daher ein wesentlicher Bestandteil moderner Sicherheitsstrategien.

Fehlende oder unzureichende Compliance Policies

Compliance-Richtlinien bilden die Grundlage für die Bewertung des Gerätezustands. Dennoch zeigt sich in der Praxis häufig, dass diese entweder gar nicht definiert oder nur rudimentär umgesetzt sind.

Ohne klare Compliance-Bewertung fehlt eine zentrale Entscheidungsbasis für Conditional Access. Geräte können dann auf Ressourcen zugreifen, ohne dass ihr Sicherheitszustand zuverlässig überprüft wird.

Eine saubere Definition und konsequente Durchsetzung von Compliance Policies ist daher entscheidend, um den Gerätezustand als Sicherheitskriterium wirksam zu nutzen.

Keine Absicherung kritischer Aktionen

In vielen Umgebungen fehlt eine gezielte Absicherung besonders sensibler administrativer Aktionen. Maßnahmen wie Device Wipe, Skriptausführung oder Rollenänderungen können häufig ohne zusätzliche Freigabe durchgeführt werden.

Dies erhöht sowohl das Risiko gezielter Angriffe als auch die Wahrscheinlichkeit unbeabsichtigter Fehlkonfigurationen. Ohne Mechanismen wie Multi Admin Approval entsteht hier ein direkter Angriffspunkt innerhalb der Verwaltungsplattform.

Die Einführung von Freigabeprozessen für kritische Aktionen stellt daher einen wichtigen Baustein zur Risikominimierung dar.

Unzureichendes Monitoring

Ein weiterer zentraler Schwachpunkt liegt im Bereich Monitoring und Transparenz. In vielen Umgebungen werden administrative Aktivitäten zwar protokolliert, jedoch nicht aktiv ausgewertet oder in Sicherheitsprozesse integriert.

Dadurch bleiben auffällige Muster, ungewöhnliche Änderungen oder potenziell kompromittierte Konten häufig lange unentdeckt. Gerade in cloudbasierten Umgebungen, in denen Angriffe oft subtil und über legitime Mechanismen erfolgen, ist dies besonders kritisch.

Ein wirksames Monitoring erfordert daher nicht nur Logging, sondern auch eine kontinuierliche Auswertung und Integration in Sicherheitsprozesse, etwa über SIEM- oder XDR-Lösungen.

Dieses Kapitel verdeutlicht, dass Sicherheit nicht allein durch Architektur entsteht, sondern durch deren konsequente Umsetzung im operativen Betrieb. Die identifizierten Schwachstellen liefern dabei konkrete Ansatzpunkte, um bestehende Umgebungen systematisch zu überprüfen und gezielt zu verbessern.

Architekturelle Gesamtbetrachtung

Die zuvor betrachteten Aspekte moderner Gerätesicherheit – von Identität über Gerätekontrolle bis hin zu Zugriff und Monitoring – entfalten ihre volle Wirkung erst im Kontext einer konsistenten Gesamtarchitektur. Einzelne Funktionen sind dabei weniger entscheidend als ihr strukturiertes Zusammenspiel.

Ein belastbares Modell lässt sich in drei logisch getrennte, aber eng verzahnte Ebenen gliedern: Identität, Kontrolle und Zugriff.

Identity Layer: Entra ID als Fundament

Die Identität bildet den Ausgangspunkt aller sicherheitsrelevanten Entscheidungen. In Entra ID laufen Authentifizierung, Autorisierung und Risikobewertung zusammen. Mechanismen wie phishing-resistente Authentifizierung, Privileged Identity Management und die Absicherung von Tokens definieren hier das grundlegende Vertrauensniveau. Wird diese Ebene kompromittiert, verlieren nachgelagerte Kontrollen ihre Wirksamkeit.

Control Layer: Intune als Steuerungsinstanz

Aufbauend auf der Identitätsebene definiert Intune den vertrauenswürdigen Gerätezustand. Richtlinien, Compliance-Bewertungen und Konfigurationsvorgaben werden hier umgesetzt.
Mit Ansätzen wie Declarative Device Management verschiebt sich die Steuerung zunehmend von zentraler Kontrolle hin zu einer zustandsbasierten, resilienten Architektur. Ergänzend ermöglichen Cloud Policy Preferences die strukturierte Überführung klassischer Konfigurationsmuster in moderne Cloud-Modelle.

Access Layer: Conditional Access als Durchsetzungsebene

Conditional Access bildet die operative Entscheidungsinstanz. Auf Basis von Identität, Gerätezustand und Kontext wird festgelegt, ob und unter welchen Bedingungen Zugriff gewährt wird. Damit wird das Zero-Trust-Prinzip technisch umgesetzt: Vertrauen ist kein statischer Zustand, sondern das Ergebnis kontinuierlicher Bewertung.

Zusammenspiel der Ebenen

Sicherheit entsteht nicht innerhalb einzelner Schichten, sondern durch ihr koordiniertes Zusammenwirken. Identität definiert den Akteur, Intune bewertet den Zustand des Endgeräts, und Conditional Access setzt die daraus abgeleiteten Anforderungen konsequent durch.

Aus dieser Perspektive wird deutlich, dass Intune kein isoliertes Werkzeug ist, sondern eine zentrale Steuerungskomponente innerhalb einer mehrschichtigen Sicherheitsarchitektur.

Intune im Kontext moderner Sicherheitsarchitekturen

Die Rolle von Microsoft Intune geht weit über klassische Gerätekonfiguration hinaus. Die Plattform wirkt als operative Instanz innerhalb einer Architektur, in der Identität, Gerätezustand und Zugriff dynamisch miteinander verknüpft sind.

Entscheidend ist dabei eine klare Fokusverschiebung: Nicht einzelne Features stehen im Mittelpunkt, sondern deren Einbettung in ein konsistentes Sicherheitsmodell. Richtlinien, Compliance-Prüfungen und Gerätekonfigurationen entfalten ihren Wert erst im Zusammenspiel mit Identitäts- und Zugriffskontrollen.

Diese Integration ist eine zentrale Voraussetzung für die Umsetzung von Zero-Trust-Strategien. Intune liefert den aktuellen Gerätekontext, Entra ID bewertet Identität und Risiko, und Conditional Access kombiniert beide Dimensionen zu einer fundierten Zugriffsentscheidung in Echtzeit.

Gleichzeitig verstärkt Intune bestehende architektonische Qualitäten – sowohl im positiven als auch im negativen Sinne. Sauber definierte Identitätsmodelle, klare Rollenstrukturen und konsistente Zugriffskonzepte werden durch Intune effektiv operationalisiert. Schwächen in diesen Bereichen hingegen werden durch die zentrale Steuerungsfunktion sichtbar und können sich unmittelbar auf das Sicherheitsniveau auswirken.

Die zentrale Herausforderung besteht daher nicht in der Aktivierung möglichst vieler Funktionen, sondern in der Entwicklung einer tragfähigen Architektur. Sicherheit entsteht durch strukturierte Zusammenhänge, nicht durch isolierte Maßnahmen.

Abschlussgedanke

Nachhaltige Sicherheit ist das Ergebnis eines durchdachten Systems. Intune stellt die notwendigen technischen Mechanismen bereit – ihre Wirksamkeit hängt jedoch vollständig von der architektonischen Einbettung ab. Erst das abgestimmte Zusammenspiel von Identität, Kontrolle und Zugriff ermöglicht ein Sicherheitsniveau, das modernen Anforderungen dauerhaft standhält.

Quellenangaben

(Abgerufen am 28.03.2026)

Offizielle Dokumentation

• Microsoft Learn: Common ways to use Conditional Access with Intune
• Microsoft Learn: Integrate Microsoft Defender for Endpoint with Intune for Device Compliance
• Microsoft Learn: Microsoft Intune planning guide
• Microsoft Learn: Microsoft Intune securely manages identities, manages apps, and manages devices
• Microsoft Learn: Use compliance policies to set rules for devices you manage with Intune
• Microsoft Learn: What is Conditional Access?
• Microsoft Learn: What is Microsoft Entra ID?

Sicherheit und Zero Trust

• Aaron Siller (Siller Consulting): Microsoft 365 Security: Tipps zur Härtung Deines Mandanten!
• Dorian Garbe (Softtailor): How does Zero Trust work with Microsoft 365 and Intune?
• Keytos: How to Protect Your Microsoft Intune Environment
• Microsoft Learn: What is Zero Trust?
• Microsoft Learn: Zero Trust security guidance
• Niklas Tinner (Oceanleaf): Top 10 Entra & Intune Security Tips

Sicherheitsvorfälle und Angriffsszenarien

• Cryptika: CISA Urges Organizations to Secure Microsoft Intune Environments Following Stryker Breach
• Dirk-jan Mollema: Extending AD CS attack surface to the cloud with Intune certificates
• James Azar (CyberHub Podcast): Stryker Hack Used Intune to Wipe 200K Devices, China Espionage Hits Asian Militaries, Wing FTP 0-Day
• Rithula Nisha (Cyber Magazine): Stryker Cyberattack: The Case to Secure Microsoft Intune
• Uwe Gradenegger: Attack on the Active Directory via Microsoft Intune – and how it can be contained with TameMyCerts

Best Practices und Sicherheitskonfiguration

• Aymen Eneljaziri (LinkedIn): Intune Security Deep Dive : Enable Tamper Protection to Secure Defender Settings on Windows Devices
• Marco Wohler (Oneconsult): Windows 11 Hardening mit Intune: Methoden und Empfehlungen für eine sichere Umgebung
• Microsoft TechCommunity: Best practices for securing Microsoft Intune
• Nicholas Bock (Medium): These 5 Intune mistakes are ruining your environment.

Conditional Access und Identity Protection

• Aaron Siller (Siller Consulting): Conditional Access Best Practices: Die 5 Must-Have Richtlinien!
• Aaron Siller (Siller Consulting): Entra ID Identity Protection: Dein Guide zur Einrichtung
• Anders Ahl (MSEndpointMgr): Microsoft Conditional Access: Implementation Considerations and Common Mistakes
• Microsoft Learn: Conditional Access with Microsoft Purview
• Microsoft Learn: Configure Conditional Access in Microsoft Defender for Endpoint
• Oktay Sari (AllThingsCloud): A Deep Dive into Location and Device-Based Access Control
• Ulrich Boddenberg: Conditional Access in Microsoft 365

Gerätemanagement und moderne Architektur (DDM, Compliance)

• Apple: Einführung in die deklarative Geräteverwaltung für Apple-Geräte
• Bonpago: Intune Default Device Compliance Policy: Risiken und Best Practices
• Julian Stabentheiner: macOS & iOS Updates mit Intune per DDM effizient verwalten
• Microsoft TechCommunity: Support tip: Move to declarative device management for Apple software updates
• Peter Klapwijk (InTheCloud247): Intune compliance for Windows 365 Cloud PCs
• Somesh Pathak (IntuneIRL): macOS & iOS 26 for Enterprise: DDM, Deployment, and the Intel Mac Sunset

Automatisierung, Erweiterung und neue Funktionen

• Ben Whitmore (MSEndpointMgr): Getting started with Microsoft Security Copilot for Intune
• Maurice Daly (MSEndpointMgr): Introducing Cloud Policy Preferences
• Microsoft Learn: Azure Functions documentation
• Microsoft Learn: Overview of Microsoft Graph
• Microsoft Learn: Remediations
• Ulrich Boddenberg: Management Summary – Warum Labels + Policies + Automation heute Pflicht sind

Migration und Transformation: GPO, Entra ID und Intune

• Angelo Salandanan (ninjaOne): Modern GPO Alternatives: Transitioning to Intune Configuration Profiles
• Benoit Lecours (systemcenterdudes): Migrate Group Policy to Microsoft Intune
• Microsoft Learn: Create a Settings Catalog policy using your imported GPOs in Microsoft Intune
• Ulrich Boddenberg: Entra ID Sync – Praxisleitfaden für IT-Leiter und M365-Administratoren

Logging, Monitoring und SIEM (Intune & Sentinel)

• Aastik Gakhar (Medium): Microsoft Intune Monitoring Walkthrough Notes | TryHackMe
• Benoit Lecours (systemcenterdudes): Understanding Microsoft Intune Logs files for Troubleshooting
• Jeff Johnson (ControlUp): How to Supercharge Microsoft Intune with Real-Time Monitoring and IT Automation
• Microsoft Learn: Intune Reports
• Microsoft Learn: Remote device action: collect diagnostics
• Microsoft Learn: What is Microsoft Sentinel?
• Rod Trent (myITforum): Unlocking the Power of Intune: Monitor and Analyze Device Data to Enhance Security and Compliance

Historische Grundlagen: Identität, Sicherheit und klassische Verwaltung

• Integer IT: Passwords: the end is nigh!
• Microsoft Learn: Group Policy overview for Windows Server
• Microsoft Learn: Group Policy Preferences
• Microsoft: Bill Gates: Microsoft’s Security Vision and Strategy, RSA Conference 2006

Weiterlesen hier im Blog

• Ada Lovelace und ihre Nachfolgerinnen – Frauen in der Geschichte von Computer- und Netzwerktechnologie
• ARPANET, TCP/IP und das World Wide Web – Wie das Internet die Welt vernetzte
• Die Entwicklung des Computers: Von Turing bis zur KI-Workstation
• Externes Routing im Internet und WAN – Architektur, Historie und Bedeutung von BGP
• PowerShell Toolmaking als Architekturfrage – Einordnung und Aufbau der Beitragsreihe
• Wie KI lernt – vom Datenpunkt zur Entscheidung