M365 Teams | richtig absichern

Microsoft Teams läuft in unzähligen Umgebungen direkt nach der Lizenzzuweisung mit den Standardeinstellungen. Das Resultat: Nutzer erstellen eigene Teams, laden unkontrolliert externe Gäste ein und integrieren ungeprüfte Drittanbieter-Apps.

Die Angriffsfläche für Datenabfluss wächst mit jedem Klick. Das Zielbild für eine saubere IT-Infrastruktur sieht anders aus. Eine strukturierte Teams-Umgebung kombiniert harte Governance-Regeln mit strikten Sicherheitsrichtlinien auf Basis der zugrundeliegenden Identitäten, wodurch du kontrolliertes Wachstum erreichst und Unternehmensdaten schützt.

Microsoft Teams ist kein isolierter Dienst. Die Plattform fungiert als zentraler Hub und greift permanent auf verschiedene Backend-Dienste zu. Wenn du ein neues Team erstellst, legt das System im Hintergrund automatisch eine Microsoft-365-Gruppe an. Diese Gruppe bildet die Basis für Berechtigungen und bündelt verschiedene Dienste. Durch diese Verknüpfung erhält das Team eine zentrale Stelle für Unterhaltungen, die Dateiablage, Notizen und die Aufgabenplanung.

Die eigentlichen Chat-Nachrichten und Kanal-Unterhaltungen speichert Teams in einer Azure Cosmos DB. Für Compliance-Zwecke erzeugt die Substrate-Schicht Kopien dieser Nachrichten und legt sie in versteckten Ordnern in Exchange Online ab. Genau auf diese Kopien greifen eDiscovery und Aufbewahrungsrichtlinien zu, nicht auf die produktiven Daten in Cosmos DB. Dateien aus Kanal-Unterhaltungen landen in einer dedizierten SharePoint-Dokumentenbibliothek, während Dateien aus privaten Chats im OneDrive for Business des jeweiligen Senders gespeichert werden.

Private und freigegebene Kanäle brechen dieses Muster auf. Beide erhalten eine eigene SharePoint-Site außerhalb der Team-Site, Nachrichten aus privaten Kanälen liegen in den Postfächern der Kanalmitglieder, Nachrichten aus freigegebenen Kanälen in einem Systempostfach des Kanals. Wer Berechtigungen nur auf Ebene der Team-Site prüft, übersieht diese Nebenschauplätze.

Diese verteilte Architektur erfordert ein übergreifendes Sicherheitskonzept. Wenn du Teams absichern willst, musst du zwangsläufig Entra ID, Exchange und SharePoint in deine Strategie einbeziehen. Eine isolierte Betrachtung des Teams-Clients greift zu kurz, da die eigentlichen Daten in den angebundenen Cloud-Speichern liegen.

Der erste Schritt zur Absicherung beginnt vor der eigentlichen Nutzung. Die unkontrollierte Erstellung von Teams führt schnell zu Wildwuchs mit doppelten Teams, fehlenden Namenskonventionen und ungeklärter Zuständigkeit. Weil jedes neue Team eine Microsoft-365-Gruppe erzeugt, setzt du den Hebel genau dort an und beschränkst die Gruppenerstellung auf eine dedizierte Security Group. Dadurch entstehen Teams bewusst und nach einem festgelegten Prozess.

Die Oberfläche im Entra Admin Center kennt dafür allerdings nur einen Schalter mit zwei Zuständen. Unter Groups > General setzt du die Option zur Erstellung von Microsoft-365-Gruppen auf No und sperrst damit alle Nicht-Administratoren. Die gezielte Freigabe für einen definierten Personenkreis konfigurierst du über Graph PowerShell im Directory-Setting Group.Unified: EnableGroupCreation auf false, GroupCreationAllowedGroupId auf die Objekt-ID deiner Security Group. Die Mitglieder dieser Gruppe brauchen eine Entra ID P1 Lizenz, sonst ist die Konfiguration lizenzrechtlich nicht gedeckt.

