Aufbau sicherer und zuverlässiger Systeme

Kapitel 1. Der Schnittpunkt von Sicherheit und Verlässlichkeit

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Von Adam Stubblefield, Massimiliano Poletto und Piotr Lewandowski

mit David Huska und Betsy Beyer

Über Passwörter und Power Drills

Am 27. September 2012 verursachte eine unschuldige Google-weite Ankündigung eine Reihe von kaskadenartigen Ausfällen bei einem internen Dienst. Um diese Ausfälle zu beheben, war eine Bohrmaschine erforderlich.

Google hat einen internen Passwort-Manager, mit dem Mitarbeiter Geheimnisse für Dienste von Drittanbietern, die keine besseren Authentifizierungsmechanismen unterstützen, speichern und weitergeben können. Eines dieser Geheimnisse ist das Passwort für das Gast-WiFi-System in der großen Busflotte, die die Google-Standorte in der San Francisco Bay Area verbindet.

An jenem Tag im September schickte das Transportteam des Unternehmens eine E-Mail mit der Ankündigung an Tausende von Mitarbeitern, dass das WiFi-Passwort geändert worden war. Der daraus resultierende Ansturm war weitaus größer, als das Passwortverwaltungssystem - das Jahre zuvor für eine kleine Gruppe von Systemadministratoren entwickelt worden war - bewältigen konnte.

Die Last führte dazu, dass das primäre Replikat des Passwortmanagers nicht mehr reagierte, so dass der Load Balancer den Datenverkehr auf das sekundäre Replikat umleitete, das prompt auf dieselbe Weise fehlschlug. An diesem Punkt rief das System den Bereitschaftsingenieur an. Der Techniker hatte keine Erfahrung mit Ausfällen des Dienstes: Der Passwortmanager wurde nach bestem Bemühen unterstützt und hatte in den fünf Jahren seines Bestehens noch nie einen Ausfall erlebt. Der Techniker versuchte, den Dienst neu zu starten, wusste aber nicht, dass für einen Neustart eine Hardware-Sicherheitsmodul (HSM)-Smartcard erforderlich war.

Diese Smartcards wurden in mehreren Tresoren in verschiedenen Google-Büros auf der ganzen Welt aufbewahrt, aber nicht in New York City, wo sich der Bereitschaftsingenieur befand. Als der Neustart des Dienstes fehlschlug, kontaktierte der Techniker einen Kollegen in Australien, um eine Smartcard zu holen. Zu ihrer großen Bestürzung konnte der Techniker in Australien den Tresor nicht öffnen, weil die Kombination in dem inzwischen abgeschalteten Passwortmanager gespeichert war. Glücklicherweise hatte sich ein anderer Kollege in Kalifornien die Kombination für den Tresor vor Ort gemerkt und konnte die Smartcard abrufen. Doch selbst nachdem der Techniker in Kalifornien die Karte in ein Lesegerät gesteckt hatte, schlug der Dienst mit der kryptischen Fehlermeldung fehl: "Das Passwort konnte keine der Karten laden, die diesen Schlüssel schützen."

An diesem Punkt beschlossen die Techniker in Australien, dass sie ihr Tresorproblem mit brachialer Gewalt angehen sollten und setzten eine Bohrmaschine ein. Eine Stunde später war der Tresor geöffnet, aber auch die neu entnommenen Karten lösten die gleiche Fehlermeldung aus.

Es dauerte eine weitere Stunde, bis das Team feststellte, dass das grüne Licht auf dem Chipkartenleser nicht anzeigte, dass die Karte korrekt eingesteckt war. Als die Techniker die Karte umdrehten, lief der Dienst wieder an und der Ausfall war beendet.

Zuverlässigkeit und Sicherheit sind zwei entscheidende Komponenten eines wirklich vertrauenswürdigen Systems, aber es ist schwierig, Systeme zu entwickeln, die sowohl zuverlässig als auch sicher sind. Die Anforderungen an Zuverlässigkeit und Sicherheit haben zwar viele gemeinsame Eigenschaften, erfordern aber auch unterschiedliche Überlegungen bei der Entwicklung. Es ist leicht, das subtile Zusammenspiel zwischen Zuverlässigkeit und Sicherheit zu übersehen, das zu unerwarteten Resultaten führen kann. Der Ausfall des Passwortmanagers wurde durch ein Zuverlässigkeitsproblem ausgelöst - schlechte Lastausgleichs- und Lastabwurfstrategien - und seine Wiederherstellung wurde später durch mehrere Maßnahmen zur Erhöhung der Sicherheit des Systems erschwert.

Der Schnittpunkt von Sicherheit und Datenschutz

