SharePoint-Server im eigenen Haus: Warum dieser Patch nicht bis nächste Woche warten darf

Was ist passiert?

Ende Juli wurde bekannt, dass die Schweizer Bundesbehörde BIT über eine Schwachstelle in SharePoint on-premises kompromittiert wurde — also über einen SharePoint-Server, der im eigenen Rechenzentrum betrieben wird und nicht als Cloud-Dienst läuft. Betroffen sind nach bisherigem Stand hunderte Nutzerkonten.

Parallel dazu liefert der August-Patchday den Fix für eine weitere kritische SharePoint-Schwachstelle, die eine Codeausführung aus der Ferne ermöglicht — ein Angreifer kann also eigenen Programmcode auf dem Server starten, ohne sich vorher anmelden zu müssen. Sicherheitsanalysten stufen sie als den wichtigsten Risikopunkt dieses Patchdays für Unternehmen mit eigenem SharePoint ein.

Die Kombination ist unangenehm: ein realer, erfolgreicher Angriff auf eine gut ausgestattete Behörde — und zugleich eine frisch veröffentlichte Lücke, deren Details ab sofort öffentlich sind.

Warum ist gerade SharePoint on-premises so gefährdet?

Weil hier drei ungünstige Eigenschaften zusammenkommen. Erstens ist SharePoint fast immer erreichbar: Der Sinn der Software ist es, Dokumente für Mitarbeitende und oft auch für Externe bereitzustellen — viele Server hängen deshalb direkt am Internet.

Zweitens liegen dort die wertvollsten Daten: Verträge, Angebote, Personalunterlagen, Projektdokumentation. Ein kompromittierter SharePoint ist kein Randschaden, sondern trifft den Kern des Unternehmenswissens.

Drittens hängt SharePoint tief im Berechtigungssystem: Er ist eng mit dem Active Directory verzahnt. Wer den Server übernimmt, steht damit oft nicht am Ende, sondern am Anfang seines Angriffswegs — der nächste Schritt ist das Firmennetz.

Anders als bei der Cloud-Variante SharePoint Online liegt die Verantwortung fürs Patchen dabei vollständig bei Ihnen. Microsoft liefert das Update — einspielen muss es Ihr Haus.

Sind Sie betroffen — und woran erkennen Sie das?

Betroffen sind ausschließlich Unternehmen mit eigenem SharePoint-Server. Wer ausschließlich SharePoint Online aus Microsoft 365 nutzt, ist von dieser Lücke nicht betroffen — dort patcht Microsoft selbst. Der häufigste Fall im Mittelstand ist allerdings der dritte: eine hybride Umgebung, in der ein alter Server noch mitläuft, obwohl der Großteil längst in der Cloud liegt.

Fragen Sie Ihre IT gezielt diese vier Dinge ab:

• Betreiben wir einen eigenen SharePoint-Server? Auch einen, der nur noch für ein Altsystem oder ein Archiv läuft.
• Ist er aus dem Internet erreichbar? Das ist der entscheidende Risikofaktor.
• Ist der August-Patch eingespielt? Mit Datum, nicht mit „müsste“.
• Prüfen wir auf Anzeichen einer bereits erfolgten Kompromittierung? Bei aktiv ausgenutzten Lücken reicht Patchen allein nicht.

Der letzte Punkt wird gern übersehen: Ein Patch schließt die Tür — er wirft niemanden hinaus, der bereits drin ist.

Was sollten Sie in den nächsten 48 Stunden tun?

In dieser Reihenfolge, und ohne auf das nächste reguläre Wartungsfenster zu warten:

• Patch einspielen — auf allen SharePoint-Servern, auch auf denen, die „eigentlich niemand mehr nutzt“.
• Erreichbarkeit einschränken: Wenn der Server aus dem Internet erreichbar sein muss, dann nur über VPN oder ein vorgeschaltetes Gateway — nicht offen.
• Auf Spuren prüfen: Ungewöhnliche Anmeldungen, neue Konten, unerwartete Dateien im Webverzeichnis, auffällige ausgehende Verbindungen.
• Zugangsdaten erneuern: Bei Verdacht die Dienstkonten des Servers und alle darauf gespeicherten Zugänge.

Warum das Tempo? Sobald ein Patch veröffentlicht ist, analysieren Angreifer ihn gezielt, um die Lücke zu rekonstruieren. Der Zeitraum zwischen Veröffentlichung und breiten Angriffswellen liegt bei kritischen Serverlücken erfahrungsgemäß im Bereich von Tagen, nicht Wochen — das hat schon der Rekord-Patchday im Juli gezeigt.

Sollten Sie SharePoint überhaupt noch selbst betreiben?

Diese Frage ist die eigentlich wichtige — denn der nächste Zero-Day kommt. Für die meisten Mittelständler lautet die ehrliche Antwort: nein, wenn es keinen zwingenden Grund gibt.

Ein eigener SharePoint-Server ergibt Sinn, wenn regulatorische Vorgaben oder eine tief integrierte Fachanwendung ihn erfordern. Er ergibt keinen Sinn, wenn er nur historisch noch läuft — dann tragen Sie das volle Betriebs- und Sicherheitsrisiko für eine Funktion, die als Cloud-Dienst mitgepflegt würde.

Der Umstieg ist planbar und keine Nacht-und-Nebel-Aktion; welche Stolpersteine dabei typisch sind, haben wir in Microsoft 365 Migration und mit Blick auf die Datenablage in Fileserver oder SharePoint? beschrieben. Dasselbe Muster kennen wir vom Exchange Server — auch dort war der eigene Betrieb irgendwann mehr Risiko als Nutzen.

Was sollten Sie als Nächstes tun?

Kurzfristig zählt nur eines: patchen und prüfen, ob der Server unnötig aus dem Internet erreichbar ist. Das ist an einem Vormittag machbar und nimmt den akuten Druck.

Mittelfristig lohnt die grundsätzliche Entscheidung: Welche Server müssen wirklich im eigenen Haus stehen — und welche laufen dort nur noch aus Gewohnheit? Genau diese Bestandsaufnahme machen wir mit Ihnen: Wir prüfen Ihre SharePoint- und Serverlandschaft, schließen die akuten Lücken und zeigen, was sich sinnvoll ablösen lässt. Damit Sie beim nächsten Zero-Day gar nicht mehr betroffen sind.