Durch Namenskonventionen in Entra ID mit Präfixen oder Suffixen wird der Verwendungszweck eines Teams sofort für alle Teilnehmer sichtbar. Ein Präfix wie INT für interne und EXT für externe Zusammenarbeit reicht als Einstieg. Vergib außerdem mindestens zwei Besitzer pro Team, denn ein einzelner Besitzer blockiert nach seinem Austritt jede Mitglieder- und App-Verwaltung im Team.

Um Karteileichen zu vermeiden, aktivierst du eine Ablaufrichtlinie für Microsoft-365-Gruppen unter Entra Admin Center > Groups > Expiration. Diese Richtlinie ist im Auslieferungszustand deaktiviert. Inaktive Gruppen werden nach einer definierten Zeit automatisch entfernt, was das Risiko unbemerkter Zugriffsrechte auf verwaisten Datenbeständen senkt. Aktivität in Outlook, SharePoint oder Teams verlängert eine Gruppe automatisch, Besitzer erhalten vor Ablauf zusätzlich eine Benachrichtigung. Gelöschte Gruppen lassen sich 30 Tage lang wiederherstellen, danach verschwinden die Daten endgültig. Kalkuliere auch hier die Lizenzen ein: Der Tenant muss Entra ID P1 oder P2 für alle Mitglieder der betroffenen Gruppen vorhalten, eine Zuweisung an jeden einzelnen Nutzer verlangt Microsoft dagegen nicht.

Unkontrollierter Gastzugriff ist eine der häufigsten Schwachstellen in Microsoft-365-Tenants. Gäste in Teams können in der Standardeinstellung auf Chats, Dateien und Kanäle zugreifen. Ohne entsprechende Einschränkungen erhalten externe Personen Zugang zu internen Diskussionen und Dokumenten, die überhaupt nicht für sie bestimmt sind. Du musst Guest Access Policies definieren. Diese Richtlinien regeln präzise, wer Gäste einladen darf, welche Berechtigungen diese Gäste erhalten und wie lange der Gastzugriff gültig ist.

Neben dem Gastzugriff läuft die externe Kommunikation über einen zweiten Kanal: External Access ist im Standard aktiv und erlaubt Chats mit anderen Organisationen sowie mit nicht verwalteten Teams-Konten. Genau diesen Weg nutzen Angreifer, die sich als IT-Support ausgeben. Schalte die Kommunikation mit nicht verwalteten Teams-Konten ab oder ersetze die offene Föderation durch eine Domain-Allow-List für bekannte Partner.

Die Verwaltung endet nicht mit der Einladung. Ohne regelmäßige Überprüfungen bleiben Gastkonten in Entra ID aktiv, auch wenn die eigentliche Zusammenarbeit an einem Projekt längst beendet ist. Entra ID Access Reviews automatisieren diesen Prozess und nehmen die Gruppenbesitzer in die Pflicht, sodass diese die Notwendigkeit der Gastzugänge bestätigen müssen. Diese Funktion setzt Entra ID P2 oder Entra ID Governance voraus, für die Überprüfung von Gastkonten rechnet Microsoft zusätzlich nach Nutzung ab. Ohne passende Lizenz bleibt dir der manuelle Weg über eine gefilterte Abfrage der Gastkonten und deren letzter Anmeldung.

Standardmäßig erlaubt das zugrundeliegende SharePoint in vielen Tenants das Teilen mit externen Personen auch völlig anonym. Ohne eine harte Einschränkung dieser Richtlinien können Mitarbeiter sensible Teams-Dokumente unkontrolliert nach außen freigeben. Anonyme Freigabelinks entkoppeln den Datenzugriff vollständig von einer überprüfbaren Identität.

Prüfe deshalb die organisationsweite Freigabestufe im SharePoint Admin Center und setze sie auf Neue und vorhandene Gäste oder restriktiver. Durch diese Maßnahme zwingst du externe Partner zur Authentifizierung und machst den Datenabfluss nachvollziehbar. Der Wert auf Tenant-Ebene wirkt als Obergrenze, einzelne Sites kannst du danach nur noch strenger konfigurieren, niemals offener.