Sicherheit und Datenschutz sind eng miteinander verbunden. Damit ein System die Privatsphäre der Nutzerinnen und Nutzer respektiert, muss es grundlegend sicher sein und sich in Gegenwart eines Angreifers wie beabsichtigt verhalten. Ebenso erfüllt ein perfekt sicheres System nicht die Bedürfnisse vieler Nutzer, wenn es die Privatsphäre der Nutzer nicht respektiert. Auch wenn sich dieses Buch auf die Sicherheit konzentriert, kannst du die allgemeinen Ansätze, die wir beschreiben, oft auch zur Erreichung von Datenschutzzielen einsetzen.

Zuverlässigkeit vs. Sicherheit: Überlegungen zur Gestaltung

Bei der Planung von Zuverlässigkeit und Sicherheit musst du verschiedene Risiken berücksichtigen. Die primären Zuverlässigkeitsrisiken sind nicht böswilliger Natur - zum Beispiel ein fehlerhaftes Software-Update oder ein physischer Geräteausfall. Sicherheitsrisiken hingegen gehen von Angreifern aus, die aktiv versuchen, Schwachstellen im System auszunutzen. Bei der Planung der Zuverlässigkeit gehst du davon aus, dass einige Dinge irgendwann schief gehen werden. Bei der Sicherheitskonzeption musst du davon ausgehen, dass ein Angreifer zu jedem Zeitpunkt versuchen könnte, das System zum Scheitern zu bringen.

Daher sind verschiedene Systeme so konzipiert, dass sie auf ganz unterschiedliche Weise auf Ausfälle reagieren. In Abwesenheit eines Angreifers schlagen Systeme oft sicher fehl (oder sind offen): Ein elektronisches Schloss ist zum Beispiel so konzipiert, dass es bei einem Stromausfall offen bleibt, um einen sicheren Ausgang durch die Tür zu ermöglichen. Das fehlgeschlagene/offene Verhalten kann zu offensichtlichen Sicherheitsschwachstellen führen. Um sich gegen einen Angreifer zu schützen, der einen Stromausfall ausnutzen könnte, könntest du die Tür so konstruieren, dass sie sicher fehlschlägt und geschlossen bleibt, wenn sie nicht mit Strom versorgt wird.

Kompromiss zwischen Zuverlässigkeit und Sicherheit: Redundanz

Bei der Entwicklung von zuverlässigen Systemen musst du oft Redundanzen einbauen. Zum Beispiel schlagen viele elektronische Schlösser sicher fehl, lassen sich aber bei Stromausfällen mit einem physischen Schlüssel öffnen. Ebenso bieten Feuerleitern einen redundanten Fluchtweg für Notfälle. Während Redundanz die Zuverlässigkeit erhöht, vergrößert sie auch die Angriffsfläche. Ein Angreifer muss nur eine Schwachstelle in einem Weg finden, um erfolgreich zu sein.

Kompromiss zwischen Verlässlichkeit und Sicherheit: Incident Management

Die Anwesenheit eines Gegners kann sich auch auf die Methoden der Zusammenarbeit und die Informationen auswirken, die den Einsatzkräften während eines Vorfalls zur Verfügung stehen. Bei Zuverlässigkeitsvorfällen ist es von Vorteil, wenn die Mitarbeiter/innen mehrere Perspektiven einnehmen, um die Ursache schnell zu finden und zu beseitigen. Im Gegensatz dazu willst du bei Sicherheitsvorfällen oft mit einer möglichst kleinen Anzahl von Personen arbeiten, die das Problem effektiv beheben können, damit der Gegner nichts von den Wiederherstellungsmaßnahmen mitbekommt. Im Sicherheitsbereich gibst du Informationen nur weiter , wenn du sie brauchst. Ebenso können umfangreiche Systemprotokolle die Reaktion auf einen Vorfall erleichtern und die Zeit bis zur Wiederherstellung verkürzen, aber - je nachdem, was protokolliert wird - können diese Protokolle auch ein wertvolles Ziel für einen Angreifer sein.

Vertraulichkeit, Integrität, Verfügbarkeit

Sowohl bei der Sicherheit als auch bei der Zuverlässigkeit geht es um die Vertraulichkeit, Integrität und Verfügbarkeit von Systemen, aber sie betrachten diese Eigenschaften durch eine andere Brille. Der wichtigste Unterschied zwischen den beiden Sichtweisen ist das Vorhandensein oder Fehlen eines böswilligen Gegners. Ein zuverlässiges System darf die Vertraulichkeit nicht versehentlich verletzen, wie ein fehlerhaftes Chatsystem, das Nachrichten falsch zustellt, verstümmelt oder verliert. Außerdem muss ein sicheres System einen aktiven Gegner daran hindern, auf vertrauliche Daten zuzugreifen, sie zu manipulieren oder zu zerstören. Schauen wir uns ein paar Beispiele an, die zeigen, wie ein Zuverlässigkeitsproblem zu einem Sicherheitsproblem führen kann.

