Microsoft Teams in KRITIS-Umgebungen

Management Summary

Microsoft Teams kann in Kritischen Infrastrukturen (KRITIS) – etwa Energieversorgern, Gesundheitswesen, Finanzsektor oder öffentlicher Verwaltung – sicher und regelkonform eingesetzt werden, sofern bestimmte organisatorische und technische Voraussetzungen erfüllt sind. Dieser Leitfaden beschreibt ein Zielbetriebsmodell mit hohem Sicherheitsniveau, das sowohl aktuellen gesetzlichen Anforderungen (IT-Sicherheitsgesetz 2.0, NIS2-Richtlinie, DSGVO) als auch dem besonderen Schutzbedarf von KRITIS entspricht.

Quick Wins (90 Tage): In den ersten 90 Tagen sollten Sie die grundlegenden Sicherheitsmaßnahmen umsetzen. Dazu zählen die flächendeckende Einführung von Mehrfaktor-Authentifizierung (MFA), erste Conditional Access-Regeln (z.B. Zugriff nur von geprüften Geräten), eine klare Zuständigkeitsverteilung (Rollen & Verantwortlichkeiten) sowie kurzfristige Schulungen für Administratoren und Benutzer. Diese Schritte erhöhen sofort das Sicherheitsniveau und adressieren zentrale Risiken wie unbefugte Zugriffe oder unkontrollierte Datenfreigaben.

Mittelfristige Roadmap (12 Monate): Innerhalb eines Jahres sollten Sie eine vertiefte Härtung und Integration vornehmen: Einrichtung einer umfassenden Governance (Teams-Lebenszyklus, App-Freigaben, Änderungsmanagement), Implementierung von Datenschutz- und Compliance-Funktionen (DLP-Regeln, Sensitivitätslabel, Aufbewahrungsrichtlinien) sowie die Anbindung von Überwachungs- und Alarmierungssystemen (SIEM, Security Operations Center). Außerdem sollten Notfallkommunikation und Microsoft-Teams-Telefonie so gestaltet werden, dass auch bei Ausfällen oder Krisen die Erreichbarkeit – insbesondere von Notrufnummern – jederzeit gewährleistet bleibt.

Risiken bei Untätigkeit: Ohne zeitnahe Maßnahmen drohen erhebliche Risiken. Dazu zählen Sicherheitsvorfälle durch kompromittierte Accounts oder Datenlecks, Betriebsunterbrechungen mangels Vorbereitung auf Ausfälle sowie Compliance-Verstöße, die zu behördlichen Sanktionen führen können. Dieser Artikel bietet daher einen prüfsicheren Rahmen, um Microsoft Teams proaktiv in eine KRITIS-konforme Gesamtlösung einzubetten und Kommunikationsprozesse sowohl effektiv als auch regelkonform zu gestalten.

1. Ausgangslage und KRITIS-Spezifika

Kritische Infrastrukturen unterliegen besonderen Anforderungen an Verfügbarkeit, Integrität, Vertraulichkeit und Nachvollziehbarkeit der Kommunikation. Im KRITIS-Umfeld hat die Aufrechterhaltung wichtiger Geschäftsprozesse oberste Priorität – Ausfälle oder Sicherheitsvorfälle in der Kommunikationsplattform können unmittelbare Auswirkungen auf die Versorgungssicherheit oder öffentliche Ordnung haben. Microsoft Teams als zentrale Kollaborations- und Kommunikationsplattform bietet grundsätzlich hohe Verfügbarkeit durch die global verteilte Microsoft-365-Cloud und integrierte Sicherheitsfunktionen. Allerdings muss ein Standard-M365-Tenant gezielt für KRITIS-Bedürfnisse gehärtet werden, da die werkseitigen Standardeinstellungen nicht sämtliche regulatorischen und sicherheitstechnischen Anforderungen abdecken.

Teams-Workloads: Microsoft Teams bündelt verschiedene Workloads – Chat und Präsenzinformationen, Besprechungen (Audio/Video-Konferenzen), Kanäle für Team-Zusammenarbeit, Telefonie (VoIP/Telefonanlagen-Funktionalität) sowie die Einbindung von Apps und Workflows. Diese breite Nutzung macht Teams zu einem unverzichtbaren Werkzeug, birgt aber zugleich vielfältige Angriffs- und Ausfallflächen. Beispielsweise erfordert die Chat- und Dateifreigabe besondere Maßnahmen gegen Datenabfluss, während bei Meetings und Anrufen die Echtzeitdienste robust gegen Netzwerkstörungen sein müssen.

KRITIS-Härtung vs. Standard-Tenant: Ein KRITIS-Tenant unterscheidet sich von einem herkömmlichen Office-365-Tenant durch zusätzliche Schutzmechanismen und strengere Vorgaben. Dazu zählen unter anderem restriktivere Sicherheitsrichtlinien, intensives Monitoring, erweiterte Protokollierung und klar definierte Betriebsprozesse. Ziel ist es, ein Niveau zu erreichen, das dem „Stand der Technik“ gemäß §8a (3) BSI-Gesetz (BSIG) entspricht. Wo ein Standard-Tenant z.B. Gastzugriff und App-Installation relativ offen handhabt, gelten im KRITIS-Betrieb engere Richtlinien: Nur freigegebene Apps, definierte Gastszenarien und regelmäßige Überprüfungen garantieren die Kontrolle.

Mandantenstrategie (Ein- vs. Mehr-Tenant): Sie sollten früh eine passende Mandantenstrategie festlegen. Ein Single-Tenant-Ansatz – alle Nutzer arbeiten in einem zentralen M365-Tenant – erleichtert Governance und Datenauswertung, da alle Regeln einheitlich greifen. Alternativ kann ein Multi-Tenant-Ansatz gewählt werden, etwa um unterschiedliche Organisationseinheiten oder Sicherheitszonen zu trennen (z.B. ein separater Tenant für besonders sensible Bereiche oder externe Partner). Multi-Tenant-Strukturen erhöhen jedoch die Komplexität: Synchronisation von Identitäten, tenantübergreifende Kommunikation und Verwaltung werden aufwändiger. In den meisten Fällen empfiehlt sich für KRITIS-Betreiber ein einzelner, strikt segmentierter Tenant mit klar abgegrenzten Teams bzw. Kanälen für unterschiedliche Schutzbedarfe, anstatt viele getrennte Tenants zu betreiben.

Prüfpunkte für KRITIS:
– Gibt es eine dokumentierte Entscheidung zur Mandantenstrategie (Single vs. Multi-Tenant) mit Begründung?
– Wurden die spezifischen Anforderungen an Vertraulichkeit, Integrität, Verfügbarkeit und Nachvollziehbarkeit der Kommunikation in Ihrer KRITIS-Organisation identifiziert und priorisiert?
– Ist der verwendete Microsoft-365-Tenant als kritisch eingestuft und für höhere Sicherheitsanforderungen vorgesehen (im Vergleich zu Standard-Umgebungen)?
– Wurden bereits erste Abweichungen von den Standardeinstellungen identifiziert (z.B. offener Gastzugriff) und interimistisch adressiert?
– Liegt ein Management-Buy-in für zusätzliche Aufwände im Teams-Betrieb (Personal, Prozesse, Tools) vor, um KRITIS-Anforderungen gerecht zu werden?

2. Zielbild-Architektur für KRITIS

Ein Referenzarchitekturmodell für Microsoft Teams in KRITIS-Umgebungen umfasst alle relevanten Komponenten, Datenflüsse und Sicherheitszonen vom Endgerät bis zur Cloud. In der Zielarchitektur sind Vertrauenszonen klar abgegrenzt: die Internen Netze der Organisation (Clients und lokales Netz), die Perimeter-Sicherheitszone (Firewalls, Proxys, ggf. DMZ mit Telefonie-Gateways) sowie die Microsoft-365-Cloud als externe Zone. Alle Kommunikationswege zwischen diesen Zonen müssen gesichert, überwacht und bei Bedarf segmentiert sein. Nachfolgend werden die wichtigsten Architekturbausteine und ihre KRITIS-relevanten Anforderungen beschrieben.

Netzwerkpfade, Perimeter & QoS

Die Anbindung von Microsoft Teams erfordert performante und sichere Netzwerkpfade. Egress/Ingress: Für optimale Verfügbarkeit sollten Internetzugriffe für Teams möglichst direkt und redundant ausgelegt sein (lokaler Internet-Breakout pro Standort mit Backup-Leitungen), um Latenz und Ausfallrisiken zu minimieren. Perimeter: Firewalls und Proxys müssen so konfiguriert sein, dass die für Teams erforderlichen Ports und Ziele freigegeben sind. Dies umfasst u.a. HTTPS-Verbindungen zu Microsoft-Teams-Servern sowie UDP/TCP-Ports für Audio/Video (Standard: UDP 3478-3481 für STUN/TURN). TLS-Inspection-Bypass: Da Microsoft Teams eine Ende-zu-Ende-Verschlüsselung der Medien und Pinning von Zertifikaten nutzt, sollte jegliche Deep-Packet-Inspection oder TLS-Interception für Teams-Verkehr deaktiviert bzw. umgangen werden. Ein Bypass für Office-365-Traffic auf Proxy/Firewall-Ebene ist empfehlenswert, um Qualität und Sicherheit (keine erzwungene Downgrade von TLS) zu gewährleisten. DNS-Strategie: Interne DNS-Server sollten Microsoft-Cloud-Domains direkt auflösen oder Anfragen weiterleiten, ohne dass Cloud-Namen gefiltert werden. Ein falsch konfiguriertes DNS (z.B. Blockierung von *.teams.microsoft.com) kann die Erreichbarkeit beeinträchtigen. Quality of Service (QoS): Für die Priorisierung von Echtzeit-Verkehr ist QoS essenziell. Dazu werden DSCP-Markierungen (Differentiated Services Code Point) genutzt. Empfohlen ist eine Klassifizierung z.B. DSCP 46 (EF) für Audio, DSCP 34 (AF41) für Video und DSCP 18 (AF21) für Bildschirmfreigaben. Die Endgeräte können diese Markierungen setzen (via Gruppenrichtlinie oder Intune-Richtlinie), und die Netzwerkgeräte müssen QoS beachten, um bei Engpässen Sprach- und Video-Daten gegenüber weniger kritischem Traffic zu priorisieren.

Identität & Zugriff (Entra ID, MFA, Conditional Access, PIM)

Entra ID (ehemals Azure Active Directory) bildet das Identitäts- und Zugriffsmanagement für Teams. In KRITIS-Umgebungen ist eine robuste Authentifizierung und Autorisierung unabdingbar. MFA (Multi-Faktor-Authentifizierung) sollte für alle Benutzerkonten obligatorisch sein, um die Gefahr von Account-Kompromittierungen zu minimieren. Besonders privilegierte Konten (Administratoren) sind zwingend mit MFA und zusätzlichen Sicherheitsmaßnahmen (z.B. Hardware-Token, FIDO2-Keys) auszustatten. Conditional Access (Bedingter Zugriff) erweitert die Zugriffskontrolle: Sie definieren Richtlinien, unter welchen Bedingungen Nutzer auf Teams zugreifen dürfen (z.B. nur aus bestimmten Netzwerkbereichen, nur mit firmeneigenen oder compliant Geräten, keine signifikanten Risiko-Meldungen am Konto). Solche Richtlinien stellen sicher, dass z.B. ein Anmeldeversuch von einem unbekannten Auslandstandort oder von einem unsicheren Gerät blockiert oder mit Auflagen (wie zusätzlicher MFA) versehen wird. Privileged Identity Management (PIM) sollte eingesetzt werden, um Administratorrechte nur temporär und nach Bedarf zu vergeben (Just-in-Time Admin). So haben Administratoren nicht dauerhaft hohe Berechtigungen, was das Risiko einer missbräuchlichen Nutzung reduziert. Weiterhin empfiehlt sich die Einrichtung von Break-Glass-Konten: Dies sind Notfall-Admin-Konten ohne die strikten Conditional-Access-Regeln (aber mit hohen Sicherheitsvorkehrungen, z.B. komplexes Passwort, offline verwahrt), die im Notfall (z.B. Ausfall von MFA-Diensten oder Sperrung regulärer Admin-Accounts) den Zugriff auf den Tenant ermöglichen.

