> ## Content Index > Fetch the complete content index at: https://www.stefanoviani.com/llms.txt > Use this file to discover other available public pages before exploring further. # Was digitale Resilienz bedeutet – und was nicht - URL: https://www.stefanoviani.com/was-digitale-resilienz-bedeutet/ - Published: 2026-10-27T07:00:00.000Z - Updated: 2026-10-27T07:00:00.000Z - Description: Resilienz ist nicht IT-Sicherheit, nicht Unverwundbarkeit und nicht Autarkie. Was sie ist, und was der PHP2Shell-Tag im Oktober darüber gezeigt hat. - Author: Stefano Viani - Tags: Resilient aufgestellt *Serie B – Resilient aufgestellt, Teil 1* Als ich meine digitale Infrastruktur [von AWS zu Scaleway umgezogen](https://www.stefanoviani.com/infrastruktur-nach-europa/) hatte, dachte ich für einen Moment: Jetzt bin ich resilient. Die Daten liegen in Europa, die Server laufen, die Backups auch. Ein paar Tage später fiel mir auf, dass ich damit nur eine Frage beantwortet hatte: Wo liegen meine Daten? Die wichtigere Frage hatte ich mir noch gar nicht gestellt: Was passiert, wenn etwas davon morgen nicht mehr da ist? Um diese zweite Frage geht es in dieser Serie. Und weil „Resilienz“ inzwischen auf vielen Folien steht, beginne ich mit einer Abgrenzung. ## Was mit Resilienz gemeint ist Das Wort kommt aus der Materialkunde und der Psychologie. Ein resilientes Material verformt sich unter Last und kehrt danach in seine Form zurück. Ein resilienter Mensch übersteht eine Krise, ohne daran zu zerbrechen. Übertragen auf ein Unternehmen oder eine Selbstständigkeit heißt das: Digitale Resilienz ist die Fähigkeit, eine Störung zu überstehen, in der Zeit danach handlungsfähig zu bleiben und den normalen Betrieb wiederherzustellen. Im besten Fall kommt ein vierter Teil dazu: aus der Störung zu lernen, damit die nächste weniger weh tut. Das klingt selbstverständlich. In der Praxis wird es aber oft mit drei anderen Dingen verwechselt. ## Was Resilienz nicht ist **Resilienz ist nicht dasselbe wie IT-Sicherheit.** IT-Sicherheit fragt: Wie verhindere ich, dass jemand eindringt, Daten stiehlt oder Systeme lahmlegt? Das ist wichtig, und ohne sie geht es nicht. Resilienz setzt einen Schritt später an. Sie fragt: Was tue ich, wenn trotzdem etwas ausfällt? Sicherheit versucht, den Schaden zu verhindern. Resilienz rechnet damit, dass er eintritt, und begrenzt ihn. Dazu kommt ein zweiter Unterschied: Die meisten Störungen sind gar keine Angriffe. Ein Konto wird gesperrt, weil ein Algorithmus etwas falsch einordnet. Ein Anbieter erhöht die Preise, ändert seine Bedingungen oder stellt einen Dienst ein. Ein Rechenzentrum brennt, wie 2021 bei OVHcloud in Straßburg. Oder ich lösche selbst versehentlich den falschen Ordner. Gegen nichts davon hilft eine Firewall. **Resilienz ist nicht Unverwundbarkeit.** Wer versucht, jede Störung auszuschließen, gibt viel Geld aus und scheitert trotzdem. Resilient ist nicht, wem nichts passiert. Resilient ist, wer weiß, was im Ernstfall zu tun ist, und schnell wieder arbeiten kann. **Resilienz ist nicht Autarkie.** Ich hoste inzwischen einiges selbst: diese Website, meinen Newsletter, meine Cloud. Das macht mich unabhängiger von einzelnen Plattformen. Aber es schafft eine neue Abhängigkeit: von mir selbst. Wenn ich krank bin, ein Update schiefgeht oder ich eine Einstellung nicht verstehe, steht alles. Selbst hosten kann Resilienz erhöhen. Es kann sie auch senken. Darum geht es im Teil „Selbst hosten oder europäisch mieten?“ in Serie A. ## Und was ist mit digitaler Souveränität? Die beiden Begriffe gehören zusammen, meinen aber nicht dasselbe. Souveränität fragt: Wer hat die Kontrolle über meine Daten und Werkzeuge, und nach wessen Recht? Resilienz fragt: Wie schnell bin ich wieder handlungsfähig, wenn etwas wegbricht? Ein Beispiel: Wer alle Daten bei einem einzigen europäischen Anbieter hat, ist ziemlich souverän, aber nicht unbedingt resilient. Fällt dieser eine Anbieter aus, steht alles. Umgekehrt kann jemand mit mehreren US-Diensten und guten Backups sehr resilient sein, ohne souverän zu sein. Am besten ist beides. Aber man sollte wissen, welches Problem man gerade löst. ## Vier Fragen statt einer Checkliste Für Resilienz gibt es kein Produkt, das man kauft, und keine Liste, die man einmal abhakt. Was es gibt, sind Fragen, die man sich regelmäßig stellt. Ich nutze vier: 1. **Was ist wirklich kritisch?** Nicht alles ist gleich wichtig. Bei mir sind es die Kontakte zu Kunden und Lesern, meine Bilder und Texte, die Buchhaltung und die Kanäle, über die mich Menschen erreichen. 2. **Wovon hängt das ab?** Von welchem Anbieter, welchem Konto, welchem Zugang, welcher Person? Oft ist die Antwort überraschend lang. Und oft steht an einer Stelle ein einzelnes Passwort oder eine einzelne Telefonnummer für die Zwei-Faktor-Anmeldung. 3. **Was passiert, wenn es weg ist?** Für eine Stunde, für eine Woche, für immer. Ein Ausfall von einer Stunde ist ärgerlich. Ein dauerhaft gesperrtes Konto mit zehn Jahren Inhalten und allen Kontakten ist eine andere Kategorie. 4. **Wie komme ich zurück, und habe ich das ausprobiert?** Ein Backup, das ich nie zurückgespielt habe, ist eine Hoffnung, kein Plan. Dasselbe gilt für Notfallzugänge und Ersatzkanäle. Diese Fragen lassen sich in einer Stunde für das eigene Geschäft beantworten. Sie ersetzen kein Sicherheitskonzept. Aber sie zeigen ziemlich schnell, wo die eigentlichen Schwachstellen liegen. ## Wo ich selbst verwundbar bin Als Fotograf hängt ein großer Teil meiner Sichtbarkeit an Instagram. Dort erreiche ich die meisten Menschen, dort entstehen viele Kontakte. Gleichzeitig gehört mir dort nichts: nicht die Reichweite, nicht die Liste der Follower, nicht die Regeln. Wenn das Konto morgen gesperrt wäre, wären die Bilder noch da. Der Weg zu den Menschen, die sie sehen wollen, wäre es nicht. Das ist der Grund, warum ich einen eigenen Blog und einen eigenen Newsletter aufbaue. Nicht, weil Instagram schlecht wäre, sondern weil ich nicht von einem einzigen Kanal abhängig sein will, den ich nicht kontrolliere. Um genau diese Verwundbarkeit geht es im nächsten Teil. ## Ein Ernstfall aus der letzten Woche Wie das praktisch aussieht, hat der 21\. Oktober gezeigt. An diesem Tag hat das PHP-Projekt zwei kritische Lücken geschlossen, die unter dem Namen „PHP2Shell“ bekannt wurden. Über sie ließ sich ohne Anmeldung fremder Code auf Webservern ausführen. Das BSI warnte mit der zweithöchsten Stufe und riet, Systeme im Zweifel vom Netz zu nehmen. Einige Behörden, Hochschulen und Kliniken haben genau das getan. Bei Blackbit, der Agentur, die ich lange geführt habe und an der ich bis heute beteiligt bin, lief der Tag anders. Die Plattformen der Hosting-Kunden laufen dort auf einem eigenen Kubernetes-Cluster bei Scaleway. Noch vor dem offiziellen Update änderte das Team auf allen Kundensystemen eine Einstellung, die das Risiko verringerte. Als der Patch kam, wurde er eingespielt, ohne die Websites dafür abzuschalten. Viele Kunden haben von dem Tag kaum etwas gemerkt. Der Cluster allein war aber nicht der Grund. Für ältere PHP-Versionen, die das PHP-Projekt offiziell nicht mehr pflegt, gab es zunächst keinen Patch. Systeme, deren Software für eine aktuelle Version zu alt war, mussten deshalb auch bei Blackbit vorsorglich vom Netz. Dass sie wieder online gehen konnten, war Glück: Wegen der Schwere der Lücken stellte das PHP-Team ausnahmsweise doch eine Notfallkorrektur für einige ältere Versionen bereit. Ohne sie hätte nur eine Aktualisierung der ganzen Anwendung samt PHP-Version geholfen, und die ist in wenigen Stunden nicht zu schaffen. Diese Seiten wären auf unbestimmte Zeit offline geblieben. Für die gepflegten Systeme war der Patch dagegen Routine. Die Lücke betraf alle gleich. Ob man sich auf Planung oder auf Glück verlassen musste, entschied die Pflege der Monate davor. Den Ablauf hat Dennis Korbginski im [Blackbit-Blog](https://www.blackbit.com/de/blog/php2shell-warum-updates-kein-selbstzweck-sind?ref=stefanoviani.com) beschrieben. Mein eigener Nextcloud-Server stand an diesem Abend schlechter da. Der Patch war zwar erschienen, aber die Paketquelle, aus der ich PHP beziehe, war überlastet und lieferte ihn erst Stunden später. Bis dahin blieb nur, den Server abzuschalten. Für eine private Cloud ist das kein Drama. Es ist aber genau die Abhängigkeit von mir selbst, von der oben unter „Autarkie“ die Rede war. ## Was das für die nächsten Wochen heißt Die Serie „Resilient aufgestellt“ geht die vier Fragen der Reihe nach durch: - **Gemietete Reichweite:** Warum eine Marke, die nur auf Instagram existiert, verwundbar ist. - **Backups, die man zurückholen kann:** Die 3-2-1-Regel und warum nur der getestete Restore zählt. - **Der Tag X:** Was zu tun ist, wenn das Geschäftskonto gesperrt wird oder ein Dienst ausfällt. - **Eigene Kanäle aufbauen:** Wie Website, Newsletter und Community zum Rückgrat werden. Zu einigen Teilen gibt es für Abonnenten eine Anleitung zum Umsetzen, etwa den Plattform-Notfallplan oder die Einrichtung verschlüsselter Backups. ## Fazit Digitale Resilienz ist keine Technik, sondern eine Haltung: davon auszugehen, dass etwas schiefgeht, und vorbereitet zu sein. IT-Sicherheit ist ein Teil davon, Souveränität ein anderer. Wer beides hat und trotzdem nie ausprobiert hat, wie er nach einem Ausfall zurückkommt, ist noch nicht resilient. Ich bin es auch noch nicht ganz. Aber ich weiß inzwischen, wo die Lücken sind. --- *Nächster Teil der Serie B am 17\. November: Gemietete Reichweite.*