Hinweis

Vertraulichkeit, Integrität und Verfügbarkeit gelten traditionell als grundlegende Attribute sicherer Systeme und werden als CIA-Dreiklang bezeichnet. Obwohl viele andere Modelle die Menge der Sicherheitsattribute über diese drei hinaus erweitern, hat sich die CIA-Triade im Laufe der Zeit durchgesetzt. Trotz des Akronyms hat dieses Konzept nichts mit der Central Intelligence Agency zu tun.

Vertraulichkeit

In der Luftfahrtindustrie ist ein klemmendes Push-to-Talk-Mikrofon in der Sendeposition ein erhebliches Problem für die Vertraulichkeit. In mehreren gut dokumentierten Fällen hat ein verklemmtes Mikrofon private Gespräche zwischen Piloten im Cockpit übertragen, was eine Verletzung der Vertraulichkeit darstellt. In diesem Fall handelt es sich nicht um einen böswilligen Angreifer: Ein Fehler in der Zuverlässigkeit der Hardware führt dazu, dass das Gerät sendet, obwohl der Pilot dies nicht beabsichtigt.

Integrität

Auch bei der Kompromittierung der Datenintegrität muss kein aktiver Angreifer beteiligt sein. Im Jahr 2015 stellten die Google Site Reliability Engineers (SREs) fest, dass die kryptografischen Integritätsprüfungen einiger Datenblöcke fehlschlugen. Da einige der Rechner, die die Daten verarbeiteten, später Anzeichen von unkorrigierbaren Speicherfehlern aufwiesen, beschlossen die SREs, eine Software zu schreiben, die die Integritätsprüfung für jede Version der Daten mit einem einzigen Bit-Flip (eine 0 wird zu einer 1 oder umgekehrt) vollständig berechnet. Auf diese Weise konnten sie sehen, ob eines der Ergebnisse mit dem Wert der ursprünglichen Integritätsprüfung übereinstimmte. Es stellte sich heraus, dass es sich bei allen Fehlern tatsächlich um einen Ein-Bit-Flip handelte, und die SREs konnten alle Daten wiederherstellen. Interessanterweise war dies ein Fall, in dem eine Sicherheitstechnik bei einem Zuverlässigkeitsvorfall zur Hilfe kam. (Googles Speichersysteme verwenden ebenfalls nicht kryptografische End-to-End-Integritätsprüfungen, aber andere Probleme hinderten die SREs daran, die Bitumkehrungen zu erkennen).

Verfügbarkeit

Schließlich ist die Verfügbarkeit natürlich sowohl ein Zuverlässigkeits- als auch ein Sicherheitsaspekt. Ein Angreifer könnte die Schwachstelle eines Systems ausnutzen, um das System zum Stillstand zu bringen oder den Betrieb für autorisierte Nutzer/innen zu beeinträchtigen. Oder er kontrolliert eine große Anzahl von Geräten, die über die ganze Welt verteilt sind, um einen klassischen verteilten Denial-of-Service-Angriff (DDoS) durchzuführen, bei dem die vielen Geräte angewiesen werden, ein Opfer mit Datenverkehr zu überfluten.

Denial-of-Service (DoS)-Angriffe sind ein interessanter Fall, weil sie sich zwischen den Bereichen Zuverlässigkeit und Sicherheit bewegen. Aus Sicht des Opfers kann ein bösartiger Angriff nicht von einem Designfehler oder einer legitimen Datenverkehrsspitze unterschieden werden. Ein Software-Update aus dem Jahr 2018 führte beispielsweise dazu, dass einige Google Home- und Chromecast-Geräte große synchronisierte Spitzen im Netzwerkverkehr erzeugten, als die Geräte ihre Uhren umstellten, was zu einer unerwarteten Belastung des zentralen Zeitdienstes von Google führte. Ähnlich kann eine große Eilmeldung oder ein anderes Ereignis, das Millionen von Menschen zu nahezu identischen Eingabeaufforderungen veranlasst, einem herkömmlichen DDoS-Angriff auf Anwendungsebene ähneln. Wie in Abbildung 1-1 dargestellt, wurde die Google-Infrastruktur in der San Francisco Bay Area mitten in der Nacht im Oktober 2019 durch ein Erdbeben der Stärke 4,5 mit einer Flut von Anfragen überschwemmt.

Abbildung 1-1. Webverkehr, gemessen in HTTP-Anfragen pro Sekunde, der die Google-Infrastruktur erreicht, die Nutzer in der San Francisco Bay Area bedient, als ein Erdbeben der Stärke 4,5 die Region am 14. Oktober 2019 erschütterte

Verlässlichkeit und Sicherheit: Gemeinsamkeiten