Verified ID und Rollenverwaltung: Microsoft Entra Verified ID erlaubt es, digitale Berechtigungsnachweise zu erstellen und zu überprüfen. In Zukunft können KRITIS-Betreiber damit etwa nachweisen, dass externe Partner oder Dienstleister eine Sicherheitsüberprüfung durchlaufen haben, bevor sie in sensiblen Teams als Gast hinzugefügt werden. Auch interne Nachweise, z.B. dass ein Mitarbeiter verpflichtende Schulungen absolviert hat, ließen sich so als Verified ID hinterlegen und vor dem Zugriff auf bestimmte kritische Teams überprüfen. Diese Technologien stehen ergänzend zur klassischen Rollen- und Rechteverwaltung: Jede Team-Berechtigung und Admin-Rolle sollte klar geregelt und gemäß dem Minimalprinzip vergeben sein.

Geräte & Compliance (Intune, Richtlinien, BYOD)

Die Endgeräte stellen das Frontend der Teams-Nutzung dar und sind somit ein wichtiger Teil der Sicherheitsarchitektur. Microsoft Intune (Endpoint Manager) dient zur Verwaltung und Absicherung von Clients. Alle dienstlich genutzten Geräte (Notebooks, Smartphones, Tablets), die auf Teams zugreifen, sollten durch Intune oder eine vergleichbare MDM/MAM-Lösung verwaltet sein. Über Compliance-Richtlinien wird sichergestellt, dass Geräte einen definierten Sicherheitsstatus aufweisen (z.B. Vollfestplattenverschlüsselung aktiviert, aktueller Patch-Stand, Virenschutz aktiv, kein Jailbreak/Rooting). Conditional Access kann diese Geräte-Compliance prüfen und den Zugriff auf Teams verweigern, wenn ein Gerät nicht konform ist. Für Bring Your Own Device (BYOD)-Szenarien, in denen private Geräte zugelassen werden, sollten zumindest App-Schutzrichtlinien gelten: Mit Intune App Protection Policies lassen sich z.B. auf privaten Smartphones die Teams- und Outlook-Apps isolieren (Container-Prinzip), sodass Unternehmensdaten nicht in unsichere Apps abfließen können (Clipboard-Schutz, Verbot von Speicherung in persönliche Clouds etc.). Ein konsequenter Geräte-Lifecycle (Onboarding neuer Hardware mit Sicherheitskonfiguration, regelmäßiges Überprüfen der Compliance, Offboarding inkl. remote Löschen von Unternehmensdaten bei Ausscheiden) ist im KRITIS-Umfeld Pflicht. Wenn BYOD nicht erforderlich ist, erwägen Sie, den Zugriff ausschließlich auf firmeneigene Geräte zu beschränken – dies reduziert die Variabilität und vereinfacht die Durchsetzung von Richtlinien.

Datenklassifikation & Schutz (Sensitivity Labels, DLP, Archivierung)

KRITIS-Organisationen verarbeiten häufig Informationen mit unterschiedlichen Schutzbedarfen – von öffentlich bis streng vertraulich. Sensitivity Labels (Vertraulichkeitskennzeichnungen) in Microsoft Purview ermöglichen es, Teams (bzw. die zugrunde liegenden M365-Gruppen und SharePoint-Sites) entsprechend zu klassifizieren. Beispielsweise kann ein Label „Vertraulich – intern“ verhindern, dass Gäste zu einem Team hinzugefügt werden, oder bestimmte Privacy-Einstellungen vorgeben. Solche Labels sollten für alle Teams verbindlich vorgegeben werden, idealerweise muss bereits bei der Team-Erstellung ein Label ausgewählt werden. Zusätzlich können DLP (Data Loss Prevention)-Richtlinien für Teams-Chats und -Dateien definiert werden. Diese erkennen und unterbinden z.B. das Teilen von Kreditkartennummern, Personaldaten oder vertraulichen Dokumenteninhalten in Chats oder Channel-Unterhaltungen, sofern dies gegen Richtlinien verstößt. Im Alarmfall wird der Vorgang blockiert oder gemeldet, und es können automatisierte Prozesse (Info an den Compliance-Beauftragten, Sensibilisierung des Nutzers) angestoßen werden.

E-Discovery & Aufbewahrung: Für Nachvollziehbarkeit und rechtliche Anforderungen (z.B. regulatorische Aufbewahrungspflichten) ist Microsoft Purview eDiscovery essenziell. Alle Teams-Chats und -Dateien sollten im Unified Audit Log erfasst sein. Aufbewahrungsrichtlinien legen fest, wie lange Chat-Nachrichten und Kanalbeiträge mindestens vorgehalten werden (z.B. 6 oder 10 Jahre, je nach Branche und gesetzlicher Vorgabe). Dabei ist zu beachten, dass eine längere Aufbewahrung zwar die Nachweisführung erleichtert, jedoch DSGVO-Anforderungen genügen muss (Daten nicht länger speichern als nötig, Löschung nach Frist). Für Teams bietet sich eine Archivierungsfunktion an: Abgeschlossene Projekte oder nicht mehr aktive Teams können im Tenant archiviert werden. Beim Archivieren wird das Team schreibgeschützt, bleibt aber für Audits und Nachschlagen erhalten. Zusätzlich sollten regelmäßige Backups bzw. Exporte kritischer Daten erwogen werden – etwa ein periodischer Export von Team-Wiki-Inhalten oder wichtigen Dateien, falls gesetzlich eine unveränderliche Archivierung gefordert ist.

Bedrohungserkennung & Reaktion (Defender, SIEM)

Eine zeitnahe Erkennung von Bedrohungen ist gemäß IT-SiG 2.0 (Pflicht zu Systemen zur Angriffserkennung) für KRITIS unverzichtbar. Microsofts Defender-Suite bietet hierfür mehrere Module: Defender for Endpoint schützt die Clients vor Malware und erkennt Angriffsverhalten; Defender for Office 365 prüft Links und Dateien, auch in Teams-Chats, auf Phishing oder Schadcode (Stichwort Safe Links/Safe Attachments); Defender for Cloud Apps überwacht anomaliehaftes Nutzerverhalten in Cloud-Diensten (z.B. Massen-Downloads aus Teams oder verdächtige Login-Muster) und kann Alarme auslösen oder Sessions blockieren. Darüber hinaus sollten Sie ein zentrales Security Information and Event Management (SIEM) anbinden. Sämtliche sicherheitsrelevanten Logs aus Entra ID, Teams, Intune, Defender, dem Netzwerk und ggf. dem SBC (Session Border Controller für Telefonie) sollten in ein SIEM eingespeist und korreliert werden. Dies ermöglicht die übergreifende Erkennung von Angriffsmustern (z.B. gleichzeitige Auffälligkeiten auf dem Gerät und im Konto eines Benutzers). Eine zeitgemäße Lösung ist etwa Microsoft Sentinel (Cloud-SIEM) oder ein bestehendes zentrales SIEM im Unternehmen. Wichtig ist auch die Log-Aufbewahrung: Da Vorfälle oft erst verspätet entdeckt werden, sollten Audit- und Security-Logs mindestens 6 bis 12 Monate, besser länger, revisionssicher gespeichert werden. Im Idealfall werden sie manipulationssicher (WORM-Prinzip) archiviert, um im Ernstfall als Beweismittel zu dienen.

Tabelle – Referenzkomponenten & KRITIS-Anforderungen:
 

Prüfpunkte für KRITIS:
– Sind alle relevanten Netzpfade für Teams (inkl. Notruffunktionen) redundant ausgelegt und gegen Ausfall gesichert?
– Wurden Proxy/Firewall so konfiguriert, dass Microsoft-365-Traffic nicht unerwünscht gefiltert oder verlangsamt wird (inkl. TLS-Inspection-Ausnahmen)?
– Sind MFA sowie geeignete Conditional-Access-Regeln für alle Benutzer (insb. Administratoren) aktiviert, sodass nur verifizierte Identitäten und konforme Geräte Zugriff erhalten (Zero-Trust-Prinzip)?
– Sind Sensitivitätslabels und DLP-Richtlinien für die Klassifizierung und den Schutz aller in Teams ausgetauschten Informationen implementiert und getestet?
– Werden sicherheitsrelevante Ereignisse in Echtzeit überwacht (Defender/SIEM) und existiert ein etabliertes Alarmierungs- und Reaktionsverfahren bei Incidents?

3. Governance & Betriebsmodell

Ein klar definiertes Governance-Modell stellt sicher, dass die Verantwortung für den Teams-Betrieb und die -Nutzung in geordneten Bahnen verläuft. Dabei hilft insbesondere eine RACI-Matrix (Responsible, Accountable, Consulted, Informed), um für zentrale Entscheidungen und Aufgaben festzulegen, welche Rolle verantwortlich ist, wer die Umsetzung durchführt, und wer konsultiert bzw. informiert werden muss. In KRITIS-Organisationen sollte Governance herstellerneutral und prozessual verankert sein – z.B. durch eine Betriebsrichtlinie für Collaboration-Tools und regelmäßige Governance-Boards, die über Ausnahmen und Änderungen entscheiden.

Rollen & Verantwortlichkeiten: Typische Rollen im Teams-Governance-Kontext sind etwa der Tenant-Verantwortliche (z.B. M365-Plattform-Owner), Teams-Service-Manager (operativer Betrieb), Sicherheitsbeauftragter bzw. CISO (für Security/Compliance-Entscheidungen), Datenschutzbeauftragter (für DSGVO-Belange), Fachbereichsleiter (Interessen der Nutzer) und IT-Support (für Anfragen und Störungen). Die nachfolgende RACI-Tabelle zeigt Beispiele für Zuständigkeiten bei wichtigen Entscheidungen:

RACI-Tabelle – Governance-Beispiele:
 

Lebenszyklusverwaltung: Die Verwaltung des Lebenszyklus von Teams (und dazugehörigen M365-Gruppen) ist essenziell, um Wildwuchs und verwaiste Ressourcen zu vermeiden. Legen Sie ein Namenskonzept fest, das z.B. Abkürzungen für Bereiche oder Projektcodes enthält. Beispielsweise könnten Teams nach dem Schema „Abteilung – Projekt – Jahr“ benannt werden (etwa „IT – Notfallplanung – 2025“). Ein konsistentes Schema erleichtert es, Teams anhand des Namens zuzuordnen und wiederzufinden. Weiterhin sollte die Provisionierung neuer Teams kontrolliert erfolgen: Anstatt unbeschränkter Selbstbedienung empfiehlt sich ein gesteuerter Prozess, etwa über ein Antragsformular oder ein automatisiertes Workflow-Tool, in dem der Bedarf begründet und von einer zuständigen Stelle genehmigt wird. Technisch lässt sich dies unterstützen, indem z.B. nur definierte Administratoren oder ein Bot Teams erstellen dürfen, ggf. mit vordefinierten Teams-Vorlagen (Templates), die bereits passende Kanäle, Apps und Einstellungen enthalten.

Wichtig ist auch die Rezertifizierung bestehender Teams: In regelmäßigen Abständen (z.B. jährlich) sollten Team-Owner bestätigen, dass ihr Team noch benötigt wird, dass die Mitgliederliste aktuell und berechtigt ist, und dass die Klassifizierung (Label) weiterhin zutreffend ist. Falls ein Team keine aktive Betreuung mehr hat oder nicht mehr gebraucht wird, sollte es konsequent archiviert oder gelöscht werden. Azure AD bietet eine automatische Gruppenablaufsteuerung (Group Expiration), bei der ungenutzte Gruppen/Teams nach einer definierten Zeit zur Verlängerung anstehen und ohne Bestätigung entfernt werden. Solche Mechanismen können helfen, die Umgebung schlank zu halten, müssen aber sorgfältig eingeführt werden (Kommunikation an die Nutzer, Möglichkeiten zur Wiederherstellung aus dem Archiv falls versehentlich gelöscht, etc.).

