5 sind geladen 10 sind gekommen, gieß Wasser zur Suppe heiß alle Willkommen

Dieser sehr Gastfreundliche Spruch hing bei meiner Großmutter stets in der Küche. Auch wenn ich die Grundeinstellung sehr positiv finde, verhält es sich mit Gästen im Geschäftskontext leicht anders.

Grundsätzlich ist die B2B-Gastfunktion des Azure AD ein Segen. Insbesondere als Dienstleister erlebe ich regelmäßig, was es heißt regelmäßig Konten bei anderen Firmen angelegt zu bekommen:

          Unklare Prozesse und Zuständigkeiten

          Fehlende (oder auch viel zu viele) Berechtigungen

          Eine Vielzahl an VPN-Clients

          Komplizierte Prozeduren, um das Initial-Passwort sicher zum Nutzer zu übertragen

Während das für mich als „Techie“ alles irgendwie händelbar ist, war es für den Otto-Normal-Anwender, der auf einen On-Prem SharePoint eines Partners zugreifen sollte, jedes Mal ein Abenteuer mit ungewissem Ausgang.

Für Anwender ist hier eine erhebliche Erleichterung mit Microsoft 365 gekommen: Sofern beide Unternehmen Microsoft 365 einsetzen besteht keine Notwendigkeit mehr, dass man zwei Konten benutzt. Stattdessen kann man beim Partner einfach „sein eigenes Konto mitbringen“. Das ist aus mehreren Gründen erfreulich. Der Partner muss sich nicht mehr darum kümmern, wenn der Eingeladene:

          Sein Passwort vergisst

          Das Unternehmen verlässt

          Seinen Namen ändert

Soweit dürfte das, bekanntes Wissen sein. Was sich aber bisher (fast) jeder meiner Kunden gefragt hat ist: Ich muss doch auch die Gäste irgendwie verwalten, oder? Wie machen denn das die anderen Kunden von Ihnen?

Eine passende Gast-Nutzer Strategie ist eigentlich kein Hexenwerk, es wird bei M365 Einführungen aber häufig vernachlässigt. Wir haben in unseren Kundenprojekten dabei mehrere Ansätze realisiert, die ich im Folgenden kurz skizziert werden.

Variante 1 „Fully Managed“

Ohne die IT kommt keiner rein oder raus. Kann über Bordmittel realisiert werden, bringt aber viele Usability-Einschränkungen mit sich. Wenn der Service Desk so aufgestellt ist, dass diese Anfragen zügig bearbeitet werden, durchaus ein praktikabler Weg. Wichtig ist dann, dass die IT dann auch die Buchführung über die Gäste übernimmt und diese wieder aus dem AAD entfernt, wenn die Anforderung für den Zugriff nicht mehr besteht.

Variante 2 „Managed Self Service“

Der Anwender bekommt eine Möglichkeit über ein Formular einen neuen Gast selbst einzuladen. Im Formular werden mind. zwei Ansprechpartner festgehalten. Diese Ansprechpartner für den Gast müssen dann alle 3 / 6 / 9 / 12 Monate entscheiden, ob der Gast weiter Mitglied bleiben soll.

Mit Abstand mein Favorit unter allen Möglichkeiten, am besten umsetzbar mit 3rd-Party-Software, z.B. der AvePoint Governance Suite. Alternativ lassen sich auch eigene Lösungen auf Basis von Power Apps und Power Automate bauen.

Variante 3 „Unmanaged Self Service“

Auch diese Variante ist präsent. Sie entspricht den Voreinstellungen: Jeder kann einladen und niemand räumt auf.

Diese Varianten lassen sich natürlich in verschiedenen Abstufungen mischen.

Gastmanagement auf dem nächsten Level

Letztendlich betrachten all diese Varianten nur den Prozess „Wie gelangt ein Gast in das Benutzerverzeichnis“. Das genügt vielen Unternehmen nicht und die Kontrolle muss noch eine Ebene tiefer auf die Berechtigungen des Gasts innerhalb des eigenen Tenants gerichtet werden.