Zuverlässigkeit und Sicherheit sind - im Gegensatz zu vielen anderen Systemmerkmalen - Eigenschaften, die sich aus dem Design eines Systems ergeben. Beide lassen sich im Nachhinein nur schwer nachrüsten, daher solltest du sie idealerweise schon in den frühesten Entwurfsphasen berücksichtigen. Außerdem müssen sie während des gesamten Lebenszyklus des Systems ständig im Auge behalten und getestet werden, denn es ist leicht möglich, dass Systemänderungen sie versehentlich beeinflussen. In einem komplexen System werden die Zuverlässigkeits- und Sicherheitseigenschaften oft durch das Zusammenspiel vieler Komponenten bestimmt, und eine harmlos aussehende Aktualisierung einer Komponente kann die Zuverlässigkeit oder Sicherheit des gesamten Systems in einer Weise beeinträchtigen, die vielleicht erst bei einem Zwischenfall bemerkt wird. Wir wollen diese und andere Gemeinsamkeiten genauer untersuchen.

Unsichtbarkeit

Verlässlichkeit und Sicherheit sind meist unsichtbar, wenn alles gut läuft. Aber eines der Ziele von Zuverlässigkeits- und Sicherheitsteams ist es, das Vertrauen von Kunden und Partnern zu gewinnen und zu erhalten. Eine gute Kommunikation - nicht nur in schwierigen Zeiten, sondern auch, wenn alles gut läuft - ist eine solide Grundlage für dieses Vertrauen. Es ist wichtig, dass die Informationen so ehrlich und konkret wie möglich und frei von Plattitüden und Fachjargon sind.

Leider bedeutet die Unsichtbarkeit von Zuverlässigkeit und Sicherheit in Abwesenheit von Notfällen, dass sie oft als Kosten betrachtet werden, die man ohne unmittelbare Folgen reduzieren oder aufschieben kann. Doch die Kosten für Ausfälle in den Bereichen Zuverlässigkeit und Sicherheit können erheblich sein. Medienberichten zufolge könnten Datenschutzverletzungen dazu geführt haben, dass der Preis, den Verizon für die Übernahme des Internetgeschäfts von Yahoo! im Jahr 2017 gezahlt hat, um 350 Millionen Dollar gesunken ist. Im selben Jahr führte ein Stromausfall dazu, dass wichtige Computersysteme bei Delta Airlines ausfielen, was zu fast 700 Flugausfällen und Tausenden von Verspätungen führte und den Flugdurchsatz von Delta an diesem Tag um etwa 60 % reduzierte.

Bewertung

Da es in der Praxis nicht möglich ist, eine perfekte Zuverlässigkeit oder Sicherheit zu erreichen, kannst du risikobasierte Ansätze verwenden, um die Kosten negativer Ereignisse sowie die Vorab- und Opportunitätskosten für die Vermeidung dieser Ereignisse zu schätzen. Allerdings solltest du die Wahrscheinlichkeit von negativen Ereignissen für Zuverlässigkeit und Sicherheit unterschiedlich bewerten. Du kannst über die Zuverlässigkeit einer Systemzusammensetzung nachdenken und die Entwicklungsarbeit entsprechend den gewünschten Fehlerbudgets planen,¹ Zumindest teilweise, weil du davon ausgehen kannst, dass die einzelnen Komponenten unabhängig voneinander ausfallen. Die Sicherheit einer solchen Zusammensetzung ist schwieriger zu beurteilen. Die Analyse des Entwurfs und der Implementierung eines Systems kann ein gewisses Maß an Sicherheit bieten. Angreifer-Tests - simulierte Angriffe, die in der Regel aus der Perspektive eines bestimmten Angreifers durchgeführt werden - können auch dazu verwendet werden, die Widerstandsfähigkeit eines Systems gegen bestimmte Arten von Angriffen, die Wirksamkeit von Mechanismen zur Erkennung von Angriffen und die möglichen Folgen von Angriffen zu bewerten.

Einfachheit

Ein möglichst einfacher Systementwurf ist eine der besten Methoden, um die Zuverlässigkeit und Sicherheit eines Systems zu beurteilen. Ein einfacheres Design reduziert die Angriffsfläche, verringert das Potenzial für unvorhergesehene Systeminteraktionen und macht es für Menschen einfacher, das System zu verstehen und darüber nachzudenken. Verständlichkeit ist besonders in Notfällen wertvoll, wenn sie den Einsatzkräften hilft, die Symptome schnell zu lindern und die mittlere Reparaturzeit (MTTR) zu verkürzen. Kapitel 6 geht näher auf dieses Thema ein und erörtert Strategien wie die Minimierung von Angriffsflächen und die Isolierung der Verantwortung für Sicherheitsinvarianten in kleinen, einfachen Subsystemen, die unabhängig voneinander durchdacht werden können.