Apps in Teams sind keine kleinen Komfortfunktionen für die Anwender. Es handelt sich um tiefe Integrationen mit einem eigenen Berechtigungsmodell und API-Zugriff auf Tenant-Daten. Wenn Nutzer eigenständig Apps aus dem Store hinzufügen dürfen, besteht die Gefahr, dass unsichere Anwendungen weitreichende Zugriffsrechte auf sensible Informationen erhalten.

Die Steuerung läuft inzwischen über App Centric Management. Microsoft hat die früheren App Permission Policies als veraltet gekennzeichnet und migriert Tenants auf das neue Modell, bei dem du jeder App einzeln zuweist, welche Nutzer und Gruppen sie einsetzen dürfen. Die drei Zustände lauten Everyone, Specific users or groups und No one. Prüfe zuerst auf der Seite der Berechtigungsrichtlinien, ob dein Tenant bereits migriert wurde, denn in migrierten Tenants greifen die alten Policies nicht mehr, auch wenn ein Skript mit Set-CsTeamsAppPermissionPolicy weiterhin ohne Fehler durchläuft.

Die pauschale Sperre für Drittanbieter-Apps setzt du in den organisationsweiten App-Einstellungen auf der Seite Apps verwalten. Anschließend gibst du gezielt die Anwendungen frei, die den internen Datenschutzvorgaben entsprechen und für den Geschäftsbetrieb notwendig sind. Dieser Allow-List-Ansatz schließt den Weg, über den Daten sonst über unautorisierte Schnittstellen abfließen. Deaktiviere im selben Zug die Einbindung von Drittanbieter-Speichern wie Dropbox oder Google Drive, weil abgelegte Dateien sonst deiner Kontrolle und deinen Aufbewahrungsrichtlinien entzogen sind.

Die Identität der Nutzer ist die primäre Sicherheitsgrenze. Conditional Access steuert den Zugriff auf Microsoft Teams auf Basis von Signalen in Echtzeit und setzt eine Entra ID P1 Lizenz voraus, die in Microsoft 365 Business Premium und E3 enthalten ist. Eine saubere Basis-Policy verlangt für jeden Zugriff auf Microsoft-365-Ressourcen zwingend eine Multi-Faktor-Authentifizierung (MFA). Ohne MFA können Angreifer mit gestohlenen Passwörtern direkt auf den Tenant und somit auf alle Teams-Daten zugreifen.

Der klassische Bypass über Legacy-Protokolle wie IMAP oder POP3 zielt nicht auf Teams, sondern auf Exchange Online, und Microsoft hat Basic Authentication für diese Protokolle bereits Ende 2022 abgeschaltet. Offen bleibt Basic Auth bei der Client Submission über SMTP AUTH, die Microsoft nach mehreren Verschiebungen zum Jahresende 2026 standardmäßig deaktiviert. Eine Conditional-Access-Regel gegen Legacy-Authentifizierung behältst du trotzdem: Diese Regel fängt Clients ab, die auf keine moderne Authentifizierung umgestellt wurden, und verhindert, dass eine reaktivierte Ausnahme unbemerkt zur offenen Tür wird.

Zusätzlich definierst du Richtlinien für nicht verwaltete Geräte (BYOD). Der Hebel liegt dabei nicht im Teams-Client, sondern in den Daten dahinter. Über die App Enforced Restrictions greifst du auf SharePoint Online und OneDrive durch, sodass Dateien auf einem privaten Rechner nur im Browser geöffnet werden. Downloads, Druck und Synchronisierung über den OneDrive-Client sind dann technisch unterbunden, während der Chat im Teams-Client weiter funktioniert. Wer den Zugriff härter fassen will, kombiniert die Session-Steuerung mit einer Grant-Regel, die kompatible oder Entra-hybrid-eingebundene Geräte verlangt. Beachte dabei, dass eine Conditional-Access-Regel auf SharePoint immer auch auf Teams wirkt, weil der Client seine Dateien aus SharePoint bezieht.

