Identität und darüber hinaus – Sicht eines Architekten

  • Artikel

In diesem Artikel erläutert Alex Shteynberg, Principal Technical Architect bei Microsoft, die wichtigsten Entwurfsstrategien für Unternehmensorganisationen, die Microsoft 365 und andere Microsoft-Clouddienste einführen.

Über den Autor

Alex Shteynberg Foto.

Ich bin Principal Technical Architect im Microsoft Technology Center in New York. Ich arbeite hauptsächlich mit großen Kunden und komplexen Anforderungen. Meine Ansichten und Meinungen basieren auf diesen Interaktionen und können nicht für jede Situation gelten. Wenn wir jedoch Kunden mit den komplexesten Herausforderungen helfen können, können wir meiner Erfahrung nach allen Kunden helfen.

In der Regel arbeite ich jedes Jahr mit mehr als 100 Kunden. Obwohl jedes organization einzigartige Eigenschaften hat, ist es interessant, Trends und Gemeinsamkeiten zu sehen. Ein Trend ist beispielsweise das branchenübergreifende Interesse für viele Kunden. Schließlich kann eine Bankfiliale auch ein Café und ein Gemeindezentrum sein.

In meiner Rolle konzentriere ich mich darauf, Kunden dabei zu helfen, die beste technische Lösung zu finden, um ihre individuellen Geschäftsziele zu erreichen. Offiziell konzentriere ich mich auf Identität, Sicherheit, Datenschutz und Compliance. Ich liebe die Tatsache, dass diese alles berühren, was wir tun. Es gibt mir die Möglichkeit, mich an den meisten Projekten zu beteiligen. Diese Aktivität hält mich beschäftigt und genießt diese Rolle.

Ich lebe in New York City (das Beste!) und genieße wirklich die Vielfalt seiner Kultur, Essen und Menschen (nicht Verkehr). Ich liebe es zu reisen, wenn ich kann und hoffe, den größten Teil der Welt in meinem Leben zu sehen. Ich recherchiere gerade eine Reise nach Afrika, um mehr über Wildtiere zu erfahren.

Leitprinzipien

  • Einfach ist oft besser: Sie können (fast) alles mit Technologie tun, aber es bedeutet nicht, dass Sie es sollten. Vor allem im Sicherheitsbereich übermäßig viele Kunden lösungen. Ich mag dieses Video von Googles Stripe-Konferenz, um diesen Punkt zu unterstreichen.
  • Personen, Prozess, Technologie: Entwerfen sie für Menschen, um den Prozess zu verbessern, nicht tech first. Es gibt keine "perfekten" Lösungen. Wir müssen verschiedene Risikofaktoren und Entscheidungen abwägen, die für jedes Unternehmen unterschiedlich sein können. Zu viele Kunden entwerfen einen Ansatz, den ihre Benutzer später vermeiden.
  • Konzentrieren Sie sich zuerst auf das "Warum" und später auf das "Wie": Seien Sie das lästige 7-jährige Kind mit einer Million Fragen. Wir können nicht zur richtigen Antwort gelangen, wenn wir die richtigen Fragen nicht kennen. Viele Kunden gehen davon aus, wie die Dinge funktionieren müssen, anstatt das Geschäftsproblem zu definieren. Es gibt immer mehrere Pfade, die verwendet werden können.
  • Langes Ende der bewährten Methoden in der Vergangenheit: Erkennen Sie, dass sich bewährte Methoden mit Lichtgeschwindigkeit ändern. Wenn Sie sich Microsoft Entra vor mehr als drei Monaten angesehen haben, sind Sie wahrscheinlich nicht mehr aktuell. Alles hier kann sich nach der Veröffentlichung ändern. "Beste" Option ist heute möglicherweise nicht mehr die gleiche sechs Monate.

Grundlegende Konzepte

Überspringen Sie diesen Abschnitt nicht. Ich finde oft, dass ich zu diesen Artikeln zurücktreten muss, auch für Kunden, die Clouddienste seit Jahren nutzen. Leider ist Sprache kein präzises Werkzeug. Wir verwenden oft dasselbe Wort, um unterschiedliche Konzepte oder andere Wörter zu bedeuten, um dasselbe Konzept zu bedeuten. Ich verwende häufig das folgende Diagramm, um eine grundlegende Terminologie und ein "Hierarchiemodell" festzulegen.

Abbildung von Mandant, Abonnement, Dienst und Daten.

Wenn Sie schwimmen lernen, ist es besser, im Pool und nicht in der Mitte des Ozeans zu beginnen. Ich versuche nicht, mit diesem Diagramm technisch genau zu sein. Es ist ein Modell, um einige grundlegende Konzepte zu besprechen.

Aus dem Diagramm geht Folgendes hervor:

  • Mandant = eine instance von Microsoft Entra ID. Sie befindet sich am "anfang" einer Hierarchie oder im Diagramm auf Ebene 1. Wir können diese Ebene als die "Grenze" betrachten, an der alles andere stattfindet (Microsoft Entra B2B abgesehen). Alle Microsoft Enterprise Cloud Services sind Teil eines dieser Mandanten. Verbraucherdienste sind getrennt. "Mandant" wird in der Dokumentation als Microsoft 365-Mandant, Azure-Mandant, WVD-Mandant usw. angezeigt. Ich finde diese Variationen oft für Verwirrung bei Kunden.
  • Dienste/Abonnements, Ebene 2 im Diagramm, gehören nur zu einem Mandanten. Die meisten SaaS-Dienste sind 1:1 und können ohne Migration nicht verschoben werden. Azure ist anders, Sie können die Abrechnung und/oder ein Abonnement auf einen anderen Mandanten verschieben. Es gibt viele Kunden, die Azure-Abonnements verschieben müssen. Dieses Szenario hat verschiedene Auswirkungen. Objekte, die außerhalb des Abonnements vorhanden sind, werden nicht verschoben. Beispiel: rollenbasierte Zugriffssteuerung (Azure RBAC), Microsoft Entra Objekte (Gruppen, Apps, Richtlinien usw.) und einige Dienste (Azure Key Vault, Data Bricks usw.). Migrieren Sie Dienste nicht ohne eine gute geschäftliche Notwendigkeit. Einige Skripts, die für die Migration hilfreich sein können, werden auf GitHub freigegeben.
  • Ein bestimmter Dienst weist in der Regel eine Art "Unterebene"-Grenze oder Ebene 3 (L3) auf. Diese Grenze ist nützlich, um die Trennung von Sicherheit, Richtlinien, Governance usw. zu verstehen. Leider gibt es keinen einheitlichen Namen, den ich kenne. Einige Beispiele für L3 sind: Azure-Abonnement = Ressource; Dynamics 365 CE = instance; Power BI = Arbeitsbereich; Power Apps = Umgebung; Und so weiter.
  • Auf Ebene 4 befinden sich die tatsächlichen Daten. Diese "Datenebene" ist ein komplexer Artikel. Einige Dienste verwenden Microsoft Entra ID für RBAC, andere nicht. Ich werde es ein wenig besprechen, wenn wir zu Delegierungsartikeln kommen.