Entwicklung

Unabhängig davon, wie einfach und elegant das ursprüngliche Design ist, bleiben Systeme im Laufe der Zeit selten unverändert. Neue Anforderungen an die Funktionen, Änderungen des Umfangs und die Weiterentwicklung der zugrunde liegenden Infrastruktur führen zu mehr Komplexität. Auf der Sicherheitsseite kann die Notwendigkeit, mit den sich entwickelnden Angriffen und neuen Gegnern Schritt zu halten, die Systemkomplexität ebenfalls erhöhen. Außerdem kann der Druck, den Anforderungen des Marktes gerecht zu werden, dazu führen, dass Systementwickler und -betreuer an der falschen Stelle sparen und technische Schulden anhäufen. Kapitel 7 geht auf einige dieser Herausforderungen ein.

Komplexität sammelt sich oft ungewollt an, aber das kann zu Kipp-Punkt-Situationen führen, in denen eine kleine und scheinbar harmlose Änderung große Auswirkungen auf die Zuverlässigkeit oder Sicherheit eines Systems hat. Ein 2006 eingeführter und fast zwei Jahre später entdeckter Fehler in der Debian GNU/Linux-Version der OpenSSL-Bibliothek ist ein berüchtigtes Beispiel für einen großen Fehler, der durch eine kleine Änderung verursacht wurde. Einem Open-Source-Entwickler fiel auf, dass Valgrind, ein Standardwerkzeug zur Fehlersuche bei Speicherproblemen, Warnungen über den vor der Initialisierung verwendeten Speicher meldete. Um die Warnungen zu beseitigen, entfernte der Entwickler zwei Codezeilen. Leider führte dies dazu, dass der Pseudo-Zufallszahlengenerator von OpenSSL nur mit einer Prozess-ID geimpft wurde, die unter Debian damals standardmäßig eine Zahl zwischen 1 und 32.768 war. So konnten kryptografische Schlüssel leicht mit roher Gewalt geknackt werden.

Google ist nicht immun gegen Ausfälle, die durch scheinbar harmlose Änderungen ausgelöst werden. Im Oktober 2018 zum Beispiel war YouTube wegen einer kleinen Änderung in einer allgemeinen Protokollierungsbibliothek weltweit mehr als eine Stunde lang nicht erreichbar. Eine Änderung, mit der die Granularität der Ereignisprotokollierung verbessert werden sollte, sah sowohl für den Autor als auch für den designierten Codeüberprüfer harmlos aus und bestand alle Tests. Die Entwickler waren sich jedoch nicht im Klaren über die Auswirkungen der Änderung auf YouTube: Unter Produktionslast führte die Änderung dazu, dass den YouTube-Servern schnell der Speicher ausging und sie abstürzten. Als die Ausfälle den Nutzerverkehr auf andere, noch gesunde Server verlagerten, brachten kaskadenartige Ausfälle den gesamten Dienst zum Stillstand.

Resilienz

Natürlich sollte ein Problem mit der Arbeitsspeicherauslastung nicht zu einem globalen Ausfall des Dienstes geführt haben. Systeme sollten so konzipiert sein, dass sie auch unter ungünstigen oder unerwarteten Umständen belastbar sind. Aus Sicht der Zuverlässigkeit werden solche Umstände oft durch unerwartet hohe Last oder Komponentenausfälle verursacht. Die Auslastung ist eine Funktion des Volumens und der durchschnittlichen Kosten der Anfragen an das System. Du kannst also Ausfallsicherheit erreichen, indem du einen Teil der eingehenden Last abwirfst (weniger verarbeitest) oder die Verarbeitungskosten für jede Anfrage reduzierst (billigere Verarbeitung). Um Ausfällen von Komponenten entgegenzuwirken, sollte das Systemdesign Redundanz und verschiedene Fehlerdomänen vorsehen, damit du die Auswirkungen von Ausfällen durch das Umleiten von Anfragen begrenzen kannst. In Kapitel 8 werden diese Themen näher erörtert und in Kapitel 10 wird insbesondere auf DoS-Abwehrmaßnahmen eingegangen.

Wie widerstandsfähig die einzelnen Komponenten eines Systems auch sein mögen, sobald es komplex genug ist, kannst du nicht mehr ohne Weiteres nachweisen, dass das gesamte System immun gegen Kompromisse ist. Dieses Problem lässt sich zum Teil durch "Defense in Depth" und unterschiedliche Fehlerdomänen lösen. Defense in depth" bedeutet, dass mehrere, manchmal redundante, Verteidigungsmechanismen eingesetzt werden. Unterschiedliche Fehlerdomänen begrenzen den "Radius" eines Fehlers und erhöhen damit auch die Zuverlässigkeit. Ein gutes Systemdesign schränkt die Möglichkeiten eines Angreifers ein, einen kompromittierten Host oder gestohlene Anmeldedaten auszunutzen, um sich seitlich zu bewegen oder seine Rechte zu erweitern und andere Teile des Systems zu beeinflussen.