App-Zulassungsprozess & Shadow IT: Microsoft Teams lässt sich mit einer Vielzahl von Apps und Bots erweitern, was den Nutzen steigert, aber auch Risiken birgt. Definieren Sie einen App Governance-Prozess: Neue Drittanbieter-Apps oder eigene Entwicklungen sollten vor der Freischaltung geprüft werden – u.a. hinsichtlich Sicherheit (Wer ist der Anbieter? Wohin fließen die Daten?), Compliance (Speicherung von Inhalten außerhalb der EU?) und Nutzen. Ein internes Gremium (z.B. IT-Governance-Board oder die IT-Sicherheitsabteilung) sollte solche Apps bewerten. Im Teams Admin Center kann die App-Bereitstellung so konfiguriert werden, dass standardmäßig alle Apps blockiert sind und nur freigegebene auf eine Allow-Liste kommen. Alternativ kann man zumindest App-Berechtigungsrichtlinien nutzen, um bestimmten Benutzergruppen den Zugriff auf Apps zu erlauben oder zu verwehren. Achten Sie dabei auch auf Shadow IT: Wenn Nutzer benötigte Funktionen in Teams nicht vorfinden oder zu stark eingeschränkt werden, besteht das Risiko, dass sie auf inoffizielle Lösungen (WhatsApp, private Cloud-Speicher etc.) ausweichen. Dies kann durch transparente Prozesse (Wunsch nach neuer Funktion melden, schnelle Prüfung und Feedback) und durch Monitoring (z.B. erkennt ein Cloud Access Security Broker die Verwendung von nicht freigegebenen Anwendungen) adressiert werden. Ziel ist, einerseits die Sicherheit zu wahren, andererseits aber die Produktivität nicht durch übermäßige Restriktionen zu hemmen.

Änderungsmanagement: Änderungen an der Teams-Umgebung – seien es neue Funktionen, Policy-Änderungen oder technische Anpassungen – sollten einem formalen Change Management unterliegen. In einer KRITIS-Organisation ist ein freigegebener Change-Prozess wichtig: Jede Änderung sollte dokumentiert, risikobewertet und von den zuständigen Stellen genehmigt werden (Vier-Augen-Prinzip). Praktisch empfiehlt sich die Einrichtung von Test- bzw. Pilotphasen: Beispielsweise können neue Funktionen erst in einem separaten Test-Tenant oder für einen begrenzten Pilotnutzerkreis aktiviert werden. Microsoft bietet über den Targeted Release-Ring die Möglichkeit, Neuerungen vorab zu evaluieren. Nutzen Sie zudem Wartungsfenster für geplante Änderungen: Kritische Konfigurationsänderungen (z.B. Umstellung der Conditional-Access-Policies, Updates am SBC) sollten außerhalb der Kernarbeitszeiten erfolgen und den Benutzern angekündigt werden, falls Auswirkungen spürbar sein könnten. Halten Sie für jede Änderung einen Rollback-Plan bereit, falls unerwartete Probleme auftreten. Dokumentieren Sie die Änderung im Betriebsprotokoll und prüfen Sie nach Umsetzung die Sollfunktion (Post-Change Testing). Zudem sollte es einen Prozess geben, um Microsoft-Updates im Blick zu behalten (z.B. per RSS-Feed/Change Log des Microsoft 365 Admin Centers), damit notwendige Reaktionen (Anpassung interner Dokumentation, Schulung der Nutzer) rechtzeitig erfolgen können.

Prüfpunkte für KRITIS:
– Sind alle relevanten Rollen rund um Teams klar benannt und mit Verantwortlichkeiten hinterlegt (ggf. in einer RACI-Matrix dokumentiert)?
– Existiert ein verbindliches Verfahren zur Anlage neuer Teams inkl. Namenskonvention, Freigabe durch Verantwortliche und regelmäßiger Überprüfung der Teamexistenz?
– Wird die Installation und Nutzung von Apps in Teams aktiv gesteuert und protokolliert (Freigabeprozess, dokumentierte Risikoanalyse für kritische Apps)?
– Unterliegen Änderungen an sicherheits- oder compliance-relevanten Einstellungen in Teams einem definierten Change Management mit Freigabe und Test (Vier-Augen-Prinzip)?
– Sind Prozesse etabliert, um inaktive oder nicht mehr benötigte Teams zeitnah zu identifizieren und geordnet zu entfernen bzw. zu archivieren (inkl. entsprechender Nachweise)?

4. Sicherheits- und Compliance-Konzept für Teams

Conditional Access Muster: Für KRITIS-Betreiber sollten Conditional Access-Regeln feinjustiert werden. Neben den bereits genannten Bedingungen (Standort, Gerätezustand, Nutzerkonto-Risiko) können auch Session Controls eingesetzt werden: Beispielsweise lässt sich über Microsoft Defender for Cloud Apps eine Teams-Websession auf Read-only beschränken, sodass von unsicheren Geräten kein Download oder Copy&Paste von Dateien möglich ist. Ebenso kann man den Zugriff zeitlich begrenzen (z.B. erneute MFA-Anforderung nach 4 Stunden). Solche granulare Steuerungen implementieren den Zero-Trust-Grundsatz: Jedem Zugriff wird nur das nötige Mindestmaß an Berechtigung für begrenzte Zeit eingeräumt.

Härtung der Teams-Einstellungen: In den Teams-spezifischen Einstellungen des Tenants sind etliche Optionen zu prüfen. Externe Kommunikation (Federation): Standardmäßig können Teams-Nutzer mit Externen chatten, sofern die Domäne nicht blockiert ist. In KRITIS-Umgebungen empfiehlt es sich, nur bekannte Partnerdomänen zuzulassen oder die Federation ganz zu deaktivieren, um unkontrollierte Kontakte zu vermeiden. Gastzugriff: Falls Gastbenutzer erlaubt sind, sollten die Gastberechtigungen innerhalb von Teams möglichst restriktiv gesetzt sein (z.B. keine Erstellung privater Kanäle durch Gäste, Download-Einschränkungen) und die Gäste nur in dafür vorgesehenen Teams/Channels aufgenommen werden. Private Kanäle: Diese ermöglichen es Team-Mitgliedern, separate, nur für einen Teil der Mitglieder sichtbare Bereiche zu erstellen. Aus Governance-Sicht bedeutet dies eine mögliche Schatten-IT innerhalb eines Teams – es entstehen separate SharePoint-Bereiche, die ggf. an Compliance-Mechanismen vorbeigehen, wenn sie nicht berücksichtigt werden. Es ist zu entscheiden, ob Private Channels erlaubt sein sollen. Falls ja, sollten sie auf wenige vertrauenswürdige Owner beschränkt und deren Verwendung überwacht werden. Shared Channels (Teams Connect): Mit Shared Channels können Personen aus anderen Tenants eingeladen werden, ohne als klassische Gäste hinzugefügt zu werden. Für KRITIS kann dies problematisch sein, da die Kontrolle über solche externen Teilnehmer eingeschränkt ist. Im Zweifel sollte Teams Connect deaktiviert oder sehr restriktiv (nur mit ausdrücklich freigegebenen Partner-Tenants) genutzt werden.

Informationsschutz in Besprechungen: Auch Meetings selbst lassen sich schützen. Standardmäßig sollten Lobby-Einstellungen so gesetzt sein, dass externe Teilnehmer nicht ohne Zutun des Organisators beitreten können (Wartebereich für externe/anonyme). Bei vertraulichen Besprechungen kann der Organisator Ende-zu-Ende-Verschlüsselung (E2EE) aktivieren, wodurch der Inhalt selbst für Microsoft nicht einsehbar wird – allerdings auf Kosten von Funktionen wie Aufzeichnung oder Live-Untertitel. Hier muss abgewogen werden: E2EE eignet sich für hochsensible Ad-hoc-Gespräche, während in anderen Fällen die Dokumentation (Aufzeichnung) wichtiger sein könnte. Eine Richtlinie könnte vorgeben, unter welchen Umständen E2EE genutzt werden darf. Aufzeichnungen: Wenn Meetings aufgezeichnet werden (Video/Audio via OneDrive/SharePoint), ist sicherzustellen, dass diese Aufzeichnungen ebenfalls den Aufbewahrungsregeln unterliegen und geschützt abgelegt werden. Nutzer sollten sensibilisiert sein, dass eine Aufzeichnung keine offizielle Archivierung ersetzt – Chats, geteilte Dateien und Entscheidungen gehören weiterhin in die Protokolle bzw. in die vorgesehenen Speicher. Gegebenenfalls kann man das Aufzeichnen global einschränken oder mit einem sichtbaren Wasserzeichen (Preview-Funktion) versehen, um den unkontrollierten Mitschnitt vertraulicher Gespräche zu erschweren.

Audit-Trails & Beweissicherung: Für jedes sicherheitsrelevante Ereignis in Teams muss eine Prüfspur vorhanden sein. Der Unified Audit Log von M365 protokolliert Aktionen wie Team-Erstellungen, Hinzufügen von Gästen, Datei-Downloads, Chat-Löschungen usw. Dieses Logging sollte aktiviert sein (ist meist per Default aktiv) und die Logs sollten in regelmäßigen Abständen überprüft werden. Um Manipulationen auszuschließen, kann es sinnvoll sein, die Protokolle zusätzlich in ein fälschungssicheres Archiv zu überführen (WORM-Speicher oder durch das SIEM). Aufbewahrungsfristen für Logs und Kommunikation müssen an die gesetzlichen Vorgaben angepasst werden – eine Orientierung bietet z.B. die 10-jährige Aufbewahrungspflicht im Finanzsektor oder branchenspezifische Anforderungen. Ebenso sollten Zugriffsprotokolle für Administratoraktivitäten (Änderungen an Policies, Berechtigungen) regelmäßig ausgewertet werden, um unautorisierte Änderungen schnell zu entdecken.

Checkliste – Mindestkontrollen für einen KRITIS-Tenant: (Ja = erfüllt, Nein = offen; jeweils mit Evidenz belegen)
 

Prüfpunkte für KRITIS:
– Wurden alle o.g. Mindestkontrollen implementiert bzw. dokumentiert und sind die entsprechenden Evidenzen aktuell hinterlegt?
– Gibt es zu allen Kontrollen eindeutige Verantwortlichkeiten für Betrieb und Monitoring („Control Owner“)?
– Sind Abweichungen oder Risiken bei einzelnen Kontrollen bekannt und vom Management akzeptiert (mit entsprechendem Maßnahmenplan)?
– Wird die Einhaltung der Sicherheits- und Compliance-Vorgaben regelmäßig überprüft (z.B. internes Audit oder Management-Review)?

5. Teams-Telefonie in KRITIS inkl. Notruf

Microsoft Teams kann auch als Telefonanlage (Cloud-PBX) eingesetzt werden. In KRITIS-Umgebungen gelten dabei besondere Anforderungen, insbesondere was die Notruf-Abwicklung und Ausfallsicherheit angeht. Grundsätzlich stehen drei Anbindungsmodelle für die Telefonie zur Verfügung:

