FAQ

Microsoft Entra ID (ehemals Azure AD) ist ein cloudbasierter Identity Provider für Anwendungen, Geräte und Services. Es ersetzt on‑prem Active Directory (AD DS) nicht 1:1, sondern ergänzt oder löst es je nach Szenario ab: Für SaaS/Cloud‑Apps, SSO und Conditional Access ist Microsoft Entra ID zentral; für Kerberos/LDAP/GPO bleiben AD DS oder alternative Mechanismen relevant. In modernen Zielbildern wird Microsoft Entra ID als primäre Identitätsschicht genutzt, während AD DS für Legacy‑Workloads oder Übergangsphasen weiterbetrieben wird.

Häufige Herausforderungen sind inkonsistente UPNs/SMTP-Adressen, Duplicate/Orphaned Objects, nicht standardisierte OU- und Gruppenstrukturen sowie ein unklarer „Source of Authority“. Technisch relevant sind außerdem Microsoft Entra Connect / Microsoft Entra Cloud Sync Design, Passwort-Hash-Sync vs. Pass‑Through Authentication, Gerätezustände (Microsoft Entra hybrid join, vormals Hybrid Azure AD Join) und sauberes Lifecycle-Management (Joiner/Mover/Leaver).

Bewährt ist ein schrittweises Policy-Design: erst Baseline (MFA für Admins, Block Legacy Auth), dann risikobasierte Policies (Sign-in/User Risk), danach app- und gruppenspezifische Regeln. Wichtig sind Break‑Glass Konten, Exklusionen nur minimal, konsequentes Logging sowie ein „Report‑only“-Rollout mit klaren Change-Fenstern.

MFA erhöht den Faktor‑Mix, ist aber nicht automatisch phishing-resistent (z. B. Push). Passwordless (FIDO2, Windows Hello for Business, Passkeys) reduziert Passwortabhängigkeit. Phishing‑resistant MFA verlangt Methoden, die gegen Token‑Relay/Prompt‑Bombing robust sind (FIDO2, Zertifikat‑basiert, WHfB).

PIM ermöglicht Just‑in‑Time Admin-Rechte, zeitlich begrenzt und mit Approval/Begründung. Das reduziert dauerhafte Privilegien, verbessert Auditierbarkeit und unterstützt Segregation of Duties. Kritisch sind saubere Rollenmodelle, Notfallprozesse und die Integration in Incident Response.

Zero Trust wird in „Identity, Device, App, Data“ operationalisiert: starke Identitäten (CA, PIM), verwaltete Geräte (Intune Compliance), App-Schutz (Defender, App Governance), Datenkontrollen (Purview DLP/Labels) und kontinuierliches Monitoring (Sentinel/Defender XDR). Der pragmatische Ansatz priorisiert die größten Risiken (Admin-Accounts, E-Mail, Exfiltration) statt „Big Bang“.

Kernbausteine sind: Deaktivierung von Legacy Auth, konsequente MFA/CA, saubere SPF/DKIM/DMARC, Defender for Office 365 Policies (Anti‑Phish, Safe Links/Attachments), restriktive Exchange Online Transportregeln sowie ein klarer Prozess für Allow/Block-Listen und False Positives.

Defender for Endpoint schützt Endpoints (EDR, Vulnerability Management), Defender for Office 365 fokussiert auf E‑Mail/Collaboration-Bedrohungen, und Defender XDR korreliert Signale über Workloads hinweg (Identity, Endpoint, Office, Cloud Apps) für konsolidierte Incidents und Response.

Sentinel lohnt sich, wenn Sie Log‑Quellen zentral korrelieren, Use‑Cases automatisieren (SOAR) und Cloud‑Skalierung nutzen möchten. Typische Treiber sind steigende Compliance-Anforderungen, heterogene Security-Tools und der Bedarf an schneller Incident Response. Wichtig ist ein Kosten‑/Ingestion‑Design (Data tiers, Filter, Sampling) und ein priorisiertes Use‑Case‑Backlog.

Definieren Sie zunächst Sicherheits- und Betriebs-Use‑Cases, dann wählen Sie die minimal nötigen Datenquellen. Typisch: Entra Sign‑in/Audit, Defender, Azure Activity, Key Vault, Storage, Firewall, und Workload-Logs. Nutzen Sie Retention/Archive, Basic Logs/Data tiers, und vermeiden Sie „log everything“ ohne Auswertung. Kostensteuerung erfolgt über DCR, Filter, und klare Retentions.