Hierfür gibt es im Rahmen der Azure AD P2 Lizenzen (u.a. in M365 E5 enthalten) die Funktion der Access Reviews und des Entitlement Management. Diese erlaubt es einem, dass z.B. jeder Team-Owner über seine Gäste in festgelegten Zeitabständen „richten“ muss. Die Entscheidung des Team-Owners führt dann dazu, dass der Gast ggf. direkt aus dem Team entfernt wird. Insbesondere in regulierten Bereichen ist eine solche Funktionalität grundlegend erforderlich, und zwar nicht nur für Gäste.

Wer jetzt vor den Zusatzkosten für die Azure AD P2 Lizenz zurückscheut hat aber noch weitere Optionen. Zum einen bietet die bereits zuvor erwähnte AvePoint Governance Suite eine vergleichbare Funktion. Falls man ganz ohne 3rd Party Software auskommen möchte, kann man auch hier mit Hilfe von Power Automate, PowerShell & Co eine individuelle Lösung bauen.

Empfehlung

 

Um einen wirklich modernen Arbeitsplatz aufzubauen sollte man versuchen den Anwender so autonom wie möglich zu machen. Daher ist mein Favorit die Variante 2. Variante 1 hat den großen Nachteil, dass die Entscheidung, ob jemand weiter Gast bleiben soll, inhaltlich keine Entscheidung der IT ist. Der Anwender selbst muss bestimmen, ob der Gast noch weiter im Projekt benötigt wird oder nicht.

Wenn Gäste keine Gäste sein sollen

Authenticator Logo

Mit der Möglichkeit Gäste in SharePoint Online oder Microsoft Teams einzuladen wurde die Zusammenarbeit zwischen verschiedenen Unternehmen massiv vereinfacht. Auf der anderen Seite stellt diese Offenheit auch ein Problem dar, wenn es darum geht sensible Inhalte zu schützen. Neben den tollen Möglichkeiten rund um Sensitivity Labels, Data Loss Prevention & Co ist eins der effektivsten Mittel aber immer noch auf bestimmten SharePoint-Sites einfach den Guest-Access komplett zu deaktivieren. Das ist schnell im SharePoint Online Admin-Center konfiguriert und z.B. für Intranet-Seiten durchaus sinnvoll.

Jetzt gibt es aber diesen einen Ausnahmefall, bei dem die „keine Gäste auf dieser Seite“-Regel vielleicht doch nicht passt. Vielleicht ist es ein Freelancer mit dem man eng zusammenarbeitet oder ein Berater der hier Zugriff benötigt. Jetzt kann man natürlich den „klassischen“ Weg gehen und der Person einen ganz normalen Account im eigenen System anlegen, inkl. zugehöriger Lizenz. Schöner wäre es aber für alle Seiten, wenn der andere mit seinem ganz normalen Account weiterarbeiten könnte.

Hierfür hält das Azure AD die Möglichkeit per PowerShell bereit einen Gast nicht als Gast einzuladen, sondern als „normales“ Mitglied. Auch bestehende Gäste können per PowerShell konvertiert werden. Der konkrete Befehl sieht wie folgt aus:

New-AzureADMSInvitation -InvitedUserDisplayName „Max Mustermann (Gast)“ -InvitedUserEmailAddress „max.mustermann@bright-skies.de“ -SendInvitationMessage $true -InviteRedirectUrl „https://www.myapps.microsoft.com“ -InvitedUserType Member

bzw. für die Umwandlung bestehender User:

Set-AzureADUser -ObjectId 123-456789-123 -UserType Member

Die Veränderung des Gast-Nutzer-Status wirkt sich sowohl bei Conditional Access, als auch bei SharePoint Online und Microsoft 365 Groups aus. Weitere Punkte sind – nach bisherigen Tests – nicht davon betroffen.

