CIA, (to) DIE, or CAP?

TLAs. Three Letter Acronyms. Drei-Buchstaben-Abkürzungen. Da besteht immer die Gefahr, dass jeder etwas anderes darunter versteht, und eine meiner wichtigsten Erfahrungen im Berufsleben war tatsächlich, bei Abkürzungen und auch bei Begriffen erstmal nachzufragen, was die Kollegen darunter verstehen. Überraschungen garantiert. Und erleichterte Gesichter bei Kollegen, die auch Zweifel am gemeinsamen Verständnis hatten, sich selbst aber nicht trauten nachzufragen.

CIA

Nein, nicht Central Intelligence Agency. Auch keine der anderen Abkürzungen von CIA auf Wikipedia. Im Sicherheitsumfeld meinen wir eigentlich immer Confidentiality (Vertraulichkeit), Integrity (Integrität), und Availability (Verfügbarkeit), die drei allgemeinen, klassischen Schutzziele in der Informationssicherheit. Angereichert um Belastbarkeit finden sie sich auch in Artikel 32 Abs. 1 DSGVO.

DIE

Nein, nicht sterben, auch wenn David Fuhr in der ix 06/2023 schreibt, CIA ist tot, und das dann in ix 07/2023 widerruft. DIE steht für Distributed (Verteilung), Immutable (Unveränderlichkeit), Ephemeral (Vergänglichkeit), und ist kein Ersatz für CIA, sondern ein Ansatz, bisherige Annahmen wie wir Systeme betreiben in Frage zu stellen und damit vielleicht auch zu anderen Lösungen zu kommen (unterhaltsam auf Englisch in Sounil Yu: New Paradigms for the Next Era of Security).

CAP

Jetzt kommen wir zum eigentlichen Problem: Consistency (Konsistenz), Availability (Verfügbarkeit), Partition Tolerance (Ausfalltoleranz). Das CAP-Theorem oder Brewers Theorem besagt, dass es in einem verteilten System unmöglich ist, gleichzeitig die drei Eigenschaften Consistency (Konsistenz), Availability (Verfügbarkeit) und Partition Tolerance (Ausfalltoleranz) zu garantieren.

Das CAP-Theorem hat sich in Deutschland leider noch nicht durchgesetzt hat – so wie auch andere magische Dreiecke, wie z.B. das bekannteste und trotzdem selten beachtete der agilen Softwareindustrie, man kann nicht Zeit oder Ressourcen, Funktionsumfang, und Qualität fest vorausplanen. Eine dieser Dimensionen ist immer variabel, und wenn man sich nicht entscheidet, dann meist die Qualität. Und dass eine Schwangerschaft sich nicht mit 9 Frauen auf einen Monat beschleunigen lässt haben viele Manager leider auch noch nicht verstanden.

Tatsächlich lohnt es sich, diese Abkürzungen und Konflikte im Zusammenhang zu sehen. Auch wenn die klassischen Schutzziele andeuten, alles sei gleich wichtig, sie sind es nicht. Wenn ich konsequent verschlüssele und authentifiziere, erreiche ich nur CI. Für das A brauche ich mindestens Backups, besser Redundanz, und sobald ich über Redundanz nachdenke muss ich das CAP-Theorem beachten. Da Ausfälle – egal ob Strom, Internet, Hardware oder Software – immer eintreten können, muss man sich zwischen Konsistenz und Verfügbarkeit entscheiden, und die klassischen relationalen Datenbanken oder Hochverfügbarkeits-Cluster implizieren eine Entscheidung für Konsistenz und nicht für Verfügbarkeit. Weil diese Aussage beim Hochverfügbarkeits-Cluster auf Stirnrunzeln stoßen wird: genaugenommen kann es in einer Architektur unterschiedliche Ebenen geben in denen die Entscheidung unterschiedlich getroffen wird. Solange der Cluster ein funktionierendes internes Netz hat, ist die Welt in Ordnung, fällt dieses aus, fällt der Cluster insgesamt aus. Wikipedia stuft relationale Datenbanken als CA ein, aber Partitionierungen kann man nicht einfach wegdefinieren.

Als ich im Herbst 2020 eine Vorlesung über Verteilte Systeme gehalten habe war für mich klar, das CAP-Theorem muss rein, auch die oft unverstandenen Probleme von Netzwerken und verteilten Datenbanken. Das Skript eines Professors den mein Vorgänger mir vermittelt hat – leider nichts dazu. Das Standardwerk Maarten van Steen, Andrew S. Tanenbaum: Distributed Systems bespricht das CAP-Theorem erst in der 3. Auflage von 2017 und dort in Abschnitt 8.2, aber es bleibt unklar, welche der vorhergehenden Kapitel damit noch richtig und anwendbar sind.