• Direct Routing: Hier betreibt der KRITIS-Betreiber einen eigenen Session Border Controller (SBC), der Microsoft Teams mit dem öffentlichen Telefonnetz (PSTN) verbindet. Dies bietet maximale Kontrolle über die Leitung (z.B. Nutzung vorhandener Carrier-Verträge, Integration von Analog/ISDN-Geräten), erfordert aber auch eigene Infrastruktur und Know-how. Der SBC muss hochverfügbar und sicher (gehärtet, aktuelles Zertifikat, abgesicherte SIP-Interfaces) betrieben werden.
• Operator Connect: Dabei übernimmt ein zertifizierter Telekommunikationsanbieter die Anbindung von Teams an das Telefonnetz. Die Verbindung zwischen Microsoft und dem Operator ist über dedizierte Peering-Verbindungen gesichert. Der Vorteil: kein eigener SBC vor Ort erforderlich, der Anbieter stellt Hochverfügbarkeit sicher. Allerdings hat man weniger direkte Kontrolle über Routing und ist auf die SLA des Providers angewiesen.
• Calling Plans (Microsoft PSTN): Microsoft selbst agiert als Telefonieanbieter (in Deutschland verfügbar). Das ist für KRITIS meist weniger attraktiv, da die Rufnummern und Verbindungen komplett von Microsoft gemanagt werden und Integrationen (z.B. spezielle Leitstellentechnik, Durchwahl zu bestehenden Anlagen) kaum möglich sind. Vorteil ist die Einfachheit – alles wird cloudbasiert bereitgestellt.

Viele KRITIS-Betreiber entscheiden sich für Direct Routing, um z.B. eigene Notrufleitungen, Durchwahlen oder bestehende Sprachaufzeichnungen weiter zu nutzen. Wichtig bei Direct Routing ist, dass der eingesetzte SBC den BSI-Anforderungen genügt: Härtung nach Stand der Technik (nur notwendige Ports öffnen, aktuelle Patches einspielen), physische Sicherheit (ggf. Redundanz über zwei Rechenzentren) und Kapazitätsplanung für Lastspitzen. Der SBC sollte mindestens georedundant ausgelegt werden (zwei Instanzen, die in verschiedenen Brandabschnitten oder Standorten laufen), damit ein Ausfall nicht die gesamte Telefonie lahmlegt.

Notrufkonzept (Deutschland): Betreiber von Telefonanlagen sind gesetzlich verpflichtet, Notrufe an 110/112 barrierefrei und mit Ortsinformation zu ermöglichen. In Microsoft Teams muss dazu für jede potenziell rufende Person ein Standort definiert werden. Üblich ist, jedem festen Standort (Bürogebäude, Werksgelände) sogenannte Notfalladressen (Emergency Location Addresses, ELA) zuzuweisen. Teams bietet in der Phone System Konfiguration die Möglichkeit, über den Location Information Service (LIS) Netzwerkidentifikatoren (Subnetze, WLAN-Zugangspunkte) mit solchen Adressen zu verknüpfen. Meldet sich ein Nutzer in diesem Netzwerk an, so wird automatisch seine Standort-ID für Notrufe gesetzt. Für Telearbeiter im Home-Office oder unterwegs ist dies schwieriger – hier wird entweder eine „Default“-Adresse hinterlegt (z.B. Firmenzentrale) oder es muss pro Nutzer händisch ein Standort in Teams gepflegt werden. Wichtig ist, dass Anwender wissen: Bei Notrufen über Teams sollten sie dem Disponenten sofort ihren aktuellen Standort nennen, falls dieser vom übermittelten abweicht.

Dynamische Notruf-Routing & ELS: Moderne Notrufsysteme versuchen, den Standort eines Anrufers dynamisch zu ermitteln. Microsoft Teams unterstützt dies in einigen Regionen über eine Integration mit Betriebssystem-Funktionen (Emergency Location Service, ELS), die z.B. auf mobilen Geräten GPS-Daten an den PSAP (Public Safety Answering Point) übermitteln können. In der EU und speziell Deutschland ist diese Integration noch im Aufbau. Daher ist für KRITIS-Betreiber zentral, die statischen Notfalladressen so gepflegt zu haben, dass sie in >95% der Fälle korrekt sind. Eine besondere Herausforderung sind große Werksgelände oder Campusse: Hier sollte man das Gelände in Zonen unterteilen (Gebäude, Etagen) und im LIS möglichst granulare Informationen hinterlegen.

Test von Notrufen: Ein Notruf-Test sollte niemals unkoordiniert erfolgen, um die echte Notrufleitung nicht unnötig zu belasten. Stattdessen sind Testabsprachen mit den Leitstellen notwendig. Einige Unternehmen führen jährlich Testanrufe in Abstimmung mit der jeweils zuständigen Leitstelle durch (z.B. in Zeiten geringer Auslastung), um zu prüfen: Kommt der Anruf richtig an? Wurde die richtige Adresse übermittelt? Kann der Anrufer verstanden werden? Solche Tests sollten dokumentiert und fest eingeplant sein.

Redundanz & Ausfallsicherheit: Die Telefonie-Infrastruktur muss auch bei Teil-Ausfällen funktionsfähig bleiben. Dazu gehört eine redundante Netzwerkanbindung (damit Notrufe auch bei Ausfall eines Internet-Links rausgehen), redundante SBCs und nach Möglichkeit zwei unabhängige Telefonie-Provider oder Trunks. Idealerweise routet jeder SBC über einen anderen Provider, sodass selbst ein Ausfall beim Carrier überbrückt wird. Auch Endgeräte (wie IP-Telefone oder Konferenztelefone) sollten über USV abgesichert sein. Eine bewährte Praxis ist es, analoge Notfalltelefone oder Mobiltelefone als ultimativen Fallback bereit zu halten – z.B. rote Notfallapparate, die über das klassische Festnetz laufen, für den Fall eines vollständigen Cloud- oder Stromausfalls.

Alarmierung & Leitstellen-Integration: In kritischen Umgebungen muss nicht nur der Notruf nach außen funktionieren, sondern auch interne Alarmierungswege. Microsoft Teams kann in Alarmierungskonzepte eingebunden werden (z.B. durch Broadcast-Nachrichten oder automatisierte Anrufe via Bots), ersetzt aber keine dedizierten Alarmierungssysteme, die z.B. Sirenen oder Lautsprecher ansteuern. Dennoch sollte definiert sein, wie im Krisenfall über Teams informiert wird (z.B. ein „All-Employee“-Chat für Warnmeldungen). Für Leitstellenpersonal, das Teams als Kommunikationsmittel nutzt, sind Eskalationsmatrizen wichtig: Welche alternativen Kontaktmöglichkeiten bestehen, wenn Teams nicht verfügbar ist? Hier überschneidet sich dieses Thema mit dem generellen Notfallkommunikationsplan (siehe Abschnitt 6). Auch die Protokollierung von telefonischen Alarmen ist relevant: Gespräche, die z.B. betrieblich wichtige Alarme enthalten, sollten dokumentiert werden (ggf. per kurzem Follow-Up im Teams-Chat „Bestätigung: Alarm X weitergegeben an Y“ oder automatisierte Sprachaufzeichnung in kritischen Bereichen, sofern zulässig).

Tabelle – Notruf-Sollkonzept:
 

Prüfpunkte für KRITIS:
– Sind für alle Benutzer aktuelle Notfall-Standortinformationen in Teams hinterlegt bzw. Prozesse etabliert, um Standortänderungen zeitnah nachzuführen?
– Wurde die Notruf-Funktion in Teams unter koordinierten Bedingungen erfolgreich getestet (inkl. Adressübermittlung und interner Alarmierung)?
– Existieren redundante Routen und Fallback-Möglichkeiten, sodass ein Ausfall von Internet, SBC oder Provider die Notruffähigkeit nicht unterbricht?
– Haben alle mit Notrufen befassten Stellen (Leitwarte/Sicherheitszentrale) Zugang zu einer Backup-Kommunikation (z.B. analoges Telefon oder Betriebsfunk), falls Teams ausfällt?
– Liegen Absprachen mit den zuständigen Rettungsleitstellen vor (z.B. bzgl. Testanrufen, Schlüsselwörtern bei Standortmeldungen) und sind diese dokumentiert?

6. Betriebsprozesse & Runbooks

Ein gut durchdachtes Betriebs- und Notfallmanagement sorgt dafür, dass Teams auch in Krisensituationen beherrschbar bleibt. Dazu gehören klare Prozesse für Störungen, definierte Abläufe für Änderungen sowie vorbereitete Anleitungen (Runbooks) für typische Notfallszenarien.

Incident-Management: Beim Auftreten von Störungen oder Sicherheitsvorfällen mit Teams muss eine schnelle Reaktion gewährleistet sein. Legen Sie Schwellwerte und Schweregrade fest (z.B. „Incident Level 1“ für Totalausfall der Kommunikation, „Level 2“ für Teilstörungen oder sicherheitsrelevante Vorfälle). Definieren Sie für jedes Level einen Maßnahmenplan: Wer wird informiert (z.B. IT-Leitung, CISO, Fachabteilungen)? Über welche Kanäle erfolgt die interne Kommunikation, falls Teams selbst betroffen ist (E-Mail, Telefonkonferenz, SMS-Verteiler)? Beispielsweise sollte bei einem Teams-Ausfall eine vordefinierte Telefonkonferenznummer oder alternative Chat-Plattform bereitstehen, über die sich der Krisenstab austauschen kann. Rollen sind klar zuzuweisen: Ein Incident Manager koordiniert die Behebung, ein Kommunikationsverantwortlicher informiert die Anwender (Statusmeldungen), der Security Officer bewertet etwaige Sicherheitsimplikationen und übernimmt Pflichtmeldungen (z.B. an das BSI im Falle eines signifikanten KRITIS-Ausfalls (gemäß §8b BSIG) oder an die Datenschutzbehörde bei Datenpannen binnen 72 Stunden gemäß DSGVO). Wichtig ist, alle Schritte zu protokollieren (Zeitpunkt, Maßnahme, Verantwortlicher), um später eine lückenlose Auswertung ermöglichen zu können.

Change- und Release-Management: Wie bereits in Abschnitt 3 erläutert, sollten Änderungen an der Konfiguration von Teams kontrolliert erfolgen. Erstellen Sie für wiederkehrende Änderungen Standard-Runbooks. Beispielsweise ein Runbook „Teams-Policy Update einspielen“ mit Schritten wie: (1) Ankündigung im Change Advisory Board, (2) Backup der aktuellen Einstellung (z.B. Export von Policies per PowerShell), (3) Durchführung im Test-Tenant, (4) Review, (5) Rollout im Produktiv-Tenant im Wartungsfenster, (6) Funktionstest, (7) Dokumentation des Changes im Änderungsprotokoll. Solche Runbooks stellen sicher, dass nichts Wesentliches übersehen wird und dass im Fehlerfall schnell reagiert werden kann (z.B. Schritt für Schritt zurück zum Ursprungszustand). Auch Release-Notes von Microsoft sollten systematisch ausgewertet werden: Welche neuen Features können Auswirkungen auf unseren Betrieb haben? Muss ggf. eine neue Funktion deaktiviert werden, bis Policies und Schulungen angepasst sind? Planen Sie Patches/Updates für angebundene Komponenten (z.B. SBC-Firmware) vorausschauend ein.