Es gilt wie so oft: Nur weil etwas technisch machbar ist, sollte man es nicht unbedingt auch tun. Am Ende kommt es darauf an einen Plan zu haben. Die benannte Variante sollte gut durchdacht genutzt werden und eine Ausnahme sein statt der Regel. Dazu gehört eine saubere Dokumentation der so eingeladenen Externen Accounts sowie eine Betrachtung der Folgen. Dabei ist es wichtig das vollständige Conditional Access-Regelwerk des Unternehmens zu kennen, sowie die Governance-Richtlinien und konkreten Einstellungen in SharePoint. Vergisst man etwas davon passiert es leicht, dass man mit einem mal zu viele Informationen teilt.

Umzug in der Cloud

Gerade rechtzeitig zur ersten Welle der Corona Pandemie, hat Microsoft Neukunden für Microsoft 365 mit einer deutschen Adresse in neue Rechenzentren in der Region Deutschland geleitet. Während für Azure die neuen Regionen schon länger verfügbar waren, hat sich der M365-Service noch etwas mehr Zeit gelassen.

Das bedeutet: Die allermeisten der neu erstellten Tenants im letzten Jahr sind in Rechenzentren in Deutschland gelandet. (Nicht zu verwechseln mit der Spezial-Cloud für Deutschland, welche durch die T-Systems als Treuhänder verwaltet wurde und sich als Konzept nicht durchgesetzt hat).

Jetzt gibt es einige Bestandskunden aus Deutschland, die bereits vorher einen Tenant angelegt haben. Deren Tenant ist im Standard in der Region West-Europa (Standorte Dublin und Amsterdam) angelegt worden. An dieser Stelle hat Microsoft jetzt eine Möglichkeit für Kunden mit Adresse in Deutschland geschaffen ihre „Core-Data“ in deutsche Region umzuziehen. Auf diesen Eintrag im Message Center bin ich in den letzten Wochen häufiger angesprochen worden, was auch der Anlass für diesen Artikel ist.

In den meisten Fällen lautet die Frage, die gestellt wird:

Sollen wir das machen?

Um das zu beantworten, muss man erst Mal die Vor- oder Nachteile kennen.

Was spricht für eine Migration?

         Aus Datenschutz-Perspektive ist es zwar egal, ob ich Daten in Deutschland oder der EU speichere, aber manche Firmen haben mit ihren Kunden Zusatzverträge abgeschlossen, dass Daten nur innerhalb Deutschlands gespeichert werden. Hier kann eine Migration in die Deutsche Region Vorteile bringen.

         Manche Kunden verbinden damit die Hoffnung eine bessere Netzwerkanbindung zu haben, wenn das Rechenzentrum näher ist. Microsoft warnt in seinen FAQ, dass ein geografisch nähergelegener Standort nicht unbedingt in einer besseren Anbindung resultieren muss. Wenn man aktuell Performance-Probleme im Netzwerk beim Zugriff auf M365 hat, wird sich das durch die Migration wahrscheinlich nicht ändern.

         Es handelt sich hier um ein einmaliges Angebot: Wer sich nicht im Zeitraum bis zum 30.04. für die Migration meldet, hat keine einfache Möglichkeit mehr die geografische Region für die Core-Data zu ändern (abgesehen von Multi-Geo-Funktionen).

Was spricht gegen eine Migration?

         Es gibt während der Migration geringe Funktionseinschränkungen. Bei Exchange betrifft das bestimmte Szenarien für den Zugriff auf geteilte Postfächer. Bei SharePoint ist die Suche während der Migration nicht aktuell (neuste Inhalte können fehlen) für einen Zeitraum von 24-48 Stunden. Mehr Details gibt es dazu hier.

         Zu Beginn waren manche Funktionen nicht verfügbar, wenn man in der deutschen Region war. Das hat v.a. Teams Liveereignisse betroffen – leider gibt es hierzu aktuell keine offizielle Dokumentation, ob die Einschränkung jetzt aufgehoben wurde. Hierzu folgt aber noch ein Update in diesem Artikel!

Und sollen wir das jetzt machen?