Einige andere Konzepte, über die ich viele Kunden (und Microsoft-Mitarbeiter) finde, sind verwirrt oder haben Fragen zu diesem Thema:

  • Jeder kann viele Mandanten kostenloserstellen. Sie benötigen keinen Dienst, der darin bereitgestellt wird. Ich habe Dutzende. Jeder Mandantenname ist im weltweiten Clouddienst von Microsoft eindeutig (mit anderen Worten, keine zwei Mandanten können denselben Namen haben). Sie haben alle das Format TenantName.onmicrosoft.com. Es gibt auch Prozesse, die Mandanten automatisch erstellen (nicht verwaltete Mandanten). Dieses Ergebnis kann beispielsweise auftreten, wenn sich ein Benutzer für einen Unternehmensdienst mit einer E-Mail-Domäne registriert, die in keinem anderen Mandanten vorhanden ist.
  • In einem verwalteten Mandanten können viele DNS-Domänen darin registriert werden. Durch dieses Ergebnis wird der ursprüngliche Mandantenname nicht geändert. Es gibt derzeit keine einfache Möglichkeit, einen Mandanten umzubenennen (mit Ausnahme der Migration). Obwohl der Name des Mandanten heutzutage technisch nicht kritisch ist, fühlen sich einige Personen möglicherweise durch diese Realität eingeschränkt.
  • Sie sollten einen Mandantennamen für Ihre organization reservieren, auch wenn Sie noch keine Dienste bereitstellen möchten. Andernfalls kann jemand es von Ihnen nehmen, und es gibt keinen einfachen Prozess, um es zurückzunehmen (dasselbe Problem wie DNS-Namen). Ich höre das viel zu oft von Kunden. Wie Ihr Mandantname lauten sollte, ist auch ein Diskussionsartikel.
  • Wenn Sie den DNS-Namespace besitzen, sollten Sie all diese Namespaces Ihren Mandanten hinzufügen. Andernfalls könnte ein nicht verwalteter Mandant mit diesem Namen erstellt werden, was dann zu einer Unterbrechung führt, um ihn zu verwalten.
  • Ein DNS-Namespace (z. B. contoso.com) kann nur zu einem Mandanten gehören. Diese Anforderung hat Auswirkungen auf verschiedene Szenarien (z. B. die Freigabe einer E-Mail-Domäne während einer Fusion oder Übernahme usw.). Es gibt eine Möglichkeit, einen DNS-Sub (z. B. div.contoso.com) in einem anderen Mandanten zu registrieren. Dies sollte jedoch vermieden werden. Durch die Registrierung eines Domänennamens der obersten Ebene wird davon ausgegangen, dass alle Unterdomänen zum selben Mandanten gehören. In Szenarien mit mehreren Mandanten (wie im Folgenden erläutert) würde ich normalerweise empfehlen, einen anderen Domänennamen der obersten Ebene (z. B. contoso.ch oder ch-contoso.com) zu verwenden.
  • Wer sollte einen Mandanten "besitzen"? Ich sehe oft Kunden, die nicht wissen, wer derzeit der Besitzer ihres Mandanten ist. Dieser Mangel an Wissen ist eine erhebliche rote Flagge. Rufen Sie den Microsoft-Support asap an. Ebenso problematisch ist es, wenn ein Dienstbesitzer (häufig ein Exchange-Administrator) für die Verwaltung eines Mandanten bestimmt wird. Der Mandant enthält alle Dienste, die Sie in Zukunft möglicherweise benötigen. Der Mandantenbesitzer sollte eine Gruppe sein, die eine Entscheidung für die Aktivierung aller Clouddienste in einem organization treffen kann. Ein weiteres Problem ist, wenn eine Mandantenbesitzergruppe aufgefordert wird, alle Dienste zu verwalten. Diese Methode lässt sich für große Organisationen nicht skalieren.
  • Es gibt kein Konzept eines Sub-/Supermandanten. Aus irgendeinem Grund wiederholt sich dieser Mythos immer wieder. Dieses Konzept gilt auch für Azure Active Directory B2C-Mandanten . Ich höre zu oft: "Meine B2C-Umgebung befindet sich in meinem XYZ-Mandanten" oder "Gewusst wie meinen Azure-Mandanten in meinen Microsoft 365-Mandanten verschieben?"
  • Dieses Dokument konzentriert sich hauptsächlich auf die kommerzielle cloud weltweit, da die meisten Kunden diese verwenden. Manchmal ist es hilfreich, sich mit Sovereign Clouds zu informieren. Sovereign Clouds müssen noch andere Implikationen diskutieren, die für diese Diskussion außerhalb des Rahmens liegen.

Artikel zur Baselineidentität

Es gibt viele Dokumentationen zur Identitätsplattform von Microsoft – Microsoft Entra ID. Für Menschen, die gerade erst anfangen, fühlt es sich oft überwältigend an. Auch wenn Sie davon erfahren haben, kann es eine Herausforderung sein, mit ständigen Innovationen und Veränderungen Schritt zu halten. In meinen Kundeninteraktionen finde ich mich oft als "Übersetzer" zwischen Geschäftszielen und "Gut, Besser, Am besten" Ansätzen, um diese Bedenken (und menschliche "Klippennotizen" für diese Artikel) zu behandeln. Es gibt selten eine perfekte Antwort und die "richtige" Entscheidung ist ein Gleichgewicht verschiedener Risikofaktoren. Als Nächstes sind einige der häufigen Fragen und Konfusionsbereiche aufgeführt, die ich tendenziell mit Kunden besprechen möchte.

Bereitstellung