Du kannst verschiedene Fehlerdomänen einrichten, indem du die Berechtigungen aufteilst oder den Geltungsbereich der Anmeldeinformationen einschränkst. Die interne Infrastruktur von Google unterstützt zum Beispiel Zugangsdaten, die explizit auf eine bestimmte geografische Region beschränkt sind. Solche Funktionen können die Möglichkeiten eines Angreifers einschränken, der einen Server in einer Region kompromittiert und seitlich auf Server in anderen Regionen zugreifen kann.

Die Verwendung unabhängiger Verschlüsselungsebenen für sensible Daten ist ein weiterer gängiger Mechanismus für die Tiefenverteidigung. Auch wenn Festplatten eine Verschlüsselung auf Geräteebene bieten, ist es oft sinnvoll, die Daten auch auf der Anwendungsebene zu verschlüsseln. Auf diese Weise reicht selbst eine fehlerhafte Implementierung eines Verschlüsselungsalgorithmus in einem Laufwerks-Controller nicht aus, um die Vertraulichkeit der geschützten Daten zu gefährden, wenn ein Angreifer physischen Zugriff auf ein Speichergerät erhält.

Während die bisher genannten Beispiele von externen Angreifern ausgehen, musst du auch potenzielle Bedrohungen durch böswillige Insider in Betracht ziehen. Obwohl ein Insider vielleicht mehr über potenzielle Missbrauchsvektoren weiß als ein externer Angreifer, der zum ersten Mal die Anmeldedaten eines Mitarbeiters stiehlt, unterscheiden sich die beiden Fälle in der Praxis oft nicht sehr. Das Prinzip der geringsten Privilegien kann Insider-Bedrohungen eindämmen. Es besagt, dass ein Benutzer nur über die minimalen Rechte verfügen sollte, die für die Ausübung seiner Tätigkeit erforderlich sind. Mechanismen wie sudo von Unix unterstützen zum Beispiel fein abgestufte Richtlinien, die festlegen, welche Benutzer welche Befehle in welcher Rolle ausführen dürfen.

Bei Google verwenden wir außerdem eine Mehrparteien-Autorisierung, um sicherzustellen, dass sensible Vorgänge von bestimmten Gruppen von Mitarbeitern überprüft und genehmigt werden. Dieser Mehrparteien-Mechanismus schützt sowohl vor böswilligen Insidern als auch vor unschuldigen menschlichen Fehlern, einer häufigen Ursache für Zuverlässigkeitsmängel. Least Privilege und Mehrparteienautorisierung sind keine neuen Ideen - sie wurden bereits in vielen Szenarien außerhalb der Computerwelt eingesetzt, von Atomraketen bis hin zu Banktresoren. In Kapitel 5 werden diese Konzepte eingehend behandelt.

Vom Entwurf zur Produktion

Sicherheits- und Zuverlässigkeitsaspekte sollten auch bei der Umsetzung eines soliden Entwurfs in ein vollständig eingesetztes Produktionssystem berücksichtigt werden. Schon bei der Entwicklung des Codes gibt es Möglichkeiten, potenzielle Sicherheits- und Zuverlässigkeitsprobleme durch Codeüberprüfungen zu erkennen und sogar ganze Klassen von Problemen zu vermeiden, indem gemeinsame Frameworks und Bibliotheken verwendet werden. In Kapitel 12 werden einige dieser Techniken erläutert.

Bevor du ein System in Betrieb nimmst, kannst du mit Tests sicherstellen, dass es sowohl in normalen Szenarien als auch in den Kantenfällen, die sich typischerweise auf die Zuverlässigkeit und Sicherheit auswirken, korrekt funktioniert. Egal, ob du Lasttests verwendest, um das Verhalten eines Systems bei einer Flut von Anfragen zu verstehen, Fuzzing, um das Verhalten bei potenziell unerwarteten Eingaben zu untersuchen, oder spezielle Tests, um sicherzustellen, dass kryptografische Bibliotheken keine Informationen preisgeben - Testen spielt eine entscheidende Rolle, um sicherzustellen, dass das System, das du tatsächlich gebaut hast, deinen Designabsichten entspricht. In Kapitel 13 werden diese Ansätze eingehend behandelt.

Und schließlich können einige Ansätze für die tatsächliche Bereitstellung von Code (siehe Kapitel 14) das Sicherheits- und Zuverlässigkeitsrisiko begrenzen. Canaries und langsame Rollouts können zum Beispiel verhindern, dass das System für alle Nutzer gleichzeitig kaputt geht. Auch ein Verteilungssystem, das nur ordnungsgemäß geprüften Code akzeptiert, kann das Risiko verringern, dass ein Insider eine bösartige Binärdatei in die Produktion einschleust.