Die Argumente dafür sind genauso schwach, wie die Gründe dagegen. Die Möglichkeit wurde nicht für Deutschland „erfunden“, sondern vorab schon in anderen Ländern angeboten (z.B. Japan, Süd-Korea oder Australien). Durch die EU fällt die Unterscheidung in Deutschland daher schwerer, letztendlich würde ich mich aber für eine Migration nach Deutschland entscheiden. Wer weiß was in Zukunft noch für Dienste mit Anforderungen an ultra-niedrige Latenzen entstehen. Auch anderen Unsicherheiten wird so vorgebeugt (vielleicht zieht es die Iren plötzlich auch aus der EU oder die Niederlanden versinken im Meer …).

Alle Informationen von Microsoft zum Nachlesen gibt es noch mal hier:

How to request your data move – Microsoft 365 Enterprise | Microsoft Docs

During and after your data move – Microsoft 365 Enterprise | Microsoft Docs

Data move general FAQ – Microsoft 365 Enterprise | Microsoft Docs

AvePoint Governance meets Education

Governance & Compliance Logo

Mit dem Einzug von Microsoft 365 in die Unternehmen ist zunehmend auch die Bereitschaft der IT vorhanden, den Anwendern mehr Services zur direkten Verfügung zu stellen ohne vorherige Anträge. Das ist gut so, denn die teilweise langen und umständlichen Bereitstellungszeiten durch die IT sind oftmals der Grund für Anwender gewesen sich dann doch in Richtung Dropbox umzuschauen. Ganz ohne Regeln geht es in einigen Unternehmen aber nicht. Heute steht dabei eine Branche im Fokus die sehr heterogene Nutzergruppen aufweist: Hochschulen. Sobald man Teams für die Lehre einsetzt, müssen Studenten zwangsweise auch gewisse Berechtigungen in Teams bekommen. Wie viele Berechtigungen ist dann oftmals eine Frage der konkreten Anforderungen, allerdings lässt der Standard nur wenige Einstellungen vor. Mit der AvePoint Governance-Lösung hat man hier deutlich mehr Gestaltungsspielraum. Im Folgenden bauen wir ein einfaches Szenario auf in dem Studenten, Lehrkräfte und Verwaltung ganz eigene Möglichkeiten haben und keiner für seine tägliche Arbeit auf die Zuarbeit der IT angewiesen ist.

In AvePoint Governance stellt alles, was man Endanwendern bereitstellen möchte einen Service dar. Ein Service kann die unterschiedlichsten Dinge darstellen, in unserem Fall ist es der Service, dass man sich ein MS Teams nach bestimmten Vorgaben anlegen lassen kann.

Alle Konfigurationen für Services aufzulisten würde hier den Rahmen sprengen, für die Erstellung von Teams habe ich hier mal meine Favoriten herausgepickt:

  • Wer kann diesen Service in Anspruch nehmen?
    Hier kann man auf eine Filterung nach Azure AD Eigenschaften setzen oder manuell Listen pflegen. In den meisten Fällen sollten die Azure AD Eigenschaften praxistauglicher sein.
  • Für welche Sprache soll der Service bereitgestellt werden?
    Dass das Thema Mehrsprachigkeit direkt mit berücksichtigt wurde sorgt bei mir für weitere Pluspunkte – auch Benachrichtigungs-Mails & Co können in verschiedenen Sprachen hinterlegt werden.
  • Welches Site Design soll die mit dem Team verbundene SharePoint Site erhalten?
    Die Kopplung mit Site Designs ist ein echtes Highlight für mich. Über Site Designs kann man fast alle wichtigen SharePoint-Elemente mit bereitstellen lassen, z.B. zusätzliche Navigationslinks auf der Seite oder bestimmte Metadaten-Spalten in Bibliotheken.
  • Soll das Team (bzw. die M365 Group) in Outlook als Postfach sichtbar sein?
    Im Standard hängt diese Einstellung davon ab, wo man die Gruppe erstellt hat: In Outlook oder in Teams. Mit dieser Option kann man es so kontrollieren wie man möchte. Theoretisch auch denkbar: Ein eigener Service für die Anwender, der nur diese Eigenschaft im Self-Service steuerbar macht.
  • Welches Template soll verwendet werden?
    Wer möchte, hat hier die Möglichkeit auf vorab erstellte Teams als Template zurückzugreifen.
  • Welche Namenskonventionen sollen gelten?
    Bei Namenskonventionen scheiden sich die Geister: Auf der einen Seite machen Präfixe die Übersichtlichkeit in Teams kaputt, auf der anderen Seite hilft es Teams schnell in die richtige Kategorie stecken zu können. Grundsätzlich sollte man, falls überhaupt notwendig, ein möglichst kurzes Präfix verwenden.