Backup & Wiederherstellung: Die Cloud-Architektur von Teams stellt Hochverfügbarkeit sicher, aber klassische Backups im Sinne einer vollständigen Datenkopie sind begrenzt. Chats und Teams-Beiträge liegen verteilt in Exchange-Postfächern und SharePoint. Ein vollumfängliches Restore-Szenario („alle Datenstand von vor 2 Tagen wiederherstellen“) ist kaum umsetzbar. Stattdessen fokussiert man auf Retention (Aufbewahrung) und Recovery-Optionen im Rahmen des M365: Gelöschte Teams können innerhalb von 30 Tagen wiederhergestellt werden, gelöschte Dateien aus SharePoint bis zu 93 Tage (Papierkorb-Phasen), gelöschte Einzelchat-Nachrichten hingegen gar nicht (außer via eDiscovery-Protokoll). Daher sollten Administratoren in KRITIS besonderen Wert darauf legen, versehentliche Löschungen zu vermeiden (z.B. Bestätigungsmechanismen, Berechtigungskonzepte, die riskante Aktionen auf wenige Personen beschränken). Für absolut kritische Daten kann der Einsatz von Drittanbieterlösungen für M365-Backups erwogen werden, die zumindest Dateien und Mails (und damit auch Channel-Chats in gewissem Umfang) archivieren. Die Wiederanlaufzeiten (RTO = Recovery Time Objective) und Datenverlustgrenzen (RPO = Recovery Point Objective) müssen definiert sein: Im Regelfall sichert Microsoft die Live-Verfügbarkeit (RTO nahe 0 durch automatische Failover in der Cloud), während RPO vom letzten Sync abhängt (typisch wenige Sekunden). Für lokale Komponenten (z.B. SBC) sollten Backup-Konfigurationen vorhanden sein, um bei kompletten Ausfällen die Funktion innerhalb von Stunden wiederherstellen zu können (z.B. Ersatz-SBC hochfahren und Konfiguration einspielen).

Übungsszenarien: Theorie ist nur so gut wie ihre Umsetzung in der Praxis. Üben Sie den Ernstfall regelmäßig. Ein Krisenstab-Team in Teams (möglichst vorab angelegt mit allen relevanten Mitgliedern) kann für Simulationen genutzt werden. Szenario-Beispiele: „Totalausfall Internet am Hauptstandort“, „Leak von vertraulichen Informationen in einem extern freigegebenen Team“ oder „Cyberangriff verschlüsselt Teile der Infrastruktur“ – jeweils mit Fokus auf die Kommunikations- und Kollaborationsaspekte. In den Übungen sollte getestet werden, ob alle Beteiligten wissen, welche Kanäle zu nutzen sind, wo die Runbooks liegen und wie die Wiederherstellung abläuft. Solche Simulationen decken oft blinde Flecken auf (z.B. fehlende Berechtigungen für Ersatzkommunikation, Unklarheiten in der Verantwortung), die im Nachgang bereinigt werden können.

Runbook-Beispiel: Notfallkommunikation bei WAN-Ausfall
Ziel: Aufrechterhaltung der internen Kommunikation, wenn die Firmenstandorte vom Internet (und damit von Teams) abgeschnitten sind.
Trigger: Gesamtausfall der WAN-Verbindung eines oder mehrerer Standorte (Internet-Blackout).

Ablauf/Schritte:
1. Erkennung: Das Netzwerk-Überwachungstool schlägt Alarm „WAN Down“. Das Netzwerk-Team informiert umgehend den IT-Krisenstab über alternative Kanäle (automatisierter SMS-Alarm und Anruf).
2. Initiale Bewertung: Der Incident Manager bewertet den Ausfallumfang (betroffene Standorte, geschätzte Dauer) und ruft den Krisenstab auf dem Backup-Kommunikationsweg zusammen (z.B. Einwahl aller Mitglieder über eine festgelegte Telefonkonferenznummer).
3. Kommunikation an Mitarbeiter: Über einen zuvor definierten Verteiler (E-Mail/SMS) wird an alle Mitarbeiter der betroffenen Standorte die Information versandt, dass Teams derzeit nicht verfügbar ist. Hinweis: Falls möglich, mobile Daten (Smartphones als Hotspot) nutzen, um wichtige Aufgaben fortzuführen.
4. Problembehebung: Das Netzwerk-Team arbeitet mit dem Provider an der Entstörung. Zwischenzeitlich koordiniert der Krisenstab über die Telefonkonferenz die wichtigsten Maßnahmen (Priorität auf Aufrechterhaltung kritischer Prozesse, ggf. manuelle Workarounds). Regelmäßig fließen Status-Updates an alle Beteiligten.
5. Wiederanlauf: Sobald das WAN wieder verfügbar ist, informiert der Incident Manager die Mitarbeiter über die Wiederherstellung (erneut via E-Mail/SMS). Der Krisenstab dokumentiert die Dauer des Ausfalls und ggf. verbleibende Probleme in Teams.

Fallback: Sollte neben dem WAN auch das Mobilfunknetz betroffen sein (Worst Case), greift der vorbereitete absolute Notfallplan: Nutzung von Satellitentelefonen oder lokalen Funkgeräten, physische Treffen des Krisenstabs an einem definierten Ort. Dieser Zustand und die Rückfallebene werden in Übungen gesondert geprobt.

Abschluss: Nach Wiederanlauf stellt der Incident Manager zusammen mit dem Problem Manager die Ursache fest (RCA-Analyse). Das Runbook wird anhand der Erfahrungen überarbeitet. Ein Abschlussbericht (inkl. Timeline, Impact und ergriffenen Maßnahmen) geht an die Geschäftsleitung. Lessons Learned werden festgehalten und mit allen Stakeholdern geteilt.

Prüfpunkte für KRITIS:
– Ist ein Incident-Response-Plan für Ausfälle oder Sicherheitsvorfälle in Zusammenhang mit Teams vorhanden, und kennen alle relevanten Personen ihre Rolle darin?
– Sind alternative Kommunikationswege und -mittel für den Fall eines Teams- oder Internet-Ausfalls definiert, getestet und den Nutzern kommuniziert (z.B. alternative Hotline, Notfall-E-Mail-Verteiler)?
– Sind aktuelle Runbooks für zentrale Störungs- und Notfallszenarien schriftlich dokumentiert und leicht auffindbar (z.B. im Intranet oder als Offline-Kopie)?
– Finden regelmäßig Notfallübungen statt, die auch die Teams-Kommunikation und -Wiederherstellung einbeziehen, und werden daraus Maßnahmen abgeleitet?
– Wurden Verantwortlichkeiten für Backup/Restore klar zugewiesen, auch wenn technische Limitierungen bestehen (wer koordiniert z.B. die Datenwiederherstellung im Fall der Fälle)?

7. Protokollierung, Monitoring & Nachweisführung

Ohne verlässliche Protokollierung kann keine Nachweisführung gegenüber Prüfern oder im Ernstfall (z.B. forensische Untersuchung nach einem Sicherheitsvorfall) stattfinden. Microsoft Teams generiert eine Vielzahl von Log-Daten, die es zu nutzen gilt: Teams-Audit-Logs (Aktionen der Nutzer und Administratoren in Teams), Entra ID Sign-in- und Audit-Logs (Anmeldungen, Änderungen an Gruppen, Rollen), Defender-Alerts (z.B. Malware-Erkennung auf einem Client oder Phishing-Link in einer Nachricht), Intune-Logs (Compliance-Verstöße von Geräten), SBC-Logs (Anrufdetailnachweise, SIP-Registrierungen) sowie klassische Netzwerk- und Firewall-Logs. All diese Quellen sollten in einem zentralen Monitoring zusammenfließen.

Log-Aufbewahrung und Integrität: Gemäß den KRITIS-Vorgaben (und teils rechtlichen Pflichten) müssen sicherheitsrelevante Ereignisse für eine gewisse Dauer vorgehalten werden (z.B. 6 Monate gemäß BSIG, teilweise länger nach branchenspezifischen Regeln). In Microsoft 365 E5 lassen sich Audit-Logs bis zu 1 Jahr in der Cloud speichern; für längere Zeiträume oder bei niedrigerem Lizenzniveau ist der Export in ein externes System erforderlich. Wichtig: Die Logs sollten manipulationsgeschützt gespeichert werden. Ein SIEM – sofern on-premises betrieben – sollte so konfiguriert sein, dass nachträgliche Änderungen an den Events ausgeschlossen oder zumindest detektierbar sind (z.B. durch kryptografische Signaturen oder WORM-Storage). Die Integrität der Beweisdaten genießt höchste Priorität, gerade wenn sie in Audits oder sogar gerichtlichen Auseinandersetzungen bestand haben müssen.

Korrelierte Überwachung & Metriken: Ein isolierter Log für sich genommen liefert selten das volle Bild. Erst die Korrelation verschiedener Ereignisse und das Definieren von Alarm-Schwellen macht ein Monitoring leistungsfähig. Beispiele: Meldet der Defender auf einem Client eine Malware und kurz darauf sieht das Entra ID Log einen ungewohnten Login dieses Benutzers in Teams von einer fremden IP, so deutet die Kombination auf einen ernsthaften Sicherheitsvorfall hin. Solche Use Cases sollten im SIEM bzw. Monitoring-Tool hinterlegt sein. Auch Anomalieerkennung (Machine Learning in Security-Produkten) kann hilfreich sein, um z.B. abnormale Nutzungsmuster in Teams aufzudecken (etwa ein Benutzer, der plötzlich große Mengen Daten in kurzer Zeit herunterlädt). Neben sicherheitsrelevanten Alerts sind aber auch Qualitäts- und Performance-Metriken zu überwachen: Microsoft bietet mit dem Call Quality Dashboard (CQD) Einblick in Anrufqualitäten (Latenz, Paketverlust, MOS-Werte). Diese Kennzahlen gilt es, auf definierte Schwellwerte hin zu beobachten, da eine Verschlechterung der Medienqualität oft auf Netzwerkprobleme oder falsch konfigurierte Priorisierung hindeutet. Ebenso sollten Nutzungsmetriken (Anzahl aktiver Nutzer, Anzahl erstellter Teams, Speicherauslastung) betrachtet werden, um Trends frühzeitig zu erkennen (z.B. Bedarf an Schulungen oder Speichererweiterungen).

SIEM-Anbindung & Use Cases: Die Integration in ein zentrales SIEM (Security Information and Event Management) oder XDR-System (Extended Detection & Response) ermöglicht automatisierte Auswertungen. Sinnvolle Use Cases im Kontext Teams können sein:

• Ungewöhnlicher Login: Anmeldung eines internen Users aus einem Land, in dem das Unternehmen keine Aktivitäten hat (möglicher Account-Kompromiss).
• Massen-Download: Ein Benutzer lädt in kurzer Zeit sehr viele Dateien aus Teams herunter (möglicher Datenabfluss).
• Ghost-Guest: Ein Gastbenutzer wird in besonders viele Teams eingeladen oder ist dort sehr aktiv (mögliche Spionage-Tätigkeit).
• Policy Changes: Eine sicherheitsrelevante Einstellung (z.B. Gastzugriff) wird geändert, ohne genehmigten Change (möglicher Insider-Fehler oder -Angriff).
• Notruf abgesetzt: Trigger, wenn über Teams ein Notruf erfolgte (Prüfen, ob interne Stellen benachrichtigt wurden).

Solche Muster sollten definiert und getestet werden, damit im Ernstfall Alarm geschlagen wird.

Tabelle – KRITIS-Kennzahlen (KPIs):
 

Prüfpunkte für KRITIS:
– Sind alle relevanten Ereignisquellen (Teams, Entra ID, Endgeräte, Netzwerk, etc.) an ein zentrales Monitoring/SIEM angebunden und werden sie aktiv ausgewertet?
– Sind Aufbewahrungsfristen für Protokolle definiert und technisch umgesetzt, sodass Audit-Logs im Bedarfsfall über den geforderten Zeitraum verfügbar sind?
– Gibt es definierte KPI-Ziele für den Teams-Betrieb (Verfügbarkeit, Qualität, Sicherheit) und werden diese Kennzahlen regelmäßig erhoben und an das Management berichtet?
– Werden Alerts aus dem SIEM/Sicherheitsmonitoring zu Teams zeitnah bearbeitet (Prozesse für Incident Response, 24/7-Bereitschaft falls notwendig) und getestet?
– Findet eine regelmäßige Überprüfung der Log- und Monitoringstrategie statt, um neue Risiken oder Änderungen im Nutzungsverhalten abzudecken (kontinuierliche Verbesserung)?

8. Externe Zusammenarbeit & Drittlandthemen

Die Zusammenarbeit über die Grenzen der eigenen Organisation hinweg ist in Microsoft Teams grundsätzlich möglich, muss in KRITIS-Umgebungen jedoch streng kontrolliert werden.

