Von ToolShell bis End-of-Support: Jetzt beginnt Ihr Zeitplan für die SharePoint-Migration
Die ToolShell-Exploit-Kette ist mehr als nur eine weitere Sicherheitslücke, die gepatcht werden muss. Sie markiert einen grundlegenden Wandel darin, wie staatlich gesteuerte Akteure On-Premises-Kollaborationsinfrastrukturen ins Visier nehmen. Die chinesischen Bedrohungsgruppen Linen Typhoon und Violet Typhoon kompromittierten erfolgreich SharePoint-Server, um kryptografische Schlüssel zu stehlen und dauerhaften Netzwerkzugriff zu etablieren. Diese aktive Angriffskampagne, kombiniert mit dem 14. Juli 2026 als Stichtag für den erweiterten Microsoft-Support, erzeugt einen engen Zeitrahmen, den die meisten Unternehmen erheblich unterschätzen.
Die Rechnung ist einfach, aber unerbittlich: Eine realistische SharePoint-Migration benötigt 12–18 Monate vom ersten Assessment bis zur abgeschlossenen Bereitstellung. Mit nur noch 20 Monaten bis zum Support-Ende im November 2025 stehen Unternehmen, die die Planung über dieses Quartal hinaus aufschieben, vor überstürzten Entscheidungen, Budgetengpässen oder dem Betrieb nicht mehr unterstützter Infrastruktur, während sie hektisch migrieren. Dieser Beitrag bietet einen Meilenstein-basierten Zeitplan, der Budgetzyklen, die Komplexität der Anbieterauswahl und die tatsächlichen Migrationsrealitäten berücksichtigt – und nicht die optimistischen Schätzungen der Anbieter.
Executive Summary
Kernaussage: Eine erfolgreiche Migration von SharePoint On-Premises vor dem Microsoft-Support-Ende am 14. Juli 2026 erfordert einen sofortigen Start des Planungsprozesses mit einem strukturierten Fünf-Meilenstein-Ansatz über 12–18 Monate. Unternehmen müssen Budgetzyklen, gründliche Anbieterauswahl, schrittweise Bereitstellung und Nutzerakzeptanz einplanen – Zeitfaktoren, die sich nicht ohne erhebliches Risiko für Sicherheit, Compliance und Betriebsstabilität verkürzen lassen.
Warum das relevant ist: Unternehmen, die erst Ende 2025 oder Anfang 2026 mit der SharePoint-Migrationsplanung beginnen, stehen vor unmöglichen Entscheidungen: Sie müssen kritische Evaluierungs- und Planungsphasen überstürzen, Sicherheitslücken während hektischer Migrationen in Kauf nehmen oder auf verwundbarer, nicht unterstützter Infrastruktur arbeiten, während der Übergang noch läuft. Die Kombination aus aktiver ToolShell-Ausnutzung und dem nahenden Support-Ende lässt keinen Spielraum mehr für das nächste Budgetjahr oder verzögerte Entscheidungen.
wichtige Erkenntnisse
- ToolShell zeigt architektonische Schwachstellen auf: Diese Exploit-Kette gegen SharePoint On-Premises (CVE-2025-53770, CVSS 9.8) steht für ausgefeilte Taktiken staatlicher Akteure, die kryptografische Schlüssel stehlen und so dauerhaften Zugriff erhalten – Schwachstellen, die sich in Legacy-On-Premises-Architekturen nicht allein durch Patches beheben lassen.
- Migration benötigt mindestens 12–18 Monate: Unternehmen unterschätzen den Zeitaufwand für Migrationen regelmäßig um 6–12 Monate, da sie die Anforderungsaufnahme, Anbieterauswahl, Compliance-Prüfung, schrittweise Bereitstellung und Nutzerakzeptanz in verteilten Umgebungen nicht ausreichend berücksichtigen.
- Budgetzyklen erhöhen den Zeitdruck: Unternehmen ohne Budgetzuweisung für das Geschäftsjahr 2026 starten Projekte erst Mitte/Ende 2026 und schließen die Migration damit erst 2027 oder später ab – also deutlich nach dem Support-Ende am 14. Juli 2026.
- Fünf kritische Meilensteine sind nicht komprimierbar: Assessment und Anforderungsaufnahme, Anbieterauswahl, Planung und Design, Pilotbereitstellung sowie vollständige Produktivmigration benötigen jeweils eigene Zeitfenster für eine erfolgreiche Umsetzung ohne Sicherheitslücken oder Betriebsunterbrechungen.
- Start im November 2025 ist bereits spät: Mit 20 Monaten bis zum Support-Ende und 12–18 Monaten Migrationsdauer bleibt Unternehmen, die jetzt beginnen, nur ein minimaler Puffer für unerwartete Komplikationen oder Verzögerungen.
ToolShell verstehen: Warum sich die Migrationsrechnung grundlegend ändert
ToolShell unterscheidet sich in Umfang und Absicht von typischen Schwachstellen. Chinesische staatliche Gruppen entwickelten diese Exploit-Kette gezielt für Angriffe auf SharePoint-Server und nutzen dabei kritische Schwachstellen wie CVE-2025-53770, CVE-2025-53771, CVE-2025-49704 und CVE-2025-49706. Die Raffinesse des Exploits liegt nicht nur im Erstzugriff, sondern auch darin, kryptografische Schlüssel zu stehlen und so dauerhaften Zugriff zu sichern, der Patch-Zyklen überdauern kann.
Für Sicherheitsteams stellt das ein grundlegendes Problem dar. Traditionelle Zero-Trust-Sicherheitsarchitekturen gehen von einem Einbruch aus und begrenzen laterale Bewegungen durch kontinuierliche Verifizierung. SharePoint On-Premises, entwickelt in einer Zeit der Perimeter-Sicherheit, bietet diese architektonischen Schutzmechanismen nicht. Selbst Unternehmen mit ausgefeilten Incident-Response-Fähigkeiten sehen sich mit Verwundbarkeitsfenstern zwischen Exploit-Veröffentlichung und erfolgreichem Patchen in komplexen Umgebungen konfrontiert.
Die gezielte Attacke auf Kollaborationsplattformen durch staatliche Akteure folgt einem klaren Muster. Diese Systeme enthalten wertvolle Daten wie Verträge, geistiges Eigentum und sensible Kommunikation. Kompromittierte Kollaborationsserver dienen zudem als Ausgangspunkt für laterale Bewegungen zu weiteren Netzwerkressourcen. Unternehmen können architektonische Schwachstellen, die diese Systeme zu attraktiven Zielen machen, nicht einfach durch Patches beheben.
Der echte Migrationszeitplan: Fünf kritische Meilensteine
Meilenstein 1: Assessment und Anforderungsaufnahme (Monate 1–3)
Die Grundlage einer erfolgreichen Migration ist eine umfassende Anforderungsdokumentation, die Unternehmen häufig überstürzt oder ganz überspringen. In dieser Phase sind eine Sicherheitsrisikoanalyse der aktuellen SharePoint-Infrastruktur, das Mapping der Compliance-Anforderungen relevanter Frameworks, Datenklassifizierung und Sensitivitätsanalyse, Dokumentation von Nutzer-Workflows über Abteilungen hinweg sowie die Einbindung aller Stakeholder aus IT, Security, Compliance und Fachbereichen erforderlich.
Wer diese Phase verkürzt, entdeckt zwangsläufig während der Migration fehlende Anforderungen, was teure Kurswechsel oder nachträgliche Tool-Ergänzungen notwendig macht. Das Ergebnis ist nicht nur ein Anforderungskatalog, sondern ein klares Verständnis davon, was die SharePoint-Alternative aus Sicht von Sicherheit, Compliance und Betrieb leisten muss. Für regulierte Branchen gehört dazu auch das Mapping der Anforderungen für CMMC, HIPAA, DSGVO oder andere relevante Frameworks.
Meilenstein 2: Anbieterauswahl und -bewertung (Monate 3–6)
Die Anbieterauswahl umfasst mehr als das Prüfen von Marketingunterlagen und Demoterminen. Unternehmen müssen Proof-of-Concept-Tests mit echten Daten und Workflows durchführen, Sicherheitsarchitekturen validieren, die Unterstützung von Compliance-Frameworks auf spezifische Anforderungen abbilden, die Gesamtkosten inklusive versteckter Betriebskosten analysieren und Verträge mit passenden Support- und Service-Level-Agreements verhandeln.
Die entscheidende Frage ist nicht „Kann diese Plattform, was SharePoint kann?“, sondern „Löst diese Plattform die Probleme, die uns von SharePoint wegtreiben?“ Plattformen mit Private Data Network-Architektur, Zero-Trust-Prinzipien, FedRAMP-Moderate-Zertifizierung und einheitlicher Governance für Filesharing, E-Mail und Managed File Transfer bieten grundlegend andere Ansätze als die bloße Migration von SharePoint in eine Multi-Tenant-Cloud.
Meilenstein 3: Planung und Design (Monate 6–9)
Die Migrationsplanung entscheidet, ob der Übergang gelingt oder zur Dauerkrise wird. In dieser Phase werden eine detaillierte Migrationsmethodik mit Phasenplanung, Design der Sicherheitsarchitektur und Konfiguration der Compliance-Frameworks, Integrationsarchitektur für Bestandssysteme, Mapping von Nutzerzugriffen und Berechtigungen, Entwicklung von Trainingsprogrammen und Kommunikationsplänen sowie die Auswahl von Pilotgruppen mit Erfolgskriterien erarbeitet.
Das Ergebnis ist kein einfacher Projektplan, sondern ein umfassender Blueprint für technische Architektur, Sicherheits- und Compliance-Validierung, Nutzerkommunikation, Trainings und Notfallplanung. Wer diese Phase überstürzt, riskiert längere Ausfallzeiten, Nutzerverwirrung, Sicherheitslücken und die Notwendigkeit, Migrationsschritte zu wiederholen.
Meilenstein 4: Pilotbereitstellung und Validierung (Monate 9–12)
Die Pilotbereitstellung mit 50–200 Anwendern ist der entscheidende Praxistest vor dem breiten Rollout. In dieser Phase wird geprüft, ob Workflows realitätsnah funktionieren, Sicherheitsrichtlinien wie vorgesehen greifen, Audit-Trails die erforderlichen Compliance-Daten erfassen und die Nutzererfahrung die Akzeptanzschwelle erreicht.
Die Erkenntnisse aus der Pilotphase fließen direkt in die Produktivmigration ein. Probleme, die im Pilot gelöst werden, treten beim breiten Rollout nicht mehr auf. Wer die Pilotphase überspringt oder überstürzt, entdeckt diese Probleme erst, wenn die Auswirkungen größer und der Nutzerkreis breiter sind – mit entsprechendem Zeitverlust und Vertrauensverlust in die Migration.
Meilenstein 5: Vollständige Produktivmigration (Monate 12–18)
Die Produktivmigration erfolgt in Wellen, nicht als Big Bang. Frühe Anwendergruppen migrieren zuerst und liefern zusätzliche Validierung, bevor Standardnutzer folgen. Komplexe oder besonders sensible Gruppen migrieren zuletzt und profitieren von optimierten Prozessen und Lessons Learned. Jede Welle erfordert Monitoring, Support, Problemlösung und Validierung, bevor die nächste startet.
Dieser gestufte Ansatz gibt Nutzern Zeit zur Anpassung, ermöglicht Problemlösung ohne Krisendruck und stellt sicher, dass alles funktioniert, bevor Altsysteme abgeschaltet werden. Verkürzte Zeitpläne führen zu Nutzerwiderstand, Sicherheitsumgehungen und möglichen Lücken in der Daten-Governance.
Der Kalender-Realismus: Warum Warten das Verpassen der Frist bedeutet
Die Mathematik der Migrationszeitpläne ist unerbittlich. Heute ist November 2025. Das Support-Ende von Microsoft ist der 14. Juli 2026 – also etwa 20 Monate entfernt. Ein realistischer Migrationszeitraum beträgt 12–18 Monate. Unternehmen, die jetzt starten, haben 2–8 Monate Puffer für unerwartete Komplikationen. Wer bis Q1 2026 wartet, hat keinen Puffer mehr. Wer auf die Budgetfreigabe für das Geschäftsjahr 2027 wartet, verpasst die Frist komplett.
Budgetzyklen verschärfen den Druck zusätzlich. Unternehmen ohne Budget für die SharePoint-Ablösung im Geschäftsjahr 2026 müssen auf die Planung und Genehmigung für das Geschäftsjahr 2027 warten – Projektstart also Mitte/Ende 2026. Das verschiebt den Abschluss auf 2027 oder 2028 und erfordert einen längeren Betrieb auf nicht unterstützter Infrastruktur, während die Migration läuft.
Jeder Monat Verzögerung erhöht die Angriffsfläche für Exploits wie ToolShell, reduziert die Zeit für eine gründliche Anbieterauswahl und erhöht die Wahrscheinlichkeit überhasteter Entscheidungen unter Zeitdruck. Spät startende Unternehmen stoßen zudem auf Kapazitätsengpässe bei Anbietern, da der Markt vor dem Support-Ende eilig migriert.
Interimistische Sicherheitsmaßnahmen: Notwendig, aber nicht ausreichend
Während die Migrationsplanung läuft, sollten Unternehmen verstärkte Sicherheitsmaßnahmen für bestehende SharePoint-Infrastrukturen umsetzen. Sicherheitsupdates sind sofort nach Veröffentlichung einzuspielen, Netzsegmentierung zur Begrenzung lateraler Bewegungen kompromittierter Server einzurichten, Monitoring für ToolShell-Indikatoren und ungewöhnliche Authentifizierungsmuster zu intensivieren, Zugriffskontrollen inklusive Multi-Faktor-Authentifizierung zu verschärfen sowie Backup-Frequenz und regelmäßige Wiederherstellungstests zu erhöhen.
Diese Zwischenmaßnahmen senken das Risiko, beseitigen aber nicht die grundlegenden architektonischen Schwachstellen, die On-Premises-Kollaborationsplattformen zu attraktiven Zielen machen. Sie sind temporäre Risikominderung, keine langfristige Sicherheitsstrategie. Unternehmen sollten die Migrationsplanung beschleunigen, statt sich dauerhaft auf Zwischenkontrollen zu verlassen.
Kiteworks: Ihre SharePoint-Migrationslösung
Unternehmen, die SharePoint-Alternativen evaluieren, stehen vor einer entscheidenden Wahl: Migration zu SharePoint Online – und damit Übernahme vieler Compliance-Einschränkungen einer Multi-Tenant-Architektur – oder Wechsel zu einer Plattform, die gezielt die Probleme löst, die Sie von On-Premises-Infrastruktur wegführen.
Kiteworks bietet ein Private Data Network mit Zero-Trust-Architektur, das die Angriffsfläche eliminiert, die staatliche Akteure bei On-Premises-Plattformen ausnutzen. Im Gegensatz zum Multi-Tenant-Modell von SharePoint Online bietet Kiteworks logisch isolierte Infrastruktur, darunter eine seit Juni 2017 FedRAMP-Moderate-zertifizierte und seit Februar 2025 FedRAMP-High-Ready-virtuelle Private Cloud – Sicherheitsvalidierung, die nur wenige Alternativen bieten.
Die einheitliche Governance der Plattform adressiert eine zentrale SharePoint-Schwäche: fragmentierte Sicherheit über mehrere Datenkanäle hinweg. Kiteworks konsolidiert Datenkommunikation – darunter sicheres Filesharing, sichere E-Mail, Secure MFT, Kiteworks SFTP und Kiteworks Secure Data Forms – unter zentralen Richtlinien und Audit-Trails und beseitigt so den Compliance-Overhead, der beim Abgleich verteilter Systeme entsteht.
Für Compliance-Teams automatisiert Kiteworks Aufgaben, die SharePoint nur mit manuellem Aufwand ermöglicht. Die Plattform unterstützt out-of-the-box fast 90% der CMMC 2.0 Level 2-Anforderungen für Defense Contractors, bietet vorkonfigurierte Frameworks für HIPAA-Compliance, PCI DSS-Compliance, DSGVO-Compliance, PCI-Compliance, CMMC 2.0-Compliance und ITAR-Compliance und liefert automatisierte Audit-Reports, die laut Kunden 90% schneller sind als manuelle SharePoint-Prozesse.
Der messbare Effekt ist entscheidend für Budgetfreigaben: Unternehmen, die zu Kiteworks migrieren, berichten von 75% weniger Sicherheitsvorfällen im Zusammenhang mit sensiblen Datenbewegungen, 90% schnelleren Compliance-Reports im Vergleich zu SharePoint On-Premises und 60% geringeren Gesamtkosten, wenn eingesparte Hardwarekosten, reduzierte Security-Operations-Aufwände und zurückgewonnene IT-Kapazitäten einbezogen werden.
Gerade für Unternehmen mit Frist Juli 2026 entscheidend: Kiteworks bietet eine bewährte Migrationsmethodik, die in Tausenden Projekten verfeinert wurde. Unser dediziertes Migrationsteam begleitet Unternehmen durch alle Meilensteine mit gestuften Ansätzen, die Störungen minimieren und Sicherheitsgewinne maximieren. Diese strukturierte Unterstützung ermöglicht es, auch ambitionierte Zeitpläne einzuhalten, ohne Anforderungen zu kompromittieren oder Sicherheitslücken zu schaffen.
Der Zeitdruck ist real, aber der Lösungsweg ist klar. Erfahren Sie, wie Kiteworks Sie bei einer Meilenstein-basierten SharePoint-Migration unterstützt, die die Frist Juli 2026 einhält und gleichzeitig die Sicherheits-, Compliance- und Governance-Lücken schließt, die On-Premises-Infrastruktur nicht mehr lösen kann. Vereinbaren Sie eine Beratung, um Ihren individuellen Zeitplan und Ihre Anforderungen zu besprechen.
Häufig gestellte Fragen
ToolShell ist eine Exploit-Kette, die von den chinesischen staatlichen Gruppen Linen Typhoon und Violet Typhoon entwickelt wurde und kritische Schwachstellen in SharePoint Server ausnutzt, darunter CVE-2025-53770 (CVSS 9.8), CVE-2025-53771, CVE-2025-49704 und CVE-2025-49706. Diese Exploits ermöglichen es Angreifern, SharePoint-Server zu kompromittieren und kryptografische Schlüssel zu stehlen, die dauerhaften Netzwerkzugriff selbst nach dem Patchen der ursprünglichen Schwachstelle erlauben. SharePoint-Server sind attraktive Ziele, da sie sensible Kommunikation, Verträge, geistiges Eigentum enthalten und als Ausgangspunkt für laterale Bewegungen zu weiteren Netzwerkressourcen dienen. Der Exploit zeigt, dass On-Premises-Kollaborationsplattformen architektonische Schwachstellen aufweisen, die sich nicht allein durch Patches beheben lassen, da diese Systeme für Perimeter-Sicherheit und nicht für Zero-Trust-Architekturen entwickelt wurden, die von einem Einbruch ausgehen und laterale Bewegungen begrenzen.
Realistische SharePoint-Migrationsprojekte dauern 12–18 Monate vom ersten Assessment bis zur vollständigen Produktivsetzung – deutlich länger als die von vielen Unternehmen angenommenen 6–9 Monate. Dieser Zeitraum umfasst Assessment und Anforderungsaufnahme (Monate 1–3), Anbieterauswahl und Proof-of-Concept-Tests (Monate 3–6), detaillierte Planung und Design inklusive Sicherheitsarchitektur und Compliance-Konfiguration (Monate 6–9), Pilotbereitstellung und Validierung mit einer Teilmenge der Nutzer (Monate 9–12) sowie gestufte Produktivmigration in Wellen (Monate 12–18). Unternehmen unterschätzen diese Zeiträume regelmäßig, weil sie Budgetfreigaben, gründliche Sicherheitsbewertung der Alternativen, Validierung von Compliance-Frameworks, Nutzerschulung und -akzeptanz sowie die Tatsache, dass groß angelegte Migrationen nicht überstürzt werden können, nicht ausreichend berücksichtigen. Plattformen wie Kiteworks mit bewährter Migrationsmethodik und dedizierten Support-Teams helfen Unternehmen, im realistischen Zeitrahmen zu bleiben – dennoch benötigen organisatorisches Change Management und Validierung feste Zeitfenster, die sich nicht ohne erhebliches Risiko verkürzen lassen.
Der Betrieb von SharePoint On-Premises nach dem Support-Ende von Microsoft am 14. Juli 2026 führt zu sich verschärfenden Risiken. Sicherheitslücken, die nach diesem Datum entdeckt werden, erhalten keine Patches mehr – Ihre Systeme bleiben dauerhaft für bekannte Exploits verwundbar, ohne dass eine Abhilfe möglich ist. Compliance-Frameworks verlangen zunehmend, dass Systeme mit sensiblen Daten regelmäßig Sicherheitsupdates erhalten. Es wird daher schwierig oder unmöglich, Compliance nachzuweisen, wenn nicht unterstützte Software betrieben wird – das betrifft insbesondere Unternehmen, die CMMC, HIPAA, PCI DSS oder ähnliche Vorgaben erfüllen müssen. Cyber-Versicherungen schließen in der Regel Schäden durch nicht unterstützte Software aus, was zu finanziellen Risiken führt. Operativ summieren sich Kompatibilitätsprobleme mit neuen Systemen und Sicherheitstools, was spätere Migrationen komplexer und teurer macht. Unternehmen sollten den Juli 2026 nicht als fernes Ziel, sondern als spätesten Fertigstellungstermin betrachten und die Evaluierung und Planung sofort beginnen, um nicht auf verwundbarer, nicht unterstützter und potenziell nicht konformer Infrastruktur arbeiten zu müssen.
Diese Entscheidung hängt davon ab, ob SharePoint Online die Kernprobleme löst, die Sie von On-Premises-Infrastruktur wegführen. SharePoint Online beseitigt den Hardwareaufwand, läuft aber in einer Multi-Tenant-Architektur, in der Ihre Daten die Infrastruktur mit Tausenden anderen Unternehmen teilen – das genügt oft nicht den hohen Sicherheitsanforderungen für besonders sensible Daten. Viele Compliance-Einschränkungen von SharePoint On-Premises bleiben bestehen, etwa fehlende automatisierte Audit-Reports, lückenlose Datenherkunftsnachweise und fehlende einheitliche Governance über E-Mail, Filesharing und andere Datenkanäle. Unternehmen mit hohen Sicherheits- oder Compliance-Anforderungen stellen häufig fest, dass speziell entwickelte Plattformen für sicheren Datenaustausch ihre Bedürfnisse besser erfüllen. Plattformen wie Kiteworks bieten Private Data Network-Architektur mit logisch isolierter Infrastruktur, FedRAMP-Moderate-Zertifizierung, Unterstützung für fast 90% der CMMC 2.0 Level 2-Anforderungen und einheitliche Governance für alle sensiblen Datenbewegungen. Die richtige Wahl hängt von Ihren spezifischen Sicherheitsarchitekturanforderungen, Compliance-Frameworks und dem Bedarf an Konsolidierung von Managed File Transfer, E-Mail-Sicherheit und Filesharing unter einheitlichen Richtlinien und Audit-Trails ab.
Die häufigsten und teuersten Fehler bei der SharePoint-Migrationsplanung sind die Unterschätzung des Zeitaufwands um 6–12 Monate, das Nichtberücksichtigen von Budgetzyklen und Genehmigungsprozessen, das Überspringen einer gründlichen Anforderungsaufnahme (was zu Kurswechseln während der Migration führt), das Überstürzen oder Auslassen der Pilotphase (wodurch Probleme erst beim breiten Rollout sichtbar werden) sowie der Versuch eines Big-Bang-Cutovers statt einer gestuften Migration mit kontrollierter Validierung und Problemlösung. Unternehmen versäumen es oft, Compliance-Anforderungen umfassend zu mappen, und entdecken Lücken erst bei Audits nach der Migration. Ein weiterer Fehler ist die Bewertung von Plattformen nur anhand von Feature-Checklisten statt nach architektonischen Ansätzen für Sicherheit und Governance – also die Frage „Kann es, was SharePoint kann?“ statt „Löst es die Probleme, die uns von SharePoint wegführen?“. Viele Unternehmen unterschätzen auch den Change-Management- und Trainingsbedarf für die Nutzerakzeptanz, was zu Workarounds und Umgehung von Sicherheitskontrollen führt. Schließlich wird häufig nicht validiert, ob die gewählte Plattform tatsächlich die spezifischen Anforderungen an Data Governance, Zero-Trust-Sicherheit und Compliance-Automatisierung erfüllt – diese Lücken werden dann erst nach erheblichem Zeit- und Budgetaufwand sichtbar.
Weitere Ressourcen
- Blog Post
5 beste sichere Filesharing-Lösungen für Unternehmen - Blog Post
Wie Sie Dateien sicher teilen - Video
Kiteworks Snackable Bytes: Sicheres Filesharing - Blog Post
12 unverzichtbare Anforderungen an sichere Filesharing-Software - Blog Post
Die sichersten Filesharing-Optionen für Unternehmen & Compliance