Damit aber nicht genug, denn zu jedem Service kann man auch noch eine Policy auswählen. Über die Policy kann man dann eine ganze Reihe weiterer Eigenschaften kontrollieren, z.B.:

  • Quota (Speicherplatz für Dateien)
  • Darf die Seite mit Gästen geteilt werden?
  • Dürfen Mitglieder die Inhalte mit anderen Personen teilen oder nur der Owner?
  • Soll eine „Neuwahl“ eines Team-Owners ausgeführt werden, wenn der aktuelle deaktiviert oder gelöscht wird?
  • Wie oft müssen Mitglieder und Owner der Gruppe überprüft werden?
  • Wie oft soll überprüft werden, ob das Team noch benötigt wird?

Jetzt gilt es aus diesem Blumenstrauß an technischen Möglichkeiten ein Konzept zu entwickeln. In unserem theoretischen Szenario einer Hochschule könnte das wie folgt aussehen:

Studenten können eigenständig Teams anlegen (z.B. für Lerngruppen o.ä.), diese Teams sind durch Namenskonvention gut erkennbar, werden bei Inaktivität gelöscht und haben ein geringes Quota. Lehrkräfte können für Vorlesungen zeitlich beschränkte Teams erstellen, um das Team auch als Mail-Verteiler nutzen zu können, wird das Team in Outlook eingeblendet. Für die Verwaltung gibt es die wenigsten Regeln und Limitierungen, Lehrkräfte können für Teams ohne Studenten auch die Verwaltungs-Vorlage nutzen, um Teams zu erzeugen.

  Studenten Lehrkräfte Verwaltung
Namenskonvention STUD_  
Lebensdauer 90 Tage Inaktivität mit Infomail vor Löschung ca. 1 Semester mit Approval vor Löschung 365 Tage Inaktivität mit Approval vor Löschung
Quota 2GB
Aktion bei fehlendem Owner Neuwahl Service-Request mit Approval Service-Request mit Approval
Sichtbarkeit Outlook Nein Ja Ja
Externes Teilen Nein Nein Ja
Review Team-Mitglieder Nein Nein Ja, alle 365 Tage

Das Charmante an der AvePoint Governance Lösung ist, dass man diese Vorgaben auch im Self-Service verändern lassen kann: Muss eine Lehrkraft ein Team mit externen Teilen, kann hier ein Service-Request via AvePoint erstellt werden mit dem die Lehrkraft das eigenständig anpassen kann. Eine weitere Variante ist es z.B. den Studenten über einen Self-Service-Request mehr Speicherplatz für ihr Team einzuräumen – hier könnte man dann auch einen Approval-Prozess einbauen, bei dem zunächst ein Sekretariat zustimmen muss, bevor die Speichererhöhung gewährt wird.

Die genaue Ausprägung der Einstellungen wird jeder für sich vornehmen müssen, genügend Möglichkeiten es für sich anzupassen sind technisch auf jeden Fall vorhanden. Ziel sollte es immer sein, jeder Anwendergruppe möglichst autonomes Arbeiten zu ermöglichen, ohne dabei die Kontrolle zu verlieren.

Wer sich weiter über das Thema Governance informieren möchte, findet auch in diesem Blogbeitrag von AvePoint sehr gute weiterführende Informationen!