Weil komplexe Software schwierig zu entwickeln und zu warten ist, haben Entwickler von Cloud-Software – Amazon, Netflix, Spotify – die Microservices erfunden, die idealerweise einen Ausschnitt des Gesamtproblems adressieren und idealerweise auch unabhängig entwickelt, getestet, installiert, und aktualisiert werden können. Auch wird damit das magische Dreieck des Projektmanagements beherrschbarer. Wenn Änderungen und damit Ausfälle aber häufig stattfinden, dann muss man den Ausfall zum Normalfall erklären, und genau das hat Martin Fowler: Blue/Green Deployment gemacht und damit Continuous Integration/Delivery geprägt. Viele Entwickler schütteln dann leider den Kopf und verwerfen die zweite Datenbank oder Persistenz, und handeln sich damit halt wieder das Verfügbarkeitsproblem ein. Auch der Chaos Monkey entstammt der Denkweise, Ausfälle sind der Normalfall. Hat man das wirklich verstanden, dann ist DIE eigentlich keine Überraschung mehr. Für mich ist DIE auch kein Schutzziel wie CIA, sondern ein Mittel um die Verfügbarkeit trotz Ausfällen durch Änderungen einschließlich Sicherheitskorrekturen zu erreichen oder zumindest zu verbessern. Und es ist auf jeden Fall moderner als das klassische Verlegen der erforderlichen Downtime auf den Feierabend, das Wochenende, oder manchmal auch das Jahresende. Dennoch: nur weil die Systeme kürzer leben sind sie nicht automatisch sicherer im Sinne von CI ohne A. Sarkastisch könnte ich auch behaupten, wer CIA durch DIE ersetzt, der hat aufgegeben, CI zu erreichen.

Stellenanzeigen mit den Stichworten Microservices, Springboot, Java, MySQL oder auch eine andere Datenbank – haben die das Problem verstanden? Ich vermute nein. Das sind Macroservices, die Probleme mehr anziehen als lösen, von Log4j über den Speicher- und damit Ressourcenverbrauch bis hin zur fehlenden Ausfallsicherheit.

Oder Artikel wie NAS im Eigenbau statt vorkonfektionierter Fertigsysteme: Ein Sicherheitskonzept fehlt, Backups werden nicht erwähnt. Auch keine Links zu entsprechenden Artikeln. Nein, die Verwendung von DRBD ist kein Backup, und dass eigentlich nicht definiert ist, was passieren kann, wenn man wirklich die Replikationsrichtung bei einem Ausfall umdreht wäre schon wert, dargestellt zu werden. Sogar die Entwickler von DRBD haben meine Frage nicht beantwortet. Wenn man das CAP-Theorem verstanden hat, dann ist eigentlich klar dass es nicht ausreicht, den Festplatteninhalt von einem System auf das andere zu replizieren, sondern man braucht um die Konsistenz zu garantieren analog zu einer Datenbank ein Undo-Log um die Änderungen rückgängig machen zu können falls die Replikation beim Fail-Over umgedreht werden soll. Davon steht leider nichts im Artikel. Eine Warnung findet sich verklausuliert auf Replication modes dadurch, dass kein Mode beim Wiederanlauf nach einem Ausfall Konsistenz garantiert. Ein inkonsistentes Dateisystem ist bestimmt das allerletzte was man haben will. Dieser Artikel ist allenfalls Halbwissen und ich rate davon ab, ein redundantes NAS so aufzubauen.

Oder reicht ihnen abwarten und beten? Oder §3 kölsches Grundgesetz Et hätt noch immer jot jejange. Notfalls zurück zur Schreibmaschine wie beim Berliner Kammergericht? Ob Hackerangriff oder Stromausfall – einerlei. Denken Sie bitte an den Wiederaufbau.

Alle Anwendungen hochverfügbar zu machen und in redundante Microservices zu migrieren ist aber auch keine Lösung – das ist teuer in der Entwicklung und im Betrieb, kostet Geld und verursacht CO₂. Tatsächlich sollte man für seine Organisation definieren, welche Verfahren oder Prozesse überlebenswichtig sind, und dann für die dafür erforderlichen Systeme die Verfügbarkeitsanforderungen ableiten. Soweit auch völlig richtig der BSI Standard 200-4 Business-Continuity-Management. Allerdings fehlt die Übersetzung für das IT-Continuity-Management, nämlich dass ich auf IT Ebene das CAP-Theorem beachten muss, und dass bei der Umsetzung DIE ein guter Weg ist.

Schlusswort: wenn Sie nicht alle Abkürzungen oder Begriffe dieses Artikels kannten, dann sind sie in guter Gesellschaft. Trauen Sie sich nachzufragen. Und auch TLA ist eine überladene Abkürzung. Es stand in den 80ern auch für The Last Assembler, denn die Entwickler an der University of California at San Diego glaubten, ihr Assembler sei so generisch, dass er der letzte sein werde. Leider war er auch so langsam, dass er aus Sicht der Anwender das letzte was man verwenden will war.