B2B-Gäste & Tenant-zu-Tenant: Ein Gastbenutzer (Azure AD B2B) erhält Zugang zu einem Team, als wäre er ein interner Nutzer mit eingeschränkten Rechten. Dies ermöglicht z.B. Projektarbeit mit Partnerfirmen. In KRITIS sollte die Gastfunktion nur gezielt und nach Freigabe genutzt werden. Empfehlungen: Nur Administratoren oder definierte Sponsoren dürfen Gäste hinzufügen, jeder Gast bekommt einen internen Verantwortlichen zugeordnet, und es gibt einen Prozess zur regelmäßigen Überprüfung aller Gäste (z.B. quartalsweise: Welcher Gast ist noch nötig?). Technisch unterstützen Azure AD Access Reviews diese Überprüfungen. Alternativ kann Gastzugriff global deaktiviert werden, wenn er nicht benötigt wird – dies ist jedoch oft unrealistisch und würde zu unsicheren Workarounds führen. Wichtig ist, dass für jede Zusammenarbeit mit Externen dokumentiert ist, welche Daten geteilt werden dürfen und welche nicht.

Tenant Restrictions & Cross-Tenant Policies: Mitarbeiter können selbst als Gäste in die Teams anderer Organisationen eingeladen werden. Dies birgt das Risiko, dass Daten unkontrolliert in fremde Tenants gelangen oder dass Mitarbeiter dort unsichere Umgebungen nutzen. Mit Tenant Restrictions (Netzwerkfeature auf Proxy/Firewall-Ebene) kann man den Login auf fremde Azure-AD-Tenants unterbinden, außer auf erlaubte. Ebenso lassen sich in Entra ID Cross-Tenant Access Policies definieren (z.B. nur bestimmte Partner-Tenants dürfen unsere User als Gäste aufnehmen, oder es wird gefordert, dass im fremden Tenant MFA genutzt wird). Diese Stellschrauben sollten genutzt werden, um unregulierte externe Kollaboration einzuschränken.

Datenresidenz & Datenschutz: Bei Cloud-Diensten ist immer zu beachten, wo die Daten liegen und wer darauf zugreifen kann. Microsoft speichert die Kern-Daten von EU-Tenants in Rechenzentren innerhalb der EU (bei deutschen Tenants meist in Frankfurt/Main und Berlin). Trotzdem können Supportzugriffe aus Drittstaaten oder bestimmte Metadatenverarbeitungen stattfinden. Ein Vertrag zur Auftragsverarbeitung (AVV) mit Microsoft gemäß DSGVO Art. 28 ist Pflicht und in den Microsoft-Nutzungsbedingungen inkludiert. Darüber hinaus sollten KRITIS-Betreiber eine Datenschutz-Folgenabschätzung (DSFA/DPIA) für den Einsatz von Teams durchführen, in der Risiken (z.B. Cloud Act, Schrems II-Problematik) und Gegenmaßnahmen (z.B. Verschlüsselung, minimale Speicherung personenbezogener Inhalte) dokumentiert sind. Exportkontrollen: Falls im Unternehmen dem Exportkontrollrecht unterliegende Informationen behandelt werden, ist Vorsicht geboten. Die Freigabe solcher Informationen in Teams (besonders an ausländische Gäste) sollte nur nach Freigabe durch die Exportkontrollstelle erfolgen. Teams selbst bietet keine automatische Prüfung, daher müssen Prozesse und Schulungen greifen, um Verstöße zu vermeiden.

Freigabe- und Sperrkriterien: Legen Sie klare Kriterien fest, unter welchen Voraussetzungen externe Zusammenarbeit erlaubt ist. Beispiele: „Daten mit Schutzstufe X dürfen niemals in externen Tenants geteilt werden“ oder „Zusammenarbeit nur mit Organisationen, die einem vergleichbaren Sicherheitsstandard unterliegen (nachgewiesen z.B. durch ISO 27001 Zertifikat)“, „Keine Nutzung von Teams mit Partnern aus bestimmten Regionen ohne Einzelfreigabe“. Solche Vorgaben sollten in einer Policy niedergeschrieben und technisch, soweit möglich, umgesetzt werden (z.B. Sensitivitäts-Label, das das externe Teilen unterbindet; DLP-Regel, die Uploads in externe Tenants erkennt).

„Clean Rooms“ / Sicherheitszonen: Für höchst sensible Projekte kann es sinnvoll sein, eine Art „Sicherheitskapsel“ innerhalb von Teams zu schaffen. Das können separate „Security Teams“ sein, die nur auf gehärteten Geräten und innerhalb bestimmter Netzwerke zugreifbar sind. So ließe sich z.B. über Conditional Access regeln, dass auf ein Team mit Geheimhaltungsstufe „Streng geheim“ nur vom Büro aus und mit speziellen, überwachten Rechnern zugegriffen werden darf. Auch können für solche Teams alle Dritt-Apps deaktiviert werden und das Teilen von Dateien stark reglementiert sein. Microsoft Purview bietet zudem Information Barriers, um zu verhindern, dass bestimmte Benutzergruppen in Teams überhaupt miteinander kommunizieren oder Daten austauschen (relevant z.B. bei Chinese Walls im Finanzsektor). Überlegen Sie, ob für bestimmte besonders kritische Bereiche ein separater Tenant sinnvoll ist (Nachteil: erhöhter Verwaltungsaufwand, fehlende direkte Zusammenarbeit mit dem Haupt-Tenant) oder ob isolierte Sicherheitszonen innerhalb des Tenants ausreichen.

Risikoregister (Auszug): Nachfolgend sind exemplarisch einige Risiken im Kontext von Teams aufgeführt, inklusive Bewertung und Maßnahmen. Dieses Register sollte Teil des ISMS sein und regelmäßig aktualisiert werden.

Prüfpunkte für KRITIS:
– Ist die Zusammenarbeit mit externen Partnern klar geregelt und auf definierte Anwendungsfälle beschränkt (inkl. Kriterien wie Länder, Sicherheitsniveau des Partners etc.)?
– Werden Gäste und externe Zugriffe regelmäßig überprüft und bei Nichtbedarf umgehend entzogen?
– Liegen alle datenschutzrechtlich erforderlichen Dokumente und Verträge für die Nutzung von Teams vor (AV-Vertrag, DSFA, Nutzerrichtlinien zur Einwilligung soweit nötig)?
– Sind besondere Maßnahmen für den Schutz sensibler Daten umgesetzt (z.B. dedizierte Sicherheitsbereiche in Teams, Informationsbarrieren, separate Tenants bei Bedarf)?
– Wird das Risikoregister zu Teams laufend gepflegt und werden Maßnahmen bei Änderungen (neue Bedrohungen, neue Nutzungen) nachgeführt?

9. Proof-of-Compliance & Audits

Um im Prüfungsfall (internes oder externes Audit, z.B. KRITIS-Prüfung gemäß §8a BSIG) bestehen zu können, muss die Einhaltung aller relevanten Vorgaben nachgewiesen werden. Dies erfordert Dokumentation und Evidenzen in mehreren Ebenen:

• Richtlinien & Prozesse: Alle geltenden Policies rund um Teams (Sicherheitsrichtlinie, Nutzungsrichtlinie, Admin-Konzept, Notfallkonzept) sollten schriftlich fixiert und gültig freigegeben vorliegen. Ebenso Prozessbeschreibungen für Routineaufgaben (z.B. Onboarding neuer Nutzer, Behandlung von Sicherheitsvorfällen in Teams) und Notfallprozesse.
• Technische Einstellungen: Die Sicherheits- und Compliance-Konfiguration des Tenants muss dokumentiert sein. Dazu gehören z.B. Screenshots oder Exporte der Conditional-Access-Policy, der Teams-Einstellungen, DLP-Regeln, Sensitivitätslabel-Definitionen etc. Idealerweise wird für jeden Soll-Kontrollpunkt festgehalten, wo und wie er konfiguriert ist.
• Prozessnachweise: Hierzu zählen Protokolle von Durchführungen: z.B. Berichte über die quartalsweise Überprüfung der Gastnutzer, das Protokoll der jährlichen Rezertifizierung aller Teams (Liste der Team-Owner-Bestätigungen), Logs von Change Advisory Board Meetings für Änderungen, und Nachweise von Notfallübungen (Datum, Beteiligte, Ergebnis).
• Schulungsnachweise: Wichtig in KRITIS ist auch die Qualifikation der handelnden Personen. Dokumentieren Sie, dass Administratoren entsprechende Schulungen (z.B. M365 Security) besucht haben und Nutzer über die Nutzungsregeln informiert wurden (z.B. über E-Learnings oder Bestätigung der Nutzungsbedingungen beim ersten Login).

All diese Unterlagen sollten gebündelt und aktuell in einem Audit-Ordner oder Tool vorgehalten werden, um auf Anforderung schnell vorgelegt werden zu können. Für KRITIS-Prüfungen empfiehlt sich eine Zuordnung der Nachweise zu den Anforderungen des relevanten Prüfungsstandards (z.B. B3S oder ISO 27001 in Verbindung mit dem branchenspezifischen Standard für die Sparte, falls vorhanden). So kann ein Auditor direkt sehen, welche Maßnahmen Ihre Organisation für jede Forderung umgesetzt hat.

Periodische Kontrollen: Compliance ist kein einmaliger Akt, sondern ein fortlaufender Prozess. Stellen Sie sicher, dass wiederkehrende Aufgaben im Kalender oder einem GRC-Tool hinterlegt sind: z.B. Jährliche Rezertifizierung aller Teams (Owner müssen Existenz und korrekte Klassifizierung bestätigen), Quartalsweise Zugriffsreviews für privilegierte Konten und Gäste (wer hat noch Zugriff, ist das notwendig?), Halbjährliche Überprüfung der zugelassenen Apps (sind neue Risiken bekannt, muss eine App entzogen werden?). Ergebnisse dieser Reviews sollten protokolliert werden (wer hat geprüft, Ergebnis, Maßnahmen). Auch Changes und Incidents sollten nachträglich analysiert werden: Wurden alle Prozesse eingehalten? Wo gibt es Verbesserungsbedarf? Diese Kontinuität zeigt Prüfern, dass das ISMS lebt und nicht nur auf dem Papier existiert.

Audit-Vorbereitung: Mindestens 2–3 Monate vor einem angekündigten Audit (oder jederzeit, wenn ein ungeplantes kommen kann) sollte eine interne Audit-Readiness-Prüfung erfolgen. Gehen Sie die relevanten Kontrollpunkte durch und vergewissern Sie sich, dass:

• alle erforderlichen Nachweise vorhanden, aktuell und zugreifbar sind,
• die operativen Verantwortlichen Auskunft über ihre Bereiche geben können (ggf. kurze Briefings oder Q&A-Vorbereitung mit den Admins durchführen),
• eventuelle Lücken geschlossen oder zumindest erklärbar und mit einem Plan hinterlegt sind.

Eine sinnvolle Methode ist es, Stichproben zu simulieren: z.B. bitten Sie intern jemanden, 5 zufällige Teams auszuwählen und alle relevanten Einstellungen sowie die Zugriffsberechtigungen zu prüfen (wie würde es ein Auditor tun). Entdecken Sie hierbei Unklarheiten (z.B. ein Team ohne Owner, ein aktiver Gast ohne Begründung), bereinigen Sie dies vor dem echten Audit. Legen Sie alle Evidenzen zentral ab (z.B. in einem SharePoint-Audit-Workspace oder einem Offline-Ordner für den Auditorzugriff). Definieren Sie Zuständigkeiten während des Audits: Wer beantwortet Fragen zur Technik, wer zu Prozessen, wer zur Notfallkommunikation etc., damit immer ein kompetenter Ansprechpartner zur Verfügung steht.

Tabelle – Kontrollkatalog & Evidenzmapping:
 