Zweiter Faktor ohne Smartphone

Authenticator Logo

Fast jede Microsoft 365-Einführung ist unterschiedlich, aber fast alle haben einen gemeinsamen Nenner: Endlich ist es einfach möglich eine Multi-Faktor-Authentifizierung bei den Usern umzusetzen. Das freut den IT-Security-Beauftragten genauso wie den Datenschützer und das zurecht: Durch MFA werden laut Microsoft 99,9% der Angriffe auf Accounts erfolgreich abgewehrt. 

Spätestens jetzt sollten auch die letzten Zweifler einsehen, dass das Thema eine hohe Relevanz hat für die sichere Nutzung der Cloud-Dienste. Um loszulegen braucht es nur eine passende Lizenz bei Microsoft, ein paar Klicks, um eine Conditional Access Policy festzulegen und schon bekommen die Anwender beim nächsten Login die Aufforderung eine weitere Methode zur Authentifizierung zu hinterlegen. 

Der Admin / IT-Consultant, der es gut mit seinen Usern meint, hat vielleicht noch vorab eine kurze Warnung verschickt, dass da jetzt „so eine Meldung kommt“. In manchen Unternehmen, mit IT-affiner Belegschaft, soll das schon gereicht haben – in den meisten wird es aber jetzt erst richtig interessant. Denn, welche Optionen werden mir zur Multi-Faktor-Authentifizierung angeboten? Konkret stehen zur Auswahl: 

Ohne (dienstliches) Mobiltelefon bleibt die Option Anruf oder SMS auf eine Festnetznummer. Beides hat den entscheidenden Nachteil, dass es in der Regel an den Büroarbeitsplatz gebunden ist. Möchte ein Mitarbeiter also im Homeoffice den 2ten Faktor bestätigen, stehen wir vor einem Problem. Eine Variante dieses Problem zu lösen wäre, dass der Mitarbeiter einfach auf sein privates Smartphone zurückgreift. Aus Sicherheitsaspekten wäre das auf jeden Fall akzeptabel, aber die Erfahrung zeigt, dass das nicht jeder Mitarbeiter möchte. Genau diesen Problemfall gilt es jetzt aufzulösen.

Variante 1: Jeder Mitarbeiter mit MFA bekommt ein Smartphone.

Pro: Einfach.

Contra: Teuer. Wer sich damit anfreunden kann, ist an dieser Stelle fertig mit dem Blog. 

 

Variante 2: Wir suchen einen anderen zweiten Faktor. Aber wo bekommen wir den her? Was heißt überhaupt „mehrere Faktoren“? Die Theorie sagt, dass man mehrere (typischerweise zwei) Faktoren haben sollte. Also etwas, das man weiß, besitzt oder das man „ist“ (Biometrie). Der erste Faktor ist in der Regel immer etwas, das ich weiß: Mein Passwort. Biometrie als echter Faktor ist nach wie vor noch etwas komplizierter, somit verbleibt aus den drei Optionen nur noch „etwas das man besitzt“. Bei der Zusendung von TANs per SMS, Anruf oder App geht es also nur darum zu prüfen, ob ich ein Stück Hardware besitze. Dementsprechend gilt es jetzt ein anderes Stück Hardware zu suchen, das als zweiter Faktor dient. Die einfachste Variante ist es, das Firmennotebook hierfür zum Einsatz zu bringen. 

Computer statt Smartphone als zweiten Faktor 