Systeme und Logging untersuchen

Bisher haben wir uns auf Konstruktionsprinzipien und Implementierungsansätze konzentriert, um sowohl Zuverlässigkeits- als auch Sicherheitsmängel zu verhindern. Leider ist es meist unpraktisch oder zu teuer, perfekte Zuverlässigkeit oder Sicherheit zu erreichen. Du musst davon ausgehen, dass Präventivmechanismen fehlschlagen werden, und einen Plan ausarbeiten, um Fehler zu erkennen und zu beheben.

Wie wir in Kapitel 15 besprechen, ist eine gute Protokollierung die Grundlage für die Erkennung von und die Vorbereitung auf Ausfälle. Im Allgemeinen gilt: Je vollständiger und detaillierter die Logs sind, desto besser - aber diese Richtlinie hat einige Einschränkungen. Bei ausreichender Größe verursacht das Log-Volumen erhebliche Kosten, und eine effektive Analyse der Logs kann schwierig werden. Das YouTube-Beispiel weiter oben in diesem Kapitel zeigt, dass die Protokollierung auch zu Problemen mit der Zuverlässigkeit führen kann. Sicherheitsprotokolle stellen eine zusätzliche Herausforderung dar: Protokolle sollten in der Regel keine sensiblen Informationen enthalten, wie z. B. Authentifizierungsdaten oder personenbezogene Daten, damit die Protokolle selbst nicht zu einem attraktiven Ziel für Angreifer werden.

Krisenreaktion

Bei einem Notfall müssen die Teams schnell und reibungslos zusammenarbeiten, denn Probleme können unmittelbare Folgen haben. Im schlimmsten Fall kann ein Vorfall ein Unternehmen innerhalb von Minuten zerstören. Im Jahr 2014 zum Beispiel legte ein Angreifer den Code-Hosting-Dienst Code Spaces innerhalb weniger Stunden lahm, indem er die Verwaltungstools des Dienstes übernahm und alle Daten, einschließlich aller Backups, löschte. Eine gut eingespielte Zusammenarbeit und ein gutes Incident Management sind entscheidend für rechtzeitige Reaktionen in solchen Situationen.

Die Organisation der Krisenbewältigung ist eine Herausforderung, daher ist es am besten, einen Plan zu haben, bevor ein Notfall eintritt. Wenn du einen Vorfall entdeckst, tickt die Uhr vielleicht schon seit einiger Zeit. In jedem Fall arbeiten die Einsatzkräfte unter Stress und Zeitdruck und (zumindest anfangs) mit einem begrenzten Situationsbewusstsein. Wenn ein Unternehmen groß ist und der Vorfall eine 24/7-Reaktionsfähigkeit oder eine Zusammenarbeit über Zeitzonen hinweg erfordert, erschwert die Notwendigkeit, den Status zwischen den Teams aufrechtzuerhalten und das Vorfallsmanagement an den Grenzen der Arbeitsschichten abzugeben, den Betrieb zusätzlich. Bei Sicherheitsvorfällen besteht in der Regel auch ein Spannungsverhältnis zwischen dem Wunsch, alle wichtigen Beteiligten einzubeziehen, und der Notwendigkeit - oft aufgrund gesetzlicher oder behördlicher Vorschriften -, die Weitergabe von Informationen auf eine "Need-to-know"-Basis zu beschränken. Außerdem kann der erste Sicherheitsvorfall nur die Spitze des Eisbergs sein. Die Untersuchung könnte über die Unternehmensgrenzen hinausgehen oder die Strafverfolgungsbehörden einbeziehen.

In einer Krise sind eine klare Befehlskette und ein solider Satz von Checklisten, Spielbüchern und Protokollen unerlässlich. Wie in den Kapiteln 16 und 17 beschrieben, hat Google die Krisenreaktion in einem Programm namens Incident Management at Google (IMAG) kodifiziert, das einen einheitlichen Standard für den Umgang mit allen Arten von Vorfällen - von Systemausfällen bis hin zu Naturkatastrophen - festlegt und eine effektive Reaktion organisiert. Das IMAG wurde nach dem Vorbild des Incident Command System (ICS) der US-Regierung entwickelt, einem standardisierten Ansatz für die Leitung, Kontrolle und Koordination von Notfallmaßnahmen zwischen den Einsatzkräften verschiedener Behörden.