Microsoft Entra ID löst sich nicht für fehlende Governance in Ihrer Identitätswelt! Identitätsgovernance sollte unabhängig von Cloudentscheidungen ein wichtiges Element sein. Die Governanceanforderungen ändern sich im Laufe der Zeit, weshalb es sich um ein Programm und nicht um ein Tool handelt.

Microsoft Entra Connect vs. Microsoft Identity Manager (MIM) im Vergleich zu etwas anderem (Drittanbieter oder benutzerdefiniert)? Sparen Sie sich Probleme jetzt und in Zukunft und gehen Sie mit Microsoft Entra Connect. Es gibt alle Arten von Smarts in diesem Tool, um eigenartige Kundenkonfigurationen und laufende Innovationen zu adressieren.

Einige Edgefälle, die zu einer komplexeren Architektur führen können:

  • Ich verfüge über mehrere AD-Gesamtstrukturen ohne Netzwerkkonnektivität. Es gibt eine neue Option namens Cloudbereitstellung.
  • Ich verfüge weder über Active Directory noch möchte ich es installieren. Microsoft Entra Connect kann für die Synchronisierung über LDAP konfiguriert werden (partner ist möglicherweise erforderlich).
  • Ich muss dieselben Objekte für mehrere Mandanten bereitstellen. Dieses Szenario wird technisch nicht unterstützt, hängt aber von der Definition von "identisch" ab.

Sollte ich Standardsynchronisierungsregeln anpassen (Objekte filtern, Attribute ändern, alternative Anmelde-ID usw.)? Vermeiden Sie es! Eine Identitätsplattform ist nur so wertvoll wie die Dienste, die sie verwenden. Sie können zwar alle Arten von verrückten Konfigurationen ausführen, aber um diese Frage zu beantworten, müssen Sie sich die Auswirkungen auf Anwendungen ansehen. Wenn Sie E-Mail-aktivierte Objekte filtern, ist die GAL für Onlinedienste unvollständig. Wenn die Anwendung auf bestimmte Attribute angewiesen ist, hat das Filtern nach diesen Attributen unvorhersehbare Auswirkungen. Usw. Es ist keine Entscheidung des Identitätsteams.

XYZ SaaS unterstützt die Just-in-Time-Bereitstellung (JIT). Warum müssen Sie mich synchronisieren? Weitere Informationen finden Sie im vorherigen Absatz. Viele Anwendungen benötigen "Profil"-Informationen für die Funktionalität. Sie können keine GAL haben, wenn nicht alle E-Mail-aktivierten Objekte verfügbar sind. Gleiches gilt für die Benutzerbereitstellung in Anwendungen, die in Microsoft Entra ID integriert sind.

Authentifizierung

Kennworthashsynchronisierung (Password Hash Sync , PHS) vs. Passthrough-Authentifizierung (PTA) im Vergleich zu Verbund.

Normalerweise gibt es eine leidenschaftliche Debatte um die Föderation. Einfacher ist in der Regel besser und daher verwenden Sie PHS, es sei denn, Sie haben einen guten Grund dazu. Es ist auch möglich, verschiedene Authentifizierungsmethoden für verschiedene DNS-Domänen im selben Mandanten zu konfigurieren.

Einige Kunden aktivieren Verbund und PHS hauptsächlich für:

Ich beschreite Kunden häufig durch den Clientauthentifizierungsflow, um einige Missverständnisse zu klären. Das Ergebnis sieht wie das folgende Bild aus, das nicht so gut ist wie der interaktive Prozess, um dorthin zu gelangen.

Beispiel für eine Whiteboardunterhaltung.

Diese Art von Whiteboardzeichnung veranschaulicht, wo Sicherheitsrichtlinien innerhalb des Flusses einer Authentifizierungsanforderung angewendet werden. In diesem Beispiel werden Richtlinien, die über den Active Directory-Verbunddienst (AD FS) erzwungen werden, auf die erste Dienstanforderung angewendet, aber nicht auf nachfolgende Dienstanforderungen. Dieses Verhalten ist mindestens ein Grund, Sicherheitskontrollen so weit wie möglich in die Cloud zu verschieben.

Wir verfolgen den Traum vom einmaligen Anmelden (Single Sign-On , SSO) so lange, wie ich mich erinnern kann. Einige Kunden glauben, dass sie einmaliges Anmelden erreichen können, indem sie den "richtigen" Verbundanbieter (STS) auswählen. Microsoft Entra ID kann erheblich dazu beitragen, SSO-Funktionen zu aktivieren, aber kein STS ist magisch. Es gibt zu viele "Legacy"-Authentifizierungsmethoden, die noch für kritische Anwendungen verwendet werden. Die Erweiterung Microsoft Entra ID mit Partnerlösungen kann viele dieser Szenarien abdecken. SSO ist eine Strategie und eine Reise. Sie können nicht dorthin gelangen, ohne zu Standards für Anwendungen zu wechseln. Im Zusammenhang mit diesem Artikel handelt es sich um eine Reise zur kennwortlosen Authentifizierung, die auch keine magische Antwort hat.

Die mehrstufige Authentifizierung (Multi-Factor Authentication , MFA) ist heute unerlässlich (weitere Informationen finden Sie hier ). Fügen Sie die Analyse des Benutzerverhaltens hinzu, und Sie haben eine Lösung, die die meisten gängigen Cyberangriffe verhindert. Selbst Für Verbraucherdienste ist MFA erforderlich. Dennoch treffe ich viele Kunden, die nicht zu modernen Authentifizierungsansätzen wechseln wollen. Das größte Argument, das ich höre, ist, dass es Sich auf Benutzer und Ältere Anwendungen auswirkt. Manchmal kann ein guter Kick den Kunden helfen, sich zu bewegen - Exchange Online angekündigte Änderungen. Viele Microsoft Entra Berichte sind jetzt verfügbar, um Kunden bei dieser Umstellung zu helfen.

Authorization

Laut Wikipedia ist "zu autorisieren", eine Zugriffsrichtlinie zu definieren. Viele Benutzer betrachten es als die Möglichkeit, Zugriffssteuerungen für ein Objekt (Datei, Dienst usw.) zu definieren. In der aktuellen Welt der Cyberbedrohungen entwickelt sich dieses Konzept schnell zu einer dynamischen Richtlinie, die auf verschiedene Bedrohungsvektoren reagieren und die Zugriffssteuerungen schnell als Reaktion darauf anpassen kann. Wenn ich beispielsweise von einem ungewöhnlichen Ort aus auf mein Bankkonto zugreift, erhalte ich zusätzliche Bestätigungsschritte. Um uns dieser Realität zu nähern, müssen wir nicht nur die Politik selbst, sondern auch das Ökosystem der Methoden zur Bedrohungserkennung und Signalkorrelation berücksichtigen.