Es mag zunächst wenig intuitiv erscheinen den Computer als zweiten Faktor einzusetzen, denn wo sollte sich der Mitarbeiter sonst einloggen? Aber es geht ja nicht um den Mitarbeiter, sondern um potenzielle Angreifer von außen und das diese Zugriff auf ein Firmennotebook haben, ist dann schon ungewöhnlich. Wichtig für das Konzept ist, dass es sich eben tatsächlich um einen bekannten Firmen-Computer handelt. Das lässt sich mit einfachen Mitteln in der Microsoft 365 Cloud feststellen. Wenn man noch über ein klassisches AD verfügt, ist die einfachste Variante den Hybrid-Join für Geräte zu aktivieren. Dadurch erhalten alle Domain-Joined-Devices einen „Sonderstatus“ im Azure AD. Diesen Sonderstatus kann ich dann in meinem Regelwerk für den Multi-Faktor-Zugriff (-> Conditional Access) abfragen und entsprechende Geräte von einer MFA-Abfrage via Smartphone ausnehmen. Wichtig dabei ist jetzt nur noch einen Prozess zu haben, der alte oder verlorengegangene Geräte auch aus dem eigenen Verzeichnis entfernt. Mitarbeiter müssen weiterhin sensibilisiert werden den Verlust eines Firmennotebooks unmittelbar zu melden. Alles in allem hat man aber so eine Variante, wie man bei einem hohen Sicherheitsniveau die Zahl der SMS-Tokens deutlich reduziert und die Notwendigkeit für Firmen-Smartphones in der breiten Masse abschaffen kann. 

Bitte einmal Windows 10, sicher und zum Mitnehmen!

Windows 10 Logo

Windows 10 bietet für Unternehmen eine fast unüberschaubare Anzahl von Hebeln und Schaltern (bzw. Registry Keys), um das System gegenüber dem Auslieferungszustand zu härten. Während man in großen Konzernen über die Kapazitäten verfügt sich alle wichtigen Einstellungen zu erarbeiten und regelmäßig auch neue Sicherheitsfeature für sich aktivieren kann, ist das für viele Unternehmen mit kleineren IT-Abteilungen eine Mammutaufgabe. 

Um dem entgegenzuwirken hat Microsoft das Konzept der Security Baselines ins Leben gerufen. Bei den Security Baselines handelt es sich um ein Bündel von Einstellungen, die man über Intune auf damit verwaltete Geräte zur Anwendung bringen kann. Die Einstellungen sind dabei so gewählt, dass diese gängigen Empfehlungen für eine sichere Arbeitsumgebung folgen. Wer sich jetzt auf eine „Fire & Forget“-Funktion freut den muss ich leider enttäuschen: Auch wenn diese Funktion den Client auf einen Schlag sicher macht, ist eine Detailbetrachtung einiger Optionen immer noch notwendig. Denn ein sicherer Client ist einer auf dem man nicht mehr alles kann und darf. Wer diese Baselines beispielsweise an Softwareentwickler ausrollt, darf sich auf einigen Unmut gefasst machen. Weiterhin erscheinen regelmäßig (alle paar Monate) Updates für diese Baselines, durch die dann neue Funktionen in die Nutzung gebracht werden. 

Dazu kommt, dass es mittlerweile nicht nur ein Security Baseline gibt, sondern einmal für  

  • Windows 10 (MDM Security Baseline) 
  • Microsoft Defender ATP 
  • Microsoft Edge 

Um mit den Baselines zu starten empfiehlt es sich diese zunächst mal für ein paar Testgeräte zu aktivieren. Eine gute Anleitung zum Start findet man in der Microsoft Dokumentation: https://docs.microsoft.com/de-de/mem/intune/protect/security-baselines#manage-baselines  

Wichtig ist es im Schritt „Assignments“ eine passende Testgruppe für die Geräte zu wählen mit denen man seine Tests fährt. Am besten startet man mit den Windows 10 Baselines, verprobt diese gegen die wichtigsten Anwendungen und nimmt dann einzelne, problematische Einstellungen zurück. Sobald man hier eine stabile, eigene Baseline gefunden hat, kann man damit starten diese einem breiteren User-Kreis zur Verfügung zu stellen. Auf die gleiche Art und Weise kann man sich bei den Baselines für Edge und den Defender ATP (sofern in Nutzung) durcharbeiten.  

Im nächsten Blog-Artikel zu diesem Thema gehen wir dann auf ein paar der Einstellungen genauer ein und erklären, welche besonders häufig zu Problemen bei den Anwendern führen.