Wenn die Einsatzkräfte nicht mit dem Druck eines laufenden Ereignisses konfrontiert sind, gibt es in der Regel lange Zeiträume mit wenig Aktivität. In dieser Zeit müssen die Teams ihre Fähigkeiten und ihre Motivation aufrechterhalten und die Prozesse und die Infrastruktur in Vorbereitung auf den nächsten Notfall verbessern. Das Disaster Recovery Testing Programm (DiRT) von Google simuliert regelmäßig verschiedene interne Systemausfälle und zwingt die Teams, mit solchen Szenarien umzugehen. Häufige offensive Sicherheitsübungen testen unsere Verteidigung und helfen, neue Schwachstellen zu identifizieren. Google setzt die IMAG auch bei kleineren Zwischenfällen ein, was uns zusätzlich dazu auffordert, regelmäßig Notfallwerkzeuge und -prozesse zu üben.

Erholung

Die Behebung einer Sicherheitslücke erfordert oft das Patchen von Systemen, um eine Schwachstelle zu beheben. Intuitiv möchtest du, dass dieser Prozess so schnell wie möglich abläuft und Mechanismen verwendet werden, die regelmäßig geübt werden und daher zuverlässig sind. Die Fähigkeit, Änderungen schnell zu veröffentlichen, ist jedoch ein zweischneidiges Schwert: Während diese Fähigkeit dazu beitragen kann, Sicherheitslücken schnell zu schließen, kann sie auch Bugs oder Leistungsprobleme einführen, die großen Schaden anrichten. Der Druck, Patches schnell zu veröffentlichen, ist größer, wenn die Sicherheitslücke weithin bekannt oder schwerwiegend ist. Die Entscheidung, ob die Patches langsam verteilt werden sollen - und damit mehr Sicherheit besteht, dass es keine unbeabsichtigten Nebenwirkungen gibt, aber das Risiko besteht, dass die Schwachstelle ausgenutzt wird - oder ob sie schnell verteilt werden sollen, hängt letztlich von einer Risikobewertung und einer geschäftlichen Entscheidung ab. So kann es zum Beispiel akzeptabel sein, etwas Leistung zu verlieren oder die Ressourcennutzung zu erhöhen, um eine schwerwiegende Sicherheitslücke zu schließen.

Entscheidungen wie diese unterstreichen den Bedarf an zuverlässigen Wiederherstellungsmechanismen, die es uns ermöglichen, notwendige Änderungen und Aktualisierungen schnell durchzuführen, ohne die Zuverlässigkeit zu beeinträchtigen, und die auch potenzielle Probleme erkennen, bevor sie einen weitreichenden Ausfall verursachen. Ein robustes Flottenwiederherstellungssystem muss zum Beispiel eine zuverlässige Darstellung des aktuellen und des gewünschten Zustands jeder Maschine haben und muss außerdem Backstops bereitstellen, um sicherzustellen, dass dieser Zustand nie auf eine veraltete oder unsichere Version zurückgesetzt wird. Kapitel 9 befasst sich mit diesem und vielen anderen Ansätzen, und in Kapitel 18 geht es darum, wie man Systeme tatsächlich wiederherstellt, wenn ein Ereignis eingetreten ist.

Fazit

Sicherheit und Zuverlässigkeit haben viel gemeinsam - beides sind inhärente Eigenschaften aller Informationssysteme, die anfangs verlockend sind, im Namen der Geschwindigkeit zu opfern, aber im Nachhinein kostspielig zu beheben. Dieses Buch soll dir dabei helfen, die unvermeidlichen Herausforderungen in Bezug auf Sicherheit und Zuverlässigkeit frühzeitig anzugehen, wenn sich deine Systeme weiterentwickeln und wachsen. Neben den technischen Bemühungen muss jede Organisation die Rollen und Verantwortlichkeiten (siehe Kapitel 20) verstehen, die zum Aufbau einer Kultur der Sicherheit und Zuverlässigkeit(Kapitel 21) beitragen, um nachhaltige Praktiken aufrechtzuerhalten. Indem wir unsere Erfahrungen und Erkenntnisse mit dir teilen, hoffen wir, dass du es vermeiden kannst, später einen höheren Preis zu zahlen, indem du einige der hier beschriebenen Prinzipien früh genug im Lebenszyklus deines Systems anwendest.

Wir haben dieses Buch mit Blick auf ein breites Publikum geschrieben, damit du es unabhängig von der Phase oder dem Umfang deines Projekts relevant findest. Behalte bei der Lektüre das Risikoprofil deines Projekts im Hinterkopf - der Betrieb einer Börse oder einer Kommunikationsplattform für Dissidenten hat ein ganz anderes Risikoprofil als der Betrieb einer Website für ein Tierschutzgebiet. Im nächsten Kapitel werden die verschiedenen Arten von Gegnern und ihre möglichen Beweggründe im Detail erläutert.

¹ Weitere Informationen zu Fehlerbudgets findest du in Kapitel 3 des SRE-Buches.