Die Richtlinien-Engine von Microsoft Entra ID wird mithilfe von Richtlinien für bedingten Zugriff implementiert. Dieses System ist auf Informationen von anderen Bedrohungserkennungssystemen angewiesen, um dynamische Entscheidungen zu treffen. Eine einfache Ansicht wäre in etwa wie die folgende Abbildung:

Richtlinien-Engine in Microsoft Entra ID.

Die Kombination all dieser Signale ermöglicht dynamische Richtlinien wie die folgenden:

  • Wenn eine Bedrohung auf Ihrem Gerät erkannt wird, wird Ihr Zugriff auf Daten nur auf das Web reduziert, ohne dass die Möglichkeit zum Herunterladen besteht.
  • Wenn Sie eine ungewöhnlich hohe Datenmenge herunterladen, ist alles, was Sie herunterladen, verschlüsselt und eingeschränkt.
  • Wenn Sie von einem nicht verwalteten Gerät aus auf einen Dienst zugreifen, werden Sie für hochsensible Daten gesperrt, dürfen aber auf nicht eingeschränkte Daten zugreifen, ohne sie an einen anderen Speicherort zu kopieren.

Wenn Sie dieser erweiterten Autorisierungsdefinition zustimmen, müssen Sie zusätzliche Lösungen implementieren. Welche Lösungen Sie implementieren, hängt davon ab, wie dynamisch die Richtlinie sein soll und welche Bedrohungen Sie priorisieren möchten. Einige Beispiele für solche Systeme sind:

Neben Microsoft Entra ID verfügen verschiedene Dienste und Anwendungen über eigene spezifische Autorisierungsmodelle. Einige dieser Modelle werden später im Delegierungsabschnitt erläutert.

Überwachung

Microsoft Entra ID verfügt über detaillierte Überwachungs- und Berichterstellungsfunktionen. Diese Berichte sind jedoch in der Regel nicht die einzige Informationsquelle, die für Sicherheitsentscheidungen erforderlich ist. Weitere Informationen zu diesem Thema finden Sie im Delegierungsabschnitt.

Es gibt keinen Exchange

Keine Panik! Exchange ist nicht veraltet (oder SharePoint usw.). Es ist immer noch ein Kerndienst. Was ich meine, ist, dass Technologieanbieter seit geraumer Zeit Benutzeroberflächen (User Experience, UX) auf Komponenten mehrerer Dienste umstellen. In Microsoft 365 ist ein einfaches Beispiel "moderne Anlagen", bei denen E-Mail-Anlagen in SharePoint Online oder OneDrive gespeichert werden.

Anfügen einer Datei an eine E-Mail.

Wenn Sie sich den Outlook-Client ansehen, können Sie viele Dienste sehen, die als Teil dieser Erfahrung "verbunden" sind, nicht nur Exchange. Beispiele hierfür sind Microsoft Entra ID, Microsoft Search, Apps, Profile, Compliance und Microsoft 365-Gruppen.

Outlook-Schnittstelle mit Legenden.

Informieren Sie sich über Microsoft Fluid Framework als Vorschau auf bevorstehende Funktionen. In der Vorschauversion kann ich jetzt Teams-Unterhaltungen direkt in Outlook lesen und beantworten. Tatsächlich ist der Teams-Client eines der prominenteren Beispiele für diese Strategie.

Insgesamt wird es schwieriger, eine klare Linie zwischen Microsoft 365 und anderen Diensten in Microsoft-Clouds zu ziehen. Ich halte dies für einen großen Vorteil für Kunden, da sie von totaler Innovation in allem, was wir tun, profitieren können, auch wenn sie eine Komponente verwenden. Ziemlich cool und hat weitreichende Auswirkungen für viele Kunden.

Heute finde ich, dass viele IT-Kundengruppen nach "Produkten" strukturiert sind. Dies ist für eine lokale Welt logisch, da Sie einen Experten für jedes bestimmte Produkt benötigen. Ich bin jedoch froh, dass ich keine Active Directory- oder Exchange-Datenbank mehr debuggen muss, da diese Dienste in die Cloud verschoben wurden. Automatisierung (was die Cloud im Grunde ist) entfernt bestimmte sich wiederholende manuelle Aufträge (sehen Sie sich an, was mit Fabriken passiert ist). Diese Aufgaben werden jedoch durch komplexere Anforderungen ersetzt, um dienstübergreifende Interaktionen, Auswirkungen, geschäftsbezogene Anforderungen usw. zu verstehen. Wenn Sie bereit sind, etwas zu lernen, bietet die Cloudtransformation große Möglichkeiten. Bevor ich in die Technologie springe, spreche ich oft mit Kunden über das Management von Veränderungen in IT-Fähigkeiten und Teamstrukturen.

An alle SharePoint-Fan-Personen und -Entwickler wenden Sie sich bitte nicht mehr nach "Wie kann ich XYZ in SharePoint Online machen?" Verwenden Sie Power Automate (oder Flow) für Workflows, dies ist eine viel leistungsfähigere Plattform. Verwenden Sie Azure Bot Framework , um eine bessere Benutzeroberfläche für Ihre 500-K-Elementliste zu erstellen. Beginnen Sie mit der Verwendung von Microsoft Graph anstelle von CSOM. Microsoft Teams umfasst SharePoint, aber auch eine Welt mehr. Es gibt viele weitere Beispiele, die ich auflisten kann. Es gibt ein riesiges und wunderbares Universum da draußen. Öffnen Sie die Tür, und beginnen Sie mit der Erkundung.

Die andere gemeinsame Auswirkung liegt im Compliancebereich. Dieser dienstübergreifende Ansatz scheint viele Konformitätsrichtlinien völlig zu verwechseln. Ich sehe immer wieder Organisationen, die sagen: "Ich muss die gesamte E-Mail-Kommunikation an ein eDiscovery-System journalieren." Was bedeutet diese Aussage wirklich, wenn E-Mail nicht mehr nur E-Mail, sondern ein Fenster zu anderen Diensten ist? Microsoft 365 hat einen umfassenden Ansatz für Compliance, aber veränderungen von Personen und Prozessen sind oft viel schwieriger als technologie.