Eine Landing Zone ist ein standardisiertes Fundament (Management Groups, Subscriptions, Netzwerk, Policies, Identity, Logging). Sie reduziert Wildwuchs, beschleunigt Rollouts und erleichtert Governance. Typische Fehler sind zu frühe Überkomplexität oder fehlende Guardrails (Naming, RBAC, Policies).

Ein bewährtes Muster ist Hub‑Spoke mit zentralen Shared Services (Firewall, VPN/ER, DNS). Private Endpoints reduzieren Public Exposure, benötigen aber saubere DNS-Zonen (privatelink.*) und Routing. Häufige Probleme entstehen durch split‑horizon DNS, unklare UDRs und fehlende egress‑Kontrollen.

Setzen Sie auf RBAC/Access Policies konsistent, deaktivieren Sie Public Network Access wo möglich, nutzen Sie Private Endpoints, Key Rotation, und getrennte Vaults für Umgebungen. Für Apps: Managed Identities statt Secrets, und Logging/Alerts auf Secret‑Reads/Key‑Operations.

Azure Policy erzwingt oder auditiert Konfigurationen (Guardrails). Blueprints sind historisch für Paketierung genutzt worden; in vielen Zielbildern werden Policy Initiatives, Terraform/Bicep und Landing‑Zone‑Frameworks bevorzugt. Entscheidend ist: Policy für Compliance‑Durchsetzung, IaC für Provisionierung.

Intune ist geeignet, wenn Sie moderne Geräteverwaltung (Windows, macOS, iOS, Android) zentralisieren, Compliance/Conditional Access koppeln und Zero‑Touch Provisioning (Autopilot) nutzen wollen. Herausforderungen sind App‑Packaging, Legacy‑GPO‑Ablösung, und ein sauberes Rollen‑/Scope‑Design.

Typisch sind falsche Gerätezustände (Hybrid Join Timing), unklare Zuweisungen von Profilen/Apps, Treiber/BIOS‑Abhängigkeiten und zu schwere „ESP“-Phasen. Abhilfe: schlanke Baseline, gestaffelte App‑Rollouts, klare Device Groups und ein Test‑Ring‑Modell.

Starten Sie mit einem Controls‑Mapping (Sicherheitsbaseline, Hardening), identifizieren Sie GPOs ohne MDM‑Äquivalent und definieren Sie Ersatz (Scripts, CSP, ADMX ingest). Rollout via Pilot‑Ringe, koexistente Phase (GPO/MDM) mit Konfliktregeln und messbaren Compliance‑KPIs.

Azure Virtual Desktop (AVD) bietet flexible, skalierbare Multi‑Session/Hostpools und passt gut für variable Lasten oder Spezialapps. Windows 365 ist stärker „SaaS‑artig“ mit planbaren SKUs und einfacherem Betrieb. Entscheidungskriterien sind Kostenprofil, Betriebsmodell, App‑Kompatibilität, Netzwerklatenz und Security (Conditional Access, MFA, Defender).

Definieren Sie Richtlinien für Team-Erstellung (Self‑Service mit Templates), Namenskonventionen, Ablauf/Rezertifizierung, Gastzugriff und externe Föderation. Ergänzend: Sensitivity Labels, DLP, und klare Verantwortlichkeiten (Owner‑Pflichten). Ohne Governance entstehen schnell Daten‑Wildwuchs und Schatten‑IT.

Meist fehlt ein Informationsarchitektur‑Konzept: Site‑Struktur, Berechtigungsmodell, Namensschema, Retention und Archivierung. Technisch problematisch sind zu viele individuelle Berechtigungen, fehlende Sensitivity Labels und unklare Regeln für externe Freigaben.

Beginnen Sie mit einem einfachen Klassifikationsmodell (öffentlich/intern/vertraulich), nutzen Sie Sensitivity Labels inkl. Verschlüsselung, und definieren Sie DLP‑Policies für Kernkanäle (Exchange, SharePoint/OneDrive, Teams). Rollout im Audit‑Modus, dann schrittweise Enforcement. Wichtig: Exceptions/Business‑Flows sauber modellieren, sonst sinkt Akzeptanz.