MFA ist die Basis, birgt aber auch Risiken bei Fehlkonfigurationen oder Ausfällen des Authentifizierungsdienstes. Ohne Break-Glass-Accounts kann ein fehlerhaft konfigurierter Conditional-Access-Blocker den gesamten Tenant lahmlegen. Diese dedizierten Notfallkonten schließt du deshalb von allen blockierenden Zugriffsrichtlinien aus.

Ein reines Passwort im Tresor reicht dafür nicht mehr. Microsoft erzwingt MFA für die Anmeldung an den Verwaltungsportalen unabhängig von Conditional Access, weshalb auch das Notfallkonto eine phishing-resistente Methode registriert haben muss, etwa einen FIDO2-Schlüssel oder zertifikatsbasierte Authentifizierung. Wähle dabei bewusst ein anderes Verfahren als für die täglichen Admin-Konten, damit ein Ausfall des regulären Verfahrens dich nicht gleichzeitig aus dem Notfallzugang aussperrt. Hardware-Token und Zugangsdaten gehören physisch weggeschlossen, die Anmeldungen dieser Konten gehören überwacht.

Jeder dauerhaft zugewiesene administrative Account vergrößert die Angriffsfläche. Das Prinzip des Least Privilege bedeutet hier den Verzicht auf permanente Rechte als Globaler Administrator. Spezialisierte Rollen wie Teams-Administrator oder SharePoint-Administrator begrenzen den potenziellen Schaden bei einer Account-Kompromittierung. Privileged Identity Management (PIM) reduziert diese dauerhaften Rechte weiter, indem hohe Berechtigungen nur zeitweise, mit Begründung und nachvollziehbar aktiviert werden. PIM setzt Entra ID P2 voraus.

Die Konfiguration und der sichere Betrieb von Microsoft Teams erfordern ein tiefgreifendes Verständnis der zugrundeliegenden Architektur. Teams ist kein isoliertes Produkt. Es fungiert als Schnittstelle, die Daten und Dienste aus dem gesamten Microsoft-365-Ökosystem aggregiert und den Nutzern präsentiert. Wenn du die Sicherheitseinstellungen im Teams Admin Center anpasst, musst du immer die Auswirkungen auf SharePoint, OneDrive und Entra ID mitdenken. Das blinde Deaktivieren von Funktionen ist keine gangbare Lösung, da Anwender bei zu starken Einschränkungen schnell auf unsichere Alternativen außerhalb der Unternehmens-IT ausweichen. Eine sichere Umgebung entsteht durch die bewusste Steuerung von Berechtigungen, Datenflüssen und Identitäten.

Die Beschränkung der Gruppenerstellung auf autorisierte Nutzer, die konsequente Überwachung von Gastzugriffen mittels Access Reviews und das strenge Management von Drittanbieter-Apps bilden das Minimum an administrativer Sorgfalt. Conditional Access flankiert diese Maßnahmen auf technischer Ebene, indem es den Zugriff anhand von Geräte-Compliance und Identitätsrisiken dynamisch steuert. Prüfe vor der Planung die vorhandenen Lizenzen, denn Ablaufrichtlinien, Access Reviews und PIM hängen an Entra ID P1, P2 oder Governance und lassen sich ohne diese Basis nicht umsetzen.

Wer den aktuellen Sicherheitsstatus seines Tenants bewerten und verbessern möchte, findet in dem Dokument "Hardening-Checkliste-Microsoft-365.pdf" eine belastbare Grundlage. Die Checkliste deckt systematisch ab, an welchen Stellen die Standardeinstellungen von Microsoft Schwachstellen aufweisen und mit welchen exakten Klickpfaden Administratoren diese Lücken schließen. Die Umsetzung all dieser Maßnahmen erfordert Zeit und eine saubere Kommunikation mit den betroffenen Fachabteilungen. Langfristig bewahrt eine nach Best Practices gehärtete Architektur das Unternehmen jedoch vor massivem Datenabfluss und teuren Datenschutzverletzungen. Der initiale Aufwand für eine saubere Konfiguration rechnet sich bei jedem verhinderten Sicherheitsvorfall um ein Vielfaches.