Es gibt viele andere Personen und Prozessauswirkungen. Meiner Meinung nach ist dieser Faktor ein kritischer und nicht diskutierter Bereich. Vielleicht mehr in einem anderen Artikel.

Mandantenstrukturoptionen

Einzelmandant und mehrinstanzenfähig

Im Allgemeinen sollten die meisten Kunden nur über einen Produktionsmandanten verfügen. Es gibt viele Gründe, warum mehrere Mandanten eine Herausforderung darstellen (eine Bing-Suche) oder dieses Whitepaper lesen. Gleichzeitig verfügen viele Unternehmenskunden, mit denen ich zusammenarbeite, über einen weiteren (kleinen) Mandanten für IT-Lernen, -Tests und -Experimente. Der mandantenübergreifende Azure-Zugriff wird mit Azure Lighthouse vereinfacht. Für Microsoft 365 und viele andere SaaS-Dienste gelten Grenzwerte für mandantenübergreifende Szenarien. Bei Microsoft Entra B2B-Szenarien gibt es viel zu beachten.

Viele Kunden haben nach einer Fusion und Übernahme (M&A) mehrere Produktionsmandanten und möchten konsolidieren. Heute ist dies nicht einfach und würde Microsoft Consulting Services (MCS) oder einen Partner plus Software von Drittanbietern erfordern. Es gibt laufende Engineering-Arbeiten, um verschiedene Szenarien mit mehrinstanzenfähigen Kunden in Zukunft zu behandeln.

Einige Kunden entscheiden sich für mehr als einen Mandanten. Dies sollte eine sorgfältige Entscheidung und fast immer geschäftliche Vernunft sein! Einige Beispiele umfassen die folgenden Gründe:

  • Eine Unternehmensstruktur vom Typ "Holding", in der keine einfache Zusammenarbeit zwischen verschiedenen Entitäten erforderlich ist und starke administrative und andere Isolationsanforderungen bestehen.
  • Nach einer Übernahme wird eine Geschäftsentscheidung getroffen, um zwei Entitäten voneinander zu trennen.
  • Simulation der Umgebung eines Kunden, die die Produktionsumgebung des Kunden nicht ändert.
  • Entwicklung von Software für Kunden.

In diesen Szenarien mit mehreren Mandanten möchten Kunden häufig einige Konfigurationen mandantenübergreifend gleich lassen oder über Konfigurationsänderungen und Abweichungen berichten. Dies bedeutet häufig, von manuellen Änderungen zur Konfiguration als Code zu wechseln. Der Microsoft Premiere-Support bietet einen Workshop für diese Arten von Anforderungen basierend auf dieser öffentlichen IP-Adresse: https://Microsoft365dsc.com.

Multi-Geo

In Multi-Geo oder nicht in Multi-Geo. Das ist die Frage. Mit Microsoft 365 Multi-Geo können Sie ruhende Daten an den geografischen Standorten bereitstellen und speichern, die Sie zur Erfüllung der Datenresidenzanforderungen auswählen. Es gibt viele Missverständnisse über diese Funktion. Beachten Sie die folgenden Punkte:

  • Es bietet keine Leistungsvorteile. Dies könnte die Leistung verschlechtern, wenn das Netzwerkdesign nicht korrekt ist. Bringen Sie Geräte in die Nähe des Microsoft-Netzwerks, nicht unbedingt zu Ihren Daten.
  • Es ist keine Lösung für die Einhaltung der DSGVO. Die DSGVO konzentriert sich nicht auf Datenhoheit oder Speicherorte. Es gibt weitere Complianceframeworks für Datenhoheit oder Speicherorte.
  • Es löst keine Delegierung von Verwaltungsbarrieren (siehe unten) oder Informationsbarrieren.
  • Es ist nicht dasselbe wie mehrinstanzenfähig und erfordert mehr Workflows für die Benutzerbereitstellung .
  • Ihr Mandant (Ihr Microsoft Entra ID) wird nicht in eine andere Geografische Region verschoben.

Delegierung der Verwaltung

In den meisten großen Organisationen ist die Trennung von Aufgaben und die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) eine notwendige Realität. Ich werde mich im Voraus entschuldigen. Diese Aktivität ist nicht so einfach, wie es einige Kunden wünschen. Kunden-, Rechtliche, Compliance- und andere Anforderungen sind unterschiedlich und manchmal in Konflikt auf der ganzen Welt. Einfachheit und Flexibilität liegen oft auf gegenüberliegenden Seiten. Verstehen Sie mich nicht falsch, wir können bei diesem Ziel einen besseren Job machen. Im Laufe der Zeit wurden (und werden) erhebliche Verbesserungen vorgenommen. Besuchen Sie Ihr lokales Microsoft Technology Center , um das Modell zu ermitteln, das Ihren Geschäftlichen Anforderungen entspricht, ohne 379.230 Dokumente zu lesen! Hier konzentriere ich mich darauf, was Sie denken sollten und nicht, warum es so ist. In Kürze sind fünf verschiedene Bereiche zu planen und einige der häufig auftretenden Fragen, denen ich begegnen muss.

Microsoft Entra ID und Microsoft 365 Admin Center

Es gibt eine lange und wachsende Liste integrierter Rollen. Jede Rolle besteht aus einer Liste von Rollenberechtigungen, die gruppiert sind, damit bestimmte Aktionen ausgeführt werden können. Sie können diese Berechtigungen auf der Registerkarte "Beschreibung" in jeder Rolle anzeigen. Alternativ können Sie eine besser lesbare Version dieser Berechtigungen im Microsoft 365 Admin Center sehen. Die Definitionen für integrierte Rollen können nicht geändert werden. Im Allgemeinen gliedere ich diese Rollen in drei Kategorien:

  • globaler Administrator: Diese "all powerful"-Rolle sollte genau wie in anderen Systemen streng geschützt sein. Typische Empfehlungen sind: Keine permanente Zuweisung und Verwendung Microsoft Entra Privileged Identity Management (PIM), starke Authentifizierung usw. Interessanterweise bietet Ihnen diese Rolle nicht standardmäßig Zugriff auf alles. In der Regel sehe ich Verwirrung in Bezug auf Compliancezugriff und Azure-Zugriff, die später erläutert wird. Diese Rolle kann jedoch immer Zugriff auf andere Dienste im Mandanten zuweisen.
  • Bestimmte Dienstadministratoren: Einige Dienste (Exchange, SharePoint, Power BI usw.) nutzen allgemeine Verwaltungsrollen von Microsoft Entra ID. Dieses Verhalten ist nicht für alle Dienste konsistent, und es werden später weitere dienstspezifische Rollen erläutert.
  • Funktional: Es gibt eine lange (und wachsende) Liste von Rollen, die sich auf bestimmte Vorgänge (Gastladener usw.) konzentrieren. In regelmäßigen Abständen werden mehr dieser Rollen basierend auf den Kundenanforderungen hinzugefügt.