Klären Sie zuerst regulatorische Aufbewahrungsfristen, dann setzen Sie Purview Retention Labels/Policies und Hold‑Prozesse auf. eDiscovery benötigt Rollen, Case‑Workflows und dokumentierte Export‑Ketten. Kritisch sind klare Scope‑Definitionen und das Zusammenspiel mit Backup/Archiv.

Azure SQL (PaaS) bietet höchste Betriebsabstraktion und Skalierung, ideal für moderne Apps. Managed Instance ist nahe an SQL Server-Kompatibilität (z. B. Agent, Cross‑DB) und eignet sich für Lift‑and‑Shift mit weniger Refactoring. SQL on VM ist IaaS, maximal flexibel, aber mit vollem Betriebsaufwand (Patching, HA, Backup).

AKS ist sinnvoll bei containerisierten Microservices, Bedarf an Skalierung und GitOps/IaC. Scheitern passiert oft durch fehlende Plattform-Standards (Ingress, Observability, Secrets, RBAC), unklare Verantwortlichkeiten („You build it, you run it“), und mangelndes Cost/Capacity‑Management. Starten Sie mit einer Referenzplattform und klaren Guardrails.

Azure Arc erweitert Azure‑Governance, Policies, Inventory und teilweise Services auf On‑prem/Edge und andere Clouds. Nutzen entsteht, wenn Sie einheitliches Management, Compliance und Automatisierung über heterogene Landschaften brauchen. Erfolgsfaktoren sind saubere Tagging‑/Ressourcenmodelle und ein klares Betriebs-Target-Model.

Wichtig ist Konsistenz: ein Toolset, modulare Patterns, Code‑Reviews, Environments und ein Release‑Prozess. Bicep integriert sich eng in ARM; Terraform bietet breite Provider‑Ökosysteme. GitOps ergänzt für Kubernetes. Entscheidend ist nicht das Tool, sondern Standards (Naming, Tags), Secrets‑Handling und Drift‑Kontrolle.

Die größten Risiken sind Datenexposition (zu offene SharePoint/Teams Berechtigungen), fehlende Klassifizierung/Labels, und unklare Nutzungsregeln. Technisch benötigen Sie Identität/CA, Purview‑Kontrollen, Logging sowie ein Enablement‑Programm (Use‑Cases, Prompt‑Guidelines, Governance).

Führen Sie regelmäßige Access Reviews durch, reduzieren Sie globale Admins, nutzen Sie PIM, und implementieren Sie Rollen-basierte Gruppen statt Individualrechte. In SharePoint/Teams helfen Sensitivity Labels, standardisierte Site‑Templates und Rezertifizierung der Owner.

Planen Sie in Phasen: Identity/Domain‑Vorbereitung, Mail (Exchange), Collaboration (Teams/SharePoint/OneDrive), Geräte (Intune) und Security/Compliance. Kritisch sind Koexistenz, Cutover‑Fenster, Datenintegrität und Benutzerkommunikation. Technisch müssen Redirects, Client‑Reprofiles, und Berechtigungsübernahme sauber getestet werden.

Microsoft 365 bietet hohe Verfügbarkeit, ersetzt aber kein fachliches Backup-Konzept. Definieren Sie RPO/RTO, prüfen Sie native Möglichkeiten (Retention, eDiscovery, Versioning) und ergänzen Sie – je nach Risiko – ein Drittanbieter‑Backup für Exchange/SharePoint/OneDrive/Teams. Wichtig sind Restore‑Tests und klare Verantwortlichkeiten.

Starten Sie mit Anforderungen (Security/Compliance Use‑Cases) statt Feature‑Listen. E5 lohnt sich oft, wenn XDR/SIEM/DLP/Insider Risk genutzt werden – andernfalls sind E3 + Add-ons wirtschaftlicher. Entscheidend ist eine Gap‑Analyse: vorhandene Tools vs. Microsoft‑Stack, Betriebsaufwand und Integrationskosten.

Sammeln Sie Incidents/Findings, mappen Sie auf MITRE‑Techniken und priorisieren Sie nach Risiko, Machbarkeit und Datenverfügbarkeit. Starten Sie mit „High signal“ Use‑Cases (Admin Abuse, Impossible Travel, Malware on Endpoint, Phishing) und automatisieren Sie Response-Schritte in Sentinel/Defender. Messen Sie Erfolg über Detection Coverage und Mean Time to Respond.