Prüfpunkte für KRITIS:
– Sind für sämtliche relevanten Kontrollpunkte umfassende Evidenzen abgelegt (Konfiguration, Prozesse, Berichte) und leicht abrufbar?
– Werden wiederkehrende Compliance-Tasks (Reviews, Schulungen, Tests) planmäßig durchgeführt und ist dies dokumentiert?
– Ist eine zuständige Person/Gruppe benannt, die die Audit-Vorbereitung koordiniert und sicherstellt, dass auftretende Fragen zügig und konsistent beantwortet werden können?
– Wurden vor einem externen Audit interne Selbstprüfungen durchgeführt (Stichproben, Simulationen), um eventuelle Schwachstellen vorab zu erkennen und zu beheben?
– Liegen aktuelle Freigaben des Managements für Richtlinien und Risikoakzeptanzen vor, sodass im Audit die formale Governance nachgewiesen werden kann?

10. Migrations- und Transformationspfade

Nicht jede Organisation startet auf dem gleichen Reifegrad, wenn es um Teams und dessen Governance geht. Wichtig ist, einen Entwicklungsplan zu haben, der ausgehend vom Ist-Zustand die nötigen Schritte bis zum Zielbild (KRITIS-konformer Betrieb) beschreibt. Man kann vier Reifegradstufen unterscheiden:

• Stufe 0 – Ad-hoc Nutzung: Teams wird unreguliert verwendet, möglicherweise sogar ohne offizielle Freigabe (Schatten-IT oder im Ausnahmefall eingeführt, z.B. pandemiebedingt). Sicherheitsmechanismen sind weitgehend Default, es existieren kaum Dokumentationen oder Verantwortlichkeiten. Risiken: hohe Unklarheit über Datenablagen, potenzielle Regelverstöße unbemerkt.
• Stufe 1 – Standardisiert: Teams ist offiziell im Einsatz, es gibt erste Richtlinien (z.B. Acceptable Use Policy) und Basisschutz (MFA aktiviert, einige Einstellungen angepasst). Dennoch fehlen noch formalisierte Prozesse; vieles hängt von Einzelinitiativen ab. Risiken: Inkonsistente Handhabung, Lücken in Überwachung und Dokumentation.
• Stufe 2 – Gesteuert: Teams-Betrieb ist prozessual verankert: Es existiert eine Governance-Struktur, klare Zuständigkeiten, die meisten in diesem Leitfaden genannten technischen Sicherheitsfeatures sind implementiert. Audits würden bereits weitestgehend bestanden, einige Nachweise müssten aber evtl. noch manuell gesucht werden. Risiken: Restlücken in der Automatisierung, möglicherweise Abhängigkeit von Schlüsselpersonen, dynamische Änderungen von Teams seitens Microsoft erfordern stete Aufmerksamkeit.
• Stufe 3 – Audit-Ready: Der Zustand, den wir anstreben: Vollständig dokumentierter und überprüfbarer Betrieb. Jeder Kontrollpunkt ist adressiert, Verantwortlichkeiten sind institutionalisiert (nicht personengebunden), Reviews und Monitoring laufen kontinuierlich. Man ist bereit für offizielle Audits und kann externe Nachweise (z.B. Audit-Zertifikat) erbringen. Teams ist nun ein integrierter, beherrschbarer Bestandteil des KRITIS-ISMS.

Der Übergang von Stufe 0 oder 1 zu Stufe 3 erfolgt typischerweise in Projekten über mehrere Monate. Quick Wins sind Maßnahmen, die sofort erhebliche Risiken reduzieren, während Deep Dives und strukturelle Maßnahmen mehr Zeit und Planung benötigen.

Beispiele für Quick Wins (0–3 Monate):

• MFA für alle einführen.
• Kritische Einstellungen sofort härten (Gastzugriff temporär aus, externe Kommunikation auf bekannte Domänen beschränken).
• Schnelle Schulung der Admins zu Security-Features.
• Erste DLP-Regel einschalten (z.B. Warnung bei offensichtlichen sensiblen Infos).
• Einen kleinen Pilot für Intune App-Schutz auf mobilen Geräten starten (für BYOD absichern).

Parallel dazu startet man mit den Grundlagen (Deep Dive-Vorbereitung): Aufbau einer Projektgruppe, Abstimmung mit Datenschutz und Betriebsrat, Bestandsaufnahme der vorhandenen Teams und Inhalte, Erstellung einer groben Gap-Analyse im Vergleich zu KRITIS-Anforderungen.

In den Folgemonaten (3–12 Monate) folgen dann vertiefende Maßnahmen:

• Ausrollen eines vollständigen Conditional-Access-Konzepts.
• Umsetzung eines mandantenweiten Klassifizierungskonzepts (Sensitivitätslabel).
• Einbindung aller Endgeräte in Intune mit Compliance-Prüfung.
• Strukturierung des Teams-Lebenszyklus (Naming, Archivierung, etc.).
• Pilotierung der Teams-Telefonie unter KRITIS-Aspekten (z.B. an einem Standort).

Abhängigkeiten sollten im Projektplan berücksichtigt sein: So muss etwa Identitätsmanagement (MFA, AD-Synchronisierung) weitgehend stehen, bevor fein granularer Zugriffsschutz Sinn ergibt. Ebenso sollte die Netzwerkbasis (VPN, LAN, Internet-Bandbreite) ausgebaut sein, bevor man flächendeckend auf Teams setzt (Qualitätsprobleme bei schlechter Verbindung untergraben die Akzeptanz und führen zu Umgehungen). Datenklassifizierung kann nur etabliert werden, wenn allgemein im Unternehmen klar ist, welche Schutzklassen es gibt und wie sie angewendet werden – das erfordert oft Change Management und Schulungen außerhalb von IT.

Nachfolgend eine Roadmap mit groben Etappen für 90, 180 und 360 Tage:

90 Tage (Quick Wins & Planung):
– Ziele: Sofortmaßnahmen umsetzen, die größte Risiken adressieren; Projektorganisation etablieren.
– Meilensteine: Projektteam ernannt; MFA für alle aktiv; erste Policies konfiguriert (CA-Basisregeln, Gastzugriff temporär eingeschränkt, Audit-Log an SIEM angebunden); Management Kick-off absolviert.
– Deliverables: Sicherheitsbaseline-Dokument (Ist-Stand + Quick-Win-Maßnahmen dokumentiert); Schulungsplan für nächste 6 Monate; Risikoanalyse initial erstellt (Top 10 Risiken mit Maßnahmen definiert).
– Risiken: Möglicher Widerstand von Nutzern bei plötzlichen Einschränkungen (Kommunikationsrisiko); technische Probleme beim Aktivieren von MFA oder CA (Rollback-Plan bereithalten); begrenzte Ressourcen für das Projekt neben Tagesgeschäft.
– Ressourcen: Interne Projektleitung (Teilzeit), Security-Architekt (intern oder extern) zur Beratung, ggf. Microsoft-Partner für spezifische Themen; Zeitbudget für Admin-Schulungen und Policy-Tests.

180 Tage (Aufbau & Erweiterung):
– Ziele: Vollständiges Governance-Framework in Betrieb nehmen; vertiefte technische Absicherung implementieren; Pilotprojekte (z.B. Telefonie, neue Tools) unter KRITIS-Bedingungen durchführen.
– Meilensteine: Governance-Gremium etabliert (regelmäßige Meetings); alle Rollen (RACI) benannt; Klassifizierungskonzept in Teams umgesetzt (alle neuen Teams mit Label); Conditional Access Regeln für alle wichtigen Szenarien aktiv; Intune Compliance für >90% der Geräte durchgesetzt; Pilot Teams-Telefonie an Standort X erfolgreich (inkl. Notruf-Test).
– Deliverables: Betriebsdokumentation (Governance-Handbuch, Admin-Runbooks) fertig; Notfallkommunikationskonzept aktualisiert; Zwischenbericht ans Management über Projektfortschritt; Schulung aller Mitarbeiter zu neuen Security-Policies (z.B. via E-Learning abgeschlossen).
– Risiken: Verzögerung bei Klassifizierung, weil Abstimmung mit Betriebsrat länger dauert; technische Schwierigkeiten im Pilot (z.B. QoS-Probleme bei Telefonie); möglicher Anstieg Support-Aufwand, wenn neue Sicherheitsfeatures greifen (User brauchen Starthilfe).
– Ressourcen: Evtl. Einstellung eines dedizierten M365-Security Engineers oder Nutzung von externen Consultants für Implementierung; Budget für Telefonie-Hardware (SBC, zertifizierte Headsets); Unterstützung durch Rechtsabteilung/Datenschutz für die Compliance-Dokumentation.

360 Tage (Konsolidierung & Audit-Bereitschaft):
– Ziele: Abschluss aller vorgesehenen Maßnahmen; System in den Dauerbetrieb übergeben; Audit-Vorbereitungen abschließen.
– Meilensteine: Alle zuvor identifizierten Lücken geschlossen; ggf. erste interne Audit-Simulation durchgeführt; externes KRITIS-Audit beauftragt (falls zeitlich fällig nach IT-SiG 2.0); Teams-Telefonie voll ausgerollt und abgenommen; Notfallübung mit neuem Setup durchgeführt (und erfolgreich).
– Deliverables: Vollständiges ISMS-Dokumentationspaket für Teams (allen Abschnitten dieses Leitfadens entsprechend); Audit-Readiness-Checkliste ausgefüllt; Management-Abnahmebericht, der die Betriebsbereitschaft und Regelkonformität bestätigt; ggf. Kommunikationspaket für Stakeholder („Wir sind KRITIS-ready mit Teams“).
– Risiken: Neues Release von Microsoft könnte kurzfristig Anpassungen erfordern (Plan für solche Changes parat); personelle Abgänge im Projektteam könnten Wissenslücken reißen (Wissensübergabe sichern); Auditor findet doch noch einen Schwachpunkt (Flexibilität und schnelle Nachbesserung einplanen).
– Ressourcen: Übergabe an operatives Team (Post-Projekt): sicherstellen, dass genügend Kapazität für dauerhafte Aufgaben vorhanden ist (ggf. neuen FTE einstellen); Budget für Wartung (SBC-Servicevertrag, Lizenz-TrueUp für zusätzliche Security-Funktionen) einkalkuliert; weitere Schulungen (fortgeschrittene Themen, Wechsel von Projekt- zu Betriebsmodus).

Prüfpunkte für KRITIS:
– Liegt ein abgestimmter Fahrplan (Roadmap) für die schrittweise Härtung und Optimierung von Teams vor, inkl. definierten Meilensteinen und Verantwortlichkeiten?
– Sind die kurzfristigen „Quick Win“-Maßnahmen erfolgreich umgesetzt worden und zeigen erste Verbesserungen (Metriken, weniger Incidents, höhere Sicherheit)?
– Wurden ausreichend Ressourcen (Personal, Budget, Tools) für das Transformationsprojekt bereitgestellt, und gibt es Support durch die Geschäftsleitung?
– Sind kritische Abhängigkeiten (wie Netzwerk-Upgrade, Identity-Projekte, Schulungen) identifiziert und in der Planung berücksichtigt, so dass keine Showstopper entstehen?
– Wird der Fortschritt der Umsetzung regelmäßig überwacht und kommuniziert, und werden dabei Risiken und Hindernisse aktiv adressiert?

11. Häufige Fehlannahmen und Gegenmaßnahmen

Auch im Umfeld von Microsoft Teams kursieren gewisse Mythen oder Missverständnisse. Hier werden einige dieser Fehlannahmen den Tatsachen gegenübergestellt und es werden Maßnahmen aufgezeigt, um die jeweiligen Risiken zu minimieren.

Tabelle – Mythos vs. Realität:
 