Es ist nicht möglich, alles zu delegieren (obwohl die Lücke abnimmt), was bedeutet, dass manchmal die Rolle globaler Administrator verwendet werden muss. Configuration-as-Code und Automatisierung sollten anstelle von Personen, die dieser Rolle angehören, berücksichtigt werden.

Hinweis: Die Microsoft 365 Admin Center verfügt über eine benutzerfreundlichere Benutzeroberfläche, verfügt aber im Vergleich zur Microsoft Entra Administratorerfahrung über eine Teilmenge von Funktionen. Beide Portale verwenden die gleichen Microsoft Entra Rollen, sodass Änderungen an derselben Stelle auftreten. Tipp: Wenn Sie eine identitätsverwaltungsorientierte Administratorbenutzeroberfläche ohne die gesamte Azure-Unübersichtlichkeit benötigen, verwenden Sie https://aad.portal.azure.com.

Was ist im Namen enthalten? Machen Sie keine Annahmen aus dem Namen der Rolle. Sprache ist kein präzises Tool. Das Ziel sollte darin bestehen, Vorgänge zu definieren, die delegiert werden müssen, bevor sie prüfen, welche Rollen benötigt werden. Das Hinzufügen einer Person zur Rolle "Sicherheitsleseberechtigter" führt nicht dazu, dass sicherheitsrelevante Einstellungen überall angezeigt werden.

Die Möglichkeit, benutzerdefinierte Rollen zu erstellen, ist eine häufig gestellte Frage. Diese Funktion ist in Microsoft Entra heute eingeschränkt (wie weiter unten erläutert), wird aber im Laufe der Zeit an Funktionen wachsen. Ich denke, diese benutzerdefinierten Rollen gelten für Funktionen in Microsoft Entra ID und umfassen möglicherweise nicht das Hierarchiemodell "nach unten" (wie zuvor erläutert). Immer wenn ich mit "custom" zu tun habe, tendiere ich dazu, zu meinem Prinzip von "einfach ist besser" zurückzukehren.

Eine weitere häufig gestellte Frage ist die Möglichkeit, Rollen auf eine Teilmenge eines Verzeichnisses zu festlegen. Ein Beispiel ist etwa "Helpdeskadministrator nur für Benutzer in der EU". Verwaltungseinheiten sind für dieses Szenario vorgesehen. Wie bereits beschrieben, denke ich, dass diese Bereiche auf Funktionen in Microsoft Entra ID anwendbar sind und sich möglicherweise nicht "nach unten" erstrecken. Bestimmte Rollen sind nicht sinnvoll (globale Administratoren, Dienstadministratoren usw.).

Heute erfordern alle diese Rollen eine direkte Mitgliedschaft (oder dynamische Zuweisung, wenn Sie Microsoft Entra PIM verwenden). Dies bedeutet, dass Kunden diese Rolle direkt in Microsoft Entra ID verwalten müssen, und diese Rollen können nicht auf einer Sicherheitsgruppenmitgliedschaft basieren. Ich bin kein Fan davon, Skripts zu erstellen, um diese Rollen zu verwalten, da sie mit erhöhten Rechten ausgeführt werden müssten. Ich empfehle im Allgemeinen die API-Integration mit Prozesssystemen wie ServiceNow oder die Verwendung von Partnergovernancetools wie Saviynt. Es gibt technische Arbeiten, um dieses Problem im Laufe der Zeit zu beheben.

Ich habe Microsoft Entra PIM mehrmals erwähnt. Es gibt eine entsprechende MICROSOFT IDENTITY MANAGER-Lösung (MIM) Privileged Access Management (PAM) für lokale Steuerelemente. Sie können sich auch Privileged Access Workstations (PAWs) und Microsoft Entra ID Governance ansehen. Es gibt auch verschiedene Tools von Drittanbietern, die just-in-time, just-enough und dynamische Rollenerweiterungen ermöglichen können. Diese Funktion ist in der Regel Teil einer größeren Diskussion zum Schutz einer Umgebung.

Manchmal erfordern Szenarien das Hinzufügen eines externen Benutzers zu einer Rolle (siehe vorheriger mehrinstanzenfähiger Abschnitt). Dieses Ergebnis funktioniert gut. Microsoft Entra B2B ist ein weiterer großer und unterhaltsamer Artikel, durch den Kunden erläutert werden können, vielleicht in einem anderen Artikel.

Microsoft Defender XDR- und Microsoft 365 Purview-Complianceportale

Email & Rollen für die Zusammenarbeit im Microsoft Defender-Portal und *Rollengruppen für Microsoft Purview-Lösungen im Microsoft 365 Purview-Complianceportal sind eine Sammlung von "Rollengruppen", die sich von Microsoft Entra Rollen unterscheiden. Dies kann verwirrend sein, da einige dieser Rollengruppen den gleichen Namen wie Microsoft Entra Rollen haben (z. B. Sicherheitsleseberechtigter), aber sie können unterschiedliche Mitgliedschaften haben. Ich bevorzuge die Verwendung von Microsoft Entra Rollen. Jede Rollengruppe besteht aus einer oder mehreren "Rollen" (was ich über die Wiederverwendung desselben Worts meine?) und verfügt über Mitglieder aus Microsoft Entra ID, bei denen es sich um E-Mail-fähige Objekte handelt. Außerdem können Sie eine Rollengruppe mit demselben Namen wie eine Rolle erstellen, die diese Rolle enthalten kann oder nicht (vermeiden Sie diese Verwirrung).

In gewisser Weise sind diese Berechtigungen eine Weiterentwicklung des Exchange-Rollengruppenmodells. Exchange Online verfügt jedoch über eine eigene Verwaltungsschnittstelle für Rollengruppen. Einige Rollengruppen in Exchange Online sind über Microsoft Entra ID oder die Microsoft Defender XDR- und Microsoft 365 Purview-Complianceportale gesperrt und verwaltet, andere haben jedoch möglicherweise die gleichen oder ähnliche Namen und werden in Exchange Online verwaltet (was zur Verwirrung beitäuschen kann). Ich empfehle, die Verwendung der Exchange Online-Benutzeroberfläche zu vermeiden, es sei denn, Sie benötigen Bereiche für die Exchange-Verwaltung.

Sie können keine benutzerdefinierten Rollen erstellen. Rollen werden von Diensten definiert, die von Microsoft erstellt wurden und mit der Einführung neuer Dienste weiter wachsen. Dieses Verhalten ähnelt dem Konzept von Rollen, die von Anwendungen in Microsoft Entra ID definiert werden. Wenn neue Dienste aktiviert werden, müssen häufig neue Rollengruppen erstellt werden, um ihnen Zugriff zu gewähren oder zu delegieren (z. B. Insider-Risikomanagement).

Diese Rollengruppen erfordern auch eine direkte Mitgliedschaft und dürfen keine Microsoft Entra Gruppen enthalten. Leider werden diese Rollengruppen heute von Microsoft Entra PIM nicht unterstützt. Wie Microsoft Entra Rollen empfehle ich die Verwaltung dieser Rollengruppen über APIs oder ein Partnergovernanceprodukt wie Saviynt oder andere.

Microsoft Defender Portal- und Microsoft 365 Purview-Complianceportalrollen umfassen Microsoft 365, und Sie können diese Rollengruppen nicht auf eine Teilmenge der Umgebung festlegen (wie bei Verwaltungseinheiten in Microsoft Entra ID). Viele Kunden fragen, wie sie subdelegate können. Beispiel: "Erstellen einer DLP-Richtlinie nur für EU-Benutzer" Wenn Sie heute über Rechte für eine bestimmte Funktion in den Microsoft Defender XDR- und Microsoft 365 Purview-Complianceportalen verfügen, haben Sie Rechte für alles, was von dieser Funktion im Mandanten abgedeckt wird. Viele Richtlinien verfügen jedoch über Funktionen für eine Teilmenge der Umgebung (z. B. "Diese Bezeichnungen nur für diese Benutzer verfügbar machen"). Ordnungsgemäße Governance und Kommunikation sind eine wichtige Komponente, um Konflikte zu vermeiden. Einige Kunden entscheiden sich für die Implementierung eines "Configuration-as-Code"-Ansatzes, um untergeordnete Delegierungen in den Microsoft Defender XDR- und Microsoft 365 Purview-Complianceportalen zu behandeln. Einige bestimmte Dienste unterstützen die Unterdelegation (siehe nächster Abschnitt).

Dienstspezifisch

Wie bereits erwähnt, möchten viele Kunden ein differenzierteres Delegierungsmodell erreichen. Ein gängiges Beispiel: "Verwalten des XYZ-Diensts nur für Benutzer und Standorte der Abteilung X" (oder eine andere Dimension). Die Möglichkeit dazu hängt von jedem Dienst ab und ist nicht über Dienste und Funktionen hinweg konsistent. Darüber hinaus kann jeder Dienst über ein separates und eindeutiges RBAC-Modell verfügen. Anstatt alle diese Modelle zu diskutieren (was ewig dauern würde), fügen Sie relevante Links für jeden Dienst hinzu. Diese Liste ist nicht vollständig, aber sie kann Ihnen den Einstieg erleichtern.

  • Exchange Online – (/exchange/permissions-exo/permissions-exo)
  • SharePoint Online – (/sharepoint/manage-site-collection-administrators)
  • Microsoft Teams – (/microsoftteams/itadmin-readiness)
  • eDiscovery – (.. /compliance/index.yml)
    • Berechtigungsfilterung : (.. /compliance/index.yml)
    • Compliancegrenzen – (.. /compliance/set-up-compliance-boundaries.md)
    • eDiscovery (Premium) – (.. /compliance/overview-ediscovery-20.md)
  • Viva Engage : (/viva/engage/manage-viva-engage-users/manage-viva-engage-admins)
  • Multi-Geo - (.. /enterprise/add-a-sharepoint-geo-admin.md)
  • Dynamics 365 – (/dynamics365/)

Hinweis

Dieser Link ist zum Stamm der Dokumentation. Es gibt mehrere Arten von Diensten mit Variationen im Administrator-/Delegierungsmodell.

  • Power Platform – (/power-platform/admin/admin-documentation)

    • Power Apps – (/power-platform/admin/wp-security)

      Hinweis

      es gibt mehrere Typen mit Variationen in den Administrator-/Delegierungsmodellen.

    • Power Automate – (/power-automate/environments-overview-admin)

    • Power BI – (/power-bi/service-admin-governance)

      Hinweis: Die Sicherheit und Delegierung der Datenplattform (power BI ist eine Komponente) ist ein komplexer Bereich.

  • Intune : (/mem/intune/fundamentals/role-based-access-control)

  • Microsoft Defender for Endpoint – (/windows/security/threat-protection/microsoft-defender-atp/user-roles)

  • Microsoft Defender XDR - (.. /security/defender/m365d-permissions.md)

  • Microsoft Defender for Cloud Apps : (/cloud-app-security/manage-admins)

  • Stream : (/stream/assign-administrator-user-role)

  • Informationsbarrieren - (.. /compliance/information-barriers.md)

Aktivitätsprotokolle

Microsoft 365 verfügt über ein einheitliches Überwachungsprotokoll. Es ist ein sehr detailliertes Protokoll, aber lesen Sie nicht zu viel in den Namen ein. Es enthält möglicherweise nicht alles, was Sie für Ihre Sicherheits- und Complianceanforderungen benötigen oder benötigen. Außerdem sind einige Kunden sehr an Audit (Premium) interessiert.

Beispiele für Microsoft 365-Protokolle, auf die über andere APIs zugegriffen wird, umfassen die folgenden Features:

Es ist wichtig, zunächst alle Protokollquellen zu identifizieren, die für ein Sicherheits- und Complianceprogramm erforderlich sind. Beachten Sie auch, dass verschiedene Protokolle unterschiedliche Onlineaufbewahrungsgrenzwerte aufweisen.