Prüfpunkte für KRITIS:
– Sind Entscheidungsträger und Administratoren über typische Irrtümer aufgeklärt und verstehen die tatsächlichen Risiken sowie Maßnahmen?
– Wurden Nutzern (und dem Management) realistische Erwartungen vermittelt, was Teams leisten kann und wo Grenzen sind (z.B. Cloud entbindet nicht von eigener Verantwortung)?
– Gibt es dokumentierte Richtlinien oder FAQs, die auf diese Fehlannahmen eingehen, sodass im Alltag keine falschen Entscheidungen aufgrund von Mythen getroffen werden?
– Wird kontinuierlich beobachtet, ob neue „Mythen“ oder Missverständnisse im Unternehmen auftreten (z.B. durch Feedback-Runden oder Support-Analysen), um darauf mit Aufklärung reagieren zu können?

12. Vorlagen & Artefakte (sofort nutzbar)

Zum Abschluss stellen wir einige direkt verwertbare Vorlagen und Beispiele zur Verfügung, die Sie in Ihrer Organisation anpassen können:

Policy-Muster (Auszug):

• Namenskonventionen: Alle Teams erhalten einen prägnanten Namen nach Schema „Abteilung – Thema/Projekt – optional Jahr“. Beispiel: „IT – Notfallplanung – 2025“. Sensible Teams erhalten einen Prefix (z.B. „VS-“ für „Verschlusssache“) und dürfen keine externen oder irreführenden Begriffe enthalten. Teamnamen müssen eindeutig und möglichst kurz sein; regelmäßige Überprüfung auf Dubletten erfolgt durch den Tenant-Admin.
• Gastzugriff: Gäste sind grundsätzlich nicht erlaubt, außer es liegt ein genehmigter Antrag vor (Freigabe durch InfoSec + Fachbereich). Jeder Gast wird mit Klarnamen und Firma dokumentiert. Gastberechtigungen sind minimal (nur auf das notwendige Team beschränkt). Vierteljährliche Kontrolle: Team-Owner bestätigen die weitere Notwendigkeit aller Gäste. Gäste sehen ein Banner mit Nutzungsbedingungen (NDA) beim Login.
• App-Zulassung: Nur vom IT-Governance-Board geprüfte und freigegebene Apps dürfen installiert werden. Die Standardeinstellung ist: alle Third-Party-Apps blockiert, Ausnahme auf Anfrage. Für jede App-Freigabe wird ein Risikosteckbrief erstellt (Datenverarbeitungsort, benötigte Berechtigungen, Compliance des Anbieters). Jährliche Neubewertung aller zugelassenen Apps. Custom-Apps (Eigenentwicklungen) müssen den Secure-Development-LifeCycle-Vorgaben genügen und vom CISO-Team abgenommen werden.
• Sensitivity Labels & Datensicherheit: Alle neu erstellten Teams müssen mit einem Vertraulichkeits-Label versehen werden (Standard: „Intern“). Hochvertrauliche Bereiche nutzen die Labels „Vertraulich“ oder „Streng Vertraulich“, die automatisch Gäste ausschließen und strengere Sharing-Regeln haben. Dokumente in Teams müssen entsprechend ihres Inhalts ebenfalls gelabelt sein (Integration mit Office Auto-Labeling). Uploads von Dateien ohne Label werden vom System abgefangen oder mit Default-Label „Intern“ versehen. Nutzer werden regelmäßig zur korrekten Klassifizierung sensibilisiert.

PowerShell/Graph Automatisierung (Beispiele):

• Beispiel 1: Liste aller Teams mit Gast-Benutzern (PowerShell)
   

           # Voraussetzung: MicrosoftTeams PowerShell-Modul ist installiert
Connect-MicrosoftTeams
$teams = Get-Team
foreach ($t in $teams) {
    $guests = Get-TeamUser -GroupId $t.GroupId -Role Guest
    if ($guests.Count -gt 0) {
        Write-Host „Team ‚$($t.DisplayName)‘ hat $($guests.Count) Gast/Gäste“
    }
}

           Kommentar: Dieses Skript gibt für jeden Team-Namen aus, wie viele Gäste darin Mitglied sind, und hilft so bei der Inventarisierung externer Zugriffe.

• Beispiel 2: Teams per Skript anlegen mit Label & Owner (PowerShell/Graph API)
   

           # Pseudocode: Neues Team mit Klassifizierung erstellen
$TeamName = „IT – Beispielprojekt – 2025“
$OwnerUPN = „max.muster@firma.de“
$LabelId = „GUID_des_SensitivityLabels_Intern“

# Gruppe/Team anlegen via Graph API (Voraussetzung: Graph Modul und Berechtigungen)
$newGroup = New-MgGroup -DisplayName $TeamName -MailEnabled $true -MailNickname „proj2025-it“ -SecurityEnabled $true -GroupTypes „Unified“ -Visibility Private -AssignedLabels @(@{labelId=$LabelId})
New-MgTeam -GroupId $newGroup.Id   # Team aktivieren
Add-TeamUser -GroupId $newGroup.Id -User $OwnerUPN -Role Owner

           Kommentar: Dieses Skript (Pseudo-Code) zeigt, wie man ein Team automatisiert erstellen könnte, inklusive Setzen eines Sensitivity-Labels (hier: Intern) und Zuordnung eines Owners. In der Praxis würde man noch weitere Parameter setzen (Beschreibung, weitere Einstellungen), ggf. mittels Teams-Vorlagen.

Channel-Vorlagen (Aufbau von Teams):

• Krisenstab-Team: Enthält Kanäle wie „Allgemein“ (Hauptkommunikation im Krisenfall, nur Kernteam), „Lageberichte“ (Einstellen von Lageberichten und Status-Updates, ggf. für erweiterte Beteiligte lesbar), „Maßnahmenverfolgung“ (Tracking der Aufgaben, Integration mit Planner für Maßnahmen) und „Dokumentation“ (Ablage von Notfallplänen, Kontaktlisten, Checklisten). Berechtigungen: Nur Krisenstab-Mitglieder, keine Gäste.
• Leitwarte-Team: Mögliche Kanäle: „Störungsmeldungen“ (Eingehende technische Alarme, ggf. via Connector automatisiert), „Eskalation“ (Abstimmung bei kritischen Störungen, hier sind auch Management/Stakeholder vertreten), „Schichtprotokoll“ (Infos zum Schichtwechsel, Übergabe zwischen Leitwarten-Personal), „Dokumente/Handbücher“ (betrieblich wichtige Unterlagen, Ansprechpartnerlisten). Zweck: Transparenz in der Leitstelle erhöhen, bessere Übergaben und Reaktionszeiten sicherstellen.
• Instandhaltung-Team: Mögliche Kanäle: „Wartungsplanung“ (Planung von Instandhaltungsfenstern, Abstimmung mit Betrieb), „Akute Störungen“ (Meldung aktueller Defekte, inkl. Fotos oder Sensordaten, Zuweisung eines Verantwortlichen), „Ersatzteile & Inventar“ (Verfolgung benötigter Ersatzteile, Lagerbestände, Bestellungen), „Wissen & Dokus“ (Anleitungen, Schaltpläne, Lessons Learned aus Einsätzen). Dieses Team wird idealerweise auch mobil genutzt (Tablets für Techniker mit Offline-Zugriff auf Dokumentation).

Checkliste Abnahme „Go-Live KRITIS-Teams“:

1. Das Management hat den KRITIS-Betrieb von Microsoft Teams formal genehmigt und alle relevanten Richtlinien freigegeben.
2. Rollen und Verantwortlichkeiten (inkl. Stellvertreterregelungen) für Betrieb, Sicherheit, Datenschutz und Notfall wurden benannt und kommuniziert.
3. Alle Benutzerkonten sind mit MFA abgesichert; erfolgreiche MFA-Anmeldung wurde bei allen getestet.
4. Administratorkonten sind separiert und mit PIM abgesichert; Notfallzugänge (Break-Glass) sind eingerichtet und getestet.
5. Conditional Access Policies sind für alle relevanten Zugriffs-Szenarien aktiv (inkl. Geräte-Compliance, Ortsabhängigkeiten, Risikoerkennung) und wurden mit Testusern verifiziert.
6. Alle genutzten Endgeräte erfüllen die Compliance-Vorgaben (Intune-Berichte sind grün); BYOD-Geräte haben App-Schutzrichtlinien oder werden blockiert.
7. Ein Klassifizierungs- und Labeling-Konzept ist umgesetzt: Jeder Team-Bereich hat ein Sensitivity-Label, alle Benutzer kennen die Label und wenden sie an.
8. DLP-Regeln für Teams sind aktiv und greifen (Test z.B. mit Dummy-Personaldaten wurde erfolgreich blockiert).
9. Aufbewahrungsrichtlinien (Retention) für Teams-Chats und -Dateien sind gemäß Regulierung eingestellt (und wurden in Tests validiert, z.B. dass Löschungen nach Ablauf erfolgen bzw. Inhalte vorher nicht gelöscht werden können).
10. Audit-Logging ist aktiviert und Logs der letzten Monate sind verfügbar; der Export bzw. die Anbindung ans SIEM funktioniert (Stichprobe von Events erfolgreich).
11. Einstellungen für externen Zugang und Gastzugriff entsprechen der Policy (z.B. Gastzugriff = an, aber mit Einschränkungen; externe Domänen: nur definierte Partner zugelassen).
12. Teams-spezifische Einstellungen wurden gehärtet: Keine anonymen Gäste in Meetings zugelassen, private Kanäle deaktiviert (oder nur für Owner erlaubt), Sharing-Optionen für Dateien sind eingeschränkt (z.B. kein Link-Typ „Jeder“).
13. Die Notruffunktion über Teams-Telefonie ist implementiert und erfolgreich getestet (inkl. Adressübermittlung und interner Alarmierung).
14. Telefonie-Redundanzen wurden getestet: Ausfall eines SBC / einer Leitung wurde simuliert und Notrufe sowie Kerntelefonie funktionierten über Backup.
15. Ein Incident- und Notfallhandbuch für Microsoft Teams liegt vor; Eskalationslisten (wer wird wann informiert) und alternative Kommunikationswege sind definiert.
16. Alle Administratoren und First-Level-Support-Mitarbeiter sind geschult (Systemkonfiguration, Sicherheitsrichtlinien, Supportprozesse in Teams).
17. Endbenutzer wurden über die wichtigsten Nutzungsregeln informiert (Do’s & Don’ts, Datenschutz, Meldewege bei Vorfällen) und haben diese akzeptiert (z.B. via Login-Banner oder schriftliche Bestätigung).
18. Sämtliche Dokumentation (Policies, Prozesse, betriebliche Anweisungen) ist zentral verfügbar, versioniert und in Kraft; alle Betroffenen kennen deren Standort.
19. Ein internes Audit oder Management-Review der Teams-Umgebung hat stattgefunden und keine kritischen Lücken mehr aufgezeigt (bzw. Maßnahmen wurden vor Go-Live umgesetzt).
20. Ein kontinuierliches Monitoring- & Maintenance-Konzept ist etabliert (Verantwortlicher benannt, KPIs definiert, geplanter Review-Turnus), um die nachhaltige Sicherheit und Compliance der Teams-Nutzung sicherzustellen.

Prüfpunkte für KRITIS:
– Wurden die bereitgestellten Policy-Vorlagen auf die spezifischen Anforderungen der Organisation angepasst und offiziell verabschiedet?
– Sind automatisierte Skripte und Tools (z.B. für Reporting oder Provisionierung) getestet und einsatzbereit, um den operativen Aufwand zu reduzieren und Fehler zu minimieren?
– Wurden sämtliche Punkte der Go-Live-Checkliste erfüllt und durch die zuständigen Verantwortlichen formal abgenommen, bevor Microsoft Teams in den KRITIS-Regelbetrieb übergeht?
– Sind die hier aufgeführten Vorlagen und Artefakte in das bestehende ISMS/Betriebshandbuch integriert, sodass sie kontinuierlich aktualisiert und genutzt werden?

Weitere Beiträge zum Thema SharePoint und Teams