Aus Sicht der Administratordelegierung verfügen die meisten Microsoft 365-Aktivitätsprotokolle nicht über ein integriertes RBAC-Modell. Wenn Sie über die Berechtigung zum Anzeigen eines Protokolls verfügen, können Sie alles darin sehen. Ein gängiges Beispiel für eine Kundenanforderung ist: "Ich möchte aktivität nur für EU-Benutzer abfragen können" (oder eine andere Dimension). Um diese Anforderung zu erfüllen, müssen wir Protokolle an einen anderen Dienst übertragen. In der Microsoft-Cloud wird empfohlen, sie entweder an Microsoft Sentinel oder Log Analytics zu übertragen.

Allgemeines Diagramm:

Diagramm der Protokollquellen für ein Sicherheits- und Complianceprogramm.

Das Diagramm zeigt integrierte Funktionen zum Senden von Protokollen an Event Hubs und/oder Azure Storage und/oder Azure Log Analytics. Noch nicht alle Systeme enthalten diese out-of-the-box. Es gibt jedoch andere Ansätze, um diese Protokolle an dasselbe Repository zu senden. Weitere Informationen finden Sie beispielsweise unter Schützen Ihrer Teams mit Microsoft Sentinel.

Das Kombinieren aller Protokolle an einem Speicherort bietet zusätzliche Vorteile, z. B. Kreuzkorrelationen, benutzerdefinierte Aufbewahrungszeiten, Erweitern mit Daten, die zur Unterstützung des RBAC-Modells erforderlich sind usw. Sobald sich Daten in diesem Speichersystem befinden, können Sie eine Power BI-Dashboard (oder einen anderen Visualisierungstyp) mit einem geeigneten RBAC-Modell erstellen.

Protokolle müssen nicht nur an einen Ort weitergeleitet werden. Es kann auch von Vorteil sein, Microsoft 365-Protokolle in Microsoft Defender for Cloud Apps oder ein benutzerdefiniertes RBAC-Modell in Power BI zu integrieren. Verschiedene Repositorys haben unterschiedliche Vorteile und Zielgruppen.

Es ist erwähnenswert, dass es ein umfangreiches integriertes Analysesystem für Sicherheit, Bedrohungen, Sicherheitsrisiken usw. in einem Dienst namens Microsoft Defender XDR gibt.

Viele große Kunden möchten diese Protokolldaten an ein Drittanbietersystem (z. B. SIEM) übertragen. Es gibt verschiedene Ansätze für dieses Ergebnis, aber im Allgemeinen sind Azure Event Hubs und Graph gute Ausgangspunkte.

Azure

Ich werde oft gefragt, ob es eine Möglichkeit gibt, Rollen mit hohen Berechtigungen zwischen Microsoft Entra ID, Azure und SaaS (z. B. Globaler Administrator für Microsoft 365, aber nicht Azure) zu trennen. Nicht wirklich. Eine mehrinstanzenfähige Architektur ist erforderlich, wenn eine vollständige administrative Trennung erforderlich ist, aber dies führt zu erheblicher Komplexität (wie weiter oben erläutert). Alle diese Dienste sind Teil derselben Sicherheits-/Identitätsgrenze (wie im Hierarchiemodell dargestellt).

Es ist wichtig, die Beziehungen zwischen verschiedenen Diensten im selben Mandanten zu verstehen. Ich arbeite mit vielen Kunden zusammen, die Geschäftslösungen entwickeln, die Azure, Microsoft 365 und Power Platform (und häufig auch lokale und Clouddienste von Drittanbietern) umfassen. Ein gängiges Beispiel:

  1. Ich möchte an einer Reihe von Dokumenten/Bildern/etc. zusammenarbeiten (Microsoft 365)
  2. Senden Sie jeden einzelnen von ihnen über einen Genehmigungsprozess (Power Platform)
  3. Nachdem alle Komponenten genehmigt wurden, bauen Sie diese Elemente in einem einheitlichen Lieferumfang (Azure) zusammen, Graph-API hier Ihr bester Freund ist. Nicht unmöglich, aber wesentlich komplexer, um eine Lösung zu entwerfen, die mehrere Mandanten umfasst.

Azure Role-Based Access Control (RBAC) ermöglicht eine differenzierte Zugriffsverwaltung für Azure. Mithilfe von RBAC können Sie den Zugriff auf Ressourcen verwalten, indem Sie Benutzern die geringsten Berechtigungen erteilen, die für die Ausführung ihrer Aufgaben erforderlich sind. Details werden in diesem Dokument nicht behandelt. Weitere Informationen zu RBAC finden Sie unter Was ist die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) in Azure? RBAC ist wichtig, aber nur ein Teil der Governanceüberlegungen für Azure. Cloud Adoption Framework ist ein guter Ausgangspunkt, um mehr zu erfahren. Ich mag es, wie mein Freund Andres Ravinet Kunden Schritt für Schritt durch verschiedene Komponenten führt, um sich für den Ansatz zu entscheiden. Die allgemeine Ansicht für verschiedene Elemente (nicht so gut wie der Prozess, um zum tatsächlichen Kundenmodell zu gelangen) ist in etwa wie folgt:

Allgemeine Ansicht der Azure-Komponenten für die delegierte Verwaltung.

Wie Sie aus der obigen Abbildung sehen können, sollten viele andere Dienste als Teil des Entwurfs berücksichtigt werden (z. B. Azure-Richtlinien, Azure Blueprints, Verwaltungsgruppen usw.).

Zusammenfassung

Dieser Artikel begann als kurze Zusammenfassung und endete länger als erwartet. Ich hoffe, Sie sind jetzt bereit, sich mit dem Erstellen eines Delegierungsmodells für Ihre organization zu beginnen. Diese Unterhaltung ist sehr häufig mit Kunden. Es gibt kein Modell, das für jeden geeignet ist. Warten Sie auf einige geplante Verbesserungen von Microsoft Engineering, bevor Sie gängige Muster dokumentieren, die wir bei kundenübergreifend sehen. In der Zwischenzeit können Sie mit Ihrem Microsoft-Kontoteam zusammenarbeiten, um einen Besuch im nächstgelegenen Microsoft Technology Center zu vereinbaren. Wir sehen uns dort!